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

[Tom Haynes <[e-mail]>]

Resending from an address that is not considered spam….

> On Apr 19, 2018, at 8:54 AM, Thomas Haynes <[e-mail]> wrote:
> 
> Thanks for the review Benjamin, comments inline.
> 
>> On Apr 17, 2018, at 3: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]”.
> 
> My counter proposal is:
> 
>   This section discusses how the original layout types interact with
>   Section 12 of [RFC5661], which enumerates the requirements of pNFS
>   layout type specifications.  It is not normative with regards to the
>   file layout type presented in Section 13 of [RFC5661], the block
>   layout type [RFC5663], and the object layout type [RFC5664].  These
>   are discussed here only to illuminate the updates made in Section 3
>   of this document to Section 12 of [RFC5661].
> 
> 
> 
>> 
> 
>> 
>> ----------------------------------------------------------------------
>> 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.
>> 
> 
> 
> I’ve made this change
> 
> 
>> 
>> 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”?
> 
> Accepted
> 
>> 
>>  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?
>> 
> 
> It is issued to the client. But in a tightly coupled approach, the 
> metadata server can inform the storage device that a particular
> stateid is invalid. That would then remove access for only the
> client which has the stateid.
> 
> With a loosely coupled approach, the metadata server can not
> invalidate a specific stateid and must remove access for all
> clients to the file. Each client would then renegotiate access
> to file and the metadata server could at that point deny access
> to the particular 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[".
>> 
>> 
> 
> 
> See above.
> 
> 
>> Section 6
>> 
>>  [...] In the latter case, I/O access writes
>>  are reflected in layouts [...]
>> 
>> s/writes/rights/
>> 
>> 
> 
> But it reads writely! :-)
> 
> Changed...