From: Neil Brown (neilb@cse.unsw.edu.au)
Date: 10/13/99-10:22:59 PM Z
From: Neil Brown <neilb@cse.unsw.edu.au> Date: Thu, 14 Oct 1999 13:22:59 +1000 (EST) Message-ID: <14341.19603.124250.12160@notabene.cse.unsw.EDU.AU> Subject: Re: Feedback on draft-ietf-nfsv4-01 - general On Wednesday October 13, mre@eng.sun.com wrote: > Neil, > > I thought that most of the issues you raised around clarity of the specification > were quite valid. On some issues I have specific comments. > > > In section 5.4, the "change" attribute is allowed to be "mtime", > > with unspecified resolution. This doesn't provide a guarantee of "no > > other client has made a change" in the face of multiple changes in one > > second. > > Then the language of the spec should state that mtime is permissable, > provided that file cannot be updated more frequently than resolution of > of mtime. > > > I think that the change attribute should be required to change at least > > whenever the file changes (it may change at other times too, such as > > server restart). > > It we really want to allow "mtime" to be usable, then I would suggest > > that "change" have a special value "0" which means "the file is > > changing. i.e. if "change" reads as '0', then the client must assume > > that the file has changed since the last time the change attribute was > > read. Then the formula: > > > > (mtime == current_time) ? 0 : mtime > > > > would work. > > While, NFS V4 is decidely quite stateful, in terms of GETATTR, it > it remains stateless. How is the server going to know when the > client last read the attribute? Instead, I suggest the specification beef > up the language around the suggestion for using mtime, or > delete the reference to mtime. No statefulness was implied. The meaning of "change == 0" was intended to be: I cannot give you a repliable change value at the moment, because if I did and the file changed in a few milliseconds, then the only "change" number that I would would not be affected by that change, and I know you don't like that. Essentially it is a way out for a server who cannot provide any guarantees about whether the file has changed to not. You're wrist-watch server might always set change to 0, and require the client to never do any caching. I not particularly saying that having this is a good thing, but it is important that "change" comes with guarantees, and this is a way to allow a simple server to provide minimal guarantees. > > Section 12.2.31 SETCLIENTID > > > > The SETCLIENTID4args do not mention the cb_client callback > > information, though the definition in Section 17 does. > > Also the discussion in 8.2.1 doesn't mention it either. > > > > It is not clear what sort of credential should accompany SETCLIENTID. > > Presumably it is a credential for the client host, rather than for any > > user (as all other credentials are). Is this true? Should this is stated? > > It can be any credential. However, to reset the client id using the same value > of nfs_client_id.id, the same credential must be used. See section 8.2.1. > > Practically speaking, a fat client like a UNIX system will likely use a constant > per host principal for generating the credential. Other types of clients > may not. The specification permits either, and it also permits the co-existance > of a a user-level NFS V4 client with a "native" client. It would be a mistake > to mandate a constant per host principal. I completely agree. My point is that the spec should make clear what is required of this credential. Any rogue client that has access to the same credential as was used for SETCLIENTID can launch a denial-of-service attach by telling the server to forget all state associated with that CLIENTID. This should be clearly stated in the document (currently it is implied) so that client implementers know what is needed. Thanks, NeilBrown
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:43 AM Z CST