[nfsv4] Re: Changes in the rfc5661bis effort

Christoph Hellwig <hch@lst.de> Fri, 07 June 2024 15:21 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 7590AC14CF09; Fri, 7 Jun 2024 08:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q560pYyOMuI1; Fri, 7 Jun 2024 08:21:35 -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 2A37AC14F61A; Fri, 7 Jun 2024 08:21:34 -0700 (PDT)
Received: by verein.lst.de (Postfix, from userid 2407) id D553368BEB; Fri, 7 Jun 2024 17:21:31 +0200 (CEST)
Date: Fri, 07 Jun 2024 17:21:31 +0200
From: Christoph Hellwig <hch@lst.de>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20240607152131.GB8904@lst.de>
References: <CADaq8jd4MX3Re8dkyTE0JCBqT3yjyP5SjaP0pFqBqnZ-=QgDxg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jd4MX3Re8dkyTE0JCBqT3yjyP5SjaP0pFqBqnZ-=QgDxg@mail.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/29Ppxx8dKzR4_sg0iHycWKLJxLY>
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 10:10:25AM -0400, David Noveck wrote:
>    - The drafting for most of these (eight out of ten) is done or will be
>    done when rfc5661bis-05 is out in a about a week.
>    - The option of creating a new *OPTIONAL *attribute for ACL feature
>    would let us close out the acl work and complete the bis effort much
>    earlier than we had been expecting.   It  requires we decide to limit our
>    interoperability-enablement efforts in the v4.1 context to the UNIX ACLs
>    subset or something close to it.  I am looking to make that scope decision
>    at IETF120.

If you have incompatible ACL changes, or new optional attributes these
absolutely should not be in a 4.1 document.

> BTW, diffs with RFC881 are not helpful.


>    3:   Security for all minor versions is being thoroughly respecified
>         in the NFSv4-wide document [I-D.dnoveck-nfsv4-security].  In
>         this discussion, issues related to authorization semantics and
>         to ACLs are being dealt with separately.

We had this discussion at a few face to face meetings, where I voiced
my opinion, but let me restate it here:

- trying to define new features for both 4.0 and 4.1 in the same document
  is a losing proposition.  No one really cares about 4.0, but if you
  find people that actually care about it let them do a separate
  document that makes life for 4.1 implementers harder (and 4.1
  implementers includes 4.2 as that is just a small set of optional