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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Apr 2018 15:38:58 -0700

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

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 19 Apr 2018 08:10:44 -0500

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

> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/

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)

---

From: Tom Haynes <[email-masked]>
Date: Thu, 19 Apr 2018 08:55:50 -0700

Resending from an address that is not considered spam….

> On Apr 19, 2018, at 8:54 AM, Thomas Haynes <[email-masked]> wrote:
> 
> Thanks for the review Benjamin, comments inline.
> 
>> On Apr 17, 2018, at 3:38 PM, Benjamin Kaduk <[email-masked]> wrote:
>> 
>> [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].
> 
> 
> 
>> 
> 
>> 
> I’ve made this change
>> Maybe "it is not appropriate for publication as an IETF-stream RFC”?
> 
> Accepted
> 
>> 
> 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.
> 
> 
> 
>> 
> See above.
> But it reads writely! :-)
> 
> Changed...

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Apr 2018 11:04:50 -0500

> >   of this document to Section 12 of [RFC5661].

That works for me, thanks!  I'll clear my DISCUSS.

> > to the particular client.

Thanks for the explanation.  (I was just double-checking if "storage
device" or "client" was better in that phrase, and trust you to do
the right thing.)

-Benjamin