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

On Mon, Oct 19, 2015 at 6:59 PM, Seth Johnson <seth.p.johnson@gmail.com> wrote:
<SNIP>

> I think the following was my earliest posting here on this general theme.
>
> What's great about the present moment is that the transition's nature
> is starting to become evident, even among folks who are very leery
> about talking about the law.
>
> I will see about finding some earlier proposals I presented.  I've
> been acutely aware that this isn't stuff that gets through until
> people see it coming to fruition.

Okay, this comment (and the whole thread if you go to the archives)
from back in November illustrates my attempts roughly starting then to
get this group to recognize and address the fact that the transition
will bring changes that need to be addressed (rather than the basic
"don't make waves" orientation here).  It should be interesting to
some of you to look at this and consider where we are now.

Seth

---------- Forwarded message ----------
From: Seth Johnson <seth.p.johnson@gmail.com>
Date: Sun, Nov 16, 2014 at 4:14 PM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: Milton L Mueller <mueller@syr.edu>, "rhill@hill-a.ch"
<rhill@hill-a.ch>, Alissa Cooper <alissa@cooperw.in>,
"ianaplan@ietf.org" <ianaplan@ietf.org>, Eliot Lear <lear@cisco.com>

No, the implications of the transition go well beyond the functional
perception of the process.

Our job is to conduct the transition in a controlled and responsible
manner, to articulate how that needs to be done.  Those who conduct
the process are stakeholders who are also process owners, and that
gives you a certain tunnel vision.  If the functions you're executing
are the same, then supposedly "obviously" the result will be the same.

Our job is to say, Yes, there is a transition.  How do we understand
its significance and implications and what can we do to transition the
process without screwing it up?

The notion that just saying it's all good is going to characterize the
process and the change we're undergoing sufficiently is the very
hallmark of a transition that fails because process owners did not
think it necessary to analyze the process sufficiently and went on how
they've done things and what they know (tacitly and explicitly),
because that's what they do every day.  It also allows the process to
change fundamentally as a result of unacknowledged factors, both in
tacit understandings and in the change of context surrounding the
process.  This is exactly *not* what we are supposed to do.  If we
don't rise to the task, we are simply handing off the process,
apparently just because it's always worked that way.  The protocol
registries are a product that has many stakeholders, and we are
responsible for understanding what the transition is going to do -- to
the protocol registries, what they mean, how they're used -- to the
role of government, which we have been able to expect not to meddle in
our communications -- to the process and how we conduct it -- and to
all of us who depend on the registries and the way we use them.

Seth

On Sun, Nov 16, 2014 at 2:04 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:
>
>
> On 11/16/14, 4:30 AM, "Milton L Mueller" <mueller@syr.edu> wrote:
> <snip>
>>
>>I do not understand why the other side of this debate is not willing to
>>make a few minor compromises required to gain true consensus for this
>>document. It raises major issues regarding the viability of any claim
>>that this document has even rough consensus.
>
> "True consensus" surely means something different than IETF consensus. But
> if you ask the IETF a question, IETF consensus determines how it is
> answered. Our consensus process is integral to who we are - arguably, it
> is all that we are. It up to the chairs of this group to assess consensus
> on this document, and there's little purpose in asserting on the list that
> consensus has or has not been achieved.
>
>>That will raise problems for the proposal both at the ICG stage and at
>>the broader public comment stage.
>
> I fear I must preface my remarks here with another declaration that I do,
> really, believe you personally are trying to help here Milton. And I think
> it is entirely appropriate for ICG members to be on this list and to
> participate in this discussion - even to clarify what they believe the ICG
> is asking for. But there is a line here. There is a fine line between an
> ICG member telling the IETF its proposed response "will raise problems...
> at the ICG stage" and an ICG member effectively threatening to raise
> problems if the IETF response doesn't conform with personal preferences.
>
> Now please, again, nobody freak out, we're all cool here, I'm not saying
> that line has yet been crossed. But if that line is crossed by anyone on
> the ICG, I would propose that we add an appendix to our ICG response
> pointing to any relevant statements and explaining that this input
> hampered our ability to answer these questions.
>
> This isn't an ethics matter or a conflict of interest matter even - it
> just defeats the purpose of process. The ICG, perhaps ill-advisedly, asked
> the IETF for its response to this questionnaire. The response that the ICG
> gets should be the IETF's response - not the response of some different
> legally-savvy techno-political body, not a response based on something
> other than our consensus process, but the IETF's response with all the
> constraints and limitations that implies. If instead the ICG would rather
> see a document reflecting what the ICG thinks the IETF should put into
> such a response, surely the ICG could produce that document on its own and
> save us some work.
>
> Please, just let us resolve this - to us, relatively trivial technical
> matter - to our own satisfaction.
>
>
> Jon Peterson
> Neustar, Inc.
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan