Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-35

Based on the "Changes since RFC 3530" section 1.5, I don't believe that there is any OPS related new issues.

I am balloting No-Obj based on a "quick" read for any impacts on INT-related technologies.  Given the amount of time that my quick read took, I fully support Stephen's suggestion of carving this beast up into more manageable specifications.

I support Stephen's discuss points and will add to the pile-on request (I believe the author agreed with this already) to slit the document up into digestible chunks next time.   As Alissa pointed out, some of the text comparing versions adds unnecessary bulk to the draft.  I think it would be helpful to just have one section that includes changes, then have the set of specifications that make up the new version just specify that new version.  If you need to track motivations, perhaps using a wiki or a draft that may or may not be published would be better.

In the Security Considerations section, in the last two sentences of the first paragraph it seems like the word "privacy" is used where you mean "confidentiality", both are important.  Confidentiality is a security property that can help with privacy, but so can leaving the privacy sensitive data out and not encrypting sessions.  Confidentiality can apply to scenarios other than privacy specific ones as well, so they really shouldn't be conflated.  Confidentiality may be required to protect business information that doesn't have an effect on privacy (not HR sensitive data or identifying information about an individual).  It seems odd in section 3 to call one of the security "flavors" privacy, I think you mean confidentiality here. I'm guessing this term usage is because of rpc_gss_svc_privacy.  It might be helpful to explain the intended use and then map to the GSS functions.


Section 8.4 - Just as an FYI that does not need to be added to the draft, the location information would also be useful for ESI Data Maps, part of which requires an organization to track each instance of data (along with security protections and other information like retention periods.)

Thanks for addressing all of my comments. Good work.

I am still not thrilled with the use of RECOMMENDED and REQUIRED as qualifiers for attributes (I like the way 3530 did it better), but with the explanation called out, I think it should cause no problems. And I'm still utterly amused about the explanation of 2119 words in 12.1, since those definitions are *exactly* how 2119 defines the terms, only in more detail. The "conformance" use that we see in other documents nowadays, that this section is trying to distinguish itself from, is not what 2119 says.

But as I said, a fine job getting it to this point.

Please remember that I'm not smart about NFS, but I did have some questions. Please consider them along with the other feedback you've collected. And telling me I don't understand NFS could be a fine response ...

In this text:

  o  The user or group may be returned or used for verification in a	
     different form, as a result of Unicode normalization at the	
     server.  The result SHOULD be a canonically equivalent Unicode	
     string [UNICODE].  Other sorts of string modification, including	
     case mapping or folding, SHOULD NOT be done as such modifications	
                              ^^^^^^ ^^^          
     may cause the server to merge identities that are separate at the	
     client.
          
I lack understanding why violating this SHOULD NOT would be OK. If there's a reason why violating this SHOULD NOT would be OK, would that be a candidate to point out as a security consideration ("your server may hand objects that belong to you to anyone else with a similar user or group")?

In this text:

  -  In this particular case, we are pretty sure anyway that what has	
     moved is /this/is/the/path rather than /this/is/the since we have	
     the fsid of the latter and it is that of the pseudo-fs, which	
     presumably cannot move. 
     ^^^^^^^^^^
          
Is it possible for a pseudo-fs to move? (can you be pretty sure, but wrong?)

In this text:

  Stateid values whose "other" field is either all zeros or all ones	
  are reserved.  They may not be assigned by the server but have	
                      ^^^ ^^^
  special meanings defined by the protocol.
      
Would that be a MUST NOT?

I want to emphasize that my next comment is just from pattern matching, but what triggered it, was that the second bullet read strangely. In this text:

 o  Otherwise, if the entity corresponding to the lock-owner (e.g., a	
    process) sending the I/O has a byte-range lock stateid for the	
    associated open file, then the byte-range lock stateid for that	
    lock-owner and open file SHOULD be used.	
          
So, I'm reading this as one lock stateid for that lock-owner and open file. Is that right? In this text:
 		
 o  If there is no byte-range lock stateid, then the OPEN stateid for	
    the current open-owner, and that OPEN stateid for the open file in	
    question SHOULD be used.
          
I'm reading this as two OPEN stateids, one for the current open-owner, and one for the open file. Is that right? If it is, I just tripped over a non-pattern that's not supposed to match. If it's not, the sentence sure makes it sound like there are.

In this text:

  Since the sequence number is represented with an unsigned 32-bit	
  integer, the arithmetic involved with the sequence number is mod	
  2^32.  Note that when the seqid wraps, it SHOULD bypass zero and use	
                                            ^^^^^^
  one as the next seqid value. 

So, if this SHOULD is violated, what happens?

In this text:

  In any event, the server is able to safely release state-owner state	
  (in the sense that retransmitted requests will not be erroneously	
  acted upon) when the state-owner no currently being utilized by the	
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  client (i.e., there are no open files associated with an open-owner	
  and no lock stateids associated with a lock-owner).  

I couldn't parse the sentence, starting where I indicated.

Thanks for handling my discuss so promptly with such a monster document!

S.

--- The comments below aren't modified from the -11 (diff) review.

Review is based on diff:
https://tools.ietf.org/rfcdiff?url1=rfc3530&url2=draft-ietf-nfsv4-rfc3530bis-34.txt

And also on the diff vs. version -26 which was the last time
I reviewed this (in May 2013)
https://www.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-rfc3530bis-26&difftype=--html&submit=Go!&url2=draft-ietf-nfsv4-rfc3530bis-34

- Despite splitting out the xdr stuff, you have still managed
to increase the size of another NFS monster spec. That's not
really going in the right direction from the POV of this
reader. I'd encourage the WG to consider re-factoring the NFS
documentation into more digestable chunks at some point.
(While fully realising the huge and thankless effort that would
involve.) At some point, making these RFCs bigger and bigger is
going to by itself break something.

- 1.5: The move away from lipkey and spkm is quite reasonable.

- 3.3.1 - SECINFO is no longer "new" since that text hasn't
changed since 3530:-)

- 5.9: What does "kerberized" mean? If you mean "uses Kerberos"
then saying that would be better than inventing a new term.  If
it means something else, then I'm not sure what.

- 6.2.1 says: "Therefore servers should accept every ACL that
they can without compromising security." I know what you mean,
but I'm not sure if it's possible to implement that, in
general. Wouldn't it be possible to say some more about what a
server has to implement?

- 10.4.1, last para: (This was a DISCUSS on -26, but is now a
comment based on Tom's response) "making private copies" of
credentials sounds odd.  I assume you mean kerberos tickets but
I'm not sure how that can work. I'd also guess its security
mechanism specific.  Doesn't that need either some more text or
to just say that it doesn't work? Or am I confused? (Quite
possible;-)

And Tom said:

"Actually, it simply means UID and GID here.

As an example, there are scenarios in Solaris where when pages
get flushed to disk, the UID and GID from the original system
write have been lost and the page goes across the wire with
root credentials. This can be okay on a local file system but
not on a remote one."

So I think making that clear would be good or just not saying
those are credentials.

- section 17 says: "...the translation SHOULD be done in a
secure manner that preserves the integrity of the translation."
I don't know how that SHOULD turns into code - does 5.9 really
tell me exactly? If not, what's missing in 5.9 and shouldn't
that be here? If 5.9 does tell me exactly then I think a more
precise reference to the bit of 5.9 that's not a MUST
(presumably leading to this SHOULD) is needed.