[Gen-art] review of draft-ietf-tsvwg-admitted-realtime-dscp-05.txt
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-tsvwg-admitted-realtime-dscp-05.txt Reviewer: Francis Dupont Review Date: 2008-11-19 IETF LC End Date: 2008-11-27 IESG Telechat date: unknown Summary: Ready Comments: I have minor editorial (== to be handled by default by the RFC Editor) concerns and proposals (ending by '?'): - ToC page 2: Acknowledgements -> Acknowledgments - 1 page 3: I suggest to introduce the EF (Expedited Forwarding) abbrev as soon as possible, i.e.: Expedited Forwarding -> Expedited Forwarding (EF) - 1 page 3: the CAC (Call Admission Control) abbrev must be introduced, i.e.: CAC -> Call Admission Control (CAC) - 1 page 3: I don't like "aka" (use "i.e.," in place of it, or no abbrev?) - 1 page 3: I'd like to get a reference for "e-911" - 1 page 3: e.g. -> e.g., - 1 page 3: the policy ... need -> the policy ... needs ? - 1 page 4: i.e. -> i.e., - 1.1 page 4 (PHB): introduce the DS (Differentiated Services) abbrev here? - 1.1 page 4: the not-introduced PSTN abbrev is questionable. IMHO you should keep it (common abbrev and not necessary for understanding). - 2.1 page 8: more questionable for SLA abbrev. - 2.1 page 8: conaining -> containing - 2.1 page 8: MBPS is *not* an acceptable unit (I propose Mbits/s) - 2.2 page 9: reployed -> deployed - 2.2 page 10: eg., -> e.g., - 2.3 page 10: AAA abbrev: questionable but IMHO should be kept. - 3 page 11: Video classes -> Video classes: ? - 6 page 12 (title): Acknowledgements -> Acknowledgments - 6 page 12 (last character): , -> . Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09
I think I want to rev the draft as Ben's first issue regarding a SHOULD may require some careful wordsmithing - it's not immediately clear to me that just substituting a MUST for the SHOULD will suffice. Thanks, --David > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2008 10:00 AM > To: [EMAIL PROTECTED]; Black, David > Cc: [EMAIL PROTECTED]; gen-art@ietf.org; fridella, stephen; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09 > > 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]
Re: [Gen-art] Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09
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
