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

[Thomas Haynes <[e-mail]>]

On Thu, Aug 13, 2026 at 08:23:25AM -0800, Barry Leiba via Datatracker 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.  For write caching, there's a real issue of
> corrupting the file, so why is this not "MUST NOT"?
> 
> 

Barry,

Thanks for the review and catching this!

MUST NOT is safe here because Section 4.2 has already carved out
the legitimate case:

> The transient retention of WRITE data needed to complete an
> in-flight UNSTABLE4 and COMMIT exchange is not considered "caching"
> for the purposes of this attribute.

With that exclusion in place, nothing legitimate remains under
"delay transmission for the purpose of combining WRITEs or improving
efficiency" -- that's the exact behaviour the attribute exists to
forbid.

MUST NOT is also consistent, because Section 4.2 already uses it
in the identical conditional context — "Clients MUST NOT defer
COMMIT past the point at which the application's write call returns"
— for what is arguably the lesser hazard. This is a real asymmetry:
the stronger corruption risk currently carries the weaker keyword.

So I'll make the change.

Tom


-- 
Tom Haynes <[e-mail]>