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

--001a113e574e95d407054275b16d
Content-Type: text/plain; charset=UTF-8

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
>

--001a113e574e95d407054275b16d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Perhaps we can revisit your suggestions when some of the d=
ocuments<div>currently in WGLC (three!) require shepherding.=C2=A0 For a ve=
ry long time,=C2=A0</div><div>Spencer has been the only person doing shephe=
rding and I don&#39;t feel=C2=A0</div><div>that this situation can go on fo=
rever.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Tue, Nov 29, 2016 at 1:52 PM, Benjamin Kaduk <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mon, Nov 28, =
2016 at 12:32:58PM -0500, David Noveck wrote:<br>
&gt;<br>
&gt; We&#39;ve tried reminders and Chuck did remove unnecessary work.=C2=A0=
 However, the<br>
&gt; IETF rules don&#39;t appear to allow changing ownership of the task of=
<br>
&gt; producing a wrIteup.=C2=A0 If you think that is appropriate, then perh=
aps you<br>
&gt; should investigate it.=C2=A0 Given that there is a bunch of other docu=
ments that<br>
<br>
</span>The &quot;IETF rules&quot; (insamuch as there are rules) do allow fo=
r changing the<br>
document shepherd after assignment, and for non-WG-chair document shepherds=
.<br>
The chairs have a fair amount of latitude in assigning shepherds, as I unde=
rstand it.<br>
We&#39;ve been having similar problems with a backlog of documents in the k=
itten<br>
WG, and recently had a contributor volunteer some time to help shepherd<br>
documents, which has made a big difference.<br>
<span class=3D""><br>
&gt;<br>
&gt; True, but there is a significant portion of the process where we wind =
up<br>
&gt; waiting for action by the WG chair, and for these documents, that has =
been<br>
&gt; a considerable portion of the delay.=C2=A0 Is there a viable way to sp=
read out<br>
&gt; this work better?<br>
<br>
</span>Bringing in non-chair document shepherds might help, and there is al=
so<br>
some possibility (in terms process) of adding a third co-chair, if there<br=
>
are suitable candidates and the current chairs/AD are amenable.<br>
<br>
Ultimately, it comes down to finding someone willing to do the work who<br>
has time; shepherding is some of the least glorious work (you don&#39;t eve=
n<br>
get your name on the final RFC!), but is still an important part of<br>
the document lifecycle.<br>
<br>
I see that the two documents in the subject have already been submitted<br>
for publication, so maybe there is no longer an immediate need, but it<br>
still seemed worth pointint out that there are a few options in this space.=
<br>
<br>
-Ben<br>
</blockquote></div><br></div>

--001a113e574e95d407054275b16d--

