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

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: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