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

Déclarations de conformité pour 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 
Copyright (C) The Internet Society (1999). Tous droits réservés.

Table des matières
1.	Introduction
1.1	Note sur la terminologie
2.	Définitions
3.	Transposition de la macro OBJECT-GROUP
3.1	Transposition de la clause OBJECTS
3.2	Transposition de la clause STATUS
3.3	Transposition de la clause DESCRIPTION
3.4	Transposition de la clause REFERENCE
3.5	Transposition de la valeur OBJECT-GROUP
3.6	Exemple d’utilisation
4.	Transposition de la macro NOTIFICATION-GROUP
4.1	Transposition de la clause NOTIFICATIONS
4.2	Transposition de la clause STATUS
4.3	Transposition de la clause DESCRIPTION
4.4	Transposition de la clause REFERENCE
4.5	Transposition de la valeur NOTIFICATION-GROUP
4.6	Exemple d’utilisation
5.	Transposition de la macro MODULE-COMPLIANCE
5.1	Transposition de la clause STATUS
5.2	Transposition de la clause DESCRIPTION
5.3	Transposition de la clause REFERENCE
5.4	Transposition de la clause MODULE
5.4.1	Transposition de la clause MANDATORY-GROUPS
5.4.2	Transposition de la clause GROUP
5.4.3	Transposition de la clause OBJECT
5.4.4	Transposition de la clause DESCRIPTION
5.5	Transposition de la  MODULE-COMPLIANCE value
5.6	Exemple d’utilisation
6.	Transposition de la macro AGENT-CAPABILITIES
6.1	Transposition de la clause PRODUCT-RELEASE
6.2	Transposition de la clause STATUS
6.3	Transposition de la clause DESCRIPTION
6.4	Transposition de la clause REFERENCE
6.5	Transposition de la clause SUPPORTS
6.5.1	Transposition de la clause INCLUDES
6.5.2	Transposition de la clause VARIATION
6.6	Transposition de la valeur AGENT-CAPABILITIES
6.7	Exemple d’utilisation
7.	Extension d’un module d’information
7.1	Groupes de conformité
7.2	Définitions de conformité
7.3	Définitions de capacités
8.	Considérations pour la sécurité
9.	Adresse des éditeurs
10.	Références
11.	Déclaration complète de droits de reproduction

1.	Introduction

Les informations de gestion sont vues comme une collection d’objets gérés, résidant dans une mémoire d’informations virtuelle, appelée 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 les 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], appelé Structure des informations de gestion (SMI) [2].

Il peut être utile de définir les limites inférieures acceptables de mise en œuvre, ainsi que le niveau réel de mise en œuvre réalisé. C’est l’objet du présent document de définir la notation utilisée à cette fin.

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

2.	Définitions

SNMPv2-CONF DEFINITIONS ::= BEGIN

IMPORTS ObjectName, NotificationName, ObjectSyntax FROM SNMPv2-SMI ;

-- définitions pour les groupes de conformité

OBJECT-GROUP MACRO ::=
BEGIN
    TYPE NOTATION ::=
                  ObjectsPart
                  "STATUS" Statut
                  "DESCRIPTION" Texte
                  ReferPart

VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)

ObjectsPart ::= "OBJECTS" "{" Objects "}"
    Objects ::=
                  Object
                | Objets "," Objet
    Object ::=
                  value(ObjectName)
    Statut ::=
                  "courant"
                | "déconseillé"
                | "obsolète"
    ReferPart ::=
                  "REFERENCE" Texte
                | vide
    -- chaîne de caractères comme définie dans [2]
    Text ::= value(IA5String)
END

-- définitions supplémentaires pour les groupes de conformité
MACRO NOTIFICATION-GROUP ::=
BEGIN
    NOTATION du type ::=
                  NotificationsPart
                  "STATUS" Status
                  "DESCRIPTION" Text
                  ReferPart
    NOTATION DE LA VALEUR ::=
                  value(VALUE OBJECT IDENTIFIER)
    NotificationsPart ::=
                  "NOTIFICATIONS" "{" Notifications "}"
    Notifications ::=
                  Notification
                | Notifications "," Notification
    Notification ::=
                  value(NotificationName)
    Statut ::=
                  "courant"
                | "déconseillé"
                | "obsolète"
    ReferPart ::=
                  "REFERENCE" Texte
                | vide
    -- chaîne de caractères telle que définie en [2]
    Text ::= value(IA5String)
END

-- définitions pour les déclarations de conformité
MACRO MODULE-COMPLIANCE ::=
BEGIN
    NOTATION DU TYPE ::=
                  "STATUS" Statut
                  "DESCRIPTION" Texte
                  ReferPart
                  ModulePart
    NOTATION DE LA VALEUR ::=
                  value(VALEUR D’IDENTIFIANT D’OBJET)
    Statut ::=
                  "courant"
                | "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 commencer par une lettre majuscule
                  identifier ModuleIdentifier
                  -- ne doit pas être vide sauf contenu dans un module de MIB
                | vide
    ModuleIdentifier ::=
                  value(IDENTIFIANT D’OBJET)
                | vide
    MandatoryPart ::=
                  "MANDATORY-GROUPS" "{" Groups "}"
                | vide
    Groups ::=
                  Group
                | Groups "," Group
    Group ::=
                  value(IDENTIFIANT D’OBJET)
    CompliancePart ::=
                  Compliances
                | vide
    Compliances ::=
                  Compliance
                | Compliances Compliance
    Compliance ::=
                  ComplianceGroup
                | Object
    ComplianceGroup ::=
                  "GROUP" value(IDENTIFIANT D’OBJET)
                  "DESCRIPTION" Texte
    Object ::=
                  "OBJECT" value(ObjectName)
                  SyntaxPart
                  WriteSyntaxPart
                  AccessPart
                  "DESCRIPTION" Text
    -- doit être un affinement de la clause SYNTAX de l’objet
    SyntaxPart ::= "SYNTAX" Syntax
                | vide
    -- doit être un affinement de la clause SYNTAX de l’objet
    WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
                | vide

    Syntax ::=    -- Doit être une des suivantes:
                       -- un type de base (ou son affinement),
                       -- une convention textuelle (ou son affinement), ou
                       -- un pseudo-type BITS
                  type
                | "BITS" "{" NamedBits "}"

    NamedBits ::= NamedBit
                | NamedBits "," NamedBit

    NamedBit ::= identifier "(" number ")" -- number est non négatif

    AccessPart ::=

                  "MIN-ACCESS" Access
                | vide
    Access ::=
                  "non accessible"
                | "accessible pour-notifier"
                | "lecture-seule"
                | "lecture-écriture"
                | "lecture-création"

    -- chaîne de caractères telle que définie en [2]
    Text ::= value(IA5String)
END

-- définitions des déclarations de capacité

AGENT-CAPABILITIES MACRO ::=
BEGIN
    TYPE NOTATION ::=
                  "PRODUCT-RELEASE" Texte
                  "STATUS" Statut
                  "DESCRIPTION" Texte
                  ReferPart
                  ModulePart

    VALUE NOTATION ::=
                  value(VALUE OBJECT IDENTIFIER)

    Status ::=
                  "courant"
                | "obsolète"

    ReferPart ::=
                  "REFERENCE" Texte
                | vide

    ModulePart ::=
                  Modules
                | vide
    Modules ::=
                  Module
                | Modules Module
    Module ::=
                  -- nom du module --
                  "SUPPORTS" ModuleName
                  "INCLUDES" "{" Groups "}"
                  VariationPart

    ModuleName ::=

                  -- l’identifiant doit commencer par une lettre majuscule
                  identifier ModuleIdentifier
    ModuleIdentifier ::=
                  value(OBJECT IDENTIFIER)
                | vide

    Groups ::=
                  Group
                | Groups "," Group
    Group ::=
                  value(OBJECT IDENTIFIER)

    VariationPart ::=
                  Variations
                | vide
    Variations ::=
                  Variation
                | Variations Variation

    Variation ::=
                  ObjectVariation
                | NotificationVariation

    NotificationVariation ::=
                  "VARIATION" value(NotificationName)
                  AccessPart
                  "DESCRIPTION" Text

    ObjectVariation ::=
                  "VARIATION" value(ObjectName)
                  SyntaxPart
                  WriteSyntaxPart
                  AccessPart
                  CreationPart
                  DefValPart
                  "DESCRIPTION" Texte

    -- doit être un affinement de la clause SYNTAX de l’objet
    SyntaxPart ::= "SYNTAX" Syntax
                | vide

    WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
                | vide

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

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

    NamedBits ::= NamedBit
                | NamedBits "," NamedBit

    NamedBit ::= identifier "(" number ")" -- number est non négatif

    AccessPart ::=
                  "ACCESS" Access
                | vide

    Access ::=
                  "non mis en œuvre"
                -- seulement "non mis en œuvre" pour les notifications
                | "accessible-pour-notifier"
                | "lecture-seule"
                | "lecture-écriture"
                | "lecture-création"
                -- ce qui suit est seulement pour la rétro-compatibilité
                | "écriture-seule"

    CreationPart ::=
                  "CREATION-REQUIRES" "{" Cells "}"
                | vide
    Cells ::=
                  Cell
                | Cells "," Cell
    Cell ::=
                  value(ObjectName)

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

    Defvalue ::=  -- doit être valide pour la syntaxe de l’objet dans la clause SYNTAX de cette macro, si présente,
                  -- ou sinon, dans la macro OBJECT-TYPE de l’objet
                  value(ObjectSyntax)
                | "{" BitsValue "}"

    BitsValue ::= BitNames
                | vide

    BitNames ::=  BitName
                | BitNames "," BitName

    BitName ::= identifiant

    -- chaîne de caractères telle que définie en [2]
    Text ::= value(IA5String)
END

END

3.	Transposition de la macro OBJECT-GROUP

Pour les besoins de la conformité, il est utile de définir une collection d’objets gérés en rapport. La macro OBJECT-GROUP est utilisée pour définir chacune de ces collections d’objets relatés. Il vaut de noter que l’expansion de la macro OBJECT-GROUP est quelque chose qui survient durant la mise en œuvre et non durant le lancement.

Pour "mettre en œuvre" un objet, un agent doit retourner une valeur raisonnablement précise pour les opérations de restitution du protocole de gestion ; de même, si l’objet est écrivable, en réponse à une opération d’établissement du protocole de gestion, un agent doit alors également être capable d’influencer raisonnablement l’entité gérée sous jacente. Si un agent ne peut pas mettre en œuvre un objet, le protocole de gestion y fournit afin de retourner une exception ou une erreur, par exemple, noSuchObject [4]. En aucun cas un agent ne doit retourner une valeur pour des objets qu’il ne met pas en œuvre – il doit toujours retourner l’exception ou erreur appropriée, comme décrit dans la spécification du protocole [4].

Noter que la macro OBJECT-GROUP ne fournit par elle-même pas d’informations de conformité. Les informations de conformité sont plutôt spécifiées par l’inclusion des groupes définis dans une macro MODULE-COMPLIANCE.

3.1	Transposition de la clause OBJECTS
La clause OBJECTS, qui doit être présente, est utilisée pour spécifier chaque objet contenu dans le groupe de conformité. Chacun des objet spécifiés doit être défini dans le même module d’informations que celui où apparaît la macro OBJECT-GROUP, et doit avoir une valeur de clause MAX-ACCESS de "accessible-pour-notification", "lecture-seule", "lecture-écriture", ou "lecture-création".

Il est exigé que tout objet défini dans un module d’information avec une clause MAX-ACCESS autre que "non-accessible" soit contenu dans au moins un groupe d’objet. Cela évite l’erreur courante de l’ajout d’un nouvel objet à un module d’information en oubliant d’ajouter le nouvel objet à un groupe.

3.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 que le groupe ne devrait plus être utilisé pour définir la conformité. Bien que la valeur "déconseillé" indique aussi une définition obsolète, elle permet une utilisation nouvelle/continuée des définitions de conformité qui utilisent ce groupe.

3.3	Transposition de la clause DESCRIPTION
La clause DESCRIPTION, qui doit être présente, contient une définition textuelle de ce groupe, ainsi qu’une description de toutes relations avec d’autres groupes. Noter que les exigences de conformité génériques ne devraient pas être déclarées dans cette clause. Cependant, les relations de mise en œuvre entre ce groupe et d’autres groupes peuvent être définies dans cette clause.

3.4	Transposition de la clause REFERENCE
La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence textuelle croisée à un autre document, ou un 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.

3.5	Transposition de la valeur OBJECT-GROUP
La valeur d’une invocation de la macro OBJECT-GROUP est le nom du groupe, qui est un OBJECT IDENTIFIER, un nom alloué administrativement.

3.6	Exemple d’utilisation
Le groupe SNMP [3] est décrit :

snmpGroup OBJECT-GROUP
    OBJECTS { snmpInPkts,
              snmpInBadVersions,
              snmpInASNParseErrs,
              snmpBadOperations,
              snmpSilentDrops,
              snmpProxyDrops,
              snmpEnableAuthenTraps }
    STATUS	courant
    DESCRIPTION
 "Collection d’objets qui fournissent l’instrumentation et le contrôle de base d’un agent."
   ::= { snmpMIBGroups 8 }

Conformément à cette invocation, le groupe de conformité dénommé { snmpMIBGroups 8 } contient 7 objets.

4.	Transposition de la macro NOTIFICATION-GROUP

Pour les besoins de la conformité, il est utile de définir une collection de notifications. La macro NOTIFICATION-GROUP sert à cette fin. Il faut noter que l’expansion de la macro NOTIFICATION-GROUP est quelque chose qui survient durant la mise en œuvre et non durant le lancement.

4.1	Transposition de la clause NOTIFICATIONS
La clause NOTIFICATIONS, qui doit être présente, est utilisée pour spécifier chaque notification contenue dans le groupe de conformité. Chacune des notifications spécifiées doit être définie dans le même module d’informations que celui où apparaît la macro NOTIFICATION-GROUP.

Il est exigé que chaque notification définie dans un module d’information soit contenue dans au moins un groupe de notification.

4.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 que ce groupe ne devrait plus être utilisé pour définir la conformité. Alors que la valeur "déconseillé" indique aussi une définition obsolète, elle permet une utilisation nouvelle/continue des définitions de conformité qui utilisent ce groupe.

4.3	Transposition de la clause DESCRIPTION
La clause DESCRIPTION, qui doit être présente, contient une définition textuelle du groupe, ainsi qu’une description de toutes relations à d’autres groupes. Noter que les exigences de conformité génériques ne devraient pas être déclarées dans cette clause. Cependant, les relations de mise en œuvre entre ce groupe et d’autres groupes peuvent être définies dans cette clause.

4.4	Transposition de la clause REFERENCE
La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence textuelle croisée à un autre document, ou un 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.

4.5	Transposition de la valeur NOTIFICATION-GROUP
La valeur d’une invocation de la macro NOTIFICATION-GROUP est le nom du groupe, qui est un OBJECT IDENTIFIER, un nom alloué administrativement.

4.6	Exemple d’utilisation
On décrit le groupe SNMP Notifications de base [3] :

snmpBasicNotificationsGroup NOTIFICATION-GROUP
    NOTIFICATIONS { coldStart, authenticationFailure }
    STATUS	courant
    DESCRIPTION
"Les deux notifications qu’un agent est obligé de mettre en œuvre."
   ::= { snmpMIBGroups 7 }

Conformément à cette invocation, le groupe de conformité nommé { snmpMIBGroups 7 } contient deux notifications.

5.	Transposition de la macro MODULE-COMPLIANCE

La macro MODULE-COMPLIANCE est utilisée pour porter un ensemble minimum d’exigences par rapport à la mise en œuvre d’un ou plusieurs modules de MIB. Il faut noter que l’expansion de la macro MODULE-COMPLIANCE est quelque chose qui survient durant la mise en œuvre et non durant le lancement.

Une exigence pour tous les modules de MIB "standard" est qu’une spécification correspondante de MODULE-COMPLIANCE soit aussi définie, soit dans le même module d’informations soit dans un module d’information conjoint.

5.1	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 que cette spécification de MODULE-COMPLIANCE ne spécifie plus une définition de conformité valide. Bien que la valeur "déconseillé" indique aussi une définition obsolète, elle permet une utilisation nouvelle/continuée de la spécification de MODULE-COMPLIANCE.

5.2	Transposition de la clause DESCRIPTION
La clause DESCRIPTION, qui doit être présente, contient une définition textuelle de cette déclaration de conformité et devrait comprendre toute information qui serait autrement communiquée dans toutes annotations de commentaires ASN.1 associées à la déclaration.

5.3	Transposition de la clause REFERENCE
La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence textuelle croisée à un autre document, ou à un 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.

5.4	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 MIB pour lequel des exigences de conformité sont spécifiées. Chaque module de MIB est désigné par son nom de module, et facultativement, par son OBJECT IDENTIFIER associé. Le nom de module peut être omis lorsque l’invocation de MODULE-COMPLIANCE survient à l’intérieur d’un module de MIB, pour se référer au module de MIB qui le renferme.

5.4.1	Transposition de la clause MANDATORY-GROUPS
La clause MANDATORY-GROUPS, qui n’a pas besoin d’être présente, désigne le ou les objets ou groupes de notification au sein du module de MIB correspondant qui sont inconditionnellement obligatoires pour une mise en œuvre. Si un agent revendique la conformité au module de MIB, il doit alors mettre en œuvre chaque objet et notification au sein de chaque groupe de conformité figurant sur la liste. C’est à dire que si un agent retourne une exception noSuchObject en réponse à une opération d’obtention de protocole de gestion [4] pour tout objet d’un groupe de conformité obligatoire pour chaque vue de MIB possible, ou si l’agent ne peut pas générer chaque notification listée dans un groupe de conformité dans les circonstances appropriées, l’agent est alors une mise en œuvre non conforme au module de MIB.

5.4.2	Transposition de la clause GROUP
La clause GROUP, qui n’a pas besoin d’être présente, est utilisée de façon répétée pour désigner chaque objet et groupe de notification qui est conditionnellement obligatoire pour la conformité au module de MIB. La clause GROUP peut aussi être utilisée pour désigner des groupes facultatifs inconditionnels. Un groupe nommé dans une clause GROUP doit être absente de la clause MANDATORY-GROUPS correspondante.

Les groupes conditionnellement obligatoires incluent ceux qui ne sont obligatoires que si un protocole particulier est mis en œuvre, ou si un autre groupe est mis en œuvre. Une DESCRIPTION de clause GROUP spécifie les conditions dans lesquelles le groupe est conditionnellement obligatoire.

Un groupe qui n’est nommé ni dans une clause MANDATORY-GROUPS ni dans une clause GROUP, est inconditionnellement facultatif pour la conformité au module de MIB.

5.4.3	Transposition de la clause OBJECT
La clause OBJECT, qui n’a pas besoin d’être présente, est utilisée de façon répétée pour spécifier chaque objet de MIB pour lequel la conformité a une exigence raffinée par rapport à la définition du module de MIB. L’objet de MIB doit être présent dans un des groupes de conformité nommés dans la clause MANDATORY-GROUPS correspondante ou dans les clauses GROUP.

Par définition, chaque objet spécifié dans une clause OBJECT est une clause MODULE qui désigne le module d’information dans lequel cet objet est défini. Donc, l’utilisation d’une déclaration IMPORTS, pour spécifier d’où de tels objets sont importés, est redondante et n’est pas exigée dans un module d’information.

5.4.3.1	Transposition de la clause SYNTAX
La clause SYNTAX, qui n’a pas besoin d’être présente, est utilisée pour fournir une syntaxe raffinée pour l’objet désigné dans la clause OBJECT correspondante. Noter que si cette clause et une clause WRITE-SYNTAX sont toutes deux présentes, cette clause ne s’applique alors que lorsque des instances de cet objet désigné dans la clause OBJECT correspondante sont lues.

Consulter la Section 9 de [2] pour plus d’informations  sur les syntaxes raffinées.

5.4.3.2	Transposition de la clause WRITE-SYNTAX
La clause WRITE-SYNTAX, qui n’a pas besoin d’être présente, est utilisée pour fournir une syntaxe raffinée pour l’objet désigné dans la clause OBJECT correspondante lorsque des instances de cet objet sont écrites.

Consulter la Section 9 de [2] pour plus d’informations  sur les syntaxes raffinées.

5.4.3.3	Transposition de la clause MIN-ACCESS
La clause MIN-ACCESS, qui n’a pas besoin d’être présente, est utilisée pour définir le niveau minimal d’accès pour l’objet nommé dans la clause OBJECT correspondante. Si cette clause est absente, le niveau minimal d’accès est le même que le niveau maximal spécifié dans l’invocation correspondante de la macro OBJECT-TYPE. Si elle est présente, cette clause ne doit pas spécifier un niveau d’accès supérieur à celui spécifié dans l’invocation correspondante de la macro OBJECT-TYPE.

Pour certains types d’objets, le niveau d’accès est fixé conformément à leur définition de syntaxe. Ces types incluent : les tableaux et rangées conceptuelles, les objets auxiliaires, et les objets qui ont la syntaxe de Counter32, Counter64 (et éventuellement, certains types de conventions textuelles). Une clause MIN-ACCESS ne devrait pas être présente pour de tels objets.

Une mise en œuvre est conforme si le niveau d’accès qu’elle fournit est supérieur ou égal au niveau minimal dans la macro MODULE-COMPLIANCE et inférieur ou égal au niveau maximal dans la macro OBJECT-TYPE.

5.4.4	Transposition de la clause DESCRIPTION
La clause DESCRIPTION doit être présente pour chaque utilisation de la clause GROUP ou OBJECT. Pour une clause OBJECT, elle contient une description textuelle de l’exigence de conformité raffinée. Pour une clause GROUP, elle contient une description textuelle des conditions dans lesquelles le groupe est conditionnellement obligatoire ou inconditionnellement facultatif.

5.5	Transposition de la  MODULE-COMPLIANCE value
La valeur d’une invocation de la macro MODULE-COMPLIANCE est un OBJECT IDENTIFIER. Comme telle, cette valeur peut être utilisée d’autorité lorsqu’on se réfère à la déclaration de conformité incorporée par cette invocation de la macro.

5.6	Exemple d’utilisation
La déclaration de conformité contenue dans le MIB (hypothétique) XYZv2 pourrait être :

xyzMIBCompliance MODULE-COMPLIANCE
STATUS	courant
DESCRIPTION
"Déclaration de conformité pour les entités XYZv2 qui mettent en œuvre le MIB XYZv2."
MODULE  -- conformité au module de MIB contenant
MANDATORY-GROUPS { xyzSystemGroup, xyzStatsGroup, xyzTrapGroup, xyzSetGroup, xyzBasicNotificationsGroup }

GROUP	xyzV1Group
DESCRIPTION
"Le groupe xyzV1 n’est obligatoire que pour les entités XYZv2 qui mettent aussi en œuvre XYZv1."
::= { xyzMIBCompliances 1 }

Conformément à cette invocation, pour revendiquer l’alignement sur la déclaration de conformité nommée { xyzMIBCompliances 1 } un système doit mettre en œuvre les groupes de conformité des objets xyzSystemGroup, xyzStatsGroup, xyzTrapGroup, et xyzSetGroup du MIB XYZv2, ainsi que le groupe de notification xyzBasicNotificationsGroup. De plus, si l’entité XYZv2 met aussi en œuvre XYZv1, elle doit aussi prendre en charge le groupe XYZv1Group, si elle veut revendiquer la conformité.

6.	Transposition de la macro AGENT-CAPABILITIES

La macro AGENT-CAPABILITIES est utilisée pour convoyer un ensemble de capacités présentes chez un agent. Il faut noter que l’expansion de la macro AGENT-CAPABILITIES est quelque chose qui survient durant la mise en œuvre et non durant le lancement.

Lorsqu’un module de MIB est écrit, il est divisé en unités de conformité appelées groupes. Si un agent revendique la mise en œuvre d’un groupe, il doit alors mettre en œuvre chacun des objets, ou chacune des notifications, au sein de ce groupe. Bien sûr, pour une raison quelconque, un agent peut ne mettre en œuvre qu’un sous-ensemble des groupes au sein d’un module de MIB. De plus, la définition de certains objets/notifications de MIB laisse certains aspects de la définition à la discrétion du développeur.

L’expérience pratique a démontré la nécessité d’une description concise des capacités d’un agent par rapport à un ou plusieurs modules de MIB. La macro AGENT-CAPABILITIES permet à un agent de mise en œuvre de décrire le niveau précis de prise en charge que revendique un agent par rapport à un groupe de MIB, et de lier cette description à la valeur d’une instance de sysORID [3]. En particulier, certains objets peuvent avoir une syntaxe ou des niveaux d’accès restreints ou augmentés.

Si l’invocation AGENT-CAPABILITIES est donnée à une mise en œuvre de station de gestion, cette mise en œuvre peut construire des applications de gestion qui s’optimisent lorsqu’elles communiquent avec un agent particulier. Par exemple, la station de gestion peut entretenir une base de données de ces invocations. Lorsqu’une station de gestion interagit avec un agent, elle restitue à partir de l’agent les valeurs de toutes les instances de sysORID [3]. Sur cette base, elle consulte la base de données pour localiser chaque entrée qui correspond à une des valeurs restituées de sysORID. En utilisant les entrées localisées, l’application de gestion peut alors optimiser son comportement en conséquence.

Noter que la macro AGENT-CAPABILITIES spécifie des raffinements ou des variations par rapport aux macros OBJECT-TYPE et NOTIFICATION-TYPE dans les modules de MIB, et NON par rapport aux macros MODULE-COMPLIANCE dans les déclarations de conformité.

6.1	Transposition de la clause PRODUCT-RELEASE
La clause PRODUCT-RELEASE, qui doit être présente, contient une description textuelle de la livraison de produit qui comporte cet ensemble de capacités.

6.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 que cette déclaration de capacités n’est plus utilisée.

6.3	Transposition de la clause DESCRIPTION
La clause DESCRIPTION, qui doit être présente, contient une description textuelle de cet ensemble de capacités.

6.4	Transposition de la clause REFERENCE
La clause REFERENCE, qui n’a pas besoin d’être présente, contient une référence textuelle croisée à un autre document, ou un 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.

6.5	Transposition de la clause SUPPORTS
La clause SUPPORTS, qui n’a pas besoin d’être présente, est utilisée de façon répétée pour désigner chaque module de MIB pour lequel l’agent revendique une mise en œuvre complète ou partielle. Chaque module de MIB est désigné par son nom de module, et facultativement aussi, par son OBJECT IDENTIFIER associé (tel qu’enregistré par la macro MODULE-IDENTITY, voir [2]).

6.5.1	Transposition de la clause INCLUDES
La clause INCLUDES, qui doit suivre chacune des utilisations de la clause SUPPORTS, sert à désigner chaque groupe de MIB associé à la clause SUPPORTS, dont l'agent revendique la mise en œuvre.

6.5.2	Transposition de la clause VARIATION
La clause VARIATION, qui n’a pas besoin d’être présente, est utilisée de façon répétée pour désigner chaque objet ou notification que l’agent met en œuvre dans des variantes ou de façon raffinée par rapport à l’invocation correspondante de la macro OBJECT-TYPE ou NOTIFICATION-TYPE.

Noter que le concept de variation signifie des restrictions génériques de mise en œuvre, par exemple, si la variation pour un objet dépend des valeurs d’autres objets, cela devrait alors être noté dans la clause DESCRIPTION appropriée.

Par définition, chaque objet spécifié dans une clause VARIATION suit une clause SUPPORTS qui désigne le module d’information dans lequel cet objet est défini. Donc, l’utilisation d’une déclaration IMPORTS, pour spécifier d’où sont importés de tels objets, est redondante et n’est pas exigée dans un module d’information.

6.5.2.1	Transposition de la clause SYNTAX
La clause SYNTAX, qui n’a pas besoin d’être présente, est utilisée pour fournir un raffinement de syntaxe pour l’objet désigné dans la clause VARIATION correspondante. Noter que si cette clause et une clause WRITE-SYNTAX sont toutes deux présentes, cette clause ne s’applique alors que lorsque des instances de l’objet désigné dans la clause VARIATION correspondante sont lues.

Consulter la Section 9 de [2] pour plus d’informations sur les raffinements de syntaxe

Noter que pour les énumérations de INTEGER et pour la construction BITS, les changements permis lors de la mise à jour d’un module de MIB comportent l’ajout d’énumérations et/ou le changement des labels des énumérations existantes (voir le paragraphe 10.2 de [2]). Ce type de changement peut poser des problèmes avec une macro AGENT-CAPABILITIES écrite sur une ancienne révision d’un module de MIB. Une façon d’éviter de tels problèmes est de faire une liste explicite de tous les objets qui ont une syntaxe d’énumération dans une clause VARIATION, même lorsque toutes les énumérations sont actuellement prises en charge.

6.5.2.2	Transposition de la clause WRITE-SYNTAX
La clause WRITE-SYNTAX, qui n’a pas besoin d’être présente, est utilisée pour fournir un raffinement de syntaxe pour l’objet désigné dans la clause VARIATION correspondante lorsque des instances de cet objet sont écrites.

Consulter la Section 9 de [2] pour plus d’informations sur les raffinements de syntaxe.

6.5.2.3	Transposition de la clause ACCESS
La clause ACCESS, qui n’a pas besoin d’être présente, est utilisée pour indiquer que l’agent fournit moins que le niveau maximal d’accès à l’objet ou notification désigné dans la clause VARIATION correspondante.

La seule valeur applicable aux notifications est "non-mise-en-œuvre".

La valeur "non-mise-en-œuvre" indique que l’agent ne met pas en œuvre l’objet ou notification, et dans l’ordre des valeurs possibles est équivalente à "non-accessible".

La valeur "écriture-seule" n’est fournie que pour la rétro compatibilité, et ne doit pas être utilisée pour les types d’objet nouvellement définis. Dans l’ordre des valeurs possibles, "écriture-seule" est inférieur à "non-accessible".

6.5.2.4	Transposition de la clause CREATION-REQUIRES
La clause CREATION-REQUIRES, qui n’a pas besoin d’être présente, est utilisée pour désigner les objets de colonne d’une rangée conceptuelle à laquelle des valeurs doivent être explicitement allouées par une opération d’établissement du protocole de gestion, avant que l’agent ne permette que l’instance de la colonne état de cette rangée ne soit réglée à 'active'. (Consulter la définition de RowStatus [5].)

Si la rangée conceptuelle n’a pas de colonne état (c’est--dire, si les objets correspondant au tableau conceptuel ont été définis en utilisant les mécanismes de [6,7]), la clause CREATION-REQUIRES, qui n’a pas besoin d’être présente, est alors utilisée pour désigner les objets de colonne d’une rangée conceptuelle à laquelle des valeurs doivent être explicitement allouées, par une opération d’établissement du protocole de gestion, avant que l’agent ne crée de nouvelles instances des objets dans cette rangée.

Cette clause ne doit pas être présente sauf si l’objet désigné dans la clause VARIATION correspondante est une rangée conceptuelle, c’est-à-dire, a une syntaxe qui se résout en une SEQUENCE contenant des objets de colonne. Les objets désignés dans la valeur de cette clause vont habituellement se référer aux objets de colonne dans cette rangée. Cependant, des objets sans relation avec la rangée conceptuelle peuvent aussi être spécifiés.

Tous les objets qui sont désignés dans la clause CREATION-REQUIRES pour une rangée conceptuelle, et qui sont des objets de colonne de cette rangée, doivent avoir un niveau d’accès de "lecture-création".

6.5.2.5	Transposition de la clause DEFVAL
La clause DEFVAL, qui n’a pas besoin d’être présente, est utilisée pour fournir une valeur DEFVAL de remplacement pour l’objet désigné dans la clause VARIATION correspondante. La sémantique de cette valeur est identique à celle de la clause DEFVAL de la macro OBJECT-TYPE.

6.5.2.6	Transposition de la clause DESCRIPTION
La clause DESCRIPTION, qui doit être présente pour chaque utilisation de la clause VARIATION, contient une description textuelle de la variante ou raffinement de mise en œuvre de l’objet ou de la notification.

6.6	Transposition de la valeur AGENT-CAPABILITIES
La valeur d’une invocation de la macro AGENT-CAPABILITIES est un OBJECT IDENTIFIER, qui désigne la valeur de sysORID [3] pour laquelle cette déclaration de capacités est valide.

6.7	Exemple d’utilisation
Considérons comment peut être décrite une déclaration de capacités pour un agent :

exampleAgent AGENT-CAPABILITIES
    PRODUCT-RELEASE	"ACME Agent release 1.1 for 4BSD."
    STATUS	courant
    DESCRIPTION	"ACME agent for 4BSD."

    SUPPORTS	SNMPv2-MIB
        INCLUDES	{ systemGroup, snmpGroup, snmpSetGroup, snmpBasicNotificationsGroup }

        VARIATION	coldStart
            DESCRIPTION	"Un trap coldStart est généré sur tous les réamorçages."

    SUPPORTS	IF-MIB
        INCLUDES	{ ifGeneralGroup, ifPacketGroup }

        VARIATION	ifAdminStatus
            SYNTAX	INTEGER { up(1), down(2) }
            DESCRIPTION	"Incapable de régler le mode d’essai à 4BSD."

        VARIATION	ifOperStatus
            SYNTAX	INTEGER { up(1), down(2) }
            DESCRIPTION	"Information limités sur 4BSD."

    SUPPORTS	IP-MIB
        INCLUDES	{ ipGroup, icmpGroup }

        VARIATION	ipDefaultTTL
            SYNTAX	INTEGER (255..255)
            DESCRIPTION	"Câblage matériel en 4BSD."

        VARIATION	ipInAddrErrors
            ACCESS	non-mis-en-œuvre
            DESCRIPTION	"Information non disponible sur 4BSD."

        VARIATION	ipNetToMediaEntry
            CREATION-REQUIRES	{ ipNetToMediaPhysAddress }
            DESCRIPTION	"Les transpositions d’adresse sur 4BSD exigent les adresses de protocole et de support."

    SUPPORTS	TCP-MIB
        INCLUDES	{ tcpGroup }
        VARIATION	tcpConnState
         ACCESS	lecture-seule
         DESCRIPTION	"Incapable de se régler sur 4BSD."

    SUPPORTS	UDP-MIB
        INCLUDES	{ udpGroup }

    SUPPORTS	EVAL-MIB
        INCLUDES	{ functionsGroup, expressionsGroup }
        VARIATION	exprEntry
            CREATION-REQUIRES	{ evalString, evalStatus }
            DESCRIPTION	"La création de rangée conceptuelle est prise en charge."

    ::= { acmeAgents 1 }

Conformément à cette invocation, un agent avec une valeur sysORID de { acmeAgents 1 } accepte les objets définis dans six modules de MIB.

À partir du MIB SNMPv2, cinq groupes de conformité sont acceptés.

À partir du MIB IF, les groupes ifGeneralGroup et ifPacketGroup sont acceptés. Cependant, les objets ifAdminStatus et ifOperStatus ont une syntaxe restreinte.

À partir du MIB IP, tous les objets dans les groupes ipGroup et icmpGroup sont acceptés sauf ipInAddrErrors, alors que ipDefaultTTL a une gamme restreinte, et lors de la création d’une nouvelle instance dans le tableau ipNetToMediaTable, la demande d’établissement doit créer une instance de ipNetToMediaPhysAddress.

À partir du MIB TCP, le groupe tcpGroup est accepté sauf que tcpConnState n’est disponible qu’en lecture.

À partir du MIB UDP, le groupe udpGroup est pleinement accepté.

À partir du MIB EVAL, tous les objets contenus dans les groupes de conformité functionsGroup et expressionsGroup sont acceptés, sans variation. De plus, la création de nouvelles instances dans le tableau expr est accepté, et exige les deux objets : evalString et evalStatus, pour leur allouer une valeur.

7.	Extension d’un module d’information

Avec l’expérience de la publication d’un module d’information, il peut être souhaitable de réviser ce module d’information.

La Section 10 de [2] définit les règles d’extension d’un module d’information. Le reste de cette section définit comment peuvent être étendus les groupes de conformité, les déclarations de conformité, et les déclarations de capacités.

7.1	Groupes de conformité
Il peut être souhaitable de réviser la définition d’un groupe de conformité (un OBJECT-GROUP ou un NOTIFICATION-GROUP) après l’avoir expérimenté. Cependant, les groupes de conformité peuvent être référencés par des définitions de conformité et/ou de capacités. Donc, un changement à un groupe de conformité n’est pas permis si il pourrait éventuellement causer une différence de référence entre la définition originale du groupe et celle de la définition mise à jour. De tels changements ne peuvent s’accommoder que de la définition d’un nouveau groupe de conformité avec un nouveau descripteur et une nouvelle valeur de OBJECT IDENTIFIER.

Les révisions suivantes sont permises :

(1)	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". Lors d’un tel changement, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.
(2)	Une clause REFERENCE peut être ajoutée ou mise à jour.

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

(4)	Tout changement rédactionnel.
Il n’est pas nécessaire de changer la valeur STATUS d’un groupe de conformité quand le statut d’un membre du groupe est changé.

7.2	Définitions de conformité
Il peut être souhaitable de réviser la définition d’une définition de conformité (MODULE-COMPLIANCE) après l’avoir expérimentée. Cependant, les changements ne sont pas admis si ils causent une différence entre les exigences spécifiées par la définition originale et les exigences de la définition mise à jour. De tels changements ne peuvent s’accommoder que de la définition d’une nouvelle définition de conformité avec un nouveau descripteur et une nouvelle valeur d’OBJECT IDENTIFIER.

Les révisions suivantes sont permises :

(1)	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". Lors d’un tel changement, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.

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

(3)	Des éclaircissements et des informations supplémentaires peuvent être incluses dans la ou les clauses DESCRIPTION.

(4)	Tout changement rédactionnel.
	Il n’est pas nécessaire de changer la valeur de STATUS d’une définition de conformité du fait d’un changement de la valeur de STATUS d’une définition à laquelle il fait référence.
7.3	Définitions de capacités
Il peut être souhaitable de réviser la définition d’une définition de capacités (AGENT-CAPABILITIES) après en avoir fait l’expérience. Cependant, les changements ne sont pas admis si ils causent une différence entre les capacités spécifiées à l’origine et les capacités de la spécification mise à jour. De tels changements ne peuvent être traités qu’en définissant une nouvelle définition de capacités avec un nouveau descripteur et une nouvelle valeur d’OBJECT IDENTIFIER.

Les révisions suivantes sont admises :

(1)	Une valeur de clause STATUS de "courant" peut être révisée en "obsolète". Lors d’un tel changement, la clause DESCRIPTION devrait être mise à jour pour en expliquer la raison.
(2)	Une clause REFERENCE peut être ajoutée ou mise à jour.

(3)	Des éclaircissements et des informations supplémentaires peuvent être incluses dans la ou les clauses DESCRIPTION.

(4)	Tout changement rédactionnel.
	Il n’est pas nécessaire de changer la valeur de STATUS d’une définition de capacités du fait d’un changement de la valeur de STATUS d’une définition à laquelle il fait référence.
8.	Considérations pour la sécurité

Le présent document définit les moyens de définir des exigences de conformité pour la mise en œuvre des documents qui décrivent les informations de gestion. Cette méthode de définition des exigences de conformité n’a pas d’impact sur la sécurité de l’Internet.

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

10.	Références

[1]	Systèmes de traitement de l’information – Interconnexion des systèmes ouverts - Spécification de la notation de syntaxe abstraite n° 1 (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, "Structure des informations de gestion, version 2 (SMIv2)", STD 58, RFC 2578, avril 1999.

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

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

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

[6]	M. Rose et K. McCloghrie, "Structure et identification des informations de gestion pour les internets fondés sur TCP/IP", STD 16, RFC 1155, mai 1990.

[7]	M. Rose et K. McCloghrie, "Brèves définitions de MIB", STD 16, RFC 1212, mars 1991.

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

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

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.