[nfsv4] Re: WGLC review of draft-ietf-nfsv4-uncacheable-directories-05

[Thomas Haynes <[e-mail]>]

> On Apr 22, 2026, at 11:15 AM, David Noveck <[e-mail]> wrote:
> 
> Is that rework available?   In its absence, I'm having trouble understanding how you intend to address the lack of motivation for the feature that I cited in my review.

Yes, I sent it out the day of your original review - it has been sitting there for weeks.

> 
> As far as I can determine, you still believe the server can validly give inconsistent values for the contents of directories or file attributes and it is the job of client to deal with that behavior.  That seems to be your motivation for this proposed attribute.
> 
> We clearly disagree as to the validity of a server returning such inconsistent data (in your terms, data which is "not globally consistent").   If it is not valid, as I believe to be the case,  then your motivation is not a valid one and this attribute a should not be added as an extension.  I think the chairs have everything they need to complete the WGLC although, until they declare this WGLC over other opinions can be entertained.
> 
> If you could cite a valid instance of servers returning data that is not globally consistent, we could restart the discussion from there.  However, I cannot see adding work based on speculation that this situation might exist in the future, which seems to be where you are now with this.
> 
> 
> 
> On Friday, March 27, 2026, Thomas Haynes <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Mar 27, 2026, at 7:20 AM, David Noveck <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Overall Evaluation 
>>> Appropriateness of Publication 
>>> It is not appropriate to proceed with publication of this document at this time because, as discussed in  Lack of Feature Motivation <>, there is no clear description of a needed feature that would motivate the addition of this attribute.  It appears that the motivations presented in the existing Abstract are purely speculative, as discussed in Close Reading of Existing Abstract <>.   This makes it inadvisable to proceed with publication until motivations are clarified or addressed as described in Possible Future Motivations <>.
>>> 
>>> Absence of Detailed Review
>>> Because of uncertainties as to intent and a lack of concern with  important details as discussed in Close Reading of Existing Abstract <>, much of this document has not had a detailed review.  Given the discussion in Lack of Feature Motivation <>, it appears likely that one will be delayed until a successor document is available, when a clear motivation for the proposed attribute is provided. This could enable reconsideration of this attribute at that later time, including a detailed review.
>>> 
>>> Lack of Feature Motivation
>>> Previous Motivations
>>> As originally specified, it was anticipated that this feature, including variation of some attribute values (i.e., the data-related ones like size) was needed as a complement to work described in draft-ietf-nfsv4-uncacheable-files.  However, further work on that document had the following effects:
>>> 
>>> ·       It was decided that variability of the attributes needed  to support draft-ietf-nfsv4-uncaceable-files (i/e.., those tied closely to file contents) could be handled directly within draft-ietf-nfsv4-uncaceable-files..
>>> ·       Furthermore, the necessary variability was not per-user but per-client reflecting simultaneous modification of file contents by multiple clients.
>>> ·       In any case, because of changes to draft-ietf-nfsv4-uncacheable-files, one of the motivations for this feature ceased to exist although the mischaracterization of file attributes as “dirent metadata” might have made that difficult to see.
>>> 
>>> Later it was anticipated that per-user variability might be necessary to support ABE, as discussed in Access-based Enumeration <>.  However:
>>> 
>>> ·       Tom felt that now was not the time to specify the semantics of this feature in detail.
>>> ·       Tom did not feel ready to drop this effort despite the fact  that there were no substantive motivations yet identified.   As will be discussed  in  Close Reading of Existing Abstract <>,  the result was essentially a motivation placeholder, which now needs to be filled in.
>>> ·       While the Working Group is free to proceed on the basis of the speculative motivations currently present, doing so would present difficulties, deriving from the current assumption that all file attributes can legitimately be treated as validly presented differently based on the identity of the interrogator.  For reasons discussed in Gaps that Need to be Addressed Elsewhere <>, Need for Semantic Description <>, and Needs for an Abstract for a Possible Successor Document <>, this would move the protocol in a bad direction, making it necessary that we have a more concrete discussion of a necessary use case before including this extension in NFSv4.2
>>> 
>>> Current Status of Feature Motivation
>>> As discussed above, this feature, which seemed a natural correlate of draft-ietf-nfsv4-uncacheable-files, has, during ongoing discussion, experienced a loss of its original motivation and possible replacements, resulting in an attempt at  motivation that relies on some unjustifiable assumptions that have been erroneously adopted while the existing NFSv4. 1 specifications did not discuss authorization in detail, despite the need to do so to support ACL definition.  These matters are discussed in Gaps that Need to be Addressed Elsewhere <> where suggestions regarding necessary clarification also appear.
>>> 
>>> As a result of this unfortunate history, we are forced to conclude that a new justification will be necessary, as will be discussed in  Possible Future Motivations <>.
>>> 
>>> Possible Future Motivations
>>> Access-based Enumeration
>>> Despite the circumstances that make it impossible to immediately proceed with specification of an ABE extension, it remains possible that it might serve as a basis for an attribute limiting metadata caching, keeping in mind the following issues:
>>> 
>>> ·       ABE has no need for varying attribute values on a per-user basis but deals with visibility only.
>>> ·       The potential need for per-user visibility is connected to the question of whether visibility restrictions apply to LOOKUP (or OPEN), in addition to READDIR.
>>> 
>>> Need for Semantic Description
>>> To provide an ABE-based specification, the following issues would need to be addressed:
>>> 
>>> ·       A clear description of the filtering to be provided that applies to the use of modes or ACLs  (presumably including draft-POSIX ACLs as well).
>>> ·       Clear guidelines with regard to the handling of LOOKUP, OPEN, and CREATE.
>>> 
>>> Other Possibilities
>>> While none are now known, we will need to consider the possibility that features needing this sort of per-user variability will be needed in the future.  An Important matter to consider for such features is whether they can be provided for within the extension model described in RFC8178.
>>> 
>>> Per-section Discussion
>>> In light of the problems in the existing Abstract and the lack of justification for many of the assumptions made in deciding to include this attribute, our discussion will be limited to issues raised by the existing Abstract.
>>> 
>>> Close Reading of Existing Abstract
>>> To provide better insight into the difference between my views and Tom’s regarding the issues involved, the abstract is reproduced together with:
>>> 
>>> ·       My comments on the existing text in red italics.
>>> ·       Possible replacements in blue italics
>>> ·       Other related comment in green italics.
>>> 
>>> To summarize the discussion below, it appears that Tom has some feature in mind that might, legitimately depend on user-specific attributes but is unwilling at this time to present it in detail.  As a result, in attempting to motivate this feature, he supposes that servers have an astounding level of freedom in making such decision and characterizes it as part of server access control.
>>> 
>>> This is not valid and access control needs to be limited to authorization to be describable by the protocol specification.  Although user identity is valid in effecting quota restrictions and might be extended to other sorts or resource-allocation decisions, it cannot and must not be extended to allow the server, at will, to report different values of attributes on a per-user basis.  Access control needs to be kept restricted, even if there were a valid argument for particular attributes to be interrogated on a per-user basis.
>>> 
>>> The existing abstract is to be found below, with my comments:
>>> 
>>> Network File System version 4.2 (NFSv4.2) clients may cache directory-entry (dirent) metadata returned by READDIR to improve performance.
>>> 
>>> It is not clear here what is intended by the phrase “directory-entry metadata”.  It seems that Tom is referring to the file attributes that can be returned by READDIR.  The fact that they are returned with dirents does not justify calling them “directory-entry metadata”, however. 
>>> 
>>> This is more than a purely verbal issue since this identification causes us to neglect the very real constraints that should apply to per-file attributes and obscures the fact that the protocol makes no provision for them to be different as seen by different users.
>>> 
>>> Network File System version 4.2 (NFSv4.2) clients will sometimes cache file attributes returned by READDIR in order to improve performance.
>>> 
>>> Such caching typically assumes that directory-entry  metadata and visibility are identical for all users of a client.  In some deployments,
>>> 
>>> With regard to attribute values, they make that assumption as part of the protocol is to give multiple users access to the same file, whether that is stated explicitly in RFC8881 or not.
>>> 
>>> However, servers may present directory entries or associated metadata based on the identity of the requesting user.
>>> 
>>> This can happen since there is no way of stopping a putative NFS server from doing so. 
>>> 
>>> This would be clearer if “may” were “replaced by “might”.  Even though “MAY” is not used, this gives the impression that this OK simply because servers might do it.
>>> 
>>> This is not so since there are strong reasons for a file’s attributes to be the same as seen by all users.  For example, if I set the ACL attribute of a file, I would not want  other users to see a different ACL that allowed it access I did not intend.
>>> 
>>> Reuse of cached directory-entry metadata across users can therefore result in clients presenting directory contents or attributes that do not reflect the server's current access control decisions. 
>>> 
>>> The phrase “current access control decisions” is troubling.  Generally, access control decisions are used to effect authorization and I am uncomfortable with the assumption that servers are free to make such decisions volidly simply because they area capable of doing so.
>>> 
>>> This  document introduces an uncacheable dirent metadata attribute for NFSv4.2 that allows servers to advise clients that directory-entry metadata returned by READDIR and related operations should not be  reused across users.
>>> 
>>> What is missing here is some explanation of why servers are to be allowed the freedom assumed above or why clients should be encouraged to modify their behavior to enable it.
>>> 
>>> Gaps that Need to be Addressed Elsewhere
>>> As we consider the assumptions made in the existing Abstract, it appears that there is a fundamental disagreement about what it is valid for a server to do based on the identity of the requester.  Part of this is undoubtedly the result of the previous unwillingness to address authorization in detail.   While the v4.1 respecification effort was intended to address the gaps in the discussion of these matters, it now appears that further work will be required in making it clear what, if anything, a server might validly do differently based on user identity, in addition to effecting the authorization semantics defined by the protocol.
>>> 
>>> In the past, it had been assumed, in connection with authorization, that the fact that a server chose to do something, somehow made it incumbent on clients to adapt to that behavior.   That issue was addressed with respect to ACLs  in draft-ietf-nfsv4-acls-update but needs to be addressed more generally.
>>> 
>>> As a result, when work resumes on the unaccountably delayed draft-ietf-nfsv4-security, it will be necessary to address these questions and provide reasonable limits regarding uses of user identity other than those mandated by the NFSv4 authorization model,
>>> 
>>> Needs for an Abstract for a Possible Successor Document
>>> It appears to me that the information missing in this document that would need to be provided in a successor (not necessarily in the abstract) has to include following:
>>> 
>>> ·       An explanation of the scope of the variability including whether differences in contents are to be accommodated or whether the same file can be described with different attribute values for different users.
>>> 
>>> For example, ABE-like extensions might report different directory contents without providing different attribute values for different users.
>>> 
>>> ·       If per-user attributes need to be accommodated, then it needs to be clear which attributes are allowed to be returned in this way and whether any can be set differently based on the user doing the modification.
>>> ·       It needs to be clearly specified how per-user visibility (or attribute variability ( if that is to be allowed) is affected by the use of different operations.
>>> 
>>> For example, it is not clear whether the arguments to  LOOKUP are to be filtered in the same way that READDIR results are.  This is a matter of ABE semantics that needs to be resolved.  In addition, the corresponding case of OPEN is even more difficult to deal with since the normal response to specification of a non-existing file name is to create a new file.
>>> 
>> 
>> Hi Dave,
>> 
>> I want to address one point directly, since I think it may be driving some of the concern.
>> 
>> There isn’t an unstated feature behind this work, nor is this document intended to introduce or define something like access-based enumeration.
>> 
>> The intent of this document is limited to specifying client behavior necessary to maintain correctness in situations where directory contents or associated metadata observed by a client may differ, whether over time or across clients. The document does not define the mechanisms that might lead to such variation, and does not rely on any specific model for how or why it occurs.
>> 
>> In particular, the goal is to ensure that client-side caching does not result in incorrect behavior when observations are not globally consistent. This is a cache correctness issue, independent of any specific server-side feature.
>> 
>> I agree that the current text can be read as implying new server-side semantics, and I’ll rework it to make the scope clearer and avoid that implication.
>> 
>> – Tom
>> 
>>