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

[John C Klensin <[e-mail]>]

Hi.

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.

--On Friday, May 24, 2019 09:49 +0000 Spencer Dawkins at IETF
<[e-mail]> wrote:

> 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
> <[e-mail]> 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.

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.

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.

Like more good stories starting with "once upon a time", some
aspects of that era are at least a bit mythical.  But I think
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 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 ...

Right.  Perhaps more useful than a proposal for one on the
subject of recalls; see below.

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

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

(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.
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
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).

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.

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

At the same time, if the topic of the work is controversial,
this lends itself to abuse... especially so if there is a
personal or business relationship between the WG Chair/author
and the relevant AD.  Even if some other AD, perhaps from some
other area, takes over formal responsibility for the document,
if the document is controversial there is going to be at least a
faint whiff of suspicion about improper relationships.  

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

Yep.

best,
   john