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

[Matt Rogers <[e-mail]>]

On Tue, Apr 11, 2017 at 10:39 PM, Benjamin Kaduk <[e-mail]> wrote:
> In addition to the other thread, I have a few comments from my
> read-through, in addition to the issues already raised by others.
>
> I'm inclined to agree with Greg that specifying a discovery scheme
> for a protocol that is not well-specified/interoperable is probably
> not worth doing; there was some IESG pushback recently as OAuth was
> trying to get an "amr" registry created (similar to our
> authentication indicator, in a rough sense), which listed some
> schemes like "hotp" without any explanation of how they would work.
>
Agreed, I am removing the text related to admin services.

> We very informally bring in the concept of a "master server" in
> section 4.2.1; this is not a term that commonly appears in kerberos
> RFCs, so it may be worth indicating that it is a term being newly
> defined (or avoiding it altogether).
>
The updated text for the master flag description should help clarify
(see below).

> Listing [e-mail] as a Designated Expert is unwise; the
> expert(s) should be named individuals selected by the IESG.  The
> document creating the registry ought to give the IESG some guidance
> as to who is qualified to be such an expert, though.  The
> instructions to the expert can certainly include a three-week period
> of public review on the kitten list, though.
>

Looking at some existing IANA Considerations examples, I might suggest
the following:

8.  IANA Considerations

   This document establishes two registries [to be] managed by IANA, in
   accordance with [RFC5226].

   For registration requests the responsible IESG area director should
   appoint a Designated Expert.  The intention is that any allocation
   will be accompanied by a published RFC.  The Designated Expert will
   post a request to the KITTEN WG mailing list (or a successor
   designated by the Area Director) for comment and review, including an
   Internet-Draft.  Before a period of three weeks has passed, the
   Designated Expert will either approve or deny the registration
   request, publish a notice of the decision to the KITTEN WG mailing
   list or its successor, and inform IANA of its decision.  A denial
   notice must be justified by an explanation and, in the cases where it
   is possible, concrete suggestions on how the request can be modified
   so as to become acceptable.

> It's sometimes odd to have the IANA considerations be the first
> place that certain concepts come up in the document.  It may be
> clearer to have a table for them in the main body of the text, and
> the IANA considerations refer back to that table as being the
> initial registry contents.
>

I'm expanding on the master flag separately from the registry contents
and try to clarify its intent;

6.2.  Flags
...
6.2.1.  Master Flag

   The "m" flag indicates that the server is a "master".  The client
   SHOULD consider this server as one that might possess more up-to-date
   long-term key material, and use it as a fallback for errors that
   might result from out-of-date keys.
....
8.1.2.  Initial Registry Contents

   o Value: m
   o Description: Master flag
   o Reference: [This Document]

> Something of a nit, but I thought that "MS-KKDCPP" was the
> established abbreviation for that specifciation (i.e., with two
> 'P's).
>

The Microsoft documentation and others only refer to it as "MS-KKDCP".
Thanks again for your comments,

Matt