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

[Chuck Lever <[e-mail]>]

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.

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