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

[Orie Steele <[e-mail]>]

Thanks for addressing my comments.

On Thu, Aug 22, 2024 at 11:18 AM Thomas Haynes <[e-mail]> wrote:

>
>
> 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]
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>