[AFS3-std] New version of rxgk draft

[Russ Allbery]

Simon Wilkinson <simon@sxw.org.uk> writes:
> On 2 Dec 2011, at 00:32, Simon Wilkinson wrote:

>> I've just pushed a new version of the rxgk specification as an internet
>> draft:  http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-01

> Does anyone have any comments they want to make about this draft before
> I ask the chairs to move to Last Call?

> Please comment, even if its just to say that you've read the draft and
> are happy with its contents.

The enum RXGK_Level doesn't include the value for Bind, even though one
has been assigned.  Is that intentional?

Section 5:

   The token must permit the receiving server to identify the
   corresponding user and session key for the incoming connection -
   whether that be by encrypting the information within the token, or
   making the token a large random identifier which keys a lookup hash
   table on the server.

I think that should be "by decrypting the information," correct?

There's no way to convey the minor GSS-API status back to the client?
With Kerberos GSS-API negotiations, that often contains very useful
information; the major status is usually basically useless.

expiration in the RXGK_ClientInfo struct doesn't use the time format
defined elsewhere as the rxgk time format?  It says that it's seconds
since epoch, but the time format defined earlier is in much smaller
increments.

In 8.3, what's the rx epoch?  Is that an rx concept that we're just using
under the assumption that readers are already familiar with rx?

In 8.5, start_time here is also specified as the number of seconds since
epoch, which is not the rxgk timestamp format defined earlier.

8.6 talks about a version number of the rxgk challenge, but the challenge
specified in 8.4 doesn't include a version field.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>