Session Date/Time: 07 Nov 2024 15:30

nfsv4

Summary

This meeting covered several active and not-yet-adopted documents within the NFSv4 working group. Key topics included internationalization, Flex Files (client-side erasure encoding), the uncatchable attribute, recursive attribute setting, POSIX draft ACLs, and the bis documents for RFC 5661 and 5662, especially concerning security aspects. The discussions highlighted challenges in balancing theoretical correctness with practical implementability and the need for clear working group consensus on document adoption and direction.

Key Discussion Points

Internationalization: In working group last call. Need more feedback on the list. Debate on whether to include 4.0 support given its obsolescence. Show of hands indicated mixed opinions on including support for v4.0. The resolution will be taken to the mailing list.
Flex Files (Client-Side Erasure Encoding): Mike presented a proposal for client-side erasure encoding, focusing on integrity and consistency. The goal is to prevent block corruption in erasure code, not to solve general consistent writing without locks. Christoph expressed concerns regarding complexity, efficiency, extra metadata and right amplification. Discussion focused on balancing integrity guarantees with performance and complexity, contrasting it to traditional RAID models.
Uncatchable Attribute: The attribute is intended to avoid client-side caching for access-based enumeration and file data. Concerns were raised about when the attribute is set and the impact on other clients with existing caches. Suggestion made to split the attribute into two attributes: not caching metadata and not caching file data. A show of hands indicated support for adoption, with confirmation needed on the mailing list.
Recursive Attribute Setting: Richiechen presented a proposal for recursively setting attributes on the server. Discussion centered on handling permission errors, crossing file systems, server scalability, and potential impact on server performance. Concerns were raised about the potential for a client to inadvertently trigger resource exhaustion on the server. Use cases were discussed as well.
POSIX Draft ACLs: Rick presented a proposal to access and manipulate POSIX draft ACLs directly via new NFSv4.2 attributes, addressing inconsistencies in mapping between POSIX draft ACLs and NFSv4 ACLs. Key issues discussed were the semantics of verify/nverify and the order of ACEs. Christoph raised concerns about the use of the POSIX trademark and the need for a normative reference for the ACL algorithm. A suggestion to explicitly declare verifiable attributes.
RFC 5661 and 5662 BIS Documents: David Noveck presented an update on the effort to update RFC 5661 and 5662 including security. The documents address a significant backlog of errata and areas that were never correctly described. Christoph expressed concerns about the lack of version control and the difficulty in reviewing the changes. Concerns were raised about the lack of progress, unclear scope and overall direction of the security documents, along with the disconnect between theoretical security and practical deployability. Suggestion to create an informational RFC describing the state of NFS security was made.

Decisions and Action Items

Internationalization: Chair will take the question of 4.0 support to the mailing list to gauge working group consensus.
Uncatchable Attribute: Chair will confirm the show of hands results on the mailing list for adoption.
POSIX Draft ACLs: Chair to determine if the POSIX trademark can be used.
RFC 5661 and 5662 BIS Documents: Working group needs to decide on the future direction of these documents (adopt, drop, revise scope) and propose a plan in the next cycle (interim or later).

Next Steps

Discuss the future of the RFC 5661/5662 BIS documents, particularly the security aspects, during the upcoming interim meeting.
Continue discussions on the mailing list regarding the Flex Files proposal, recursive attribute setting, POSIX draft ACLs, and other topics raised during the meeting.
The already scheduled interim meeting should be consulted on the IETF calendar.