Subject: Genart last call review of draft-ietf-nfsv4-flex-files-15

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Dec 2017 02:25:03 -0800

Reviewer: Christer Holmberg
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-nfsv4-flex-files-15
Reviewer: Christer Holmberg
Review Date: 2017-12-21
IETF LC End Date: 2018-01-16
IESG Telechat date: 2018-01-25

Summary: The document is well written, and almost ready for publication.
However, I think some additional text is needed, as described below.

Major issues: None.

Minor issues: None:

Nits/editorial comments:

Q1:

The Abstract says:

   "The flexible file layout type is defined in this
   document as an extension to pNFS which allows the use of storage
   devices in a fashion such that they require only a quite limited
   degree of interaction with the metadata server, using already
   existing protocols."

…and the Introduction says:

   "There are different layout types for different storage
   systems and methods of arranging data on storage devices.  This
   document defines the flexible file layout type used with file-based
   data servers that are accessed using the Network File System (NFS)
   protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
   NFSv4.2 [RFC7862].”

But, there is no text about the existing file layout type, and how this file
layout types will improve things. The Abstract mentions impacts on the
interactions with the metadata server, but there is no text about that in the
Introduction. I think a few sentences in the Introduction, describing the
high-level advantages and changes that the flexible file layout type brings,
would be good.

Also, the Abstract mentions client mirroring, but there is nothing about that
in the Introduction.

Q2:

Is section 2 specific to the flexible file layout type, or is it about pNFS in
general? I think it would good to have a sentence describing the scope of the
section.

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 22 Dec 2017 01:42:06 +0000

Hi Christer,

Thanks for the review, replies in line.

> On Dec 21, 2017, at 2:25 AM, Christer Holmberg <[email-masked]> wrote:
> 
> layout types will improve things.

It does not have to improve things, it is just a different layout type.

> The Abstract mentions impacts on the
> Introduction.

There is, but perhaps the relationship needs to be explained.

The entire second paragraph is about the interactions with the metadata
server.

> I think a few sentences in the Introduction, describing the

Both of these were on purpose - I wanted to introduce the terms in Section 1.1
before using them.

I’ll add the high-level summary, including client side mirroring.

> general? I think it would good to have a sentence describing the scope of the

It starts out general for all pNFS and covered more specifically in [pNFSLayouts].

And having said that, I disagree with it immediately.

I can point the reader to [pNFSLayouts] and paint the scope as to how
FlexFiles will address this issue.

> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Dec 2017 19:47:38 +0000

Hi Thomas,

...

>> But, there is no text about the existing file layout type, and how 
>> this file layout types will improve things.
>

But, shouldn't there be any description about the difference between the existing file layout type? Is there some specific scenario in mind? Is there some characteristic(s) specific to the flexible file layout type?

I assume there was *SOME* reason for defining the flexible file layout type - other than just defining a new layout type for the sake of it :)

>> The Abstract mentions impacts on the interactions with the metadata server, but there is no text about that 
>> in the Introduction.
>
> The entire second paragraph is about the interactions with the metadata server.

If that is specific to the flexible file layout type, I think it should be explicitly stated.

>> I think a few sentences in the Introduction, describing the high-level 
>> advantages and changes that the flexible file layout type brings, 
>> would be good.
>> 
>> Also, the Abstract mentions client mirroring, but there is nothing 
>> about that in the Introduction.
>> 
>
> Both of these were on purpose - I wanted to introduce the terms in Section 1.1 before using them.

That is fine.

> I’ll add the high-level summary, including client side mirroring.

Thanks!

>> Q2:
>> 
>> Is section 2 specific to the flexible file layout type, or is it about 
>> pNFS in general? I think it would good to have a sentence describing 
>> the scope of the section.
>

Disagree with what? My suggestion to have a sentence describing the scope?

> I can point the reader to [pNFSLayouts] and paint the scope as to how FlexFiles will address this issue.

Thanks!

Regards,

Christer

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 22 Dec 2017 23:00:04 +0000

> On Dec 22, 2017, at 11:47 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> ...
> 
>>> Q1:
>>> 
>>> The Abstract says:
>>> 

The old type did not allow you to use NFSv3 to access the storage devices.

Which is covered here:

   This
   NFSv4.2 [RFC7862].

DISCLAIMER: I am too close to this document and after RFC 7530 and RFC 7862, I tend to be terse.

In general, a new layout type is created to access the storage devices via a
different protocol than provided by existing layout types. See RFC 8154 and
draft-hellwig-nfsv4-rdma-layout-00.

I’ll add some text to make apparent the desire is to access non-NFSv4 storage devices.

> Disagree with what? My suggestion to have a sentence describing the scope?

No, hah! My statement of "It starts out general for all pNFS and covered more specifically in [pNFSLayouts].”

---

From: Rick Macklem <[email-masked]>
Date: Sat, 23 Dec 2017 12:52:26 +0000

Thomas Haynes wrote:
[stuff snipped]
>> On Dec 22, 2017, at 11:47 AM, Christer Holmberg wrote:
>>
There is also client side driven storage server mirroring (which is the reason
I am interested in it) and more flexible striping (although no one seems to
be doing striping these days).

rick