Re: [nfsv4] NFSv4 Charter change proposal

[David Noveck <[e-mail]>]

Works for me.

On Tue, Jul 7, 2020, 12:23 PM Black, David <[e-mail]> wrote:

> 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
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>