[AFS3-std] Re: Last Call: afs3-rxgk-04

[Andrew Deason]

On Tue, 16 Apr 2013 15:09:33 -0400
Michael Meffie <mmeffie@sinenomine.net> wrote:

> Title:      rxgk: GSSAPI based security class for RX
> Filename:   draft-wilkinson-afs3-rxgk-04
> URL:        http://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk/

I have just a couple of comments that haven't been mentioned elsewhere
in the thread.  But first of all, I agree with Simon that the only
significant future changes I can see are the opaque limits and possibly
the GSSNegotiate loop language. The latter I don't think needs to be too
_perfect_, since it seems like there is plenty of agreement on what to
actually do; the only problem is the language maybe being confusing. But
anyway, everything below is unrelated to those issues, and so I consider
minor.

>> 4.  Security Levels
[...]
>> This corresponds to the traditional 'clear' security level.

I feel like I've said this before, but I can't find the reference.
Mentioning "traditional" security levels doesn't make a lot of sense to
me in this context; I wish these said something about rxkad, to provide
an explicit reference for where to look to see what these are talking
about.

>> 6.  Key Negotiation
[...]
>> This lifetime is advisory.

I also feel like I've whined about this before, but I can't find where.
This sentence by itself doesn't really seem to say anything. The
definitions of "lifetime" and "bytelife" on page 7 I feel should just
point to the definitions of "lifetime" and "bytelife" on 10 for details,
and have them in one place.

Of course, that's kind of difficult when section 6 is 6 pages long
without any subsections, but I also think that section 6 could use some
subsections to make it more readable. It seems like this could at least
be broken up into: GSSNegotiate argument/field definitions, the core
GSSNegotiate loop algorithm, the RXGK_ClientInfo field definitions, and
what the client does after the GSSNegotiate loop finishes. But if you're
changing the GSSNegotiate loop text in general, maybe that section would
look different.

-- 
Andrew Deason
adeason@sinenomine.net