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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Feb 2018 15:52:19 -0600

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.

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.

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

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 …

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?"

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.

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?

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 5 Feb 2018 23:00:11 +0000

> On Feb 5, 2018, at 1:52 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear Authors,
> 
> I did make some notes during AD Evaluation, and would like to resolve them before requesting IETF Last Call.
> 

Okay

> 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

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

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

The server and stateid type. 

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

---

From: David Noveck <[email-masked]>
Date: Tue, 6 Feb 2018 12:38:32 -0500

> 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 <[email-masked]>
wrote:

> 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.
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 8 Feb 2018 07:59:01 -0600

I looked at -09, and it seems quite reasonable. Thanks for your help during
AD Evaluation.

Mr. Spencer (S), are we ready for Last Call?

Spencer (D)

On Tue, Feb 6, 2018 at 11:38 AM, David Noveck <[email-masked]> wrote:

>> > 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
>> While my intent is to say “read the security considerations of each
>> Layout Type spec”, I can present an example.
>>

---

From: spencer shepler <[email-masked]>
Date: Thu, 08 Feb 2018 20:44:58 +0000

Yes, we are ready for last call.

Spencer

On Thu, Feb 8, 2018 at 5:59 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> >> > I'd suggest "authors of new specifications" ... "may struggle”