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

Benjamin Kaduk <> Tue, 29 November 2016 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 837401298B3 for <>; Tue, 29 Nov 2016 10:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ad-49waVlY3e for <>; Tue, 29 Nov 2016 10:52:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CCAC1295C0 for <>; Tue, 29 Nov 2016 10:52:28 -0800 (PST)
X-AuditID: 12074422-7f3ff700000047b1-de-583dce6bd22f
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D9.EB.18353.B6ECD385; Tue, 29 Nov 2016 13:52:27 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id uATIqQZo004925; Tue, 29 Nov 2016 13:52:26 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id uATIqNVo031643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2016 13:52:25 -0500
Date: Tue, 29 Nov 2016 12:52:23 -0600
From: Benjamin Kaduk <>
To: David Noveck <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nrpt9zjbCYOEWAYuzU7+xW8x+/4jV YvuDuywOzB47Z91l91iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGXeW72ApuMlb8XvlAcYG xgbuLkZODgkBE4ljy+aydDFycQgJtDFJrLrRDuVsZJQ4/m4KK4RzlUni/M5VLCAtLAKqEsf2 3WUEsdkEVCQaui8zg9giAuoSPx40sXUxcnAwC0RITF4MtkFYwF3iz9RPTCA2r4CxxNm/3cwQ M3tYJDom7mSFSAhKnJz5BGw+s4CWxI1/L5kg5khLLP/HARLmFAiU+Py5hw3EFhVQlmiY8YB5 AqPALCTds5B0z0LoXsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4dF2U djBO/Od1iFGAg1GJh3dCn22EEGtiWXFl7iFGSQ4mJVHef0eAQnxJ+SmVGYnFGfFFpTmpxYcY JTiYlUR4L50ByvGmJFZWpRblw6SkOViUxHkZ3L+GCwmkJ5akZqemFqQWwWRlODiUJHhjzgI1 ChalpqdWpGXmlCCkmTg4QYbzAA0vPgUyvLggMbc4Mx0if4pRUUqc9yvIVgGQREZpHlwvKLVI ZO+vecUoDvSKMG8RyAoeYFqC634FNJgJaPDb19Ygg0sSEVJSDYwzjn2wn7O/N+bfLFavafNd Z6Vt1XDzddH4uDL3yfErT9++6G0LPsBpz935dl2rdf5LKbMZIYnaNxrnKphEL4vsUU7meNF3 4OMxd8fFk3tDj+ruqw+P2Lfhcqqj5XOuRaW8zKyGTU+0a032XGWZNdFXSvXA/ci31TpVsv+i v77c45739jLHrkIlluKMREMt5qLiRAAUU3cyCAMAAA==
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: Tue, 29 Nov 2016 18:52:29 -0000

On Mon, Nov 28, 2016 at 12:32:58PM -0500, David Noveck wrote:
> We've tried reminders and Chuck did remove unnecessary work.  However, the
> IETF rules don't appear to allow changing ownership of the task of
> producing a wrIteup.  If you think that is appropriate, then perhaps you
> should investigate it.  Given that there is a bunch of other documents that

The "IETF rules" (insamuch as there are rules) do allow for changing the
document shepherd after assignment, and for non-WG-chair document shepherds.
The chairs have a fair amount of latitude in assigning shepherds, as I understand it.
We've been having similar problems with a backlog of documents in the kitten
WG, and recently had a contributor volunteer some time to help shepherd
documents, which has made a big difference.

> True, but there is a significant portion of the process where we wind up
> waiting for action by the WG chair, and for these documents, that has been
> a considerable portion of the delay.  Is there a viable way to spread out
> this work better?

Bringing in non-chair document shepherds might help, and there is also
some possibility (in terms process) of adding a third co-chair, if there
are suitable candidates and the current chairs/AD are amenable.

Ultimately, it comes down to finding someone willing to do the work who
has time; shepherding is some of the least glorious work (you don't even
get your name on the final RFC!), but is still an important part of
the document lifecycle.

I see that the two documents in the subject have already been submitted
for publication, so maybe there is no longer an immediate need, but it
still seemed worth pointint out that there are a few options in this space.