Subject: [kitten] GFD.24 and draft-ietf-kitten-gssapi-naming-exts-09

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Apr 2011 17:58:00 +0200

All,

One way to reduce the problem with the normative reference to an
external experimental document is to clarify which parts of the external
document is required by the naming extensions document.  I propose to
add text like this (to naming-exts) to clarify the relationship:

      The normative reference to GFD.24 is for the buffer set functions
      defined in section 2.5 and the associated buffer set C types
      defined in section 6 (namely gss_buffer_set_desc,
      gss_buffer_set_t, gss_create_empty_buffer_set,
      gss_add_buffer_set_member, gss_release_buffer_set).  Nothing else
      from GFD.24 is required to implement this document.  In
      particular, that document specify changes in behaviour existing
      GSS-API functions in section 3: implementing those changes are not
      required to implement this document.

The GFD.24 section 3 changes to existing GSS-API functions are
problematic for me.  I don't want to implement that part and I see no
reason to do so in order to support naming extensions.  Modifications to
IETF standardized functions should go through the IETF in my opinion.
Without something like my text above, it is unclear whether naming
extensions requires that change or not.

When reviewing GFD.24 I also noticed that the the generic GSS-API
functions are poorly named: they are using C-style names rather than
GSS-API-cased names used in RFC 2743.  For example, GFD.24's function
"gss_create_empty_buffer_set" should be called
"GSS_Create_empty_buffer_set" for consistency.  Also there are no
documentation on how the C functions should behave, compare RFC 2744 for
how proper C function definitions for GSS-API bindings should look like.

I can probably guess what the intended meaning of GFD.24 is, but I think
the document is underspecified and does not permit interoperable
implementations without guesswork and/or access to external information.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Apr 2011 07:52:34 -0400

I strongly support the adoption of Simon's text or similar text in
naming extensions.