> -----Original Message----- > From: Roman Danyliw <r...@cert.org> > Sent: Sunday, November 5, 2023 11:15 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; i...@ietf.org > Cc: draft-ietf-regext-rdap-ope...@ietf.org; regext-cha...@ietf.org; > regext@ietf.org; AlBanna, Zaid <zalba...@verisign.com> > Subject: [EXTERNAL] RE: [regext] Roman Danyliw's Discuss on draft-ietf- > regext-rdap-openid-25: (with DISCUSS and COMMENT) > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > Hi Scott! > > Thanks for -26 is addresses all but the following feedback. Please see > below > ... > > > -----Original Message----- > > From: Hollenbeck, Scott <shollenb...@verisign.com> > > Sent: Wednesday, October 4, 2023 11:29 AM > > To: r...@cert.org; i...@ietf.org > > Cc: draft-ietf-regext-rdap-ope...@ietf.org; regext-cha...@ietf.org; > > regext@ietf.org; AlBanna, Zaid <zalba...@verisign.com> > > Subject: Re: [regext] Roman Danyliw's Discuss on > > draft-ietf-regext-rdap-openid- > > 25: (with DISCUSS and COMMENT) > > > > Thanks for the review, Roman. I'll reply below. > > > > > -----Original Message----- > > > From: Roman Danyliw via Datatracker <nore...@ietf.org> > > > Sent: Tuesday, October 3, 2023 10:06 PM > > > To: The IESG <i...@ietf.org> > > > Cc: draft-ietf-regext-rdap-ope...@ietf.org; regext-cha...@ietf.org; > > > regext@ietf.org; AlBanna, Zaid <zalba...@verisign.com>; AlBanna, > > > Zaid <zalba...@verisign.com> > > > Subject: [EXTERNAL] Roman Danyliw's Discuss on > > > draft-ietf-regext-rdap- > > > openid-25: (with DISCUSS and COMMENT) > > > > > > Caution: This email originated from outside the organization. Do not > > > click links or open attachments unless you recognize the sender and > > > know the content is safe. > > > > > > Roman Danyliw has entered the following ballot position for > > > draft-ietf-regext-rdap-openid-25: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > [SAH] [snip] > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > [snip] > > > > ** Section 11. > > > An RDAP server > > > operator SHOULD develop policies for information disclosure to ensure > > > that personally identifiable information is disclosed only to clients > > > that are authorized to process that information. > > > > > > Why is this not a MUST? What are the circumstances where PII should > > > be disclosed without authorization? > > > > [SAH] The SHOULD is about policy development, not information > > disclosure. I don't think a protocol specification like this can > > mandate development of an operational policy. > > I read this text as the policy being the key thing that ensures there isn't > disclosure of PII since the sentence construction is that the "RDAP server > operator SHOULD ... <something> to ensure <disclosure doesn't happen>". > Is that not the intent? > > Stepping back, is the thinking that RDAP operators could be operating > without a policy around handling who gets PII in their data? > > Per your comment of "I don't think a protocol specification like this can > mandate development of an operational policy", why can a protocol spec say > SHOULD but not MUST? Policy or not, shouldn't RDAP operators ensure that > whatever they do the "PII is disclosed only to clients that are authorized > ..."? > Would using lower case words work for the guidance you want to provide, > say "An RDAP server operator must develop and enforce policies for > information disclosure ..."?
[SAH] All good points! My original reply was focused on discomfort with saying that an operator MUST (normative MUST here) do something that has nothing to do with interoperability; SHOULD seemed like a softer, but still strong, suggestion. I like the idea if a non-normative "must" because it reflects the reality that operators will develop policies with some certainty, but doing so isn't an interoperability mandate. I'll change the text to use "must" instead of "SHOULD" and will publish an update in a few minutes. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
