Re: [nfsv4] NFSv4 Charter change proposal

["Black, David" <[e-mail]>]

Hi Magnus,

> So I am not a great fan of unspecific allowances. Especially when it comes cross WG
> matters.

Ok ... as Tom subsequently wrote:

Tom> Just to confirm, no, there is no linkage at all to QUIC from Push Mode.
Tom> It is a straight-up RDMA extension, with no transport implication on TCP, QUIC, or any other lower layer.

I understand the specific intent here is to have the NFSV4 WG take on responsibility for maintenance and extension of the RDMA protocols originally developed by the RDDP WG (RFCs 5040-5045, e.g., RDMAP, DDP and MPA) and subsequently maintained by the STORM WG (i.e., RFCs 6580, 6581 and 7306).  The draft that Tom is working on is akin to RFC 7306 - it's primarily a functional extension to RDMAP (RFC 5040), but also has some impacts on DDP (RFC 5041).

I'd suggest updating the charter with a paragraph that states that scope explicitly, e.g.:

	The NFSv4 working group is also responsible for maintenance and extension
	of the RDMA protocols originally developed by the now-concluded RDDP WG
	(RFCs 5040-5045, e.g., RDMAP, DDP and MPA) , whose maintenance and
	extension were previously handled by the now-concluded STORM WG.

The overall structural goal here is not to send that activity to TSVWG, as the relevant expertise is in the NFSV4 WG rather than in the TSVWG WG, and TSVWG has more than enough work to keep it busy ;-).

Thanks, --David

> -----Original Message-----
> From: nfsv4 <[e-mail]> On Behalf Of Magnus Westerlund
> Sent: Monday, July 6, 2020 7:44 AM
> To: [e-mail]
> Subject: [nfsv4] NFSv4 Charter change proposal
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> I like to discuss the proposed charter change as written by David:
> 
> > I am now proposing replacing the second paragraph of the extensions
> > section which now reads:
> >
> > Similarly, associated ONC protocol components that have a versioning/
> > extension framework can be incrementally extended, when necessary.
> >
> > By the following three-paragraph replacement:
> >
> > In dealing with needed extensions to areas that underlay NFSv4, the
> > working group's role will depend on the specific area needing
> > extension.  In the case of associated ONC protocol components, those
> > that have a versioning/extension framework can be incrementally extended,
> when necessary.
> >
> > In the case of  extensions needed to lower-layer transport facilities
> > of particular importance to NFSv4, the working group will work with
> > the responsible working group to make sure needed extensions are available.
> >
> > In cases in which there is no assigned working group,  the  Nfsv4
> > working group can, with coordination provided by the relevant Area
> > Director(s), help by developing the necessary extension itself, as is
> > being done in providing an extension to RDMAP, RFC5040/7306, for enhanced
> memory placement ("Push Mode").
> >
> >
> 
> So I am not a great fan of unspecific allowances. Especially when it comes cross WG
> matters. Sorry if I am missing any context here, but if this is to enable a mapping to
> QUIC. Then I think the WG and proponents for this can discuss a individual draft
> until you think you understand the problem and what requirements that puts on
> QUIC and if new functionality. Having that understanding it is much clearer to
> determine how to best charter that work.
> 
> I will note that the QUIC WG is kept on a short leash so far when it comes to
> extensions.
> 
> When it comes to the charter I am actually considering if we should do a complete
> rewrite to a more focus charter that are more explicit on what set of work the WG
> is doing.
> 
> I am happy to discuss this more on Thursday.
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4