Redacted Fields in the Registration Data Access Protocol (RDAP) Response
draft-ietf-regext-rdap-redacted-16

Yes

Murray Kucherawy

No Objection

Erik Kline
Francesca Palombini
Jim Guichard
John Scudder
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
(Andrew Alston)
(Robert Wilton)

Note: This ballot was opened for revision 14 and is now closed.

Murray Kucherawy
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Paul Wouters
(was Discuss) No Objection
Comment (2023-11-09 for -15) Sent 
Thanks for addressing my Security Considerations issue. I have updated my ballot to 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.
Warren Kumari
No Objection
Comment (2023-09-20 for -14) Not sent 
Thank you very much for writing this document; I found it well written and clear.
Zaheduzzaman Sarker
No Objection
Comment (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 ?
Éric Vyncke
No Objection
Andrew Alston Former IESG member
No Objection
No Objection (for -14) Not sent 

                            

                        
                    

                
            
                
                    

                        

                            Robert Wilton Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (for -14)
                                
                                
                                    
                                         Not sent