Résumé

  • Une partie du sens d'une configuration montée dépend des données parentes sélectionnées pour évaluer ses contraintes, pas seulement du fichier qui définit le modèle.
  • Schema Mount distingue cette visibilité pour XPath de l'accès aux données par NETCONF ou RESTCONF. Référencer un nœud ne revient pas à obtenir le droit de le lire ou de le modifier.
  • La responsabilité de composition doit être identifiable : un module peut rester parfaitement stable pendant que ses conditions d'utilisation changent.

Un incident de configuration peut se perdre entre deux explications exactes. L'équipe qui maintient le modèle affirme n'avoir rien changé. Celle qui gère les affectations du réseau confirme que ses nouvelles données sont correctes. Pourtant, une configuration dépendant des deux ne produit plus le résultat attendu. Sans responsable de leur articulation, chacun peut défendre son périmètre sans expliquer l'ensemble.

Il ne s'agit pas ici du récit d'un incident observé. C'est une question d'organisation rendue concrète par YANG Schema Mount : où placer la responsabilité lorsque les règles sont livrées par un modèle et qu'une partie de leur contexte est fournie ailleurs ? Le mécanisme permet justement de réutiliser des modèles complets sans réécrire chacun pour toutes les structures qui pourraient l'accueillir.

Cette séparation est une qualité de conception. Elle évite de multiplier les variantes. Mais elle crée aussi un objet de travail distinct du module : la relation qui le rattache à son environnement. Une procédure d'acceptation peut examiner minutieusement les deux extrémités et oublier cette relation.

Commencer par ce qu'un accès ne prouve pas

Le mot « accès » est particulièrement trompeur dans ce dossier. Il peut désigner les données disponibles pour calculer une expression, les opérations exposées par un serveur, ou les droits d'une personne authentifiée. Ces usages ne décrivent pas la même chose.

Le RFC 8528 permet, dans le mode de schéma partagé, de sélectionner des nœuds du parent à l'aide de parent-reference. Le résultat enrichit l'arbre accessible lors de l'évaluation des expressions XPath du modèle monté. Il ne transforme pas ces nœuds en données que le client pourrait consulter ou modifier à travers le point de montage par NETCONF ou RESTCONF.

Une règle peut ainsi tenir compte d'une affectation administrée par une autre partie du système sans que la gestion de cette affectation lui soit transférée. C'est précisément ce qui rend la distinction utile. Effacer la frontière entre dépendance et permission conduirait soit à surestimer les pouvoirs du client, soit à sous-estimer ce dont dépend la validité de ses données.

De même, le caractère non configurable d'un nœud n'est pas une liste d'utilisateurs autorisés. Le statut de lecture seule peut résulter du point de montage ou des informations qui décrivent ce montage. Il répond à une question sur la nature des données, pas à toutes les questions d'autorisation.

Une interface présente n'est pas nécessairement la bonne

L'exemple d'instance réseau du RFC apporte un cas précis. Une expression sélectionne dans le parent les interfaces rattachées à l'instance courante. Le modèle monté peut alors utiliser des références d'interface, notamment pour une interface de sortie de route statique, alors que le module des interfaces n'appartient pas à son propre schéma.

La présence d'une interface sur l'équipement ne suffit donc pas à expliquer son rôle dans ce contexte. Il faut regarder la sélection. Deux instances utilisant la même définition peuvent aboutir à des ensembles différents, parce que l'expression est évaluée depuis des instances différentes.

Cet exemple de l'annexe A.3 est non normatif. Il ne démontre ni l'adoption d'un produit, ni la conformité d'un fournisseur, ni un effet mesuré sur le trafic. Il établit une possibilité de composition que les responsables d'intégration doivent comprendre. La conclusion opérationnelle reste conditionnelle : une modification du parent peut changer les données dont dépend une contrainte du modèle monté.

Le mot « peut » est essentiel. Une modification sans rapport avec la contrainte ne suffit pas. La sélection peut rester inchangée. Certaines règles ne dépendent d'aucun nœud ajouté. Pour expliquer un résultat, il faut suivre la relation effective plutôt que déclarer tout changement du parent suspect.

La validité exige un contexte déterminé

Dans YANG, une condition must exprime une contrainte qui doit être vraie pour les données concernées. La langue définit aussi les références de feuille et leur exigence d'existence. Avec require-instance à true, une instance correspondante doit satisfaire les règles applicables ; avec false, son absence peut être admise. Ces différences sont définies dans le RFC 7950.

Il serait donc insuffisant de demander si « les références fonctionnent ». Il faut savoir de quelle référence il s'agit, dans quel arbre elle est évaluée et avec quelle exigence. Un modèle n'est pas un certificat de validité attaché pour toujours à une chaîne de caractères de configuration. Il définit des conditions qui portent sur des données et sur leurs relations.

Imaginons, comme comparaison analytique, une même configuration candidate conservée pendant que change une affectation d'interface dans le parent. Si la sélection et la contrainte dépendent de cette affectation, le résultat de l'évaluation peut différer sans modification du module. Cela ne prouve aucun comportement particulier d'un routeur. Cela montre pourquoi une comparaison des seuls fichiers peut laisser la bonne question sans réponse.

Même les exemples publiés demandent une lecture attentive des relations. L'erratum éditorial vérifié 5797 corrige une autre partie de l'annexe : le champ d'affectation à un élément réseau logique doit contenir le nom de cet élément, non celui de l'interface. La correction ne remet pas en cause le mécanisme de référence au parent. Elle rappelle simplement qu'un identifiant plausible peut désigner le mauvais type d'objet.

La souplesse a une adresse

Le parent choisit les emplacements de montage, sur un conteneur ou une liste. Les chemins du modèle monté sont interprétés par rapport à ce point, et non automatiquement depuis la racine de tout l'équipement. Ce périmètre est parfois appelé mount jail. Le terme ne doit pas être pris pour une preuve de séparation des processus ou d'isolement des clients.

Les références au parent constituent une extension explicite du contexte d'évaluation. Elles sélectionnent des ensembles de nœuds, auxquels s'ajoutent leurs ancêtres. Dans une composition imbriquée, les relations de référence peuvent elles-mêmes traverser plusieurs niveaux de contexte selon les règles du RFC. Plus la composition est riche, plus il importe de savoir où une dépendance commence et quelle équipe peut la modifier.

Pour autant, les informations d'état schema-mounts ne constituent pas un guichet universel de reconfiguration. Elles décrivent ce que le serveur met en place. Le standard ne prescrit pas une méthode unique pour obtenir toutes les données sous-jacentes ou créer les instances. La présence d'une description observable ne révèle donc pas, à elle seule, l'ensemble des pouvoirs de changement de l'implémentation.

Le même soin s'impose pour la découverte. Un schéma partagé impose un schéma commun aux instances du point de montage. Le mode inline permet des schémas différents. Chaque instance opérationnelle fournit des informations YANG Library, mais des identifiants de contenu identiques entre deux instances inline ne prouvent pas que leurs bibliothèques sont identiques.

Surtout, le partage d'un schéma ne signifie pas le partage des valeurs ordinaires du parent. Une liste de modules ne remplace pas l'ensemble des données sélectionnées pour une contrainte. On peut donc connaître les modules sans savoir reconstruire le contexte qui expliquait une ancienne décision de validation.

Séparer la dépendance du pouvoir d'agir

Lorsque NACM est implémenté, les nœuds montés restent soumis au contrôle d'accès selon leur place dans l'arbre composé. Le montage ne crée pas de lui-même un univers d'autorisation autonome. Les modes de gestion partagée ou séparée concernent l'organisation des sessions ; ils ne suffisent pas à prouver une isolation de sécurité complète.

Le RFC 8341 sur NACM souligne en outre que les dépendances des modèles, les références et certains effets implicites peuvent révéler des informations ou affecter d'autres données. Interdire une lecture directe ne décrit pas à lui seul tout ce qu'une opération autorisée permet d'observer. Ce sont des précautions générales, pas la démonstration d'une faille particulière de Schema Mount.

Une évaluation sérieuse évite donc deux raccourcis opposés. La présence d'une référence au parent ne prouve pas que l'isolation a échoué. L'absence d'un chemin de lecture direct ne prouve pas qu'elle est complète. Il faut examiner les modèles, les sessions, les droits et les comportements effectivement disponibles.

À l'arrivée, la question n'est pas de choisir entre des modèles réutilisables et des modèles sûrs. Elle est de ne pas faire disparaître le travail d'intégration derrière la qualité de chacun des modules. La relation entre deux modèles mérite un responsable aussi identifiable que les modèles eux-mêmes.