Groupe de travail Réseau	G. Swallow, Cisco Systems, Inc.
Request for Comments : 5284	A. Farrel, Old Dog Consulting
Catégorie : Sur la voie de la normalisation	août 2008
Traduction Claude Brière de L'Isle	

Erreurs définies par l’utilisateur pour RSVP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le protocole de réservation de ressources (RSVP, Resource ReserVation Protocol) définit un objet ERROR_SPEC pour communiquer les erreurs. Cet objet a un format qui permet la définition de 256 codes d’erreur. Comme RSVP s’est développé et étendu, la convention a dû être prudente dans la définition de nouveaux codes d’erreur. De plus, aucune disposition pour des erreurs définies par l’utilisateur n’existe dans RSVP.

Le présent document définit une USER_ERROR_SPEC (spécification d’erreur d’utilisateur) à utiliser en plus de la ERROR_SPEC (spécification d’erreur) pour porter des informations d’utilisateur supplémentaires relatives à des erreurs.
Table des matières
1. Introduction	1
1.1 Conventions	2
2. Erreurs définies par l’utilisateur	2
3. Classe USER_ERROR_SPEC	2
3.1 Sous objets	3
4. Procédures pour utiliser la User Error Spec	3
4.1 Procédures d’envoi de User Error Spec	3
4.2 Procédures pour recevoir la User Error Spec	3
5. Considérations relatives à l’IANA	4
5.1 Codes d’erreur RSVP	4
5.2 Objets RSVP	4
6. Considérations sur la sécurité	4
7. Remerciements	4
8. Références	5
8.1 Références normatives	5
8.2 Références pour information	5
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

 	1.	Introduction

Le protocole de réservation de ressources (RSVP, Resource ReserVation Protocol) [RFC2205] définit un objet ERROR_SPEC pour communiquer les erreurs. Cet objet a un format qui permet la définition de 256 codes d'erreur. Avec le développement et l’extension de RSVP, la convention a dû être prudente pour la communication des erreurs. De plus, aucune disposition n’existe dans RSVP pour les erreurs définies par l’utilisateur.

Quand on développe des extensions à RSVP, il est souvent utile que ceux qui mettent en œuvre définissent des messages d’erreur pour aider aussi bien le débogage initial que les essais par rapport aux versions antérieures ou les autres mises en œuvre.

Le présent document définit un nouvel objet RSVP pour permettre de communiquer les erreurs définies par l’utilisateur. Cela va permettre aux organisations de définir des erreurs qu’elles peuvent utiliser pour le développement interne. Ces valeurs d’erreur pourraient aussi être partagées avec la communauté au sens large pour aider à promouvoir l’interopérabilité entre diverses mises en œuvre.

Les messages RSVP PathErr et ResvErr exigent la présence d’un objet ERROR_SPEC ([RFC2205]). La [RFC3473] définit le message Notify qui exige aussi la présence d’un objet ERROR_SPEC. Afin de ne pas changer le contenu obligatoire de ces messages, le présent document définit une nouvelle valeur de code d'erreur qui indique que le nouvel objet est présent et porte un code d'erreur défini par l’utilisateur.

Noter que le message ResvConf défini dans la [RFC2205] porte aussi un objet ERROR_SPEC. Mais cet usage de l’objet ne porte pas de codes ou valeurs d’erreur significatifs et donc les extensions définies dans le présent document ne sont pas applicables à ce message.

 	1.1	Conventions
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].

 	2.	Erreurs définies par l’utilisateur

Un nouveau code d’erreur est défini pour être utilisé dans un objet ERROR_SPEC.

Code d’erreur = 33 : spécification d’erreur par l’utilisateur

Ce code d'erreur est utilisé pour signaler la présence d’une USER_ERROR_SPEC. Une valeur d’erreur est définie comme suit  :

Valeur d’erreur 0 = plus de détails dans la spécification d’erreur par l’utilisateur

D’autres valeurs d’erreur pourront être définies dans de futures spécifications.

Lors de l’envoi de ce code d'erreur, un objet USER_ERROR_SPEC DOIT être inclus dans le message PathErr, ResvErr, ou Notify.

 	3.	Classe USER_ERROR_SPEC

Une nouvelle classe d’objet RSVP appelée USER_ERROR_SPEC est définie. Pour prendre en charge la rétro-compatibilité, son numéro de classe est dans la gamme 192 à 247. Comme défini dans la [RFC2205], les mises en œuvre qui ne comprennent pas un tel objet vont le transmettre non modifié.

Objet USER_ERROR_SPEC : classe = 194, C-Type = 1

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|                     Numéro d’entreprise                       |
+---------------+---------------+---------------+---------------+
|    Sous org.  | Long desc err | Valeur d’erreur d’utilisateur |
+---------------+---------------+---------------+---------------+
|                                                               |
~                       Description d’erreur                    ~
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
~             Sous objets définis par l’utilisateur             ~
|                                                               |
+---------------+---------------+---------------+---------------+

Numéro d’entreprise : identifiant unique d’une organisation codé sur un entier de 32 bits. Les numéros d’entreprise (parfois appelés Numéros d’entreprise privée) sont alloués par l’IANA et gérés sur la base du premier arrivé, premier servi dans le registre IANA "Numéros d’entreprise" [RFC2578].

Sous org  : identifiant unique d’une organisation codé sur un entier de 32 bits. Une organisation PEUT utiliser ce champ pour créer des espaces de valeurs d’erreur indépendants. Ceci est destiné à faciliter de travail d’équipes qui font du développement en parallèle. Si des espaces indépendants ne sont pas nécessaires, ce champ DEVRAIT être à zéro.

Long desc err : longueur de la description d’erreur dans le champ Description d’erreur en octets à l’exclusion de tout bourrage. Zéro est une longueur valide si aucune description d’erreur n’est fournie.

Valeur d’erreur d’utilisateur  : entier de 16 bits. La signification est spécifiée par la (sous) organisation indiquée par les champs Numéro d’entreprise et Sous org.

Description d’erreur : chaîne de caractères bourrée avec des nuls (0x00) à un multiple de 4 octets. En accord avec les lignes directrices de la [RFC2277], cette chaîne DOIT utiliser le codage UTF-8/Net-Unicode [RFC5198]. De plus, il est RECOMMANDÉ que les mises en œuvre limitent les chaînes qu’elles génèrent à une seule ligne imprimable US-ASCII [ASCII] chaque fois que faisable pour améliorer la probabilité d’une utilisation facile par le receveur. Si la longueur de description d’erreur est zéro, aucun octet n’est alors fourni. Noter que le contenu de ce champ est spécifique de la mise en œuvre. Il est normalement imprimable, mais peut n’être pas montré à tous les utilisateurs de toutes les mises en œuvre (à cause du choix du jeu de caractères). Donc, le contenu du champ DEVRAIT être limité aux informations supplémentaires et NE DEVRAIT PAS contenir d’informations critiques pour le fonctionnement du réseau. Les informations critiques sont présentes dans le champ Valeur d’erreur d’utilisateur.

Sous objets définis par l’utilisateur  : des sous objets définis par l’utilisateur PEUVENT être inclus. Le format générique des sous objets est spécifié au paragraphe 3.1. La sémantique d’un sous objet est indiquée par le champ Type, mais la sémantique, le format, et le contenu du champ Valeur sont spécifiés par la (sous) organisation indiquée par les champs Numéro d’entreprise et Sous org de cet objet.

 	3.1	Sous objets
Chaque sous objet est codé comme un TLV dans le format suivant :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|     Type      |     Longueur  | (contenu des sous objets)     |
+---------------+---------------+-------------//----------------+

Type  : nombre de 8 bits alloué par la (sous) organisation indiquée par les champs Numéro d’entreprise et Sous org de l’objet USER_ERROR_SPEC.

Longueur : contient la longueur totale du sous objet en octets, incluant les champs Type et Longueur. La longueur DOIT être d’au moins 4, et DOIT être un multiple de 4.

 	4.	Procédures pour utiliser la User_Error_Spec
 	4.1	Procédures d’envoi de User_Error_Spec
Un objet USER_ERROR_SPEC PEUT être inclus dans tout message PathErr, ResvErr, ou Notify pour tout code d'erreur défini. Le numéro d’entreprise DOIT être une valeur valide allouée par l’IANA dans le registre "Numéros d’entreprise".

Comme spécifié dans les [RFC2205] et [RFC3473], un objet ERROR_SPEC avec un code d'erreur valide DOIT être inclus dans tous les messages PathErr, ResvErr, et Notify. Cette règle n’est pas changée par ces procédures même quand un objet USER_ERROR_SPEC est inclus. Si aucun autre code d'erreur ne s’applique, le code d’erreur dans l’objet ERROR_SPEC DOIT être réglé à "Spécification d’erreur d’utilisateur" comme défini à la Section 2 du présent document. Quand le code d’erreur dans l’objet ERROR_SPEC est réglé à "Spécification d’erreur d’utilisateur", le sous code Valeur d’erreur DEVRAIT être réglé à "Plus de détails dans la spécification d’erreur d’utilisateur" comme défini à la Section 2, mais plus de sous codes de valeur d’erreur peuvent être définis dans de futures spécifications.

 	4.2	Procédures pour recevoir la User Error Spec
Il est RECOMMANDÉ que les mises en œuvre qui reçoivent un message PathErr, ResvErr, ou Notify portant un objet USER_ERROR_SPEC enregistrent (au minimum) le numéro d’entreprise, la sous organisation, la valeur d’erreur d’utilisateur, et la description d’erreur. Noter que le jeu de caractères utilisé pour la description d’erreur peut signifier qu’il pourrait ne pas convenir pour l’affichage de l’enregistrement dans tous les systèmes. Les mises en œuvre capables d’interpréter le contenu de l’objet USER_ERROR_SPEC DEVRAIENT prendre d’autres mesures sur la base de l’erreur rapportée.

Les mises en œuvre qui ne prennent pas en charge UTF-8 et qui reçoivent un objet USER_ERROR_SPEC DEVRAIENT traiter la description d’erreur en accord avec les procédures établies dans la [RFC5137].

Si un message reçu contient un objet ERROR_SPEC qui utilise le code d'erreur "Spécification d’erreur d’utilisateur" mais ne contient pas d’objet USER_ERROR_SPEC, le message DOIT être traité comme mal formé et traité en accord avec la [RFC2205].

Les mises en œuvre DEVRAIENT ignorer les occurrences répétées des objets USER_ERROR_SPEC, et DEVRAIENT les transmettre inchangés sur tout message qu’elles transmettent. Cela assiure la rétro-compatibilité.

Les mises en œuvre qui reçoivent un objet USER_ERROR_SPEC dans un message autre que PathErr, ResvErr, ou Notify DOIVENT traiter l’erreur comme un message mal formé et le traiter conformément à la [RFC2205].

 	5.	Considérations relatives à l’IANA
 	5.1	Codes d’erreur RSVP
Le présent document fait les allocations suivantes dans le registre RSVP des codes d’erreur et sous codes de valeur d’erreur définies mondialement :

Code d’erreur	Signification
       33 	Spécification d’erreur d’utilisateur

Un sous code de valeur d’erreur est défini pour être utilisé avec ce code d’erreur comme suit :

0 = Plus de détails dans la spécification d’erreur d’utilisateur

 	5.2	Objets RSVP
Le présent document fait les allocations suivantes dans le registre RSVP des noms de classes, numéros de classes, et types de classes :

Espace de numéros	Valeur	Nom
Numéros de classe	194	USER_ERROR_SPEC
Type de classe	    1	Erreur définie par l’utilisateur

 	6.	Considérations sur la sécurité

Le présent document ne fait pas de changement aux échanges de messages de base des [RFC2205] et [RFC3473]. Il va en résulter une petite augmentation du nombre de messages d’erreur envoyés dans les cas où les messages étaient précédemment éliminés en silence du fait de l’absence d’un code d’erreur approprié.

Les mécanismes définis dans le présent document peuvent être utilisés par les mises en œuvre pour rapporter des conditions d’erreur supplémentaires et des informations survenant de problèmes de sécurité et d’attaques contre le réseau RSVP.

Noter que l’utilisation d’une chaîne de caractères qui va être affichée ou enregistrée donne des opportunités pour certaines attaques par l’utilisation de caractères de commande rajoutés ou incorporés. Les mises en œuvre DEVRAIENT prendre des précautions contre les rajouts, et (en particulier lorsque le jeu de caractères complet de la [RFC5198] n’est pas pris en charge, DEVRAIENT utiliser les procédures de la [RFC5137] pour traiter les caractères de commande inattendus ou inconnus.

 	7.	Remerciements

Les auteurs tiennent à remercier Elisheva Halevy qui a motivé le présent document. Merci à Tom Nadeau, Magnus Westerlund, Hannes Tschofenig, Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, et Tom Petch de leur relecture et de leurs commentaires.

 	8.	Références
 	8.1	Références normatives

[ASCII]	American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.

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

[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.)

[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)

[RFC5137]	J. Klensin, "Codage ASCII des caractères Unicode", février 2008. (BCP0137)

[RFC5198]	J. Klensin, M. Padlipsky, "Format Unicode pour les échanges sur le réseau", mars 2008. (Remplace RFC0698, MàJ RFC0854) (P.S.)

 	8.2	Références pour information

[RFC2277]	H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", BCP 18, janvier 1998.

[RFC2578]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure des informations de gestion, version 2 (SMIv2)", avril 1999. (STD0058)

 	Adresse des auteurs

George Swallow	Adrian Farrel	
Cisco Systems, Inc.	Old Dog Consulting	
mél : swallow@cisco.com	mél : adrian@olddog.co.uk	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).