Re-revised to accomodate these changes, and submitted as -02. https://datatracker.ietf.org/doc/draft-brashear-afs3-pts-extended-names/
On Wed, May 12, 2010 at 3:44 PM, Jeffrey Hutzelman <[email protected]> wrote: > --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 > -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
