Last Call Review of draft-ietf-nfsv4-scsi-layout-05
review-ietf-nfsv4-scsi-layout-05-opsdir-lc-kuarsingh-2016-08-16-00

Dear Authors,



I have reviewed this document as part of the Operational directorate's 


ongoing effort to review all IETF documents being processed by the 


IESG.  These comments were written with the intent of improving the 


operational aspects of the IETF drafts. Comments that are not addressed 


in last call may be included in AD reviews during the IESG review.  


Document editors and WG chairs should treat these comments just like any 


other last call comments.




Document Reviewed - Parallel NFS (pNFS) SCSI Layout


Link to Document - 


https://tools.ietf.org/html/draft-ietf-nfsv4-scsi-layout-06






Summary:



The document reviewed is intended to provide an extension of pNFS 


(Parallel Network File System) providing a Layout Type for the use of 


SCSI block storage devices.  The original pNFS standard was documented 


in RFC5663 and updated by RFC6688 (Block Disk Protection).






The document details the client and server technical implementation 


details for the new Layout Type along with the XDR description of the 


NFSv4.1 SCSI layout.




General Comments and Feedback:



The document is well written and no specific textual changes (i.e. NITs, 


edits) are recommended by this review.  Overall the document fully 


describes proposed standard and use of the new Layout Type for pNFS 


operation.






There are two generic comments from this review which the author(s) can 


consider with respect to operational considerations.





(1). Operational Considerations Section [Minor]



Throughout the document, many of the operational considerations are in 


fact noted, but are within the body text.  Although this is valid, the 


author(s) may consider highlighting those considerations in a separate 


section (perhaps before/after Security Considerations Section) to help a 


new ready quickly understand the mail challenges which considering the 


use of this Layout for specific implementations.






An example of such a consideration would be in the fourth (4th) 


paragraph on page 7 which notes that SCSI devices are generally not 


capable of enforcing such file-based security in environments were pNFS 


clients cannot be trusted.  Since this is a potential use scenario, it 


would be good to have such items specifically noted and highlighted.




This is not necessary, but only recommended.

(2). Layout Requests and Extent Lists [Minor]



Section 2.4.1 outlines criteria for extent list returns. Bullet's 1 and 


2 provide both the allowed and not allowed extent returns.  Although 


technically correct, if the not allowed extents are going to be listed 


(which makes sense to ensure the implementer understands what's 


allowed), perhaps sub-bullets can be used to highlight those (e.g. 


PNFS_SCSI_INVALID_DATA) or a more clear "SHALL NOT" (keyword) such as " 


but SHALL NOT return PNFS_SCSI_INVALID_DATA or PNFS_SCSI_READ_WRITE_DATA 


extends".





Textual Review, questions and feedback:

None recommended.