Re: [nfsv4] AD review: draft-ietf-nfsv4-delstid-03

On Nov 9, 2023, at 3:14 PM, David Noveck <davenoveck@gmail.com> wrote:

First of all, it is incorrect to have this document marked as updating RFC8881 since you are not extending NFSv4.1.  Please don't do that as it is likely to result in confusion if somebody tries implementing these extensions in 4.1.

Are you saying I should be “updating” rfc7862 instead? As it is NFSv4.2?

Or are you objecting to “updating” in general?

I’d love to have a normative reference to what “updating” means here.

Is it “completely replaces” or more like “tweaks”?

Regarding the idnit output, I'm not sure if it is possible to avoid all output regarding this issue.  My experience has been that the "could be OK"-text is meant to warn you to check the if the abstract makes sense and when I get it. I look over the text and submit anyway.  I think that happened with RFCs 7530 and 8881.

On Mon, Nov 6, 2023, 6:22 PM Thomas Haynes <loghyr@hammerspace.com<mailto:loghyr@hammerspace.com>> wrote:

> On Oct 5, 2023, at 3:43 AM, Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com<mailto:zahed.sarker.ietf@gmail.com>> wrote:
>
>
> # Please clearly mention that this specification will update RFC8881 in the abstract.

One of my problems with this is that when I do that, the nit picker complains:

Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC7863, but the
     abstract doesn't seem to directly say this.  It does mention RFC7863
     though, so this could be OK.

  -- The draft header indicates that this document updates RFC8881, but the
     abstract doesn't seem to directly say this.  It does mention RFC8881
     though, so this could be OK.

Here is my abstract for reference:

      The Network File System v4 (NFSv4) allows a client to both open a
      file and be granted a delegation of that file.  This delegation
      provides the client the right to authoritatively cache metadata
      on the file locally.  This document presents several extensions
      for both the opening and delegating of the file  to
      the client. This document updates both RFC8881 and RFC7863.

If I change it to:

This document updates both <xref
      target="RFC8881" format="default" sectionFormat="of"/> and <xref
      target="RFC7863" format="default" sectionFormat="of"/>.

I get:

 Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The abstract seems to contain references ([RFC7863], [RFC8881]), which
     it shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  -- The draft header indicates that this document updates RFC7863, but the
     abstract doesn't seem to directly say this.  It does mention RFC7863
     though, so this could be OK.

  -- The draft header indicates that this document updates RFC8881, but the
     abstract doesn't seem to directly say this.  It does mention RFC8881
     though, so this could be OK.

So I guess the first form is correct, but how am I supposed to input this to not trigger the nits?

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4