Subject: Comments on draft-ietf-kitten-gssapi-extensions-iana-02.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 10 Mar 2008 17:27:02 +0000

Hi Nico,
I've scanned through draft-ietf-kitten-gssapi-extensions-iana-02.txt and
have some quick comments:

> 7.  Registration Form(s)

[...]

>    | Registration   | 'Protocol Action', 'Expert | Describes the rules |
>    | Rules          | Review',                   | for allocation of   |
>    |                | 'First-Come-First-Served', | items that fall in  |
>    |                | 'Closed-For-Registrations' | this sub-namespace, |
>    |                |                            | if this entry is    |
>    |                |                            | for a sub-namespace |
>    |                |                            | (OPTIONAL).         |

I think different values for this field come from RFC 2434. It should be 
mentioned as a reference here.

>    | Status         | 'Standards-Track',         | Status of the       |
>    |                | 'Informational',           | registration.       |
>    |                | 'Experimental',            |                     |
>    |                | 'Obsolete', 'Other'        |                     |

I think you need to be more specific about what the status is. Is it 
status of the document defining the namespace registration? Or of the 
registration itself?

Section 7 and 8 need more text, as described by your editorial comments.
I think this is a prerequisite before starting WGLC on the document.

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Mar 2008 19:00:25 -0500

> mentioned as a reference here.

Indeed.  I'll remove most of those values, add text referencing RFC2434
and give a few examples.

> status of the document defining the namespace registration? Or of the 

The description already answers that :)

> I think this is a prerequisite before starting WGLC on the document.

Indeed.  I think we agreed at Philadelphia that the initial registry
content can be provided separately.  That makes a lot of sense, since
during the IANA review part of the RFC publication process that contents
might be taken out of the document altogether (once it's been
incorporated into the registry, and with authoritative definitions in
RFCs like 2743, what's the point of having a tens of pages repeating the
same material in this one?).

So I think I'll update section 8 to state that the initial content will
be provided separately.  We'll review that content on the list though,
of course.

I'll iron out section 7 in the next few days.

It'd be great if we could WGLC, then hold the document until we've
reviewed the initial registry content submissions, then send the I-D
to the IESG.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Mar 2008 15:21:14 -0500

I've just submitted -03, with much new IANA guidelines text.

I'd appreciate a review of those guidelines, particularly the guidelines
for expert reviewer selection and the guidelines for expert reviewers.

I've also begun to create initial contents registrations.  I began with
a simple Unix pipeline to extract from RFC2743 and 2744 anything that
appeared to be a symbol name.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Mar 2008 16:47:18 -0500

> appeared to be a symbol name.

First installment:

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_BINDINGS
Constant Value/Range(s): Unspecified
Description: Major status code indicating channel binding mismatch
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_MECH
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the given mechanism is not supported/available
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_MIC
Constant Value/Range(s): Unspecified
Description: Major status code indicating that MIC verification failed
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_NAME
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the given NAME was bad
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_NAMETYPE
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the given name type OID was bad
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_QOP
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the given qop is not supported/available
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_SIG
Constant Value/Range(s): Unspecified
Description: Alias of GSS_S_BAD_SIG
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_BAD_STATUS
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the status code passed to GSS_Display_status() is unknown
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_COMPLETE
Constant Value/Range(s): Unspecified
Description: Major status code indicating that the operation succeeded
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_CONTEXT_EXPIRED
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given CONTEXT HANDLE has expired
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_CONTINUE_NEEDED
Constant Value/Range(s): Unspecified
Description: Major status code indicating the operation has not yet completed, but no error resulted
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_CREDENTIALS_EXPIRED
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given CREDENTIAL HANDLE has expired
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_DEFECTIVE_CREDENTIAL
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given CREDENTIAL HANDLE is defective
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_DEFECTIVE_TOKEN
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given token is defective
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_DUPLICATE_ELEMENT
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given OID is already present in the given set
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_DUPLICATE_TOKEN
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given per-msg token has been replayed
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_FAILURE
Constant Value/Range(s): Unspecified
Description: Major status code indicating failure of the operation
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_GAP_TOKEN
Constant Value/Range(s): Unspecified
Description: Major status code indicating one or more per-msg tokens between this one and its predecessor are missing
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_NAME_NOT_MN
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given NAME is not an MN
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_NO_CONTEXT
Constant Value/Range(s): Unspecified
Description: Major status code indicating no CONTEXT HANDLE was given
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_NO_CRED
Constant Value/Range(s): Unspecified
Description: Major status code indicating no CREDENTIAL HANDLE is available, and not was given
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_OLD_TOKEN
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given per-msg token is too old to be processed
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_UNAUTHORIZED
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given operation is not authorized
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_UNAVAILABLE
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given operation is not available
Reference: RFC2743
Status: Standards-Track

Registration type: Instance
Bindings: Generic
Object Type: Constant
Symbol Name/Prefix: GSS_S_UNSEQ_TOKEN
Constant Value/Range(s): Unspecified
Description: Major status code indicating the given per-msg token was received out of order (later tokens have been processed)
Reference: RFC2743
Status: Standards-Track

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Mar 2008 11:36:09 +0000

>The description already answers that :)  
Well, in this case you need to define what 
'Standards-Track','Informational', 'Experimental', 'Obsolete' and 
'Other' mean.
Including who determines the relevant status. With document status it is 
simple. With registrations that can be submitted in email, or be 
described in anything other than RFC, this is not clear.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 12:10:10 -0400

> described in anything other than RFC, this is not clear.

What is the purpose of assigning such a status to a registration, separate 
from that of the specification for the registered extension?

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Mar 2008 16:15:55 +0000

Jeffrey Hutzelman wrote:

>>>>>  |                | 'Experimental',            
>>>>> |                     |
> What is the purpose of assigning such a status to a registration, 
> separate from that of the specification for the registered extension?

A registration can be specified in a non IETF document. If we don't want 
to allow for that, then there is no practical difference.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 11:18:11 -0500

> from that of the specification for the registered extension?

I was thinking that a Standards-Track RFC could register names that are
experimental too, say.

But, yeah, the easiest thing to do is to say that if there's an RFC,
then the status of the entry is that of the RFC, and if there isn't then
the status is as the expert reviewer thinks it should be: private use
vs. <?>.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 12:25:43 -0400

--On Tuesday, March 25, 2008 11:18:11 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> >>>> | Status         | 'Standards-Track',         | Status of the
>> >>>> | |
>> >>>> |                | 'Informational',           | registration.
>> >>>> |                | | 'Experimental',            |
>> >>>> |                | | 'Obsolete', 'Other'        |
>> >>>> |                | |
>> >>>>
>> >>>>
>> > Including who determines the relevant status. With document status it
>> > is simple. With registrations that can be submitted in email, or be

You are both missing the point.
Why does the entry need to have a status at all?
What purpose does it serve?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 11:27:36 -0500

On Tue, Mar 25, 2008 at 04:15:55PM +0000, Alexey Melnikov wrote:
> A registration can be specified in a non IETF document.

Exactly.

>                                                         If we don't want 

In this case a registry offers minimal value if registration requires
RFC publication.

We're talking about an API more than about a protocol.  Implementors
already feel free to add extensions with symbol names of their choosing,
and this does not inconvenience the other implementors much *unless*
there is a naming conflict.  I don't think we'll be able to get all
implementors to publish Informational or Experimental RFCs, much less
Standards-Track RFCs before they add new functions/whatever.  Therefore
a registry that requires RFC publication will likely go unused, leaving
us with the same problem that we have today.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 11:30:21 -0500

> What purpose does it serve?

You're right, it serves little purpose.

Rather, we need to document how the entry came about (from the
publication of an RFC, individual registration).

A way to mark an entry as obsoleted might be nice though.  Someone adds
GSS_Foo(), then later realizes that it should have some extra argument
and they register GSS_Foobar() -- it'd be nice if they could mark
GSS_Foo() as updated/obsoleted bu GSS_Foobar().
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Mar 2008 16:30:07 +0000

Nicolas Williams wrote:

>Standards-Track RFCs before they add new functions/whatever.
>
This is my fear as well.

>Therefore
Agreed.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Mar 2008 16:32:40 +0000

>publication of an RFC, individual registration).
Sure.

>GSS_Foo() as updated/obsoleted bu GSS_Foobar().
Indeed, "obsolete" is very useful. Adding an entry as experimental ("I 
don't know if this is going to work, I might have to change the API 
later on") might be useful as well.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 11:41:24 -0500

> later on") might be useful as well.

Also, during expert review of a registration (assuming we *want* expert
review) it might be useful to have a "Proposed" status.

So I think I'll make it:

	Reference(s): none | <reference> [, <reference> ...]
	Status:	Proposed | Registered | Obsoleted
	Obsoleting reference(s): <reference> [, <reference> ...]

As for expert review, I give some guidelines.  Please review.  Reviews
should be simple and quick.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 13:25:31 -0400

> publication of an RFC, individual registration).

Entries generally include a reference for this purpose.  When the entry is 
created by publication of an RFC, the reference is to an RFC.  When it is 
created in response to an individual registration request, the reference is 
to the person who made the registration.

> GSS_Foo() as updated/obsoleted bu GSS_Foobar().

Sure.  So you provide an obsolete flag, and maybe even an "obsoleted by" 
pointer, which can be updated by the owner of an entry.  For entries 
defined by an IETF RFC (not an RFC-Editor submission), the "owner" is 
deemed to be the IESG.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 13:27:10 -0400

--On Tuesday, March 25, 2008 04:32:40 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> don't know if this is going to work, I might have to change the API later
> on") might be useful as well.

Nope; it doesn't matter.  The purpose of the registry is to register use of 
the name, not to serve as a development tracking database.  I suppose one 
might define a whole taxonomy of interface stability designations and what 
they mean, but really, an IANA registry is not the place for that.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 14:06:12 -0400

> review) it might be useful to have a "Proposed" status.

This is not necessary.  If we use expert review, the registration will not 
exist until that review is complete.  IANA is responsible for tracking 
registration requests in progress and avoiding collisions; we do not need 
to provide fields for this purpose.

You're trying too hard.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 13:38:20 -0500

> they mean, but really, an IANA registry is not the place for that.

Two minutes earlier you indicated that obsolete is fine.  I assume
that's still your view, but that you're arguing that for any other
interface stability attribute we should not record it in the
registration.  I agree.  Besides, the description field is free-form :)
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Mar 2008 15:25:37 -0400

--On Tuesday, March 25, 2008 01:38:20 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> Nope; it doesn't matter.  The purpose of the registry is to register use
>> of  the name, not to serve as a development tracking database.  I
>> suppose one  might define a whole taxonomy of interface stability
>> designations and what  they mean, but really, an IANA registry is not
>> the place for that.
>
> registration.

Pretty much.  Information about the stability or "status" or whatever turns 
the registry from a collection of mostly-static things into a dynamic 
database that is trying to do more than intended.  IANA is a registration 
service, not a database engine.  The primary purpose of a registry is to 
avoid collisions and to let you find out what a name names and where to 
look for more information.  Anything more is extraneous.

I'll accept an obsolete flag with reference, because it lets you provide 
information on where one should look instead of using the obsolete name, 
and there often _is_ no other place for such a pointer.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Mar 2008 19:38:12 +0000

Jeffrey Hutzelman wrote:

> Nope; it doesn't matter.  The purpose of the registry is to register 
> use of the name, not to serve as a development tracking database.

I agree that the primary purpose it to register use of names.

> I suppose one might define a whole taxonomy of interface stability 

Why not? :-)

Ok, I am actually fine with just having the obsolete flag in the registry.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 17:12:53 -0500

Are there GSS-API namespaces for which registration via anything other
than IESG Protocol Action should be disallowed?

E.g., context req/ret flags.  Context flags form a small namespace (as
small as 32 flags for the C-Bindings), for one, but also may have
semantics that impacts mechanism protocols.  Thus we should not allow
registration of context flags.

There are some other small namespaces, but not nearly that small (e.g.,
the namespace of calling, routine and supplementary status codes for the
C-Bindings -- 256, 256 and 65536 possible values, correspondingly).
Next we have qop values -- 2^32 at least.  I suppose we could allow
registration of major status codes, while allowing the expert reviewer
to reject any requests that appear frivolous.

Also, must we specify a procedure for appealing expert review results?

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Mar 2008 17:27:23 -0500

> Also, must we specify a procedure for appealing expert review results?

Er, never mind that question -- rfc2434 answers it.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 26 Mar 2008 10:20:46 -0400

--On Tuesday, March 25, 2008 05:12:53 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> small as 32 flags for the C-Bindings), for one,

The values of context ret/req flags are not specified as part of the C 
bindings, so maintaining a registry for those values would be pointless. 
It is reasonable to maintain a registry for the _names_ of flags, and that 
is not a scarce space.

Granted, the use of a 32-bit bitmask limits the number of flags an 
implementation can actually support, but it can be picky in which flags it 
assigns values for.  For example, if one doesn't support delegation, then 
GSS_C_DELEG_FLAG can simply be zero.  Of course, we won't discuss such 
dirty tricks in a document, but the point is that the namespace is not 
necessarily scarce just because the current C bindings only give 
implementors 32 bits to play with.

> but also may have
> semantics that impacts mechanism protocols.

This doesn't parse.

> Thus we should not allow

Don't try to use existence of a registry or registration policy as a way of 
preventing people from adding extensions you don't like.  It won't work, 
and we'll just end up with a mess.  It's entirely plausible that someone 
will come along and invent a mechanism which provides some new kind of 
feature for which a context flag would be appropriate.

> to reject any requests that appear frivolous.

To at least some extent, calling and routine status codes should correspond 
to conditions defined in the abstract interface.  I'm not sure we want to 
create an opportunity to register numbers in such a space that are not tied 
to corresponding abstract statuses.  Then again, I'm not sure we don't.

The supplementary status is a bitmask, not a 16-bit value, so codes are 
quite scarce.  These also correspond directly to supplementary status 
defined as part of the abstract interface, like GSS_S_CONTINUE_NEEDED.

> Also, must we specify a procedure for appealing expert review results?

No.  You're thinking too hard.

-- Jeff