Resumen

  • RFC 2860 dejó constancia del memorando firmado por IETF e ICANN en marzo de 2000 sobre el trabajo técnico de IANA para protocolos de IETF e IRTF. Los RFC aportan primero los criterios; el IESG guía los casos ambiguos y el IAB resuelve determinados desacuerdos.
  • El texto excluye las cuestiones de política en la asignación de nombres de dominio y bloques de direcciones IP, pero conserva en su ámbito algunas asignaciones técnicas de esos espacios. También exige información pública, un canal de solicitudes, motivos técnicos para denegar, una vía de apelación y un preaviso de seis meses para la terminación unilateral.

Análisis

La diferencia entre una política y una asignación técnica determina qué parte de RFC 2860 se aplica. La sección 4.3 dice que las cuestiones de política al asignar nombres de dominio y bloques de direcciones IP quedan fuera del memorando. En la frase siguiente, sin embargo, mantiene dentro de la sección 4 los nombres usados para DNS inverso, bloques especializados de multicast o anycast y las asignaciones experimentales cuando no constituyen cuestiones de política. Por eso el documento no dice que todo el trabajo con nombres o direcciones quede excluido. Clasifica el tipo de problema antes de determinar la regla.

La clasificación importa porque el acuerdo establece una secuencia comprobable. Para parámetros de protocolos dentro del ámbito de IETF, la sección 4.1 indica que IANA asigna y registra conforme a los criterios y procedimientos de los RFC: estándares propuestos, preliminares o completos, prácticas recomendadas y cualquier otro RFC que solicite una asignación. Si no hay criterio o existe ambigüedad, IANA continúa la práctica tradicional salvo instrucción del IESG. Ante una duda o disputa técnica, solicita y sigue la orientación técnica del IESG; este puede nombrar un experto.

Las partes también contemplan desarrollar con el tiempo los criterios ausentes, que IANA adoptaría cuando así se lo indique el IESG.

El desacuerdo entre IANA e IESG tiene un escalón separado: la sección 4.2 remite a ambos al IAB, cuya decisión es final según el memorando. La sección 4.5 aborda las solicitudes y los rechazos. IANA debe ofrecer un medio en línea para que el público solicite parámetros y resolverlos con prontitud, ejecutando la asignación o denegándola por incumplimiento de los requisitos técnicos aplicables. El rechazo solo puede basarse en motivos técnicos legítimos. Para un registro creado por acción de IETF, la apelación puede ir al IESG y después al IAB. La norma define el itinerario; no informa de cuántas solicitudes siguieron cada paso.

La publicidad del registro aporta otra clase de control. La sección 4.4 exige que los datos de cada asignación vigente, incluidos los datos de contacto del titular, estén disponibles en línea y sin coste. Una asignación publicada en un RFC por el editor de RFC cuenta como publicada para este propósito. Con ello, quien implementa un protocolo puede consultar el valor registrado y la referencia que lo respalda. Pero encontrar una entrada no demuestra que una solicitud disputada haya sido aprobada ni que se haya aplicado en todos los sistemas.

El documento no reserva toda intervención a la relación entre quien solicita y quien registra. Según la sección 4.6, IANA puede tener puestos de enlace sin voto en los comités pertinentes que determine IETF y participar en debates sobre requisitos técnicos. La sección 4.7 le encarga revisar los documentos en Last Call de IETF y comunicar al IESG los problemas que detecte. Son vías para que la operación de los registros informe el diseño; no convierten a IANA en autora de los criterios que el texto atribuye a los RFC y a las instrucciones del IESG.

RFC 2860 también separa el trabajo de investigación. Su sección 5 aplica el procedimiento de la sección 4 a parámetros que correspondan principalmente a IRTF, sustituyendo IRTF e IRSG por IETF e IESG. Si no está claro de qué lado es un parámetro, el IAB decide la clasificación. La pregunta «¿qué institución opera?» se responde después de resolver «¿a qué ámbito pertenece el registro?», no al revés.

El contexto de publicación evita una lectura excesiva. RFC 2860 es Informational y declara que no especifica un estándar de Internet. El texto registra un memorando firmado por IETF e ICANN el 1 de marzo de 2000 y ratificado por el consejo de ICANN el 10 de marzo. Su propósito es definir exclusivamente el trabajo técnico de IANA para IETF e IRTF. A la vez, reconoce que ICANN puede prestar servicios similares a registros creados fuera de la acción de esas organizaciones.

El memorando podía modificarse o terminarse por acuerdo mutuo; cualquiera de las partes también podía cancelarlo con al menos seis meses de aviso. La cláusula importa como mecanismo de salida, aunque no prueba que se ejerciera. RFC 6220, de 2011, ofrece una descripción posterior de los operadores de registros de parámetros de IETF y dice que IETF mantiene la responsabilidad sobre esos parámetros. Sirve para entender la función del operador en ese documento posterior, no para afirmar que todos los arreglos de 2000 siguieron iguales.

Así, RFC 2860 distribuye criterios, registro, orientación técnica, revisión pública y apelación dentro de un ámbito delimitado. No demuestra que cada decisión cumpliera el procedimiento, cuál habría sido el resultado de un caso concreto ni quién decidía los asuntos de política que quedaron fuera. El propio límite es parte de la evidencia.

Fuentes

El documento principal es RFC 2860, Memorandum of Understanding Concerning the Technical Work of the IANA, en especial las secciones 1–5. La descripción posterior del papel de los operadores aparece en RFC 6220.