Subject: Getting to Proposed Std, again (Chapter 3)

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 16 Jul 2002 12:38:59 -0700

Issue 148: The lease period provided by the server should not be set to 
zero. Server implementations should ensure that an administration error 
does not set the server's lease period to a value of zero. In fact, the 
minimum should be something larger than 1 second but this decision is 
still implementation based.

     I agree that the lease period "should" (note I didn't say "SHOULD")
     not be set to zero, but what is gained by adding this to the spec?  
     It is already clear from the way that the protocol is defined that
     leases would be useless by the time the client got them, so what is 
     added by adding this kind of statement to the spec.  In some cases
     such statements might be useful to "add artistic verisimilitude to
     an otherwise bald and unconvincing narrative", but they aren't necessary.
     In this particular case, I think having the server set a lease time 
     to zero would be a great client QA test (the client should madly 
     try to renew but should work (slowly) as long as it doesn't lose to
     conflicting locks but not panic or become otherwise unstuck) so let's
     leave this interesting option open.

Issue 153: The use of NFS4ERR_NOFILEHANDLE in the case that the saved filehandle is 
not set should be clarified in the errors section. 

     In the error section, after the words "current file handle value",
     add the words "(or, in the case of RESTOREFH, the saved file handle 
     value)".

Issue 154: For the READDIR operation, clarify what the maxcount parameter represents 
(READDIR4res or READDIR4resok). 

     In the second sentence of the fifth paragraph of the READDIR DESCRIPTION 
     section, add after the words "being returned" add the words within the 
     READDIR4resok structure".

Issue 158: Clarify results of LOOKUPP operation when current filehandle is a named 
attribute directory. 

     I think the only reasonable choice is that it is the directory or file of which
     the attribute directory is associated.  Anybody have another opinion?  

Issue 159: The client doesn't have a simple mechanism to determine if a particular 
server filesystem supports named attributes. Should a new number attribute be added 
to allow for this type of query? 

     We should put this if clients need it.  So far I haven't heard a groundswell
     of support.  Am I just not listening?

Issue 160: Clarify for RENAME which error should be returned for the condition where 
the target is a non-empty directory. Should be able to indicate this condition as 
opposed to the condition where the types of the source and target of the rename do 
not match.
 
     The clarification is in the latest spec.  On the other hand, the error is not
     different as asked for here.  What is the case for a separate error.  My inclination
     is to leave this as it is.

Issue 165: What is the behavior at the server for OPEN(create) when the size is zero? 
When the file data is truncated, should existing named attributes be removed as well 
or should named attributes be left as is on OPEN(create/truncate).

      This one where I think we have to reply on the expertise of those who work
      with systems (e.g. windows) that have streams.  Which seems more useful?
      Intuitively it seems better to me to blow away the streams but I'm not sure
      that that's right.

Issue 166: DOUBLE CHECK: Callback program should be able to enumerate ipv4/ipv6 at 
the same time. 

      Don't understand this issue.

Issue 167: If a file is opened write only, the client/application will not be able 
to read from the file. This has impacts on the traditional unix client that wants 
to fill a page in its page cache to allow a partial write of that page. Need to 
clarify the behavior (strictness) of the open(write-only) path and if this allows 
for a reasonable implementation at the client.

      I believe this was resolved by my rewrite of 8.1.4.

Issue 168: Discuss implementation per Bill's note: 
larger question of SETATTR in presence of delegation. I've been thinking about 
DELEGRETURN on trunc-up. Do you think we should return a delegation if a trunc-up 
operations takes the file size about the file size limit? 

     Yes.

Maybe a better question is should we do OTW SETATTR when the app does a trunc-up? I 
know we'd agreed that, in general, SETATTR goes OTW even when owning a delegation, 
but perhaps truncation is a special case.

     It seems like this is very much like a WRITE.
 
If a client returns a delegation when it hits the file size or modified block limits, 
should the client push all of the dirty date back to the server before doing DELEGRETURN? 
I know it does this in the case of RECALL, but I'm not sure about other cases.

     I think the two cases should be handled the same.  Looking at 9.4.3, it says 
     that and also discusses when you have to write back the data.  I think this 
     is OK as it is.

Issue 169: What is the behavior for OPEN(create) and CREATE where the fattr array is 
zero length? Succeed, no error?

     Why should be an error?  Unless some particular attribute is required, the null
     set of attribute seems a fine set.  Unless the spec specially calls out the e
     edge condition, I think we should assume it is valid.

Issue 170: Clarify OPEN and CREATE behavior where "owner" attribute is not specified. 
The owner of the new object should match that of the RPC authentication. 

     Except where the implementation chooses otherwise.  I agree that this is the
     normal choice but since it is the normal choice, implementers can make that
     choice unaided.  I think it would be good if the spec were shorter than War 
     and Peace. 

Issue 172: Mounted-on fid attribute to allow server to communicate underlying fid 
to the client who needs it to construct mount points for posix behavior.

     Don't understand why we would need this.

Issue 173: Use of the error NFS4ERR_DENIED is incorrect in the description of the 
OPEN operation. Should be NFS4ERR_SHARE_DENIED.

     In the four sentence of the sixth paragraph of the DESCRIPTION for OPEN, change
     NFS4ERR_DENIED to NFS4ERR_SHARE_DENIED. 

Issue 174: Add RELEASE_STATE operation to take the place of the RELEASE_STATE lock 
type; use this to avoid confusion about usage, etc. 

     I believe this is done.

Issue 175: Should SETCLIENTID with same client identifier, same verifier and a different 
callback program should return an error (not clear client state).

     I'm treating this as a dup on Issue 114 (even though it isn't really), but I
     think that all of these SETCLIENTID issues need to addressed together to 
     get to a solution that works.

Issue 176: Add the NFS4ERR_BADHANDLE to the OPEN operation.

     So let's add it. 

Issue 177: When LOCKU operation receives a locktype that is different than the lock 
set on the file, should LOCKU return NFS4ERR_INVAL or allow the LOCKU to operate
and return NFS4_OK.

     Certainly it should match for strict locking.  But for the horrible
     POSIX locking, can't you unlock range that include multiple locks of
     multiple types.  What do the clients want here?  

Issue 178: SECINFO currently allows for the return of NFS4ERR_WRONGSEC. This should 
be removed and language added to state that PUTFH should be checking for the 
appropriate security mechanism and itself returning NFS4ERR_WRONGSEC. 

     I agree this should be done. 

Issue 181: For the supp_attr attribute, clarify scope of supported attributes; is 
it for that object or all objects in the file system (per fsid).
 
     I believe it should be per file-system and this should be stated explicitly.

Issue 184: Delegation interpretation issues. 1) CLOSE, DELEGRETURN separate,
2) handling of "change" attribute between CB_GETATTR   

     1) is a dup of Issue 105 while 2) is a dup of Issue 113.

Issue 186: With respect to UTF-8 usage in the protocol, what is the correct behavior 
at client and server for invalid encodings. This includes both illegal prefixes, 
incorrect number of bytes and the case where the server does not allow storage 
of particular UCS characters.

     Let's deal with the server (or the client if called back) because he can
     return errors.  If the utf-8 item is not valid UTF-8 (partial characters,
     inappropriate prefixes) then I would think INVAL is appropriate (I think
     Peter Astrand's test expect BADXDR which is OK with me as long the spec
     defines one or the other.  A string inlcuding a character that the server 
     fs does not support should be a different (new) error, NFS4ERR_BADCHAR.
     The client (except on callback) can't really do anything about any of this.

Issue 187: The definition of fattr4_mode should be clear about what is to be 
included. Is it just the mode or does it include type? Should it be allowed to 
include other information as has been the case in v2/v3?

     I think it has to include the other information.  Otherwise all hell will
     break loose.  There is no need for the type.  That should be defined as
     zero on GETATTR and reserved (i.e. may not be set on SETATTR).

Issue 188: Explanation of the use of NFS4ERR_ATTRNOTSUPP should be included in the
appropriate operation descriptions. Most interesting in the case that an OPEN/CREATE 
specifies an attribute that is not supported by the server. Should the OPEN succeed 
if there is a mix of supported and non-supported attributes specified and all of the 
supported attributes could be set? Also include error return in the case that a 
supported read-only attribute is specified.

     I'm not sure I understand the argument here.  There is a general description
     of NFS4ERR_ATTRNOTSUPP and a statement that it doesn't apply to GETATTR.
     So do we have to clutter up each description with this?  As far as OPEN/
     CREATE, it should not work if unsupported options are specified, whether 
     there are supported ones specified or not.  I assume INVAL error if read-only
     attributes are specified.  That certainly is the default.

Issue 189: Add brief discussion to explicitly list operations with respect to 
being idempotent and non-idempotent.

     Why do we need to do this?

Issue 191: Add new error(s) to signify that the server is rejecting the use 
of a character or filename based on local operating environment restrictions. 
An example would be if a request were attempting to create a file with the name 
of ".". The server may reject this and the client should know that it is because 
of a poor choice in filenames.

     Agree that this should be done: NFS4ERR_BADNAME.  However, if this is
     because it includes a character not supported by the files system at 
     all, NFS4ERR_BADCHAR would be the error to return.  (See Issue 186).

Issue 192: Clarify the ACE flags ACE4_SUCCESSFUL_ACCESS_FLAG and 
ACE4_FAILED_ACCESS_FLAG and expected behaviors.

     No idea how to deal with this.  Anybody familiar with the NT world
     have clue?

Issue 193: For the case of OPEN(create-exclusive) add discussion of how long 
the server should/must keep the exclusive create verifier around.

     It should be until someone does a SETATTR on the file.

Issue 194: Change definitions for fh_expire_type slightly to accommodate 
Dave Noveck's description of a particular migration event and filehandle 
management via volatile filehandles.

     I still think this should be done.  The message is at
     http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0078.html      

Issue 195: Clarification of how linktext4 is to be interpreted. 

     The spec doesn't say how to interpret files either.  I would leave this 
     out.

Issue 197: Resolve the mapping of user/group ids and their representation in 
ACLs as they related to RPC credentials. 

     After the rewrite of the section on user and group names, is there still
     a need for something more?

Issue 199: It is not clear what should be the result of LOOKUPP on a named 
attribute directory. Should it refer to the object associated with that named attribute directory or should it refer to the parent directory of that object, 
which could be implied from the documentation "LOOKUPP assigns the filehandle 
for its parent directory to be the current filehandle". 
Also see issue 158.

     DUP of Issue 158.

Issue 202: It may be possible to map a POSIX draft ACL to and from the NFSv4 
ACL with the addition of a POSIX_ACL_MASK@ special user.

     Since nobody has made a proposal about doing this, I'm assuming that 
     there is not sufficient interest to do this.  Am I wrong? 

Issue 203: If the server is accepting requests but no file system resources 
are currently available, what is the requirement for the server. Does it have 
to present a directory for PUTROOTFH and show that it is empty? If so, what 
security mechanism should it accept since it is likely that if no file system
resources are available that no corresponding or default security mechanism 
is in effect.

     It has to present a directory and the obvious appearance for it is 
     empty.  This is consequence of showing the resources.  When there are
     none, the directory is empty.  As far as which security mechanism
     to accept, whichever one the implementation wants, or the administrator
     directs, depending on how paranoid he is.  Why is this a matter for
     the spec to decide?

Issue 204: Should the protocol include a NFS4ERR_DEADLOCK error for those 
instances that a server supports and can determine that a deadlock condition 
has occurred with respect to file locking? 

      I don't see how this can be done with the V4 locking model.  You don't 
      wait for locks, you retry.  In that context, if A has lock 1 and B has 
      lock 2, if B asks for 1, it is rejected and then A asks for 2 and it 
      is rejected.  Even if the server tried to remember previous requests,
      how would it know that the A still wanted the lock?  If this is 
      important to somebody, it should have been brought up three years
      ago when v4 locking was designed.