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

[Thomas Haynes <[e-mail]>]

On Thu, Aug 13, 2026 at 12:44:56PM -0800, David Noveck wrote:
> 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

If there are no valid reasons to deviate and no way for a client
to weigh them, then SHOULD NOT is simply the wrong keyword — that
is precisely the test RFC 2119 sets for it.

>    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.

Section 4 is normative throughout -- MUST, MUST NOT, SHOULD, MAY
in Section 4.2 and Section 4.3, including the deliberate "Meeting
this MUST requirement satisfies the general SHOULD obligation above".
Making Section 4.1 the one prose-only subsection would leave the
central prohibition the only untestable statement in the section.

And Section 4.4 already resolves the advisory tension you are  
raising: the attribute "is advisory. Clients retain flexibility in
how they satisfy the requirements described above." Advisory governs
whether you honor it; once you do, what honoring means has to be
testable, or the attribute means nothing.

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

-- 
Tom Haynes <[e-mail]>