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

[David Noveck <[e-mail]>]

> Earlier I had believed we had some historical reasons
> for matching the intent of RFC 5667.

I think we do, where that intent is clear.

> But if we are
> interested only in documenting the behavior of
> existing implementations,

For some of the cases you mention, there is no possible
ambiguity.  The clear intent of RFC5666 and RFC5667
is that multiple READs and WRITEs were supposed to be
allowed and considerable effort was expended in explaining
how they would work.

So it appears that some the things on your liist are bugs.  We
may be forced, for practical reasons, to turn a blind eye to these
bugs for some period of time, but this is not the same sort of
situation as the PZRC-read-chunk issue which is a fairly minor nit
based on text with rfc56667 that defies clear interpretation.  Sigh!

> note that:

interesting/depressing list deleted

> This could be an argument to, in addition, remove a
> large piece of text that discusses multiple Write chunks.

Perhaps it could.

> However, it might be interesting to some to leave
> some flexibility for future use.

Do you mean future use within Version One?  Or we
could limit Version One to what it is now., in the expectation
that it will not exist for very long. Then we
could use base Version Two to implement what
Version One was supposed to be and get a small set
of performance goodies at the same time.

If we on;t want to write off Version One in that way,
we need a reliable means of distinguishing servers
with full COMPOUND support  from those that you
describe.

For example, when you say a server only supports a single READ
operation, what does it do if it gets a COMPOUND with more than
one?  We could have something to work with if:

   - All such servers did the same thing.
   - It didn't result in disconnection or memory corruption.

I thought about an extension adding a full_rdma_compound_support
attribute but that doesn't work for V4.0.

BTW, do any of these old-fashioned servers with these bugs, recognize
and report DDP-eligibility violations?  If not this could be a fool proof
way
to distinguish servers who may have these implememtation gaps from newer
ones that should have full COMPOUND support for RDMA.



On Mon, Feb 27, 2017 at 11:38 AM, David Noveck <[e-mail]> wrote:

> One of the issues that Chuck has to deal with is the need
> to make new implementations interoperable with existing
> implementation.  That has been the source of some new
> MUSTs.
>
> Regarding the use of MUSTs, I think these terms are overused
> in general and that RFC2119's suggestion that these be used
> sparingly (which ironically uses a "MUST") is too often ignored,
> including by  the IESG.
>
> Regarding your suggestion that 5667bis is using "MUST" too
> much, a comparison with RFC5667 is instructive.  Including
> "MUST NOT"s, the RFC2119 term "MUST" Is  used:
>
>    - 22 times in RFC5667, a 10-page spec.
>    - 14 times in rf5667bis-06, an 18-page spec.
>
> Part of Chuck's advantage here is that he deleted a lot of the
> duplication in which RFC5667 ether repeated what was in
> RFC5666 specialized to NFS (useless) or contradicted it (which
> really had to go).
>
>
> On Mon, Feb 27, 2017 at 8:16 AM, Tom Talpey <[e-mail]> wrote:
>
>> On 2/26/2017 3:29 PM, Chuck Lever wrote:
>>
>>> On Feb 25, 2017, at 3:54 PM, David Noveck <[e-mail]> wrote:
>>>>
>>>> RFC 5667 Section 4 says:
>>>>>
>>>>
>>>> Similarly, a single RDMA Read list entry MAY be posted by the client
>>>>>> to supply the opaque file data for a WRITE request or the pathname
>>>>>> for a SYMLINK request.
>>>>>>
>>>>>
>>>> Part of the problem here is that, as you discuss later, this statement
>>>> is
>>>> ambiguous, as the meaning of "read list entry" is not clear.
>>>>
>>>> The server MUST ignore any Read list for
>>>>>> other NFS procedures,
>>>>>>
>>>>>
>>>> As I understand it, this statement cannot apply to PZRCs, and rfc5666bis
>>>> has already dealt with that issue.  So, if one tried to maintain this
>>>> paragraph,
>>>> in something like the RFC5667-form, some modification would have been
>>>> necessary to avoid essentially preventing any use of PZRCs
>>>>
>>>> as well as additional Read list entries beyond
>>>>>> the first in the list.
>>>>>>
>>>>>
>>>> I take "Read list entry" to mean Read chunk, composed of
>>>>> multiple list entries that share the same XDR position.
>>>>> This comports with similar language describing Write
>>>>> chunks where a single list entry is indeed allowed to
>>>>> have multiple segments.
>>>>>
>>>>
>>>> Makes sense to me.
>>>>
>>>> However, the original intent might have been "single
>>>>> Read segment".
>>>>>
>>>>
>>>> It might have been but there is no way to be sure.
>>>>
>>>
>>> We can ask Tom Talpey. If he does not recall, then
>>> we have no way to be sure.
>>>
>>
>> I agree the paragraph in question could have been more clear. I'll
>> hazard a guess that it should have been written as "Read list" instead
>> of "Read list entry", meaning, an entire scatter list is provided.
>> This woud certainly match the semantic for the result of an ordinary
>> NFS Read.
>>
>> I will also observe that the statement is a MAY. That is, it prescribes
>> no behavior, and offers a choice to the implementer. It does not rule
>> out the option of posting a list.
>>
>> I think you guys need to stop worrying about writing these "rules"
>> down so literally. The only goal of RFC5667 was to isolate the tidbits
>> of NFS behaviors separate from the core rpcrdma transport. The
>> document makes relatively few MUST requirements.
>>
>> Tom.
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>
>