[secdir] Re: [nfsv4] draft-ietf-nfsv4-uncacheable-files-11 ietf last call Secdir review

[David Noveck <[e-mail]>]

On Thu, Aug 13, 2026 at 11:23 AM Barry Leiba via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-nfsv4-uncacheable-files
> Title: Adding an Uncacheable File Data Attribute to NFSv4.2
> Reviewer: Barry Leiba
> Review result: Ready
>
> Thanks for this well-written and clear document.  I have only one question:
>
> -- Section 4.1 --
>
>    When honoring the uncacheable file data attribute, clients SHOULD NOT
>    delay transmission of WRITE data for the purpose of combining
>    multiple WRITE operations or improving efficiency.
>
> I wonder about the SHOULD NOT here.


I do as well although are reasons for considering this an issue to be
addressed are probably quite different.

In my reading:

   1. I have trouble imagining what might be "valid" reasons  to ignore
   this  or how the client might be aware of the implications of doing so
   given that reasons for forr refraining from going this are not stated in
   the spec but are the result of the unconstrained judgment of the server or
   of another client tt sets this attribute
   2. Given that the recommendationmis provided by the server or a
   client,it is hard to undrstand why the RFC219-derived terms are used here.

For write caching, there's a real issue of
> corrupting the file, so why is this not "MUST NOT"?
>

That addresses 1 above but not 2.  While I recognized that there is a
strong impulse to use these terms, I would argue that,in this case, ot
is one "more honored the breach than the observance" in the sense that
Hamlet intended.

I suggest "When honoring the uncacheable file data attribute, clients need
to avoid delaying transmission of WRITE data for the purpose of
combining multiple
WRITE operations or improving efficiency since the clear implication of
this attribute is that such is not to be done and that, by doing  anyway,
one raises the possibility of data corruption.".


>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>