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

[Tom Talpey <[e-mail]>]

Your reply really chopped up the quoting. I'll cherry-pick...

On 6/4/2020 7:42 AM, David Noveck wrote:
> 
> 
> On Wed, Jun 3, 2020, 3:21 PM Tom Talpey <[e-mail] 
> <mailto:[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.

Indeed. But I'm not sure the QUIC WG will take up an upper layer-
specific matter, so I am expecting the same rule might apply. That's
why I suggested an AD needs to be in the loop, to review the assignment.

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

This sounds hypothetical. Because this is a charter update, I think the
"for example", "would be", and "as one such effort" should be deleted or
moved to a separate statement.

Tom.


>     -----Original Message-----
>     From: Magnus Westerlund <[e-mail]
>     <mailto:[e-mail]>>
>     Sent: Wednesday, June 3, 2020 11:44 AM
>     To: [e-mail] <mailto:[e-mail]>; Tom Talpey
>     <[e-mail] <mailto:[e-mail]>>
>     Cc: [e-mail] <mailto:[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]
>     <mailto:[e-mail]>>
>      > Sent: Wednesday, June 3, 2020 9:55 AM
>      > To: [e-mail] <mailto:[e-mail]>
>      > Cc: Tom Talpey <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[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] <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]
>     <mailto:[e-mail]>
>     ----------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>