[CWG-Stewardship] multistakeholder principle was Re: [] FW: FW: CWG ... 2B
Guru Acharya
gurcharya at gmail.com
Sat Nov 15 08:42:28 UTC 2014
Avri,
I reproduce some previous conversations on this list below that may help
have an informed discussion.
I request you to address the points raised by Becky and MM.
-
*Becky*: Seems to me that the core of this group would be registry
operators, perhaps with representation from other stakeholders like
registstrars, registrants, etc.
-
*Greg*: Oversight of the IANA functions for the naming community should
not be left solely (or even primarily) to its direct "customers." An
essential part of the multistakeholder construct is that all Internet
stakeholders (aka "the Global Multistakeholder Community") are affected,
directly or indirectly, by these matters. This CWG is roughly
representative of those stakeholders. Any group or entity designated or
created to hold steward/oversight responsibility should be similarly
representative.
-
*MM*: I disagree at the most fundamental level. This position is based
on a fallacy. The fallacy is to confuse the accountability and input of
ICANN’s policy making process with the accountability of and input into the
IANA functions. All stakeholders should have a voice in and fair
representation in the process of policy development. But once a policy is
agreed, the implementation of policies by the IANA is a derivative
technical and operational function in which its direct customers are the
primary stakeholders. Broad public oversight would be meaningless at best
(because random members of the public would not know what is going on at
that level) and dangerous at worst (because there would be temptations to
circumvent agreed policies by politically intervening at the implementation
level). I suspect that people who argue for broad representation of IANA
contracting function are people who want there to be a capability for some
kind of political circumvention of the policy process at the IANA level. In
other words, they think policy should be made by IANA rather than by ICANN.
That’s wrong, fundamentally wrong, and that is why IGP – and many others –
have argued as a principle that policy and IANA implementation need to be
clearly separated. If you want to change policy, do it in the policy
process. If you want to monitor technical implementation of a policy by a
registry, the operators of a registry are in the best position to do that.
Yes, there should be some public interest representation in a contracting
authority (IGP proposed that, too) but mainly for transparency purposes and
for keeping them honest. IANA should be primarily accountable to the people
who actually use its services and whose basic functions and activities are
dependent on those services. Whether or not one thinks they used it, the US
government’s authority over modifications to the root zone created the
potential for that kind of political intervention at the implementation
level. This set a very bad precedent for the world that we are still
dealing with. Now some people are trying to reproduce that situation by
making IANA oversight a way for interest groups who don’t get what they
want in a policy process to get a second, back door bite at the apple.
Let’s reject that clearly. If one knows what the performance of the IANA
functions actually are, the idea that every stakeholder in the world should
be engaged in “oversight” of its performance is pretty ridiculous. You
might as well say there should be public, multistakeholder oversight over
what secretaries a registry hires, what cars they rent, what buildings they
live in. After all if their cars break down you as a customer might be
affected, right? If their building power goes out, you might be affected,
right? If the ccTLD for .za submits a request for a change in its root zone
file data neither you, Greg – nor I – are in a position to say whether the
request should happen or whether it has been implemented correctly. You may
argue that internet users under .za will be affected if the IANA
implementation of a root zone change for .za is performed badly, but the
answer is that the .za registry would be affected immediately and far more
damagingly than any individual customer would be, and in terms of both
incentives and knowledge, is in a much better position to prevent that from
happening than any other stakeholder. So if you really care about the
security, accuracy and accountability of registry changes, we will be
relying on the primary users, no matter what kind of a structure we set up.
-
Becky: Thanks Elise, very helpful. I was thinking that the “oversight
counsel” would focus on technical and operational issues as opposed to
policy issues: Things like SLAs, how quickly name server changes are
processed, etc. Where a government actually operates the ccTLD, it would be
direct consumers of IANA services, like gTLDs and ccTLDs. But policy for
IANA would remain in existing ICANN processes. Could you help me
understand which technical/operational IANA services might raise “public
interest” concerns? I agree with you that having some GAC reps on a
Oversight Counsel would not be inconsistent with the Strickling view, but I
am curious about why GAC might want to participate in that kind of counsel.
-
MM: Totally agree with Becky. I think any IANA transition solution that
gives governments a special, privileged role is not meeting the NTIA
criteria and could not be implemented. Most governmental concerns arise in
the policy development process. As I’ve said before, IANA does not and
should not be involved in making policy, nor should it be viewed as a way
to veto or circumvent agreed policy. Therefore govts – and we - must not
confuse IANA issues with the accountability of ICANN’s policy making
process. For that reason I really like Stacey King’s statement: if GAC is
represents on an oversight council “that the ICANN Bylaws provision
allowing for GAC advice on any policy matter does not apply to IANA. Ie,
that the GAC cannot exercise any additional authority over IANA functions
through other means/routes.”
-
Guru: Becky. I agree with your initial assessment that the "oversight
council" would focus on "technical and operational issues" (as opposed to
policy issues); and therefore GAC participation in the council will not be
required even though GAC participation at an equal footing will not be
inconsistent with the multi-stakeholder model. However, I think GAC
participation in the council might be essential in the scenario where the
oversight council decides to change the IANA operator in the future. If the
council decides to contract a different operator (different from ICANN) in
the future, would it not lead to various policy issues such as jurisdiction
of the new IANA operator, financing of the new IANA operator etc - where
the insight of the GAC may be beneficial? Therefore I think GAC should be a
part of the oversight council.
-
Allan: There is a potential problem with having just registries doing
the oversight. Particularly for gTLD,s policy is set by a MS group (the
GNSO) and it is possible that they can set a policy that the gTLD
registries do not approve of (they do not have a veto based on GNSO voting
threshholds). If IANA were to not be implementing that policy properly, the
oversight body, composed of only registries would have no incentive to call
IANA out on the problem
-
Becky: IANA is a service provider. If you hire a contractor to build a
house, it is the contractor’s job to make sure that the plumber and the
electrician do their work properly. If your house burns down because the
wiring is faulty, you are going to look to the contractor – not the
electrician – to make you whole. I fully support multi-stakeholder policy
development. Multi-stakeholder oversight of the electrician doesn’t make
sense to me.
-
Oliver: irrespective of whether an "Oversight Council" is a desirable
thing or not (I have not yet made up my mind about this, only having very
basic information about it), I see a serious conflict of Interest where
only the directly affected parties oversee operations that concern them
directly. There was much discussion about the GAC having seats. Although I
have not asked them, I am pretty much sure that end users, as affected
parties, would need a number of seats too
-
MM: I can’t agree with Olivier and Fouad. Olivier, help me to understand
why the directly affected parties shouldn’t have the primary responsibility
for operations they are the direct users of and that their own operations
depend on. To me your claim that this constitutes a “conflict of interest”
is almost self-contradictory and self-refuting – it is a confluence of
interest, not a conflict – but perhaps I am missing something. Please
explain. What I suspect is happening is that both of you are confusing
policy development functions of ICANN with the operational and technical
functions of IANA, and applying inappropriate mental models drawn from the
former to the latter. In policy development we want “openness, diversity,
inclusiveness and the user perspective.” In the DNS IANA functions the
users are the registries, it’s an intermediate good, it’s all about
implementation, so we want efficiency, security and direct accountability
to the primary users, not some playground for different stakeholders to
voice their opinions. I do agree with Alan there should be safeguards to
prevent the operational and technical functions from being managed in ways
that undermine or subvert policy that is made in the MS process. It would
be useful to discuss institutional safeguards – including antitrust law –
to prevent those kinds of things. But throwing an infinite number of
“stakeholders” into looking over the shoulders of those making root zone
file modifications accomplishes nothing useful from a public interest
perspective, while raising all kinds of risks and inefficiencies. If Alan
can recognize the danger that IANA contractors or implementations might
compromise the policy process, I hope that he can also recognize the danger
that politicized ‘multstakeholdered’ oversight of the technical operations
could be abused to circumvent or veto the policies developed by the MS
process.
On Sat, Nov 15, 2014 at 1:41 PM, Avri Doria <avri at acm.org> wrote:
> Hi,
>
> I think we need to start from principles, as opposed to having a solution
> and making sure the principles fit the desired solution.
>
> And if we are stating that we think 'one Stakeholder Group is more
> relevant than all other stakeholder types' and by virtue of that have
> primacy in decision making, then that should be stated explicitly in the
> principles section. If it is already then I missed it.
>
> I prefer the equal-footing multistakeholder principle, but if there is
> near consensus for the one stakeholder above all stakeholders viewpoint, I
> would like to understand.
>
> Thanks
>
> avri
>
> On 15-Nov-14 01:33, Guru Acharya wrote:
>
> Avri
>
> I'm sure your viewpoints are not being ignored. Peace. I forgive you for
> your sin.
>
> Nobody is saying multi stakeholder compositions are not applicable or there
> is consensus against it. Please look at strawmans 2 and 3.
>
> I intact support a multi-stakeholder composition.
>
> I'm just saying I don't agree there is consensus against a registry only
> composition, which you seem to be eliminating by way of the principle that
> you are suggesting.
> On 15 Nov 2014 11:51, "Avri Doria" <avri at acm.org> <avri at acm.org> wrote:
>
>
> Hi,
>
> Apologies, guess I picked the wrong email. I hope I can be forgiven for
> this sin.
>
> I guess that means that my viewpoints will just be ignored.
>
> But if this group is able to decide that multistakeholder models are not
> applicable, no matter which thread an email is attached to. I think we may
> be in more trouble than I think we are. Are you saying we have consensus
> on a principle against commitment to the multistakeholder model? How can
> that be when the multistakeholder model is really one of the first
> principles we much meet for an NTIA solution
>
> avri
>
> On 14-Nov-14 22:48, Guru Acharya wrote:
>
> Avri - You got the wrong thread. This thread is for RFP2B and not the
> principles.
>
> And your suggested principle for a multi-stakeholder composition of the
> oversight council appears to be in contradiction to Strawman 1 and ignores
> the range of discussions that happened on this list about the composition.
>
> On Sat, Nov 15, 2014 at 6:13 AM, Avri Doria <avri at acm.org> <avri at acm.org> <avri at acm.org> <avri at acm.org> wrote:
>
>
> Hi,
>
> I have suggested a few edits to the doc. hope I did it in the mandated
> manner.
>
> the changes refer to
>
> - transparency and requirements that any and all audit reports be
> published.
> - bottom-up modalities
> - multistakeholder nature of any committee or oversight arrangements.
>
> Hope I did not mess up any of the formatting.
>
> avri
>
>
> _______________________________________________
> CWG-Stewardship mailing listCWG-Stewardship at icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
> _______________________________________________
> CWG-Stewardship mailing listCWG-Stewardship at icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141115/5c552c2c/attachment-0001.html>
More information about the CWG-Stewardship
mailing list