Re: AD Sponsorship of draft-moonesamy-recall-rev

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 24 May 2019 09:49 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2723120160 for <ietf@ietfa.amsl.com>; Fri, 24 May 2019 02:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3DpYhFM0KiiU for <ietf@ietfa.amsl.com>; Fri, 24 May 2019 02:49:55 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 7BCF21200DB for <ietf@ietf.org>; Fri, 24 May 2019 02:49:54 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id f1so6644666lfl.6 for <ietf@ietf.org>; Fri, 24 May 2019 02:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UHG7Acu31j9RswMLwHHtDoqM4ziL/Lurl0pmwFmuEKs=; b=fj88/U5+R+x5SPG+NO1eEWA4ulCwiBySy4WZh58S/YgN0CFdFY0W9Td98uuWMdO2+N Yn/tc/xGbxU6H31X1THpMC1BTzY/Bj3G5LO7OwEEBpZ1dK+K4GeLqUZEeq0qAiGHpUgr SQwKpqlHJWXEsMz+Kl6jjGO9S3gr+NIlgYNSkJ4sOKX9ke3ksWIWtHKOhwyUohdWbTaq Yp1rD192sKcX9QUdMjkTNUVNfqx07SIbOXdDyhqY5CAifkEIt/ii8+3SBujdq3hosNsW m/vKPcBVewgSivGkQGN8bL9jVQx5YwBD3Iwn2MqYRWdJbxAD1irfYas93k5/CR8QUN0P FvPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UHG7Acu31j9RswMLwHHtDoqM4ziL/Lurl0pmwFmuEKs=; b=NNuGWQxK6xPceL6NbdDAE/q54gZ2A++zwwHdUmTDgdXxOzDSUW8/XgrT6TiQ7TqSeA Ptddcz1r6QO/tUBK1Xy2e8qk74NxxEts0Zyl6pxpwjJEBSX4f/0SKbxcrwQKf6YsdK3s Nz8fTBO/Hgq/NZeSK+zLZ0cmiWTciUXQyqz5jZ7kZRe+6NJqPtJ6SgSV+VPFTtW4neYf Fy21xE20WN9vLQ3Jj6+Y7XE4ObyYO7OcW4NUizNLGSkkFTwuGYDkyNCC/GtuCUVfq0+e mfl3JNWiulYpB6UW4BQJRrn8dHz/L+9Q2oytJr2rj8FW3GW0rqFLMJsD3u3oknpkENW1 rUGA==
X-Gm-Message-State: APjAAAWbOKglDerjfNX6q3/eko+/5R8CZV6LFEOctum888XAluHA7qEU 2l2fRfU0lrKlgY8zzNKO9CoeVdvSP262mMYtR+A=
X-Google-Smtp-Source: APXvYqyUgy/tqgFLKFjqnnc3aLSJnRzdGUSGSBx5B5W2JTGMFqTFfgFtvej6Zpthja7RpB76bRsUwo59F6mBninMN8U=
X-Received: by 2002:ac2:4209:: with SMTP id y9mr11431846lfh.83.1558691392603; Fri, 24 May 2019 02:49:52 -0700 (PDT)
MIME-Version: 1.0
References: <6.2.5.6.2.20190509041736.0d6d4548@elandsys.com> <f5834466-8f40-42bd-82d8-4dcb7d418859@www.fastmail.com> <6.2.5.6.2.20190509105617.0c08ef60@elandnews.com> <e854adaf-1ead-41d0-95bf-df56cb5a5914@www.fastmail.com> <6.2.5.6.2.20190514234822.0bc461f0@elandnews.com> <15BCE05FEA1EEA6AD0E7E5BD@PSB> <6.2.5.6.2.20190516103829.11f9fb18@elandnews.com> <E85C84CF-DB0B-410E-A0B2-A7C7E705E469@kaloom.com> <6.2.5.6.2.20190518141450.1163e590@elandnews.com> <75FF5D48-C416-4198-BC44-1B25524BF0E2@cooperw.in> <6.2.5.6.2.20190520025912.0ce8f378@elandnews.com> <CABcZeBNV0VxRrW0-Z4hY4zh_Ok3cRM8FJGyogYogP6R6X8K12Q@mail.gmail.com> <6.2.5.6.2.20190524004523.0ccaf558@elandnews.com>
In-Reply-To: <6.2.5.6.2.20190524004523.0ccaf558@elandnews.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 24 May 2019 09:49:27 +0000
Message-ID: <CAKKJt-fxYm5+YuCOF8skD8ej0vZnGTT9_7JzdSgpnyYnp2232g@mail.gmail.com>
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
To: S Moonesamy <sm+ietf@elandsys.com>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF list <ietf@ietf.org>, John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary="000000000000c54dcf05899f1ec1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wsvdgqNQMZPe2q27LffkE4NjMTs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 09:49:57 -0000

I'm still jet-lagged at RIPE, but just to try to contribute to this
discussion in a helpful way ...

On Fri, May 24, 2019 at 9:15 AM S Moonesamy <sm+ietf@elandsys.com> wrote:

> Dear Mr Rescorla,
> At 03:45 AM 20-05-2019, Eric Rescorla wrote:
> >I'm not on any kind of I*, but when I was, the idea behind an IAB
> >shepherd was not that primarily that they provided a review but that
> >they helped the proponents of the work navigate the IETF process
> >(especially the BOF process) and get to a crisp problem statement,
> >etc. I never thought of it as a requirement, but rather something
> >that was intended to result in a more productive discussion.
>

This is actually written down in more detail in
https://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-member-roles-in-evaluating-new-work-proposals/,
which seems to be one of the more obscure practices at IETF, since when I
was on IESG and referred to it in discussions with IESG and IAB members,
people often told me they hadn't seen it.

The IAB could have changed that practice last week at their retreat, or
could have decided it needed to be changed, but AFAIK, the 2012 version is
still operative (the IAB has become way more transparent, but they still
review their meeting minutes before they publish them).

This might also be useful information for other people proposing IETF 105
BOFs, of course ...


> Thank you for providing the above information.
>
> The short draft was intended to be narrow in scope (re. crisp problem
> statement).  Some time back, I served as editor of a draft which was
> discussed at length on this mailing list.  My co-author also served
> as editor of other drafts.  He has much more experience than I do
> with respect to getting drafts through the IETF process.
>
> As a comment about IETF process, it was pointed out to me that a
> Working Group Chair cannot author drafts within his/her working
> group.


I was only on the IESG for six years, but AFAIK, this isn't quite right.

It's common, in TSV at least, for WG chairs to author drafts in their own
WGs. What we don't do, is have WG chairs shepherd their own documents. The
idea is that you don't get to declare consensus on your own document.

This is the same thing as me authoring drafts while I was on the IESG (I
did), but not being the responsible AD for publication.

But both of those are practices - the operative principle is to Do The
Right Thing.


> That does not seem to be a problem for other Working Group
> Chairs; some of them have been authored drafts in their working
> groups.  That can create a perception that the rule, if there is one,
> is applied in different ways to different people.


Working group chairs, and ADs, have a lot of flexibility because we rely on
them to Do The Right Thing, If that flexibility is misused, that's a
problem. Please speak up if this looks like a problem to you - there is an
appeals chain, and it starts with the person who takes a problematic
action.

I was able to wear my IETF 104 t-shirt at RIPE this week, which says "Make
Good Choices", and that's as true now, as it was in March.

Best wishes, of course.

Spencer


> I am okay if the
> IAB wishes to provide guidance on a problem statement about that as
> part of the revision to IETF eligibility procedures.
>
> I read draft-rescorla-istar-recall-00.  One of the conclusions from
> it is that the recall system is so unwieldy that it is undeployable
> even in the most egregious cases.  I could not figure out the
> rationale for having an accountability mechanism which, by design, is
> not intended to work.
>
> There is the following sentence at the end of Section 3 of the draft:
> "The Chair of the IETF may not be removed by expulsion".  That is an
> interesting proposal.
>
> Regards,
> S. Moonesamy
>
>