(English Below) *SSR RT Draft Report – Comentarios Públicos*** *Estos comentarios públicos son realizados en nuestra capacidad individual en nombre de Juan Manuel Rojas, José Francisco Arce, Javier Pallero y Fátima Cambronero de los Capítulos de AGEIA DENSI Argentina y Colombia. * * * En primer lugar, queremos felicitar al Equipo Revisor de Seguridad, Estabilidad y Resiliencia por el enorme esfuerzo hecho y por el gran trabajo realizado y un especial agradecimiento a su Chair, Alejandro Pisanty, miembro de nuestra región de América Latina y Caribe. Nos gustaría poner especial énfasis en la presentación ordenada y específica por temas, ya que eso facilitó que un tema con gran nivel de complejidad fuera entendido fácilmente por la comunidad, al estar expresado con un orden lógico y estructurado, y concatenadas cada una de las recomendaciones. Apoyamos todas las recomendaciones realizadas, y aunque no hay mucho margen para ampliarlas, dejamos sentado en el presente, algunos comentarios particulares. Consideramos que es importante que este RT haya partido abordando el alcance de la misión técnica limitada de ICANN. Creemos que es necesario elaborar un documento único, con terminología clara, donde pueda quedar establecida la definición y alcance del SSR, como uno de los objetivos principales dentro del marco del trabajo sobre el Plan de SSR para FY12, incorporando la declaración de responsabilidad de SSR tal cual fue propuesta por el Equipo Revisor. Al mismo tiempo, acordamos que deben quedar claras las relaciones de la ICANN con los demás grupos y las relaciones del SSAC con el RSSAC, por lo que se apoyan las Recomendaciones de la 1 a la 6, ya que la única forma de que los procedimientos sean transparentes y se pueda tener mejor aporte es definiendo, como dice la Recomendación 3, de manera clara la naturaleza de las relaciones. De esta manera, ICANN va a llegar a una mayor cantidad de involucrados dentro del ecosistema de Internet. Especialmente como miembros de una organización regional de usuarios de Internet, sugerimos tener especialmente en cuenta a aquellos que no participan de ICANN. Acordamos con la necesidad de tener definido lo antes posible un Plan de SSR en cuanto a vinculación con otras comunidades dentro y fuera de ICANN y el desarrollo de un mecanismo de retroalimentación eficiente del trabajo del SSR. Compartimos lo expresado respecto a publicar información sobre las amenazas del DNS y sus estrategias de mitigación. Sería importante que se dé a conocer la efectividad o no del plan de seguridad actual que tiene ICANN para hacer frente a desafíos y amenazas reales y potenciales; y cuáles son los objetivos a corto y largo plazo para hacer frente a los futuros desafíos y amenazas a la seguridad, estabilidad y resiliencia del DNS, en concordancia con la misión técnica limitada de la ICANN, así como controlar el poder para mantener la estabilidad del DNS pero con los límites que esto conlleva. Recalcamos la necesidad de que el Plan Estratégico de ICANN refleje el compromiso con el objetivo y misión de ICANN de "preservar y mejorar la estabilidad operacional, confiabilidad, seguridad e interoperabilidad global de Internet." Es importante también que el SSR-RT no se centre exclusivamente en cuestiones físicas pues como se sabe, también existen otras amenazas que pueden afectar la estabilidad y seguridad del DNS. Esto debe estar enmarcado en un proceso de mejora continua no sólo para lo relacionado con SSR sino con toda la organización. Acordamos con el comentario de Ayesha Hassan cuando expresa que el equipo de revisión podría examinar la manera en que las mejores prácticas se incluirán en los contratos tal como se menciona en la Recomendación 12. Remarcamos la Recomendación 23 en cuanto a la necesidad de dotar a los Grupos de Trabajo y Comités Asesores, de recursos y ciertas libertades para poder desarrollar conclusiones de alta calidad. Para ello el RT debería planificar de qué forma creen que ICANN puede garantizar esta forma de trabajo. Acordamos con el comentario público de Mikey O'Connor en cuanto a la necesidad de agudizar el significado de "marco de gestión de riesgo" en el documento, y con el comentario de ALAC en cuanto a la necesidad de ICANN de acelerar la creación y publicación de un marco formal y completo de administración de riesgo del DNS. Es importante recalcar que en el objetivo de estar enfocados en los riesgos a largo plazo, no se olvide de prestar atención a los riesgos a corto plazo. El diseño del framework debe ser realizado por capas y desde una múltiple perspectiva para medir y administrar el nivel del DNS. Este marco debería soportar los análisis de riesgos, las probabilidades y el impacto de los cambios en la infraestructura del DNS así como también el cambio en la creación de políticas. Y apoyamos la Recomendación 28 a los fines de que ICANN siga comprometiéndose, en la planificación y prevención de incidentes, dando difusión y educación, involucrando a todas las áreas interesadas, para preservar el modelo de múltiples partes interesadas, con procesos de abajo hacia arriba, permitiendo también la participación de los usuarios finales especializados. El reporte hace referencia a la ausencia de un marco integral para la gestión de riesgos del DNS. Por lo que debemos pensar de qué manera se puede crear este marco formal con la actuación del SSAC, DSSA, Grupo de Trabajo de Gestión de Riesgos de la Junta, CSO y con la participación de los stakeholders especializados. *Juan Manuel Rojas - José Francisco Arce - Javier Pallero - Fatima Cambronero - AGEIA DENSI Capítulos Argentina y Colombia.*** ------ *SSR RT Draft Report – Public Comments* *These public comments are made on our individual capacity on behalf of Juan Manuel Rojas, Jose Francisco Arce, Javier Pallero and Fatima Cambronero of AGEIA DENSI Argentina and Colombia Chapters.* First, we want to congratulate the Security, Stability and Resilience Review Team for their enormous effort and we want to give a special acknowledgement to the RT Chair, Alejandro Pisanty, a member of our region. We would like to make special emphasis on the ordered and subject-specific presentation that provided for an issue with a high level of complexity to be easily understood by the community, by being presented in a logical, structured, and concatenated manner regarding each one of the recommendations. We support all of the recommendations that were made, and although there is not very much to add, we would like to state some comments in particular. We believe it is important that the RT started addressing the ICANN's technical limited mission. We believe it is necessary to develop a single document, with a clear terminology, where the definition and scope of SSR can be established, as one of the main objectives within the framework on the SSR Plan for FY12, incorporating the statement of responsibility for SSR as it was proposed by the RT. At the same time, we agree that the relationships between ICANN and other groups should be clear, as well as the relationships among RSSAC and SSAC, so in consequence, we support recommendations 1 to 6, since the only way for the procedures to be transparent and contributions be properly issued, is by providing a clear definition on the nature of relationships, as the Recommendation 3 has expressed. Thus, ICANN will reach for a greater number of stakeholders within the Internet ecosystem. We specially, as members of a regional organization of Internet users, suggest having particular regard to those who do not participate in ICANN. We agree on the need to have a defined plan as soon as possible in terms of SSR linkage to other communities within and outside of ICANN and the development of an efficient feedback mechanism on SSR work. We share the statement on posting information about DNS threats and mitigation strategies for them. It would be important to publicize the effectiveness of the current security plan that ICANN has established to face potential or actual challenges and threats; and what are the short-and long-term objectives to meet future challenges and threats to security, stability and resilience of DNS, consistent with the limited technical mission of ICANN, and to control the power to maintain stability of the DNS with the due limits that this entails. We stress the need for the ICANN Strategic Plan to reflect the commitment to its goal and mission stated as to "preserve and enhance the operational stability, reliability, security and global interoperability of the Internet". It is also important that the SSR-RT does not focus exclusively on “physical” issues given that, as we know, there are other threats that can affect the stability and security of DNS. This should be framed in a process of continuous improvement, not only on subjects related to SSR but with the entire organization. We agree with Ayesha Hassan's comment when she says that the RT could examine how best practices would be included in contracts as referred to in Recommendation 12. We stress Recommendation 23 regarding the need to provide Working Groups and Advisory Committees, of resources and certain freedoms in order to develop high quality conclusions. Because of this, the RT should plan how they believe that ICANN can guarantee this way of working. We agree with Mikey O'Connor's public comment regarding the need to sharpen the meaning of "risk management framework" in the document, and with ALAC's comment about the need for ICANN to accelerate the creation and publication of a formal and comprehensive framework for risk management of the DNS. It is important that the goal of focusing on long-term risks does not imply paying less attention to short-term risks. The framework design should be done in layers and from a multiple perspective to measure and manage the DNS level. This framework should support risk analysis, the likelihood and impact of changes in the DNS infrastructure as well as the changes in policy making. And we support Recommendation 28 for the purpose of ICANN to continue its engagement in the planning and prevention of incidents, providing outreach and education, involving all areas concerned to preserve the multi-stakeholder model, including bottom-up processes and also allowing the participation of specialized Internet end-users. The report refers to the absence of a comprehensive framework for risk management of the DNS. So we must think about how this formal framework ought to be created with the involvement of the SSAC, DSSA, Board DNS Risk Management Working Group, CSO and with the participation of specialized stakeholders. *Juan Manuel Rojas - Jose Francisco Arce – Javier Pallero - Fatima Cambronero - AGEIA DENSI Argentina and Colombia Chapters.* -- *Fatima Cambronero* Abogada-Argentina Directora de Investigaciones *AGEIA DENSI Argentina* http://ar.ageiadensi.org/ *@facambronero* *Join the LACRALO/ICANN discussions:* https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es