[nfsv4] Re: Changes in the rfc5661bis effort

Christoph Hellwig <hch@lst.de> Fri, 07 June 2024 15:15 UTC

Return-Path: <hch@lst.de>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 58A9AC14CF1E; Fri, 7 Jun 2024 08:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id O_elFb-gsmZq; Fri, 7 Jun 2024 08:15:55 -0700 (PDT)
Received: from verein.lst.de (verein.lst.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DCCC14F61A; Fri, 7 Jun 2024 08:15:53 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407) id 4BF5568BEB; Fri, 7 Jun 2024 17:15:48 +0200 (CEST)
Date: Fri, 07 Jun 2024 17:15:47 +0200
From: Christoph Hellwig <hch@lst.de>
To: Thomas Haynes <loghyr@gmail.com>
Message-ID: <20240607151546.GA8904@lst.de>
References: <CADaq8jd4MX3Re8dkyTE0JCBqT3yjyP5SjaP0pFqBqnZ-=QgDxg@mail.gmail.com> <D7DBCD68-E784-4C62-AE08-21E587EB4590@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D7DBCD68-E784-4C62-AE08-21E587EB4590@gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
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/3nYjEVUAXsrA9MunS98WHI3iTG0>
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 Sun, May 19, 2024 at 02:59:38PM -0700, Thomas Haynes wrote:
> If you are adding new OPTIONAL attributes/operations for NFSv4.1, please make sure that they do not conflict with definitions for NFSv4.2.
> 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.

Adding new attributes in a 4.1bis document feels rather odd.  Is that
really a good idea?