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

[Chuck Lever III <[e-mail]>]

> On Mar 14, 2022, at 6:33 PM, Chris Smiley <[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
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: David Noveck <[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, 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?


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