Re: [nfsv4] Progressing RFC errata for RFC 5661

[David Noveck <[e-mail]>]

On Mon, Sep 16, 2019 at 4:26 PM Trond Myklebust <[e-mail]> wrote:

>
>
> On Sun, 15 Sep 2019 at 09:44, David Noveck <[e-mail]> wrote:
>
>>
>> An additional issue that needs to be addressed before incorporating these
>> changes is that it is not appropriate to add extensive material about
>> handling of the file layout to Section 12.  That belongs in Section 13. We
>> don't want to exacerbate the confusion that Tom has noted between
>> statements about layouts in general and  about file layouts.  Rfc5661bis
>> needs to do better in this respect.
>>
>>> RFC5661 (2751
>>> <https://www.rfc-editor.org/verify_errata_select.php?eid=2751>)
>>>
>>> GLOBAL
>>>
>>> Technical
>>>
>>> nfsv4 (tsv)
>>>
>>> Ricardo Labiaga
>>>
>>
>> This is similar to the errata above although, because of the
>> extensiveness of the changes proposed I think *Rejected* is more
>> appropriate as an errata status.
>>
>
> Rejecting this would break clients that have been encoded to rely on that
> behaviour (i.e the Linux client, for one).
>

Rejecting the errata (i.e. putting it in the state "Rejected") would not do
that.

What would do that is doing an rfc5661bis that does not incorporate these
changes, but I don't think the working group is going to do that, for the
reasons you state.


> Without it, we would be unable to determine whether or not a LAYOUTCOMMIT
> is required for the files pNFS layout type, and would have to default to
> assuming it does. That would put the existing client base in violation.
>

It appears that the existing client base is in violation of rfc5661.   I
don't think we want rfc5661bis to be the same, so I expect the working
group will decide to make this sort of change.

>
>
It would also force us to start sending LAYOUTCOMMIT to servers that
> currently do not require it (i.e. NetApp).
>
> I'm not aware of any pNFS files server implementation that is in violation
> of this errata and that is expecting a LAYOUTCOMMIT on a commit-through-MDS
> implementation, or following a FILE_SYNC return from a commit-through-DS
> implementation. Ccing Rick and Tigran for their input.
>

If there are such server implementations, people will be able to tell us
about them, when we review the rfc5661bis section replacing Section 13 of
rfc5661.

The basic issue is that errata are for correcting situations in which an
RFC does not correctly represent the decisions of the working group.  I
believe that, in this case, the working group wants to change its decision,
for the good reasons you have indicated.   By saying that the errata should
be put in status "Rejected", I do not mean to imply that these changes
should not go into rfc5661bis.   I'm only saying that, according to the
IETF rules that Magnus pointed us to, this is the correct status.   Magnus
will make the final decision on errata status.   Regarding the
incorporation of these changes into rfc5661bis, the working group will make
a decision which the editor will then try to sell to the IESG, using the
kind of arguments that you have made above.   The IESG does not want the
spec to diverge from exsting implementations, so I don't expect a lot of
pushback, once the situation is made clear to them.