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
- [nfsv4] FW: New Version Notification for draft-fa… david.black
- Re: [nfsv4] FW: New Version Notification for draf… Spencer Shepler
- Re: [nfsv4] FW: New Version Notification for draf… sfaibish
- Re: [nfsv4] FW: New Version Notification for draf… Benny Halevy
- Re: [nfsv4] FW: New Version Notification for draf… sfaibish
- Re: [nfsv4] FW: New Version Notification for draf… Benny Halevy
- Re: [nfsv4] FW: New Version Notification for draf… david.black
- Re: [nfsv4] FW: New Version Notification for draf… Benny Halevy
- Re: [nfsv4] FW: New Version Notification for draf… Spencer Shepler
- Re: [nfsv4] FW: New Version Notification for draf… Jim Rees
- Re: [nfsv4] FW: New Version Notification for draf… Jason Glasgow
- Re: [nfsv4] FW: New Version Notification for draf… Jason Glasgow
- Re: [nfsv4] FW: New Version Notification for draf… Spencer Shepler
- Re: [nfsv4] FW: New Version Notification for draf… david.black
- Re: [nfsv4] FW: New Version Notification for draf… Spencer Shepler
- Re: [nfsv4] FW: New Version Notification for draf… david.black
- Re: [nfsv4] FW: New Version Notification for draf… Nico Williams
- Re: [nfsv4] FW: New Version Notification for draf… Jim Rees