[nfsv4] Orie Steele's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)
Orie Steele via Datatracker <noreply@ietf.org> Mon, 19 August 2024 15:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from [10.244.2.52] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBE6C169438; Mon, 19 Aug 2024 08:55:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Orie Steele via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.22.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172408290131.1909130.7166194519531025890@dt-datatracker-6df4c9dcf5-t2x2k>
Date: Mon, 19 Aug 2024 08:55:01 -0700
Message-ID-Hash: OYHGFZ4DTCGYEWQWBO7DVUSK6THDKNH7
X-Message-ID-Hash: OYHGFZ4DTCGYEWQWBO7DVUSK6THDKNH7
X-MailFrom: noreply@ietf.org
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: draft-ietf-nfsv4-delstid@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Orie Steele <orie@transmute.industries>
Subject: [nfsv4] Orie Steele'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/Uc5e9XQu-IkX9mrTtdh0C0NxzOQ>
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>
Orie Steele 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: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-nfsv4-delstid-05 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nfsv4-delstid-05.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### Extends or Updates? ``` 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). ``` ### What are stateids ``` 98 * during the OPEN procedure, get either the open or delegation 99 stateids, but not both. ``` Consider a reference to Section 8.2 of RFC8881. ### Introduce "compound" ``` 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 ``` Perhaps add a reference to Section 2.3 of RFC8881? ### Introduce "pNFS" / "non-pNFS" ``` 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. ``` Expand on first use, reference Section 12 of RFC 8881? ### can -> SHOULD / will -> MUST? ``` 339 The client is already prepared to not get a delegation stateid even 340 if requested. In order to not send an open stateid, the server can 341 indicate that fact with the result flag of 342 OPEN4_RESULT_NO_OPEN_STATEID. The open stateid field, 343 OPEN4resok.stateid (see Section 18.16.2 of [RFC8881]), will also be 344 set to the special all zero stateid. ``` Should this be made normative? ### maybe race conditions ``` 425 Failure to properly sequence the operations may lead to race cases. ``` Can this be avoided with normative language? Its possible this is addressed with the normative paragraphs that follow. ### 2008 reference for LEGAL Is this necessary? Is there a more recent reference? ``` 540 Both the XDR description and the scripts used for extracting the XDR 541 description are Code Components as described in Section 4 of "Legal 542 Provisions Relating to IETF Documents" [LEGAL]. These Code 543 Components are licensed according to the terms of that document. ``` ``` 594 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", 595 November 2008, <http://trustee.ietf.org/docs/IETF-Trust- 596 License-Policy.pdf>. ```
- [nfsv4] Orie Steele's No Objection on draft-ietf-… Orie Steele via Datatracker
- [nfsv4] Re: Orie Steele's No Objection on draft-i… Thomas Haynes
- [nfsv4] Re: Orie Steele's No Objection on draft-i… Orie Steele