Resumen

  • draft-ietf-radext-connectinfo-00 formaliza cómo expresar tasas, RSSI, pérdida, reintentos, Global Operating Class y agregaciones en RADIUS Connect-Info. Hace legible una afirmación del NAS; no certifica la observación que la originó.
  • Una cifra puede ser instantánea en Access-Request o representar un máximo, promedio o acumulación en Accounting-Request. Sin mensaje, ventana, algoritmo y población de muestras, el valor pierde su significado operativo.
  • RADIUS/TLS protege la entrega entre pares. La verdad de la medida, la finalidad legítima, la calidad de la política, la aplicación al usuario correcto y el servicio final requieren comprobantes independientes.

La compatibilidad resuelve una ambigüedad y conserva otras

Aceptar 41 y -41 para -41 dBm evita que años de práctica divergente rompan un parser nuevo. Es una buena labor de estandarización: reconocer que el terreno ya existe y definir una lectura interoperable. El peligro aparece cuando un sistema de decisión convierte esa normalización en equivalencia física.

El texto del grupo RADEXT, junto con sus representaciones HTML y XML, especifica una gramática para Connect-Info en redes IEEE 802.11. RFC 2869 definió el atributo 77 y recomendó comenzar por la velocidad de conexión. Las implementaciones Wi-Fi añadieron después enmiendas, señal y canal en cadenas complejas.

El nuevo ABNF reconoce TxBitRate, RxBitRate, RSSI, FrameLoss, FrameRetry y Global-OC, además de la forma heredada. RFC 6158 desaconseja tipos complejos cuando hay alternativas viables; el borrador explica que no crea uno nuevo, sino que formaliza un formato de uso extendido. Esa historia impone compatibilidad. No aporta una cadena de calibración.

Un valor de señal depende de qué tramas entraron, qué cadena o enlace se observó, cuándo se muestreó, cómo se redondeó y si el controlador actualizó el dato antes de emitir RADIUS. Dos equipos pueden cumplir la misma gramática y describir universos distintos. El servidor sabe qué texto recibió; todavía no sabe qué ocurrió junto a la antena.

El algoritmo de agregación forma parte del hecho

La sintaxis ofrece mínimo, máximo, promedio lineal, promedio exponencial y acumulación. Admite ventanas en segundos o minutos; la media exponencial puede llevar peso y periodo de muestreo. Separar esos componentes permite conservar una parte esencial de la procedencia matemática.

En un Access-Request temprano hay pocas tramas. Por eso tasas y RSSI pueden ser instantáneos, y el borrador recomienda omitir la definición de agregación. En Accounting-Request, las recomendaciones cambian: máximo para tasas, promedio para señal y acumulación para proporciones de pérdida y reintento.

Un almacén que guarda solo 600 Mbps elimina la pregunta que determina el significado: ¿fue una observación instantánea, el punto más alto de diez minutos o algo sostenido? Un motor que compara esos registros como si fueran iguales no está descubriendo una tendencia; está inventando una serie homogénea.

Global-OC también protege un contexto que el número de canal por sí solo ya no puede ofrecer, especialmente con 6 GHz. La clave puede repetirse en operación multi-link. Si una pasarela conserva únicamente la primera aparición, su parser funciona y su modelo de la estación queda mutilado. La prueba no termina donde acaba la sintaxis.

La extensibilidad no concede autoridad semántica

El ABNF admite claves futuras desconocidas. El diseño permite evolucionar sin que todo receptor rechace el atributo completo. Aun así, una clave nueva necesita definición, unidad, multiplicidad, alcance de muestreo, versión y política de agregación. “Válida pero desconocida” debe permanecer visible hasta que las partes acuerden esos términos.

El orden de la evidencia ayuda a impedir atajos. Primero el hardware observa. Después un controlador selecciona muestras y un algoritmo las combina. El NAS afirma el resultado dentro de Access-Request o Accounting-Request. El canal lo entrega. El servidor parsea, normaliza y decide si el dato puede entrar en una política. La política produce una respuesta, el acceso intenta aplicarla y solo después puede medirse el comportamiento radio y de la aplicación.

Cada flecha tiene un fallo propio. TLS no descubre un sensor atrasado. Un parse correcto no detecta unidades interpretadas de forma distinta. Access-Accept no confirma que la VLAN, limitación o admisión se aplicó a la sesión adecuada. Una asociación no garantiza latencia, continuidad ni utilidad.

El cifrado protege el tránsito, no la decisión

La revisión de grupo recomienda canales seguros y cita RADIUS con TLS. RFC 6614 define RADIUS/TLS y RFC 7360 RADIUS/DTLS. Ambas opciones pueden autenticar al par y proteger confidencialidad e integridad. Ninguna determina si -41 dBm fue bien medido o si ese valor justifica admitir, limitar o rechazar a alguien.

En itinerancia, un proveedor de acceso puede enviar Connect-Info a un proveedor de identidad que autentica credenciales y ayuda a autorizar la entrada. El borrador deja fuera la técnica de autorización. No consagra umbrales ni historial ni puntuación derivada. Cada federación debe documentar qué métrica acepta, con qué definición, para qué propósito, durante cuánto tiempo y qué ocurre con campos desconocidos o ausentes.

Esto evita que el certificado sustituya al contrato. Saber quién envió el dato es importante; saber qué prometió medir, qué derecho tenía para compartirlo y cómo puede usarse es otra capa.

La señal puede identificar sin llevar un nombre

La sección de privacidad usa el marco de RFC 6973. RSSI, correlacionado con ubicaciones conocidas de puntos de acceso, puede revelar presencia, proximidad o movimiento. Al vincularlo con una cuenta persistente se obtiene una trayectoria, aunque el atributo no contenga directamente un nombre de usuario ni una dirección MAC.

El borrador recomienda minimización y evitar enlaces duraderos. Declara además que no define aviso ni consentimiento: si son necesarios, corresponden a política del operador y derecho aplicable. Por tanto, una implementación puede ser sintácticamente perfecta y aun conservar demasiado, combinar datos fuera de su finalidad o carecer de base para el uso.

Una arquitectura responsable hace ejecutable la minimización. Elimina valores al vencer su propósito, separa identidad de telemetría, registra las uniones y exige una versión de política para cada decisión. Sin esos controles, “uso operativo” se convierte en una categoría ilimitada.

La adopción de grupo estrechó la evidencia pública

La API de Datatracker, la página del documento y el historial registran la revisión 00, fechada el 24 de septiembre de 2026, como Internet-Draft activo de RADEXT. Su cabecera dice Informational, pero Datatracker no muestra AD responsable, shepherd ni telechat y el estado RFC previsto aparece nulo. No es un RFC.

El predecesor draft-grayson-connectinfo-10 incluía una sección no normativa con un prototipo y un despliegue de 17.000 puntos de acceso. El documento adoptado eliminó ese párrafo. Separó seguridad y privacidad, añadió recomendaciones sobre canal seguro y acuerdos de interconexión, y explicitó minimización, desvinculación y límites de consentimiento. No cabe presentar la adopción como validación de un censo que el texto vigente decidió no conservar. No es RFC ni estándar publicado.

Fuentes y límites

La base es el borrador vigente en texto, HTML y XML, delimitado por la API, el estado y el historial, y comparado con el predecesor. El contexto procede de RFC 2869, RFC 6158, RFC 6614, RFC 7360 y RFC 6973. Las fuentes no aportan un censo actual, comparación de calibración, exactitud de decisiones, dictamen jurídico ni medición de experiencia.