Re: [nfsv4] Progressing RFC errata for RFC 5661

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Dave Noveck" <[e-mail]>
> To: "Trond Myklebust" <[e-mail]>
> Cc: "Tigran Mkrtchyan" <[e-mail]>, "Rick Macklem" <[e-mail]>, "Magnus Westerlund"
> <[e-mail]>, "NFSv4" <[e-mail]>
> Sent: Monday, September 16, 2019 11:29:17 PM
> Subject: Re: [nfsv4] Progressing RFC errata for RFC 5661

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

If I read suggested errata correctly, then our server does exactly what is suggested:

We do not set NFL4_UFLG_COMMIT_THRU_MDS flag and return data server returns
DATA_SYNC4 on WRITE, with expectation is that client will send a LAYOUTCOMMIT.


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


This diverge is caused by 'on the field' experience, which covered by rfc 5661
not 100% precise.

Thanks,
   Tigran.