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

[David Noveck <[e-mail]>]

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.

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]> wrote:

>
>
> On Mar 27, 2026, at 7:20 AM, David Noveck <[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 Abstra**ct*,  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
>
>
>