Re: [kitten] Updating IANA krb5 GSSAPI token type registry

[Jeffrey Hutzelman <[e-mail]>]

On Wed, 2014-03-05 at 09:23 -0500, Sam Hartman wrote:
> >>>>> "Benjamin" == Benjamin Kaduk <[e-mail]> writes:
> 
> 
>     Benjamin> To me, this seems like a(nother) bug in RFC 7055, but of
>     Benjamin> course it is not one that can be reasonably fixed.  I
>     Benjamin> guess that the easiest way forward is to publish a quick
>     Benjamin> document that reserves 0405 and 0501 noting that they were
>     Benjamin> in use before the registry was established.
> 
> I do not support reserving the iakerb value in another document.
> The right solution there is to finish iakerb and get it published.

Agreed.  For better or worse, our process generally allocates values on
publication, not when a spec first appears that needs one.  The right
way to avoid conflicts here is for the iakerb document to say "TBA"
until a value is assigned by IANA, and to mention this in its IANA
considerations section.


> my preference is that the CFX context deletion token not be registered.
> I don't see any protocol issues that are likely to result if that code
> point were re-used.
> If the community disagrees, writing a document is the right way forward.

I think that depends on how mechanisms might get stacked and whether
there is deployed code that emits or reacts to that code point.  In
general, tokens used only during context establishment almost don't need
to be in a common namespace at all, except that it makes it less
complicated to update things when one mech builds on the context
establishment of another.  However, tokens which can appear after
context establishment require a little more care (but are also less
likely to appear or change outside of 4121 or its successors).

In this particular case, I don't feel like I'm in a position to develop
an opinion on whether the code points needs to be reserved, because I
don't know what the existing implementation does with it.


Here, we're talking about a code point used in a document which was in
progress and then abandoned or superseded before the registry was
created; thus, it never appeared in any published protocol
specification.  If we're concerned that use of such a code point might
cause interop problems, then having marked it as reserved in the initial
registry would have been a fine thing to do, and there is ample
precedent for that.  If it didn't, and we consider that an oversight,
then it seems to me that publication of a new IETF-reviewed RFC is a
rather heavyweight process to correct the oversight.


-- Jeff