--On Tuesday, April 20, 2010 05:27:59 PM -0400 Derrick Brashear
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
