Eric, thanks for the quick response! Authors, you're off the hook :-)
Lars On 2008-5-5, at 15:09, ext Eric Gray wrote: > Lars, > > Russ Housely pinged me about this earlier and provided me > with a pointer to the -08 version. At that time, I indicated to > Russ that I felt the changes (between -07 and -08) addressed my > comments. > > I probably should have responded to the entire list at that > point, but did not... > > Thanks! > > -- > Eric Gray > Principal Engineer > Ericsson > >> -----Original Message----- >> From: Lars Eggert [mailto:[EMAIL PROTECTED] >> Sent: Monday, May 05, 2008 8:03 AM >> To: Eric Gray >> Cc: Tom Talpey; Brent Callaghan; [email protected] >> Subject: Re: Gen-ART LC Review of draft-ietf-nfsv4-rpcrdma-07.txt >> Importance: High >> >> Hi, authors, >> >> while you're getting ready to engage with Lisa on her >> DISCUSS, please >> also review the gen-art review below and send me an RFC Editor Note >> with any changes you'd like to make. >> >> Lars >> >> On 2008-3-27, at 13:20, ext Eric Gray wrote: >> >>> Author(s), >>> >>> 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-rpcrdma-07.txt >>> >>> Reviewer: Eric Gray >>> Review Date: 03/17/2008 >>> >>> Summary: >>> >>> This document is nearly ready to publish as a Proposed Standard >>> RFC. >>> >>> COMMENTS/QUESTIONS >>> ================== >>> >>> In the first paragraph of section 3, there is some text about >>> the fact that the RDMA header is analogous to record marking, >>> as used for RPC over TCP, but is more extensive, because "RDMA >>> transports support several modes of data transfer" and we want >>> to allow the client and server to use efficient transfer modes. >>> >>> Is the transfer mode negotiable between the client and server, >>> or are more efficient modes simply well enough defined that >>> either could make this decision on its own? >>> __________________________________________________________________ >>> >>> In the last paragraph before section 3.1, you include this >>> (paraphrased) text: >>> >>> "An upper layer may [...] define an exchange to dynamically >>> enable RPC/RDMA on an existing RPC association. Any such >>> exchange must be carefully architected so as to prevent any >>> ambiguity as to the framing in use for each side of the >>> connection." >>> >>> This does not look like the sort of statement we should be >>> making in a proposed standard. The entire (paraphrased) >>> quote above - especially the phrase "must be carefully >>> architected" - is at least a little too vague. Does this >>> specification (or another) provide support for this as an >>> option? Are there pre-conditions and signaling needs at >>> the higher layer? Or, is it enough simply to say that the >>> same approach must be consistently used within any single >>> message? >>> >>> It sounds like this is something that needs to be defined at >>> a specific level (such as at the application level) and that >>> entities at that level need to ensure that specific things >>> are correctly handled. In this case, I'm being vague because >>> I don't know the protocols involved well enough to be more >>> specific about what "specific things" and "correctly handled" >>> mean - but I strongly suspect that "carefully architected" >>> doesn't cover it. >>> >>> My suggestion is to remove (or rephrase) the last 3 sentences >>> in that paragraph, including the two paraphrased above and the >>> one that follows them. >>> __________________________________________________________________ >>> >> >> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
