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

From: "Noveck, David" <[email-masked]>
Date: Mon, 11 Apr 2022 17:26:50 +0000

>       On 21 Mar 2022, at 21:25, Chuck Lever III <[email-masked]<mailto:[email-masked]>> wrote:

>       On Mar 14, 2022, at 6:33 PM, Chris Smiley <[email-masked]<mailto:[email-masked]>> 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

OK, I mistyped the section number.
.
>       Please let us know any concerns.

>       Please note - this report still needs to be reviewed by the stream approver.

Whoever that is.

>       Thank you.

      RFC Editor/cs

On Feb 28, 2022, at 5:30 AM, RFC Errata System <[email-masked]<mailto:[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]<mailto:[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.

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.

>       The second and third bullets say SHOULD and MUST NOT About the same action.

>       I believe the errata refers to the third bullet.

I agree but the fundamental problem is that the second and third are contradictory.

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,

At the very least.
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.

I’ll send a clearer version later.   I think it will need not to follow the existing text so closely.

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

Yes.
>       I'm not sure how the rules regarding verify/reject work for an
      errata. Does the suggested corrected text change a consensus
      decision,

I don’t think so.   I don’t  think you can have a self-contradictory consensus.

We need to establish a real non-self-contradictory consensus.

>       or merely allay reader confusion?

No.

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

I think this will wind up held for document update.