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

Carlton Samuels carlton.samuels at gmail.com
Fri Feb 28 20:58:31 UTC 2014

.....here, finally, an explanation for my sense of unease and drift with
the document!

For this kind of event, it is too long; reduce the number of examples by
fielding, at minimum, the best one supportive of specific declarations,
especially the framework one; MSM is optimal for IG.  Take a look at the
submissions to date.....at least the ones folks would read all of it.

It misses the connection between the limited face time a delegate from CCWG
might have and the referent communique for which this submission should be
is expected as input for crafting.

Declarations ignored (or missed) using the declarative voice.

I support the baseline advice; reorder and make each header an affirmative



Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*

On Fri, Feb 28, 2014 at 3:12 PM, Aparna Sridhar <aparnasridhar at google.com>wrote:

> Everyone,
> 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.
> Cheers,
> Aparna Sridhar
> Counsel
> 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
>> 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
>> 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.
>> M
>> 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.
>> 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 <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 list
>> ccwg-internet-governance at icann.org
>> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance
>> _______________________________________________
>> ccwg-internet-governance mailing list
>> ccwg-internet-governance at icann.org
>> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance
>> _______________________________________________
>> ccwg-internet-governance mailing list
>> ccwg-internet-governance at icann.org
>> https://mm.icann.org/mailman/listinfo/ccwg-internet-governance
> _______________________________________________
> 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/20140228/e0fe1d60/attachment-0001.html>

More information about the ccwg-internet-governance mailing list