Équipe d'ingénierie de l'Internet (IETF)	V. Marinov, Jacobs University Bremen	
Request for Comments: 5675	J. Schoenwaelder, Jacobs University Bremen	
Catégorie : Sur la voie de la normalisation	octobre 2009	
ISSN: 2070-1721	Traduction Claude Brière de L'Isle	

Transposition des notifications du protocole simple de gestion de réseau (SNMP) en messages SYSLOG

Résumé
Le présent mémoire définit une transposition des notifications du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) en messages SYSLOG.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5675 

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Table des matières
1. Introduction	2
1.1 Conventions	2
2. Fondements	2
2.1 Notifications SNMP 	2
2.2 Notifications SYSLOG	3
3. Transposition des notifications SNMP en messages SYSLOG	4
3.1 En-tête SYSLOG	4
3.2 Données structurées	4
3.3 Données MSG	6
4. Relations à la SYSLOG-MSG-MIB	6
5. Exemple d'utilisation	7
6. Considérations relatives à l'IANA	8
7. Considérations sur la sécurité	8
8. Remerciements	9
9. Références	9
9.1 Références normatives	9
9.2 Références pour information	9
Adresse des auteurs	10

 	1.	Introduction

SNMP et SYSLOG sont deux protocoles largement utilisés pour communiquer les notifications d'événements. Bien que la coexistence de plusieurs protocoles de gestion dans un même environnement opérationnel soit possible, certains environnements exigent que toutes les notifications d'événement soient collectées par un seul automate de système, comme un collecteur SYSLOG ou un receveur de notification SNMP, via un seul protocole de gestion. Dans ces environnements, il est nécessaire de traduire les notifications d'événement entre les protocoles de gestion.

La dernière version de SYSLOG, spécifiée dans la [RFC5424], prend en charge un format d'élément de données structuré. Les éléments de données structurés permettent de transposer entre notifications SNMP et messages SYSLOG sans perdre d'information. Dans le présent mémoire, on spécifie une transposition concrète des notifications d'événement SNMP [RFC3416] en messages SYSLOG [RFC5424]. On spécifie comment le format de message SYSLOG devrait être utilisé pour porter les informations contenues dans un message de notification SNMP. Un nouvel élément de données structuré SYSLOG est défini, qui porte la portion PDU d'un message de notification SNMP.

 	1.1	Conventions
Un système qui a la capacité de recevoir les messages de notification SNMP d'un générateur de notification SNMP et d'envoyer les données SNMP contenues dans un format de message SYSLOG à un collecteur SYSLOG est appelé dans le présent mémoire un "traducteur de SNMP en SYSLOG". Par définition, un tel système devrait avoir une application de receveur de notification SNMP et un générateur SYSLOG afin d'être capable d'effectuer les fonctions d'un "traducteur de SNMP en SYSLOG".

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

 	2.	Fondements
 	2.1	Notifications SNMP
Une introduction détaillée au cadre de gestion SNMP se trouve dans la [RFC3410]. L'architecture de gestion SNMP est décrite dans la [RFC3411]. L'accès aux objets gérés est fait via un magasin virtuel d'informations, appelé la base de données d'informations de gestion (MIB, Management Information Base) [RFC3418]. Les objets dans la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information) [RFC2578].

Un message de notification SNMP est généré et transmis par une entité SNMP au nom d'une application génératrice de notifications [RFC3413]. Les notifications SNMP sont souvent utilisées pour notifier à une application de receveur de notifications sur une entité SNMP logiquement distante qu'un événement s'est produit ou qu'une certaine condition est présente. Il y a deux types d'opérations de protocole SNMP associées aux messages de notification SNMP [RFC3416] :
o	SNMPv2-Trap-PDU, un mécanisme de livraison de notification non confirmée,
o	InformRequest-PDU,  un mécanisme de livraison de notification confirmée.

La portion scopedPDU d'un message d'interruption ou d'information SNMPv3 a le format suivant [RFC3412] :

ScopedPDU ::= SEQUENCE {
    contextEngineID  CHAINE D'OCTETS,
    contextName        CHAINE D'OCTETS,
    data                       ANY -- par exemple, des PDU comme défini dans la [RFC3416]
}

Le membre data de la SEQUENCE ScopedPDU porte une SNMPv2-Trap-PDU ou une InformRequest-PDU. Elles ont toutes deux la même structure :

PDUs ::= [7] IMPLICIT SEQUENCE {
    request-id               ENTIER,
    error-status             ENTIER, 	-- ignoré dans les notifications
    error-index             ENTIER,	-- ignoré dans les notifications
    variable-bindings   VarBindList
 }

-- lien de variable

 VarBind ::= SEQUENCE {
     name ObjectName,

      CHOICE {
          value          ObjectSyntax,
          unSpecified    NULL,	-- dans les demandes de restitution
	-- par exception dans les réponses
          noSuchObject     [0] IMPLICIT NULL,
          noSuchInstance   [1] IMPLICIT NULL,
          endOfMibView   [2] IMPLICIT NULL
      }
 }

-- liste de lien de variable

 VarBindList ::= SEQUENCE (TAILLE (0..max-bindings)) DE VarBind

Les deux premiers liens de variable dans la liste de lien de variable d'une SNMPv2-Trap-PDU ou InformRequest-PDU sont sysUpTime.0 [RFC3418] et snmpTrapOID.0 [RFC3418], respectivement. Si la clause OBJECTS est présente dans l'invocation de la macro NOTIFICATION-TYPE correspondante, alors chaque variable correspondante, comme instanciée par cette notification, est copiée, dans l'ordre, dans le champ variable-bindings. Si des variables supplémentaires sont incluses (c'est une option de l'entité SNMP génératrice) alors chacune est copiée dans le champ variable-bindings.

Dans le cas de notifications SNMPv1 ou SNMPv2c, les paramètres contextEngineID et contextName ne sont pas présents dans les messages de notification.

Le présent document suppose que les notifications sont dans le format défini dans la [RFC3416]. Les notifications dans le format de notification SNMPv1 DOIVENT être traduites comme décrit au paragraphe 3.1 de la [RFC3584].

 	2.2	Notifications SYSLOG
Le protocole SYSLOG est défini dans la [RFC5424]. Le message contient un en-tête global et un certain nombre d'éléments de données structurés. La représentation ABNF [RFC5234] d'un message SYSLOG est définie dans la [RFC5424]. Les productions pertinentes pour les éléments de données structurés sont :

STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING	; les caractères '"', '\' et ; ']' DOIVENT être échappés.
SD-NAME = 1*32PRINTUSASCII 	; sauf '=', SP, ']', %d34 (")
UTF-8-STRING = *OCTET	; toute chaîne UTF-8 valide "de plus courte forme" DOIT être utilisée.
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NILVALUE = "-"

 	3.	Transposition des notifications SNMP en messages SYSLOG

Dans cette section, on définit comment la portion scopedPDU d'un message de notification SNMP est utilisée pour générer un message dans le format SYSLOG. L'application de receveur de notification au traducteur de SNMP en SYSLOG écoute les notifications entrantes. Après réception d'une notification par le moteur SNMP, la portion de données est transmise à l'application de receveur de notification. La portion de données contient la scopedPDU du message, qui est utilisée par le générateur SYSLOG sur le traducteur de SNMP en SYSLOG pour générer un message SYSLOG et l'envoyer à un collecteur (ou mandataire) SYSLOG. Noter que chaque notification SNMP se transpose en exactement un message SYSLOG.

   +-------------+              +------------------+
   |générateur de| notification |                  | message +----------+
   |notification |   SNMP       |  +------------+  | syslog  |collecteur|
   | SNMP        |------------->|  |générateur  |  |-------->|syslog    |
   +-------------+              |  |syslog      |  |         +----------+
   +-------------+              |  +------------+  |
   |générateur de| notification |  +------------+  | message +----------+
   |notification |   SNMP       |  |receveur de |  | syslog  |collecteur|
   | SNMP        |------------->|  |notification|  |-------->|syslog    |
   +-------------+              |  | SNMP       |  |         +----------+
   +-------------+              |  +------------+  |
   |générateur de| notification |                  |
   |notification |   SNMP       |  traducteur de   |
   | SNMP        |------------->|  SNMP en SYSLOG  |
   +-------------+              +------------------+

Figure 1 : Traducteur de SNMP en SYSLOG

Un scénario courant de déploiement est montré à la Figure 1. Il peut y avoir de nombreux générateurs de notifications SNMP qui envoient des notifications d'événement SNMP à un traducteur de SNMP en SYSLOG. Le traducteur de SNMP en SYSLOG extrait la portion de données de la notification, génère un message SYSLOG, et envoie le message SYSLOG à un collecteur SYSLOG, qui est chargé de collecter et mémoriser tous les messages de notification. Les flèches dans la Figure 1 indiquent les flux de messages, et non les messages individuels.

Le traducteur de SNMP en SYSLOG n'est pas transparent pour un collecteur SYSLOG. L'en-tête global du message SYSLOG généré par le traducteur SNMP en SYSLOG est rempli avec des paramètres spécifiques du système qui utilise le traducteur de SNMP en SYSLOG, comme son nom d'hôte, l'horodatage, etc. La portion de données (scopedPDU pour SNMPv3 ou PDU pour SNMPv1/SNMPv2c) du message de notification SNMP est contenue dans les données structurées du message SYSLOG.

Les mises en œuvre DOIVENT éliminer les messages SNMP invalides avant qu'ils soient passés au traducteur de SNMP en SYSLOG.

 	3.1	En-tête SYSLOG
Le traducteur de SNMP en SYSLOG remplit le champ HEADER d'un message SYSLOG avec les paramètres spécifiques du système sur lequel il fonctionne. Le niveau de facilité par défaut pour les messages SYSLOG qui contiennent des notifications SNMP DEVRAIT être 3, qui correspond aux messages générés par les automates de système. Le niveau de sévérité par défaut DEVRAIT être 5, qui correspond à "Remarque : condition normale mais significative". Si le traducteur de SNMP en SYSLOG a une notion du type de notification qui a été reçue, il pourrait choisir d'autres valeurs pour le niveau de facilité et de sévérité.

Les champs VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, et MSGID dans l'en-tête de message SYSLOG sont remplis avec des valeurs spécifiques du système sur lequel fonctionne le traducteur de SNMP en SYSLOG. Le jeu de caractères utilisé dans le champ HEADER DOIT être de l'ASCII à sept bits dans un champ de huit bits, comme décrit dans la [RFC5424].

 	3.2	Données structurées
Le champ STRUCTURED-DATA d'un message SYSLOG porte la portion ScopedPDU (ou PDU) d'un message de notification SNMP. Pour les besoins du portage des données de notification SNMP, un nouvel élément SD-ID est défini. La représentation ABNF [RFC5234] du nouvel élément structuré est :

SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
SNMP-SD-ID = %x73.6E.6D.70	; snmp
CTX = CTXENGINE CTXNAME
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
VARNAME = %d118 NUM "=" %d34 OID %d34	; "vN="
VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34	; "lN="
VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64 / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL / VALOPAQUE / VALTIMETICKS / VALSTRING
VALOID = %d111 NUM "=" %d34 OID %d34	; "oN="
VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34	; "xN="
VALCOUNTER32 = %d99  NUM "=" %d34 UNSIGNED32 %d34	; "cN="
VALCOUNTER64 = %d67  NUM "=" %d34 UNSIGNED64 %d34	; "CN="
VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34	; "uN="
VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34	; "dN="
VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34	; "iN="
VALNULL = %d110 NUM "=" %d34 %d34	; "nN="
VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 	; "pN="
VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34	; "tN="
VALSTRING = %d97  NUM "=" %d34 PARAM-VALUE %d34	; "aN="

NUM = NONZERODIGIT 0*DIGIT

OID = OIDSTART *("." OIDSUBID)
OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)

PARAM-VALUE = UTF-8-STRING	; les caractères '"', '\' et ']' DOIVENT être échappés.
UTF-8-STRING = *OCTET	; toute chaîne VALIDE UTF-8 "de plus courte forme" DOIT être utilisée.
HEXSTRING = *HEX

INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
UNSIGNED32 = NONZERODIGIT 0*DIGIT
UNSIGNED64 = NONZERODIGIT 0*DIGIT
IPV4ADDRESS = d8 "." d8 "." d8 "." d8

d8 = DIGIT    	; 0-9
         / %d49-57 DIGIT	; 10-99
         / "1" 2DIGIT	; 100-199
         / "2" %d48-52 DIGIT	; 200-249
         / "25" %d48-53	; 250-255

HEX  = DIGIT / %x41-46 / %x61-66	; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57
ZERO = %d48
DIGIT = ZERO / NONZERODIGIT
SP = %d32

Chaque SNMP-SD-ELEMENT commence par le SD-ID "snmp". Les deux premiers paramètres SD-ID sont "ctxEngine" et "ctxName". Le contexte DOIT être présent dans une notification SNMPv3 et donc "ctxEngine" et "ctxName" DOIVENT être présents dans un message SYSLOG généré par un traducteur de SNMP en SYSLOG provenant d'une notification SNMPv3. Le contextEngineID est codé comme une chaîne hexadécimale tandis que le contextName est codé comme chaîne UTF8.

Les paramètres restants dans le SD-ID "snmp" correspondent aux éléments de la liste varbind contenus dans la PDU SNMP. Le nom d'un varbind est codé comme un OID dans la notation à points. L'OID rendu est porté dans un paramètre "vN", où N identifie la position du varbind dans la liste de varbind du message SNMP (le premier varbind ayant la position  1). Une mise en œuvre conforme à la MIB peut en plus générer un paramètre "lN" portant le descripteur de l'objet de MIB associé plus le suffixe d'identifiant d'instance (aussi appelé une étiquette d'OID). Le nombre N identifie là encore la position du varbind dans la liste de varbind du message SNMP.

La valeur d'un varbind est codée selon son type conformément aux règles données dans le Tableau 1, et des noms de paramètre spécifiques du type sont utilisés pour porter les informations de type. Le nombre N identifie la position du varbind dans la liste de varbind du message SNMP. Une mise en œuvre conforme à la MIB peut de plus générer un paramètre "aN" portant une représentation textuelle de remplacement de la valeur, qui est obtenue en appliquant des DISPLAY-HINT et en traduisant les nombres désignés en les étiquettes correspondantes ou les valeurs d'IDENTIFIANT D'OBJET en descripteurs. Pour les types d'objet SNMP qui ont un DISPLAY-HINT de la forme "Ma" ou "Mt", où M est un nombre, une mise en œuvre conforme à la MIB peut choisir d'inclure le paramètre "aN" et de supprimer le paramètre "xN" correspondant. Ce cas particulier économise de l'espace pour les objets textuels. Un receveur qui reçoit un paramètre "aN" sans une valeur correspondant à la position N peut sans ambiguïté reconvertir la valeur portée dans le paramètre "aN" en une valeur de CHAINE D'OCTETS.

Alors que l'inclusion de paramètres supplémentaires portant des étiquettes d'OID ou des représentations de valeurs de remplacement augmente la lisibilité pour l'homme, cela se fait au prix d'une augmentation de la taille de message, qui peut causer la troncature des messages SYSLOG. Donc, les mises en œuvre DEVRAIENT fournir un mécanisme de configuration pour activer/désactiver la génération de paramètres portant des étiquettes d'OID ou des représentations de valeurs de remplacement.

Type SNMP	Nom de paramètre	Codage de la valeur
IDENTIFIANT D'OBJET	oN	notation en décimal séparé par des points
CHAINE D'OCTETS	xN	chaîne hexadécimale
Counter32	cN	nombre décimal non signé
Counter64	CN	nombre décimal non signé
Unsigned32	uN	nombre décimal non signé
ENTIER, Integer32	dN	nombre décimal signé
IpAddress	iN	notation quadratique séparée par des points
Opaque	pN	chaîne hexadécimale (BER)
TimeTicks	tN	nombre décimal non signé
NULL	nN	chaîne de longueur zéro

Tableau 1 : Transposition des types SNMP en paramètres SD

Le message SYSLOG généré par le traducteur de SNMP en SYSLOG peut, en plus de SNMP-SD-ELEMENT, inclure d'autres éléments de données structurés dans sa partie de données structurée. Ces éléments de données structurés supplémentaires DOIVENT se conformer à la spécification de la [RFC5424].

En particulier, les paramètres dans le SD-ID "origin" DEVRAIENT identifier le générateur de la notification SNMP. Une valeur convenable pour le paramètre "ip" PEUT être prise du varbind snmpTrapAddress si il est présent, et une valeur convenable pour le paramètre "enterpriseId" PEUT être extraite du varbind snmpTrapOID.

 	3.3	Données MSG
La partie MSG du message SYSLOG est facultative et peut contenir un message de forme libre qui fournit une description textuelle de la notification d'événement SNMP. Conformément à la [RFC5424], le jeu de caractères utilisé dans MSG DEVRAIT être Unicode, codé en utilisant l'UTF-8 comme spécifié dans la [RFC3629]. Si le générateur ne peut pas coder le MSG en Unicode, il PEUT utiliser tout autre codage. Le générateur PEUT utiliser les paramètres "language" définis dans la [RFC5424] pour porter les informations sur le langage naturel utilisé dans MSG.

 	4.	Relations à la SYSLOG-MSG-MIB

Un document d'accompagnement [RFC5676] définit un module de MIB SNMP pour représenter les messages SYSLOG et pour envoyer des messages SYSLOG comme notifications SNMP aux receveurs de notification SNMP. Cette section discute des possibilités d'utiliser les deux spécifications combinées.

Un collecteur SYSLOG qui met en œuvre le module SYSLOG-MSG-MIB et la transposition des notifications SNMP en messages SYSLOG peut être configuré à traduire les messages SYSLOG reçus qui contiennent des notifications SNMP en la notification SNMP originale. Dans ce cas, les tableaux pertinents de la SYSLOG-MSG-MIB ne vont pas être remplis pour les messages SYSLOG portant des notifications SNMP. Cette configuration permet aux opérateurs de construire une chaîne de transmission où les notifications SNMP sont "tunnelées" à travers les messages SYSLOG. Du fait des restrictions de taille des transports SYSLOG et du codage textuel plus verbeux utilisé par SYSLOG, il est possible que le contenu de la notification SNMP soit tronqué quand il est tunnelé à travers SYSLOG, et donc la notification SNMP résultante peut être incomplète.

Une application de gestion SNMP qui prend en charge la SYSLOG-MSG-MIB et la transposition de notifications SNMP en messages SYSLOG peut traiter les informations provenant de la SYSLOG-MSG-MIB afin d'émettre un message SYSLOG représentant le message SYSLOG enregistré dans le module de SYSLOG-MSG-MIB. Cette configuration permet aux opérateurs de construire une chaîne de transmission où les messages SYSLOG sont "tunnelés" à travers les messages SNMP. Un receveur de notification peut déterminer si une syslogMsgNotification contenait tous les paramètres d'élément de données structuré d'un message SYSLOG. En cas de paramètres manquants, une application transmetteuse DOIT restituer les paramètres manquants de la SYSLOG-MSG-MIB. L'interrogation régulière de la SYSLOG-MSG-MIB peut être utilisée pour traiter toute notification SNMP perdue.

 	5.	Exemple d'utilisation

On donne ici un exemple de la façon dont un message d'interruption SNMP linkUp est transposé en un message SYSLOG en utilisant les transpositions définies aux paragraphes 3.1 et 3.2.

La notification linkUp est définie comme suit dans la [RFC2863] :

linkUp NOTIFICATION-TYPE
       OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
       STATUS  current

DESCRIPTION : "Une interruption linkUp signifie que l'entité SNMP, agissant dans un rôle d'agent, a détecté que l'objet ifOperStatus pour une de ses liaisons de communication a quitté l'état "down" et est passée à un autre état (mais pas dans l'état notPresent). Cet autre état est indiqué par la valeur incluse de ifOperStatus."
::= { snmpTraps 4 }

La portion scopedPDU d'une interruption SNMP linkUp envoyée en utilisant le format de message SNMPv3 est montrée ci-dessous (la colonne de gauche montre le codage dans les règles de codage de base (BER, Basic Encoding Rules) tandis que la colonne de droite indique les définitions ASN.1 correspondantes) :

30:7C	SEQUENCE {
   04:08:80:00:02:B8:04:61:62:63	800002b804616263
   04:04:63:74:78:31	"ctx1"
   A7:6A	SNMPv2-Trap-PDU {
      02:03:6D:08:67	ENTIER 7145575
      02:01:00	ENTIER 0
      02:01:00	ENTIER 0
      30:5D	SEQUENCE OF {
         30:0F	SEQUENCE {
            06:08:2B:06:01:02:01:01:03:00	sysUpTime.0
            43:03:01:72:8C	94860 }
         30:17	SEQUENCE {
            06:0A:2B:06:01:06:03:01:01:04:01:00	snmpTrapOID.0
            06:09:2B:06:01:06:03:01:01:05:04	linkUp }
         30:0F	SEQUENCE {
            06:0A:2B:06:01:02:01:02:02:01:01:03	ifIndex.3
            02:01:03	3 }
         30:0F	SEQUENCE {
            06:0A:2B:06:01:02:01:02:02:01:07:03	ifAdminStatus.3
            02:01:01	up(1) }
         30:0F	SEQUENCE {
            06:0A:2B:06:01:02:01:02:02:01:08:03	ifOperStatus.3
            02:01:01	up(1) } } } }

Le message SYSLOG correspondant généré par le traducteur de SNMP en SYSLOG est montré ci-dessous. (On devrait considérer que les exemples SYSLOG sont sur une ligne. Ils sont indiqués sur plusieurs lignes dans ce document seulement pour des questions de lisibilité.)

<29>1 2003-10-11T22:14:15.003Z mymachine.exemple.com snmptrapd - ID47
  [snmp ctxEngine="800002b804616263" ctxName="ctx1"
    v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
    v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
      o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
    v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
    v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up"
    v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"]

Le message SYSLOG correspondant a une valeur de priorité de 29, ce qui signifie un niveau de facilité de 3 (automates systèmes) et un niveau de sévérité de 5 (Remarque : condition normale mais significative) conformément à l'algorithme pour calculer la valeur de priorité spécifiée au paragraphe 6.2.1 de la [RFC5424]. Le reste des champs dans l'en-tête du message SYSLOG sont des paramètres spécifiques du système de traducteur de SNMP en SYSLOG. La version SYSLOG est 1 et le message a été généré à 22:14:15.003Z le 2003-10-11T par l'hôte "mymachine.exemple.com". L'application sur le traducteur de SNMP en SYSLOG qui a généré le message était "snmptrapd" ; il n'y a pas d'information sur l'identifiant du processus, et le message sur le système de SNMP en SYSLOG est identifié avec l'identifiant de message de ID47.

Le message SYSLOG contient un élément de données structurées avec un SD-ID de "snmp", ce qui signifie que ceci est la portion scopedPDU d'un message de notification d'événement SNMP. Les données qui sont contenues dans la notification sont associées au ContextEngineID "123456" et au ContextName "ctx1". L'identifiant de demande du message de notification SNMP était "7145575". Suit ensuite la portion de données de la scopedPDU. Les deux premières variables contenues dans la portion de données sont toujours sysUpTime.0 et snmpTrapOID.0. Un snmpTrapOID.0 avec une valeur de "1.3.6.1.6.3.1.1.5.4" signifie que c'est une interruption linkUp. Les paramètres v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" signifient que le message de notification SNMP porte l'objet ifIndex, qui a un type de ENTIER et une valeur de 3. Les paramètres v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" signifient que le message de notification SNMP porte l'objet ifAdminStatus, qui a un type ENTIER et une valeur de 1. Les paramètres v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" signifient que le message de notification SNMP porte l'objet ifOperStatus, qui a un type ENTIER et une valeur de "1".

 	6.	Considérations relatives à l'IANA

L'IANA a enregistré la valeur de SD-ID "snmp" avec les valeurs de PARAM-NAME spécifiées au paragraphe 3.2 dans le registre des valeurs d'identifiant de données structurées SYSLOG conformément à la Section 9 de la [RFC5424]. La notation <N> indique un numéro de position.

SD-ID	PARAM-NAME
snmp	FACULTATIF
                           ctxEngine	FACULTATIF
                           ctxName	FACULTATIF
                           v<N> 	FACULTATIF
                           l<N>	FACULTATIF
                           o<N>	FACULTATIF
                           x<N>	FACULTATIF
                           c<N>	FACULTATIF
                           C<N>	FACULTATIF
                           u<N> 	FACULTATIF
                           d<N>	FACULTATIF
                           i<N>	FACULTATIF
                           n<N>	FACULTATIF
                           p<N>	FACULTATIF
                           t<N> 	FACULTATIF
                           a<N>	FACULTATIF

 	7.	Considérations sur la sécurité

Les considérations sur la sécurité discutées dans la [RFC5424] s'appliquent au présent document.

L'architecture SNMP prend en charge un mécanisme de contrôle d'accès, qui assure que les notifications SNMP sont seulement envoyées aux receveurs autorisés à recevoir la notification. Les opérateurs de réseau qui utilisent cette transposition de notifications SNMP en messages SYSLOG devraient appliquer une politique cohérente, empêchant les gens d'accéder aux notifications SNMP qui ne seraient autrement pas accessibles via la transposition SYSLOG.

 	8.	Remerciements

Les éditeurs souhaitent remercier les personnes suivantes qui ont fourni d'utiles commentaires sur les diverses versions de ce document : Martin Bjorklund, Washam Fan, Rainer Gerhards, Tom Petch, et Dan Romascanu.

 	9.	Références
 	9.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC3411]	D. Harrington, R. Presuhn, B. Wijnen, "Architecture de description des cadres de gestion du protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC5343) (STD0062)

[RFC3412]	J. Case et autres, "Traitement et distribution de message pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3413]	D. Levi, P. Meyer et B. Stewart, "Applications du protocole simple de gestion de réseau (SNMP)", STD 62, décembre  2002.

[RFC3416]	R. Presuhn, éd., "Version 2 des opérations de protocole pour le protocole simple de gestion de réseau (SNMP)", décembre  2002. (STD0062)

[RFC3418]	R. Presuhn, éd., "Base de données d'informations de gestion (MIB) pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3584]	R. Frye et autres, "Coexistence entre version 1, version 2, et version 3 du cadre de gestion de réseau standard de l'Internet", août 2003. (BCP0074)

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", DOI 10.17487/RFC5234, janvier 2008. (STD0068)

[RFC5424]	R. Gerhards, "Le protocole Syslog", mars 2009. (Remplace la RFC3164, P. S.)

[RFC5676]	J. Schoenwaelder, A. Clemm, A. Karmakar, "Définitions des objets gérés pour la transposition des messages SYSLOG en notifications du protocole simple de gestion de réseau (SNMP)", octobre 2009. (P. S.)

 	9.2	Références pour information

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

[RFC2863]	K. McCloghrie, F. Kastenholz, "MIB de groupe Interfaces", juin 2000. (D.S. ; MàJ par RFC8892)

[RFC3410]	J. Case et autres, "Introduction et déclarations d'applicabilité pour le cadre de gestion standard de l'Internet", décembre  2002. (Information)

 	Adresse des auteurs

Vladislav Marinov	Juergen Schoenwaelder	
Jacobs University Bremen	Jacobs University Bremen	
Campus Ring 1	Campus Ring 1	
28725 Bremen	28725 Bremen	
Germany	Germany	
mél : v.marinov@jacobs-university.de	mél : j.schoenwaelder@jacobs-university.de