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 |
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
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.
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).
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
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.
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.
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.
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.
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.
La valeur d’une invocation de la macro OBJECT-GROUP est le nom du groupe, qui est un OBJECT IDENTIFIER, un nom alloué administrativement.
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."
::= { snm pMIBGroups 8 }
Conformément à cette invocation, le groupe de conformité dénommé { snmpMIBGroups 8 } contient 7 objets.
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.
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.
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.
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.
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.
La valeur d’une invocation de la macro NOTIFICATION-GROUP est le nom du groupe, qui est un OBJECT IDENTIFIER, un nom alloué administrativement.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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é.
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é.
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.
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.
La clause DESCRIPTION, qui doit être présente, contient une description textuelle de cet ensemble de capacités.
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.
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]).
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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 |
[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.
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.