20150119 - John Klensin

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.