Hi, do you want me to stick this change into the tracker as an RFC Editor Note, or do you prefer to rev the draft?
Lars On 08-11-18 22:19, "ext Jason Glasgow" <[EMAIL PROTECTED]> wrote: > 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. >>>> >>>> >>>> >>>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
