ICANN recently established the Qualified Launch Program (QLP), which enables new gTLD registries to issue domain names to certain parties to help promote awareness that a new TLD is launching. These domains are somewhat like “anchor tenants” in a new shopping center – their presence makes the location attractive to other businesses.

A number of registries expressed interest in this type of program. ICANN worked to deliver without losing sight of intellectual property protections. The solution we arrived at was to permit registries to use a limited number of names in connection with registry launch activities, so long as those names did not conflict with the rights protection mechanisms required by the Registry Agreement.

How does the Qualified Launch Program work?

The QLP provides that a registry can give up to 100 names to third parties before Sunrise (a rights protection mechanism) if the name:

  1. is not on the list of Sunrise-eligible labels in the Trademark Clearinghouse (the “Sunrise List”)
  2. is on the Sunrise List, but is given to a Sunrise-eligible rights holder
  3. is a public authority or place operated by a public authority

Why is the QLP being introduced?

The goal of the QLP is to give new registries additional tools as they open up their doors for business. Having a program generally available will also be beneficial in being more efficient than asking registries to apply individually for Approved Launch Programs.

How was the QLP introduced?

As with many other ICANN endeavors, we first developed a draft of the process, then published it and solicited community input. After analyzing comments and concerns, ICANN established the Qualified Launch Program and it has been automatically incorporated into the Rights Protection Mechanism Requirements [PDF, 167 KB].

The QLP is essentially the same as the draft version. Here is an overview of the updates:

  1. Slightly revised definition of names that can be given to governments/public authorities
    Comments suggested some revisions to this category, for example, incorporating “subdivisions or districts” of a city or region, which have been incorporated as this is in keeping with the intent of the draft. We have also made a clarification that these names can be in any language provided they fit the requirements.

  2. “Public authority” category of names made available to any TLD
    Originally, only names identified as “geographic” according to the Applicant Guidebook definition were eligible under the public authority category.Community feedback suggested that eligibility should not be limited to those TLDs that fell within the Guidebook definition, as a broader set of registries might also have a geographic orientation. Given what appears to be a low risk that governments or public authorities will use the QLP to circumvent rights protections, ICANN updated the QLP to allow any registry to give out names to these groups.

How do I use the QLP?

All registries may assign names, as provided by the QLP, after following the steps below:

  1.  Notify ICANN of the intention to use the QLP, by either submitting or updating the registry’s TLD Startup Information.
  2. Obtain a Sunrise List, including all the labels associated with a Signed Mark Data (SMD) file, from the Trademark Clearinghouse.
  3. Check the names you would like to assign against the list. You may give out QLP names to:
    1. Sunrise-eligible rights holders
    2. Public authorities
    3. Anyone, IF the name isn’t on the list AND you have distributed less than 99 other names

We hope that the QLP will be a useful tool for registries to use in launching their TLDs.

Further Reading


About a year ago, The Spamhaus Project was victim to what was then considered the worst to date DDoS attack. It directed DNS response traffic at a rate of nearly 300 gigabytes per second against Spamhaus’s name servers flooding them, making them unable to resolve requests for www.spamhaus.org and making www.spamhaus.org appear down to anyone unable to resolve the name.

To do this, the attackers exploited a vulnerability in the Domain Name System (DNS). They directed their attack against DNS resolvers and against the authoritative name servers set up by the registrant (in this case, Spamhaus) for the regular operation of their own domain name. While the threat that this type of attack represents comes from the misuse given by attackers to addressing resources, its mitigation rests in improving address management practices at the network edge (see 1.4, SAC 004 [PDF, 8 KB].)

DNS DDoS Attacks Fundamentals

The attackers used three techniques – IP spoofing, reflection, and amplification – to launch this massive attack against Spamhaus. They coordinated to send extraordinary numbers of DNS queries to around 30,000 DNS servers. In each of these queries, the source address was spoofed or set to the address of Spamhaus’ DNS server. This caused the 30,000 DNS servers to believe that their responses had to be sent to the Spamhaus’ DNS server (reflection). And, to make things worse, the attackers made a DNS query that would cause all the 30,000 DNS servers to reply with a very large response packet (amplification.)

Is there a solution?

Back in the 90s, Paul Ferguson and Dan Senie predicted the enormous potential of harm that IP spoofing represents and published, via the Internet Engineering Task Force (IETF,) a draft of the document that, after a long process and several years of discussion, ended up becoming BCP 38 (What is a BCP?)

BCP 38 describes the solution (or a defense, depending on who you ask) to IP address spoofing: That all Internet service providers and operators of Internet infrastructure implement a technique called Source Address Validation in their servers. If an ISP has implemented BCP38, when it receives an IP packet claiming to come from an IP address that’s not within the range of addresses that have been assigned to it, the ISP would block the packet and not let it through.

BCP38′s implementation

BCP38 greatly reduces the ability to create attacks of such scale as the one launched against Spamhaus. What’s unfortunate is that, although the first draft of the document was published in 1997, the measures have not yet been implemented widely by most ISPs throughout the world.

Because of the low level of implementation of BCP38, I wanted to ask some questions to Paul Ferguson, one of its co-authors, who very kindly shared his view for this post:

Carlos Alvarez (CA): You are one of the 2 authors of BCP38/RFC2827. How frustrating has it been for you that it’s not been widely implemented, although the document was first published so very long ago?

Paul Ferguson (PF): We (my co-author, Dan Senie, and I) actually published the document as an IETF draft in 1997, and it later became RFC2267 in 1998 (what is an RFC?,) obsoleted by RFC2827 in 2000, and later became a BCP (Best Current Practice), specifically BCP38, later in 2000.

How frustrated am I? Only slightly. The Internet is a *very* big thing, and it is not necessarily reasonable to expect complete compliance amongst all participants, especially on an architectural issue which is voluntary, and that is what BCP38 and it’s anti-spoofing recommendations are: voluntary.

Having said that, there is *no* legitimate reason to allow source-spoofed IP traffic on the Internet. Period. Full stop. Networks which allow source-spoofed IP traffic are basically allowing criminal activity within their own networks. We should encourage the entire Internet to embrace S.A.V.E. or Source Address Validation Everywhere.

CA: How do you think we could have all the ISPs and other Internet infrastructure operators implement source address validation? Should we, as some suggest, look for new regulation (Dave Piscitello‘s excellent article on regulation and DDoS attacks can be read here) making it mandatory everywhere?

PF: I would much rather prefer that the ISP community police itself and voluntarily implement these measures instead of governments and legislatures getting involved. We need to do this before someone else tries to force us to do it, and we end up with something draconian or technically impossible.

Having said that, getting ISPs to do this voluntarily does not seem to be working, so perhaps some small amount of legislation or regulation might be needed. I run hot and cold on this issue.

CA: Merike Kaeo (who is Merike?) recently shared that during an event she asked the Finnish why they are so good at BCP38. Their answer was gracious in its transparency: ‘We implemented BCP38 because our regulator said it is a good idea.’ So, if regulation is not the perfect answer, and it of course will never be the solve-it-all solution, should we replace all the employees of every operator of Internet infrastructure with Finnish folks?

PF: With regards to the Internet, I’ve always been of the opinion that “Let a thousand flowers bloom” is the appropriate attitude. We welcome diversity, and we should embrace it. But at the same time we should also embrace the idea of a CDC (Center for Disease Control) model for the Internet Infrastructure. If we all don’t agree to some basic guidelines to support the health of the Internet, someone may come along and simply burn it down as they like, and that’s what these DDoS attacks represent.

Some recommendations regarding Source Address Validation

Paul Vixie (who is Vixie?), in a conversation he recently had with a reporter, made some suggestions on how to seek wider implementation of BCP38 that can be worth discussing, such as including civil penalties for contributory negligence when a non-Source Address Validated network is used as a DDoS launch point that causes harm, and ISO 9000 or 27000 terms of reference for this, so that buying insurance is harder if networks are not doing Source Address Validation.

To complete these, it is necessary to make reference to the document SAC065 [PDF, 423 KB], published by ICANN‘s Security, Stability and Resiliency Advisory Committee, that contains recommendations that should be adopted by all ISPs and Internet infrastructure operators all around the globe.

I asked Vixie if he could write some lines to the ISPs and Internet infrastructure operators in Latin America. I extracted these, that are applicable to folks all around the world: “Source Address Validation is a little more work for network operators, but the downstream benefit for the overall economy and for human society is well worth that extra work.”


Hopefully the ISP industry and all the other operators of Internet infrastructure will soon implement – voluntarily – Source Address Validation. If they don’t, the frequency and size of the DDoS attacks will continue to grow, increasing the likelihood of regional Internet blackouts, and increasing the likelihood that national governments enact regulations that may not necessarily be operationally or technically desirable.

Special thanks to Vixie and Fergie for their kind contributions to this article.

Greetings from California,

Carlos S. Alvarez
SSR Technical Engagement Sr. Manager
Security Stability Resiliency Team


Hace ya un año que The Spamhaus Project fue víctima del que, en su momento, fue considerado el más grande ataque distribuido de denegación de servicios. Los atacantes lograron enviar 300 gigabytes por segundo contra los servidores de nombres de dominio de Spamhaus, haciendo que éstos no pudieran responder las solicitudes de resolución del nombre www.spamhaus.org y haciendo que el sitio web pareciera estar caído a quien tratara de visitarlo al no conseguir la resolución del dominio.

Los atacantes explotaron una vulnerabilidad en el sistema de nombres de dominio (DNS). Ellos dirigieron el ataque contra los resolutores de DNS y contra los servidores de nombres de dominio autoritarios definidos por Spamhaus para la operación normal de su dominio. Mientras que la amenaza que esta clase de ataques representa es dada por el mal uso que los atacantes dan a los recursos de direccionamiento del DNS, su mitigación consiste en el mejoramiento de las prácticas de administración de direcciones en lo que se conoce como el ‘network edge‘ (ver 1.4, SAC 004 [PDF, 8 KB]).

Fundamentos de los ataques de DDoS a través del DNS

El DNS está compuesto por una cadena de queries enviados desde el navegador del usuario hasta un servidor que tiene la autoridad para responder. Simplificando el proceso, si usted quiere visitar ‘ejemplo.com’, su navegador enviará un query a un servidor de DNS preguntándole la dirección IP en la que ‘ejemplo.com’ está alojado. El servidor de DNS buscará la respuesta al query y la enviará de vuelta.

Los atacantes usaron tres técnicas – IP spoofing, reflexión y amplificación – para disparar este ataque masivo contra Spamhaus. Ellos coordinaron el envío de un número extraordinario de queries a alrededor de 30.000 servidores de DNS. En cada uno de estos queries la dirección IP estaba falsificada (spoofing) para aparentar que habían sido enviados por el servidor de DNS de Spamhaus. Esto hizo que los 30.000 servidores de DNS creyeran que sus respuestas debían ser enviadas a ese servidor de DNS de Spamhaus (reflexión). Y, para empeorar las cosas, los atacantes enviaron los queries de manera que las respuestas enviadas por los servidores de DNS a Spamhaus fueran paquetes muy grandes (amplificación).

¿Existe una solución?

En los 90, Paul Ferguson y Dan Senie previeron el enorme potencial de daño que representaba esta vulnerabilidad y publicaron en 1997, a través de la Internet Engineering Task Force o IETF, un borrador del documento que, luego de un largo proceso y varios años de discusiones y desarrollo, terminó convirtiéndose en el BCP 38 (¿Qué es un BCP?).

El BCP 38 describe la solución a esta vulnerabilidad (o una defensa, depende de a quién se pregunte): que todos los proveedores de servicios de Internet implementen una técnica denominada Source Address Validation. Si un ISP ha implementado el BCP 38, al recibir un paquete IP que diga venir de una dirección IP por fuera de los rangos de IPs que le hayan sido asignados, su servidor lo bloqueará y no lo dejará pasar.

Implementación del BCP 38

El BCP 38 reduce en gran medida las posibilidades de crear ataques de la misma escala del que fue dirigido contra Spamhaus. Lo paradójico es que, a pesar de que el primer borrador del documento fue publicado en 1997, la técnica aún no ha sido implementada por la gran mayoría de ISPs en el mundo.

Por el bajo nivel de implementación quise hacerle algunas preguntas a Paul Ferguson, uno de sus coautores, quien muy amablemente compartió su opinión para este artículo:

Carlos Álvarez (CA): Tu eres uno de los dos coautores del BCP 38. ¿Qué tan frustrante es ver que aún no ha sido ampliamente implementado, a pesar de que fue publicado hace tantos años?

Paul Ferguson (PF): Nosotros (Dan Senie y yo) publicamos el documento como un borrador de la IETF en 1997, luego se convirtió en el RFC2267 en 1998 (¿Qué es un RFC?), que fue a su vez derogado por el RFC2827 en el año 2000 y que en ese mismo año terminó convirtiéndose en el BCP 38.

¿Qué tan frustrante es para mí? Sólo un poco. Internet es algo *muy* grande y no es necesariamente razonable esperar que todos los que participan en él cumplan con su deber, especialmente en un tema de arquitectura que es voluntario.

Sin embargo, no hay una sola razón *legítima* para permitir tráfico en Internet que falsifique la dirección IP desde la que éste proviene. Punto final. Las redes que permiten esta clase de tráfico están permitiendo que haya actividad criminal en su propio terreno. Deberíamos invitar a todo el Internet a implementar SAVE o Source Address Validation Everywhere.

CA:¿Deberíamos, como algunos sugieren, buscar nuevas regulaciones y hacer de esto una obligación en todas partes? (El excelente artículo de Dave Piscitello sobre regulación y DDoS se puede encontrar acá).

PF: Preferiría mucho más que sea la comunidad misma de ISPs la que se vigile a sí misma e implemente voluntariamente estas medidas, a que sean los gobiernos y los congresos los que se involucren porque pueden terminar imponiendo leyes redactadas por personas no técnicas. Necesitamos hacer esto antes de que alguien intente forzarnos y terminemos con una regulación draconiana o técnicamente imposible.

Por otro lado, conseguir que los ISPs hagan esto voluntariamente no parece estar funcionando, así que tal vez una pequeña cantidad de legislación o regulación se puede necesitar. Estoy indeciso en este asunto.

Deberíamos también apoyar la idea de un modelo similar al del CDC (Center for Disease Control) para la infraestructura de Internet. Si todos no nos ponemos de acuerdo respecto de unas líneas básicas para apoyar la salud de Internet, alguien puede venir y simplemente incendiarlo como le plazca, que es lo que estos ataques de DDoS representan.

Recomendaciones relativas a la Source Address Validation

Hace pocos días Paul Vixie sostuvo una conversación con un reportero en la que expresó algunas recomendaciones relacionadas con la importancia de que el BCP 38 sea ampliamente implementado. Bien vale leerlas acá.

También es necesario hacer referencia al documento SAC065 [PDF, 423 KB], publicado por el Comité Asesor en Seguridad, Estabilidad y Resiliencia de la Internet Corporation for Assigned Names and Numbers (ICANN). El documento contiene una serie de recomendaciones que deberían ser seguidas por los ISPs y los operadores de infraestructura de Internet en todo el mundo.

Finalmente, pedí a Vixie que enviara unas líneas sobre este tema a los ISPs y operadores de infraestructura de Internet en América Latina. Estas son sus palabras:

“Un agradecimiento especial y un saludo a mis colegas que manejan la operación y la seguridad de Internet en América Latina… Ustedes tienen la oportunidad de construir un mejor sistema que el que nosotros tenemos.

“…El Viejo Internet fue construido sobre lo que yo llamo <<un modelo de negocio contaminante>> en el que desechos industriales peligrosos, resultado de nuestras ganancias económicas, son con frecuencia arrojados a la Red y se convierten en un problema para todos los demás.

“Los reto a hacerlo mejor que nosotros. De hecho, los reto a demostrarle al mundo cómo el Internet debió ser construido y cómo puede ser reconstruido.

“Source Address Validation es un poco más de trabajo para los operadores de redes, pero el beneficio para toda la economía y para la sociedad humana bien vale la pena ese poco más de trabajo”.


Ojalá la industria de ISPs y los demás operadores de infraestructura de Internet implementen –voluntariamente– Source Address Validation cuanto antes. Si no lo hacen, la frecuencia y la magnitud de los ataques de denegación de servicios continuarán creciendo, incrementando la probabilidad de que se presenten apagones regionales de Internet y la probabilidad de que gobiernos nacionales dicten regulaciones que no sean deseables desde el punto de vista operacional o técnico.

Un agradecimiento especial a Vixie y a Fergie por sus amables contribuciones para este artículo.

Saludos desde California,

Carlos S. Alvarez
SSR Technical Engagement Sr. Manager
Security Stability Resiliency Team

Nota: la versión en español de este artículo fue inicialmente publicada acá.


Training Wheels Off

by Fadi Chehadé on April 11, 2014

My sons are adults now but I remember like it was yesterday teaching them how to ride their bikes. Removing the training wheels from their bicycles was an important milestone, but it didn’t mean that I was ready to leave them on their own to ride the neighborhood. As they got used to being on two wheels instead of four, I was right there beside them, ready to correct and guide.

I can’t help but see the parallels when I think about the U.S. government’s announcement last month. The U.S. government came to the conclusion that the global Internet community is now ready to assume stewardship of ICANN’s performance as the administrator of the IANA functions. It feels like the moment when the multistakeholder community’s training wheels come off.

Our hard work for the last 15 years has led us to this milestone, when the U.S. government acknowledged that we as a community have performed our work with distinction and in alignment with our mission.

It is with great humility that we accept this trust and begin the work of developing and strengthening the accountability mechanisms that will be needed to give the world confidence.

During ICANN’s 49th Public Meeting in Singapore in March 2014, we launched a public dialogue on what the process for transitioning from the U.S. government’s stewardship should look like. On 8 April, we posted the initial results of that dialogue, along with a scoping document [PDF, 456 KB]written based on feedback from the community, and consistent with previous discussions.

Specifically, I wish to assure you that the U.S. government, including the NTIA, has approved the scoping document [PDF, 456 KB], and it is consistent with the views of the leaders of various Internet organizations including the Internet Engineering Task Force, the Internet Society and the Regional Internet Registries.

In addition to the public dialogue on the process for the transition of the U.S. government’s stewardship role, we launched at the same time in Singapore a second public dialogue on the broader discussion of how to strengthen the ICANN’s accountability. This second dialogue will look at strengthening existing accountability mechanisms like the Affirmation of Commitments, and ICANN’s redress mechanisms, as well as exploring new accountability mechanisms where necessary. We will share documents on the scope and proposed process of this second dialogue shortly.

These two dialogues will run in parallel, as they are certainly inter-related and will inform each other. A key difference is that the first process will be a public dialogue held in various venues across the global Internet community with a goal of developing the transition proposal requested by the U.S. government. The second is related to ICANN structures and the ICANN community, and the dialogue will mainly occur in the ICANN community while open to all.

These two public dialogues are real-time demonstrations of just how open and inclusive the ICANN community is, and will further prove to the world that we have earned the U.S. government’s confidence in our processes. This is our time to show that the multistakeholder model no longer needs its training wheels. It is ready for a long, steady ride forward.

{ 1 comment }


by Fadi Chehadé on April 11, 2014


当我上个月看到美国政府声明时,我不禁想到了这与学骑自行车的相似之处。美国政府得出了这样的结论:全球互联网群体现在已经可以作为 IANA 职能的管理者承担 ICANN 的运营管理工作。这就像是孩子们学骑自行车时去掉两侧的辅助轮一样。

经过 15 年的辛勤努力我们才完成了这一里程碑,美国政府对我们这个群体根据使命出色地完成工作表示了认可。


在 2014 年 3 月召开的第 49 届 ICANN 新加坡公开会议期间,我们发布了一份关于”美国政府管理职能过渡流程”的公开对话。4 月 8 日,我们发布了此对话的初步结果,并附上了一份根据机构群体反馈和先前讨论撰写的对问题范围的研究文档 [PDF, 75 KB]。

需要特别说明的是,我想让大家放心,美国政府(包括 NTIA)已经批准了对问题范围的研究文档 [PDF, 75 KB],并且这与各个互联网组织(包括互联网工程任务组、互联网协会和地区互联网注册管理机构)的领导者的观点一致。

除了关于”美国政府管理职能过渡流程”的公开对话外,我们还在新加坡会议期间发布了另一份关于”如何巩固 ICANN 问责制的更广泛讨论”的公开对话。第二项对话主要关注巩固当前的问责机制(例如义务确认书、 ICANN 的矫正机制),以及在必要时研究并制定新的问责机制。我们近期将向大家提供有关第二项公开对话的范围文档和拟议流程文档。

这两次对话同时进行,它们是相互联系并相互影响的。一个关键的不同之处在于,第一项对话是在各个地点召开全球互联网群体的公开对话,旨在制定美国政府要求的过渡提案。第二项对话与 ICANN 组织架构和 ICANN 机构群体有关,此次对话主要在 ICANN 机构群体内部进行并对所有人开放。

这两次公开对话都表明了 ICANN 机构群体的开放性和包容性,并将进一步向公众证明我们已经获得了美国政府的信任。我们可以向外界表明,多利益主体模式不再需要”辅助轮”, 该模式已经可以在未来很长一段时间稳定地发挥积极作用。


Мои сыновья уже выросли, но я как сейчас помню, как учил их кататься на велосипеде. Снятие тренировочных колесиков было важным этапом, но это не значило, что я был готов отпустить их кататься по району самостоятельно. Пока они не привыкли кататься на двух колесах вместо четырех, я всегда находился рядом и был готов их поправить или сориентировать.

Не могу не отметить параллели между этой ситуацией и сделанным в прошлом месяце заявлением правительства США. Правительство США пришло к заключению, что глобальное сообщество интернета готово взять на себя координирующую роль по исполнению работы ICANN в качестве стороны, осуществляющей функции IANA. У меня ощущение, как будто настал момент, когда сообщество заинтересованных сторон снимает тренировочные колеса.

Мы смогли достичь этого момента благодаря 15 годам усердной работы, и в результате правительство США подтвердило, что мы, как сообщество, выполняем свою работу отлично и в соответствии с нашей миссией.

Мы принимаем это доверие со смирением и начинаем работу по созданию и укреплению механизмов подотчетности, которые будут необходимы для того, чтобы оправдать доверие мира.

На 49-й конференции ICANN в Сингапуре в марте 2014 года мы начали диалог с общественностью на тему о том, как должен выглядеть процесс передачи координирующей роли от правительства США. 8 апреля мы опубликовали первоначальные результаты этого диалога вместе с документом, описывающим вопросы, подлежащие изучению в ходе составления предложения по передаче функций [PDF, 74 КБ], который был составлен на основании отзывов, полученных от сообщества и соответствующий сути обсуждений, прошедших на более ранних этапах.

Конкретно, я бы хотел заверить вас в том, что правительство США, включая Национальную администрацию США по телекоммуникациям и информации (NTIA), одобрило документом, описывающим вопросы, подлежащие изучению в ходе составления предложения по передаче функций [PDF, 74 КБ] – в соответствии с мнениями лидеров разных интернет-организаций, включая Инженерную проектную группу интернета, Общество Интернета и региональные интернет-регистратуры.

В дополнение к диалогу с общественностью на тему о процессе передачи координирующей роли от правительства США, мы одновременно запустили в Сингапуре второй диалог с общественностью на тему о более широком обсуждении вопросов, связанных со способами укрепления отчетности ICANN. В рамках этого второго диалога будут рассматриваться пути укрепления существующих механизмов отчетности, таких как Подтверждение обязательств, корректирующие механизмы ICANN, а также, в случае необходимости, новые механизмы отчетности. Мы предоставим документы о задачах и предлагаемом процессе в отношении этого второго диалога в скором времени.

Эти два диалога будут проходить параллельно, так как они безусловно взаимосвязаны и будут воздействовать друг на друга. Ключевое различие состоит в том, что первый процесс будет диалогом с общественностью, который будет проходить в разных местах деятельности всего глобального сообщества пользователей интернета с целью развития предложения по передаче функций, о чем попросило правительство США. Второй процесс связан со структурами ICANN и сообществом ICANN – диалог будет проходить в основном в пределах сообщества ICANN, оставаясь открытым для всех.

Эти два диалога с общественностью представляют собой демонстрацию в реальном времени степени открытости сообщества ICANN для всех, а также послужат дальнейшим доказательством того, что мы действительно заслужили доверие правительства США к нашим процессам. Настало время показать, что модель работы с участием многих заинтересованных сторон может снять «тренировочные колесики». Она готова обеспечить стабильное движение по длинной дороге.


Plus de petites roues

by Fadi Chehadé on April 11, 2014

Mes fils sont déjà des adultes, mais je me souviens comme si c’était hier quand je leur ai appris à faire du vélo. Enlever les petites roues de leurs vélos a été sans doute un jalon important, mais cela ne voulait pas dire que j’étais prêt à les laisser se promener tous seuls dans le quartier. Pendant qu’ils s’habituaient à rouler sur deux roues au lieu de quatre, j’étais là, à coté d’eux, prêt à les aider et à les corriger.

Je ne peux pas aider, mais je peux établir le parallèle lorsque je pense à l’annonce du gouvernement des États-Unis du mois dernier. Le gouvernement des États-Unis est arrivé à la conclusion que, d’ores et déjà, la communauté mondiale de l’Internet est prête à assumer la supervision de la performance de l’ICANN comme administrateur des fonctions IANA. Il semblerait que l’heure est arrivée pour que la communauté multipartite enlève les petites roues.

Le travail réalisé pendant les 15 dernières années nous a amenés à ce jalon, lorsque le gouvernement des États-Unis a reconnu que notre communauté a fait un travail remarquable en ligne avec notre mission.

Nous avons accepté cette confiance avec humilité alors que nous avons commencé à développer et à renforcer les mécanismes de responsabilité nécessaires pour mériter la confiance mondiale.

Pendant la 49e réunion de l’ICANN à Singapour, en mars 2014, nous avons lancé un dialogue public pour débattre du processus nécessaire à la transition de la supervision exercée par les États-Unis. Le 8 avril, nous avons publié les résultats initiaux de ce dialogue, ainsi qu’un document orientatif [PDF, 67 KB] écrit sur la base des commentaires de la communauté et cohérent avec les discussions préalables.

Je veux vous assurer, spécifiquement, que le gouvernement des États-Unis, y compris la NTIA, a approuvé le document orientatif [PDF, 67 KB], qui est cohérent avec les points de vue des leaders de plusieurs organisations d’Internet, y compris le groupe de travail de génie Internet (IETF), la société Internet (ISOC) et les registres Internet régionaux (RIR).

Outre le dialogue public concernant le processus de transition du rôle de supervision du gouvernement des États-Unis, nous avons lancé en même temps, à Singapour, un deuxième dialogue public pour entamer un débat plus approfondi sur la manière de renforcer la responsabilité de l’ICANN. Ce deuxième dialogue visera à renforcer les mécanismes actuels de responsabilité comme l’affirmation d’engagements et les mécanismes de réparation de l’ICANN ainsi qu’à explorer les nouveaux mécanismes de responsabilité, le cas échéant.  Nous partagerons prochainement des documents sur la portée de ce deuxième dialogue et sur le processus proposé.

Ces deux dialogues de dérouleront en parallèle de par leur nature interdépendante et ils s’informeront mutuellement. Il existe une différence clé, à savoir que le premier processus sera un dialogue public qui se tiendra dans plusieurs sites à travers la communauté Internet mondiale dans le but de développer la proposition de transition demandée par le gouvernement des États-Unis, alors que le deuxième processus est lié aux structures et à la communauté de l’ICANN. Le dialogue aura lieu principalement au sein de la communauté de l’ICANN mais il sera ouvert à tous.

Ces deux dialogues publics témoignent en temps réel du caractère ouvert et inclusif de la communauté de l’ICANN et ils montreront au monde entier que nous avons gagné la confiance du gouvernement des États-Unis dans nos processus. C’est le moment de démontrer que le modèle multipartite n’a plus besoin des petites roues, qu’il est prêt à parcourir un long chemin en toute sécurité.


Sin rueditas

by Fadi Chehadé on April 11, 2014

Mis hijos ya son adultos, pero recuerdo como si fuera ayer cuando les enseñaba a andar en bicicleta. Sacarles las rueditas auxiliares fue un hito importante, pero eso no quería decir que yo estuviera listo para dejarlos andar solos por el barrio. Mientras se acostumbraban a andar en dos ruedas en lugar de cuatro, yo estaba junto a ellos, listo para corregir el rumbo y guiarlos.

No puedo evitar trazar un paralelismo con el anuncio del Gobierno de los Estados Unidos realizado el mes pasado. El Gobierno de ese país llegó a la conclusión de que la comunidad global de Internet está en condiciones de asumir la supervisión del desempeño de la ICANN como administradora de las funciones de la Autoridad de Números Asignados en Internet (IANA). Es como si la comunidad de múltiples partes interesadas se largara a andar sin rueditas.

El arduo trabajo que realizamos durante los últimos 15 años nos ha llevado a este hito, al reconocimiento por parte del Gobierno de los Estados Unidos de que, como comunidad, hemos realizado nuestro trabajo con distinción y conforme a nuestra misión.

Es con gran humildad que aceptamos este voto de confianza e iniciamos la tarea de desarrollar y fortalecer los mecanismos de responsabilidad que serán necesarios para infundir confianza en el mundo entero.

Durante la Reunión N.o 49 de la ICANN, celebrada en marzo de 2014 en Singapur, iniciamos un diálogo público sobre la forma que debería adoptar el proceso de traspaso de la administración de las funciones de la IANA. El 8 de abril, publicamos los resultados preliminares de ese diálogo, junto con un documento de alcance [PDF, 73 KB] elaborado sobre la base de la retroalimentación recibida de la comunidad y conforme a las discusiones previas.

Específicamente, quiero confirmarles que el Gobierno de los Estados Unidos, incluida la Administración Nacional de Telecomunicaciones e Información (NTIA), ha aprobado el documento de alcance [PDF, 73 KB], y que este se condice con las opiniones de los líderes de diversas organizaciones de Internet, entre ellas, el Grupo de Trabajo en Ingeniería de Internet, la Sociedad de Internet y los Registros Regionales de Internet.

Además del diálogo público sobre el proceso de traspaso del rol de administrador del Gobierno de los Estados Unidos a la ICANN, simultáneamente iniciamos en Singapur un segundo diálogo público sobre la cuestión más amplia de cómo fortalecer los mecanismos de responsabilidad de la ICANN. Este segundo diálogo se centrará en el fortalecimiento de los mecanismos de responsabilidad existentes, como la Afirmación de Compromisos, y de los mecanismos de reparación de la ICANN, y además explorará nuevos mecanismos de responsabilidad en las áreas donde sean necesarios. En breve, publicaremos documentos sobre el alcance de este segundo diálogo y sobre el proceso propuesto para él.

Estos dos diálogos tendrán lugar en forma paralela y, sin duda, están relacionados y serán de utilidad el uno para el otro. Una diferencia fundamental es que el primer proceso será un diálogo público que se llevará a cabo en distintas sedes de la comunidad global de Internet con el objetivo de elaborar la propuesta de transición solicitada por el Gobierno de los Estados Unidos. El segundo proceso está relacionado con las estructuras de la ICANN y su comunidad, y se realizará principalmente en la comunidad de la ICANN pero estará abierto a todos.

Estos dos diálogos públicos constituyen demostraciones en tiempo real de lo abierta e inclusiva que es la comunidad de la ICANN, y además probarán al mundo que nos hemos ganado la confianza que el Gobierno de los Estados Unidos tiene en nuestros procesos. Es el momento de demostrar que el modelo de múltiples partes interesadas ya no necesita rueditas. Está listo para recorrer con firmeza un largo camino.


إزاحة عجلات التدريب المساعدة

by Fadi Chehadé on April 11, 2014

يُعد أولادي الآن بعمر البالغين ولكنني أذكر كما لو كانت البارحة عندما كنت أعلمهم كيفية قيادرة الدراجات الهوائية.  كانت إزالة عجلات التدريب المساعدة على القيادة من دراجاتهم معلماً وحدثاً هاماً، ولكن ذلك لم يكن ليعني بإنني كنت على إستعداد أن أتركهم يقودون دراجاتهم لوحدهم في الحي. وعندما إعتادوا القيادة بعجلتين فقط بدلاً من أربع عجلات، كنت دائماً بقربهم وعلى أهبة الأستعداد لتصحيح  مسارهم وتوجيهم.

لايسعني إلا إن أرى تشابه الحالتين عندما أفكر بـ إعلان الحكومة الأميركية في الشهر الماضي. فلقد توصلت الحكومة الأميركية الى قناعة أن المجتمع العالمي للأنترنت مستعد الآن لتولّي مسؤولية الإشراف والمتابعة على أداء ICANN كمسؤولة إدارية على وظائف هيئة الأرقام المخصصة للإنترنت IANA. إنها تبدو كما لو كانت اللحظة التي تُزال فيها عجلات القيادة المساعدة من مجتمع أصحاب المصلحة المتعددين.

لقد أوصلنا عملنا الجاد على مدى 15 عاماً الى هذه المرحلة وذلك عندما أعترفت الحكومة الاميركية بإننا كمجتمع قد أدينا عملنا بتميّز وبما يتماشى مع مهمّتنا. 

بمنتهى التواضع قبلنا هذه الثقة وبدأنا العمل لتطوير وتعزيز آليات المساءلة التي ستكون مطلوبة لكسب ثقة للعالم.

خلال الأجتماع العام التاسع والأربعين ICANN 49 في سنغافورا في شهر آذار 2014، بدأنا بالحوار العام حول كيف يمكن أن تكون عملية إنتقال إشراف ورقابة الحكومة الأميركية. وفي الثامن من شهر نيسان قمنا بنشر النتائج الأولية للحوار، جنباً الى جنب مع وثيقة منظور العملية [PDF، 4.91 كيلوبايت] والتي وُضعت إستناداً الى ردود أفعال المجتمع وبما يتفق مع النقاشات السابقة.

أريد أن أوكد لكم وعلى وجه الخصوص، بأن الحكومة الأميركية وبضمنها هيئة الأتصالات والمعلومات الوطنية NTIA قاد صادقت على وثيقة منظور العملية [PDF، 4.91 كيلوبايت], وهي على أتفاق تام مع وجهات نظر رؤساء مختلف منظمات الإنترنت وبضمنها فريق عمل هندسة الإنترنت IETF ومجتمع الإنترنت وسجلات الإنترنت الإقليمية.

وبالإضافة الى الحوار العام حول عملية إنتقال دورالحكومة الأميركية في الأشراف والرقابة، فإننا قد بدأنا بحوار عام ثان في نفس الوقت في سنغافورا وعلى نطاق أوسع حول كيفية تعزيز مسؤولية ICANN، سوف يبحث الحوار الثاني في تعزيز آليات المساءلة المتواجدة حالياً مثل التأكيد على الإلتزامات, وآليات الإصلاح الخاصة لدى ICANN وكذلك أستكشاف آليات مساءلة جديدة متى ما أقتضت الضرورة. سوف نقوم قريباً بنشر وثائق بخصوص منظور العملية المقترحة والخاصة بهذا الحوار الثاني.

سوف يجري هذين الحوارين بشكل متزامن مع بعضهما البعض حيث أن لكل منهما علاقة بالآخر وسوف يتم إثراء كل منهما بالآخر. الفرق الأساسي هو إن العملية الأولى ستكون حواراً عاماً يُقام في أماكن متعددة عبر المجتمع الدولي للإنترنت بهدف وضع مشروع مقترح كان قد طُلب من قبل الحكومة الأميركية. في حين أن العملية الثانية مرتبطة بالهياكل التنظيمية لـ ICANN ومجتمعها، وسيكون الحوار جارياً بصورة رئيسية ضمن مجتمع ICANN في الوقت الذي يكون مفتوحاً للجميع.

هذين الحوارين العامين هما إثباتان حقيقيان حول كيف أن مجتمع ICANN هو مجتمع مفتوح وشامل وسيؤكدان للعالم أيضاً بإننا كسبنا ثقة الحكومة الأميركية من خلال عملياتنا.  هذا هو الوقت المناسبة لنُثبت بأن نموذج أصحاب المصلحة المتعددين لم يعد بعد الآن بحاجة الى عجلات التدريب المساعدة. أنه مستعد لقيادة طويلة ومستقرة نحو الأمام.


Tirando as Rodinhas

by Fadi Chehadé on April 11, 2014

Meus filhos já são adultos hoje, mas lembro-me como se fosse ontem de quando os ensinei a andar de bicicleta. Retirar as rodinhas de apoio das bicicletas foi um momento importante, mas isso não significou que eu estava pronto para deixá-los passear sozinhos pela vizinhança. Enquanto se acostumavam a andar em duas rodas em vez de quatro, eu estava lá ao lado deles, pronto para corrigi-los e orientá-los.

Não posso deixar de notar algumas semelhanças quando penso no comunicado do governo dos EUA no mês passado. O governo dos EUA chegou à conclusão de que a comunidade global da Internet já está pronta para assumir a responsabilidade pelo desempenho da ICANN enquanto administradora das funções de IANA. Isso corresponde ao momento em que são retiradas as rodinhas da comunidade de múltiplas partes interessadas.

Todo o nosso trabalho dos últimos 15 anos nos trouxe a esse marco, quando o governo dos EUA reconheceu que nós, enquanto comunidade, desempenhamos nosso trabalho com distinção e de maneira alinhada à nossa missão.

É com grande humildade que aceitamos essa confiança e começamos o trabalho para desenvolver e fortalecer os mecanismos de responsabilidade que serão necessários para dar confiança ao mundo todo.

Durante o 49º Encontro Público da ICANN em março de 2014, em Cingapura, lançamos um diálogo público sobre como deve ser o processo para a transição da administração do governo dos EUA. Em 8 de abril, publicamos os resultados iniciais desse diálogo, juntamente com um documento de escopo [PDF, 79 KB] redigido com base no feedback da comunidade e consistente com as discussões anteriores.

Especificamente, quero garantir a todos que o governo dos EUA, incluindo a NTIA, aprovou o documento de escopo [PDF, 79 KB], e que ele é consistente com os pontos de vista dos líderes de diversas organizações da Internet, incluindo a Força-tarefa de Engenharia da Internet (IETF), a Sociedade da Internet (IS) e os Registros Regionais da Internet (RIRs).

Além do diálogo público sobre o processo para a transição da função administradora do governo dos EUA, lançamos ao mesmo tempo em Cingapura um segundo diálogo público sobre a discussão mais ampla referente a como fortalecer a responsabilidade da ICANN. Esse segundo diálogo terá como objetivo fortalecer os atuais mecanismos de responsabilidade, como a Afirmação de Compromissos, e os mecanismos de reparação da ICANN, bem como explorar novos mecanismos de responsabilidade, quando necessário. Em breve, vamos compartilhar documentos sobre o escopo e o processo proposto desse segundo diálogo.

Esses dois diálogos ocorrerão simultaneamente, na medida em que estão certamente inter-relacionados e se complementam. Uma diferença importante é que o primeiro processo será um diálogo público realizado em vários locais na comunidade global da Internet com o objetivo de desenvolver uma proposta de transição solicitada pelo governo dos EUA. O segundo está relacionado com as estruturas e a comunidade da ICANN, e o diálogo ocorrerá principalmente na comunidade da ICANN, embora esteja aberto a todos.

Esses dois diálogos públicos são demonstrações em tempo real do quanto a comunidade da ICANN é aberta e inclusiva, e comprovará ainda mais para o mundo todo que conquistamos a confiança do governo dos EUA em nossos processos. Este é o nosso momento de mostrar que o modelo de múltiplas partes interessadas não precisa mais de rodinhas. Ele está pronto para um longo e contínuo caminho à frente.