(My email client sometimes does unexpected things with message encryption. Sending again with plaintext assured...)
> -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Friday, July 27, 2018 1:52 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 > Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext- > rdap-object-tag-04: (with COMMENT) > > Benjamin Kaduk 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: > ---------------------------------------------------------------------- > > I was a little surprised to see that this document targets BCP status, not > Proposed Standard. Was there much discussion of this question in the WG? > > Section 2 > > Service provider tags are concatenated to the end of RDAP query > object identifiers to unambiguously identify the authoritative server > > It seems like it is the combination of concatenation of the service > provider tag, and the use of the rdap_objectTag_level_0 rdapConformance > attribute that provides the unambiguous property; I would like to see this > caveat made more clear here. Thanks for the review, Benjamin. The rdapConformance attribute doesn't do anything to identify the authoritative server. It's a clue to the client that the server has implemented this particular practice. > Also, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/, please > consider using IPv6 addresses in the examples. The example copied into this document comes directly from Section 5.3 of RFC 7483. I'd prefer to keep it as-is to maintain consistency with that cited reference. > Section 5.1 > > Are all provided URLs supposed to be functionally different? If not, how > do we tell which ones do what? Practice thus far in the RDAP bootstrap registries has been to register http and https URLs. The scheme of the URL identifies the functional difference. > Section 7 > > Perhaps note that it is using IANA as a well-known central trusted > authority in order to provide the property of allowing users to get RDAP > data from an authoritative source? Sure, OK. > [...] 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. > > Well, I don't know that "the same as" is quite right, especially given the > following sentence. The composed chain of "talk to iana, talk to referred > RDAP server" depends both on the security of the connection to the RDAP > server and that of the connection to IANA; it seems prudent to note that > if TLS is used for the RDAP connection, TLS should also be used when > talking to IANA, or even that TLS should always be used when talking to > IANA. OK, how about this text? 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. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
