Groupe de travail Réseau	A. Farrel, Old Dog Consulting
Request for Comments: 5511	avril 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Format Backus-Naur d'acheminement (RBNF) : syntaxe utilisée pour former les règles de codage dans diverses spécifications de protocole d'acheminement

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Plusieurs protocoles ont été spécifiés dans la zone Acheminement de l'IETF en utilisant une variante courante du format Backus-Naur (BNF) de représentation de la syntaxe de message. Cependant, il n'y a pas de définition formelle de cette version du BNF.

Il y a un intérêt à utiliser la même variante de BNF pour l'ensemble des protocoles qui sont couramment utilisés ensemble. Cela réduit la confusion and simplifie la mise en œuvre.

La mise à jour des documents existants pour utiliser des autres variantes de BNF qui sont déjà formellement documentées serait un travail conséquent.

Le présent document donne une définition formelle de la variante du BNF qui a été utilisée (qu'on appellera le BNF d'acheminement) et la rend disponible pour l'usage par les nouveaux protocoles.
Table des matières
1. Introduction	2
1.1 Terminologie	2
1.2 Usages existants	2
1.3 Déclaration d'applicabilité	2
2. Définitions formelles	3
2.1 Définitions de règle	3
2.2 Opérateurs	4
2.3 Conventions de rédaction	6
2.4 Préséance	7
3. Validation automatique	8
4. Considérations sur la sécurité	8
5. Remerciements	8
6. Références	8
6.1 Références normatives	8
6.2 Références pour information	8
Adresse de l'auteur	9

 	1.	Introduction

Le format Backus-Naur (BNF, Backus-Naur Form) a été utilisé pour spécifier les formats de message de plusieurs protocoles au sein de la zone Acheminement de l'IETF. Malheureusement, ces spécifications ne sont pas fondées sur une définition formelle spécifique de BNF, et elles diffèrent légèrement des définitions fournies en d'autres lieux.

Il est clairement précieux d'avoir une définition formelle du langage de définition de la syntaxe qui est utilisée. Il serait possible de convertir toutes les spécifications existantes pour utiliser une spécification ferme du BNF (par exemple, le BNF augmenté ou ABNF [RFC5234]) ; cependant, cela exigerait beaucoup de travail. On devrait noter que en ABNF les terminaux sont des entiers (caractères/octets) tandis que dans la forme BNF utilisée pour définir les formats de message, les terminaux sont des "objets" (une sorte d'éléments de message, mais pas des octets ou caractères individuels) ou des "messages" entiers. Cela signifie que convertir les spécifications existantes à utiliser une spécification de BNF établie exigerait aussi des extensions à cette spécification de BNF.

Par ailleurs, la variante de BNF utilisée par les spécifications en question (qui est similaire à un sous ensemble du BNF étendu [EBNF]) est cohérente et a seulement un petit nombre de constructions. Il y a donc un sens à fournir une définition de cette variante de BNF pour faciliter l'interprétation des documents existants et faciliter le développement de nouvelles spécifications de protocoles utilisant la même variante de BNF. Une spécification va aussi faciliter la vérification  automatisée des définitions formelles utilisées dans de futurs documents.

Le présent document fournit une telle spécification et appelle la variante de BNF "BNF d'acheminement" (RBNF, Routing BNF).

 	1.1	Terminologie
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119],.

 	1.2	Usages existants
La première utilisation notable de la variante de BNF qui nous concerne est dans la spécification du protocole de réservation de ressources (RSVP, Resource Reservation Protocol) [RFC2205]. RSVP a été éxtendu pour être utilisé dans les réseaux de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) pour fournir la signalisation de l'ingénierie du trafic (TE, Traffic Engineering) [RFC3209], et cela a été développé pour l'utiliser comme le protocole de signalisation dans les réseaux MPLS généralisé (GMPLS, Generalized MPLS) [RFC3473].

Chacune des trois utilisations de RSVP a donné lieu à un grand nombre de spécifications d'extensions de protocole pour fournir des caractéristiques supplémentaires au delà des documents de base. Chaque nouvelle caractérisitique est définie dans son propre document en utilisant la variante courante de BNF.

De nouveaux protocoles ont aussi été spécifiés en utilisant la même variante de BNF. Cela est arrivé en partie parce que les développeurs étaient familiarisés avec le BNF utilisé dans la [RFC2205], etc., mais aussi à cause du chevauchement entre les protocoles, en particulier par rapport aux objets de réseau contrôlés et en fonctionnement.

À remarquer que parmi ces protocoles sont le protocole de gestion de liaison (LMP, Link Management Protocol) [RFC4204] et le protocole d'élément de calcul de chemin (PCEP, Path Computation Element Protocol) [RFC5440]. Dans les deux cas, d'autres documents qui spécifient des extensions de protocole utilisent aussi la même variante de BNF.

 	1.3	Déclaration d'applicabilité
RBNF comme défini dans ce document est principalement applicable aux protocoles mentionnés dans le paragraphe précédent. La spécification peut être utilisée pour faciliter l'interprétation des RFC pré-existantes qui sont référencées. Elle devrait aussi être utilisée dans la spécification des extensions à ces protocoles.

RBNF pourrait aussi être utilisé pour la spécification de nouveaux protocoles. Ceci est approprié pour le développement de nouveaux protocoles qui sont en relation étroite avec ceux qui utilisent déjà RBNF. Par exemple, PCEP est en relation étroite avec RSVP-TE, et quand il a été développé, le groupe de travail PCE a choisi d'utiliser la même forme de BNF que celle déjà utilisée dans les spécifications RSVP-TE.

Si un protocole complètement nouveau est développé et est sans relation avec un protocole qui utilise déjà RBNF, le groupe de travail devrait considérer avec attention si il faut l'utilisation de RBNF ou d'une forme plus formellement spécifiée et plus large de BNF comme l'ABNF [RFC5234].

L'utilisation de RBNF pour spécifier des extensions aux protocoles qui n'utilisent pas déjà RBNF (c'est-à-dire, qui utilisent une autre forme de BNF) n'est pas recommandée.

 	2.	Définitions formelles
Les blocs de construction de base de BNF sont des règles et des opérateurs. Dans sa plus simple forme, une règle dans le contexte que nous définissons est un objet de protocole qui est traditionnellement défini par un diagramme binaire dans la spécification de protocole. Des règles plus complexes sont construites en combinant d'autres règles qui utilisent des opérateurs. La règle la plus complexe est le message qui est construit à partir d'une organisation d'objets de protocole spécifié par les opérateurs.

Une spécification RBNF consiste en une séquence de définitions de règle utilisant les opérateurs définis au paragraphe 2.2.  Une règle peut être construite à partir d'un ensemble d'autres règles utilisant des opérateurs. L'ordre de définition des règles n'a pas d'importance. C'est-à-dire, les règles subordonnées PEUVENT être définies d'abord et ensuite utilisées dans les définitions suivantes d'autres règles, ou les règles de niveau supérieur PEUVENT être définies en premier et suivies par un ensemble de définitions des règles subordonnées.

Les définitions de règles sont lues de gauche à droite sur toute ligne, et les lignes sont lues de haut en bas sur la page. Cela devient particulièrement important quand on considère des séquences de règles et d'opérateurs.

 	2.1	Définitions de règle
Aucune signification ne devrait être supposée aux caractères particuliers utilisés dans les noms de règles. Par exemple, il serait faux de supposer qu'une règle porte un nombre décimal parce que le nom de la règle commence ou se termine par la lettre "d". Cependant, des spécifications individuelles PEUVENT choisir d'allouer les noms de règle de toute façon qui rende plus facile l'interprétation de la règle par l'homme.

 	2.1.1	Délimitation de nom de règle
Tous les noms de règle sont enclos entre des crochets angulaires ("<" et ">"). Les noms de règle PEUVENT inclure tous caractères imprimables, mais NE DOIVENT PAS inclure de tabulations ou retours/sauts à la ligne.

Exemple :  <Path Message>

 	2.1.2	Objets
La règle la plus basique (indivisible) est appelée un objet. La définition d'un objet est dérivée de son contexte.

Les objets sont normalement écrits en majuscules. Ils n'utilisent généralement pas d'espaces dans le nom, au profit de soulignés ("_").

Exemple : <SENDER_TEMPLATE>

 	2.1.3	Constructions
Les règles qui sont construites à partir d'autres règles en utilisant des opérateurs sont appelées des constructions.

Les constructions sont écrites en minuscules, bien que des majuscules soient couramment utilisées pour indiquer les acronymes. Des espaces et des traits d'union sont utilisés entre mots au sein des noms.

Exemple : <descripteur d'envoyeur>

 	2.1.4	Messages
L'objectif final est la définition de messages. Ce sont des règles qui sont construites à partir d'objets et constructions en utilisant des opérateurs. La seule différence syntaxique entre un message et une construction est qu'aucune autre règle n'est normalement construite à partir d'un message.

Les messages sont normaement désignés en commençant par une majuscule.

Exemple : <Path Message>

 	2.2	Opérateurs
Les opérateurs sont utilisés pour bâtir des constructions et messages à partir des objets et constructions.

 	2.2.1	Allocation
L'allocation est utilisée pour former des constructions et messages.

Signification : la construction ou message désigné sur le côté gauche est défini comme étant réglé égal au côté droit de l'allocation.

Codage :  deux-points, deux-points, signe égal ("::=")

Exemple :  <WF descripteur de flux> ::= <FLOWSPEC>

Note : le côté gauche de l'allocation et l'opérateur de l'allocation DOIVENT être présents sur la même ligne.

 	2.2.2	Enchaînement
Les objets et constructions peuvent être combinés à la suite pour former une nouvelle construction ou un message.

Signification : les objets ou constructions DOIVENT être présents dans l'ordre spécifié. L'ordre de lecture de RBNF est déclaré à la Section 2.

Codage : une séquence d'objets et constructions est généralement séparée par des espaces. Les objets dans une séquence PEUVENT être séparés par des coupures de ligne.

Exemple : <SE flow descriptor> ::= <FLOWSPEC> <filter spec list>

Note : voir au paragraphe 2.3.3 des commentaires sur l'ordre des objets et constructions.

 	2.2.3	Présence facultative
La présence des objets et constructions peut être marquée comme facultative.

Signification : les objets ou constructions facultatifs PEUVENT être présent ou absents dans l'allocation. Sauf si c'est indiqué comme facultatif, les objets et constructions sont obligatoires et DOIVENT être présents. L'opérateur facultatif peut aussi être incorporé pour donner une dépendance hiérarchique de présence comme montré dans l'exemple ci-dessous.

Codage : contenu entre des crochets ("[" et "]").

Exemple :
     <PathTear Message> ::= <En-tête commun> [ <INTEGRITY> ]
                            <SESSION> <RSVP_HOP>
                            [ <descripteur de l'envoyeur> ]

Exemple d'incorporation : l'opérateur facultatif peut être incorporé. Par exemple,

<construct> ::= <MAND> [ <OPT_1> [ <OPT_2> ] ]

Dans cette construction, l'objet OPT_2 peut seulement être présent si OPT_1 est aussi present.

 	Note :	L'ensemble d'objets et constructions au sein de la même paire de crochets est traitée comme une unité (une construction sans nom). Cela signifie que quand plusieurs objets et constructions sont inclus dans la même paire de crochets, tous DOIVENT être inclus quand un est inclus, sauf si des crochets incorporés sont utilisés comme dans l'exemple précédent.

 	2.2.4	Solutions de remplacement
Des choix peuvent être indiqués dans les allocations.

Signification : une règle ou l'autre DOIT être présente.

Codage : Le symbole barre verticale ("|") est utilisé entre les objets ou constructions qui sont à choisir.

Exemple : <liste de descripteur de flux> ::= <FF liste de descripteur de flux> | <SE descripteur de flux>

Notes :
1.	L'utilisation de groupement explicite (paragraphe 2.2.6) est RECOMMANDÉ pour éviter la confusion. Le groupement implicite en utilisant des coupures de ligne (paragraphe 2.3.2) est souvent utilisé, mais donne lieu à des potentielles mauvaises interpretations et DEVRAIT être évité dans les nouvelles définitions.

2.	Plusieurs membres d'ensembles alternatifs peuvent donner lieu à confusion. Par exemple :
<liste de descripteur de flux> ::=  <vide> | <liste de descripteur de flux> <descripteur de flux>
pourrait être lu comme signifiant qu'une instance de <descripteur de flux> doit être présente ou est facultatve.

Pour éviter ce type de problème, un groupement explicite (voir le paragraphe 2.2.6) ou un intermédiaire DOIT être utilisé dans tous les nouveaux documents (les utilisations existantes ne sont pas déconseillées, et les analyseurs automatiques doivent traiter les RFC existantes). Voir aussi au paragraphe 2.4 une description des règles de préséance.

Donc : <construction> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>

n'est pas permis dans les nouveaux documents et DOIT être présenté en utilisant le groupement ou en utilisant une construction intermédiaire. Par exemple, et selon la signification voulue :

<construction> ::= ( <ALT_A> <ALT_B> ) | ( <ALT_C> <ALT_D> )

ou
<construct> ::= <ALT_A> ( <ALT_B> | <ALT_C> ) <ALT_D>

ou
<intermédiaire X> ::= <ALT_A> <ALT_B>
<intermédiaire Y> ::= <ALT_C> <ALT_D>
<construction> ::= <intermédiaire X> | <intermédiaire Y>

ou
<intermédiaire Z> ::= <ALT_B> | <ALT_C>
<construction> ::= <ALT_A> <intermédiaire Z> <ALT_D>

 	2.2.5	Répétition
Il se pourrait qu'une séquence d'objets ou constructions identifques soit exigée dans une allocation.

Signification : PEUT répéter l'objet, la construction intermédiaire, ou la construction précédent.

Codage : Trois points ("...").

Exemple :
     <Path Message> ::= <En-tête commun> [ <INTEGRITY> ]
                        <SESSION> <RSVP_HOP>
                        <TIME_VALUES>
                        [ <POLICY_DATA> ... ]
                        [ <descripteur d'envoyeur> ]

Notes :
1.	Un ensemble de zéro, un ou plusieurs objets ou constructions peut être réalisé en le combinant avec le concept facultatif montré dans l'exemple ci-dessus.

2.	Des séquences peuvent aussi être codées en construisant une construction récurrente utiliant l'opérateur Alternatif. Par exemple :

<séquence> ::= <OBJET> | ( <OBJET> <séquence> )

3.	La répétition peut aussi être appliquée à un composant d'une allocation pour indiquer la répétition facultative de ce composant. Par exemple, le message Notify dans la [RFC3473] est défini comme suit :

<message Notify> ::= <En-tête commun> [<INTEGRITY>]
                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
                          [ <MESSAGE_ID> ]
                          <ERROR_SPEC> <liste de session notify >

Dans cet exemple, il y a une séquence de zéro, une ou plusieurs instances de [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]. On pourrait objecter que l'utilisation du groupement (voir le paragraphe 2.2.6) ou d'une construction récurrente (voir la Note 2, ci-dessus) serait plus claire.

 	2.2.6	Groupement
Signification : un groupe d'objets ou constructions à traiter ensemble. Cette notation n'est pas obligatoire mais est RECOMMANDÉE poursa clarté. Voir le paragraphe 2.4 sur les préséancex.

Codage : des parenthèses ("(" et ")") entourent un ensemble d'objets, constructions, et opérateurs.

Exemple : <groupe> ::= ( <ceci> <cela> )

Notes :
1.	La règle de préséance du paragraphe 2.4 signifie que l'utilisation du groupement n'est pas nécessaire pour l'interprétation formelle de la représentation en BNF. Cependant, le groupement peut rendre le BNF plus facile à analyser sans ambiguïté. Le groupement ou une construction intermédiaire DOIT être utilisé pou les choix multiples (paragraphe 2.2.4).

2.	Les coupures de ligne (paragraphe 2.3.2) sont souvent utilisées pour clarifier le groupement comme on peut le voir dans la définition de <séquence> au paragraphe 2.2.5, mais elles ouvrent la porte à de mauvaises interprétations, et le groupement explicite est RECOMMANDÉ.

3.	Une solution de remplacement pratique au groupement est la définition de constructions intermédiaires comme illustré à la Note 2 du paragraphe 2.2.4.

 	2.3	Conventions de rédaction
 	2.3.1	Espace
Les espaces (c'est à dire les caractères espace) entre les opérateurs, objets, et constructions sont ignorées mais DEVRAIENT être utilisées pour la lisibilité.

 	2.3.2	Coupures de ligne
Les coupures de ligne au sein d'une allocation sont ignorées mais DEVRAIENT être utilisées pour la lisibilité.

Les coupures de ligne sont souvent utilisées pour impliquer le groupement au sein des règles de préséance établies au paragraphe 2.4, mais le groupement explicite (paragraphe 2.2.6) ou des constructions intermédiaires (paragraphe 2.2.4) DEVRAIENT être utilisées dans les nouvelles définitions.

Une coupure de ligne NE DOIT PAS être présente entre le côté gauche d'une allocation et l'opérateur de l'allocation (voir le paragraphe 2.2.1).

Les nouvelles allocations (c'est-à-dire, de nouvelles définitions de construction ou message) DOIVENT commencer sur une nouvelle ligne.

 	2.3.3	Ordre
L'ordre des objets et constructions dans une allocation est explicite.

Les spécifications de protocole PEUVENT opter pour déclarer que l'ordre est seulement RECOMMANDÉ. Dans ce cas, les éléments d'une liste d'objets et constructions PEUVENT être reçus dans n'importe quel ordre.

 	2.4	Préséance
La préséance est la principale opportunité de confusion dans l'utilisation de ce BNF. En particulier, l'utilisation de choix mélés à des enchaînements peut donner lieu à des interprétations différentes du BNF. Bien que la préséance puisse être déduite d'une lecture "appropriée" du BNF en utilisant les règles définies ci-dessus et de l'ordre de préséance montré ci-dessous, il est fortement RECOMMANDÉ aux auteurs d'utiliser le groupement (paragraphe 2.2.6) et l'ordre (paragraphe  2.3.3) pour éviter les cas où le lecteur serait autrement obligé de comprendre les règles de préséance.

Il est EXIGÉ des lecteurs automatiques qu'ils analysent correctement les règles avec ou sans cette utilisation du groupement.

Les divers mécanismes décrits dans les paragraphes précédents ont la préséance suivante, du plus haut (lien le plus serré) au sommet, au plus bas (et le moins serré) en bas :
objets, constructions
répétition
groupement, facultatif
enchaînement
alternative

Note : La préséance est la principale opportunité de confusion dans l'utilisation de ce BNF. il est fortement RECOMMANDÉ aux auteurs d'utiliser le groupement (paragraphe 2.2.6) dans tous les endroits où il y a une possibilité de mauvaise interprétation même quand la signification est évidente pour les auteurs.

Exemple : un exemple de confusion de préséance peut être trouvé au paragraphe 3.1.4 de la [RFC2205] et est mentionné au paragraphe 2.2.4.

<liste de descripteur de flux> ::=  <vide> | 
                                     <liste de descripteur de flux> <descripteur de flux>

La mise en œuvre DOIT décider laquelle des solution suivantes est voulue :

a.  <liste de descripteur de flux> ::= <vide> | 
                                   ( <liste de descripteur de flux> <descripteur de flux> )

b.  <liste de descripteur de flux> ::= ( <vide> | <liste de descripteur de flux> )
                                          <descripteur de flux>

La coupure de ligne PEUT être interprétée comme impliquant le groupement, mais ce n'est pas une règle explicite. Cependant, les règles de préséance disent que l'enchaînement a une préséance supérieure à celle de l'opérateur Alternative. Donc, le texte de la [RFC2205] DEVRAIT être interprété comme montré dans la formulation a.

De même (d'après le même paragraphe de la [RFC2205]) :

<liste de descripteur de flux> ::=
                        <FLOWSPEC>  <FILTER_SPEC>  |
                        <liste de descripteur de flux> <FF descripteur de flux>

DEVRA être interprété comme :

<liste de descripteur de flux> ::=
                      ( <FLOWSPEC> <FILTER_SPEC> ) |
                      ( <liste de descripteur de flux> <FF descripteur de flux> )

L'utilisation du groupement explicite ou de constructions intermédiaires est fortement RECOMMANDÉ dans les nouveaux textes pour éviter la confusion.

 	3.	Validation automatique

Le RBNF sera approprié pour la vérification utilisant des outils de validation automatique. Les outils de validation doivent être capables de vérifier une étroite conformité aux règles exprimées dans le présent document pour être utiles à la vérification des nouveaux documents, mais devraient aussi être capables d'analyser le RBNF tel qu'utilisé dans les RFC existantes. Aucun outil n'est connu pour l'instant.

 	4.	Considérations sur la sécurité

Le présent document ne définit aucun comportement du réseau et n'introduit ou ne cherche à résoudre aucun problème de sécurité.

On notera que des spécifications de protocole claires et sans ambiguïté reduisent la probabilité de mises en œuvre incompatibles ou défectueuses qui pourraient être exploitées dans des attaques contre la sécurité.

 	5.	Remerciements

Merci à Magnus Westerlund, Nic Neate, Chris Newman, Alfred Hoenes, Lou Berger, Julien Meuric, Stuart Venters, Tom Petch, Sam Hartman, et Pasi Eronen pour leur relecture et leurs commentaires.

 	6.	Références
 	6.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

 	6.2	Références pour information

[EBNF]	Norme ISO/CEI 14977, "Technologie de l'information  -- métalangage syntaxique -- BNF étendu", 1996.

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3473]	L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151,  8359)

[RFC4204]	J. Lang, éd., "Protocole de gestion de liaison (LMP)", octobre 2005. (P.S.)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5440]	JP. Vasseur et autres, "Protocole de communication d'élément de calcul de chemin (PCEP)", mars 2009. (P. S. ; MàJ par RFC7896, RFC8253, RFC8356, 9488)

 	Adresse de l'auteur

Adrian Farrel
Old Dog Consulting
mél : adrian@olddog.co.uk