Versionado del Estándar LM
Define el sistema de versionado del Estándar LM: cómo se nombran las versiones, qué tipo de cambios generan cada nivel, quién tiene autoridad para aprobar cambios, cómo se documenta y publica cada versión, y cómo se gestiona la compatibilidad entre versiones.
1. Propósito y Alcance
Ámbito de aplicación: el Estándar LM completo (LM-STD-01 a LM-STD-05 y todos los documentos que se agreguen en versiones futuras), los JSON Schema formales publicados en estandar.luvameta.com/schemas/, y los procedimientos internos LM-PI-001 y LM-PO-001 cuando incorporen cambios derivados del estándar.
2. Nomenclatura de Versiones
El Estándar LM usa un sistema de versionado semántico adaptado de los principios de Semantic Versioning (semver.org) al contexto de un estándar de certificación:
Designación abreviada
En los documentos del estándar, los esquemas y las referencias externas se usará la versión abreviada MAYOR.MENOR cuando el patch no sea relevante para la compatibilidad:
3. Tipos de Cambio y su Impacto en el Número de Versión
MAYOR — Cambio que rompe compatibilidad
Un cambio de versión MAYOR indica que la nueva versión no es retroactivamente compatible con la anterior. Las implementaciones existentes necesitan ser actualizadas. Los certificados emitidos bajo la versión anterior siguen siendo válidos bajo sus propios términos, pero el proceso de emisión de nuevos certificados DEBE seguir la versión vigente.
Ejemplos de cambios MAYOR:
- Agregar un campo requerido (DEBE) al JSON del certificado — los certificados existentes sin ese campo no pasarían la validación del nuevo esquema.
- Cambiar el algoritmo de hash de SHA-256 a otro — invalida todos los hashes existentes.
- Cambiar el formato del challenge — invalida todos los archivos
.well-known/existentes. - Eliminar una categoría de identidad del vocabulario controlado.
- Cambiar el formato del
cert_id— invalida todos los identificadores existentes.
Compatibilidad retroactiva: NO garantizada. Requiere plan de migración obligatorio publicado junto con la nueva versión.
MENOR — Nueva capacidad compatible
Un cambio de versión MENOR introduce nuevas capacidades, campos opcionales o nuevas categorías sin romper la compatibilidad con implementaciones existentes. Los certificados emitidos bajo la versión anterior siguen siendo plenamente válidos.
Ejemplos de cambios MENOR:
- Agregar un nuevo campo opcional (DEBERÍA o PUEDE) al JSON del certificado.
- Agregar una nueva categoría de identidad al vocabulario controlado.
- Definir un nuevo mecanismo de verificación adicional como alternativa al
.well-known/. - Agregar un nuevo documento LM-STD al conjunto del estándar.
- Ampliar el conjunto de estados válidos de un componente sin eliminar los existentes.
Compatibilidad retroactiva: Garantizada. Certificados e implementaciones existentes siguen siendo conformes sin modificación.
PATCH — Corrección o aclaración
Un cambio de versión PATCH corrige errores tipográficos, aclara ambigüedades en la redacción, agrega ejemplos adicionales o mejora la explicación de criterios existentes sin cambiar su comportamiento normativo. Los PATCH nunca modifican requisitos DEBE, NO DEBE ni vocabularios controlados.
Ejemplos de cambios PATCH:
- Corrección de un error tipográfico en el nombre de un campo.
- Aclaración de la redacción de un criterio DEBE sin cambiar su significado.
- Agregado de ejemplos adicionales en la tabla de errores frecuentes.
- Corrección de una URL de ejemplo incorrecta.
Compatibilidad retroactiva: Garantizada. Sin impacto en implementaciones ni en certificados existentes.
4. Proceso de Aprobación y Publicación de Versiones
4.1 Autoridades según el tipo de cambio
| Tipo de cambio | Quién puede proponerlo | Quién lo aprueba y publica |
|---|---|---|
| PATCH | Cualquier portal territorial, nodo territorial o el nodo raíz. | El nodo raíz. Puede aprobarse internamente sin periodo de consulta si el cambio es una corrección obvia de error. |
| MENOR | Cualquier portal territorial, nodo territorial o el nodo raíz. | El nodo raíz. Requiere documentación del cambio propuesto, evaluación de impacto y periodo de consulta de 15 días antes de la publicación. |
| MAYOR | Solo el nodo raíz puede proponer cambios MAYOR. | El nodo raíz. Requiere documentación completa, evaluación de impacto, plan de migración, periodo de consulta de 30 días y periodo de transición de mínimo 90 días. |
4.3 Periodos de consulta y transición
| Tipo | Periodo de consulta | Periodo de transición | Qué ocurre en la transición |
|---|---|---|---|
| PATCH | No requerido | Vigencia inmediata | La corrección entra en vigor en la fecha de publicación. Sin impacto operativo. |
| MENOR | 15 días calendario | 30 días desde publicación | Durante 30 días tanto la versión anterior como la nueva son consideradas conformes. Al día 31 solo la nueva versión es vigente. |
| MAYOR | 30 días calendario | Mínimo 90 días desde publicación | Durante el periodo de transición ambas versiones coexisten. Se publica el plan de migración con instrucciones por tipo de implementación. |
5. Declaración de Conformidad con una Versión
5.2 Declaración en los registros JSON de certificados
Los certificados DEBERÍAN incluir un campo lm_version que declare la versión del estándar bajo la que fueron emitidos. Este campo es opcional en la versión 1.0 pero se volverá obligatorio en versiones futuras:
5.3 URLs de los documentos del estándar
| Documento | Versión actual | URL del documento vigente |
|---|---|---|
| LM-STD-01 | 1.0 | estandar.luvameta.com/std/lm-std-01-v1.html |
| LM-STD-02 | 1.0 | estandar.luvameta.com/std/lm-std-02-v1.html |
| LM-STD-03 | 1.0 | estandar.luvameta.com/std/lm-std-03-v1.html |
| LM-STD-04 | 1.0 | estandar.luvameta.com/std/lm-std-04-v1.html |
| LM-STD-05 | 1.0 | estandar.luvameta.com/std/lm-std-05-v1.html |
| JSON Schema certificado | v1 | estandar.luvameta.com/schemas/certification_record_v1.json |
6. Reglas de Compatibilidad Retroactiva
| El estándar garantiza | El estándar NO garantiza |
|---|---|
| Un certificado válido bajo LM v1.0 seguirá siendo válido bajo cualquier LM v1.x. | Un certificado válido bajo LM v1.0 será válido bajo LM v2.0. Los cambios MAYOR no garantizan compatibilidad. |
| Las URLs de las versiones publicadas permanecerán estables y accesibles. | Las nuevas capacidades de versiones MENOR estarán disponibles en implementaciones de versiones anteriores. |
| Los vocabularios controlados no perderán valores existentes en versiones MENOR. | Los PATCH resolverán problemas de diseño — solo corrigen errores evidentes. |
| El JSON Schema de cada versión permanecerá disponible para validación. | Los portales podrán ignorar los cambios MENOR indefinidamente — tienen 30 días de transición. |
| Los certificados existentes no serán invalidados por versiones MENOR o PATCH. |
| Nivel de versión | Compatibilidad garantizada | Regla de compatibilidad |
|---|---|---|
| PATCH | Total | Un sistema conforme con LM v1.0.0 es automáticamente conforme con LM v1.0.N para cualquier N. |
| MENOR | Hacia atrás | Un sistema conforme con LM v1.0 es conforme con LM v1.N para cualquier N en el sentido de que sus implementaciones existentes son válidas. |
| MAYOR | No garantizada | Un cambio de versión MAYOR no garantiza compatibilidad retroactiva. El plan de migración publicado con la nueva versión MAYOR define el camino de actualización. |
7. Registro de Cambios del Estándar
El Estándar LM mantiene un registro público de todos los cambios aprobados, incluyendo los rechazados con su fundamento. Accesible en estandar.luvameta.com/changelog.
Cada entrada del registro de cambios DEBE contener: change_id (formato: LM-CHG-AAAA-NNN), tipo (MAYOR/MENOR/PATCH), versión anterior y nueva, fechas de propuesta, aprobación y vigencia, documentos afectados, descripción, motivación, impacto en implementadores, impacto en certificados y estado (PROPUESTO/EN_CONSULTA/APROBADO/RECHAZADO/VIGENTE).
8. Estado Actual del Estándar LM
| Parámetro | Valor |
|---|---|
| Versión vigente | 1.0.0 |
| Fecha de publicación | 2026 |
| Estado | VIGENTE — Versión inicial del Estándar LM. |
| Documentos incluidos | LM-STD-01 (Vocabulario Normativo), LM-STD-02 (JSON Schema), LM-STD-03 (Protocolo de Verificación), LM-STD-04 (Modelo de Estados), LM-STD-05 (Versionado). |
| Compatibilidad retroactiva | No aplica — es la versión inicial. Toda versión 1.x garantizará compatibilidad con los certificados emitidos bajo la versión 1.0. |
| Cambios registrados | Ninguno — versión inicial del estándar. |
| URL del estándar vigente | estandar.luvameta.com |
| URL del registro de cambios | estandar.luvameta.com/changelog |
Hoja de ruta — capacidades previstas para versiones futuras
| Capacidad prevista | Tipo estimado | Descripción |
|---|---|---|
Campo lm_version obligatorio | MENOR | El campo lm_version en el JSON del certificado pasaría de DEBERÍA a DEBE en una versión 1.x. |
| Integración de vocabulario schema.org | MENOR | Incorporación de campos de schema.org como capa de vocabulario complementario dentro del bloque subject. |
| Nuevas categorías de identidad | MENOR | Incorporación de nuevas categorías al vocabulario controlado de "category" según emerjan necesidades del ecosistema. |
| Mecanismo de verificación alternativo | MENOR | Definición de un segundo método de verificación de dominio como alternativa al .well-known/ para dominios con restricciones técnicas. |
| Modelo de suspensión de nodos | MENOR | Definición de estados de salida para nodos territoriales ACTIVE, actualmente no definidos en la versión 1.0. |
| Certificación multi-dominio | MAYOR | Posibilidad de que un certificado cubra más de un dominio bajo el mismo operador. Implicaría cambios estructurales en el JSON del certificado. |
9. Resumen del Estándar LM v1.0 — Índice de Documentos
| Documento | Título | Función | Lo que especifica |
|---|---|---|---|
| LM-STD-01 | Vocabulario Normativo | Fundacional | Significado y nivel de obligatoriedad de todos los términos normativos. Base de interpretación de los demás documentos. |
| LM-STD-02 | JSON Schema del Certificado | Técnico central | Schema formal del objeto de certificación. Tipos, patrones, enums y restricciones de cada campo. Errores frecuentes y ejemplos de validación. |
| LM-STD-03 | Protocolo de Verificación de Dominio | Operativo | Estructura del challenge, algoritmo de hash, especificación del archivo .well-known/, flujo de verificación y casos de error. |
| LM-STD-04 | Modelo de Estados y Transiciones | Arquitectónico | Estados válidos de certificados, nodos y portales. Todas las transiciones permitidas y prohibidas. Reglas de registro. |
| LM-STD-05 | Versionado del Estándar LM | Gobernanza | Nomenclatura de versiones, tipos de cambio, proceso de aprobación, compatibilidad retroactiva y registro de cambios. |
10. Control del Documento
| Versión | Fecha | Descripción | Autorizado por |
|---|---|---|---|
| 1.0 | 2026 | Versión inicial. Define el sistema de versionado semántico del Estándar LM, los tres tipos de cambio (MAYOR, MENOR, PATCH), el proceso de aprobación y publicación, las reglas de compatibilidad retroactiva, la estructura del registro de cambios y el estado actual del estándar con su hoja de ruta. | Nodo Raíz |