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: Tuesday, July 31, 2018 11:30 AM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> Gould, James <[e-mail]>; [e-mail];
> [e-mail]; Tim Chown <[e-mail]>
> Subject: [EXTERNAL] Re: Warren Kumari's No Objection on draft-ietf-regext-
> rdap-object-tag-04: (with COMMENT)
>
> On Tue, Jul 31, 2018 at 7:07 AM Hollenbeck, Scott
> <[e-mail]> wrote:
> >
> > > -----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.
>
> Okey dokey - my main concern is if the WG discussed it and selected
> something; I'm not yet quite so arrogant that I'm sure I know better than
> the WG :-) I think that having an example with multiple hyphens would be
> helpful to avoid issues.
>
> >
> > > 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).
> >
>
> I'd think that a SHOULD is fine - I cannot imagine the IANA disabling
> HTTPS for registries like this, but won't dig in my heels over this...

Warren, Benjamin proposed new text in his last note. I'll use his text if that's OK with you.

Scott