Groupe de travail Réseau	M. Tuexen, Muenster Univ. of Applied Sciences	
Request for Comments : 5133	K. Morneault, Cisco Systems, Inc.	
RFC mise à jour : 4233 		
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle	décembre 2007	

Changement de numéro de demande d'interrogation d'identifiant de point d'extrémité de terminal (TEI)

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de 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 "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 copyright
Copyright (C) The Internet Society (2005).

Résumé
Le protocole de couche d'adaptation d'utilisateur (IUA, User Adaptation Layer) Q.921 du réseau numérique à intégration de services (RNIS) décrit dans la RFC 4233, définit le type de message de la demande d'interrogation d'identifiant de point d'extrémité de terminal (TEI, Terminal Endpoint Identifier) comme étant 5. Cependant, ce numéro est déjà utilisé par les extensions du système de signalisation de réseau privé numérique (DPNSS, Digital Private Network Signaling System) /système n° 2 de signalisation d'accès numérique (DASS 2, Digital Access Signaling System 2) au protocole IUA décrit dans la RFC 4129. Le présent document met à jour la RFC 4233 en spécifiant que le type de message des messages de demande d'interrogation de TEI est 8.

Table des matières
1. Introduction	1
2. Conventions utilisées dans le document	1
3. Nouveau type de message du message Interrogation de TEI	2
4. Considérations relatives à l'IANA	2
5. Considérations sur la sécurité	2
6. Remerciements	2
7 Références normatives	2
Adresse des auteurs	2
Déclaration complète de droits de reproduction	2

 	1.	Introduction

Le protocole de couche d'adaptation d'utilisateur (IUA, User Adaptation Layer) Q.921 du réseau numérique à intégration de services (RNIS) décrit dans la [RFC3057] ne définit pas de message de demande d'interrogation d'identifiant de point d'extrémité de terminal (TEI, Terminal Endpoint Identifier). Les extensions DUA au système de signalisation de réseau numérioque privé (DPNSS, Digital Private Network Signaling System)/système n° 2 de signalisation d'accès numérique (DASS 2, Digital Access Signaling System 2) au protocole IUA, décrites dans la [RFC4129], introduisent des messages d'état de connexion de liaison de données (DLC, Data Link Connection) de type 5, 6, et 7. Ensuite a été publiée la [RFC4233] qui met à jour la [RFC3057]. La [RFC4233] introduit aussi le message Demande d'interrogation de TEI et utilise pour lui le type de message 5. Cela rend impossible de différencier la demande d'état de DLC d'une demande d'interrogation de TEI.

Le présent document met à jour la [RFC4233].

 	2.	Conventions utilisées dans le document

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

 	3.	Nouveau type de message du message Interrogation de TEI

Le présent document met à jour la [RFC4233] en introduisant le changement suivant :

Les messages Interrogation d'identifiant de point d'extrémité de terminal (TEI, Terminal Endpoint Identifier) DOIVENT être codés avec un type de message de 8 au lieu de 5 comme décrit dans la [RFC4233].

 	4.	Considérations relatives à l'IANA

Dans la section "Types de message" du registre "Allocations de la couche d'adaptation d'utilisateur de signalisation", l'IANA a réservé le type de message 8 des messages de gestion pour les messages Demande d'interrogation de point d'extrémité de terminal (TEI, Terminal Endpoint Identifier).

 	5.	Considérations sur la sécurité

Le présent document n'exige aucune considérations de sécurité en plus de celles données dans la [RFC4233].

 	6.	Remerciements

Les auteurs tiennent à remercier Jon Peterson et Christian Vogt de meur précieux commentaires.

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

[RFC3057]	K. Morneault et autres, "Couche d'adaptation RNIS Q.921-utilisateur", février 2001. (Obsolète, voir RFC4233) (MàJ par RFC3807) (P.S.)

[RFC4129]	R. Mukundan et autres, "Extensions de système de signalisation de réseau privé numérique (DPNSS)/système n° 2 de signalisation d'accès numérique (DASS 2) au protocole IUA", septembre 2005. (P.S.)

[RFC4233]	K. Morneault et autres, "Couche d'adaptation d'utilisateur Q.921 du réseau numérique à intégration de services (RNIS)", janvier 2006. (Remplace RFC3057) (MàJ par RFC5133) (P.S.)

 	Adresse des auteurs

Michael Tuexen	Ken Morneault	
Muenster Univ. of Applied Sciences	Cisco Systems, Inc.	
Stegerwaldstr. 39	13615 Dulles Technology Drive	
48565 Steinfurt	13615 Dulles Technology Drive	
Germany	Herndon, VA  20171	
mél : tuexen@fh-muenster.de		
	mél : kmorneau@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, 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 fournies 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 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 ci encloses ne violent 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 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 actuellement fourni par la Internet Society.