On Fri, 20 Apr 2012 12:57:00 -0400 Tom Keiser <[email protected]> wrote:
> * (lifetime, bytelife): The statement that these fields are advisory > should likely be reworded into 2119 language. > Given the similar semantics, perhaps a separate > opening paragraph (akin to the discussion of > enctype lists) should describe the that the > "server MAY honor these lifetime requests". > > Additionally, there was some disagreement as > to whether a fully-advisory lifetime/bytelife > was acceptable. Tom Keiser proposed the following > text (with Andrew Deason dissenting): > > "The server MAY choose to honor this request, but MUST > provide a token at least as prohibitive as that > requested by the client." Looking at this again, I think you're right. The 'lifetime' field in the ClientInfo struct says the server must choose something at least as restrictive. I was just looking at the "This lifetime is advisory" sentence which made me think otherwise. I'm not entirely clear on why this is a MUST, though. If either side can rekey when it wants, couldn't the client specify a stricter lifetime, and the server just completely ignores it? You still effectively get that lifetime if the client rekeys appropriately. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
