[CWG-Stewardship] Draft of Principles
Duchesneau, Stephanie
Stephanie.Duchesneau at neustar.us
Thu Nov 6 22:28:26 UTC 2014
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, 4th 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] On Behalf Of Brenden Kuerbis
Sent: Thursday, November 06, 2014 2:31 PM
To: Gomes, Chuck
Cc: 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 up policy 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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141106/2f7d8403/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CWG-PrinciplesandCriteriaV1 0_SD.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 46930 bytes
Desc: CWG-PrinciplesandCriteriaV1 0_SD.docx
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141106/2f7d8403/CWG-PrinciplesandCriteriaV10_SD-0001.docx>
More information about the CWG-Stewardship
mailing list