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	

Structure des informations d’approvisionnement de politique (SPPI)

Statut de ce mémoire
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.

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

Résumé
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.

Conventions utilisées dans ce document
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

1.	Utilisation de la SMI

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.

1.1	Traduction de terminologie

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

1.2	Généralités

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.

2.	Structure de cette spécification

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.

3.	Définitions

DÉFINITIONS COPS-PR-SPPI ::= DÉBUT

IMPORTE  	NomDObjet, SimpleSyntax, ExtUTCTime, mgmt
                DE SNMPv2-SMI;

-- Racine pour les définitions de PIB

IDENTIFIANT D’OBJET pib   ::= { mgmt 2 }

-- Définitions pour les modules de PIB

MACRO IDENTITÉ DE MODULE ::= DÉBUT
NOTATION DE TYPE  ::=
       SubjectPart 	-- nouveau
       "DERNIERE-MISE-A-JOUR" valeur( ExtUTCTime)
       "ORGANISATION" Texte
       "CONTACT-INFO" Texte
       "DESCRIPTION" Texte
       RevisionPart

NOTATION DE VALEUR  ::= valeur(IDENTIFIANT D’OBJET VALEUR)

SubjectPart ::=	-- nouveau
        "CATEGORIES-SUJET" "{" Categories "}"
	-- Voir la Section Considérations relatives à l’IANA
Categories ::= 	-- nouveau
       CategoryIDs | "tous"
CategoryIDs ::= 	-- nouveau
       CategoryID | CategoryIDs "," CategoryID
CategoryID ::=  	-- nouveau
       identifiant "(" nombre ")"  	-- nombre est positif

RevisionPart ::=  Revisions | vide
Revisions ::= Revision | Revisions Revision
Revision ::=
       "REVISION" valeur(Met-à-jour ExtUTCTime)
       "DESCRIPTION" Texte	-- chaîne de caractères comme défini dans la [RFC2578]
Texte ::= valeur(IA5String)
FIN

--

MACRO IDENTITÉ D’OBJET ::= DÉBUT
NOTATION DE TYPE  ::=
       "STATUT" Statut
       "DESCRIPTION" Texte
       ReferPart

NOTATION DE VALEUR ::=
       valeur(VALEUR D’IDENTIFIANT D’OBJET)

Statut ::= "actuel" | "déconseillé" | "obsolète"

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

Texte ::= valeur(IA5String)
FIN

-- Syntaxe des attributs

-- les "types de base" définis ici sont :
--  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.

ObjectSyntax ::=
    CHOIX {
      simple
          SimpleSyntax,	-- noter que les SEQUENCE pour les définitions de tableau et de rangées ne sont pas mentionnées ici.
      niveau-application
          ApplicationSyntax
    }

-- Types au niveau de l’application

ApplicationSyntax ::=
    CHOIX {
        valeur-ipAdresse
            IpAdresse,
        valeur-timeticks
            TimeTicks,
        valeur-arbitraire
            Opaque,
        valeur-nonsigné-entier
            Nonsigné32,
        valeur-grand-entier	-- nouveau
            Entier64,
        valeur-grand-nonsigné-entier	-- nouveau
            Nonsigné64
    }

-- les cinq types suivants sont copiés de la SMI
-- indistinguable de ENTIER, mais n’a jamais besoin de plus de 32 bits pour une représentation de complément à deux.

Entier32 ::=	-- (c’est un type étiqueté pour des raisons historiques)
        ENTIER (-2  147  483  648 à 2  147  483  647)
IpAdresse ::=
    [APPLICATION 0]
       CHAINE D’OCTETS IMPLICITE (TAILLE (4))
-- ******* CETTE DÉFINITION DE TYPE EST DÉCONSEILLÉE *******
-- 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].

Nonsigné32 ::=	-- une quantité de 32 bits non signée
    [APPLICATION 2]
       ENTIER IMPLICITE (0 à 4  294  967  295)

TimeTicks ::=	-- centaines de secondes depuis un instant donné
    [APPLICATION 3]
        ENTIER IMPLICITE (0 à 4  294  967  295)

-- seulement pour la rétro compatibilité
Opaque ::=
    [APPLICATION 4]
        CHAINE D’OCTETS IMPLICITE

-- Les deux types suivants ne sont pas présents dans la SMI.

Entier64 ::=
    [APPLICATION 10]
        ENTIER IMPLICITE (-9  223  372  036  854  775  808 à 9  223  372  036  854  775  807)

Nonsigné64 ::=
    [APPLICATION 11]
        ENTIER IMPLICITE (0 à 18  446  744  073  709  551  615)

-- Définitions pour les classes d’approvisionnement et leurs attributs
-- (Les différences avec la SMI sont notées dans les commentaires ASN.1)

MACRO TYPE D’OBJET ::=
DÉBUT
NOTATION DE TYPE  ::=
                  "SYNTAXE" Syntaxe
                  UnitsPart
                  "PIB-ACCESS" Accès 	-- modifié
                  PibReferencesPart  	-- nouveau
                  PibTagPart   	-- nouveau
                  "STATUT" Statut
                  "DESCRIPTION" Texte
                  ErrorsPart    	-- nouveau
                  ReferPart
                  IndexPart   	-- modifié
                  MibIndexPart  	-- modifié
                  UniquePart   	-- nouveau
                  DefValPart

NOTATION DE VALEUR ::=
                  valeur(VALEUR NomDObjet)

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
                   type | "BITS" "{" NamedBits "}"

NamedBits ::= NamedBit | NamedBits "," NamedBit

NamedBit ::=  identifiant "(" nombre ")" 	-- nombre est non négatif

UnitsPart ::= "UNITÉS" texte | vide

Accès ::=  	-- modifié
                  "installe" | "notifie" | "installe-notifie" | "rapport-seul"

Statut ::= "actuel" | "déconseillé" | "obsolète"

ErrorsPart ::=  	-- nouveau
                  "INSTALL-ERRORS" "{" Erreurs "}" | vide

Erreurs ::=    	-- nouveau
                  Erreur | Erreurs "," Erreur
Erreur ::=    	-- nouveau
                  identifiant "(" nombre ")" 	-- nombre est positif

ReferPart ::= "REFERENCE" texte | vide

IndexPart ::=
                  "PIB-INDEX" "{" Index "}"  	-- nouveau
                | "AUGMENTE"  "{" Entrée "}"
                | "ÉTEND"   "{" Entrée "}" 	-- nouveau
                | vide
Index ::= valeur(NomDObjet)	-- invocation du TYPE-D’OBJET correspondant
Entrée ::= valeur(NomDObjet)	-- utilise la valeur de INDEX de l’invocation de TYPE-D’OBJET correspondant.
MibIndexPart ::= "INDEX"   "{" IndexTypePart "}" | vide
IndexTypePart ::= IndexTypes | IndexTypes "," ImpliedIndex | ImpliedIndex
IndexTypes ::= Index | IndexTypes "," Index
ImpliedIndex ::= "IMPLICITE" Index

PibReferencesPart ::=	- à utiliser avec le TC ReferenceId
                  "PIB-REFERENCES" "{" Entrée "}" | vide

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

Attr ::=  valeur(NomDObjet)	-- spécifie un attribut

UniquePart ::=   	-- nouveau
                  "UNICITÉ"    "{" UniqueTypes "}"
                | "UNICITÉ"    "{" "}"
                |  vide
UniqueTypes ::= UniqueType | UniqueTypes "," UniqueType
UniqueType ::= valeur(NomDObjet)	--  invocation du TYPE-D’OBJET correspondant

DefValPart ::= "DEFVAL" "{" Defvaleur "}" | vide

Defvaleur ::= 	-- doit être valide pour le type spécifié dans la clause SYNTAXE de la même macro TYPE-D’OBJET.
                  valeur(ObjectSyntax)
                | "{" valeur des bits "}"

BitsValue ::= BitNames | vide

BitNames ::=  BitName | BitNames "," BitName

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

FIN

-- Définitions pour les groupes de conformité

MACRO GROUPE D’OBJET ::= DÉBUT
 NOTATION DE TYPE ::=
                  ObjectsPart
                  "STATUT" Statut
                  "DESCRIPTION" texte
                  ReferPart

 NOTATION DE VALEUR ::= valeur(VALEUR D’IDENTIFIANT D’OBJET)

    ObjectsPart ::= "OBJETS" "{" Objets "}"
    Objets ::= Objet | Objets "," Objet
    Objet ::= valeur(NomDObjet)

    Statut ::= "actuel" | "déconseillé" | "obsolète"
    ReferPart ::= "REFERENCE" texte | vide

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

-- Définitions pour les déclarations de conformité

MACRO MODULE DE CONFORMITÉ ::= DÉBUT
 NOTATION DE TYPE ::=
                  "STATUT" Statut
                  "DESCRIPTION" texte
                  ReferPart
                  ModulePart

NOTATION :DE VALEUR := valeur(VALEUR D’IDENTIFIANT D’OBJET)

Statut ::= "actuel" | "déconseillé" | "obsolète"
ReferPart ::= "REFERENCE" texte | vide

ModulePart ::= Modules
Modules ::= Module | Modules Module
Module ::=	-- nom du module --
              "MODULE" ModuleName
              MandatoryPart
              CompliancePart

ModuleName ::=	-- L’identifiant doit débuter par une lettre majuscule.
              identifiant ModuleIdentifier	-- Ne doit pas être vide sauf si il est contenu dans le module de MIB.
            | vide
ModuleIdentifier ::= valeur(IDENTIFIANT D’OBJET) | vide

MandatoryPart ::= "GROUPES OBLIGATOIRES" "{" Groupes "}" | vide

Groupes ::= Groupe | Groupes "," Groupe

Groupe ::= valeur(IDENTIFIANT D’OBJET)

CompliancePart ::= Compliances | vide

Compliances ::= Compliance | Compliances Compliance
Compliance ::= ComplianceGroup | Object

ComplianceGroup ::=
              "GROUPE" valeur(IDENTIFIANT D’OBJET)
              "DESCRIPTION" texte

Objet ::=
              "OBJET" valeur(NomDObjet)
              InstallSyntaxPart 	-- modifié
              AccessPart
              "DESCRIPTION" texte	-- Doit être une précision pour la clause SYNTAXE de l’objet.
InstallSyntaxPart ::= "SYNTAXE" Syntaxe | vide

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

NamedBits ::= NamedBit | NamedBits "," NamedBit

NamedBit ::= identifiant "(" nombre ")"	-- nombre est non négatif.

AccessPart ::=
                  "PIB-MIN-ACCES" Accès	-- modifié
                | vide
Accès ::=	-- modifié
                 "non-accessible" | "installe" | "notifie" | "installe-notifie" | "rapport-seul"
texte ::= valeur(IA5String) 	-- Chaîne de caractères comme défini dans la [RFC2578]
FIN

-- Définition des conventions textuelles

MACRO CONVENTION TEXTUELLE ::= DÉBUT
NOTATION DE TYPE ::=
                  DisplayPart
                  "STATUT" Statut
                  "DESCRIPTION" texte
                  ReferPart
                  "SYNTAXE" Syntaxe

NOTATION DE VALEUR ::=
                   valeur(VALEUR Syntaxe)	-- ASN.1 adapté

DisplayPart ::=
              "" texte
            | vide

Statut ::= "actuel"  | "déconseillé" | "obsolète"

ReferPart ::=
                  "REFERENCE" texte
                | vide

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
              type  | "BITS" "{" NamedBits "}"

NamedBits ::= NamedBit | NamedBits "," NamedBit

NamedBit ::=  identifiant "(" nombre ")"	-- nombre est non négatif.

FIN

COPS-PR-SPPI-TC   PIB-DEFINITIONS ::= DÉBUT

IMPORTE    Nonsigné32, IDENTITÉ-DE-MODULE, CONVENTION-TEXTUELLE, pib
                          DE COPS-PR-SPPI;

IDENTITÉ-DE-MODULE copsPrSppiTc
CATEGORIES-SUJET   { toutes }
DERNIERE MISE A JOUR "200108160000Z"
ORGANISATION "IETF RAP WG"
CONTACT-INFO "Keith McCloghrie
                  Cisco Systems, Inc.
                  170 West Tasman Drive,
                  San Jose, CA 95134-1706 USA
                  téléphone : +1 408 526 5260
                  mél : kzm@cisco.com

                  Ravi Sahita
                  Intel
                  2111 NE 25th Avenue
                  Hillsboro, OR 97124 USA
                  téléphone : +1 503 712 1554
                  mél : ravi.sahita@intel.com "
DESCRIPTION : "Module de PIB contenant un ensemble de conventions textuelles d’applicabilité générale à tous les modules de PIB."
REVISION     "200108160000Z"
DESCRIPTION : "Version initiale, publiée dans la RFC3159."
 ::= { pib 1 }

InstanceId ::= CONVENTION-TEXTUELLE
STATUT	actuel
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."
SYNTAXE :	Nonsigné32 (1  à 4  294  967  295)

ReferenceId ::= CONVENTION-TEXTUELLE
STATUT	actuel
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."
SYNTAXE :	Nonsigné32

Prid ::= CONVENTION-TEXTUELLE
STATUT	actuel
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."
SYNTAXE	IDENTIFIANT D’OBJET

TagId ::= CONVENTION-TEXTUELLE
STATUT	actuel
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."
SYNTAXE :	Nonsigné32 (1 à 4  294  967  295)

TagReferenceId ::= CONVENTION-TEXTUELLE
STATUT	actuel
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."
SYNTAXE	Nonsigné32
FIN

4.	Modules de PIB

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.

La première ligne d’un module de PIB est :

NOM DE MODULE DE PIB  PIB-DEFINITIONS ::= DÉBUT

Où NOM DE MODULE DE PIB est le nom du module.

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

4.1	Importation de définitions

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,
-	la construction BITS.

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

4.2	Mots-clés réservés

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.

5.	Hiérarchie de désignations

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.

6.	Transposition de la macro IDENTITÉ DE MODULE
6.1	Transposition de la clause CATEGORIES-SUJET

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.

7.	Transposition de la macro TYPE-D’OBJET

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.

7.1	Transposition de la clause SYNTAXE

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

Les types de base sont un sous ensemble étendu des types de base de la SMI :
-	types ASN.1 incorporés : ENTIER, CHAINE-D’OCTETS, IDENTIFIANT D’OBJET,
-	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.

7.1.1	Compteur32
Le type Compteur32 n’est pas accepté par la SPPI.

7.1.2	Gauge32
Le type Gauge32 n’est pas accepté par la SPPI.

7.1.3	Opaque
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.

7.1.4	IpAdresse
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].

7.1.5	Compteur64
Le type Compteur64 n’est pas accepté par la SPPI.

7.1.6	Entier64
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.

7.1.7	Nonsigné64
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.

7.1.8	Classes d’approvisionnement
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 :
-	la PRC comme un tout, appelée définition de tableau, et
-	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>.

7.2	Transposition de la clause MAX-ACCES

La clause MAX-ACCES n’est pas acceptée par la SPPI.

7.3	Transposition de la clause PIB-ACCES

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

7.4	Transposition de la clause INSTALLE-ERREURS

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.

7.5	Transposition de la clause PIB-INDEX

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.

7.6	Transposition de la clause 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.

7.7	Transposition de la clause AUGMENTE

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]).

7.8	Transposition de la clause ETEND

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.

7.8.1	Relation entre les clauses PIB-INDEX, AUGMENTE et ETEND
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.

7.9	Transposition de la clause UNICITÉ

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.

7.10	Transposition de la clause PIB-REFERENCES

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.

7.11	Transposition de la clause PIB-TAG

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.

8.	Transposition de la macro IDENTITÉ D’OBJET

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.

9.	Transposition de la macro GROUPE-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.

9.1	Transposition de la clause OBJETS

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.

10.	Transposition de la macro CONFORMITÉ DE MODULE

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.

10.1	Transposition de la clause MODULE

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.

10.1.1	Transposition de la clause GROUPES-OBLIGATOIRES
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é.

10.1.2	Transposition de la clause GROUPE
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.

10.1.3	Transposition de la clause OBJET
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.

10.1.3.1	Transposition de la clause SYNTAXE
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.

10.1.3.2.	Transposition de la clause SYNTAXE-ÉCRITURE
La clause SYNTAXE-ÉCRITURE n’est pas acceptée par la SPPI.

10.1.3.3	Transposition de la clause PIB-MIN-ACCES
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.

11.	Conventions textuelles

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.

11.1	Transposition de la macro CONVENTION TEXTUELLE

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.

 (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  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].

11.1.2	SYNTAXE
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.

11.1.2.1	Sous typage des conventions textuelles
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.

12.	Extension d’un module de PIB

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.

12.1	Modules de PIB

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 changements à une PIB existante peuvent être faits de plusieurs façons :
-	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.

12.2	Allocations d’objet

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

12.3	Définitions d’objet

Une définition d’objet peut être révisée d’une des façons suivantes :
-	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 clause UNITÉS peut être ajoutée.
-	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 clause REFERENCE peut être ajoutée ou mise à jour.
-	Une clause DEFVAL peut être ajoutée ou mise à jour.
-	 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.

Appendice A : Transposition d’une PIB en MIB

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 :
-	Modifier le nom de module du module en ajoutant "-MIB" au nom.
-	Changer l’OID alloué à l’IDENTITÉ-DE-MODULE pour une valeur différente.
-	 Remplacer le mot-clé PIB-DEFINITIONS par le mot-clé DEFINITIONS.
-	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
-	les omettre de la conversion, 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.)

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

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.

TYPE-D’OBJET qosIfDscpAssignTable
SYNTAXE	SEQUENCE DE QosIfDscpAssignEntry
PIB-ACCES	installe
STATUT	actuel
DESCRIPTION " "
::= { qosIfParameters 9 }

TYPE-D’OBJET qosIfDscpAssignEntry
SYNTAXE	QosIfDscpAssignEntry
STATUT	actuel
DESCRIPTION  : "Instance de la classe qosIfDscpAssign."
PIB-INDEX	{ qosIfDscpAssignPrid }
UNICITÉ	{ qosIfDscpAssignName, qosIfDscpAssignRoles }
::= { qosIfDscpAssignTable 1 }

QosIfDscpAssignEntry ::= SEQUENCE {
        qosIfDscpAssignPrid       InstanceId,
        qosIfDscpAssignName       SnmpAdminString,
        qosIfDscpAssignRoles      RoleCombination,
        qosIfDscpAssignDscpMap    TagReferenceId
}

TYPE-D’OBJET qosIfDscpAssignDscpMap
SYNTAXE	TagReferenceId
PIB-TAG	{ qosIfDscpMapMapId }	-- attribut défini plus loin.
STATUT	actuel
DESCRIPTION : "Transposition DSCP qui est appliquée aux interfaces de type qosIfDscpAssignName qui ont une combinaison de rôle de qosIfDscpAssignRoles."
::= { qosIfDscpAssignEntry 3 }

--
-- Tableau de transposition de DSCP en file d’attente et en seuil
--

TYPE-D’OBJET qosIfDscpMapTable
SYNTAXE	SEQUENCE DE QosIfDscpMapEntry
PIB-ACCES	installe
STATUT	actuel
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."
::= { qosIfParameters 10 }

TYPE-D’OBJET qosIfDscpMapEntry
SYNTAXE	QosIfDscpMapEntry
STATUT	actuel
DESCRIPTION : "Instance de la classe qosIfDscpMap."
PIB-INDEX	{ qosIfDscpMapPrid }
UNICITÉ	{ qosIfDscpMapMapId, qosIfDscpMapDscp }
::= { qosIfDscpMapTable 1 }

QosIfDscpMapEntry ::= SEQUENCE {
        qosIfDscpMapPrid       InstanceId,
        qosIfDscpMapMapId      TagId,
        qosIfDscpMapDscp       Dscp,
        qosIfDscpMapQueue      ReferenceId,
        qosIfDscpMapThresh     ReferenceId
}

TYPE-D’OBJET qosIfDscpMapMapId
SYNTAXE	TagId
STATUT	actuel
DESCRIPTION : "Entier qui identifie la transposition DSCP à laquelle appartient cette PRI."
::= { qosIfDscpMapEntry 2 }

TYPE-D’OBJET qosIfDscpMapQueue
SYNTAXE	ReferenceId
PIB-REFERENCES	{ qosIfQueueEntry }
STATUT	actuel
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."
::= { qosIfDscpMapEntry 4 }

TYPE-D’OBJET qosIfDscpMapThresh 
SYNTAXE	ReferenceId
PIB-REFERENCES	{ qosIfThresholdEntry }
STATUT	actuel
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."
::= { qosIfDscpMapEntry 5 }

Considérations pour la sécurité

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.

Considérations pour l’IANA

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

IDENTIFIANT D’OBJET internet  ::= { iso 3 6 1 }

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 :

IDENTIFIANT D’OBJET mgmt    ::= { internet 2 }
IDENTIFIANT D’OBJET experimental  ::= { internet 3 }
IDENTIFIANT D’OBJET private  ::= { internet 4 }
IDENTIFIANT D’OBJET enterprises  ::= { private 1 }

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

Le présent document définit 

IDENTIFIANT D’OBJET pib  ::= { mgmt 2 }

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]).

Adresses des auteurs

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 	

Références

[IANA]	http://www.isi.edu/in-notes/iana/assignments/smi-numbers 

[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.)

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

[RFC2579]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conventions textuelles pour SMIv2", avril 1999. (STD0058)

[RFC2580]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Déclarations de conformité pour SMIv2", avril 1999. (STD0058)

[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.)

[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.)

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