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

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

> -----Original Message-----
> From: Warren Kumari <[e-mail]>
> Sent: Monday, July 30, 2018 12:37 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Gould, James
> <[e-mail]>; [e-mail]; Gould, James
> <[e-mail]>; [e-mail]; [e-mail]
> 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