Summary

  • The NFSv4 working group's 29 September -06 ACL draft moves its proposed optional ACL_Choice attribute from number 87 to 89. Separate uncacheable-file and uncacheable-directory drafts use 87 and 88. All three are still works in progress, not proof of deployment.
  • Four proposed ACL-size error values also move to 10095–10098. New text says a server must not return them without AclChoice support, including when the particular filesystem being accessed does not support it. This section is still marked as needing consensus.

A client that receives a numbered protocol field needs to know what the number means under the specification its peer actually implements. That is why the latest ACLs within the NFSv4 Protocols draft is more than a tidy edit to a table. Its -05 version put a proposed ACL_Choice field at 87. In -06, the field is 89. The revision's own change log explains that the move makes room for the separate uncacheable-file and uncacheable-directory work. Their current drafts assign 87 to uncacheable_file_data and 88 to uncacheable_dirent_metadata.

The change is a coordination signal, not a report that a live network suffered a collision. ACL_Choice is a proposed optional NFSv4.1-bis attribute through which a server could describe aspects of its ACL behaviour to a client. The two uncacheable attributes concern file data and directory-entry metadata caching instead. A prototype built from an earlier snapshot might have to update a constant and its tests; the public documents alone cannot tell us whether any vendor shipped the old value. Nor has an IANA assignment or approved RFC settled these proposals merely because the drafts now place them in adjacent slots.

There is a second, less visible change. Four new errors describing ACLs too large to store or retrieve were numbered 20000–20003 in -05; -06 places them at 10095–10098. The new text explicitly withholds those errors when the server does not support AclChoice, or when it supports the feature elsewhere but not on the filesystem being accessed. A general server capability is therefore not enough to interpret an error for a specific file. The draft's error section retains a “Consensus Needed” marker. Its proposed MUST NOT is not a claim that current RFCs already impose this new rule.

Imagine a test harness replaying an ACL operation against two exports from the same server. The first sits on a filesystem that advertises the proposed choice information; the second does not. A decoder that knows the four new numeric values may still draw a false conclusion if it treats the server name, rather than the accessed filesystem and the draft revision, as the complete context. This is a hypothetical interoperability test, not an observed customer defect. It illustrates why recognition of a code point and evidence of feature support are different facts.

The Datatracker lists -06 as an active working-group Internet-Draft in the I-D Exists state. It has not completed the process that would update RFC 7530 or RFC 8881. The draft itself describes work leading toward an eventual working-group last call. For implementers, the immediate bounded action is to pin test expectations to a revision and check the presence and meaning of ACL_Choice on the target filesystem before treating the new errors as meaningful. That test discipline is an editorial recommendation, not a new conformance requirement.

Sources