Hi Christian, since draft-ietf-nfsv4-pnfs-block-10 is an extension for block and volume-based layout of http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-26.tx t and more information about recovery can be found in that NFSv4.1 document. Ciao Hannes >-----Original Message----- >From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On >Behalf Of ext Christian Vogt >Sent: 04 December, 2008 14:42 >To: IETF Discussion Mailing List >Cc: nfsv4-chairs@xxxxxxxxxxxxxx; fridella_stephen@xxxxxxx; >black_david@xxxxxxx; nfsv4-ads@xxxxxxxxxxxxxx; jglasgow@xxxxxxxxxxxx >Subject: Review of draft-ietf-nfsv4-pnfs-block-10 > >I was asked by the IESG to review the "pNFS Block/Volume Layout" >specification [draft-ietf-nfsv4-pnfs-block-10], and I am >sharing my review on this list. The specification is overall >in good shape and should proceed for publication soon. I do >suggest addressing the following comments, though, before >forwarding the document to the RFC Editor. > >Technical: > >- Section 2.2.1 ("Volume Identification") specifies two methods for > identifying a position on a disk: by positive offset starting at the > beginning of the disk, and by negative offset starting at the end of > the disk. The second method is limited to implementations where > server and client have the same understanding of the disk size. This > method could be generalized: If you defined an offset, positive or > negative, to be in the context of the disk size as seen by the > client, then you may potentially also support implementations where > server and clients have a different understanding of the disk size. > The authors may consider this. > >- Section 2.4 ("Crash Recovery Issues") specifies recovery procedures > that a client could initiate following a server crash. These > procedures apply in one specific condition, which is defined at the > beginning of the section ("When the server crashes while the client > holds a writable layout, and the client has written data to blocks > covered by the layout, and the blocks are still in the > PNFS_BLOCK_INVALID_DATA state, [then]..."). The section should also > consider other conditions. It may be sufficient to explain why only > the described condition requires recovery. > >- Section 2.4 ("Crash Recovery Issues") does not explain how a client > detects a server crash. The section should briefly explain this. It > may be sufficient to mention that crash detection is specified in a > related document, or that it is implementation-specific. > >Editorial: > >- The specification uses undefined acronyms in a couple of places, > including in the title. Those should be spelled out when mentioned > the first time. Search for "pNFS", "SAN", "XDR", "LUN" to find the > relevant places in the specification. > >Best regards, >- Christian > > >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf