[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>.
```