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

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

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of
> Benny Halevy
> Sent: Thursday, July 07, 2011 9:44 AM
> To: david.black@emc.com
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] FW: New Version Notification for draft-faibish-nfsv4-
> pnfs-block-disk-protection-01.txt
> 
> On 2011-07-07 19:34, 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 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
> >
> >
> >> -----Original Message-----
> >> From: Benny Halevy [mailto:bhalevy@tonian.com]
> >> Sent: Thursday, July 07, 2011 11:06 AM
> >> To: faibish, sorin; Black, David
> >> Cc: nfsv4@ietf.org
> >> Subject: Re: [nfsv4] FW: New Version Notification for
> >> draft-faibish-nfsv4-pnfs-block-disk-protection-
> >> 01.txt
> >>
> >> I remember that too.
> >> How about make that revision and resubmitting?
> >> -----Original Message-----
> >> From: sfaibish <sfaibish@emc.com>
> >> Date: Thu, 07 Jul 2011 10:44:23
> >> To: Benny Halevy<bhalevy@tonian.com>; <david.black@emc.com>
> >> Reply-To: sfaibish@emc.com
> >> Cc: <nfsv4@ietf.org>
> >> Subject: Re: [nfsv4] FW: New Version Notification for	draft-faibish-
> nfsv4-pnfs-block-disk-protection-
> >> 01.txt
> >>
> >> 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 <bhalevy@tonian.com>
> >> wrote:
> >>
> >>> 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
> >>>
> >>> On 2011-07-06 20:58, david.black@emc.com wrote:
> >>>> 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
> >>>> david.black@emc.com        Mobile: +1 (978) 394-7754
> >>>> ----------------------------------------------------
> >>>>
> >>>> -----Original Message-----
> >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >>>> Sent: Wednesday, July 06, 2011 1:55 PM
> >>>> To: Black, David
> >>>> Cc: Black, David; faibish, sorin; jglasgow@google.com
> >>>> 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
> >>>>
> >>>> _______________________________________________
> >>>> nfsv4 mailing list
> >>>> nfsv4@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/nfsv4
> >>> _______________________________________________
> >>> nfsv4 mailing list
> >>> nfsv4@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/nfsv4
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards
> >>
> >> Sorin Faibish
> >> Corporate Distinguished Engineer
> >> Unified Storage Division
> >>          EMC²
> >> where information lives
> >>
> >> Phone: 508-249-5745
> >> Cellphone: 617-510-0422
> >> Email : sfaibish@emc.com
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4