Re: [nfsv4] List of possible work items for NFSv4.2

["David P. Quigley" <[e-mail]>]

I'm also committed to being a secondary author on the RPCSEC_GSSv3
document and I will be glad to work with anyone who wants to help author
a proper document on DOIs and Interoperability using the MAC attribute.

Dave

On Sat, 2009-08-15 at 07:58 -0700, Mike Eisler wrote:
> Reading through responses, both those published to the list and privately
> sent to me, I see a strong consensus for NFSv4.2, strong indication
> that there are people willing to contribute to the document process as
> orginators, editors, and reviewers, and strong indication that this work
> will be prototyped/implemented.
> 
> I propose:
> - that NFSv4.2, RPCSEC_GSSv3, MAC be authorized as a work items immediately.
> -- I further propose that the primary editors of these three work items be,
>    respectively, Mike Eisler, Nico Williams, and Dave Quigley.
> - For the NFSv4.2 document, we start by combining the COPY operations I-D,
>   and the part of the MAC I-D that describes the RECOMMENDED MAC attribute.
> -- We should have a discussion and reach consensus on how to combine
>    sub-file caching
> (http://tools.ietf.org/html/draft-eisler-nfsv4-pnfs-dedupe
>    or
> http://tools.ietf.org/html/draft-myklebust-nfsv4-byte-range-delegations),
>    peer-to-peer NFS (
> http://tools.ietf.org/html/draft-myklebust-nfsv4-pnfs-backend ),
>    and unstable file create (see Trond's emails on this thread),
>    and then fold this consensus into NFSv4.2.
> 
> Going through the items one by one:
> 
> On Wed, August 12, 2009 8:41 pm, Mike Eisler wrote:
> 
> > Peer-to-Peer NFS
> 
> Strong indication of support for this work in terms of reviewing,
> contributing and implementing (it has already been prototyped).
> Trond wants to re-do the prototype once the NFSv4.2 form of this
> work is clarified.
> 
> > Copy
> 
> James indicated he'd like to continue to contribute here, including
> with implementation. Tom Haynes also indicated a possibility to contribute
> here.
> 
> > Hole Punching
> 
> I received a private response that proposals for hole punching and
> thin provisioning will be coming soon.
> 
> > MAC Security Attribute
> 
> Dave Quigley is committed to contributing to
> 
> > Traffic Classification
> 
> Thus far, no renewed interested has been expressed on this.
> 
> > End-to-End Data Integrity
> 
> Thus far, no renewed interested has been expressed on this.
> 
> 
> > Umask Attribute
> 
> Thus far, no renewed interested has been expressed on this.
> 
> > Shutdown Callback
> 
> Thus far, no renewed interested has been expressed on this.
> 
> > Readahead Hint
> 
> Thus far, no renewed interested has been expressed on this.
> 
> > pNFS Connectivity/Access Indication
> 
> A fresh item from Stockholm IETF meeting; absence of
> re-stating support for this is not absence of proof of interest.
> I for one am committed to seeing this solved in NFSv4.2.
> 
> > Better Negotiation of Session Reply Cache Sizes
> 
> A fresh item from after Stockholm IETF meeting; absence of
> re-stating support for this is not absence of proof of interest.
> But I remain luke warm on this ... not entirely convinced there is
> a problem to solve.
> 
> > Metadata Striping
> 
> Andy Adamson has expressed interest in prototyping this.
> 
> > De-Dupe Awareness and Sub-File Caching
> 
> In the context of peer-to-peer NFS, I see continued interested
> in sub-file caching. Sub-file caching as proposed my me, gives
> one de-dupe awareness for free (or the converse depending on
> how one wants to look at it). As I've proposed at the beginning of
> this message, the WG needs to discuss how it wants to approach all
> these topics before adding them to an NFSv4.2 I-D.
> 
> New items:
> 
> - unstable file creates. This has a lot of interested within the WG
> - capabilities: An item proposed by Nico Williams
> - attributes: Dan Muntz expressed an interest in revisiting how attributes
>   are handled.
> 
>