Simon Wilkinson <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
