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

From: Chris Smiley <[email-masked]>
Date: Mon, 14 Mar 2022 15:33:50 -0700

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 <[email-masked]> 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
> 
> --------------------------------------
> Type: Technical
> Reported by: David Noveck <[email-masked]>
> 
> 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.
> 
> 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.
> 
> 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
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Mar 2022 17:31:50 -0700

Presumably we also want s/MUST NOI/MUST NOT/ in the new text, as well.

-Ben

On Mon, Mar 14, 2022 at 03:33:50PM -0700, Chris Smiley wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever III <[email-masked]>
Date: Mon, 21 Mar 2022 20:25:36 +0000

> On Mar 14, 2022, at 6:33 PM, Chris Smiley <[email-masked]> wrote:
> 
> 
> Greetings,
> 

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

I agree that the compliance statements in the second and third
bullets are confusing, but it's not clear to me how the corrected
text addresses the contradiction mentioned below.

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?

--
Chuck Lever

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 25 Mar 2022 10:59:36 +0000

> On 21 Mar 2022, at 21:25, Chuck Lever III <[email-masked]> wrote:
> 
> 
> 
>> On Mar 14, 2022, at 6:33 PM, Chris Smiley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Greetings,
>> 
>>> https://www.rfc-editor.org/errata/eid6865 <https://www.rfc-editor.org/errata/eid6865>
>>> 
>>> Reported by: David Noveck <[email-masked] <mailto:[email-masked]>>
>>> 
>>> Section: 15.25.4
>>> 
>>> Original Text
>>> -------------
> bullets are confusing,

So the errata seems to be correctly identified issues.

> but it's not clear to me how the corrected

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

> 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