Résumé

  • RFC 10009 fournit des éléments YANG 1.1 réutilisables pour clients et serveurs HTTP : URI cliente, versions admises, TLS et proxy facultatifs, configuration HTTP côté serveur et composition pratique d’une pile d’écoute.
  • Ces modules définissent un typedef et des groupements, non des nœuds accessibles par protocole. Un modèle rempli prouve une intention de configuration, pas qu’un service écoute, authentifie, admet une requête ou produit un effet.

RFC 10009 est utile précisément avant l’ouverture d’une connexion. Son groupement ietf-http-client peut décrire une URI, une liste de versions HTTP limitée par la politique locale, du matériel TLS côté client et un passage par proxy. Son matériel ietf-http-server décrit la partie HTTP d’un serveur ; un autre groupement compose cette partie avec TCP, TLS ou QUIC/UDP. La composition rend les couches lisibles sans les faire passer pour un seul fait opérationnel.

La partie cliente montre bien cette retenue. La seule branche obligatoire est uri, dont le schéma et l’hôte sont obligatoires. Le schéma et l’autorité de l’URI portent des informations relatives aux couches de transport. protocol-versions dit ce que la configuration autorise ; supported-versions, en lecture seule, dit ce que l’implémentation sait faire indépendamment de ce choix. Les paramètres TLS facultatifs nomment le matériel d’identité du client et d’authentification du serveur ; les paramètres de proxy désignent une route. Aucun de ces champs n’observe une réponse DNS, ne démontre un chemin TCP ou QUIC, ne confirme une décision de certificat ni ne consigne une réponse applicative. L’absence de paramètres TLS interdit les connexions TLS dans cette configuration ; leur présence ne garantit toujours ni le pair ni son acceptation.

Le côté serveur est tout aussi limité. Le groupement HTTP ne configure que la partie HTTP, sans configurer TCP ou TLS. Le groupement de pile d’écoute propose HTTP sur TCP, TLS ou QUIC, mais conserve les groupements de transport correspondants. server-name, les versions admises et une petite base Basic facultative activée par fonctionnalité sont des choix de configuration. Ils ne prouvent ni un port lié, ni un processus en écoute, ni une identité de pair validée, ni une gestion correcte des mots de passe, ni une autorisation applicative. Un modèle peut être impeccable et la chaîne peut néanmoins échouer à chacune des étapes suivantes.

La phrase décisive est que les trois modules de RFC 10009 définissent des types ou groupements réutilisables et ne définissent, seuls, aucun nœud accessible par protocole. Un module consommateur doit les instancier. Il existe donc déjà deux preuves distinctes avant l’exécution : le modèle réutilisable et le dessin effectif des nœuds par le consommateur. Viennent ensuite l’écriture de gestion autorisée, la révision déployée, l’écouteur lié, le transport et le pair, l’échange HTTP, l’admission applicative et l’effet observé. Dire simplement « le point d’accès est configuré » transforme une intention en conclusion non établie.

L’autorité de configuration s’arrête avant l’autorité de service

La section sécurité conserve cette séparation. Les conséquences de ces modules de groupements dépendent de leurs consommateurs. NETCONF et RESTCONF exigent un transport sûr et une authentification mutuelle ; NACM peut limiter les opérations et contenus de gestion accessibles à un utilisateur. Cela répond à la question de savoir qui peut lire ou modifier la surface de gestion. Cela ne donne pas au client le droit d’appeler toute fonction applicative et ne convertit pas une sauvegarde de configuration en livraison.

Le typedef de versions HTTP maintenu par l’IANA appelle la même discipline. Un registre apporte un vocabulaire portable et une implémentation peut exposer ses capacités. Aucun des deux ne prouve qu’une version a été activée, négociée avec un pair, acceptée par un intermédiaire ou utile à une application. Le registre est une référence ; la capacité est une déclaration locale ; l’échange en cours est une preuve distincte.

Cette lecture est éditoriale, pas une obligation IETF. La note de Heng Lu sur la spécification initiale minimale éclaire l’intérêt d’une couche commune réduite : elle rend les composants composables et laisse les décisions ultérieures localisées. Sa thèse de la primauté du code exécuté fournit le test pratique : dire qu’un service a fonctionné exige le dossier d’exécution concilié, non le seul modèle antérieur.