[nfsv4] Re: Gunter Van de Velde's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

Thomas Haynes <loghyr@gmail.com> Thu, 22 August 2024 16:03 UTC

Return-Path: <loghyr@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 2A1F6C14F700; Thu, 22 Aug 2024 09:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 fPNkpb7_6le6; Thu, 22 Aug 2024 09:03:00 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AF0C151707; Thu, 22 Aug 2024 09:03:00 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-71430e7eaf8so875119b3a.1; Thu, 22 Aug 2024 09:03:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724342579; x=1724947379; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r5OR2mBRng5nExKrNcLelKAdD+NvuE7iGIF7b7S2FLM=; b=ZGu+NFE52hFFM5Nj7018lM0dEfU4YrAV7PY2RXQCiowVFkoU3iwfV/QO7rieaqw+up h7hCt0ED78cMFtwhZE5ujwRrz9A6gkNNSd1W9KMSbjdLtf0yMQk8M/hEcA0EeNTpvZ95 PYBcHSBXP8hcuH2TpLn6yPUnnlh839tfyPKWFlpuT3fOiRN2LAet3Smq6o1rLitoKEym eue+8WMrDe9K2Ssx7O3EVn67E+hmumDpO1Qvr/S+SES6K01Biq6ZMq5nsV4yZr5I6mFW hoS8ru9npc6xg+8UjcUgdy5+wfS38/bf4fXKY39++dFlkrOIYwszOKUCGLT+Z0wXaNbP cEWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724342579; x=1724947379; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r5OR2mBRng5nExKrNcLelKAdD+NvuE7iGIF7b7S2FLM=; b=VJFzrCSDkXta/mApeWH7T2IOPFzBVuhZQxqqfTGbO/ohLg7V/+q0qEbZgNIHwYnI7e QsPk8hFRjqFNJel9a/8yoZG2MEsi2GoM7lOBgHxRMTnhZShAd2AUdwSxpGp6B8/cwY7+ BvKF80wFAfJt4I93iKwXf7f+IMSIBYb2/a1/j3wOLWUEfYglWqf3pZwlUg6uvrY8v6MB 6m3zZh9lXsMqwe2KnEch9kvshpDiKRUCqdxDRubY8V6DCaWszTvydHimP5tuP3kjDP9l 4IoKWlIQVk2JP21Yvib7rmzJ0oJcnnBrU22cMFyjgZSDaYCqtsNvFsg99rXcCuBOyeC0 X1Kg==
X-Forwarded-Encrypted: i=1; AJvYcCVIi66Jwuv7jA1CTdSqSmOu+eySn1bHLxA77qwkR1KsOtpWR5XcuHRzQUTH9S620BFDpHfV/FU=@ietf.org, AJvYcCX9GHyuzGunlDK03WEXVJleoOtzQP0nYpt06yVL/c0bmsFewZOGY7Zqwf9P1RW3HPJFgPjRI8ylXoo5lAc1@ietf.org, AJvYcCXmUAVFtYqX7kmQtsde1ghN7eyA8jpfzGkdL6bxdevNk9vSZKhwNNpxnDx2FrU7j9Ek4HDWxcEXtcRONRFc6kBSKt8U7h7BFJ8=@ietf.org
X-Gm-Message-State: AOJu0YwRHc8Y2oDCH8QXwzVxZsmDVMBZIPv5ojwTyfHuJIFuun0ratmI Eqz78gMMw0tqTYdVRswiPVECofRBhcFYQWDdSmhGNYvSKjbMX69K
X-Google-Smtp-Source: AGHT+IGRRCdxcbe1K5dDOCl/rWMT3JyDJyBX1CAvko/X+gOVDvRoc1Vmypa1o2rIEbF556jW/i6xYg==
X-Received: by 2002:a05:6a21:9d83:b0:1bd:260e:be97 with SMTP id adf61e73a8af0-1cada1aa070mr6221991637.53.1724342579225; Thu, 22 Aug 2024 09:02:59 -0700 (PDT)
Received: from smtpclient.apple ([2601:647:4500:91:5055:5678:8782:a2d5]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7143422eab8sm1549574b3a.41.2024.08.22.09.02.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2024 09:02:58 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
From: Thomas Haynes <loghyr@gmail.com>
In-Reply-To: <172408773440.1905156.12348762353610199736@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Thu, 22 Aug 2024 09:02:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF5AEF39-4B11-4BDC-93DD-F65DA0B86677@gmail.com>
References: <172408773440.1905156.12348762353610199736@dt-datatracker-6df4c9dcf5-t2x2k>
To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
X-Mailer: Apple Mail (2.3776.700.51)
Message-ID-Hash: 333FTXJFW5PRABAFYITZ6YPCPURGKHTM
X-Message-ID-Hash: 333FTXJFW5PRABAFYITZ6YPCPURGKHTM
X-MailFrom: loghyr@gmail.com
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: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-delstid@ietf.org, nfsv4-chairs <nfsv4-chairs@ietf.org>, nfsv4@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: Gunter Van de Velde's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/9PeVZLnzL9E6wf4ls9X53uFnFBc>
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 Aug 19, 2024, at 10:15 AM, Gunter Van de Velde via Datatracker <noreply@ietf.org> wrote:
> 
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-nfsv4-delstid-05: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-delstid-05
> 
> Many thanks for writing this document.
> 
> Please find next some observations and non-blocking comments encountered during
> my processing of this work. I am not very familiar with NFS technologies, hence
> maybe some of my observations and comments could be due to unexperienced.
> 


Hi Gunter,

Thanks for the review, responses inline.


> Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
> documenting the handling of ballots.
> 
> #DETAILED COMMENTS
> #=================
> ##classified as [minor] and [major]
> 
> 10      Abstract
> 11
> 12         The Network File System v4 (NFSv4) allows a client to both open a
> 13         file and be granted a delegation of that file.  This delegation
> 14         provides the client the right to authoritatively cache metadata on
> 15         the file locally.  This document presents several extensions for both
> 16         the opening and delegating of the file to the client.  This document
> 17         extends both NFSv4.1 (see RFC8881) and NFSv4.2 (see RFC7863).
> 
> [major]
> The title of the document says "Extending the Opening of Files in NFSv4.2"
> however the abstract says that this works extends both NFSv4.1 (see RFC8881)
> and NFSv4.2 (see RFC7863)


I had a big argument to support this, but I realized it was wrong.

So I have fixed this to just mention NFSv4.2.



> 
> 88         authority for the file's metadata and data.  This document presents a
> 89         number of extensions which enhance the functionality of opens and
> 90         delegations.  These allow the client to:
> 
> [minor]
> cosmetic rewrite textblob proposal
> 
> "
> This document introduces a set of extensions designed to enhance the
> functionality of file opens and delegations. These extensions enable the client
> to: "
> 
> 98         *  during the OPEN procedure, get either the open or delegation
> 99            stateids, but not both.
> 100
> 101        *  cache both the access and modify times, reducing the number of
> 102           times the client needs to go to the server to get that
> 103           information.
> 
> [minor]
> stateid is speciefied in
> https://datatracker.ietf.org/doc/html/rfc7530#section-9.1.4

I’ve pointed to Section 1.7 of RFC8881 - ehh, strike that 9.1.4 of RFC7530 is better.



> 
> [minor]
> cosmetic rewrite textblob proposal
> 
> "
> * During the OPEN procedure, retrieve either the open stateid or delegation
> stateid, but not both simultaneously.
> 
> * Cache both the access and modify timestamps, thereby reducing the frequency
> with which the client must query the server for this information. "
> 


I’ve taken the above changes.




> 105        Using the process detailed in [RFC8178], the revisions in this
> 106        document become an extension of NFSv4.2 [RFC7862].
> 
> [major]
> See earlier in the abstract where is indicated that NFS4.1 is extended too


Already fixed the abstract.


> 
> 147        A compound with a GETATTR or READDIR can report the file's attributes
> 148        without bringing the file online.  However, either an OPEN or a
> 149        LAYOUTGET might cause the file server to retrieve the archived data
> 150        contents, bringing the file online.  For non-pNFS systems, the OPEN
> 151        operation requires a filehandle to the data content.  For pNFS
> 152        systems, the filehandle retrieved from an OPEN need not cause the
> 153        data content to be retrieved.  But when the LAYOUTGET operation is
> 154        processed, a layout type specific mapping will cause the data content
> 155        to be retrieved from offline storage.
> 
> [minor]
> I am not familiar with terminology as GETATTR, READDIR, LAYOUTGET, pNFS
> Should refereces be added if these are not wellknown in the technology area?


I added references….


> 
> 157        If the client is not aware that the file is offline, it might
> 158        inadvertently open the file to determine what type of file it is
> 159        accessing.  By interrogating the new attribute FATTR4_OFFLINE, a
> 
> [minor]
> Is FATTR4_OFFLINE a particular abbreviation for something of meaning?
> (i have no NFS experience)


Yes, it is how we define an id for an attribute.

FATTR - file attribute
4 - major version number
OFFLINE - specific attribute.

NFS implementors would easily understand this point.



> 
> 170        /// typedef bool            fattr4_offline;
> 
> [minor]
> Here lower case is used, while earlierand later the same with upper case is
> used? Is this intentional?


Again, yes.

Sadly, there is no reference to provide for this.

Basically, we have an attribute type, in all lower case and an attribute id, all in upper case.


> 
> 189        The fattr4_open_arguments attribute is a new XDR extension which
> 
> [minor]
> Should this attribute be upper case FATTR4_OPEN_ARGUMENTS ?

Looking at RFC8881, it appears that to be consistent, I should be using the attribute in all lower case.

I will modify the document to reflect that convention.

I really want to thank you on this one!

> 
> 465        only supports NFSv4.2.  An implementation could add a NFSv3 server
> 466        which is a NFSv4.2 client gateway the two incompatible systems.  As
> 
> [minor]
> The phrase seems wrong? What about:
> 
> "
> An implementation may introduce an NFSv3 server that functions as an NFSv4.2
> client, serving as a gateway between the two otherwise incompatible systems. "
> 
> 


Ack



> 
> _______________________________________________
> nfsv4 mailing list -- nfsv4@ietf.org
> To unsubscribe send an email to nfsv4-leave@ietf.org