[CWG-Stewardship] Draft of Principles
Olivier MJ Crepin-Leblond
ocl at gih.com
Thu Nov 13 16:54:51 UTC 2014
Dear Stacy,
thanks for this. I am not a lawyer, but wouldn't "redress" also involve
"compensation or satisfaction for a wrong or injury"?
Could the use of the word "redress" open the door to financial
compensation in case of a fault by the IANA operator?
May I suggest "remedy", or is this a legally charged word too?
Kind regards,
Olivier
On 11/11/2014 23:33, King(Legal), Stacey wrote:
>
> All
>
>
>
> I would like to add an addition to Stephanie’s changes to the
> Principles document. In connection with the section on appeal, I
> would change it as follows (in red):
>
>
>
> i. _Appeals and Redress_: In cases of any
> significant or irreversible decision (redelegations, for example),
> there should be an appeals process that includes [binding] redress
> open to the affected parties and this should be open to public scrutiny.
>
> I think it is important to clarify that the appeals process does not
> simply lead to a recommendation or report that is then taken into
> account, yet is not binding. Appeals should have real relief if they
> are to be successful. While it may seem obvious that an appear leads
> to redress, not everyone may see this the same way.
>
>
>
> Indeed, the definition of redress is to set right what is wrong or
> relief from wrong, whereas the definition of appeal is a request or
> reference to some person or authority for a decision; a petition. As
> a result, “appeal” alone has the possibility of being misinterpreted
> or more malleable. And as several current accountability mechanisms
> within ICANN do not have redress attached to them (rather, they are
> purely recommendations (Reconsideration) or reports on fairness for
> consideration (Ombudsman)), I think we should be clear that this
> appeals process is meant to include the redress.
>
>
>
> Stacey
>
> *From:*cwg-stewardship-bounces at icann.org
> [mailto:cwg-stewardship-bounces at icann.org] *On Behalf Of *Duchesneau,
> Stephanie
> *Sent:* Thursday, November 06, 2014 2:28 PM
> *To:* cwg-stewardship at icann.org
> *Subject:* Re: [CWG-Stewardship] Draft of Principles
>
>
>
> Hi All,
>
>
>
> Please find attached some suggested changes and edits to the
> Principles document.
>
>
>
> With the minor changes proposed am generally supportive of the draft.
>
>
>
> Welcome and encourage anyone to provide any feedback on the attached.
>
>
> Stephanie
>
> *Stephanie Duchesneau**
> **Neustar, Inc. / *Public Policy Manager
> 1775 Pennsylvania Avenue NW, 4^th Floor, Washington, DC 20006
> *Office:***+1.202.533.2623 *Mobile: *+1.703.731.2040 *Fax:
> *+1.202.533.2623*/*www.neustar.biz <http://www.neustar.biz/>
>
> ------------------------------------------------------------------------
>
> The information contained in this email message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient
> you have received this email message in error and any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately and delete the original message.
>
>
>
> *From:*cwg-stewardship-bounces at icann.org
> <mailto:cwg-stewardship-bounces at icann.org>
> [mailto:cwg-stewardship-bounces at icann.org] *On Behalf Of *Brenden Kuerbis
> *Sent:* Thursday, November 06, 2014 2:31 PM
> *To:* Gomes, Chuck
> *Cc:* cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>
> *Subject:* Re: [CWG-Stewardship] Draft of Principles
>
>
>
> I agree we need to simplify and generalize these draft principles.
> Hopefully this will allow us to quickly move on to actual proposal
> development. Following the discussions here, it seems the following
> would suffice as a guide to creating a proposal that ensures
> accountability:
>
>
>
> <principles>
>
>
>
> Independence - any proposal must ensure that the IANA functions
> operator be independent of TLD policy processes. Its role is to
> implement changes in accordance with TLD policy agreed through the
> relevant policy process;
>
>
>
> Separability - any proposal must ensure the ability to 1) separate the
> IANA functions from the current operator if warranted, and 2) to
> convene a process for selecting a new operator. Separability should
> persist through any future transfers of the IANA function(s); [Note:
> The NTIA's current contract already requires such separation]
>
>
>
> Transparency - any proposal must ensure that delegation or
> redelegation decisions implemented by the IANA functions operator and
> the rational for those decisions should be made public or at least be
> subject to an independent scrutiny as part of an ex-post assessment of
> service performance.
>
>
>
> <end principles>
>
>
>
>
>
> For me, these are the basics that are needed. While SLAs certainly
> need to be defined and referred to (e.g., what conditions warrant that
> the IANA function be separated from the operator?), I'm not certain we
> need them in principles. And while I understand the appeal of
> appeals, I think what we really want is some guarantee that the IANA
> functions operator follows exactly what is determined by policy (and
> that that process is fully accountable, has appeals, etc. - but this
> is another battle).
>
>
>
>
>
> Happy to see these revised, etc. I include the current
> draft principles language below for comparison.
>
>
>
>
>
> ---------------------------------------
>
> Dr Brenden Kuerbis
> iSchool, Syracuse University || http://internetgovernance.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__internetgovernance.org_&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=QWy6rpomIn-w1jZ6XJx72VHiN5SldQik_DE8EOTvhN4&e=>
>
> Internet Governance Project
> http://internetgovernance.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__internetgovernance.org_&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=QWy6rpomIn-w1jZ6XJx72VHiN5SldQik_DE8EOTvhN4&e=>
>
>
>
>
>
>
>
> On Thu, Nov 6, 2014 at 8:07 AM, Gomes, Chuck <cgomes at verisign.com
> <mailto:cgomes at verisign.com>> wrote:
>
> Mwendwa,
>
>
>
> Regarding your first question, let me first say that I don’t see
> ‘bottom-up’ as a cliché. Secondly, it is a fundamental principle of
> policy development. I think it is important to note that the
> principle is not saying that IANA functions are operated in a
> bottom-up way but rather that the IANA functions operator’s role is to
> implement changes according to such policies. As I see it, the
> essence of this principle is not that policy development must be
> bottom-up but rather that “the IANA functions operator should be
> independent of the policy processes”. That said, is the term
> ‘bottom-up’ essential to the principle? No. And I think that is
> probably your point. I personally don’t have any problem leaving
> ‘bottom-up’ in the statement but I don’t think removing it if the
> group wants to do that would detract from the principle.
>
>
>
> If we want to keep the principle short and to the point, we could
> delete the second sentence.
>
>
>
> Chuck
>
>
>
> *From:*cwg-stewardship-bounces at icann.org
> <mailto:cwg-stewardship-bounces at icann.org>
> [mailto:cwg-stewardship-bounces at icann.org
> <mailto:cwg-stewardship-bounces at icann.org>] *On Behalf Of *Mwendwa Kivuva
> *Sent:* Thursday, November 06, 2014 5:59 AM
> *To:* Milton L Mueller
> *Cc:* cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>
>
>
> *Subject:* Re: [CWG-Stewardship] Draft of Principles
>
>
>
> _Independence of policy from IANA_: the IANA funtions operator
> should be independent of the policy processes. Its role is to
> implement changes in accordance with policy agreed through the
> relevant bottom uppolicy process [Note: this does not pre-suppose
> any model for separation of the policy and IANA roles. The
> current contract already requires such separation];
>
>
>
> Is bottom up a cliche we want to see in our principles?
>
>
>
> _Diversity of IANA’s Customers:_
> _For ccTLDs,_the IANA should provide a service without requiring a
> contract and should respect the diversity of agreements and
> arrangements in place for ccTLDs. In particular, the national
> policy authority or legislation (related to the ccTLD operator)
> should be respected and no additional requirements should be
> imposed unless it is directly and demonstrably linked to global
> security, stability and resilience of the DNS.
>
>
>
> "unless it is directly and demonstrably linked to global security,
> stability and resilience of the DNS"
>
> Is there any example of a policy that can be implemented at the ccTLD
> level that can threaten the DNS?
>
>
> ______________________
> Mwendwa Kivuva, Nairobi, Kenya
> L: https://www.linkedin.com/in/lordmwesh
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_lordmwesh&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=HDj14R927Q50oycMrRsyHI8IMj7leOmgQjkPChXs6JQ&e=>
> B: http://lord.me.ke/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lord.me.ke_&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=Vw5vRaCppU9LKA32wTG4sVhcFiJXqgHNzoZSZaCfL3w&e=>
> T: twitter.com/lordmwesh
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_lordmwesh&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=PniNABc9fXTC8mYwkcXXeI_27giy_tU2zsehRMpC35Q&e=>
>
> "There are some men who lift the age they inhabit, till all men walk
> on higher ground in that lifetime." - Maxwell Anderson
>
>
>
> On 5 November 2014 20:40, Milton L Mueller <mueller at syr.edu
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailto-3Amueller-40syr.edu&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=IZEFP9au0uvtYZxGhQy09-CTCOL1RazCDNY37ytSqx4&e=>>
> wrote:
>
> I agree 100% with Avri. Separability has to be a principle, otherwise
> we have failed the accountability test.
>
>
>
> *From:*cwg-stewardship-bounces at icann.org
> <mailto:cwg-stewardship-bounces at icann.org>
> [mailto:cwg-stewardship-bounces at icann.org
> <mailto:cwg-stewardship-bounces at icann.org>] *On Behalf Of *Avri Doria
> *Sent:* Tuesday, November 4, 2014 9:16 PM
> *To:* cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>
> *Subject:* Re: [CWG-Stewardship] Draft of Principles
>
>
>
> Hi,
>
> While actual separation and the means of implementing that separation
> may be solutions, I am strongly of the opinion that the potential to
> separate MUST be a principle any solution is built on. It may never
> be exercised, but it would be unacceptable for there to be a solution
> that prohibited or did not otherwise allow any possible future
> separation of the function from ICANN.
>
> This is one of several principles I feel I must personally argue for
> persistently, and without which any solution would be unsatisfactory.
>
> avri
>
> On 05-Nov-14 10:45, Guru Acharya wrote:
>
> Avri,
>
>
>
> While I agree that separability should be a part of the solution, I don't
>
> think it can be made a principle.
>
>
>
> There are many who want IANA to perpetually reside in ICANN. They believe
>
> that self regulation will ensure accountability and that the need for
>
> separability does not exist.
>
>
>
> Therefore, separability may be a component of your solution rather than a
>
> principle for all solutions.
>
>
>
> Regards,
>
> Guru
>
> On 5 Nov 2014 04:00, "Avri Doria" <avri at acm.org> <mailto:avri at acm.org> wrote:
>
>
>
> Hi,
>
>
>
> Comments:
>
>
>
> a. *Oversight, accountability and transparency*: the service
>
> should be accountable and transparent.
>
>
>
>
>
> I see no reason to include the term 'oversight' here.
>
>
>
> i. *Independence of oversight*: Oversight
>
> should be independent of the IANA functions operator and should assure the
>
> accountability of the operator to the (inclusive) global multi-stakeholder
>
> community;
>
>
>
>
>
> I recommend removing this as a principle for the following reasons:
>
>
>
> a. I do not think oversight is a principle, but one possible solution to
>
> the accountability issue.
>
> b. if 'oversight' is a component of the solution, I do not understand how
>
> it is independent of the stakeholders to whom ICANN is also accountable, so
>
> the notion of 'Independence' is not a principle I understand in this case.
>
> Yes any possible oversight mechanism should be independent of ICANN
>
> corporate, but I do believe it is accountable to the same stakeholders as
>
> is ICANN.
>
>
>
> I think we need a specific principle on accountability in this section:
>
>
>
> Accountability: Post transition accountability on the IANA Stewardship
>
> function should be to the Internet stakeholder community.
>
>
>
> I also think we need to add a principle called separability
>
>
>
> Separability: In the event that the ICANN corporation, or any of its
>
> subsidies, remains responsible for the IANA functions after the transition
>
> of stewardship, it should remain possible for a well formed review and
>
> contracting granting authority to reassign the IANA function to a new IANA
>
> service provider(s). The power of removing the function to a different
>
> operator should persist through any future transfers of the the IANA
>
> function(s)
>
>
>
> Under (c.) I recommend that we include the principle that service levels
>
> be subject to independent audit, with results published for review by the
>
> Internet community on an annual basis.
>
>
>
> thanks
>
>
>
> avri
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> CWG-Stewardship mailing list
>
> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=_t1loRyp0JFgmJklPxr5Y2soQjiO6P7ZA2WFZlntzDw&e=>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AAMFaQ&c=MOptNlVtIETeDALC_lULrw&r=0hsxJJjdrXRgjayVdcz_CARI78PKqWTRtnf4a8uMAWU&m=B7RwDybeRMZmicR13aU-nAKxr2hBae0fp1XFV_zq_k8&s=_t1loRyp0JFgmJklPxr5Y2soQjiO6P7ZA2WFZlntzDw&e=>
>
>
>
>
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141113/184b53b0/attachment-0001.html>
More information about the CWG-Stewardship
mailing list