RFC(F) 3752

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau                                    A. Barbir
Demande de commentaires: 3752                            Nortel Networks
Catégorie: Informatif                                          E. Burger
                                             Brooktrout Technology, Inc.
                                                                 R. Chen
                                                               AT&T Labs
                                                              S. McHenry
                                                 Contributeur individuel
                                                                H. Orman
                                          Développement de Purple Streak
                                                                R. Penno
                                                         Nortel Networks
                                                              Avril 2004

                  Services de périphérie ouverts enfichables (OPES)
                  Cas d'utilisation et scénarios de déploiement

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). Tous les droits sont réservés.

Abstrait

   Ce mémo fournit une discussion des cas d'utilisation et des scénarios de déploiement
   pour Open Pluggable Edge Services (OPES). Le travail examine les services
   qui pourraient être exécutées aux demandes et / ou réponses.

Table des matières

   1. Introduction             
   2. Types de services OPES               
       2.1. Services rendus sur demandes          
             2.1.1. Services ayant l'intention de modifier les demandes 
             2.1.2. Services * n'ayant pas * l'intention de modifier les demandes
       2.2. Services rendus sur les réponses         
             2.2.1. Services ayant l'intention de modifier les réponses   
             2.2.2. Services * n'ayant pas * l'intention de modifier les réponses
       2.3. Services créant des réponses           
   3. Scénarios de déploiement OPES          
       3.1. Superpositions de substitution     
       3.2. Déléguer les superpositions     
       3.3. Environnement d'entreprise           
       3.4. Serveurs d'appels            
       3.5. Chaînage des filtres de données OPES et des serveurs d'appel      
             3.5.1. Chaînage le long du chemin du contenu      
             3.5.2. Chaînage le long du chemin de légende  
   4. Cas d'échec et notification de service            
   5. Considérations de sécurité            
   6. Références informatives              
   7. Remerciements               
   8. Adresses des auteurs            
   9. Déclaration de copyright complète      

1. Introduction

   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
   transformer les messages de niveau application échangés entre les données
   fournisseur et le consommateur de données. L'exécution de ces services est
   régi par un ensemble de règles de filtrage installées sur le processeur OPES.

   L'application des règles peut déclencher l'exécution du service
   applications locales au processeur OPES. Alternativement, l'OPES
   le sous-traitant peut répartir la responsabilité de l'exécution du service en
   communiquer et collaborer avec une ou plusieurs légendes distantes [6]
   les serveurs.

   Le document présente des exemples de services dans lesquels Open Pluggable
   Edge Services (OPES) serait utile. Il existe différents types de
   Services OPES: services qui modifient les demandes, services qui modifient
   réponses, et un cas particulier de ces derniers, des services qui créent
   réponses.

   Le travail examine également divers scénarios de déploiement des services OPES.
   Les deux principaux scénarios de déploiement, tels que décrits par l'OPES
   architecture [1], sont des superpositions de substitution et des superpositions de délégué.
   Les superpositions de substitution agissent au nom des applications du fournisseur de données, tandis que
   les superpositions de délégués agissent au nom des applications de consommation de données. le
   document décrit également les superpositions combinées de substitut et de délégué, comme
   on pourrait trouver dans un déploiement d'entreprise.

   Le document est organisé comme suit: la section 2 traite des différents
   types de services OPES. La section 3 présente le déploiement OPES
   scénarios. La section 4 traite des cas de panne et du service
   notification. La section 5 traite des considérations de sécurité.

   L'IAB a exprimé des préoccupations d'ordre architectural et politique [2] concernant
   OPES. D'autres documents OPES qui peuvent être pertinents sont, "Service OPES
   Exigences en matière d'autorisation et d'exécution "[5]. Voir les références [3,
   4] pour la lecture de fond recommandée.

2. Types de services OPES

   Les scénarios OPES impliquent des services qui peuvent être exécutés sur des demandes de
   données et / ou réponses. Les services OPES peuvent être classés en trois
   catégories: services rendus sur demandes, services rendus sur
   réponses et services créant des réponses. Dans la figure 1, les quatre
   les points d'activation de service pour un processeur OPES sont représentés. le
   le répartiteur de données examine les règles OPES, applique les stratégies et appelle
   applications de service (le cas échéant) à chaque activation de service
   point.

              +------------------------------------------------+
              |         +-------------+-------------+          |
              |         |   Service Application     |          |
              |         +---------------------------+          |
         Responses      |       Data Dispatcher     |     Responses
       <============4== +---------------------------+ <=3===========
         Requests       |           HTTP            |      Requests
       =============1=> +---------------------------+ ==2==========>
              |                  OPES Processor                |
              +------------------------------------------------+

                  Figure 1: Points d'activation du service

2.1. Services rendus sur demandes

   Un service OPES exécuté sur des requêtes HTTP peut se produire lorsqu'une requête
   arrive chez un processeur OPES (point 1) ou lorsqu'il est sur le point de partir
   le processeur OPES (point 2).

   Les services rendus sur les demandes peuvent être divisés en deux
   cas: ceux qui ont l'intention de modifier les demandes et ceux qui ne le font pas.

2.1.1. Services ayant l'intention de modifier les demandes

   Un processeur OPES peut modifier une demande de service au nom des données
   consommateur pour diverses raisons, telles que:

   o Le propriétaire d'un périphérique d'accès Web peut avoir besoin de contrôler le type de
      Le contenu Web est accessible avec l'appareil, le contrôle parental pour
      exemple.

   o L'organisation peut restreindre ou rediriger l'accès à certains sites Web

      services basés sur divers critères tels que l'heure de la journée ou
      privilèges d'accès des employés.

   o Masquer l'identité du consommateur de données, l'agent utilisateur ou le référent.

   o Ajout des préférences utilisateur ou du profil de l'appareil à la demande de service
      pour obtenir des services personnalisés ou adaptés.

   o Bloquer ou rediriger une demande de service due à une entreprise
      politique.

   Un processeur OPES peut également modifier une demande de service au nom du
   fournisseur de données de plusieurs manières, telles que:

   o Rediriger la requête vers un autre serveur pour réduire le serveur
      charge de travail.

   o Rediriger les demandes d'images pour améliorer le temps d'accès.

2.1.2. Services * n'ayant pas * l'intention de modifier les demandes

   Un processeur OPES peut appeler des applications de service utiles qui ne
   modifier les demandes des utilisateurs. Les exemples comprennent:

   o Fonctions administratives pour le fournisseur de données, telles que le service
      surveillance ou suivi de l'utilisation à des fins de facturation.

   o Services utiles pour le consommateur de données, tels que le profilage de l'utilisateur
      (avec le consentement de l'utilisateur) pour une adaptation ultérieure du service.

2.2. Services rendus sur les réponses

   Un service OPES exécuté sur les réponses HTTP peut se produire lorsqu'une réponse
   arrive chez un processeur OPES (point 3) ou lorsqu'il est sur le point de partir
   le processeur OPES (point 4). Dans le cas d'un proxy de mise en cache, le
   l'ancien service peut être une opération de codage avant que le contenu ne soit
   stocké dans le cache, alors que ce dernier peut être une opération de décodage
   avant que le contenu ne soit renvoyé au consommateur de données.

   Les services rendus sur les réponses peuvent en outre être divisés en deux
   cas: ceux qui ont l'intention de modifier les réponses et ceux qui ne le font pas.

2.2.1. Services ayant l'intention de modifier les réponses

   Il existe plusieurs raisons pour lesquelles les réponses des fournisseurs de données pourraient
   être modifié avant la livraison au consommateur de données:

   o Adaptation du contenu: le fournisseur de données peut ne pas avoir tout l'appareil

      profils et modèles nécessaires pour transcoder le contenu original
      dans un format adapté aux appareils mobiles à écran limité
      taille et capacités d'affichage.

   o Traduction de la langue: le fournisseur de données peut ne pas avoir tous les
      capacités de traduction nécessaires pour fournir le même contenu
      plusieurs langues dans diverses régions du monde. Un OPES
      le processeur peut effectuer la traduction de la langue ou il peut invoquer
      différents serveurs d'appels pour exécuter différentes langues
      tâches de traduction.

2.2.2. Services * n'ayant pas * l'intention de modifier les réponses

   Un service OPES peut être exécuté sur les réponses sans modifier
   leur. Les exemples comprennent:

   o Journalisation / surveillance: chaque réponse peut être examinée et enregistrée pour
      à des fins de surveillance ou de débogage.

   o Comptabilité: un processeur OPES peut enregistrer les données d'utilisation (heure et
      espace) de chaque demande de service à des fins de facturation.

2.3. Services créant des réponses

   Les services créant des réponses peuvent inclure des services OPES
   assembler dynamiquement des pages Web en fonction du contexte des données
   application grand public.

   Envisagez un fournisseur de contenu proposant des pages Web qui incluent un
   prévisions météorologiques basées sur les préférences du demandeur. Les OPES
   le service pourrait analyser les demandes reçues, identifier l'utilisateur associé
   préférences, sélectionnez les modèles appropriés, insérez les
   les prévisions météorologiques locales, puis fournirait le contenu au
   demandeur. Notez que le processeur OPES peut effectuer les tâches avec
   ou sans accès direct aux données météorologiques. Par exemple, le
   le service pourrait utiliser des données météorologiques mises en cache localement ou simplement
   incorporer une URL pointant vers un autre serveur contenant la dernière version
   informations sur les prévisions météorologiques.

3. Scénarios de déploiement OPES

   Les entités OPES peuvent être déployées sur un réseau de superposition prenant en charge
   la fourniture de services de données de manière distribuée. Recouvrir
   les réseaux sont une abstraction qui crée un réseau virtuel de
   périphériques connectés en couches sur un réseau IP sous-jacent existant dans
   afin d'exécuter des services au niveau de l'application.

   L'utilisation de réseaux superposés crée des réseaux virtuels qui via OPES

   entités permet à l'infrastructure réseau nécessaire de fournir
   de meilleurs services pour les applications consommateurs et fournisseurs de données. Au
   niveau application, les réseaux de superposition résultants sont appelés OPES
   Réseaux de services.

   Il y a deux parties intéressées par les services qui sont
   offerts par les entités OPES, le délégué et le substitut. Délégués
   sont des agents autorisés qui agissent au nom des consommateurs de données.
   Les substituts sont des agents autorisés qui agissent au nom des données
   fournisseurs.

   Toutes les parties impliquées dans l'application des politiques doivent communiquer
   les politiques aux parties impliquées. Ces partis sont
   confiance pour adhérer aux politiques communiquées.

   Afin de déléguer une confiance fine, les parties doivent transmettre
   informations de politique par contrat implicite, par un protocole de configuration, par un
   protocole de négociation dynamique ou en ligne avec les données d'application
   en-têtes.

3.1. Superpositions de substitution

   Une superposition de substitution est un type spécifique de réseau de service OPES, qui
   se voit déléguer le pouvoir de fournir des services de données au nom d'un
   ou plusieurs serveurs d'origine. Ces services comprennent, mais sans s'y limiter
   à, assemblage dynamique de pages Web, de filigrane et de contenu
   adaptation.

   Les éléments des superpositions de substitution agissent au nom des serveurs d'origine et
   appartiennent logiquement au domaine faisant autorité de l'origine respective
   les serveurs. Le scénario est illustré à la figure 2.


              *********************************************
              *                                           *
              *    +--------+             Authoritative   *
              *    | Origin |                    Domain   *
              *    | Server |                             *
              *    +--------+       +------------+        *
              *         |           | OPES Admin |        *
              *         |           |   Server   |        *
              *         |           +------------+        *
              *         |         /                       *
              *         |       /                         *
              * +--------------+      +-----------------+ *
              * |     OPES     |----- | Remote Call-out | *
              * |   Processor  |      |     Server      | *
              * +--------------+      +-----------------+ *
              *         |                                 *
              *********************************************
                        |
                        |
                        |
                   +---------------------------+
                   | Data consumer application |
                   +---------------------------+

         Figure 2: Domaines faisant autorité pour les superpositions de substitution

3.2. Superpositions de délégués

   Une superposition de délégué est un type spécifique de réseau de service OPES, qui
   se voit déléguer le pouvoir de fournir des services de données au nom d'un
   ou plusieurs applications de consommation de données.

   Les superpositions de délégués fournissent des services qui seraient autrement exécutés
   par les applications consommateurs de données. Ces services comprennent, mais sont
   non limité à l'analyse antivirus et au filtrage de contenu.

   Les éléments des superpositions de délégués appartiennent logiquement au
   domaine faisant autorité de l'application de consommation de données respective.
   La situation est illustrée à la figure 3.

                   +--------+
                   | Origin |
                   | Server |
                   +--------+
                        |
                        |
                        |
              *********************************************
              *         |                                 *
              * +--------------+      +-----------------+ *
              * |     OPES     |----- | Remote Call-out | *
              * |    Processor |      |     Server      | *
              * +--------------+      +-----------------+ *
              *         |       \                         *
              *         |         +------------+          *
              *         |         | OPES Admin |          *
              *         |         |   Server   |          *
              *         |         +------------+          *
              *    +---------------------+                *
              *    | Data consumer Appl. | Authoritative  *
              *    +---------------------+        Domain  *
              *                                           *
              *********************************************

         Figure 3: Domaines faisant autorité pour les superpositions de délégués

3.3. Environnement d'entreprise

   Le déploiement des services OPES dans un environnement d'entreprise est unique
   plusieurs façons:

   o Les fournisseurs de données et les consommateurs de données sont dans le même
      domaine administratif et domaine de confiance. Cela implique que le
      L'administrateur OPES logique a le pouvoir de faire appliquer
      politiques sur tous les fournisseurs de données, les consommateurs de données et les entités OPES.

   o Dans le cas où un serveur d'appel en dehors du pare-feu de l'entreprise
      est appelé pour les services (tels que la traduction de langue) qui ne peuvent pas
      être effectuée à l'intérieur de la société, il faut veiller à
      garantir un canal de communication sécurisé entre la légende
      serveur et entités OPES d'entreprise. Le serveur d'appel doit également
      adhérer à toutes les politiques de sécurité d'entreprise pour les services
      autorisé.

3.4. Serveurs d'appels

   Dans certains cas, le déploiement des services OPES peut bénéficier du
   utilisation de serveurs d'appel qui pourraient répartir la charge de travail d'OPES
   transformateurs ou pour contracter des services spécialisés d'autres OPES
   fournisseurs.

   En général, les opérations telles que l'analyse antivirus qui fonctionnent sur
   les objets sont mieux gérés grâce à l'utilisation d'une légende dédiée
   serveur mieux conçu pour effectuer la tâche gourmande en mémoire
   que ce qu’un processeur OPES pourrait gérer.

3.5. Chaînage des filtres de données OPES et des serveurs d'appel

   Les processeurs de données OPES peuvent être «chaînés» en deux dimensions: le long du
   chemin du contenu ou le long du chemin de la légende. Dans ce dernier cas, le
   les serveurs d'appel peuvent eux-mêmes être organisés en série pour la gestion
   demandes. Tout contenu touché par plus d'une donnée
   processeur ou plusieurs serveurs d'appel ont été gérés par un
   "chaîne".

   REMARQUE: le chaînage des serveurs d'appel est différé à partir de la version 1 du
   Protocole. La discussion du chaînage est incluse ici pour
   l'exhaustivité.

3.5.1. Chaînage le long du chemin du contenu

   Un fournisseur OPES peut avoir attribué des services OPES à un ensemble de
   processeurs disposés en série. Tout le contenu peut se déplacer dans le
   série, et si le contenu correspond aux règles d'un processeur, il est
   soumis au service. De cette manière, le contenu peut être amélioré
   par plusieurs services. Ce type de chaînage peut réussir si le
   les services sont relativement indépendants. Par exemple, le contenu pourrait
   être assemblé par un service au début de la chaîne puis plus loin
   décoré par un service postérieur.

3.5.2. Chaînage le long du chemin de légende

   Alternativement, un processeur de données OPES peut agir comme un niveau de contenu
   basculer dans un cluster d'autres processeurs de données et serveurs d'appel.

   La première étape pourrait développer un calendrier de traitement pour le contenu
   et le diriger vers d'autres processeurs de données OPES et / ou serveurs d'appel.
   Par exemple, le processeur OPES A peut gérer tous les services d'assemblage
   contenu, le processeur OPES B peut gérer tous les services impliquant une URL
   traduction, et le processeur OPES C peut gérer toute la sécurité du contenu
   prestations de service. Le premier processeur déterminerait que les processeurs A et

   C étaient nécessaires pour un objet de contenu particulier, et cela dirigerait
   le contenu à ces processeurs. À leur tour, les processeurs peuvent utiliser
   plusieurs serveurs d'appel pour accomplir la tâche.

4. Cas de panne et notification de service

   Ce sont des cas illustratifs où des informations sur le traitement OPES
   peut aider les utilisateurs finaux à déterminer où et pourquoi les modifications de contenu
   sont en cours d'exécution.

   o Le fournisseur de contenu utilise un processeur de données OPES pour améliorer le contenu
      basé uniquement sur le contexte local du fournisseur. Le contexte local
      peut être l'heure, l'URL locale ou la publicité disponible pour
      exemple. Le fournisseur de contenu peut trouver la journalisation OPES
      suffisant pour déboguer les problèmes dans ce cas. Cependant, le
      le fournisseur de contenu peut également essayer une analyse directe en émettant un
      demande de contenu et examen des en-têtes liés au traçage.
      Si des paramètres inattendus apparaissent dans les en-têtes de trace, le contenu
      l'administrateur du fournisseur peut les utiliser pour corriger les règles OPES
      ou détecter la présence d'un processeur OPES inattendu dans le
      chemin du contenu.

   o Le fournisseur de contenu utilise un processeur de données OPES pour améliorer le contenu
      basé sur le contexte lié au demandeur. Le demandeur peut
      notez que ses demandes n'obtiennent pas la même réponse que
      un autre demandeur. Il peut, par exemple, recevoir un message d'erreur. Si
      il pense qu'il y a une erreur de configuration sur les données OPES
      sous-traitant, il devra fournir des informations au
      administrateur de celui-ci. Si les informations incluent "Service OPES
      contrôle d'accès, action: bloqué ", par exemple, il peut se renseigner
      sur les circonstances qui lui permettront d'être ajouté à la
      liste de contrôle d'accès. Dans un autre exemple, s'il voit une image
      sans rapport avec le texte environnant, et si le traçage indique "OPES
      service choisir une image, action: insérer 640x480 weather.gif ", il
      pourrait se plaindre que le service OPES ne reconnaît pas correctement
      sa position géographique et insère la mauvaise carte météo. Dans tous
      cas, si les informations sont transmises au fournisseur de contenu, le
      le problème peut être résolu.

   o L'utilisateur final dispose d'un processeur OPES dans le cadre de son réseau
      environnement d'accès. L'utilisateur final peut avoir sélectionné "traduire
      De l'anglais vers l'espagnol "comme service OPES. S'il voit" Service OPES
      traduction de la langue, action: langue de destination non prise en charge,
      aucune action », il peut alors demander au prestataire OPES
      quelles langues sont prises en charge par le package. Si l'utilisateur final
      estime que la langue source n'est pas correctement représentée par le

      fournisseur, entraînant une incapacité du service à fonctionner, il
      (ou le fournisseur de services linguistiques) peut contacter le contenu
      fournisseur.

   o Si le fournisseur de contenu reçoit des plaintes d'utilisateurs concernant
      service de traduction et estime que le problème n'est pas
      contenu mais dans le service, il peut recommander que le service ne
      être appliqué à ses pages. Il peut le faire via les en-têtes de contenu,
      par exemple, avec la notation "No OPES service # 8D3298EB" ou "No
      Traduction de langue de classe OPES ".

   o Le FAI ou l'entreprise de l'utilisateur final utilise OPES pour contrôler l'accès des utilisateurs
      basé sur les profils des utilisateurs. L'utilisateur final peut voir que l'OPES
      services sont appliqués par son FAI, mais il ne peut pas les contrôler.
      S'il sent que les transformations bouleversent le contenu, il peut
      se plaindre auprès de l'organisation prestataire.

   o Le fournisseur de contenu ou l'utilisateur final s'appuie sur une distribution de contenu
      réseau et OPES est utilisé dans ce réseau. OPES peut être
      autorisé par le fournisseur de contenu, l'utilisateur final ou les deux. le
      le fournisseur de contenu peut soupçonner que ses règles de contrôle d'accès ne sont pas
      appliquée correctement, par exemple. Il peut demander une notification
      sur tous les accès à son contenu via un journal. Cette demande et
      le fichier journal est en dehors de l'architecture OPES; il y a de la sécurité
      implications pour la demande, la réponse et les ressources utilisées
      par le fichier journal.

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

   Le document présente des scénarios d'utilisation et des cas de déploiement. Problèmes
   liées à la sécurité globale des entités OPES sont données dans [1].

6. Références informatives

   [1] A. Barbir et al., "Une architecture pour Open Pluggable Edge
        Services (OPES) ", Work in Progress, juillet 2002.

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

   [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. et S.
        Waldbusser, "Terminologie pour la gestion basée sur des politiques", RFC 3198,
        Novembre 2001.

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

   [5] Groupe de travail OPES, "OPES Service Authorization and Enforcement
        Requirements », Work in Progress, mai 2002.

   [6] Beck, A., et al., "Requirements for OPES Callout Protocols",
        Work in Progress, juillet 2002.

7. Remerciements

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

8. Adresses des auteurs

   Abbie Barbir
   Nortel Networks
   3500 avenue Carling
   Nepean, Ontario K2H 8E9
   Canada

   Téléphone: +1613763 5229
   Courriel: abbieb@nortelnetworks.com

   Eric W. Burger
   Brooktrout Technology, Inc.
   18 Keewaydin Dr.
   Salem, NH 03079

   COURRIEL: e.burger@ieee.org

   Yih-Farn Robin Chen
   AT&T Labs - Recherche
   180 Park Avenue
   Florham Park, NJ 07932
   NOUS

   Téléphone: +1973360 8653
   Courriel: chen@research.att.com

   Stephen McHenry
   305 Centre-ville de Vineyard, # 251
   Morgan Hill, Californie 95037
   NOUS

   Téléphone: +1408683 2700
   EMail: stephen@mchenry.net

   Hilarie Orman
   Développement de Purple Streak

   COURRIEL: ho@alum.mit.edu

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

   Courriel: rpenno@nortelnetworks.com

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

<pre>