Skip to main content

Implementación de Referencia con Código Abierto de un Servidor REST de Whois para Nombre de Dominio – Respuestas a las Preguntas sobre la Solicitud de Propuestas [RFP]

Esta página está disponible en:

Las respuestas esta Solicitud de Propuestas [Request For Proposals – RFP] podrán enviarse a: rws-opensource@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 15 de junio de 2012.

Las siguientes 26 preguntas fueron enviadas a rws-opensource@icann.org entre el 16 de mayo y el 5 de junio de 2012. Todas las preguntas y respuestas se publicarán en el sitio web de la ICANN para beneficio de quienes presentarán sus respuestas.

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

Requisitos

Pregunta: La sección "Requisitos" de la RFP contiene el siguiente enlace: http://tools.ietf.org/id/weirds. En dicha URL, se enumeran algunos documentos que no guardan estricta relación con el modelo clásico de Whois para nombres de dominio de alto nivel (TLD), el cual suele permitir consultas sobre registradores, dominios, hosts y contactos en el repositorio local de objetos del registro). En particular, el draft-fiorelli-weirds-rws se refiere a la base de datos RIPE; en cambio, el draft-newton-et-al-weirds-rir-json-response y el draft-newton-et-al-weirds-rir-query se refieren a los Registros Regionales de Internet (RIRs); el draft-newton-weirds-arin-whoisrws se refiere al Whois de ARIN; y el draft-lacnic-weirds-restwhois-redirects aborda el redireccionamiento desde un servidor global de Whois. Con respecto a los requisitos de la RFP, ¿podríamos entonces suponer que únicamente los documentos restantes (draft-designteam-weirds-using-http, draft-kucherawy-weirds-requirements y draft-sheng-weirds-icann-rws-dnrd) – dos de los cuales son expresamente nombrados como referencias en la sección "Referencias" de la RFP – son relevantes como requisitos para la implementación de referencia? De no ser así, por favor indiquen cuales son los otros documentos incluidos en http://tools.ietf.org/id/weirds que también requieren un respaldo, junto con la razón de dicho requisito.

Respuesta: Si, el supuesto es correcto. El alcance esperado abarca únicamente registros de nombres de dominio.

Pregunta: El grupo WEIRDS está generando dos estándares de la IETF para requerir datos de Registros Regionales de Internet (RIR). Y TAMBIÉN estándares para consultar datos de registro de nombres de dominio. La implementación de referencia, ¿debe implementar todos los estándares antes mencionados o únicamente aquellos estándares relativos a los datos de registro de nombres de dominio?

Respuesta: Dado que existen solo cinco Registros Regionales de Internet (RIRs) y la mayoría de ellos ya está participando en WEIRDS, y se encuentran trabajando en sus propias implementaciones, nos estamos concentrando en el aspecto relativo a los nombres de dominio. Con más de mil registradores acreditados por la ICANN, potencialmente cientos de nuevos gTLDs, además de los ccTLDs existentes, y las restricciones de financiamiento, decidimos concentrarnos en la población principal de servidores.

Pregunta: La sección 2.4.4 indica que la implementación debería incluir un "proxy" de puerto 43 que utilice el Whois REST para responder a las solicitudes y que traduzca las consultas de puerto 43 y sus respuestas según corresponda. Si bien este es un enfoque posible, nuestra implementación actual del servidor de Whois incluye una implementación de puerto 43 que acceda "directamente" a la base de datos del servidor de Whois (es decir, no re-envía solicitudes/respuestas desde/hacia un frontend diferente), lo cual permite un desempeño de puerto 43 notablemente mejor. ¿Estaría bien que la implementación de referencia utilice este enfoque directo, en lugar de el enfoque de "proxy" que se describe en la RFP, siempre y cuando la implementación suministre un Whois de puerto 43 Whois que responda a la consultas de igual manera que en el modo "proxy"?

Respuesta: No. A los efectos de aclarar la respuesta, lo que buscamos es que todos los servicios principales tengan una base REST; luego de realizar un análisis y ver que algunos clientes aun pueden formular consultas vía puerto 43, queremos que el "proxy" del puerto 43 pueda traducir las solicitudes de estos clientes a consultas REST, y envíe el resultado vía puerto 43.

Pregunta: ¿La implementación de referencia debe servir tanto para gTLDs como para ccTLDs?

Respuesta: Correcto. Se espera que la implementación de referencia sea utilizable tanto para gTLDs como para ccTLDs.

Pregunta: Un servidor de WHOIS es básicamente un sistema de consultas a una base de datos. La base de datos es la recolección de información que un registro o registrador posee sobre los dominios, el lenguaje de consulta es el que acepte el servidor de WHOIS, y el resultado [output] se selecciona de la base de datos subyacente. ¿Qué contiene la base de datos, y que consultas soporta el lenguaje de consultas?

Si bien es posible intuir las respuestas a estas preguntas a partir de los apéndices de WHOIS provenientes de los acuerdos de registro de WHOIS extenso, los apéndices no siempre son los mismos. Por ejemplo, en el acuerdo de .INFO se especifican consultas con coincidencia parcial, mientras que ese no es el caso en el acuerdo de .BIZ. El registro .AERO tiene una campo de ENS_Authid, y rótulos de privacidad, mientras que .ASIA posee ENS_Authid, pero sin rótulos de privacidad. El acuerdo .XXX hace referencia a la información de DNSSEC, mientras este no es el caso para los acuerdos anteriores. El acuerdo .POST hace referencia a un campo de "Maintainer" en lugar de un campo de Correo Electrónico, como sucede en otros acuerdos. El acuerdo .NAME describe múltiples niveles de acceso y objetos de Registración Defensiva.

Entendemos que distintos registros continuarán teniendo requisitos parcialmente disímiles, pero, aparentemente, muchas de las diferencias entre los acuerdos derivan en mayor medida de la evolución del entendimiento de las necesidades, y no tanto de la diferencia entre decisiones deliberadas; por ejemplo, consultas parciales vs. consultas exactas, DNSSEC, y "Maintainer" vs. Correo electrónico. ¿Podría la ICANN brindar cierta orientación sobre los contenidos esperables en la base de datos subyacente y la clase de consultas que necesitan contar con soporte?

Respuesta: El contenido de la base de datos subyacente y las consultas que necesitan soporte quedan a consideración del órgano a cargo de formular las políticas del registro/registrador, tal como usted remarcó en su descripción anterior.

Es decir, esperamos que esta implementación de código abierto del RWS pueda abordar (ser configurable a tal fin) los campos para los cuales permite consultas.

Pregunta: La RFP no aclara la estructura del resultado [output]. ¿Hay alguna expectativa respecto de la secuencia de elementos de los datos? De ser así, ¿cuáles son esas expectativas?

Respuesta: Se espera que la estructura del resultado [output] sesté definida en el protocolo de la IETF. Actualmente, los Documentos de Internet citados en la RFP tienen una estructura para nombres de dominio.

Pregunta: ¿Hay algún requisito específico para el desempeño del sistema? Por ejemplo, ¿hay algún requisito mínimo de solicitudes por segundo según especificaciones concretas de hardware?

Respuesta: En este momento, contamos únicamente con los requisitos descriptos en la RFP. Estamos interesados en recibir las propuestas que los potenciales proveedores pudiesen presentar al respecto.

Pregunta: ¿Hay una lista específica de codificaciones con soporte para los datos de Whois que deban recibir soporte? Por ejemplo, ¿sería suficiente limitar las solicitudes y las respuestas a UTF-8, o debe haber soporte para una mayor cantidad de codificaciones? ¿Es posible que los datos del registro/registrador necesiten ser convertidos entre codificaciones?

Respuesta: Esto depende del protocolo, el cual todavía no fue definido. Anticipamos que sería necesario el UTF-8, pero también se podrá brindar soporte a otras codificaciones.

Pregunta: ¿Hay algún requisito mínimo respecto de los tipos de transmisión vía red que deben recibir soporte? Por ejemplo, la implementación de referencia, ¿podría implementar únicamente JSON, y luego permitir la incorporación de otros formatos, o debe brindar soporte para un conjunto mínimo de representaciones?

Respuesta: Al igual que con la pregunta sobre codificación, esto depende de los requisitos del protocolo.

Pregunta: ¿Hay un requisito mínimo para opciones de políticas? En la RFP se indica lo siguiente: "La implementación debe permitir la configuración del parámetro de opciones de políticas" pero esto es bastante amplio. ¿Hay ejemplos de las políticas que pueden ser requeridas? Por ejemplo, esto incluiría las políticas como limitación de solicitudes, filtro de respuestas, (es decir, detalles ampliados de solicitudes de Whois de parte de ciertos clientes), etc.?

Respuesta: Esperamos que haya opciones de configuración para la funcionalidad definida en las especificaciones del protocolo. No esperamos que se implemente algo que no esté definido en el protocolo. Sin embargo, esperamos que la implementación se realice en forma modular, para permitir que un registro/registrador interesado pueda hacer modificaciones con un mínimo esfuerzo si desea introducir una funcionalidad extra.

Pregunta: ¿Las pruebas de seguridad forman parte de los requisitos? De ser así, el contratista que desarrolle la implementación de referencia debe llevar a cabo dichas pruebas de seguridad?

Respuesta: Esperamos que la implementación final tenga código de calidad de producción. Por lo tanto, esperamos al menos un nivel básico de prueba de seguridad, propuesto por el contratista.

Pregunta: ¿Hay requisitos sobre la gestión integral del proyecto, o esto quedará a cargo del contratista? Por ejemplo, ¿dónde estará alojado el código? ¿Qué nos pueden indicar acerca de la emisión de flujos de trabajo de rastreo y desarrollo?

Respuesta: No. No hay requisitos al respecto, más allá de lo descripto en la RFP.

Pregunta: A los efectos de minimizar el trabajo de integración, en el documento de la RFP se incluye un ejemplo específico, según el cual las distintas capas podrían estar separadas, ver 2.4.2. en la RFP. ¿Están procurando una implementación modular, de manera que haya productos distintos para la presentación, lógica comercial/de negocios, y capa de acceso de datos que puedan utilizarse en conjunto o independientemente?

Respuesta: No los llamaríamos productos independientes, pero tendría sentido que estuviesen en módulos distintos o, al menos, sería bueno poder configurarlos por separado.

Pregunta: En cuanto a la configuración del parámetro según la sección 2.5. en la RFP, ¿la implementación debe ofrecer solo la posibilidad de configuración, o la CANN estaría dispuesta a considerar sugerencias, por ejemplo, una interfaz para configurar varias opciones que ya pudiera estar incluida en la implementación? ¿Podría ofrecerse esta posibilidad en un módulo adicional y optativo?

Respuesta: Estamos abiertos a recibir sugerencias.

Pregunta: El producto, la documentación y el soporte, ¿deben estar únicamente en inglés o deben incluirse más idiomas? En caso afirmativo, especificar.

Respuesta: Al menos en inglés, y sería fantástico tener la posibilidad de incluir otros idiomas.

Pregunta: La inclusión de un código de terceros (2.6.) puede derivar en costos impredecibles en cuanto a control de calidad y documentación. La ICANN estaría abierta a un modelo de costos que incluya este trabajo adicional sobre la base de tiempo y material? Lo mismo sería aplicable a la falta de especificación sobre la necesidad de lanzamientos según 2.2. o soporte.

Respuesta: Si. Estamos abiertos a recibir sugerencias. Sin embargo, a modo de aclaración, la idea de incluir un código de terceros es únicamente para el caso en el proveedor considere que tenga sentido utilizarlo (desde una perspectiva de costos) en lugar de realizar el trabajo desde el comienzo.


Plazo del Proyecto

Pregunta: ¿Cuál es el plazo del proyecto? En la RFP se especifica un período de soporte de un año; sin embargo, no se especifica ninguna expectativa sobre los plazos para que el grupo de trabajo genere la especificación final, ni tampoco se especifican expectativas de tiempo respecto de la entrega de la implementación inicial.

Respuesta: El plazo actual de la IETF indica que las especificaciones estarán listas en agosto de 2013; sin embargo, eso puede cambiar.

Pregunta: ¿Cuál es el plazo esperado entre los lanzamientos iterativos de las especificaciones y la entrega de los cambios al sistema?

Respuesta: No esperamos que el proveedor seleccionado implemente cada uno de los Documentos de Internet. Tenemos pensado reunirnos con el proveedor cada vez que consideremos que tiene sentido hacer un nuevo lanzamiento, y luego acordaremos el plazo y el alcance de la entrega con el proveedor.


Evaluación de la RFP y Contratación

Pregunta: ¿Quién estará a cargo de la revisión de la RFP? ¿Será un comité de selección?

Respuesta: Un comité de selección integrado por expertos técnicos estará a cargo de la revisión de la propuesta.

Pregunta: ¿Hay un monto presupuestado para el proyecto?

Respuesta: Contamos con una determinada partida presupuestaria para lo que queda de este año fiscal, y hemos solicitado una partida mayor para el próximo año fiscal. Nos gustaría evaluar las propuestas de los proveedores interesados.

Pregunta: ¿Cuál es el presupuesto total para el proyecto? ¿La ICANN está interesada en ofertas a precio fijo, o también estaría dispuesta a considerar un enfoque por etapas, en el cual primero se recaben y especifiquen los requisitos y luego se haga una estimación de costos, o se los presente sobre la base de los resultados de dicha interacción con la ICANN?

Respuesta: Nos gustaría evaluar las propuestas de los proveedores interesados. Estamos abiertos a recibir sugerencias.

Pregunta: ¿Hay formato contractual preferido, (Tiempo & Materiales, Precio Fijo, etc.)?

Respuesta: Estamos abiertos a ambos formatos, pero quizás un contrato de precio fijo sería una mejor opción para un lanzamiento, en contraposición a todo el proyecto, dada la variabilidad de los plazos.

Pregunta: En la sección "Evaluación y Otorgamiento" de la RFP se indica que el plazo exacto del otorgamiento puede depender del proceso de estandarización de la IETF. ¿De qué modo espera la ICANN que el plazo del otorgamiento dependa del proceso de la IETF? Específicamente, ¿es probable que el otorgamiento suceda dentro de aproximadamente un mes del plazo de respuesta de la RFP, o podría demorarse hasta noviembre de 2012 o agosto de 2013 (rango de fechas indicado en los hitos del Grupo de Trabajo WEIRDS WG)?

Respuesta: Nuestra intención es otorgar los contratos lo antes posible. Esperamos que los proveedores realicen lanzamientos antes de la publicación de las RFCs, una vez que se tengan especificaciones parcialmente estables y con las instrucciones previas de la ICANN.


Otras Preguntas

Pregunta: En la RFP se requiere que "el producto final cumpla con las RFCs relevantes que serán estandarizadas por el Grupo de Trabajo WEIRDS de la IETF." ¿La ICANN espera o requiere que el contratista forme parte del Grupo de Trabajo WEIRDS, o contribuya con esa agrupación, para garantizar que el proyecto de código abierto esté en consonancia con el Grupo de Trabajo?

Respuesta: No es requisito contribuir, pero sería sensato que el contratista al menos formara parte de la lista de intercambio de correos de WEIRDS.

Pregunta: La ICANN acaba de publicar una hoja de ruta para la implementación del documento SAC 051 (http://www.icann.org/es/news/announcements/announcement-6-04jun12-es.htm), en la cual se respalda la labor de la IETF sobre un nuevo protocolo, pero también se anticipan contribuciones de la comunidad de la ICANN, sobre todo de los registros y registradores de ccTLD y gTLD, y de la GNSO: "esta hoja de ruta recomienda un enfoque multisectorial para la adopción de un reemplazo del protocolo de WHOIS". El alcance del proyecto de implementación de referencia, ¿se limita a las especificaciones de protocolo que serán generadas por la IETF?

Respuesta: Si. Debe cumplir con las RFCs generadas en la IETF, pero también se espera que tenga calidad de producción.

Pregunta: ¿Es de esperar que los registros participen en el desarrollo y la evaluación del proceso?

Respuesta: Es probable que algunos registros/registradores participen, pero el proveedor seleccionado no debería dar esto por sentado.


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."