Skip to main content

Proveedor para las Pruebas Previas a la Delegación para los Nuevos gTLDs – Preguntas y Respuestas a la Solicitud de Propuestas (RFP)

Esta página está disponible en:

Las respuestas a esta Solicitud de Propuestas (RFP) deben enviarse al siguiente correo electrónico: pre-delegation-testing-bid@icann.org. El período para presentar preguntas sobre la RFP ya se encuentra cerrado. El período para presentar la respuesta final a la RFP vence el 20 de noviembre de 2012.

Las siguientes preguntas se presentaron entre el 30 de octubre y el 7 de noviembre de 2012. Todas las preguntas y respuestas se publicarán en el sitio web de la ICANN para beneficio de todos los que presentaron sus respuestas.

Las preguntas se clasifican según su similitud, o bien en grupos de preguntas que ameritan una misma respuesta.

El siguiente texto está basado en preguntas que se recibieron de parte de personas que posiblemente respondan a la RFP, y el mismo ha sido editado para brindar información neutral para todos los proveedores.

Pregunta 1: P. 16: ¿Qué es lo que la ICANN define específicamente como "las tres fases principales"?

Estas son tres partes diferentes que se encuentran definidas en la sección 2.2 ("Alcance").

Pregunta 2: ¿Se espera que también se evalúen las interfaces web que están dentro de cada sistema de registros?

La interfaz WHOIS debería ser evaluada de acuerdo a lo descrito en 2.3.4.1. La Guía para el Solicitante de Nuevos gTLD (AGB) establece que:

"La ICANN verificará que se pueda tener acceso a los datos WHOIS con IPv4 e IPv6 mediante el puerto 43 y mediante una interfaz web, y revisará la documentación de certificación propia con respecto a la capacidad de transacción WHOIS. La ICANN evaluará a distancia el formato de respuesta de acuerdo con la Especificación n.º 4 del acuerdo de registro y el acceso a WHOIS (desde el puerto 43 y la web) desde diversos puntos en Internet tanto con IPv4 como con IPv6."

Pregunta 3: ¿Habrá un recurso de la ICANN asignado para que, en caso que surgiesen preguntas, el proveedor para las pruebas previas le realice consultas durante las fases de diseño e implementación?

Sí.

Pregunta 4: La RFP indica que el proceso otorgará un contrato a "uno o más" proveedores, con lo cual los precios se verán afectados. ¿La ICANN puede brindar información adicional sobre este tema?

Tal como se encuentra solicitado en P.24, P.25 y P.26, los proveedores deberían proporcionar precios individuales para cada uno de los temas que se encuentran enumerados.

Pregunta 5: ¿Es necesario que las pruebas se realicen a cada Proveedor de Servicio de Registro Back-End, o a cada solicitante?

El proveedor para las pruebas previas a la delegación verificará que cada solicitante haya cumplido con su compromiso de establecer operaciones de registro, de conformidad con la Guía para el Solicitante de gTLD (AGB).

Pregunta 6: Dado que sólo se están solicitando 1400 cadenas de caracteres únicas, ¿aún así se espera que se realicen aproximadamente 2000 pruebas a un ritmo de 20 pruebas por semana?

Prevemos que se evalúen 1400 solicitantes a un ritmo de 20 pruebas por semana. Sin embargo, tengan en cuenta que también estamos solicitando que el proveedor pueda aumentar el ritmo a 100 pruebas por semana, en caso que esto fuese requerido por la ICANN.

Pregunta 7: ¿Pueden brindar una conclusión definitiva sobre la cantidad mínima de pruebas previas a la delegación que se anticipa que habrán?

En este momento, se desconoce la cantidad total de cadenas de caracteres que se solicitaron y que serán aprobados. Por lo tanto, no podemos confirmar la cantidad mínima de registros que deben ser evaluados, sino solo la máxima: 1400. Esperamos que la cantidad real de registros evaluados sea aproximada a este máximo.

Pregunta 8: La ICANN solicitó que el Software de las Pruebas Previas a la Delegación debe estar disponible para la ICANN en formato de código fuente, y puede que el mismo sea publicado por la ICANN como un Software de Código Abierto. Por favor, aclaren este requisito.

Cualquier limitación que pueda existir con la entrega del software o con la licencia proporcionada debería indicarse claramente en la oferta. Como mínimo, la ICANN solicita que se le otorgue una licencia no exclusiva, perpetua y gratuita para utilizar el software proporcionado para realizar las pruebas previas a la delegación.

Pregunta 9: ¿El "Software de las Pruebas Previas a la Delegación" refiere a todo el software que sea utilizado dentro del Sistema de Pruebas Previas a la Delegación o solo al software que sea utilizado para realizar las pruebas técnicas?

Refiere a todos los software que se utilizaron para brindar el Servicio de Pruebas Previas a la Delegación.

Pregunta 10: En la RFP se solicita que el Proveedor para las Pruebas Previas a la Delegación revise los documentos de certificación propia proporcionados por el operador de registro que este siendo evaluado. ¿La ICANN podría confirmar que esta revisión tiene por objeto garantizar la integridad, y no refleja pruebas adicionales para verificar evaluaciones propias?

El Proveedor para las Pruebas Previas a la Delegación debería revisar los documentos de certificación propia para verificar su integridad, verosimilitud y cumplimiento con las declaraciones específicas realizadas en la solicitud de gTLD.

Pregunta 11: Con respecto a los informes que serán generados por el Sistema de Pruebas Previas a la Delegación, ¿el Proveedor para las Pruebas Previas tiene que brindar un informe por cada solicitante o sólo un conjunto de informes uniformes de cada plataforma técnica de los proveedores de servicio de registro back-end?

Sí, se espera que los proveedores entreguen un informe de cada uno de los gTLD que hayan sido evaluados que refleje el estado de cumplimiento del operador de registro con respecto a los requisitos de Pruebas Previas a la Delegación.

Pregunta 12: ¿Las propuestas de solicitantes de gTLD o de Proveedores de Servicios de Registro Back-End y/o de Proveedores de Servicios del DNS que hayan sido contratados por solicitantes de nuevos gTLD serán descalificadas o penalizadas en este proceso de RFP?

La ICANN aceptará propuestas de solicitantes de nuevos gTLD y/o de Proveedores de Servicios de Registro Back-End de nuevos gTLD. Tal como se solicita en la P.3 y P.6, todos los conflictos de interés deberían ser declarados claramente por aquellos que respondan a la RFP. Un conflicto de interés no descalifica o penaliza automáticamente a nadie que responda a la RFP.

Pregunta 13: ¿La ICANN considerará a los Operadores de Registro Back-End de Emergencia (EBERO) como posibles Proveedores para las Pruebas Previas a la Delegación?

Sí.

Pregunta 14: En caso que el candidato para ser el Proveedor para las Pruebas Previas a la Delegación fuese el mismo solicitante para ser el Proveedor de Servicio de Registro Back-End, ¿éste puede verificar o evaluar sus propias especificaciones técnicas de conformidad con las directrices establecidas en la RFP, o existen otros métodos para tratar este tipo de situaciones? En caso que existan, por favor brinde una descripción detallada de las mismas.

Un Proveedor de Servicio de las Pruebas Previas a la Delegación no puede evaluar sus propias especificaciones o servicios de registro que le brinda a un solicitante ya que esto implica un conflicto de intereses.

Pregunta 15: ¿La ICANN permitiría un enfoque de dos proveedores para abordar las Pruebas Previas a la Delegación (es decir, un proveedor desarrolla el Software para las Pruebas Previas y aloja el Sistema de Pruebas, y el otro proveedor brindaría los Servicios de Pruebas Previas a la Delegación)?

Sí.

Pregunta 16: ¿La ICANN consideraría otorgar el contrato a un sólo proveedor que permita a) que funcionen las economías de escala y b) un modelo de evaluación uniforme para todos?

La ICANN prefiere contratar a un sólo proveedor. Sin embargo, está dispuesto a considerar a más de un proveedor en caso que esto fuese una mejor alternativa.

Pregunta 17: ¿Es posible realizar una única prueba por cada Proveedor de Servicio de Registro Back-End (ya que esto limitaría el requisito a unas 80 pruebas)?

La AGB especifica que se requiere una Prueba Previa a la Delegación por cada Operador de Registro (parte contratada de la ICANN).

Pregunta 18: ¿La ICANN considerará propuestas que abordan un subgrupo de las Pruebas Previas a la Delegación? Más específicamente: Dada su importancia y naturaleza técnica, ¿la ICANN consideraría aquellas propuestas que abordan únicamente los componentes del DNS y las DNSSEC de la RFP?

No.

Pregunta 19: ¿La ICANN tiene alguna inquietud con respecto a conflictos de intereses con otros servicios de evaluación de solicitudes que le hayan sido brindados como parte del Programa de Nuevos gTLD?

No.

Pregunta 20: P.26: Con respecto a la auditoría en sitio, ¿a cuántas personas se les requiere organizar una auditoría en sitio?

El Proveedor para las Pruebas Previas a la Delegación debería reunir un equipo que posea la capacidad necesaria para realizar una auditoría en sitio. Se prevé que se requerirá realizar sólo una pequeña cantidad de estas pruebas.

Pregunta 21: Por favor, ¿pueden aclarar los elementos de la auditoría que serán examinados durante la auditoría en sitio?

El Proveedor para las Pruebas Previas a la Delegación debería verificar el cumplimiento de los requisitos indicados en la sección 5.2 de la AGB y las declaraciones correspondientes realizadas en la solicitud de gTLD.

Pregunta 22: P.26: ¿La ICANN espera que la cantidad de pruebas que se estén realizando aumente de manera significativa a lo largo del período del contrato?

Se prevé que las Pruebas Previas a la Delegación se llevarán a cabo a un ritmo inicial de 20 pruebas por semana, con la posibilidad de aumentarlo a 100 por semana. Tal como se encuentra indicado en P.26(a), se debe brindar el precio por cada prueba.

Pregunta 23: R.6: ¿Es aceptable no implementar una autenticación mutua de los agentes de Pruebas Previas a la Delegación si el Proveedor de Pruebas Previas opera en un entorno con red interna y privada?

No, el Sistema de Pruebas Previas a la Delegación debería ser diseñado para operar en un entorno abierto (por ejemplo, a través de la red pública de Internet). La autenticación mutua y criptográfica son un requisito.

Pregunta 24: ¿El IPv6 es un requisito en el caso siguiente: "las pruebas deben realizarse a través del IPv4 y IPv6"?

Las pruebas deben realizarse a través del IPv6, cuando corresponda. Tenga en cuenta que algunos servicios (por ejemplo, el DNS y el WHOIS) deben ser brindados a través del IPv6 (tal como se encuentra requerido en la Especificación 6 del Acuerdo de Nuevo gTLD).

Pregunta 25: R.18: ¿Qué es el "Contrato de gTLD"?

El contrato de gTLD es el "Acuerdo de Nuevo gTLD" firmado.

Pregunta 26: R.19: ¿Cuáles son los contenidos de la nota al pie 1 que se encuentran ausentes?

http://www.iana.org/procedures/idn-repository.html

Pregunta 27: P.26(b) no se encuentra presentado correctamente.

"Una prueba del proceso de revelación del Agente de Custodia de datos. Se espera que la ICANN lo solicitará en el orden de 20 pruebas durante el período del contrato."

Pregunta 28: R.25: ¿La ICANN brindará un servidor raíz para la evaluación del Anclaje de Confianza de las DNSSEC?

No.

Pregunta 29: R.26: ¿Pueden brindar más detalles sobre los estándares de la Declaración de Políticas de las DNSSEC (DPS)?

De acuerdo a la sección 1.3 de la Especificación 6 del acuerdo base, la DPS debería cumplir con la siguiente Solicitud de Comentarios (RFC), describir un marco de la DPS (la cual se encuentra actualmente en su versión borrador https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/), y debe describir los controles fundamentales de seguridad y los procedimientos para almacenar material clave, obtener acceso y uso de sus propias claves, y deberá garantizar la aceptación del material público clave de los registrantes.

Pregunta 30: Preguntas sobre límites

  1. ¿Existe un límite de tiempo para que una solicitud apruebe la evaluación? ¿Cuál es el plazo requerido para que una solicitud complete las pruebas técnicas previas a la delegación del gTLD en la zona?
  2. Si la solicitud reprueba la prueba técnica la primera vez, ¿cuántas instancias adicionales tiene antes de que el procedimiento de las pruebas previas a la delegación sea cancelado?
  3. O, en caso que existan pruebas adicionales, ¿el Proveedor de Servicio de Pruebas Previas puede cobrar tarifas adicionales a la ICANN?

Los solicitantes deberían tener un plazo razonable de tiempo (el cual puede ser acordado entre el proveedor que sea seleccionado y la ICANN) para corregir cuestiones técnicas o para complementar la información que haya presentado. Si el solicitante no puede brindar la evidencia requerida dentro de este plazo de tiempo, la prueba debería ser considerada como reprobada.

Pregunta 31: P.5: ¿Hay información específica requerida sobre los subcontratistas enumerados?

Tal como se encuentra indicado en la P.15(a), aquellos que respondan a la solicitud deberían brindar una evaluación de conflictos de interés que esté basado en la actual lista de solicitantes de nuevos gTLD.

Pregunta 32: En caso que un operador de TLD repruebe un componente de la Prueba Previa a la Delegación, ¿pueden aclarar el grado de apoyo que se espera que el Proveedor para las Pruebas Previas a la Delegación le ofrezca al Operador de TLD, además de la opción de realizar una nueva evaluación?

Se espera que el Proveedor para las Pruebas Previas brinde al solicitante una respuesta descriptiva sobre cada prueba reprobada y le permita realizar correcciones dentro de un plazo de tiempo razonable (el cual será acordado entre el proveedor seleccionado y la ICANN) antes de considerar la prueba como reprobada por completo.

Pregunta 33: Dado que se requiere que se enumeren los nombres y direcciones unicast del IPv4/IPv6 de nodos anycast, ¿qué acciones desea la ICANN que se lleven a cabo si el operador de TLD, durante sus operaciones normales, no permite que sus servidores individuales en sus conjuntos de anycast sean alcanzables por cualquier dirección pública de IP que no sea de dirección anycast?

Si el operador de TLD no puede permitir consultas del Proveedor para las Pruebas Previas a la Delegación a las direcciones unicast de todos los nodos anycast, se requerirá al solicitante que presente una declaración que compense la accesibilidad para todos los nodos que no puedan ser evaluados.

Pregunta 34: ¿Pueden aclarar qué elementos de la auditoría deben ser considerados cuando se lleve a cabo la revisión de las pruebas de carga con certificación propia?

El Proveedor para las Pruebas Previas a la Delegación debería revisar los documentos de certificación propia para verificar su integridad, verosimilitud y cumplimiento con las declaraciones correspondientes que fueron realizadas en la solicitud de gTLD.

Pregunta 35: ¿La prueba del proceso de Publicación de Custodia de Datos está centrada en la publicación de un depósito existente de custodia de datos del agente de custodia de datos para la ICANN o para el Proveedor de las Pruebas Previas a la Delegación?

La prueba de publicación está enfocada en la publicación de depósitos del Agente de Custodia de Datos de gTLD para el Proveedor de Pruebas Previas a la Delegación.

Pregunta 36: Con respecto a lo establecido en 2.3.4.4 sobre la custodia de datos, ¿es un requisito verificar si la custodia de datos se encuentra en cumplimiento con los requisitos de un software específico?

No, el Proveedor para las Pruebas Previas a la Delegación debería validar el perfil de la custodia de datos y el formato de custodia de datos de un depósito completo y de un depósito de incremento gradual de custodia de datos. Por lo tanto, esta prueba no depende de un software específico.

Pregunta 37: R.24: ¿La indicación "verificar que los datos puedan ser publicados dentro de 24 horas" refiere a una revisión manual del Acuerdo de Nivel de Servicio (SLA) entre el Proveedor de Servicio de Custodia de Datos y el solicitante (proporcionado por el solicitante), o refiere a una prueba que debe ser realizada por el Proveedor para las Pruebas Previas a la Delegación con el objetivo de garantizar que los datos son publicados y devueltos conforme a los requisitos de Custodia de Datos?

En la mayoría de los casos, la ICANN sólo espera una revisión del SLA, pero en algunos casos podría solicitar que se verifique la capacidad de publicación real de cada Proveedor de Servicio de Custodia de Datos. Tal como se indica en la P.26, la ICANN lo espera en el orden de 20 pruebas durante el período del contrato.

Pregunta 38: ¿Sería aceptable evaluar únicamente los depósitos completos de Custodia de Datos?

No, en la AGB se requiere que se evalúen ambos depósitos, el completo y el de incremento gradual.

Pregunta 39: R.19 y R.20: Por favor, aclaren los requisitos para la verificación de la Tabla de IDN.

El objetivo principal es verificar que las capacidades de IDN de los solicitantes cumplen con aquellas descritas en las tablas de IDN que fueron proporcionadas. Si las tablas de IDN son proporcionadas en un formato de lectura electrónica que pueda ser leída con programas, el desempeño de dichas pruebas es muy simple. Pero la ICANN reconoce que podrían existir tablas de IDN en otros formatos, es decir, con más algoritmos complejos de generación variable.

Pregunta 40: R.13: A la interfaz del Protocolo de Aprovisionamiento Extensible (EPP), se le deben evaluar únicamente aquellos comandos del EPP que se encuentran enumerados?

No, la interfaz del EPP debería ser evaluado para analizar el cumplimiento de los estándares con respecto a los requisitos descritos en la sección 5.2 de la Guía para el Solicitante de gTLD, es decir, "verificar la conformidad con las RFC correspondientes (incluyendo las extensiones del EPP para las DNSSEC)".

Pregunta 41: R.18: ¿Se requiere de alguna prueba técnica para revisar las extensiones del EPP del solicitante?

No.

Pregunta 42: 2.3.4.1: ¿Existe algún requisito para evaluar la interfaz web de WHOIS mediante HTTPS?

Si la interfaz web de WHOIS es proporcionada mediante HTTPS, entonces debería ser evaluada a través de la misma.

Pregunta 43: P.26: ¿La "auditoría de la prueba de carga" refiere a una revisión manual de la documentación de certificación propia del solicitante, o refiere a pruebas reales que el Proveedor para la Pruebas Previas a la Delegación debe ejecutar de manera independiente para validar las declaraciones que realizó el solicitante?

P.26(c,d,e) refiere a pruebas técnicas de carga reales que debe llevar a cabo el Proveedor de las Pruebas Previas de Delegación. Se prevé que se requerirá realizar sólo una pequeña cantidad de estas pruebas.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."