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

[David Noveck <[e-mail]>]

> Indeed. But I'm not sure the QUIC WG will take up an upper layer-
> specific matter,

Possibly not.

> so I am expecting the same rule might apply.

I dont'see how we can take a rule designed for the case in which the
responsible working group doesn't exist and apply it to a case in which the
responsible working group does not want to take on the work.   That's
clearly a different situation.

In that case, the work charter proposal says we "will work with the
responsible working group to make sure needed extensions are available".
 In the case in which we want something that the Quic working goup doesn't
want to do, we would do it, unless it is something that the QUIC working
group doesn't think should be done.

> That's why I suggested an AD needs to be in the loop, to review the
assignment.

I thought it was intended to assure the IESG, that we are not going to do
stuff without supervision.

In any case, as a practical matter, there is no way would do any of this
without the responsible AD's approval/support.

On Thu, Jun 4, 2020 at 7:42 AM David Noveck <[e-mail]> wrote:

>
>
> 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]
>> ----------------------------------------------------------------------
>>
>>
>>