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

[Tom Keiser]

On Fri, Jun 18, 2010 at 1:37 PM, Simon Wilkinson <simon@sxw.org.uk> wrote:
>
> On 20 Apr 2010, at 22:27, Derrick Brashear wrote:
>
>> As before, I've written up a draft based on the 2004 Stockholm AFSig hac=
kathon
>> discussion of the PTS alternate authentication names proposal, as
>> modified based on further feedback and the 2009 Edinburgh Hackathon.
>> Comments welcome and encouraged.
>
> I've finally had a chance to review this. I've split my comments into one=
s of substance, and ones of style.
>
> Substance:
>
>> 10.4. =A0Authentication Name Type Rewriting
>
> I'm still uneasy about requiring the rewriting of GSSAPI obtained Kerbero=
s names to use the Kerberos name type. If we believe that GSSAPI is the fut=
ure, then I would prefer that we use the GSSAPI exported name for
> all GSSAPI mechanisms, rather than special casing Kerberos.
>
> Style:
>
>> =A0 =A0Some deployments provide several mechanisms to obtain AFS
>> =A0 =A0authentication; While mappings between Kerberos 4 and Kerberos 5
>> =A0 =A0[RFC1510] authentication names allow use of most Kerberos 5
>> =A0 =A0deployments with AFS, supporting more than a single realm require=
s
>> =A0 =A0matching usernames in all realms; Additionally, support for other
>> =A0 =A0systems is not provided at all.
>
> I'm not sure about the readability of this paragraph - in particular the =
use of the semicolon.
>
>> 3. =A0Background information on operation of AFS
>
> Whilst this background information is of use to a reader inexperienced wi=
th AFS, I'm not sure that every draft we produce needs to explain what AFS =
is, and how it works. Given that AFS novices are probably not the intended =
audience, I'm not convinced that this section is required.
>

I've received several off-list comments from IETF reviewers to the
contrary: that if we wish to publish via the individual submissions
mechanism, then our documents should be self-describing to the average
IETF reviewer.  This wouldn't be such a big deal if there were an
AFS-3 standard we could cite as a normative reference.  Until such
time as we can publish a definitive AFS-3 standard, using the CMU ITC
and Transarc FS-00-D16X tech reports as informative references seems
to be our stop-gap.  My counter-position would be to add some
informative references to section 3, and (perhaps?) abridge it a
tad...

Cheers,

-Tom