On Fri, Jun 18, 2010 at 1:37 PM, Simon Wilkinson <[email protected]> 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 >> hackathon >> 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 ones of > substance, and ones of style. > > Substance: > >> 10.4. Authentication Name Type Rewriting > > I'm still uneasy about requiring the rewriting of GSSAPI obtained Kerberos > names to use the Kerberos name type. If we believe that GSSAPI is the future, > then I would prefer that we use the GSSAPI exported name for > all GSSAPI mechanisms, rather than special casing Kerberos. > > Style: > >> Some deployments provide several mechanisms to obtain AFS >> authentication; While mappings between Kerberos 4 and Kerberos 5 >> [RFC1510] authentication names allow use of most Kerberos 5 >> deployments with AFS, supporting more than a single realm requires >> matching usernames in all realms; Additionally, support for other >> systems is not provided at all. > > I'm not sure about the readability of this paragraph - in particular the use > of the semicolon. > >> 3. Background information on operation of AFS > > Whilst this background information is of use to a reader inexperienced with > 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
