Résumé

  • draft-ietf-radext-connectinfo-00 formalise en ABNF les débits, le RSSI, les pertes, les retransmissions, la classe d’exploitation globale et leurs agrégations dans Connect-Info. Il normalise une déclaration du NAS, pas la façon dont le matériel a observé la radio.
  • Un instantané d’Access-Request, un maximum sur dix minutes et une moyenne de session ne sont pas comparables parce qu’ils ont la même unité. Le type de message, la population d’échantillons, l’algorithme et la fenêtre doivent accompagner la valeur.
  • TLS protège le trajet RADIUS, non la véracité de la mesure. La légitimité d’un usage d’autorisation, son application et le service réellement obtenu restent des étapes séparées.

Le maximum efface la durée précisément quand il paraît la résumer

Prenons un TxBitRate maximal sur dix minutes. Il peut provenir d’une seule trame transmise sous une modulation favorable, au milieu de neuf minutes de contention. Il peut aussi décrire une liaison stable proche de cette valeur. La fonction MAX produit le même nombre dans les deux cas. Sa fenêtre borne la recherche; elle ne donne ni distribution, ni durée de maintien, ni capacité applicative.

Le projet du groupe RADEXT, également disponible en HTML et en XML, ne prétend pas résoudre cette perte d’information. Il donne une grammaire au champ Connect-Info. RFC 2869 avait défini cet attribut RADIUS numéro 77 et recommandé que la vitesse de connexion figure au début. Les équipements Wi-Fi ont ensuite ajouté, selon des formes diverses, amendement 802.11, puissance de signal et canal.

L’ABNF reconnaît désormais des clés telles que TxBitRate, RxBitRate, RSSI, FrameLoss, FrameRetry et Global-OC. Elle décrit MIN, MAX, AVG-LIN, AVG-EXP et ACC, avec fenêtres en secondes ou minutes; la moyenne exponentielle peut préciser un poids et une période d’échantillonnage. C’est beaucoup mieux qu’une suite de nombres dont le serveur devine la position.

Mais une grammaire ne remonte pas jusqu’au pilote radio. Elle ignore quelles trames furent retenues, comment les liens multiples furent combinés, à quel moment un compteur a été remis à zéro, et si le firmware a arrondi ou conservé une valeur ancienne. RFC 6158 rappelle les difficultés des types complexes dans les attributs RADIUS. Le projet justifie sa démarche par la formalisation d’un format déjà déployé. Cette continuité facilite la migration; elle ne constitue pas une validation métrologique.

Access-Request et Accounting-Request ne répondent pas à la même question

Au début d’une association, l’Access-Request peut partir avant que le NAS dispose d’un ensemble représentatif de trames. Le projet autorise alors un débit ou un RSSI instantané et recommande de ne pas inclure AGGR. Ce point est opérationnellement honnête: le système sait peu de choses et ne doit pas simuler une moyenne.

Pour un Accounting-Request couvrant un intervalle, le texte recommande au contraire un maximum pour les débits, une moyenne pour le RSSI et une accumulation pour les rapports de pertes et de retransmissions. Conserver seulement le nombre et l’unité détruit donc le sens. Une base qui aligne un instantané de demande d’accès et un maximum de session dans la même colonne fabrique une série temporelle qui n’a jamais existé.

Le RSSI illustre une compatibilité plus subtile. La syntaxe accepte 41 et -41 pour représenter -41 dBm, parce que des implémentations historiques ont utilisé la valeur absolue ou le signe. Normaliser ces deux écritures est nécessaire. En déduire que deux radios sont calibrées à l’identique ne l’est pas. Chaînes d’antenne, cadence, moyennage et population de trames peuvent différer sans violer l’ABNF.

Le numéro de canal souffre d’une ambiguïté analogue avec l’arrivée du 6 GHz. Global-OC apporte le contexte de classe d’exploitation et peut apparaître plusieurs fois pour le fonctionnement multi-link. Un intermédiaire qui aplatit les répétitions conserve une chaîne lisible tout en perdant la topologie radio qu’elle cherchait à transmettre.

Une clé future est une demande de négociation, pas une permission de scorer

La branche extensible de la grammaire permet à une clé inconnue de survivre au parseur. C’est un bon mécanisme d’évolution. Sa réussite signifie seulement: nom et valeur respectent une forme. Elle ne fournit ni unité, ni cardinalité, ni origine, ni sémantique d’agrégation. Tant qu’un accord de version n’existe pas, «valide mais inconnue» doit rester un état explicite et ne pas alimenter silencieusement une décision.

La chaîne de preuve commence avant RADIUS. Un composant physique observe des trames. Le logiciel choisit une population. Une agrégation la transforme. Le NAS affirme un résultat dans un message précis. Le transport le remet à un serveur, lequel le parse et le normalise. Une institution décide ensuite si l’usage est permis et avec quel poids. Enfin viennent réponse d’autorisation, application sur le réseau, état radio et expérience applicative.

Confondre ces étapes rend les incidents insolubles. Une analyse syntaxique réussie ne prouve pas l’échantillon. Une réponse Access-Accept ne prouve pas qu’elle a été appliquée au bon terminal. Une association établie ne prouve pas une visioconférence utilisable. Chaque transition doit produire son propre reçu.

Le canal chiffré authentifie une enveloppe

Le projet recommande de transmettre Connect-Info uniquement par un canal sécurisé et cite RADIUS protégé par TLS. RFC 6614 spécifie RADIUS/TLS; RFC 7360 traite RADIUS/DTLS. Ces mécanismes protègent la confidentialité et l’intégrité en transit et permettent d’authentifier le pair. Ils ne calibrent pas l’accès radio et ne rendent pas correcte une règle d’admission.

Le cas de l’itinérance accentue la frontière. Un Access Network Provider exploite le NAS; un Identity Provider tiers reçoit la métrique et peut l’utiliser pour aider une décision d’autorisation. Le projet ne spécifie pas la technique d’autorisation. Seuil, historique et indicateur dérivé restent des choix locaux. Il faut donc un accord d’interconnexion qui nomme paramètres, définitions, finalité, durée de conservation, traitement des clés inconnues et droit de divulgation. Le certificat du serveur ne contient aucune de ces règles.

Un signal radio peut devenir une chronologie de déplacements

La version de groupe de travail sépare nettement sécurité et vie privée. En s’appuyant sur RFC 6973, elle explique que le RSSI peut être indirectement identifiant. Associé à la position connue des points d’accès et à un identifiant durable, il peut révéler présence, proximité ou mouvement, même si Connect-Info ne transporte directement ni nom d’utilisateur ni adresse MAC.

Le texte recommande la minimisation et l’absence de liaison avec des identifiants persistants. Il précise aussi ce qu’il ne fait pas: aucun mécanisme de notification ou de consentement n’est défini. Ces obligations éventuelles relèvent de la politique de l’opérateur et du droit applicable. Une chaîne conforme peut donc participer à un traitement non justifié, à une conservation excessive ou à une réutilisation inattendue.

La minimisation doit devenir une propriété du système: délai d’expiration, séparation des identifiants, contrôle des jointures et journal de finalité. Un paragraphe contractuel sans contrôle d’exécution ne suffit pas davantage qu’une grammaire sans échantillon.

L’adoption a retiré une affirmation de déploiement

L’API Datatracker, la fiche du document et son historique situent la révision 00 au 24 septembre 2026 comme Internet-Draft actif du groupe RADEXT. L’en-tête vise le statut Informational; aucun AD responsable, shepherd ou telechat n’est affiché, et le statut RFC visé reste nul. Ce n’est pas une RFC.

La version antérieure, draft-grayson-connectinfo-10, contenait une section non normative mentionnant un prototype et 17 000 points d’accès. Le texte adopté l’a supprimée. Il a, en revanche, renforcé les recommandations de canal sécurisé, d’accord d’interconnexion, de minimisation et d’unlinkability, et rendu explicite la limite sur le consentement. La suppression ne nie pas l’existence passée du déploiement; elle retire cette affirmation du dossier probant du document courant.

Sources et limites

L’analyse repose sur le texte 00, ses rendus HTML et XML, l’API, la page d’état et l’historique, comparés au prédécesseur. Le cadre RADIUS vient de RFC 2869, RFC 6158, RFC 6614, RFC 7360 et RFC 6973. Ces sources n’offrent ni recensement actuel, ni étalonnage comparatif, ni mesure d’exactitude des autorisations, ni avis juridique, ni résultat d’expérience utilisateur.