[AFS3-std] Revised PTS authentication name mapping draft, call for review

[Jeffrey Hutzelman]

--On Tuesday, April 20, 2010 05:27:59 PM -0400 Derrick Brashear 
<shadow@gmail.com> wrote:

> https://datatracker.ietf.org/doc/draft-brashear-afs3-pts-extended-names/



Section 3:

> Because of this, PTS authentication names take the
> format of a Kerberos 4 authentication name.

Well, not really.  They take a form similar to that conventionally used for 
writing Kerberos 4 principal names as strings, with the realm (cell) name 
omitted when it is the same as the local realm (i.e. almost always).

This is interesting because it suggests obvious algorithmic mappings to PTS 
names from krb4 and many krb5 principal names, but we don't want to give 
the impression that we're mapping everything to krb4, when in fact we're 
mapping everything to strings.


Section 4 is redundant and should be removed entirely.


Section 8.1:

> A client with knowledge of the GSSAPI mechanism MAY import
> the data portion and use it to generate a display name.

but there's no mention of a GSS-API mechanism here, and in fact such 
mechanisms comprise only one of the possible types.  I suggest instead:

] A client with knowledge of the particular name type used MAY
] use the data portion to derive a suitable display name, if none
] is provided.


Section 8.3:

I suggest removing any mention of "bit streams", which simply creates 
confusion about bit and byte order.  This operation does not return a bit 
stream; it returns a vector of 32-bit integers, of which only the first 
currently has defined structure and meaning.


Section 8.4.1:

> For each authname provided in alist, an AFS ID will be provided in
> list at the corresponding position.

s/list/ilist/

Section 8.4.2:

Same change as for 8.4.1.  Also:

> Where an authentication name cannot be looked up

How about "where neither an explicit nor implicit mapping is available..."

Finally, did I mention I hate this RPC name?
Not that I have a better one in mind...


Section 8.4.4:

s/the current the current/the current/


Section 9:

This section is non-normative.  I suggest s/required/needed/g in the first 
paragraph, to avoid any confusion with RFC2119 requirements language.


Section 11.3:

Depending on where it came from, a GSS-API name may need to be 
canonicalized by use of GSS_Canonicalize_name() before it can be exported. 
I'm not sure whether it's worth saying anything about this here, but folks 
not familiar with GSS-API may not realize that import+export may not do the 
right thing, while import+canonicalize+export always will.


-- Jeff