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

David Noveck <davenoveck@gmail.com> Tue, 29 November 2016 19:35 UTC

Return-Path: <davenoveck@gmail.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 20A971299A1 for <nfsv4@ietfa.amsl.com>; Tue, 29 Nov 2016 11:35:44 -0800 (PST)
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 85SFNOAnyvPl for <nfsv4@ietfa.amsl.com>; Tue, 29 Nov 2016 11:35:42 -0800 (PST)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 ADBB212960E for <nfsv4@ietf.org>; Tue, 29 Nov 2016 11:35:42 -0800 (PST)
Received: by mail-oi0-x22b.google.com with SMTP id b126so203206290oia.2 for <nfsv4@ietf.org>; Tue, 29 Nov 2016 11:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CvmM61FGEyIHhEqHbSeR6aEqKkTiVLi2FN8+kvTYUTw=; b=lZAAhwOtlRaKJDDczbA8zT8Y2Xmy8l6qDTaYcRTB2ptRbwBCTNqf3D+t7vJyQEpmug nBNDg6aj/6A5uZjLqWzdd/aC43ic94GxB0//P2ydt4CfL//Pd/Ky5JOHTGJTnZRIkdj0 GG9+98J1d7rbazO/YSktichcvK/WZR5hcbVAARrM3C9Vi34XBpcL9ruWAsPuKGjychnF yk697tBD7smQRMoy6nhzU0JYVJX3V21NapR8bA/IZo7WLe4OL5eap3wIki3vmfVVlu7c O7hftjFio+QYsZGwgG1hbVaLu7KiobmkfsW37Qu5RS7x7iUd4WO3e51MSypfvZezAQBj OHsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CvmM61FGEyIHhEqHbSeR6aEqKkTiVLi2FN8+kvTYUTw=; b=f4iAwvg2nbldFUhReLoOYt6BZO2R6V4pYk5oJXqagix0p88rsuCrp9BRBag130LD5i k+jPfcQMEboKY67/2tBI0Vatc7iam6tie4tkiTi6qUG5R7g08lVntNPARbU7fnKIGx6l pcLorKhoJZD3A/CRG1TyukDDO7AuP75eXMRIWv86D8T4k5Gh1OyB2rlimyCOCfJXF/JU feLwihrUWdIIqIENGguoxnAiMsTXT1IuqnBRlpzqmWH4kBlS5O6XixoLyFSYR+KGdj/6 OTJCAxJwZImhVC+ETczR5GrPqk9jZPqQLl7V9EBvU4GZ5aRUrs7IhadW6OQLavnjQlER RwiQ==
X-Gm-Message-State: AKaTC01QNQdmIfJDgcDrLHhOBEN+u0n9NAErB21xzeLfRIAfzkdNy8QcB9/B1sCroyYYrxIdezFtl+7FDsjojA==
X-Received: by 10.202.71.207 with SMTP id u198mr14579405oia.165.1480448141545; Tue, 29 Nov 2016 11:35:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Tue, 29 Nov 2016 11:35:40 -0800 (PST)
In-Reply-To: <20161129185223.GB8460@kduck.kaduk.org>
References: <6ED97840-F1BF-4BBC-9C01-7F0A8943CB78@oracle.com> <MWHPR03MB289336B4D7E04D053D27D225C7A80@MWHPR03MB2893.namprd03.prod.outlook.com> <4958FA14-2C47-4AEA-A72F-1C83F92DB4BE@oracle.com> <a3368e2b-ae35-ddef-80b3-d33646e46d88@gmail.com> <F924E4D7-3E26-4BFA-A82E-3713CDBC560A@oracle.com> <CADaq8jduTgJCsdhVmDV0wiiuhf0fkJXYYbsJ0znibipqFuQOZw@mail.gmail.com> <MWHPR03MB28934787F990928A41E84830C78A0@MWHPR03MB2893.namprd03.prod.outlook.com> <CADaq8jdpMCuq5k+k_Gjj4rC6iOgCt5xjwjorcPakRgsbqOWfMg@mail.gmail.com> <20161129185223.GB8460@kduck.kaduk.org>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 29 Nov 2016 14:35:40 -0500
Message-ID: <CADaq8jdR0AQafQ4VJA_+zq0oPSQKbMrqHQspPsKXXXn7n_+JFQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="001a113e574e95d407054275b16d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/TswRz8qLihFVlNGO9ziQH3GFQoM>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] rfc5666bis and rpcrdma-bidirection progress update
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: Tue, 29 Nov 2016 19:35:44 -0000

Perhaps we can revisit your suggestions when some of the documents
currently in WGLC (three!) require shepherding.  For a very long time,
Spencer has been the only person doing shepherding and I don't feel
that this situation can go on forever.

On Tue, Nov 29, 2016 at 1:52 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> 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.
>
> -Ben
>