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

Hi, Tom,

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