--On Monday, January 19, 2015 17:31 +0100 Seun Ojedeji
<seun.ojedeji@gmail.com> wrote:

>...
> So while it is fair to say that the issues require more work,
>> 
> On a lighter note, it's interesting that to note that IETF who
> will mostly be affected by those issues raised had to wait to
> be prompted by other communities.

Actually, that is exactly where the issue lies.  At the risk of
oversimplifying both positions (and temporarily putting the
process issues aside), I heard both:

-- arguments that these were very significant issues for the
IETF and that the IETF would be most affected by them.

-- arguments that these issues were actually of little
importance to the IETF and that, while moving the domain name
and/or trademark away from ICANN and to a presumably-neutral
party would be fine with the IETF, it was not of any great
importance.

Since Richard's note and some other comments repeat (or
summarize) the first argument, let me briefly summarize the two
most important elements of the second set:

(1) In part because the number of separate, and
separately-referenced, registries in the Protocol Parameter area
vastly exceeds the number in either the Numbers or names area,
the IETF would have a considerable conversion problem if either
the IANA function were broken into multiple pieces or if it was
somehow transferred away from ICANN under circumstances that
resulted in an ICANN decision to not be active in, and positive
about, facilitating that transition.  The requirements of that
conversion would be such that whether or not the names were
available (and hence whether the IETF needed to invent
completely new names) would be trivial as compared to everything
else that would need to be done.

(2) Because of the jurisdictional issues involved, open
questions about ICANN's long-term locale and accountability
issues, etc., some of us are very skeptical about whether what
Richard characterizes as a "legally binding agreement" is
meaningful or operationally relevant.  If there is general
agreement about what should be done and a spirit of cooperation,
then "legally binding" is unnecessary.  If there is not and one
has to somehow enforce such an agreement because one party is
perceived as having become non-responsive or uncooperative by
the other(s), then the one thing that is nearly certain is it
would take a relatively long time to get to a final conclusion.
At least for planning purposes, the IETF would need to assume
that would be long enough that it would be necessary to put an
independent transition plan into effect -- a transition plan
that would raise the issues in (1) above -- in order to preserve
the stability, accessibility, and utility of the protocol
parameter registries.

Returning to the process question, it seems to me that Richard
(and some others) simply failed to convince the WG that the
first position was of critical importance or that the arguments
for it dominated those for the second.     The other important
element of his argument seems to be that members of the "IETF
Leadership" had opinions and expressed them.  For better or
worse, an important component of the IETF's leadership selection
regime is expertise and opinions -- we aren't supposed to be
appointing professional process arbiters who don't have, or are
expected to suspend, their experience and professional judgment.
When we end up with leaders whose concerns are more about
process than about substance --including their own judgments--
we usually end up regretting it.   If he feels that there was
abuse in the consensus-determining process, that is precisely
why we have an appeals (really an extended internal review)
process of which he has failed to take advantage.  Instead, he
has claimed that he could not make such an appeal -- that is not
the case as others have pointed out.

If "I didn't like the outcome" is grounds for claiming to the
ICG that a process concern exists, then consensus as the IETF
understands it would basically be impossible.

    john