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

[Sam Hartman <[e-mail]>]

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.

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.

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'm aware of the iakerb issue, and if iakerb moves forward at a
reasonable speed, I'll certainly keep its assignment preference in mind
when reviewing other allocations.

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.