[regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rdap-object-tag-04: (with COMMENT)

["Hollenbeck, Scott" <[e-mail]>]

(My email client sometimes does unexpected things with message encryption. Sending again with plaintext assured...)

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Friday, July 27, 2018 1:52 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Gould, James
> <[e-mail]>; [e-mail]; Gould, James
> <[e-mail]>; [e-mail]
> 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