RFC(F) 3835

From RFC.Wiki
Jump to: navigation, search
Groupe de travail du réseau                                    A. Barbir
Appel à observations: 3835                                      R. Penno
Catégorie: Informational                                 Nortel Networks
                                                                 R. Chen
                                                               AT&T Labs
                                                              M. Hofmann
                                         Bell Labs / Technologies Lucent
                                                                H. Orman
                                          Développement de Purple Streak
                                                               Août 2004

        

      Une architecture pour les Open Pluggable Edge Services (OPES)

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 mémo définit une architecture qui permet la création d'un
   service d'application dans lequel un fournisseur de données, un consommateur de données et
   zéro ou plusieurs entités d'application implémentent en coopération une donnée
   service de flux.

 

Table des matières

   1. Introduction 
   2. L'architecture 
       2.1. Entités OPES
             2.1.1. Répartiteur de données
       2.2. OPES flux
       2.3. Règles OPES
       2.4. Serveurs d'appels
       2.5. Facilité de traçage
   3. Considérations de sécurité et de confidentialité
       3.1. Domaines de confiance
       3.2. Établissement de l'autorisation de confiance et de service
       3.3. Protocole d'accroche
       3.4. Intimité
       3.5. Intégrité de bout en bout
   4. Considérations architecturales et politiques de l'IAB pour OPES
       4.1. Considération de l'IAB (2.1) Consentement d'une partie
       4.2. Considération de l'IAB (2.2) Communications de la couche IP
       4.3. Examen de l'IAB (3.1 et 3.2) Notification
       4.4. Considération de l'IAB (3.3) Non bloquant
       4.5. Examen de l'IAB (4.1) Résolution URI
       4.6. Considération de l'IAB (4.2) Validité de la référence
       4.7. Prise en compte de l'IAB (4.3) Adressage d'application
             Extensions
       4.8. Considération IAB (5.1) Confidentialité
   5. Considérations de sécurité
   6. Considérations IANA
   7. Résumé
   8. Références
       8.1. Références normatives 
       8.2. Références informatives
   9. Remerciements
   10. Adresses des auteurs
   11. Déclaration de copyright complète

1. Introduction

   Lors de la fourniture d'un service de flux de données entre un fournisseur et un
   consommateur, la nécessité de fournir l'utilisation d'une autre application
   des entités, en plus du fournisseur et du consommateur, peuvent apparaître. Pour
   Par exemple, une partie peut souhaiter personnaliser un flux de données en tant que service
   à un consommateur. L'étape de personnalisation peut être basée sur le
   la disponibilité des ressources du client (par exemple, les capacités d'affichage).

   Dans certains cas, il peut être avantageux de fournir un service de personnalisation
   à un emplacement réseau entre le fournisseur et l'hôte consommateur plutôt
   qu’à l’un de ces points de terminaison. Pour certains services effectués sur
   nom de l'utilisateur final, cela peut être la seule option de service
   déploiement. Dans ce cas, aucune ou plusieurs applications supplémentaires
   les entités peuvent participer au service de flux de données. Il y a beaucoup de
   scénarios d'approvisionnement possibles qui rendent un service de flux de données
   attrayant. Le document sur les cas d'utilisation et les scénarios de déploiement OPES [1]
   fournit des exemples de services OPES. Le document traite des services
   qui modifient les demandes, les services qui modifient les réponses et les services
   qui créent des réponses. Il est recommandé que le document sur OPES
   Les cas d'utilisation et les scénarios de déploiement [1] doivent être lus avant de lire ceci
   document.

   Ce document présente les composants architecturaux d'Open Pluggable
   Services Edge (OPES) nécessaires pour exécuter une donnée
   service de flux. L'architecture répond aux considérations de l'IAB
   décrit dans [2]. Ces considérations sont couvertes dans diverses parties
   du document. La section 2.5 traite du traçage; adresses section 3
   considérations de sécurité. La section 4 présente un résumé de l'IAB
   considérations et comment l'architecture les aborde.

   Le document est organisé comme suit: La section 2 présente l'OPES
   architecture. La section 3 traite de la sécurité et de la confidentialité OPES
   considérations. La section 4 traite des considérations d'IAB pour OPES.
   La section 5 traite des considérations de sécurité. Adresses de la section 6
   Considérations IANA. La section 7 résume les
   l'architecture et les exigences d'interopérabilité.

2. L'architecture

   L'architecture d'Open Pluggable Edge Services (OPES) peut être
   décrit en termes de trois concepts interdépendants, principalement:

   o Entités OPES: processus opérant dans le réseau;

   o Flux OPES: flux de données réalisés en coopération par le
      Entités OPES; et,

   o Règles OPES: elles spécifient quand et comment exécuter les services OPES.

2.1. Entités OPES

   Une entité OPES est une application qui fonctionne sur un flux de données entre
   une application de fournisseur de données et une application de consommation de données. OPES
   les entités peuvent être:

   o une application de service OPES, qui analyse et éventuellement
      transforme les messages échangés entre le fournisseur de données
      l'application et l'application de consommation de données;

   o un répartiteur de données, qui invoque une application de service OPES basée
      sur un ensemble de règles OPES et des connaissances spécifiques à l'application.

   Le comportement coopératif des entités OPES introduit des
   fonctionnalité pour chaque flux de données à condition qu'il corresponde à l'OPES
   règles. Dans le réseau, les entités OPES résident à l'intérieur des processeurs OPES.
   Dans le travail en cours, un processeur OPES DOIT inclure une donnée
   répartiteur. En outre, le fournisseur de données et le consommateur de données
   les candidatures ne sont pas considérées comme des entités OPES.

   Pour assurer l'intégrité vérifiable du système (voir la section 3.1 sur la confiance
   domaines ci-dessous) et pour faciliter le déploiement du chiffrement de bout en bout
   et contrôle de l'intégrité des données, les processeurs OPES DOIVENT être:

   o explicitement adressable au niveau de la couche IP par l'utilisateur final (données
      application grand public). Cette exigence n'exclut pas une chaîne
      des processeurs OPES avec le premier de la chaîne explicitement
      adressé à la couche IP par l'utilisateur final (consommateur de données
      application).

   o consenti par le consommateur de données ou le fournisseur de données
      application. Les détails de ce processus dépassent le cadre de
      le travail en cours.

   L'architecture OPES est largement indépendante du protocole qui est
   utilisé par l'application du fournisseur de données et le consommateur de données
   application pour échanger des données. Cependant, ce document sélectionne HTTP
   [3] comme exemple pour le protocole sous-jacent dans les flux OPES.

2.1.1. Répartiteur de données

   Les répartiteurs de données incluent un ensemble de règles qui peut être compilé à partir de plusieurs
   sources et DOIT aboutir à un résultat sans ambiguïté. Le combiné
   l'ensemble de règles permet à un processeur OPES de déterminer quel service
   applications à appeler pour quel flux de données. En conséquence, les données
   le répartiteur constitue un point d'application de la politique amélioré, où
   les règles de stratégie sont évaluées et les gestionnaires de données spécifiques au service et
   les informations d'état sont conservées, comme le montre la figure 1.

                                        +----------+
                                        |  callout |
                                        |  server  |
                                        +----------+
                                             ||
                                             ||
                                             ||
                                             ||
                         +--------------------------+
                         | +-----------+     ||     |
                         | |   OPES    |     ||     |
                         | |  service  |     ||     |
                         | |application|     ||     |
                         | +-----------+     ||     |
                         | +----------------------+ |
         OPES flow <---->| | data dispatcher and  | |<----> OPES flow
                         | | policy enforcement   | |
                         | +----------------------+ |
                         |           OPES           |
                         |         processor        |
                         +--------------------------+

                          Figure 1: Répartiteurs de données

   L'architecture permet plus d'un point d'application de politique pour
   être présent sur un flux OPES.

2.2. Flux OPES

   Un flux OPES est une entreprise de coopération entre un fournisseur de données
   application, une application consommateur de données, zéro ou plusieurs services OPES
   applications, et un ou plusieurs répartiteurs de données.

   Étant donné que les politiques sont appliquées par les répartiteurs de données, la présence de
   au moins un répartiteur de données est requis dans le flux OPES.

     data          OPES               OPES             data
      consumer        processor A        processor N      provider

    +-----------+    +-----------+  .  +-----------+    +-----------+
    |   data    |    |  OPES     |  .  |  OPES     |    |   data    |
    | consumer  |    | service   |  .  | service   |    | provider  |
    |application|    |application|  .  |application|    |application|
    +-----------+    +-----------+  .  +-----------+    +-----------+
    |           |    |           |  .  |           |    |           |
    |   HTTP    |    |    HTTP   |  .  |    HTTP   |    |   HTTP    |
    |           |    |           |  .  |           |    |           |
    +-----------+    +-----------+  .  +-----------+    +-----------+
    |  TCP/IP   |    |   TCP/IP  |  .  |   TCP/IP  |    |  TCP/IP   |
    +-----------+    +-----------+  .  +-----------+    +-----------+
         ||             ||    ||    .       ||    ||         ||
         ================      =====.========      ===========

         | <----------------- OPES flow -------------------> |

                       Figure 2: Un flux OPES

   La figure 2 représente deux répartiteurs de données qui sont présents dans l'OPES
   couler. L'architecture permet à un ou plusieurs répartiteurs de données d'être
   présent dans n'importe quel flux.

2.3. Règles OPES

   La politique d'OPES concernant les services et les données qui leur sont fournies est
   déterminé par un ensemble de règles composé de règles OPES. Les règles consistent
   d'un ensemble de conditions et d'actions associées. Le jeu de règles est le
   sur-ensemble de toutes les règles OPES sur le processeur. Le jeu de règles OPES
   détermine quelles applications de service fonctionneront sur un flux de données.
   Dans ce modèle, tous les répartiteurs de données sont appelés pour tous les flux.

   Afin d'assurer un comportement prévisible, l'architecture OPES
   nécessite l'utilisation d'un schéma standardisé pour définir
   et interpréter l'ensemble de règles. L'architecture OPES ne nécessite pas
   un mécanisme pour configurer un ensemble de règles dans un répartiteur de données. Ce
   est traité comme une question locale pour chaque mise en œuvre (par exemple, par
   l'utilisation d'un éditeur de texte ou d'un protocole de téléchargement sécurisé), à condition que
   un tel mécanisme est conforme aux exigences énoncées dans la section
   3.

2.4. Serveurs d'appels

   L'évaluation du jeu de règles OPES détermine quel service
   les applications fonctionneront sur un flux de données. Comment est le jeu de règles
   évalué n'est pas le sujet de l'architecture, sauf à noter que
   il DOIT aboutir au même résultat sans ambiguïté dans toutes les implémentations.

   Dans certains cas, il peut être utile que le processeur OPES distribue
   la responsabilité de l'exécution du service en communiquant avec un ou
   plus de serveurs d'appel. Un répartiteur de données appelle les services d'un
   serveur d'appel à l'aide du protocole d'appel OPES (OCP). le
   les exigences pour l'OCP sont données dans [5]. L'OCP est l'application-
   agnostique, ignorant la sémantique de l'encapsulation
   protocole d'application (par exemple, HTTP). Cependant, le répartiteur de données DOIT
   incorporer une capacité de vectorisation sensible au service qui analyse les données
   flux selon le jeu de règles et fournit les données soit au
   application de service OPES locale ou distante.

   La situation d'interaction générale est illustrée à la figure 3, qui
   illustre les positions et l'interaction des différents composants de
   Architecture OPES.

   +--------------------------+
   | +-----------+            |
   | |   OPES    |            |
   | |  service  |            |      +---------------+     +-----------+
   | |application|            |      | Callout       |     | Callout   |
   | +-----------+            |      | Server A      |     | Server X  |
   |     ||                   |      | +--------+    |     |           |
   | +----------------------+ |      | | OPES   |    |     |           |
   | |     data dispatcher  | |      | | Service|    |     | +--------+|
   | +----------------------+ |      | | Appl A |    |     | | OPES   ||
   |      ||           ||     |      | +--------+    |     | |Service ||
   |  +---------+  +-------+  |      |     ||        |     | | Appl X ||
   |  |  HTTP   |  |       |  |      | +--------+    | ... | +--------||
   |  |         |  |  OCP  |=========| | OCP    |    |     |    ||     |
   |  +---------+  +-------+  |      | +--------+    |     | +------+  |
   |  |         |     ||      |      +---------------+     | | OCP  |  |
   |  | TCP/IP  |     =======================================|      |  |
   |  |         |             |                            | +------+  |
   |  +---------+             |                            +-----------+
   +--------||-||-------------+
            || ||
 +--------+ || ||                                       +--------+
 |data    |==  =========================================|data    |
 |producer|                                             |consumer|
 +--------+                                             +--------+

              Figure 3: Interaction des entités OPES

2.5. Facilité de traçage

   L'architecture OPES exige que chaque répartiteur de données fournisse
   des moyens de traçage qui permettent la vérification appropriée de ses
   opération. L'architecture OPES exige que le traçage soit faisable
   sur le flux OPES, par processeur OPES, en utilisant l'annotation dans la bande. Une
   de ces annotations pourrait être un URI avec des informations plus détaillées sur
   les services OPES en cours d'exécution dans le flux OPES.

   Fournir la capacité d'annotation dans la bande PEUT nécessiter un en-tête
   extensions sur le protocole d'application utilisé (par exemple, HTTP).
   Cependant, la présence d'un processeur OPES dans la demande de données /
   le flux de réponse NE DOIT PAS interférer avec les opérations de non-OPES
   clients et serveurs conscients. Les clients et serveurs non-OPES n'ont pas besoin
   prend en charge ces extensions du protocole de base.

   Les processeurs OPES DOIVENT obéir au traçage, à la notification et à la notification
   exigences fixées par le centre d'autorité dans le domaine de confiance pour
   auquel appartient un processeur OPES. Dans le cadre de ces exigences, le
   Le processeur OPES peut être invité à rejeter ou à ignorer
   les exigences qui proviennent d'autres domaines de confiance.

3. Considérations relatives à la sécurité et à la confidentialité

   Chaque flux de données DOIT être sécurisé conformément à plusieurs politiques.
   Les principaux intervenants sont le consommateur de données et le fournisseur de données.
   Les parties prenantes secondaires sont les entités auxquelles elles peuvent avoir
   délégué leur confiance. Les autres parties prenantes sont les propriétaires du
   serveurs d'appel. Chacune de ces parties peut participer à la
   Flux OPES.

   Ces parties DOIVENT avoir un modèle, explicite ou implicite, décrivant
   leur politique de confiance, laquelle des autres parties est fiable pour fonctionner
   sur les données, et quelles améliorations de sécurité sont nécessaires pour
   la communication. La confiance peut être déléguée pour toutes les données, ou
   peut être limité à une granularité aussi petite que les données d'une application
   unité.

   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. Domaines de confiance

   La délégation de pouvoir commence soit à un consommateur de données, soit à des données
   fournisseur et se déplace vers des entités plus distantes de manière "par étapes".
   Pas à pas signifie que A délègue à B, et B délègue à C, et ainsi de suite.
   Les entités ainsi «colorées» par la délégation formeraient un
   domaine de confiance par rapport à la partie délégante d'origine. Ici,
   "Coloré" signifie que si la première étape de la chaîne est les données
   fournisseur, puis la délégation par étapes "colore" la chaîne avec cela
   couleur "fournisseur" de données. Les seules couleurs définies sont les données
   «fournisseur» et les données «consommateur». Délégation de pouvoirs
   (coloration) se propage à partir du début de l'autorité du producteur de contenu ou
   à partir du début de l'autorité du consommateur de contenu, qui peut être différent
   à partir des points finaux du flux de données.

   La figure 4 illustre les domaines administratifs, les règles hors bande et
   distribution des politiques.


 provider administrative domain         consumer administrative domain
 +------------------------------+      +-------------------------------+
 | +--------------+             |      |            +--------------+   |
 | |Provider      |      <- out-of-band rules, ->   |Consumer      |   |
 | |Administrative|~~>~~~:  policies and         ~<~|Administrative|   |
 | |Authority     |      : service authorization :  |Authority     |   |
 | +--------------+      :        |     |        :  +--------------+   |
 |         :             :        |     |        :           :         |
 |         :             :        |     |        :           :         |
 |   +----------+        :        |     |        :        +----------+ |
 |   |  callout |    +---------+  |     |  +---------+    |  callout | |
 |   |  server  |====|         |  |     |  |         |====|  server  | |
 |   +----------+    |         |  |     |  |         |    +----------+ |
 |                   | OPES    |  |     |  | OPES    |                 |
 |   +----------+    |processor|  |     |  |processor|   +----------+  |
 |   |          |    |         |  |     |  |         |   |          |  |
 |   | data     |    |         |  |     |  |         |   | data     |  |
 |   | provider |    |         |  |     |  |         |   | consumer |  |
 |   |          |    +---------+  |     |  +---------+   +----------+  |
 |   +----------+     ||     ||   |     |   ||    ||     +----------+  |
 |        ||          ||     ||   |     |   ||    ||         ||        |
 |        =============     =================      ===========         |
 |                               |     |                               |
 +-------------------------------+     +-------------------------------+
          | <----------------- OPES flow -----------------> |

    Figure 4: Domaines administratifs OPES et distribution des politiques

   Afin de comprendre les relations de confiance entre les entités OPES,
   chacun est étiqueté comme résidant dans un domaine administratif. Entités
   associé à un flux OPES donné peut résider dans un ou plusieurs
   domaines administratifs.

   Un processeur OPES peut se trouver dans plusieurs domaines de confiance à tout moment. Là
   n'est pas une restriction quant à savoir si les processeurs OPES sont autorisés par
   consommateurs de données et / ou fournisseurs de données. Le parti d'origine a le
   possibilité d'interdire ou de limiter la redélégation.

   Un processeur OPES DOIT avoir une représentation de son domaine de confiance
   appartenances qu'il peut signaler en tout ou en partie pour le traçage
   fins. Il DOIT inclure le nom de la partie qui a délégué chaque
   privilège à lui.

3.2. Établissement de l'autorisation de confiance et de service

   Le processeur OPES aura une politique de configuration spécifiant ce
   privilèges dont disposent les serveurs d'appels et comment ils doivent être
   identifiés. OPES utilise des protocoles standard pour l'authentification et
   autre communication de sécurité avec les serveurs d'appel.

   Un processeur OPES aura une méthode fiable pour recevoir
   les informations de configuration, telles que les règles du répartiteur de données,
   serveurs d'appels de confiance, parties principales qui acceptent ou refusent
   services individuels, etc.

   Le (s) protocole (s) pour la distribution des politiques / règles sont hors de portée pour cela
   document, mais l'architecture OPES suppose l'existence d'un tel
   mécanisme.

   Les exigences relatives au mécanisme d'autorisation sont définies dans un
   document [4].

   Les demandes de service peuvent être effectuées en bande. Par exemple, une demande à
   les services de contournement OPES pourraient être signalés par un agent utilisateur à l'aide d'un HTTP
   chaîne d'en-tête "Bypass-OPES". Ces demandes DOIVENT être authentifiées.
   La manière dont les entités OPES honoreront ces demandes est subordonnée à la
   politiques d'autorisation en vigueur à ce moment.

3.3. Protocole d'accroche

   Déterminer si les processeurs OPES utiliseront ou non le
   mesures décrites dans la section précédente lors de leur
   la communication avec les serveurs d'appels dépend des détails de la
   les parties principales ont délégué la confiance aux processeurs OPES et à la confiance
   relation entre les processeurs OPES et le serveur d'appel.
   Authentification forte, codes d'authentification des messages et cryptage
   Devrait être utilisé. Si les processeurs OPES sont dans un seul
   domaine administratif avec une confidentialité et une intégrité fortes
   garanties, alors la protection cryptographique est recommandée mais
   optionnel.

   Si le mécanisme de délégation nomme les parties de confiance et leur
   privilèges d'une manière qui permet l'authentification, puis OPES
   les processeurs seront responsables de l'application de la politique et de l'utilisation
   l'authentification dans le cadre de cette application.

   Les serveurs d'appel DOIVENT être conscients de la politique régissant le
   chemin de communication. Ils NE DOIVENT PAS, par exemple, communiquer
   informations confidentielles aux serveurs auxiliaires en dehors de la confiance
   domaine.

   Une association de sécurité distincte DOIT être utilisée pour chaque canal
   établi entre un processeur OPES et un serveur d'appel. le
   les canaux DOIVENT être séparés pour les différents participants principaux.

3.4. Intimité

   Certaines données des points de terminaison de flux OPES sont considérées comme "privées" ou
   «sensibles», et les processeurs OPES DOIVENT informer les parties principales de
   leur politique de confidentialité et respecter les politiques des principales parties.
   Les informations de confidentialité DOIVENT être transmises sur une base par flux. Ce
   peut être accompli en utilisant les techniques de confidentialité actuellement disponibles
   telles que les capacités de confidentialité P3P [7] et HTTP.

   Les serveurs d'appel DOIVENT également participer à la gestion des
   données, ils DOIVENT être prêts à annoncer leurs propres capacités, et
   appliquer la politique requise par les parties principales.

3.5. Intégrité de bout en bout

   Les techniques de signature numérique peuvent être utilisées pour marquer les changements de données dans
   un moyen permettant à un tiers de vérifier que les modifications sont ou non
   conforme à la politique de la partie d'origine. Cela nécessite un
   méthode en ligne pour spécifier la stratégie et sa liaison aux données, une trace de
   changements et l'identité de la partie qui effectue les changements, et
   méthodes d'identification et d'authentification.

   Une solide intégrité de bout en bout peut remplir certaines des fonctions
   requis par "traçage".

4. Considérations architecturales et politiques de l'IAB pour OPES

   Cette section traite des considérations IAB pour OPES [2] et
   résume comment l'architecture les aborde.

4.1. Considération de l'IAB (2.1) Consentement d'une partie

   L'IAB recommande que tous les services OPES soient explicitement autorisés par
   l'un des hôtes d'extrémité de la couche application (c'est-à-dire que les données
   application grand public ou l'application fournisseur de données).

   Le travail actuel nécessite que soit l'application consommateur de données
   ou le consentement de l'application du fournisseur de données aux services OPES. Celles-ci
   les exigences ont été traitées dans les sections 2 (section 2.1) et 3.

4.2. Considération IAB (2.2) Communications de la couche IP

   L'IAB recommande que les processeurs OPES soient explicitement adressés
   au niveau de la couche IP par l'utilisateur final (application consommateur de données).

   Cette exigence a été traitée dans la section 2.1, par le
   exigence que les processeurs OPES soient adressables au niveau de la couche IP par
   l'application consommateur de données.

4.3. Considération IAB (3.1 et 3.2) Notification

   L'IAB recommande que l'architecture OPES intègre le traçage
   installations. Le traçage permet au consommateur de données et au fournisseur de données
   applications pour détecter et répondre aux actions effectuées par OPES
   processeurs jugés inappropriés pour le consommateur de données ou les données
   applications du fournisseur.

   La section 3.2 de ce document traite du traçage et de la notification
   installations qui doivent être prises en charge par les services OPES.

4.4. Considération IAB (3.3) Non bloquant

   L'architecture OPES nécessite la spécification d'extensions pour
   HTTP. Ces extensions permettront à l'application consommateur de données de
   demander une version non-OPES du contenu au fournisseur de données
   application. Ces exigences sont traitées dans la section 3.2.

4.5. Considération IAB (4.1) Résolution URI

   Cette considération recommande que la documentation OPES soit claire
   dans la description des services OPES comme étant appliqués au résultat de l'URI
   résolution, pas comme résolution URI elle-même.

   Cette exigence a été traitée dans les sections 2.5 et 3.2, par
   obligeant les entités OPES à documenter toutes les transformations qui ont
   été effectuée.

4.6. Considération IAB (4.2) Validité de référence

   Cette considération recommande que tous les services proposés doivent définir
   leur impact sur la validité de référence inter et intra-document.

   Cette exigence a été traitée dans la section 2.5 et tout au long du
   document dans lequel les entités OPES sont tenues de documenter les
   transformations.

4.7. Considération IAB (4.3) Extensions d'adressage d'application

   Cette considération recommande que tous les services OPES qui ne peuvent pas être
   atteint tout en respectant les deux considérations ci-dessus peut être
   examinés en tant qu'exigences potentielles pour l'application Internet
   adressant les extensions d'architecture, mais ne doit pas être entrepris comme une annonce
   corrections hoc.

   Le travail actuel ne nécessite pas d'extensions d'Internet
   architecture d'adressage d'application.

4.8. Considération IAB (5.1) Confidentialité

   Cette considération recommande que le cadre global OPES doit
   prévoir des mécanismes permettant aux utilisateurs finaux de déterminer la confidentialité
   politiques des intermédiaires OPES.

   Cette considération a été traitée dans la section 3.

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

   Le travail proposé doit traiter de la sécurité de divers
   points de vue. Il y a des problèmes de sécurité et de confidentialité liés à
   application consommateur de données, protocole d'appel et flux OPES. Dans
   [6], il y a une analyse des menaces contre les entités OPES.

6. Considérations IANA

   Le travail proposé évaluera les protocoles actuels pour l'OCP. Si la
   le travail détermine qu'un nouveau protocole doit être développé, puis là
   peut être nécessaire de demander de nouveaux numéros à l'IANA.

7. Résumé

   Bien que l'architecture prenne en charge un large éventail de
   services de transformation, il a peu d'exigences pour
   interopérabilité.

   Les éléments nécessaires et suffisants sont précisés ci-dessous
   documents:

   o le schéma du jeu de règles OPES, qui définit la syntaxe et la sémantique de
      les règles interprétées par un répartiteur de données; et,

   o le protocole d'appel OPES (OCP) [5], qui définit le
      exigences relatives au protocole entre un répartiteur de données et un
      serveur d'accroche.

8. Références

8.1. Références normatives

   [1] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H. et R.
        Penno, «Open Pluggable Edge Services (OPES) Use Cases et
        Scénarios de déploiement », RFC 3752, avril 2004.

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

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

   [4] Barbir, A., Batuner, O., Beck, A., Chan, T. et H. Orman,
        "Exigences en matière de politique, d'autorisation et d'application de l'Open
        Pluggable Edge Services (OPES) ", RFC 3838, août 2004.

   [5] Beck, A., Hofmann, M., Orman, H., Penno, R. et A. Terzis,
        "Conditions requises pour l'appel OPES (Open Pluggable Edge Services)
        Protocols », RFC 3836, août 2004.

   [6] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M. et H.
        Orman, "Menaces et risques de sécurité pour Open Pluggable Edge
        Services (OPES) », RFC 3837, août 2004.

8.2. Références informatives

   [7] Cranor, L. et. al, "La plate-forme pour les préférences de confidentialité 1.0
        (P3P1.0) Spécification ", Recommandation 16 du W3C
        http://www.w3.org/TR/2002/REC-P3P-20020416/, avril 2002.

9. Remerciements

   Ce document est le produit d'OPES WG. Oskar Batuner (indépendant
   consultant) et Andre Beck (Lucent) sont d'autres auteurs qui ont
   contribué à ce document.

   Les versions antérieures de ce travail ont été réalisées par Gary Tomlinson (The
   Tomlinson Group) et Michael Condry (Intel).

   Les auteurs remercient chaleureusement les contributions de: John Morris,
   Mark Baker, Ian Cooper et Marshall T. Rose.

10. Adresses des auteurs

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

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

   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

   Markus Hofmann
   Bell Labs / 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

   Reinaldo Penno
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821
   Etats-Unis

   Courriel: rpenno@nortelnetworks.com

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