Return-Path: 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 A3ACF12EAEE for ; Tue, 9 May 2017 13:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 tTgxuc-9dDte for ; Tue, 9 May 2017 13:06:35 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 B62A012EAED for ; Tue, 9 May 2017 13:06:33 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id o12so875992iod.3 for ; Tue, 09 May 2017 13:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eW6F4GqM1S8faje8A/nmdwSeBhhSn8uzNm+WNBBc3UM=; b=Nd6dIBr9+MIVsKkRxQbq2pMtXTkOYpqVUoEWmymBn9xVMZjYWI14KCLSi1+9DcYfx9 ZolkWeHeei/XRurrJzA3Vb1y01Ene4zptUuuasiQKcqvE62Z0ZJErinTHzkAKAZxBsV2 EaopztYa0jKHryOHqIOeof4MKBv2j97OCddeso9bOd7Y0+8OX7Hwq23mhGg2T4D31XQG w7UDCUPvj8pjmZqMgp9J2oU0f5gEk4NJ+/HcuvEZ2DvyA8VTWsunxfk9nazQTJbagTMi g0SvhgVDItahjFsJ1Yl9V2+Kq4t840o68t7wHNnZSR+gIP1nYpmPtHWKFc3ek2VDCKqf wSfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eW6F4GqM1S8faje8A/nmdwSeBhhSn8uzNm+WNBBc3UM=; b=KejTy/R75DgwtuqrSJXQ/QBYXKzvhponoChD7WxJzsI8zC6k56Er3xdsOIkIZ7lv69 A+ol7g9NB7Fy/Lb31EVXgLmTXt51xQbABlJXxkSesDsgm16kpmLGa7jin+TUiH+YzDDG uo2xFq5zK2jZb6gbfuYyQ10GO5LJWjPj60S1tF4ovlSDfwB41zNVJDd08ZphJI50p8WD 1wlSyfyocjeRl6zEYIDfrgDTUUzgStHBZjVRCIyrEizjXRRJvOrGfxWt4nNZxLajuAxb xsqcPbIW5llLZ1bJUAtTk7KGNNPson0Qe3DB3iTwAtQsIVqk85n44EX9H1sDCuETpr1A aRJA== X-Gm-Message-State: AODbwcD+0yqwLbmosvU7RBEqcq0sUJ0aWJb+1P9PonMKbnvCfmlBXdqk 18PafUEpu2ht5dYvkFFKtzH7NnjJYbAG X-Received: by 10.107.143.148 with SMTP id r142mr150355iod.137.1494360393031; Tue, 09 May 2017 13:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.75 with HTTP; Tue, 9 May 2017 13:06:32 -0700 (PDT) In-Reply-To: <2EB173A0-FBEB-49E0-BE26-CCB3DB71D99E@oracle.com> References: <4332475259118046202@unknownmsgid> <9BD2081A-A365-4720-8C05-25A580113882@oracle.com> <2EB173A0-FBEB-49E0-BE26-CCB3DB71D99E@oracle.com> From: David Noveck Date: Tue, 9 May 2017 16:06:32 -0400 Message-ID: To: Chuck Lever Cc: Brian Pawlowski , Brian Pawlowski , "nfsv4@ietf.org" , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=94eb2c05a28e64ab3d054f1ce422 Archived-At: Subject: Re: [nfsv4] WG Charter update - email discussion, close at IETF99 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 20:06:37 -0000 --94eb2c05a28e64ab3d054f1ce422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > IMO FedFS is truly > moribund (and I'd bet there are others on the WG who knew > this years ago), thus looking forward, perhaps the charter > should not mention FedFS. You've convinced me. The next draft version I send out will drop FedFS. When I did the initial draft I left things out only if I was certain they should be gone, but now, with your feedback, I will try to remove things based on my best understanding of the situation. People are still free to object but I hope that people who have an issue with this will not wait until Prague to raise objections. > I wasn't sure, but I thought this work was complete with the > publication of RFC 8000. I'm thinking part of our review should > determine what else might be needed. I'm not sure about this since the existing charter mentions a number of possible documents. I'm still waiting to hear from Andy about this section but if he tells us there is no there there, we don't need a review although anyone would still be free to propose something in this area. On Tue, May 9, 2017 at 2:51 PM, Chuck Lever wrote: > > > On May 9, 2017, at 12:49 PM, David Noveck wrote: > > > > > IMO the maintenance and extension sections should also mention > > > ONC RPC (and RPCSEC GSS) explicitly. A new version of RPCSEC > > > was recently ratified, and RPC can be extended in the future > > > to operate on new types of transport layers. > > > > Good point. > > > > > > > > Performance Challenges > > > > > /layout/layout type > > > > > Is work on respecifying RPC-over-RDMA Version One considered > > > maintenance or performance? > > > > I consider it both and I don't think it is a problem. Performance is t= he > > motivation while each of the performance items fits under one of the > > mechanisms, either being maintenance or extension > > > > > My impression from Dallas was > > > this was maintenance of existing specifications. > > > > Under the old charter, there was no performance category. > > > > It fit under maintenance at Dallas since: > > =E2=80=A2 Very few people people had read the charter and so most= did not > understand how constrained the concept of maintenance there was. > > =E2=80=A2 At the time we embarked on this, we didn't realize that > substantive technical changes were required., and thought of this (wrongl= y) > as purely a matter of editorial correction. For example the bi-direction > work, while clearly necessary, did not fit in the existing charter. > > > > > Where does Andy's multi-path work fit? > > > > > Does it need explicit mention in the WG charter? > > > > I'll leave that question to Andy. From a motivation point of view, thi= s > is performance-related. > > > > As far as mechanism, Andy has mentioned the possibility of an additiona= l > attribute with connection bandwidth/capability information, which would b= e > a v4.2 extension. > > > > Other work would probably fit in the maintenance category. When > migration-issue-13 is out, we can talk about plans to follow up. I'd li= ke > 20 minutes at IETF-99 for the working group to discuss this. > > > > > Does the WG want to continue pursuing FedFS, if only in > > > maintenance mode? > > > > This is something the working group will have to decide, but if there i= s > nobody to do the work, it doesn't matter what the WG decides. > > Fair enough. I'm not volunteering. > > The question is whether it is worth a mention in the charter > as part of the WG's maintenance mission. IMO FedFS is truly > moribund (and I'd bet there are others on the WG who knew > this years ago), thus looking forward, perhaps the charter > should not mention FedFS. > > > > > Is Andy's multi-domain work able to continue if FedFS is removed from > the docket? > > > > I think it can. IIRC his document was not limited to FedFS but treated > it as one likely use. > > > > As far as I am concerned, the man question is whether Andy wants to > continue this work. I certainly think it is useful > > I wasn't sure, but I thought this work was complete with the > publication of RFC 8000. I'm thinking part of our review should > determine what else might be needed. > > > -- > Chuck Lever > > > > --94eb2c05a28e64ab3d054f1ce422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> IMO FedFS is truly
> m= oribund (and I'd bet there are others on the WG who knew
> this years ago= ), thus looking forward, perhaps the charter
> should not mention FedFS.

You've convinced me.=C2=A0 The next draft versi= on I send out will drop FedFS.

When I did the= initial draft I left things out only if I was certain they should be gone, but
now, with your feedback, =C2=A0I will try to remove t= hings based on my best understanding
of the situation.=C2=A0

People ar= e still free to object but I hope that people who have an issue with this w= ill
not wait until Prague= to raise objections.

<= span style=3D"font-size:12.8px">> I wasn't sure, but I thought this = work was complete with the
> publication of RFC 8000. I'm thinking part o= f our review should
> determine what else might be needed.

I'm not sure a= bout this since the existing charter mentions a number of possible=C2=A0
documents. I'm still wa= iting to hear from Andy about this section but=C2=A0
if=C2=A0he tells us there is no there there, we don't need a review although a= nyone=C2=A0
would still b= e free to propose something in this area.


On Tue, May 9, 2017 at 2:51 PM, Chuck Lever <c= huck.lever@oracle.com> wrote:

> On May 9, 2017, at 12:49 PM, David Noveck <davenoveck@gmail.com> wrote:
>
> > IMO the maintenance and extension sections should also mention > > ONC RPC (and RPCSEC GSS) explicitly. A new version of RPCSEC
> > was recently ratified, and RPC can be extended in the future
> > to operate on new types of transport layers.
>
> Good point.
>
>
> > > Performance Challenges
>
> > /layout/layout type
>
> > Is work on respecifying RPC-over-RDMA Version One considered
> > maintenance or performance?
>
> I consider it both and I don't think it is a problem.=C2=A0 Perfor= mance is the
> motivation while each of the performance items fits under one of the > mechanisms, either being maintenance or extension
>
> > My impression from Dallas was
> > this was maintenance of existing specifications.
>
> Under the old charter, there was no performance category.
>
> It fit under maintenance at Dallas since:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Very few people people had read th= e charter and so most did not understand how constrained the concept of mai= ntenance there was.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 At the time we embarked on this, w= e didn't realize that substantive technical changes were required., and= thought of this (wrongly) as purely a matter of editorial correction. For = example the bi-direction work, while clearly necessary, did not fit in the = existing charter.
>
> > Where does Andy's multi-path work fit?
>
> > Does it need explicit mention in the WG charter?
>
> I'll leave that question to Andy.=C2=A0 From a motivation point of= view, this is performance-related.
>
> As far as mechanism, Andy has mentioned the possibility of an addition= al attribute with connection bandwidth/capability information, which would = be a v4.2 extension.
>
> Other work would probably fit in the maintenance category.=C2=A0 When = migration-issue-13 is out, we can talk about plans to follow up.=C2=A0 =C2= =A0I'd like 20 minutes at IETF-99 for the working group to discuss this= .
>
> > Does the WG want to continue pursuing FedFS, if only in
> > maintenance mode?
>
> This is something the working group will have to decide, but if there = is nobody to do the work, it doesn't matter what the WG decides.

Fair enough. I'm not volunteering.

The question is whether it is worth a mention in the charter
as part of the WG's maintenance mission. IMO FedFS is truly
moribund (and I'd bet there are others on the WG who knew
this years ago), thus looking forward, perhaps the charter
should not mention FedFS.


> > Is Andy's multi-domain work able to continue if FedFS is remo= ved from the docket?
>
> I think it can.=C2=A0 IIRC his document was not limited to FedFS but t= reated it as one likely use.
>
> As far as I am concerned, the man question is whether Andy wants to co= ntinue this work.=C2=A0 I certainly think it is useful

I wasn't sure, but I thought this work was complete with the
publication of RFC 8000. I'm thinking part of our review should
determine what else might be needed.


--
Chuck Lever




--94eb2c05a28e64ab3d054f1ce422--