Especificación Inicial Mínima, Decisión Futura Local y Adopción Voluntaria para un sistema de coordinación de Internet

Acordar la unión y dejar espacio para diseños distintos. Lu Heng propone limitar las reglas compartidas a lo que exige la interoperabilidad y dejar las decisiones posteriores en manos de los propios participantes.

Resumen

Este documento describe un patrón de diseño para sistemas de coordinación de Internet cuyo propósito es proporcionar puntos de referencia técnicos compartidos sin crear una autoridad permanente por encima de los participantes que hacen funcionar el sistema. Define tres principios vinculados: Especificación Inicial Mínima, Decisión Futura Local y Adopción Voluntaria.

En este modelo, la Especificación Inicial define únicamente las reglas deterministas y verificables localmente que hacen falta para garantizar la unicidad, la interoperabilidad, la seguridad operativa compartida y la seguridad frente a amenazas. Una vez establecida la Especificación Inicial, ningún órgano central aprueba los cambios futuros. Los participantes que ejecutan código los adoptan, los ignoran, crean bifurcaciones a partir de ellos o los abandonan.

No adoptar un cambio no constituye una infracción. Un participante que no adopta un cambio posterior permanece en su conjunto de compatibilidad existente. Si un participante emite un estado que no es válido conforme a las reglas deterministas aceptadas por otro participante, este último puede ignorar localmente al participante que lo emite. El efecto es la selección de compatibilidad, la bifurcación, el aislamiento o la interoperación selectiva, no una sanción institucional.

Este documento no define un protocolo de comunicación. Especifica una Mejor Práctica Actual para el diseño de protocolos, registros, sistemas de identificadores y mecanismos de coordinación que no deben convertirse en instituciones permanentes de gobierno.

1. Introducción

Muchos sistemas de Internet nacen con un propósito técnico limitado: permitir que actores independientes interoperen mediante un punto de referencia común, un espacio de identificadores, una regla de validación o un registro. Con el tiempo, estos sistemas suelen acumular una autoridad que no era necesaria para la interoperabilidad inicial.

Esto suele ocurrir en tres pasos.

Primero, se incorporan cuestiones futuras a la capa fundacional antes de que sean técnicamente necesarias.

Segundo, decisiones que deberían corresponder a los participantes que operan sus propios sistemas pasan a depender del reconocimiento, la interpretación o las decisiones sobre su condición por parte de un órgano permanente.

Tercero, se considera que la publicación, la inscripción en un registro, la recomendación o la aprobación procedimental bastan para crear una obligación operativa, incluso cuando los participantes no han adoptado el cambio en los sistemas en funcionamiento.

El resultado es un sistema frágil. Una capa de referencia técnica se convierte en una capa de gobierno. Quien lleva el registro se convierte en quien controla el acceso. Un instrumento de coordinación se convierte en una fuente de control futuro.

Este documento propone una disciplina de diseño diferente:

– Especificación Inicial Mínima: especificar únicamente las reglas comunes deterministas necesarias para la interoperabilidad básica, la unicidad, la seguridad operativa compartida y la seguridad frente a amenazas.
– Decisión Futura Local: una vez establecida la Especificación Inicial, dejar las decisiones futuras en manos de los participantes que ejecutan código. Un participante puede adoptar un cambio, rechazarlo, crear una bifurcación, desconectarse o interoperar selectivamente. Ningún participante puede alterar la interoperabilidad de otros participantes que sigan aplicando reglas compatibles entre sí.
– Adopción Voluntaria: hacer que los cambios posteriores se materialicen únicamente mediante su implementación, operación, validación y adopción por los participantes que ejecutan código.

Estos principios están relacionados. Un sistema que especifica demasiado al principio incorpora de antemano el control futuro a la capa común. Un sistema que mantiene una capa permanente de reconocimiento permite que la autoridad reaparezca después del despliegue. Un sistema que trata la publicación como realidad convierte la documentación en una orden.

La intuición de diseño es sencilla: la validez debe determinarse mediante reglas deterministas que los participantes puedan verificar localmente. Un participante puede adoptar un cambio posterior, rechazarlo, crear una bifurcación, desconectarse o interoperar selectivamente. Como máximo, puede excluirse a sí mismo de un conjunto de compatibilidad. Al rechazar un cambio, no puede romper la interoperabilidad de otros participantes que sigan ejecutando código compatible entre sí.

Es la misma lección general que puede observarse en sistemas como Bitcoin: quienes ejecutan el código de validación hacen cumplir las reglas de consenso, no una institución situada por encima de ellos.

2. Alcance

Este documento se aplica a sistemas de coordinación de Internet, incluidos, entre otros, registros compartidos, sistemas de identificadores, marcos de nombres y numeración, mecanismos de extensión de protocolos, sistemas de prueba de control, sistemas de portabilidad y otras arquitecturas en las que actores independientes dependen de un punto de referencia técnico común.

Este documento no se opone a las reglas comunes. Sostiene que deben ser deterministas, mínimas, verificables localmente y limitadas a lo que el sistema necesita realmente para funcionar.

Este documento no exige una cadena de bloques, un registro distribuido ni ninguna tecnología concreta. Exige una propiedad de diseño: los participantes deben poder determinar la validez aplicando localmente la Especificación Inicial, sin pedir permiso a una autoridad permanente ni solicitar que esta determine su condición.

3. Convenciones y definiciones

3.1. Lenguaje de los requisitos

Los términos de requisito escritos en mayúsculas en este documento deben interpretarse en el sentido definido por BCP 14, concretamente en RFC 2119 y RFC 8174.

3.2. Terminología

Especificación Inicial:
El conjunto de reglas, estructuras de datos, formatos, invariantes, procedimientos de validación y reglas de transición necesarios para el primer despliegue de un sistema.

Capa Común:
El conjunto mínimo de reglas compartidas o la estructura de referencia mínima que necesitan los participantes independientes para interoperar. La capa común no es una institución. Es el contenido técnico que los participantes implementan y verifican.

Regla de Validación Determinista:
Una regla que permite a un participante decidir, mediante cálculo o verificación local, si un estado, registro, transición, afirmación o mensaje es válido conforme a un conjunto de reglas especificado.

Invariante Global:
Una propiedad que debe mantenerse común dentro de un conjunto de compatibilidad para preservar la unicidad, la interoperabilidad básica, la seguridad operativa compartida o la seguridad frente a amenazas.

Participante:
Un operador, una implementación, un nodo, una red, una organización u otro actor que hace funcionar, verifica o despliega el sistema, o depende de él.

Conjunto de Compatibilidad:
Un grupo de participantes cuyas reglas de validación implementadas les permiten interoperar. Un cambio posterior puede crear un nuevo conjunto de compatibilidad si algunos participantes lo adoptan y otros no.

Adopción:
La implementación, el despliegue, la validación y el uso efectivos por los participantes que hacen funcionar el sistema.

No Adopción:
La decisión de un participante de no implementar ni utilizar un cambio propuesto. La no adopción no confiere una condición de invalidez. Solo significa que el participante no se ha incorporado al conjunto de compatibilidad creado por ese cambio.

Rechazo Local:
La decisión local de un participante de ignorar, rechazar o no interoperar con un estado, mensaje, registro o transición que sea inválido o incompatible conforme a las reglas de validación que aplica.

Bifurcación:
Una divergencia en las reglas de validación o en la práctica operativa que crea dos o más conjuntos de compatibilidad.

Instrumento de Coordinación:
Un documento, una entrada de registro, una recomendación, una nota de implementación, un perfil, una implementación de referencia u otro elemento que ayude a los participantes a coordinarse. Un instrumento de coordinación no crea una realidad operativa vinculante a menos que los participantes lo adopten en sistemas en funcionamiento.

4. Planteamiento del problema

Los diseñadores suelen intentar reducir la incertidumbre futura incorporando demasiadas disposiciones a la capa fundacional o dejando un órgano permanente encargado de interpretar las cuestiones futuras. Parece prudente. A menudo es peligroso.

El exceso de especificación en la capa fundacional tiene tres costes.

Primero, traslada decisiones futuras a una capa común en la que los cambios son más difíciles y la captura tiene mayores efectos.

Segundo, crea ambigüedad entre la validez técnica y el reconocimiento institucional.

Tercero, anima a un órgano que mantiene registros, publica documentos o convoca a los participantes a tratar esos actos como una autoridad sobre la realidad futura.

El mismo problema aparece después del despliegue. Si un sistema exige que un órgano permanente apruebe los cambios, determine la condición de los participantes o interprete el funcionamiento ordinario, ha creado una capa de control posterior a su fundación. Esa capa puede empezar como administración. Puede convertirse en gobierno. Y después puede convertirse en un punto de estrangulamiento.

El objetivo de diseño de este documento no es mejorar la discrecionalidad institucional. Es evitar que esa discrecionalidad sea necesaria.

Un sistema de coordinación de Internet bien diseñado debería definir desde el principio reglas de validez deterministas y verificables localmente; debería dejar fuera de la capa común las decisiones que no afecten a invariantes; y debería permitir que los cambios posteriores se materialicen únicamente cuando los participantes los adopten voluntariamente en sistemas en funcionamiento.

5. Principio 1: Especificación Inicial Mínima

5.1. Enunciado

Una Especificación Inicial DEBERÍA definir únicamente las reglas comunes deterministas mínimas necesarias para la interoperabilidad básica, la unicidad, la seguridad operativa compartida y la seguridad frente a amenazas.

5.2. Requisitos

Un diseño que aplique este principio:

1. DEBE identificar explícitamente sus Invariantes Globales.
2. DEBE definir reglas de validación deterministas para cada Invariante Global.
3. NO DEBE incluir una regla en la Especificación Inicial a menos que sea necesaria para preservar un Invariante Global declarado o para permitir el primer despliegue.
4. DEBE separar las reglas de validación de las preferencias de política, los acuerdos comerciales, las funciones institucionales, las aspiraciones de gobierno y el juicio discrecional.
5. DEBE permitir que los participantes verifiquen localmente la validez ordinaria sin consultar a ninguna institución, registro, comité, órgano de políticas u otra autoridad.
6. DEBERÍA definir las estructuras de datos, firmas, pruebas, reglas de transición de estado, reglas sobre conflictos u otros mecanismos necesarios para la verificación local.
7. DEBERÍA definir mecanismos de señalización de extensiones, gestión de versiones, etiquetado de compatibilidad o identificación de bifurcaciones cuando sea previsible una variación futura.
8. DEBE garantizar que los instrumentos de coordinación necesarios sean portables, auditables, reproducibles y sustituibles.
9. DEBERÍA dar preferencia a las condiciones objetivas verificables por máquina frente a los juicios subjetivos sobre méritos.
10. NO DEBE hacer del reconocimiento institucional futuro la única vía para conocer, registrar o utilizar un estado válido.

5.3. Implicaciones para el diseño

Especificación Inicial Mínima no significa especificación vaga. Significa especificar rigurosamente solo aquello que debe ser común.

Un sistema sigue necesitando suficiente estructura común para funcionar. La disciplina consiste en distinguir entre:

– lo que debe ser común para garantizar la unicidad, la interoperabilidad, la seguridad operativa compartida y la seguridad frente a amenazas; y
– lo que puede permanecer fuera de la capa común porque concierne a las preferencias del operador, las prácticas comerciales, el momento del despliegue o la decisión de adoptar cambios posteriores.

Un diseño que no pueda enunciar con claridad sus Invariantes Globales y sus reglas de validación deterministas debería partir del supuesto de que ha especificado demasiada discrecionalidad y demasiado poco contenido verificable.

6. Principio 2: Decisión Futura Local

6.1. Enunciado

Una vez establecida la Especificación Inicial, las Decisiones Futuras DEBERÍAN permanecer en el ámbito local de los participantes que ejecutan código. Una Decisión Futura solo surte efecto en el conjunto de compatibilidad cuyos participantes la adoptan. No hace falta que ninguna autoridad permanente la apruebe, y la no adopción no confiere una condición de invalidez.

6.2. Requisitos

Un diseño que aplique este principio:

1. NO DEBE exigir que los participantes obtengan permiso de una institución, registro, comité, consejo, órgano de políticas u otra autoridad ya establecidos para tomar decisiones que no alteren las reglas de validación deterministas del conjunto de compatibilidad al que pertenecen.
2. NO DEBE crear un órgano permanente cuyo reconocimiento sea la única vía para que un cambio posterior se materialice operativamente.
3. DEBE distinguir la validez conforme a la Especificación Inicial de la compatibilidad con un cambio opcional posterior.
4. NO DEBE tratar la no adopción de un cambio posterior como invalidez.
5. DEBE permitir que los participantes permanezcan en un conjunto de compatibilidad existente cuando no adopten un cambio posterior.
6. DEBE permitir que los participantes se incorporen a un nuevo conjunto de compatibilidad adoptando nuevas reglas de validación o nuevos perfiles operativos.
7. DEBE permitir que los participantes rechacen localmente estados, registros, transiciones o mensajes que sean inválidos o incompatibles conforme a las reglas de validación que aplican.
8. NO DEBE autorizar a ninguna institución, registro, comité, órgano de políticas u otro actor a declarar inválido a un participante por el mero hecho de que haya rechazado un cambio posterior.
9. DEBERÍA hacer explícitas las bifurcaciones, versiones, perfiles o conjuntos de compatibilidad para que los participantes sepan qué reglas aplican y con qué otros participantes pueden interoperar.
10. DEBERÍA evitar cualquier diseño en el que quien lleva el registro establecido pueda impedir que participantes por lo demás válidos sigan interoperando.

6.3. Implicaciones para el diseño

Decisión Futura Local no significa que una autoridad central asigne las decisiones futuras a actores locales. Significa que el sistema está diseñado para que, una vez establecida la Especificación Inicial, las decisiones futuras ordinarias no necesiten tal asignación.

La Especificación Inicial realiza de antemano la labor de delimitación. Define los invariantes mínimos necesarios para la unicidad, la interoperabilidad, la seguridad operativa compartida y la seguridad frente a amenazas. Todo lo demás permanece fuera de la capa común.

Los cambios futuros no se aprueban de forma centralizada. Los participantes que ejecutan código los adoptan, los ignoran, crean bifurcaciones a partir de ellos o los abandonan.

Un participante que rechaza un cambio puede permanecer fuera del conjunto de compatibilidad creado por ese cambio. Puede desconectarse de otros. Puede seguir en un conjunto de compatibilidad anterior. Puede crear una bifurcación. Puede interoperar selectivamente. Pero no puede romper la interoperabilidad de otros participantes que sigan aplicando reglas compatibles entre sí.

El efecto de un estado inválido o incompatible es el rechazo local, no la sanción. Nadie necesita decidir que un participante está en situación de incumplimiento. Un participante que aplica reglas de validación compatibles sencillamente no acepta el estado inválido o incompatible.

7. Principio 3: Adopción Voluntaria

7.1. Enunciado

Los cambios en un sistema de coordinación de Internet DEBERÍAN materializarse operativamente mediante su implementación, validación, despliegue y adopción por los participantes, no mediante la mera publicación o declaración.

7.2. Requisitos

Un diseño que aplique este principio:

1. NO DEBE considerar que la publicación, la inscripción en un registro, la recomendación, la aprobación en una reunión o la aprobación procedimental bastan para crear una obligación operativa universal.
2. DEBE permitir que los participantes que decidan aplicarlos desplieguen gradualmente nuevas reglas, extensiones, perfiles o procedimientos.
3. DEBE permitir que los participantes rechacen un cambio posterior sin adquirir una condición de invalidez, siempre que sus propias transiciones de estado satisfagan las reglas de validación deterministas de su conjunto de compatibilidad.
4. DEBE permitir que los participantes sigan utilizando un conjunto de compatibilidad anterior cuando la Especificación Inicial permita esa continuidad.
5. DEBE permitir que los participantes que operan dentro de un conjunto de compatibilidad rechacen o ignoren localmente estados procedentes de otro conjunto cuando las reglas sean incompatibles.
6. DEBERÍA definir vías de adopción para los cambios importantes, incluidas la señalización de versiones, el etiquetado de compatibilidad, las orientaciones para la transición y los vectores de prueba.
7. DEBERÍA definir vías para rechazar los cambios importantes, incluido cómo los participantes que no los adopten pueden seguir operando, identificar su conjunto de compatibilidad y evitar una interoperación ambigua.
8. DEBE garantizar que sea posible dejar de utilizar, trasladar, replicar, reimplementar o sustituir los instrumentos de coordinación necesarios sin que la transición tenga un coste inasumible.
9. DEBERÍA hacer que los registros, las anotaciones, las recomendaciones y los instrumentos de coordinación describan la realidad adoptada en lugar de pretender crear por declaración una realidad futura aún no adoptada.
10. DEBE evitar el diseño de un sistema en el que la única forma de que un cambio se materialice sea el reconocimiento previo de un órgano ya establecido.

7.3. Implicaciones para el diseño

La Adopción Voluntaria es la prueba operativa que permite saber si un cambio es útil, tolerable y compatible con un despliegue real.

Una propuesta no es realidad. Una recomendación no es realidad. Una actualización del registro no es realidad. Un documento no es realidad. La realidad aparece cuando los participantes implementan, validan y despliegan el cambio, y basan su operación en él.

La no adopción no crea una condición de infracción. Solo crea un hecho: el participante no se ha incorporado al conjunto de compatibilidad creado por el cambio.

Esto no elimina los procesos de normalización, los registros, la documentación ni la revisión. Limita lo que pueden arrogarse. Pueden ayudar a los participantes a coordinarse. Pueden publicar material de referencia. Pueden describir la adopción. Pueden recomendar. No pueden, por la sola vía de la declaración, hacer que una realidad futura aún no adoptada sea vinculante para los participantes que no la aplican.

8. Relación entre los tres principios

Los tres principios se refuerzan mutuamente y no son eficaces por separado.

La Especificación Inicial Mínima garantiza que la capa común contenga reglas de validación deterministas en lugar de autoridad discrecional.

La Decisión Futura Local garantiza que las decisiones futuras permanezcan en manos de los participantes que ejecutan código en lugar de volver a quedar capturadas por una capa central de aprobación.

La Adopción Voluntaria garantiza que los cambios posteriores deban superar la prueba de la implementación y el uso.

Un sistema que adopte solo uno o dos de estos principios puede reproducir la misma centralización por otros medios.

– La Especificación Inicial Mínima sin Decisión Futura Local puede seguir permitiendo que la autoridad se acumule después del despliegue.
– La Decisión Futura Local sin Especificación Inicial Mínima puede generar ambigüedad, porque los participantes no pueden determinar la validez localmente.
– La Adopción Voluntaria sin validación determinista puede generar confusión, porque los participantes no pueden distinguir una variación compatible de un estado inválido.
– La validación determinista sin posibilidad de salida, portabilidad o sustitución puede seguir generando dependencia forzosa si resulta imposible dejar de utilizar los instrumentos de registro.

Juntos, los principios dan lugar a un sistema en el que la capa común tiene un alcance limitado, la validez puede verificarse localmente, los cambios futuros son voluntarios y no hace falta ninguna institución permanente para decidir sobre el funcionamiento ordinario.

9. Patrón de diseño recomendado

9.1. Capa común determinista

La capa común DEBERÍA limitarse a:

– una semántica estable de los identificadores;
– reglas de validez deterministas;
– reglas de resolución de conflictos necesarias para preservar la unicidad;
– requisitos de interoperabilidad en el formato de comunicación o en el protocolo;
– invariantes de seguridad comunes;
– mecanismos de prueba de control, cuando sean necesarios;
– formatos de registro portables y auditables, cuando los registros sean necesarios;
– señalización de extensiones e identificación de conjuntos de compatibilidad.

La capa común NO DEBERÍA contener:

– reglas sobre modelos de negocio;
– reglas sobre precios;
– preferencias políticas regionales;
– una ideología de elegibilidad ajena a los invariantes técnicos;
– poderes discrecionales para hacer cumplir las reglas;
– valoraciones subjetivas de méritos;
– ampliaciones de la misión institucional;
– cualquier regla cuya función principal sea preservar la autoridad de un órgano ya establecido.

9.2. Ámbito de decisión del operador

Los siguientes aspectos DEBERÍAN permanecer fuera de la capa común, salvo que alteren directamente un Invariante Global declarado:

– el momento del despliegue;
– el uso comercial;
– la ubicación geográfica de los clientes;
– los acuerdos de arrendamiento, financiación o transferencia;
– las preferencias locales de elegibilidad;
– la secuencia de las operaciones;
– las prácticas de enrutamiento no necesarias para la validez compartida;
– el modelo de negocio;
– la estructura organizativa;
– el momento de la migración voluntaria;
– los perfiles o las extensiones opcionales.

Los participantes PUEDEN tomar decisiones diferentes en estos ámbitos. Esas decisiones pueden dar lugar a distintos conjuntos de compatibilidad, relaciones comerciales, acuerdos de interconexión entre pares o comunidades operativas. No generan invalidez a menos que infrinjan las reglas de validación deterministas de un conjunto de compatibilidad.

9.3. Ciclo de adopción

Cuando sea viable, el orden preferible para un cambio sustancial del sistema es:

1. propuesta;
2. implementación;
3. vectores de prueba o método de verificación determinista;
4. despliegue limitado por participantes dispuestos a adoptarlo;
5. observación de los efectos sobre la interoperabilidad y la seguridad;
6. etiquetado del conjunto de compatibilidad;
7. documentación o recomendación que describa la realidad adoptada.

Un instrumento de coordinación DEBERÍA seguir a la adopción en lugar de intentar adelantarse a ella.

9.4. Salida, bifurcación y portabilidad

Un diseño conforme con este documento DEBERÍA tratar la salida, la bifurcación y la portabilidad como requisitos normales de diseño, no como fallos.

El sistema DEBERÍA definir cómo puede un participante:

– seguir en un conjunto de compatibilidad anterior;
– adoptar un conjunto de compatibilidad más reciente;
– crear una bifurcación que dé lugar a un conjunto de compatibilidad diferente;
– trasladar registros, identificadores, pruebas o estado operativo;
– verificar la validez de los registros sin depender de quien lleva el registro establecido;
– interoperar selectivamente cuando la compatibilidad lo permita.

Un sistema que no permita salir de él o crear una bifurcación sin destruir el funcionamiento válido probablemente haya ocultado poder de gobierno dentro de su función registral.

10. Aplicabilidad y límites

Este patrón de diseño es especialmente aplicable cuando:

– el sistema abarca múltiples actores y jurisdicciones;
– el despliegue independiente es importante;
– se pretende que la capa de coordinación mantenga un alcance limitado;
– es probable que haya variaciones futuras, pero no pueden predecirse en detalle;
– la dependencia forzosa crearía un riesgo de gobierno;
– la validez puede hacerse determinista o verificable localmente.

Puede ser menos directamente aplicable cuando:

– la arquitectura prevista consiste en un único dominio administrativo;
– un acoplamiento fuerte en tiempo real exige un comportamiento uniforme en todo momento;
– la protección de la vida humana exige una uniformidad global inmediata;
– ningún mecanismo práctico permite verificar localmente la validez.

Incluso en esos casos, los diseñadores DEBERÍAN seguir reduciendo al mínimo la capa común y evitando el control discrecional futuro siempre que sea posible.

11. Objetivos que quedan fuera del alcance

Este documento no:

– prohíbe toda coordinación;
– prohíbe todos los registros compartidos;
– exige tecnología de cadena de bloques o de registro distribuido;
– garantiza el consenso;
– garantiza la neutralidad política;
– exige que todos los participantes adopten cada cambio posterior;
– trata el rechazo de un cambio como invalidez;
– legitima un comportamiento local incompatible que se presenta como compatible;
– elimina la necesidad de reglas comunes esenciales para la seguridad.

12. Consideraciones de seguridad

Una capa de coordinación de menor alcance puede reducir el riesgo de captura, limitar el alcance de los daños causados por errores institucionales y facilitar su sustitución. Sin embargo, una mayor discrecionalidad local también puede crear medidas de seguridad incoherentes, vías de degradación, presión hacia la fragmentación, afirmaciones ambiguas de compatibilidad y bifurcaciones inseguras.

Por tanto, los diseñadores que apliquen este documento DEBEN especificar explícitamente los invariantes de seguridad. En particular:

– los requisitos de autenticación y autorización necesarios para la validez compartida DEBEN ser deterministas y verificables localmente;
– la negociación de versiones y la gestión de extensiones DEBEN evitar una degradación silenciosa cuando esta afecte a la seguridad;
– las vías de rechazo, bifurcación y sustitución DEBEN analizarse en busca de riesgos de abuso y denegación de servicio;
– las etiquetas de compatibilidad DEBERÍAN ser suficientemente claras para impedir la interoperación accidental entre conjuntos de reglas incompatibles;
– NO DEBE permitirse que una variación local afirme falsamente ser compatible con un conjunto de reglas que no satisface.

La existencia de excepciones de seguridad no justifica una capa general de permisos. Solo justifica las reglas de seguridad deterministas necesarias para preservar los Invariantes Globales declarados.

13. Consideraciones relativas a IANA

Este documento no requiere ninguna actuación de IANA.

14. Referencias

14.1. Referencias normativas

– RFC 2119 — Bradner, S., Palabras clave para indicar niveles de requisito en los RFC, BCP 14, RFC 2119.
– RFC 8174 — Leiba, B., Ambigüedad entre mayúsculas y minúsculas en las palabras clave de RFC 2119, BCP 14, RFC 8174.

14.2. Referencias informativas

– RFC 6709 — Carpenter, B. y B. Aboba, Consideraciones de diseño para las extensiones de protocolos, RFC 6709.
– RFC 7282 — Resnick, P., Sobre el consenso y los zumbidos en la IETF, RFC 7282.

Apéndice A. Lista de comprobación del diseño

Un diseño que declare su conformidad con este documento DEBERÍA poder responder con claridad a las siguientes preguntas:

1. ¿Cuáles son los Invariantes Globales?
2. ¿Qué reglas de validación deterministas preservan esos Invariantes Globales?
3. ¿Qué reglas de la Especificación Inicial son estrictamente necesarias para el primer despliegue?
4. ¿Qué cuestiones futuras se dejan deliberadamente fuera de la capa común?
5. ¿Qué decisiones futuras pueden tomar los participantes sin alterar el conjunto de compatibilidad al que pertenecen?
6. ¿Cómo adopta un participante un cambio posterior?
7. ¿Cómo rechaza un participante un cambio posterior sin que se le atribuya una condición de invalidez?
8. ¿Cómo se etiquetan o descubren los conjuntos de compatibilidad?
9. ¿Cómo funciona el rechazo local cuando un estado es inválido o incompatible conforme a las reglas que aplica un participante?
10. ¿Cuál es la vía para crear una bifurcación?
11. ¿Cuál es la vía de portabilidad?
12. ¿Cuál es la vía para dejar de utilizar cualquier instrumento de coordinación necesario?
13. ¿Pueden los participantes verificar la validez ordinaria sin depender de quien lleva el registro establecido?
14. ¿Los registros y los instrumentos de coordinación describen la realidad adoptada o intentan crear por declaración una realidad futura aún no adoptada?
15. ¿Ha reducido el sistema al mínimo el número de decisiones incorporadas a la capa común?
16. ¿Ha evitado el sistema cualquier autoridad permanente que determine la condición ordinaria de los participantes?

Dirección del autor

H. Lu