Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update

Spencer Shepler <> Mon, 28 November 2016 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3F66129538 for <>; Mon, 28 Nov 2016 08:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4prcoQC1Y4bw for <>; Mon, 28 Nov 2016 08:53:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04E91129E9A for <>; Mon, 28 Nov 2016 08:53:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KPfDECdSZ3aNGRayq8OBA1GIv4Vavt6oxPUjvzxCVVw=; b=WQMd4zsR4ZIRDitZfgZu66ZuKS7L6H9CtcD2r8XuOo6ijA1AE5152mepY5R4ScVz/8Nzj/CnYqOxu09nAR36m/sXgOKGORJVNVzY7tFtl0qqW1Ze1Y8A2wSbseOYhsuouS2X5UMmgYC9Brx0WjKGDUGbobvg7A0XaLMmAhMHozA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 28 Nov 2016 16:53:44 +0000
Received: from ([]) by ([]) with mapi id 15.01.0747.015; Mon, 28 Nov 2016 16:53:44 +0000
From: Spencer Shepler <>
To: David Noveck <>, Chuck Lever <>
Thread-Topic: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update
Thread-Index: AQHSLtFppAwC81h0l0KannmYTOjwDqC5VR3QgAAPlwCAKqprAIAAA5CAgAjZ+oCAAeRw4A==
Date: Mon, 28 Nov 2016 16:53:44 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:d::6a6]
x-ms-office365-filtering-correlation-id: 9e5f6566-426c-4c43-7f4f-08d417af1d6a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR03MB2893;
x-microsoft-exchange-diagnostics: 1; MWHPR03MB2893; 7:MklpAu6GA7CYUAm+OM6QkG7HgkzLpVywq3YScuNeWisOTD9KDUqjN9YeKmlLTRSiAcsbhqZygXDe7pC7FWfoJLo32Zl1u6aUWx7sGWdr/E7RumMVLBV0CY2gEaBN7rZ7v0gam1eo3qMSoufzAEOfos603nghMjcEhgAi59uCESzL7GTQlJxqPgyMAuQTjlxGsgCAxcRQfO8BYuDb6hqKwXgATE2wBbziUF6xi0RXTWkORovsP/uGR4NaeNe0Ap9atJCc/CROqfkL2iC1HWuxOzYghbxlCpGyAPcYASzE94qc5Csb3yMsvSTJn7rRzJ3rVEQrW4P4GO8dDGJQ9K8CL413IbBOsGQ/NdyDYXQa10kGcgraMApEgem2hr802XKffRapWSG32cQwo1Z1JK21TsSi5Dzp1pDu+w4hQdPi6Ntz/G/QduHPKtdjCXLVeSIIvTRVVQASoFcSN305ziKcHRZzYtXrhLy5VqFxUocbpUs=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(60795455431006)(100405760836317)(21748063052155)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6041248)(6061324)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6047074)(6042181)(6072148); SRVR:MWHPR03MB2893; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2893;
x-forefront-prvs: 01401330D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(99286002)(105586002)(106356001)(54356999)(106116001)(76176999)(101416001)(2950100002)(33656002)(189998001)(97736004)(102836003)(790700001)(50986999)(7110500001)(4326007)(6116002)(5005710100001)(74316002)(10290500002)(10710500007)(5001770100001)(3280700002)(8990500004)(5660300001)(2906002)(10090500001)(15650500001)(3660700001)(7736002)(7846002)(2420400007)(122556002)(229853002)(93886004)(7696004)(92566002)(8936002)(68736007)(77096006)(8676002)(76576001)(81166006)(81156014)(2900100001)(38730400001)(39060400001)(6506003)(9686002)(86612001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2893;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR03MB28934787F990928A41E84830C78A0MWHPR03MB2893namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 16:53:44.4054 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2893
Archived-At: <>
Cc: "" <>
Subject: Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Nov 2016 16:53:48 -0000

For this comment, “If we want to improve the process, and I believe we should, we need to focus on review quality/adequacy as well as the pace of the process.”

If there is a desire for an item to move more quickly, treat it like any other item in life – take responsibility for it, invest the time, get others that are needed to do the same.

There are a variety of techniques for managing work that is done by others.  Reminders, regularly scheduled conference calls, changing ownership, breaking the tasks into smaller items, discarding unneeded functionality to move the process forward.

The “process” can move more quickly if desired – at least for the items that are under direct control and in the case of Internet Drafts – most of it is under the control of the authors and the collective working group once there is consensus that an I-D is a WG draft.


From: nfsv4 [] On Behalf Of David Noveck
Sent: Sunday, November 27, 2016 3:55 AM
To: Chuck Lever <>
Subject: Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update

So the review process will not be interrupted.  It will continue at the same pace as before.

With regard to the characterization of the process as "excruciatingly sluggish", it does seem that not very much has happened since the working group reached consensus on  this document on 4/17/2016 (according to the data tracker history).

However, to be fair, we should note that draft-ietf-nfsv4-rfc5666bis-00 was submitted on 12/01/2015 and it it took the working group less than a year to get to the point we are.    It looks likely to me that the whole process will (cross your fingers) be completed in around 16 months from first submission.   It is hard to get documents done faster than that within the IETF process, which is not optimized for speed.

Contrast that with RFC5666 itself which took over five years from -00 submission to RFC publication.  Despite the slow pace of the process, it appears that the document did not get the kind of review it needed before publication, making rfc5666bis necessary. I'd like to thank the authors for persevering in the effort to provide NFS with an RDMA-based transport.

If we want to improve the process, and I believe we should, we need to focus on review quality/adequacy as well as the pace of the process.