[nfsv4] Possibility of adding additional REQUIRED attributes

David Noveck <davenoveck@gmail.com> Mon, 25 March 2024 17:00 UTC

Return-Path: <davenoveck@gmail.com>
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 EB223C151096 for <nfsv4@ietfa.amsl.com>; Mon, 25 Mar 2024 10:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 d53fq-FKXmGW for <nfsv4@ietfa.amsl.com>; Mon, 25 Mar 2024 10:00:20 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0503DC151095 for <nfsv4@ietf.org>; Mon, 25 Mar 2024 10:00:19 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-7e1026a1c3cso178077241.3 for <nfsv4@ietf.org>; Mon, 25 Mar 2024 10:00:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711386018; x=1711990818; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dVoSCaDBdGmxgbkRiP81j7wBsTQRradEdmZ1L8aOMHk=; b=gSRhpu6bsKr31jmOLwreInr8EKJiwavTepOfCmfec29DGbC7GsVBDk3V4f/O54GwLs ScJFom3Dd4JQY4i7kzx0eiQYGjEZ7nWwk/pAPgJhLwEYDzLa31DbzAekcTrz24v7FI0D b6rGQxyBui8TaLRfqypmWT9RJa7Q3spULpYdYbRc+/cLzfOnT2e9Byqsz8ufPJtTZrXX FPpNq49pk3Eh7b54ma/rhaUosIIJoIEnsXDk/RWhwFFSHmxBfUN1lrIZ7vKqRWv2nK8m vfEWdiAAhhk6C3yMteMFVVFiQWW8fxej7CxK/Kt5lyrByqXqMM1fQ8XbWYzOVMsZEqdd Y6vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711386018; x=1711990818; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dVoSCaDBdGmxgbkRiP81j7wBsTQRradEdmZ1L8aOMHk=; b=FvrHxHDIRxxdHIX3dx8D60JviV6wbv6rJKvra7u9xSdaMQWqNE1UcAC3AhqqwPCgGh Y7RygiD8fjZXxn2b2cXEDB38K44EKjsclxihhmDS7dhH71eOxL/aXKOAZeKd5Zhm4KL4 z9ZPH2qRA/H3s+L2NcVy6IJDEm/AMBsWK971KhQPhjVVv8Q2iFHokeFx4U2i8U7Oht/e r2/LZ60syDnUFqH0Ws4eY10bzdE3z+6v+8lXrUoOgv5h+te8uoeBfKF7y3GrB8OTKe2e gtCow/sNZCLls6sTmHYUrckgKfHnUtnB4s5URTiF1a3UcerqyQUkVRw/HJjGt2+5PZJn iZvg==
X-Gm-Message-State: AOJu0YxiB6f+LmQHdJXMAUXL2oh4oBj06zqsD1YsJxfv28lwGAlZYCAn byLfI8H3320KJ5ikAhsjFTpgMVpVqB7M87fxqFK+oGiniks4HFGM8ncFs/v/oS2p5/0eAFzaigt 3i7yBsh9I1lC9wqIlQg9w71NnHP2DS8IL
X-Google-Smtp-Source: AGHT+IH4P2QO6saTmBqvf7ay734bPOPXM6vBfsjueL/72su08/DeNARY0OOIYVbq78RGCDJOB48rpSAiI6hazlL5D0M=
X-Received: by 2002:a67:ec44:0:b0:478:2318:e1b6 with SMTP id z4-20020a67ec44000000b004782318e1b6mr1228749vso.11.1711386018391; Mon, 25 Mar 2024 10:00:18 -0700 (PDT)
MIME-Version: 1.0
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 25 Mar 2024 13:00:07 -0400
Message-ID: <CADaq8jc0Eaz_ePTu=r44NFKsGtdHOgdy3eFNE1hTgGwr_1Zvqg@mail.gmail.com>
To: Thomas Haynes <loghyr@hammerspace.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b32e6406147f1bf3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/4zCbiAcHXE0Zn4KAjRHTqtgAe4I>
Subject: [nfsv4] Possibility of adding additional REQUIRED attributes
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 25 Mar 2024 17:00:21 -0000

IIRC, at an earlier interim(?) meeting you raised the issue of the possible
addition of other attributes to the set of *REQUIRED* attributes.   As I am
now updating rfc5661bis to reflect the attribute categorization changes
made in other documents including toe regarding mode, owner and
owner_group, I'd like to follow up on this issue soon,  if that is
possible.

Since I am looking to finalize a full reworking of attribute categorization
to appear in -03, I'd like to close out this discussion with regard to the
rfc5661bis effort, if it still has relevance to that effort.  To make
progress on this, I would need a list of attributes that you believe need
to be made *REQUIRED* as part of rfc5661bis. Right now, I don't
anticipating any, although in rewriting the general description of
*OPTIONAL* (formerly "RECOMMENDED") attributes, I am trying to provide a
more balanced discussion, getting rid of the text which stressed the
difficulty (for servers) of implementing attributes and underplayed the
issues for the client in doing without attributes typically expected.  I'm
also explicitly mentioning the need for OPTIONAL attributes in connection
with OPTIONAL features.

Although I don't know of any attributes that need to be made *REQUIRED *in
the context of fc5661bis, I feel that there are a number of attributes that
need to be considered for promotion in  NFSv4.3, now that it is in the
process of graduating from the snide remark stage to the initial discussion
stage.  These would include the ones you alluded to, the attributes brought
over from NFSv3, but I would also like us to include a substantial subset
of the per-fs *OPTIONAL *attributes.  Some examples:

   - fs_charset is very easy for the server to implement and making it
   *REQUIRED* avoid the added complexity for the client of dealing with the
   case of this attribute not being supported.
   - aclsupport raises similar issues even if it is associated with an
*OPTIONAL
   *feature.  This is similar to other attributes which provide
gateways to *OPTIONAL
   *features, with very simple implementations possible when the
*OPTIONAL *feature
   is not supported..
   - fs_layout_type could be made *REQUIRED* with servers not supporting
   pNFS simply returning a zero-length array.

Please update me regarding any issues you have regarding attributes in
rfc5661bis as soon as you can.  Also, I'd like us to schedule some
discussion of NFSv4.3 at a forthcoming interim meeting so we can really
kick off this effort.