Resumen

  • draft-ietf-netconf-error-registries-00 propone dos registros IANA de etiquetas e identidades de error YANG; la revisión inicial sigue incompleta y no convierte un nombre estable en una causa demostrada.
  • La automatización debe conservar sesión, operación, solicitante, decisión de acceso, ruta afectada, identidad con módulo, pistas estructuradas, resultado de la transacción, remedio y comprobación del servicio.

El sistema recibe invalid-value y el motor de reglas decide volver a intentarlo.

Parece una reacción precisa. Hay una etiqueta normalizada y una condición programable. Sin embargo, RESTCONF permite que esa misma etiqueta aparezca con HTTP 400, 404 o 406. Ante recursos protegidos, un servidor puede contestar 404 con invalid-value para no confirmar que el objeto existe. El nombre es correcto, pero la causa permanece deliberadamente oculta.

Esa tensión da importancia a draft-ietf-netconf-error-registries-00, publicado el 30 de septiembre de 2026. El documento activo del grupo NETCONF propone una Lista de Errores de Protocolo YANG y un registro de Identidades de Error YANG. Busca que autores e implementadores no tengan que reconstruir una fuente canónica a partir de varios RFC.

La revisión 00 apunta al Standards Track y vence el 3 de abril de 2027. No es un RFC, un registro IANA aprobado ni evidencia de despliegue. Sus cinco páginas son el comienzo de una superficie de gobierno.

El primer registro guardaría error-tag, error-type, error-severity, error-info, descripción y referencia. El segundo guardaría nombre de identidad, identidad base cuando proceda, información adicional y referencia. Ambos usarían IETF Review.

La ventaja es concreta. Una lista canónica evita variantes, hace descubribles las extensiones, vincula cada valor con la especificación que lo define y permite ordenar altas, cambios, obsolescencia y sustitución. La coordinación mejora cuando todos pueden apuntar al mismo nombre.

Pero la revisión inicial también enseña lo exigente que debe ser esa fuente. Las descripciones de los tres primeros campos siguen marcadas TBD. El borrador dice que el contenido inicial procede del apéndice A del RFC 6241, pero solo inserta cinco etiquetas: in-use, invalid-value, too-big, missing-attribute y bad-attribute. El apéndice continúa con access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed, malformed-message y otras.

La lista de identidades también conserva huellas de edición. Repite filter-unsupported, insufficient-resources y no-such-subscription. Omite identidades de los RFC citados: en RFC 8639 aparecen stream-unavailable, suspension-timeout y unsupportable-volume; en RFC 8641 aparecen cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported y sync-too-big. Además, cita RFC 5226 para la política de registro aunque RFC 8126 es la edición vigente de BCP 26 y la reemplaza.

No son defectos que deban atribuirse a una norma futura. Son hechos de la revisión 00. La inferencia razonable es que el inventario aún necesita unicidad, cobertura, referencias actuales y semántica explícita antes de convertirse en una dependencia fiable.

Supongamos que ese trabajo termina perfectamente. Aun así, el registro no explicaría un incidente.

RFC 6241 permite que una respuesta NETCONF incluya varios <rpc-error>. Cada uno puede indicar capa conceptual, etiqueta de protocolo, gravedad, etiqueta específica del modelo, ruta XPath, mensaje e información estructurada. Esas piezas separan la clasificación general del contexto que permite actuar.

RFC 8640 ofrece un ejemplo directo. filter-unsupported se representa bajo invalid-value; insufficient-resources bajo resource-denied; on-change-unsupported bajo operation-not-supported; sync-too-big bajo too-big; y unchanging-selection bajo operation-failed. La identidad precisa viaja en error-app-tag con el nombre del módulo, como ietf-subscribed-notifications:no-such-subscription.

Incluso esa identidad depende de la operación. La base válida cambia si la RPC intentaba establecer, modificar, borrar, terminar o resincronizar una suscripción. En establecimiento y modificación, error-info puede ofrecer parámetros que harían viable un intento posterior. Una regla que solo conserve la palabra pierde la diferencia entre corregir una solicitud y cambiar una política.

El caso unchanging-selection es especialmente útil. RFC 8641 permite devolverlo cuando la selección apunta a datos inexistentes o a datos que el receptor no está autorizado a leer. También puede usarse cuando un cambio de permisos hace que una selección antes útil ya no produzca actualizaciones visibles. Corregir una ruta, solicitar acceso y reinstalar un filtro tras un cambio de política son acciones distintas. El protocolo las reúne para evitar fugas. La incertidumbre es una propiedad de seguridad.

no-such-subscription preserva el mismo límite. Según RFC 8639, el identificador puede no existir, pertenecer a otro suscriptor o señalar una suscripción configurada a la que esa RPC no se aplica. El servidor comunica el resultado seguro —la operación no puede actuar sobre ese identificador— sin exponer su estado interno.

insufficient-resources tampoco nombra el recurso escaso. Puede haber memoria, CPU, ancho de banda, cola, límite de implementación o cuota de política detrás. El nombre no dice quién controla la capacidad, cuánto durará la presión, qué carga debe ceder ni cuándo conviene reintentar.

Un registro es autoridad sobre palabras, no oráculo sobre sucesos.

El comprobante mínimo comienza antes del fallo: protocolo y sesión, RPC, identificador de solicitud, principal autenticado y decisión de autorización. Conserva datastore y ruta, etiqueta general, identidad con módulo y base, error-info, versión de servidor y módulos, y resultado de transacción. Después registra el cambio aprobado, su lectura posterior y el resultado observado por el servicio.

Sin esta cadena aparecen equivalencias falsas. HTTP 404 no demuestra inexistencia. Una identidad concreta no demuestra una causa física. Una segunda petición aceptada no demuestra que el estado cambió. Un cambio confirmado no demuestra que el servicio se recuperó.

La especificación inicial mínima de Heng Lu encaja bien aquí. La IETF puede compartir un vocabulario pequeño y reglas de extensión. La decisión futura debe quedar en manos de quien posea los hechos posteriores: servidor, operador y dueño del servicio. El registro localiza el gobierno del nombre; no centraliza el juicio sobre cada incidente.

La separación de capas de realidad protege la misma disciplina. operation-failed es un símbolo. El nodo ausente, el permiso retirado, la cola llena o el parámetro imposible son realidades. El símbolo puede cubrir varias de ellas por diseño. Llamar a esa compresión “causa raíz” produce claridad aparente y control equivocado.

La primacía del código en ejecución añade el último recibo. Un reintento no equivale a recuperación. Tampoco basta una escritura aceptada. Hace falta releer el estado y observar el servicio. Solo entonces el remedio deja de ser una intención registrada y se convierte en un hecho operativo.

Fuentes