Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

[Tom Talpey <[e-mail]>]

I noticed the same thing, and I'll add that the MUST reject condition
is very confusing because it allows an "or". In my opinion a MUST is
always a single requirement, never ambiguous.

Is there some reason you want to allow such a choice? I think you'll
find that, worded properly, it becomes actually much less implementable
and interoperable than you may think.

Tom.

On 4/18/2017 6:32 PM, karen deitke wrote:
> Hi Chuck, its unclear what you mean by "is prepared to process" in the text below.
> Other than that, looks good.
>
> Karen
>
>  5.4.1
>    If an NFS version 4 client sends an RPC Call with a Write list that
>    contains more chunks than an NFS version 4 server is prepared to
>    process, the server MUST reject the RPC by responding with an
>    RDMA_ERROR message with the rdma_err value set to ERR_CHUNK.
>
>
>    If an NFS version 4 client sends an RPC Call with a Read list that
>    contains more chunks than an NFS version 4 server is prepared to
>    process, the server MUST reject the RPC by responding with an
>    RDMA_MSG message containing an RPC Reply with an accept status of
>    GARBAGE_ARGS, or with an RDMA_ERROR message with the rdma_err value
>    set to ERR_CHUNK.
>
>
> On 4/18/2017 1:21 PM, David Noveck wrote:
>> *Overall Evaluation*
>> *
>> *
>> Major improvement over RFC5667.  Almost ready to ship.  No technical
>> issues.
>>
>> A lot of my comments are basically editorial and are offered on a
>> take-it-or-lease-it basis.
>>
>> I think some clarification in Section 5.4.1 is needed although not
>> necessarily in the ways suggested below,
>>
>> *Comments by Section*
>> *5.4.1. Multiple DDP-eligible Data Items*
>> Giventhat READ_PLUS no longer has any DDP-eligible data items, the
>> situation described in the fifth bullet can no longer arise. I suggest
>> deleting the bullet.
>> The penultimate paragraph can be read as applying to some situations
>> in which it shouldn't and where the extra chunks would very naturally
>> ignored. For example, if you had on write chunk together with a READ
>> operation which failed, the server would have more chunks (i.e. one)
>> than the number it is prepared to process (i.e. zero). Suggest, as a
>> possible replacement:
>>
>>     Normally, when an NFS version 4 client sends an RPC Call with a
>>     Write list that contains multiple chunks. each such, when matched
>>     with a DDP-eligible data item in the response, directs the
>>     placement of the data item as specified by
>>     [I.D.-nfsv4-rfc5666bis]. When there are DDP-eligible data items
>>     matched to write chunks that an NFS version 4 server is not
>>     prepared to process, the server MUST reject the RPC by responding
>>     with an RDMA_ERROR message with the rdma_err value set to ERR_CHUNK.
>>
>> With regard to the last paragraph, I am curious that this paragraph,
>> unlike the previous one, allows GARBGEARGS. Is this so because that
>> would be allowed if the chunks in question had offsets other than
>> those that correspond to DDP-eligible data items? If so, please
>> consider the following possible replacement.
>>
>>     Normally, when an NFS version 4 client sends an RPC Call with a
>>     Read list that contains multiple chunks, each such, when properly
>>     matched with a DDP-eliigible data item in the request, directs the
>>     fetching of the the data item as specified by
>>     [I.D.-nfsv4-rfc5666bis]. When there are DDP-eligible data items
>>     matched to read chunks that an NFS version 4 server is not
>>     prepared to process, the server MUST reject the RPC by responding
>>     with an RDMA_ERROR message with the rdma_err value set to ERR_CHUNK.
>>
>> *5.6. Session-Related Considerations*
>> In the third sentence of the second paragraph, suggest replacing "no
>> different" by "not different".
>> In the last sentence of the last paragraph, suggest replacing "is not"
>> by "were not"
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>