AFS3 Standardization Group
Issue Tracking: draft-wilkinson-afs3-rxgk-afs
Current work-in-progress draft.
- Changes (commits)
Current open issues for draft-wilkison-afs3-rxgk-afs.
||Fixed. See commit bc9fb357|
||CM renew token text added. Security considerations not updated.|
|4||We should reference the VL spec (where we mention VL_RegisterAddrs).||There is no spec that covers VL_RegisterAddrs. (VL and VVL documents pre-date the VL_RegisterAddrs RPC.) Resolution is unclear.|
||Fixed. See commit e2b5421a|
|6||We need a better reference for extended callbacks.||Fixed. See commit b7b23186|
|7||I think Simon's reply clarified why the document forces breaking all callbacks on SetCallbackKey, but again there was not further comment.|
|8||I don't think there was consensus about the generation and expiry of extended callbacks and which channels need be rxgk-secured, and whether/how a client could upgrade and downgrade to and from them. A proposed text was "Only RPCs issued over an rxgk protected connection should cause rxgk callbacks to be received"; it was also proposed that rxgk clients might change UUID (so as to appear as a differnent client entirely and avoid the downgrading problem). I need to familiarize myself more with the extended callbacks document before I can add much here.||Discussed extensively on list. Ben proposed covering callback keying in a subsequent I-D.|
||Fixed. See commit cfad0561|
||Fixed. See commit bd42b12b|
|11||Acceptor identities for dbservers vs. fileserver/volservers||Consensus reached in discussions. Requires a small change to the rxgk and rkgk-afs documents.|