IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Thu, 25 May 2017 22:18 UTC

Return-Path: <touch@isi.edu>
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 31DF9127B52; Thu, 25 May 2017 15:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 YEQN_6obsKYx; Thu, 25 May 2017 15:18:15 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F31129B21; Thu, 25 May 2017 15:18:15 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMHhQw019774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:17:57 -0700 (PDT)
To: David Noveck <davenoveck@gmail.com>
Cc: Matthew Miller <linuxwolf+ietf@outer-planes.net>, art@ietf.org, 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>
From: Joe Touch <touch@isi.edu>
Message-ID: <d10f43d7-d136-d9b9-fcfb-dc78a52e1355@isi.edu>
Date: Thu, 25 May 2017 15:17:43 -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: <CADaq8jdWgRSqGVt0UBf3sqzp3ivYAW36y1JuNg43HGp5WboKrg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------AC254B0531D11EB8A41583A9"
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/tGGNFEwnjS6PDqap8Wf4ALysWfI>
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:18:17 -0000

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

v2.23.0 | Report a Bug | By Email