Este sitio Web esta en Espanõl. Existe una lista de las traducciones: http://www.iab.org/discussions/iana-framework-evolution/.

The current version of this document can be found at http://tools.ietf.org/html/draft-iab-iana-framework; that page can also be retrieved protected by TLS at https://tools.ietf.org/html/draft-iab-ianaframework/. Este sitio Web esta en Espanõl. Existe una lista de las traducciones: http://www.iab.org/discussions/iana-framework-evolution/. Internet Architecture Board(IAB) IAB Internet-Draft O. Kolkman, Ed. Intended status: Informational NLnet Labs Expires: July 24, 2014 January 22, 2014 Resumen Marco para la evolución de IANA (Internet Assigned Numbers Authority) draft-iab-iana-framework-01 Este documento proporciona un marco para describir la administración de los registros de Internet gestionados por IANA. Define la terminología que describe las diversas funciones y las responsabilidades asociadas con la gestión de las funciones de registro de Internet. [InternetGovtech@iab.org es la lista que IAB estará monitoreando para el análisis de este proyecto. Vea http://www.iab.org/mailman/listinfo/internetgovtech para obtener detalles de suscripción] Estado de este memorándum Este Internet-draft se presenta en plena conformidad con las disposiciones de BCP 78 y BCP 79. Los Internet-draft son documentos de trabajo de la Fuerza de Tareas de Ingeniería de Internet (IETF). Tenga en cuenta que otros grupos también pueden distribuir documentos de trabajo como Proyectos de Internet. La lista de los actuales Proyectos de Internet se encuentra en http://datatracker.ietf.org/drafts/current/. Los Internet-draft son documentos preliminares válidos por un máximo de seis meses, y pueden ser actualizados, reemplazados o considerados obsoletos por otros documentos en cualquier momento. No es adecuado utilizar Internetdraft como material de referencia o citarlos, a menos que se lo haga como «trabajo en progreso». Este Internet-Draft vencerá el 24 de julio de 2014. Aviso de derechos de autor (Copyright) Copyright (c) 2014 IETF Trust y las personas identificadas como los autores del documento. Todos los derechos reservados. Este documento está sujeto a las disposiciones legales de BCP 78 y IETF Trust relativas a los documentos de la IETF (http://trustee.ietf.org/license-info) vigente en la fecha de publicación de este documento. Revise detenidamente estos documentos, ya que describen sus derechos y restricciones con respecto a este documento. Los componentes de código extraídos de este documento

deberán incluir el texto de la Licencia BSD Simplificada como se describe en la Sección 4.e de las disposiciones legales del Fideicomiso y se ofrecen sin garantía, como se describe en la Licencia BSD Simplificada. Índice 1. Introducción.......................... 2 1.1. Registros de Internet e interoperabilidad de Internet.... 2 1.2. La función de IANA y los registros de Internet....... 3 1.3. Un marco para IANA..................... 4 2. Funciones en relación con los registros de Internet...... 5 2.1. La función del desarrollo de políticas........... 5 2.2. Aspectos de la implementación............... 6 2.2.1. La función de la coordinación de evaluaciones..... 6 2.2.2. La función del mantenimiento y la publicación del contenido del registro............................ 7 2.3. La función de supervisión................. 7 3. Los principios clave del marco de IANA............. 8 4. Análisis............................ 8 4.1. Sobre la separación de las funciones............ 8 4.2. Sobre la responsabilidad................. 8 4.3. Sobre la delegación de responsabilidades.......... 9 4.4. Sobre la capacidad para crear registros de Internet.... 10 4.5. Sobre la relación con RFC6220............... 10 5. Ejemplos............................ 11 5.1. Ejemplos de políticas................... 11 5.1.1. Ejemplo de política 1................. 11 5.1.2. Ejemplo de política 2................. 11 5.1.3. Ejemplo de política 3................. 12 5.2. Ejemplos de función de la coordinación de evaluaciones... 12 5.2.1. Ejemplo de evaluación 1................ 12 5.2.2. Ejemplo de evaluación 2................ 12 5.2.3. Ejemplo de evaluación 3................ 12 5.3. Mantenimiento y publicación del contenido del registro... 13 5.3.1. Ejemplo de mantenimiento 1............... 13 5.3.2. Ejemplo de mantenimiento 2............... 13 5.4. Ejemplos de supervisión.................. 13 5.4.1. Ejemplo de supervisión 1................ 13 5.4.2. Ejemplo de supervisión 2................ 13 5.4.3. Ejemplo de supervisión 3................ 13 5.4.4. Ejemplo de supervisión 4................ 14 6. Consideraciones de seguridad.................. 14 7. Colaboradores y reconocimientos................ 14 8. Consideraciones de IANA.................... 14 9. Referencias.......................... 14 Apéndice A. Detalles para la edición del documento......... 15 Apéndice A.1. Información sobre la versión........... 16 Apéndice A.1.1. draft-kolkman-iana-framework-00........ 16 Apéndice A.1.2. draft-kolkman-iana-framework-00 -> draft-iabiana-framework-00............... 16 Apéndice A.1.3. draft-iab-iana-framework-00 -> draft-iab-ianaframework-01................. 16 Apéndice A.1.4. TODO..................... 17 Apéndice A.2. Información sobre la subversión.......... 17 Direcciones de los autores..................... 17 1. Introducción

1.1. Registros de Internet e interoperabilidad de Internet Los registros de Internet tienen identificadores que consisten en constantes y otros valores conocidos utilizados por los protocolos de Internet. Tales valores definen un vocabulario en común que los protocolos comprenden cuando se comunican entre sí. Por ejemplo, el número «80» del puerto TCP es mundialmente entendido y designa un servicio de «http». Casi todos los protocolos en existencia hacen uso de registros en alguna forma u otra. Los registros de Internet son de importancia crítica para el funcionamiento de Internet. Son necesarios para registrar el valor definitivo y el significado de los identificadores que los protocolos usan en la comunicación entre sí. La gestión de los registros de Internet se debe hacer de una manera predecible, estable y segura con el fin de asegurar que los identificadores de protocolo tengan significados e interpretaciones coherentes en todas las implementaciones. Los valores de los identificadores de protocolo pueden ser números, cadenas, direcciones, etc. Son asignados de forma exclusiva para un propósito o uso particular. Se los puede mantener en listas centralizadas (como, por ejemplo, listas de algoritmos criptográficos que se utilizan en un determinado protocolo) o se los puede asignar y distribuir jerárquicamente por entidades separadas en diferentes puntos de la jerarquía (como para direcciones IP y nombres de dominio). En el momento en que se redacta este documento, la Autoridad de Números Asignados en Internet (IANA, por su sigla en inglés) mantiene más de mil registros de parámetros de protocolo. La asignación y el registro estable y predecible de los identificadores de protocolo para los protocolos de Internet son de gran importancia para muchas partes interesadas, tales como desarrolladores, proveedores y clientes, así como los usuarios de los dispositivos, el software y los servicios en Internet. Estas partes interesadas utilizan y dependen de los registros y confían implícitamente en el sistema de registro para que sea estable y predecible. El sistema de registro se basa en la confianza y la cooperación mutua; el uso de los registros es voluntario y no lo imponen los mandatos o las políticas de certificación. La estabilidad y la precisión de los registros de Internet se logran a través de la definición de políticas adecuadas y claras para hacer agregados o para actualizar las entradas existentes. Dichas políticas deben tener en cuenta las características técnicas y operacionales de la tecnología que hace uso de los registros. Al mismo tiempo, deben ser capaces de evolucionar como sistemas y políticas de gestión de contenido de registro a medida que Internet en sí evoluciona. 1.2. La función de IANA y los registros de Internet La Fuerza de Tareas de Ingeniería de Internet (IETF, por su sigla en inglés) y sus predecesores siempre separaron el mecanismo de publicación de sus especificaciones de protocolo, publicadas en RFC inmutables, de los registros que contienen los parámetros de protocolo. Este último se mantiene, gracias a un conjunto de funciones conocidas en manera colectiva como la Autoridad de Números Asignados en Internet (IANA). Ya desde un poco antes de los primeros días de la Internet, las funciones de publicación de especificaciones y de mantenimiento del registro fueron fuertemente conectadas: Jon Postel del Instituto de Ciencias de la Información (ISI) de la Universidad del Sur de California (USC) fue el responsable tanto de las publicaciones RFC y de la función de IANA. Sin embargo, esta estrecha conexión nunca fue un requisito

y, de hecho, hoy en día, el editor de RFC y la función de IANA se contratan a través de diferentes entidades. (El proceso de publicación de RFC y el proceso de desarrollo de políticas de IANA se mantienen estrechamente conectados. Por ejemplo, una de las responsabilidades de la IAB es supervisar RFC Series e IANA [RFC2850]) Una forma de abordar la gestión de registro de Internet es examinar el qué, el por qué, el quién y el cómo. Los registros de Internet o de IANA son tablas con las distribuciones y las asignaciones de valores (el Qué), establecidas a través de instrucciones explícitas contenidas dentro de documentos de solicitud de comentarios (RFC) (el Por qué). El marco de este documento se aplica a los registros individuales. Sin embargo, los registros de Internet están coloquialmente agrupados en tres (3) clases: Nombres, Números y Parámetros de protocolo de la IETF. El marco se aplica, con algunas modificaciones, a todos los registros, independientemente de su clase. En este marco se identifican cuatro funciones principales: Las funciones de Política, Supervisión, Coordinación de evaluaciones y Mantenimiento y publicación (los dos últimos son aspectos de la implementación). Las entidades de dichas funciones pueden ser interpretadas como «el Qué», mientras que sus responsabilidades colectivas determinan «el Cómo». Por lo general, se utiliza el término IANA para referirse al conjunto de funciones con responsabilidades específicas en el contexto de registros de Internet (sobre todo, para aquello que recae bajo Aspectos de la implementación, a continuación). En este documento, se utiliza el término IANA o función/funciones de IANA independientemente de las entidades que implementan dichas funciones (el Quién). En la actualidad, de acuerdo con el Memorándum de Entendimiento [RFC2860], el mantenimiento, la implementación y la publicación de la mayor parte de los registros de protocolo de IETF se lleva a cabo por la Corporación de Internet para Nombres y Números Asignados (ICANN, por su sigla en inglés). 1.3. Un marco de IANA Este documento proporciona un marco para describir la gestión de los registros de Internet según se implementan en la actualidad. Define la terminología que describe las diversas funciones y las responsabilidades asociadas con estas funciones en la Sección 2. En la Sección 3, se describen algunos principios clave para la implementación del marco. En la Sección 4, se analizan algunos de los asuntos que surgieron durante el desarrollo del proyecto. Por último, en la Sección 5 se proporciona una serie de ejemplos sobre cómo el marco se aplica en la actualidad. Estas secciones han sido diseñadas para demostrar que el marco se puede aplicar a la situación actual, aunque con modificaciones necesarias, y que será un concepto útil en el futuro. Aunque este documento se puede leer independientemente de [RFC6220] y de [RFC7020] que documentan los requisitos específicos de un subconjunto de registros de IANA, en particular, los de parámetros de protocolo y el sistema de registro de números de Internet, respectivamente, estos RFC proporcionan un contexto y un ejemplo del contenido tratado en este documento. Las palabras como «debe», «debería», «deberá», «se requiere», «puede», etc. no se deben interpretar como lenguaje normativo, tal como se define en [RFC2119], sino en su sentido llano en español.

2. Funciones en relación con los registros de Internet En esta sección, se analizan las funciones pertinentes a los registros de Internet en términos de un registro abstracto que se define como parte de una especificación técnica arbitraria. La gestión del registro implica tres funciones. En primer lugar, una función de desarrollo de políticas que define el propósito del registro y el proceso, además de los requisitos para hacer agregados o actualizaciones. En segundo lugar, las funciones que se refieren al proceso operativo del procesamiento de las solicitudes de cambio a un registro y de la publicación de su contenido, siendo ambos aspectos de la implementación. Por último, una función de supervisión relacionada con la responsabilidad de alto nivel, para asegurar que las otras dos funciones se desempeñen satisfactoriamente e interfieran si se necesitan cambios significativos en las políticas o la implementación de un registro. Cada una de estas funciones se describe en más detalle en las siguientes subsecciones. 2.1. La función del desarrollo de políticas Descripción: Puede ser posible que sea necesario añadir valores adicionales a los registros, o, quizá, una entrada existente necesite ser eliminada, clarificada, actualizada, etcétera. La función de desarrollo de políticas crea el registro y define las políticas que describen quién puede hacer actualizaciones o agregados, qué tipo de revisión (si la hubiese) se necesita, las condiciones en las que, por lo general, se conceden (o se niegan), las solicitudes de actualización, los requisitos de seguridad de estas interacciones, etc. La entidad que realiza esta función podrá delegar sus responsabilidades de política respecto de una parte o de la totalidad de los parámetros del registro. En consecuencia, en este documento la palabra «política» se utiliza para referirse a un curso específico o un principio de acción para la administración de un recurso técnico que se mantiene dentro de los registros específicos Responsabilidades clave: La función de desarrollo de políticas se refiere a la creación de las políticas que rigen y definen cómo y cuándo se puede actualizar o modificar un registro. Resultado principal: Un conjunto de políticas mediante el cual se pueden mantener los registros. 2.2. Aspectos de la implementación Los aspectos de la implementación se refieren a la operación real cotidiana de un registro en términos de atender las solicitudes de agregados o actualizaciones del registro y de publicación de los contenidos del registro. Estas funciones implementan procesos que se rigen por las políticas definidas por la función de desarrollo de políticas. Se pueden identificar dos funciones distintas responsables de los aspectos de la implementación: Coordinación de evaluaciones y Mantenimiento y publicación del contenido del registro. Estas funciones se analizarán por separado. 2.2.1. La función de la coordinación de evaluaciones Abreviado como función de evaluación.

Responsabilidad clave: Coordinar, operar y procesar la evaluación oportuna de las solicitudes de registro sobre la base de las políticas establecidas por la función de desarrollo de políticas. Resultado principal: Un sistema que funcione sin problemas en el que las solicitudes de cambios de registro se presenten, se evalúen y se procesen de manera que coincidan con las normativas de política, registrando y publicando los resultados, según corresponda. En algunos casos, la evaluación de las solicitudes es una tarea sencilla que requiere poco o nada de evaluación subjetiva, mientras que en otros casos la evaluación es más compleja y requiere el aporte de expertos en la materia, según la definición de la normativa de política pertinente. Relación con otras funciones y actividades: Los resultados de las evaluaciones se introducen en el proceso de asignación, delegación y/o de ingreso de registros realizado por la entidad que hace mantenimiento (Sección 2.2.2). Las evaluaciones se llevan a cabo en base a las políticas definidas por la función de desarrollo de políticas. La coordinación de la evaluación es distinta de la evaluación de una solicitud en sí: La función de evaluación se encarga de atender la solicitud de asignación o mantenimiento de un registro y puede, bajo la dirección de la función de desarrollo de políticas, y en coordinación con esta, delegar la evaluación real a un tercero. 2.2.2. La función del mantenimiento y la publicación del contenido del registro Abreviado como función de mantenimiento. Responsabilidad clave: El mantenimiento del contenido de los registros: la asignación o la distribución de parámetros después de la evaluación positiva, de acuerdo con las políticas establecidas, y el mantenimiento de un registro apropiado de las transacciones y la publicación de los registros a disposición del público. Resultado principal: Acceso fácil y conveniente a los contenidos del registro, con adiciones y actualizaciones rápidas. Nota: El mantenimiento y la publicación del registro son funciones estrictamente mecánicas. En la práctica, la entidad que realiza estas funciones suele llevar a cabo todas o algunas de las responsabilidades de la coordinación de las evaluaciones de políticas. Por ejemplo, la verificación de que una solicitud sea correcta es una responsabilidad de la evaluación de políticas que puede ser asignada, de manera razonable y explícita, a la entidad que realiza la función de IANA, por la entidad que realiza la función de desarrollo de políticas.

2.3. La función de supervisión Descripción: La función de supervisión se relaciona con la responsabilidad de alto nivel para asegurar que las otras dos funciones se estén desempeñando satisfactoriamente e interfiriendo en caso que se necesiten cambios significativos en las políticas o la implementación de un registro. Responsabilidad clave: Asegurar que las políticas y la implementación de registros están alineados para apoyar el desarrollo y uso coherente a largo plazo de los recursos de Internet compartidos. Coordinar con las entidades que desempeñan funciones similares para otros registros. La función de supervisión, por lo general, está aislada del proceso de desarrollo de políticas. No obstante, puede servir para resolver apelaciones o ratificar las políticas desarrolladas. 3. Los principios clave del marco de IANA Todo marco IANA debe poder aplicarse teniendo en mente los siguientes principios claves. Estable y predecible: La implementación estable y predecible de la función de registros de Internet es importante para establecer la confianza global. Responsabilidad y transparencia: Las funciones de supervisión, implementación y desarrollo de políticas son responsables ante las partes materialmente afectadas y la comunidad en general. No todas las funciones pueden ser directamente responsables ante la comunidad en general; en la práctica, la función de supervisión tiene la responsabilidad de velar por la comunidad en general. En consecuencia, la función de supervisión debe mantener los más altos estándares posibles de transparencia y estar receptiva a comentarios y modificaciones. Separación de funciones: Las funciones de supervisión, desarrollo de políticas e implementación deben estar separadas o, al menos, poderse separar. Una clara distinción entre las funciones aumenta la transparencia y hace que sea más sencillo identificar quién es responsable ante quién. Delegación: Debería ser posible delegar cualquiera de las funciones (política, implementación o supervisión) respecto de los registros o parte de ellos. 4. Análisis 4.1. Sobre la separación de las funciones En muchos registros, existe una separación de hecho entre el desarrollo de políticas y la coordinación de evaluaciones que se lleva a cabo en la implementación. Si bien esto no ha sido nunca un requisito explícito, parece que la separación de las funciones puede resultar en falta de claridad en las políticas. Además, si se utiliza esta disposición de políticas, la separación de las funciones de supervisión y evaluación previene que la función de evaluación se vea afectada por las percepciones de favoritismo e injusticia.

4.2. Sobre la responsabilidad Cualquier entidad que realice una de las funciones definidas en este marco deberá rendir cuentas de sus responsabilidades. La responsabilidad de cada entidad debe ser expresada en términos de «quién» y «cómo»; a quién es la entidad responsable y por cuáles mecanismos deberá la entidad rendir cuentas. En otras palabras, el desarrollo de políticas de registro y las operaciones de registro deben «rendir cuentas» a la comunidad afectada. En la práctica, los mecanismos de rendición de cuentas y responsabilidad pueden definirse mediante memorandos de entendimiento o mediante acuerdos de servicios contractuales (SLA) entre las entidades que implementan y el organismo que controla, a la vez que los organismos de supervisión son responsabilizados a través de los mecanismos de revisión de la comunidad, por ejemplo, mediante el proceso de llamado y apelación. Por ejemplo: Para los parámetros de protocolo, la supervisión general de la función de IANA es llevada a cabo por el IAB como una responsabilidad derivada de [RFC2850] (ver también la Sección 5.4). Además, el IAOC, organismo responsable de los asuntos financieros y administrativos de la IETF [RFC4071], mantiene un servicio contractual (SLA) con ICANN, especificando con ello las necesidades operativas con respecto a la coordinación de la evaluación y el mantenimiento y la publicación de los registros. Tanto el IAB y el IAOC son responsables ante la comunidad extendida de Internet y se responsabilizan a través del proceso de la IETF Nomcom [BCP10]. 4.3. Sobre la delegación de responsabilidades La mayoría, si no todos, los registros de los parámetros de protocolo fueron creados por la IETF o sus predecesores. Hoy en día, la mayoría de los registros de protocolos de la IETF son mantenidos en IANA por ICANN. Sin embargo, nada en este marco prohíbe la delegación de las funciones de supervisión, política, evaluación o mantenimiento (o cualquier combinación de estas) de los registros de parámetros específicos de protocolo a otras organizaciones. En algunas circunstancias, esto puede ser deseable e incluso permitir una mejor gestión del registro para el bien de la comunidad global de Internet. La delegación de un registro IANA puede ser deseable por varias razones, incluyendo el apoyo para el desarrollo de políticas de registro más inclusivas, la distribución de las operaciones de registro a nivel mundial y la capacidad para considerar la política pública en la gestión del registro. Si bien la delegación de un registro de IANA en estas situaciones puede mejorar el servicio de registro que recibe la comunidad mundial de Internet, esto no está garantizado, y, por tanto, le corresponde al IAB tener directrices claras para que la delegación del registro IANA sea exitosa. Estas directrices están fuera del alcance de este documento. Algunos ejemplos de registros donde la responsabilidad de desarrollar la política se ha delegado, en su totalidad o en parte, incluyen la asignación de nombres de dominio y la asignación de bloques de direcciones de IP (ambos considerados asuntos de política por [RFC2860]) y el registro de números de sistema autónomo (AS) [RFC7020]. [RFC2860] demuestra que la delegación puede ser delimitada de manera muy específica: «Se deberá tener en cuenta que (a) las asignaciones de nombres de dominio para usos técnicos (tales como los nombres de dominio de reversos), (b) las asignaciones de bloques de direcciones especializados (tales como bloques multicast o anycast) y (c) las

asignaciones experimentales no se consideran asuntos de política (...)». Estos nombres y direcciones para usos especiales se asignan de la misma manera que los parámetros de protocolo, excepto que se requiere coordinación durante el establecimiento de la política y la asignación real de los valores. Los organismos de supervisión pueden facilitar la coordinación. Véase también Ejemplos de políticas 2 y 3 en la Sección 5.1. 4.4. Sobre la capacidad para crear registros de Internet Al igual que con la IETF y los registros de protocolo de IANA correspondientes, otros organismos de normalización (y otras instituciones) tienen una larga historia de definir y crear registros, así como los parámetros, las tablas y otros valores que los componen. Estas prácticas normales pueden, obviamente, extenderse a los registros y sus contenidos para su uso en Internet. Este documento no prescribe cómo se rigen estos registros. En el contexto de este documento, el término registros de Internet se utiliza para aquellos registros organizados actualmente como registros de Nombres de dominio, Recursos numéricos y Parámetros de protocolos de la IETF. La IETF (en términos más amplios) tiene la autoridad para crear nuevos registros de parámetros de protocolos de la IETF, como se describe en [RFC6220]. La IETF también tiene la autoridad para crear los registros que pertenecen al Sistema de nombres de dominio, pero solo para especificar el uso técnico [RFC6761]. Por último, la IETF tiene la autoridad (exclusiva) para adjudicar la asignación técnica de los recursos numéricos fuera del espacio de direcciones actualmente reservado ([RFC2860] y [RFC4291]). 4.5. Sobre la relación con RFC6220 Los autores son conscientes de que este marco utiliza menos términos, términos ligeramente diferentes y términos más genéricos para describir las diversas funciones en comparación con [RFC6220]. [RFC6220] es un documento que se refiere específicamente a los registros de parámetros de protocolo de la IETF. Por ejemplo, [RFC6220] Sección 2.1 «Función del operador de registro de parámetro de protocolo» describe el conjunto completo de responsabilidades para el/los operador(es) de los registros de parámetros de protocolo de la IETF. Estas responsabilidades se relacionan con los aspectos de Implementador en la Sección 2.2 anterior. [RFC6220] también describe la función del Comité de Supervisión Administrativa de la IETF (IAOC) y de IETF Trust. Estos organismos tienen responsabilidades específicas en la IETF más amplio y son responsables de la contratación y los derechos de propiedad intelectual (IPR), respectivamente. Dentro de este marco deben ser considerados parte de la «Función de supervisión». 5. Ejemplos 5.1. Ejemplos de políticas No es coincidencia que los siguientes tres ejemplos muestren cómo se organizan en la actualidad las funciones de registro IANA: Registros de parámetros de protocolo de la IETF, Recursos numéricos y Nombres de dominio. 5.1.1. Ejemplo de política 1

La IETF, a través del IESG (véase Sección [RFC6220] 2.3), actúa en esta función cuando en las secciones «Consideraciones de IANA» de sus RFC se especifica la creación de un nuevo registro, se especifican las entradas iniciales, y se especifica una política para añadir entradas adicionales en el registro en el futuro. [RFC5226] proporciona orientación y terminología que han demostrado ser útiles dentro de la IETF para describir las políticas comunes para la gestión de sus registros. Esos términos incluyen «Uso privado», «Asignación jerárquica», «Orden de llegada», «Revisión por expertos», «Especificación requerida«, «Aprobación de IESG», «Consenso de IETF» y «Acción sobre normas». La IETF utiliza estos términos y, si es necesario, otras plantillas para definir la política a través de la cual se ingresan registros. 5.1.2. Ejemplo de política 2 El protocolo de Sistema de nombres de dominio (DNS) permite el mantenimiento jerárquico de los registros de nombres de dominio y su publicación. En la actualidad, la ICANN es el responsable del control de cambios en la zona raíz, que incluye el establecimiento y el mantenimiento de políticas para dicha zona. El control de cambios, el control de políticas y la autoridad de publicación siguen la jerarquía del DNS; y aunque la ICANN es la entidad autorizada en la función de políticas para la zona raíz, no tiene autoridad sobre todos los dominios inferiores a la raíz. Por ejemplo, la IETF establece la política para determinar qué nombres se asignan en la zona ietf.org. Para dominios de nivel superior de código de país (cctld) las políticas son establecidas por el registro de cctld, en coordinación con la comunidad local, entes reguladores locales y otros organismos nacionales. Incluso la política de asignación de nombres dentro de la raíz está sujeta a modificaciones. Por ejemplo, la ICANN ha reservado dominios de nivel superior de dos letras para uso como dominios de nivel superior de código de país y territorio (cctld). La asignación de los códigos de dos letras en sí (que consecutivamente se pueden utilizar como dominios de nivel superior de DNS) se realiza mediante la norma ISO TC46/WG2 y son mantenidos por el organismo que mantiene la norma ISO 3166 [ISO.3166.2013]. La selección del operador de un cctld se rige actualmente por [RFC1591], véase también la Sección 5.4 Ejemplo de supervisión 4. 5.1.3. Ejemplo de política 3 La asignación de direcciones IP y el desarrollo de las políticas asociadas también se distribuyen. Por ejemplo, la IETF ha definido un rango de direcciones IPv6 denominado direcciones unicast. Para una fracción de ese rango de direcciones, la ICANN ha delegado el control de cambios (véase [RFC3513] Sección 4 para más detalles y [GlobAddrPol] para ejemplos). El control de cambios se delega aún más a los Registros Regionales de Internet (RIR) que, de acuerdo con las políticas establecidas por las comunidades regionales, delegan aún más el control de cambios, por ejemplo, a los Registros Nacionales de Internet. 5.2. Ejemplos de función de la coordinación de evaluaciones 5.2.1. Ejemplo de evaluación 1 Como se mencionó anteriormente, [RFC5226] proporciona la terminología para definir políticas comunes que utilizan los registros de la IETF asociados con protocolos de la IETF. Una de las políticas que la función de desarrollo políticas puede imponer para la asignación de un registro es «Revisión por

expertos». En este caso, un experto en la materia evaluará la solicitud de asignación y determinará si se hará o no una asignación. Una política alternativa de asignación es el requisito de Consenso de IETF. Aquí es donde por primera vez la IETF, en su función de desarrollo de políticas, establece la política y, a continuación, en su función de evaluación de políticas, la implementa al determinar un consenso para una modificación de un registro en particular. El operador de funciones de IANA (actualmente operado por ICANN) es la entidad que coordina para la IETF la evaluación de las solicitudes de registro a la luz de las políticas establecidas por la IETF. 5.2.2. Ejemplo de evaluación 2 La política de asignación de dirección IP se desarrolla de manera ascendente por las comunidades de Registros Regionales de Internet (RIR). Las comunidades RIR realizan la función de desarrollo de política mientras que en los RIR la función de evaluación de políticas es realizada por analistas de recursos IP (o similares), que evalúan las solicitudes de asignación a la luz de las políticas desarrolladas en la región. El personal del RIR suele respaldar o incluso iniciar el proceso de desarrollo de políticas. 5.2.3. Ejemplo de evaluación 3 La política genérica de delegación TLD es desarrollada en la actualidad de manera ascendente a través de los procesos de políticas de la ICANN. Como se especifica en los estatutos de la ICANN [ADDREF], el Directorio de la ICANN supervisa estos procesos para llevar a cabo la función de desarrollo de políticas. La función de evaluación de políticas se lleva a cabo bajo la responsabilidad del Directorio de ICANN; el personal y una variedad de paneles evalúan las solicitudes de nuevos dominios genéricos de nivel superior a la luz de las políticas desarrolladas a través de los procesos de desarrollo de políticas de la ICANN. Además, el personal de la ICANN, por lo general, suele respaldar estos procesos de desarrollo de políticas. 5.3. Mantenimiento y publicación del contenido del registro 5.3.1. Ejemplo de mantenimiento 1 La ICANN, como el actual operador de funciones de IANA, publica los registros de parámetros de protocolo en el sitio web de IANA. Recientemente los cuadros de texto sin formato de este sitio web fueron realzados con tablas en un formato estructurado y legible por máquina. La coordinación de los requisitos para publicación y la implementación de sistemas técnicos es parte de la responsabilidad de mantenimiento y publicación. 5.3.2. Ejemplo de mantenimiento 2 [AVISO EDITORIAL: Agregar el contenido DNS y WHOIS inverso como ejemplo de publicación y mantenimiento] 5.4. Ejemplos de supervisión 5.4.1. Ejemplo de supervisión 1

El Comité de Arquitectura de Internet (IAB) es responsable de supervisar el proceso utilizado para crear estándares de Internet y coordina con aquellas otras entidades que tienen la función de supervisar los registros de Internet. 5.4.2. Ejemplo de supervisión 2 De manera colectiva, las comunidades servidas por los Registros Regionales de Internet supervisan el desarrollo de políticas para las políticas de asignación global de direcciones de Internet. 5.4.3. Ejemplo de supervisión 3 De manera colectiva, las partes interesadas involucradas en los procesos de desarrollo de políticas de la ICANN tienen la función de supervisar el desarrollo de políticas para los procesos de asignación de TLD genéricos. Otros ejemplos de coordinación alrededor de los protocolos de la IETF son la coordinación con el ITU-T, cuando el protocolo ENUM comenzó a utilizar los identificadores E.164 (números telefónicos) [RFC3245]. Otro ejemplo es la coordinación entre el proceso de desarrollo de protocolos de la IETF y la reserva de las etiquetas en el nivel superior del espacio de nombres de dominio con RFC6761, como un ejemplo reciente. 5.4.4. Ejemplo de supervisión 4 El lector sagaz seguramente habrá notado que en el Ejemplo de política 2, en la Sección 5.1, la política a través de la cual se seleccionan los operadores de cctld se refiere a RFC1591. RFC1591 fue publicada en el momento en que Jon Postel era responsable de las funciones de la IANA, antes de que instituciones como la ICANN y la IETF existieran, y el IAB tenía otro tipo de responsabilidades. En caso de que fuera necesaria una actualización del RFC1591 o de que se requiera una declaración de la naturaleza histórica de ese documento, dicha acción probablemente involucraría a la administración y la coordinación por parte del IAB y la ICANN. 6. Consideraciones de seguridad Como hemos visto, la Sección 1.1 Registros de Internet y el modelo presentado en este documento son de importancia crítica para los elementos de seguridad de Internet. Sin embargo, este documento simplemente discute ese modelo, en lugar de proponer cambios, y en consecuencia no afecta directamente a la seguridad de Internet. 7. Colaboradores y reconocimientos Este texto ha sido [está siendo] desarrollado dentro del programa de estrategia del IAB de la IANA. Las ideas y muchos, si no la mayoría, de los fragmentos de texto y las correcciones, se derivan o fueron inspirados en los comentarios de: Jaap, Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, John Curran, Leslie Daigle, Elise Gerich, Russ Housley, John Klensin, Danny McPherson, Thomas Narten, Andrei Robachevsky y Greg Wood. También se recibió inspiración adicional y aportes en diversas reuniones con IETF y otras comunidades líderes de Internet (RIR, ISOC, W3C, IETF y IAB). 8. Consideraciones de IANA

Este memorándum no contiene ninguna instrucción específica para cualquier entidad que desempeñe la función de Implementador. 9. Referencias [BCP10] Galvin, J., Ed., IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, BCP 10, RFC 3777, junio de 2004. Dawkins, S., Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers, BCP 10, RFC 5633, agosto de 2009. [GlobAddrPol] Board's Review Procedures for Global Internet Number Resource Policies Forwarded for Ratification by the ASO Address Council in Accordance with the ASO MoU, julio de 2005. [ISO.3166.2013] Organización Internacional de Normalización, Codes for the representation of names of countries and their subdivisions, Norma ISO 3166, noviembre de 2013. [RFC1591] Postel, J., Domain Name System Structure and Delegation, RFC 1591, marzo de 1994. [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, marzo de 1997. [RFC2850] Comité de Arquitectura de Internet y B. Carpenter, Charter of the Internet Architecture Board (IAB), BCP 39, RFC 2850, mayo de 2000. [RFC2860] Carpenter, B., Baker, F. and M. Roberts, Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, RFC 2860, junio de 2000. [RFC3245] Klensin, J.IAB, The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2), RFC 3245, marzo de 2002. [RFC3513] Hinden, R. and S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, RFC 3513, abril de 2003. [RFC4071] Austein, R. and B. Wijnen, Structure of the IETF Administrative Support Activity (IASA), BCP 101, RFC 4071, abril de 2005. [RFC4291] Hinden, R. and S. Deering, IP Version 6 Addressing Architecture, RFC 4291, febrero de 2006. [RFC5226] Narten, T. and H. Alvestrand, BCP 26, RFC 5226, mayo de 2008. [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.Internet Architecture Board, Defining the Role and Function of IETF Protocol Parameter Registry Operators, RFC 6220, abril de 2011. [RFC6761] Cheshire, S. and M. Krochmal, Special-Use Domain Names, RFC 6761, febrero de 2013. [RFC7020] Housley, R., Curran, J., Huston, G. and D. Conrad, The Internet Numbers Registry System, RFC 7020, agosto de 2013.

Apéndice A. Detalles para la modificación del documento [El texto entre corchetes que empieza con las iniciales son las notas del editor. Cualquier otro texto entre corchetes se considerará como una acción de parte del editor de RFC antes de su publicación como RFC. En la mayoría indicará eliminación de texto, sugerencias estilísticas o editoriales o alguna pregunta] [Esta sección y sus subsecciones deben eliminarse antes de la publicación como RFC] Apéndice A.1. Información sobre la versión Apéndice A.1.1. draft-kolkman-iana-framework-00 Este proyecto es el resultado de una puesta en común de ideas en el programa del IAB de IANA y no pretende reflejar ningún tipo de consenso. Apéndice A.1.2. draft-kolkman-iana-framework-00 -> draft-iab-ianaframework-00 Se agregaron las secciones «Sobre la responsabilidad» y «Sobre la delegación de responsabilidades». Se volvieron a redactar algunas de las frases a través de una revisión a que llevó a cabo David Conrad. Se añadió una referencia a [RFC7020] en la Sección 1.3 y se aclaró la naturaleza informativa en vez de normativa de los ejemplos. Se añadió la Sección 3 y se cambió el nombre de la Sección 4. Modificaciones menores. Apéndice A.1.3. draft-iab-iana-framework-00 -> draft-iab-iana- framework-01 Se volvió a ordenar en detalle el documento al quitar los ejemplos de las descripciones de las funciones y colocarlos en la Sección 5. Se dividió la «Función de implementación» en dos funciones diferentes de manera explícita: Evaluación y Mantenimiento. Ambas funciones pueden ser dirigidas bajo los aspectos de la implementación. Se volvió a redactar el texto sobre «el Qué, el Quién y el Por qué» y se proporcionó una visión general en la Sección 1.2 Se reformuló el texto de la Sección 4.3 para resaltar que solamente la asignación de nombres es el aspecto de la política que fue delegado. Del mismo modo, en la Sección 5.1, al introducir la referencia a la Norma ISO3166, se intentó de ilustrar que hay políticas delegadas, incluso, dentro de la asignación de nombres de dominio en la raíz. Se añadió el Ejemplo de supervisión 4 en la Sección 5.4 como un ejemplo de política que ha existido durante algunas décadas y para la cual se necesitaría la coordinación en caso de que fuese necesaria una actualización. Modificaciones menores. Apéndice A.1.4. TODO

Tal vez añadir una sección de terminología con más explicaciones y elaboración de términos como mantenimiento, coordinación, etc. EDITOR RFC: la referencia BCP10 [BCP10] necesita ser formateada correctamente. El hack de anotación utilizado para enumerar los varios RFC que componen el BCP10 no parece funcionar.] Revisar y potencialmente añadir texto de aclaración sobre el uso de los «Registros de Internet» (números de IP y AS, nombres de dominio y registros de protocolo de la IETF). Apéndice A.2. Información sobre la subversión $Id: iana-framework.xml 30 2014-01-22 11:42:00Z olaf $ Direcciones de los autores Comité de Arquitectura de Internet Correo electrónico: iab@iab.org Olaf Kolkman, editor Stichting NLnet Labs Science Park 400 Ámsterdam, 1098 XH, Holanda Correo electrónico: olaf@nlnetlabs.nl URL: http://www.nlnetlabs.nl/