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

[Benjamin Kaduk <[e-mail]>]

On Thu, 6 Mar 2014, Sam Hartman wrote:

> So, my understanding of the situation is that we have an implementation
> that has chosen to ship code prior to completion of a spec in two
> instances.
>
> 1) CFX.  In that instance, the spec evolved differently than anticipated
> and no longer standardizes the behavior MIT implements.

Greg pointed out that we have removed the code that generates the CFX 
deletion token from our development branch, though of course older 
releases still generate such tokens.

> 2) Iakerb.  There, we still expect that the spec will use the same value
> as MIT.
>
> In the CFX case, I don't actually see any significant harm that would
> result if we were to  assign the codepoint MIT uses to something else.
> It would be bad if we assigned that codepoint to some token other than a
> context deletion token intended to be passed into
> gss_process_context_token.
> However, there are no such tokens and there are no extensions under
> discussion that would create such tokens.

There actually is provision in RFC 2743 for tokens to be passed to 
gss_process_context_token which are not deletion tokens. (Last two 
paragraphs of 1.2.1.2.)  I do not remember any provisions in RFC 4121 to 
account for this case, though, so I guess it is under-specified.

> In general, when you ship a draft, you take on responsibility for
> dealing if the IETF process doesn't go the way you anticipate.  Doing
> that is part of doing business; it's definitely the case that there are
> times when you end up shipping based on drafts.

I don't disagree with anything you say there.

However, I think we should consider what the purpose of the central 
registry is: to document what values are in use and avoid conflicts. 
Given that there were already values in broad use when the registry was 
created, I think it is appropriate to document those values in the 
registry, even if it is just as "reserved to avoid conflicts", as Martin 
notes in the prior art.  There certainly does not seem to be a shortage 
of values in the token type space.

> IANA expert decisions can be appealed; you'd first file an appeal with
> me, and then I'm not sure whether it goes to the IESG as a whole or the
> security AD.

Is there a magic phrase that invokes such an appeal?  (Or does it go 
through IANA?)  I am unfamiliar with the process, and not necessarily 
indicating intent to do so.

-Ben