Parallel NFS (pNFS) Block Disk Protection
draft-ietf-nfsv4-pnfs-block-disk-protection-03

[Ballot discuss]
The following paragraph seems more like fodder for the proto write-up:

  As of November 2011, many current operating system versions support
  the GPT, including FreeBSD, Linux and Solaris [GPT-W].

Did you comply with the trademark terms of use for FreeBSD, Linux, and Solaris?  For example:

http://www.freebsdfoundation.org/documents/Guidelines.shtml

If not then it's probably best to just remove this paragraph.

[Ballot comment]
These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 3 --
        The pNFS Block Storage partitions are identified in the GPT with 
        GUID e5b72a69-23e5-4b4d-b176-16532674fc34.  This GUID has been 
        generated by one of the draft authors for this purpose.

This won't be a "draft" when it's published, and I don't think it matters who generate the GUID.  How about this?:

        The pNFS Block Storage partitions are identified in the GPT with 
        GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been
        generated for this purpose.

As I read section 3, what I think I get is that the whole thing defined by this document is this:
- A new GUID is defined.
- If servers put this GUID in, clients can use is presence to behave better.

Is that right?  If so, I think the last paragraph of the Introduction could be expanded by another sentence or two to make the simplicity fully clear.

Of course, if that's NOT right, then I'm missing something, so please tell me what.  :-)

Oh, and you might consider updating the date in the last paragraph of Section 3, especially if you have more recent detail of the implementation.

I don't think the Conclusions section adds anything, and would remove it.  "Conclusions" aren't customary in IETF specs, unless there's really something to say.

[Ballot comment]
I don't get why you use a  SHOULD in "A pNFS client operating
system that supports block layouts SHOULD recognize this GUID
and use its presence to prevent data access to pNFS block
devices until a layout that includes the device is received from
the MDS. " Maybe you mean "SHOULD use its presence" but it reads
as if you're saying "SHOULD recognize."

[Ballot comment]
I don't why you use a  SHOULD in "A pNFS client operating
system that supports block layouts SHOULD recognize this GUID
and use its presence to prevent data access to pNFS block
devices until a layout that includes the device is received from
the MDS. " Maybe you mean "SHOULD use its presence" but it reads
as if you're saying "SHOULD recognize."

IANA has reviewed draft-ietf-nfsv4-pnfs-block-disk-protection-02, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (pNFS block disk protection) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'pNFS block disk protection'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to
  enable direct client access to file data on storage, bypassing the
  NFSv4 server.  This can increase both performance and parallelism,
  but requires additional client functionality, some of which depends
  upon the type of storage used.  The pNFS specification for block
  storage (RFC 5663) describes how clients can identify the volumes
  used for pNFS, but this mechanism requires communication with the
  NFSv4 server.  This document updates RFC 5663 to add a mechanism that
  enables identification of block storage devices used by pNFS file
  systems without communicating with the server.  This enables clients
  to control access to pNFS block devices when the client initially
  boots, as opposed to waiting until the client can communicate with
  the NFSv4 server.

This last call explicitly identifies 1 downref in the normative references
of this document:
  [GPT]    Unified EFI Forum, "Unified Extensible Firmware Interface
            Specification", Version 2.3.1, Errata A, Section 5.3,
            September 2011, available from http://www.uefi.org .

GPT GUID usage is well understood and implemented. This I-D provides a
documentation/definition point.Given the use case of NFSv4.1 pNFS block
devices, the documentation of the pNFS GPT GUID in an IETF RFC best
suites the need of the community.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-pnfs-block-disk-protection/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-pnfs-block-disk-protection/ballot/


No IPR declarations have been submitted directly on this I-D.

Working Group: NFSv4
Area Director: David Harrington
Document Author/Shepherd: Spencer Shepler (sshepler@microsoft.com)

Internet Draft:

draft-ietf-nfsv4-pnfs-block-disk-protection-01.txt

(1.a) Spencer Shepler (sshepler@microsoft.com) is the document shepherd.
I have reviewed the document and believe it is ready for further
review by the IESG and publication as a standards track RFC.

(1.b) The document has received necessary and sufficient review.

(1.c) Review by area experts or outside parties is not needed.

(1.d) The shepherd has no outstanding concerns and there are no
IPR disclosures for this work.

(1.e) There is strong WG consensus for this document's content.

(1.f) No dissent has been expressed in relation to this document or
the review of such.

(1.g) The document meets all ID nits.

(1.h) The document has split references and normative references
are of an appropriate form.

(1.i) The IANA section exists and is correct for the document's content.

(1.j) The GUID definition made in the document is appropriate and correct.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

The NFSv4.1 protocol allows for the location of file system data
to be expressed in the form of "layouts". The layout for a
particular file identifies location and access information such
that the NFSv4.1 client may "directly" access the data without
interaction with the primary or NFSv4.1 meta-data server.
In the instance of the pNFS block layout type (defined in RFC 5663)
the client accesses data via traditional block storage protocols.
The NFSv4.1 pNFS block enabled client, by definition, will have
read/write access to the block devices of the NFSv4.1 server.
This access presents a problem for the client operating environment
in that identification of these NFSv4.1 pNFS block devices is not
well defined. This I-D provides the needed identification by
defining and documenting a GPT GUID value for pNFS block devices.
By using this GPT GUID, the NFSv4.1 pNFS block server can now
label the block devices under its control and thus eliminating the
immediate conflict that may occur at the NFSv4.1 client operating system.

Working Group Summary

The NFSv4.1 working group had immediate consensus for the need
of the definition/documentation of an identifying mechanism for
the pNFS block layout.

Document Quality

GPT GUID usage is well understood and implemented. This I-D
provides a documentation/definition point. A central
registration mechanism does not exist for GPT GUIDs. Given the
use case of NFSv4.1 pNFS block devices, the documentation of
the pNFS GPT GUID in an IETF RFC best suites the need of the
community.

I-D has completed working group last call and has been reviewed by the
document shepherd.  The I-D is ready for IESG review and IETF last call
on the way to publication on the standards track.