Subject: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt

From: <[email-masked]>
Date: Wed, 6 Jul 2011 13:58:33 -0400

A new version of the draft explaining how to use the GPT (GUID partition table) to protect
pNFS block devices from access when the pNFS server can't be contacted (e.g., during early
stages of boot) has been posted.  This has been shortened and focused from the -00 version.

Would the keeper of the Quebec City agenda please include a short slot for this draft?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 1:55 PM
To: Black, David
Cc: Black, David; faibish, sorin; [email-masked]
Subject: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt

A new version of I-D, draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt has been successfully submitted by David Black and posted to the IETF repository.

Filename:	 draft-faibish-nfsv4-pnfs-block-disk-protection
Revision:	 01
Title:		 pNFS block disk protection
Creation date:	 2011-07-08
WG ID:		 Individual Submission
Number of pages: 6

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 adds a mechanism to RFC 5663 that
   enables clients to identify 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.

The IETF Secretariat

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 6 Jul 2011 18:09:09 +0000

Yes, I will add this to the agenda.  Thanks for the update.

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, July 06, 2011 10:59 AM
> To: [email-masked]
> Subject: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-
> pnfs-block-disk-protection-01.txt
> 
> A new version of the draft explaining how to use the GPT (GUID partition
> table) to protect pNFS block devices from access when the pNFS server
> can't be contacted (e.g., during early stages of boot) has been posted.
> This has been shortened and focused from the -00 version.
> 
> A new version of I-D, draft-faibish-nfsv4-pnfs-block-disk-protection-
> 01.txt has been successfully submitted by David Black and posted to the
> IETF repository.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: sfaibish <[email-masked]>
Date: Wed, 06 Jul 2011 15:35:28 -0400

I think I already asked for a slot in a previous email.

/Sorin

On Wed, 06 Jul 2011 14:09:09 -0400, Spencer Shepler  
<[email-masked]> wrote:

>> Would the keeper of the Quebec City agenda please include a short slot  
>> for
>> this draft?
>>
>> Thanks,
>> --David
>> Subject: New Version Notification for  
>> draft-faibish-nfsv4-pnfs-block-disk-
>> protection-01.txt
>>

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Benny Halevy <[email-masked]>
Date: Thu, 07 Jul 2011 17:24:53 +0300

Isn't it a problem to have this draft on the proposed standard track
while it builds and references the non-standard GPT structure.

I can see this going in the "best practices" informational RFC
direction.

Benny

---

From: sfaibish <[email-masked]>
Date: Thu, 07 Jul 2011 10:44:23 -0400

I thought we already decided in Prague. No, I don't think so.

/Sorin

On Thu, 07 Jul 2011 10:24:53 -0400, Benny Halevy <[email-masked]>  
wrote:

>> for this draft?
>> draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
>>
>> A new version of I-D,  
>> draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt has been  
>> successfully submitted by David Black and posted to the IETF repository.
>>

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: "Benny Halevy" <[email-masked]>
Date: Thu, 7 Jul 2011 15:05:55 +0000

I remember that too.
How about make that revision and resubmitting? 
-----Original Message-----
From: sfaibish <[email-masked]>
Date: Thu, 07 Jul 2011 10:44:23 
To: Benny Halevy<[email-masked]>; <[email-masked]>
Reply-To: [email-masked]
Cc: <[email-masked]>
Subject: Re: [nfsv4] FW: New Version Notification for	draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt

/Sorin

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 12:34:42 -0400

I don't think the two of you have the same memory :-).

What's the problem with use of GPT?

Thanks,
--David

> From: Benny Halevy [mailto:[email-masked]]
> Sent: Thursday, July 07, 2011 11:06 AM
> To: faibish, sorin; Black, David
> Cc: [email-masked]

---

From: Benny Halevy <[email-masked]>
Date: Thu, 07 Jul 2011 19:44:09 +0300

> What's the problem with use of GPT?

There is no formal standard for it as far as I see
so it may change without notice (wikipedia is really a good place
to define standards :)
Where are you registering the proposed GUID so it won't clash with
another one (yeah, I realize it's a huge namespace, but still...)?

Benny

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Jul 2011 16:46:05 +0000

Given that this seems to be defining convention such that others
may find a definition of the behavior, my suggestion had been
that this work should be an information RFC.

Spencer

> Benny Halevy
> Sent: Thursday, July 07, 2011 9:44 AM
> To: [email-masked]
> Cc: [email-masked]
> There is no formal standard for it as far as I see so it may change
> without notice (wikipedia is really a good place to define standards :)
> Where are you registering the proposed GUID so it won't clash with another
> one (yeah, I realize it's a huge namespace, but still...)?
> 
> Benny
> 
> >
> > Thanks,
> > --David
> >
> >
> >> Subject: Re: [nfsv4] FW: New Version Notification for
> >> Subject: Re: [nfsv4] FW: New Version Notification for	draft-faibish-
> nfsv4-pnfs-block-disk-protection-
> >> 01.txt
> >>
> >>>> A new version of the draft explaining how to use the GPT (GUID
> >>>> partition table) to protect pNFS block devices from access when the
> >>>> pNFS server can't be contacted (e.g., during early stages of boot)
> >>>> has been posted.  This has been shortened and focused from the -00
> >>>> version.
> >>>>
> >>>> David L. Black, Distinguished Engineer EMC Corporation, 176 South
> >>>> St., Hopkinton, MA  01748

---

From: Jim Rees <[email-masked]>
Date: Thu, 7 Jul 2011 13:04:28 -0400

Benny Halevy wrote:

Isn't it part of UEFI?  Which may be problematical if it requires a license,
but would still be a published standard.

Besides, Wikipedia says it's a standard, so it must be true.

---

From: Jason Glasgow <[email-masked]>
Date: Thu, 7 Jul 2011 13:12:01 -0400

The GPT is defined in

Extensible Firmware Interface
Specification
Version 1.10
December 1, 2002

http://www.intel.com/technology/efi/efiagree.htm

-Jason

---

From: Jason Glasgow <[email-masked]>
Date: Thu, 7 Jul 2011 13:38:55 -0400

As suggested, the GPT is also defined in UEFI specification.
http://www.uefi.org/specs/download/UEFI_Spec_2_3_1.pdf, so I think this RFC
should still be on the standards track.

As for using the GUID in the document, at the risk of quoting Wikipedia
(again),

A *globally unique identifier* (*GUID*, 
/<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>
> ˈ <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɡ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>
> uː <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɪ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>
> d <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>/<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>
>  or / <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>ˈ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>
> ɡ <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>w<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>
> ɪ <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>d<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>
> / <http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>) is a unique
> reference number used as an identifier in computer software<http://en.wikipedia.org/wiki/Computer_software>.
> The term *GUID*also is used for Microsoft<http://en.wikipedia.org/wiki/Microsoft>'s
> implementation of the Universally Unique Identifier<http://en.wikipedia.org/wiki/Universally_Unique_Identifier> (UUID)
> standard.
> The value of a GUID is represented as a 32-character hexadecimal<http://en.wikipedia.org/wiki/Hexadecimal> string,
> such as {21EC2020-3AEA-1069-A2DD-08002B30309D}, and is usually stored as a
> 128-bit integer. The total number of unique keys is 2128 or 3.4×1038. This
> number is so large that the probability of the same number being generated
> randomly twice is negligible.
> Still, certain techniques have been developed to help ensure that GUID
> numbers are not duplicated (see Algorithm<http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm>
>  below).

Responding directly to Benny's question about the GUID:

The UEFI specification defines only three partition types, and proscribes
that "OS vendors need to generate their own Partition Type GUIDs to identify
their partition types."  The purpose of using a GUID is to avoid the
necessity of a global registry of partition types (for better or for worse).

-Jason

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Jul 2011 19:03:54 +0000

I don’t have a strong opinion about information/standards track.

Given that the GUID selection is adhoc, I viewed this document
as a method of publishing the selection of the GUID value and its
associate/use with pNFS.  That seemed informational.  We can
close on this at the Quebec City meeting.

Given the purpose of this I-D to publish a GUID value for pFNS block
devices, the I-D takes a long time to get there.  The title should
be changed to something like:

“A pNFS Block Device GPT GUID value”

The GUID value should be in the abstract and the I-D should be
quick to get to the definition.

Obviously the normative reference needs to move from Wikipedia
to either/both the intel and UEFI documents.

Finally, if there exist two block pNFS implementations, wouldn’t
there be a desire (potentially) to have a different GUID value for
each?  If so, there needs to be language in this I-D identifying this
possibility and that if this occurs another RFC should be written
to capture that value.

Spencer

From: Jason Glasgow [mailto:[email-masked]]
Sent: Thursday, July 07, 2011 10:39 AM
To: Jim Rees; Benny Halevy
Cc: [email-masked]; Spencer Shepler
Subject: Re: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt

As suggested, the GPT is also defined in UEFI specification.
http://www.uefi.org/specs/download/UEFI_Spec_2_3_1.pdf, so I think this RFC should still be on the standards track.

As for using the GUID in the document, at the risk of quoting Wikipedia (again),

A globally unique identifier (GUID, [play]  /<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>ˈ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɡ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>uː<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɪ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>d<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>/<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English> or /<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>ˈ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɡ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>w<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>ɪ<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>d<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key>/<http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English>) is a unique reference number used as an identifier in computer software<http://en.wikipedia.org/wiki/Computer_software>. The term GUIDalso is used for Microsoft<http://en.wikipedia.org/wiki/Microsoft>'s implementation of the Universally Unique Identifier<http://en.wikipedia.org/wiki/Universally_Unique_Identifier> (UUID) standard.
The value of a GUID is represented as a 32-character hexadecimal<http://en.wikipedia.org/wiki/Hexadecimal> string, such as {21EC2020-3AEA-1069-A2DD-08002B30309D}, and is usually stored as a 128-bit integer. The total number of unique keys is 2128 or 3.4×1038. This number is so large that the probability of the same number being generated randomly twice is negligible.
Still, certain techniques have been developed to help ensure that GUID numbers are not duplicated (see Algorithm<http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm> below).

The UEFI specification defines only three partition types, and proscribes that "OS vendors need to generate their own Partition Type GUIDs to identify their partition types."  The purpose of using a GUID is to avoid the necessity of a global registry of partition types (for better or for worse).

-Jason

On Thu, Jul 7, 2011 at 1:12 PM, Jason Glasgow <[email-masked]<mailto:[email-masked]>> wrote:
The GPT is defined in

-Jason

On Thu, Jul 7, 2011 at 1:04 PM, Jim Rees <[email-masked]<mailto:[email-masked]>> wrote:
Benny Halevy wrote:

Besides, Wikipedia says it's a standard, so it must be true.
_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 15:21:48 -0400

> each?

No.  The goal is to have a single GUID that can be used by all pNFS block
implementations to enable operating systems to prevent non-pNFS access to
devices used for block pNFS data.  Actual claiming of a pNFS block device
for use with a particular implementation happens via the pNFS protocol,
but that can't be used early in an OS boot sequence.

Thanks,
--David

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Jul 2011 19:34:29 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 07, 2011 12:22 PM
> To: Spencer Shepler
> Cc: [email-masked]
> Subject: RE: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-
> > Finally, if there exist two block pNFS implementations, wouldn’t there
> > be a desire (potentially) to have a different GUID value for each?
> 

The pNFS block client won't differentiate but the pNFS block MDS may, right?
The MDS will certainly scan available devices and determine which are
within its purview.  It is then assumed that all will have the same GUID
and that additional information beyond the GPT/GUID will identify
implementation type and then file system structure.  It then is assumed
that this is left as an exercise to the MDS server implementation?

That is all fine; a brief summary of that would be helpful in the I-D.

BTW: if there is only one GUID, then the "SHOULD" in the I-D should
be a "MUST"?

Spencer

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 15:47:19 -0400

> The pNFS block client won't differentiate but the pNFS block MDS may, right?

Not based on the GPT using this GUID.  The MDS is free to add another GUID to
the GPT for other purposes, but checking for a superblock for the MDS's physical
filesystem layout is a more likely mechanism.

> that this is left as an exercise to the MDS server implementation?

Yes - it already works this way today, although the MDS scan will typically not
see block devices that aren't supposed to be used by the MDS.

> BTW: if there is only one GUID, then the "SHOULD" in the I-D should

"SHOULD" was used because it's up to implementers to decide whether to implement
this. The requirement could be rephrased as a conditional "MUST" - if the
implementation uses GPT access protection of pNFS block devices, then this GUID
MUST be used.

Thanks,
--David

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jul 2011 15:14:04 -0500

On Thu, Jul 7, 2011 at 12:04 PM, Jim Rees <[email-masked]> wrote:
>  > What's the problem with use of GPT?
>

Standards-Track RFCs can (and many do) have normative references to
non-Internet standards, even non-free standards (ASN.1 specs used to
be non-free in the sense that one had to pay to get a copy).

Nico
--

---

From: Jim Rees <[email-masked]>
Date: Thu, 7 Jul 2011 16:23:11 -0400

Nico Williams wrote:

Agreed.  I meant problematical for the implementor, not for the spec writer
(I count myself among the former).