[ccwg-internet-governance] Master Document on Google Docs

Olivier MJ Crepin-Leblond ocl at gih.com
Thu Feb 27 16:18:32 UTC 2014

Dear Leon,

I had done some formatting work on the document & have done a complete
cut/paste on it.

Everyone: FYI we're now working from the Google Doc here:
Document 	Draft Internet Governance Brazil Meeting ccWG Submission

Kind regards,


On 27/02/2014 15:02, León Felipe Sánchez Ambía 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
>> <mailto:leonfelipe at sanchez.mx>>
>> *Asunto: **Draft Internet Governance Brazil Meeting ccWG Submission
>> Consolidated (leonfelipe at sanchez.mx <mailto:leonfelipe at sanchez.mx>)*
>> *Fecha: *27 de febrero de 2014 08:57:08 GMT-6
>> *Para: *leonfelipe at sanchez.mx <mailto:leonfelipe at sanchez.mx>
>> *Cc: *kdrazek at verisign.com <mailto:kdrazek at verisign.com>,
>> michele at blacknight.com <mailto:michele at blacknight.com>,
>> kstubbs at afilias.info <mailto:kstubbs at afilias.info>, DFares at 21cf.com
>> <mailto:DFares at 21cf.com>, paf at netnod.se <mailto:paf at netnod.se>,
>> aparnasridhar at google.com <mailto:aparnasridhar at google.com>,
>> jbladel at godaddy.com <mailto:jbladel at godaddy.com>,
>> marilynscade at hotmail.com <mailto:marilynscade at hotmail.com>,
>> ocl at gih.com <mailto:ocl at gih.com>, GShatan at reedsmith.com
>> <mailto:GShatan at reedsmith.com>
>> I've shared an item with you.
>> Document 	Draft Internet Governance Brazil Meeting ccWG Submission
>> Consolidated
>> <https://docs.google.com/a/sanchez.mx/document/d/1BOpCmeE4YL3cat_6oN5RaNvDgvEYO-HS82gRzc_aRjo/edit?usp=sharing>
>> Snapshot of the item below:
>> Draft Internet Governance Brazil Meeting ccWG Submission Consolidated
>> 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.
>> Logo for Google Drive <https://drive.google.com/>
> _______________________________________________
> ccwg-internet-governance mailing list
> ccwg-internet-governance at icann.org
> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance

Olivier MJ Crépin-Leblond, PhD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccwg-internet-governance/attachments/20140227/67f0a206/attachment-0001.html>

More information about the ccwg-internet-governance mailing list