David, Thank you to Ben for the review. His comment on "GETDEVICEINFO" points out a problem in the draft. The problem is that the preceding paragraph references GETDEVICELIST, where it should really reference GETDEVICEINFO.
So, in section "2.2.2 Volume Topology", the text: The "pnfs_block_device_addr4" data structure is returned by the server as the storage-protocol-specific opaque field da_addr_body in the "device_addr4" structure by a successful GETDEVICELIST operation. [NFSV4.1]. should read as: The "pnfs_block_device_addr4" data structure is returned by the server as the storage-protocol-specific opaque field da_addr_body in the "device_addr4" structure by a successful GETDEVICEINFO operation. [NFSV4.1]. -Jason On Tue, Nov 18, 2008 at 6:14 PM, Ben Campbell <[EMAIL PROTECTED]> wrote: > > On Nov 18, 2008, at 4:52 PM, [EMAIL PROTECTED] wrote: > > Ben, >> >> Thanks for doing this review. >> >> -- Section 2.3.4, second paragraph, last sentence: >>> >>> This policy SHOULD be implemented when >>>> storage devices do not provide atomicity for concurrent >>>> >>> read/write >> >>> and write/write operations to the same data. >>>> >>> >>> I wonder why that's not a MUST. It seems like the result of neither >>> providing atomic operations, or implementing this policy, would result >>> >> >> in corruption, right? Isn't it safe to say that the client MUST NOT >>> create corruption? >>> >> >> That's actually from 2.3.5, and yes, we'll do something like that - >> a MUST or MUST NOT is clearly called for here. >> > > Good, thanks! > > >> >> -- Section 3, paragraph 2: >>> >>> In environments where the >>>> security requirements are such that client-side protection from >>>> access to storage outside of the layout is not sufficient pNFS >>>> block/volume storage layouts for pNFS SHOULD NOT be used, unless >>>> >>> the >> >>> storage device is able to implement the appropriate access >>>> >>> checks, >> >>> via use of virtualized block addresses, or other means. >>>> >>> >>> Maybe this is my ignorance of the subject talking, but I have to >>> wonder what sort of environment might exist where it is sufficient to >>> >> >> allow client-side protection only for this sort of thing. It seems >>> like a malicious client could cause all sorts of mayhem. >>> >> >> The motivation is a physically isolated SAN where all the servers are >> trusted. FWIW, early versions of this technology worked over parallel >> SCSI cables, and the block layout is designed to be used this way if >> desired. >> >> > Ok, understood. > > [Nits and Editorial] >>> >>> -- IDNITs reports that Page 1 is too long (59 lines) >>> >>> -- Section 2.2.2, last paragraph: >>> >>> In the case of the server >>>> returning NFS4ERR_TOOSMALL the client SHOULD allocate a buffer of >>>> >>> at >> >>> least gdir_mincount_bytes to contain the expected result and >>>> >>> retry >> >>> the GETDEVICEINFO request. >>>> >>>> >>> Should this be GETDEVICELIST? I don't see a prior reference to an >>> initial GETDEVICEINFO request. >>> >> >> I believe you've found a think-o. We'll double-check this and correct >> it. >> >> > Great, thanks! > > Thanks, > > Ben. > > > > Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> >> >> -----Original Message----- >>> From: Ben Campbell [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, November 04, 2008 5:51 PM >>> To: General Area Review Team; Black, David; fridella, >>> stephen; [EMAIL PROTECTED] >>> Cc: Lars Eggert; [EMAIL PROTECTED]; [EMAIL PROTECTED]; >>> [EMAIL PROTECTED] >>> Subject: Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09 >>> >>> 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 resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> >>> Document: draft-ietf-nfsv4-pnfs-block-09 >>> Reviewer: Ben Campbell >>> Review Date: 2008-11-04 >>> IETF LC End Date: 2008-11-27 >>> >>> Summary: >>> >>> This draft is almost ready for publication as a proposed standard. I >>> have a couple of questions that I think should be considered first, >>> and a couple of nits. >>> >>> Comments: >>> >>> [Disclaimer] >>> >>> While it is normal for a Gen-ART reviewer to be inexpert in the >>> subject matter being reviewed, I found myself feeling much more >>> inexpert than usual while reviewing this draft. This is due to the >>> subject matter, not the presentation, which seems to be clear in >>> general. >>> >>> >>> [substantive] >>> >>> -- Section 2.3.4, second paragraph, last sentence: >>> >>> This policy SHOULD be implemented when >>>> storage devices do not provide atomicity for concurrent >>>> >>> read/write >>> >>>> and write/write operations to the same data. >>>> >>> >>> I wonder why that's not a MUST. It seems like the result of neither >>> providing atomic operations, or implementing this policy, >>> would result >>> in corruption, right? Isn't it safe to say that the client MUST NOT >>> create corruption? >>> >>> -- Section 3, paragraph 2: >>> >>> In environments where the >>>> security requirements are such that client-side protection from >>>> access to storage outside of the layout is not sufficient pNFS >>>> block/volume storage layouts for pNFS SHOULD NOT be >>>> >>> used, unless >>> >>>> the >>>> storage device is able to implement the appropriate >>>> >>> access checks, >>> >>>> via use of virtualized block addresses, or other means. >>>> >>> >>> Maybe this is my ignorance of the subject talking, but I have to >>> wonder what sort of environment might exist where it is >>> sufficient to >>> allow client-side protection only for this sort of thing. It seems >>> like a malicious client could cause all sorts of mayhem. >>> >>> >>> [Nits and Editorial] >>> >>> -- IDNITs reports that Page 1 is too long (59 lines) >>> >>> -- Section 2.2.2, last paragraph: >>> >>> In the case of the server >>>> returning NFS4ERR_TOOSMALL the client SHOULD allocate a >>>> >>> buffer of >>> >>>> at >>>> least gdir_mincount_bytes to contain the expected result >>>> >>> and retry >>> >>>> the GETDEVICEINFO request. >>>> >>>> >>> Should this be GETDEVICELIST? I don't see a prior reference to an >>> initial GETDEVICEINFO request. >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> >>> >>> >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
