Re: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience

Chuck Lever <chuck.lever@oracle.com> Mon, 26 September 2016 15:49 UTC

Return-Path: <chuck.lever@oracle.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 5979712B2E7 for <nfsv4@ietfa.amsl.com>; Mon, 26 Sep 2016 08:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.518
X-Spam-Level:
X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qRXwpbXHNA6P for <nfsv4@ietfa.amsl.com>; Mon, 26 Sep 2016 08:49:51 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4B312B2E4 for <nfsv4@ietf.org>; Mon, 26 Sep 2016 08:49:51 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8QFnnlM026008 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2016 15:49:49 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u8QFnmkY015416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2016 15:49:49 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8QFnmnB030536; Mon, 26 Sep 2016 15:49:48 GMT
Received: from [172.20.9.88] (/207.241.138.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Sep 2016 08:49:48 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <MWHPR03MB2893FDD000D7B4BB62D7EC54C7FA0@MWHPR03MB2893.namprd03.prod.outlook.com>
Date: Mon, 26 Sep 2016 08:50:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD956208-68A6-4F7F-A546-A60C980B7ED4@oracle.com>
References: <A69DFCB1-2708-4C31-8A80-11BBA1529A2D@oracle.com> <MWHPR03MB2893FDD000D7B4BB62D7EC54C7FA0@MWHPR03MB2893.namprd03.prod.outlook.com>
To: Spencer Shepler <sshepler@microsoft.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/TH79XWIbznCgK-zNUK4oGUb5ZJY>
Cc: NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 26 Sep 2016 15:49:53 -0000

Spencer, I have heard no further objections to this plan,
so let's go with it.


> On Sep 9, 2016, at 10:14 AM, Spencer Shepler <sshepler@microsoft.com> wrote:
> 
> 
> Chuck,
> 
> I support your proposal as stated - let the I-D stand as-is.
> 
> Spencer
> 
> -----Original Message-----
> From: nfsv4 [mailto:nfsv4-bounces@ietf.org] On Behalf Of Chuck Lever
> Sent: Thursday, September 8, 2016 8:51 AM
> To: NFSv4 <nfsv4@ietf.org>
> Subject: [nfsv4] disposition of draft-ietf-nfsv4-rfc5666-implementation-experience
> 
> Hi-
> 
> The original purpose of draft-ietf-nfsv4-rfc5666-implementation-experience
> was two-fold:
> 
> - To act as a problem statement for updating RFC 5666
> 
> - To act as a stop-gap for helping future implementers of RPC-over-RDMA until an updated RFC 5666 could be published
> 
> IMO these two purposes have been fulfilled, now that rfc5666bis has reached WGLC.
> 
> During the March 2016 RDMA design conference call, Bill Simpson asked that rfc5666-implementation-experience draft be considered to become an RFC. As I understand it, he felt it contained information not in rfc5666bis that could be valuable to future implementers, and thus should be made available as an Informational RFC. There was no objection to publication at that time.
> 
> Strictly speaking, there's no cost to the WG for it, but publishing an RFC is not free. I'm looking at my own workload and the workload of WG chair and the IESG and wondering if there's another way to retain the information in this document without the cost of ratification and publication.
> 
> It does not specify a protocol or even conventions that need consensus; all that is already done in rfc5666bis. If it isn't, rfc5666bis should be changed to include such items.
> 
> I think there is unlikely to be much change to the content of the implementation experience document as it moves through IESG review and beyond.
> 
> If left to expire, this document will continue to exist in the expired I-D archive. I don't see that publication lends increased value, except perhaps by making its content somewhat easier to find. [*]
> 
> Lastly, is this a document that is likely to be cited by others, and would it be of value to other IETF participants? I think its value is largely historical, with perhaps some value as implementation advice. Very much like other I-Ds in the archive of expired I-Ds.
> 
> Therefore, since it is not already cited by other I-Ds, I propose that this document be dropped from the three RDMA related documents that finished last call in June, and allowed to expire.
> 
> Comments?
> 
> 
> --
> Chuck Lever
> 
> 
> [*] We have, already, another expired I-D which is part of the canon of material recommended for RPC-over-RDMA implementers:
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-hilland-rddp-verbs-00&data=02%7c01%7csshepler%40microsoft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636089469137625631&sdata=IR%2fLFVWsfPqsfZsFdpZVPhmazU7peU8wFitiI5evwsg%3d
> 
> Along with these:
> 
>  RFC 1832
>  RFC 5040-42
>  RFC 5531
>  RFC 5666(bis)
>  RFC 5667(bis)
> 
> There is some overlap between that document and RFCs 5040-42, just as there is between rfc5666bis and rfc5666-implementation-experience.
> 
> Spencer Dawkins suggested creating an nfsv4 wiki where we could cite this kind of reference material. Is that of interest to anyone?
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fnfsv4&data=02%7c01%7csshepler%40microsoft.com%7cd5af168cdf4f4b18677208d3d8008460%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636089469137625631&sdata=2HChNwS8JNDzEVTlLnjGyzbJ1REYu4SSzKsc92G8mQQ%3d

--
Chuck Lever