Markdown Version | Session Recording

Session Date/Time: 11 Jul 2023 19:00

NFSV4

Summary

This interim meeting of the NFSV4 Working Group focused primarily on the status and planned revisions for draft-ietf-nfsv4-rfc5661bis (the "5661bis" document), with a brief update on other WG documents. Discussion centered on clarifying terminology, resolving inconsistencies, improving security treatment, and the process for moving this foundational document forward. Initial meeting logistics were challenging due to issues with the MeetEcho platform.

Key Discussion Points

• Meeting Logistics: The meeting started with significant difficulties in sharing slides and audio connectivity for several participants. There was a general sentiment that the MeetEcho platform for this specific interim was problematic, and the chairs indicated they would discuss alternative arrangements for future interims.
• Document Status Updates (Chairs):
  • draft-ietf-nfsv4-layout-status: Feedback is still being sought on the layout draft. The current plan is to discuss it at IETF 117.
  • draft-ietf-nfsv4-pnfs-parallel-nfs-v4: The Working Group Last Call (WGLC) received sufficient positive responses. This document will be moved forward out of the WG.
  • draft-ietf-nfsv4-nfsv4-rdma-extensions: The WGLC also received sufficient positive responses. This document will be moved forward out of the WG.
  • draft-ietf-nfsv4-state-id-lease-list (aka "Bells Did"): A new revision has been published in response to previous WGLC feedback. A new two-week WGLC will be restarted for this document, with the aim to move it forward by IETF 117.
• RFC 5661bis (draft-ietf-nfsv4-rfc5661bis) Discussion (Dave):
  • Motivations:
    • Separate common areas (internationalization, security, extensions) into dedicated documents where appropriate.
    • Consolidate existing NFSv4.1 related RFCs (5661, 8081, 8434) into a single document.
    • Improve the treatment of security, including adding threat analysis, as current documents provide "unsatisfactory" coverage (e.g., lack of threat analysis, mischaracterizing RPCSEC_GSS as optional means of authentication).
  • Related Documents:
    • draft-ietf-nfsv4-internationalization-06: This is a WG document. An ART review is planned for the 14th of the month.
    • Security Draft: The adoption call was delayed, and the individual draft expired. Dave will repost the current individual draft and the WG will plan a new adoption call.
    • RFC 5662bis: Minor changes required. An adoption call is pending but not seen as a major issue.
    • RFC 8178: The new 5661bis document must clearly indicate RFC 8178 as the definitive definition of extensions for all minor versions.
    • RFC 8434: This document needs to be incorporated into the 5661bis document over the next few drafts.
  • Identified Issues/Changes (Found during drafting 00 and 01):
    • RFC 2119 Terms: Widespread misuse of "MUST", "SHOULD", etc., not in accordance with RFC 2119 definitions, despite boilerplate.
    • Confused Terminology: Cleanup needed for terms like "verifier" (6 different meanings) and "client owner" (used to mean string vs. string+verifier).
    • Directory Delegation: Defined but unimplemented; needs clarification on what it does and does not do. Text to be added to 02 draft.
    • Memory-Mapped I/O and Locking: Section has been revised; feedback is requested.
    • Reviewing Changes: Diffing between RFC 8881 and 01 is difficult due to section moves; appendices B1-B3 explain changes.
    • Changes from 8881 to 00: Introduction added, adaptation for internationalization/protocol extensions/security in separate documents, addressing numerous errata, shifting from RFC 2119 "RECOMMENDED" to lowercase "recommended."
    • Changes from 00 to 01:
      • "MUST wait for response": Changed as no implementations (e.g., Linux client on Ctrl+C) comply. Revised to reflect practical reality.
      • "MUST NOT retry" (for exactly-once semantics - EOS): Changed to reflect that retries are "a bad idea" but not strictly forbidden, clarifying that EOS provides "at most once" semantics when operations are interrupted.
      • Memory Mapping/Locking: Section was entirely rewritten.
      • Terminology Refinement: Distinguished "client owner" (string + verifier) from "client owner ID" (string). Clarified various "verifier" definitions.
      • PNFS Terminology: Introduced "file data provider" (generic for file servers/storage devices) and "data protocol" (instead of storage protocol). Clarified "control protocol" distinctions, particularly for flexible file layouts without a separate control protocol.
      • Impact on NVMe PNFS (Kristoff's draft): Clarified that 5661bis changes are forward-looking and do not require retroactive terminology changes in existing SCSI documents or Kristoff's draft.
  • PNFS Security and Threat Analysis:
    • Work is needed on threat analysis for PNFS, organized by data protocol usage.
    • Categorization of PNFS layout types: File layout, flexible files (tied coupling mode - where RPC is included in data access protocol), and others.
    • Discussion on control protocols and ensuring isolation/integrity in cluster server environments.
    • Approach to Threat Analysis: Dave plans to draft initial content himself over the next month, then seek review and help from the Security Area Directorate within the working group structure, rather than an "over the wall" formal review.
  • Planned for Draft-02:
    • Address David Black's clarification suggestions.
    • Clarify directory delegation.
    • Clarify "persistence issues": atomic requirements for compound operations (current text might imply unachievable atomicity or poor performance), server restart handling for compounds/locks (ambiguity on graceful recovery vs. grace period). A proposal to include a mechanism to communicate lock persistence and avoid grace periods during server restarts will be included.
    • Address remaining errata reports.
    • Lowercase "recommended" vs. "REQUIRED" discussion: Dave outlined that many attributes formally categorized as "lowercase recommended" (e.g., mode, owner, group) are practically "REQUIRED" for clients to function with a server. This leads to a need for a clearer hierarchy of "optionality." David Black suggested a three-tiered approach: REQUIRED/MUST, an uppercase SHOULD (for current strong recommendations), and lowercase "recommended" for truly optional features. Dave will ensure the use of lowercase "recommended" is clearly explained in the document to avoid confusion with RFC 2119 "RECOMMENDED."
  • Process for 5661bis: The chairs will decide the formal process after IETF 117. Expect at least 2-3 more drafts before a WGLC. Discussion will continue on the mailing list and in future interim meetings.
• IETF 117 Notional Agenda (Chris):
  • Shepherding Parallel NFS, RDMA extensions, Bells Did (potential final conversation).
  • Layout draft status update.
  • Broader conversation on security approach and protocol structure.
  • Internationalization "move forward plan" (updated from "efforts").
  • Discussion on future interim meetings, especially regarding timing and platform due to the current meeting's technical difficulties.

Decisions and Action Items

Decisions:

• Parallel NFS (draft-ietf-nfsv4-pnfs-parallel-nfs-v4): Moving forward out of the WG after positive WGLC feedback.
• RDMA Extensions (draft-ietf-nfsv4-nfsv4-rdma-extensions): Moving forward out of the WG after positive WGLC feedback.
• State ID Lease List (draft-ietf-nfsv4-state-id-lease-list): A new two-week Working Group Last Call will be initiated.
• RFC 5661bis Security Threat Analysis: Dave will draft initial content, then the WG will seek review and assistance from the Security Area Directorate within the WG structure.
• Clarification of "recommended": The 5661bis document will clearly explain the use of lowercase "recommended" to distinguish it from the RFC 2119 meaning.

Action Items:

• Dave (Editor):
  • Repost the expired individual security draft and work with chairs to plan a new WG adoption call.
  • Incorporate RFC 8434 into RFC 5661bis over upcoming drafts.
  • Clarify the use of lowercase "recommended" in draft-ietf-nfsv4-rfc5661bis-02 (or later) to distinguish it from RFC 2119 "RECOMMENDED."
  • Draft clarification text for directory delegation and persistence issues in draft-ietf-nfsv4-rfc5661bis-02.
  • Draft initial threat analysis for PNFS security.
  • Address remaining errata reports for RFC 5661bis.
• Chairs (Chris):
  • Update the IETF 117 agenda item "internationalization efforts" to "internationalization move forward plan."
  • Discuss potential alternative platforms or scheduling for future interim meetings.
• Brian (Secretary):
  • Combine notes from the meeting recording and personal notes, and push them up.

Next Steps

• RFC 5661bis:
  • Continue discussion on the working group mailing list.
  • Publish draft-ietf-nfsv4-rfc5661bis-02 incorporating discussed changes and proposals.
  • Begin drafting the PNFS security threat analysis.
• IETF 117:
  • Present status updates for all WG documents.
  • Hold a broader discussion on the WG's approach to security.
  • Discuss the "internationalization move forward plan."
• Interim Meetings: The chairs will review the cadence and platform for future interim meetings to ensure better participation and fewer technical issues.