[ccwg-internet-governance] Fwd: Draft Internet Governance Brazil Meeting ccWG Submission Consolidated (leonfelipe at sanchez.mx)
marilynscade at hotmail.com
Fri Feb 28 21:37:38 UTC 2014
I agree w Aparna's view re no need to reference new gtlds in any detail.
Sent from my iPhone
Let's add a non Icann MS example/ IGF is good. Ivan draft description and maybe one that govt s will recognize easily.
> On Feb 28, 2014, at 21:12, "Aparna Sridhar" <aparnasridhar at google.com> wrote:
> Apologies for missing the call last week. I have had a chance to review the Google document and had the following suggestion for section 3 (Declarations).
> I propose to reorder the sections and make each header affirmative. My proposal is to structure the sections as follows:
> (1) A multistakeholder model best services the Internet community.
> This section would include the text currently appearing under the header "Why is a multi-stakeholder governance model better for the Internet than a multi-lateral model?"
> It would then give two examples:
> How the MSM works within ICANN. The discussion of how the MSM works within ICANN could incorporate a discussion of the GAC and the function of GAC advice (currently a separate heading under 3.2).
> How the multistakeholder model works within the RIRs. Much of this text currently appears in a discussion under the header Critical Internet Resources. I also suggest that the RIR text can be streamlined with an eye to focusing on how the multistakeholder model works within the registries.
> (2) The Cross-Community Working Group Supports an Internet with a Single Root.
> This section would contain the text currently under "why is a single root needed?"
> (3) The Cross-Community Working Group Supports One Internet
> This section would contain the text currently under "Why is a Single Internet Needed?"
> (4) The Cross-Community Working Group Supports Best Practices that Enhance Internet Security.
> This section would contain the text currently under "What is DNSSEC?" I suggest that it is not necessary to go into detailed discussion of Trusted community representatives in this document, which is already quite long.
> Unless members feel strongly, I do not think it is necessary to discuss top level domains or category 1 and category 2 GAC advice. Currently there are three headers along those lines: (1) "Why did ICANN open up the NameSpace for New Top Level Domains?" (2) "Why did it take so long for new Top Level Domains to be create?" (3) "What is 'Category 1 and Category 2 Names' in GAC Advice?" The answers to these questions are not really either declarations or principles. They may be examples that help elucidate some of the broader principles, but to me, they do not stand alone as arguments to be made in a submission.
> I hope you will consider these suggestions as a way to make the document more focused and forceful. I will also include a reference to this e-mail as a comment in the document itself so that you can easily refer to it in connection with the draft.
> Aparna Sridhar
> Google Inc.
> 1101 New York Avenue N.W.
> Second Floor
> Washington, DC 20005
> tel: 202.346.1261
> e-mail: aparnasridhar at google.com
>> On Fri, Feb 28, 2014 at 6:49 AM, Marilyn Cade <marilynscade at hotmail.com> wrote:
>> My apologies for having to drop off half way through. I can read the transcript as soon as it s posted. During the time I was on, I heard some suggestions that to me would from the basis of topics that are relevant to identify, but that I fear that CCWG is able to make a fulsome assessment or discussion, both because of time limitations, and because some of these topics have widely ranging views within the ICANN communities. But I do think they form part of the topics that really have to be discussed, and reconciled within ICANN.
>> It is not a surprise that my view is that ICANN is a bottom up, consultative, consensus based organization, as I have stated that many times. And, I appreciate that colleagues on CCWG have made similar statements.
>> Nareesh offered two very interesting suggestions.
>> Under the topic we discussed on 'legal jurisdiction for recourse, appeal, enforcement of contracts and perhaps more", I think we agreed to have it noted, but some of the discussion indicated that these issues are under consideration within ICANN and should continue to be addressed within ICANN.
>> On these topics, I would not think that CCWG can make any consensus statement, but we can perhaps state that there are a range of views about a range of issues related to legal jurisdiction. and even list a few of them.
>> On a second topic, which I am not sure how to 'label' it, comes the discussion of 'what is ICANN's scope of responsibility", e.g. is it only a technical coordinating body, or does it have a range of responsibilities. I suggested it not be put under 'what is ICANN' as
>> what is ICANN is a bit more settled, with language that is based on bylaw definition.
>> The topic Nareesh raised and which I had comment on, is a bit more like" What is ICANN's scope of responsibility" for its actions, and again, I think that this is the ICANN's community's responsibility to debate and reach rough agreement on.
>> Some may believe strongly that ICANN has broader opportunity to affect the use and availability the Internet, while others will perhaps want a very strict interpretation of 'what is ICANN's role or scope of responsibility'.
>> Again, I support having a subject line, and describing the discussion, as it is about evolving ICANN, but I don't consider it possible for the CCWG to answer the question in time for a submission.
>> Recommendations and Preliminary Conclusions Section:
>> I would also propose that the CCWG consider a statement about where these discussions and decisions should take place: e.g. inside ICANN, external to ICANN; some mechanism which considers external proposals made but where the ICANN community takes outputs from external events, such as the Brazilian hosted NET Mundial conference, as well as other related and applicable happenings in the broader Internet Ecosystem into account.
>> Planning Team for the Public Session : What shall we call those who are developing the Public Session: Public Session Planning Team: Coordinators for the Public Session? Public Session Program Team? It is a time limited working team, that is just developing a proposed approach for the CCWG to agree to...
>> Petya is sending a doodle for those who are participating in the development of the public session during ICANN/Singapore and we can have a preliminary call next week, and then report into the next CCWG, and address additional inputs/ideas.
>> Again, my apologies to have to drop off. As some know when we started, I had indicated informally before the transcript started, that I am at the UN Commission on Science and Technology [CSTD] Working Group. This discussion is a key part of the 'evolution of the Internet Governance EcoSystem', as it is about the broader EcoSystem.
>> SUGGESTION for one more statement:
>> Ithink one thing we should also talk about is CCWG 'view' for consideration by the broader ICANN community about what the fuller definition and scope of the IG EcoSystem is/and whom it includes.
>> It is a bit disconcerting to me that in the first Strat Panel report published, the advisors/drafters, who are listed, fortunately, as well as the official members of the group, seem to misconvey the larger ecosystem and how ICANN fits into a much larger ecosystem in some places, while in others, they seem to be doing better.
>> The published charts actually put ICANN sort in the 'center' of the entire universe in one case, Another chart they use in that Strat Panel Report shows the US, EU, ICANN, ITU, FTC, which I assume means a governmental agency, possibly from the US-- e.g. the Federal Trade Commission. They ignore all other countries; list the GAC as separate from ICANN, and indeed sort of convey that gTLDs and ccTLDs are separate from ICANN. They have a chart, Figure 4,which uses the term Functional View of the Internet Ecosystem which is mostly about the relationship between ITU and ICANN, but confusingly inserts the IGF into a section alongside Governments and Companies, WTPF, WSIS, ISOC and ITU.
>> CCWG and the broader ICANN COMMUNITY of stakeholders are much more sophisticated in understanding that the Internet governance Eco System is much more than ICANN. As we think about messages that the CCWG might be trying to agree on for the submission into NETmundial Conference, I hope that we can make a statement of this nature, while noting that we believe members of ICANN's stakeholders often wear different hats, and also work at UNESCO, CSTD,
>> Can I first see if there is support for this idea for a paragraph of this nature -- NOT about the charts, but about ICANN's role within the larger Internet Governance EcoSystem.
>> Sent from my iPad
>>> On Feb 27, 2014, at 5:16 PM, "Marilyn Cade" <marilynscade at hotmail.com> wrote:
>>> I need access, Leon.
>>> I have trouble using Google docs, on my tablet, but will try.
>>> Sent from my iPad
>>>> On Feb 27, 2014, at 4:03 PM, "León Felipe Sánchez Ambía" <leonfelipe at sanchez.mx> wrote:
>>>> Dear all,
>>>> I have created, as per Olivier’s request, a google doc that consolidates the most recen contributions to the document we’ve been working on.
>>>> If you were not included in the original notification of creation, I kindly ask you to request access to the document and I will gladly grant it immediately.
>>>> The aim of this is to have a common workspace other than the wiki so we can all contribute in a single draft document.
>>>> I hope you find it useful.
>>>> All the best,
>>>> Inicio del mensaje reenviado:
>>>>> De: León Felipe Sánchez Ambía (Google Drive) <leonfelipe at sanchez.mx>
>>>>> Asunto: Draft Internet Governance Brazil Meeting ccWG Submission Consolidated (leonfelipe at sanchez.mx)
>>>>> Fecha: 27 de febrero de 2014 08:57:08 GMT-6
>>>>> Para: leonfelipe at sanchez.mx
>>>>> Cc: kdrazek at verisign.com, michele at blacknight.com, kstubbs at afilias.info, DFares at 21cf.com, paf at netnod.se, aparnasridhar at google.com, jbladel at godaddy.com, marilynscade at hotmail.com, ocl at gih.com, GShatan at reedsmith.com
>>>>> I've shared an item with you.
>>>>> Draft Internet Governance Brazil Meeting ccWG Submission Consolidated
>>>>> Snapshot of the item below:
>>>>> DRAFT Contribution from the ICANN Cross Community Working Group on Internet Governance.
>>>>> [ Short intro with all the bells & whistles thanking the conference organisers for accepting the contribution. ]
>>>>> This contribution has been drafted using multi-stakeholder principles by the ICANN Cross Community Working Group (CCWG) on Internet Governance, a group that comprises members of ICANN’s Supporting Organisations (SO), Advisory Committees (AC) and Generic Names Supporting Organization (GNSO) Stakeholder Groups (SG). This bottom-up process involved up to 5 people from each of these groups that comprise ICANN’s volunteer community. The concepts expressed in this paper are the result of discussion having taken place on the working group’s mailing list, the CCWG Wiki space created to support it and weekly conference calls throughout the months of January and February 2014.
>>>>> Due to time pressures, the proposals expressed in this contribution have not, so far, been ratified by the respective SOs, ACs and SGs of ICANN. Further communication will advise the NetMundial Organizing Committee if such ratification takes place before the meeting in Brazil.
>>>>> PART 1: Internet Principles
>>>>> 2. Definitions of the terms we are using
>>>>> [ In this section we provide definitions of terms we are going to use in our arguments, so as to avoid any ambiguity which would bring a frivolous discussion in Brazil or generate a misunderstanding which could be used by people wishing to attack the accuracy of our submission. ]
>>>>> In this section, we provide a backgrounder on the definitions that we attribute to terms used in this contribution. The definition of those terms does not serve as a universal definition but rather as the meaning of those terms in the context of the contribution in order to avoid ambiguity.
>>>>> What is ICANN?
>>>>> [ Contributions from Michele Neylon; Ariel Manoff; Marilyn Cade; Wolf-Ulrich Knoben – consensus needed ]
>>>>> What is a multi-stakeholder model?
>>>>> [ Leon Sanchez ]
>>>>> The Multi-Stakeholder Model (MSM), as opposed to the Multi-Lateral Model, provides all interested parties a voice in critical decision-making processes. Within the MSM different stakeholders will take the lead on particular matters based on their competency and mandate but transparency and dialogue are key to the success of multistakeholder processes. Within the context of ICANN, the multistakeholder model refers to the bottom-up, consensus-based process by which stakeholders who participate in ICANN develop policies related to Internet naming and numbering, as well as policies to support the security, stability, and interoperability of the global Internet. Participants in ICANN’s multistakeholder model include businesses, civil society organizations, individual Internet users, technical experts, and governments, each with their respective role. In the MSM, any individual or organization may voice anopinion, and ideally, all opinions are considered on their own merits.
>>>>> What is a multi-lateral model?
>>>>> [ Leon Sanchez ]
>>>>> The Multi-Lateral Model (MLM) is a decision-making process wherein nation states negotiate policy among themselves. In an ideal process, the governmental parties are expected to voice the interests of their citizens. Citizens, businesses, civil society organizations and technical experts cannot participate directly in decision-making of a multi-lateral decisionmaking process. Some multilateral organizations do offer consultative status to non-governmental stakeholders.
>>>>> ASO: [ definition needed, possibly from ASO members ]
>>>>> ccNSO: [ definition needed, possibly from ccNSO members ]
>>>>> GNSO: [ definition needed, possibly from GNSO members ]
>>>>> ALAC: "At-Large" is the name for the community of individual Internet users who participate in the policy development work of ICANN. The 15 member At-Large Advisory Committee (ALAC) is responsible for considering and providing advice on the activities of the Internet Corporation for Assigned Names and Numbers (ICANN), as they relate to the interests of individual Internet users (the “At-Large” community). ICANN, as a private sector, non-profit corporation with technical management responsibilities for the Internet’s domain name and address system, relies on the ALAC and the broader At-Large community to involve and represent in ICANN a broad set of individual Internet user interests.
>>>>> GAC: [ definition needed, possibly from GAC members ]
>>>>> SSAC: The Security and Stability Advisory Committee (SSAC) advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems. This includes operational matters (e.g., matters pertaining to the correct and reliable operation of the root name system), administrative matters (e.g., matters pertaining to address allocation and Internet number assignment), and registration matters (e.g., matters pertaining to registry and registrar services such as WHOIS). SSAC engages in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and advises the ICANN community accordingly.
>>>>> RSSAC: [ definition needed, possibly from RSSAC members ]
>>>>> RIR: [ Draft already Submitted by Filiz, Michele & Tracy ]
>>>>> IETF: [ definition needed // John Curran Def possible ]
>>>>> [ John Curran’s draft:
>>>>> The mission of the Internet Engineering Task Force (IETF) is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
>>>>> 1) The IETF develops Internet protocol standards to facilitate global
>>>>> communications among the voluntary users of these protocols -
>>>>> 1a) Users of these protocols include both the vendors who implement
>>>>> them and the customers who use these implementations
>>>>> 1b) These standards have specifications (as elaborated in the RFC
>>>>> series) and interoperability is facilitated by implementation
>>>>> and usage in conformance with the specifications
>>>>> 1c) Specifications should be made widely and freely available to
>>>>> the extent possible, to encourage usage in conformance with the
>>>>> 2) Some protocols include specification of parameter fields which can
>>>>> take on a range of values; these ranges are referred to registries.
>>>>> Interoperability is facilitated having commonly agreed values in
>>>>> each protocol parameter registry -
>>>>> 2a) Just as with the specifications themselves, the users of these
>>>>> registries include both the vendors who implement protocols and
>>>>> the customers who use the implementations.
>>>>> 2b) Interoperability is facilitated by having registries implemented
>>>>> and used in conformance with the protocol specifications.
>>>>> 2c) Access to registries should be widely and freely available to
>>>>> the extent possible, to encourage protocol usage in conformance
>>>>> with the specifications.
>>>>> 2d) Some protocol parameters are "general use", and registry values
>>>>> assigned upon request to specific parties in accordance with the
>>>>> registry policy. Such assignments are generally unique in nature,
>>>>> i.e. only one party is associated with each general-purpose
>>>>> registry entry.
>>>>> 2e) Coordination (or automation) is necessary to provide uniqueness
>>>>> of assignments in each registry, but it is particularly important
>>>>> in the general purpose registries given the large number of
>>>>> assignments involved. Several of the general purpose registries
>>>>> (DNS, IPv4, IPv6, ASNs) have been delegated to parties external
>>>>> to the IETF which are believed to be reasonably representative
>>>>> of the communities dependent upon those registries.
>>>>> 2f) Due to protocol specifications, some registries have interactions
>>>>> with one another (e.g. IPv4 assignments and in-addr.arpa DNS space)
>>>>> and require coordination of registry activities as a result.
>>>>> 3) The remarkable success of the Internet has resulted in it serving a
>>>>> fundamental role in economic and social development; therefore, the
>>>>> ability of a given community (or government) to "voluntarily" decline
>>>>> to make use of Internet standards and registries is actually rather
>>>>> limited -
>>>>> 3a) The implied requirement to make use of Internet standards and
>>>>> registries in order to achieve the economic and social benefits
>>>>> of the Internet only reinforces the need for development processes
>>>>> which are open to all interested parties, as well as the importance
>>>>> of transparency in decision making.
>>>>> 3b) Outcomes which are based on factors other than technical merit
>>>>> may result in social, political, or economic tradeoffs being
>>>>> integrated into the specifications or registry policies, and
>>>>> are best done based on extremely widely held norms and values.
>>>>> 3c) To the extent that the IETF does decide to embed a particular
>>>>> social or economic tradeoff in a specification beyond reasons
>>>>> of technical necessity, it should do so in an explicit manner
>>>>> and based on widespread endorsement by the IETF community.
>>>>> 3d) Particular care in Internet coordination should be paid to
>>>>> expressions of public policy principles which are widely held
>>>>> by many governments (e.g. EU's personal data privacy directive),
>>>>> as these can be more readily considered to avoid specifications
>>>>> or registry policy which might be in conflict in a wide region and
>>>>> thus contrary to the goal of facilitating global communications.
>>>>> 3e) Mechanisms should be provided for promoting high-level awareness
>>>>> to all interested parties (including governments and other
>>>>> stakeholders such as civil society) of specification or registry
>>>>> policy development which has significant potential for incorporating
>>>>> public policy tradeoffs in the final specifications or registry policy.
>>>>> This last principle and its corollaries (3 & 3a-3e) are a distinguishing
>>>>> factor between the IETF and simply any other technical standards body...
>>>>> i.e. with global and pervasive deployment of the IETF's specifications must
>>>>> also come a level of awareness of its potential (intentionally and otherwise)
>>>>> of social and economic impact as a result of its efforts. This has been
>>>>> more visible in the DNS and IP registry communities, but should probably
>>>>> be explicitly discussed in the IETF so that a common understanding can be
>>>>> reached on the IETF's role in the Internet ecosystem, and particularly with
>>>>> respect to governmental interactions since governments are now coming to
>>>>> similar realization about the Internet ecosystem (incl IETF) and its potential. ]
>>>>> 3. Arguments (place-holder name, please suggest another name than this)
>>>>> [ These are the explanation of the point of view of this community. Please draft those as punchy and concisely as possible.
>>>>> At the moment we are all working in small groups in order to draft those arguments. You'll notice that some are technical in nature (the single root) whilst others are more "internet governance".
>>>>> 3.1 Technical Arguments
>>>>> Why is a Single Root needed?
>>>>> A single root is needed to ensure global uniqueness regarding names in the namespace created by the delegated administration and allocation of unique names.
>>>>> Why is a Single Internet needed?
>>>>> Only parties connected to the same IP based network with the same globally unique IP address space can communicate with each other.
>>>>> What is DNSSEC? On what principles does it work?
>>>>> With the help of the digital signatures of DNSSEC it is possible for whoever receives a response from a DNS query to validate that the response is authoritative, and that the signed data has not been changed during transport.
>>>>> Trusted Community Representatives in DNSSEC?
>>>>> As part of the joint effort to secure the domain name system (DNS) and the Root DNSSEC key management process currently under consideration, a number of persons acting as trusted representatives of the Internet community will be sought to participate in the root key generation and signing ceremonies. These persons are called Trusted Community Representatives (TCRs).
>>>>> The TCRs can be either Crypto Officers or Recovery Key Share Holders.
>>>>> The Crypto Officers are needed to operate the Hardware Security Modules (HSMs) that keep the private key for the root zone. The Recovery Key Share Holders holds pieces of the key material needed for backup of the HSMs content, in the case of complete HSM failure.
>>>>> 3.2 ICANN Governance Arguments
>>>>> How does the Multistakeholder model work in ICANN?
>>>>> Why did ICANN open up the NameSpace for new Top Level Domains?
>>>>> Why did it take so long for new Top Level Domains to be created?
>>>>> What is GAC Advice?
>>>>> What is “Category 1 and Category 2 names in GAC advice”?
>>>>> 3.3 Internet Governance Arguments
>>>>> Critical Internet Resources (CIR)
>>>>> Why is a multi-stakeholder governance model better for the Internet than a multi-lateral model?
>>>>> A multistakeholder model allows all users – whether individual citizens, businesses, governments, civil society organizations, or technical experts – to have a say in shaping the future of Internet governance. Because all members of the Internet community are affected by Internet governance, we should all contribute to its development. Moreover, the multistakeholder model has enabled and fostered the astonishingly rapid growth of the Internet as a critical platform for innovation, creativity, commerce, and the exchange of information and ideas. If we continue to refine and improve the multistakeholder model, we will ensure that the Internet continues to grow and flourish in the future. Again, within the MSM different stakeholders will take the lead on particular matters based on their competency and mandate but transparency and dialogue are key to the success of multistakeholder processes.
>>>>> PART 2: Future evolution of the Internet Governance ecosystem
>>>>> 4. Roadmap Contributions
>>>>> [ This is the part of the Brazil meeting which wishes to design a Roadmap for further evolution of the Internet Governance ecosystem. Whilst in sections 2 and 3, we are merely stating fact which I believe we can all agree to pretty quickly (since it is drafted by the best experts in ICANN: you), Section 4 is going to be a much harder piece of work because:
>>>>> a. we might not agree with each other
>>>>> b. we have so little time to discuss it
>>>>> So let me fire the first shot: what does one mean by a Roadmap? Well, you can bet ICANN's going to be in the firing line for this and Internationalisation of ICANN, including the IANA function is going to be a really hot topic in Brazil. You can already see the European Commission warming up on this. You know Brazil's also hot. And that's nothing compared with some other contributions which we've heard at WCIT over a year ago. ]
>>>>> Evolution of ICANN: principles by which ICANN should evolve.
>>>>> Evolution driven by the ICANN Community
>>>>> bottom-up multi-stakeholder input from the ICANN community
>>>>> Board in ongoing consultation with the community
>>>>> Advice provided by external consultants
>>>>> Needs to be reviewed by the Community
>>>>> Shepherding by the Board
>>>>> Needs to instruct ICANN Senior staff on future directions
>>>>> Negotiations with US Department of Commerce on future of ICANN
>>>>> Taking into account input received from the community in the run-up to these negotiations
>>>>> Transparency as a key to all actions by the Board, ICANN Staff and the Community
>>>>> Topics to be included in Evolution of ICANN
>>>>> Internationalization of ICANN
>>>>> Internationalization of the IANA function
>>>>> International Frameworks for the accountability of ICANN
>>>>> 5. Conclusions
>>>>> [ A very short conclusion // I would shy away from repeating the content in the body of the contribution but would make use of this paragraph to emphasize our overall message. I'd suggest something very punchy here. ]
>>>>> Google Drive: create, share, and keep all your stuff in one place.
>>>> ccwg-internet-governance mailing list
>>>> ccwg-internet-governance at icann.org
>>> ccwg-internet-governance mailing list
>>> ccwg-internet-governance at icann.org
>> ccwg-internet-governance mailing list
>> ccwg-internet-governance at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ccwg-internet-governance