Resumen

  • RFC 6643 permite leer objetos SMIv2 mediante NETCONF después de convertir sus módulos MIB a YANG. No crea automáticamente nodos de configuración a partir de todos los objetos que antes admitían escritura.
  • El problema incluye dónde se define la persistencia: en SNMP puede depender del objeto o de su fila; en NETCONF depende de las propiedades del almacén de configuración.
  • Las desviaciones documentadas permiten habilitar casos concretos con semánticas compatibles. La cobertura de lectura no demuestra que todas las tareas de control hayan abandonado la herramienta anterior.

El presupuesto termina antes que la dependencia

Una migración puede llegar al cierre administrativo con un resultado técnicamente correcto y una obligación todavía pendiente. El panel nuevo muestra los datos previstos, las consultas funcionan y los usuarios reconocen sus objetos. Sin embargo, para efectuar cierto cambio aún hay que abrir la herramienta que el proyecto pretendía sustituir.

Este supuesto sirve para distinguir dos entregas, no para describir un incidente real. Una entrega incorpora observaciones a una interfaz común. La otra traslada la capacidad de modificar el sistema bajo unas condiciones conocidas. Que la primera esté terminada no obliga a que la segunda lo esté, aunque ambas compartan nombre de proyecto.

La diferencia aparece de forma explícita en RFC 6643. El documento, publicado en julio de 2012, define una conversión automática de módulos SMIv2 a YANG destinada al acceso de solo lectura a través de NETCONF. Su alcance limitado no es un fallo que el integrador deba disimular. Es parte del acuerdo técnico.

Puede ser razonable comprar precisamente esa capacidad. Un operador quizá quiera renovar sus aplicaciones de consulta sin rediseñar de inmediato todos los procedimientos de administración. Lo que necesita evitar es que la aceptación de una vista nueva se convierta, sin otra evidencia, en autorización para eliminar el medio que sigue ejecutando cambios.

Qué puede conservar una conversión

Los módulos SMIv2 contienen más que nombres y tipos. Incluyen descripciones, referencias, identificadores de objetos y declaraciones de acceso. RFC 6643 establece cómo representar esa información en YANG; por ello, el resultado puede conservar mucho conocimiento del modelo de origen.

Un ejemplo importante es MAX-ACCESS. Si el objeto original está marcado como read-write o read-create, la conversión puede conservar esa declaración mediante smiv2:max-access. Pero el contenedor superior generado para los objetos queda clasificado como config false. La información sobre el acceso original no anula la clasificación de los datos en el destino.

Eso permite que dos afirmaciones sean ciertas al mismo tiempo: el origen definía una posibilidad de escritura, y el modelo convertido expone el objeto como dato de estado. No hay motivo para deducir que el servidor nuevo dispone ya de la operación correspondiente solo porque la declaración antigua resulte visible.

La distinción es valiosa también para la documentación de entrega. «Se ha conservado la descripción de acceso» se comprueba inspeccionando el modelo. «Esta tarea se puede ejecutar por el nuevo canal» exige conocer la implementación y el procedimiento. Un inventario que llama soporte a ambas cosas pierde la precisión necesaria para decidir qué dependencia ha desaparecido.

Tampoco conviene exagerar en sentido contrario. La conversión no borra toda la semántica de SMIv2. Parte de ella permanece como información descriptiva o como extensiones. El límite consiste en que conservar una explicación no equivale a convertirla automáticamente en comportamiento de configuración.

La persistencia tiene una dirección concreta

La sección 11 de RFC 6643 identifica el obstáculo central. En SNMP, la persistencia puede estar definida en la descripción del objeto o en las propiedades de la fila conceptual a la que pertenece. En algunos casos interviene una columna que utiliza la convención textual StorageType. En NETCONF, las propiedades del almacén de configuración determinan el contrato relevante.

Por tanto, el traductor no recibe una única instrucción universal que pueda copiar. Necesita reconciliar compromisos situados en lugares distintos. No basta con encontrar un campo de nombre parecido y asignarle el mismo valor.

La definición de StorageType en RFC 2579 ilustra el detalle que se perdería con una conversión indiscriminada. Una fila volátil desaparece al reiniciar. Otras clases cuentan con almacenamiento estable, pero no permiten las mismas modificaciones. Una fila permanent se puede cambiar, aunque no borrar; una readOnly no admite ninguna de las dos acciones. El valor de la propia columna de almacenamiento también tiene restricciones.

La palabra permanente no convierte, pues, cada celda en inmutable. Y el hecho de que algo esté almacenado de forma estable no concede autoridad a cualquier usuario para modificarlo. Son propiedades diferentes que una interfaz compacta puede presentar juntas, pero que la aceptación de una migración debe mantener separadas.

En el destino, RFC 6241 tampoco ofrece una promesa genérica de que cualquier escritura sobrevivirá. El modelo básico incluye la configuración en ejecución, running. Los almacenes adicionales dependen de capacidades anunciadas. La escritura directa sobre running requiere su capacidad correspondiente.

Cuando el dispositivo admite un almacén de arranque distinto, una modificación de la configuración en ejecución no se copia allí automáticamente. Actualizar startup a partir de running es una operación explícita. El análisis debe, por tanto, identificar el destino de la escritura y no deducir durabilidad del nombre NETCONF.

Estas reglas no son una recomendación para reiniciar equipos en producción. Explican qué promesa debe documentarse antes de considerar equivalente una tarea. Una lectura inmediatamente posterior puede mostrar el mismo valor en dos sistemas con expectativas distintas para el siguiente arranque.

Además, las operaciones de edición y copia de configuración de RFC 6241 no son un mecanismo general para modificar cualquier estado operacional. El inventario de valores consultables es más amplio que una lista de órdenes que deberían reproducirse. Clasificar el objeto es anterior a decidir cómo trasladar su escritura.

El caso especial no autoriza el cambio masivo

La norma deja una salida para determinados objetos. Cuando sus semánticas de persistencia son compatibles, la implementación puede exponer algunos nodos generados como datos de configuración. Esa desviación respecto al resultado de solo lectura debería documentarse mediante un módulo YANG separado.

RFC 6643 contempla específicamente que cambiar config false a true, sin otros cambios semánticos, no altere la conformidad con el módulo generado. Esa condición no demuestra que todos los objetos cumplan el requisito. Habilita una decisión delimitada, no una sustitución automática de todos los indicadores.

El ejemplo de una tabla de control RMON2 muestra cómo identificar distintos niveles y nodos y anunciar los módulos, revisiones y desviaciones utilizados. La propia explicación advierte que una desviación afecta a su nodo de destino: no debe tratarse como una promoción indiferenciada de toda la estructura que queda debajo.

Esto debe distinguirse de las reglas normales de herencia cuando falta una declaración config. RFC 7950, la especificación posterior de YANG 1.1, describe esa herencia, impide situar configuración bajo un nodo de estado y exige que el modelo siga siendo válido tras aplicar las desviaciones anunciadas. Para entender una capacidad hace falta el esquema efectivo, no una línea aislada del archivo base.

La excepción localizada tiene una ventaja práctica. Permite trasladar tareas cuyo significado se ha reconciliado y conservar el resto en el canal anterior. No exige que toda la organización acepte una promesa homogénea de persistencia para obtener valor de una pequeña parte de la migración.

Una modificación necesita una genealogía

RFC 6643 recomienda mantener las correcciones en el SMIv2 de origen, actualizar la información de revisión y volver a generar el YANG, en vez de editar directamente el resultado. Las ampliaciones y desviaciones separadas siguen siendo posibles.

Esta separación identifica quién es la fuente de cada decisión. Si alguien modifica el archivo generado sin conservar el motivo, una nueva generación puede borrar la particularidad que la implementación necesitaba. Si se mantiene solo el origen y no las desviaciones entregadas, el siguiente equipo podría reconstruir un modelo válido que no describe el dispositivo que administra.

El problema no consiste necesariamente en falta de archivos. Puede haber muchos archivos y faltar la relación entre ellos. Una entrega basada en la memoria de quien realizó la integración funciona mientras esa persona siga disponible. No constituye por sí misma una capacidad transferible a otro equipo.

La errata técnica verificada 4786 permite observar una corrección de alcance mucho menor. Verificada en agosto de 2016, evita una hoja duplicada en una traducción de notificaciones cuando el objeto actual ya forma parte del índice. Corrige la estructura generada; no concede escritura ni modifica las garantías de conservación.

Una corrección así justifica revisar el caso afectado del convertidor. No justifica afirmar que el sistema entero ha superado una prueba operacional. Del mismo modo, la ficha pública de RFC 6643 sitúa el documento y su publicación, pero no acredita una implementación concreta.

Convivencia elegida o deuda no reconocida

Mantener un canal de observación nuevo y otro de escritura antiguo puede ser una elección sensata. La cuestión es si esa convivencia tiene responsable y presupuesto, o si se ha transformado en un resto que nadie considera parte del producto.

Las tareas infrecuentes son especialmente fáciles de perder en un informe de cobertura. Apenas contribuyen al volumen de consultas, aunque puedan ser necesarias para la continuidad del servicio. Sus credenciales, conocimientos, condiciones de acceso y reglas de conservación requieren mantenimiento mientras la obligación subsista.

La inferencia económica es que el ahorro debe calcularse sobre funciones realmente retiradas, no sobre pantallas que ya no se abren cada mañana. Una consulta migrada puede reducir un coste real. No elimina necesariamente el coste de conservar el instrumento que seguirá siendo necesario para actuar.

El acceso de solo lectura también conserva un límite de seguridad propio. RFC 6643 remite a la sensibilidad de los objetos de las MIB originales y a los controles de acceso. Que el modelo no permita modificar un valor no implica que divulgarlo sea inocuo. Observar y cambiar siguen necesitando decisiones diferenciadas.

Alcance de la evidencia

Este análisis utiliza la distinción de Lu Heng entre representación y poder ejecutable y su examen del control separado de sus consecuencias. Aplicar esa perspectiva a la migración de gestión es una inferencia de Daniel Kade, no una evaluación de estos protocolos atribuible a Lu Heng.

Las fuentes establecen reglas de conversión, almacenamiento y configuración, además de una corrección verificada. No aportan cifras de adopción, ahorros medidos, incidentes ni conformidad de proveedores. No se modificó ningún dispositivo ni se realizó una prueba de protocolo para este artículo. Las decisiones de retirada requieren pruebas particulares del sistema y de las tareas que se pretende sustituir.