Groupe de travail Réseau	A. Westerinen & J. Schnizlein, Cisco Systems	
Request for Comments : 3198	J. Strassner, Intelliden Corporation	
Catégorie : Information	M. Scherling, xCert	
novembre 2001	B. Quinn, Celox Networks	
	S. Herzog, PolicyConsulting	
	A. Huynh, Lucent Technologies	
	M. Carlson, Sun Microsystems	
	J. Perry, Network Appliance	
Traduction Claude Brière de L’Isle	S. Waldbusser	

Terminologie pour la gestion fondée sur la politique

Statut de ce mémoire
Le présent mémoire apporte des information pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2001). Tous droits réservés

Résumé
Le présent document est un glossaire des termes relatifs à la politique. Il donne des abréviations, des explications, et des recommandations pour l’utilisation de ces termes. Le document emprunte l’approche et le format de la RFC 2828, qui définit un glossaire de la sécurité Internet. L’intention est d’améliorer la compréhension et la cohérence des écrits qui traitent de la politique du réseau, en particulier les documents de normalisation de l’Internet (ISD, Internet Standards document).

Table des Matières
1. Introduction	1
2. Explication du marquage des paragraphes	2
3. Termes	2
4. Propriété intellectuelle	8
5. Remerciements	8
6. Considérations pour la sécurité	9
7. Références	9
8. Adresse des auteurs	10
9. Déclaration complète de droits de reproduction	10

1.	Introduction

Le présent document fournit des abréviations, définitions, et explications des termes qui se rapportent à la politique du réseau. Toutes les définitions sont fournies dans la Section 3, avec les termes rangés par ordre alphabétique.

L’intention est d’améliorer la compréhension et la cohérence des documents de normes de l’Internet (ISD, Internet Standards document) – c’est-à-dire, les RFC, les projets Internet, et les autres matériaux produits au titre du processus de normalisation de l’Internet [RFC2026]. Les bénéfices pour les ISD sont bien décrits dans l’introduction à la [RFC2828] :
o	 "Une documentation claire, concise, et facile à comprendre" – exige que l’ensemble des termes et définitions soit cohérent, auto suffisant et  uniforme à travers tous les ISD.
o	Excellence technique – par laquelle tous les ISD utilisent la terminologie de façon appropriée, précise et sans ambiguïté.
o	Mise en œuvre et essais préalables – exige que les termes soient utilisés dans leur forme la plus ordinaire, que les termes à usage privé et les termes "maquillés" soient évités dans les ISD, et que de nouvelles définitions ne soient pas en conflit avec celles déjà établies.
o	"Ouverture, équité, et précision" – par lesquelles les ISD évitent les termes qui sont protégés ou favorisent d’une manière quelconque un fabricant particulier, ou qui créent un biais en faveur d’une technologie ou mécanisme particulier.

Des termes de politique courants et/ou controversés sont définis. Ces termes sont en relation directe et spécifique avec la politique du réseau.

Partout où c’est possible, le présent document tire les définitions des ISD existants. On devrait noter que :
o	les projets Internet arrivés à expiration ne sont pas référencés, non plus que leur terminologie et les définitions utilisées dans le présent document.
o	plusieurs définitions peuvent exister à travers les ISD. Chaque définition  est donnée avec sa source.

2.	Explication du marquage des paragraphes

La section 3 marque les termes et définitions comme suit :
o	Majuscules : seuls les termes qui sont des noms propres sont en majuscules.
o	Marquage des paragraphes : les définitions et explications sont déclarées dans des paragraphes qui sont marqués comme suit :
-	"P" identifie les termes de base relatifs à la politique.
-	"T" identifie diverses techniques pour créer ou convoyer des informations relatives à la politique dans un réseau. Par exemple, COPS et un "modèle d’information" sont deux techniques pour communiquer et décrire des données relatives à la politique. SNMP et les MIB en sont d’autres.
-	"A" identifie des groupes de travail spécifiques et des "domaines d’utilisation" spécifiques de politique. Par exemple, AAA et QS sont deux "domaines d’utilisation" où les concepts de politique sont extrêmement importants pour leur rôle et leur fonctionnement.

3.	Termes

Note :	En fournissant les définitions de politique, d’autres termes "spécifiques de la technologie" (par exemple, relatifs aux services différenciés) peuvent être utilisés et référencés. Ces termes non politiques ne seront pas définis dans le présent document, et le lecteur se reportera à l’ISD référencé pour les détails.

$ niveaux d’abstraction (abstraction levels). Voir "abstraction de politique".

$ action. Voir "action de politique".

$ authentification, autorisation, comptabilité (AAA, Authentication, Authorization, Accounting)
(A) L’AAA traite du contrôle, de l’authentification, de l’autorisation et de la comptabilité des systèmes et environnements sur la base de politiques établies par les administrateurs et utilisateurs des systèmes. L’utilisation de la politique peut être implicite - comme défini par RADIUS [RFC2138]. Dans RADIUS, un serveur d’accès réseau envoie des accréditifs d’un utilisateur téléphonique à un serveur AAA, et reçoit l’authentification que l’usager est celui qu’il prétend être, avec un ensemble de paires attribut-valeur autorisant diverses caractéristiques de service. La politique est implicite à la fois dans l’authentification, qui peut être restreinte selon l’heure de la journée, le nombre de sessions, le numéro appelant, etc., et les valeurs d’attribut autorisées.

$ modèle d’information commun (CIM, Common Information Model)
(T) Modèle d’information en mode objet publié par le groupe de travail sur la gestion répartie (DMTF, Distributed Management Task Force) [DMTF]. Il consiste en une spécification qui détaille les constructions et les principes de modélisation abstraite du modèle d’information, et une définition de langage textuel pour représenter le modèle. Les schémas de CIM sont définis comme un ensemble de fichiers, écrits en langage de spécification, avec un rendu graphique qui utilise UML [UML]. Des ensembles de classes et d'associations représentent le cœur et les modèles communs de CIM, définissant un modèle d’information pour "l’entreprise" – traitant les concepts généraux (dans le cœur) et les systèmes, appareils, utilisateurs, la distribution du logiciel, l’environnement physique, les réseaux et la politique (dans les modèles communs). (Voir aussi "modèle d’information".)

$ service commun de politique ouverte (COPS, Common Open Policy Service)
(T) Protocole simple d’interrogation et réponse fondé sur TCP qui peut être utilisé pour échanger des informations de politique entre un point de décision de politique (PDP, Policy Decision Point) et ses clients les points de mise en application de politique (PEP, Policy Enforcement Point) [RFC2748]. Le protocole COPS est utilisé pour assurer la gestion externe des décisions de politique pour RSVP [RFC2749]. Un autre usage est pour le provisionnement de politique [RFC3084]. (Voir aussi "point de décision de politique" et "point de mise en application de politique".)

$ condition. Voir "condition de politique".

$ configuration
(P) "Configuration" peut être défini selon deux perspectives : 
-	L’ensemble des paramètres dans les éléments de réseau et autres systèmes qui déterminent leur fonction et leur fonctionnement. Certains paramètres sont statiques, comme l’allocation de la file d’attente des paquets et peuvent être prédéfinis et téléchargés sur un élément de réseau. D’autres sont plus dynamiques, comme les actions effectuées par un appareil du réseau lors de l’occurrence d’un certain événement. La distinction entre "configuration" statique (prédéfinie) et l’état dynamique des éléments de réseau se chevauche lorsque le réglage des paramètres devient plus sensible, et que la signalisation contrôle plus de degrés du comportement d’un appareil du réseau.
-	Un réglage statique d’un élément de réseau, effectué avant la livraison à un consommateur et qui ne peut pas être modifié par le consommateur.
La première est l’usage accepté dans la communauté de l’Internet.

$ modèle de données (data model)
(T) Transposition du contenu d’un modèle d’information dans une forme qui est spécifique d’un type particulier de mémorisation ou répertoire de données. Un "modèle de données" est fondamentalement le rendu d’un modèle d’information conforme à un ensemble spécifique de mécanismes de représentation, d’organisation, de mémorisation et de traitement des données. Il a trois parties [DecSupp] :
-	une collection de structures de données comme des listes, des tableaux, des relations, etc.
-	une collection d’opérations qui peuvent être appliquées aux structures comme des restitutions, des mises à jour, des ajouts, etc.
-	une collection de règles d’intégrité qui définissent les états légaux (ensemble de valeurs) ou les changements d’état  (opérations sur les valeurs). (Voir aussi "modèle d’information".)

$ services différenciés (DS, Differentiated Services)
(T) Le champ d’en-tête IP, appelé champ DS. Dans IPv4, il définit la disposition de l’octet type de service (ToS, Type of Service) ; dans IPv6, c’est l’octet Classe de trafic [RFC2474].
(A) "Services différenciés" est aussi une "zone d’utilisation" pour les politiques de qualité de service. Il exige que la politique définisse la correspondance entre les codets dans le champ DS du paquet et les comportements individuels par bond (pour réaliser un comportement spécifié par domaine). De plus, la politique peut être utilisée pour spécifier l’acheminement des paquets sur la base de divers critères de classification. (Voir aussi "Qualité de service" et "filtre".)

$ diffserv. Voir "Services différenciés".

$ réseaux à capacité de répertoire (DEN, Directory Enabled Network)
(T) Modèle de données qui est la transposition LDAP du modèle d’informations commun (CIM, Common Information Model). Ses buts sont de permettre le déploiement et l’utilisation de politiques en commençant par des concepts communs de service et d’utilisateur (définis dans le modèle d’information) spécifiant leur transposition/mémorisation dans un répertoire fondé sur LDAP, et en utilisant ces concepts dans des règles de politique indépendantes du fabricant et de l’appareil [DMTF]. (Voir aussi "modèle d’information commun" et "modèle de données".)

$ domaine (domain)
(P) Collection d’éléments et services, administrée d’une façon coordonnée. (Voir aussi "domaine de politique".)

$ filtre (filter)
(T) Ensemble de termes et/ou critères utilisés pour des besoins de séparation ou de catégorisation. C’est réalisé via un seul - ou plusieurs - champs correspondant à un en-tête de trafic et/ou de données de charge utile. Les "filtres" sont souvent manipulés et utilisés dans le fonctionnement et la politique du réseau. Par exemple, les filtres de paquets spécifient les critères de correspondance à des schémas (par exemple, des critères IP ou 802) pour distinguer les classes de trafic séparables.

$ but (goal) Voir "but de politique".

$ modèle d’information (information model)
(T) Abstraction et représentation des entités dans un environnement géré, leurs propriétés, attributs et opérations, et la façon dont elles se rapportent les unes aux autres. Il est indépendant de tout répertoire spécifique, de l’usage d’un logiciel, d’un protocole, ou d’une plate-forme.

$ base de données d’informations de gestion (MIB, Management Information Base)
(T) Collection d’informations auxquelles on peut accéder via le protocole simple de gestion de réseau. Les informations de gestion sont définies dans des modules de MIB qui utilisent les règles contenues dans les spécifications de structure d’informations de gestion (SMI, Structure of Management Information) de SNMP [RFC2570]. Les informations de gestion sont un concept abstrait, et les définitions peuvent être créées pour des spécifications de politique de haut niveau, de bas niveau, aussi bien que de configurations, d’états et de statistiques spécifiques d’une technologie et d’un fabricant. (Voir aussi "protocole simple de gestion de réseau" et "structure des informations de gestion".)

$ MPLS
Voir "commutation d’étiquettes multi protocoles". (MPLS peut aussi se référer à commutation lambda multi protocoles dans les réseaux optiques. Mais cela n’a pas de rapport avec la politique et ne sera pas discuté dans le présent document.)

$ commutation d’étiquettes multi protocoles (MPLS, Multiprotocol Label Switching)
(T) Elle intègre un cadre d’échange et de commutation d’étiquettes avec l’acheminement de couche réseau [RFC2702]. L’idée de base implique d’allouer des étiquettes de longueur fixe courtes aux paquets à l’entrée d’un nuage MPLS. Tout au long de l’intérieur du domaine MPLS, les étiquettes attachées aux paquets sont utilisées pour prendre les décisions de transmission (généralement sans recours aux en-têtes du paquet original).

$ politique gérée en externe (outsourced policy)
(P) Modèle d’exécution dans lequel un appareil de mise en application de politique produit une interrogation pour déléguer une décision pour un événement de politique spécifique à un autre composant, qui lui est externe. Par exemple, dans RSVP, l’arrivée d’un nouveau message RSVP à un PEP exige une décision de politique rapide (pour ne pas retarder l’établissement de bout en bout). Le PEP peut utiliser COPS-RSVP pour envoyer une interrogation au PDP, demandant une décision de politique [RFC2205], [RFC2748]. Une "politique gérée en externe" se différencie d’une "politique provisionnée", mais elles ne s’excluent pas mutuellement et les systèmes opérationnels peuvent les combiner.

$ politique (policy)
(P) Une "politique" peut être définie selon deux perspectives :
-	Un objectif, cours ou méthode d’action défini pour guider et déterminer les décisions présentes et futures. Les "politiques" sont mises en œuvre ou exécutées au sein d’un contexte particulier (comme des politiques définies au sein d’une unité d’affaires).
-	Des politiques comme ensemble de règles pour administrer, gérer, et contrôler l’accès aux ressources du réseau [RFC3060].
Noter que ces deux perspectives ne sont pas contradictoires car des règles individuelles peuvent être définies à l’appui d’objectifs commerciaux. (Voir aussi "but de politique", "abstraction de politique" et "règle de politique".)

$  abstraction de politique (policy abstraction)
(P) La politique peut être représentée à différents niveaux, allant de buts commerciaux à des paramètres de configuration spécifiques de l’appareil. La traduction entre les différents niveaux d’abstraction peut exiger des informations autres que la politique, comme une configuration et des capacités de paramètres du réseau et de l’hôte. Divers documents et mises en œuvre peuvent spécifier des niveaux d’abstraction explicites. Cependant, ils ne correspondent pas nécessairement à des entités de traitement distinctes ou à l’ensemble complet des niveaux dans tous les environnements. (Voir aussi "configuration" et "traduction de politique".)

$ action de politique (policy action)
(P) Définition de ce qui est fait pour appliquer une règle de politique, lorsque les conditions de la règle sont satisfaites. Les actions de politique peuvent résulter en l’exécution d’une ou plusieurs opérations pour affecter et/ou configurer le trafic et les ressources du réseau. Dans la [RFC3060], les actions d’une règle peuvent être ordonnées.

$ condition de politique (policy condition)
(P) Une représentation de l’état nécessaire et/ou des prérequis qui définissent si les actions d’une règle de politique devraient être effectuées. Cette représentation n’a pas besoin d’être complètement spécifiée, mais peut être fournie implicitement dans une mise en œuvre ou un protocole. Lorsque la ou les conditions de politique associées à une règle de politique s’évaluent à VRAI, alors (sous réserve d’autres considérations comme les priorités de règle et les stratégies de décision) la règle devrait être appliquée. 
(T) Dans la [RFC3060], les conditions d’une règle peuvent être exprimées comme un ensemble OUixé d’ensembles ETixés de déclarations (forme normale disjonctive), ou un ensemble ETixé d’ensembles OUixés de déclarations (forme normale conjonctive). Les déclarations de conditions individuelles peuvent aussi être niées.

$ conflit de politique (policy conflict)
(P) Survient lorsque les actions de deux règles (qui sont toutes deux satisfaites simultanément) se contredisent. L’entité qui met en œuvre la politique ne sera pas capable de déterminer quelle action effectuer. Les mises en œuvre de systèmes de politique doivent fournir des mécanismes de détection et évitement ou résolution de conflits pour prévenir cette situation. Un"conflit de politique" est différent d’une "erreur de politique".

$ conversion de politique (policy conversion). Voir "traduction de politique".

$ modèle d’informations de cœur de politique (PCIM, Policy Core Information Model) [RFC3060]
(T) Modèle d’information qui décrit les concepts de base des groupes de politique, des règles, conditions, actions, répertoires et leurs relations. Ce modèle est décrit comme un modèle "cœur" car il ne peut pas être appliqué sans des extensions spécifiques du domaine (par exemple, des extensions pour la QS ou IPsec). PCIM est "cœur" par rapport à la zone de politique. Cependant, c’est un "modèle commun" par rapport à CIM – en ceci qu’il étend les concepts CIM de base pour la politique. (Voir aussi "modèle d’information commun".)

$ décision de politique (policy decision)
(P) Il existe deux perspectives de "décision de politique" :
-	une perspective "processus" qui traite de l’évaluation des conditions d’une règle de politique,
-	une perspective "résultat" qui traite des actions de mise en application, lorsque les conditions d’une règle de politique sont VRAI.

$ point de décision de politique (PDP, Policy Decision Point)
(P) Entité logique qui prend des décisions de politique pour elle-même ou pour d’autres éléments de réseau qui demandent de telles décisions [RFC2753]. (Voir aussi "décision de politique".)

$ domaine de politique (policy domain)
(P) Collection d’éléments et de services, et/ou d’une portion d’un Internet sur lequel un ensemble commun et cohérent de politiques est administré de façon coordonnée [RFC2474]. Cette définition d’un domaine de politique n’empêche pas la création de multiples sources de politique au sein d’une organisation, mais exige que les politiques résultantes soient coordonnées. 
Les politiques définies dans le contexte d’un domaine peuvent avoir besoin d’être communiquées ou négociées en dehors de ce domaine. (Voir aussi "négociation de politique".)

$ mise en application de politique (policy enforcement)
(P) C’est l’exécution d’une décision de politique.

$ point d’application de politique (PEP, Policy Enforcement Point)
(P) Entité logique qui met en application les décisions de politique [RFC2753]. (Voir aussi "mise en application de politique".)

$ erreur de politique (policy error)
(P) Les "erreurs de politique" surviennent lorsque les tentatives de mise en application des actions de politique échouent, qu’elles soient dues à un état temporaire ou à une discordance permanente entre les actions de politique et les capacités d’application de l’appareil. Ceci est différent d’un "conflit de politique".

$ but de politique (policy goal)
(P) Les buts sont les objectifs commerciaux ou l’état désiré destiné à être entretenu par un système de politique. En tant que plus haut niveau d’abstraction de politique, ces buts sont le plus directement décrits en termes d’affaires plutôt que techniques. Par exemple, un but peut déclarer qu’une application particulière fonctionne sur le réseau bien qu’elle ait son propre réseau dédié, en dépit de l’utilisation d’une infrastructure partagée. Les 'buts de politique' peuvent inclure les objectifs d’un accord de niveau de service, ainsi que l’allocation de ressources aux applications ou individus. Un système de politique peut être créé qui s’efforce automatiquement de réaliser un but par des retours concernant la mesure dans laquelle le but (comme un niveau de service) est en train d’être atteint.

$ base de données d’informations de politique (PIB, Policy Information Base)
(T) Collections de classes d’approvisionnement (PRC, PRovisioning Classe) en rapport, définies comme un module. (Voir aussi "classe d’approvisionnement".)

$ transposition de politique (policy mapping). Voir "traduction de politique".

$ négociation de politique (policy negotiation)
(P) Exposition de la partie désirée ou appropriée d’une politique à un autre domaine. Ceci est nécessaire pour prendre en charge une interconnexion partielle entre des domaines, qui fonctionnent avec des ensembles de politiques différents.

$ répertoire de politique (policy repository)
(P) Un "répertoire de politiques" peut être défini selon trois perspectives :
-	Un stockage de données spécifique qui détient les règles de politique, leurs conditions et actions, et les données de politique qui s’y rapportent. Une base de données ou un répertoire serait un exemple d’un tel stockage.
-	Un conteneur logique représentant la portée administrative et la désignation des règles de politique, leurs conditions et actions, et les données de politique qui s’y rapportent. Un domaine "politique de QS" serait un exemple d’un tel conteneur.
-	Dans la [RFC3060] existe une définition plus restrictive que la précédente. Un PolicyRepository est une abstraction de modèle représentant un conteneur logique défini administrativement pour des éléments de politique réutilisables.

$ demande de politique (policy request)
(P) Message qui demande un service en rapport avec la politique. Cela peut se référer à une demande de restitution d’un ensemble spécifique de règles de politique, pour déterminer les actions à mettre en application, ou à d’autres demandes de politique. Lorsque elle est envoyée par un PEP à un PDP, elle est plus précisément qualifiée de "demande de décision de politique" [RFC2753]. (Voir aussi "décision de politique".)

$ règle de politique (policy rule)
(P) Pierre angulaire d’un système fondé sur la politique. C’est le liant d’un ensemble d’actions avec un ensemble de conditions – où les conditions sont évaluées pour déterminer si les actions sont effectuées [RFC3060].

$ serveur de politique (policy server)
(P) Terme commercial de définition imprécise. À l’origine, la [RFC2753] faisait référence à un "serveur de politique". Comme la RFC a évolué, ce terme a été précisé et est devenu le point de décision de politique (PDP, Policy Decision Point). Aujourd’hui, le terme est utilisé dans la littérature commerciale et autre pour se référer spécifiquement à un PDP, ou pour toute entité qui utilise/dessert une politique.

$ traduction de politique (policy translation)
(P) Transformation d’une politique d’une représentation et/ou niveau d’abstraction, en une autre représentation ou niveau d’abstraction. Par exemple, il peut être nécessaire de convertir des données d’une PIB en un format de ligne de commande. Dans cette "conversion," la traduction dans la nouvelle représentation va vraisemblablement exiger un changement du niveau d’abstraction (devenant plus ou moins spécifique). Bien que ces tâches soient logiquement distinctes, elles sont (dans la plupart des cas) brouillées dans l’acte de traduction/conversion/transposition. Donc, ceci est aussi appelé une "conversion de politique" ou une "transposition de politique".

$ PolicyGroup
(T) Abstraction du modèle d’information de cœur de politique de la [RFC3060]. C’est une classe qui représente un conteneur, qui agrège des règles de politique ou d’autres groupes de politique. Elle permet le groupement de règles dans une politique, et de préciser des politiques de haut niveau à des groupes homologues de niveau inférieur ou différent (c’est-à-dire, converties ou traduites).

$ politique provisionnée (provisioned policy)
(P) Modèle d’exécution dans lequel les éléments de réseau sont préconfigurés, sur la base d’une politique, avant de traiter les événements. La configuration est poussée dans l’appareil réseau, par exemple, sur la base de l’heure du jour du démarrage initial de l’appareil. Dans ce modèle, l’accent est mis sur la distribution des informations de configuration, et les services différenciés de la [RFC2475] en sont un bon exemple. Sur la base des événements reçus, les appareils utilisent des mécanismes téléchargés (préprovisionnés) pour mettre en œuvre la politique. "politique provisionnée" s’oppose à "politique gérée en externe".

$ classe d’approvisionnement (PRC, PRovisioning Class)
(T) Ensemble ordonné d’attributs représentant un type de données de politique. Les PRC sont définies dans les modules de PIB (codées en utilisant SPPI) et enregistrées dans l’arborescence des identifiants d’objet. Les instances de chaque PRC sont organisée en tableaux, similaires aux tableaux conceptuels dans SMIv2. (Voir aussi "structure des informations d’approvisionnement de politique" et "base de données d’informations de politique".) 
L’acronyme, PRC, a évolué de "classe de règle de politique" en "classe d’approvisionnement". La raison du changement est qu’une discordance existait entre l’utilisation des mots, "règle de politique" dans le contexte PRC par rapport aux autres utilisations dans PCIM et l’industrie. Dans ces dernières, les règles sont Si/alors déclarations – un lien des conditions aux actions. Les PRC ne sont pas des "règles" dans cette définition, mais le codage des informations de configuration (à l’échelle du réseau) pour un appareil.

$ instance d’approvisionnement (PRI, PRovisioning Instance)
(T) C’est une instanciation d’une classe d’approvisionnement. (Voir aussi "classe d’approvisionnement".)

$ qualité de service (QoS, Quality of Service)
(A) À un haut niveau d’abstraction, "qualité de service" se réfère à la capacité de livrer des services réseau conformément aux paramètres spécifiés dans un accord de niveau de service. La "qualité" est caractérisée par la disponibilité du service, le délai, la gigue, le débit et le ratio de perte de paquets. Au niveau des ressources du réseau, "qualité de service" se réfère à un ensemble de capacités qui permettent à un fournisseur de service de donner une priorité à du trafic, de contrôler la bande passante et la latence du réseau. Il y a deux approches différentes de la "qualité de service" sur les réseaux IP : les services intégrés [RFC1633], et les services différentiés [RFC2475]. Les services intégrés exigent un contrôle de la politique sur la création des réservations signalées, qui provoquent un comportement spécifique quantitatif de bout en bout pour un (ensemble de) flux. À l’opposé, les services différenciés exigent que la politique définisse la correspondance entre les codets dans le champ DS du paquet et les comportements individuels par bond (pour réaliser un comportement spécifié par domaine). Un maximum de 64 comportements par bond limite le nombre de classes de service de trafic qui peuvent être marquées en tout point d’un domaine. Ces classes de service signalent le traitement des paquets par rapport aux divers aspects de QS, comme la priorité des flux et la préséance d’abandon de paquet. De plus, la politique peut être utilisée pour spécifier l’acheminement des paquets sur la base de divers critères de classification. La politique contrôle l’ensemble des paramètre de configuration et l’acheminement pour chaque classe des services différenciés, et les conditions d’admission pour les réservations dans les services intégrés. (Voir aussi "abstraction de politique" et "accord de niveau de service".)

$ protocole de réservation de ressource (RSVP, Resource reSerVation Protocol)
(T) Protocole d’établissement conçu pour un Internet à services intégrés, pour réserver les ressources du réseau pour un chemin [RFC2205]. Et un mécanisme de signalisation pour gérer la QS du trafic d’application dans un réseau à services différenciés.

$ rôle (role)
(P) Un "rôle" est défini selon trois perspectives :
-	Une position ou fonction commerciale, à laquelle sont affectées des personnes et des entités logiques. [X.500]
-	Les points d’extrémité étiquetés d’une association de langage de modélisation unifié (UML, Unified Modeling Language). Citation de [UML], "Lorsque une classe participe à une association, elle a un rôle spécifique qu’elle joue dans cette relation  ; un rôle est juste la face que présente la classe à l’extrémité proche de l’association à la classe qui est à l’autre extrémité de l’association". Le modèle d’information de cœur de politique [RFC3060] utilise l’UML pour décrire sa hiérarchie de classes. Les relations/associations sont significatives dans le modèle.
-	Une caractéristique spécifiée administrativement d’un élément géré (par exemple, une interface). C’est un sélecteur pour les règles de politique et les classes d’approvisionnement (PRC), pour déterminer l’applicabilité de la règle/PRC à un élément géré particulier [RFC3060].
Seule la troisième définition (rôles comme sélecteurs de politique) se rapporte directement à la gestion de la politique du réseau. Cependant, la première définition (rôles comme positions et fonctions commerciales) peut être référencée dans les conditions et actions de politique.

$ combinaison de rôles (role combination)
(P) Ensemble de rôles lexicographiquement ordonnés qui caractérisent des éléments gérés et indique l’applicabilité de règles de politique et de classes d’approvisionnement (PRC). Un système de politique utilise l’ensemble de rôles rapportés par l’élément géré pour déterminer les règles/PRC correctes à envoyer pour leur mise en application. Cette détermination peut examiner toutes les règles de politique applicables identifiées par la combinaison de rôles, ses sous combinaisons et les rôles individuels dans la combinaison [RFC3060]. Dans le cas de PRC, une PRC doit explicitement correspondre à la combinaison de rôles de l’élément géré afin d’être applicable et/ou mise en application. (La comparaison est normalement sensible à la casse.) L’ensemble final de règles/PRC à mettre en application est défini par le système de politique, comme approprié pour la combinaison de rôles spécifiée de l’élément géré.

$ règle. Voir "règle de politique".

$ moteur fondé sur la règle (rule based engine)
(T) Un moteur fondé sur la règle est capable d’évaluer des conditions de politique et de déclancher les actions de politique appropriées. Un moteur particulier fondé sur la règle peut seulement être capable d’agir sur des règles de politique qui sont formatées d’une façon spécifiée ou d’adhérer à un langage spécifique.

$ schéma (schema)
(T) Deux différentes perspectives de schéma sont définies :
-	Un ensemble de règles qui détermine quelles données peuvent être mémorisées dans une base de données ou un service de répertoire [DirServs].
-	Une collection de modèles de données qui sont chacun liés au même type de répertoire.
Cette dernière est la préférée et est recommandée pour les documents de normalisation de l’Internet. (Voir aussi "modèle de données".)

$ service
(P) Comportement ou fonctionnalité fourni par un réseau, un élément de réseau ou un hôte [DMTF], [RFC2216]. En citant la [RFC2216], afin de spécifier complètement un "service", on doit définir les "fonctions à accomplir ..., les informations requises ... pour effectuer ces fonctions, et les informations rendues disponibles par les éléments aux autres éléments du système". La politique peut être utilisée pour configurer un "service" dans un réseau ou sur un élément/hôte du réseau, invoquer ses fonctionnalités, et/ou coordonner les services dans un inter domaine ou un environnement de bout en bout.

$ accord de niveau de service (SLA, Service Level Agreement)
(P) C’est le résultat documenté d’une négociation entre un abonné/consommateur et un fournisseur de service, qui spécifie les niveaux de disponibilité, de service, de performances, de fonctionnement ou autres attributs du service [RFC2475]. (Voir aussi "objectifs de niveau de service".)

$ objectif de niveau de service (SLO, Service Level Objective)
(P) Ils partagent un SLA en métriques individuelles et en informations opérationnelles pour mettre en application et/ou surveiller le SLA. Des "objectifs de niveau de service" peuvent être définis au titre d’un SLA, d’un SLS, ou dans un document séparé. C’est un ensemble de paramètres et leurs valeurs. Les actions de mise en application et le rapport de surveillance de la conformité peuvent être mis en œuvre comme une ou plusieurs politiques. (Voir aussi "accord de niveau de service".)

$ spécification de niveau de service (SLS, Service Level Specification)
(P) Elle spécifie le traitement du trafic du consommateur par un fournisseur de réseau. Elle est négociée entre un consommateur et le fournisseur, et (par exemple) dans un environnement DiffServ, définit des paramètres comme les codets spécifiques et le comportement par bond, les caractéristiques du profil et le traitement du trafic pour ces codets. Un SLS est un SLA spécifique (un accord négocié) et ses SLO (les métriques individuelles et les données de fonctionnement à mettre en application) pour garantir la qualité de service pour le trafic du réseau. (Voir aussi "accord de niveau de service" et "objectif de niveau de service".)

$ protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol)
(T) SNMP est un cadre (incluant un protocole) pour gérer les systèmes dans un environnement de réseau [RFC2570]. Il peut être utilisé pour la configuration et le contrôle fondés sur la politique en utilisant un module de MIB spécifique conçu pour exécuter les politiques sur les éléments gérés via des descriptifs (scripts). Les éléments (instances) dans un appareil réseau sont évalués en utilisant un filtre de politique, pour déterminer où la politique va s’appliquer.

$ structure des informations d’approvisionnement de politique (SPPI, Structure of Policy Provisioning Information)
(T) Sous ensemble adapté de la structure des informations de gestion de SNMP (SMIv2) qui est utilisé pour coder des collections de classes d’approvisionnement en rapport comme une PIB [RFC3159]. (Voir aussi "base de données d’informations de politique" et "classe d’approvisionnement".)

$ structure des informations de gestion (SMI, Structure of Management Information), version 2 (SMIv2)
(T) Sous ensemble adapté de la notation de syntaxe abstraite n° 1 (ASN.1) de l’OSI, (1988) utilisé pour coder des collections d’objets en rapport comme modules SNMP de base de données d’information de gestion (MIB) [RFC2578].

$ sujet (subject)
(P) Entité, ou collection d’entités, qui génère une demande, et est vérifiée comme autorisée/non autorisée à effectuer cette demande.

$ cible (target)
(P) Entité, ou collection d’entités, qui est affectée par une politique. Par exemple, les "cibles" d’une politique pour reconfigurer un appareil réseau sont les services individuels qui sont mis à jour et configurés.

4.	Propriété intellectuelle

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

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

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

5.	Remerciements

Le présent document s’appuie sur les travaux des précédents projets de terminologie. Les auteurs de ces documents sont Fran Reichmeyer, Dan Grossman, John Strassner, Ed Ellesson et Matthew Condell. Aussi, les définitions des concepts généraux de politique et de règle de politique incluent des apports de Predrag Spasic. Des commentaires et suggestions très utiles ont été reçus de Juergen Schoenwaelder, Joe Salowey, Jon Saperia, Ravi Sahita, Bob Moore, Guus Sliepen, T.H. Jonatan et Dave Perkins.

6.	Considérations pour la sécurité

Le présent document définit seulement des termes en rapport avec la politique. Il ne décrit pas en détail les vulnérabilités, les menaces, ou les mécanismes qui protègent les mises en œuvre spécifiques de politique ou les protocoles Internet relatifs à la politique.

7.	Références

[DecSupp]	R. Sprague, and E. Carleson. "Building Effective Decision Support Systems". Prentice Hall, 1982.

[DirServs]	T. Howes, M. Smith, and G. Good. "Understanding and Deploying LDAP Directory Services". MacMillan Technical Publications, 1999.

[DMTF]	Distributed Management Task Force, Inc.  "Common Information Model (CIM) Schema, version 2.x". Les composants du schéma CIM v2.x sont disponibles à http://www.dmtf.org/standards/standard_cim.php .

[RFC1633]	R. Braden, D. Clark et S. Shenker, "Intégration de services dans l'architecture de l'Internet : généralités", juin   1994. (Info.)

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

[RFC2138]	C. Rigney, A. Rubens, W. Simpson, S. Willens, "Service d'authentification distante d'utilisateur appelant (RADIUS)", avril   1997. (Remplace RFC2058) (Obsolète, voir RFC2865) (P.S.)

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC2216]	S. Shenker, J. Wroclawski, "Modèle de spécification de services d'élément de réseau", septembre 1997. (Information)

[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)

[RFC2475]	S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre   1998. (MàJ par RFC3260)

[RFC2570]	J. Case, R. Mundy, D. Partain, B. Stewart, "Introduction à la version 3 du cadre de gestion de réseau de l'Internet", avril  1999. (Obsolète, voir RFC3410) (Information)

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

[RFC2702]	D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre   1999. (Information)

[RFC2748]	D. Durham et autres, "Protocole COPS (Service commun de politique ouverte)", janvier 2000. (MàJ par RFC4261) (P.S.)

[RFC2749]	S. Herzog,  et autres, "Utilisation de COPS avec RSVP", janvier 2000. (P.S.)

[RFC2753]	R. Yavatkar, D. Pendarakis, R. Guerin, "Cadre pour le contrôle d'admission fondé sur la politique", janvier 2000. (Info.)

[RFC2828]	R. Shirey, "Glossaire de la sécurité sur l'Internet", FYI 36, mai 2000. (Obsolète, voir RFC4949)

[RFC3060]	B. Moore et autres, "Spécification du modèle d'information de cœur de politique -- version 1", février 2001. (MàJ par RFC3460) (P.S.)

[RFC3084]	K. Chan et autres, "Utilisation de COPS pour l'approvisionnement de politique (COPS-PR)", mars 20010 (P.S.)

[RFC3159]	K. McCloghrie et autres, "Structure des informations d'approvisionnement de politique (SPPI)", août 2001. (P.S.)

[UML]	 G. Booch, J. Rumbaugh, and I. Jacobson  "The Unified Modeling Language User Guide". Addison-Wesley, 1999.

[X.500]	Recommandations UIT-T X.500-X.521, "Annuaire des réseaux de communications de données", novembre 1988.

8.	Adresse des auteurs

Andrea Westerinen	John Schnizlein	John Strassner	
Cisco Systems, Bldg 20	Cisco Systems	Intelliden Corporation	
725 Alder Drive	9123 Loughran Road	90 South Cascade Avenue	
Milpitas, CA 95035	Fort Washington, MD 20744	Colorado Springs, CO 80903	
mél : andreaw@cisco.com 	mél : john.schnizlein@cisco.com 	mél :   john.strassner@intelliden.com 	

Mark Scherling	Bob Quinn	Jay Perry	Shai Herzog	
Xcert International Inc.	Celox Networks	Network Appliance	PolicyConsulting.com	
Vancouver, BC	2 Park Central Drive	495 East Java Drive	200 Clove Rd.	
V7X 1M3	Southborough, MA 01772	Sunnyvale, CA 94089	New Rochelle, NY 10801	
mél : mscherling@xcert.com 	bquinn@celoxnetworks.com 	mél : jay.perry@netapp.com 	herzog@PolicyConsulting.com 	

An-Ni Huynh	Mark Carlson	Steve Waldbusser	
Lucent Technologies	Sun Microsystems, Inc.	téléphone : 650-948-6500	
2139 Route 35	500 Eldorado Boulevard	Fax :   650-745-0671	
Holmdel, NJ 07733	Broomfield, CO 80021	mél : waldbusser@nextbeacon.com 	
	mél  : mark.carlson@sun.com 		

9.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

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

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.