Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-layout-types-10: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Dear draft-ietf-nfsv4-layout-types authors,

On Tue, Apr 17, 2018 at 5:38 PM, Benjamin Kaduk <[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-layout-types-10: Discuss
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for writing this up; it's good to have better clarity about the
> requirements placed on various actors in pNFS.  I will change to Yes once
> this
> issue is resolved:
>
> Section 4 leaves me confused about what exactly from RFC 5661 is
> being updated.  That is, the subsections look to be some discussion
> about how the "real requirements" (i.e., this document) apply to the
> given layout types, and we are told that these sections do not update
> the specification for those specific layout types.  So it's hard to
> get a clear picture about which specific requirements are being
> changed/added;
> this leads me to wonder if the top-level Section 4 should not say
> "This section updates Section 12 of [RFC5661]" and leave the
> "discussed here only to illuminate the updates made to Section 12 of
> [RFC5661]".
>

I haven't seen a reply to Benjamin's Discuss yet, and it seems simple
enough to resolve. Could you take a look at this, and start that Discussion?

Thanks,

Spencer (D)


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
>    Such matters are defined in a standards-track layout type
>    specification.
>
> This could be read as saying that there is a single document, which
> happens to be a layout-type specification and standards-track, that
> gives guidance on how layout types differ.  Maybe:
>
>    Each layout type will define the needed details for its usage in
>    the specifciation for that layout type; layout type
>    specifications are always standards-track RFCs.
>
>
> Section 3.3
>
>    [..] If the document does not
>    impose implementation requirements sufficient to ensure that these
>    semantic requirements are met, it is not appropriate for the working
>    group to allow the document to move forward.
>
> Maybe "it is not appropriate for publication as an IETF-stream RFC"?
>
>    o  If the metadata server does not have a means to invalidate a
>       stateid issued to the storage device to keep a particular client
>       from accessing a specific file, then the layout type specification
>       has to document how the metadata server is going to fence the
>       client from access to the file on that storage device.
>
> Is the stateid issued to the storage device or to the client?
>
>
> Section 4 leaves me confused about what exactly from RFC 5661 is
> being updated.  That is, the subsections look to be some discussion
> about how the "real requirements" (i.e., this document) apply to the
> given layout types, we are told that these sections do not update
> the specification for those specific layout types.  So it's hard to
> get a clear picture about which specific things are being updated;
> this leads me to wonder if the top-level Section 4 should not say
> "This section updates Section 12 of [RFC5661]" and leave the
> "discussed here only to illuminate the updates made to Section 12 of
> [RFC5661[".
>
>
> Section 6
>
>    [...] In the latter case, I/O access writes
>    are reflected in layouts [...]
>
> s/writes/rights/
>
>
>