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

[Lars Eggert <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art