[nfsv4] Re: Changes in the rfc5661bis effort

Christoph Hellwig <hch@lst.de> Mon, 17 June 2024 05:49 UTC

Return-Path: <hch@lst.de>
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 4358EC14F6AB; Sun, 16 Jun 2024 22:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYf8mc9gnMM5; Sun, 16 Jun 2024 22:49:12 -0700 (PDT)
Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF99C14F6A1; Sun, 16 Jun 2024 22:49:09 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407) id 386A668B05; Mon, 17 Jun 2024 07:49:06 +0200 (CEST)
Date: Mon, 17 Jun 2024 07:49:06 +0200
From: Christoph Hellwig <hch@lst.de>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20240617054906.GA17051@lst.de>
References: <CADaq8jd4MX3Re8dkyTE0JCBqT3yjyP5SjaP0pFqBqnZ-=QgDxg@mail.gmail.com> <D7DBCD68-E784-4C62-AE08-21E587EB4590@gmail.com> <CADaq8jdYqqTjVxRFWeuPb7d7rZKWDo+EvO4+JDFaz+uvFZMtgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jdYqqTjVxRFWeuPb7d7rZKWDo+EvO4+JDFaz+uvFZMtgA@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Message-ID-Hash: SBIJPO6BH7ZEWPHE5H7LQR2E7VKNCEIV
X-Message-ID-Hash: SBIJPO6BH7ZEWPHE5H7LQR2E7VKNCEIV
X-MailFrom: hch@lst.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: NFSv4 <nfsv4@ietf.org>, nfsv4-chairs <nfsv4-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: Changes in the rfc5661bis effort
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/5gYFu5PGxuvdoXOZ4NTHNC2I684>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>

On Fri, Jun 07, 2024 at 04:11:32PM -0400, David Noveck wrote:
> > I.e., do not assign FATTR4_NEW_ATTRIBUTE to be 77, instead first assign it
> > in the NFSv4.2 block range and then use that same number on NFSv4.1.
> >
> 
> I don't see how we could make the definition of 4.1 depend on 4.2.   I just
> need to find an unsigned value and then ask those proposing 4.2 attributes
> not to conflict with that.

I don't think that is what Tom is proposing.  Just to coordinate the
assignments.  Btw, why aren't attributes managed by an IANA registry?

That being said I find the idea of adding any new code points to a 4.1bis
document very counterproductive if we have 4.2 which is basically defined
as a set of compatible extensions to 4.1 and thus THE extension path
for 4.1.  If implementors can't live with upgrading the supported version
number we might have to revisit the approach to version numbers. 

Just to take an example nvme allows discoverable features to be
implemented on older base versions, making the exact version number
largely irrelevant.