Resumen

  • Los campos udpSafeOptions y udpUnsafeOptions registran si cada tipo de opción fue observado al menos una vez entre los paquetes que forman un Flow.
  • Las listas de identificadores experimentales desplazan a las banderas genéricas EXP y UEXP y conservan nombres, no una secuencia de sucesos.
  • La afirmación depende del punto de observación, las claves y tiempos del Flow, la selección de paquetes, la plantilla y la entrega al colector. Ver no equivale a procesar.

Una pregunta pequeña, una respuesta exacta

RFC 9870 no intenta narrar el tráfico. Define una pregunta acotada que un exportador puede contestar con pocos bits: ¿qué tipos de opción UDP aparecieron alguna vez en este Flow? Para los tipos SAFE, el ElementID 525 ofrece un mapa de 256 bits, de los cuales 192 corresponden a los tipos 0 a 191. Para los tipos UNSAFE, el ElementID 526 asigna 64 bits a los valores 192 a 255.

El umbral es una sola observación. Un paquete y diez mil paquetes dejan el mismo bit en uno. La posición dentro del Flow también desaparece. El mapa no muestra si la opción fue inicial, tardía, continua, intermitente o coincidente con otra opción.

El diseño sirve para clasificación y búsqueda. Su peligro aparece en la capa siguiente, cuando una regla de seguridad interpreta el bit como tasa, persistencia o causalidad. El estándar no ofrece esa expansión. Tampoco exporta con esos mapas el valor interno de cada opción.

Dos listas evitan una ambigüedad y dejan otras

Los experimentos concurrentes no caben bien en una sola marca. RFC 9868 reservó EXP y UEXP; RFC 9870 define un udpExID de 16 bits y listas distintas para los identificadores SAFE y UNSAFE observados. Así, el colector puede distinguir qué experimentos estuvieron presentes.

La precedencia importa para escribir y leer. Si aparece udpSafeExIDList, esa lista ya señala que se observó EXP y el exportador no debe encender además el bit EXP del mismo Flow. La lista UNSAFE aplica la misma regla a UEXP. Un analizador que ignore las listas pierde evidencia positiva aunque el mapa genérico parezca limpio.

Sin embargo, una lista de identificadores no es un registro de paquetes. No atribuye cada identificador a una hora, posición, cantidad o respuesta. Puede preservar dos nombres y borrar por completo si se alternaron, coexistieron o sólo aparecieron una vez.

El alcance de un cero

Una lectura negativa necesita conocer el universo observado. RFC 7011 vincula cada Flow a un punto de observación, un intervalo y un conjunto de propiedades. La selección o el muestreo, los límites activo e inactivo y la capacidad del proceso de medición deciden qué paquetes pueden contribuir.

Con ese contexto completo, el cero declara que el tipo no fue observado en el Flow representado. Sin él, no demuestra ausencia en otro enlace, otro intervalo, los paquetes descartados por la selección o el tráfico que nunca llegó al medidor. El lenguaje correcto conserva la frontera: «no observado aquí bajo esta configuración».

El uno tampoco salta al receptor. Indica una observación en la superficie del medidor. No prueba que el destino entendiera la opción, aceptara su política, verificara su integridad o produjera un resultado. Esos recibos pertenecen al extremo y a la aplicación.

Los bytes necesitan su contrato

El mapa SAFE usa unsigned256, definido por RFC 9740, y admite codificación de tamaño reducido. Las listas se apoyan en basicList, definido por RFC 6313. Por ello, un valor almacenado sin plantilla, longitud, número de elemento y revisión semántica puede ser imposible de interpretar con fidelidad.

IANA mantiene los elementos 525 a 529 y los registros de tipos UDP y ExID. Esa autoridad asigna identificadores comunes; no certifica una implementación, una observación ni un resultado. El registro hace comparable el vocabulario, no completa la cadena probatoria.

Fuentes