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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 11 Apr 2017 21:39:20 -0500

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.

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

Listing [email-masked] 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.

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.

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

-Ben

---

From: Matt Rogers <[email-masked]>
Date: Thu, 13 Apr 2017 15:29:42 -0400

> schemes like "hotp" without any explanation of how they would work.
Agreed, I am removing the text related to admin services.

> defined (or avoiding it altogether).
The updated text for the master flag description should help clarify
(see below).

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

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

> established abbreviation for that specifciation (i.e., with two

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

Matt