[nfsv4] Re: Orie Steele's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

[Thomas Haynes <[e-mail]>]

> On Aug 19, 2024, at 8:55 AM, Orie Steele via Datatracker <[e-mail]> 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-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:
> ----------------------------------------------------------------------


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


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


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


Thanks, 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’s 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’s 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’s 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                   November 2008, <http://trustee.ietf.org/docs/IETF-Trust-
> 596                   License-Policy.pdf>.
> ```
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]