Subject: Artart last call review of draft-ietf-nfsv4-versioning-09

From: Matthew Miller <[email-masked]>
Date: Fri, 12 May 2017 13:37:31 -0700

Reviewer: Matthew Miller
Review result: Ready with Issues

Document: draft-ietf-nfsv4-versioning-09
IETF LC End Date: 2017-05-12
IESG Telechat date: 2017-05-25

This document provides guidance for dealing with extensions
and versioning in NFSv4, including how and when to update
minor versions.

This document is mostly ready.  Some of the grammatical choices
make for a more difficult read; the most obvious ones to me are
nits below.

Major issues:

NONE

Minor issues:

NONE

Nits/editorial comments:

* For the bullet points in this document, some end in periods and
some don't.  I recommend the authors choose one and update
accordingly.

* In section 1. "Introduction", the last sentence is very clumsy.
The Gen-ART review already points this out, and provides what I think
is a good suggested change.

* In section 4.4.2 "Establishing Interoperability", the phrase
"client
would uses" should be "client uses"

* In section 5.2 "Behavioral Changes", the following sentence is
difficult parse:

   """
   One class of behavioral change involves changes in the set of
errors
   to be returned in the event of various errors.
   """

I think the following has the same meaning:

   """
   One class of behavior change involves changes in the set of errors
   to be returned when various failure conditions occur.
   """

That's not tremendously better, but I think it's a little easier to
wrap one's mind around.

* In the title for Section 9.3 "XDR Corrections to REQUIRED
features",
"Features" should be capitalized.

* In Section 9.3 "XDR Corrections to REQUIRED features", the word
"correct" should be "corrected" in the sentence "Such clients would
only
be capable of interoperating with servers that supported the correct
version."

---

From: David Noveck <[email-masked]>
Date: Sat, 13 May 2017 09:26:45 -0400

Thanks for the review.

> some don't.  I recommend the authors choose one and update

Will update those without periods.

> is a good suggested change.

It has been updated.

> would uses" should be "client uses"

Will fix.

> * In section 5.2 "Behavioral Changes", the following sentence is

...

> That's not tremendously better, but I think it's a little easier to

Will change.

> "Features" should be capitalized.

Will fix.

> be capable of interoperating with servers that supported the correct

Will fix.

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 11:51:13 -0700

Hi, all,

I'd like to add one point.

This doc gives guidance on creating minor versions, but never addresses
major versions.

IMO, past variants of NFS have not handled major version changes
appropriately. Each one has been assigned a new port number. This is no
longer recommended practice (see RFC7605, Sec 7.5).

Is this issue addressed in another document?

AFAICT, if (when) NFSv5 is developed, it seems to appear to need another
port number. If that's the case (and I sincerely hope it isn't), it MUST
be the last one assigned to this service.

Joe

---

From: David Noveck <[email-masked]>
Date: Thu, 25 May 2017 15:33:07 -0400

> This doc gives guidance on creating minor versions, but never addresses

I think we had enough to do addressing minor versions and didn't want to
speculate about a possible v5.  after all, we're the nfsv4 working group
and not the nfsvn working group.

> longer recommended practice (see RFC7605, Sec 7.5).

Makes sense.

> Is this issue addressed in another document?

I don't think so.

> port number.

I don't see why it would.  If there is another Rpc version of the NFS
program,
I don't see why the appropriate negotiation could be defined.  I think
doing\
that would be up to those defining nfsv5.

> If that's the case (and I sincerely hope it isn't), it MUST

I don't think "MUST" is appropriate in this case but I would say that
assigning
another port would be a DAMN SHAME.

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 15:17:43 -0700

Hi, David,

Thanks for the response, and agreed throughout.

Joe

On 5/25/2017 12:33 PM, David Noveck wrote:
> On Thu, May 25, 2017 at 2:51 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi, all,
>

---

From: Tom Talpey <[email-masked]>
Date: Thu, 25 May 2017 15:40:26 -0700

>> > longer recommended practice (see RFC7605, Sec 7.5).

I feel compelled to chime in on this one. NFS has always had a single
assigned port, 2049, which has not changed with major version. In the
NFSv2 days, it was self-assigned by Sun Microsystems, later, in NFSv3,
it was registered with IANA. For both versions, the RPC portmapper was
used by clients to resolve the server port.

In NFSv4, the portmapper is not used, but the port number assignment
did not change. This remains true for all NFSv4 minor versions.

There is one exception - NFS over RDMA received a new port assignment
from IANA, 20049, because the NFSv2 and NFSv3 protocols could not
negotiate the NFS/RDMA listener using legacy portmapping. While the
NFSv4.1+ versions provide a mechanism for that, the static 20049
assignment is still recommended.

Bottom line, the NFS ports are stable and registered, and there is no
need to allocate more, at least as foreseen at this time.

Tom.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 26 May 2017 09:56:09 -0400

Hi, Tom,

> need to allocate more, at least as foreseen at this time.

Thanks for the history on port allocations, which I lacked, and I'm glad
that your answer is the right answer :-)

>>> On Thu, May 25, 2017 at 2:51 PM, Joe Touch <[email-masked] <mailto:
>>> [email-masked]>> wrote:
>>>
>>>     Hi, all,
>>>