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

[Chuck Lever <[e-mail]>]

Hi Tom-

> On Apr 18, 2017, at 11:08 PM, Tom Talpey <[e-mail]> wrote:
> 
> 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.

I agree this kind of thing is tricky. I wrote it as "the server MUST
reject the RPC". That's the single requirement. The choice is how the
rejection is conveyed to the client.


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

The Solaris server can return an RPC-level error in cases like this.
I think there are similar choices allowed in rfc5666bis. Let's say
that in a perfect world, I would go with only ERR_CHUNK, but I'm
documenting existing implementation behavior here.

I'm not sure it matters to the client: both errors are permanent and
the RPC is terminated on the client.

I'm open to alternatives.


> 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
>> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever