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

Marilia Maciel mariliamaciel at gmail.com
Fri Feb 28 04:23:43 UTC 2014


Dear all, a contribution about evolution of the ecosystem is now in the
google doc. I tried to expand Olivier's initial points. It is rough, but it
is a small step forward. There are some topics that others could develop
better than me, so I left them as bullet points.

Unfortunately I did not have the chance to discuss this with the other
volunteers in my group yet. Since the call will start in a couple of hours
I decided to share it, but please bear that in mind.

I will try to be in the call, but it will start at 4AM for me, in about 3
hours. Apologize in advance if I fail to make it.

Best wishes,
Marilia


On Fri, Feb 28, 2014 at 12:37 AM, Marilia Maciel <mariliamaciel at gmail.com>wrote:

> 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.
> Thanks!
> Marilia
>
>
> 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
> http://direitorio.fgv.br/cts
>
> DiploFoundation associate
> www.diplomacy.edu
>
>
>
>


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

Researcher and Coordinator
Center for Technology & Society - FGV Law School
http://direitorio.fgv.br/cts

DiploFoundation associate
www.diplomacy.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccwg-internet-governance/attachments/20140228/6779b974/attachment-0001.html>


More information about the ccwg-internet-governance mailing list