Nota:64 Especificación inicial mínima, decisión futura localizada y adopción voluntaria para sistemas de coordinación de Internet

Escrito por Lu Heng

|

18 Abril 2026

Director ejecutivo de LARUS Limited y fundador de la Fundación LARUS. Trabaja en la intersección de la infraestructura de Internet, los mercados de direcciones IP y la gobernanza global de Internet, aprovechando la participación directa de los cinco Registros Regionales de Internet. Estas notas tienen como objetivo aclarar cómo se gobiernan los recursos numéricos en la práctica y promover un marco más responsable y resiliente para los activos críticos IP.

Abstracto

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 continua por encima de los participantes que ejecutan el sistema. Define tres principios vinculados: especificación inicial mínima, decisión futura localizada y adopción voluntaria.

Según este modelo, la Especificación Inicial define sólo las reglas deterministas y verificables localmente necesarias para la unicidad, la interoperabilidad, la seguridad compartida y la protección. Después de la Especificación Inicial, los cambios futuros no son aprobados por un organismo central. Son adoptados, ignorados, bifurcados o abandonados por los participantes que ejecutan código.

La no adopción no es una violación. Un participante que no adopta un cambio posterior permanece en su conjunto de compatibilidad existente. Un participante que emite un estado no válido según las reglas deterministas aceptadas por otro participante puede ser ignorado localmente por ese participante. El efecto es selección de compatibilidad, bifurcación, aislamiento o interoperación selectiva, no castigo institucional.

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

1. Introducción

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

Esto suele ocurrir en tres pasos.

Primero, las preguntas futuras se colocan en la capa fundacional antes de que sean técnicamente necesarias.

En segundo lugar, las decisiones que deberían tomar los participantes que administran sus propios sistemas pasan a depender del reconocimiento, la interpretación o las decisiones de estatus por parte de un organismo permanente.

En tercer lugar, la publicación, el registro, la recomendación o la aprobación del procedimiento se consideran suficientes para crear una obligación operativa, incluso cuando los participantes no hayan adoptado el cambio en los sistemas operativos.

El resultado es un sistema frágil. Una capa de referencia técnica se convierte en una capa de gobernanza. Un encargado de registros se convierte en un guardián. Un artefacto 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 sólo las reglas comunes deterministas requeridas para la interoperabilidad básica, la unicidad, la seguridad compartida y la protección.
- Decisión futura localizada:después de la Especificación inicial, mantenga las opciones futuras con los participantes ejecutando el código. Un participante puede adoptar, rechazar, bifurcar, desconectar o interoperar de forma selectiva. Ningún participante puede alterar la interoperabilidad de otros participantes que continúen aplicando reglas mutuamente compatibles.
- Adopción voluntaria:hacer que el cambio posterior sea real solo a través de la implementación, operación, validación y adopción por parte de los participantes que ejecutan el código.

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

La intuición del diseño es simple: la validez debe estar determinada por reglas deterministas que los participantes puedan verificar localmente. Un participante puede adoptar un cambio posterior, rechazarlo, bifurcarlo, desconectarlo o interoperar de forma selectiva. Como máximo, puede eliminarse de un conjunto de compatibilidad. Al rechazar un cambio, no puede romper la interoperabilidad de otros participantes que continúan ejecutando código mutuamente compatible.

Ésta es la misma lección general visible en sistemas como Bitcoin: las reglas de consenso las aplican quienes ejecutan el código de validación, no una institución que esté por encima de ellos.

2. Alcance

Este documento se aplica a los sistemas de coordinación de Internet, incluidos, entre otros, registros compartidos, sistemas de identificación, 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 los actores independientes dependen de un punto de referencia técnico común.

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

Este documento no requiere una cadena de bloques, un libro de contabilidad distribuido ni ninguna tecnología específica. Requiere una propiedad de diseño: los participantes deben poder determinar la validez aplicando la Especificación Inicial localmente, sin pedir permiso o estatus a una autoridad permanente.

3. Convenciones y definiciones

3.1. Requisitos Idioma

Los términos de requisitos en mayúsculas en este documento deben interpretarse en el sentido definido por BCP 14, específicamente 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 la primera implementación de un sistema.

Capa común:
El conjunto mínimo de reglas compartidas o estructura de referencia requerida para que los participantes independientes interoperen. El estrato común no es una institución. Es la sustancia técnica que los participantes implementan y verifican.

Regla de validación determinista:
Regla que permite a un participante decidir, mediante cálculo local o verificación local, si un estado, registro, transición, afirmación o mensaje es válido según un conjunto de reglas específico.

Invariante global:
Una propiedad que debe seguir siendo común dentro de un conjunto de compatibilidad para preservar la unicidad, la interoperabilidad básica, la seguridad compartida o la protección.

Partícipe:
Un operador, implementación, nodo, red, organización u otro actor que ejecuta, verifica, implementa o depende del sistema.

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:
Implementación, despliegue, validación y uso reales por parte de los participantes que ejecutan el sistema.

No adopción:
La elección de un participante de no implementar o utilizar un cambio propuesto. La no adopción no crea un estado inválido. Solo significa que el participante no se ha unido 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 no es válido o incompatible según las reglas de validación que ejecuta.

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

Artefacto de coordinación:
Un documento, entrada de registro, recomendación, nota de implementación, perfil, implementación de referencia u otro artefacto que ayude a los participantes a coordinarse. Un artefacto de coordinación no crea una realidad operativa vinculante a menos que los participantes lo adopten en los sistemas en ejecución.

4. Declaración del problema

Los diseñadores a menudo intentan reducir la incertidumbre futura escribiendo demasiado en la capa fundacional o dejando un cuerpo continuo para interpretar preguntas futuras. Esto parece prudente. Muchas veces es peligroso.

La sobreespecificación en la capa fundacional tiene tres costos.

En primer lugar, traslada las opciones futuras a un nivel común donde el cambio es más difícil y donde la captura tiene un mayor efecto.

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

En tercer lugar, alienta a un organismo que mantiene registros, publica documentos o convoca a participantes a tratar esos actos como autoridad sobre la realidad futura.

El mismo problema aparece después de la implementación. Si un sistema requiere un organismo continuo para aprobar cambios, determinar el estado o interpretar la operación ordinaria, el sistema ha creado una capa de control posterior a la fundación. Esa capa puede comenzar como administración. Puede convertirse en gobernanza. Entonces puede convertirse en un cuello de botella.

El objetivo de diseño de este documento no es una mejor discreción institucional. El objetivo del diseño es evitar la necesidad de esa discreción.

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 las opciones no invariantes fuera de la capa común; y debería permitir que los cambios posteriores se vuelvan reales sólo cuando los participantes los adopten voluntariamente en los sistemas en ejecución.

5. Principio 1: Especificación inicial mínima

5.1. Declaración

Una especificación inicial SHOULD define solo las reglas comunes deterministas mínimas requeridas para la interoperabilidad básica, la unicidad, la seguridad compartida y la protección.

5.2. Requisitos

Un diseño que utiliza este principio:

1. MUST identifica explícitamente sus Invariantes Globales.
2. MUST define reglas de validación deterministas para cada Invariante Global.
3. MUST NOT coloque una regla en la especificación inicial a menos que la regla sea necesaria para preservar una invariante global establecida o para habilitar la primera implementación.
4. MUST separa las reglas de validación de las preferencias políticas, los acuerdos comerciales, los roles institucionales, las aspiraciones de gobernanza y el juicio discrecional.
5. MUST permite a los participantes verificar la validez ordinaria localmente sin preguntar a ninguna institución, registro, comité, organismo político u otra autoridad.
6. SHOULD define estructuras de datos, firmas, pruebas, reglas de transición de estado, reglas de conflicto u otros mecanismos necesarios para la verificación local.
7. SHOULD define la señalización de extensión, el control de versiones, el etiquetado de compatibilidad o la identificación de bifurcaciones cuando se prevean variaciones futuras.
8. MUST garantiza que los artefactos de coordinación requeridos sean portátiles, auditables, reproducibles y reemplazables.
9. SHOULD prefiere condiciones objetivas verificables por máquina al juicio de mérito subjetivo.
10. MUST NOT hacen del futuro reconocimiento institucional el único camino por el cual se puede conocer, registrar o utilizar un estado válido.

5.3. Implicaciones de diseño

La especificación inicial mínima no significa una especificación vaga. Significa una especificación estricta de sólo lo que debe ser común.

Un sistema todavía necesita suficiente estructura común para funcionar. La disciplina consiste en distinguir entre:

- qué debe ser común para lograr unicidad, interoperabilidad, seguridad compartida y protección; y
- lo que puede quedar fuera de la capa común porque tiene que ver con las preferencias del operador, las prácticas comerciales, el momento de implementación o la elección posterior de adopción.

Un diseño que no puede establecer claramente sus Invariantes Globales y sus reglas de validación deterministas debería asumir que ha especificado demasiada discreción y muy poca sustancia verificable.

6. Principio 2: Decisión futura localizada

6.1. Declaración

Después de la especificación inicial, las decisiones futuras SHOULD permanecen locales para los participantes que ejecutan el código. Una Decisión Futura entra en vigor sólo para el conjunto de compatibilidad cuyos participantes la adoptan. No se requiere ninguna autoridad continua para aprobarlo y la no adopción no crea un estado inválido.

6.2. Requisitos

Un diseño que utiliza este principio:

1. MUST NOT requiere que los participantes obtengan permiso de una institución, registro, comité, junta, organismo normativo u otra autoridad titular para realizar elecciones que no alteren las reglas de validación deterministas del conjunto de compatibilidad en el que participan.
2. MUST NOT crean un cuerpo permanente cuyo reconocimiento es el único camino por el cual un cambio posterior puede volverse operativamente real.
3. MUST distingue la validez según la especificación inicial de la compatibilidad con un cambio opcional posterior.
4. MUST NOT trata la no adopción de un cambio posterior como invalidez.
5. MUST permite a los participantes permanecer en un conjunto de compatibilidad existente cuando no adoptan un cambio posterior.
6. MUST permite a los participantes unirse a un nuevo conjunto de compatibilidad adoptando nuevas reglas de validación o perfiles operativos.
7. MUST permite a los participantes rechazar localmente estados, registros, transiciones o mensajes que no sean válidos o incompatibles según las reglas de validación que ejecutan.
8. MUST NOT autoriza a cualquier institución, registro, comité, organismo político u otro actor a declarar inválido a un participante simplemente porque rechazó un cambio posterior.
9. SHOULD hace explícitos los forks, versiones, perfiles o conjuntos de compatibilidad para que los participantes sepan qué reglas están ejecutando y con qué otros participantes pueden interoperar.
10. SHOULD evite cualquier diseño en el que un administrador de registros titular pueda impedir que participantes que de otro modo serían válidos continúen interoperando.

6.3. Implicaciones de diseño

Decisión futura localizada no significa que una autoridad central asigne decisiones futuras a actores locales. Significa que el sistema está diseñado de manera que, después de la Especificación Inicial, las elecciones futuras ordinarias no necesiten dicha asignación.

La Especificación Inicial hace el trabajo limitante por adelantado. Define las invariantes mínimas requeridas para la unicidad, la interoperabilidad, la seguridad compartida y la protección. Todo lo demás queda fuera de la capa común.

Los cambios futuros no se aprueban de forma centralizada. Los participantes que ejecutan código lo adoptan, lo ignoran, lo bifurcan o lo abandonan.

Un participante que rechace un cambio podrá permanecer fuera del conjunto de compatibilidad creado por ese cambio. Puede desconectarse de los demás. Es posible que continúe en un conjunto de compatibilidad anterior. Puede bifurcarse. Puede interoperar selectivamente. Pero no puede romper la interoperabilidad de otros participantes que continúan aplicando reglas mutuamente compatibles.

El efecto de un Estado inválido o incompatible es el rechazo local, no el castigo. Nadie necesita decidir que un participante tiene mala reputación. Un participante que ejecuta reglas de validación compatibles simplemente no acepta el estado no válido o incompatible.

7. Principio 3: Adopción Voluntaria

7.1. Declaración

Los cambios en un sistema de coordinación de Internet SHOULD se vuelven operacionalmente reales a través de la implementación, validación, despliegue y adopción por parte de los participantes, no solo a través de la publicación o declaración.

7.2. Requisitos

Un diseño que utiliza este principio:

1. MUST NOT trata la publicación, el registro, la recomendación, la aprobación de la reunión o la aprobación del procedimiento como suficiente para crear una obligación operativa universal.
2. MUST permite que los participantes que decidan ejecutarlos implementen nuevas reglas, extensiones, perfiles o procedimientos de forma incremental.
3. MUST permite a los participantes rechazar un cambio posterior sin adquirir un estado no válido, siempre que sus propias transiciones de estado satisfagan las reglas de validación deterministas de su conjunto de compatibilidad.
4. MUST permite a los participantes continuar usando un conjunto de compatibilidad anterior donde la especificación inicial permite dicha continuidad.
5. MUST permite a los participantes que ejecutan un conjunto de compatibilidad rechazar o ignorar localmente el estado de otro conjunto de compatibilidad donde las reglas son incompatibles.
6. SHOULD define rutas de adopción para cambios importantes, incluida la señalización de versión, el etiquetado de compatibilidad, la guía de transición y los vectores de prueba.
7. SHOULD define rutas de rechazo para cambios importantes, incluida la forma en que los participantes que no adoptan continúan la operación, identifican su conjunto de compatibilidad y evitan la interoperación ambigua.
8. MUST garantiza que los artefactos de coordinación necesarios se puedan salir, migrar, duplicar, reimplementar o reemplazar sin costos de transición imposibles.
9. SHOULD tiene registros, registros, recomendaciones y artefactos de coordinación que describen la realidad adoptada en lugar de declarar la existencia de una realidad futura no adoptada.
10. MUST evite diseñar un sistema en el que la única manera de que un cambio se haga realidad sea el reconocimiento previo por parte de un organismo competente.

7.3. Implicaciones de diseño

La adopción voluntaria es la prueba operativa de si un cambio es útil, tolerable y compatible con una implementación real.

Una propuesta no es la realidad. Una recomendación no es la realidad. Una actualización del registro no es una realidad. Un documento no es la realidad. La realidad aparece cuando los participantes implementan, validan, implementan y confían en el cambio.

La no adopción no crea ningún estado de violación. Solo crea un hecho: el participante no se ha unido al conjunto de compatibilidad creado por el cambio.

Esto no elimina los procesos, registros, documentación o revisión de estándares. Limita su reclamo. Pueden ayudar a los participantes a coordinarse. Podrán publicar material de referencia. Pueden describir la adopción. Quizás lo recomienden. No pueden, mediante una sola declaración, hacer que una realidad futura no adoptada sea vinculante para los participantes que no la dirigen.

8. Relación entre los tres principios

Los tres principios se refuerzan mutuamente y no son eficaces de forma aislada.

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 localizada garantiza que las opciones futuras permanezcan en manos de los participantes que ejecutan el código en lugar de ser recuperadas por una capa de aprobación central.

La adopción voluntaria garantiza que los cambios posteriores sobrevivan al contacto con la implementación y el uso.

Un sistema que adopte sólo 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 localizada aún puede permitir que se acumule autoridad después de la implementación.
- La decisión futura localizada sin especificación inicial mínima puede producir ambigüedad, porque los participantes no pueden determinar la validez localmente.
- La adopción voluntaria sin validación determinista puede producir confusión, porque los participantes no pueden distinguir la variación compatible del estado no válido.
- La validación determinista sin salida, portabilidad o reemplazabilidad aún puede producir bloqueo si los artefactos del mantenimiento de registros se vuelven imposibles de abandonar.

Juntos, los principios producen un sistema en el que la capa común es delgada, la validez es verificable localmente, el cambio futuro es voluntario y no se necesita ninguna institución permanente para decidir el funcionamiento ordinario.

9. Patrón de diseño recomendado

9.1. Capa común determinista

La capa común SHOULD se limitará a:

- semántica de identificador estable;
- reglas de validez deterministas;
- reglas de resolución de conflictos necesarias para preservar la unicidad;
- requisitos de interoperabilidad a nivel de cable o de protocolo;
- invariantes de seguridad compartidas;
- mecanismos de prueba de control, cuando sea necesario;
- formatos de registros portátiles y auditables, cuando los registros sean necesarios;
- señalización de extensión e identificación del conjunto de compatibilidad.

La capa común SHOULD NOT contiene:

- normas de modelo de negocio;
- reglas de fijación de precios;
- preferencias políticas regionales;
- ideología de elegibilidad no relacionada con invariantes técnicas;
- poderes discrecionales de ejecución;
- valoraciones subjetivas de méritos;
- ampliación de la misión institucional;
- cualquier norma cuya función principal sea preservar la autoridad de un organismo en ejercicio.

9.2. Superficie de decisión del operador

Los siguientes SHOULD permanecen fuera de la capa común a menos que alteren directamente un Invariante Global declarado:

- calendario de despliegue;
- uso comercial;
- geografía del cliente;
- acuerdos de arrendamiento, financiación o transferencia;
- preferencia de elegibilidad local;
- secuenciación operativa;
- no se requiere práctica de enrutamiento para la validez compartida;
- modelo de negocio;
- estructura organizativa;
- calendario de migración voluntaria;
- perfiles o extensiones opcionales.

Los participantes MAY adoptan diferentes opciones en estas áreas. Esas elecciones pueden producir diferentes conjuntos de compatibilidad, relaciones comerciales, acuerdos de peering o comunidades operativas. No crean invalidez a menos que violen reglas de validación deterministas en un conjunto de compatibilidad.

9.3. Bucle de adopción

Cuando sea posible, el orden preferido para el cambio del sistema de materiales es:

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

Un artefacto de coordinación SHOULD sigue a la adopción en lugar de intentar adelantarse a ella.

9.4. Salida, bifurcación y portabilidad

Un diseño conforme SHOULD trata la salida, la bifurcación y la portabilidad como requisitos de diseño normales en lugar de fallas.

El sistema SHOULD define cómo un participante puede:

- continuar en un conjunto de compatibilidad anterior;
- adoptar un conjunto de compatibilidad más nuevo;
- bifurcarse en un conjunto de compatibilidad diferente;
- registros, identificadores, pruebas o estado operativo del puerto;
- verificar la validez de los registros sin depender de un encargado de registros titular;
- interoperar selectivamente cuando la compatibilidad lo permita.

Un sistema del que no se puede salir ni bifurcar sin destruir una operación válida probablemente tenga un poder de gobernanza oculto dentro de su función de mantenimiento de registros.

10. Aplicabilidad y límites

Este patrón de diseño es particularmente aplicable donde:

- el sistema es multiactor y multijurisdiccional;
- cuestiones de despliegue independiente;
- la capa de coordinación debe permanecer delgada;
- es probable que haya variaciones futuras, pero no se pueden predecir en detalle;
- el bloqueo crearía un riesgo de gobernanza;
- la validez puede hacerse determinista o verificable localmente.

Puede ser menos directamente aplicable cuando:

- la arquitectura prevista es un dominio administrativo único;
- un fuerte acoplamiento en tiempo real requiere un comportamiento uniforme en todo momento;
- las preocupaciones por la seguridad humana requieren una uniformidad global inmediata;
- la validez no puede verificarse localmente mediante ningún mecanismo práctico.

Incluso en tales casos, los diseñadores SHOULD aún minimizan la capa común y evitan el control futuro discrecional siempre que sea posible.

11. No metas

Este documento no:

- prohibir toda coordinación;
- prohibir todos los registros compartidos;
- requerir tecnología blockchain o de contabilidad distribuida;
- garantizar el consenso;
- garantizar la neutralidad política;
- exigir a todos los participantes que adopten todos los cambios posteriores;
- tratar la negativa a adoptar como nulidad;
- legitimar comportamientos locales incompatibles reivindicando al mismo tiempo compatibilidad;
- eliminar la necesidad de normas comunes críticas para la seguridad.

12. Consideraciones de seguridad

Una capa de coordinación más delgada puede reducir el riesgo de captura, disminuir el radio de error institucional y mejorar la reemplazabilidad. Sin embargo, una mayor discreción local también puede crear una postura de seguridad inconsistente, rutas de degradación, presión de fragmentación, afirmaciones de compatibilidad ambiguas y bifurcaciones inseguras.

Por lo tanto, los diseñadores que aplican este documento MUST especifican explícitamente las invariantes de seguridad. En particular:

- los requisitos de autenticación y autorización necesarios para la validez compartida MUST sean deterministas y verificables localmente;
- la negociación de versiones y el manejo de extensiones MUST evitan una degradación silenciosa cuando la seguridad se ve afectada;
- las rutas de rechazo, bifurcación y reemplazo MUST se analizarán para detectar riesgos de abuso y denegación de servicio;
- las etiquetas de compatibilidad SHOULD sean lo suficientemente claras para evitar la interoperación accidental entre conjuntos de reglas incompatibles;
- Se permitirá que la variación local MUST NOT afirme falsamente compatibilidad con un conjunto de reglas que no cumple.

La existencia de excepciones de seguridad no justifica una capa de permiso general. Sólo justifica las reglas de seguridad deterministas necesarias para preservar las Invariantes Globales declaradas.

13. Consideraciones sobre IANA

Este documento no tiene acciones IANA.

14. Referencias

14.1. Referencias normativas

- RFC 2119 — Bradner, S., Palabras clave para usar en RFCs para indicar niveles de requisitos, BCP 14, RFC 2119.
- RFC 8174 — Leiba, B., Ambigüedad entre mayúsculas y minúsculas en palabras clave RFC 2119, BCP 14, RFC 8174.

14.2. Referencias informativas

- RFC 6709 — Carpintero, B. y B. Aboba, Consideraciones de diseño para extensiones de protocolo, RFC 6709.
- RFC 7282 — Resnick, P., Sobre el consenso y el tarareo en el IETF, RFC 7282.

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

Un diseño que afirme conformidad con este documento SHOULD podrá responder claramente a las siguientes preguntas:

1. ¿Qué son las invariantes globales?
2. ¿Qué reglas de validación deterministas preservan esas Invariantes Globales?
3. ¿Qué reglas de la Especificación inicial son estrictamente necesarias para la primera implementación?
4. ¿Qué cuestiones futuras quedan intencionalmente fuera de la capa común?
5. ¿Qué decisiones futuras pueden tomar los participantes sin alterar el conjunto de compatibilidad en el que se encuentran?
6. ¿Cómo adopta un participante un cambio posterior?
7. ¿Cómo puede un participante rechazar un cambio posterior sin que se le asigne el estatus de no válido?
8. ¿Cómo se etiquetan o descubren los conjuntos de compatibilidad?
9. ¿Cómo funciona el rechazo local cuando el estado no es válido o es incompatible según las reglas que ejecuta un participante?
10. ¿Cuál es el camino de bifurcación?
11. ¿Cuál es el camino de la portabilidad?
12. ¿Cuál es la ruta de salida de cualquier artefacto de coordinación requerido?
13. ¿Pueden los participantes verificar la validez ordinaria sin depender de un registrador titular?
14. ¿Los registros y los artefactos de coordinación describen la realidad adoptada o intentan declarar la existencia de una realidad futura no adoptada?
15. ¿Ha minimizado el sistema el número de decisiones integradas en la capa común?
16. ¿Ha evitado el sistema cualquier autoridad continua que determine el estatus de participante ordinario?

## Dirección del autor

H. Lu
[TBD]