I-D list for Network File System Version 4 RSS Feed

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-14T23:56:36+00:00

IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-13T15:23:25.772606+00:00

Request for IETF Last Call review by SECDIR Completed: Ready. Reviewer: Barry Leiba. Sent review to list.

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-12T21:22:46.752526+00:00

Request for IETF Last Call review by ARTART is assigned to Claudio Allocchio

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-12T15:47:17.875170+00:00

Request for IETF Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list.

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-11T13:20:43.390036+00:00

Request for IETF Last Call review by GENART is assigned to Vijay Gurbani

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-11T09:33:05.236488+00:00

Request for IETF Last Call review by SECDIR is assigned to Barry Leiba

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-10T16:10:29.467371+00:00

IANA Review state changed to IANA - Review Needed

Last Call Issued: Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-10T16:10:29.440612+00:00

The following Last Call announcement was sent out (ends 2026-08-24):

From: The IESG
To: IETF-Announce
CC: cel-ietf@chucklever.net, draft-ietf-nfsv4-uncacheable-files@ietf.org, gorry@erg.abdn.ac.uk, nfsv4-chairs@ietf.org, nfsv4@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call: (Adding an Uncacheable File Data Attribute to NFSv4.2) to Proposed Standard

The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'Adding an Uncacheable File
Data Attribute to NFSv4.2'

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 2026-08-24. 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

Network File System version 4.2 (NFSv4.2) clients commonly perform
client-side caching of file data in order to improve performance. On
some systems, applications may influence client data caching
behavior, but there is no standardized mechanism for a server or
administrator to indicate that particular file data should not be
cached by clients for reasons of performance or correctness. This
document introduces a new file data caching attribute for NFSv4.2.
Files marked with this attribute are intended to be accessed with
client-side caching of file data suppressed, in order to support
workloads that require predictable data visibility. This document
extends NFSv4.2.

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

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

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-10T16:10:29.341457+00:00

IESG state changed to In Last Call from Last Call Requested

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-10T16:09:53.108974+00:00

Last call announcement was generated

Internationalization for the NFSv4 Protocols

2026-08-08T07:54:40.999353+00:00

IETF-LC comments resulted in -17 and continue to be received.
A further revision may be needed, unless all agree the document is now ready.

Please send any comments/requests relating to this latest version by noon your time on Friday 14th August 2026

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:48:01.706358+00:00

Last call was requested

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:48:01.524287+00:00

Last call announcement was generated

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:48:01.028432+00:00

IESG state changed to Last Call Requested from AD Evaluation::AD Followup

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:47:20.933643+00:00

RFC Editor Note was changed to

RFC Editor Note

Please remove "Note to Readers" after the abstract when published.

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:47:20.876512+00:00

RFC Editor Note for ballot was generated

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:46:59.177106+00:00

RFC Editor Note for ballot was generated

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:12:46.520262+00:00

Ballot writeup was changed

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:12:35.341859+00:00

Ballot writeup was changed

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:05:11.919047+00:00

Ballot approval text was generated

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-08T07:03:57.654689+00:00

IESG state changed to AD Evaluation::AD Followup from Publication Requested

Parallel NFS (pNFS) Flexible File Layout Version 2

2026-08-07T17:11:55.447559+00:00

New version available: draft-haynes-nfsv4-flexfiles-v2-08.txt

Parallel NFS (pNFS) Flexible File Layout Version 2

2026-08-07T17:11:55.445449+00:00

New version accepted (logged-in submitter: Thomas Haynes)

Parallel NFS (pNFS) Flexible File Layout Version 2

2026-08-07T17:11:55.398911+00:00

Uploaded new revision

Proxy-Driven Server for Flexible Files Version 2

2026-08-07T17:07:00.113728+00:00

New version available: draft-haynes-nfsv4-flexfiles-v2-proxy-server-04.txt

Proxy-Driven Server for Flexible Files Version 2

2026-08-07T17:07:00.111317+00:00

New version accepted (logged-in submitter: Thomas Haynes)

Proxy-Driven Server for Flexible Files Version 2

2026-08-07T17:07:00.063246+00:00

Uploaded new revision

Delta-Write Extension for the Flexible File Version 2 Layout Type

2026-08-07T16:59:15.710707+00:00

New version available: draft-haynes-nfsv4-flexfiles-v2-delta-writes-00.txt

Delta-Write Extension for the Flexible File Version 2 Layout Type

2026-08-07T16:59:15.708469+00:00

New version accepted (logged-in submitter: Thomas Haynes)

Delta-Write Extension for the Flexible File Version 2 Layout Type

2026-08-07T16:56:58.360160+00:00

Uploaded new revision

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.229409+00:00

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Document: draft-ietf-nfsv4-uncacheable-files-11
Shepherd: Chuck Lever
Date: 2026-08-07

**Shepherd dual role.** The shepherd also serves as a co-chair of the
NFSv4 Working Group and was one of the three reviewers during the WGLC
period. This is disclosed here and revisited in item 1.

## 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?**

Broad agreement within a small WG. Working Group Last Call for -03 was
announced by co-chair Christopher Inacio on 2026-01-16, with comments
due 2026-01-30. Three independent WG members submitted substantive
technical reviews: David Noveck reviewed -04, Chuck Lever reviewed -04,
and Rick Macklem reviewed -06. Each review drew a response from the
author and a revised document. Revisions -05 through -10 were produced
between March and June 2026.

Reviews arriving at the close of the original comment window were
treated as the beginning of an extended review period rather than as
late submissions. In April 2026 Macklem posted a note describing a
historical alternative caching approach, stating explicitly that he was
not requesting changes to the draft. In May 2026 Noveck and Macklem
exchanged views on write-handling semantics; that exchange raised no
new objections. No WG member objected to publication at any point.

The reviewers are the participants who work on NFSv4 client and server
implementations, so the review population matches the population that
will implement the attribute. Silence from the remainder of the list is
consistent with the narrow scope of the change.

Regarding the dual role disclosed above: the shepherd's technical
review carried no more weight than any other participant's, and the
consensus determination rests on the record of the three reviews and
the absence of sustained objection, not on the shepherd's own position.

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

One structural disagreement, resolved. At the close of the WGLC comment
period the author proposed merging the uncacheable-files and
uncacheable-directories drafts into a single document. The WG discussed
this in February 2026. David Noveck and Chuck Lever argued for keeping
the documents separate, and the proposal was set aside. The
disagreement concerned document organization, not technical content.

The technical reviews raised points that the author addressed by
revision rather than by argument. Noveck raised terminology, the
distinction between read caching and write-behind suppression, and
authorization guidance for SETATTR. Lever raised ambiguous SHOULD
compliance language, underspecified metadata requirements for cache
invalidation, and a need for additional implementation guidance.
Macklem raised SETATTR timing, write durability behavior, and the risk
of inconsistent client behavior. No point remained in dispute at the
close of review.

**3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?**

No.

**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 recommends) or elsewhere (where)?**

Yes. Section 6, "Implementation Status", reports two prototypes per
RFC 7942 and carries the customary note asking the RFC Editor to remove
the section prior to publication.

A Hammerspace server implements the attribute. A Linux NFS client
prototype treats the attribute as a directive to apply O_DIRECT-like
behavior and to revalidate file-associated metadata before serving
cached state to applications. Trond Myklebust, Mike Snitzer, Jon Flynn,
Keith Mannthey, and Thomas Haynes worked on the prototype at
Hammerspace, per the Acknowledgments.

Experience with the prototype indicates the attribute delivers many of
the practical benefits of O_DIRECT without requiring application
modification, with reduced memory pressure and CPU utilization in the
client. The two implementations come from a single organization. Rick
Macklem's reviews reflect the FreeBSD client perspective, but no
FreeBSD implementation is reported.

## 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. The document adds one boolean attribute to the NFSv4.2 attribute
set. It defines no new operations, changes no existing on-the-wire
encoding, and touches no technology owned by another IETF working group
or by an external standards organization. No cross-group review was
solicited, and the shepherd does not believe one is needed.

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

None apply. The document contains no MIB module, no YANG module, no
media type registration, and no URI scheme.

**7. If the document contains a YANG module, has the final version of
the module been checked with any of the recommended validation tools
for syntax and formatting validation? ... Does the YANG module comply
with the Network Management Datastore Architecture (NMDA)?**

Not applicable. The document contains no YANG module.

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

The document contains XDR [RFC 4506]. Section 7 is two declarations:

/// typedef bool fattr4_uncacheable_file_data;
///
/// const FATTR4_UNCACHEABLE_FILE_DATA = 87;

Section 8 supplies the standard NFSv4 extraction script, which selects
lines beginning with the `///` sentinel and strips it. The shepherd
verified against -11 that the sentinel-prefixed lines are well formed,
that the script extracts them cleanly, and that the extracted text
appends to the NFSv4.2 XDR base from RFC 7863 without collision. The
typedef and the constant are the only two XDR declarations in the
document.

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

The shepherd reviewed -08 on 2026-06-19, -10 on 2026-06-29, and -11 on
2026-08-07. The -08 review identified three issues:

- *Minor.* The Abstract carried a parenthetical RFC citation ("This
document extends NFSv4.2 (see RFC7862)"), contrary to RFC 7322
Section 4.3. Resolved in -10. The Abstract now reads "This document
extends NFSv4.2." Confirmed against -11.

- *Moderate.* Section 4.3 layered a SHOULD and a MUST such that an
implementer satisfying the MUST could not determine whether that
also satisfied the SHOULD. Resolved in -10 with an explicit
bridging sentence: "Meeting this MUST requirement satisfies the
general SHOULD obligation above." Confirmed against -11.

- *Watch item.* An informative reference to a personal, non-WG draft,
[I-D.haynes-nfsv4-flexfiles-v2], cited only to attribute the "write
hole" definition. A normative-track document should not depend on a
personal draft for a definition its readers need. Resolved in -10.
The definition is now self-contained and the reference is gone.
Confirmed absent from -11.

-11 is a keepalive resubmission of -10. The shepherd diffed the two
versions on 2026-08-07. The only difference in the body text is the
expiry date line; the remainder of the diff is the version string,
running headers, and page footers. Every technical finding recorded
against -10 carries forward to -11 unchanged.

The document is needed. NFSv4.2 offers no standardized way for a server
or administrator to signal that client-side caching of a file's data is
unsuitable, and the HPC workloads that motivate the attribute have no
portable alternative to per-application O_DIRECT.

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

The NFSv4 WG sits in the Web and Internet Transport area. The shepherd
reviewed the document against the general shepherd checks in this
questionnaire and against RFC 7322 and the authors.ietf.org content
guidelines, and found the issues recorded in items 9 and 14.

No area-specific directorate review has been requested, and the
shepherd has not walked the document against a per-area ExpertTopics
checklist. The change introduces no new protocol operation, no new
congestion or transport behavior, and no new authentication or
authorization mechanism, so the shepherd does not anticipate findings
from transport-area or security-area review. The responsible AD should
treat that as the shepherd's expectation rather than as a completed
review, and request directorate review if they disagree.

**11. What type of RFC publication is being requested on the IETF
stream? Why is this the proper type of RFC? Do all Datatracker state
attributes correctly reflect this intent?**

Proposed Standard. The title page header reads "Intended status:
Standards Track."

Proposed Standard is correct. The document defines a new NFSv4.2
attribute with interoperability requirements binding on compliant
implementations, expressed in BCP 14 keywords, and supplies the XDR
that implementations encode on the wire.

The shepherd should confirm at submission time that the Datatracker
"Intended RFC status" attribute reads Proposed Standard, and that the
stream is set to IETF. The Datatracker currently lists no responsible
Area Director; one is assigned when the publication request is made.

**12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described in
BCP 79? 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. Thomas Haynes is the sole author. He was polled and confirmed via
private email on 2026-06-30:

> "I have no IPR (per BCP 79 / RFC 8179) to disclose for
> draft-ietf-nfsv4-uncacheable-files. Neither I nor my employer hold
> any patents or pending patent applications related to the technology
> described in this document, and I am aware of none from any third
> party. BCP 78 obligations were addressed at I-D submission time per
> the standard Datatracker workflow."

The confirmation was given privately, so there is no archived message
to link. The Datatracker IPR search returns "No IPR disclosures have
been submitted directly on draft-ietf-nfsv4-uncacheable-files." No
disclosure has been filed and, per the author's statement, none is
required.

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

Yes. Thomas Haynes is the sole author. He confirmed by email on
2026-08-07:

> "I am willing to be listed as the author of
> draft-ietf-nfsv4-uncacheable-files."

The front page carries one author, well under the five-author
threshold, so no justification is required. The document has no
Contributors section; the names in the Acknowledgments are prototype
implementers, reviewers, and process participants, not listed
contributors in the RFC 7322 sense. No further confirmations are
outstanding.

**14. Document any remaining I-D nits in this document. Simply running
the idnits tool is not enough; please review the "Content Guidelines"
on authors.ietf.org.**

Automated check. idnits 2.17.1 was run against -11 via
author-tools.ietf.org on 2026-08-07:

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--)

The single comment reports that the document date is 14 days in the
past. That is an artifact of when the check ran, not a defect.

This is a cleaner result than the check recorded against -10, which
used idnits 2.15.01 and reported a spurious "Simplified BSD License"
versus "Revised BSD License" mismatch caused by stale boilerplate
hardcoded in that release. 2.17.1 does not reproduce it. The
boilerplate in the document is the current IETF Trust text.

Manual review against the content guidelines found one item:

- The "Note to Readers" section on the front page carries the WG
mailing list address, the mail archive URL, and two GitHub URLs.
It belongs in the Internet-Draft and not in the published RFC, but
it carries no instruction to remove it. Section 6 does carry such
an instruction ("Note to RFC Editor: please remove this section
prior to publication"). The shepherd recommends the author add the
same instruction to "Note to Readers", or that the responsible AD
record an RFC Editor note to that effect. This is editorial and
does not block submission.

The Abstract is free of citations and expands NFSv4.2 on first use. The
document expands abbreviations on first use elsewhere and carries no
unused references.

**15. Should any informative references be normative or vice-versa?**

No. The split is correct.

The normative references are RFC 2119, RFC 4506, RFC 7862, RFC 7863,
RFC 8174, RFC 8178, and RFC 8881. Each is required to implement: BCP 14
keyword interpretation, the XDR language, the NFSv4.2 protocol and its
XDR base, the NFSv4 extension rules the document relies on, and
NFSv4.1.

The informative references are [MOUNT], [OPEN-O_DIRECT], and
[SOLARIS-FORCEDIRECTIO]. All three are cited as background on existing
platform mechanisms that motivate the attribute. None is needed to
implement it.

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

None. Every normative reference is an RFC, freely available from the
RFC Editor.

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

None. RFC 4506 is an Internet Standard (STD 67). RFC 2119 and RFC 8174
are BCP 14. RFC 7862, RFC 7863, RFC 8178, and RFC 8881 are Proposed
Standard. No normative reference sits below the requested maturity
level, so no downref applies and nothing needs to be called out in the
IETF Last Call notice.

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

No. Every normative reference is a published RFC.

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

No. The document extends NFSv4.2 (RFC 7862) through the extension
mechanism defined in RFC 8178, which does not create an Updates
relationship. Section 3 states this and cites RFC 8178 for the
procedure.

The title page header carries no Updates or Obsoletes field, and the
Datatracker metadata should show none. The shepherd will confirm this
at submission.

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

The IANA Considerations section reads "This document has no IANA
actions." The shepherd reviewed this against the body and believes it
is correct.

IANA maintains no registry for numbered FATTR4 attributes. The one
NFSv4-related registry, "NFSv4 Named Attribute Definitions", covers
string-named attributes reached through OPENATTR, which is a different
mechanism from the numbered attribute this document defines. No
registry is referenced and none is created, so the questions about
initial contents, allocation procedures, and registry naming do not
arise.

*Point for the responsible AD.* The document claims attribute number
87. Numbered FATTR4 attributes are allocated by IETF publication of
Standards Track RFCs rather than through an IANA registry, which is how
RFC 8275 took attribute 81 and RFC 8276 took attribute 82. No published
RFC assigns 83 through 86. The selection of 87 was settled by
coordination on nfsv4@ietf.org, not by a registry action, so nothing in
the process reserves it against a competing claim from a concurrent
draft. The shepherd raises this so the AD is aware of how the number
was chosen; the shepherd does not believe it blocks publication.

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

None. The document creates no IANA registry.

---

## Announcement text

The 4 July 2022 questionnaire dropped the Document Announcement
Write-Up that earlier templates carried. The Datatracker collects
announcement text in a separate field. The following is supplied for
that field.

**Technical Summary**

This document introduces the fattr4_uncacheable_file_data attribute
(FATTR4_UNCACHEABLE_FILE_DATA, attribute number 87) for NFSv4.2. The
attribute is a per-file boolean that lets a server or administrator
indicate that client-side caching of file data is unsuitable for a
particular file. When it is set, clients suppress write-behind caching,
transmitting WRITE data promptly rather than combining multiple writes,
and suppress read caching, revalidating the change attribute and file
size before serving cached data to applications. The attribute is
advisory and is not a security boundary. It is motivated by
High-Performance Computing workloads in which multiple clients write
disjoint byte ranges of a shared file and require predictable data
visibility. The extension follows the NFSv4 minor version extension
mechanism of RFC 8178 and does not formally update RFC 7862.

**Working Group Summary**

Working Group Last Call for -03 ran from 2026-01-16 to 2026-01-30.
Three WG members submitted substantive technical reviews, and the
author revised the document in response to each. A February 2026
proposal to merge this document with the companion uncacheable-
directories draft was discussed and set aside; the disagreement
concerned document organization rather than technical content. No WG
member objected to publication.

**Document Quality**

Two prototypes are reported in Section 6: a Hammerspace server and a
Linux NFS client. The Linux prototype applies O_DIRECT-like behavior
and revalidates file-associated metadata before serving cached state to
applications. Experience with it indicates the attribute delivers much
of the practical benefit of O_DIRECT without requiring application
modification. The normative XDR is two declarations, and the extraction
script in Section 8 produces output that appends cleanly to the NFSv4.2
XDR base from RFC 7863.

**Personnel**

Document Shepherd: Chuck Lever
Responsible Area Director: Gorry Fairhurst (Web and Internet Transport)

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.194381+00:00

IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.145873+00:00

IESG state changed to Publication Requested from I-D Exists

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.139035+00:00

Changed action holders to Gorry Fairhurst (IESG state changed)

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.061268+00:00

Responsible AD changed to Gorry Fairhurst

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:59.053469+00:00

Document is now in IESG state Publication Requested

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:32.490897+00:00

Changed consensus to Yes from Unknown

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:26:32.481260+00:00

Intended Status changed to Proposed Standard from None

Adding an Uncacheable File Data Attribute to NFSv4.2

2026-08-07T16:21:35.208968+00:00

The Network File System Access Control List Protocol

2026-08-04T17:37:24.884880+00:00

Changed document external resources from: None to:

github_repo https://github.com/ietf-wg-nfsv4/i-d-nfs-acl

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:46.416792+00:00

Changed action holders to Gorry Fairhurst (IESG state changed)

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:46.385474+00:00

Sub state has been changed to AD Followup from Revised I-D Needed

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:46.364675+00:00

IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:45.868827+00:00

New version available: draft-ietf-nfsv4-internationalization-17.txt

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:45.864965+00:00

New version accepted (logged-in submitter: David Noveck)

Internationalization for the NFSv4 Protocols

2026-08-04T09:11:45.787490+00:00

Uploaded new revision

Internationalization for the NFSv4 Protocols

2026-08-04T07:46:30.202058+00:00

Comments received during IETF Last Call and Area Review require a new revision.

Internationalization for the NFSv4 Protocols

2026-08-04T07:46:30.193491+00:00

Changed action holders to David Noveck (IESG state changed)

Internationalization for the NFSv4 Protocols

2026-08-04T07:46:30.138167+00:00

IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead

Internationalization for the NFSv4 Protocols

2026-08-03T20:20:49.145396+00:00

Request for IETF Last Call review by GENART Completed: Almost Ready. Reviewer: Ines Robles. Sent review to list.