Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

[Benjamin Kaduk <[e-mail]>]

On Mon, Apr 03, 2017 at 12:32:55PM -0400, Greg Hudson wrote:
> On 03/30/2017 02:51 PM, Matt Rogers wrote:
> >> * RFC 7553 is informational and this document is standards track, which
> >>   is a down reference (see RFC 3967).  Also, RFC 7553 contains ambiguous
> >>   guidance about URI records labels which some readers have interpreted
> >>   as being incompatible with our use of labels.  I think at one point we
> >>   received advice to reference the IANA registration of the URI record
> >>   type instead of RFC; unfortunately I do not know the mechanics of that
> >>   kind of reference.
> 
> > The IANA registration entry refers to RFC 7553:
> > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
> > Perhaps it should just be an informative reference instead.
> 
> There is also a "completed template" in the IANA assignment:
> 
> https://www.iana.org/assignments/dns-parameters/URI/uri-completed-template
> 
> I hadn't read this before.  It says (in section E):
> 
>   The URI RR has service information encoded in its ownername.  In
>   order to encode the service for a specific owner name one uses
>   service parameters.  Valid service parameters used are either
>   Enumservice Registrations registered by IANA, or prefixes used
>   for the SRV resource record.

It's not entirely clear just how binding this is on consumers,
though I do think IANA consults this sort of thing sometimes.

> which seems like a slightly more restrictive statement than the one in
> RFC 7553.  We may need some guidance from the chairs or ADs on the

Given how similar it is to the text in the RFC, I think we are
forced to conclude that the RFC takes precedence, possibly due to
last-minute changes.  (That is, that someone got sloppy at some
point.  But the RFC text is what has IETF consensus, and is thus
preferred.)  The relevant text was added in draft-faltstrom-uri-11,
FWIW.

We can call this issue out in the shepherd writeup for IESG
attention, too.  Making a final call is "above our pay grade" :)

> mechanics of moving forward here.  Simply making the reference
> informative doesn't seem sufficient, as the URI RR type is fundamental
> to this standard.
> 
> (To be clear, I think what we're doing ought to be fine, and that it's
> generally pointless to include a transport label in a URI record owner
> name like one would in a SRV owner name.  The question is one of
> conformance with the pre-existing standard, not practicality.)

It is correct to leave the reference as normative; the downref can
be called out during IETF last call (though, IIRC, some recent-ish
changes in policy do not mandate it quite as strongly as it used to
be).

> >> * Similarly, MS-KKDCP is in the normative references section, and is not
> >>   a standards-track IETF document.  It is only used as the reference in
> >>   the initial contents of the transport registry, so perhaps it can just
> >>   be an informative reference.
> >>
> > I'll make this an informative reference.
> 
> The MS-KKDCP reference is obvious controlling when using the kkdcp
> transport.  Since this is just an initial transport registration, it may
> be okay to use an informative reference.

I believe an informative reference is fine for this document, as
that spec is not needed in order to use the discovery protocol
itself.  (It's needed to use the results of discovery, but that's
out of scope.)

> >> * The wording here seems too general.  I think we want to specifically
> >>   say that URI records should be preferred over SRV records.
> 
> > How about: "Clients that support service discovery through both URI
> > and SRV records SHOULD perform the URI discovery first. If no URI
> > record is found, the client MAY then attempt SRV discovery."
> 
> Sure.
> 
> There is an argument for a MUST here.  DNS administrators will commonly
> want to set up both URI and SRV records for a realm, and the behavior of
> trying URI first may be important (e.g. if the URI record includes a
> kkdcp entry).

Note that the MUST only applies for implementations that claim to
comply with <RFC-to-be>, so it is not as strong a requirement as it
might seem at first.

> >> * The reference here is "TBD".  Is there a plan?  Is the reference
> >>   supposed to be to this RFC once a number is assigned?
> >>
> > 
> > It should be changed to the assigned number, yes. It was suggested
> > that instead of TBD we use [This Document], which I think is the
> > convention for this kind of reference.
> 
> That seems okay.  There might also need to be an RFC editor guidance
> section pointing out the need for a substitution there.  For instance,
> in https://tools.ietf.org/html/draft-ietf-krb-wg-crypto-07 see the
> "Notes to RFC Editor" section at the end.

Yes, "[this document]" is an accepted form.  I don't expect a
specific RFC Editor note is needed for this sort of usage.

-Ben