Re: [nfsv4] Ben Campbell's No Objection on draft-ietf-nfsv4-rpcrdma-bidirection-07: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Thanks for the response. That all sounds good.

Thanks!

Ben.

On 2 Mar 2017, at 14:18, Chuck Lever wrote:

>> On Mar 1, 2017, at 3:23 PM, Ben Campbell <[e-mail]> wrote:
>>
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-nfsv4-rpcrdma-bidirection-07: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-bidirection/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Some minor comments:
>>
>> -4.1: This is the first mention of "credits", and there is no definition.
>> I realize that the term is defined in the reference from the previous
>> section. It would be helpful to mention that in the context of that
>> reference.
>
> I can add that.
>
>
>> --  Are there any head-of-line-blocking issues introduced by
>> bidirectional transactions? For example, can a reply get stuck behind
>> requests that are blocked by flow control?
>
> Head-of-line-blocking issues that affect one direction
> should have no impact on the other direction because the
> two directions have independent credit accounting
> mechanisms.
>
>
>> -5.4, 4th paragraph, last sentence: Can a reverse requestor reasonably
>> give up or time out, rather than wait "indefinitely"?
>
> Yes, a timeout is a reasonable response to this situation.
> I can soften this sentence to include that possibility.
>
>
>> -8:  This implies that reverse direction transactions do not change
>> anything.If that is the case, please say so explicitly. For example, Is
>> there any change to authentication for reverse calls?
>
> Reverse calls would make use of a separate authentication
> mechanism and credentials, but would otherwise operate in
> the same fashion as requests in the forward direction. I
> can add a sentence that states this.
>
>
>> I am not an expert
>> in direct memory access transport protocols; are there every situation
>> where authentication depends on an initial request from the client?
>
> The authentication mechanisms are handled by the RPC layer.
> There is no authentication (or integrity or confidentiality
> protection) in RPC transports, whose only responsibility is
> moving bytes. I can add an introductory sentence that states
> this.
>
>
> --
> Chuck Lever