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

[Benjamin Kaduk <[e-mail]>]

On Thu, Apr 19, 2018 at 08:55:50AM -0700, Tom Haynes wrote:
> 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:
> >> 
> >> ----------------------------------------------------------------------
> >> 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].

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

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

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