Re: [kitten] New URI Discovery Draft

[Matt Rogers <[e-mail]>]

On Thu, 2016-09-29 at 23:53 -0400, Benjamin Kaduk wrote:

Thanks for the review!

> 
> 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"?
> 

With this re-wording would it be more appropriate to specify in the
IANA definition for 'm' and not under 4.2?

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

Ack.

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

Not a bad suggestion for the overall flow of the document.

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

Yes, that's left over from a previous revision, so I'll correct that.

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

Ok, I'll work on revising this.

> 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]".
> 
I'll update this reference. Also, after some further discussion about
the case-sensitivity and flag criticality issue, I think ultimately the
right thing to do for this version of the draft is to just specify that
the URI fields are case-sensitive and unknown flags must be ignored. A
registered transport can then maintain any case-sensitive elements
(such as the path extension for KKDCP) while the scheme, flags, and
transport names will be registered with their literal values so there
should not be any ambiguity on the case for those fields. 

If later on a critical flag needs to be added, then this would leave it
open to being a capital version of an existing flag or just a different
character altogether.

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

Good point. 

Thanks again,
Matt