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

S Moonesamy <sm+ietf@elandsys.com> Sat, 25 May 2019 19:47 UTC

Return-Path: <sm@elandsys.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 0E81F1200EB for <ietf@ietfa.amsl.com>; Sat, 25 May 2019 12:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=c87dE6AC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=upxGyHLw
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 5IGo7GdXC0Ty for <ietf@ietfa.amsl.com>; Sat, 25 May 2019 12:47:13 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA99120021 for <ietf@ietf.org>; Sat, 25 May 2019 12:47:12 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.49.188]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x4PJktHm010066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 May 2019 12:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1558813629; x=1558900029; bh=cqAiglbARSXler9LZh4w9xlor635AADm2FZpEqgcPDQ=; h=Date:To:From:Subject:In-Reply-To:References; b=c87dE6ACGX6ikSOzU6i5Pd3c+dqJEFSuxX4JBhDHMA66jzM6huqcKP9qOJ/8iVsI/ 6hpPdA7PjvqX+IuRP7/P+/gbRYZYVpMsEVrFyWKp7t2NCACKdOAfWyKG9hNqomKaIj gJmey5kGL/q+LoTJat5Oh9v/czsSqT204QMUo0nE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1558813629; x=1558900029; i=@elandsys.com; bh=cqAiglbARSXler9LZh4w9xlor635AADm2FZpEqgcPDQ=; h=Date:To:From:Subject:In-Reply-To:References; b=upxGyHLw1kCcOb4l/OsNiibzuFjNGIdb5rpxh1EXZAJ/IgTdfMr5eu3rmDhbY9txE JvSBUh/fDbuGeZN5Q6lvkAum05Fd+/fw/A3qT29eRlBLa1/7rxPznBocIzH9Vc1yJJ ZttJBA8jrmqWg1nO/P4vzS1f2feJymaSJRjoXJNE=
Message-Id: <6.2.5.6.2.20190525005132.0e003be8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 25 May 2019 12:46:28 -0700
To: John C Klensin <john-ietf@jck.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, ietf@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
In-Reply-To: <AA1980490AAFFA9C4D3AED7D@PSB>
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> <CAKKJt-fxYm5+YuCOF8skD8ej0vZnGTT9_7JzdSgpnyYnp2232g@mail.gmail.com> <AA1980490AAFFA9C4D3AED7D@PSB>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/GDhEdDk4WBs_f3eoNKTSMck6gXo>
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: Sat, 25 May 2019 19:47:15 -0000

Hi John, Spencer,
At 02:23 PM 24-05-2019, John C Klensin wrote:
>Since I've been cited in my co-author capacity, a few
>comments...  Note that, while I supplied an earlier draft for
>use as a starting point, left the question of whether to list me
>as co-author to SM, and agree with what this draft is trying to
>accomplish, I've been trying to stay out of this one.  The
>reasons may become clear below.

I viewed it as the appropriate thing to do.

>Once upon a time, there was general agreement that, if something
>was a "real" procedure, it was agreed upon by community
>consensus, published in the RFC Series, and then generally
>adhered to. IESG (and IAB) statements, when made at all, were
>general guidance to the community about how the IESG (or IAB)
>intended to do its work, rather than rigid rules: if special
>circumstances arose, good sense would always be applied rather
>than prior statements about procedures. In that same long-ago
>time, if an IESG or IAB member, or the whole bodies, started
>behaving as if they had somehow been anointed with imperial, or
>perhaps divine, wisdom or authority, the community had, and
>used, corrective methods that were far faster and less ambiguous
>than the recall mechanism, typically methods that were applied
>at plenaries and that often involved, at least metaphorically,
>airborne application of ripe fruit.

The "IESG Statements" might be similar to "executive orders" except 
that their status is unknown.  The IESG also invented the 
IONs.  There is some information about that in RFC 6393.

I have heard of imperial bodies.  I find it odd that an entity which 
describes itself as the "most prominent standards bodies" seeks to 
evolve into an elected monarchy.  However, there is not much I can do 
about it as it is easy for a person to be targeted when it is known 
that he/she does not have access to the redress mechanism.

>My impression is that the community at that time was far more
>concerned about several members of the IESG (or of the IAB)
>getting together to force someone out who was taking strong
>positions that didn't agree with the majority view than it was
>about serious and objective malfeasance or non-feasance.

I assume that you are referring to using one's position to push an agenda.

>Like more good stories starting with "once upon a time", some
>aspects of that era are at least a bit mythical.  But I think

Anyone from afar might view it as an era of enchantment.

>things have actually changed and that, in particular, the use by
>the community of plenaries as a control function for any issues
>significantly more important than the quantity or quality of
>cookies has largely vanished.  Among other effects, that makes
>the recall mechanism the community's first line of defense
>against bad behavior rather than a second or third level method.
>If that is true, it better be equally available to all
>participants in the IETF and it better be fair.  It should also
>be usable in practice, but those are actually separable problems.

The plenary have fallen in disuse since over a decade.  I suggest 
taking a look at Section 4 of RFC 7437.

>As the co-author who is presumably being referenced, I believe I
>have learned three things about process change proposals in the
>last decade (I see NEWTRK as a turning point; others may have
>different impressions):
>
>(1) While we can make, or at least pretend we can make, purely
>technical decisions about protocol standards, procedural ones
>are inevitably a matter of taste.  That turns "whose taste?"
>into an important question, especially if there are tradeoffs
>involving who might be helped or put at risk by a particular
>decision.

It is not possible to make those purely technical decisions without a 
set of procedures to regulate how the decisions will be taken.  As 
John mentioned, those decisions could be perceived as a matter of taste.

>(2) Procedural change proposals that originate with (or are
>actively discussed within) the IESG and that are written up by
>one AD and sponsored/shepherded by another, are going to go
>through.  I presume there is a level of community consensus
>against such a proposal that would kill it but, given that much
>of the community won't spend time engaging with and commenting
>on procedural changes and that the IESG determination of rough
>consensus is inherently somewhat subjective, almost any proposal
>generated and handled that way is going to be accepted,
>published, and, unless it explicitly says otherwise, treated as
>a set of firm rules.

The above is about the breath of consensus.  If the IETF seeks to be 
an international body, should the breath of engagement reflect 
that?  The easy way is to choose the path of convenience and call it 
"rough consensus".

>(3) Procedural change proposals that do not originate with the
>IESG and that don't have immediate strong support from within
>the IESG have, statistically, a grim future ahead of them,
>especially if their effect would include either changing the
>IESG's responsibilities or increasing the ways in which the
>community can hold the IESG, or IESG members, accountable.

I noticed that.

>Especially with procedural proposals, rather than technical
>ones, the IESG has a rather wide range of options for killing
>something about which they are not enthused, starting with
>insisting on a BOF or two, forcing discussions off the IETF list
>and into one for which people who are not strongly committed to
>procedural issues won't sign up, claiming that the BOF does not
>show sufficient support (easily encouraged by scheduling a F2F
>BOF, appointing leadership who are skeptical about, or hostile
>to, the idea) or even concluding that there is insufficient
>support on the mailing list to justify holding a BOF, broadening
>scope sufficiently to make convergence in a WG before everyone

It is easy to terminate a proposal as per process rules.  That works 
well for anyone who is more than happy to do whatever the IESG wishes.

>runs out of energy, etc.   Because each of those decision points
>involves an IESG evaluation of consensus and whether the topic
>is worth more community time, separating entirely reasonable
>decisions from abusive behavior is generally going to be
>impossible.  With NEWTRK, we even saw the IESG receive documents
>on which the WG had consensus and refuse to initiate an IETF
>Last Call (and make it clear than an appeal would go nowhere).

There is not much which can be done if the IESG does not address an 
appeal adequately.

>I hope and trust that this draft is viewed with enough interest
>in the community and the IESG that it will be an exception to
>the above and, in particular, that SM will submit a proposal for
>either a virtual BOF or one in Montreal, that the BOF will
>confirm that it is appropriate to go ahead with this narrow
>piece of work, and that a WG, if needed at all, will be
>confirmed quickly and can progress rapidly and without F2F
>meetings.  But history does not lead to optimism.

:-)

Regards,
S. Moonesamy