[art] Artart last call review of draft-ietf-nfsv4-versioning-09

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[art] Artart last call review of draft-ietf-nfsv4-versioning-09

Matthew Miller
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."


_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|

Re: [art] Artart last call review of draft-ietf-nfsv4-versioning-09

Joe Touch
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

_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art
Reply | Threaded
Open this post in threaded view
|

Re: [art] [nfsv4] Artart last call review of draft-ietf-nfsv4-versioning-09

Spencer Dawkins at IETF
Hi, Tom,

On Thu, May 25, 2017 at 6:40 PM, Tom Talpey <[hidden email]> wrote:
On 5/25/2017 3:17 PM, Joe Touch wrote:
Hi, David,

Thanks for the response, and agreed throughout.

Joe


On 5/25/2017 12:33 PM, David Noveck wrote:
> This doc gives guidance on creating minor versions, but never addresses
> major versions.

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.


> 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).

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.

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


Makes sense.

> Is this issue addressed in another document?

I don't think so.

> AFAICT, if (when) NFSv5 is developed, it seems to appear to need another
> 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
> be the last one assigned to this service.

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

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

    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





_______________________________________________
nfsv4 mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/nfsv4



_______________________________________________
art mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/art