IETF Last Call Review of draft-ietf-nfsv4-uncacheable-files-11
review-ietf-nfsv4-uncacheable-files-11-secdir-lc-leiba-2026-08-13-00
| Request | Review of | draft-ietf-nfsv4-uncacheable-files |
|---|---|---|
| Requested revision | No specific revision (document currently at 11) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-08-24 | |
| Requested | 2026-08-10 | |
| Authors | Thomas Haynes | |
| I-D last updated | 2026-08-14 (Latest revision 2026-07-24) | |
| Completed reviews |
Secdir IETF Last Call review of -11
by Barry Leiba
Genart IETF Last Call review of -11 by Vijay K. Gurbani |
|
| Assignment | Reviewer | Barry Leiba |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-nfsv4-uncacheable-files by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/wHQntWQuUmtq9L0tdTyrJY7-flA | |
| Reviewed revision | 11 | |
| Result | Ready | |
| Completed | 2026-08-13 |
review-ietf-nfsv4-uncacheable-files-11-secdir-lc-leiba-2026-08-13-00
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"?