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

[Warren Kumari <[e-mail]>]

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...

W

> Scott



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf