Document Shepherd Write-Up
draft-ietf-nfsv4-uncacheable-files-10
Shepherd: Chuck Lever <cel-ietf@chucklever.net>
Date: 2026-06-30
Note: The shepherd serves concurrently as a co-chair of the NFSv4
Working Group and was one of the three technical reviewers during
the WGLC period. This dual role is disclosed in item (6) below.
(1) What type of RFC is being requested, and is this type of RFC
indicated in the title page header?
Proposed Standard. The title page header correctly identifies
the intended status as "Standards Track." A Proposed Standard
is appropriate: the document introduces a new NFSv4.2 attribute
with interoperability requirements that are binding on compliant
implementations.
(2) Document Announcement Write-Up.
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 allows
a server or administrator to indicate that client-side caching
of file data is unsuitable for a particular file. When set,
clients are advised to suppress both write-behind caching
(transmitting WRITE data promptly rather than combining
multiple writes) and read caching (revalidating the change
attribute and file size before serving cached data to
applications). The attribute is advisory and does not
constitute a security boundary. Its primary motivation is
High-Performance Computing workloads where multiple clients
write disjoint byte ranges of shared files and require
predictable data visibility. The extension follows the NFSv4
minor version extension mechanism defined in RFC 8178 and does
not require a formal update to RFC 7862.
Working Group Summary:
Working Group Last Call for -03 was announced by co-chair
Christopher Inacio on 2026-01-16, with comments due
2026-01-30. At the close of the comment period the author
proposed merging the uncacheable-files and uncacheable-
directories drafts into a single document. The WG discussed
the proposal in February 2026; David Noveck and Chuck Lever
argued for keeping the documents separate, and the proposal
was set aside. Reviews submitted during the original comment
window were treated as the beginning of an extended review
period.
Three substantive technical reviews were received. David
Noveck reviewed -04, raising concerns about terminology,
the distinction between read caching and write-behind
suppression, and authorization guidance for SETATTR. Chuck
Lever reviewed -04, identifying ambiguous SHOULD compliance
language, underspecified metadata requirements for cache
invalidation, and a need for additional implementation
guidance. Rick Macklem reviewed -06, raising concerns about
SETATTR timing, write durability behavior, and the risk of
inconsistent client behavior. In each case the author
responded and posted a revised document; revisions -05
through -10 were produced between March and June 2026.
In April 2026 Macklem posted a note describing a historical
alternative caching approach, explicitly stating he was not
requesting changes to the draft. In May 2026 Noveck and
Macklem exchanged views on write-handling semantics; no new
objections were raised. No WG member objected to
publication at any point in the process.
Document Quality:
Two prototype implementations are described in Section 6: a
Hammerspace server and a Linux NFS client. The Linux 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.
Experience with the prototype demonstrated that the attribute
delivers practical benefits comparable to O_DIRECT without
requiring application modification.
The normative XDR in Section 7 consists of two lines: a
typedef (fattr4_uncacheable_file_data as bool) and a constant
(FATTR4_UNCACHEABLE_FILE_DATA = 87). 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 <cel-ietf@chucklever.net>
Responsible Area Director: (to be assigned)
(3) Briefly describe the review of this document performed by the
Document Shepherd.
The shepherd reviewed version -08 on 2026-06-19 and version
-10 on 2026-06-29. The -08 review identified three issues:
Issue 1 (minor): A parenthetical RFC citation in the Abstract
("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."
Issue 2 (moderate): Ambiguous SHOULD/MUST layering in
Section 4.3, where 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."
Issue 3 (watch item): An informative reference to a personal
(non-WG) draft, [I-D.haynes-nfsv4-flexfiles-v2], cited only
for attribution of the "write hole" definition. Resolved in
-10: the definition is now self-contained and the reference
has been removed.
Idnits 3.0.0-alpha was run against -10 and reported one
warning: PREFER_BCP14_REF, which recommends citing BCP 14 in
addition to RFC 2119 and RFC 8174. RFC 8174 itself requires
that both documents be cited individually; the warning is not
actionable. No errors were reported.
The shepherd believes -10 is ready for forwarding to the IESG.
(4) Does the shepherd have any concerns about the depth or breadth
of the reviews?
No. Three independent WG members -- David Noveck, Chuck Lever,
and Rick Macklem -- submitted substantive technical reviews
covering caching semantics, normative keyword usage, XDR,
security considerations, and IANA treatment. Each review
prompted a response and a revision from the author. No
dedicated non-WG review was solicited; the document's narrow
scope (a single boolean attribute and two lines of XDR) makes
that adequate.
(5) Do portions of the document need review from a particular or
broader perspective?
No additional reviews are needed. The Security Considerations
section is proportionate for the surface introduced: it covers
authorization for SETATTR operations that modify the attribute,
the multi-client implications of allowing unprivileged users to
modify it, the advisory (non-security-boundary) nature of the
attribute, and the absence of changes to existing NFSv4.2
access control semantics.
(6) Specific concerns or issues for the Responsible Area Director
and/or the IESG.
Shepherd dual role: The document shepherd also serves as a
co-chair of the NFSv4 Working Group and was one of the three
WGLC reviewers. The shepherd is satisfied that the WG process
was conducted fairly and that rough consensus was determined
appropriately.
Attribute number 87: Attributes 81 and 82 were assigned by
RFC 8275 and RFC 8276 respectively. No published RFC assigns
attributes 83-86. The selection of attribute number 87 for
fattr4_uncacheable_file_data was established through
coordination on the nfsv4@ietf.org mailing list rather than
through a formal IANA registry process. This is consistent
with how previous numbered FATTR4 attributes have been assigned
(by IETF publication of Standards Track RFCs). The IANA
Considerations section correctly states that no IANA actions
are required.
(7) Has each author confirmed that all required IPR disclosures
have been filed per BCP 78 and BCP 79?
Yes. Thomas Haynes 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."
(8) Has an IPR disclosure been filed that references this document?
No. The Datatracker IPR search confirms: "No IPR disclosures
have been submitted directly on draft-ietf-nfsv4-uncacheable-
files."
(9) How solid is the WG consensus behind this document?
Solid. Three independent WG members submitted substantive
reviews; the author responded to each and revised the document
across ten versions over approximately six months. No WG
member objected to publication. The only structural
disagreement -- the February 2026 proposal to merge the files
and directories drafts -- concerned document organization, not
technical content, and was resolved decisively when the WG
rejected the proposal.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
No.
(11) ID nits.
Idnits 3.0.0-alpha was run against -10 and reported one
warning (PREFER_BCP14_REF; not actionable; see item (3)).
No errors were reported.
Idnits 2.15.01 was also run and reported one error: a
"Simplified BSD License" vs. "Revised BSD License" mismatch.
This is a known false positive caused by stale boilerplate
text hardcoded in the 2.15.01 tool. The boilerplate in the
draft is the correct current IETF Trust text.
(12) Formal review criteria.
No MIB Doctor, YANG Doctor, media type, or URI type reviews
apply to this document.
(13) Have all references been identified as normative or informative?
Yes. All references are correctly classified.
(14) Are there normative references to documents not ready for
advancement?
No. All normative references are published RFCs on the
Standards Track or as BCP: RFC 2119, RFC 4506, RFC 7862,
RFC 7863, RFC 8174, RFC 8178, RFC 8881.
(15) Are there downward normative references?
No.
(16) Will publication change the status of any existing RFCs?
No. This document extends NFSv4.2 (RFC 7862) using the
extension mechanism defined in RFC 8178, which does not
require a formal Updates relationship. The title page header
contains no Updates or Obsoletes fields.
(17) IANA Considerations review.
The IANA Considerations section states "This document has no
IANA actions." This is correct. IANA does not maintain a
registry for numbered FATTR4 attributes; the only NFSv4-related
IANA registry covers Named Attribute Definitions (string-named
attributes accessed via OPENATTR). Numbered FATTR4 attribute
assignments are made through IETF publication of Standards
Track RFCs, consistent with the handling of RFC 8275
(attribute 81) and RFC 8276 (attribute 82).
(18) New IANA registries requiring Expert Review.
None.
(19) Validation of formal language sections.
The XDR in Section 7 consists of two lines:
typedef bool fattr4_uncacheable_file_data;
const FATTR4_UNCACHEABLE_FILE_DATA = 87;
The shepherd verified that the extraction script in Section 8
produces syntactically valid XDR output that appends cleanly
to the NFSv4.2 XDR base from RFC 7863.
(20) YANG module validation.
Not applicable; this document contains no YANG module.