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

Spencer Shepler <sshepler@microsoft.com> Thu, 07 July 2011 19:03 UTC

Return-Path: <sshepler@microsoft.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC3B21F8569 for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.523
X-Spam-Level:
X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EolqDxUEIFzl for <nfsv4@ietfa.amsl.com>; Thu, 7 Jul 2011 12:03:56 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CC5A021F8539 for <nfsv4@ietf.org>; Thu, 7 Jul 2011 12:03:55 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 7 Jul 2011 12:03:55 -0700
Received: from TK5EX14MBXC124.redmond.corp.microsoft.com ([169.254.4.62]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0289.008; Thu, 7 Jul 2011 12:03:55 -0700
From: Spencer Shepler <sshepler@microsoft.com>
To: Jason Glasgow <jglasgow@google.com>, Jim Rees <rees@umich.edu>, Benny Halevy <bhalevy@tonian.com>
Thread-Topic: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
Thread-Index: AQHMPMzEItXlWF0fnEmmQvqc/labQ5ThNfuw
Date: Thu, 07 Jul 2011 19:03:54 +0000
Message-ID: <E043D9D8EE3B5743B8B174A814FD584F1FDC0E14@TK5EX14MBXC124.redmond.corp.microsoft.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392870@MX14A.corp.emc.com> <4E15C1B5.5070600@tonian.com> <op.vx8679iyunckof@usensfaibisl2e.eng.emc.com> <1746881557-1310051155-cardhu_decombobulator_blackberry.rim.net-585899366-@b27.c3.bise3.blackberry> <7C4DFCE962635144B8FAE8CA11D0BF1E0589392A9A@MX14A.corp.emc.com> <4E15E259.2090208@tonian.com> <20110707170428.GA26714@merit.edu> <CAP_8SaeM5fn7uLXoOU8XsQ4hdRZP=eLXhi7p51kaFHDOyJ7uyQ@mail.gmail.com> <CAP_8SacPC9nSMOe_jtjpWaP6Vv2ouQf+Fgi7wmBNpWehDJR0hw@mail.gmail.com>
In-Reply-To: <CAP_8SacPC9nSMOe_jtjpWaP6Vv2ouQf+Fgi7wmBNpWehDJR0hw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_E043D9D8EE3B5743B8B174A814FD584F1FDC0E14TK5EX14MBXC124r_"
MIME-Version: 1.0
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-pnfs-block-disk-protection-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2011 19:03:57 -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:jglasgow@google.com]
Sent: Thursday, July 07, 2011 10:39 AM
To: Jim Rees; Benny Halevy
Cc: nfsv4@ietf.org; 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).

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


On Thu, Jul 7, 2011 at 1:12 PM, Jason Glasgow <jglasgow@google.com<mailto:jglasgow@google.com>> wrote:
The GPT is defined in

Extensible Firmware Interface
Specification
Version 1.10
December 1, 2002

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

-Jason

On Thu, Jul 7, 2011 at 1:04 PM, Jim Rees <rees@umich.edu<mailto:rees@umich.edu>> wrote:
Benny Halevy wrote:

 On 2011-07-07 19:34, david.black@emc.com<mailto:david.black@emc.com> wrote:
 > I don't think the two of you have the same memory :-).
 >
 > What's the problem with use of GPT?

 There is no formal standard for it as far as I see
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.
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org<mailto:nfsv4@ietf.org>
https://www.ietf.org/mailman/listinfo/nfsv4