Re: [nfsv4] [Technical Errata Reported] RFC8881 (6865)

[Zaheduzzaman Sarker <[e-mail]>]

> On 21 Mar 2022, at 21:25, Chuck Lever III <[e-mail]> wrote:
> 
> 
> 
>> On Mar 14, 2022, at 6:33 PM, Chris Smiley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> Greetings,
>> 
>> This errata reports a problem with Section 15.25.4/RFC 8881.  Upon further review, we believe it should point to Section 18.25.4/RFC 8881. We have updated accordingly.  Please let us know any concerns. 
>> 
>> Please note - this report still needs to be reviewed by the stream approver.
>> 
>> Thank you.
>> 
>> RFC Editor/cs
>> 
>> 
>>> On Feb 28, 2022, at 5:30 AM, RFC Errata System <[e-mail]> wrote:
>>> 
>>> The following errata report has been submitted for RFC8881,
>>> "Network File System (NFS) Version 4 Minor Version 1 Protocol".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid6865 <https://www.rfc-editor.org/errata/eid6865>
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: David Noveck <[e-mail] <mailto:[e-mail]>>
>>> 
>>> Section: 15.25.4
>>> 
>>> Original Text
>>> -------------
>>> The server MUST NOT delete the directory entry if the reply from 
>>> OPEN had 
>>> the flag OPEN4_RESULT_PRESERVE_UNLINKED set.
> 
> There is no section 15.25.4 in RFC 8881. However, I found what might
> be the erroneous text in section 18.25.4 (as Chris pointed out):
> 
> 18.25.  Operation 28: REMOVE - Remove File System Object
> 
> 18.25.4.  IMPLEMENTATION
> 
>   If the server finds that the file is still open when the REMOVE
>   arrives:
> 
>   *  The server SHOULD NOT delete the file's directory entry if the
>      file was opened with OPEN4_SHARE_DENY_WRITE or
>      OPEN4_SHARE_DENY_BOTH.
> 
>   *  If the file was not opened with OPEN4_SHARE_DENY_WRITE or
>      OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
>      directory entry.  However, until last CLOSE of the file, the
>      server MAY continue to allow access to the file via its
>      filehandle.
> 
>   *  The server MUST NOT delete the directory entry if the reply from
>      OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set.
> 
> I believe the errata refers to the third bullet.
> 
> 
>>> Corrected Text
>>> --------------
>>> If the reply from OPEN had the flag OPEN4_RESULT_PRESERVE_UNLINKED set,
>>> The server 
>>> MUST NOI delete the file contents until each directory entry is 
>>> deleted and the file is no longer open.
> 
> I agree that the compliance statements in the second and third
> bullets are confusing,

So the errata seems to be correctly identified issues.

> but it's not clear to me how the corrected
> text addresses the contradiction mentioned below.

That means we need to have more discussions about the correct approach.

> 
> I'm not sure how the rules regarding verify/reject work for an
> errata. Does the suggested corrected text change a consensus
> decision, or merely allay reader confusion?

Apart from the verify / reject, we have another status which is “held for document update” (https://www.rfc-editor.org/errata-definitions/). This is applied when we have a correct errata report but resolution cannot be agreed . See here (https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/)--

"Technical items that have a clear resolution in line with the original intent should be classified as Verified. If the resolution is not clear or requires further discussion, the report should be classified as Hold for Document Update. In both cases, only items that are clearly wrong should be considered."

If we can’t reach to some resolution  then we can put the errata in “held for document update” status.

But first let’s have some more thoughts and discussions on the resolution for the identified issue.

Thanks Chuck!!


//Zahed


> 
> 
>>> Notes
>>> -----
>>> The existing second and third bullets are directly contradictory.
>>> 
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party  
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC8881 (draft-ietf-nfsv4-rfc5661sesqui-msns-04)
>>> --------------------------------------
>>> Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
>>> Publication Date    : August 2020
>>> Author(s)           : D. Noveck, Ed., C. Lever
>>> Category            : PROPOSED STANDARD
>>> Source              : Network File System Version 4
>>> Area                : Transport
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> 
>> 
> 
> --
> Chuck Lever