> -----Original Message----- > From: Warren Kumari <war...@kumari.net> > Sent: Monday, July 30, 2018 12:37 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-regext-rdap-object-...@ietf.org; Gould, James > <jgo...@verisign.com>; regext-cha...@ietf.org; Gould, James > <jgo...@verisign.com>; regext@ietf.org; tim.ch...@jisc.ac.uk > Subject: [EXTERNAL] Warren Kumari's No Objection on draft-ietf-regext- > rdap-object-tag-04: (with COMMENT) > > Warren Kumari has entered the following ballot position for > draft-ietf-regext-rdap-object-tag-04: No Objection > > 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.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-object-tag/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this - it solves a useful purpose, and is clear and > easy to read. > > I had 2 comments / questions - please also see Tim Chown'sOpsDir review > for a useful nit. > > Section 2. Object Naming Practice > The entire 'HYPHEN-MINUS' selection makes me slightly twitchy - the > argument that it was chosen because it is commonly already used as a > separator feels like it cuts both ways - the fact that 'Handles can > themselves contain HYPHEN-MINUS characters' already seems to argue that a > different separator should have been chosen to minimize the chance of > collisions / people getting this wrong. I get that the document says "the > service provider identifier is found following the last HYPHEN-MINUS > character in the tagged identifier", and would feel more comfortable if > some of the examples contained more than one hyphen to make this clearer.
Thanks for the review, Warren. We actually had quite a debate in the WG about the separator character (witness the change log). I could change one of the examples in Section 2 if that would be helpful. > Section 7. Security Considerations > 'The transport used to access the IANA registries can be more secure by > using TLS [RFC5246], which IANA supports.' I'm confused by this sentence > in the Security Considerations section - more secure than what, not using > TLS? Why isn't this something like "The transport used to access the IANA > registries SHOULD (or MUST) be over TLS"? Benjamin also had a comment about this text. I proposed this change in my reply to him: OLD: This practice helps to ensure that end users will get RDAP data from an authoritative source using a bootstrap method to find authoritative RDAP servers, reducing the risk of sending queries to non-authoritative sources. The method has the same security properties as the RDAP protocols themselves. The transport used to access the IANA registries can be more secure by using TLS [RFC5246], which IANA supports. NEW: This practice uses IANA as a well-known, central trusted authority to provide the property of allowing users to get RDAP data from an authoritative source, reducing the risk of sending queries to non-authoritative sources and divulging query information to unintended parties. Additional privacy protection can be gained by using TLS [RFC5246] to provide data confidentiality when retrieving registry information from IANA. Better? I hesitate to say "The transport used to access the IANA registries SHOULD (or MUST) be over TLS" because that's not something the RDAP client controls - it's controlled by IANA's web server (which, in fact, is currently redirecting http connections to https). Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
