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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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 [hidden email] 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Matt Rogers
On Tue, Apr 11, 2017 at 10:39 PM, Benjamin Kaduk <[hidden email]> 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 [hidden email] 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten