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

[Barry Leiba <[e-mail]>]

Thanks, Thomas!

Barry

On Thu, Aug 13, 2026 at 2:25 PM Thomas Haynes <[e-mail]> wrote:
>
> 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]>