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

Chuck Lever <chuck.lever@oracle.com> Thu, 08 September 2016 15:55 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 3E31912B0D0 for <nfsv4@ietfa.amsl.com>; Thu, 8 Sep 2016 08:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Level:
X-Spam-Status: No, score=-5.709 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=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MTu8s1HmiXHP for <nfsv4@ietfa.amsl.com>; Thu, 8 Sep 2016 08:55:07 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 B9B9B12B0DF for <nfsv4@ietf.org>; Thu, 8 Sep 2016 08:51:04 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u88Fp3wW019768 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Thu, 8 Sep 2016 15:51:03 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u88Fp3CO030782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Thu, 8 Sep 2016 15:51:03 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u88Fp1WD005331 for <nfsv4@ietf.org>; Thu, 8 Sep 2016 15:51:02 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Sep 2016 08:51:01 -0700
From: Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <A69DFCB1-2708-4C31-8A80-11BBA1529A2D@oracle.com>
Date: Thu, 08 Sep 2016 11:51:00 -0400
To: NFSv4 <nfsv4@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
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/TJuD_hW5Xo4FzueJfeV5-zpgB98>
Subject: [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: Thu, 08 Sep 2016 15:55:09 -0000

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://tools.ietf.org/html/draft-hilland-rddp-verbs-00

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?