Re: [nfsv4] AD Evaluation of draft-ietf-nfsv4-layout-types-08

[David Noveck <[e-mail]>]

 > > I found myself wondering "unique within what scope?”


> The server and stateid type.

For v4.1, it's actually unique within the scope of a particlar
client-server pair as repeented by
a clientid.

Section 8.2 of RFC5661 says:

The server may assign stateids independently for different clients.

A stateid with the same bit pattern for one client may designate an

entirely different set of locks for a different client.  The stateid

is always interpreted with respect to the client ID associated with

the current session.  Stateids apply to all sessions associated with

the given client ID, and the client may use a stateid obtained from

one session on another session associated with the same client ID.



On Mon, Feb 5, 2018 at 6:00 PM, Thomas Haynes <[e-mail]>
wrote:

>
>
> > On Feb 5, 2018, at 1:52 PM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > Dear Authors,
> >
> > This draft looks quite clean. NFSv4 drafts usually do.
> >
> > I did make some notes during AD Evaluation, and would like to resolve
> them before requesting IETF Last Call.
> >
> > Please let me know what you think.
> >
> > Spencer
> >
> > In this text from the Abstract,
> >
> >   This document defines the requirements which individual pNFS layout
> >    types need to meet in order to work within the parallel NFS (pNFS)
> >    framework as defined in RFC5661.  In so doing, it aims to clearly
> >    distinguish between requirements for pNFS as a whole and those
> >    specifically directed to the pNFS File Layout.  The lack of a clear
> >    separation between the two set of requirements has been troublesome
> >    for those specifying and evaluating new Layout Types.  In this
> >    regard, this document effectively updates RFC5661.
> >
> > I'd suggest dropping "effectively" in the last sentence.
> >
>
> Okay
>
>
> > In this text,
> >
> >   The concept of layout type has a central role in the definition and
> >    implementation of Parallel Network File System (pNFS).  Clients and
> >    servers implementing different layout types behave differently in
> >    many ways while conforming to the overall pNFS framework defined in
> >    [RFC5661] and this document.
> >
> > I'd suggest adding the reference to [RFC5661] at the end of the first
> sentence, since that's where pNFS is defined (right?). The existing
> reference to [RFC5661] in the final sentence is fine.
> >
>
>
> Okay
>
>
> > In this text,
> >
> >   As a consequence, new internet drafts (see [FlexFiles] and [Lustre])
> >    may struggle to meet the requirements to be a pNFS layout type.
> >
> > I'd suggest "authors of new specifications" ... "may struggle”.
>
> Okay
>
>
> >
> > I understand that the Terminology section is in alphabetical order, but
> could you consider whether a different organization might be helpful?
> "loose coupling" and "tight coupling" seem useful to read together, for
> instance, but they don't appear on the same page. If you tell me that doing
> that doesn't seem helpful, I believe you …
>
> The only problem is that we might want to make the same change in the Flex
> Files document.
>
> I’ve rearranged them such that the major concepts are grouped together.
>
>
> >
> > In this text,
> >
> >   layout stateid:  is a 128-bit quantity returned by a server that
> >       uniquely defines the layout state provided by the server for a
> >       specific layout that describes a layout type and file (see
> >       Section 12.5.2 of [RFC5661]).
> >
> > I found myself wondering "unique within what scope?”
>
>
> The server and stateid type.
>
>
> >
> > In this text,
> >
> > 3.  The Control Protocol
> >
> >    A layout type has to meet the requirements that apply to the
> >    interaction between the metadata server and the storage device such
> >    that they present to the client a consistent view of stored data and
> >    lock state (Section 12.2.6 of [RFC5661]).  Particular implementations
> >    may satisfy these requirements in any manner they choose and the
> >    mechanism chosen need not be described as a protocol.
> >
> > could you give an example of a mechanism that wouldn't be described as a
> protocol? I can guess, but I'm guessing. The SCSI layout given as an
> example a bit further down this section is the kind of example I'm thinking
> about here.
> >
>
> I was actually thinking not of layout types, but of implementations of a
> Layout Type.
>
> The prime example is the NFSv4.1 file layout type as implemented in Data
> ONTAP by NetApp. The view of stored data, the stateid validation, and the
> locking state are handled by their clustering software. Do I have a
> citation for that? Nope.
>
>
>
> > The security considerations section deflects the reader to the security
> considerations that appear in layout type specifications, but doesn't
> provide any specific references to guide the user in finding such
> specifications. Would it be possible to provide pointers to layout type
> definition documents, even if there are only one or two that would make
> sense?
>
>
> While my intent is to say “read the security considerations of each Layout
> Type spec”, I can present an example.
>
> I went with adding this to the end of the paragraph:
>
>     For example, in Section 5 of <xref target="RFC5663" />, the lack
>     of finer-than-physical disk access control necessitates that the
>     client is delegated the responsibility to enforce the access
>     provided to them in the layout extent which they were granted by
>     the metadata server.
>
>
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>