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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Tom,

On Thu, May 25, 2017 at 6:40 PM, Tom Talpey <tom@xxxxxxxxxx> 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 <touch@xxxxxxx <mailto:touch@xxxxxxx>> 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
nfsv4@xxxxxxxx
https://www.ietf.org/mailman/listinfo/nfsv4



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]