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

Tom Talpey <tom@talpey.com> Thu, 25 May 2017 22:41 UTC

Return-Path: <tom@talpey.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C74129BBD for <nfsv4@ietfa.amsl.com>; Thu, 25 May 2017 15:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.52
X-Spam-Level:
X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoxAoo0GK64J for <nfsv4@ietfa.amsl.com>; Thu, 25 May 2017 15:40:57 -0700 (PDT)
Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B44127B52 for <nfsv4@ietf.org>; Thu, 25 May 2017 15:40:57 -0700 (PDT)
Received: from [10.137.198.25] ([131.107.147.196]) by :SMTPAUTH: with SMTP id E1QedC8pzqTuIE1QfdErrA; Thu, 25 May 2017 15:40:25 -0700
To: Joe Touch <touch@isi.edu>, David Noveck <davenoveck@gmail.com>
Cc: art@ietf.org, Matthew Miller <linuxwolf+ietf@outer-planes.net>, ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" <nfsv4@ietf.org>
References: <149462145126.13443.7366912235626631179@ietfa.amsl.com> <d64909ad-b71a-a932-606b-8b974cf68140@isi.edu> <CADaq8jdWgRSqGVt0UBf3sqzp3ivYAW36y1JuNg43HGp5WboKrg@mail.gmail.com> <d10f43d7-d136-d9b9-fcfb-dc78a52e1355@isi.edu>
From: Tom Talpey <tom@talpey.com>
Message-ID: <c3ef20a9-f96e-9b26-330a-138036943db8@talpey.com>
Date: Thu, 25 May 2017 15:40:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <d10f43d7-d136-d9b9-fcfb-dc78a52e1355@isi.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfFgqD0Unhil59tIg+xyBVNyA8nfVrdu/pl43zl5VLTnxYXaYTJQ5vHzUmi/HSQwbdd0rzNDK2bJmbO+7bbwkA0NNAlSuQfLhaXOfqpJaEXi/WZPeCKIC koow8ZkNj5G7Hr749yuPzogX6ls5jrMAKQEpql0mnhwcQJf8EwDntULSfGCDVdNM2hWxcikf/PITQTwHZe9V2JK3g8vlECQjgc67gAtQbrZVjzppXkYMDui7 J9frzljPjEUofnPJL1PTsed84xcdYWNSwjK2fI6sWM9ykvymW6fY+IZBAFVfxl5wmrJvqoWefOezkw9P3Gdi868HURw00/tIwYgMiAq04CB1rXJQIdLHt3B9 1jVHu9LdmBOQPiFik+8MoKU3cqff8Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-zlmst4O5Q80EofaL8-MrGpmruk>
Subject: Re: [nfsv4] [art] Artart last call review of draft-ietf-nfsv4-versioning-09
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 22:41:00 -0000

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.

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
>