Actividades y reuniones de la Junta Directiva
Minutas | Reunión extraordinaria de la Junta Directiva de la ICANN 18 de mayo de 2013
Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: http://www.icann.org/en/groups/board/documents/minutes-18may13-en.htm
El 18 de mayo de 2013, se realizó una Reunión ordinaria de la Junta Directiva de la Corporación para la Asignación de Números y Nombres en Internet (ICANN) en Ámsterdam, Países Bajos, a las 2:00 pm, hora local.
El Presidente de la Junta, Steve Crocker, declaró abierta la sesión con puntualidad.
Junto al Vicepresidente de la Junta, los siguientes Directores participaron en la reunión, en forma total o parcial: Sébastien Bachollet, Fadi Chehadé (Presidente y Director Ejecutivo –CEO–), Bertrand de La Chapelle, Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vicepresidente), Judith Vazquez y Kuo-Wei Wu.
Los siguientes coordinadores de enlace de la Junta Directiva participaron en forma total o parcial de la reunión: Francisco da Silva, Coordinador del Grupo de Coordinación Técnica (TLG); Heather Dryden, Coordinador del Comité Asesor Gubernamental (GAC); Ram Mohan, Coordinador del Comité Asesor de Seguridad y Estabilidad (SSAC); Thomas Narten, Coordinador de la Fuerza del Trabajo en Ingeniería de Internet (IETF); y Suzanne Woolf, Coordinadora del Comité Asesor del Sistema de Servidores Raíz (RSSAC).
Los siguientes integrantes del personal participaron en forma total o parcial de la asamblea: John Jeffrey, Asesor Jurídico y Secretario; Akram Atallah, Director de Operaciones; Sally Costerton, Tarek Kamel, David Olive, Megan Bishop, Michelle Bright, Samantha Eisner, Dan Halloran, Denise Michel, Cory Schruth y Amy Stathos.
Jonne Soininen estuvo presente como invitado.
- Agenda convenida
- Agenda principal
- Sesión ejecutiva
-
Agenda convenida:
Antes de la introducción de la Agenda Convenida, el Presidente de la Junta y el Presidente y CEO agradecieron al personal por sus esfuerzos en la organización del taller.
El Presidente de la Junta presentó los temas de la agenda convenida y señaló que la solicitud de redelegación para .ID fue retirada de la agenda y también que el tema relacionado con el Subcomité del BGC (Comité de Gobernanza de la Junta) se trasladó a la agenda principal. Sébastien Bachollet prosiguió y Cherine Chalaby apoyó la siguiente resolución, y la Junta Directiva tomó la siguiente medida:
Queda resuelto, por la presente, se aprueban las siguientes resoluciones de esta Agenda convenida:
-
Aprobación de las minutas de la Junta Directiva
Queda resuelto (2013.05.18.01), la Junta Directiva aprueba las minutas de la reunión ordinaria de la Junta Directiva de la ICANN del día 13 de octubre de 2012.
-
Cronograma para la aprobación presupuestaria del FY2014 (año fiscal 2014)
Visto y considerando que, el Presupuesto FY2014 se encuentra actualmente publicado para la recepción de comentarios públicos, el cual cierra el día 20 de junio de 2013.
Que, por lo general la ICANN aprueba el presupuesto de cada año durante una de sus reuniones públicas.
Que, este año, la reunión de mitad de año de la ICANN será celebrada en Durban, Sudáfrica (del 14 al 18 de julio de 2013), y se realizará después del inicio del año fiscal 2014, que comienza el día 1 de julio de 2014.
Queda resuelto (2013.05.18.02), la Junta Directiva de la ICANN tiene la intención de aprobar el Presupuesto FY2014 durante la reunión pública que la ICANN celebrará en Durban, Sudáfrica.
Queda resuelto (2013.05.18.03), para el período de tiempo que comienza el día 1 de julio de 2013 hasta la fecha en que la Junta Directiva apruebe el Presupuesto FY2014, la Junta Directiva indica al Presidente y CEO que el funcionamiento de la ICANN responda de manera congruente al Presupuesto FY2014, publicado para la recepción de comentarios públicos.
Fundamentos de las resoluciones 2013.05.18.02 — 2013.05.18.03
De conformidad con los Estatutos de la ICANN, el presupuesto de un año determinado debe ser aprobado antes de finalizar el año fiscal anterior (30 de junio). Históricamente, esta aprobación ha tomado lugar en la última reunión pública de la ICANN del año fiscal (una reunión a mitad de año), que por lo general se programa a finales del mes de junio. Este año, la reunión de mitad de año se celebrará del día 14 al día 18 de julio de 2013, fecha que se sitúa en el siguiente año fiscal.
Se prevé que el foro de comentarios públicos sobre el Presupuesto FY2014 cierre el día 20 de junio de 2013. Como esa fecha está a sólo diez días previos al cierre del año fiscal, existe una limitación de tiempo para garantizar que todos los comentarios públicos sean revisados y considerados (incluyendo los posibles cambios al presupuesto preliminar que se incorporen posteriormente a examinar los comentarios públicos) antes de pasar el presupuesto a la Junta Directiva, para su consideración. Además, varios miembros de la comunidad de la ICANN han expresado su preferencia para que el presupuesto de cada año sea aprobado en una reunión pública de la ICANN.
Con el fin de permitir el tiempo suficiente para la revisión de los comentarios públicos presentados y para que la Junta Directiva examine los comentarios sobre el presupuesto, el personal recomendó al Comité de Finanzas de la Junta (BFC) que el presupuesto FY2014 sea aprobado por la Junta Directiva durante la reunión de Durban. El BFC estuvo de acuerdo y recomendó la Junta Directiva que resuelva la aprobación del Presupuesto FY2014 en Durban. Esta acción mejora la responsabilidad de la Junta Directiva para con la comunidad, ya que la Junta está respondiendo a los deseos de la comunidad para aprobar el presupuesto en una reunión pública, así como para garantizar que la Junta Directiva cuente con el tiempo suficiente para considerar los aportes de la comunidad antes de tomar una decisión sobre el Presupuesto FY2014.
Con el fin de permitir el funcionamiento de la ICANN durante el comienzo del FY2014, que inicia el día 1 de julio 2014 y hasta la fecha en que la Junta Directiva apruebe el presupuesto FY2014, la ICANN requiere de la autorización de la Junta. Por lo tanto, la Junta Directiva está autorizando al Presidente y CEO a dirigir la ICANN durante este período, de acuerdo con el Presupuesto FY2014 que ha sido publicado para la recepción de comentarios públicos. Esta acción permitirá a la ICANN mantener sus operaciones a la espera de la aprobación formal del Presupuesto FY2014.
La otra alternativa en este caso sería que la Junta Directiva tome una decisión antes del día 30 de junio de 2013 y fuera de una reunión pública. Esto no se consideró preferible bajo las circunstancias dadas.
Debido a que la demora en la aprobación del presupuesto está acompañada por una medida para permitir que las operaciones de la ICANN continúen, no se espera que la misma tenga un impacto significativo sobre las operaciones fiscales previstas de la organización o de la comunidad. Esta acción no tiene ningún impacto sobre la seguridad, la estabilidad ni la flexibilidad del DNS (Sistema de Nombres de Dominio).
Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN que no requieren de comentarios públicos.
-
Emplazamiento para la reunión de la ICANN en América del Norte, octubre 2014
Visto y considerando que, de conformidad con su política, la ICANN tiene intención de celebrar su tercera reunión de 2014 en la región de América del Norte, en forma alineada con la Resolución de la Junta Directiva del 20 de diciembre de 2012 sobre los emplazamientos de reunión en 2014.
Que, el personal ha completado una revisión exhaustiva de todos los emplazamientos de reunión disponibles en América del Norte y ha encontrado que Los Ángeles, California, es el más adecuado.
Que, el Comité de Participación Pública y Compromiso de Partes Interesadas de la Junta estuvo de acuerdo en la selección de Los Ángeles, California como el lugar donde celebrar la reunión de la ICANN que en 2014 se realizará en América del Norte.
Queda resuelto (2013.05.18.04), la Junta Directiva aprueba a Los Ángeles, California, como el sitio donde celebrar la reunión pública de la ICANN que en 2014 se realizará América del Norte, la cual está programada del 12 al 17 de octubre de 2014.
Queda resuelto (2013.05.18.05), se designa a la reunión pública de la ICANN que en 2014 se realizará en Los Ángeles como la Reunión anual de la ICANN de 2014.
Queda resuelto (2013.05.18.06), la Junta Directiva reafirma su resolución de fecha 20 de diciembre de 2012, la cual autoriza al Presidente y CEO a hacer todos los arreglos necesarios para llevar a cabo las reuniones de la ICANN en 2014, incluyendo todas las contrataciones y los desembolsos necesarios.
Fundamentos de las resoluciones 2013.05.18.04 — 2013.05.18.06
Tres veces al año, la ICANN celebra una reunión en diferentes regiones geográficas del mundo (conforme lo establecido en los Estatutos de la ICANN). La reunión ICANN51, programada del 12 al 17 de octubre de 2014, se realizará en la región geográfica de América del Norte. El personal identificó ubicaciones disponibles y adecuadas, y llevó a cabo un análisis exhaustivo de esos emplazamientos para asegurar que cumplan con los Criterios de selección para reuniones. Sobre la base de ese análisis, el personal recomendó que la reunión ICANN51 se realice en Los Ángeles, California.
La Junta Directiva examinó la recomendación del personal para celebrar la reunión en Los Ángeles, California, y determinó que la propuesta cumplía con factores fundamentales de los Criterios de selección para reuniones, utilizados como lineamiento en la labor de selección. El proceso de selección de este emplazamiento no requiere de consulta pública, debido a que la evaluación del personal sobre la viabilidad de cualquier sitio constituye la consideración principal.
Los emplazamientos para las reuniones de marzo de 2014 (Singapur) y junio de 2014 (Londres) han sido aprobados por la Junta Directiva el 20 de diciembre de 2012. Para obtener información comparativa, las instalaciones para la reunión y su presupuesto de producción en Singapur no ha de exceder los US$ 885.000 (ochocientos ochenta y cinco mil dólares estadounidenses), las instalaciones para la reunión y su presupuesto de producción en Londres no ha de exceder los US$ 734.000 (setecientos treinta y cuatro mil dólares estadounidenses), y la reunión de Los Ángeles cuenta con un presupuesto para instalaciones de reunión y producción que no exceda de los US$ 568,000 (quinientos sesenta y ocho mil dólares estadounidenses). Estas cifras no incluyen otros gastos relacionados con las reuniones.
Habrá un impacto financiero sobre la ICANN basado en la celebración de la reunión y el suministro de apoyo para viajes, según sea necesario; así también sobre la comunidad, al incurrir en los gastos de viaje para asistir a la reunión. Sin embargo, dicho impacto hubiese debido ser abordado, independientemente de la ubicación donde se realizase la reunión. No existe ningún impacto sobre la seguridad o la estabilidad del DNS como resultado de la celebración de estas reuniones.
Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.
-
Propuesta del ACDR para ser un proveedor de UDRP
Visto y considerando que, el Centro Árabe para la Resolución de Disputas de Nombres de Dominio (ACDR) presentó una propuesta a la ICANN para ser aprobado como un proveedor de UDRP (Política uniforme para la resolución de disputas de nombres de dominio).
Que, la propuesta del ACDR fue publicada el día 28 de septiembre de 2010 para la recepción de comentarios públicos y que el día 1 de marzo de 2013 se publicó una versión revisada que tuvo en cuenta los comentarios recibidos; el ACDR ha producido una nueva propuesta revisada abordando una última cuestión planteada en el foro público del 01 de marzo 2013.
Que, la propuesta revisada del ACDR cumple con los elementos sugeridos conforme lo establecido en la Información relativa al proceso de aprobación para los Proveedores de servicio de resolución de disputa.
Queda resuelto (2013.05.18.07), la Junta Directiva aprueba la solicitud del ACDR para convertirse en un proveedor de UDRP y recomienda al Presidente y CEO, a través de la Oficina del Asesoría Jurídica, que inicie conversaciones con el ACDR respecto al proceso para la provisión de servicios de UDRP por parte del ACDR.
Fundamentos de la Resolución 2013.05.18.07
La aprobación de la solicitud del ACDR por parte de la Junta Directiva pone fin a la labor del ACDR (en cooperación con el personal de la ICANN) para cumplir con las normas y los elementos del proceso de aprobación de los proveedores de la Política uniforme para la resolución de disputas de nombres de dominio ("UDRP"). Esto mejora la responsabilidad de la ICANN mediante la adhesión a sus procesos. En forma adicional, la aprobación del primer proveedor de UDRP localizado en Medio Oriente, mejora la responsabilidad de la ICANN para con la comunidad de Internet en general, mejorando la capacidad de elección para denuncias de UDRP.
La propuesta del ACDR fue publicada dos veces para la recepción de comentarios públicos. Todos los comentarios recibidos fueron suministrados al ACDR para su consideración. Algunos de los comentarios en oposición abordaron temas tal como el nivel de las tasas, lo cual está completamente dentro de las competencias del ACDR. Otros comentadores sugirieron que la ICANN desarrolle contratos con cada uno de sus proveedores de la UDRP como medio para exigir la uniformidad entre los proveedores. Nunca se han requerido contratos para los proveedores de la UDRP. Sin embargo, respecto a la cuestión de la uniformidad entre los proveedores, la propuesta del ACDR hace dos cosas: en primer lugar se han modificado aquellas áreas destacadas en el cuales se percibía el riesgo de una conducta no uniforme (por ejemplo, problemas con fechas de inicio y definiciones escritas); en segundo lugar, la propuesta ahora incluye un reconocimiento afirmativo de que si la ICANN impone requisitos adicionales a los proveedores, el ACDR cumplirá con tales exigencias; en tercer lugar, el ACDR ha revisado una parte específica de sus Reglas suplementarias, señaladas por los comentadores como potenciales riesgos para la uniformidad. Se trata de un avance positivo y ayuda a solucionar preocupaciones sobre la capacidad de la ICANN para identificar, en un futuro, aquellas áreas en las cuales debe exigir uniformidad de acción y el cumplimiento de las modificaciones que la ICANN eventualmente realice para mejorar la uniformidad entre los proveedores.
La consideración de la propuesta del ACDR por parte de la ICANN también señala la importancia de su responsabilidad para con la comunidad. Después de la solicitud de la comunidad para contar con la oportunidad de ver la propuesta nuevamente en forma previa a su aprobación, la Junta Directiva estuvo de acuerdo y pidió al personal que proceda con un período adicional de comentarios públicos. Además, la Junta Directiva también solicitó al personal informar a la comunidad respecto a cómo la ICANN arribó a su conclusión anterior en relación a las cuestiones uniformidad de los proveedores de UDRP. Como resultado, se ha elaborado un documento informativo que será divulgado públicamente.
Hay un impacto mínimo sobre los recursos de la ICANN como resultado de esta decisión, para asegurar que el personal de la ICANN esté disponible para trabajar con el ACDR en el inicio y mantenimiento de su labor como proveedor. No existe ningún impacto sobre la seguridad, estabilidad o flexibilidad del DNS, como resultado de esta decisión.
Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.
Todos los miembros de la Junta Directiva aprobaron las Resoluciones 2013.05.18.01, 2013.05.18.02, 2013.05.18.03, 2013.05.18.04, 2013.05.18.05, 2013.05.18.06 y 2013.05.18.07. Las resoluciones fueron aprobadas.
-
-
Agenda principal:
-
Asesoramiento del SSAC sobre los Certificados de nombres internos
Ram Mohan presentó un informe del trabajo del SSAC sobre los certificados de nombres internos —incluidos en el informe denominado SAC057—, a la Junta Directiva. En resumen, se señala que hoy en día existen muchos casos en los que se puede acceder al interior de una intranet —la intranet de una empresa—, y se puede simplemente escribir http dos puntos barra barra [insertar TLD] y obtener una intranet corporativa en su forma corta. No se necesita escribir el nombre completo o la dirección completa que en realidad fue asignada a la intranet. Varios de los nombres que se han solicitado en la ronda de nuevos gTLD son aquellos que pueden ser de este tipo. Hay actuales proveedores de SSL que ofrecerían un certificado de SSL válido para un nombre que simplemente no existe.
Podría haber un riesgo de colisión o enfrentamientos entre TLDs no asignados, nombres de dominio, así como nombres que ya están en existencia y en uso alrededor del mundo. Este es por supuesto un tema algo polémico, dado que estamos a mitad de camino o ya un poco adentrados en el proceso de nuevos gTLD. De modo que la recomendación del SSAC es iniciar un estudio que involucre datos reales, obteniendo datos reales por parte de los Operadores de servidores raíz, de los proveedores de certificados SSL... cotejar los datos, entrelazarlos, asignar al personal que trabaje con ello y también indicar al personal que trabaje con el RSSAC para que dicho Comité pueda ayudar con la coordinación con los servidores raíz. Además, la recomendación es de asignar al personal la tarea de consultar con el SSAC sobre este proceso, dado que el origen de este trabajo provino del SSAC. Por último, preguntar al SSAC —después de todo este análisis y después de que el estudio sea realizado—, si considera que necesita actualizar sus recomendaciones a la Junta Directiva.
El SSAC recomienda que este tipo de diligencia debe formar parte de la futura expansión del DNS. Hubo cierto debate interno dentro del SSAC sobre si aún necesitamos esta resolución, pero el proceso de pensamiento fue: 1. envía un mensaje de que la Junta Directiva y la ICANN están enfocadas en este tema y está tomando medidas deliberadas al respecto; y 2. hay un deseo de conseguir la cooperación desde dentro de la estructura de Organizaciones de apoyo y Comités asesores de la ICANN como desde afuera. Ram confirmó que este trabajo es sólo el principio; en función de los resultados del trabajo, si fuese indicado, podría existir la necesidad de considerar cómo manejar las cadenas de caracteres que se solicitaron a tal efecto y que podrían causar este tipo de colisión. El trabajo ordenado hoy ayudará a reunir los datos sobre este tema.
Suzanne Woolf confirmó que parte de este trabajo ya está en marcha, y señaló que esta labor constituye un precedente en la coordinación entre el SSAC, el RSSAC, el personal y los consultores. Existe mucho trabajo que ya está en curso.
Ray Plzak comparó este tema con la cuestión de las direcciones IP y las redes privadas, y le preguntó si había en marcha algún tipo de coordinación con la IETF. Ray señaló que en este momento podría ser prematuro, debido a que el tema continúa siendo delimitado pero, dependiendo de los resultados, la IETF tiene años de experiencia con este tipo de problemas desde el lado del direccionamiento IP.
Thomas Narten sugirió que la inclusión de un plazo claro en la resolución sería de gran ayuda, en parte para ayudar a comprender el cronograma para el despliegue de los nuevos gTLD.
Akram Atallah confirmó que la ICANN ya ha comenzado a delimitar el alcance de este trabajo y debería tener información oportuna sobre esto, y ofreció que a fines del mes de junio sería viable informar algunos de los resultados del estudio a la Junta Directiva.
Ram sugirió que también se podría incluir fechas para las otras partes del trabajo. El Presidente de la Junta recomendó que en lugar de colocar fechas específicas —lo cual no produce los mejores resultados—, se incluya que la Junta Directiva reconoce la urgencia y sensibilidad en este asunto, y que solicita los más altos niveles de atención a este respecto.
George Sadowsky señaló que este trabajo muestra la importancia del SSAC en la identificación de posibles problemas de seguridad y en ayudar a trabajar sobre ellos y recomendar nuevas medidas.
Bruce Tonkin sugirió que sería útil colocar algunos de los datos recabados mediante las diversas encuestas a disposición de otros.
Akram confirmó que tenía entendido que los datos estarían disponibles al público, aunque la publicación no siempre se identificase a las fuentes. El Presidente de la Junta señaló que esto permitirá que el análisis del SSAC conforme datos públicamente disponibles, lo cual es bueno.
Suzanne expresó que la credibilidad sobre los resultados es muy importante, y que el principio enunciado debe ser claro para todos.
Ray destacó la importancia de contar con un plan claro para la recolección de datos, a los fines de garantizar que se está recabando la información correcta. Ram confirmó que el SSAC traerá fuentes externas como algo necesario para garantizar que se recopilen los datos correctos. El Presidente de la Junta confirmó que esto es un detalle operacional que se dejará para ser diseñado por el personal.
El Presidente de la Junta agradeció al SSAC y al RSSAC por la iniciativa en este asunto, y confirmó que la Junta Directiva continuará monitoreando este trabajo. El Presidente de la Junta pidió una actualización en la próxima reunión.
La Junta Directiva tomó las siguientes medidas:
Visto y considerando que, la delegación de TLDs en una manera que promueva la seguridad y una buena experiencia de usuario constituye un tema de importancia de larga data para la Junta Directiva de la ICANN y la comunidad de Internet a nivel mundial.
Que, el día 15 de marzo de 2012, el Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN publicó el documento SAC057: Asesoramiento del SSAC sobre los Certificados de nombres internos.
Que, las empresas tienen entornos locales que podrían incluir fuertes supuestos respecto a cuáles dominios de nivel superior existen en el nivel raíz del DNS público, y/o han introducido dominios locales de nivel superior que pudiesen entrar en conflicto con nombres aún no delegados a nivel raíz del DNS público.
Que, en su rol de administrador, la ICANN desea determinar cuáles son estos potenciales enfrentamientos.
Queda resuelto (2013.05.18.08), la Junta Directiva indica al Presidente y CEO que, en consulta con el SSAC, encargue un estudio sobre el uso de los TLDs que actualmente no han sido delegados en el nivel raíz del DNS público en las empresas. El estudio deberá tener en cuenta los posibles impactos en la seguridad de las cadenas de caracteres de nuevos gTLD en relación a este uso.
Queda resuelto (2013.05.18.09), la Junta Directiva solicita al RSSAC que ayude a la ICANN con la recolección de datos y observaciones relacionadas con las operaciones del servidor raíz que sean relevantes para el estudio, y que trabaje con los operadores de servidores raíz para permitir el intercambio de tales datos y observaciones, según proceda, de la manera más oportuna posible.
Queda resuelto (2013.05.18.10), la Junta Directiva indica al Presidente y CEO contactarse con el foro de Autoridades de Certificación/Navegadores para recopilar estadísticas sobre la distribución de los certificados de nombres internos de dominios de nivel superior, de la manera más oportuna posible.
Queda resuelto (2013.05.18.11), la Junta Directiva solicita al SSAC que considere ofrecer asesoramiento adicional sobre la base de su evaluación respecto a los problemas identificados en el estudio de la ICANN, de la manera más oportuna posible.
Fundamentos de las resoluciones 2013.05.18.08 — 2013.05.18.11
¿Por qué la Junta está abordando el tema ahora?
La cuestión del certificado interno identificado por el SSAC en el documento SAC057 es un síntoma de que las empresas tienen entornos locales que incluyen fuertes supuestos sobre la cantidad estática de dominios de nivel superior y/o han introducido dominios locales de nivel superior que pudiesen entrar en conflicto con nombres aún no delegados. Independientemente de si estos supuestos son válidos o no, para ser proactiva en su rol de administración, la ICANN desea determinar qué consecuencias tienen estos posibles conflictos para la seguridad y la estabilidad, especialmente porque las solicitudes de nuevos gTLD se encuentran en proceso de ser evaluadas por la ICANN para ser delegadas en la raíz. Este estudio también establece un precedente para posibles futuras rondas de TLD, las cuales podrían necesitar realizar estudios similares en carácter de la debida diligencia.
¿Cuáles son las propuestas que se están considerando?
La Junta Directiva indica al Presidente y CEO que encargue un estudio sobre el uso de los TLDs que actualmente no han sido delegados en el nivel raíz del DNS público en las empresas. El estudio también considerará los posibles impactos de las cadenas de caracteres solicitadas como nuevos gTLD sobre la seguridad, en relación con este uso. Una vez cumplido con este estudio, la Junta Directiva también está considerando solicitar al RSSAC que ayude a los operadores de raíz en la prestación de algunas estadísticas y observaciones. Por último y sobre la base de su análisis respecto al estudio, la Junta Directiva está considerando solicitar al SSAC que evalúe si tiene asesoramiento adicional para presentar a la Junta Directiva.
¿A qué partes interesadas u otros se consultó?
En Beijing, el SSAC presentó a la comunidad el documento "SAC057: Asesoramiento del SSAC sobre los Certificados de nombres internos". Como resultado, el SSAC recibió retroalimentación por parte de la comunidad sobre este tema y sus aportes ofrecieron información respecto a la solicitud del SSAC.
¿Qué preocupaciones o inquietudes fueron planteadas por la comunidad?
Algunos miembros de la comunidad han expresado su preocupación por el uso de dominios de TLDs que actualmente no están delegados en el nivel raíz del DNS público, y su impacto en las empresas cuando la ICANN delegue tales TLDs al DNS público. Algunos han solicitado una evaluación de esos riesgos para que la comunidad de la ICANN pueda tomar decisiones informadas. Algunos han dicho que sus estudios no muestran ningún riesgo significativo para la seguridad y la estabilidad del DNS, y han exhortado a la ICANN para continuar el curso de la evaluación y eventual delegación de todas las solicitudes de gTLD exitosas, independientemente de los conflictos debido a los certificados de nombres internos.
¿Qué materiales significativos revisó la Junta Directiva?
Informe del SSAC sobre los Certificados de nombres internos1 [PDF, 1.14 MB], Informe del SSAC sobre Consultas inválidas de TLD a nivel raíz del DNS (15 de noviembre de 2010 con correcciones)2 [PDF, 507 KB], Informe del SSAC sobre Ampliación de la raíz (6 de diciembre de 2010)3 [PDF, 175 KB]
¿Qué factores considera importantes la Junta Directiva?
Al tomar esta medida, la Junta Directiva examinó las recomendaciones del SSAC en sus documentos SAC045, SAC046 y SAC057.
¿Se observan impactos positivos o negativos en la comunidad?
La medida de la Junta Directiva indicando al personal —a través del Presidente y CEO— encargar un estudio detallado sobre los riesgos relacionados con el uso de TLDs que actualmente no están delegados a nivel raíz del DNS público en empresas ofrecerá un impacto positivo sobre la comunidad, ya que mejorará el entendimiento sobre esta cuestión al suministrar información relacionada con los impactos de las cadenas de caracteres solicitadas como nuevos gTLD sobre la seguridad, en relación con este uso. Esto permitirá a la comunidad y a la Junta Directiva entender con más detalle los posibles problemas de seguridad y estabilidad en caso de delegarse los TLDs que están en conflicto, así como el impacto que tendrían sobre la funcionalidad global de Internet.
¿Existen impactos o ramificaciones fiscales sobre la ICANN (plan estratégico, plan operativo, presupuesto); sobre la comunidad y/o el público?
No se espera que esta medida tenga algún impacto sobre los recursos de la ICANN, y la indicación de realizar este trabajo podría resultar en cambios de implementación para los nuevos gTLDs. Mientras que el estudio no tendrá un impacto fiscal sobre la ICANN, la comunidad o el público, es posible que el estudio pueda revelar riesgos que conlleven a exigencias de establecer medidas de protección especiales para los gTLDs que tienen conflicto. También es posible que algunos de los nuevos gTLD no puedan ser elegibles para ser delegados.
¿Se observa alguna cuestión de seguridad, estabilidad o flexibilidad relacionada con el DNS?
El documento SAC057 ha identificado varios riesgos para la seguridad del DNS. Este estudio tiene la intención de ofrecer una visión más cuantitativa del problema, y de proporcionar información que pueda fundamentar las decisiones futuras.
Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos. Sin embargo, es probable que las recomendaciones que surjan de la labor indicada a través de la presente resolución necesiten aportes de la comunidad antes de ser consideradas por la Junta Directiva.
Todos los miembros de la Junta Directiva aprobaron las resoluciones 2013.05.18.08-2013.05.18.11. Las resoluciones fueron aprobadas.
-
Solicitud presupuestaria del SSAC
Ray Plzak presentó la moción y Mike Silber secundó la siguiente resolución propuesta.
Luego George Sadowsky presentó el tema, señalando que había algunas solicitudes presupuestarias de la comunidad que no podían esperar hasta la aprobación del presupuesto anual completo. Una de esas solicitudes era la del SSAC, y no fue presentada para aprobación con un grupo anterior de solicitudes de la comunidad. Sin embargo, el Comité de Finanzas de la Junta considera que esta solicitud para viajes de miembros del SSAC a la reunión de Durban es razonable y debe ser aprobada, y esa es la recomendación para la Junta Directiva.
El Presidente de la Junta señaló que hay una estructura de organizaciones de apoyo (SO) y comités asesores (AC) dentro de la ICANN, y que cada uno ofrece diferentes funciones y objetivos dentro de dicha Corporación. Particularmente entre los comités asesores, cada grupo es muy diferente entre sí. Como resultado de ello, es difícil establecer fórmulas en el manejo de este tipo de solicitudes, así como para tratar a cada AC como si fuese igual a los demás. Es importante que el rol de cada AC sea considerado como parte de las solicitudes presupuestarias, así como el valor de la función y el tiempo que cada comité asesor aporta. En este caso, el SSAC está compuesto por expertos independientes que asesoran a la ICANN sobre la seguridad y la estabilidad, y ese es un asunto altamente prioritario para la ICANN.
La Junta Directiva tomó las siguientes medidas:
Visto y considerando que, el 11 de abril de 2013, la Junta Directiva aprobó las solicitudes presupuestarias de SO/AC mediante un proceso expeditivo para su inclusión en el Presupuesto FY2014.
Que, en ese entonces la Junta Directiva no aprobó una solicitud del SSAC relacionada con viajes adicionales a la reunión que la ICANN celebrará en Durban.
Queda resuelto (2013.05.18.12), por la presente la Junta Directiva aprueba la solicitud del SSAC por el importe de US$20.000 (veinte mil dólares estadounidenses) como adicional para viajes a la reunión que la ICANN celebrará en Durban, para que la misma sea incluida en el presupuesto del año fiscal 2014 de la ICANN, como parte de las solicitudes presupuestarias expeditas de SO/AC.
Todos los miembros de la Junta Directiva aprobaron la resolución 2013.05.18.12. La resolución fue aprobada.
Fundamentos de la Resolución 2013.05.18.12
El Proceso de solicitud presupuestaria adicional expedita de SO/AC que conlleva a la aprobación presupuestaria en forma más temprana a lo usual constituye un ajuste razonable para las actividades que comienzan cerca del inicio del FY2014. Este ligero acrecentamiento para el proceso y calendario establecidos para la aprobación presupuestaria de la ICANN facilita la labor de la comunidad y del personal de la ICANN, y no genera gastos adicionales.
Por recomendación del Comité de Finanzas de la Junta, y a la luz del rol específico que desempeña el SSAC dentro de la ICANN, esta decisión es importante para el trabajo relacionado con la seguridad, estabilidad y flexibilidad del DNS, aunque no se espera ningún impacto directo sobre la seguridad, estabilidad o flexibilidad del DNS como resultado de esta decisión.
Esta medida forma parte de las funciones administrativas y organizacionales de la ICANN, para la cual se recibieron comentarios públicos.
-
Solicitudes de reconsideración para Subcomité del BGC relacionado con nuevos gTLD
Bruce Tonkin presentó el tema y señaló que en todos los asuntos, los miembros de la Junta Directiva tienen la obligación continua de identificar posibles conflictos y divulgarlos. En cuanto al Programa de Nuevos gTLD, también existe el Comité del Programa de nuevos gTLD, que es una manera de trazar una línea brillante alrededor de aquellos miembros ante los cuales se han determinado conflictos de interés reales o potenciales en relación al Programa. Algunos de los miembros del Comité de Gobernanza de la Junta (BGC), que escucha y recomienda a la Junta Directiva sobre las Solicitudes de reconsideración para la Junta, no forman parte del Comité del Programa de nuevos gTLD. Ahora que hay solicitantes que no están satisfechos con los resultados del Programa de nuevos gTLD, ellos están empezando a traer Solicitudes de reconsideración, y se espera que esto continúe. Como resultado, el BGC puede tomar cada Solicitud en una base de caso por caso para determinar los conflictos, o bien se puede conformar un subcomité a partir de los miembros del BGC que sean miembros del Comité del Programa de nuevos gTLD, y que sea el grupo base de miembros que escucharán las Solicitudes relacionadas con los nuevos gTLD. Existe la preocupación de que el hacer una determinación caso por caso podría ser una carga, dado las sensibilidades respecto a los tiempos de respuesta a las Solicitudes de reconsideración. Como resultado, el BGC recomienda utilizar un Subcomité para este propósito. La Subcomité tendría la oportunidad de incorporar a otros miembros de la Junta Directiva que tengan conocimientos especializados sobre ciertas cuestiones, si corresponde. Como las recomendaciones del BGC se divulgan públicamente, también podría existir una oportunidad para posteriores aportes, antes de que la Junta Directiva o el NGPC (Comité del Programa de nuevos gTLD) tomen una decisión respecto a una Solicitud de reconsideración determinada.
Ray Plzak preguntó acerca de los requisitos de quórum y el tamaño óptimo del Subcomité. Ray señaló la preocupación de que si el Subcomité es de tres miembros y sólo dos fueran necesarios para lograr el quórum, eso sólo representaría a dos de los seis miembros del BGC, lo que podría plantear cuestiones de óptica.
El Asesor Jurídico y Secretario confirmó que el BGC podría recomendar el tamaño óptimo. La recomendación aquí es sea conformado con miembros del BGC.
Bruce confirmó que el BGC sólo busca la aprobación de la Junta Directiva para la formación del Subcomité en este momento; sin embargo, aún no está nombrando a los miembros de dicho Subcomité de modo que esas cuestiones podrían discutirse más adelante.
George Sadowsky señaló que no ve la necesidad de crear un Subcomité, ya que una cuestión que podría plantearse en una Solicitud de reconsideración sería que uno de los miembros excluidos en realidad no tiene un conflicto. Por defecto se debería permitir una recusación cuando existe un conflicto y no que el conflicto sea predeterminado.
Bruce confirmó que se está creando una situación de opción de ingreso (opt-in) en lugar de una situación de opción de salida (opt-out). Sería un comité permanente que se pueda convocar con una antelación breve y que a veces sería necesario para las Solicitudes de reconsideración. Ahora, todo el BGC debe recibir notificación y participar en una reunión y luego determinar los conflictos, lo que requiere de mucho tiempo. Esta es una medida de eficiencia, como el NGPC.
George señaló que esto es diferente del NGPC, el cual cubre una amplia gama de cuestiones. Las Solicitudes de reconsideración son de óptica individual.
Bruce confirmó que en ningún momento hay una suposición de que todos los presentes en el NGPC no tienen conflicto respecto a un tema en particular; la determinación del conflicto debe hacerse cada vez, al igual que con los elementos frente a la Junta Directiva.
Olga Madruga Forti señaló que puede haber eficiencias a partir del subcomité, y que es importante para todos en la Junta Directiva que las decisiones sean tomadas sin ninguna sugerencia de conflicto de interés. La posibilidad de que directores con conflictos de interés puedan ofrecer su pericia parece poner esto en duda, por lo cual Olga pidió más información sobre este proceso.
Bruce confirmó que podría haber situaciones en las cuales un director en realidad no tenga ningún conflicto de interés respecto a un tema y entonces podrían participar. Del mismo modo, si un director tiene un conocimiento específico en un área, podría ofrecer asesoramiento sobre esa área a la Junta Directiva. Va de una estructura opt-in versus una estructura opt-out.
El Presidente de la Junta señaló que una de las preocupaciones podría ser que la invitación a un director interesado debido a su pericia sólo responda al ímpetu del Subcomité o de la Junta Directiva. Podría resultar útil ofrecer un mecanismo para que el director auto-identifique su área de especialización.
Bertrand de La Chapelle señaló que queda claro que la Junta Directiva está tratando de hacer lo correcto y ejemplificar el buen comportamiento. Pero esto también plantea cuestiones administrativas de quórum y tiempo y eficiencia. Bertrand entendió la posición de George, respecto a que los conflictos relativos a las Solicitudes de reconsideración que plantee el Programa de nuevos gTLD podrían ser diferentes de los conflictos que en general se relacionan con el Programa. La Reconsideración en sí misma requiere la toma de decisiones sobre una base caso por caso, y la estructura de opt-out posiblemente sea el mejor camino a seguir. También existe la posibilidad, sugerida por Ray, que las cuestiones de quórum mezcladas con cuestiones de conflicto específicas, podrían generar que nadie pueda escuchar la Solicitud de reconsideración. Si en última instancia se elige un enfoque de opt-in, podría mejorarse ofreciendo detalles específicos sobre el proceso que involucre la participación de expertos, que Bruce estaba planteando.
Luego, la Junta Directiva examinó algunas modificaciones propuestas para la resolución y Mike Silber planteó la preocupación de que esta cuestión debería regresar al BGC, en contraposición a editar una resolución sobre la marcha.
Los miembros de la Junta Directiva estuvieron entonces de acuerdo en que sería apropiado que el BGC ofreciese más aportes sobre este tema y que la votación sobre la resolución propuesta no ocurriese en este momento.
-
Otros asuntos
La Junta Directiva recibió un breve informe del Presidente y CEO en relación con la idea de la creación de algunos Grupos asesores presidenciales sobre temas específicos que pudiesen ayudar a elaborar directrices sobre cuestiones estratégicas que enfrenta la organización. Este tema aún se encuentra en su etapa de formación, y el Presidente y CEO estuvo de acuerdo en consultar con los miembros interesados de la Junta para ayudar a guiar y enmarcar la labor de estos comités. El Presidente y CEO también informó a la Junta Directiva sobre el desarrollo de un proceso para la identificación de una aprobación para viajes de la Junta necesarios fuera de las reuniones de la ICANN y talleres de la Junta Directiva, así como el uso del proceso de Oradores expertos de la ICANN.
-
-
Sesión ejecutiva
La Junta Directiva celebró una sesión ejecutiva en la que no participó el personal. Durante su sesión ejecutiva, la Junta Directiva tomó las siguientes medidas:
-
Compensación en riesgo del CEO
Visto y considerando que, cada miembro de la Junta Directiva ha confirmado no tener conflictos de interés respecto al establecimiento del importe de pago para la compensación en riesgo del Presidente y CEO, correspondiente al segundo trimestre de FY13.
Que, Comité de Compensaciones recomendó a la Junta Directiva aprobar un pago al Presidente y CEO para su compensación en riesgo, correspondiente al segundo trimestre de FY13.
Queda resuelto (2013.05.18.13.C01), la Junta Directiva aprueba un pago al Presidente y CEO para su compensación en riesgo, correspondiente al segundo trimestre de FY13.
Queda resuelto (2013.05.18.14), "elementos específicos de esta resolución se mantendrán en absoluta confidencialidad por tratarse de una "acción relativa al personal o a cuestiones laborales", de conformidad con la Sección 5.2 del Artículo III de los Estatutos de la ICANN.
Justificación de la Resolución 2013.05.18.xx
Cuando el Presidente y CEO fue contratado, se le ofreció un sueldo base, más un componente en riesgo dentro de su paquete de compensación. En congruencia con todo el personal de la ICANN, el Presidente y CEO es evaluado respecto a los objetivos específicos establecidos en coordinación con la Comisión de Compensaciones.
En Beijing, el Comité de Compensaciones recomendó que la Junta Directiva apruebe un pago al Presidente y CEO para su compensación en riesgo, correspondiente al segundo trimestre de FY13 y la Junta Directiva está de acuerdo con esta recomendación.
Mientras que esto tendrá un impacto fiscal sobre la ICANN, es un impacto que ha sido contemplado dentro del presupuesto FY13. Esta decisión no tendrá ningún impacto sobre la seguridad, estabilidad y flexibilidad del DNS.
Esta decisión forma parte de las funciones administrativas y organizacionales de la ICANN que no requiere de comentarios públicos.
-
Resolución Confidencial
[Resoluciones ocultas]
Queda resuelto (2013.05.18.18), los elementos específicos de esta resolución [resoluciones 2013.05.18.15, 2013.05.18.16 y 2013.05.18.17] se mantendrán en absoluta confidencialidad por tratarse de una "acción relativa al personal o a cuestiones laborales", de conformidad con la Sección 5.2 del Artículo III de los Estatutos de la ICANN, y toda la resolución tendrá carácter confidencial conforme a esta misma disposición estatutaria, hasta que el Presidente y CEO determine que la parte no confidencial puede ser divulgada públicamente.
Fundamentos de las resoluciones 2013.05.18.15 — 2013.05.18.18
[Fundamentos ocultas]
-
1 Véase http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf [PDF, 1.14 MB]
2 Véase http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf [PDF, 507 KB]
3 Véase http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf [PDF, 175 KB]