Re: [nfsv4] Proposed charter changes (with updates)

[David Noveck <[e-mail]>]

On Wed, Jun 3, 2020, 3:21 PM Tom Talpey <[e-mail]> wrote:

> Thanks for the QUIC terminology correction, previously I understood the
> upper-layer specific stuff to be considered "extensions". And, at this time
> none are proposed by or for NFSv4, although I suspect there will be
> someday.
>

Rdma-oriented work  is certainly possible and would be of interest to us

Also it's worth noting again that this is only for cases where no WG exists.
>

I'm assuming that QUIC will continue to exist for quite a while so such
work is unlikely to be relevant to the charter changes being discussed.



> I'll leave it to Dave to propose final text,


I certainly hope it is final.  As Magnus rightly points out, there is
important core work to do, so I think we have to limit how much time we
spend  on assuaging IESG anxieties about us doing crazy things that are
clearly outside the limits we propose.

except to suggest that to address your
> preference, we might word this as
>

I like your changes and will produce proposed final text below.  One change
I will make is to address the contradiction between "help" and "itself".
You got that from my original text ☹️.

This proposed text will be in the original multi-paragraph format to make
it clearer that only *extensions *are to be done and not whole new
transport protocols.😩

  In cases in which there is no assigned working group, and under the
> coordination
>   of the relevant Area Director(s), the NFSv4 WG can help develop the
> necessary
>   extension itself.
>
>   An extension to RDMAP, RFC5040/7306, for enhanced memory placement
>   ("Push Mode") is chartered, as the first such effort.
>
> Comments?
>

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. For example, an extension to
RDMAP, RFC5040/7306, for enhanced memory placement ("Push Mode") would be
authorized, as one such effort.


> Tom.
>
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]>
> Sent: Wednesday, June 3, 2020 11:44 AM
> To: [e-mail]; Tom Talpey <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: Proposed charter changes (with updates)
>
> On Wed, 2020-06-03 at 14:17 +0000, Tom Talpey wrote:
> > In my earlier suggest, I proposed "e.g. transport". While I don't think
> the WG
> > needs to dive into TCP or SCTP, there is certainly an RDMA item, and I
> would
> > foresee a possible QUIC extension someday?
>
> So, e.g. transport is very wide. It would allow you to do a new transport
> protocol which I don't think is ok. And I think you may want to do is what
> QUIC
> working group calls a protocol mapping, rather than a QUIC extension which
> is an
> actual extension to the QUIC protocol.
>
> I really prefer the charter to be quite specific on what you want to do.
>
> I also want to remind you that I really want to you to finish up your core
> items
> include updates to take care of the major issues around security,
> internationalization etc that the partial update to 4.1 discussed.
>
> Cheers
>
> Magnus
>
>
>
> >
> > -----Original Message-----
> > From: Magnus Westerlund <[e-mail]>
> > Sent: Wednesday, June 3, 2020 9:55 AM
> > To: [e-mail]
> > Cc: Tom Talpey <[e-mail]>; [e-mail]
> > Subject: [EXTERNAL] Re: Proposed charter changes (with updates)
> >
> > Hi,
> >
> > I think the last sentence of the last paragraph will get comments by the
> IESG.
> > It is a bit to much a blank check for you to go do anything which IETF
> doesn't
> > already do. So are there ways to be more specific?
> >
> > Otherwise it might be possible to add some safe guard to this sentence.
> > However,
> > I would actually prefer that we rather run through rechartering if you
> want to
> > updated or extend things in areas outside of your current scope.
> >
> > Cheers
> >
> > Magnus
> >
> > On Sun, 2020-05-24 at 07:25 -0400, David Noveck wrote:
> > > First of all, thanks to Daniel and Tom for corrections/suggestions.
> > >
> > > I am 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 two-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 lower-layer 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, it can help develop the necessary extension itself.
> > >
> > >
> >
> > --
> > Cheers
> >
> > Magnus Westerlund
> >
> >
> > ----------------------------------------------------------------------
> > Networks, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Torshamnsgatan 23           | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> >
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>