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

David Noveck <davenoveck@gmail.com> Thu, 04 June 2020 13:15 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA073A0C6D for <nfsv4@ietfa.amsl.com>; Thu, 4 Jun 2020 06:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swMKEC614bIo for <nfsv4@ietfa.amsl.com>; Thu, 4 Jun 2020 06:15:33 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEB53A08FA for <nfsv4@ietf.org>; Thu, 4 Jun 2020 06:15:32 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id c35so4688987edf.5 for <nfsv4@ietf.org>; Thu, 04 Jun 2020 06:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s6bQzyd3hxCY+zN7I8h/MG8iFxvNlc+NYm6jKsLZBxQ=; b=oqEeIUIZtQjqblcFi/eXyCiLZLSdQo0kTjZTy+/AgH5zLBzy7VDKgYrHoWcokziUWr JHe3BvpiOYhY2GkJ//s6Kb35EzhNPw4L2uYwZzaUY97fDSihG3h9x23avpdh2qn6mSp0 BG7qR/fSTC0AuDkUcCpHjMplY+ERedjcnJt9ZYcrUlAQIFLKr5D+xWOJxF84+BtbkgTS 9/p09dEPa6mWT6vXdszV3oK8s9SOLu5Fy8Ffwp0f1NZ7QswXJlf5eRMAsJOHCQkf7GWy x6bZRU8gRegq7hMhV/7JP87wQVUbO0gLueCLCsPi3I4k9Yfa7eqfBhowGeZLmhGkel6J 7yag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s6bQzyd3hxCY+zN7I8h/MG8iFxvNlc+NYm6jKsLZBxQ=; b=tSnh6Ndwjz2Azb9LuUaGs36EC3ZuotTW3H145g2RJd34BvKdEQ8JnZevrd8LBnYxQy hy3Cmy4gPqTlQosAKpFLPhwEIT22hF+Ts1OGYSjk48D5TxHUIo+gLP28bsesZU4bW3xx 9Lw43K+YGlLfg7BbF0qclNOnK70PEWw2hLrVp5PUwkM+duFn8gJeGc6g5UWlMTAqeC/Z X4ibHERYQPP+Whcmoi5jBTHPoYJ4glVA/5/vTS8IW9xySAEUG6perqq4QYcLbJdUTUy2 lksp4ZEt+b110ryLAasbSeBSfJIS7ZShE88N5TzRM8igeC1lKy2cDT2lAisTzc66KJ12 Lr6w==
X-Gm-Message-State: AOAM5302KS0a1EKUykD38JnXz3t/cxP2CWa4AyKQ+eNIWQ3WfGFMscU1 GH1PLkws9JTFBKPDoXHejA7JroxDXi433p46Lnc8BBwP
X-Google-Smtp-Source: ABdhPJxuvPjEq8+xY3E2VOE0e5a32Af98sGWCA3KkJIP27tEVe5zK9yNuctmZQ9IHCcTk1N688uwNU3P5L+AdH2wKAQ=
X-Received: by 2002:aa7:d054:: with SMTP id n20mr4175197edo.344.1591276531275; Thu, 04 Jun 2020 06:15:31 -0700 (PDT)
MIME-Version: 1.0
References: <CADaq8jfgREzCvi=rZk4tEg8uLnA2mDeeQF0drC9kWrL11JH4Sg@mail.gmail.com> <4a88fddce55d78d1b64fc0a4f6d71d910bb7ada2.camel@ericsson.com> <MN2PR00MB068665937287B4AF541F8A3EA0880@MN2PR00MB0686.namprd00.prod.outlook.com> <6d9f4bb4c0c0661841f38940fe0b4a71893764fa.camel@ericsson.com> <MN2PR00MB06861C2E6C2982BC2C39A3FAA0880@MN2PR00MB0686.namprd00.prod.outlook.com> <CADaq8jcQpxAYqWk3RigviVFq4rauMx9Q8QPEQKf+UQWmm2hbJw@mail.gmail.com> <87d5836b-73b9-869f-b3ca-975cb84179fb@talpey.com>
In-Reply-To: <87d5836b-73b9-869f-b3ca-975cb84179fb@talpey.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 04 Jun 2020 09:15:20 -0400
Message-ID: <CADaq8jfWGT8ys530KhYS2rx9=JCnY7-MBKbj8v6CBy+LyBCihw@mail.gmail.com>
To: Tom Talpey <tom@talpey.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062dd6605a741f09e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/NShlm4QDkD8My4896u8lKQnBZ_Q>
Subject: Re: [nfsv4] Proposed charter changes (with updates)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 13:15:36 -0000

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

I see your point but the fact is, it is being cited as an example.  How
abut the following as the final paragraph:

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


On Thu, Jun 4, 2020 at 8:17 AM Tom Talpey <tom@talpey.com> wrote:

> 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 <ttalpey@microsoft.com
> > <mailto:ttalpey@microsoft.com>> 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 <magnus.westerlund@ericsson.com
> >     <mailto:magnus.westerlund@ericsson.com>>
> >     Sent: Wednesday, June 3, 2020 11:44 AM
> >     To: davenoveck@gmail.com <mailto:davenoveck@gmail.com>; Tom Talpey
> >     <ttalpey@microsoft.com <mailto:ttalpey@microsoft.com>>
> >     Cc: nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> >     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 <magnus.westerlund@ericsson.com
> >     <mailto:magnus.westerlund@ericsson.com>>
> >      > Sent: Wednesday, June 3, 2020 9:55 AM
> >      > To: davenoveck@gmail.com <mailto:davenoveck@gmail.com>
> >      > Cc: Tom Talpey <ttalpey@microsoft.com
> >     <mailto:ttalpey@microsoft.com>>; nfsv4@ietf.org <mailto:
> nfsv4@ietf.org>
> >      > 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  +46 10 7148287
> >      > Torshamnsgatan 23           | Mobile +46 73 0949079
> >      > SE-164 80 Stockholm, Sweden | mailto:
> >     magnus.westerlund@ericsson.com <mailto:
> magnus.westerlund@ericsson.com>
> >      >
> >
>  ----------------------------------------------------------------------
> >      >
> >      >
> >     --
> >     Cheers
> >
> >     Magnus Westerlund
> >
> >
> >
>  ----------------------------------------------------------------------
> >     Networks, Ericsson Research
> >
>  ----------------------------------------------------------------------
> >     Ericsson AB                 | Phone  +46 10 7148287
> >     Torshamnsgatan 23           | Mobile +46 73 0949079
> >     SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> >     <mailto:magnus.westerlund@ericsson.com>
> >
>  ----------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>