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

John C Klensin <john-ietf@jck.com> Thu, 25 April 2019 20:10 UTC

Return-Path: <john-ietf@jck.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 D8A8712024E for <ietf@ietfa.amsl.com>; Thu, 25 Apr 2019 13:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 m27Zf04u-1dk for <ietf@ietfa.amsl.com>; Thu, 25 Apr 2019 13:10:10 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50E6120240 for <ietf@ietf.org>; Thu, 25 Apr 2019 13:10:09 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hJkh3-000Jbu-6J; Thu, 25 Apr 2019 16:10:05 -0400
Date: Thu, 25 Apr 2019 16:09:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Nico Williams <nico@cryptonector.com>
cc: S Moonesamy <sm+ietf@elandsys.com>, ietf@ietf.org
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
Message-ID: <8DD74B1AFDFDA6774289AF4B@PSB>
In-Reply-To: <20190425173218.GV3137@localhost>
References: <CABcZeBNdaWU4wwOK_MnWC5hOr7Lu3osmC_6_KKxB5fHuHVHyTw@mail.gmail.com> <23d54797-5c94-aa00-ec55-3f2c4fdfcfae@comcast.net> <6.2.5.6.2.20190424095017.13cdadc8@elandnews.com> <51068F13-E90F-42A2-8AE2-627D5E18B145@akamai.com> <20190424201939.GM3137@localhost> <6.2.5.6.2.20190424134823.0c9faf68@elandnews.com> <20190424211123.GO3137@localhost> <6.2.5.6.2.20190424144539.0cabcde0@elandnews.com> <20190424234334.GQ3137@localhost> <11F97591808485C30AD98A22@PSB> <20190425173218.GV3137@localhost>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dcJGq74Y2XJufZCgMO2mKFxFhfY>
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: Thu, 25 Apr 2019 20:10:13 -0000


--On Thursday, April 25, 2019 12:32 -0500 Nico Williams
<nico@cryptonector.com> wrote:

> On Thu, Apr 25, 2019 at 01:24:11PM -0400, John C Klensin wrote:
>> Nico,
>> 
>> Let me note two bits of history and then suggest that you (and
>> others who have responded to the idea of reviewing and
>> potentially approving this document by an Individual
>> Submission process with the sort of righteous outrage that I
>> read into your last comment/jest above) tone it down a bit. 
> 
> I think you may have misread my note.  There was no outrage.
> My point was that having to host a BoF due to no AD sponsoring
> the I-D is hardly a serious problem.  The author seemed more
> upset than I thought should be the case.

I won't try to speak for the author (as I've said, it would
exaggerate my role in the I-D to describe it as "secondary"),
but let me address what you are interpreting (correctly or not)
as "upset".  First note the comments in my earlier message about
asking a body to make changes that increase its accountability
and the vunerability of its members to unpleasant removal
actions.  Also note that, although different people can, and do,
interpret actions in different ways and that, ADAIK, none of the
people on the IESG now were on the IESG "then", the IESG doesn't
have a great track record for processing community-initiated
procedural changes that constrain AD behavior.  The two examples
that come to mind are the efforts many years ago to change WG
creation and retention rules to avoid regular increases in the
size of the IESG and/or the length of f2f meetings and the
results of the NEWTRK WG that would have actually changed the
standards process.  In the first cases, despite considerable
discussion, one interpretation of events is that the IESG
refused to either initiate a Last Call on any of the proposals
or to move in the direction of creating a WG to work on the
topic.  Again, people's interpretations and recollections will
differ on whether there were good and substantive reasons such
as an accurate judgment that the community really didn't care.
NEWTRK is probably more complicated and, again, other
interpretations of what happened are possible (and certainly out
there) but after a BOF, long discussions about charter, and
creation of a WG that did considerable work, the WG came up with
I-Ds that successfully went through WG Last Call... and the IESG
essentially refused to conduct an IETF Last Call on the subset
of those I-Ds that would have constrained the IESG's behavior.

I'm not suggesting that, in declining to handle this document as
an Individual Submission that is almost entirely fine tuning,
the IESG had any motivations along those lines, but, from the
standpoint of those who think the proposed changes are
fine-tuning needed to restore the appearance of fairness as the
population of people who mostly participate remotely increases,
the two possible ways to progress the document look like:

(1) Focus the discussion, walling off discussions of other
things that might or might not be desirable to create new
mechanisms for removing members of the leadership or even make
other changes to the recall procedure, hold an IETF Last Call,
and, if there is community support for the proposal, approve it
and move on.   Assuming approval for calculation purposes, by my
count and allowing for another week or so of discussion, a
four-week IETF Last Call, and a month for the IESG to do its
evaluation (shouldn't take that long, but...), that leads to a
document in the RFC Editor's hands in mid-August.  

(2) Start down the path of a BOF in Montreal to think about
things, possibly one organized to discuss these changes as part
of a general review of nominations and accountability
procedures.  I think the latter is consistent with Alissa's
note, although it is possible that I misinterpreted it.  Now,
that could move along swiftly: BOF the third week in July,
approval of a charter and appointment of WG leadership on July
26, a WG meeting at IETF 106, a couple of weeks of WG Last Call
starting around Dec 1, IETF Last Call starting sometime in
January, document to the RFC Editor in February sometime.  There
are ways to make that go faster, but, if the justification for a
BOF and WG is really to allow opening up the broader issues,
that schedule might be optimistic.    In addition, while I trust
it is not the case, if the purpose of asking for a BOF and WG is
to drag this out until people lose interest and move on, then
the Montreal BOF is determined to be inconclusive (at least as
much as matter of IESG discretion as how to handle an Individual
Submission), leading to another BOF in Bangkok if people don't
just give up, a WG chartering process that stretches at least
into January, discussions continuing until at least halfway
through 2020 (again, if people don't just lose interest), and
then no guarantees that the IESG will actually act on the WG's
conclusions if, against all odds, it reaches conclusions.

Again, not speaking for either Subramanian or even myself, it is
not completely irrational for those who see the I-D as making a
very small but important change to restore to appearance of
fairness to compare the two options, consider the Independent
Submission one _much_ more appropriate, and to question the
effects and motivation for the BOF-plus-WG plan... especially in
the light of the last several new documents and updates to older
ones that affect the recall process being handled as Individual
Submissions/

     john

p.s. If one wants to open the entire can of worms, I've believed
for some years that, as the IETF becomes more diverse, the whole
idea of handling Individual Submissions at the discretion of ADs
has become inappropriate and prone to abuse and unfairness.
Many of us can find at least a few examples of documents that
appear to have been processed on that track because the
submitters were friends,  cronies, or co-workers of the relevant
ADs (even if some other AD nominally takes over formal
responsibility) while other submitters who have lacked that type
of qualification get their documents ignored or are forced
toward the BOF and WG approach only to be told that not enough
of the community cares about the document to be worth the
investment of resources.  Perhaps Individual Submissions, at
least for Standards track documents, should require a petition
signed by a significant number of active IETF participants with
bars against too many people from the same organization.   I'd
hope we would not feel a need to bias _those_ petition
requirements against people who contribute remotely.