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

[Derrick Brashear]

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 <jhutz@cmu.edu> wrote:
> --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. =A0They 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 P=
TS
> 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 mapp=
ing
> 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. =A0I 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. =A0This operation does not return a b=
it
> 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. =A0Also:
>
>> 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. =A0I suggest s/required/needed/g in the fi=
rst
> 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 canonicali=
zed
> 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 familia=
r
> with GSS-API may not realize that import+export may not do the right thin=
g,
> while import+canonicalize+export always will.
>
>
> -- Jeff
>



--=20
Derrick