RFC(F) 3836

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau                                      A. Beck
Appel à observations: 3836                                    M. Hofmann
Catégorie: Informationnelles                         Technologies Lucent
                                                                H. Orman
                                          Développement de Purple Streak
                                                                R. Penno
                                                         Nortel Networks
                                                               A. Terzis
                                                Université Johns Hopkins
                                                               Août 2004

Conditions requises pour les services Open Pluggable Edge (OPES)

Protocoles d'accroche

Statut de ce mémo

   Ce mémo fournit des informations à la communauté Internet. Cela fait
   ne pas spécifier de norme Internet d'aucune sorte. Distribution de ceci
   le mémo est illimité.

Copyright

   Copyright (C) L'Internet Society (2004).

Abstrait

   Ce document spécifie les exigences que l'OPES (Open
   Le protocole d'appel Pluggable Edge Services) doit satisfaire pour
   prend en charge l'exécution à distance des services OPES. Les exigences sont
   destiné à aider à évaluer les candidats potentiels au protocole, ainsi qu'à
   guider l'élaboration de tels protocoles.

Table des matières

   1. Terminologie. . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Présentation. . . . . . . . . . . . . . . . . . . . . . . . . 2
   3. Exigences fonctionnelles. . . . . . . . . . . . . . . . . . . 3
       3.1. Fiabilité. . . . . . . . . . . . . . . . . . . . . . 3
       3.2. Évitement de la congestion. . . . . . . . . . . . . . . . . 3
       3.3. Transactions d'accroche. . . . . . . . . . . . . . . . . 3
       3.4. Connexions de légende. . . . . . . . . . . . . . . . . . 4
       3.5. Échange de messages asynchrone. . . . . . . . . . . . . 5
       3.6. Segmentation des messages. . . . . . . . . . . . . . . . . 5
       3.7. Prise en charge du mécanisme Keep-Alive. . . . . . . . . . . 6
       3.8. Fonctionnement dans des environnements NAT. . . . . . . . . . . . . 6
       3.9. Serveurs d'appels multiples. . . . . . . . . . . . . . . 6
       3.10. Processeurs OPES multiples. . . . . . . . . . . . . . . 6
       3.11. Prise en charge de différents protocoles d'application. . . . . . 7
       3.12. Négociations sur les capacités et les paramètres. . . . . . . . . 7
       3.13. Méta-données et instructions. . . . . . . . . . . . . . 8
   4. Exigences de performance. . . . . . . . . . . . . . . . . . 9
       4.1. Efficacité du protocole. . . . . . . . . . . . . . . . . . 9
   5. Exigences de sécurité. . . . . . . . . . . . . . . . . . . . 9
       5.1. Authentification, confidentialité et intégrité. . . . 9
       5.2. Confidentialité hop-by-hop. . . . . . . . . . . . . . . dix
       5.3. Opération sur des domaines non approuvés. . . . . . . . . . . dix
       5.4. Intimité . . . . . . . . . . . . . . . . . . . . . . . . dix
   6. Considérations de sécurité. . . . . . . . . . . . . . . . . . . dix
   7. Références. . . . . . . . . . . . . . . . . . . . . . . . . . dix
       7.1. Références normatives. . . . . . . . . . . . . . . . . . dix
       7.2. Références informatives. . . . . . . . . . . . . . . . . 11
   8. Remerciements. . . . . . . . . . . . . . . . . . . . . . . 11
   9. Adresses des auteurs. . . . . . . . . . . . . . . . . . . . . . 12
   10. Déclaration de copyright complète. . . . . . . . . . . . . . . . . . . 13

1. Terminologie

   Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS",
   «DEVRAIT», «NE DEVRAIT PAS», «RECOMMANDÉ», «PEUT» et «OPTIONNEL» dans ce
   document doivent être interprétés comme décrit dans BCP 14, RFC 2119 [2].

2. Présentation

   L’architecture OPES (Open Pluggable Edge Services) [1] permet
   services d'application coopératifs (services OPES) entre une donnée
   fournisseur, un consommateur de données et zéro ou plusieurs processeurs OPES. le
   services applicatifs envisagés analyser, et éventuellement
   transformation, messages au niveau de l'application échangés entre les données
   fournisseur et le consommateur de données.

   L'exécution de ces services est régie par un ensemble de règles
   installé sur le processeur OPES. L'application des règles peut
   déclencher l'exécution d'applications de service locales à l'OPES
   processeur. Alternativement, le processeur OPES peut distribuer le
   responsabilité de l'exécution du service en communiquant et
   collaborer avec un ou plusieurs serveurs d'appels distants. Comme décrit
   dans [1], un processeur OPES communique avec et appelle des services sur un
   serveur de callout en utilisant un protocole de callout. Ce document présente
   les exigences d'un tel protocole.

   Les exigences de ce document sont divisées en trois catégories -
   exigences fonctionnelles, exigences de performance et sécurité
   exigences. Chaque exigence est présentée comme une ou plusieurs
   déclarations, suivies de brèves explications, le cas échéant.

3. Exigences fonctionnelles

3.1. Fiabilité

   Le protocole d'appel OPES DOIT être en mesure de fournir une fiabilité ordonnée
   pour la communication entre un processeur OPES et un serveur d'appel.
   De plus, le protocole d'appel DEVRAIT être en mesure de fournir
   fiabilité incontrôlée.

   Afin de répondre aux exigences de fiabilité, la légende
   le protocole DEVRAIT spécifier qu'il doit être utilisé avec un transport
   protocole qui fournit une fiabilité ordonnée / non ordonnée au
   couche de transport, par exemple TCP [6] ou SCTP [7].

3.2. Évitement de la congestion

   Le protocole d'appel OPES DOIT garantir que l'évitement d'encombrement
   correspondant à la norme RFC 2914 [4] est appliquée à toutes les communications
   entre le processeur OPES et le serveur d'appel. A cet effet, le
   Le protocole d'appel DEVRAIT utiliser une couche de transport contrôlée par encombrement
   protocole, probablement TCP [6] ou SCTP [7].

3.3. Transactions d'accroche

   Le protocole d'appel OPES DOIT activer un processeur OPES et un appel
   serveur pour effectuer des transactions d'appels dans le but d'échanger
   messages de protocole partiels ou complets au niveau de l'application (ou
   modifications de celui-ci). Plus spécifiquement, le protocole d'appel DOIT
   permettre à un processeur OPES de transmettre une application partielle ou complète
   message à un serveur d'appel afin qu'un ou plusieurs services OPES puissent
   traiter le message d'application transmis (ou des parties de celui-ci). le
   le résultat de l'opération de service peut être une application modifiée
   message. Le protocole d'appel DOIT donc activer l'appel

   serveur pour renvoyer un message d'application modifié ou les pièces modifiées
   d'un message d'application au processeur OPES. De plus, le
   le protocole d'appel DOIT permettre à un serveur d'appel de rapporter le résultat de
   une transaction d'accroche (par exemple, sous la forme d'un code d'état) retour à
   le processeur OPES.

   Une transaction d'accroche est définie comme un échange de messages entre un
   Processeur OPES et serveur d'appel constitué d'une requête d'appel
   et une réponse d'appel. Les deux, la demande de légende et la légende
   réponse PEUT chacun consister en un ou plusieurs messages de protocole d'appel,
   c'est-à-dire une série de messages de protocole. Une demande d'appel DOIT toujours
   contiennent un message de candidature partiel ou complet. Une légende
   La réponse DOIT toujours indiquer le résultat de la transaction d'appel.
   Une réponse d'appel PEUT contenir un message d'application modifié.

   Les transactions d'accroche sont toujours initiées par une demande d'accroche de
   un processeur OPES et sont généralement terminés par une réponse d'appel
   à partir d'un serveur d'appel. Le protocole d'appel OPES DOIT, cependant, également
   fournir un mécanisme qui autorise l'un ou l'autre des points de terminaison d'une légende
   transaction pour mettre fin à une transaction d'accroche avant une légende
   la demande ou la réponse a été entièrement reçue par le correspondant
   point de terminaison de l'accroche. Un tel mécanisme DOIT garantir qu'une prématurité
   la résiliation d'une transaction de rappel n'entraîne pas la perte de
   données de message d'application.

   Une résiliation prématurée d'une transaction d'appel est nécessaire pour
   prend en charge les services OPES, qui peuvent se terminer avant même qu'ils n'aient
   a traité l'intégralité du message de candidature. Services d'analyse de contenu,
   par exemple, peut être en mesure de classer un objet Web après avoir
   traité uniquement les premiers octets d'un objet Web.

3.4. Connexions d'accroche

   Le protocole d'appel OPES DOIT activer un processeur OPES et un appel
   serveur pour effectuer plusieurs transactions d'accroche sur une légende
   lien. De plus, le protocole d'appel DOIT fournir une méthode
   d'associer des transactions d'accroche à des connexions d'accroche. UNE
   la connexion de légende est définie comme une connexion logique au
   couche d'application entre un processeur OPES et un serveur d'appel. UNE
   la connexion d'appel PEUT avoir certains paramètres qui lui sont associés,
   par exemple, les paramètres qui contrôlent le comportement de basculement de
   points de terminaison de connexion. Les paramètres spécifiques à la connexion d'appel PEUVENT être
   négocié entre les processeurs OPES et les serveurs d'appel (voir la section
   3.12).

   Le protocole d'appel OPES PEUT choisir de multiplexer plusieurs appels
   connexions via une connexion de couche de transport unique si un flux
   mécanisme de contrôle garantissant l'équité entre les appels multiplexés
   les connexions sont appliquées.

   Les connexions de rappel DOIVENT toujours être initiées par un processeur OPES. UNE
   la connexion d'appel PEUT être fermée par l'un ou l'autre des points d'extrémité du
   connexion, à condition que cela n'affecte pas le
   opération de transactions d'accroche en cours associées à
   connexion de légende.

3.5. Échange de messages asynchrone

   Le protocole d'appel OPES DOIT prendre en charge un message asynchrone
   échange sur des connexions de légende.

   Afin de permettre un traitement asynchrone sur le processeur OPES et
   serveur d'appel, il DOIT être possible de séparer l'émission de la demande de
   traitement des réponses. Le protocole DOIT donc autoriser plusieurs
   demandes d'appel en suspens et fournir une méthode de corrélation
   réponses d'accroche avec des demandes d'accroche.

   De plus, le protocole d'appel DOIT permettre à un serveur d'appel de
   répondre à une demande d'accroche avant d'avoir reçu l'intégralité
   demande.

3.6. Segmentation des messages

   Le protocole d'appel OPES DOIT permettre à un processeur OPES de transmettre un
   message d'application à un serveur d'appel dans une série de
   fragments de message. Le protocole d'appel DOIT en outre activer le
   réception du serveur d'appel pour réassembler l'application fragmentée
   message.

   De même, le protocole d'appel DOIT permettre à un serveur d'appel de retourner
   un message d'application à un processeur OPES dans une série de
   fragments de message. Le protocole d'appel DOIT activer la réception
   Processeur OPES pour réassembler le message d'application fragmenté.

   En fonction du protocole de couche application utilisé sur le chemin de données,
   les messages d'application peuvent être très volumineux (par exemple dans le
   cas de flux audio / vidéo) ou de taille inconnue. Dans les deux cas, le
   Le processeur OPES doit lancer une transaction d'appel avant d'avoir
   reçu l'intégralité du message de candidature pour éviter de longs retards
   consommateur de données. Le processeur OPES DOIT donc pouvoir transmettre
   fragments ou morceaux d'un message d'application à un serveur d'appel comme

   il les reçoit du fournisseur de données ou du consommateur. De même, le
   le serveur d'appel DOIT être capable de traiter et de renvoyer le message d'application
   fragments comme il les reçoit du processeur OPES.

   La segmentation des messages d'application est également requise si la légende OPES
   protocole fournit un mécanisme de contrôle de flux afin de multiplexer
   plusieurs connexions de légende sur une seule connexion de couche de transport
   (voir section 3.4).

3.7. Prise en charge du mécanisme Keep-Alive

   Le protocole d'appel OPES DOIT fournir un mécanisme de maintien en vie qui,
   s'il est utilisé, permettrait aux deux points de terminaison d'une connexion d'accroche de détecter
   une panne de l'autre endpoint, même en l'absence de légende
   transactions. Le protocole d'appel PEUT spécifier que keep-alive
   les messages soient échangés via des connexions d'appel existantes ou un
   connexion entre le processeur OPES et le serveur d'appel. La légende
   protocole PEUT également spécifier que l'utilisation du mécanisme de maintien en vie est
   optionnel.

   La détection d'une défaillance du serveur d'appel peut activer un OPES
   processeur pour établir une connexion de légende avec une légende de veille
   serveur afin que les futures transactions d'appel n'entraînent pas la perte
   des données de message d'application. La détection de la panne d'un OPES
   le processeur peut permettre à un serveur d'appel de libérer des ressources qui
   ne serait autrement pas disponible pour les transactions d'accroche avec d'autres
   Processeurs OPES.

3.8. Fonctionnement dans des environnements NAT

   Le protocole OPES DEVRAIT être compatible NAT, c'est-à-dire que son fonctionnement devrait
   ne pas être compromis par la présence d'un ou plusieurs périphériques NAT dans le
   chemin entre un processeur OPES et un serveur d'appel.

3.9. Serveurs d'appels multiples

   Le protocole d'appel OPES DOIT permettre à un processeur OPES de
   communiquer simultanément avec plus d'un serveur d'appel.

   Dans les grands réseaux, les services OPES sont probablement hébergés par
   différents serveurs d'appels. Par conséquent, un processeur OPES sera probablement
   doivent communiquer avec plusieurs serveurs d'appel. Le protocole
   la conception DOIT permettre à un processeur OPES de le faire.

3.10. Processeurs OPES multiples

   Le protocole d'appel OPES DOIT permettre à un serveur d'appel de
   communiquer simultanément avec plus d'un processeur OPES.

   La conception du protocole DOIT prendre en charge un scénario dans lequel plusieurs OPES
   les processeurs utilisent les services d'un seul serveur d'appel.

3.11. Prise en charge de différents protocoles d'application

   Le protocole d'appel OPES DEVRAIT être indépendant du protocole d'application,
   c'est-à-dire qu'il NE DEVRAIT faire aucune hypothèse sur les caractéristiques de
   le protocole de couche application utilisé sur le chemin de données entre les données
   fournisseur et consommateur de données. Au minimum, le protocole d'appel DOIT
   être compatible avec HTTP [5].

   Les entités OPES sur le chemin de données peuvent utiliser différentes applications.
   protocoles de couche, y compris, mais sans s'y limiter, HTTP [5] et RTP [8].
   Il serait souhaitable de pouvoir utiliser la même légende OPES
   protocole pour tout protocole de la couche application.

3.12. Négociations sur les capacités et les paramètres

   Le protocole d'appel OPES DOIT prendre en charge la négociation de
   fonctionnalités et paramètres de connexion de légende entre un OPES
   processeur et un serveur d'appel. Cela implique que le processeur OPES
   et le serveur d'appel DOIT être en mesure d'échanger leurs capacités
   et préférences. Ensuite, ils DOIVENT être capables de s'engager dans un processus déterministe
   processus de négociation qui se termine soit avec les deux points de terminaison
   convenir des capacités et des paramètres à utiliser pour l'avenir
   connexions / transactions d'accroche ou avec une détermination que leur
   les capacités sont incompatibles.

   Capacités et paramètres qui pourraient être négociés entre un OPES
   le processeur et un serveur d'appel incluent (mais ne sont pas limités à):
   version du protocole d'appel, comportement de basculement, fréquence cardiaque pour
   messages keep-alive, paramètres liés à la sécurité, etc.

   Le protocole d'appel NE DOIT PAS utiliser la négociation pour déterminer le
   protocole de transport à utiliser pour les connexions d'appel. La légende
   protocole PEUT cependant spécifier qu'un certain message d'application
   protocole (par exemple, HTTP [5], RTP [8]) nécessite l'utilisation d'un certain
   protocole de transport (par exemple, TCP [6], SCTP [7]).

   Les paramètres de connexion de légende peuvent également concerner les caractéristiques
   des services de légende OPES si, par exemple, les connexions de légende sont
   associé à un ou plusieurs services OPES spécifiques. Un OPES
   un paramètre spécifique au service peut, par exemple, spécifier quelles parties de
   un message d'application dont un service OPES a besoin pour son fonctionnement.

   Les paramètres de connexion d'appel DOIVENT être négociés par appel
   base de connexion et avant toute transaction d'appel
   via la connexion d'accroche correspondante. Autres paramètres et

   capacités, telles que le comportement de basculement, PEUVENT être négociées
   entre les deux points de terminaison indépendamment des connexions de légende.

   Les parties à un protocole d'appel PEUVENT utiliser des connexions d'appel pour
   négocier tout ou partie de leurs capacités et paramètres.
   Alternativement, une connexion de contrôle séparée PEUT être utilisée pour cela
   objectif.

3.13. Méta-données et instructions

   Le protocole d'appel OPES DOIT fournir un mécanisme pour les points d'extrémité
   d'une transaction d'accroche particulière pour inclure des métadonnées et
   instructions pour le processeur OPES ou le serveur de légende dans la légende
   demandes et réponses.

   Plus précisément, le protocole d'appel DOIT permettre à un processeur OPES de
   inclure des informations sur le message d'application transféré dans un
   demande de rappel, p.ex. pour spécifier le type de
   message d'application ou pour spécifier quelle (s) partie (s) de l'application
   les messages sont transmis au serveur d'appel. De même, la légende
   le serveur DOIT être en mesure d'inclure des informations sur le
   message d'application.

   Le processeur OPES DOIT en outre être en mesure d'inclure une liste ordonnée de
   un ou plusieurs services OPES spécifiés de manière unique qui doivent être
   effectuée sur le message d'application transféré dans le
   ordre. Cependant, comme le protocole d'appel PEUT également choisir d'associer
   des connexions avec des services OPES spécifiques, il se peut qu'il n'y ait pas
   besoin d'identifier les services OPES sur une base de transaction par appel.

   De plus, le protocole d'appel OPES DOIT autoriser le serveur d'appel
   pour indiquer au processeur OPES la capacité de mise en cache de la légende
   réponses. Cela implique que les réponses aux appels doivent porter
   instructions de contrôle du cache pour le processeur OPES.

   Le protocole d'appel OPES DOIT en outre permettre au processeur OPES de
   indiquer au serveur d'appel s'il a conservé une copie locale du
   message d'application transmis (ou des parties de celui-ci). Cette information
   permet au serveur d'appel de déterminer si le transfert
   le message d'application doit être renvoyé au processeur OPES, même si
   il n'a pas été modifié par un service OPES.

   Le protocole d'appel OPES DOIT également permettre aux processeurs OPES de se conformer
   avec les exigences de traçage de l'architecture OPES telles que définies dans
   [1] et [3]. Cela implique que le protocole d'appel DOIT activer un
   serveur d'appel pour transmettre au processeur OPES des informations sur le
   Opérations de service OPES effectuées sur l'application transmise
   message.

4. Exigences de performance

4.1. Efficacité du protocole

   Le protocole d'appel OPES DEVRAIT avoir une latence minimale. Par exemple,
   la taille et la complexité de ses en-têtes pourraient être minimisées.

   Parce que les transactions d'appel OPES ajoutent une latence au protocole d'application
   transactions sur le chemin des données, l'efficacité du protocole d'appel est cruciale
   à la performance globale.

5. Exigences de sécurité

   En l'absence de tout mécanisme de sécurité, les informations sensibles
   peut être communiqué entre le processeur OPES et l'appel
   serveur en violation de la politique de sécurité et de confidentialité de l'un ou l'autre des terminaux,
   par une mauvaise configuration ou une attaque d'initié délibérée. En utilisant
   authentification forte, cryptage des messages et contrôles d'intégrité,
   la menace peut être réduite à un plus petit nombre d'initiés et / ou d'opérateurs
   erreurs de configuration.

   Le processeur OPES et les serveurs d'appel DEVRAIENT avoir des
   politiques qui limitent les parties avec lesquelles ils communiquent et qui
   déterminer les protections à utiliser en fonction des identités des terminaux
   et d'autres données (telles que les politiques de l'utilisateur final). Afin de faire respecter la
   politiques, ils DOIVENT être en mesure d'authentifier le protocole d'appel
   points de terminaison utilisant des méthodes cryptographiques.

5.1. Authentification, confidentialité et intégrité

   Les parties au protocole d'appel DOIVENT avoir une base solide pour
   lier les identités authentifiées aux points de terminaison du protocole, et ils
   DOIT vérifier que ces identités sont cohérentes avec leur sécurité
   Stratégies.

   Le protocole d'appel OPES DOIT prévoir l'authentification des messages,
   confidentialité et intégrité entre le processeur OPES et le
   serveur d'accroche. Il DOIT fournir une authentification mutuelle. Pour ça
   but, le protocole d'appel DEVRAIT utiliser la sécurité existante
   mécanismes. La spécification du protocole d'appel n'est pas requise pour
   spécifier les mécanismes de sécurité, mais il PEUT plutôt faire référence à un
   protocole de sécurité de niveau inférieur et discutez de la manière dont ses mécanismes doivent
   être utilisé avec le protocole d'appel.

5.2. Confidentialité hop-by-hop

   Si le chiffrement saut par saut est une exigence pour le chemin du contenu, alors
   cette confidentialité DOIT être étendue à la communication entre
   le processeur OPES et le serveur d'appel. Bien qu'il soit recommandé
   que la communication entre le processeur OPES et le serveur d'appel
   toujours être crypté, le cryptage PEUT être facultatif si les deux OPES
   le processeur et le serveur d'appel sont co-localisés ensemble dans un même
   domaine administratif avec de fortes garanties de confidentialité.

   Afin de minimiser l'exposition des données, le protocole d'appel DOIT utiliser un
   clé de chiffrement différente pour chaque flux de contenu chiffré.

5.3. Opération sur des domaines non approuvés

   Le protocole d'appel OPES DOIT fonctionner en toute sécurité sur des
   domaines entre le processeur OPES et le serveur d'appel.

   Si les canaux de communication entre le processeur OPES et la légende
   serveur croisé en dehors de l'organisation qui est responsable de la
   Services OPES, puis authentification des terminaux et protection des messages
   (confidentialité et intégrité) DOIT être utilisé.

5.4. Intimité

   Toute communication contenant des informations pertinentes aux politiques de confidentialité
   DOIT protéger les données à l'aide du cryptage.

6. Considérations relatives à la sécurité

   Les exigences de sécurité pour le protocole d'appel OPES sont discutées
   dans la section 5.

7. Références

7.1. Références normatives

   [1] Barbir, A., Penno, R., Chen, R., Hofmann, M. et H. Orman, "An
        Architecture pour Open Pluggable Edge Services (OPES) ", RFC 3835,
        Août 2004.

   [2] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer l'exigence
        Niveaux », BCP 14, RFC 2119, mars 1997.

   [3] Floyd, S. et L. Daigle, "IAB Architectural and Policy
        Considérations relatives aux services Open Pluggable Edge ", RFC 3238,
        Janvier 2002.

   [4] Floyd, S. et L. Daigle, "IAB Architectural and Policy
        Considérations relatives aux services Open Pluggable Edge ", RFC 3238,
        Janvier 2002.

   [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P., et T. Berners-Lee, "Hypertext Transfer Protocol -
        HTTP / 1.1 ", RFC 2616, juin 1999.

7.2. Références informatives

   [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        Septembre 1981.

   [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. et V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, octobre 2000.

   [8] Schulzrinne, H., Casner, S., Frederick, R. et V. Jacobson,
        "RTP: un protocole de transport pour les applications en temps réel", RFC
        3550, juillet 2003.

8. Remerciements

   Certaines parties de ce document sont basées sur des travaux antérieurs d'Anca Dracinschi
   Sailer, Volker Hilt et Rama R. Menon.

   Les auteurs tiennent à remercier les participants du GT OPES pour
   leurs commentaires sur ce document.

9. Adresses des auteurs

   André Beck
   Technologies Lucent
   101, chemin Crawfords Corner
   Holmdel, NJ 07733
   NOUS

   COURRIEL: abeck@bell-labs.com

   Markus Hofmann
   Technologies Lucent
   Salle 4F-513
   101, chemin Crawfords Corner
   Holmdel, NJ 07733
   NOUS

   Téléphone: +1732332 5983
   COURRIEL: hofmann@bell-labs.com

   Hilarie Orman
   Développement de Purple Streak

   COURRIEL: ho@alum.mit.edu
   URI: http://www.purplestreak.com

   Reinaldo Penno
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821
   NOUS

   Courriel: rpenno@nortelnetworks.com

   Andreas Terzis
   Département d'informatique
   Université Johns Hopkins
   3400 North Charles Street, 224 NEB
   Baltimore, MD 21218

   Téléphone: +1410516 5847
   COURRIEL: terzis@cs.jhu.edu

10. Déclaration de droit d'auteur complète

   Copyright (C) L'Internet Society (2004). Ce document est sujet
   aux droits, licences et restrictions contenus dans BCP 78, et
   sauf indication contraire, les auteurs conservent tous leurs droits.

   Ce document et les informations qu'il contient sont fournis sur un
   "TEL QUEL" et LE CONTRIBUTEUR, L'ORGANISATION QU'IL / ELLE REPRÉSENTE
   OU EST SPONSORISÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ INTERNET ET INTERNET
   GÉNIE TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE,
   INCLUANT, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION
   LES INFORMATIONS CI-DESSUS NE VIOLENT AUCUN DROIT OU TOUT DROIT IMPLICITE
   GARANTIES DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

   L'IETF ne prend aucune position concernant la validité ou la portée de tout
   Droits de propriété intellectuelle ou autres droits susceptibles d'être revendiqués
   concernent la mise en œuvre ou l'utilisation de la technologie décrite dans
   ce document ou la mesure dans laquelle une licence en vertu de ces droits
   peut ou peut ne pas être disponible; il ne signifie pas non plus qu'il a
   fait tout effort indépendant pour identifier ces droits. Information
   sur les procédures relatives aux droits dans les documents RFC peuvent être
   trouvé dans BCP 78 et BCP 79.

   Copies des divulgations de DPI faites au Secrétariat de l'IETF et
   les assurances de licences à mettre à disposition, ou le résultat d'un
   tentative faite pour obtenir une licence générale ou une autorisation pour l'utilisation de
   ces droits de propriété par les exécutants ou les utilisateurs de ce
   Les spécifications peuvent être obtenues auprès du référentiel IPR en ligne de l'IETF à l'adresse
   http://www.ietf.org/ipr.

   L'IETF invite toute partie intéressée à porter à son attention toute
   droits d'auteur, brevets ou demandes de brevets, ou autres
   les droits qui peuvent couvrir la technologie qui peut être nécessaire pour mettre en œuvre
   cette norme. Veuillez adresser les informations à l'IETF à l'ietf-
   ipr@ietf.org.

Reconnaissance

   Le financement de la fonction RFC Editor est actuellement assuré par le
   Société Internet.