Re: [Ianaplan] What's happening at ICANN?

[Eliot Lear <[e-mail]>]

Hi,

On 10/19/15 3:51 PM, John C Klensin wrote:
> Yes, but there is another difference between IETF appeals and
> most of what has been contemplated for ICANN.  The IETF process
> is designed to force what other bodies call "reconsideration".
> The IESG is told to take another look and the IAB's maximum
> authority in most scenarios is to tell the IESG to look again
> and consider a specific set of issues.  The ISOC Trustees have
> more power to actually make changes and final decisions (at
> least the way some of us read the spec) but we have no actual
> experience with the use of that part of the model to conclusion
> in the 19 years since the ISOC BoT provision was introduced in
> RFC 2026.

Indeed.

The IETF moved to the current model thanks to a sequence of events that
irked the community.  The first, and seemingly small, involved a
situation in which the ETHERNET-MIB working group sent something through
for publication, and between it and the RFC-Editor, a counter width had
been changed without discussion.  At the Atlanta meeting in 1991, the
chair of the ETHERNET-MIB working group exploded that the WG's output
had been edited without their consent (and, I believe, knowledge).  A
grey bearded guy with a squirelly pony tail started screaming a
profanity in the back of the room.  Yes, that was a few people's
introduction to Jon Postel, including my own.  Anyway, that stuck in
some people's craws.

But the one that really caused change was the IAB's decision, on their
own, to choose a next generation IP.  This I affectionately call the
Kobe Kabal.  Their decision was so unpopular that what followed was a
very well known apology from Vint at Danvers, which I like to think of
as the Boston Tea Party.  Not too long after that, RFC 2026 was
introduced to specifically enjoin the IAB from making actual changes to
standards.

This is the essence of oversight.  To see, observe, and review as
requested.  To indicate agreement or disagreement with a party when
called upon to do so, but NOT to do the work of fixing what is broken in
a specification.

As John writes, other analogies break down for various reasons, but this
oversight model is actually the IETF's strength and worth reiterating
(again and again).

Eliot