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

León Felipe Sánchez Ambía leonfelipe at sanchez.mx
Fri Feb 28 03:41:06 UTC 2014

Dear Marilia,

I have changed the document settings so anyone that has the link can access
and edit it.

Best regards,


El 27/02/2014, a las 21:37, Marilia Maciel <mariliamaciel at gmail.com>

Dear Leon,
Could you please grant me access to the Google document? I have drafted
some initial text on institutional evolution and have shared with the
volunteers in my group, but it would be good if others could take a look
before our meeting.

On Thu, Feb 27, 2014 at 1:18 PM, Olivier MJ Crepin-Leblond <ocl at gih.com>wrote:

>  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:
>   [image: 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>
> Kind regards,
> Olivier
> 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>
>  *Asunto: **Draft Internet Governance Brazil Meeting ccWG Submission
> Consolidated (leonfelipe at sanchez.mx <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.
>   [image: 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 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. [image:
> Logo for Google Drive] <https://drive.google.com/>
> _______________________________________________
> ccwg-internet-governance mailing listccwg-internet-governance at icann.orghttps://mm.icann.org/mailman/listinfo/ccwg-internet-governance
> --
> Olivier MJ Crépin-Leblond, PhDhttp://www.gih.com/ocl.html
> _______________________________________________
> ccwg-internet-governance mailing list
> ccwg-internet-governance at icann.org
> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance

*Marília Maciel*
Pesquisadora Gestora
Centro de Tecnologia e Sociedade - FGV Direito Rio

Researcher and Coordinator
Center for Technology & Society - FGV Law School

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

More information about the ccwg-internet-governance mailing list