Summary

  • draft-cel-nfsv4-element-registries-00 proposes eight IANA registries for operations, callback operations, status codes, attributes and ACCESS/OPEN values, replacing an ad hoc practice in which an author chooses the next number the author knows to be free.
  • A public allocation prevents coordinated reuse of a wire coordinate; it does not prove the feature’s merit, implementation support, active capability, correct decode, authorization, execution, durability or application result.

The integration test that changes both drafts

Team A adds an operation to a COMPOUND request. Team B, working elsewhere, adds a different operation. Each extends its local nfs_opnum4 enumeration with the next unused integer. Each generator produces valid XDR. Each client and server pair interoperates in its own laboratory.

Then one implementation imports both features. The same discriminant now names two union arms. A packet carrying that number cannot ask the decoder to remember which draft its sender meant. One side parses an argument layout the other side did not send. The defect is not that the specifications used similar prose. They assigned two meanings to one place on the wire.

Revision 00 of Registries of Network File System Version 4 Protocol Elements was submitted on 25 September 2026 and expires on 29 March 2027. Datatracker lists it as an active individual Internet-Draft, without a standards stream, working-group adoption, responsible Area Director or IESG approval. Its header proposes Standards Track status and an update to RFC 8178 if approved. It is a proposal, not an RFC or evidence that IANA has created the requested registries.

The draft identifies a narrow missing control. RFC 8178 explains how NFSv4 may add operations, callback operations, attributes, enumeration values and flag bits while preserving extension rules. It forbids deleting or reusing an assigned element. It does not say how an author obtains the number in the first place.

In practice, the draft says, authors choose the next value after the highest one they know. That method works only when every relevant allocation is visible to every author before anyone implements it. Parallel standards work breaks that assumption.

A number is executable structure

The proposal covers eight element types because NFSv4 puts numbers in several different control surfaces. An operation number in nfs_opnum4 selects the request and response arm of a COMPOUND union. A callback operation does the equivalent in CB_COMPOUND. A status number carries a defined error or result condition. An attribute number is both an XDR constant and a bit position in the fattr4 bitmap. ACCESS and OPEN flags occupy bits or subfield values. OPEN delegation types select another union arm.

The same decimal value can legitimately exist in two different registries. Context supplies the namespace: operation or callback, attribute or status, request flag or result flag. That is why an inventory containing only “value 82” is inadequate. A useful receipt includes the registry, direction, enclosing XDR type, NFS minor-version scope and referenced specification.

Within one registry, however, a duplicate is a semantic collision. The decoder does not receive a draft URL next to the discriminant. Coordination must happen before the number becomes a shared wire fact.

RFC 8276 shows the previous evidence surface. Its extended-attribute specification recorded numeric values after checking them against the most recent protocol version and current minor version known to the authors. That was careful and enabled interoperable prototypes. It still depended on the completeness of the authors’ view. An unseen concurrent draft was outside the check.

Eight registries replace private memory

Revision 00 asks IANA to create registries for NFSv4 Operations, Callback Operations, Status Codes, fattr4 Attributes, ACCESS Flags, OPEN Share Access Flags, OPEN Result Flags and OPEN Delegation Types. It seeds them from published RFCs, including the base minor-version specifications and later extensions.

For the covered types, each registry would become the single authoritative source of assignments after publication. A document adding an element would request the value in its IANA Considerations. The XDR constant would be derived from the allocated number, and the document could not publish a different constant.

That changes the order of authority. The author still defines the feature. IETF consensus still decides whether the Proposed Standard should exist. IANA assigns and records the coordinate under the stated policy. The implementation still decides what code runs. None can substitute for the others.

The proposed policy is Standards Action with Expert Review. Standards Action preserves RFC 8178’s demand that an extension to an existing minor version be published as a Proposed Standard. Expert Review adds a bounded registration check. It is not a shortcut around consensus.

The expert reviews the row, not the feature

The draft is unusually explicit about the Designated Expert’s scope. The expert checks that the request names the right registry and direction, uses the lowest available non-reserved value or its own early allocation, follows the naming convention, supplies the relevant XDR definition, states a coherent Versions range and cites the correct document.

The expert does not decide whether the element is a good protocol feature. That judgment belongs to the IETF consensus process that produced the Proposed Standard. A clean expert review can therefore coexist with unresolved deployment, performance or security questions. Conversely, a valuable feature can still have a defective registration request.

This separation prevents a registry receipt from becoming an endorsement token. “Registered” means that a coordinate was assigned under a process and recorded with its scope. It does not mean “recommended,” “widely implemented,” “enabled,” “secure for this workload” or “successful on this request.”

Early allocation closes the dangerous interval

Waiting until RFC publication to allocate a number would leave implementers with the same temptation that created the problem: choose a seemingly free value so prototypes can exchange packets. RFC 7120 supplies a controlled alternative.

An early allocation requires a sufficiently described and stable specification plus a judgment that early implementation interest or collision risk warrants the reservation. The working-group chairs and Area Director participate in the request. IANA records the assignment publicly as temporary, normally for one year, with dates visible in the registry.

Revision 00 says a working-group document introducing an element should seek early allocation after adoption and must not use a value that is neither registered nor early-allocated. The point is not to claim the draft has become a standard. It is to give experiments one public coordinate while the standards decision remains open.

Temporary is meaningful. RFC 7120 defines follow-up, renewal, expiry, deprecation and possible de-allocation. An early row is evidence that a value was reserved for a specified work item at a stated time. It is not final approval, and an expired temporary assignment should not be reported as current authority.

Non-reuse preserves the cost of old code

Revision 00 assigns the lowest available non-reserved value, but it refuses to recycle assigned values. A withdrawn element remains in the registry. Its Versions column can narrow or become none; references can record the document that withdrew it. The coordinate remains occupied.

This is conservative for a reason. Standards can withdraw a meaning faster than operators can prove that every binary, generated XDR file, packet analyzer, test fixture and appliance has forgotten it. Reassigning the integer would make an old emitter and a new receiver silently disagree. Keeping the grave marker consumes namespace in exchange for interpretive safety.

The row is therefore historical evidence, not a census. Versions: none would say that no current NFSv4 minor version is specified to use the element. It would not prove that no device emits the value. 4.1+ would say the standard makes the element applicable from 4.1 onward, subject to later changes. It would not prove that every 4.1 client and server implements the optional extension.

RFC 8178 allows implementations of the same minor version to support different valid subsets of extensions. Minor-version equality is not capability equality. The registry’s Versions field and a live endpoint’s supported element set answer different questions.

What a registry miss can and cannot say

If the proposed registries exist and a production specification claims a covered value that has neither a final nor valid early allocation, the absence is strong evidence that the claim lacks the proposed public allocation authority. It should stop publication or deployment until the discrepancy is explained.

It is not proof that the number is absent from the world. Experimental branches, private patches, old drafts, expired allocations and nonconforming products can emit unregistered values. A registry controls coordinated public meaning; it cannot recall bytes from installed code.

That distinction matters during migration. A team should search source trees, generated XDR, language bindings, dissector tables, fixtures, firmware and captures. It should key the search by element type and direction as well as number. A clean registry cannot reveal a stale constant that never reached the registry.

Likewise, a registry hit does not prove the packet was decoded under the correct document. The receiver’s build may predate the assignment, implement a provisional layout or know the element without supporting it. RFC 8178 explicitly separates unknown protocol elements from known-but-unsupported elements and supported ones. Their error paths differ.

Nine receipts from coordinate to outcome

A defensible NFSv4 claim links nine separate records:

  1. The exact Internet-Draft or RFC and its standards status identify the rule set.
  2. The registry row identifies element type, number, name, Versions, references and temporary or final state.
  3. The allocation record identifies the request, decision path, dates and change authority.
  4. The specification supplies the exact XDR arm, bit meaning, status semantics and version scope.
  5. The build record fingerprints source, generated XDR and constants in the actual binary.
  6. Capability evidence shows which optional elements the client and server recognize and support.
  7. A wire receipt binds number, direction, COMPOUND context, session and decoded bytes.
  8. An execution receipt records recognition, authorization, returned status and state transition.
  9. Storage and application observation establish the outcome that mattered.

Each receipt narrows uncertainty. None can be manufactured from the one below it. A final registry entry cannot prove the binary was upgraded. A correct decoder cannot prove the principal was authorized. NFS4_OK cannot by itself prove stable storage or the application’s later read.

What the sources do not prove

The frozen source set proves that revision 00 proposes the eight registries, explains the author-memory collision risk, imports published values, prescribes allocation and non-reuse, and limits expert review to registry hygiene. It does not show an observed NFSv4 collision, a defective product, an implemented IANA registry, working-group adoption, consensus, performance, prevalence, exploit or service incident.

The right conclusion is not that central registration makes NFSv4 safe. It is that it removes one avoidable ambiguity from the wire and makes responsibility legible. In Heng Lu’s terms, the registry should be authoritative for the claim it can actually support: who owns a coordinate, under which specification and for which version range. Authority over running truth remains with the evidence produced by the running system.

Sources