Initiale releaseHEADmaster

1 files changed, 324 insertions, 0 deletions

diff --git a/RFC_7950_The_YANG_11_Data_Modeling_Language.txt b/RFC_7950_The_YANG_11_Data_Modeling_Language.txt
new file mode 100644
index 0000000..9a8a47e
--- /dev/null
+++ b/RFC_7950_The_YANG_11_Data_Modeling_Language.txt
@@ -0,0 +1,324 @@
+Titre: RFC 7950: The YANG 1.1 Data Modeling Language
+Auteur: 
+Date: Mon 10 Oct 2016 02:00:00 +0200
+Lien: https://www.bortzmeyer.org/7950.html
+
+Le protocole standard Netconf (normalisé dans le RFC 6241) permet de configurer
+un équipement réseau (par exemple un commutateur) à distance. Netconf 
+fonctionne par des RPC dont les paramètres sont des actions à faire effectuer 
+par l'équipement configuré, ou bien les nouvelles valeurs que peut prendre 
+telle ou telle des variables de configuration de cet équipement. Mais comment 
+savoir quelles actions sont possibles, quelles variables existent, et quelles 
+valeurs elles peuvent prendre ? Jusqu'à présent, cela pouvait se spécifier 
+uniquement dans une documentation en langue naturelle fournie avec 
+l'équipement. Désormais, il est possible de spécifier ces informations dans un 
+langage formel, YANG. La première version de YANG était normalisée dans RFC 
+6020, ce nouveau RFC normalise la nouvelle version, la 1.1, qui a peu de 
+changements, mais certains cassent la compatibilité ascendante.
+
+Ce RFC 7950 est très détaillé, plus de deux cents pages. Et je n'ai pas 
+personnellement d'expérience pratique avec YANG. Donc, je ne donne ici qu'un 
+très bref résumé. Un tel survol se trouve également dans la section 4 du RFC : 
+YANG modélise les données (configuration et état) qui seront utilisées par 
+Netconf. Ces données sont représentées sous forme arborescente. YANG est 
+modulaire (section 5.1 du RFC), un module YANG pouvant se référer à d'autres 
+modules. YANG définit un ensemble de types pour décrire les données (section 9 
+et RFC 6991). Il permet également d'indiquer les contraintes que doivent 
+respecter les données. YANG, langage de haut niveau, ne décrit pas l'encodage 
+utilisé sur le câble.
+
+Notez que YANG peut être utilisé avec d'autres protocoles que Netconf, comme 
+RESTCONF (décrit dans le RFC 8040).
+
+YANG a donc bien des points communs avec le SMI des RFC 2578 et RFC 2579. Avant
+Netconf, beaucoup de gens pensaient que toute la gestion des équipements réseau
+se ferait en SNMP, en s'appuyant sur ce modèle SMI. Si, pour la lecture des 
+variables, SNMP s'est largement imposé, force est de constater que, pour 
+l'écriture de variables et pour les actions, SNMP reste très peu utilisé, au 
+profit de toute une galaxie de mécanismes privés (Web, REST, SSH + CLI, etc), 
+galaxie que Netconf vise à remplacer. Une MIB du SMI peut donc être traduite en
+YANG, l'inverse n'étant pas vrai (YANG étant plus riche).
+
+La syntaxe de YANG utilise des groupes emboîtés, délimités par des accolades. 
+Mais une syntaxe équivalente, en XML, existe, sous le nom de Yin. Tout module 
+YANG peut être traduit en Yin sans perte et réciproquement (voir la section 13 
+pour plus de détails sur Yin).
+
+Donc, un engin donné, routeur ou autre équipement qu'on veut gérer, est décrit 
+par des modules YANG. Lorsqu'un serveur Netconf à bord dudit engin met en œuvre
+un module YANG, cela veut dire qu'il permet de modifier, via Netconf, les 
+variables décrites dans le module (le serveur typique met en œuvre plusieurs 
+modules). Voici le début d'un module possible : 
+
+     // Only an example, not a real module. 
+     module acme-system {
+         namespace "http://acme.example.com/system";
+         prefix "acme";
+
+         organization "ACME Inc.";
+         contact "joe@acme.example";
+         description
+             "The module for entities implementing the ACME system.";
+
+         revision 2010-08-05 {
+             description "Initial revision.";
+         }
+...
+
+On l'a dit, YANG est arborescent. Les feuilles de l'arbre (section 4.2.2.1 du 
+RFC) contiennent une valeur particulière, par exemple, ici, le nom de l'engin 
+géré : 
+
+       leaf host-name {
+           type string;
+           description "Hostname for this system";
+       }
+Ici, leaf est un mot-clé de YANG qui indique une feuille de l'arbre (plus de 
+nœuds en dessous), host-name est le nom que l'auteur du module a donné à une 
+variable, de type « chaîne de caractères ». Lorsqu'un serveur Netconf enverra 
+cette information à un client (ou réciproquement), elle sera encodée en XML 
+ainsi (Netconf utilise XML pour l'encodage des messages mais d'autres encodages
+sont possibles, cf. RFC 7951) : 
+
+
+       <>host-name>my-router.example.com<>/host-name>
+Donc, pour résumer, YANG modélise ce qu'on peutlire ou modifier, Netconf permet
+de le lire ou de le modifier effectivement. 
+
+Par contre, si un nœud de l'arbre YANG n'est pas une feuille, il est désigné 
+par le mot-clé container. Par exemple, il y a ici deux containers emboîtés et 
+une feuille : 
+
+     container system {
+         container login {
+             leaf message {
+                 type string;
+                 description
+                     "Message given at start of login session";
+             }
+         }
+     }
+Lorsque Netconf utilise cette donnée, cela ressemblera, sur le câble, à ceci : 
+
+
+     <>system>
+       <>login>
+         <>message>Good morning<>/message>
+       <>/login>
+     <>/system>
+
+YANG dispose d'un certain nombre de types pour représenter les données (section
+4.2.4 et RFC 6991), mais on peut aussi créer ses types (sections 4.2.5 et 7.3) 
+par exemple ainsi : 
+
+     typedef percent {
+         type uint8 {
+             range "0 .. 100";
+         }
+         description "Percentage";
+     }
+
+     leaf completed {
+         type percent;
+     }
+On a ajouté un intervalle de validité au type prédéfini uint8. Autre exemple, 
+en indiquant une valeur par défaut, et en dérivant d'un type défini dans le 
+module inet[1] : 
+
+     typedef listen-ipv4-address {
+         type inet:ipv4-address;
+         default "0.0.0.0";
+     }
+
+YANG a bien d'autres possibilités, décrites en détail dans les sections 
+suivantes. Par exemple, dans un monde idéal, tous les engins mettant en œuvre 
+un module YANG donné géreraient la totalité des variables du module. Mais, 
+comme ce n'est pas forcément le cas, YANG permet des déviations (sections 5.6.3
+et 7.20.3). Prenons l'exemple du RFC, un routeur BGP qui suit un module YANG 
+BGP. Le module ne donne pas de limite au nombre de pairs BGP mais un routeur 
+bas de gamme pourrait avoir une limite, disons à 16 pairs. Un client Netconf 
+qui tenterait de configurer un dix-septième pair recevrait donc une erreur. Le 
+mot-clé YANG deviationpermettrait audit client de savoir à l'avance en quoi ce 
+routeur particulier dévie du modèle BGP général. Le client Netconf n'aurait 
+donc pas à essayer pour voir, il pourrait savoir à l'avance que l'opération de 
+configuration du dix-septième pair ne marchera pas.
+
+La syntaxe formelle de YANG est décrite en section 6. Elle ressemble à celle de
+langages de programmation comme C ou à celle de SMIng du RFC 3780 (RFC qui n'a 
+pas eu de succès). Cette syntaxe favorise la lisibilité par des humains, le 
+cahier des charges étant de privilégier les lecteurs, pas les auteurs de 
+modules, ni les programmeurs d'outils YANG. À noter que, comme dans toutes les 
+normes modernes, YANG n'est pas limité à l'ASCII et peut utiliser tout Unicode.
+
+Bien que YANG n'utilise pas XML, il réutilise un langage de ce monde, XPath 
+(sections 6.4 et 7.5.3). XPath sert à indiquer les dépendances entre nœuds de 
+l'arbre.
+
+YANG permet en effet de définir des contraintes (section 8) que doivent 
+respecter les variables, avec la directive must. Par exemple : 
+
+         must "ifType != 'ethernet' or " +
+              "(ifType = 'ethernet' and ifMTU = 1500)" {
+             error-message "An ethernet MTU must be 1500";
+         }
+
+Voici un exemple de requête Netconf complète, correspondant à une variable 
+YANG. Soit un équipement muni d'un serveur SSH et d'un serveur Netconf pour sa 
+configuration. Disons que le serveur Netconf met en œuvre la variable YANG port
+, définie ainsi : 
+
+     leaf port {
+         type inet:port-number;
+         default 22;
+         description "The port which the SSH server listens to"
+     }
+La requête Netconf <>edit-config> (RFC 6241, section 7.2) qui configure le 
+serveur SSH pour écouter sur le port 2022 serait : 
+
+
+     <>rpc message-id="101"
+          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
+          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
+       <>edit-config>
+         <>target>
+           <>running/>
+         <>/target>
+         <>config>
+           <>system xmlns="http://example.com/schema/config">
+             <>services>
+               <>ssh>
+                 <>port>2022<>/port>
+               <>/ssh>
+             <>/services>
+           <>/system>
+         <>/config>
+       <>/edit-config>
+     <>/rpc>
+
+Le choix de YANG comme langage standard pour la description des capacités d'un 
+serveur Netconf ne s'était pas fait sans mal. Plusieurs concurrents avaient été
+envisagés notamment Relax NG, un choix logique puisque Netconf utilise XML. Un 
+langage de description de schémas comme Relax NG semblait donc un choix 
+raisonnable. Parmi les discussions à ce sujet, citons par exemple le débat qui 
+avait eu lieu sur la liste du secteur Applications de l'IETF[2]. Les raisons du
+choix de YANG, telles que vues par les concepteurs de YANG, sont décrites sur 
+le site officiel du projet[3] mais je trouve cette comparaison très 
+unilatérale.
+
+Un bon tutoriel Netconf, couvrant également YANG, est disponible en 
+http://www.aims-conference.org/issnsm-2008/06-netconf-yang.pdf[4].
+
+Quelles sont les mises en œuvre de YANG ? Il en existe une liste sur le site 
+officiel[5]. Voyons par exemple l'outil pyang[6], qui sert à valider des 
+schémas YANG (y compris de la nouvelle version 1.1 décrite dans ce RFC) et à 
+les convertir dans d'autres formats. Il ne semble pas trop maintenu mais, bon, 
+il marche. Il peut produire du XSD et du RelaxNG - enfin du DSDL mais c'est 
+presque pareil. Voici un exemple de test d'un schéma invalide (leaf a été tapé 
+laf) : 
+
+
+% pyang test.yang
+test.yang:11: error: unexpected keyword "laf"
+Et, si on corrige : 
+
+% pyang test.yang
+% 
+Maintenant, convertissons en Yin : 
+
+
+% cat test.yang
+ module acme-foo {
+         namespace "http://acme.example.com/foo";
+         prefix "acfoo";
+
+         list interface {
+             key "name";
+             leaf name {
+                 type string;
+             }
+
+             leaf mtu {
+                 type uint32;
+                 description "The MTU of the interface.";
+             }
+         }
+     }
+
+% pyang -fyin test.yang
+<>?xml version="1.0" encoding="UTF-8"?>
+<>module name="acme-foo"
+        xmlns="urn:ietf:params:xml:ns:yang:yin:1"
+        xmlns:acfoo="http://acme.example.com/foo">
+  <>namespace uri="http://acme.example.com/foo"/>
+  <>prefix value="acfoo"/>
+  <>list name="interface">
+    <>key value="name"/>
+    <>leaf name="name">
+      <>type name="string"/>
+    <>/leaf>
+    <>leaf name="mtu">
+      <>type name="uint32"/>
+      <>description>
+        <>text>The MTU of the interface.<>/text>
+      <>/description>
+    <>/leaf>
+  <>/list>
+<>/module>
+Et voici une conversion du même code en DSL : 
+
+
+% pyang -fdsdl test.yang
+<>?xml version='1.0' encoding='UTF-8'?>
+<>grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
+	 ns="http://acme.example.com/foo"
+	 xmlns="http://relaxng.org/ns/structure/1.0"
+	 xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
+	 xmlns:acfoo="http://acme.example.com/foo"
+	 xmlns:dc="http://purl.org/dc/terms"
+	 xmlns:dsrl="http://purl.oclc.org/dsdl/dsrl"
+	 xmlns:nm="urn:ietf:params:xml:ns:netmod:dsdl-attrib:1"
+	 xmlns:sch="http://purl.oclc.org/dsdl/schematron">
+  <>dc:source>YANG module 'acme-foo' (automatic translation)<>/dc:source>
+<>start>
+   <>zeroOrMore>
+      <>element name="interface" nm:key="name">
+	  <>element name="name">
+	     <>data type="string"/>
+	  <>/element>
+	  <>optional>
+	     <>element name="mtu"><>a:documentation>The MTU of the interface.<>/a:documentation>
+		<>data type="unsignedInt"/>
+	     <>/element>
+	  <>/optional>
+       <>/element>
+   <>/zeroOrMore>
+<>/start>
+<>/grammar>
+
+Outre pyang, il y a bien entendu même un mode Emacs, yang-mode[7].
+
+Le site officiel du projet, http://www.yang-central.org/[8], contient beaucoup 
+d'autre information sur YANG.
+
+Notez que l'ancien YANG, 1.0, décrit dans le RFC 6020, n'est pas abandonné. 
+L'ancien RFC reste d'actualité pour décrire la version 1.0, qui restera en 
+usage un certain temps. Les principaux changements apportés par la version 1.1 
+de YANG sont décrits dans la section 1.1 du RFC. La liste est très longue, mais
+la plupart ne sont que des points de détail. Parmi les changements qui peuvent 
+rendre illégaux des modèles YANG qui étaient légaux avant, il y a par exemple 
+le changement d'interprétation des échappements dans les chaînes de caractères,
+ou bien le fait qu'une chaîne de caractères qui n'est pas encadrée par des 
+apostrophes ou des guillemets n'a plus le droit de contenir des apostrophes ou 
+guillemets (section 6.1.3). De même, les clés (identificateurs uniques) ne 
+peuvent plus être conditionnelles (instructions when ou if-feature) ce qui est 
+logique, mais rend également invalide certains anciens modèles YANG.
+
+Liens:
+[1]: http://www.netconfcentral.com/modulereport/ietf-inet-types (lien)
+[2]: http://www.ietf.org/mail-archive/web/discuss/current/msg00987.html (lien)
+[3]: http://www.yang-central.org/twiki/bin/view/Main/ComparingYang (lien)
+[4]: http://www.aims-conference.org/issnsm-2008/06-netconf-yang.pdf (lien)
+[5]: http://www.yang-central.org/twiki/bin/view/Main/YangTools (lien)
+[6]: http://code.google.com/p/pyang/ (lien)
+[7]: http://www.yang-central.org/twiki/pub/Main/YangTools/yang-mode.el (lien)
+[8]: http://www.yang-central.org/ (lien)