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

[Chuck Lever <[e-mail]>]

Hi Karen-


> On Apr 18, 2017, at 6:32 PM, karen deitke <[e-mail]> wrote:
> 
> Hi Chuck, its unclear what you mean by "is prepared to process" in the text below. 

Fair enough, that's an awkward turn of phrase, and I had some
difficulty coming up with the right language.

Suppose this limit is based on what's in the COMPOUND? Like the
server supports 6 Read chunks for WRITE operations, but only 1
Read chunk for SYMLINK operations?

Can you give some alternatives? That would help me understand
what other readers find ambiguous.


> 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
>> Given that 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

--
Chuck Lever