[nfsv4] Re: draft-ietf-nfsv4-uncacheable-files Post-WGLC readiness assessment

[Thomas Haynes <[e-mail]>]

> On Jun 22, 2026, at 6:31 AM, Chuck Lever <[e-mail]> wrote:
> 
> SUMMARY
> -------
> 
> The draft is ready to advance past WGLC.  No publication-blocking
> issues were found.  Three items should be addressed before the
> shepherd submits to the AD (see below).
> 
> NEXT ACTIONS
> ------------
> 
> The following steps are required to advance this document from WGLC
> to AD submission.  The controlling RFC is cited for each mandatory
> action.
> 
> Step 1 -- Request revision -09 from the author
> 
>   Ask the author to produce -09 addressing Issues 1 and 2 from this
>   review.  Recommend also resolving Issue 3 in the same revision by
>   making the "write hole" definition self-contained and removing the
>   attribution citation to [I-D.haynes-nfsv4-flexfiles-v2].  Doing
>   so avoids a predictable RFC Editor query and is cleaner than
>   leaving Issue 3 as a shepherd watch item.
> 


Done


> Step 2 -- Formally declare the WGLC complete  [RFC 2418 Section 7.4]
> 
>   RFC 2418 Section 7.4 assigns the WG Chair responsibility for
>   evaluating WGLC responses and determining consensus.  Post a
>   message to [e-mail] formally closing the WGLC, citing the
>   three substantive reviews received (Noveck, Lever, Macklem), the
>   author's responsiveness across eight revisions, and the absence of
>   any objection to publication.  Update the Datatracker WG state
>   from "In WG Last Call" to "WG Consensus: Waiting for Write-Up."
> 
> Step 3 -- Verify -09 and run idnits  [RFC 4858 Section 3.1(1.a),(1.g)]
> 
>   RFC 4858 Section 3.1(1.a) requires the shepherd to have personally
>   reviewed the version being forwarded.  RFC 4858 Section 3.1(1.g)
>   requires a thorough idnits check; boilerplate checks alone are
>   insufficient.  Confirm that -09 resolves Issues 1 and 2 (and
>   ideally 3) before proceeding.
> 
> Step 4 -- Prepare the Document Shepherd Write-Up  [RFC 4858 Section 3.1]
> 
>   RFC 4858 Section 3.1 requires the shepherd to answer questions
>   (1.a) through (1.k).  Items requiring particular attention for
>   this document:
> 
>   (1.b)  Three reviewers: Noveck, Lever, Macklem.  All are WG
>          members.  No dedicated non-WG review was solicited; the
>          document's narrow scope makes that adequate.
> 
>   (1.d)  Disclose the flexfiles-v2 informative reference if Issue 3
>          is not resolved in -09.  Note that attribute number 87 was
>          selected through WG list coordination rather than an IANA
>          registry process.  Note the shepherd's dual role as
>          co-chair.
> 
>   (1.e)  Rough consensus: no objectors; responsive author; eight
>          revisions over six months.  The WGLC was informally
>          extended past the original January 30, 2026 deadline
>          because the author proposed merging the files and
>          directories drafts; the WG rejected that proposal and
>          reviews of -04 were treated as the continuation of the
>          WGLC.
> 
>   (1.f)  No appeals threatened.
> 
>   (1.h)  All normative references are Standards Track or BCP; no
>          downrefs.  If Issue 3 is unresolved in -09, document the
>          informative I-D reference and the expected publication
>          timeline for flexfiles-v2.
> 
>   (1.i)  IANA Considerations verified: no IANA actions required.
>          Numbered FATTR4 attribute assignments are made by IETF
>          publication, consistent with RFC 8275 and RFC 8276.  Record
>          the WG coordination that established attribute number 87.
> 
>   (1.j)  The XDR consists of two lines (a typedef and a constant).
>          Confirm that the extraction script produces output that
>          appends cleanly to the NFSv4.2 XDR from RFC 7863.
> 
>   (1.k)  Write the Document Announcement Write-Up: Technical
>          Summary, Working Group Summary (note the merger episode and
>          the extended WGLC), Document Quality (Hammerspace server
>          prototype; Linux client prototype described in Section 6),
>          Personnel.
> 
> Step 5 -- Submit to the Area Director  [RFC 2418 Section 7.5;
>                                        RFC 4858 Section 3.1]
> 
>   Two obligations converge at this step.
> 
>   RFC 2418 Section 7.5 mandates: "The WG Chair MUST send email to
>   the relevant Area Director.  A copy of the request MUST be also
>   sent to the IESG Secretariat.  The mail MUST contain the reference
>   to the document's ID filename, and the action requested."
> 
>   RFC 4858 Section 3.1 mandates: "The Document Shepherd MUST send
>   the Document Shepherd Write-Up to the Responsible Area Director
>   and [e-mail] together with the request to publish
>   the document."  The shepherd SHOULD also send the Write-Up to the
>   WG mailing list.
> 
>   Since the co-chair and shepherd roles are held by the same person,
>   a single submission satisfies both requirements, but it must
>   contain the document filename, the action requested (publication
>   as a Standards Track RFC), and the complete shepherd write-up.
>   Enter the write-up into the Datatracker as a comment and add the
>   shepherd's email address to the "State or Version Change Notice
>   To" field per RFC 4858 Section 3.1.
> 
>   After submission, responsibility for progressing the document
>   passes to the IESG per RFC 2418 Section 7.5.  The shepherd's
>   ongoing role -- tracking IESG DISCUSS and COMMENT items and
>   liaising with the author -- continues through IESG evaluation and
>   RFC Editor processing per RFC 4858 Sections 3.2 and 3.3.
> 
> 
> REMAINING ISSUES
> ----------------
> 
> Issue 1 (minor) -- Abstract contains a citation
> 
>   The final sentence of the Abstract reads:
> 
>      "This document extends NFSv4.2 (see RFC7862)."
> 
>   RFC 7322 Section 4.3 states that abstracts normally should not
>   contain references.  The same citation appears properly as
>   [RFC7862] at line 119 of the Introduction.  The Abstract sentence
>   should be rewritten without the citation, e.g.:
> 
>      "This document extends NFSv4.2."
> 
> 
> Issue 2 (moderate) -- SHOULD/MUST layering in Section 4.3 is ambiguous
> 
>   Section 4.3 contains the following sequence:
> 
>      "Clients SHOULD ensure that cached file data is not reused
>      without first validating that the file has not changed."
> 
>      "At a minimum, clients MUST revalidate metadata necessary to
>      ensure correctness of cached file data, including the change
>      attribute and file size."
> 
>   Both sentences address the same obligation (cache revalidation
>   before reuse), at different levels of specificity.  As written,
>   an implementer satisfying the MUST cannot tell whether that also
>   satisfies the SHOULD.
> 
>   Suggested fix: add a sentence making the relationship explicit,
>   e.g., "Meeting the MUST requirement satisfies the general SHOULD
>   obligation."  Or invert the order -- state the MUST floor first,
>   then use MAY for the additional optional attributes -- so the
>   hierarchy is unambiguous.
> 
> 
> Issue 3 (watch item for shepherd) -- Informative I-D reference
> 
>   The "write hole" definition in Section 2 cites:
> 
>      [I-D.haynes-nfsv4-flexfiles-v2]
> 
>   for attribution.  The informative classification is correct -- an
>   implementer does not need that document to implement this one.
> 
>   However, this is a personal (non-WG) draft.  As of this review it
>   has not been adopted by the NFSv4 WG and its milestone for IESG
>   submission is November 2026.  If it is not published as an RFC
>   before this document, the RFC Editor will query the reference.
> 
>   The shepherd write-up should note whether:
>   (a) flexfiles-v2 is expected to be published concurrently, or
>   (b) the "write hole" definition will be made self-contained
>       (removing the attribution citation).
> 
> 
> ITEMS VERIFIED
> --------------
> 
> BCP 14 boilerplate: verbatim, cites both [RFC2119] and [RFC8174].
> Mandatory sections: all present (Abstract, Introduction, Definitions,
>  Requirements Language, body sections, Security Considerations,
>  IANA Considerations, References).
> Normative keyword usage: all MUST/SHOULD/MAY instances reflect
>  genuine interoperability requirements.
> No normative Internet-Draft references.
> No downrefs: all normative references are Standards Track or BCP.
> 
> Normative references verified against cached RFC text:
>  [RFC2119]  title, authors, date correct.
>  [RFC4506]  title, authors, date correct.
>  [RFC7862]  title, authors, date correct.
>  [RFC7863]  title, authors, date correct.
>  [RFC8174]  title, authors, date correct.
>  [RFC8178]  title, authors, date correct; Section 4.4.3 confirms
>             the GETATTR/SETATTR probing procedure cited in Section 1.
>  [RFC8881]  title, authors, date correct; normative classification
>             appropriate -- the draft relies directly on NFSv4.1
>             constructs (NF4REG, NFS4ERR_INVAL, NFS4ERR_PERM,
>             supported_attrs, change attribute, delegations) defined
>             there.
> 
> IANA Considerations: "no IANA actions" claim verified.  IANA does
>  not maintain a registry for numbered FATTR4 attributes; only the
>  Named Attribute Definitions registry exists for NFSv4 (string-named
>  attributes accessed via OPENATTR).  Numbered attribute assignments
>  are made through IETF publication of Standards Track RFCs, consistent
>  with how RFC 8275 (attr 81) and RFC 8276 (attr 82) were handled.
> 
> Attribute number 87: attributes 81 and 82 are assigned by RFC 8275
>  and RFC 8276 respectively.  No published RFC assigns numbers 83-86.
>  The draft's choice of 87 is consistent with WG coordination
>  (confirmed via nfsv4 mailing list archive).  The shepherd write-up
>  should record this coordination.
> 
> Security Considerations: proportionate for the new surface introduced.
>  Covers authorization for SETATTR, multi-client implications of
>  unprivileged attribute modification, advisory (non-security-boundary)
>  nature, and absence of changes to existing access control semantics.
>  No wholesale delegation to another document.
> 
> 
> WG LAST CALL STATUS
> -------------------
> 
> The [e-mail] mailing list archive was reviewed to assess
> whether rough consensus to advance this document exists.
> 
> Timeline:
> 
>  2026-01-16  WGLC for -03 announced by Christopher Inacio (co-chair),
>              comments due 2026-01-30.
> 
>  2026-01-30  WGLC period closes.  No formal consensus declaration was
>              made.  Instead, the author posted a proposal to merge the
>              files and directories drafts into a single document.
> 
>  2026-02-09  Merger proposal discussed on the list.  Both Chuck Lever
>  to 02-10    and David Noveck argued for keeping the two documents
>              separate.  The merger proposal was set aside.
> 
>  2026-03-10  Noveck posted "Need for decision re WGLC for uncacheable
>              files draft," offering two paths: restart the WGLC with a
>              merged document, or resume the existing WGLC against the
>              files draft with a further two-week review window.
> 
>  2026-03-18  Version -04 posted.
> 
>  2026-03-20  Chuck Lever submitted a review of -04.  Issues raised:
>              vague SHOULD compliance statement, underspecified metadata
>              for cache invalidation, insufficient implementation
>              guidance.
> 
>  2026-03-23  David Noveck submitted "WGLC review of draft-ietf-nfsv4-
>              uncacacheable-files-04."  Issues raised: terminology
>              ("uncacheable" vs. advisory framing), insufficient
>              distinction between read-caching and write-behind
>              suppression, authorization guidance for SETATTR.
>              Versions -05 and -06 were posted the same day, addressing
>              both reviews.
> 
>  2026-03-30  Rick Macklem raised concerns about -06: SETATTR timing
>  to 04-01    (should be settable only at file creation), write
>              durability behavior, and the risk of inconsistent
>              implementations.  Version -07 was posted 2026-04-01,
>              adding the WRITE Durability subsection (Section 4.2) and
>              clarifying SETATTR semantics.
> 
>  2026-04-17  Macklem posted an informational note about a historical
>              alternative caching approach, explicitly stating he was
>              not suggesting the draft be rewritten.
> 
>  2026-05-25  Noveck and Macklem exchanged views on write-handling
>              semantics; no new objections were raised.
> 
>  2026-06-09  Version -08 posted and forwarded to the WG list by the
>              author as the final revision incorporating all review
>              feedback.
> 
>  2026-06-08  WG co-chair Brian Pawlowski issued a "Final call on
>              draft-ietf-nfsv4-uncacheable-directories," noting that
>              IESG progress of that document depends on this document
>              completing first.
> 
> Participants: David Noveck, Chuck Lever, and Rick Macklem each
> submitted substantive technical reviews.  In all cases the author
> responded and revised the document.  No WG member has objected to
> publication of the uncacheable-files specification.  The February
> merger discussion concerned document structure, not the technical
> content.
> 
> Formal status: The IETF Datatracker shows WG State "In WG Last Call"
> with no document shepherd assigned.  No chair has posted a formal
> WGLC-complete notice for this document.
> 
> Assessment: Rough consensus to advance is present.  No sustained
> objection has been raised.  Three independent reviewers engaged
> constructively and their comments have been addressed across eight
> revisions.  The WG chairs should formally declare the WGLC complete
> and assign a shepherd so the document can proceed to AD submission.
> 
> 
> -- 
> Chuck Lever
> Brian Pawlowski
> 
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]