[ccwg-internet-governance] Fwd: Draft Internet Governance Brazil Meeting ccWG Submission Consolidated (leonfelipe at sanchez.mx)

Marilyn Cade marilynscade at hotmail.com
Thu Feb 27 16:15:09 UTC 2014


I need access, Leon. 

I have trouble using Google docs, on my tablet, but will try.

M

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,
> 
> 
> 
> León
> 
> 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.
>> Introduction
>> [ 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
>>        specifications.
>> 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
> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccwg-internet-governance/attachments/20140227/a3598804/attachment-0001.html>
-------------- next part --------------
_______________________________________________
ccwg-internet-governance mailing list
ccwg-internet-governance at icann.org
https://mm.icann.org/mailman/listinfo/ccwg-internet-governance


More information about the ccwg-internet-governance mailing list