On 17 Feb 2012, at 18:50, Dave Botsch wrote: > Just started reading this over. > > First thing that jumped out of me, in section 5. "Token Format" > > grammar: "specific to an particular application" ... an should be a\
I'll fix this. > > the statement: the client, which just transmits it from server > to server > > is kind of funky in its wording. I'm guessing this means the client > receives the token from one server and transmits said token to another. That's exactly what it means - having received a token from the key negotiation service, the client just passes that token, untouched, to the application server. > In section 6, " Within a given > application protocol, a client must be able to locate the key > negotiation service" > makes it sound like the location of the key negotiation service must be > part of each application protocol (like http). Yes. In a non-AFS application protocol, you would deploy a key negotiation service on each application server. The negotiation service is, in this model, just part of the standard RX stack. > And "The simplest deployment has the servicce running on every > server"... are we referring to every AFS DB server? Or every AFS server, > period. Or every application server, too? We're not referring to AFS at all. This document describes the behaviour of rxgk to secure any arbitrary RX service. Because AFS runs in the kernel, and because AFS presents multiple servers to the user as a single "cloud" AFS is special. The way that rxgk works with AFS-3 is described in a companion document to this one - http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-01 Cheers, Simon _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
