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
