Re: [nfsv4] NFSv4 Charter change proposal

David Noveck <davenoveck@gmail.com> Tue, 07 July 2020 08:18 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 078F13A07A0 for <nfsv4@ietfa.amsl.com>; Tue, 7 Jul 2020 01:18:37 -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 T2TbOWOnlyMU for <nfsv4@ietfa.amsl.com>; Tue, 7 Jul 2020 01:18:35 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 B67CD3A07A2 for <nfsv4@ietf.org>; Tue, 7 Jul 2020 01:18:34 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id a8so36435048edy.1 for <nfsv4@ietf.org>; Tue, 07 Jul 2020 01:18:34 -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=i7HMjmzZVqTQpVPexxjAgQY7s4OgqLdgw30skdadRR0=; b=OXq45PVUGeFo2LDWBBifsLhWMK9SUurHiS1YnoHMojxzZSTSttyjSzGlICGfCjuuTS MCP10xFtNFFETpFkWwgvO1UijjrfTeOB0UEc1q+qTFF2GHDxKGCo3fxsXhrHN8MEllk7 S+LA7i4QkmTlEZjmsZS+KjpIAAeywbPWdhZverbJp/eyWdbeFcKKH4c7/+KfBUa6DP4e c3ATVhrsycFtvMshx3FUYseZd6xHb2huEHzh8e9DF5V4qMS5UWKEGjrgFHO8zdPWmkvz vTVbdobmURk0HI1Q/DG8grBjk7UAy83J4Kr/siukmQOKna4GF6FDwhrb6lYUT9zcFevy t9JA==
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=i7HMjmzZVqTQpVPexxjAgQY7s4OgqLdgw30skdadRR0=; b=dAh/VIrM3S0qKrYUtwpg+IL/L+3IDfxlQngvnfSvM+3Csnayr2dYWgbdB4V3bqPYYa PC7q52Zss1/5WkKCCFJKwCmOzytBCjHJPWEVtGAdQ8iD6K9+jnVsfvNIUYm5NfvOsxAl 8KQN/Wt22x+sSUkMqPTtpAjmyDr5CppyqrmDjOU9yktHvk5PHBNY4NVo8cQ2RKpm/p97 DwL/rjDI91o3n8xgG70ZoS7k03auP27ywmfhUYbeLqIvS+Z+11/N5XelGpIDlBy0dXPe yJzRwa4NCuUxeGrXAioLkjfzfFau4coQ45gdCfvR+f4xZ3717lsKiDixjVJ1zOq0aK65 yhjQ==
X-Gm-Message-State: AOAM531SH5dkeaUENVqVr+6uwJGZ1MfYKeQq6eUqMLXoBq0Cx5hoZoK9 iu3mmesLY4lWWc8eGEvt4ErcB6pk+Fj0vkv4zXg=
X-Google-Smtp-Source: ABdhPJy4Ox7heHE8VkWiDGkR2CYXWzMhaaAioRjFnI9ceo0/Uj/1jGDoCwEbqbTw23oWVhw4hjHt/11gsRLunBf1OaQ=
X-Received: by 2002:aa7:c54e:: with SMTP id s14mr60831814edr.81.1594109913015; Tue, 07 Jul 2020 01:18:33 -0700 (PDT)
MIME-Version: 1.0
References: <1c46b13053661a78fb69ee8783f29130447eff63.camel@ericsson.com>
In-Reply-To: <1c46b13053661a78fb69ee8783f29130447eff63.camel@ericsson.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 07 Jul 2020 04:18:21 -0400
Message-ID: <CADaq8jdubM5JoyKf3xM5Uis1OpBgDnBXPuAxSsQ-CKwUfM5obg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019287c05a9d5a36d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/QCvQIsCYHRypiI9r8Lj_FjEqYfw>
Subject: Re: [nfsv4] NFSv4 Charter change proposal
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: Tue, 07 Jul 2020 08:18:37 -0000

On Mon, Jul 6, 2020 at 7:44 AM Magnus Westerlund <magnus.westerlund=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> I like to discuss the proposed charter change as written by David:
>

Just to provide the proper context, I'd like to state that the motivation
for this change is,  and has always been, to enable us to take part in the
work for Tom's push-mode draft.


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

I thought that the existing paragraph, which dealt with extending
facilities for ONC, could be extended to deal with this situation.  It
appears, given the months that Tom has had to wait, it appears that I was
wrong 😞.

What I wanted to avoid was an unmotivated random statement saying
essentially, "By the way, the working group can also do Tom's
Push-mode draft". I wanted the charter to present a coherent area of
responsibility.  If that can be dispensed with, then we can cite the
specifics of Tom's proposal and go forward that way.


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


IIRC, this was inserted mainly to assure the IESG that we were not
intending to go poaching into other groups' work.  If there is something
specific about the wording that might confer undue license on the v4 wg,
I'm open to discussing changes to make this more limited.


> >
> > 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 if there is something that provides the wg broad discretion, it is this,
which only deals with working groups which we depend on that don't exist,
only applies to RDDP.  I don't see how this is a real worry.

>
> So I am not a great fan of unspecific allowances.


So we gather, although it seems to me that this
significantly understates the matter.


> Especially when it comes cross
> WG matters.


You've made that clear but I want us to focus on how we can most
expeditiously enable Tom to proceed on the push-mode draft about which
there seems to be no debate as to the suitability of the v4 wg as a home.



> Sorry if I am missing any context here, but if this is to enable a
> mapping to QUIC.


I don't think it is.


> 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 agree that such extensions would best be addressed in that way.


> I will note that the QUIC WG is kept on a short leash so far when it comes
> to
> extensions.
>
> Understood, but if that is the case, then that "short leash" would apply
to us, if we were to co-ordinate work with them, any such "short leash"
would apply to us as well.


> 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 don't see the need for this as the current charter, not all that old, has
been satisfactory.  Is there some specific difficulty that would motivate a
rechartering at this point? I realize that it is not as tightly constrained
as you might prefer, but doing a complete rewrite now would be a
considerable effort and it is not clear who is available to drive such an
effort.  In particular, I'm busy enough balancing the demans of 5661bis and
my day job as it is.   I have no cycles available to deal with a charter
rewrite.  Is there anyone else who does?

GIven that this group deals with maintenance, a tightly constrained charter
could undercut the effectiveness of the group, since it is often hard to
know, in advance, what is broken.  This could result in broken things not
getting fixed in a timely fashion if any proposal to fix them needs to
involve a lengthy charter discussion.

We created the v4 extension mechanism to simplify the process of making
simple discrete v4 extensions.  The kind of charter you are considering
would undercut that by involving the IESG in such matters. I don't think
the working group or the IESG is prepared for that.

>
> I am happy to discuss this more on Thursday.
>
> The agenda is pretty full.   I can carve out five or ten minutes but there
is no time to resolve the major philosophical differences that appear to
exist.

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



>