[CWG-Stewardship] multistakeholder principle was Re: [] FW: FW: CWG ... 2B
Greg Shatan
gregshatanipc at gmail.com
Mon Nov 17 06:44:06 UTC 2014
Olivier and Chuck and All,
I think this is an important point, and one we should hold onto as we look
at the issues relating to the roles that various stakeholders play after
the transition.
Greg
On Sun, Nov 16, 2014 at 6:31 PM, Gomes, Chuck <cgomes at verisign.com> wrote:
> So we may not be that far apart Olivier.
>
> Chuck
>
>
> Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Olivier MJ Crepin-Leblond <ocl at gih.com>
> Date:11/16/2014 5:29 PM (GMT-05:00)
> To: "Gomes, Chuck" <cgomes at verisign.com>, Avri Doria <avri at acm.org>,
> cwg-stewardship at icann.org
> Cc:
> Subject: Re: [CWG-Stewardship] multistakeholder principle was Re: [] FW:
> FW: CWG ... 2B
>
> Dear Chuck,
>
> my point is that there should be a multi-stakeholder aspect to it, whether
> reporting to a multi-stakeholder committee or having the function performed
> by someone selected or reporting to a multi-stakeholder process. I would
> not recommend that the function of administrative and technical checks be
> performed by a multi-stakeholder process.
> Kind regards,
>
> Olivier
>
> On 16/11/2014 19:39, Gomes, Chuck wrote:
>
> Olivier,
>
>
>
> The administrative and technical checks now do not involve a
> multi-stakeholder process. Multi-stakeholder is by definition slower. How
> could changing to multi-stakeholder not slow it down?
>
>
>
> Chuck
>
>
>
> *From:* Olivier MJ Crepin-Leblond [mailto:ocl at gih.com <ocl at gih.com>]
> *Sent:* Sunday, November 16, 2014 12:11 PM
> *To:* Gomes, Chuck; Avri Doria; cwg-stewardship at icann.org
> *Subject:* Re: [CWG-Stewardship] multistakeholder principle was Re: []
> FW: FW: CWG ... 2B
>
>
>
> Dear Chuck,
>
> we are going to have to discuss this in Frankfurt since I'm afraid my
> opinion is that the administrative and technical check parts of the process
> cannot be accountable if they do not have a multi-stakeholder aspect to
> them. Would you please be so kind to expand on why you think this would
> cause delays in the performance of specific IANA functions and what
> functions were you thinking would be affected?
> Kindest regards,
>
> Olivier
> (own opinions)
>
> On 16/11/2014 16:13, Gomes, Chuck wrote:
>
> Avri,
>
>
>
> As I tried to say in another message, I understand and support the use of
> a multi-stakeholder approach for the policy development aspects of the
> process but fear that applying it to the administrative and technical
> checks part of the process will cause delays in the performance of specific
> IANA functions. Maybe what we need to explore is how the functions of the
> OPRC could be divided in a way that distinguishes those that are
> specifically related to administrative and technical checks versus broader
> more policy related functions and think of ways to involve the
> multistakeholder community in the latter.
>
>
>
> Note that these are just my personal thoughts; I have not vetted them
> within the RySG.
>
>
>
> Chuck
>
>
>
> *From:* cwg-stewardship-bounces at icann.org [
> mailto:cwg-stewardship-bounces at icann.org
> <cwg-stewardship-bounces at icann.org>] *On Behalf Of *Avri Doria
> *Sent:* Saturday, November 15, 2014 7:32 PM
> *To:* cwg-stewardship at icann.org
> *Subject:* Re: [CWG-Stewardship] multistakeholder principle was Re: []
> FW: FW: CWG ... 2B
>
>
>
> Hi,
>
> I assume you are referring to the RFP3 strawman. I read it and added some
> comments in the text, which I will sent the RFP3 list (unless I am confused
> again about the mapping of document numero-names to email lists) . I will
> send my comments to that list.
>
> I basically had difficulty with several aspects of it.
>
> - the unistakeholder approach
> - the lack of a credible separability mechanism for removing the function
> to another contractor if needed
> - the reliance on changes to the bylaws that could be undone
>
> but,
>
> - it probably does avoid the problem of mission creep and bureaucratic
> scope, as it would be able to leverage ICANN's capabilities in that area.
>
> As it is a solution and not a principle, it does not have the effect of
> presupposing the solution in the principle. It seems to be forming based
> on the principle that one stakeholder is more relevant than all other
> stakeholders and the determination that they should be the sole oversight
> is consistent with a unistakeholder modality. As such it does not answer
> my issue about the need for a multistakeheholder principle to guide our
> work, though it does demonstrate what kind of solution one can arrive out
> without that principle.
>
> thanks
>
> avri
>
>
> On 15-Nov-14 09:14, Gomes, Chuck wrote:
>
> Avri,
>
>
>
> I find your message below very helpful. I haven’t had time to fully grasp your concern regarding ‘oversight’ and what you say below clarifies it a lot. If I am understanding you correctly, I also don’t believe that day-to-day oversight is required.
>
>
>
> I will be curious to see your reaction to the modified Straw Man 1 proposal that Stephanie sent to the CWG list yesterday. In particular, I would like to know whether you think it meets your concerns regarding oversight.
>
>
>
> Chuck
>
>
>
> From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org <cwg-stewardship-bounces at icann.org>] On Behalf Of Avri Doria
>
> Sent: Saturday, November 15, 2014 8:43 AM
>
> Cc: cwg-stewardship at icann.org
>
> Subject: Re: [CWG-Stewardship] multistakeholder principle was Re: [] FW: FW: CWG ... 2B
>
>
>
> Hi,
>
>
>
> Thanks for pulling that all together. You display one of the best attributes of a list member.
>
>
>
> I had read those arguments on the list earlier, though in some cases a few days late, and my view was that we were in the midst of a discussion that had not yet resolved. As far as I could tell we were still early in the discussion and that the few who had weighed in were split on the issue. There is nothing in the quote you sent to show a consensus.
>
>
>
> Part of the problem we are getting into here, is that the principles of some seem to presuppose that there will be oversight of the day to day operation of IANA, and are thus proposing principles for oversight and not principles for the transition of Stewardship. From all of the exegesis of the NTIA contract and practice I have seen to date, NTIA never engaged in day to day oversight of naming or any other operations. I.e. in many of the arguments it is a predetermined solution, one I do not accept, that is presupposing a principle. I think, on the other hand that in the NTIA mssion the multistakeholder principle is inherent and must be carried through in the principles of a solution.
>
>
>
> To put it another way, I think many of the arguments here have the tail wagging the dog.
>
>
>
> Therefore I maintain that accepting that the multistakeholder principle is fundamental in our work is essential and cannot be removed by solutionism . As I said in another hand, if there is a concensus argument that on principle "one stakeholder should be more equal than all other stakeholders," then that should be set down as the principle. I do not believe I have seen that consensus.
>
>
>
> I do agree that there needs to be remedies/redress for SLA issue &c., and this is part of our brief. But solutions for these issues do not necessarily require day to day operational oversight in my opinion and we should not use one possible remedy as the explanation for a principle. I do agree that performance on SLA &c. would be material that was reviewed at the time of the renewal, but would argue that a multistakeholder group is fully capable of understanding and coming up with an appropriate decision on renwal taking those issue into consideration with all other relevant issues.
>
>
>
> Thanks
>
>
>
> avri
>
> On 15-Nov-14 03:42, Guru Acharya wrote:
>
>
>
> 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> <avri at acm.org><mailto:avri at acm.org> <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><mailto:avri at acm.org> <avri at acm.org> <avri at acm.org> <avri at acm.org><mailto: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><mailto:avri at acm.org> <avri at acm.org> <avri at acm.org> <avri at acm.org><mailto:avri at acm.org> <avri at acm.org> <avri at acm.org> <avri at acm.org><mailto:avri at acm.org> <avri at acm.org> <avri at acm.org> <avri at acm.org><mailto: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<mailto:listCWG-Stewardship at icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship> <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<mailto:listCWG-Stewardship at icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship> <listCWG-Stewardship at icann.orghttps://mm.icann.org/mailman/listinfo/cwg-stewardship>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
> CWG-Stewardship mailing list
>
>
>
> CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org> <CWG-Stewardship at icann.org>
>
>
>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> CWG-Stewardship mailing list
>
> CWG-Stewardship at icann.org
>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
>
>
> --
>
> Olivier MJ Crépin-Leblond, PhD
>
> http://www.gih.com/ocl.html
>
>
> --
> Olivier MJ Crépin-Leblond, PhDhttp://www.gih.com/ocl.html
>
>
> _______________________________________________
> 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/20141117/5ccedbe3/attachment-0001.html>
More information about the CWG-Stewardship
mailing list