Groupe de travail Réseau	Éditeurs de la présente version : K. McCloghrie, Cisco Systems
Request for Comments : 2578	D. Perkins, SNMPinfo
STD : 58	J. Schoenwaelder, TU Braunschweig
RFC rendue obsolète : 1902	Auteurs de la version précédente : J. Case, SNMP Research
Catégorie : En cours de normalisation	K. McCloghrie, Cisco Systems
avril 1999	M. Rose, First Virtual Holdings
Traduction Claude Brière de L’Isle	S. Waldbusser, International Network Services

Structure des informations de gestion, version 2 (SMIv2)

Statut du présent mémoire

Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son 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 la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Table des matières

1. Introduction

Les informations de gestion sont vues comme une collection d’objets gérés, résidant dans un magasin d’informations virtuel, appelé la base de données d’informations de gestion (MIB, Management Information Base). Les collections des objets qui s’y rapportent sont définies dans des modules de MIB. Ces modules sont écrits en utilisant un sous-ensemble adapté de la notation de syntaxe abstraite n° 1 (ASN.1, Abstract Syntax Notation One) de l’OSI, (1988) [1], qui est l’objet du présent document. La structure des informations de gestion (SMI, Structure of Management Information) définit ce sous-ensemble adapté et alloue un ensemble de valeurs administratives qui y sont associées.

Le SMI est divisé en trois parties : définitions de module, définitions d’objet, et définitions de notification.

(1) Les définitions de module sont utilisées pour décrire des modules d’information. Une macro ASN.1, MODULE-IDENTITY, est utilisée pour porter de façon concise la sémantique d’un module d’information.

(2) Les définitions d’objet sont utilisées pour la description des objets gérés. Une macro ASN.1, OBJECT-TYPE, est utilisée pour porter de façon concise la syntaxe et la sémantique d’un objet géré.

(3) Les définitions de notification sont utilisées pour décrire des transmissions non sollicitées d’informations de gestion. Une macro ASN.1, NOTIFICATION-TYPE, est utilisée pour porter de façon concise la syntaxe et la sémantique d’une notification.

1.1 Note sur la terminologie

Pour les besoins de l’exposé, la structure d’informations de gestion originale, telle que décrite dans les RFC 1156 (STD 16), 1212 (STD 16), et RFC 1215, est appelée SMI version 1 (SMIv1). La version actuelle de la structure d’informations de gestion est appelée SMI version 2 (SMIv2).

2. Définitions

SNMPv2-SMI DEFINITIONS ::= BEGIN

-- le chemin de la racine

org	OBJECT IDENTIFIER ::= { iso 3 }	-- "iso" = 1
dod	OBJECT IDENTIFIER ::= { org 6 }
internet	OBJECT IDENTIFIER ::= { dod 1 }
directory	OBJECT IDENTIFIER ::= { internet 1 }
mgmt	OBJECT IDENTIFIER ::= { internet 2 }
mib-2	OBJECT IDENTIFIER ::= { mgmt 1 }
transmission	OBJECT IDENTIFIER ::= { mib-2 10 }
experimental	OBJECT IDENTIFIER ::= { internet 3 }
private	OBJECT IDENTIFIER ::= { internet 4 }
enterprises	OBJECT IDENTIFIER ::= { private 1 }
security	OBJECT IDENTIFIER ::= { internet 5 }
snmpV2	OBJECT IDENTIFIER ::= { internet 6 }

-- domaines de transport
snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }

-- mandataires de transport
snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }

-- identités de module
snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }

-- Temps UTC étendu ExtUTCTime, pour permettre les dates à quatre chiffres
-- (Noter que cette définition de ExtUTCTime n’est pas à IMPORTER par les modules de MIB.)
ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
-- le format est AAMMJJHHMMZ ou AAAAMMJJHHMMZ
-- où : AA - les deux derniers chiffres de l’année (seulement entre 1900 et 1999)
-- AAAA – quatre derniers chiffres de l’année (n’importe quelle année)
-- MM – mois (de 01 à 12)
-- DD – jour du mois (de 01 à 31)
-- HH – heures (de 00 à 23)
-- MM – minutes (de 00 à 59)
-- Z – note l’heure GMT (le caractère ASCII Z)

-- Par exemple, "9502192015Z" et "199502192015Z" représentent 20:15 GMT le 19 février 1995. Les années après 1999 doivent utiliser le format d’année à quatre chiffres. Les années de 1900 à 1999 peuvent utiliser le format à deux ou quatre chiffres.

-- définitions des modules d’informations
MODULE-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"LAST-UPDATED" value(Update ExtUTCTime)
"ORGANIZATION" Text
"CONTACT-INFO" Text

"DESCRIPTION" Text
RevisionPart

VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)

RevisionPart ::=
Revisions
| empty
Revisions ::=
Revision
| Revisions Revision
Revision ::=
"REVISION" valeur(Update ExtUTCTime)
"DESCRIPTION" Texte

-- chaîne de caractères comme défini au paragraphe 3.1.1

Texte ::= valeur(IA5String)
END

OBJECT-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::= "STATUS" État
"DESCRIPTION" Texte

ReferPart
VALUE NOTATION ::= valeur(VALUE OBJECT IDENTIFIER)

Status ::=
"courant"
| "déconseillé"
| "obsolète"

ReferPart ::= "REFERENCE" Texte
| vide

-- chaîne de caractères comme défini au paragraphe 3.1.1

Text ::= valeur(IA5String)
END

-- noms des objets
-- (Noter que ces définitions de ObjectName et NotificationName ne sont pas à IMPORTER par les modules de MIB.)

ObjectName ::=
OBJECT IDENTIFIER

NotificationName ::=
OBJECT IDENTIFIER

-- syntaxe des objets

-- les "types de base" définis ici sont :

-- 3 types ASN.1 incorporés : INTEGER, OCTET STRING, OBJECT IDENTIFIER

-- 8 types définis par l’application : Integer32, IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, et Counter64

ObjectSyntax ::= CHOICE {
simple
SimpleSyntax,

-- noter que les SEQUENCE pour les tableaux et rangées conceptuels ne sont pas mentionnés ici...

application-wide
ApplicationSyntax
}

-- types ASN.1 incorporés

SimpleSyntax ::=
CHOICE {
-- des entiers avec une gamme plus restrictive peuvent aussi être utilisés
integer-value -- inclut Integer32
INTEGER (-2147483648..2147483647),

-- des chaînes d’octets d’une taille plus restrictive peuvent aussi être utilisées

string-value
OCTET STRING (SIZE (0..65535)),

objectID-value
OBJECT IDENTIFIER
}

-- ne peut être distingué de INTEGER, mais n’a jamais besoin de plus de 32 bits pour une représentation de complément à deux
Integer32 ::= INTEGER (-2 147 483 648..2 147 483 647)

-- types de niveau application

ApplicationSyntax ::=
CHOICE {
ipAddress-value
IpAddress,

counter-value
Counter32,

timeticks-value
TimeTicks,
arbitrary-value
Opaque,

big-counter-value
Counter64,
unsigned-integer-value -- inclut Gauge32
Unsigned32
}

-- dans l’ordre des octets du réseau (c’est un type marqué pour des raisons historiques)
IpAddress ::=
[APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4))

-- il fait le tour du compteur
Counter32 ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)

-- il ne revient pas à zéro
Gauge32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

-- quantité de 32 bits non signée qu’on ne peut distinguer de Gauge32
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

-- centièmes de secondes depuis une certaine date
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)

-- seulement pour la rétro-compatibilité
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET STRING

-- pour les compteurs qui font le tour en moins d’une heure avec seulement 32 bits
Counter64 ::=
[APPLICATION 6]
IMPLICIT INTEGER (0..18446744073709551615)

-- définition pour les objets

OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
"SYNTAX" Syntaxe
UnitsPart
"MAX-ACCESS" Accès
"STATUS" État
"DESCRIPTION" Texte
ReferPart
IndexPart
DefValPart

VALUE NOTATION ::=
valeur(VALUE ObjectName)

Syntax ::= -- Doit être une des suivantes :
-- un type de base (ou son raffinement),
-- une convention textuelle (ou son raffinement), ou
-- un pseudo-type BITS

type
| "BITS" "{" NamedBits "}"

NamedBits ::= NamedBit
| NamedBits "," NamedBit

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

UnitsPart ::=
"UNITS" Texte
| vide

Accès ::=
"non-accessible"
| "accessible-pour-notifié"
| "lecture-seule"
| "lecture-écriture"
| "lecture-création"

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

ReferPart ::=
"REFERENCE" Texte
| vide

IndexPart ::=
"INDEX" "{" IndexTypes "}"
| "AUGMENTS" "{" Entry "}"
| vide
IndexTypes ::=
IndexType
| IndexTypes "," IndexType
IndexType ::=
"IMPLIED" Index
| Index

Index ::=
-- utilise la valeur SYNTAX de l’invocation OBJECT-TYPE correspondante
valeur(ObjectName)
Entry ::=
-- utilise la valeur INDEX de l’invocation OBJECT-TYPE correspondante
valeur(ObjectName)

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

Defvalue ::= -- doit être valide pour le type spécifié dans la clause SYNTAX de la même macro OBJECT-TYPE
valeur(ObjectSyntax)
| "{" BitsValue "}"

BitsValue ::= BitNames
| vide

BitNames ::= BitName
| BitNames "," BitName

BitName ::= identifiant
-- une chaîne de caractères comme défini au paragraphe 3.1.1
Text::= valeur(IA5String)
END

-- définitions pour les notifications

MACRO NOTIFICATION-TYPE ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" État
"DESCRIPTION" TextE
ReferPart

VALUE NOTATION ::=
valeur(VALUE NotificationName)

ObjectsPart ::=
"OBJECTS" "{" Objects "}"
| vide
Objects ::=
Object

| Objects "," Object
Object ::=
valeur(ObjectName)

Status ::=
"courant"
| "déconseillé"
| "obsolète"

ReferPart ::=
"REFERENCE" Texte
| vide

-- chaîne de caractères comme défini au paragraphe 3.1.1
Text ::= valeur(IA5String)
END

-- définitions des identifiants administratifs

zeroDotZero OBJECT-IDENTITY
STATUS courant
DESCRIPTION
"Valeur utilisée pour les identifiants nuls."
::= { 0 0 }
END

3. Modules d’information

Un "module d’information" est un module ASN.1 qui définit des informations se rapportant à la gestion de réseau.

Le SMI décrit comment utiliser un sous-ensemble adapté de l’ASN.1 (1988) pour définir un module d’information. De plus, des restrictions supplémentaires sont imposées aux modules d’information "standard". Il est fortement recommandé que les modules d’information "spécifiques de l’entreprise" se conforment aussi à ces restrictions.

Normalement, il y a trois sortes de modules d’information:

(1) les modules de MIB, qui contiennent les définitions des objets gérés qui ont des relations croisées, font usage des macros OBJECT-TYPE et NOTIFICATION-TYPE ;

(2) les déclarations de conformité pour les modules de MIB, qui font usage des macros MODULE-COMPLIANCE et OBJECT-GROUP [2] ;

(3) les déclarations de capacité pour les mises en œuvre d’agent qui font usage de la macro AGENT-CAPABILITIES [2].

Ce schéma de classification n’implique pas une taxonomie rigide. Par exemple, un module d’information "standard" inclura normalement des définitions d’objets gérés et une déclaration de conformité. De même, un module d’information "spécifique de l’entreprise" peut inclure des définitions d’objets gérés et une déclaration de capacité. Bien sûr, un module d’information "standard" peut ne pas contenir de déclaration de capacité.

Les constructions d’ASN.1 permises dans les modules d’information SMIv2 incluent : la clause IMPORTS, les définitions de valeur pour les OBJECT IDENTIFIER (identifiants d’objet), les définitions de type pour les SEQUENCE (avec les restrictions), les allocations de type ASN.1 des types ASN.1 restreints admis dans SMIv2, et les instances de macros ASN.1 définies dans le présent document et ses documents compagnons [2, 3]. Des macros ASN.1 additionnelles ne doivent pas être définies dans les modules d’information SMIv2. Les macros SMIv1 ne doivent pas être utilisées dans les modules d’information SMIv2.

Les noms de tous les modules d’information standard doivent être uniques (mais différentes versions du même module d’information devraient avoir le même nom). Les développeurs de modules d’information d’entreprise sont invités à choisir pour leurs modules d’information des noms qui aient une faible probabilité de collision avec ceux des modules d’information standard ou d’autres entreprises. Un module d’information peut ne pas utiliser la construction ASN.1 consistant à placer une valeur d’identifiant d’objet entre le nom du module et le mot clé "DEFINITIONS". Pour les besoins de la présente spécification, un nom de module ASN.1 commence par une lettre majuscule et continue par zéro, une ou plusieurs lettres, chiffres, ou traits d’union, sauf qu’un trait d’union ne doit pas être le dernier caractère, et qu’il ne doit pas y avoir deux traits d’union consécutifs.

Tous les modules d’information commencent par exactement une invocation de la macro MODULE-IDENTITY, qui fournit les informations de contact ainsi que l’historique des révisions pour distinguer entre les versions du même module d’information. Cette invocation doit apparaître immédiatement après toute déclaration IMPORT.

3.1 Invocation de macro

Au sein d’un module d’information, chaque invocation de macro apparaît comme :

où <descripteur> correspond à un identifiant ASN.1, les noms <macro> aux macros invoquées, et <clauses> et <valeur> dépendent de la définition de la macro. (Noter que cette définition d’un descripteur s’applique à toutes les macros définies dans le présent mémoire et dans [2].)

Pour les besoins de cette spécification, un identifiant ASN.1 consiste en une ou plusieurs lettres ou chiffres, et son caractère initial doit être en minuscule. Noter que le trait d’union n’est pas admis par cette spécification (excepté utilisé par les modules d’information convertis de SMIv1 qui admettait le trait d’union).

Pour tous les descripteurs qui apparaissent dans un module d’information, le descripteur devra être unique et mnémonique, et ne doit pas dépasser 64 caractères. (Cependant, les descripteurs de plus de 32 caractères ne sont pas recommandés.) Ceci met en avant un langage commun à utiliser par les hommes lors des discussions de module d’information et facilite aussi les simples transpositions de tableaux pour les interfaces d’utilisateur.

L’ensemble des descripteurs défini dans tous les modules d’information "standard" devra être unique.

Finalement, par convention, si le descripteur se réfère à un objet avec une valeur de clause SYNTAX de Counter32 ou de Counter64, le descripteur utilisé pour l’objet devrait alors noter une pluralité.

3.1.1 Valeurs et chaînes textuelles

Dans une invocation de macro certaines clauses peuvent prendre une chaîne de caractères pour une valeur textuelle (par exemple, la clause DESCRIPTION). D’autres clauses prennent des chaînes binaires ou hexadécimales (dans toute position où un nombre non négatif est admis).

Une chaîne de caractères est précédée et suivie par le caractère quote ("), et consiste en un nombre arbitraire (qui peut être zéro) de :
- tout caractère ASCII affichable de 7 bits excepté quote ("),
- caractères de tabulation,
- espaces,
- caractères de terminaison de ligne (\n ou \r\n).

La valeur d’une chaîne de caractères est interprétée comme de l’ASCII.

Une chaîne binaire consiste en un certain nombre (éventuellement zéro) de zéros et de uns précédés par un seul (') et suivi par la paire ('B) ou ('b), où le nombre est un multiple de huit.

Une chaîne hexadécimale consiste en un nombre pair (éventuellement zéro) de chiffres hexadécimaux, précédés par un seul (') et suivi par la paire ('H) ou ('h). Les chiffres spécifiés via des lettres peuvent être en majuscule ou en minuscule.

Noter que les commentaires ASN.1 ne peuvent pas être inclus à l’intérieur de ces types de chaînes.

3.2 Symboles de IMPORT

Pour faire référence à un objet externe, la déclaration IMPORTS doit être utilisée pour identifier à la fois le descripteur et le module dans lequel le descripteur est défini, et le module est identifié par son nom de module ASN.1.

Noter que lorsque les symboles provenant de modules d’information "spécifiques de l’entreprise" sont référencés (par exemple, un descripteur), il y a une possibilité de collision. À ce titre, si différents objets ayant le même descripteur sont IMPORTés, cette ambiguïté est alors résolue en préfixant le descripteur avec le nom du module d’information et un point ("."), c’est-à-dire, "module.descripteur".

(Tous les descripteurs doivent être uniques au sein de tout module d’information.)

Bien sûr, cette notation peut être utilisée pour se référer aux objets même lorsqu’il n’y a pas de collision lors de l’IMPORTation de symboles.

Finalement, si un des types et macros ASN.1 désignés définis dans le présent document, spécifiquement : Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE-IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-IDENTITY, TimeTicks, Unsigned32, ou n’importe lequel de ceux définis dans [2] ou [3], est utilisé dans un module d’information, il doit alors être importé en utilisant la déclaration IMPORTS. Cependant, ce qui suit ne doit pas être inclus dans une déclaration IMPORTS :
- les types désignés définis par l’ASN.1 lui-même, précisément : INTEGER, OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
- les constructions BITS.

3.3 Symboles d’exportation

La déclaration ASN.1 EXPORTS n’est pas permise dans les modules d’information SMIv2. Tous les éléments définis dans un module d’information sont automatiquement exportés.

3.4 Commentaires en ASN.1

Les commentaires en ASN.1 peuvent être inclus dans un module d’information. Cependant, il est recommandé que toutes les descriptions de substantif soient placées au sein d’une clause DESCRIPTION appropriée.

Les commentaires ASN.1 commencent par une paire de traits d’union adjacents et se terminent par la prochaine paire de traits d’union adjacents ou à la fin de la ligne, selon ce qui intervient en premier. Les commentaires qui se terminent par une paire de traits d’union ont l’effet d’un seul caractère d’espace.

3.5 Valeurs de OBJECT IDENTIFIER

Une valeur OBJECT IDENTIFIER est une liste ordonnée de nombres non négatifs. Pour SMIv2, chaque nombre de la liste est conçu comme un sous-identifiant. Il y a au plus 128 sous-identifiants dans une valeur, et chaque sous-identifiant a une valeur maximum de 2^32-1 (4294967295 en décimal).

Toutes les valeurs OBJECT IDENTIFIER ont au moins deux sous-identifiants, où la valeur du premier sous-identifiant est un des noms bien connus suivants :

Valeur	Nom
0	ccitt
1	iso
2	joint-iso-ccitt

(Noter que ce SMI ne reconnaît pas de "nouveaux" noms bien connus, par exemple, comme lorsque le CCITT est devenu UIT-T.)

3.6 Utilisation de OBJECT IDENTIFIER

Les OBJECT IDENTIFIER sont utilisés de deux façons dans les modules d’information :

(1) enregistrement : la définition d’un élément particulier est enregistrée comme valeur d’OBJECT IDENTIFIER particulière, et associée à un descripteur particulier. Après un tel enregistrement, la sémantique ainsi associée à la valeur n’est pas autorisée à changer, l’OBJECT IDENTIFIER ne peut pas être utilisé pour un autre enregistrement, et le descripteur ne peut être changé ni associé à un autre enregistrement. Les macros suivantes sont enregistrées :

OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE, AGENT-CAPABILITIES.

(2) allocation : un descripteur peut être alloué à une valeur d’OBJECT IDENTIFIER particulière. Pour cet usage, la sémantique associée à la valeur d’OBJECT IDENTIFIER n’est pas autorisée à changer, et un descripteur alloué à une valeur d’OBJECT IDENTIFIER particulier ne peut pas ensuite être alloué à une autre. Cependant, plusieurs descripteurs peuvent être alloués à la même valeur d’OBJECT IDENTIFIER. De telles allocations sont spécifiées de la façon suivante :

mib OBJECT IDENTIFIER ::= { mgmt 1 } -- d’après la RFC1156
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- d’après la RFC1213
fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }

Noter qu’alors que les exemples ci-dessus sont légaux, le suivant ne l’est pas :

dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }

Il est permis à un descripteur d’être associé à la fois à un enregistrement et à une allocation, pourvu que tous deux soient associés à la même valeur et sémantique d’OBJECT IDENTIFIER.

3.7 Mots clés réservés

Les mots clés suivants sont réservés et ne doivent pas être utilisés comme noms de descripteurs ou de modules :

ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32 IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE-IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH WRITE-SYNTAX

4. Hiérarchie de dénomination

La racine du sous-arbre administré par l’Autorité d’allocation des numéros de l’Internet (IANA) pour l’Internet est :

internet OBJECT IDENTIFIER ::= { iso 3 6 1 }

C’est à dire que le sous-arbre Internet des OBJECT IDENTIFIER débute par le préfixe : 1.3.6.1.

Plusieurs branches en dessous de ce sous-arbre sont utilisées pour la gestion de réseau.

mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }

Cependant, le SMI n’interdit pas la définition d’objets dans d’autres portions de l’arbre des objets.

Le sous-arbre mgmt(2) est utilisé pour identifier des objets "standard".

Le sous-arbre experimental(3) est utilisé pour identifier des objets qui sont conçus par des groupes de travail de l’IETF. Si un module d’information produit par un groupe de travail devient un module d’information "standard", les objets seront passés dans le sous-arbre mgmt(2) au tout début de son entrée dans le processus de normalisation Internet.

Le sous-arbre private(4) est utilisé pour identifier des objets définis unilatéralement. Le sous-arbre enterprises(1) en dessous de private est utilisé, entre autres choses, pour permettre aux fournisseurs de sous-systèmes de réseautage d’enregistrer les modèles de leurs produits.

5. Transposition de la macro MODULE-IDENTITY

La macro MODULE-IDENTITY est utilisée pour fournir le contact et l’historique des révisions de chaque module d’information. Il doit apparaître exactement une fois dans chaque module d’information. Il devrait être noté que l’expansion de la macro MODULE-IDENTITY est quelque chose qui arrive conceptuellement pendant la mise en œuvre et non durant le lancement.

Noter que la référence dans une clause IMPORTS ou dans des clauses de macros SMIv2 à un module d’information N’EST PAS par l’utilisation du 'descripteur' d’une macro MODULE-IDENTITY ; un module d’information est plutôt référencé par la spécification de son nom de module.

5.1 Transposition de la clause LAST-UPDATED

La clause LAST-UPDATED, qui doit être présente, contient la date et l’heure à laquelle ce module d’information a été édité pour la dernière fois.

5.2 Transposition de la clause ORGANIZATION

La clause ORGANIZATION, qui doit être présente, contient une description textuelle de l’organisation sous les auspices de laquelle ce module d’information a été développé.

5.3 Transposition de la clause CONTACT-INFO

La clause CONTACT-INFO, qui doit être présente, contient le nom, l’adresse postale, le numéro de téléphone, et l’adresse de messagerie électronique de la personne à qui les questions techniques concernant ce module d’information devraient être envoyées.

5.4 Transposition de la clause DESCRIPTION

La clause DESCRIPTION, qui doit être présente, contient une description textuelle de haut niveau du contenu de ce module d’information.

5.5 Transposition de la clause REVISION

La clause REVISION, qui n’a pas besoin d’être présente, est utilisée de façon répétée pour décrire les révisions (y compris la version initiale) faites à ce module d’information, en ordre chronologique inverse (c’est-à-dire, la plus récente en premier). Chaque instance de cette clause contient la date et l’heure de la révision.

5.5.1 Transposition de la sous-clause DESCRIPTION

La sous-clause DESCRIPTION, qui doit être présente pour chaque clause REVISION, contient une description textuelle de haut niveau de la révision identifiée dans cette clause REVISION.

5.6 Transposition de la clause MODULE-IDENTITY

La valeur d’une invocation de la macro MODULE-IDENTITY est un OBJECT IDENTIFIER. Comme telle, cette valeur peut être utilisée d’autorité lors de la spécification d’une valeur d’OBJECT IDENTIFIER pour se référer au module d’information qui contient l’invocation.

Noter qu’il est de pratique courante d’utiliser la valeur de la macro MODULE-IDENTITY comme sous-arbre sous lequel d’autres valeurs d’OBJECT IDENTIFIER allouées au sein du module sont définies. Cependant, il est légal (et occasionnellement nécessaire) pour les autres valeurs d’OBJECT IDENTIFIER allouées au sein du module de n’être pas mises en relation avec la valeur d’OBJECT IDENTIFIER de la macro MODULE-IDENTITY.

5.7 Exemple d’utilisation

Considérons comment un module de MIB squelettique pourrait être construit : par exemple,

FIZBIN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, experimental
FROM SNMPv2-SMI;

fizbin MODULE-IDENTITY
LAST-UPDATED "199505241811Z"
ORGANIZATION "IETF SNMPv2 Working Group"

CONTACT-INFO
" Marshall T. Rose
Postal: Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US

Tel: +1 415 968 1052
Fax: +1 415 968 2510
E-mail: mrose@dbc.mtview.ca.us"

DESCRIPTION
"Module de MIB pour les entités mettant en œuvre le protocole xxxx."

REVISION "9505241811Z"
DESCRIPTION
"Dernière version de ce module de MIB."

REVISION "9210070433Z"
DESCRIPTION
"La version initiale de ce module de MIB, publié dans la RFC yyyy."
-- contacter l’IANA pour le numéro actuel
::= { experimental xx }
END

6. Transposition de la macro OBJECT-IDENTITY

La macro OBJECT-IDENTITY est utilisée pour définir les informations sur une allocation de OBJECT IDENTIFIER. Toutes les allocations administratives de OBJECT IDENTIFIER qui définissent une valeur d’identification de type (voir Type autonome, une convention textuelle définie dans [3]) devraient être définies via la macro OBJECT-IDENTITY. Il vaut de noter que l’expansion de la macro OBJECT-IDENTITY est quelque chose qui arrive conceptuellement durant la mise en œuvre et non durant le lancement.

6.1 Transposition de la clause STATUS

La clause STATUS, qui doit être présente, indique si cette définition est courante ou historique.

La valeur "courant" signifie que la définition est actuelle et valide. La valeur "obsolète" signifie que la définition est obsolète et ne devrait pas être mise en œuvre et/ou peut être retirée si elle a été mise en œuvre précédemment. Alors que si la valeur "déconseillé" indique aussi une définition obsolète, elle permet de nouvelles/continues mises en œuvre afin de ménager l’interopérabilité avec les mises en œuvre anciennes/existantes.

6.2 Transposition de la clause DESCRIPTION

La clause DESCRIPTION, qui doit être présente, contient une description textuelle de l’allocation d’objet.

6.3 Transposition de la clause REFERENCE

La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence croisée textuelle à d’autres documents, ou à un autre module d’information qui définit une allocation qui s’y rapporte, ou à d’autres documents qui fournissent des informations supplémentaires pertinentes pour cette définition.

6.4 Transposition de la valeur OBJECT-IDENTITY

La valeur d’une invocation de la macro OBJECT-IDENTITY est un OBJECT IDENTIFIER.

6.5 Exemple d’utilisation

Considérons comment une allocation de OBJECT IDENTIFIER pourrait être faite : par exemple,

fizbin69 OBJECT-IDENTITY
STATUS courant
DESCRIPTION
"Identité d’autorisation du chipset Fizbin 69."
::= { fizbinChipSets 1 }

7. Transposition de la macro OBJECT-TYPE

La macro OBJECT-TYPE est utilisée pour définir un type d’objet géré. On devrait noter que l’expansion de la macro OBJECT-TYPE est quelque chose qui survient durant la mise en œuvre et non durant le lancement.

Pour les objets d’extrémité qui ne sont pas des objets de colonne (c’est-à-dire, qui ne sont pas contenus dans un tableau conceptuel), les instances de l’objet sont identifiées en ajoutant un sous-identifiant de zéro au nom de cet objet. Autrement, la clause INDEX de l’objet de rangée conceptuelle supérieure à un objet de colonne définit les informations d’identification de l’instance.

7.1 Transposition de la clause SYNTAX

La clause SYNTAX, qui doit être présente, définit la structure de données abstraites correspondant à cet objet. La structure de données doit être d’une des suivantes : un type de base, la construction BITS, ou une convention textuelle. (SEQUENCE OF et SEQUENCE sont aussi possibles pour les tableaux conceptuels, voir au paragraphe 7.1.12). Les types de base sont ceux définis dans le CHOICE ObjectSyntax. Une convention textuelle est un type nouvellement défini comme sous-type d’un type de base [3].

Un sous-ensemble étendu des pleines capacités de sous-typage de l’ASN.1 (1988) est permis, comme approprié au type ASN.1 sous jacent. Toute restriction de cette sorte sur la taille, la gamme ou les énumérations spécifiée dans cette clause représente le niveau maximal de prise en charge qui a un sens pour le protocole. Les restrictions au sous-typage sont spécifiées en détail à la Section 9 et à l’Appendice A du présent mémoire.

La sémantique de ObjectSyntax est décrite ci-après.

7.1.1 Integer32 et INTEGER

Le type Integer32 représente les informations en valeurs d’entiers entre -2^31 et 2^31-1 inclus (-2 147 483 648 à 2 147 483 647 en décimal). Ce type ne se distingue pas du type INTEGER. Les deux types INTEGER et Integer32 peuvent être sous-typés pour être plus contraignants que le type Integer32.

Le type INTEGER (mais pas le type Integer32) peut aussi être utilisé pour représenter les informations en valeurs d’entiers comme les énumérations de nombres désignés. Dans ce cas, seuls les nombres désignés sont énumérés peuvent être présents comme valeur. Noter que bien qu’il soit recommandé que les valeurs énumérées commencent à 1 et soient énumérées de façon contiguë, toute valeur valide pour Integer32 est permise pour une valeur énumérée et de plus, les valeurs énumérées n’ont pas besoin d’être allouées de façon contiguë.

Finalement, un label pour une énumération de nombres désignés doit consister en une ou plusieurs lettres ou chiffres, jusqu’à un maximum de 64 caractères, et le caractère initial doit être en minuscule. (Cependant, les labels plus longs que 32 caractères ne sont pas recommandés.) Noter que les traits d’union ne sont pas admis par la présente spécification (excepté utilisés par les modules d’information convertis de SMIv1 qui acceptait les traits d’union).

7.1.2 OCTET STRING

Le type OCTET STRING (chaîne d’octets) représente des données binaires ou textuelles arbitraires. Bien que la limitation de taille spécifiée pour le SMI pour ce type soit de 65535 octets, les concepteurs de MIB devraient réaliser qu’il peut y avoir des limitations de mise en œuvre et d’interopérabilité pour les tailles excédant 255 octets.

7.1.3 OBJECT IDENTIFIER

Le type OBJECT IDENTIFIER (identifiant d’objet) représente des noms alloués administrativement. Toute instance de ce type peut avoir au plus 128 sous-identifiants. De plus, chaque sous-identifiant ne doit pas excéder la valeur 2^32-1 (4 294 967 295 en décimal).

7.1.4 La construction BITS

La construction BITS représente une énumération de bits désignés. Cette collection est allouée à des valeurs non négatives, contiguës (mais voir ci-dessous), commençant à zéro. Seuls les bits désignés ainsi énumérés peuvent être présent dans une valeur. (Et donc, les énumérations doivent être allouées à des bits consécutifs ; cependant, voir à la Section 9 des affinements sur les objets qui ont cette syntaxe.)

Au titre de la mise à jour d’un module d’information, pour un objet défini en utilisant la construction BITS, de nouvelles énumérations peuvent être ajoutées ou des énumérations existantes peuvent recevoir de nouveaux labels. Après l’ajout d’une énumération, il peut n’être pas possible de distinguer entre une mise en œuvre de l’objet mise à jour pour laquelle la nouvelle énumération n’est pas affirmée, et une mise en œuvre de l’objet antérieure à l’ajout. Selon les circonstances, une telle ambiguïté peut être désirable ou non. Le moyen d’éviter une telle ambiguïté dépend du codage des valeurs sur le réseau ; cependant, il y a la possibilité de définir de nouvelles énumérations commençant au prochain multiple de huit bits. (Bien sûr, cela peut aussi résulter en des discontinuités de l’énumération.)

Bien qu’il n’y ai pas de limitation spécifiée par le SMI sur le nombre des énumérations (et donc sur la longueur d’une valeur), excepté ce qui peut être imposé par la limité sur la longueur d’une OCTET STRING, les concepteurs de MIB devraient réaliser qu’il peut y avoir des limitations de mise en œuvre et d’interopérabilité pour les tailles excédant 128 bits.

Finalement, un label pour une énumération de nombres désignés doit consister en une ou plusieurs lettres ou chiffres, jusqu’à un maximum de 64 caractères, et le caractère initial doit être une minuscule. (Cependant, les labels plus longs que 32 caractères ne sont pas recommandés.) Noter que le trait d’union n’est pas admis par la présente spécification.

7.1.5 IpAddress

Le type IpAddress représente une adresse internet de 32 bits. Il est représenté comme une OCTET STRING de longueur 4, dans l’ordre des octets du réseau.

Noter que le type IpAddress est un type marqué pour des raisons historiques. Les adresses réseau devraient être représentées en utilisant une invocation de la macro TEXTUAL-CONVENTION [3].

7.1.6 Counter32

Le type Counter32 représente un entier non négatif à accroissement monotone jusqu’à atteindre une valeur maximum de 2^32-1 (4 294 967 295 en décimal), où il revient alors à zéro pour s’accroître à nouveau.

Les compteurs n’ont pas de valeur "initiale" définie, et donc, une seule valeur d’un Counter n’a (en général) pas de contenu informatif. Les discontinuités dans les valeurs à croissance monotone surviennent normalement à la réinitialisation du système de gestion, et à d’autres moments comme spécifié dans la description d’un type d’objet utilisant ce type ASN.1. Si de telles occurrences peuvent survenir, par exemple, à la création d’une instance d’objet à des moments autres que la réinitialisation, un objet correspondant devrait alors être défini, avec une clause SYNTAX appropriée, pour indiquer la dernière discontinuité. Des exemples de clause SYNTAX appropriée sont : TimeStamp (une convention textuelle définie dans [3]), DateAndTime (une autre convention textuelle tirée de [3]) ou TimeTicks.

La valeur de la clause MAX-ACCESS pour les objets ayant une valeur de clause SYNTAX de Counter32 est soit "lecture-seule", soit "accessible-pour-notification".

Une clause DEFVAL n’est pas admise pour les objets qui ont une valeur de clause SYNTAX de Counter32.

7.1.7 Gauge32

Le type Gauge32 représente un entier non négatif, qui peut croître ou décroître,mais ne doit jamais excéder une valeur maximum, ni tomber en dessous d’une valeur minimum. La valeur maximum ne peut être supérieure à 2^32-1 (4 294 967 295 en décimal), et la valeur minimum ne peut être inférieure à 0. La valeur d’un Gauge32 a sa valeur maximum chaque fois que les informations modélisées sont supérieurs ou égales à sa valeur maximum, et il a sa valeur minimum chaque fois que les informations modélisées sont inférieures ou égales à sa valeur minimum. Si les informations modélisées décroissent ensuite en dessous (croissent au-delà) de la valeur maximum (minimum), le Gauge32 décroît (croît) aussi. (Noter qu’en dépit de l’utilisation du terme "verrouillé" dans la définition d’origine de ce type, il ne reste pas "collé" à sa valeur maximum ou minimum.)

7.1.8 TimeTicks

Le type TimeTicks représente un entier non négatif qui représente le temps, modulo 2^32 (4 294 967 296 en décimal), en centièmes de seconde entre deux époques. Lorsque les objets sont définis avec ce type ASN.1, la description de l’objet identifie les deux époques de référence.

Par exemple, [3] définit la convention textuelle TimeStamp qui se fonde sur le type TimeTicks. Avec un TimeStamp, la première époque de référence est définie comme le moment où sysUpTime [5] était zéro, et la seconde époque de référence est définie comme la valeur actuelle de sysUpTime.

Le type TimeTicks ne peut pas être sous-typé.

7.1.9 Opaque

Le type Opaque est uniquement fourni pour la rétrocompatibilité, et ne doit pas être utilisé pour des types d’objet nouvellement définis.

Le type Opaque accepte la capacité de passer une syntaxe ASN.1 arbitraire. Une valeur est codée en utilisant les règles de codage de base de l’ASN.1 [4] en une chaîne d’octets. Elle est ensuite codée comme une OCTET STRING, 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 à codage opaque. Il n’est pas nécessaire qu’elle soit capable de développer les données puis d’interpréter leur contenu.

Une exigence du module de MIB "standard" est qu’aucun objet ne peut avoir une valeur de clause SYNTAX de Opaque.

7.1.10 Counter64

Le type Counter64 représente un entier non négatif qui croît de façon monotone jusqu’à ce qu’il atteigne une valeur maximum de 2^64-1 (18 446 744 073 709 551 615 en décimal), moment où elle recommence à croître à partir de zéro.

Les compteurs n’ont pas de valeur "initiale" définie, et donc, une seule valeur de Counter n’a (en général) aucun contenu d’information. Les discontinuités dans la valeur à croissance monotone surviennent normalement à la réinitialisation du système de gestion, et à d’autres moments spécifiés dans la description d’un type d’objet utilisant ce type ASN.1. Si un tel autre moment peut survenir, par exemple, la création d’une instance d’objet à un autre moment que la réinitialisation, un objet correspondant devrait alors être défini, avec une clause SYNTAX appropriée, pour indiquer la dernière discontinuité. Des exemples de clause SYNTAX appropriée sont : TimeStamp (une convention textuelle définie dans [3]), DateAndTime (une autre convention textuelle tirée de [3]) ou TimeTicks.

La valeur de la clause MAX-ACCESS pour des objets ayant une valeur de clause SYNTAX de Counter64 est soit "lecture-seule" soit "accessible-pour-notification".

Une exigence du module de MIB "standard" est que le type Counter64 ne peut être utilisé que si les informations modélisées reviendraient à zéro en moins d’une heure si le type Counter32 était utilisé à la place.

Une clause DEFVAL n’est pas admise pour les objets ayant une valeur de clause SYNTAX de Counter64.

7.1.11 Unsigned32

Le type Unsigned32 représente les informations en valeurs d’entiers entre 0 et 2^32-1 inclus (0 à 4 294 967 295 en décimal).

7.1.12 Tableaux conceptuels

Les opérations de gestion s’appliquent exclusivement aux objets scalaires. Cependant, il est parfois pratique pour les développeurs d’applications de gestion d’imposer une structure tabulaire imaginaire à une collection ordonnée d’objets au sein du MIB. Chacun de ces tableaux conceptuels contient zéro, un ou plusieurs rangées, et chaque rangée peut contenir un ou plusieurs objets scalaires, appelés objets de colonne. Cette conceptualisation est formalisée à l’aide de la macro OBJECT-TYPE pour définir à la fois un objet qui correspond à un tableau et un objet qui correspond à une rangée dans ce tableau. Un tableau conceptuel a une SYNTAX de la forme :

SEQUENCE OF <EntryType>

où <EntryType> se réfère au type SEQUENCE de sa rangée conceptuelle subordonnée. Une rangée conceptuelle a une SYNTAX de la forme :

où <EntryType> est un type SEQUENCE défini comme suit :

<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }

où il y a un <type> pour chaque objet subordonné, et chaque <type> est de la forme :

où <descripteur> est le descripteur désignant un objet subordonné, et <syntax> a la valeur de la clause SYNTAX de cet objet subordonné, sauf que aussi bien 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 dans <syntax>.

De plus, un <type> est toujours présent pour chaque objet subordonné. (Les clause ASN.1 DEFAULT et OPTIONAL ne sont pas admises dans la définition de SEQUENCE.) La clause MAX-ACCESS pour les tableaux et rangées conceptuels est "non-accessible".

7.1.12.1 Création et suppression des rangées conceptuelles

Pour les rangées conceptuelles nouvellement définies qui permettent la création d’instances de nouveaux objets et/ou la suppression d’instances d’objets existants, il devrait y avoir un objet de colonne avec une valeur de clause SYNTAX de RowStatus (une convention textuelle définie dans [3]) et une valeur de clause MAX-ACCESS de lecture-création. Par convention, ceci est appelé la colonne état de la rangée conceptuelle.

7.2 Transposition de la clause UNITS

Cette clause UNITS, qui n’a pas besoin d’être présente, contient une définition textuelle des unités associées à cet objet.

7.3 Transposition de la clause MAX-ACCESS

La clause MAX-ACCESS, qui doit être présente, définit si cela a un sens pour le protocole de lire, écrire et/ou créer une instance de l’objet, ou d’inclure sa valeur dans une notification. C’est le niveau maximal d’accès pour l’objet. (Ce niveau maximal d’accès est indépendant de toute politique d’autorisation administrative.)

La valeur "lecture-écriture" indique que l’accès en lecture et en écriture a un sens pour le protocole, mais pas la création. La valeur "lecture-création" indique que l’accès en lecture, en écriture et en création ont un sens pour le protocole. La valeur "non-accessible" indique un objet auxiliaire (voir au paragraphe 7.7). La valeur "accessible-pour-notification" indique un objet qui n’est accessible que via une notification (par exemple, snmpTrapOID [5]).

Ces valeurs sont ordonnées, de la plus petite à la plus grande : "non-accessible", "accessible-pour-notification", "lecture-seule", "lecture-écriture", "lecture-création".

Si un objet de colonne dans une rangée conceptuelle a "lecture-création" comme niveau maximal d’accès, aucun autre objet de colonne de la même rangée conceptuelle ne peut avoir un accès maximal de "lecture-écriture". (Noter que "lecture-création" est un surensemble de "lecture-écriture".)

7.4 Transposition de la clause STATUS

La clause STATUS, qui doit être présente, indique si cette définition est actuelle ou historique.

La valeur "courant" signifie que la définition est actuelle et valide. La valeur "obsolète" signifie que la définition est obsolète et ne devrait pas être mise en œuvre et/ou peut être retirée si elle e été mise en œuvre antérieurement. Alors que la valeur "déconseillé" indique aussi une définition obsolète, elle permet de nouvelles/continues mises en œuvre afin de ménager l’interopérabilité avec les mises en œuvre anciennes/existantes.

7.5 Transposition de la clause DESCRIPTION

La clause DESCRIPTION, qui doit être présente, contient une définition textuelle de cet objet qui donne toutes les définitions de sémantique nécessaires à la mise en œuvre, et devrait incorporer toutes les informations qui seraient autrement communiquées dans toutes annotations de commentaire ASN.1 associées à l’objet.

7.6 Transposition de la clause REFERENCE

La clause REFERENCE, qui n’a pas besoin d’ être présente, contient des références croisées textuelles à d’autres documents, ou un autre module d’information qui définit une allocation qui s’y rapporte, ou à un autre document qui fournit des informations supplémentaires pertinentes pour cette définition.

7.7 Transposition de la clause INDEX

La clause INDEX, qui doit être présente si cet objet correspond à une rangée conceptuelle (sauf si une clause AUGMENTS est présente à la place), et doit être absente autrement, définit des informations d’identification d’instance pour les objets de colonne subordonnés à cet objet.

Les informations d’identification d’instance dans une clause INDEX doivent spécifier le ou les objets tels que la ou les valeurs de ce ou ces objets distinguent sans ambiguïté une rangée conceptuelle. Les objets peuvent être des objets de colonne provenant du même tableau conceptuel et/ou d’un autre, mais ne doivent pas être des objets scalaires. Plusieurs occurrences du même objet dans une seule clause INDEX est vivement déconseillé.

La syntaxe des objets dans la clause INDEX indique comment former l’identifiant d’instance :

(1) valeur d’entier (c’est-à-dire ayant INTEGER comme type de primitive sous-jacent) : un seul sous-identifiant prenant la valeur entière (cela ne fonctionne que pour les entiers non négatifs) ;

(2) valeur de chaîne, chaînes de longueur fixe (ou de longueur variable précédées par le mot-clé IMPLIED) : 'n' sous-identifiants, où 'n' est la longueur de la chaîne (chaque octet de la chaîne est codé dans un sous-identifiant distinct) ;

(3) valeur de chaîne, chaînes de longueur variable (non précédée du mot-clé IMPLIED ) : 'n+1' sous-identifiants, où 'n' est la longueur de la chaîne (le premier sous-identifiant est 'n' lui-même, après quoi, chaque octet de la chaîne est codé dans un sous-identifiant distinct) ;

(4) objet à valeur d’identifiant (lorsque précédé du mot-clé IMPLIED) : 'n' sous-identifiants, où 'n' est le nombre de sous-identifiants dans la valeur (chaque sous-identifiant de la valeur est copié dans un sous-identifiant distinct) ;

(5) objet à valeur d’identifiant (lorsqu’il n’est pas précédé du mot-clé IMPLIED) : 'n+1' sous-identifiants, où 'n' est le nombre de sous-identifiants dans la valeur (le premier sous-identifiant est 'n' lui-même, après quoi, chaque sous-identifiant dans la valeur est copié) ;

(6) valeur de IpAddress : 4 sous-identifiants, dans la notation a.b.c.d familière.

Noter que le mot-clé IMPLIED peut seulement être présent pour un objet ayant une syntaxe de longueur variable (par exemple, chaîne de longueur variable ou objets à valeur d’identifiant d’objet). De plus, le mot-clé IMPLIED peut seulement être associé au dernier objet dans la clause INDEX. Finalement, le mot-clé IMPLIED ne peut pas être utilisé sur un objet de chaîne à longueur variable si cette chaîne pourrait avoir une valeur de longueur zéro.

Comme une seule valeur d’un Counter n’a (en général) aucun contenu d’information (voir les paragraphes 7.1.6 et 7.1.10), les objets définis avec la syntaxe, Counter32 ou Counter64, ne doivent pas être spécifiés dans une clause INDEX. Si un objet défini en utilisant la construction BITS est utilisé dans une clause INDEX, il est considéré comme une chaîne de longueur variable.

Les instances identifiées par l’utilisation d’objets à valeur d’entier devraient être numérotées à partir de un (c’est-à-dire, pas à partir de zéro). L’utilisation de zéro comme valeur pour un objet d’indice à valeur d’entier devrait être évitée, sauf cas particulier.

Les objets qui sont à la fois spécifiés dans la clause INDEX d’une rangée conceptuelle et comme objet de colonne de la même rangée conceptuelle sont appelés objets auxiliaires. La clause MAX-ACCESS pour les objets auxiliaires est "non-accessible", sauf dans les circonstances suivantes :

(1) au sein d’un module de MIB écrit à l’origine pour se conformer à SMIv1, et ultérieurement converti conformément à SMIv2 ; ou

(2) une rangée conceptuelle doit contenir au moins un objet de colonne qui ne soit pas un objet auxiliaire. Dans l’éventualité où tous les objets de colonne d’une rangée conceptuelle seraient aussi spécifiés dans sa clause INDEX, l’un d’entre eux doit alors être accessible, c’est-à-dire, avoir une clause MAX-ACCESS de "lecture-seule". (Noter que cette situation ne vient pas d’une rangée conceptuelle qui permet l’accès en création, car une telle rangée aura une colonne état qui ne sera pas un objet auxiliaire.)

Noter que les objets spécifiés dans la clause INDEX d’une rangée conceptuelle n’ont pas besoin d’être des objets de colonne de cette rangée conceptuelle. Dans cette situation, la clause DESCRIPTION de la rangée conceptuelle doit inclure une explication textuelle de la façon dont les objets qui sont inclus dans la clause INDEX mais ne sont pas des objets de colonne de cette rangée conceptuelle sont utilisés dans les instances d’identification univoque des objets de colonne de la rangée conceptuelle.

7.8 Transposition de la clause AUGMENTS

La clause AUGMENTS, qui ne doit être présente que si l’objet correspond à une rangé conceptuelle, est une solution de remplacement de la clause INDEX. Tout objet correspondant à une rangée conceptuelle a soit une clause INDEX soit une clause AUGMENTS.

Si un objet correspondant à une rangée conceptuelle a une clause INDEX, cette rangé est appelée une rangée conceptuelle de base ; autrement, si l’objet a une clause AUGMENTS, la rangée est dite être une augmentation de rangée conceptuelle, où la clause AUGMENTS nomme les objet correspondant à la rangée conceptuelle de base qui est augmentée par cette augmentation de rangée conceptuelle. (Et donc, une augmentation de rangée conceptuelle ne peut pas être augmentée elle-même.) Les instances d’objets de colonne subordonnées d’une augmentation de rangée conceptuelle sont identifiés conformément ) la clause INDEX de la rangée conceptuelle de base correspondant à l’objet désigné dans la clause AUGMENTS. De plus, les instances d’objet de colonne subordonnés d’une augmentation de rangée conceptuelle existent conformément à la même sémantique que les instances d’objets de colonne subordonnés de la rangée conceptuelle de base qui est augmentée. À ce titre, noter que la création d’une rangée conceptuelle de base implique la création correspondante de toutes augmentations de rangée conceptuelle.

Par exemple, un concepteur de MIB pourrait souhaiter définie des colonnes additionnelles dans un MIB "spécifique de l’entreprise" qui étend logiquement une rangée conceptuelle dans un MIB "standard". La définition de MIB "standard" de la rangée conceptuelle inclurait la clause INDEX et le MIB "spécifique de l’entreprise" contiendrait la définition d’une rangée conceptuelle utilisant la clause AUGMENTS. D’un autre côté, il serait incorrect d’utiliser la clause AUGMENTS pour les relations entre le ifTable de la RFC 2233 et les nombreux MIB spécifiques du support qui l’étendent pour des supports spécifiques (par exemple, le dot3Table de la RFC 2358), car toutes les interfaces ne sont pas sur le même support.

Noter qu’une rangée conceptuelle de base peut être augmentée par plusieurs augmentations de rangée conceptuelle .

7.8.1 Relation entre clauses INDEX et AUGMENTS

Pour définir les informations d’identification d’instance pour un tableau conceptuel :

(1) S’il y a une correspondance biunivoque entre les rangées conceptuelles de ce tableau et un tableau existant, la clause AUGMENTS devrait alors être utilisée.

(2) Autrement, si il y a une relation lâche entre les rangées conceptuelles de ce tableau et un tableau existant, on devrait alors utiliser une clause INDEX identique à celle du tableau existant. Par exemple, la relation entre le ifTable de la RFC 2233 et un MIB spécifique d’un support qui étend le ifTable pour un support spécifique (par exemple, le dot3Table dans la RFC 2358), est une relation lâche).

(3) Autrement, si aucun objet existant n’a la syntaxe et sémantique requises, les objets auxiliaires devraient alors être définis au sein de la rangée conceptuelle pour le nouveau tableau, et ces objets devraient être utilisés au sein de la clause INDEX pour la rangée conceptuelle.

7.9 Transposition de la clause DEFVAL

La clause DEFVAL, qui n’a pas besoin d’ être présente, définit une valeur par défaut acceptable qui peut être utilisée à la discrétion d’un agent lors de la création d’une instance d’objet. C’est-à-dire que la valeur est un "conseil" aux développeurs.

Durant la création d’une rangée conceptuelle, si une instance d’un objet de colonne n’est pas présente comme une des opérandes dans l’opération correspondante d’établissement de protocole de gestion, la valeur de la clause DEFVAL, si elle est présente, indique alors une valeur par défaut acceptable qu’un agent peut utiliser (en particulier pour un objet en lecture seule).

Noter qu’avec cette définition de la clause DEFVAL, il est approprié de l’utiliser pour tout objet de colonne d’un tableau en lecture-création. Il est aussi permis de l’utiliser pour des objets scalaires créés de façon dynamique par un agent, ou pour des objets de colonne d’un tableau en lecture-écriture créé de façon dynamique par un agent.

La valeur de la clause DEFVAL doit, bien sûr, correspondre à la clause SYNTAX pour l’objet. Si la valeur est un OBJECT IDENTIFIER, elle doit alors être exprimée comme un seul identifiant ASN.1, et non comme une collection de sous-identifiants.

Noter que si un opérande de l’opération d’établissement de protocole de gestion est une instance d’un objet en lecture seule, l’erreur `notWritable' [6] sera alors retournée. À ce titre, la clause DEFVAL peut être utilisée pour fournir une valeur par défaut acceptable qu’un agent pourrait utiliser.

À titre d’exemple, considérons les clauses DEFVAL possibles suivantes :

ObjectSyntax	clause DEFVAL
Integer32	DEFVAL { 1 } -- la même pour Gauge32, TimeTicks, Unsigned32
INTEGER	DEFVAL { valid } -- valeur énumérée
OCTET STRING	DEFVAL { 'ffffffffffff'H }
DisplayString	DEFVAL { "SNMP agent" }
IpAddress	DEFVAL { 'c0210415'H } -- 192.33.4.21
OBJECT IDENTIFIER	DEFVAL { sysDescr }
BITS	DEFVAL { { primary, secondary } } -- valeurs énumérées qui sont établies
BITS	DEFVAL { { } } -- aucune valeur énumérée n’est établie

Une chaîne binaire utilisée dans une clause DEFVAL pour une OCTET STRING doit être un multiple entier de huit ou zéro bits ; de même, une chaîne hexadécimale doit être un nombre pair de chiffres hexadécimaux. La valeur d’une chaîne de caractères utilisée dans une clause DEFVAL ne doit pas contenir de caractères de tabulation ni de terminaison de ligne.

Les types d’objet avec une SYNTAX de Counter32 et Counter64 peuvent ne pas avoir de clause DEFVAL, car il n’ont pas de valeur initiale définie. Cependant, il est recommandé de les initialiser à zéro.

7.10 Transposition de la clause OBJECT-TYPE

La valeur d’une invocation de la macro OBJECT-TYPE est le nom de l’objet, qui est un OBJECT IDENTIFIER, un nom alloué administrativement.

Lorsqu’un OBJECT IDENTIFIER est alloué à un objet :

(1) Si l’objet correspond à un tableau conceptuel, une seule allocation , celle pour une rangée conceptuelle, est alors présente immédiatement au-dessous de cet objet. Le nom alloué administrativement à l’objet de la rangée conceptuelle est déduit en ajoutant un sous-identifiant de "1" au nom alloué administrativement au tableau conceptuel.

(2) Si l’objet correspond à une rangée conceptuelle, au moins une allocation, une pour chaque colonne de la rangée conceptuelle, est alors présente au-dessous de cet objet. Le nom alloué administrativement pour chaque colonne est déduit en ajoutant un sous-identifiant unique positif au nom alloué administrativement pour la rangée conceptuelle.

(3) Autrement, aucune autre OBJECT IDENTIFIER qui est subordonné à l’objet ne peut être alloué.

Noter que le sous-identifiant final de tout nom alloué administrativement pour un objet doit être positif. Un sous-identifiant final de valeur zéro est réservé pour une utilisation future.

7.11 Exemple d’utilisation

Considérons comment on pourrait définir un tableau conceptuel et ses subordonnés. (Cet exemple utilise la convention textuelle RowStatus définie dans [3].)

evalSlot OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS lecture-seule
STATUS courant
DESCRIPTION
"Le numéro d’index de la première entrée non allouée dans le tableau d’évaluation, ou la valeur zéro indiquant que toutes les entrées sont allouées. Une station de gestion devrait créer de nouvelles entrées dans le tableau d’évaluation en utilisant cet algorithme : d’abord, produire une opération de restitution de protocole de gestion pour déterminer la valeur de evalSlot ; et ensuite, produire une opération d’établissement de protocole de gestion pour créer une instance de l’objet evalStatus réglant sa valeur à createAndGo(4) ou createAndWait(5). Si cette dernière opération réussit, la station de gestion peut alors continuer de modifier les instances correspondant à la rangée conceptuelle nouvellement créée sans craindre de collision avec d’autres stations de gestion."
::= { eval 1 }

evalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EvalEntry
MAX-ACCESS non-accessible
STATUS courant
DESCRIPTION
"Tableau d’évaluation (conceptuel)."
::= { eval 2 }

evalEntry OBJECT-TYPE
SYNTAX EvalEntry
MAX-ACCESS non-accessible
STATUS courant
DESCRIPTION
"Une entrée (rangée conceptuelle) dans le tableau d’évaluation."
INDEX { evalIndex }
::= { evalTable 1 }

EvalEntry ::=
SEQUENCE {
evalIndex Integer32,
evalString DisplayString,
evalValue Integer32,
evalStatus RowStatus
}

evalIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS courant
DESCRIPTION
"La variable auxiliaire utilisée pour identifier les instances des objets de colonne dans le tableau d’évaluation."
::= { evalEntry 1 }

evalString OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS lecture-création
STATUS courant
DESCRIPTION
"La chaîne à évaluer."
::= { evalEntry 2 }

evalValue OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS lecture-seule
STATUS courant
DESCRIPTION
"La valeur lors de la dernière évaluation de evalString, ou zéro si aucune valeur n’est disponible."
DEFVAL { 0 }
::= { evalEntry 3 }

evalStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS lecture-création
STATUS courant
DESCRIPTION
"Colonne d’état utilisée pour créer, modifier, et supprimer des instances d’objets de colonne dans le tableau d’évaluation."
DEFVAL { active }
::= { evalEntry 4 }

8. Transposition de la macro NOTIFICATION-TYPE

La macro NOTIFICATION-TYPE est utilisée pour définir les informations contenues dans une transmission non sollicitée d’informations de gestion (c’est-à-dire, au sein d’un SNMPv2-Trap-PDU ou d’un InformRequest-PDU). Il devrait être noté que l’expansion de la macro NOTIFICATION-TYPE est quelque chose qui arrive conceptuellement durant la mise en œuvre et non durant le lancement.

8.1 Transposition de la clause OBJECTS

La clause OBJECTS, qui n’a pas besoin d’être présente, définit une séquence ordonnée de types d’objets de MIB. Une seule instance d’objet pour chaque occurrence de chaque type d’objet doit être présente, et dans l’ordre spécifié, dans toute instance de la notification. Si le même type d’objet survient plusieurs fois dans une séquence ordonnée d’une notification, une instance d’objet est alors présente pour chacun d’eux. Un type d’objet spécifié dans cette clause ne doit pas avoir une clause MAX-ACCESS de "non-accessible". La clause DESCRIPTION de la notification doit spécifier les informations et/ou la signification portée par chaque occurrence de chaque type d’objet dans la séquence. La clause DESCRIPTION doit aussi spécifier quelle instance d’objet est présente pour chaque type d’objet dans la notification.

Noter qu’un agent est autorisé, à son entière discrétion, à ajouter autant d’objets supplémentaires qu’il estime utile à la fin de la notification (c’est-à-dire, après les objets définis par la clause OBJECTS).

8.2 Transposition de la clause STATUS

La clause STATUS, qui doit être présente, indique si cette définition est actuelle ou historique.

La valeur "courant" signifie que la définition est actuelle et valide. la valeur "obsolète" signifie que la définition est obsolète et ne devrait pas être mise en œuvre et/ou qu’elle peut être retirée si elle a été mise en œuvre antérieurement. Alors que la valeur "déconseillé" indique aussi une définition obsolète, elle permet de nouvelles/continues mises en œuvre afin de ménager l’interopérabilité avec les mises en œuvre anciennes/existantes.

8.3 Transposition de la clause DESCRIPTION

La clause DESCRIPTION, qui doit être présente, contient une définition textuelle de la notification qui fournit toutes les définitions de sémantique nécessaires pour la mise en œuvre, et devrait comporter toute information qui serait autrement communiquée dans des annotations de commentaires ASN.1 associées à la notification. En particulier, la clause DESCRIPTION devrait indiquer quelles instances des objets mentionnés dans la clause OBJECTS devraient être contenus au sein des notifications de ce type.

8.4 Transposition de la clause REFERENCE

La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence croisée textuelle à un autre document, autre module d’information, qui définit une allocation qui s’y rapporte, ou quelque autre document qui fournit des informations supplémentaires pertinentes pour cette définition.

8.5 Transposition de la valeur NOTIFICATION-TYPE

La valeur d’une invocation de la macro NOTIFICATION-TYPE est le nom de la notification, qui est un OBJECT IDENTIFIER, un nom alloué administrativement. Afin de réalise la compatibilité avec les traps SNMPv1, à la fois lors de la conversion de modules d’information SMIv1 de/vers ce SMI, et dans les procédures employées par des systèmes multi langages et des applications qui transmettent à partir de mandataires, les prochains sous-identifiants jusqu’au dernier dans le nom de tout notification nouvellement définie doivent avoir la valeur zéro.

Les paragraphes 4.2.6 et 4.2.7 de [6] décrivent respectivement comment la macro NOTIFICATION-TYPE est utilisée pour générer un SNMPv2-Trap-PDU ou un InformRequest-PDU.

8.6 Exemple d’utilisation

Considérons comment une notification de changement de configuration pourrait être décrite :

entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }

entConfigChange NOTIFICATION-TYPE
STATUS courant

DESCRIPTION
"Un trap entConfigChange est envoyé lorsque la valeur de entLastChangeTime change. Il peut être utilisé par un NMS pour déclencher des interrogations de maintenance de tableau d’entité logique/physique.

Un agent ne doit pas générer plus d’un 'événement de trap' entConfigChange par période de cinq secondes, où un 'événement de trap' est la transmission d’un seul PDU de trap à une liste de destinations de trap. Si des changements de configuration supplémentaires surviennent dans la période de cinq secondes de 'ralenti', ces événements de trap devraient alors être supprimés par l’agent. Un NMS devrait périodiquement vérifier la valeur de entLastChangeTime pour détecter tout événement de trap entConfigChange manqué, par exemple du fait du ralenti ou de pertes de transmission."

::= { entityMIBTrapPrefix 1 }

Conformément à cette invocation, la notification identifiée péremptoirement comme { entityMIBTrapPrefix 1 } est utilisée pour rapporter un type particulier de changement de configuration.

9. Précisions sur la syntaxe

Certaines macros ont des clauses qui permettent de raffiner la syntaxe, en particulier : la clause SYNTAX de la macro OBJECT-TYPE, et les clauses SYNTAX/WRITE-SYNTAX des macros MODULE-COMPLIANCE et AGENT-CAPABILITIES [2]. Cependant, tous les raffinements de syntaxe ne sont pas appropriés. En particulier, la primitive de l’objet ou un type d’application ne doivent pas être changés.

De plus, les restrictions suivantes s’appliquent :

Restrictions au raffinement de la
syntaxe d’objet	gamme	énumération	taille
INTEGER	(1)	(2)	-
Integer32	(1)	-	-
Unsigned32	(1)	-	-
OCTET STRING	-	-	(3)
OBJECT IDENTIFIER	-	-	-
BITS	-	(2)	-
IpAddress	-	-	-
Counter32	-	-	-
Counter64	-	-	-
Gauge32	(1)	-	-
TimeTicks	-	-	-

où :

(1) la gamme des valeurs permises peut être raffinée en élevant la limite inférieure, en réduisant la limite supérieure, et/ou en réduisant les choix de valeur/gamme de remplacement ;

(2) l’énumération de valeurs désignées peut être raffinée en retirant une ou plusieurs valeurs désignées (noter que pour BITS, un raffinement peut causer une rupture de la continuité de l’énumération) ; ou,

(3) la taille en octets de la valeur peut être raffinée en élevant la limite inférieure, en réduisant la limite supérieure, et/ou en réduisant les choix de taille de remplacement.

Aucun autre type de raffinement ne peut être spécifié dans la clause SYNTAX. Cependant, la clause DESCRIPTION est disponible pour spécifier des restrictions supplémentaires qui ne peuvent pas être exprimées dans la clause SYNTAX. Des précisions sur le sous typage (et des exemples) sont fournis dans l’Appendice A.

10. Extension d’un module d’information

Après un peu d’expérience d’un module d’information, il sera peut-être souhaitable de le réviser. Cependant, les changements ne sont pas admis si ils peuvent causer des problèmes d’interopérabilité "sur le réseau" entre une mise en œuvre utilisant la spécification d’origine et une mise en œuvre qui utilise une ou des spécifications mises à jour.

Pour tout changement, l’invocation de la macro MODULE-IDENTITY doit être mise à jour pour inclure les informations sur la révision : précisément, de mettre à jour la clause LAST-UPDATED, d’ajouter une paire de clauses REVISION et DESCRIPTION (voir le paragraphe 5.5), et d’effectuer tous les changements nécessaires aux clauses existantes, y compris les clauses ORGANIZATION et CONTACT-INFO.

Noter que toute définition contenue dans un module d’information est disponible pour être IMPORTée par tout autre module d’information, et est référencée dans une clause IMPORTS via le nom du module. Et donc, un nom de module ne devrait pas être changé. Précisément, le nom de module (par exemple, "FIZBIN-MIB" dans l’exemple du paragraphe 5.7) ne devrait pas changé lors de la révision d’an module d’information (sauf pour corriger les fautes de frappe), et les définitions ne devraient pas être déplacées d’un module d’information à l’autre.

Noter aussi que les définitions obsolètes ne doivent pas être retirées des modules de MIB car leurs descripteurs peuvent toujours être référencés par d’autres modules d’information, et les OBJECT IDENTIFIER utilisés pour les nommer ne doivent jamais être réalloués.

10.1 Allocations d’objet

Si un changement non rédactionnel quelconque est fait à toute clause d’une allocation d’objet, la valeur OBJECT IDENTIFIER associée à cet allocation d’objet doit aussi être changée, ainsi que son descripteur associé.

10.2 Définitions d’objets

Une définition d’objet peut être révisée d’une des façons suivantes :

(1) Une clause SYNTAX contenant une énumération de INTEGER peut avoir de nouvelles énumérations ajoutées ou des labels existants changés. De même, des bits désignés peuvent être ajoutés ou des labels existants changés pour la construction BITS.

(2) La valeur d’une clause SYNTAX 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, ait le même ensemble de valeurs, et ait une sémantique identique.

(3) Une valeur de clause STATUS de "courant" peut être révisée en "déconseillé" ou "obsolète". De même, une valeur de clause STATUS de "déconseillé" peut être révisée en "obsolète". Lorsqu’un tel changement est effectué, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.

(4) Une clause DEFVAL peut être ajoutée ou mise à jour.

(5) Une clause REFERENCE peut être ajoutée ou mise à jour.

(6) Une clause UNITS peut être ajoutée.

(7) Une rangée conceptuelle peut être augmentée en ajoutant de nouveaux objets de colonne à la fin de la rangée, et en faisant la mise à jour correspondante à la définition de SEQUENCE.

(8) Des précisions et des informations supplémentaires peuvent être incluses dans la clause DESCRIPTION.

(9) Des objets entièrement nouveaux peuvent être définis, nommés avec des valeurs de OBJECT IDENTIFIER non allouées précédemment.

Autrement, si la sémantique de tout objet précédemment défini est changée (c’est-à-dire, si un changement non rédactionnel l est fait à toute clause autre que celles spécifiquement permises ci-dessus), la valeur de l’OBJECT IDENTIFIER associée à cet objet doit alors être changée aussi.

Noter que le changement du descripteur associé à un objet existant est considéré comme changement sémantique, car ces chaînes peuvent être utilisées dans une déclaration IMPORTS.

10.3 Définitions de notification

Une définition de notification peut être révisée d’une des façons suivantes :

(1) Une clause REFERENCE peut être ajouté ou mise à jour.
(2) Une valeur de clause STATUS de "courant" peut être révisée en "déconseillé" ou "obsolète". De même, une valeur de clause STATUS de "déconseillé" peut être révisée en "obsolète". Lorsqu’on fait un tel changement, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.
(3) Une clause DESCRIPTION peut être précisée.

Autrement, si la sémantique de tout objet précédemment défini est changée (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’OBJECT IDENTIFIER associée à cet objet doit alors être changée aussi.

Noter que le changement du descripteur associé à un objet existant est considéré comme changement sémantique, car ces chaînes peuvent être utilisées dans une déclaration IMPORTS.

11. Appendice A : Règles détaillées pour les sous-types

11.1 Règles de syntaxe

Les règles syntaxiques du sous typage figurent ci-dessous. Noter que bien que cette syntaxe se fonde sur l’ASN.1, elle comporte certaines extensions qui vont au-delà de ce que permet l’ASN.1, et un certain nombre de constructions ASN.1 ne sont pas permises par cette syntaxe.

<integerSubType>
::= <empty>
| "(" <range> ["|" <range>]... ")"

<octetStringSubType>
::= <empty>
| "(" "SIZE" "(" <range> ["|" <range>]... ")" ")"

où :
<empty> est la chaîne vide
<number> est un entier non négatif
<hexString> est une chaîne hexadécimale (par exemple, '0F0F'H)
<binString> est une chaîne binaire (par exemple, '1010'B)
<range> a les restriction supplémentaires suivantes :
- toute <value> utilisée dans une clause SIZE doit être non négative.
- lorsqu’une paire de valeurs est spécifiée, la première valeur doit être inférieure à la seconde valeur.
- lorsque plusieurs gammes sont spécifiées, les gammes ne doivent pas se chevaucher mais peuvent se toucher. Par exemple, (1..4 | 4..9) est invalide, et (1..4 | 5..9) est valide.
- les gammes doivent être un sous-ensemble de la gamme maximum du type de base.

11.2 Exemples

Voici quelques exemples de sous-types légaux :

Integer32 (-20..100)
Integer32 (0..100 | 300..500)
Integer32 (300..500 | 0..100)
Integer32 (0 | 2 | 4 | 6 | 8 | 10)
OCTET STRING (SIZE(0..100))
OCTET STRING (SIZE(0..100 | 300..500))
OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10))
SYNTAX TimeInterval (0..100)
SYNTAX DisplayString (SIZE(0..32))

(Noter que les deux derniers exemples ci-dessus ne sont pas valides dans une TEXTUAL CONVENTION, voir [3].)

Voici quelques exemples de sous-types illégaux :

Integer32 (150..100) -- le premier est supérieur au deuxième
Integer32 (0..100 | 50..500) -- les gammes se chevauchent
Integer32 (0 | 2 | 0 ) -- une valeur est dupliquée
Integer32 (MIN..-1 | 1..MAX) -- MIN et MAX ne sont pas permis
Integer32 (SIZE (0..34)) -- on ne doit pas utiliser SIZE
OCTET STRING (0..100) -- on doit utiliser SIZE
OCTET STRING (SIZE(-10..100)) -- SIZE négatif

12. Considérations pour la sécurité

Le présent document définit un langage pour écrite et lire des descriptions d’informations de gestion. Le langage n’a pas par lui-même d’impact sur la sécurité de l’Internet.

13. Adresse des éditeurs

Keith McCloghrie	David Perkins	Juergen Schoenwaelder
Cisco Systems, Inc.	SNMPinfo	TU Braunschweig
170 West Tasman Drive	3763 Benton Street	Bueltenweg 74/75
San Jose, CA 95134-1706	Santa Clara, CA 95051	38106 Braunschweig
USA	USA	Germany
téléphone : +1 408 526 5260	téléphone : +1 408 221-8702	téléphone : +49 531 391-3283
mél : kzm@cisco.com	mél : dperkins@snmpinfo.com	mél : schoenw@ibr.cs.tu-bs.de

14. Références

[1] Systèmes de traitement de l’information – Interconnexion des systèmes ouverts - Spécification de la Notation de syntaxe abstraite numéro un (ASN.1), Organisation Internationale de normalisation. Norme internationale 8824, (décembre, 1987).

[2] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose et S. Waldbusser, "Déclarations de conformité pour SMIv2", STD 58, RFC 2580, avril 1999.

[3] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. Rose et S. Waldbusser,"Conventions textuelles pour SMIv2", STD 58, RFC 2579, avril 1999.

[4] Systèmes de traitement de l’information – Interconnexion des systèmes ouverts - Spécification des règles de codage de base pour la Notation de syntaxe abstraite numéro un (ASN.1), Organisation Internationale de normalisation. Norme internationale 8825, (décembre, 1987).

[5] Groupe de travail SNMPv2, J. Case, K. McCloghrie, M. Rose et S. Waldbusser, "Base de données d’informations de gestion pour la version 2 du protocole simple de gestion de réseau (SNMPv2)", RFC 1907, janvier 1996.

[6] Groupe de travail SNMPv2, J. Case, K. McCloghrie, M. Rose et S. Waldbusser, "Opérations de protocole pour la version 2 du protocole simple de gestion de réseau (SNMPv2)", RFC 1905, janvier 1996.

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

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.