Re: [nfsv4] WG Action: Rechartered Network File System Version 4 (nfsv4)

[Spencer Shepler <[e-mail]>]

Great news that we are re-chartered.  Please take a brief moment to review the milestones.
If you have ownership of something that will be delivered in a milestone, please focus
on the delivery dates and let me know if there will be shifts in the schedule so that I may
notify our area director.

Spencer

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of The IESG
> Sent: Thursday, June 21, 2012 12:37 PM
> To: IETF-Announce
> Cc: nfsv4 WG
> Subject: [nfsv4] WG Action: Rechartered Network File System Version 4
> (nfsv4)
> 
> The Network File System Version 4 (nfsv4) working group in the Transport
> Area of the IETF has been rechartered. For additional information please
> contact the Area Directors or the WG Chairs.
> 
> Network File System Version 4 (nfsv4)
> ------------------------------------------------
> Current Status: Active Working Group
> 
> Chairs:
>   Spencer Shepler <[e-mail]>
>   Brian Pawlowski <[e-mail]>
> 
> Technical advisors:
>   Leif Johansson <[e-mail]>
> 
> Assigned Area Director:
>   Martin Stiemerling <[e-mail]>
> 
> Mailing list
>   Address: [e-mail]
>   To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4
>   Archive: http://www.ietf.org/mail-archive/web/nfsv4/
> 
> Charter of Working Group:
> 
> NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's
> utility and currency, the working group is chartered to maintain the existing
> NFSv4, NFSv4.1, Federated Namespace, and related specifications. The
> working group will also consider a new
> NFSv4 minor version in the form of NFSv4.2 and supporting protocols. Finally,
> deployment guidance will be collected for deployments of the NFSv4 FedFS
> implementations and their interaction with integration with new user
> authentication models.
> 
> Maintenance
> 
> The working group has found that as NFSv4 implementations mature and
> deployments continue, clarifications to existing RFCs are needed.
> These clarifications assist vendors in delivering quality and interoperable
> implementations. The working group is chartered with the vetting of the
> issues and determining correctness of submitted errata.  In the case that the
> needed changes are inappropriate for the errata system, the working group
> will assist in publication of RFCs that provide either editorial modification to
> original RFCs or best practices RFCs.  The completion of RFC3530bis is the first
> work item.  RFCs expected to generate the most discussion or activity
> are: RFC 5661, RFC 5662, RFC 5663, and RFC 5664.
> 
> RFC5664bis
> 
> The NFSv4.1 Objects Layout needs some additional clarification that are to be
> documented in a bis update.  The working group will work final issues and
> deliver an RFC for the clarifications.
> 
> NFSv4.2
> 
> For some time, the working group has discussed the requirements for the
> next NFSv4 minor version.  A consensus has formed within the working
> group for an NFSv4.2 that contains the following:
> 
>    - Server Side Copy
>    - Sparse Files
>    - Seek Hole/Data
>    - Space Reservations
>    - Application Data Blocks
>    - Labeled NFS
>    - Simple IO hinting (modeled from posix IO_ADVISE)
>    - Change Attribute Behaviors
> 
> This is a limited set of functionality that can be effectively documented as an
> "addition" to the base NFSv4.1 protocol (RFC 5661).
> Two of the items in this list, Server Side Copy and Labeled NFS, require a new
> version of the RPCSEC_GSS security abstraction layer.
> Thus two documents will be developed by the working group.
> 
> NFSv4 Multi-Domain Access for FedFS
> 
> As NFSv4 FedFS deployment models are discussed/planned, a significant
> issue related to conflicting user identification spaces exists.  User
> identification collisions can occur when an NFSv4 server exports non-domain
> aware POSIX file systems with separate name (NIS/LDAP) services.  These
> collisions can block proper FedFS operation in large corporations or
> Universities with multiple naming services, or in being a solution to join NFS
> name spaces in corporate acquisitions or across University domains.
> 
> To assist in resolving these issues, the working group will deliver three items.
> 
> First, there are a number of constraints and clarifications to the current
> NFSv4.0 and NFSv4.1 protocols to fully enable cross domain FedFS.
> 
> Second, there is a best practices deliverable describing methods to work
> around the common current situation of non-domain aware POSIX file
> systems, and in managing naming services to cooperate in resolving remote
> domain POSIX UIDs and GIDs for remote user file access.
> 
> Third, the WG needs to track the new work in the GSS-API authentication
> and authorization space (KRB WG, KITTEN WG, ABFAB WG) to ensure NFS
> can take advantage of the new features that address cross domain
> authentication and authorization issues.
> 
> 
> Milestones:
>   Done     - Issue strawman Internet-Draft for v4
>   Done     - Submit Initial Internet-Draft of requirements document
>   Done     - Submit Final Internet-Draft of requirements document
>   Done     - AD reassesses WG charter
>   Done     - Submit v4 Internet-Draft sufficient to begin prototype
> implementations
>   Done     - Begin Interoperability testing of prototype implementations
>   Done     - Submit NFS version 4 to IESG for consideration as a Proposed
> Standard.
>   Done     - Conduct final Interoperability tests
>   Done     - Conduct full Interoperability tests for all NFSv4 features
>   Done     - Update API advancement draft
>   Done     - Form core design team to work on NFS V4
> migration/replication requirements and protocol
>   Done     - Submit revised NFS Version 4 specification (revision to RFC
> 3010) to IESG for consideration as a Proposed Standard
>   Done     - Strawman NFS V4 replication/migration protocol proposal
> submitted as an ID
>   Done     - WG Last Call for RPC and NFS RDMA drafts
>   Done     - WG Last Call for rfc1831bis (RPC version 2)
>   Done     - WG Last Call for NFSv4.1 Object-based layout
>   Done     - WG Last Call for NFSv4 minor version 1
>   Done     - WG Last Call for NFSv4.1 block/volume layout
>   Done     - Submit NFS Minor Version 1 to IESG for publication as a
> Proposed Standard
>   Done     - Submit Object-based pNFS Operations to IESG for publication
> as a Proposed Standard
>   Done     - Submit pNFS Block/Volume Layout to IESG for publication as a
> Proposed Standard
>   Done     - WG Last Call for Requirements for Federated File Systems
> draft-ietf-nfsv4-federated-fs-reqts-01
>   Done     - WG Last Call for Administration Protocol for Federated
> Filesystems draft-ietf-nfsv4-federated-fs-admin-00.txt
>   Done     - WG Last Call for NSDB Protocol for Federated Filesystems
> draft-ietf-nfsv4-federated-fs-protocol-00.txt
>   May 2012 - WG Last Call for Labeled NFS Requirements
>   Jun 2012 - Submit RFC3530bis to IESG (Standards Track)
>   Jun 2012 - Submit Labeled NFS Requirements to IESG (Informational)
>   Jul 2012 - Submit RFC5664bis to IESG (Standards Track)
>   Sep 2012 - WG Last Call NFSv4.2
>   Oct 2012 - WG Last Call RPCSEC_GSS v3
>   Oct 2012 - Submit NFSv4.2 to IESG (Standards Track)
>   Nov 2012 - Submit RPCSEC_GSS v3 to IESG (Standards Track)
>   Nov 2012 - WG Last Call for NFSv4.0/4.1 Cross Domain FedFS document
>   Nov 2012 - WG Last Call for NFSv4 Multi-domain best practices
>   Dec 2012 - Submit NFSv4 Cross Domain FedFS document to IESG
> (Informational)
>   Dec 2012 - Submit NFSv4 Multi-domain deployment guidance to IESG
> (Informational)
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4