Re: [Gen-art] Gen-ART LC Review of draft-ietf-nfsv4-rpcrdma-07.txt

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:lars.eggert@nokia.com] 
> Sent: Monday, May 05, 2008 8:03 AM
> To: Eric Gray
> Cc: Tom Talpey; Brent Callaghan; gen-art@ietf.org
> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art