Return-Path: 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 3080CC14F70C; Thu, 22 Aug 2024 09:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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, 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 mLjDz5BVw0Ia; Thu, 22 Aug 2024 09:18:44 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 1DC25C14F6FD; Thu, 22 Aug 2024 09:18:43 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2d3c05dc63eso823549a91.0; Thu, 22 Aug 2024 09:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724343522; x=1724948322; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=o2yyg8OqDXLdqxieL2YzPk+vrOnJ/igQrrY97fn7hGE=; b=ZFOrDMKeVkRKjhQ9VPc4XgWv1+/KQ1hRSnFI/6fRH6HfiMu204uHin6QtgCoCkmCJB IdoQh4vv2eylPrQ/aAPulmtm+sVgNcI6hFjvsE86TcVpit3Rdi/FUMqqNa6XEUn6S5CH frbJPEii9Nbf4y9R8sgiYRvVBDDDWmDoUUcXLLVm4MMswZ63+N40A2s9Yb3VLCNc5fDc GoqdmKbItqn8exWaPxfNlzkahhb6E9lKW5uwevBsKmKFDjf7RibXSrZ7ZlM8uBZy7GMq VI5G4+y5I7mjlLCnnFPNWEoIU9vxk5+BSLEamdYE2N1VJWA3to1RWYLmlDV89PfNlVfJ uC8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724343522; x=1724948322; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o2yyg8OqDXLdqxieL2YzPk+vrOnJ/igQrrY97fn7hGE=; b=bzvouY7DysFpPUQPXNScmNvKMmS9sNKPCCmJTNQL29lV0eVJaY2VOM7u27kQ5vyUo1 8jp35P6R9oRjYOqPiDtphJqMs1ETJpflyRL4O+eKYRxnzLVEwtvnWUwRAgfAL+7Qh9Ie x+jcvJZeIhG1Z/Z48gKF7dv8JO8gTgZRtDS9BuHWSYDYAt7VlAUbGN9tlbUG6deh9Ml8 2HGMaHT04IjkJFwOX4/ghk6Z6RTZWxJir/7D5FDkYMv4j50uAoc28WwUjofl+K/iri05 Cm4cCib1CAG8G2+GZKpsC3/4mc39imHkz74qaYTqVnTYcNtq9UIESuWuFCv+fV5mgzyc k6MA== X-Forwarded-Encrypted: i=1; AJvYcCVcy2Akvik0kIuDeWkP6sAgfn9LZjHhaaPzFf01SgLO4ttI5/LclLIJI+dhTQ8RMLWAZc2Tpu9YHmi3C/W9l/hkHj0H2FcMo24=@ietf.org, AJvYcCW9CAb9VSIEz7hmTTWUo0Yjkvs7Bef6yW2bFfgSHh6FjEFxEDAafeqPkovEdLdRXM/NIpjskdX81cNMJydi@ietf.org, AJvYcCX4IkBNFfXrN1UFnLm4m+58PkeQCxQ62n7WIhJoApPmg0DVtVri4gYvcRqeXpKHhe0ar+lghEY=@ietf.org X-Gm-Message-State: AOJu0Yyj7D+SGFfVQK9isvt5h6gWs5ShJwZvt0ckha1s6Zi08xeivxxW WV/ek674HbEEx//gc9KKCpCSYD2cJgaHjx2nukYnyUuKvDjx838pNOMsSPYc X-Google-Smtp-Source: AGHT+IHJXunECef0btkdk7+zAwitjIW9pUYV64mpnsCmHx+fUmv9l4sFpqo2Pks3h9nRAZuMGryAlw== X-Received: by 2002:a17:90b:4f89:b0:2d3:dca0:89b7 with SMTP id 98e67ed59e1d1-2d5e99fb6d1mr8031303a91.3.1724343521977; Thu, 22 Aug 2024 09:18:41 -0700 (PDT) Received: from smtpclient.apple ([2601:647:4500:91:5055:5678:8782:a2d5]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2d5eb1fc146sm4448872a91.0.2024.08.22.09.18.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2024 09:18:41 -0700 (PDT) From: Thomas Haynes Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_51982FEE-A03F-4DB9-A33F-F8BC12277020" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Date: Thu, 22 Aug 2024 09:18:30 -0700 In-Reply-To: <172408290131.1909130.7166194519531025890@dt-datatracker-6df4c9dcf5-t2x2k> To: Orie Steele References: <172408290131.1909130.7166194519531025890@dt-datatracker-6df4c9dcf5-t2x2k> X-Mailer: Apple Mail (2.3776.700.51) Message-ID-Hash: N77LSAQJRHUKJNWTBPJQV6YN4UGUA2XN X-Message-ID-Hash: N77LSAQJRHUKJNWTBPJQV6YN4UGUA2XN 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 , draft-ietf-nfsv4-delstid@ietf.org, nfsv4-chairs , NFSv4 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnfsv4=5D_Re=3A_Orie_Steele=27s_No_Objection_on_draft-ietf-nfsv4?= =?utf-8?q?-delstid-05=3A_=28with_COMMENT=29?= List-Id: NFSv4 Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_51982FEE-A03F-4DB9-A33F-F8BC12277020 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 19, 2024, at 8:55=E2=80=AFAM, Orie Steele via Datatracker = wrote: >=20 > Orie Steele has entered the following ballot position for > draft-ietf-nfsv4-delstid-05: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/=20 > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Hi Orie, Thanks for the review, comments inline. >=20 > # Orie Steele, ART AD, comments for draft-ietf-nfsv4-delstid-05 > CC @OR13 >=20 > * line numbers: > - > = https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archiv= e/id/draft-ietf-nfsv4-delstid-05.txt&submitcheck=3DTrue >=20 > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md >=20 > * "Handling Ballot Positions": > - = https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >=20 > ## Comments >=20 > ### Extends or Updates? >=20 > ``` > 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). > ``` We went through this one with Zaheed and the RFC Editors booth. Updates implies replacement, whereas extends implies adding on. The term the WG decided on is documented in = https://datatracker.ietf.org/doc/html/rfc8178#section-6 >=20 > ### What are stateids >=20 > ``` > 98 * during the OPEN procedure, get either the open or = delegation > 99 stateids, but not both. > ``` >=20 > Consider a reference to Section 8.2 of RFC8881. Thanks, that is better than the one Gunter provided. >=20 > ### Introduce "compound" >=20 > ``` > 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 > ``` >=20 > Perhaps add a reference to Section 2.3 of RFC8881? Agreed >=20 > ### Introduce "pNFS" / "non-pNFS" Done with Gunter=E2=80=99s review. >=20 > ``` > 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. > ``` >=20 > Expand on first use, reference Section 12 of RFC 8881? Done with Gunter=E2=80=99s review. >=20 > ### can -> SHOULD / will -> MUST? >=20 > ``` > 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. > ``` >=20 > Should this be made normative? Yes, except that they are both MUST. >=20 > ### maybe race conditions >=20 > ``` > 425 Failure to properly sequence the operations may lead to = race cases. > ``` >=20 Ack, changed > Can this be avoided with normative language? >=20 > Its possible this is addressed with the normative paragraphs that = follow. >=20 > ### 2008 reference for LEGAL >=20 I believe I addressed this point with Roman=E2=80=99s review. I.e., I = removed it all. > Is this necessary? Is there a more recent reference? >=20 > ``` > 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. > ``` >=20 > ``` > 594 [LEGAL] IETF Trust, "Legal Provisions Relating to IETF = Documents", > 595 November 2008, = 596 License-Policy.pdf>. > ``` >=20 >=20 >=20 > _______________________________________________ > nfsv4 mailing list -- nfsv4@ietf.org > To unsubscribe send an email to nfsv4-leave@ietf.org --Apple-Mail=_51982FEE-A03F-4DB9-A33F-F8BC12277020 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 19, 2024, at 8:55=E2=80=AFAM, Orie Steele via = Datatracker <noreply@ietf.org> wrote:

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-position= s/
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:
-----------------------------------------------------= -----------------


Hi Orie,

Thanks for the review, comments = inline.



# = Orie Steele, ART AD, comments for draft-ietf-nfsv4-delstid-05
CC = @OR13

* line numbers:
 -
=  https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/= archive/id/draft-ietf-nfsv4-delstid-05.txt&submitcheck=3DTrue

*= 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).
```


We went through this one with Zaheed and the RFC Editors = booth.

Updates implies replacement, whereas = extends implies adding on.

The term the WG = decided on is documented in https://d= atatracker.ietf.org/doc/html/rfc8178#section-6


### 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.


Th= anks, that is better than the one Gunter = provided.




### 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?

Agreed
=


### Introduce = "pNFS" / "non-pNFS"

Done = with Gunter=E2=80=99s review.


```
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?

Done with = Gunter=E2=80=99s review.


### 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?

Yes, except = that they are both = MUST.




### maybe race conditions

```
425 =        Failure to properly sequence = the operations may lead to race = cases.
```


Ack, = changed


Can = this be avoided with normative language?

Its possible this is = addressed with the normative paragraphs that follow.

### 2008 = reference for = LEGAL


I believe I = addressed this point with Roman=E2=80=99s review.  I.e., I removed = it all.


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 =             &n= bsp;     November 2008, = <http://trustee.ietf.org/docs/IETF-Trust-
596 =             &n= bsp;     License-Policy.pdf>.
```


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

= --Apple-Mail=_51982FEE-A03F-4DB9-A33F-F8BC12277020--