Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type
draft-ietf-nfsv4-layoutwcc-07

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-nfsv4-layoutwcc and RFC 9766, changed IESG state to RFC Published)

[Ballot comment]
** Editorial.  Earlier reference to XDR.  I would have benefited from an earlier reference to XDR/RFC4506, say in Section 1.1.  Section 3 has XDR definitions but it isn’t explained to the reader until Section 4 that this is the underlying format.

** I had a similar question to Deb’s about security considerations.

[Ballot comment]
Thanks to Carsten for the ART ART Review.

It appears his comments were addressed: https://mailarchive.ietf.org/arch/msg/art/X8W1v3biypQyb1ECaP4OQvwnd-k/

However, I do not see a reply from him, confirming this on the list.

I have no further comments on this document.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-layoutwcc-05

# the referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nfsv4-layoutwcc-05.txt

# Many thanks for this document. I am not very NFS aware, so my review is only high level and editorial. I do however have a single easy to resolve DISCUSS.

# I found the text at times not trivial to read due to strange language constructs. In some instances i proposed an editorial rewrite you could consider.

#DISCUSS
#=======

# In the IANA section is written that there is no action required, but line 244 and 245 seem to indicate that there is a code point allocated for lowa_type. Maybe i got confused and misunderstood the text, or maybe the needs to describe the intent more accurate for NFS unware people as myself?

244   The lowa_type is defined to be a value from the IANA registry for
245   'pNFS Layout Types Registry'.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-layoutwcc-05

# the referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nfsv4-layoutwcc-05.txt

# Many thanks for this document. I am not very NFS aware, so my review is only high level and editorial. I do however have a single easy to resolve DISCUSS.

#GENERIC COMMENTS
#================

## I found the text at times not trivial to read due to strange language constructs. In some instances i proposed an editorial rewrite you could consider.

#DISCUSS
#=======

# In the IANA section is written that there is no action required, but line 244 and 245 seem to indicate that there is a code point allocated for lowa_type. Maybe i got confused and misunderstood the text, or maybe the needs to describe the intent more accurate for NFS unware people as myself?

244   The lowa_type is defined to be a value from the IANA registry for
245   'pNFS Layout Types Registry'.

[Ballot comment]
#DETAILED COMMENTS
#=================

10 Abstract
11
12   The Parallel Network File System (pNFS) Flexible File Layout allows
13   for a file's metadata (MDS) and data (DS) to be on different servers.
14   It does not provide a mechanism for the data server to update the
15   metadata server to changes to the data part of the file.  The client
16   has knowledge of such updates, but lacks the ability to update the
17   metadata server.  This document presents a refinement to RFC8435 to
18   allow the client to update the metadata server to changes on the data
19   server.

GV> What about the following alternative abstract:

"
This document specifies extensions to the parallel Network File System (NFS) version 4 (pNFS) for improving write cache consistency. These extensions introduce mechanisms that ensure partial writes performed under a pNFS layout remain coherent and correctly tracked. The solution addresses concurrency and data integrity concerns that may arise when multiple clients write to the same file through separate data servers. By defining additional interactions among clients, metadata servers, and data servers, this specification enhances the reliability of NFSv4 in parallel-access environments and ensures consistency across diverse deployment scenarios.
"

106   See Section 1.1 of [RFC8435] for a fuller set of definitions.

GV> Not sure that using the word "fuller" is appropriate. What about:

"
For a more comprehensive set of definitions, see Section 1.1 of [RFC 8435].
"

143   A layout type for pNFS enables the metadata server to tell the client
144   both the storage protocol and location of data to be used to
145   communicate with the storage devices.  The Flex Files Layout Type (in
146   [RFC8435]) details how NFSv3 data servers can be accessed.  The
147   client is only allowed to perform NFSv3 READ (see Section 3.3.6 of
148   [RFC1813]), WRITE (see Section 3.3.6 of [RFC1813]), and COMMIT (see
149   Section 3.3.21 of [RFC1813]) operations on the file handles provided
150   in the layout.  I.e., the client is only allowed to use NFSv3
151   operations which directly act on the data portion of the data file.

GV> I find the use of "to tell" odd in IETF text. What about the following editorial suggestion:

"
A pNFS layout type enables the metadata server to inform the client of both the storage protocol and the locations of the data that the client should use when communicating with the storage devices. The Flex Files Layout Type, as specified in [RFC 8435], describes how data servers using NFSv3 can be accessed. The client is restricted to performing NFSv3 READ (Section 3.3.6 of [RFC 1813]), WRITE (Section 3.3.6 of [RFC 1813]), and COMMIT (Section 3.3.21 of [RFC 1813]) operations on the file handles provided in the layout. In other words, the client may only use NFSv3 operations that act directly on the data portion of the file.
"

170   For example, the metadata server would issue a NFSv3 GETATTR to the
171   data server.  This query is most likely triggered in response to a
172   NFSv4 GETATTR issued by a client to the metadata server.  Not only
173   are these NFSv3 GETATTRs to the data server individually expensive,
174   the data server can become inundated by a storm of such requests.
175   NFSv3 solved a similar issue by having the READ and WRITE operations
176   employ a post-operation attribute to report the weak cache
177   consistency (WCC) data (See Section 2.6 of [RFC1813]).

GV> This reads odd to me. Are you trying to suggest the following

"
For example, the metadata server might issue an NFSv3 GETATTR operation to the data server, which is typically triggered by a client’s NFSv4 GETATTR request to the metadata server. In addition to the cost of each individual GETATTR operation, the data server can be overwhelmed by a large volume of such requests. NFSv3 addressed a similar challenge by including a post-operation attribute in the READ and WRITE operations to report weak cache consistency (WCC) data (see Section 2.6 of [RFC 1813]).
"

179   Each NFSv3 operation corresponds to one round trip between the client
180   and server.  So a WRITE followed by a GETATTR would require two round
181   trips.  In that scenario, the attribute information retrieved is
182   considered to be strict server-client consistency.  For NFSv4, the
183   WRITE and GETATTR can be issued together inside a compound, which
184   only requires one round trip between the client and server.  And this
185   is also considered to be a strict server-client consistency.  In
186   essence, the NFSv4 READ and WRITE operations drop the post-operation
187   attributes, allowing the client to decide if it needs that
188   information.

GV> Proposal text:

"
Each NFSv3 operation entails a single round trip between the client and server. Consequently, issuing a WRITE followed by a GETATTR would require two round trips. In that situation, the retrieved attribute information is regarded as strict server-client consistency. By contrast, NFSv4 enables a WRITE and GETATTR to be combined within a compound operation, which requires only one round trip. This combined approach is likewise considered strict server-client consistency. Essentially, NFSv4 READ and WRITE operations omit post-operation attributes, allowing the client to determine whether it requires that information.
"

205   In this document, we present a new NFSv4.2 operation called
206   LAYOUT_WCC, which allows the client to update the metadata server
207   with information from the data server.  The client is responsible for
208   taking the NFSv3 WCC information (which is returned by the 3
209   operations it is allowed to use) and pass that back to the metadata
210   server in the NFSv4.2 attributes.  The metadata server MAY then avoid
211   costly NFSv3 GETATTR calls to the data servers.  As this is a weak
212   model, the metadata server MAY make such calls anyway in order to
213   strengthen the model.

GV> proposal text:

"
This document introduces a new NFSv4.2 operation, LAYOUT_WCC, which enables the client to provide the metadata server with information obtained from the data server. The client is responsible for gathering the NFSv3 WCC data, returned by the three permissible NFSv3 operations, and conveying it back to the metadata server as part of NFSv4.2 attributes. The metadata server MAY therefore avoid issuing costly NFSv3 GETATTR calls to the data servers. Because this approach relies on a weak model, the metadata server MAY still perform these calls if it chooses to strengthen the model.
"

239 3.3.  DESCRIPTION
240
241   The current filehandle and the lowa_stateid identifies the particular
242   layout for the LAYOUT_WCC operation.  The lowa_type indicates how to
243   unpack the layout type specific payload inside the lowa_body field.
244   The lowa_type is defined to be a value from the IANA registry for
245   'pNFS Layout Types Registry'.
246
247   The lowa_body will contain the data file attributes.  The client will
248   be responsible for mapping the NFSv3 post-operation attributes to
249   those in a fattr4.  Just as the post-operation attributes may be
250   ignored by the client, the server may ignore the attributes inside
251   the LAYOUT_WCC.  But the server can also use those attributes to
252   avoid querying the data server for the data file attributes.  Note
253   that as these attributes are optional and there is nothing the client
254   can do if the server ignores one, there is no need to return a
255   bitmap4 of which attributes were accepted in the result of the
256   LAYOUT_WCC.

GV> Alternative proposal text:

"
The current filehandle and the lowa_stateid identify the specific layout for the LAYOUT_WCC operation. The lowa_type indicates how to interpret the layout-type-specific payload contained in the lowa_body field. This lowa_type is defined as a value (TBD#1) from the IANA registry for 'pNFS Layout Types'.

The lowa_body contains the data file attributes. The client is responsible for mapping NFSv3 post-operation attributes to the fattr4 representation. Similar to the behavior of post-operation attributes, the client may ignore these attributes, and the server may also choose to ignore any attributes included in LAYOUT_WCC. However, the server can use these attributes to avoid querying the data server for data file attributes. Because these attributes are optional and the client has no recourse if the server opts to disregard them, there is no requirement to return a bitmap4 indicating which attributes have been accepted in the LAYOUT_WCC result.
"

458 6.  IANA Considerations
459
460   This section is to be removed before publishing as an RFC.
461
462   There are no IANA considerations for this document.

GV> Is this correct? Section 3 at line 244 & 245 i read:

  The lowa_type is defined to be a value from the IANA registry for
  'pNFS Layout Types Registry'.

Does this not indicate that there is a value assigned by IANA?

Many thanks again for this document,

Kind Regards,
Gunter Van de Velde,
RTG AD

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-layoutwcc-05

# the referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nfsv4-layoutwcc-05.txt

# Many thanks for this document. I am not very NFS aware, so my review is only high level and editorial. I do however have a single easy to resolve DISCUSS.

#DISCUSS
#=======

# In the IANA section is written that there is no action required, but line 245 and 246 seem to indicate that there is a code point allocated for lowa_type. Maybe i got confused and misunderstood the text, or maybe the needs to describe the intent more accurate for NFS unware people as myself?

244   The lowa_type is defined to be a value from the IANA registry for
245   'pNFS Layout Types Registry'.

[Ballot comment]
#GENERIC COMMENTS
#================

## I found the text at times not trivial to read due to strange language constructs. In some ocations i proposed an editorial rewrite you may consider.

#DETAILED COMMENTS
#=================

10 Abstract
11
12   The Parallel Network File System (pNFS) Flexible File Layout allows
13   for a file's metadata (MDS) and data (DS) to be on different servers.
14   It does not provide a mechanism for the data server to update the
15   metadata server to changes to the data part of the file.  The client
16   has knowledge of such updates, but lacks the ability to update the
17   metadata server.  This document presents a refinement to RFC8435 to
18   allow the client to update the metadata server to changes on the data
19   server.

GV> What about the following alternative abstract:

"
This document specifies extensions to the parallel Network File System (NFS) version 4 (pNFS) for improving write cache consistency. These extensions introduce mechanisms that ensure partial writes performed under a pNFS layout remain coherent and correctly tracked. The solution addresses concurrency and data integrity concerns that may arise when multiple clients write to the same file through separate data servers. By defining additional interactions among clients, metadata servers, and data servers, this specification enhances the reliability of NFSv4 in parallel-access environments and ensures consistency across diverse deployment scenarios.
"

106   See Section 1.1 of [RFC8435] for a fuller set of definitions.

GV> Not sure that using the word "fuller" is appropriate. What about:

"
For a more comprehensive set of definitions, see Section 1.1 of [RFC 8435].
"

143   A layout type for pNFS enables the metadata server to tell the client
144   both the storage protocol and location of data to be used to
145   communicate with the storage devices.  The Flex Files Layout Type (in
146   [RFC8435]) details how NFSv3 data servers can be accessed.  The
147   client is only allowed to perform NFSv3 READ (see Section 3.3.6 of
148   [RFC1813]), WRITE (see Section 3.3.6 of [RFC1813]), and COMMIT (see
149   Section 3.3.21 of [RFC1813]) operations on the file handles provided
150   in the layout.  I.e., the client is only allowed to use NFSv3
151   operations which directly act on the data portion of the data file.

GV> I find the use of "to tell" odd in IETF text. What about the following editorial suggestion:

"
A pNFS layout type enables the metadata server to inform the client of both the storage protocol and the locations of the data that the client should use when communicating with the storage devices. The Flex Files Layout Type, as specified in [RFC 8435], describes how data servers using NFSv3 can be accessed. The client is restricted to performing NFSv3 READ (Section 3.3.6 of [RFC 1813]), WRITE (Section 3.3.6 of [RFC 1813]), and COMMIT (Section 3.3.21 of [RFC 1813]) operations on the file handles provided in the layout. In other words, the client may only use NFSv3 operations that act directly on the data portion of the file.
"

170   For example, the metadata server would issue a NFSv3 GETATTR to the
171   data server.  This query is most likely triggered in response to a
172   NFSv4 GETATTR issued by a client to the metadata server.  Not only
173   are these NFSv3 GETATTRs to the data server individually expensive,
174   the data server can become inundated by a storm of such requests.
175   NFSv3 solved a similar issue by having the READ and WRITE operations
176   employ a post-operation attribute to report the weak cache
177   consistency (WCC) data (See Section 2.6 of [RFC1813]).

GV> This reads odd to me. Are you trying to suggest the following

"
For example, the metadata server might issue an NFSv3 GETATTR operation to the data server, which is typically triggered by a client’s NFSv4 GETATTR request to the metadata server. In addition to the cost of each individual GETATTR operation, the data server can be overwhelmed by a large volume of such requests. NFSv3 addressed a similar challenge by including a post-operation attribute in the READ and WRITE operations to report weak cache consistency (WCC) data (see Section 2.6 of [RFC 1813]).
"

179   Each NFSv3 operation corresponds to one round trip between the client
180   and server.  So a WRITE followed by a GETATTR would require two round
181   trips.  In that scenario, the attribute information retrieved is
182   considered to be strict server-client consistency.  For NFSv4, the
183   WRITE and GETATTR can be issued together inside a compound, which
184   only requires one round trip between the client and server.  And this
185   is also considered to be a strict server-client consistency.  In
186   essence, the NFSv4 READ and WRITE operations drop the post-operation
187   attributes, allowing the client to decide if it needs that
188   information.

GV> Proposal text:

"
Each NFSv3 operation entails a single round trip between the client and server. Consequently, issuing a WRITE followed by a GETATTR would require two round trips. In that situation, the retrieved attribute information is regarded as strict server-client consistency. By contrast, NFSv4 enables a WRITE and GETATTR to be combined within a compound operation, which requires only one round trip. This combined approach is likewise considered strict server-client consistency. Essentially, NFSv4 READ and WRITE operations omit post-operation attributes, allowing the client to determine whether it requires that information.
"

205   In this document, we present a new NFSv4.2 operation called
206   LAYOUT_WCC, which allows the client to update the metadata server
207   with information from the data server.  The client is responsible for
208   taking the NFSv3 WCC information (which is returned by the 3
209   operations it is allowed to use) and pass that back to the metadata
210   server in the NFSv4.2 attributes.  The metadata server MAY then avoid
211   costly NFSv3 GETATTR calls to the data servers.  As this is a weak
212   model, the metadata server MAY make such calls anyway in order to
213   strengthen the model.

GV> proposal text:

"
This document introduces a new NFSv4.2 operation, LAYOUT_WCC, which enables the client to provide the metadata server with information obtained from the data server. The client is responsible for gathering the NFSv3 WCC data, returned by the three permissible NFSv3 operations, and conveying it back to the metadata server as part of NFSv4.2 attributes. The metadata server MAY therefore avoid issuing costly NFSv3 GETATTR calls to the data servers. Because this approach relies on a weak model, the metadata server MAY still perform these calls if it chooses to strengthen the model.
"

239 3.3.  DESCRIPTION
240
241   The current filehandle and the lowa_stateid identifies the particular
242   layout for the LAYOUT_WCC operation.  The lowa_type indicates how to
243   unpack the layout type specific payload inside the lowa_body field.
244   The lowa_type is defined to be a value from the IANA registry for
245   'pNFS Layout Types Registry'.
246
247   The lowa_body will contain the data file attributes.  The client will
248   be responsible for mapping the NFSv3 post-operation attributes to
249   those in a fattr4.  Just as the post-operation attributes may be
250   ignored by the client, the server may ignore the attributes inside
251   the LAYOUT_WCC.  But the server can also use those attributes to
252   avoid querying the data server for the data file attributes.  Note
253   that as these attributes are optional and there is nothing the client
254   can do if the server ignores one, there is no need to return a
255   bitmap4 of which attributes were accepted in the result of the
256   LAYOUT_WCC.

GV> Alternative proposal text:

"
The current filehandle and the lowa_stateid identify the specific layout for the LAYOUT_WCC operation. The lowa_type indicates how to interpret the layout-type-specific payload contained in the lowa_body field. This lowa_type is defined as a value (TBD#1) from the IANA registry for 'pNFS Layout Types'.

The lowa_body contains the data file attributes. The client is responsible for mapping NFSv3 post-operation attributes to the fattr4 representation. Similar to the behavior of post-operation attributes, the client may ignore these attributes, and the server may also choose to ignore any attributes included in LAYOUT_WCC. However, the server can use these attributes to avoid querying the data server for data file attributes. Because these attributes are optional and the client has no recourse if the server opts to disregard them, there is no requirement to return a bitmap4 indicating which attributes have been accepted in the LAYOUT_WCC result.
"

458 6.  IANA Considerations
459
460   This section is to be removed before publishing as an RFC.
461
462   There are no IANA considerations for this document.

GV> Is this correct? Section 3 at line 245 & 246 i read:

  The lowa_type is defined to be a value from the IANA registry for
  'pNFS Layout Types Registry'.

Does this not indicate that there is a vakue assigned by IANA?

Many thanks again for this document,

Kind Regards,
Gunter Van de Velde,
RTG AD

[Ballot comment]
Section 5:  Security Considerations:  It seems odd to me that allowing the DS and MDS on different servers doesn't drive a security concern.  Given this draft is a refinement to RFC8435, do the security considerations from that RFC apply to this draft?

Thanks to Ben Schwartz for his secdir review, and to Carsten Bormann, who parenthetically alludes to this situation.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-nfsv4-layoutwcc-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-11-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-nfsv4-layoutwcc@ietf.org, inacio@cert.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'Add LAYOUT_WCC to NFSv4.2's
Flex File Layout Type'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-11-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Parallel Network File System (pNFS) Flexible File Layout allows
  for a file's metadata (MDS) and data (DS) to be on different servers.
  It does not provide a mechanism for the data server to update the
  metadata server of changes to the data part of the file.  The client
  has knowledge of such updates, but lacks the ability to update the
  metadata server.  This document presents a refinement to RFC8435 to
  allow the client to update the metadata server to changes on the data
  server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layoutwcc/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Agreement was reached across the WG for this draft.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This draft was relatively uncontroversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Nothing has been threatened or no particular conflict present.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


There are some significant implementations (in Linux) but not broadly yet
beyond Linux.  There is at least one server implementation.  The Linux
implementation is part of the kernel mainline, and so included in all
distributions.

This is an optional feature.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There are sed scripts and extraction test for the XDR definitions in the
NFSv4 documents.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track; this is appropriate because this is an extension to an
existing standard protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors were reminded.  They have confirmed no additional
disclosures.

No IPR is being claimed and all copyright, including for the included code,
is assigned.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors have agreed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Just the delstid draft which is in WGLC currently.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Reviewed the section and discussed with the author.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Agreement was reached across the WG for this draft.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This draft was relatively uncontroversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Nothing has been threatened or no particular conflict present.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


There are some significant implementations (in Linux) but not broadly yet.
This is an optional feature.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There are sed scripts and extraction test for the XDR definitions in the
NFSv4 documents.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track; this is appropriate because this is an extension to an
existing standard protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors were reminded.  They have confirmed no additional
disclosures.

No IPR is being claimed and all copyright, including for the included code,
is assigned.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors have agreed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Just the delstid draft which is in WGLC currently.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Reviewed the section and discussed with the author.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Agreement was reached across the WG for this draft.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This draft was relatively uncontroversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

Nothing has been threatened or no particular conflict present.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?


There are some significant implementations (in Linux) but not broadly yet.
This is an optional feature.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There are sed scripts and extraction test for the XDR definitions in the
NFSv4 documents.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track; this is appropriate because this is an extension to an
existing standard protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors were reminded.  They have confirmed no additional
disclosures.

No IPR is being claimed and all copyright, including for the included code,
is assigned.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors have agreed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Just the delstid draft which is in WGLC currently.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Reviewed the section and discussed with the author.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/