Resumen

  • draft-fedyk-netmod-yang-normal-form-00 propone conservar la representación léxica original y derivar otra forma determinista para igualdad, claves de lista y unicidad de leaf-lists de configuración.
  • En el ejemplo MAC, dos puntos o guiones y letras hexadecimales en mayúscula o minúscula producen el mismo valor comparativo de doce dígitos. pattern valida la sintaxis; no define la igualdad entre cadenas válidas.
  • Datatracker lo registra como Internet-Draft individual activo, sin estado RFC previsto y con estado IESG I-D Exists. El encabezado interno dice Intended status: Standards Track. No hay prueba de adopción por NETMOD ni de respaldo del IETF.

Guardar la grafía sin usarla como identidad

Dos plataformas de gestión pueden representar la misma dirección de 48 bits con textos diferentes. El tipo común del IETF en el RFC 6991 y su revisión vigente RFC 9911 usa octetos separados por dos puntos y describe la minúscula como forma canónica. El tipo IEEE mostrado en materiales del IETF usa guiones y describe la mayúscula. La persona reconoce una dirección; una clave string sigue viendo caracteres distintos.

La revisión 00 divide esas funciones. El valor léxico recibido se conserva para codificación y consulta. Una extensión optativa normalized-form señala un algoritmo determinista cuyo resultado rige = y !=, la unicidad de las claves de lista y la de los leaf-lists de configuración.

El procedimiento mac-48 primero valida la entrada con su tipo. Después elimina separadores, convierte los dígitos hexadecimales a mayúscula y usa los doce restantes. aa:bb:cc:dd:ee:ff, AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff y AA-BB-CC-DD-EE-FF derivan así AABBCCDDEEFF. El documento muestra 0xAABBCCDDEEFF; la identidad de doce dígitos es la parte posterior al prefijo.

Ampliar una expresión regular no crea equivalencia. El RFC 7950 define pattern como una restricción de los strings admitidos. También establece que la forma canónica del string integrado coincide con su representación léxica y no aplica normalización Unicode. Aceptar ambas cajas o ambos separadores no instruye al comparador para plegarlos.

El mismo par puede ser uno o dos registros

El mecanismo es voluntario para la implementación. Quien anuncia soporte debe comparar la forma normalizada; quien no lo soporta continúa con el tipo léxico. La regla general de YANG permite ignorar por completo una extensión desconocida y exige procesar conforme a especificación una extensión soportada.

Si ya existe aa:bb:cc:dd:ee:ff y llega AA-BB-CC-DD-EE-FF a un nodo cuyo tipo admite esa grafía, una implementación compatible puede rechazar la segunda entrada como la misma clave normalizada. Otra puede ver dos strings. Esa diferencia alcanza igualdad XPath, listas con clave y leaf-lists de configuración.

Por eso un recibo de duplicado debe identificar la revisión del módulo, el nodo y tipo base, la identidad normalizada, producto y versión, prueba de soporte y valor calculado. Conservar solo las dos cadenas y el error no permite explicar la decisión.

El proceso real no está en el encabezado

La página actual de Datatracker muestra un Internet-Draft individual activo, ningún flujo RFC, ningún estado RFC previsto y I-D Exists. Advierte que cualquiera puede presentar un I-D y que este texto no está respaldado por el IETF ni tiene posición formal en el proceso. El cuerpo inmutable declara Intended status: Standards Track y vence el 2 de enero de 2027.

El encabezado expresa una intención de los autores; Datatracker describe la situación procesal. Incluso la cadena «IETF NETMOD Working Group» en el campo organization del módulo incluido carece de valor como prueba de adopción.

Los autores son Don Fedyk, de LabN Consulting, y Scott Mansfield, de Ericsson. El perfil de Fedyk enumera 24 RFC; el de Mansfield, cinco RFC y funciones de enlace IETF–UIT-T. La trayectoria da contexto, no aprobación institucional.

El antecedente está en las diapositivas NETMOD del IETF 124. Allí se compararon las grafías IETF e IEEE y se plantearon una única forma, patterns inclusivos, una función de equivalencia, almacenamiento binario o ninguna acción. La revisión 00 elige una identidad de comparación separada y conserva la grafía.

Igualdad de valor no es igualdad de sujeto

Una forma normalizada igual demuestra que dos entradas admitidas pasaron por la misma transformación declarada. Un true de XPath documenta la evaluación de esa implementación en ese contexto. Un rechazo documenta una restricción local.

No demuestra que dos filas representen el mismo dispositivo, que cualquier identidad futura carezca de colisiones o que dos implementaciones ejecuten idéntico algoritmo. Tampoco prueba soporte bilateral, mismo esquema y árbol visible, migración del datastore, intención, autorización, deduplicación del plano de reenvío ni resultado de red.

La propuesta difiere de la canonicalización ordinaria. XDR emite una representación externa única; aquí se guardan varias grafías y una identidad paralela gobierna algunas comparaciones. Un nombre de módulo correcto o un diff de esquema tampoco demuestra que el algoritmo se ejecutó.

La pregunta útil queda acotada: ¿qué evidencia permite saber que el sistema comparó el valor declarado y no la tipografía del string?