I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-nfsv4-pnfs-obj-09.txt Reviewer: Brian Carpenter Review Date: 2008-11-28 IESG Telechat date: 04 Dec 2008 Summary: Almost ready, some queries and nits (no response to Last Call review sent 2008-10-22) Comments: My understanding is that the current specification of OSD is expected to be updated in a big way for Version 2 of OSD, and that there is very little deployment of OSDv1. I can't judge the utility of defining a pNFS to OSDv1 mapping at this time, but I do wonder whether this is really appropriate for the standards track rather than Experimental (or Informational, if it documents current practice). I don't see any goal or milestone in the WG charter for this work, but the charter hasn't been updated since 2003 anyway. It is impossible to review this in detail for technical content unless the reviewer is an expert on NFSv4 and OSD, which I am not. So these are mainly comments on form rather than content. The document is generally of good quality. > 11. Client Fencing > > In cases where clients are uncommunicative and their lease has > expired or when clients fail to return recalled layouts in a timely > manner the server MAY revoke client layouts and/or device address > mappings and reassign these resources to other clients. What does "in a timely manner" mean? Is there a specific timer specified for this, in which case there should be a cross-reference? If not, there should be a statement about what determines the timeout and what the default value should be. _________________________________________________ Normative reference issues: > [2] Weber, R., "SCSI Object-Based Storage Device Commands", > July 2004, . This looks like it's a draft, so could be a problem as a normative reference. > Note that the XDR code contained in this document depends on types > from the NFSv4.1 nfs4_prot.x file ([8]). IMHO [8] should therefore be a normative reference. > The deviceid4 data > type is defined in NFSv4.1 draft [9]. Ditto for [9] > The client MAY still use other > discovery mechanisms such as iSNS [16] to locate the device Ditto for [16] I think, despite the "such as". _________________________________________________ Nits: > Abstract ... > Internet Draft, > which is currently draft-ietf-nfsv4-minorversion1-23. Needless to say this is out of date, and it will be an RFC by the time the present document is an RFC itself. Just delete the phrase? The XDR code includes /// * /// * Copyright (C) The IETF Trust (2007-2008) /// * All Rights Reserved. /// * /// * Copyright (C) The Internet Society (1998-2006). /// * All Rights Reserved. I believe this is inconsistent with the latest (draft) requirements of the IETF Trust. This may be a test case, but according to http://trustee.ietf.org/policyandprocedures.html , I believe that the code should simply say: /// * This code was derived from IETF RFC /// * [[RFC Editor: please insert RFC number]]. /// * Please reproduce this note if possible. [5] IBM, IBM, Cisco Systems, Hewlett-Packard Co., and IBM, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004, . [7] Hewlett-Packard Co., Hewlett-Packard Co., and Hewlett-Packard Co., "T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names", RFC 3980, February 2005, . These should be cited by author names like any other RFC.