Network Working Group K

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions d’amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document, Structure des informations d’approvisionnement de politique (SPPI, Structure of Policy Provisioning Information) définit le sous-ensemble adapté de la structure des informations de gestion (SMI) de SNMP utilisé pour écrire les modules de base de données d’informations de politique (PIB).

La RFC2748 définit le protocole COPS et la RFC2749 décrit comment le protocole COPS est utilisé pour fournir la génération externe des décisions de politique pour RSVP. Une autre utilisation du protocole COPS, pour l’approvisionnement de politique, est introduite dans la RFC3084. Dans ce modèle d’approvisionnement, les informations de politique sont vues comme une collection de classes d’approvisionnement (PRC) et d’instances d’approvisionnement (PRI) résidant dans un magasin d’informations virtuel, appelé la base de données d’informations de politique (PIB, Policy Information Base). Les collections des classes d’approvisionnement en rapport sont définies dans un module de PIB.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

Table des Matières

1. Utilisation de la SMI 2

1.1 Traduction de terminologie 2

1.2 Généralités 2

2. Structure de cette spécification 3

3. Définitions 3

4. Modules de PIB 9

4.1 Importation de définitions 10

4.2 Mots-clés réservés 10

5. Hiérarchie de désignations 10

6. Transposition de la macro IDENTITÉ DE MODULE 10

6.1 Transposition de la clause CATEGORIES-SUJET 10

7. Transposition de la macro TYPE-D’OBJET 11

7.1 Transposition de la clause SYNTAXE 11

7.2 Transposition de la clause MAX-ACCES 12

7.3 Transposition de la clause PIB-ACCES 12

7.4 Transposition de la clause INSTALLE-ERREURS 12

7.5 Transposition de la clause PIB-INDEX 13

7.6 Transposition de la clause INDEX 13

7.7 Transposition de la clause AUGMENTE 13

7.8 Transposition de la clause ETEND 13

7.9 Transposition de la clause UNICITÉ 14

7.10 Transposition de la clause PIB-REFERENCES 14

7.11 Transposition de la clause PIB-TAG 14

8. Transposition de la macro IDENTITÉ D’OBJET 15

9. Transposition de la macro GROUPE-D’OBJET 15

9.1 Transposition de la clause OBJETS 15

10. Transposition de la macro CONFORMITÉ DE MODULE 15

10.1 Transposition de la clause MODULE 15

11. Conventions textuelles 16

11.1 Transposition de la macro CONVENTION TEXTUELLE 16

12. Extension d’un module de PIB 17

12.1 Modules de PIB 17

12.2 Allocations d’objet 17

12.3 Définitions d’objet 18

Appendice A : Transposition d’une PIB en MIB 18

Appendice B : Exemple d’usage des clauses PIB-REFERENCES et PIB-TAG 19

Considérations pour la sécurité 20

Considérations pour l’IANA 20

Adresses des auteurs 21

Références 21

Déclaration complète de droits de reproduction 22

Les modules de SPPI et PIB se fondent sur les modules de SMI et de MIB de SNMP, qui utilisent un sous ensemble adapté du langage de définition de données de l’ASN.1 [ASN1]. La décision de fonder la définition des modules de PIB sur ce format permet de démultiplier les connaissances, l’expérience, et les outils de la communauté, sur les modules de SMI et de MIB.

La structure des informations de gestion (SMI, Structure of Management Information) utilise le terme "objets gérés" pour se référer aux types d’objets, aussi bien les types tabulaires avec des descripteurs tels que xxxTable et xxxEntrée, que les types d’objets scalaires et colonnaires. La SPPI n’utilise pas le terme "objet" de façon à éviter toute confusion avec les objets du protocole COPS. À la place, la SPPI utilise le terme de classe d’approvisionnement (PRC, PRovisioning Class) pour les définitions de tableaux et de rangées (respectivement, les objets xxxTable et xxxEntrée) et d’instance d’approvisionnement (PRI, PRovisioning Instance) pour une instanciation d’une définition de rangée. Pour un objet colonnaire d’une définition de tableau, la SPPI utilise le terme "attribut" d’une classe d’approvisionnement. (La SPPI ne prend pas en charge l’équivalent des objets scalaires de la SMI.)

La SMI de SNMP est divisée en cinq parties : définitions de modules, définitions d’objets, définitions de notifications [RFC2578], définitions de conventions textuelles [RFC2579] et définitions de conformité [RFC2580].

- La macro IDENTITÉ DE MODULE de la SMI est utilisée pour porter la sémantique d’un module de MIB. La SPPI utilise cette macro pour porter la sémantique d’un module de PIB.

- La macro TYPE D’OBJET de la SMI est utilisée pour convoyer la syntaxe et la sémantique des objets gérés. La SPPI utilise cette macro pour convoyer la syntaxe et la sémantique des PRC et de leurs attributs.

- Les définitions de notification de la SMI ne sont pas utilisées (pour l’instant) par la SPPI. (Noter que l’utilisation du mot-clé 'notifie' dans la SPPI n’a pas de rapport avec les notifications de la SMI).

- La macro CONVENTION TEXTUELLE de la SMI permet de définir de nouveaux types de données. La SPPI utilise cette macro pour définir de nouveaux types de données ayant une syntaxe et une sémantique particulière qui est commune à plusieurs attributs d’une ou plusieurs PRC.

- Les définitions de conformité de la SMI définissent plusieurs macros : la macro GROUPE D’OBJET, la macro GROUPE DE NOTIFICATION, la macro CONFORMITÉ DE MODULE, et la macro CAPACITÉS D’AGENT. La SPPI utilise les macros GROUPE D’OBJET et CONFORMITÉ DE MODULE pour spécifier les limites inférieures acceptables de la mise en œuvre des attributs des PRC, et par là, indirectement, les limites inférieures acceptables de la mise en œuvre elle-même. La macro GROUPE DE NOTIFICATION n’est pas utilisée (pour l’instant) par la SPPI. L’éventuel usage par la SPPI de la macro CAPACITÉS D’AGENT fera l’objet d’études futures.

La SMI est spécifiée en termes de définition ASN.1 avec un texte descriptif pour chaque élément introduit dans cette définition ASN.1. Le présent document spécifie aussi la SPPI via une définition ASN.1, qui est une version modifiée de la définition de la SMI, avec un texte descriptif pour les seuls éléments de la définition ASN.1 de la SPPI qui présentent des différences avec celle de la SMI. Pour les éléments de la définition ASN.1 qui n’ont pas de texte descriptif dans la présente spécification, le lecteur se reportera au texte descriptif de la SMI pour cet élément.

ReferPart ::= "REFERENCE" Texte | vide -- chaîne de caractères comme défini dans la [RFC2578]

-- 3 types ASN.1 incorporés : ENTIER, CHAINE D’OCTETS, IDENTIFIANT D’OBJET.

-- 7 types définis par l’application : Entier32, IpAdresse, Nonsigné32, TimeTicks, Opaque, Entier64 et Nonsigné64.

SimpleSyntax, -- noter que les SEQUENCE pour les définitions de tableau et de rangées ne sont pas mentionnées ici.

-- indistinguable de ENTIER, mais n’a jamais besoin de plus de 32 bits pour une représentation de complément à deux.

-- Le type IpAdresse représente une adresse Internet IPv4 de 32 bits. Il est représenté comme ChaîneDOctets de longueur 4, dans l’ordre des octets du réseau.

-- Noter que le type IpAdresse est présent pour des raisons historiques. Les adresses IPv4 et IPv6 devraient être représentées en utilisant la INET-ADDRESS-MIB définie dans la [RFC2851].

Syntaxe ::= -- Doit être une des suivantes : un type de base (ou ses déclinaisons), une convention textuelle (ou ses déclinaisons, ou un pseudo-type BITS

Entrée ::= valeur(NomDObjet) -- utilise la valeur de INDEX de l’invocation de TYPE-D’OBJET correspondant.

PibTagPart ::= "PIB-TAG" "{" Attr "}" | vide - à utiliser avec le TC TagReferenceId

Defvaleur ::= -- doit être valide pour le type spécifié dans la clause SYNTAXE de la même macro TYPE-D’OBJET.

texte ::= valeur(IA5String) -- Chaîne de caractères telle que définie dans la [RFC2578].

texte ::= valeur(IA5String) -- Chaîne de caractères comme défini dans la [RFC2578].

identifiant ModuleIdentifier -- Ne doit pas être vide sauf si il est contenu dans le module de MIB.

"DESCRIPTION" texte -- Doit être une précision pour la clause SYNTAXE de l’objet.

Syntaxe ::= -- Doit être un type de base (ou sa précision) une convention textuelle (ou sa précision) ou un pseudo-type BITS

texte ::= valeur(IA5String) -- Chaîne de caractères comme défini dans la [RFC2578]

Syntaxe ::= -- Doit être un type de base (ou sa précision) ou un pseudo-type BITS

DESCRIPTION : "Module de PIB contenant un ensemble de conventions textuelles d’applicabilité générale à tous les modules de PIB."

DESCRIPTION :"Convention textuelle suivie par un attribut qui est utilisé comme indice d’identification d’instance d’une PRC, c’est-à-dire, un attribut désigné dans une clause PIB-INDEX. La valeur d’un attribut avec cette syntaxe est toujours positive. Les PRI de la même PRC n’ont pas besoin d’avoir des valeurs contiguës pour leur attribut d’identification d’instance."

DESCRIPTION : "Convention textuelle suivie par un attribut qui est utilisé comme pointeur pour référencer une instance d’une PRC particulière. Un attribut ne doit pas être utilisé avec cette syntaxe dans une clause PIB-INDEX, et sa description doit spécifier la PRC particulière à laquelle la PRI référencée appartient. Pour un attribut de ce type, la PRI référencée doit exister. De plus, c’est une erreur d’essayer de supprimer une PRI qui est référencée par une autre instance sans supprimer/modifier d’abord l’instance de référence. La définition d’un attribut avec cette syntaxe peut permettre à l’attribut d’avoir une valeur de zéro pour indiquer qu’il ne pointe pas actuellement sur une PRI."

DESCRIPTION : "Représente un pointeur sur une PRI, c’est-à-dire, sur une instance d’une PRC. La valeur est le nom d’OID de la définition de rangée de la PRC, auquel s’ajoute le sous identifiant qui contient la valeur de l'identifiant d’instance InstanceId de l’instance référencée. La définition d’un attribut avec cette syntaxe peut permettre à un attribut d’avoir une valeur de 0,0 pour indiquer qu’il ne pointe pas actuellement sur une PRI."

DESCRIPTION : "Représente une valeur d’étiquette, de telle sorte que toutes les instances d’une PRC particulière qui ont la même valeur d’étiquette forment une liste d’étiquettes. Une liste d’étiquettes est identifiée par la valeur d’étiquette partagée par toutes les instances de cette liste d’étiquettes."

DESCRIPTION : "Représente une référence à une liste d’étiquettes des instances d’une PRC particulière. Cette PRC doit avoir un attribut qui a la syntaxe de TagId. La liste d’étiquettes consiste en toutes les instances qui ont la même valeur de l’attribut TagId. La référence à la liste d’étiquettes se fait via l’attribut avec la syntaxe de TagReferenceId contenant la valeur d’étiquette qui identifie la liste d’étiquettes. La définition d’un attribut avec cette syntaxe peut permettre à l’attribut d’avoir une valeur de 0 pour indiquer qu’il ne référence actuellement aucune liste d’étiquettes."

Les noms de tous les modules de PIB standard doivent être uniques (mais différentes versions du même module devraient avoir le même nom). Les développeurs de modules de MIB d’entreprise sont invités à choisir pour leurs modules des noms qui aient une faible probabilité de collision avec les modules normalisés ou ceux d’autres entreprises.

Comme pour la SMI, des macros ASN.1 supplémentaires ne doivent pas être définies dans les modules de PIB.

Comme la SMI, un module de PIB qui a besoin de faire référence à une définition externe, doit utiliser la déclaration IMPORTE pour identifier le descripteur et le module dans lequel le descripteur est défini, où un module est identifié par son nom de module ASN.1.

En particulier, un module de PIB importe chacun des types de données de base qu’il utilise à partir de COPS-PR-SPPI (définie dans le présent document) et peut importer en tant que de besoin à partir d’autres modules de PIB. Un module de PIB peut importer, de la SMI, des OID (une sous arborescence) pour les besoins de la définition de nouveaux OID. Un module de PIB peut aussi importer, d’autres modules de MIB, des définitions d’allocation d’OID ainsi que de convention textuelle pourvu que leur syntaxe sous-jacente soit acceptée par la SPPI. Cependant, ce qui suit ne doit pas être inclus dans une déclaration IMPORTE :

- les types nommés définis par l’ASN.1 lui-même, et précisément les types ENTIER, CHAINE D’OCTETS, IDENTIFIANT D’OBJET, SEQUENCE, SEQUENCE DE,

Pour chaque macro ASN.1 qu’utilise une PIB, elle doit importer cette définition de macro de la COPS-PR-SPPI.

En plus des mots-clés réservés énumérés dans la SMI, ceux qui suivent ne doivent pas être utilisés comme descripteurs ou noms de module : ÉTEND, INSTALLE-ERREURS, Entier64, PIB-MIN-ACCES, PIB-ACCES, PIB-INDEX, PIB-REFERENCES, PIB-TAG, CATEGORIES-SUJET, UNICITÉ, Nonsigné64.

La SPPI utilise la même hiérarchie de désignation d’IDENTIFIANT D’OBJET que la SMI. C’est-à-dire, les OID sont normalement alloués aux modules de PIB à partir de la sous arborescence administrée par l’Autorité d’allocation des numéros de l’Internet (IANA). Cependant, comme la SMI, la SPPI n’interdit pas la définition de PRC dans d’autres portions de l’arborescence des OID.

La clause CATEGORIES-SUJET, qui doit être présente, identifie une ou plusieurs catégories de données d’approvisionnement pour lesquelles ce module de PIB définit des informations d’approvisionnement. Pour les utiliser avec le protocole COPS-PR, les catégories individuelles de sujets sont transposées en types de client COPS [RFC3084]. Les considérations relatives à l’IANA pour les CATEGORIES-SUJET SPPI suivent les mêmes exigences que celles spécifiées dans les considérations relatives à l’IANA de la [RFC2748] pour les types de client COPS. Les catégories de sujet sont identifiées :

- via le mot-clé "tous", qui indique que le module de PIB définit les informations d’approvisionnement pertinentes pour toutes les catégories de sujet (et donc, tous les types de client COPS) ou

- par une liste énumérant les nombres désignés, où chaque nombre, qui doit être supérieur à zéro, identifie une catégorie de sujet, et est transposé en le type de client qui est identifié par le même nombre dans le protocole COPS. L’espace des noms pour ces nombres désignés est global et donc les étiquettes devraient être allouées de façon cohérente à travers les modules de PIB. Pour l’instant, pas plus d’une énumération de numéros désignés ne devrait être spécifiée.

Noter que la liste des catégories spécifiées dans une clause CATEGORIES-SUJET d’un module de PIB n’est pas exclusive. C’est-à-dire que certaines autres spécifications pourraient (par exemple, à l’avenir) spécifier des types de clients COPS supplémentaires pour lesquels le module serait pertinent.

Lorsque un module de PIB s’applique à plusieurs catégories de sujets, ce module de PIB existe dans plusieurs magasins d’informations virtuels, un pour chaque type de client. Un module de PIB avec CATEGORIES-SUJET réglé à "tous" utilise le nombre désigné spécifié dans la CATEGORIES-SUJET de la PIB à laquelle il est associé, comme type de client COPS lorsque il est envoyé sur COPS.

La SPPI exige que toutes les définitions d’attribut soient contenues dans une PRC, c’est-à-dire, au sein d’une définition de tableau.

La clause SYNTAXE, qui doit être présente au sein de la définition d’un attribut, définit la structure de données abstraite de cet attribut. La structure de données doit être une des suivantes : type de base, construction BITS, ou convention textuelle.

La clause SYNTAXE doit aussi être présente pour les définitions de tableau et de rangée d’une PRC, et dans ce cas, doit être une SEQUENCE DE ou SEQUENCE (voir au paragraphe 8.1.7).

- types définis par l’application : Entier32, Nonsigné32, TimeTicks, Entier64 et Nonsigné64.

Une convention textuelle est un type nouvellement défini comme un sous-type d’un type de base [RFC2579]. La valeur d’un attribut dont la syntaxe est définie en utilisant une convention textuelle est codé "sur le fil" conformément au type de base sous-jacent de la convention textuelle.

Noter que l’ensemble des types de base a été choisi de façon à fournir une diversité suffisante de codages sur le fil des valeurs d’attributs ; les types de base devraient contenir un minimum de sémantique. La sémantique devrait, dans la mesure du possible, être incorporée dans un type de données par l’utilisation d’une convention textuelle.

On décrit maintenant les différences de la sémantique de ObjectSyntax par rapport à la SMI.

Le type Opaque n’est fourni que pour la rétro compatibilité, et ne devra pas être utilisé pour les types d’objet nouvellement définis. Le type Opaque prend en charge la capacité de passer une syntaxe ASN.1 arbitraire. Une valeur est codée en utilisant les règles de codage de base ASN.1 [ASN1] dans une chaîne d’octets. Cela est à son tour codé comme une CHAINE D’OCTETS, effectuant une "double enveloppe" de la valeur ASN.1 d’origine. Noter qu’une mise en œuvre conforme a seulement besoin d’être capable d’accepter et reconnaître les données opaques codées. Elle n’a pas besoin d’être capable de désenvelopper les données et d’interpréter ensuite leur contenu. Une exigence des modules de PIB "standard" est qu’aucun objet ne puisse avoir une valeur de clause SYNTAXE de Opaque.

Le type IpAdresse n’est fourni que pour la rétro compatibilité, et ne devra pas être utilisé pour les types d’objet nouvellement définis. Il est plutôt recommandé d’utiliser la paire de conventions textuelles InetAddressType/InetAddress comme défini dans la [RFC2851].

Le type Entier64 représente des informations de valeur d’entier entre -2^63 et 2^63-1 inclus (de -9 223 372 036 854 775 808 à 9 223 372 036 854 775 807 en décimal). Bien que Entier64 puisse être sous typé pour être plus restreint, si la contrainte résulte en ce que toutes les valeurs possibles sont contenues dans la gamme (-2 147 483 648 à 2 147 483 647) le type Entier32 doit alors être utilisé à la place de Entier64.

Le type Nonsigné64 représente des informations de valeur d’entier entre 0 et 2^64-1 inclus (en décimal, de 0 à 18 446 744 073 709 551 615). Bien que Nonsigné64 puisse être sous typé pour être plus restreint, si la contrainte résulte en ce que toutes les valeurs possibles sont contenues dans la gamme (0 à 4 294 967 295) le type Nonsigné32 doit alors être utilisé à la place de Nonsigné64.

Les opérations (sur les PIB) prises en charge par la SPPI s’appliquent exclusivement aux PRC. Chaque PRC est modélisée comme une structure tabulaire, c’est-à-dire, un tableau. Chaque instance d’une PRC particulière a le même ensemble d’attributs. L’ensemble des attributs qui appartiennent à chaque instance d’une PRC particulière est modélisé comme une rangée du tableau. Noter qu’une PRC ne doit pas avoir plus de 127 attributs. L’usage de sous identifiants (pour les attributs de la PRC) au delà de 127 (c’est-à-dire 128 et après) est réservée pour la transposition de PIB en MIB (voir l’Appendice A). Les PRC qui exigent plus de 127 attributs doivent utiliser la clause AUGMENTE pour augmenter la PRC qui contient les 127 attributs initiaux pour ajouter les attributs supplémentaires. La définition des classes d’approvisionnement est formalisée en utilisant la macro TYPE-D’OBJET pour définir :

- les caractéristiques de chaque instance d’une PRC particulière, appelée la définition de rangée.

Dans la définition de tableau, la clause SYNTAXE a la forme : SEQUENCE DE <EntréeType> où <EntréeType> se réfère au type SEQUENCE de ses définitions d’attribut. Dans la définition de rangée, la clause SYNTAXE a la forme : <EntréeType> où <EntréeType> est un type SEQUENCE défini comme suit : <EntréeType> ::= SEQUENCE { <type1>, ... , <typeN> } où il y a un <type> pour chaque attribut, et chaque <type> est de la forme : <descripteur> <syntaxe> où <descripteur> est le descripteur qui désigne un attribut, et <syntaxe> a la valeur de cette clause SYNTAXE de l’attribut, sauf que les informations de sous type et les valeurs désignées pour les entiers énumérés ou les bits désignés pour la construction BITS, sont omis de <syntaxe>.

La clause PIB-ACCES doit être présente pour une définition de tableau de PRC, et ne doit être présente pour aucune autre définition de TYPE-D’OBJET. La clause PIB-ACCES définit quelle sorte d’accès est appropriée pour la PRC :

- la valeur "installe" est utilisée pour indiquer une PRC qu’un PDP peut installer dans le PEP comme informations d’approvisionnement.

- la valeur "notifie" est utilisée pour indique une PRC pour laquelle le PEP doit notifier au PDP toutes ses instances et valeurs d’attributs de cette PRC.

- la valeur "installe-notifie" est utilisée pour indiquer le type non courant de PRC qui a les deux caractéristiques "installe" et "notifie".

- la valeur "rapport-seul" est utilisée pour indiquer une PRC qui n’a ni la caractéristique "installe" ni la caractéristique "notifie". Cependant, de telles instances de PRC peuvent être incluses dans des rapports synchrones/asynchrones générés par le PEP. (Noter que les PRC qui ont les caractéristiques "installe" et/ou "notifie" peuvent aussi être incluses dans des rapports générés par le PEP.)

La clause INSTALLE-ERREURS, qui peut facultativement être présente pour une définition de tableau de PRC, et doit être absente autrement, fait la liste d’une ou plusieurs raisons éventuelles de rejet d’installation ou de retrait d’une instance de la PRC. Chaque raison consiste en une énumération de nombres désignés, où les nombres représentent un code d’erreur spécifique d’une PRC à utiliser dans un message de protocole COPS, comme le sous code d’erreur, avec le code d’erreur réglé à priSpecificError (voir la [RFC3084]). La sémantique de chaque énumération de nombres désignés devrait être décrite dans la clause DESCRIPTION de la PRC.

Les nombres énumérés dans une INSTALLE-ERREURS doivent être supérieurs à zéro et inférieurs à 65 536. Si cette clause n’est pas présente, un installe/retire peut quand même échouer, mais aucune erreur spécifique de PRC n’est disponible pour être rapportée.

La clause PIB-INDEX, qui doit être présente pour une définition de rangée (sauf si une clause AUGMENTE ou ETEND est présente à la place) et doit être absente autrement, définit les informations d’identification pour les instances de la PRC.

La clause PIB-INDEX comporte exactement un descripteur. Ce descripteur spécifie un attribut (normalement, mais pas nécessairement, de la même PRC) qui est utilisé pour identifier une instance de cette PRC. Il est EXIGÉ que la syntaxe de cet attribut soit InstanceId (une convention textuelle avec une syntaxe sous-jacente de Nonsigné32) et n’a pas d’autre sémantique que son utilisation pour identifier l’instance de PRC. L’IDENTIFIANT-D’OBJET qui identifie une instance d’une PRC est formé en ajoutant un sous identifiant à l’OID qui identifie la définition de rangée de cette PRC. La valeur du sous identifiant supplémentaire est la valeur de cette instance de l’attribut spécifié dans la clause INDEX.

Noter que la SPPI ne permet pas l’usage du mot-clé IMPLICITE dans une clause PIB-INDEX.

La clause INDEX est facultativement présente si une clause PIB-INDEX est présente, et doit être absente autrement. Si elle est présente, la clause INDEX peut contenir un nombre quelconque d’attributs, et n’est utilisée que par la conversion algorithmique d’une PIB en MIB (voir l’Appendice A).

Un mot-clé IMPLICITE peut être présent dans une clause INDEX si on le désire.

La clause AUGMENTE, qui ne doit être présente que dans les définitions de rangées, est une solution de remplacement de la clause PIB-INDEX et de la clause ETEND. Chaque définition de rangée a exactement une des clauses PIB-INDEX, AUGMENTE, ou ETEND.

Une définition de rangée qui a une clause PIB-INDEX est appelée une définition de rangée de base. Une définition de rangée qui a une clause AUGMENTE est appelée une augmentation de rangée, où la clause AUGMENTE désigne la définition de rangée de base qui est augmentée par cette augmentation de rangée. (Donc, une augmentation de rangée ne peut pas être elle-même augmentée.)

Une PRC dont la définition de rangée est une augmentation de rangée est appelée une PRC d’augmentation. Les instances d’une PRC d’augmentation sont identifiées conformément à la clause PIB-INDEX de la définition de rangée de base désignée dans la clause AUGMENTE. De plus, les instances d’une PRC d’augmentation existent conformément à la même sémantique que les instances de la PRC qu’elle augmente. À ce titre, lorsque une instance d’une PRC est installée ou retirée, une instance de chaque PRC qui l’augmente est aussi installée ou retirée (pour les détails, voir la [RFC3084]).

La clause ETEND, qui ne doit être présente que dans les définitions de rangée, est une solution de remplacement à la clause PIB-INDEX et à la clause AUGMENTE. Chaque définition de rangée a exactement une clause PIB-INDEX, ou une clause AUGMENTE, ou une clause ETEND.

Une définition de rangée qui a une clause ETEND est appelée une augmentation de rangée éparse, où la clause ETEND désigne la définition de rangée qui est augmentée de façon éparse par cette augmentation de rangée éparse. La rangée augmentée de façon éparse peut être une définition de rangée de base, ou une autre augmentation de rangée éparse.

Une PRC dont la définition de rangée est une augmentation de rangée éparse est appelée une PRC à augmentation éparse. Les instances d’une PRC à augmentation éparse sont identifiées conformément à la clause PIB-INDEX de la définition de rangée désignées dans la clause ETEND de la PRC à augmentation éparse.

Une instance d’une PRC à augmentation éparse ne peut exister que si existe une instance correspondante de la PRC qui augmente de façon éparse. À ce titre, lorsque une instance d’une PRC est supprimée, une instance de toute PRC qui l’augmente de façon éparse est aussi supprimée. Cependant, une instance d’une PRC à augmentation éparse n’a pas besoin d’exister lorsque il existe une instance correspondante de la PRC à augmentation éparse. Donc, une instance d’une PRC à augmentation éparse peut être installée au même moment que l’installation de l’instance correspondante de la PRC qu’elle augmente de façon éparse, ou ensuite, et elle peut être supprimée avant la suppression de cette instance. Ainsi, les instances d’une PRC à augmentation éparse doivent être installées explicitement, mais elles sont supprimées soit implicitement (via la suppression de la PRI augmentée) soit explicitement. Lorsque une PRC à augmentation éparse est installée, les deux instances, l’instance de la PRC augmentée de façon éparse et l’instance de la PRC à augmentation éparse doivent être envoyées dans un seul message COPS.

Lorsque on définit les informations d’identification d’instance pour une PRC :

- Si il y a une correspondance biunivoque entre les instances de cette PRC et les instances d’une PRC existante, la clause AUGMENTE devrait être utilisée.

- Autrement, si il y a une relation distante entre les instances de cette PRC et les instances d’une PRC existante (c’est-à-dire, si il y a une correspondance de un à zéro entre les instances d’une PRC à augmentation éparse et les instances de la PRC qui l’augment de façon éparse) une clause ETEND devrait alors être utilisée.

- Autrement, une clause PIB-INDEX devrait être utilisée qui désigne son propre attribut InstanceId.

La clause UNICITÉ, qui est facultativement présente pour une définition de rangée, énumère une ensemble de zéro, un ou plusieurs attributs de PRC, pour lesquels deux instances de la PRC ne peuvent pas avoir le même ensemble de valeurs. L’ensemble spécifié d’attributs fournit un ensemble nécessaire et suffisant de valeurs par lesquelles identifier une instance de cette PRC. L’attribut contenu dans la clause PIB-INDEX peut n’être pas présent dans la clause UNICITÉ. Par définition, un attribut peut ne pas apparaître plus d’une fois dans une clause UNICITÉ. Une clause UNICITÉ qui contient zéro attribut indique qu’il est possible que deux instances de la PRC aient des valeurs identiques pour tous les attributs excepté, bien sûr, pour celui désigné dans la clause PIB-INDEX.

Si une PRC et la PRC qui l’augmente de façon éparse ont toutes deux une clause UNICITÉ, la contrainte UNICITÉ pour les instances de chaque PRC DOIT être appliquée conformément à la clause UNICITÉ dans la définition de PRC correspondante. Noter qu’une PRC à augmentation éparse peut donc outrepasser la clause UNICITÉ de la PRC qu’elle augmente de façon éparse.

Bien que la clause UNICITÉ soit facultative, son inclusion est recommandée chaque fois qu’elle fournit des informations utiles.

La clause PIB-REFERENCES, qui doit être présente pour tout attribut qui a la SYNTAXE de ReferenceId, et doit être absente autrement, désigne la PRC dont une instance est référencée par l’attribut ReferenceId. Pour un exemple d’utilisation de la clause PIB-REFERENCES, voir l’Appendice B.

La clause PIB-TAG, qui doit être présente pour un attribut qui a la SYNTAXE TagReferenceId, et doit être absente autrement, est utilisée pour indiquer que cet attribut fait référence à une "liste d’étiquettes" des instances d’une autre PRC. Une telle liste d’étiquettes (d’un concept similaire à l’usage du même terme dans la [RFC2573]) est formée par toutes les instances de l’autre PRC qui ont la même valeur (étiquette) d’un attribut particulier de cette autre PRC. L’attribut particulier de l’autre PRC, qui doit avoir la SYNTAXE TagId, est désigné dans la clause PIB-TAG. Pour un exemple d’usage de la clause PIB-TAG, voir l’Appendice B.

La macro IDENTITÉ D’OBJET est utilisée dans les modules de PIB pour définir des informations sur une allocation d’IDENTIFIANT D’OBJET.

Pour les besoins de la conformité, il est utile de définir un groupe de conformité comme une collection de PRC en rapports et de leurs attributs. La macro GROUPE-D’OBJET définit (directement) la collection des attributs qui appartiennent à un groupe de conformité. Comme chaque attribut inclus dans la collection appartient à une PRC, la collection des PRC en rapports qui appartiennent à un groupe de conformité est aussi spécifiée (indirectement) comme l’ensemble des PRC auxquelles appartiennent les attributs inclus.

La clause OBJETS, qui doit être présente, est utilisée pour spécifier chaque attribut contenu dans le groupe de conformité. Chacun des attributs spécifiés doit être défini dans le même module de PIB que celui où apparaît la macro GROUPE-D’OBJET.

Il est exigé que tout nouvel attribut défini dans un module de PIB soit contenu dans au moins un groupe de conformité. Cela évite l’erreur courante d’ajouter un nouvel attribut à un module et d’oublier d’ajouter le nouvel attribut à un groupe.

La macro CONFORMITÉ DE MODULE est utilisée pour porter un ensemble minimum d’exigences par rapport à la mise en œuvre d’un ou plusieurs modules de PIB.

Une exigence pour tous les modules de PIB "standard" est qu’une spécification CONFORMITÉ DE MODULE correspondante soit aussi définie, dans le même module ou dans un module d’accompagnement.

La clause MODULE, qui doit être présente, est utilisée de façon répétée pour désigner chaque module de PIB pour lequel une exigence de conformité doit être spécifiée. Chaque module de PIB est désigné par son nom de module, et facultativement aussi son IDENTIFIANT-D’OBJET associé. Le nom de module peut être omis lorsque l’invocation CONFORMITÉ DE MODULE survient au sein d’un module de PIB, pour se référer au module de PIB qui la renferme.

La clause GROUPES-OBLIGATOIRES, qui n’est pas nécessairement présente, désigne le ou les groupes de conformité au sein du module de PIB correspondant qui sont de mise en œuvre inconditionnellement obligatoire. Si un agent revendique la conformité au module de PIB, il doit alors mettre en œuvre chacun des attributs (et donc les PRC auxquelles ils appartiennent) au sein de chaque groupe de conformité énuméré.

La clause GROUPE, qui n’est pas nécessairement présente, est utilisée de façon répétée pour désigner chaque groupe de conformité qui es conditionnellement obligatoire pour la conformité au module de PIB. La clause GROUPE peut aussi être utilisée pour désigner des groupes inconditionnellement facultatifs. Un groupe désigné dans une clause GROUPE doit être absent des clauses GROUPES-OBLIGATOIRES correspondantes.

Les groupes conditionnellement obligatoires n’incluent ceux qui sont obligatoires que si un protocole particulier est mis en œuvre, ou si un autre groupe est mis en œuvre. La DESCRIPTION d’une clause GROUPE spécifie les conditions dans lesquelles le groupe est conditionnellement obligatoire.

Un groupe qui n’est désigné ni dans une clause GROUPES-OBLIGATOIRES ni dans une clause GROUPE, est inconditionnellement facultatif pour la conformité au module de PIB.

La clause OBJET, qui n’est pas nécessairement présente, est utilisée de façon répétée pour spécifier chaque attribut pour lequel la conformité a été précisée par rapport à la définition du module de PIB par une exigence supplémentaire. L’attribut doit être présent dans un des groupes de conformité désigné dans la clause GROUPES-OBLIGATOIRES ou la clause GROUPE correspondantes.

Par définition, chaque attribut spécifié dans une clause OBJET suit une clause MODULE qui désigne le module de PIB dans lequel cet attribut est défini. Donc, l’utilisation d’une déclaration IMPORTE pour spécifier d’où sont importés de tels attributs, est redondante et n’est pas exigée dans un module de PIB.

La clause SYNTAXE, qui n’est pas nécessairement présente, est utilisée pour préciser une SYNTAXE pour l’attribut désigné dans la clause OBJET correspondante. La syntaxe précisée est le niveau minimum de prise en charge nécessaire pour que cet attribut soit conforme.

La clause PIB-MIN-ACCES, qui n’est pas nécessairement présente, est utilisée pour définir le niveau minimal d’accès pour l’attribut désigné dans la clause OBJET correspondante. Si cette clause est absente, le niveau minimal d’accès est le même que le niveau maximal spécifié dans la clause PIB-ACCES de l’invocation correspondante de la macro TYPE-D’OBJET. Si elle est présente, cette clause doit spécifier un sous ensemble de l’accès spécifié dans la clause PIB-ACCES correspondante, où "installe" est un sous ensemble de "installe-notifie", "notifie" est un sous ensemble de "installe-notifie", et "non-accessible" est un sous ensemble de toutes les autres valeurs.

Une mise en œuvre est conforme si le niveau d’accès qu’elle fournit est le même ou un sur ensemble du niveau minimal dans la macro CONFORMITÉ DE MODULE et le même ou un sous ensemble du niveau maximal dans la clause PIB-ACCES.

Lors de la conception d’un module de PIB, il est souvent utile de définir de nouveaux types de données similaires à ceux définis dans la SPPI. Par rapport à un type défini dans la SPPI, chacun de ces nouveaux types a un nom différent, une syntaxe similaire, et une sémantique spécifique. Ces types nouvellement définis sont appelés des conventions textuelles, et sont utilisés pour la commodité du lecteur humain du module de PIB.

Les attributs définis en utilisant une convention textuelle sont toujours codés au moyen des règles qui définissent leur type sous-jacent.

La macro CONVENTION TEXTUELLE est utilisée pour porter la syntaxe et la sémantique associées à une convention textuelle. On devrait noter que l’expansion de la macro CONVENTION TEXTUELLE est quelque chose qui arrive conceptuellement durant la mise en œuvre et non durant le lancement.

Le nom d’une convention textuelle doit consister en une ou plusieurs lettres ou chiffres, le caractère initial étant une majuscule. Le nom ne doit pas entrer en conflit avec un des mots réservés énumérés au paragraphe 5.2, ne devrait pas comporter que des lettres majuscules, et ne devra pas excéder 64 caractères. (Cependant, les noms de plus de 32 caractères ne sont pas recommandés.) Le trait d’union n’est pas admis dans le nom d’une convention textuelle (sauf utilisé dans les modules d’information convertis de SMIv1 qui permettait les traits d’union dans les allocations de type ASN.1). De plus, tous les noms utilisés pour les conventions textuelles définis dans tous les modules de PIB "standard" devront être uniques.

La clause CONSEIL-D’AFFICHAGE (DISPLAY-HINT), qui n’est pas nécessairement présente, donne un conseil sur la façon dont la valeur d’une instance d’un objet qui a la syntaxe définie en utilisant cette convention textuelle pourrait être affichée. La clause CONSEIL-D’AFFICHAGE ne doit pas être présente si la convention textuelle est définie avec une syntaxe de IDENTIFIANT D’OBJET, ou toute syntaxe énumérée (BITS ou ENTIER). Déterminer si il y a un sens pour d’autres types de syntaxe dépend de la définition spécifique de la convention textuelle.

Les règles pour la spécification du format du conseil sont les mêmes que celles spécifiée au paragraphe 3.1 de la [RFC2579].

La clause SYNTAXE, qui doit être présente, définit une structure de données abstraite correspondant à la convention textuelle. La structure de données doit être soit un type de base (voir la clause SYNTAXE d’une macro TYPE-D’OBJET) soit la construction BITS. Noter que cela signifie que la clause SYNTAXE d’une convention textuelle ne peut pas se référer à une convention textuelle définie précédemment.

La clause SYNTAXE d’une macro CONVENTION TEXTUELLE peut être sous typée de la même façon que la clause SYNTAXE d’une macro TYPE-D’OBJET.

Les PIB pourront être révisées lorsque l’expérience de leur mise en œuvre y invitera. Cependant, les changements qui pourraient causer l’interruption de l’interopérabilité entre la PIB précédente et la PIB révisée ne sont par permis.

Pour tout changement, l’invocation de la macro IDENTITÉ-DE-MODULE doit être mise à jour pour inclure des informations sur la révision, en particulier la mise à jour de la clause DERNIERE-MISE-A-JOUR, l’ajout d’une paire de clauses REVISION et DESCRIPTION, et effectuer tout changement nécessaire aux clauses existantes, y compris les clauses ORGANISATION et CONTACT-INFO.

Noter que toute définition contenue dans une PIB existante est disponible pour être importée par toute autre PIB, et est référencée comme une clause IMPORTE via le nom du module de PIB. Donc, un nom de module de PIB ne devrait pas être changé. Les définitions ne devraient pas être déplacées d’une PIB à une autre.

Noter aussi que les définitions obsolètes ne doivent pas être retirées des modules de PIB car leurs descripteurs peuvent encore être référencés par d’autres modules de PIB, et l’IDENTIFIANT D’OBJET utilisé pour les désigner ne doit jamais être réalloué. La clause ETEND/AUGMENTE devrait être utilisée pour étendre les définitions précédentes en fonction des informations à représenter.

- Des PRC supplémentaires peuvent être ajoutées à une PIB ou à une existante qui est déconseillée.

- Des attributs peuvent être ajoutés à, ou déconseillés de, une PRC existante. Noter qu’une valeur ASN.1 du type correct ou une valeur ASN.1 NUL doit être envoyée même pour des attributs déconseillés pour conserver l’interopérabilité. Les nouveaux attributs doivent être ajoutés à la suite de ceux existants.

- Une PRC existante peut être étendue ou augmentée par une nouvelle PRC définie dans une autre PIB (peut-être spécifique d’une entreprise).

.Des énumérations supplémentaires de nombres désignés peuvent être ajoutées à une clause CATEGORIES-SUJET.

Si un changement non rédactionnel est fait à une clause d’une allocation d’objet, la valeur de l’IDENTIFIANT D’OBJET associée à cette allocation d’objet doit alors aussi être changée, avec son descripteur associé. Noter que le sous identifiant maximum pour les attributs de PRC est 127 (voir le paragraphe 7.1.8).

- Une clause SYNTAXE contenant une énumération de ENTIER peut avoir de nouvelles énumérations ajoutées ou des étiquettes existantes changées. De même, des bits désignés peuvent être ajoutés ou des étiquettes existantes changées pour la construction BITS.

- La valeur d’une clause SYNTAXE peut être remplacée par une convention textuelle, pourvu que la convention textuelle soit définie pour utiliser le même type de primitive ASN.1, qu’elle ait le même ensemble de valeurs, et une sémantique identique.

- Une valeur de clause STATUT de "actuel" peut être révisée en "déconseillé" ou "obsolète". De même, une valeur de clause STATUT de "déconseillé" peut être révisée en "obsolète". Lorsque on fait un tel changement, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.

- Des éclaircissements et des informations supplémentaires peuvent être incluses dans la clause DESCRIPTION.

- Une clause INSTALLE-ERREURS peut être ajoutée ou une clause INSTALLE-ERREURS existante peut avoir des erreurs supplémentaires définies.

- Une PRC peut être augmentée en ajoutant de nouveaux objets à la fin de la rangée, et en faisant la mise à jour correspondante à la définition de SEQUENCE.

- Des objets entièrement nouveaux peuvent être définis, désignés avec des valeurs d’IDENTIFIANT D’OBJET précédemment non allouées.

Autrement, si la sémantique d’un objet précédemment défini a changé (c’est-à-dire, si un changement non rédactionnel est fait à toute clause autre que celles spécifiquement permises ci-dessus) la valeur de l’IDENTIFIANT D’OBJET associé à cet objet doit alors aussi être changée. Noter que changer le descripteur associé à un objet existant est considéré comme un changement sémantique, car ces chaînes peuvent être utilisées dans une déclaration IMPORTE.

Comme la SPPI est modélisée sur la SMI, une PIB peut être transposée algorithmiquement en une MIB. Cette transposition est réalisée au moyen des règles suivantes :

- Changer l’OID alloué à l’IDENTITÉ-DE-MODULE pour une valeur différente.

- Modifier les noms de module de toutes les références externes des modules de PIB en ajoutant "-MIB" à chacun de ces noms de module.

- Pour chaque définition de PRC, si une clause INDEX est absente, changer le mot-clé "PIB-INDEX" en "INDEX" ; autrement, supprimer la clause PIB-INDEX.

- Supprimer toutes les clauses suivantes : PIB-ACCES, PIB-REFERENCES, PIB-TAG, UNICITÉ, INSTALLE-ERREURS, et CATEGORIES-SUJET.

- Changer toutes les clauses PIB-MIN-ACCES en clauses MIN-ACCES, et modifier "installe" et "installe-notifie" en "lire-créer", et "notifie" en "lecture-seule".

- Ajouter une clause MAX-ACCES à chaque TYPE-D’OBJET. Pour chaque définition de tableau et de rangée, le MAX-ACCES est "non-accessible". Pour chaque attribut qui est dans la clause INDEX, le MAX-ACCES est "non-accessible". Pour les attributs restants, le MAX-ACCES est "lire-créer".

- Ajouter un attribut colonnaire de type RowStatus avec un descripteur et une DESCRIPTION appropriée. Le descripteur peut être formé en ajoutant les neuf caractères "RowStatus" à la fin du descripteur de la PRC (tronqué si nécessaire pour éviter que le descripteur résultant soit trop long). Un sous identifiant au delà de 127 (c’est-à-dire, 128 et au-delà) peut être utilisé comme OID pour cet attribut colonnaire.

- Modifier toute clause SYNTAXE qui a un type de données de base non admis dans la SMI, soit en un type de données valide dans la SMI, soit en omettant la définition de TYPE-D’OBJET ou de CONVENTION-TEXTUELLE et toutes les références à elle. Comme on ne voir pas clairement (pour le moment) quel est le meilleur type de données de SMI à utiliser, la conversion DEVRAIT fournie une option configurable permettant un choix au moins entre :

- le convertir en une CHAINE D’OCTETS de la taille pertinente. Précisément, cette option transposerait Entier64 et Nonsigné64 en CHAINE D’OCTETS (TAILLE(8)), ou

- transposer Entier64 et Nonsigné64 en Compteur64 (même si cela pose le problème de représentation de nombres négatifs, et d’une sémantique de compteur indésirable.)

L’exemple suivant montre l’utilisation des clauses PIB-REFERENCES et PIB-TAG.

Dans cet exemple, la clause PIB-REFERENCES est utilisée par l’attribut qosIfDscpMapQueue pour indiquer de quelle PRC il référence une instance, et de même, par l’attribut qosIfDscpMapThresh.

La PRC qosIfDscpMapTable a une instance pour chaque DSCP d’une "transposition" particulière, mais il n’y a pas de PRC définie pour une transposition elle-même ; une transposition consiste plutôt en toutes les instances de qosIfDscpMapTable qui ont la même valeur de qosIfDscpMapMapId. C’est-à-dire, une liste d’étiquettes est formée par toutes les instances de qosIfDscpMapTable qui ont la même valeur de qosIfDscpMapMapId. Cette liste d’étiquettes est référencée par l’attribut qosIfDscpAssignDscpMap, et son utilisation de la clause PIB-TAG l’indique.

DESCRIPTION : "Transposition DSCP qui est appliquée aux interfaces de type qosIfDscpAssignName qui ont une combinaison de rôle de qosIfDscpAssignRoles."

DESCRIPTION : "Alloue des valeurs DSCP aux files d’attente et aux seuils pour une transposition DSCP arbitraire. Cette transposition peut alors être allouée à diverses paire d’interface et de combinaison de rôle."

DESCRIPTION : "Entier qui identifie la transposition DSCP à laquelle appartient cette PRI."

DESCRIPTION : "Cet attribut transpose le DSCP spécifié par qosIfDscpMapDscp en la file d’attente identifiée par qosIfQueuePrid dans qosIfQueueTable. Pour une certaine transposition DSCP, toutes les files d’attente doivent appartenir à un seul ensemble de files d’attente."

DESCRIPTION : "Cet attribut transpose le DSCP spécifié par qosIfDscpMapDscp en le seuil identifié par qosIfThresholdId dans qosIfThresholdTable. L’ensemble de seuils auquel appartient ce seuil doit être alloué à la file d’attente spécifiée par qosIfDscpMapQueue."

Le présent document définit un langage pour définir les informations d’approvisionnement. Le langage n’a par lui-même pas d’impact sur la sécurité de l’Internet.

La racine de la sous arborescence administrée par l’Autorité d’allocation des numéros de l’Internet (IANA) pour l’Internet est :

C’est-à-dire que la sous arborescence Internet de IDENTIFIANT D’OBJET commence par le préfixe : 1.3.6.1.

Plusieurs branches de cette sous arborescence sont utilisées pour la gestion de réseau :

La sous arborescence mgmt(2) est utilisée pour identifier les objets "standard".

comme racine des PIB définies comme étant portées sur la [RFC3084]. Cet identifiant d’objet est une allocation de haut niveau qui doit être enregistrée par l’IANA. Les identifiants d’objet racine pour les futures PIB "en cours de normalisation" devront aussi être enregistrés et DOIVENT utiliser les identifiants d’objet sous cet OID. Une PIB en cours de normalisation ne peut recevoir un OID de l’IANA que si la PIB est approuvée par l’IESG comme document "en cours de normalisation". Des PIB expérimentales et d’entreprise DOIVENT être définies sous les identifiants d’objet respectivement "experimental" et "enterprises".

Le module de PIB "copsPrSppiTc" est défini dans le présent document comme un module standard qui a donc besoin d’une allocation de sous identifiant sous l’OID "pib" de l’IANA.

Les CATEGORIES DE SUJET de SPPI sont transposées en types de client COPS. Les Considérations relatives à l’IANA pour CATEGORIES DE SUJET suivent les mêmes exigences que celles spécifiées dans les Considérations relatives à l’IANA pour les types de client COPS de la [RFC2748]. Donc, une nouvelle PIB peut définir un nouveau type de client COPS dans l’espace "standards", "experimental" ou "enterprise", et lorsque elle aura été approuvée, cela signifiera qu’un nouveau type de client COPS aura été alloué. L’IANA doit par conséquent mettre à jour le registre des types de client COPS (lorsque applicable comme décrit dans les Considérations relatives à l’IANA de la [RFC2748]).

[ASN1] International Organization for Standardization. International Standard 8824, "Information processing systems -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1)", décembre 1987.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[RFC2573] D. Levi, P. Meyer, B. Stewart, "Applications SNMP", avril 1999. (Obsolète, voir RFC3413) (D.S.)

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

[RFC2851] M. Daniele et autres, "Conventions textuelles pour les adresses réseau Internet", juin 2000. (Obs., voir RFC4001) (P.S.)

[RFC3084] K. Chan et autres, "Utilisation de COPS pour l'approvisionnement de politique (COPS-PR)", mars 20010 (P.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 y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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

Groupe de travail Réseau	K. McCloghrie & M. Fine, Cisco Systems
Request for Comments : 3159	J. Seligson & K. Chan, Nortel Networks
Catégorie : En cours de normalisation	S. Hahn & R. Sahita, Intel
	A. Smith, Allegro Networks
	F. Reichmeyer, PFN
Traduction Claude Brière de L'Isle	août 2001

Keith McCloghrie	Michael Fine	John Seligson
Cisco Systems, Inc.	Cisco Systems, Inc.	Nortel Networks, Inc.
170 West Tasman Drive	170 West Tasman Drive	4401 Great America Parkway
San Jose, CA 95134-1706	San Jose, CA 95134-1706 USA	Santa Clara, CA 95054 USA
USA	téléphone : +1 408 527 8218	téléphone : +1 408 495 2992
téléphone : +1 408 526 5260	mél : mfine@cisco.com	mél : jseligso@nortelnetworks.com
mél : kzm@cisco.com

Kwok Ho Chan	Scott Hahn	Ravi Sahita
Nortel Networks, Inc.	Intel	Intel
600 Technology Park Drive	2111 NE 25th Avenue	2111 NE 25th Avenue
Billerica, MA 01821 USA	Hillsboro, OR 97124 USA	Hillsboro, OR 97124 USA
téléphone : +1 978 288 8175	téléphone : +1 503 264 8231	téléphone : +1 503 712 1554
mél : khchan@nortelnetworks.com	mél : scott.hahn@intel.com	mél : ravi.sahita@intel.com

Andrew Smith	Francis Reichmeyer
Allegro Networks	PFN Inc.
6399 San Ignacio Ave.	University Park at MIT
San Jose, CA 95119 USA	26 Landsdowne Street
Fax : +1 415 345 1827	Cambridge, MA 02139 USA
mél : andrew@allegronetworks.com	téléphone : +1 617 494 9980
	mél : franr@pfn.com