Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-03-23
35 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-03-02
35 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-02-15
35 (System) RFC Editor state changed to RFC-EDITOR from REF
2015-02-12
35 (System) RFC Editor state changed to REF from AUTH
2015-02-11
35 (System) RFC Editor state changed to AUTH from EDIT
2015-01-04
35 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-12-26
35 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-12-26
35 (System) IANA Action state changed to Waiting on Authors
2014-12-23
35 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-12-22
35 (System) RFC Editor state changed to EDIT
2014-12-22
35 (System) Announcement was received by RFC Editor
2014-12-22
35 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-12-22
35 Amy Vezza IESG has approved the document
2014-12-22
35 Amy Vezza Closed "Approve" ballot
2014-12-22
35 Amy Vezza Ballot approval text was generated
2014-12-21
35 Martin Stiemerling Ballot writeup was changed
2014-12-21
35 Martin Stiemerling all ready to go!
2014-12-21
35 Martin Stiemerling IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-12-19
35 Martin Stiemerling IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup
2014-12-15
35 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-12-04
35 Stephen Farrell
[Ballot comment]

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

S.

--- The comments below aren't modified from the -11 (diff) …
[Ballot comment]

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.
2014-12-04
35 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2014-12-04
35 Pete Resnick
[Ballot comment]
Thanks for addressing all of my comments. Good work.

I am still not thrilled with the use of RECOMMENDED and REQUIRED as qualifiers …
[Ballot comment]
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.
2014-12-04
35 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2014-12-04
35 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-12-04
35 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-35.txt
2014-12-04
34 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-12-04
34 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-12-04
34 Ted Lemon [Ballot comment]
This document addresses several of the concerns I've had with previous versions of NFS.  Thanks for doing it!
2014-12-04
34 Ted Lemon [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon
2014-12-04
34 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-12-04
34 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-12-03
34 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-12-03
34 Kathleen Moriarty
[Ballot comment]
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 …
[Ballot comment]
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.)
2014-12-03
34 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-12-03
34 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-12-03
34 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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.
2014-12-03
34 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2014-12-03
34 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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.
2014-12-03
34 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-12-03
34 Pete Resnick
[Ballot discuss]
As Barry said, the rewrite of section 12 is generally excellent work. Thanks for that. My only concern is 12.6. I've spent some …
[Ballot discuss]
As Barry said, the rewrite of section 12 is generally excellent work. Thanks for that. My only concern is 12.6. I've spent some time trying to fix this section, and I think any problems can be easily addressed, but I'm not sure what the intention is, so I've not been able to come up with the right text. So, let me ask some questions.

Do you mean to reject strings that have characters that are not IDNA-valid according to IDNA2008? That is, do you want to allow or disallow strings that are valid UTF-8 but aren't valid U-labels? Similarly, do you want to reject invalid ASCII LDH-labels or invalid A-labels? Remember, U-labels and A-labels only contain IDNA-valid characters.

Or, conversely, do you want to use the old NAMEPREP routine from RFC3491 and map invalid stuff into valid stuff?

The text as written doesn't make that clear, and it doesn't do either of those two things correctly, so let me know what you want to happen, and I'll try to help you make it happen.
2014-12-03
34 Pete Resnick
[Ballot comment]
I have re-reviewed those sections that have changed (particularly section 12) and included comments from my earlier review that have not been addressed. …
[Ballot comment]
I have re-reviewed those sections that have changed (particularly section 12) and included comments from my earlier review that have not been addressed.

1.3.6:

  At OPEN, the server may provide the client
  either a OPEN_DELEGATE_READ or OPEN_DELEGATE_WRITE delegation for the
  file.  If the client is granted a OPEN_DELEGATE_READ delegation, it
  is assured that no other client has the ability to write to the file
  for the duration of the delegation.  If the client is granted a
  OPEN_DELEGATE_WRITE delegation, the client is assured that no other
  client has read or write access to the file.

Personally, I think the 3530 use of the informal words is better instead of OPEN_DELEGATE_READ/WRITE  in the introductory section. Those terms are not defined at this point.

2.1:

s/String MUST be sent as ASCII/String is sent as ASCII

4.2.3:

  SHOULD return an error of NFS4ERR_FHEXPIRED.

So you're now saying that it's an interoperability problem to return other than NFS4ERR_FHEXPIRED, but there might be cases where you have to? Can you give an example of one of those cases?

5: In this section, you changed "mandatory attributes" to "REQUIRED attributes" and "recommended attributes" to "RECOMMENDED attributes", and uppercased a bunch of MUSTs, SHOULDs, and MAYs. I'm a bit worried you did this simply because one or more people said "Shouldn't those all be 2119 terms?" without any particular reason, and I'm worried that some of the new uses actually don't make sense. For example, you now have:

  A server should support as many of the RECOMMENDED attributes as
  possible but, by their definition, the server is not required to
  support all of them.

RECOMMENDED, in the 2119 sense, doesn't mean that. RECOMMENDED (like SHOULD) means, "There may be reasons to not do this, but you need to understand the full implications of doing so, because normally this is required for interoperability or to avoid harm." Later in 5.2 you say:

  A client MAY ask for any of these attributes to be
  returned by setting a bit in the GETATTR request but must handle the
  case where the server does not return them.  A client MAY ask for the
  set of attributes the server supports and SHOULD NOT request
  attributes the server does not support.

A client must handle the case where the server doesn't return REQUIRED attributes as well (i.e., a client can't just crash because a server is broken). It sounds to me like these RECOMMENDED attributes are really OPTIONAL in the 2119 sense. (They might be "recommended" in the informal sense, as I think you had it before, but 2119 terms muck up the issue.) Also, it seems to me that a client MUST NOT request attributes that the server does not support, not SHOULD NOT.

I'm not convinced this improved the document.

5.9:

OLD
  For example, the DNS domain name might be "lab.example.org", but the
  user names are defined in "example.org".
 
This is written ambiguously. I think you mean

NEW
  For example, the DNS domain name of the host running the NFS server
  might be...".

I don't think the following is helpful:

OLD
  Internationalization issues (for a general discussion of which see
  Section 12) make this impossible and the client needs to take note of
  the following situations:

I think you should simply refer to section 12 and not give the examples here:

NEW
  Internationalization issues make this impossible under certain
  circumstances and the client needs to take note of these. See Section
  12 for a detailed discussion of these issues.
 
8.2, third paragraph: s/whether it has moved or not/whether it has moved or simply never existed

9.8, fourth paragraph: I don't know how to implement a "MUST NOT assume". Change back to "may not" or make it "can not", or explain exactly what it is that a client MUST NOT do as a result of a failed operation.

10.2:

  However, the time allowed for
  recall completion SHOULD NOT be unbounded.

That's not a very helpful normative requirement. I don't see why you changed it to such a thing.

12ff: Generally, excellent work. Thanks for this.

12.1 makes me laugh a little, 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.

12.3 (editorial): This sentence is repeated twice: "Such servers ignore normalization-related issues and there is no way for them to implement either normalization or representation-independent lookups."

12.4: I don't understand the reference to 2279. There's nothing in there that isn't in 3629.

12.5: s/must normalize/will need to normalize

Just to avoid confusion.
2014-12-03
34 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2014-12-03
34 Benoît Claise [Ballot comment]
Based on the "Changes since RFC 3530" section 1.5, I don't believe that there is any OPS related new issues.
2014-12-03
34 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-12-02
34 Brian Haberman
[Ballot comment]
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 …
[Ballot comment]
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.
2014-12-02
34 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-12-01
34 Stephen Farrell
[Ballot discuss]

(1) 3.2.1.1: Do you really still need to say that clients do
not need to support rpc_gss_svc_privacy? That seems
inconsistent with e.g. RFC7258 …
[Ballot discuss]

(1) 3.2.1.1: Do you really still need to say that clients do
not need to support rpc_gss_svc_privacy? That seems
inconsistent with e.g. RFC7258 and the recent IAB statement on
confidentiality. Neither of those strictly require protocols to
support confidentiality of course, they mostly encourage it, so
I'm not DISCUSSing on the basis that our processes require
confidentiality. It just seems to me like it's probably not
really a problem today to say that client MUST support that GSS
service as well. Am I wrong? I'm perfectly willing to be
convinced that I'm wrong here btw e.g. if there are a whole
slew of implementations that can't support this but I suspect
that might no longer be the case. (I can well imagine it used
be the case a decade ago.) And if I am wrong then I'm happy to
clear the DISCUSS, on the basis that you're not really changing
the protocol here so it'd not be reasonable to insist on you
adding confidentiality part of this work.

(2) 3.2.1.1: The reference to Kerberos via 4121 (and updates)
presumably makes AES the MTI crypto alg now? If not, that I
think would need to be called out but I think it is the case. I
just wanted to check that we're not allowing for something mad
like single-DES still be nominally consistent with this spec.
(I saw from Tom Haynes August 2013 response to my DISCUSS on
-26 that there are such implementations, but I hope they are
not considered compliant in that respect.) So this is just checking.
2014-12-01
34 Stephen Farrell
[Ballot comment]

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 …
[Ballot comment]

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.
2014-12-01
34 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2014-11-28
34 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2014-11-28
34 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2014-11-12
34 Barry Leiba
[Ballot comment]
First, a general comment on Section 12:
This was a lot of work, and is very well done.  Of course, it necessarily often …
[Ballot comment]
First, a general comment on Section 12:
This was a lot of work, and is very well done.  Of course, it necessarily often throws up its hands, but that's as it has to be, given the variables involved.  As one of the App ADs who sent this back to have this stuff fleshed out, this is a big "Thanks!" for the good work on the internationalization text.  I know it wasn't easy.

Thanks also for addressing my list of comments.  Only two remain, and they are non-blocking:

-- Section 8.8.1 --

   o  All file system instances servers should be considered as of
      different readdir classes.

I can't parse "file system instances servers".  I see that you removed the word "servers" from the previous list item, so I guess it's just that.

-- Section 18.1 --

Thanks for changing the policy specification to make it clear that it's Specification Required.
It would be good if you would also provide some brief guidance to the designated expert as to what she should be considering in her review.  Should the expert *only* consider whether the specification is suitable to build interoperable implementations from?  Should the expert also consider the merits of what is being proposed?  It's worth bring explicit about that, and, if the latter, to say something about when it might be appropriate -- and when not -- to deny a request or to send it back for re-work.
2014-11-12
34 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss
2014-11-10
34 Thomas Haynes IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-11-10
34 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-34.txt
2014-11-07
33 Barry Leiba
[Ballot discuss]
I have a few points I'd like to discuss before the document moves ahead.  I don't think any of them are big deals, …
[Ballot discuss]
I have a few points I'd like to discuss before the document moves ahead.  I don't think any of them are big deals, so it should all be easy discussion.

-- Section 4.2.1 --

   If two filehandles
   from the same server are equal, they MUST refer to the same file
   system object.  Servers SHOULD try to maintain a one-to-one
   correspondence between filehandles and file system objects but this
   is not required.  Clients MUST use filehandle comparisons only to
   improve performance, not for correct behavior.  All clients need to
   be prepared for situations in which it cannot be determined whether
   two filehandles denote the same object and in such cases, avoid
   making invalid assumptions which might cause incorrect behavior.

I'm very confused by this, as parts of it appear to contradict other parts.  If equal filehandles MUST refer to the same object, how can there be situations in which that cannot be determined?  What invalid assumptions might a client make?  And if a client uses the fact that two filehandles are equal in order to improve performance, how is it not expecting correct behaviour out if that?  I don't understand.

(Note that I DO understand that two accesses to the same object might have different filehandles, but the thrust of the question relates to behaviour when the filehandles ARE equal.)

-- Section 6.2.1.2 --

   Support for any of the ACL attributes is optional (albeit,
   RECOMMENDED).

Noooooooooo!
RECOMMENDED does not mean optional!  RECOMMENDED means that you'd better support them unless you have a good reason not to and you fully understand the ramifications of what you're doing.

If they're truly OPTIONAL, then say that.  If they're truly RECOMMENDED, then please figure out a way to reword this to say what you really mean to say, or just remove it.

-- Section 6.3.1.2 --

   Clients must be aware of situations in which an object's ACL will
   define a certain access even though the server will not enforce it.
   In general, but especially in these situations, the client needs to
   do its part in the enforcement of access as defined by the ACL.  To
   do this, the client MAY send the appropriate ACCESS operation prior
   to servicing the request of the user or application in order to
   determine whether the user or application should be granted the
   access requested.

I absolutely don't understand this.  I presume that this is saying that a server might respond to an ACCESS operation by telling you that access is not allowed, but an OPEN would actually allow it.

1. If the client does its part without sending an ACCESS operation (MAY makes that optional), then isn't it in contradiction with the previous paragraph, which says "Clients SHOULD NOT do their own access checks based on their interpretation the ACL, but rather use the OPEN and ACCESS operations to do access checks." ?

2. How is it in any way secure to rely on a client to refuse access, if the server won't enforce the access controls?  I can't see how it's a good thing to make the client part of the access control model.

3. You refer to 6.3.1.1 for examples, but all of those are examples of the server purposefully altering the effective access controls.  None are actually cases where the server *fails* to enforce access controls.  Do those cases actually exist?

-- Section 9.1.1 --

      *  The client machine's serial number (for privacy reasons, it is
         best to perform some one way function on the serial number).

      *  A MAC address.

The MAC address is at least as much a privacy issue as the serial number is, and should have the same warning.

-- Section 11 --

   The following items represent the basic rules for the development of
   minor versions.  Note that a future minor version may decide to
   modify or add to the following rules as part of the minor version
   definition.

That seems, at best, unwise.  V4.0 implementations are going to assume that they can interoperate with v4.1 and v4.2 implementations to the extent that minor versioning adheres to these precepts.  The whole point of distinguishing minor versions from major ones is to allow that -- some limited level of assured backward compatibility.  But if you allow v4.1 to change the rules, all assumptions that v4.0 implementations made are off, and you might as well not have had these rules at all.

Perhaps the working group debated this at length, and this represents clear and informed consensus.  If so, let me know, and I'll accept that.  Otherwise, it seems to me that the rules for what changes are and are not allowed between minor versions should only be changeable in a new major version.

-- Section 18.1 --

   All assignments to the registry are made on a First Come First Served
   basis, per section 4.1 of [RFC5226].  The policy for each assignment
   is Specification Required, per section 4.1 of [RFC5226].

This is an incorrect policy specification, and now is a good time to fix it, by changing the specification and alerting IANA to the change.  FCFS and Specification Required are different policies, and it doesn't make sense to combine them like this.  I think that what you want here is just Specification Required, and then you should provide some brief guidance to the designated expert as to what she should be considering in her review.  If you think it's important to tell the expert that she should consider requests in the order that they were made, and that if requests conflict, the earlier one should take precedence, then say that.  You should also say something about when it might be appropriate -- and when not -- to deny a request or to send it back to re-work.
2014-11-07
33 Barry Leiba
[Ballot comment]
In case anyone is wondering, a ten-hour flight is about the right time to review a 300-page document.  Your mileage may vary, of …
[Ballot comment]
In case anyone is wondering, a ten-hour flight is about the right time to review a 300-page document.  Your mileage may vary, of course.  (And I did this on an iPad, so if I've left some odd typo un-fixed, please do your best to figu54Mit out.)

First, a general comment on Section 12:
This was a lot of work, and is very well done.  Of course, it necessarily often throws up its hands, but that's as it has to be, given the variables involved.  As one of the App ADs who sent this back to have this stuff fleshed out, this is a big "Thanks!" for the good work on the internationalization text.  I know it wasn't easy.

I have a bunch of non-blocking comments.  I think some of them are important, despite their being non-blocking, so please do consider them:

   1.2.  Definitions in the companion document NFS Version 4 Protocol
   are Authoritative

   [RFCNFSv4XDR], NFS Version 4 Protocol, contains the definitions in
   XDR description language of the constructs used by the protocol.
   Inside this document, several of the constructs are reproduced for
   purposes of explanation.  The reader is warned of the possibility of
   errors in the reproduced constructs outside of [RFCNFSv4XDR].  For
   any part of the document that is inconsistent with [RFCNFSv4XDR],
   [RFCNFSv4XDR] is to be considered authoritative.

But the title of RFCNFSv4XDR isn't that... it's "NFS Version 4 XDR Description".  The correct title should replace "NFS Version 4 Protocol" in the section title and the first sentence.  I would also put the document title in quotation marks.

In Sections 1.5 and 1.6, it would be best if the list items were made parallel.  That is, make each item a complete sentence, ending with a ".".  For example, the first item in 1.5 would get a ".", and the second would become "Updates have been made for the latest IETF intellectual property statements."

Is Section 1.6 about changes between 3010 and *this*, or between 3010 and 3530?  I think it's the latter, and if it's still valuable to retain that list, the text should make the context clear, like this:

OLD
1.6.  Changes since RFC 3010

   This definition of the NFSv4 protocol replaces or obsoletes the
   definition present in [RFC3010].  While portions of the two documents
   have remained the same, there have been substantive changes in
   others.  The changes made between [RFC3010] and this document
   represent implementation experience and further review of the
   protocol.
NEW
1.6.  Changes between RFC 3010 and RFC 3530

   The definition of the NFSv4 protocol in [RFC3530] replaced and
   obsoleted the definition present in [RFC3010].  While portions
   of the two documents remained the same, there were substantive
   changes in others.  The changes made between [RFC3010] and
   [RFC3530] represent implementation experience and further
   review of the protocol.
END

That said, I wonder whether it's not best to just drop Section 1.6, as 3530 has been the current version for 11 years.  Does anyone really care what's changed since 3010 at this point?

-- Section 3.1 --

   Historically, NFSv2 and NFSv3 servers have resided on port 2049.

NFSv4 has been around for 14 years, and has (I presume) continued to use port 2049; shouldn't it be added to the list as well?

-- Section 3.2.1 --

   NFSv4 clients and
   servers MUST be implemented on operating environments that comply
   with the REQUIRED cryptographic algorithms of each REQUIRED
   mechanism.

I think that 2119 key words belong in directives (the MUST here), but not in adjectives that reference directives that are given elsewhere (the two REQUIRED key words).  They should be in lower case here.  Presumably they are correctly given as directives where the required algorithms and mechanisms are specified.  The same applies to the last paragraph of Section 3.2.1.1.

-- Section 4.2.3 --
There are a bunch of "should"s in this section that I wonder about: ought some or all of them be "SHOULD"?  For one example, here:

   Servers which provide volatile filehandles that may expire while open
   (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if
   FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should
   deny a RENAME or REMOVE that would affect an OPEN file of any of the
   components leading to the OPEN file.  In addition, the server should
   deny all RENAME or REMOVE requests during the grace period upon
   server restart.

Is it that servers just sorta kinda oughta deny RENAME and REMOVE in these situations?  Or is it an important protocol directive that they deny them?  Please look at the "should"s in this section and see which, if any, need to be protocol directives.

-- Section 4.2.4 --

   A volatile filehandle, while opaque to the client could contain:

Editorial nit: this needs another comma after "client".

-- Section 5.1 --

   A client can ask for any of these attributes
   to be returned by setting a bit in the GETATTR request, and the
   server MUST return their value.

Editorial nit: make it "values", as "attributes" is also plural.

-- Section 5.6 --

      but in such an event, it should be
      resolved with Errata to this document and/or [RFCNFSv4XDR].  See
      [ISEG_errata] for the Errata process.

Nice: I don't know if we've had references to IESG statements before.  But please make the reference anchor be "IESG_errata", not "ISEG".  :-)

   o  Acc: Access allowed to the attribute.  R means read-only (GETATTR
      may retrieve, SETATTR may not set).  W means write-only (SETATTR
      may set, GETATTR may not retrieve).  R W means read/write (GETATTR
      may retrieve, SETATTR may set).

Just above, in 5.5, you say "get-only" and "set-only".  It'd be best to be consistent.

-- Section 5.8 subsections --
I didn't see this specified anywhere: as attributes 5 and 6 (link_support and symlink_support) refer to the object's file system, and attribute 8 (fsid) identifies the filesystem... is it an error if two objects have the same fsid, but different values for one of the link attributes?  That is, if two objects have the same value for fsid, is it the case that they MUST also have the same values for attributes 5 and 6?

-- Section 5.8.1.2 --

   The phrase "is an regular file" means

Change "an" to "a".  And I have to ask: is there any phrase that means that the object's type attribute is NF4LNK?  That one's missing from the list.

-- Sections 5.8.2.3 and 5.8.2.4 --

Because I've seen the question come up often in other contexts, I think a few more words of explanation might be useful here.  So if I may, let me suggest this:

OLD
  5.8.2.3.  Attribute 16: case_insensitive

     TRUE, if file name comparisons on this file system are case
     insensitive.

  5.8.2.4.  Attribute 17: case_preserving

     TRUE, if file name case on this file system is preserved.

NEW
  5.8.2.3.  Attribute 16: case_insensitive

     TRUE, if file name comparisons on this file system are case
     insensitive.  This refers only to comparisons, and not to
     the case in which file names are stored.

  5.8.2.4.  Attribute 17: case_preserving

     TRUE, if file name case on this file system is preserved.
     This refers only to how file names are stored, and not to
     how they are compared.  File names stored in mixed case
     might be compared using either case-insensitive or
     case-sensitive comparisons.

END

-- Section 5.8.2.11 --
Is it really best to say "Windows API" here, or might "underlying file system API" be better (more flexible)?  Same question applies to attribute 46 (system).

-- Section 5.8.2.18 --

   Attribute 32: mimetype
   MIME body type/subtype of this object.

We're really trying to say "media type" instead of "MIME type" these days.  We can't change the attribute name at this point, I guess, but might we change the description to "MIME media type/subtype of this object."?

-- Section 5.8.2.27 --

   If the file's type
   attribute is not NF4BLK or NF4CHR, the value returned SHOULD NOT be
   considered useful.

Might this be this?:

NEW
   If the file's type
   attribute is not NF4BLK or NF4CHR, this attribute SHOULD NOT be
   returned, and any value returned SHOULD NOT be considered useful.
END

-- Section 5.10 --
There seems to be a "(" missing after "Turkish".  It might also be good to break that awfully long sentence before "therefore".

-- Section 6.2.1 --

   For example, a UNIX-
   style server might choose to silently allow read attribute
   permissions even though an ACL does not explicitly allow those
   permissions.  (An ACL that explicitly denies permission to read
   attributes should still be rejected.)

I didn't get this until the third reading: you don't mean that the ACL should be rejected.  You mean that the access should be denied.  "(An ACL that explicitly denies permission to read attributes should still result in a denial.)"

   The guiding principle with regard to NFSv4 access is that the server
   must not accept ACLs that appear to make access to the file more
   restrictive than it really is.

The way this is worded seems ambiguous, and I'm not sure what you intend.  Do you mean this?:

NEW?
   The guiding principle with regard to NFSv4 access is that the server
   must not accept ACLs that give an appearance of more restricted
   access to a file than what is actually enforced.
END

-- Section 6.2.1.3.1 --

In ACE4_READ_DATA (and later in ACE4_EXECUTE):

         Servers SHOULD allow a user the ability to read the data of the
         file when only the ACE4_EXECUTE access mask bit is allowed.

I don't think the access mask bit is "allowed"... I think you mean "set".

Why isn't the SHOULD a MUST?  As you say, it is not possible to execute a file that you can't read.  And the third bullet in 6.3.1.1 says as much, as well.

In ACE4_APPEND_DATA:

         If a file has an ACL such as the one described above
         and a WRITE request is made for somewhere other than EOF, the
         server SHOULD return NFS4ERR_ACCESS.

Not MUST??  Wouldn't I be very unpleasantly surprised if I set an append-only ACL and later found the data overwritten?  If a server can't enforce append-only, shouldn't it simply not allow this bit?

In ACE4_EXECUTE:

See above, with regard to ACE4_READ_DATA.  Also, it would be good if the two descriptions of ACE4_EXECUTE explicitly said that there are two different meanings, depending upon the operation being done.

-- Section 6.2.1.3.2 --

   Servers SHOULD allow unlink if either ACE4_DELETE is permitted on the
   target, or ACE4_DELETE_CHILD is permitted on the parent.  (Note that
   this is true even if the parent or target explicitly denies one of
   these permissions.)

I think this would be a little clearer if it said "this is true even if the parent or target explicitly denies the other of these permissions."

-- Section 7.1 --
Should you really be talking about Windows NT here, given how long the NT brand hasn't been used, and how many Windows versions have come since?  Might it be sufficient to just say "Windows" here?  Similarly, in 7.4 is there still a point in talking about DOS?

-- Section 8.4 --
This section and its subsections could do with some review and reorganization.  There seems to be quite a bit of duplication that's jarring, at best.  Examples include paragraph 3 of 8.4 and paragraph 1 of 8.4.2; and paragraph 3 of 8.4.1 and paragraph 3 of 8.4.2.

-- Section 8.8.1 --

      All listed file system instances should be considered as of the
      same handle class

Here and in the subsequent bullet items, it would be clearer if you said "should be considered as being of the same..." instead.  Without "being" it's a bit odder to read.

   o  All file system instances servers should be considered as of
      different change classes.

   o  All file system instances servers should be considered as of
      different readdir classes.

I can't parse "file system instances servers"; what does it mean?

-- Section 9.1.1 --

   The first field, verifier is a client incarnation verifier that is
   used to detect client reboots.

Editorial nit: you need another comma after "verifier".  And similarly, after "id" here:

   The second field, id is a variable length string that uniquely
   defines the client.

-- Section 9.1.3.1 --

      Stateids may represent file delegations, which are recallable
      guarantees by the server to the client, that other clients will
      not reference, or will not modify a particular file, until the
      delegation is returned.

This is not correctly punctuated, which makes it hard to parse.

NEW
      Stateids may represent file delegations, which are recallable
      guarantees by the server to the client that other clients will
      not reference, or will not modify, a particular file until the
      delegation is returned.
END

-- Section 9.6.1 --

   In the event that a client fails, the server may recover the client's
   locks when the associated leases have expired.  Conflicting locks
   from another client may only be granted after this lease expiration.
   If the client is able to restart or reinitialize within the lease
   period the client may be forced to wait the remainder of the lease
   period before obtaining new locks.

The last sentence confuses me.  Do you mean that the *other* client may be forced to wait?  If not, why would the restarted client want new locks, when the original ones are still in effect?

-- Section 10.3.1 --

      Clients may
      choose to do the revalidation more often (i.e., at OPENs
      specifying DENY=NONE) 

Is "i.e." correct there, or did you mean "e.g." (or, better, "such as", avoiding the often-confused Latin abbreviations)?

-- Section 12.1 --

   o  Behavior implemented by some not all existing clients or servers,
      is described using "MAY"

Make it "...by some, but not all existing...".

-- Section 12.6 --

   The string sent SHOULD be in the form of a U-label although it MAY be
   in the form of one or more A-labels or a UTF-8 domain name that is
   not a properly formatted U-label.

This is 2119 error number 1: MAY is not an alternative to SHOULD, but specifies behaviour that is entirely optional.  Something like this works:

NEW
   The string sent SHOULD be in the form of a U-label.  If that is
   impractical, it can instead be in the form of one or more
   A-labels or a UTF-8 domain name that is not a properly formatted
   U-label.
END

   A server SHOULD use the first method, but MAY use the second method.

Same as above.  Here, I would just say, "A server SHOULD use the first method."

-- Section 13.2 --
Take this as you see best: I have seen many cases where this sort of list was provided, and it later turned out to make sense to use an error code in a context that had not been anticipated, and angst ensued.  I wonder whether you want to add an escape clause here and in the following sections, to the effect that this is here to provide guidance, that error codes might later be used in other ways, and that implementations should not be coded to refuse to accept combinations that are not listed here (and maybe change "valid" to "expected", of some such).  That might save you both document errata and implementation problems later.

-- Section 15 --
I found this section to be hard to read because of the plethora of subsections and the fact that the first-level subsections are not differentiated.  I suggest asking the RFC Editor to make each first-level subsection start on a new page, to make it easier to find the start of each operation.  Same for Section 16, though it's not as important there (there aren't as many).

-- Section 15.6.4 --

   The CREATE operation creates a non-regular file object in a directory
   with a given name.  The OPEN operation MUST be used to create a
   regular file.

I don't think that's a 2119 MUST: it's simply a statement of how the protocol works, so I would change "MUST be" to "is".
2014-11-07
33 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2014-10-23
33 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Not OK
2014-10-20
33 Martin Stiemerling Telechat date has been changed to 2014-12-04 from 2013-05-30
2014-10-20
33 Martin Stiemerling IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-10-20
33 Martin Stiemerling Changed consensus to Yes from Unknown
2014-10-20
33 Martin Stiemerling Ballot has been issued
2014-10-20
33 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2014-10-06
33 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-09-30
33 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2014-09-30
33 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530bis-33, which is currently in Last Call, and has the following comments:

IANA has a question about the IANA …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530bis-33, which is currently in Last Call, and has the following comments:

IANA has a question about the IANA Considerations section in this draft.

We received the following comments/questions from the IANA's reviewer:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

QUESTION: The following text is located in section 18.1.  Named Attribute Definitions:

/snip/

All assignments to the registry are made on a First Come First Served
  basis, per section 4.1 of [RFC5226].  The policy for each assignment
  is Specification Required, per section 4.1 of [RFC5226].

/snip/

We believe that this draft is not intended to update RFC5661 nor introduce any new
changes.  However the above text appears to contradict the current information
listed in the registry:

NFSv4 Named Attribute Definitions Registry

Registration Procedure(s):
Specification Required
Expert(s):
Spencer Shepler
Reference:
[RFC5661]

See: http://www.iana.org/assignments/nfsv4-named-attributes

Q: Is " All assignments to the registry are made on a First Come First Served
  basis, per section 4.1 of [RFC5226].  The policy for each assignment
  is Specification Required, per section 4.1 of [RFC5226]." applying to
new sub-registries to be added to the registry "NFSv4 Named Attribute
Definitions Registry" (http://www.iana.org/assignments/nfsv4-named-attributes)?

Q: Should a new NFSv4 Named Attribute registration use Specification Required
or First Come First Served?

Can the authors please clarify the above?

If this assessment is not accurate, please respond as soon as possible.
2014-09-29
33 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Henry Yu
2014-09-29
33 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Henry Yu
2014-09-25
33 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-09-25
33 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2014-09-25
33 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2014-09-25
33 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2014-09-24
33 Cindy Morgan Created "Approve" ballot
2014-09-24
33 Cindy Morgan Closed "Approve" ballot
2014-09-22
33 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Network File System (NFS) Version …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Network File System (NFS) Version 4 Protocol) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Network File System (NFS) Version 4 Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Network File System (NFS) version 4 is a distributed file system
  protocol which builds on the heritage of NFS protocol version 2, RFC
  1094
, and version 3, RFC 1813.  Unlike earlier versions, the NFS
  version 4 protocol supports traditional file access while integrating
  support for file locking and the mount protocol.  In addition,
  support for strong security (and its negotiation), compound
  operations, client caching, and internationalization have been added.
  Of course, attention has been applied to making NFS version 4 operate
  well in an Internet environment.

  This document, together with the companion XDR description document,
  RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
  4 protocol.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1960/



2014-09-22
33 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-09-22
33 Amy Vezza Last call announcement was changed
2014-09-21
33 Martin Stiemerling Last call was requested
2014-09-21
33 Martin Stiemerling IESG state changed to Last Call Requested from AD Evaluation
2014-09-21
33 Martin Stiemerling Last call announcement was generated
2014-07-25
33 Martin Stiemerling IESG state changed to AD Evaluation from Publication Requested
2014-07-25
33 Spencer Shepler

Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-33.txt

Network …

Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-33.txt

Network File System (NFS) Version 4
External Data Representation Standard (XDR) Description
draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

These documents are candidates for Proposed Standard RFCs.

As the title suggests, these are bis documents for RFC3530
which itself is of Proposed Standard status.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary:

The Network File System (NFS) version 4 is a distributed
filesystem protocol which owes heritage to NFS protocol
version 2, RFC 1094, and version 3, RFC 1813.  Unlike earlier
versions, the NFS version 4 protocol supports traditional file
access while integrating support for file locking and the
mount protocol.  In addition, support for strong security (and
its negotiation), compound operations, client caching, and
internationalization have been added.  Of course, attention
has been applied to making NFS version 4 operate well in an
Internet environment.

This document, together with the companion XDR description
document, RFCNFSv4XDR, replaces RFC 3530 as the definition of
the NFS version 4 protocol.

This document includes updates that address: reported errata,
clarifications related to implementation experience, and
expanded text included from other sources.

Working Group Summary:

These documents have been very non-controversial given the
nature of the included errata and the fact that most of the
document updates were drawn from the NFSv4.1 definition.

Document Quality:

The quality of this document is very high.  There are multiple
implementations of the mandatory features of the protocol and
at least one implementation covering most (if not all)
optional features.  The reason for doing the update was to
raise the overall quality through expanded explanatory text
and correcting ambiguities.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a full review of the documents
and they are ready for publication.

This resubmission was done to clarify issues raised in the last IESG
review and were mainly related to I18N behaviors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is needed.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

Not applicable.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

No additional IPR has been filed for this "bis" work.
Original IPR for RFC3010 and RFC3530 (if present) still apply.

Specifically:
http://datatracker.ietf.org/ipr/1960/

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The quoted IPR was filed against the original RFC 3530 and is:
https://datatracker.ietf.org/ipr/721


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Full working group consensus.  No issues exist.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not applicable.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

No ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes, appropriate references align with appropriate
normative and informative use.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

All normative references are published with the exception of
the companion internet draft: "NFSv4 Version 0 XDR Description"

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

Not applicable.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes, RFC3530 will be obsolete.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

The IANA has been reviewed and been found to meet the
necessary requirements.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

IANA registries do not require expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.

2014-07-25
33 Spencer Shepler IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-07-25
33 Spencer Shepler IESG state changed to Publication Requested from AD is watching
2014-07-25
33 Spencer Shepler

Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-33.txt

Network …

Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-33.txt

Network File System (NFS) Version 4
External Data Representation Standard (XDR) Description
draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

These documents are candidates for Proposed Standard RFCs.

As the title suggests, these are bis documents for RFC3530
which itself is of Proposed Standard status.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary:

The Network File System (NFS) version 4 is a distributed
filesystem protocol which owes heritage to NFS protocol
version 2, RFC 1094, and version 3, RFC 1813.  Unlike earlier
versions, the NFS version 4 protocol supports traditional file
access while integrating support for file locking and the
mount protocol.  In addition, support for strong security (and
its negotiation), compound operations, client caching, and
internationalization have been added.  Of course, attention
has been applied to making NFS version 4 operate well in an
Internet environment.

This document, together with the companion XDR description
document, RFCNFSv4XDR, replaces RFC 3530 as the definition of
the NFS version 4 protocol.

This document includes updates that address: reported errata,
clarifications related to implementation experience, and
expanded text included from other sources.

Working Group Summary:

These documents have been very non-controversial given the
nature of the included errata and the fact that most of the
document updates were drawn from the NFSv4.1 definition.

Document Quality:

The quality of this document is very high.  There are multiple
implementations of the mandatory features of the protocol and
at least one implementation covering most (if not all)
optional features.  The reason for doing the update was to
raise the overall quality through expanded explanatory text
and correcting ambiguities.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a full review of the documents
and they are ready for publication.

This resubmission was done to clarify issues raised in the last IESG
review and were mainly related to I18N behaviors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is needed.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

Not applicable.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

No additional IPR has been filed for this "bis" work.
Original IPR for RFC3010 and RFC3530 (if present) still apply.

Specifically:
http://datatracker.ietf.org/ipr/1960/

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

The quoted IPR was filed against the original RFC 3530 and is:
https://datatracker.ietf.org/ipr/721


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Full working group consensus.  No issues exist.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not applicable.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

No ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes, appropriate references align with appropriate
normative and informative use.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

All normative references are published with the exception of
the companion internet draft: "NFSv4 Version 0 XDR Description"

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

Not applicable.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes, RFC3530 will be obsolete.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

The IANA has been reviewed and been found to meet the
necessary requirements.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

IANA registries do not require expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.

2014-07-25
33 Spencer Shepler Document shepherd changed to Spencer Shepler
2014-04-11
33 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-33.txt
2014-03-04
32 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-32.txt
2014-02-13
31 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-31.txt
2014-01-09
30 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-30.txt
2013-11-28
29 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-29.txt
2013-10-27
28 Martin Thomson Assignment of request for Telechat review by GENART to Martin Thomson was rejected
2013-10-19
28 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-28.txt
2013-09-11
27 Elwyn Davies Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Elwyn Davies.
2013-09-11
27 Elwyn Davies Request for Telechat review by GENART Completed: Ready. Reviewer: Elwyn Davies.
2013-08-16
27 Thomas Haynes IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-08-16
27 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-27.txt
2013-05-30
26 (System) Requested Telechat review by GENART
2013-05-30
26 Cindy Morgan State changed to AD is watching from IESG Evaluation
2013-05-30
26 Cindy Morgan [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel by Cindy Morgan
2013-05-30
26 Barry Leiba
[Ballot discuss]
I fully support Pete's DISCUSS points, and I have a couple of my own to add.  I'll say up front that given the …
[Ballot discuss]
I fully support Pete's DISCUSS points, and I have a couple of my own to add.  I'll say up front that given the state of the I18N situation in NFSv4, what came up in the discussion thread of Joel's DISCUSS seems like the best answer: make Section 12 a truly minimal thing, and write up a proper "Internationalization for NFSv4" document that takes the time and has the expertise to get it right.  (And, I'll add, that loops in the precis work.)

A couple of specific points to add, particularly if Section 12 stays as plump as it is:

- I don't think that punting *all* this (normalization, compatibility, confusability, and any other such issues) to the file system is acceptable.  I agree that we have to push canonicalization there.  It's true that if NFS uses different normalization or applies different confusability rules than the file system does (say, a file system allows ZERO-WIDTH-SPACE and NFS does not), then some files will not be accessible through NFS.  It's also true that if the file system doesn't handle these issues either (or doesn't cover a particular case), you'll have the same result.  Defining consistent behaviour does at least give consistent results, and I'm seriously worried about interoperability if it's done this way.  Also, ignoring some of these issues can open the system up to attacks that that target known weaknesses in file systems.  Consider a situation where lack of filtering of zero-width characters, for example, doesn't matter when the files are accessed locally, but making it accessible to NFS allows remote attacks that hadn't been possible before.

- I'm uncomfortable with a new document having no reference to the stringprep update work that's being done in the precis WG, even though that work is still in progress.  For example, you say that one problem with stringprep is that it locks you into Unicode 3.2... but moving us away from that lock-in is exactly the motivation for the precis work.  Also, as Pete mentions, the lack of communication with precis leaves a visible gap in I18N expertise.
2013-05-30
26 Barry Leiba
[Ballot comment]
Other specific comments on Section 12 and its subsections, which don't rise into the DISCUSS realm:

The intro to Section 12 has three …
[Ballot comment]
Other specific comments on Section 12 and its subsections, which don't rise into the DISCUSS realm:

The intro to Section 12 has three paragraphs that seem to amount to a long-winded way of saying that files will likely be accessed in multiple ways, and those ways have to coexist.  That's all fine, but (1) it really seems hard to pull that out of the verbiage (and I'm using that word in its proper sense of "*excessive* wordiness"), and (2) it and what comes after largely misses the main point: that we want, to the extent possible, to have filenames be interpreted consistently between NFS and other file access mechanisms -- despite the fact that we can't be perfect nor guarantee it.

That is, please focus on what you *want* to happen, and explain the challenges and potential failures... rather than focusing on the failures and not really making the goal clear.

I'll also note that there are a lot of English grammar issues in Section 12 and its subsections; it would be a good idea to go through and correct them, and not to rely on the RFC Editor to get the corrections right.

The paragraph in Section 12.1 seems to me to be entirely backward.  We're not using UTF-8 because it's convenient to deal with plain ASCII that way.  We're using UTF-8 for other reasons, and one nice side effect is that it's an identity mapping for ASCII filenames.  I also don't think it's useful to characterize anything as "[having] no internationalization requirements", because that will change as soon as the file system contains a file with a non-ASCII name.

The second and third bullets that distance you from stringprep do not make sense to me; can you explain them in clearer English?

An extended discussion of normalization is not really appropriate here.  Readers should be sent to proper references (I really think you need a reference to RFC 5198), with only a brief introduction.  For example, this:

  Some string pairs are thought as only differing in the way accents
  and other diacritics are encoded, as illustrated in the examples
  below.  Such string pairs are called "canonically equivalent".

...is too oversimplified, in an attempt to explain the situation too briefly.  You should make the real point, which is that there are multiple ways of representing the same character sequence, and it's desirable to have those multiple representations map to the same file as much as possible.  An example or two is appropriate (maybe one with combining accents, maybe another with compatibility equivalence), but beyond that, a detailed discussion of character normalization is well out of scope.

You cite RFC 5891 (IDNA 2008) only as a reference for NFKC; it should be clearer that it's a reference for all handling of domain name strings: strings that represent server and domain names are handled according to RFC 5891RFC 5198 is a better reference for general use of UTF-8 and normalization, canonicalization, and so on.  And where you cite 5891, consider also 5894.
2013-05-30
26 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2013-05-30
26 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-05-30
26 Sean Turner
[Ballot comment]
Pendant alert: If this document and the companion document both obsolete 3530 should there be some text in this document about how to …
[Ballot comment]
Pendant alert: If this document and the companion document both obsolete 3530 should there be some text in this document about how to refer to NFsv4?  That is I write a draft should I be pointing to just this document or both (or does it matter?).
2013-05-30
26 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-05-30
26 Jari Arkko
[Ballot discuss]
Thank you for writing this detailed specification. I cannot say that reading it is easy, but it is an important and necessary specification. …
[Ballot discuss]
Thank you for writing this detailed specification. I cannot say that reading it is easy, but it is an important and necessary specification. It is particularly important to revise specifications based on experience. So thank you for doing this hard work.

I do have a couple of issues that I would like to discuss before recommending the document be approved, however.

First, there seems to be advice in S6.3.1.2 that I don't know how I could implement. The advice seems even contradictory:

    Clients SHOULD NOT do their own access checks based on their
    interpretation the ACL, but rather use the OPEN and ACCESS operations
    to do access checks.  This allows the client to act on the results of
    having the server determine whether or not access should be granted
    based on its interpretation of the ACL.

    Clients must be aware of situations in which an object's ACL will
    define a certain access even though the server will not enforce it.
    In general, but especially in these situations, the client needs to
    do its part in the enforcement of access as defined by the ACL.  To
    do this, the client MAY send the appropriate ACCESS operation prior
    to servicing the request of the user or application in order to
    determine whether the user or application should be granted the
    access requested.  For examples in which the ACL may define accesses
    that the server doesn't enforce see Section 6.3.1.1.

Secondly, Martin Thomson raised a general issue that relates to the above, in his Gen-ART review. He said:

The document uses lowercase "must" and "may" a lot.  It's not
clear whether these are intended to be interpreted as normative
statements or not.  To my eyes, most of these are.  On the other hand,
there are places where 2119 language is used to effectively specify
implementation details that aren't observable at a protocol level.
If the document weren't so large, I'd suggest that the editors go through
and make sure that every 2119 keyword is in uppercase and then to
check each and every instance.

I agree with this, and would like to ask the authors if they have gone over the specification and ensured that keywords are used where they are needed. I'm asking in part because the first issue that I raised above depends a bit on the interpretation of the "must" in the second paragraph. To be exact, I am not pointing to other cases in the document that would be faulty, or even claiming that this one is. But I am asking a question if the authors feel a keyword check pass would be useful.

Third, I cannot find a response to Martin's review from the WG or the authors. I would like to ensure that you have seen the review and have either planned to take it into account, have already taken it into account, or after analysis, decided that no changes are needed. Please confirm.

Fourth, is there a response for Elwyn's review? See above.

Fifth, I would like the concept of inheritance explained at the conceptual level and up front. Elwyn made some comments on this, and I tried to understand the document from that perspective, but failed to find a full description. The WG probably has a model in mind, but for the rest of us this should be written up explicitly (and it may not need more than a paragraph). Elwyn wrote:

The intended functionality of inheritance is not explicitly documented.  To come to any sort of understanding of how inheritance is supposed to work you have to read through to the next to the last section (s6.4.3).  I have now read through the section two or three times and I have a model in my mind, but there is no text that would allow me to verify my understanding.  I *think* i have understood that (1) inheritance only applies when you initially create an object rather than being fed through to all 'inferior' objects in the tree if a superior object has a heritable ACE added; (2) inheritance only applies if you don't explicitly give any ACEs when the object is created, and (3) if you give a mode but no ACL then some complex combination of inherited ACL and mode is applied.  An upfront explanation of what is trying to be achieved would have helped a lot.  However, none of this explains what happens with either hard or symbolic links.  It is unclear to me whether inheritance of ACLs is applied when creating a hard or symbolic link to an existing object.

Sixth, are there inconsistencies in error codes? Elwyn reported these:

s13.1.4.2: Value of NFS4ERR_DQUOT is 19 here but 69 in table 8 (seems ok in -26)
s13,1.4.11: Value of NFS4ERR_NXIO is 5 here but 6 in table 8 (and value 5 is already used for NFS4ERR_IO).
s13.1.5.2: Value of NFS4ERR_BAD_STATEID is 10026 here but 10025 in table 8 (and value 10026 is already used for NFS4ERR_BAD_SEQID).

Seventh, in general the number of issues seems to indicate that maybe another checking pass through the document, for consistency and other reasons would be preferable. Even if it is painful for such a big document.
2013-05-30
26 Jari Arkko
[Ballot comment]
I am concerned about S12 and internationalization design, but since there are existing issues raised on those topics from Joel and Pete, I …
[Ballot comment]
I am concerned about S12 and internationalization design, but since there are existing issues raised on those topics from Joel and Pete, I will not discuss them further here.

Please see the reviews from Martin and Elwyn for many detailed issues. These probably should be addressed.
2013-05-30
26 Jari Arkko Ballot comment and discuss text updated for Jari Arkko
2013-05-30
26 Jari Arkko
[Ballot discuss]
Thank you for writing this detailed specification. I cannot say that reading it is easy, but it is an important and necessary specification. …
[Ballot discuss]
Thank you for writing this detailed specification. I cannot say that reading it is easy, but it is an important and necessary specification. It is particularly important to revise specifications based on experience. So thank you for doing this hard work.

I do have a couple of issues that I would like to discuss before recommending the document be approved, however.

First, there seems to be advice in S6.3.1.2 that I don't know how I could implement. The advice seems even contradictory:

    Clients SHOULD NOT do their own access checks based on their
    interpretation the ACL, but rather use the OPEN and ACCESS operations
    to do access checks.  This allows the client to act on the results of
    having the server determine whether or not access should be granted
    based on its interpretation of the ACL.

    Clients must be aware of situations in which an object's ACL will
    define a certain access even though the server will not enforce it.
    In general, but especially in these situations, the client needs to
    do its part in the enforcement of access as defined by the ACL.  To
    do this, the client MAY send the appropriate ACCESS operation prior
    to servicing the request of the user or application in order to
    determine whether the user or application should be granted the
    access requested.  For examples in which the ACL may define accesses
    that the server doesn't enforce see Section 6.3.1.1.

Secondly, Martin Thomson raised an issue that relates to the above, in his Gen-ART review. He said:

General: The document uses lowercase "must" and "may" a lot.  It's not
clear whether these are intended to be interpreted as normative
statements or not.  To my eyes, most of these are.  On the other hand,
there are places where 2119 language is used to effectively specify
implementation details that aren't observable at a protocol level.
If the document weren't so large, I'd suggest that the editors go through
and make sure that every 2119 keyword is in uppercase and then to
check each and every instance.

I agree with this, and would like to ask the authors if they have gone over the specification and ensured that keywords are used where they are needed. I'm asking in part because the first issue that I raised above depends a bit on the interpretation of the "must" in the second paragraph. To be exact, I am not pointing to other cases in the document that would be faulty, or even claiming that this one is. But I am asking a question if the authors feel a keyword check pass would be useful.
2013-05-30
26 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from No Record
2013-05-30
26 Stewart Bryant
[Ballot comment]
I have only reviewed this document for interactions with the routing system, and have no objection to it's publication.

One note that in …
[Ballot comment]
I have only reviewed this document for interactions with the routing system, and have no objection to it's publication.

One note that in relative terms is really a nit that surfaced in looking for "router" in the text:

"As long as the server maintains the last sequence number received and follows the methods described above, there are no risks of a Byzantine router re-sending old requests."

I don't think that you can make any statement about the behavior of Byzantine routers, since they are Byzantine. I think you mean to say something like:

"As long as the server maintains the last sequence number received and follows the methods described above, there is no risk to the NFS protocol as a result of the requests being re-sent by the routing system."  or perhaps "... re-sent by Byzantine routers in the routing system."

BTW I don't think it's fair to pin all the suspicion on the routers, Byzantine hypervisors are also pretty dangerous.
2013-05-30
26 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-05-30
26 Jari Arkko
[Ballot comment]
Isn't the following contradictory advice (from S6.3.1.2):

    Clients SHOULD NOT do their own access checks based on their
    interpretation …
[Ballot comment]
Isn't the following contradictory advice (from S6.3.1.2):

    Clients SHOULD NOT do their own access checks based on their
    interpretation the ACL, but rather use the OPEN and ACCESS operations
    to do access checks.  This allows the client to act on the results of
    having the server determine whether or not access should be granted
    based on its interpretation of the ACL.

    Clients must be aware of situations in which an object's ACL will
    define a certain access even though the server will not enforce it.
    In general, but especially in these situations, the client needs to
    do its part in the enforcement of access as defined by the ACL.  To
    do this, the client MAY send the appropriate ACCESS operation prior
    to servicing the request of the user or application in order to
    determine whether the user or application should be granted the
    access requested.  For examples in which the ACL may define accesses
    that the server doesn't enforce see Section 6.3.1.1.
2013-05-30
26 Jari Arkko Ballot comment text updated for Jari Arkko
2013-05-29
26 Pete Resnick
[Ballot discuss]
My localized comments about section 12 below notwithstanding, I think section 12 has some serious problems. I've tried to go through and pick …
[Ballot discuss]
My localized comments about section 12 below notwithstanding, I think section 12 has some serious problems. I've tried to go through and pick out individual problems, but at base it's hard for me to imagine how this could possibly be interoperable: There are strings (USHOULD and UVSHOULD) defined by the spec essentially as 'could be UTF-8, but might not be'. That's not a good start.

I'm also not convinced that this section got sufficient review. The draft did not get noticed by the PRECIS WG list, and the only person on the PRECIS list who reports having reviewed this section in detail is David Black. The apps-discuss list review was "less than thorough" (and I apologize for that). I think this section should be passed by the PRECIS list for further review. Our experience, post IDNA2003, is that the kinds of normalizations done for stringprep in IDNA was generally a mistake and we are working on ways for other protocols to avoid those mistakes.

Even though RFC 2277 says that we should go with UTF-8, if there is legacy of this sort, I would argue it is better to stick with the legacy and label it (just as we do with email) instead of "half" switching to UTF-8 and making implementers hope it all works. My understanding of the recent discussion on the mailing list is that neither the 3530 internationalization nor this one have actually been implemented properly. That's further indication, in my book, that this proposal is simply not going to be interoperable as it stands.

Some specific worries:

12.3:

  Where a UTF-8 string is used as a file name component, the file
  system implementation MUST NOT return NFS4ERR_BADNAME, simply due to
  a normalization mismatch.  In such cases the implementation SHOULD
  convert the string to its own preferred normalization mode before
  performing the operation.  As a result, a client cannot assume that a
  file created with a name it specifies will have that name when the
  directory is read.  It may have instead, the name converted to the
  file system's preferred normalization form.

A call silently succeeding without signal back to the client that the name has been changed seems destined for non-interoperability.

12.7.1.2:

  o  One alternate character repertoire is to represent file name
      components as strings of bytes with no protocol-defined encoding
      of multi-byte characters.

Unlabeled multi-byte characters are by their nature non-interoperable because of the lack of label. A client supporting UTF-8 names has no way to pass something to the application that can be reasonably manipulated by a user.

12.7.1.5.1:

  o  Implement normalization-sensitive handling without enforcing a
      normalization form constraint on file names.  This exposes the
      client to the possibility that two files can be created in the
      same directory which have different names which map to the same
      name when normalized.  This may be a significant issue when
      clients which use different normalization forms are used on the
      same file system, but this issue needs to be set against the
      difficulty of providing other sorts of normalization handling for
      some existing file systems.

Allowing servers to normalize at all worries me, but this option being available to the server is pretty scary from a client perspective. 12.7.1.5.2 pretty much expresses this problem.

I think we should discuss the best way forward.
2013-05-29
26 Pete Resnick
[Ballot comment]
Overall comment: I understand the desire to keep the document as one complete work. However, given that people have not yet implemented some …
[Ballot comment]
Overall comment: I understand the desire to keep the document as one complete work. However, given that people have not yet implemented some of the newer items, doing the corrections/clean up to the main body only and putting the entirely independent and new sections into separate documents first and then incorporating them at some point down the road would have kept the reviewing task much easier and would have made it easier to check implementations for interoperability down the road. For instance, I really see no reason that sections 7 and 12 couldn't have been pulled out into their own documents. That said, I suspect this ship has sailed.

Specifics smaller comments:

Somewhere there needs to be a reference to RFC 3629, UTF-8.

1.3.6:

  At OPEN, the server may provide the client
  either a OPEN_DELEGATE_READ or OPEN_DELEGATE_WRITE delegation for the
  file.  If the client is granted a OPEN_DELEGATE_READ delegation, it
  is assured that no other client has the ability to write to the file
  for the duration of the delegation.  If the client is granted a
  OPEN_DELEGATE_WRITE delegation, the client is assured that no other
  client has read or write access to the file.
 
Personally, I think the 3530 use of the informal words is better instead of OPEN_DELEGATE_READ/WRITE  in the introductory section. Those terms are not defined at this point.

2.1:

  | utf8_expected        | typedef utf8string utf8_expected;          |
  |                      | String expected to be UTF-8 but no        |
  |                      | validation                                |
  | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4;  |
  |                      | String SHOULD be sent UTF-8 and SHOULD be  |
  |                      | validated                                  |
  | utf8val_REQUIRED4    | typedef utf8string utf8val_REQUIRED4;      |
  |                      | String MUST be sent UTF-8 and MUST be      |
  |                      | validated                                  |
  | ascii_REQUIRED4      | typedef utf8string ascii_REQUIRED4;        |
  |                      | String MUST be sent as ASCII and thus is  |
  |                      | automatically UTF-8                        |

I'm not a big fan of the MUSTs and SHOULDs in this table because an implementer really won't know what to do with them until much later in the document. I think it would be better for all of these entries to simply have a reference to section 12 (or specifically 12.2.2) in each of the entries and leave the explanations for later. (It might be worth moving section 12 earlier in the document as well.)

5: In this section, you changed "mandatory attributes" to "REQUIRED attributes" and "recommended attributes" to "RECOMMENDED attributes", and uppercased a bunch of MUSTs, SHOULDs, and MAYs. I'm a bit worried you did this simply because one or more people said "Shouldn't those all be 2119 terms?" without any particular reason, and I'm worried that some of the new uses actually don't make sense. For example, you now have:

  A server should support as many of the RECOMMENDED attributes as
  possible but, by their definition, the server is not required to
  support all of them.

RECOMMENDED, in the 2119 sense, doesn't mean that. RECOMMENDED (like SHOULD) means, "There may be reasons to not do this, but you need to understand the full implications of doing so, because normally this is required for interoperability or to avoid harm." Later in 5.2 you say:

  A client MAY ask for any of these attributes to be
  returned by setting a bit in the GETATTR request but must handle the
  case where the server does not return them.  A client MAY ask for the
  set of attributes the server supports and SHOULD NOT request
  attributes the server does not support.
 
A client must handle the case where the server doesn't return REQUIRED attributes as well (i.e., a client can't just crash because a server is broken). It sounds to me like these RECOMMENDED attributes are really OPTIONAL in the 2119 sense. (They might be "recommended" in the informal sense, as I think you had it before, but 2119 terms muck up the issue.) Also, it seems to me that a client MUST NOT request attributes that the server does not support, not SHOULD NOT.

Also in 5.1 I see:

  A client may ask for any of these attributes
  to be returned by setting a bit in the GETATTR request, and the
  server must return their value.

The first "may" is lowercase, which is different than what you did in 5.2, and I suspect they should both be lowercase. But the "must return their value" sounds like it should be a "MUST return their value."

I'm not convinced this improved the document.

5.9:

  To avoid a representation that is tied to a particular
  underlying implementation at the client or server, the use of the
  UTF-8 string has been chosen.

I know this was in 3530, but I was really confused by this. I think you simply mean: "UTF-8 was chosen to avoid a representation that is tied to a particular implementation at the client or server."

  For example, the DNS domain name might be "lab.example.org", but the
  user names are defined in "example.org".

This is written ambiguously. I think you mean, "For example, the DNS domain name of the host running the NFS server might be...".

  Internationalization issues (for a general discussion of which see
  Section 12) make this impossible and the client needs to take note of
  the following situations:
 
I think you should simply refer to section 12 and not give the examples here: "Internationalization issues make this impossible under certain circumstances and the client needs to take note of these. See Section 12, especially sections 12.6 and 12.7.3 for a detailed discussion of these issues."

5.10: Put in a direct reference to 12.7.1.3.

7.2, third paragraph: s/whether it has moved or not/whether it has moved or simply never existed

12.1 (and subsections): This discussion should really point to external documents. RFC 6885 is an interesting choice. Another is draft-ietf-precis-framework. Even RFC 5890 could be helpful. But I think going through this discussion in this document is not useful.

12.2.1: Needs a reference to RFC 5890 or 5891 to define A-label and U-label.

12.3:

  e.g., names containing characters that have
  more than two octets on a file system that supports UCS-2 characters
  only

"Characters" do not have "two octets". There are better ways to say this.
2013-05-29
26 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2013-05-29
26 Richard Barnes
[Ballot comment]
I'm honestly baffled by the versioning scheme here.  Why are there two RFCs for NFSv4.0, plus one for NFSv4.1, plus this one (version …
[Ballot comment]
I'm honestly baffled by the versioning scheme here.  Why are there two RFCs for NFSv4.0, plus one for NFSv4.1, plus this one (version 4.0, published *after* version 4.1), plus NFSv4.2 as a working group item?  Is there some hidden linearity to this versioning, or is it a more complicated graph? 

In a related vein, a summary of changes relative to RFC 3530 would have been very helpful.
2013-05-29
26 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-05-29
26 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-05-28
26 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-05-28
26 Stephen Farrell
[Ballot discuss]

(The diff with 3530 wasn't very useful, so I just read as much
of the draft as I could and commented as if …
[Ballot discuss]

(The diff with 3530 wasn't very useful, so I just read as much
of the draft as I could and commented as if this was new text
describing a widely deployed protocol. Please feel free to argue
that anything that is in 3530 that doesn't really need to
change.)

(1) 3.2.1.1.1: RFC6649 is a BCP. I think you need to say that
implementations MUST follow its guidance, and not just that 6649
offers guidance. 

(2) 10.4.1, last para: "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;-)

(3) 15.33.5, 2nd last para: this says that if the server says
AUTH_NONE then the client can try any mechanism it likes, but
that then the client "SHOULD always be prepared" to fall back to
AUTH_NONE.  That seems broken. If the client wanted AUTH_foo for
some foo then why would AUTH_NONE be ok? Perhaps this ought say
that the client "MUST be able to handle a failure and SHOULD NOT
fall back to AUTH_NONE" instead?
2013-05-28
26 Stephen Farrell
[Ballot comment]

- general: Just wondering: Have we learned anything since 3530
(10 years ago) about DoS vectors related to NFS and mitigations
that is …
[Ballot comment]

- general: Just wondering: Have we learned anything since 3530
(10 years ago) about DoS vectors related to NFS and mitigations
that is worth a mention?

- general: Is there anything to be said on the
size/randomness/difficulty-to-guess for numbers that are used in
the protocol?  The ones where that might be useful that I
spotted were: file handles, Client IDs, Stateid, Verifier,
chaingid4 values, nfs_cookie4, nfs_locid4, verifier4, *.opaque
(e.g. nfs_client_id4.opaque).  I'm not asking that you add a
MUST or anything, but rather if it'd be good to say (for some of
these) that implementations SHOULD or ought ensure that values
have some good randomness, especially for cases where weaker or
no security is used in a deployment.

- What replaced LIPKEY/SPKM-3?

- Are seqid4 values supposed to start from a random value?

- 3.3.2: What does "minimal security triple" mean? It could mean
"a MTI triple" or "the weakest triple." I think you should
clarify.

- 4.2.4: Would it be worth mentioning that a server could
encrypt (for itself) the boot-time, slot and generation number?

- section 5: I would guess that some commonly used named
atrributes might have privacy considerations, e.g. geographic
location or timing information associated with the file.  (Like
image exif data for example.) Are those noted anywhere? Might be
worth just a mention that there can be privacy issues with
those.  Similarly, the standard owner and time_create attributes
might be privacy sensitve. (I'm not suggesting NFS do anything
about that, other than just note it.)

- 5.8.2.5: What's a privileged user in NFS or does this mean in
one of or both the client or server OS? While I get what you
mean, this seems somewhat vague.

- 6.1, ACE is used before its expanded, but since the expansion
is about 4 lines down, I forgive you:-)

- 6.2.1.4: I wondered what a server is supposed to do if an
AUDIT or ALARM event is supposed to happen but the (server
specific) logging or alarm actions doesn't work. Should the
server behave as if no AUDIT or ALARM event happened or should
it fail the operation or something else?

- 6.4: What does "much is made of" mean?

- 6.4: Why is there no reference for the withdrawn POSIX draft?
I think there ought be a reference there.

- 6.4.3: What does "implementors should standardize on..." mean?

- 7.4: Could I use an NFS4ERR_MOVED error to trick someone into
writing a file to my dodfy server? Put another way, do you need
the same level of security for handling this error as for the
server authentication for a write operation and is that security
mechanism supposed to be the same for all server
instances/replicas? Is that noted somewhere if there's a
vulnerability? I guess referrals could pose a similar threat.
(This isn't a discuss because I think you said earlier that the
same security has to be used but I wanted to check. I've also
probably garbled the terminology here, sorry;-)

- 7.9: Is there a happy-eyeballs concept for how to handle the
DNS name here? Should you refer to RFRC 6555 somewhere?

- 9.1.3.4: Am I right in thinking that guessing stateid field
values might allow me to misbehave? Its hard to know given how
complex this section is, but I have a suspicion that it might be
the case;-)

- section 17: I'm not clear how TLS (5246) is relevant here.

- 17: "should definitely use" isn't 2119 language - did you mean
"SHOULD use"?
2013-05-28
26 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-05-27
26 Spencer Dawkins
[Ballot comment]
I'm balloting "YES", but I'm providing a number of comments. Please don't be discouraged. I have 14 comments, for an average of one …
[Ballot comment]
I'm balloting "YES", but I'm providing a number of comments. Please don't be discouraged. I have 14 comments, for an average of one comment every 23 pages :-)

Several are nits. Several others are places where I didn't think the meaning was clear. I do have three questions.

None of these questions are blocking, but I'd appreciate it if you could look at 3.1, 5.6 and 9.14.

In this text:

1.2.  Inconsistencies of this Document with the companion document NFS
      Version 4 Protocol

  [I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains
  the definitions in XDR description language of the constructs used by
  the protocol.  Inside this document, several of the constructs are
  reproduced for purposes of explanation.  The reader is warned of the
  possibility of errors in the reproduced constructs outside of
  [I-D.ietf-nfsv4-rfc3530bis-dot-x].  For any part of the document that
  is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x],
  [I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative.

It took me a few reads to be somewhat confident that I understood what this text says - the first few times, I was reading it as "these are the inconsistencies between the two documents, but we're publishing both documents without fixing them". I think the section title was about half of my problem. I know that's not what you meant :-)

Am I reading it correctly, if I restate it this way?

1.2.  Definitions in the companion document NFS Version 4 Protocol are
      Authoritative

  [I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains
  the definitions in XDR description language of the constructs used by
  the protocol.  Inside this document, several of those constructs are
  reproduced for purposes of explanation.  The reader is warned of the
  possibility of errors in the reproduced constructs in this
  document.  For any part of this document that
  is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x],
  [I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative.

In this text:

1.3.3.  Filesystem Model

  The NFSv4 protocol does not require a separate protocol to provide
  for the initial mapping between path name and filehandle.  Instead of
  using the older MOUNT protocol for this mapping, the server provides
  a ROOT filehandle that represents the logical root or top of the
  filesystem tree provided by the server.  The server provides multiple
  filesystems by gluing them together with pseudo filesystems.  These
  pseudo filesystems provide for potential gaps in the path names
  between real filesystems.

Is "potential gaps" a term of art in the NFS community? It hasn't been defined in the spec, and "gap" only appears one other place in the spec, in Section 8.6. I can figure it out from the discussion in 8.6, but that's more than 100 pages into the spec.

In this text:

1.3.3.3.  Multi-server Namespace

  These attributes may be used together with the concept of absent file
  systems, which provide specifications for additional locations but no
  actual file system content.

Is "absent file system" a term of art in the NFS community? It's defined in section 7.2, but that's the 7th occurrence in the document, about 75 pages in.

In this text:

3.1.  Ports and Transports

  To date, all NFSv4 implementations are TCP based, i.e., there are
  none for SCTP nor UDP.  UDP by itself is not sufficient as a
  transport for NFSv4, neither is UDP in combination with some other
  mechanism (e.g., DCCP [RFC4340], NORM [RFC5740]).

"some other mechanism" wasn't clear to me. Could you help me understand what this sentence is saying about DCCP and NORM, and what the problems are if you tried to use (for example) NFSv4 over DCCP? I believe you, it's just unclear to me from the text what reason you have for saying this.

In this text:

5.6.  REQUIRED Attributes - List and Definition References

  o  Id: The number assigned to the attribute.  In the event of
      conflicts between the assigned number and
      [I-D.ietf-nfsv4-rfc3530bis-dot-x], the latter is likely
      authoritative, but should be resolved with Errata to this document
      and/or [I-D.ietf-nfsv4-rfc3530bis-dot-x].  See [ISEG_errata] for
      the Errata process.

I'm struggling with "is likely authoritative". I suspect that part of my struggle is that you're talking about how to resolve possible conflicts between this spec, another spec, and an IANA registry. You're sort of picking a designated tie-breaker, but the reader still has to try to figure out what the right answer should be. Given that you're telling people to be prepared to resolve conflicts using the errata process, do you need to say more than that?

In this text:

5.8.2.26.  Attribute 40: quota_used

  The value in bytes that represents the amount of disc space used by
  this file or directory and possibly a number of other similar files
  or directories, where the set of "similar" meets at least the
  criterion that allocating space to any file or directory in the set
  will reduce the "quota_avail_hard" of every other file or directory
  in the set.

I noted a "disc" among the "disk"s.

In this text:

7.7.  Effecting File System Transitions

  Transitions between file system instances, whether due to switching
  between replicas upon server unavailability or to server-initiated
  migration events, are best dealt with together.  This is so even
  though, for the server, pragmatic considerations will normally force
  different implementation strategies for planned and unplanned
  transitions. 

these two sentences would have made more sense to me if they used the same words to describe the same thing. If I'm getting the parallels right, one way to do that, would be

7.7.  Effecting File System Transitions

  Transitions between file system instances, whether due to switching
                                                            ^ unplanned
  between replicas upon server unavailability or to server-initiated
                                                    ^ planned
  migration events, are best dealt with together.  This is so even
  though, for the server, pragmatic considerations will normally force
  different implementation strategies for planned and unplanned
  transitions. 

In this text:

9.14.  Migration, Replication and State

  If a server replica or a server immigrating a filesystem agrees to,
  or is expected to, accept opaque values from the client that
  originated from another server, then it is a wise implementation
  practice for the servers to encode the "opaque" values in network
  byte order.  This way, servers acting as replicas or immigrating
  filesystems will be able to parse values like stateids, directory
  cookies, filehandles, etc. even if their native byte order is
  different from other servers cooperating in the replication and
  migration of the filesystem.

I'm having a difficult time connecting "it is a wise implementation practice" to "*will* be able to parse" - is it obvious to the replica server that the opaque values have been encoded in network byte order, so it's safe to parse values based on that? Or are these servers expected to be tightly coupled enough that each server knows whether other servers will encode opaque values "wisely"?

In this text:

10.2.1.  Delegation Recovery

  o  Upon reclaim, a client reporting resources assigned to it by an
      earlier server instance must be granted those resources.

Is "reporting" the right word? This may be a term of art, but I'm not seeing other places in the specification where clients "report" resources to servers.

Just a little further down:

  Situations in which there us a series of client and server restarts

I'm pretty sure this is "there is a series"

In this text:

12.4.1.  Processing of Principal Strings

  The string should be scanned for at-signs.  If there is more that one
  at-sign, the string is considered invalid.

I'm pretty sure this is "more than one"

In this text:

15.18.3.  RESULT

    nfs_space_limit4
              space_limit; /* Defines condition that
                              the client must check to
                              determine whether the
                              file needs to be flushed
                              to the server on close.  */

I'm no expert, but could I ask you to check whether this is the right description for this struct? nfs_space_limit4 looks like it's either a file size or a number of blocks, and I wasn't understanding how that was a "condition" or how the limit had anything to do with flushing a file to the server on close, so I'm wondering about a cut-and-paste error.

In this text:

15.33.5.  IMPLEMENTATION

  Note that a server MAY use the AUTH_NONE flavor to signify that the
  client is allowed to attempt to use authentication flavors that are
  not explicitly listed in the SECINFO results.  Instead of using a
  listed flavor, the client might then, for instance opt to use an
  otherwise unlisted RPCSEC_GSS mechanism instead of AUTH_NONE.  It may
  wish to do so in order to meet an application requirement for data
  integrity or privacy.  In choosing to use an unlisted flavor, the
  client SHOULD always be prepared to handle a failure by falling back
  to using AUTH_NONE or another listed flavor.  It MUST NOT assume that
  identity mapping is supported, and should be prepared for the fact
  that its identity is squashed.
                        ^^^^^^^^

Is "squashed" a term of art in the NFS community? It's not defined, it only appears once in the document, and it wasn't obvious to me what reference I should be checking to understand the sentence.

In this text:

18.1.  Named Attribute Definitions

  Under the NFSv4 specification, the name of a named attribute can in
  theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
  clients and servers will be unable to a handle string that long.

Something is garbled here. I'm guessing "will be unable to handle a string that long", but that's guessing ...
2013-05-27
26 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2013-05-27
26 Joel Jaeggli
[Ballot discuss]
This is a discuss:discuss, I can probably clear without major objections.

First off I'd like to thank Elwin Davies alot for the second …
[Ballot discuss]
This is a discuss:discuss, I can probably clear without major objections.

First off I'd like to thank Elwin Davies alot for the second genart review against draft 25.

http://www.ietf.org/mail-archive/web/gen-art/current/msg08538.html

I'd like to see the authors response to those points. if they have already that's great, just point me to it.

In particular:


s12:  It seems the client has to play '20 questions' with the server to find out how it treats internationalized component names.  Some of it seems little better than guesswork.  I was wondering why some of the server choices are not described using attributes so that the client doesn't have to thrash around in the dark.  Also there doesn't seem to be any requirement for a filesystem to be treated identically after migration. As far as I can see the client can't really rely on the internationalisation treatment not changing after migration.

the update to section 18 in (26) I think is good. likewise I think I've made my peace with 3.2.1
2013-05-27
26 Joel Jaeggli
[Ballot comment]
Registering a comment since I've been thinking about this for a while, without yet registering a position.

two points...

Addressed -- * I …
[Ballot comment]
Registering a comment since I've been thinking about this for a while, without yet registering a position.

two points...

Addressed -- * I dont' have a review handy for section 12 by an internationalization domain expert, that's one of the bigger pieces that's new for 3530bis if someone has a pointer that would be great.

Addressed -- * having looked at 3.2.1.1 a couple times, I'm convinced that this is probably an improvement over mandatory to implement algorithms that are bad, but since there are no longer requirements other than that you're expected to follow kerberos standard that there not longer a must implemented minimum set for interoperability. I'm not convinced that's a problem.
2013-05-27
26 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to Discuss from No Record
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2013-05-23
26 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2013-05-23
26 Joel Jaeggli
[Ballot comment]
Registering a comment since I've been thinking about this for a while, without yet registering a position.

two points...

* I dont' have …
[Ballot comment]
Registering a comment since I've been thinking about this for a while, without yet registering a position.

two points...

* I dont' have a review handy for section 12 by an internationalization domain expert, that's one of the bigger pieces that's new for 3530bis if someone has a pointer that would be great.

* having looked at 3.2.1.1 a couple times, I'm convinced that this is probably an improvement over mandatory to implement algorithms that are bad, but since there are no longer requirements other than that you're expected to follow kerberos standard that there not longer a must implemented minimum set for interoperability. I'm not convinced that's a problem.
2013-05-23
26 Joel Jaeggli Ballot comment text updated for Joel Jaeggli
2013-05-15
26 Martin Stiemerling State changed to IESG Evaluation from IESG Evaluation::AD Followup
2013-05-08
26 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-05-08
26 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-26.txt
2013-04-26
25 Martin Stiemerling State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-04-19
25 Martin Thomson Request for Last Call review by GENART Completed: Ready. Reviewer: Martin Thomson.
2013-04-18
25 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-04-18
25 (System) IANA Review state changed to IANA - Review Needed from IANA - Not OK
2013-04-18
25 Martin Stiemerling Removed telechat returning item indication
2013-04-18
25 Martin Stiemerling Telechat date has been changed to 2013-05-30 from 2013-04-25
2013-04-18
25 Martin Stiemerling State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-04-18
25 Martin Stiemerling Ballot has been issued
2013-04-18
25 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2013-04-18
25 Martin Stiemerling Created "Approve" ballot
2013-04-18
25 Martin Stiemerling Ballot writeup was changed
2013-04-16
25 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-04-13
25 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2013-04-13
25 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530bis-25.txt.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530bis-25.txt.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, the actions requested in the IANA considerations section have already been completed.

The IANA Considerations section of this document requests the creation of a new registry called the "NFSv4 Named Attribute Definitions Registry". This registry appears to already have been created by RFC5661 on 2009-01-16 and is located at:

http://www.iana.org/assignments/nfsv4-named-attributes/nfsv4-named-attributes.xml

IANA Question --> Does the existing registry meet the requirements set forth in Section 18 of the current document? Should the references be updated to [ RFC-to-be ]?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-04-11
25 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yoav Nir.
2013-03-26
25 Martin Stiemerling Placed on agenda for telechat - 2013-04-25
2013-03-21
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yoav Nir
2013-03-21
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yoav Nir
2013-03-21
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2013-03-21
25 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2013-03-19
25 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-03-19
25 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Network File System (NFS) Version 4 …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Network File System (NFS) Version 4 Protocol) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Network File System (NFS) Version 4 Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Network File System (NFS) version 4 is a distributed filesystem
  protocol which owes heritage to NFS protocol version 2, RFC 1094, and
  version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
  protocol supports traditional file access while integrating support
  for file locking and the mount protocol.  In addition, support for
  strong security (and its negotiation), compound operations, client
  caching, and internationalization have been added.  Of course,
  attention has been applied to making NFS version 4 operate well in an
  Internet environment.

  This document, together with the companion XDR description document,
  RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
  4 protocol.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1960/



2013-03-19
25 Amy Vezza State changed to In Last Call from Last Call Requested
2013-03-19
25 Martin Stiemerling Last call was requested
2013-03-19
25 Martin Stiemerling Ballot approval text was generated
2013-03-19
25 Martin Stiemerling Ballot writeup was generated
2013-03-19
25 Martin Stiemerling State changed to Last Call Requested from AD Evaluation
2013-03-19
25 Martin Stiemerling Last call announcement was changed
2013-03-19
25 Martin Stiemerling Last call announcement was generated
2013-03-01
25 Martin Stiemerling will start WGLC right after the IETF-86 meeting.
2013-03-01
25 Martin Stiemerling State changed to AD Evaluation from AD Evaluation::External Party
2013-02-25
25 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-25.txt
2013-02-12
24 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-24.txt
2013-02-12
23 Martin Stiemerling State changed to AD Evaluation::External Party from AD Evaluation::AD Followup
2013-02-12
(System) Posted related IPR disclosure: Martin Stiemerling's Statement about IPR related to draft-ietf-nfsv4-rfc3530bis-23 belonging to IBM
2013-02-01
23 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-02-01
23 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-23.txt
2013-02-01
22 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup
2013-01-29
22 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-01-29
22 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-22.txt
2013-01-20
21 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from AD Evaluation
2012-11-10
21 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-21.txt
2012-10-17
20 Martin Stiemerling State changed to AD Evaluation from Publication Requested
2012-10-16
20 Amy Vezza Note added 'Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)'
2012-10-16
20 Amy Vezza State changed to Publication Requested from AD is watching
2012-10-16
20 Amy Vezza
Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-20.txt

Network …
Working Group: NFSv4
Area Director: Martin Stiemerling
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-20.txt

Network File System (NFS) Version 4
External Data Representation Standard (XDR) Description
draft-ietf-nfsv4-rfc3530bis-dot-x-12.txt


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

These documents are candidates for Proposed Standard RFCs.

As the title suggests, these are bis documents for RFC3530
which itself is of Proposed Standard status.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


Technical Summary:

The Network File System (NFS) version 4 is a distributed
filesystem protocol which owes heritage to NFS protocol
version 2, RFC 1094, and version 3, RFC 1813.  Unlike earlier
versions, the NFS version 4 protocol supports traditional file
access while integrating support for file locking and the
mount protocol.  In addition, support for strong security (and
its negotiation), compound operations, client caching, and
internationalization have been added.  Of course, attention
has been applied to making NFS version 4 operate well in an
Internet environment.

This document, together with the companion XDR description
document, RFCNFSv4XDR, replaces RFC 3530 as the definition of
the NFS version 4 protocol.

This document includes updates that address: reported errata,
clarifications related to implementation experience, and
expanded text included from other sources.

Working Group Summary:

These documents have been very non-controversial given the
nature of the included errata and the fact that most of the
document updates were drawn from the NFSv4.1 definition.

Document Quality:

The quality of this document is very high.  There are multiple
implementations of the mandatory features of the protocol and
at least one implementation covering most (if not all)
optional features.  The reason for doing the update was to
raise the overall quality through expanded explanatory text
and correcting ambiguities.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a full review of the documents
and they are ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review is needed.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

Not applicable.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

No additional IPR has been filed for this "bis" work.
Original IPR for RFC3010 and RFC3530 (if present) still apply.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

See (7).


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Full working group consensus.  No issues exist.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not applicable.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

No ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes, appropriate references align with appropriate
normative and informative use.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

All normative references are published with the exception of
the companion internet draft: "NFSv4 Version 0 XDR Description"

(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

Not applicable.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes, RFC3530 will be obsolete.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

The IANA has been reviewed and been found to meet the
necessary requirements.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

IANA registries do not require expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.

2012-09-25
20 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-20.txt
2012-09-04
19 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-19.txt
2012-05-08
18 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-18.txt
2012-03-29
17 Martin Stiemerling Intended Status changed to Proposed Standard
2012-03-29
17 Martin Stiemerling IESG process started in state AD is watching
2012-03-12
17 Thomas Haynes New version available: draft-ietf-nfsv4-rfc3530bis-17.txt
2011-10-30
16 (System) New version available: draft-ietf-nfsv4-rfc3530bis-16.txt
2011-09-07
15 (System) New version available: draft-ietf-nfsv4-rfc3530bis-15.txt
2011-09-02
14 (System) New version available: draft-ietf-nfsv4-rfc3530bis-14.txt
2011-08-17
13 (System) New version available: draft-ietf-nfsv4-rfc3530bis-13.txt
2011-04-08
12 (System) New version available: draft-ietf-nfsv4-rfc3530bis-12.txt
2011-04-04
11 (System) New version available: draft-ietf-nfsv4-rfc3530bis-11.txt
2011-03-14
10 (System) New version available: draft-ietf-nfsv4-rfc3530bis-10.txt
2011-03-13
09 (System) New version available: draft-ietf-nfsv4-rfc3530bis-09.txt
2011-03-04
08 (System) New version available: draft-ietf-nfsv4-rfc3530bis-08.txt
2011-02-28
07 (System) New version available: draft-ietf-nfsv4-rfc3530bis-07.txt
2011-02-16
06 (System) New version available: draft-ietf-nfsv4-rfc3530bis-06.txt
2010-10-21
05 (System) New version available: draft-ietf-nfsv4-rfc3530bis-05.txt
2010-07-09
04 (System) New version available: draft-ietf-nfsv4-rfc3530bis-04.txt
2010-03-05
03 (System) New version available: draft-ietf-nfsv4-rfc3530bis-03.txt
2010-03-05
02 (System) New version available: draft-ietf-nfsv4-rfc3530bis-02.txt
2010-03-05
01 (System) New version available: draft-ietf-nfsv4-rfc3530bis-01.txt
2009-10-04
16 (System) Document has expired
2009-04-03
00 (System) New version available: draft-ietf-nfsv4-rfc3530bis-00.txt