Skip to main content

Shepherd writeup

Working Group:  NFSv4
Area Director:  David Harrington
Document Author/Shepherd:  Spencer Shepler (

Internet Draft:


  (1.a) Spencer Shepler ( 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