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

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 13 August 2026 15:23 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178663460582.82495.12458802157423865341@dt-datatracker-559c48c7fb-jvzsw>
Date: Thu, 13 Aug 2026 08:23:25 -0700
Message-ID-Hash: LRCPHDBISJ6KTXWUNBILMR2EPTZ76N7O
CC: draft-ietf-nfsv4-uncacheable-files.all@ietf.org, last-call@ietf.org, nfsv4@ietf.org
Reply-To: Barry Leiba <barryleiba@computer.org>
Subject: [secdir] draft-ietf-nfsv4-uncacheable-files-11 ietf last call Secdir review
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wHQntWQuUmtq9L0tdTyrJY7-flA>

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"?

[secdir] draft-ietf-nfsv4-uncacheable-files-11 ie… Barry Leiba via Datatracker
[secdir] Re: [nfsv4] draft-ietf-nfsv4-uncacheable… David Noveck
[secdir] Re: [nfsv4] draft-ietf-nfsv4-uncacheable… Thomas Haynes
[secdir] Re: draft-ietf-nfsv4-uncacheable-files-1… Thomas Haynes
[secdir] Re: draft-ietf-nfsv4-uncacheable-files-1… Barry Leiba