Re: [kitten] New URI Discovery Draft

[Benjamin Kaduk <[e-mail]>]

On Fri, 23 Sep 2016, Nathaniel McCallum wrote:

> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc
> overy/
>
> I've submitted a new version of the draft. This version matches the
> code that is now merged into MIT Kerberos.

A few comments (with no particular hat):

Section 4.2.1, "master server" is only implicitly defined; would it be
reasonable to say that such are "expected to be an authoritative source
for KDC database information, not subject to propagation delay"?

It's probably worth a forward reference to the IANA considerations
somewhere in Section 4.2 to note how new flags can be allocated.  Likewise
for the transport types in 4.3 (as well as a list of the types specified
by this document!).

I'd be slightly tempted to reorder things so section 4 comes after
sections 5, 6, and 7 (so that the queries come first and the field
contents later), but that's really a stylistic question and subject to
authorial discretion.

Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI formats
specified in this document", but doesn't this document only contain one
(required) URI format?

Section 7 should probably note that the kadmin protocol is not
standardized and consumers must be aware of the server implementation.
(If we're really excited, we could even include a field to indicate what
the server implementation is, but that would run the risk of introducing
IETF politics at IETF LC or IESG review.)

I don't believe that the kitten list can be a designated expert (and it's
unclear what exactly the document is saying will be done for expert
review).  IIRC, the necessary things in this part are to give the IESG
guidance for selecting Designated Expert(s) (e.g., well-known kerberos
implementors, past or current krb-wg/kitten chairs, etc.), as well as
instructions for what review/criteria the expert should apply when
considering registration requests.  Requiring the expert to call for open
discussion on the kitten list can be part of the instructions to the
expert, but probably ought not be the entirety of those instructions.
Also, it's my understanding that IANA likes things to be written in the
form "IANA has done $X", though for drafts, people tend to write "IANA
[will do|has done]" with literal brackets and pipe.

We already covered the non-case-sensitivity of the flags, but as a nit,
the reference field should be to a document that describes the details of
the flag.  I don't see how the reference for the 'm' flag would not be
"[this document]".

The examples would be more useful if accompanied by prose description of
what they mean.

-Ben