Redacted Fields in the Registration Data Access Protocol (RDAP) Response
draft-ietf-regext-rdap-redacted-16
Yes
(Murray Kucherawy)
No Objection
Éric Vyncke
Jim Guichard
(Andrew Alston)
(Erik Kline)
(Francesca Palombini)
(John Scudder)
(Robert Wilton)
Note: This ballot was opened for revision 14 and is now closed.
Éric Vyncke
No Objection
Jim Guichard
No Objection
Roman Danyliw
No Objection
Comment
(2023-09-19 for -14)
Sent
Thank you to Hilarie Orman for the SECDIR review. ** Section 3. Redaction in RDAP can be handled in multiple ways. The resulting redacted RDAP response MUST comply with the RDAP RFCs, such as [RFC9083]. This language of “comply with the RDAP RFCs” seems to too imprecise given the normative MUST. Is there a way to be more precise? Could this be scoped to “RFC9083 and updates”? ** Section 8. Servers MAY exclude the redacted members for RDAP fields that are considered a privacy issue in providing a data existence signal. Could this please be expanded upon? Is this practically saying if the fields are “sufficiently privacy sensitive” (where the existence of the data must not be revealed then) ignore the redaction mechanism in this draft? ** The SECDIR review thread (https://mailarchive.ietf.org/arch/msg/secdir/lqQBoljsw6aP2bgiVQOMzHBKpWU/) suggested additional language around a published redaction policy. Recognizing the operational details noted in https://mailarchive.ietf.org/arch/msg/secdir/f3--V4Wfzk_m6cBGQCj-FTldRFM/, I would recommend adding an Operational Consideration sections saying something to the effect of: NEW (rough text) Operational Considerations RDAP server operators MAY choose to publish a redaction policy describing how this extension is implemented for their constituency. The contents of such a policy are outside the scope of this specification.
Murray Kucherawy Former IESG member
Yes
Yes
(for -14)
Unknown
Andrew Alston Former IESG member
No Objection
No Objection
(for -14)
Not sent
Erik Kline Former IESG member
No Objection
No Objection
(for -14)
Not sent
Francesca Palombini Former IESG member
No Objection
No Objection
(for -14)
Not sent
John Scudder Former IESG member
No Objection
No Objection
(for -14)
Not sent
Paul Wouters Former IESG member
(was Discuss)
No Objection
No Objection
(2023-11-09 for -15)
Sent
Thanks for addressing my Security Considerations issue. I have updated my ballot to No Objection.
Robert Wilton Former IESG member
No Objection
No Objection
(for -14)
Not sent
Warren Kumari Former IESG member
No Objection
No Objection
(2023-09-20 for -14)
Not sent
Thank you very much for writing this document; I found it well written and clear.
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection
(2023-09-20 for -14)
Sent
Thanks for working on this specification. May be this is not related to this document rather on JSONPath base document but should there be no internationalization considerations here? how much off the track I am on that ?