Re: [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: art@ietfa.amsl.com
Delivered-To: art@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/art/IHj8dFTA458vfndSJs1XDkdrCTw>
Subject: Re: [art] Artart last call review of draft-ietf-nfsv4-versioning-09
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-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 > >
- [art] Artart last call review of draft-ietf-nfsv4… Matthew Miller
- Re: [art] Artart last call review of draft-ietf-n… David Noveck
- Re: [art] Artart last call review of draft-ietf-n… Joe Touch
- Re: [art] Artart last call review of draft-ietf-n… David Noveck
- Re: [art] Artart last call review of draft-ietf-n… Joe Touch
- Re: [art] [nfsv4] Artart last call review of draf… Tom Talpey
- Re: [art] [nfsv4] Artart last call review of draf… Spencer Dawkins at IETF