Groupe de travail Réseau	S. Channabasappa, CableLabs
Request for Comments : 5428	W. De Ketelaere, tComLabs
Catégorie : Sur la voie de la normalisation	E. Nechamkin, Broadcom Corp.
Traduction Claude Brière de L'Isle	avril 2009

Base de données d'informations de gestion (MIB) d'événement pour appareils conformes à PacketCable et à IPCablecom

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

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.

Résumé
Le présent mémoire définit une portion de la base de données d'informations de gestion (MIB, Management Information Base) à utiliser avec les protocoles de gestion de réseau dans la communauté de l'Internet. En particulier, il définit un ensemble de base d'objets gérés pour la gestion d'événements fondés sur le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) qui peuvent être générés par des appareils d'adaptateur de terminal multimédia conformes à PacketCable et à IPCablecom.
Table des matières
1. Cadre de gestion standard de l'Internet	2
2. Introduction	2
3. Terminologie	2
3.1 PacketCable	2
3.2 IPCablecom	2
3.3 MTA	3
3.4 Point d'extrémité	3
3.5 MSO	3
3.6 UDP	3
4. Vue d'ensemble	3
4.1 Structure de la MIB	4
4.2 pktcEventControl	4
4.3 pktcEventThrottle	4
4.4 pktcEventStatus	5
4.5 pktcEvent	5
4.6 pktcEventLog	5
4.7 pktcEventNotifications	5
5. Relations aux autres modules de MIB	5
5.1 Modules de MIB exigés pour IMPORTS	5
6. Définitions	5
7. Considérations relatives à l’IANA	19
8. Considérations sur la sécurité	19
9. Remerciements	20
10. Références normatives	20
11. Références pour information	21
Adresse des auteurs	21
 	1.	Cadre de gestion standard de l'Internet

Pour une vue détaillée des documents qui décrivent le cadre actuel de gestion standard de l'Internet, se reporter à la Section  7 de la [RFC3410].

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). On accède généralement aux objets de MIB par le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets de la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB conforme à SMIv2, qui est décrit dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

 	2.	Introduction

Un adaptateur de terminal multimédia (MTA, Multimedia Terminal Adapter) est utilisé pour livrer l'accès à l'Internet haut débit, les données, et/ou la voix conjointement au service de téléphonie à des locaux d'abonnés ou consommateurs qui utilisent une infrastructure de réseau par câble. Un MTA est normalement installé dans les locaux de l'abonné ou consommateur et est couplé à un opérateur de système multiple (MSO, Multiple System Operator) en utilisant un réseau d'accès hybride fibre coaxial (HFC, Hybrid Fiber Coax).

Un MTA est provisionné par le MSO pour le service d'Internet large bande, de données, et/ou de voix. Pour plus d'informations sur le provisionnement de MTA, se reporter à [PKT-SP-PROV] et à la [RFC4682]. Les appareils de MTA incluent un ou plusieurs points d'extrémité (par exemple, des accès téléphoniques) qui reçoivent les informations de signalisation d'appel pour établir la cadence de sonnerie, et les codecs, qui fournissent le service de téléphonie.

Pour plus d'informations sur la signalisation d'appel, voir [PKT-SP-MGCP] et la [RFC3435].

Pour plus d'informations sur les codecs, voir [PKT-SP-CODEC].

Étant donnée la complexité de ces systèmes, il est important qu'un mécanisme convenable de gestion d'événement soit défini pour permettre la gestion effective. Ce module de MIB fournit des objets convenables pour la génération et la gestion des événements sur le MTA.

 	3.	Terminologie

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

Les termes "module de MIB" et "module d'information" sont utilisés de manière interchangeable dans le présent mémoire. Comme ils sont utilisés ici, les deux termes se réfèrent à un des trois types de modules d'information définis à la Section 3 de la [RFC2578]. Certains des termes utilisés dans ce mémoire sont définis ci-dessous. Certains termes supplémentaires sont aussi définis dans la spécification du mécanisme d'événement de gestion de PacketCable(TM) [PKT-SP-MEM1.5] dans la spécification de provisionnement d'appareil de MTA de PacketCable [PKT-SP-PROV].

 	3.1	PacketCable
PacketCable est une initiative conduite par CableLabs qui vise à développer des spécifications d'interface interopérable pour fournir des services avancés de multimédia en temps réel sur des systèmes de câbles bidirectionnels.

 	3.2	IPCablecom
IPCablecom est un projet de l'union internationale des Télécommunications, secteur de la normalisation (UIT-T) qui comporte une architecture et une série de recommandations qui permettent la livraison de services en temps réel sur les réseaux de télévision par câble utilisant des modems câbles.

 	3.3	MTA
Un adaptateur de terminal multimédia (MTA, Multimedia Terminal Adapter) est un appareil conforme à PacketCable ou IPCablecom qui fournit des services de téléphonie sur un système de câble ou hybride utilisé pour livrer des signaux vidéo à une communauté. Il contient une interface à des points d'extrémité, une interface réseau, des codecs, et toutes les fonctions de signalisation et d'encapsulation requises pour le transport de la voix sur IP, la signalisation d'appel, et la signalisation de qualité de service. Un MTA peut être un appareil incorporé ou autonome. Un MTA incorporé (E-MTA) est un appareil de MTA qui contient un modem câble incorporé de spécifications d'interface de service du système de transmission de données par câble (DOCSIS, Data Over Cable Service Interface Specifications). Un MTA autonome (S-MTA) est un appareil de MTA séparé du modem câble DOCSIS par une interface non DOCSIS de contrôle d'accès au support (MAC, Media Access Control) (par exemple, Ethernet, USB).

 	3.4	Point d'extrémité
Un point d'extrémité ou MTA de point d'extrémité est un accès physique standard de téléphonie RJ-11 situé sur le MTA et qui est utilisé pour rattacher l'appareil téléphonique au MTA.

 	3.5	MSO
Un opérateur multi systèmes (MSO, Multi-System Operator) est une compagnie de câbles qui gère de nombreuses localisations d'extrémités de tête dans plusieurs villes.

 	3.6	UDP
Le protocole de datagrammes d'utilisateur (UDP, User Datagram Protocol) est un protocole sans connexion construit par dessus le protocole Internet (IP, Internet Protocol) conformément à la [RFC0768].

 	4.	Vue d'ensemble

Les adaptateurs de terminal multimédia (MTA) conformes à IPCablecom de PacketCable, de l'Institut Européen des normes de télécommunications (ETSI, European Telecommunications Standards Institute) et de l'Union Internationale des télécommunications, secteur de la normalisation (UIT-T, International Telecommunication Union Telecommunication Standardization Sector) sont obligés de générer des événements de gestion en présence de l'occurrence de certaines conditions de fonctionnement (par exemple, "défaillance d'alimentation AC, MTA fonctionnant sur batterie"). L'ensemble complet de conditions et les événements de gestion correspondants à générer sont spécifiés dans [PKT-SP-MEM1.5] (PacketCable), [ETSITS101909-22] (ETSI), et [ITU-T-J176] (UIT-T). De plus, le fabricant de MTA peut spécifier des événements de gestion spécifiques du fabricant. Par exemple, le fabricant XYZ peut spécifier "Erreur de lecture de mémoire, terminaison de processus, code : XYZ123".

Quand des événements de gestion sont générés, ils peuvent être mémorisés dans un enregistrement local sur le MTA ou transmis en utilisant deux mécanismes possibles : SNMP ou syslog. Ce choix entre mémorisation et transmission doit être configurable et gérable par la station de gestion pour chaque événement de gestion (les valeurs par défaut peuvent être fournies quand les événements sont définis). Le présent document propose une MIB qui peut fournir la configuration et la gestion de tels événements de gestion. Un moyen d'enregistrer les événements est fourni dans le module de MIB spécifié. Pour un transport syslog, les informations nécessaires (format, transport, etc.) sont aussi spécifiées. Pour un transport SNMP, les objets de MIB spécifiés dans la SNMP-TARGET-MIB et SNMP-NOTIFICATION-MIB comme utilisés, sont spécifiés dans la [RFC3413].

De plus, chaque événement de gestion peut être identifié de façon univoque en utilisant l'identifiant d'organisation et l'identifiant d'événement. L'identifiant d'organisation est le numéro d'entreprise privée de l'organisation qui spécifie l'événement (par exemple, 4491 pour CableLabs) et un identifiant univoque qui identifie l'événement. L'identifiant d'événement identifie de façon univoque l'événement au sein de l'espace d'identifiant d'organisation. Le présent document ne spécifie aucun événement de gestion. Il fournit seulement un mécanisme pour gérer la mémorisation et la transmission des événements.

Le module de MIB EVENT spécifié dans ce document est destiné à mettre à jour les modules de MIB EVENT dont il est partiellement dérivé :
-	la spécification de MIB d'événement de gestion PacketCable 1.5 [PKT-SP-EVEMIB1.5] et
- les exigences pour une MIB de mécanisme d'événement de gestion UIT-T IPCablecom [ITU-T-J176].

Plusieurs références normatives et pour information sont utilisées pour aider à définir les objets de MIB d'événement de gestion. Par convention, chaque fois que les exigences sont équivalentes au moment de la rédaction, la référence PacketCable est utilisée. Cependant, les mises en œuvre de MTA DOIVENT se référer aux spécifications correspondantes pour s'assurer de la conformité.

 	4.1	Structure de la MIB
Le module de MIB Événement de gestion est identifié par pktcIetfEventMib et est structuré dans les sous arborescences suivantes :
- pktcEventControl spécifie les informations de gestion pertinentes pour le contrôle des capacités de génération d'événement de l'appareil.
- pktcEventThrottle spécifie les informations de gestion pertinentes pour modérer la transmission des événements de gestion en utilisant syslog ou SNMP.
- pktcEventStatus spécifie les informations de gestion pour que l'appareil rapporte les information d'état relatives aux événements générés.
- pktcEvents spécifie les informations de gestion pour que l'appareil fasse la liste de tous les événements qu'il est capable de générer.
- pktcEventLog spécifie les informations de gestion pour que l'appareil mémorise les événements générés.
- pktcEventNotifications spécifie les informations de gestion qui définissent l'alerte SNMP et les messages d'information.

 	4.2	pktcEventControl
Le groupe des objets dans cette sous arborescence fournit trois contrôles importants : la capacité de réinitialiser les enregistrements d'événement et les descriptions d'événement, la configuration syslog, et les classes d'événements.

Les événement importants sont les suivants :

pktcEventReset - cet objet de MIB permet à une station de gestion de réinitialiser les enregistrements d'événement, les descriptions d'événement , ou les deux.

pktcEventSyslog - ce groupe d'objets de MIB permet à la station de gestion de fournir des informations pour la transmission des événements à un serveur syslog, comme les formats de message et les protocoles de transport.

pktcEventClassTable - ce tableau de MIB permet aux MTA de classer les événements de gestion dans différentes catégories, appelées des "classes d'événements". Il permet ensuite aux opérations communes d'être affectées à travers tous les événements relevant d'une classe d'événements spécifique.

 	4.3	pktcEventThrottle
Comme indiqué précédemment, les événements générés peuvent être mémorisés localement ou transmis en utilisant SNMP, syslog, ou les deux. Cependant, les stations de gestion qui reçoivent de tels événements peuvent souhaiter contrôler le taux de transmission de ces événements. Ce comportement de réduction d'événements est fourni par les objets de MIB dans cette sous arborescence.

Certains points marquants sont :

pktcEventThrottleAdminStatus - cet objet de MIB permet des transmissions sans contraintes, maintenues en dessous d'un seuil, arrêtées au seuil, ou inhibées.

pktcEventThrottleThreshold - cet objet de MIB spécifie le modérateur, c'est-à-dire, le nombre d'événements sur un intervalle qui est considéré être le seuil.

pktcEventThrottleInterval - cet objet de MIB spécifie l'intervalle sur lequel le seuil est calculé.

 	4.4	pktcEventStatus
Cette sous arborescence est conçue pour fournir des informations d'état relatives aux transmissions d'événement. Elle contient actuellement un objet de MIB, pktcEventTransmissionStatus, qui permet à un client de rapporter l'état des transmissions d'événement.

 	4.5	pktcEvent
Cette sous arborescence est conçue pour fournir une liste de tous les événements qui peuvent être générés par un MTA et ses descriptions associées. Les objets de MIB sont groupés sous le tableau de MIB pktcEventTable.

 	4.6	pktcEventLog
Cette sous arborescence est conçue pour permettre au MTA de mémoriser tous les événements qui sont générés durant son fonctionnement. Les événements sont mémorisés avec des informations comme l'heure de l'événement, sa description et les caractéristiques en rapport, comme les niveaux de sévérité.

 	4.7	pktcEventNotifications
Cette sous arborescence spécifie les informations de notification, c'est-à-dire, quand les MTA transmettent les messages en utilisant les alertes et informations SNMP. Les alertes SNMP se réfèrent à la SNMPv2-Trap-PDU. Les alertes SNMPv1 sont déconseillées.

 	5.	Relations aux autres modules de MIB

Certains objets de gestion définis dans d'autres modules de MIB sont applicables à une entité qui met en œuvre la présente MIB. En particulier, on suppose qu'une entité qui met en œuvre le module PKTC-IETF-EVENT-MIB va aussi mettre en œuvre le groupe "interfaces" de la IF-MIB [RFC2863].

 	5.1	Modules de MIB exigés pour IMPORTS
Le module de MIB PKTC-IETF-EVENT-MIB importe des objets de la SMI SNMPv2 [RFC2578], de la TC SNMPv2 [RFC2579], de la MIB de cadre SNMP [RFC3411], de SNMPv2-CONF [RFC2580], de IF-MIB [RFC2863], de INET-ADDRESS-MIB [RFC4001], de SNMP-TARGET-MIB [RFC3413], de SNMP-NOTIFICATION-MIB [RFC3413], et de la SYSLOG-TC-MIB [RFC5427].

 	6.	Définitions

DÉFINITIONS de PKTC-IETF-EVENT-MIB ::= DÉBUT

IMPORTE
       MODULE-IDENTITY,
       TYPE D'OBJET,
       Unsigned32,
       TYPE DE NOTIFICATION,
       mib-2                            DE SNMPv2-SMI

       TruthValue,
       DateAndTime, CONVENTION TEXTUELLE  DE SNMPv2-TC
       SnmpAdminString                  DE SNMP-FRAMEWORK-MIB
       GROUPE D'OBJET,
       CONFORMITÉ DE  MODULE,
       GROUPE DE NOTIFICATION     DE SNMPv2-CONF
       ifPhysAddress                                 DE IF-MIB
       InetAddressType,
       InetAddress,
       InetPortNumber                                                               DE INET-ADDRESS-MIB
       snmpTargetBasicGroup, snmpTargetResponseGroup    DE SNMP-TARGET-MIB
       snmpNotifyGroup, snmpNotifyFilterGroup                    DE SNMP-NOTIFICATION-MIB
       SyslogSeverity, SyslogFacility                                        DE SYSLOG-TC-MIB;

IDENTITÉ DE MODULE  pktcIetfEventMib 
       DERNIERE MISE A JOUR "200903300000Z" -- 30 mars 2009
       ORGANISATION "IETF IP over Cable Data Network Working Group"
       CONTACT-INFO
               "Sumanth Channabasappa
                Cable Television Laboratories, Inc.
                858 Coal Creek Circle,
                Louisville, CO 80027, USA
                +1 303-661-3307
                Sumanth@cablelabs.com

                Wim De Ketelaere
                tComLabs
                Gildestraat 8
                9000 Gent, Belgium
                +32 9 269 22 90
                deketelaere@tComLabs.com

                Eugene Nechamkin
                Broadcom Corporation
                200 - 13711 International Place
                Richmond, BC, V6V 2Z8, Canada
                +1 604 233 8500
                enechamkin@broadcom.com

Groupe de travail IETF IPCDN 
            Discussion générale : ipcdn@ietf.org
            Abonnement : http://www.ietf.org/mailman/listinfo/ipcdn
            Archive : ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
            Co-président : Jean-François Mule, jf.mule@cablelabs.com
            Co-président : Richard Woundy, Richard_Woundy@cable.comcast.com"

DESCRIPTION : "Ce module de MIB spécifie les objets de gestion de base pour gérer les événements générés par les appareils adaptateur de terminal miltimédia conformes aux exigences de PacketCable et IPCablecom.

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

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises sous réserve de satisfaction des conditions suivantes :
-	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
-	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériels fournis avec la distribution.
-	Ni le nom de la Internet Society, de l'IETF ou du IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour endosser ou promouvoir les produits dérivés de ce logiciel sans une permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs des droits de reproduction et les contributeurs "tel qu'il est" et toutes garanties expresses ou implicites, incluant, mais sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particuler sont déclinées. En aucun cas le propriétaire des droits de reproduction ou les contributeurs ne seront responsables d'aucun dommage direct, indirect, incident, spécial, exemplaire, ou conséquent (incluant, mais sans s'y limiter, la fourniture de bien ou services de substitution, perte d'usage, de données, ou de profits, ou d'interruption d'affaires) cependant causés et de toute théorie de responsabilité, que ce soit par contrat, responsabilité stricte, ou tort (incluant la négligence ou autre) survenant de quelque manière de l'utilisation de ce logiciel, même si il est averti de la possibilité de tels dommages.

Cette version de ce module de MIB fait partie de la RFC 5428 ; voir dans la RFC elle-même les notices légales complètes."

RÉVISION : "200903300000Z" -- 30 mars 2009

DESCRIPTION : "Version initiale, publiée comme RFC 5428."
   ::=  { mib-2 182 }

SyslogSeverityMask ::= CONVENTION TEXTUELLE
STATUT : courant
DESCRIPTION : "Cette convention textuelle représente un gabarit binaire indiquant la sévérité des événements syslog qui peuvent être générés. Elle correspond aux divers niveaux de sévérité associés aux messages syslog, comme spécifié dans le 'Protocole Syslog', [RFC5424].

emerg        (0),  - urgence ; le système est inutilisable
alert           (1),  - une action doit être prise immédiatement
crit             (2),  - condition critique 
err              (3),  - condition d'erreur
warning     (4),  - condition d'avertissement
notice         (5),  - condition normale mais significative
info            (6),  - message d'information
debug         (7),  - messages de niveau débogage"

SYNTAXE :  BITS {
                  emerg(0),
                  alert(1),
                  crit(2),
                  err(3),
                  warning(4),
                  notice(5),
                  info(6),
                  debug(7)
                  }

--
IDENTIFIANT D'OBJET pktcEventNotifications ::= { pktcIetfEventMib 0 }
IDENTIFIANT D'OBJET pktcEventMibObjects   ::= { pktcIetfEventMib 1 }
IDENTIFIANT D'OBJET pktcEventConformance ::= { pktcIetfEventMib 2 }
--
--
IDENTIFIANT D'OBJET pktcEventControl   ::= { pktcEventMibObjects 1 }
IDENTIFIANT D'OBJET pktcEventThrottle  ::= { pktcEventMibObjects 2 }
IDENTIFIANT D'OBJET pktcEventStatus     ::= { pktcEventMibObjects 3 }
IDENTIFIANT D'OBJET  pktcEvents            ::= { pktcEventMibObjects 4 }
IDENTIFIANT D'OBJET  pktcEventLog       ::= { pktcEventMibObjects 5 }

---
-- Objets de contrôle de rapport d'événement
---
TYPE D'OBJET   pktcEventReset  
SYNTAXE :  BITS {
                   resetEventLogTable(0),
                   resetEventTable(1)
                   }
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB permet à une station de gestion de supprimer l'enregistrement local des événements générés, de réinitialiser les descriptions d'événement de gestion, ou les deux.
Les MTA génèrent des événements de gestion. Ces événements sont mémorisés dans le tableau de MIB pktcEventLogTable. Si une station de gestion a besoin de supprimer toutes les entrées courantes (par exemple, après l'achèvement d'une opération de réparation) elle peut le faire en réglant le bit resetEventLogTable(0) à une valeur de '1'.

Le MTA est pré-configuré avec les événements qu'il peut générer. Cela est mémorisé dans le tableau de MIB pktcEventTable. Ce tableau contient aussi les descriptions associées à ces événements. Ces descriptions peuvent être modifiées par une station de gestion. Cependant, si la station de gestion souhaite remettre les descriptions aux valeurs d'usine par défaut, elle peut le faire en réglant le bit resetEventTable(1) à la valeur de '1'.

Les actions de MTA sont résumées ci-dessous :
Bit resetEventLogTable(0) réglé à la valeur de '1'
- supprime toutes les entrées du pktcEventLogTable ;
- remet la valeur de pktcEventLogIndex à '0'.
Bit resetEventTable(1) réglé à la valeur de '1'
- remet le pktcEventTable aux valeurs d'usine par défaut.
Bits resetEventLogTable(0) et resetEventTable(1) réglés à la valeur de '1'
- effectue les actions ci-dessus comme si elles étaient effectuées individuellement (dans n'importe quel ordre).

Régler un bit reset à une valeur de '0' NE DOIT PAS résulter en une action.

Le MTA DOIT effectuer les actions ci-dessus sans considération de leur persistance (c'est-à-dire, de leur mémorisation dans une mémoire non volatile).

Le MTA DOIT toujours retourner une valeur de "00" quand cet objet de MIB est lu.

Une station de gestion qui réinitialise les tableaux en utilisant cet objet de MIB doit faire attention à l'impact sur d'autres stations de gestion qui peuvent dépendre des informations contenues dans le ou les tableaux réinitialisés. Par exemple, si une station de gestion A crée un ensemble spécifique de descriptions d'événement dans le tableau d'événements (pktcEventTable) à des fins de débogage et attend tout événement généré pour rapporter les descriptions modifiées. Dans ce cas, si une autre station de gestion réinitialise le tableau d'événements aux valeurs d'usine par défaut, tous les événements suivants ne contiendront pas les descriptions modifiées attendues par la station de gestion A. De telles contraintes multi gestionnaires ne sont pas traitées dans ce module de MIB. Donc, il est RECOMMANDÉ aux stations de gestion d'utiliser cet objet de MIB avec soin et prudence, et seulement quand c'est absolument exigé."
  ::=  pktcEventControl 1 }

---
-- Objets de MIB spécifiques de syslog
---

IDENTIFIANT D'OBJET pktcEventSyslog   ::= { pktcEventControl 2 }
TYPE D'OBJET  pktcEventSyslogCapabilities  
SYNTAXE :  BITS {
                   formatBSDSyslog(0),
                   formatSyslogProtocol(1),
                   transportUDP(2),
                   transportTLS(3),
                   transportBEEP(4)
                   }
MAX-ACCESS : lecture seule
STATUT :  courant
DESCRIPTION : "Cet objet de MIB contient les capacités du MTA pour la prise en charge du protocole syslogl, en particulier les formats de message et les protocoles de transport.
Le format de message syslog BSD est spécifié dans la [RFC3164] (formatBSDSyslog) et le protocole syslog de l'IETF est spécifié dans la [RFC5424] (formatSyslogProtocol).
Le MTA DOIT régler les bits appropriés de protocole et de transport, sur la base de la mise en œuvre."
RÉFÉRENCE : "Protocole BSD de Syslog" [RFC3164], "Protocole Syslog" [RFC5424], "Transmission des messages Syslog sur UDP" [RFC5426], "Transposition de transport TLS pour Syslog" [RFC5425], "Livraison fiable pour syslog" [RFC3195]."
  ::= { pktcEventSyslog 1 }

TYPE D'OBJET pktcEventSyslogAddressType
SYNTAXE : InetAddressType
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB définit le type d'adresse Internet du serveur syslog spécifié par l'objet de MIB pktcEventSyslogAddress. Une valeur de dns(16) est déconseillée parce qu'un nom de domaine DNS non résolvable va laisser l'appareil sans serveur syslog auquel il puisse rapporter les événements."
RÉFÉRENCE : "PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]."
DEFVAL { ipv4 }
  ::= { pktcEventSyslog 2 }

TYPE D'OBJET pktcEventSyslogAddress  
SYNTAXE : InetAddress
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'adresse IP du serveur syslog auquel le MTA peut transmettre un message syslog lors de la génération d'un événement de gestion. Le type d'adresse que cet objet représente est défini par l'objet de MIB pktDevEventSyslogAddressType.
Le format du message syslog est spécifié par l'objet de MIB pktcEventSyslogMessageFormat."
RÉFÉRENCE : "PacketCable MTA Device Provisioning Specification" [PKT-SP-PROV], "PacketCable Management Event Mechanism Specification" [PKT-SP-MEM1.5].
DEFVAL { "0.0.0.0" }
  ::= { pktcEventSyslog 3 }

TYPE D'OBJET pktcEventSyslogMessageFormat 
SYNTAXE : ENTIER {
                   formatBSDSyslog(1), 	-- Protocole BSD de syslog;
                   formatSyslogProtocol(2)	-- Protocole syslog.
                   }
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le format de message syslog à utiliser pour transmettre les messages syslog au serveur contenu dans l'objet de MIB pktcEventSyslogServer."
RÉFÉRENCE : "Protocole BSD de syslog" [RFC3164], "Protocole Syslog" [RFC5424].
DEFVAL { formatSyslogProtocol }
  ::= { pktcEventSyslog 4 }

TYPE D'OBJET pktcEventSyslogTransport 
SYNTAXE : ENTIER {
                     udp(1),	-- Transmission de messages syslog sur UDP
                     tls(2),	-- Transposition de transport TLS pour Syslog
                     beep(3)	-- Transposition de transport BEEP pour Syslog
                   }
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB spécifie le transport à utiliser pour transmettre des messages syslog au serveur syslog contenus dans l'objet de MIB pktcEventSyslogAddress.
Si le MTA ne prend pas en charge le transport spécifié dans une opération SET, il DOIT retourner une réponse d'erreur appropriée, comme une "valeurIncohérente".
RÉFÉRENCE : "Transmission des messages Syslog sur UDP" [RFC5426], "Transposition de transport TLS pour Syslog" [RFC5425].
DEFVAL : {tls}
  ::= { pktcEventSyslog 5 }

TYPE D'OBJET pktcEventSyslogPort  
SYNTAXE : InetPortNumber
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le numéro d'accès du serveur syslog auquel les messages syslog sont à transmettre."
RÉFÉRENCE : "Transmission des messages Syslog sur UDP" [RFC5426], "Transposition de transport TLS pour Syslog" [RFC5425].
DEFVAL : { 6514 }
  ::= { pktcEventSyslog 6 }

---
-- Classes d'événements
---

TYPE D'OBJET pktcEventClassTable 
SYNTAXE : SÉQUENCE DE PktcEventClassEntry
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Ce tableau de MIB permet que des événements de gestion qui peuvent être générés par un MTA soient classés en catégories, ou "classes d'événements". Par exemple, tous les événements relatifs à une configuration peuvent être associés à une classe d'événements intitulée "configuration". Une telle classification permet à une station de gestion d'effectuer des changements à un groupe commun d'événements en une fois. Deux opérations sont spécifiées sur une classe d'événements : permettre ou désactiver tous les événements d'une classe d'événements, et une permission ou désactivation sélective sur la base d'un niveau de sévérité."
  ::= { pktcEventControl 3 }

TYPE D'OBJET pktcEventClassEntry 
SYNTAXE : PktcEventClassEntry
MAX-ACCESS ; non accessible
STATUT : courant
DESCRIPTION : "Chaque entrée de ce tableau spécifie une classe d'événements, un groupement d'événements, comme identifié par le fabricant du MTA. Tout événement associé à une classe d'événements dans ce tableau DOIT être spécifié dans le pktcEventTable.
Le MTA DOIT créer une entrée (index=100) pour la classe d'événements intitulée "générique". Cette classe d'événements DOIT contenir tous les événements qui ne sont pas contenus dans une autre classe d'événements spécifiée par le fabricant.
Une station de gestion NE DEVRAIT PAS associer un événement à plusieurs classes d'événements. Cependant, si un événement est associé à plusieurs classes d'événements, le MTA DOIT donner la préséance à la classe d'événements de plus faible index. Donc, à un moment donné, seule une classe d'événements est applicable à un événement.
Le tableau d'événements (pktcEventTable) donne la classe d'événements qui affecte l'événement. Chaque fois qu'un événement est généré, le MTA DOIT vérifier l'entrée de classe d'événements applicable pour prendre les actions spécifiées. Les entrées dans ce tableau persistent à travers les réinitialisations et réamorçages."
INDEX { pktcEventClassIndex }
  ::= { pktcEventClassTable 1 }

PktcEventClassEntry::= SEQUENCE {
       pktcEventClassIndex          Unsigned32,
       pktcEventClassName          SnmpAdminString,
       pktcEventClassStatus         TruthValue,
       pktcEventClassSeverity      SyslogSeverityMask
     }

TYPE D'OBJET pktcEventClassIndex 
SYNTAXE : Unsigned32 (1..100)
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Cet objet de MIB est un index dans le tableau de classe d'événements. Cette valeur a une signification locale."
  ::= { pktcEventClassEntry 1 }

TYPE D'OBJET pktcEventClassName 
SYNTAXE : SnmpAdminString (SIZE (1..100))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le nom de la classe d'événements.
Les fabricants PEUVENT définir différentes classes d'événements (par exemple, DHCP, SNMP, DEBUG) pour grouper les événements de gestion d'une catégorie particulière.
Les noms de classes d'événement doivent prendre en considération les exigences de définition de SnmpAdminString, telles que l'utilisation de la séquence de code de contrôle CR LF pour représenter une nouvelle ligne."
  ::= { pktcEventClassEntry 2 }

TYPE D'OBJET pktcEventClassStatus 
SYNTAXE : TruthValue
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB indique si des événements appartenant à la classe d'événements correspondante sont activés ou désactivés, pour le rapport d'événement.
Régler cet objet à une valeur de "vrai"' permet le rapport de tous les événements dans la classe d'événements.
Lorsque activé, le moyen de rapport d'événements est spécifié par l'objet de MIB pktcEventReporting.
Régler cet objet à la valeur "faux" désactive tout rapport d'événement, sans tenir compte de la valeur de l'objet de MIB pktcEventReporting pour un événement spécifique.
La valeur par défaut de cet objet de MIB est spécifique du fabricant. Cependant, le fabricant DEVRAIT permettre par défaut toutes les catégories d'événement définies par PacketCable ou IPCablecom"
  ::= { pktcEventClassEntry 3 }

TYPE D'OBJET pktcEventClassSeverity 
SYNTAXE : SyslogSeverityMask
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB définit le niveau de sévérité des événements appartenant à une classe d'événements spécifique qui sont activés pour le rapport d'événement.
Cet objet de MIB n'a pas d'effet sur le rapport d'événement sauf si l'objet de MIB pktcEventClassStatus est réglé à la valeur "vrai" (activé) pour la classe d'événements correspondante.
Régler un bit dans le gabarit à une valeur de "1" implique que les événements correspondants à ce niveau de sévérité DOIVENT être rapportés comme défini par la valeur correspondante de "pktcEventReporting" pour les événements de la classe d'événements.
Régler un bit à une valeur de "0" implique que les événements correspondants à ce niveau NE DOIVENT PAS être rapportés, sans considération de la valeur correspondante de "pktcEventReporting" pour les événements de la classe d'événements.
Il est recommandé que les bits correspondants à emerg(0), alert(1), crit(2), et err(3) soient réglés à la valeur de "1" pour assurer le rapport des événements qui exigent une attention immédiate."
RÉFÉRENCE : "Protocole Syslog" [RFC5424].
  ::= { pktcEventClassEntry 4 }

---
--  Contrôle de modération d'événement
---

TYPE D'OBJET pktcEventThrottleAdminStatus  
SYNTAXE : ENTIER {
                   unconstrained(1),
                   maintainBelowThreshold(2),
                   stopAtThreshold(3),
                   inhibited(4)
                   }
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contrôle la modération des messages transmis lors de la génération d'un événement (SNMP/syslog). Il n'affecte pas l'enregistrement local des événements.
Une valeur de unconstrained(1) cause la transmission des messages d'événement sans égard aux réglages de seuil.
Une valeur de maintainBelowThreshold(2) cause la suppression des messages d'événement si le nombre de transmissions excéderait autrement le seuil spécifié par pktcEventThrottleThreshold sur l'intervalle spécifié par pktcEventThrottleInterval.
Une valeur de stopAtThreshold(3) cause l'arrêt de la transmission des messages d'événement une fois atteint le seuil spécifié par pktcEventThrottleThreshold (sur l'intervalle spécifié par pktcEventThrottleInterval). La génération d'événements est reprise quand la valeur de cet objet de MIB est modifiée par une station de gestion ou quand l'appareil se réinitialise ou réamorce.
Une valeur de inhibited(4) cause la suppression de toutes les transmissions de message d'événement.
Un événement causant à la fois un message SNMP et un message syslog est quand même traité comme un seul événement.
Se reporter aux objets de MIB pktcEventThrottleThreshold et pktcEventThrottleInterval pour des informations sur la modération."
DEFVAL { unconstrained }
  ::= { pktcEventThrottle 1 }

TYPE D'OBJET pktcEventThrottleThreshold  
SYNTAXE : Unsigned32(0..1024)
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le nombre d'événements par pktcEventThrottleInterval à transmettre avant modération. Un événement résultant en plusieurs actions (par exemple, SNMP et syslog) est quand même traité comme un seul événement."
DEFVAL { 2 } ::= { pktcEventThrottle 2 }

TYPE D'OBJET pktcEventThrottleInterval  
SYNTAXE : Unsigned32(0..604800)
UNITÉS : "secondes"
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'intervalle sur lequel le seuil de modération s'applique."
DEFVAL { 1 } ::= { pktcEventThrottle 3 }

---
-- Rapport de l'état de transmission
---

TYPE D'OBJET pktcEventTransmissionStatus 
SYNTAXE :  BITS {
                   syslogThrottled(0),
                   snmpThrottled(1),
                   validsyslogServerAbsent(2),
                   validSnmpManagerAbsent(3),
                   syslogTransmitError(4),
                   snmpTransmitError(5)
                   }
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB reflète l'état des transmissions d'événement en utilisant syslog, SNMP, ou les deux.
Si un bit correspondant à un état est réglé à une valeur de :
"1", il indique que l'état est vrai
"0", il indique que l'état est faux
Si le MTA n'est pas configuré avec un serveur syslog ou un gestionnaire SNMP, les bits correspondants "modération" et "transmission d'erreur' DOIVENT être réglés à la valeur de "0". Par exemple, si un gestionnaire SNMP n'est pas configuré sur le MTA, le bit correspondant à validSnmpManagerAbsent(3) est réglé à la valeur de "1", et les valeurs des bits correspondant à snmpThrottled(1) et snmpTransmitError(5) sont réglés à la valeur de "0".
"modération d'événement" est fondé sur des seuils et le réglage courant de l'objet de MIB pktcEventThrottleAdminStatus.
Les indicateurs "Serveur/gestionnaire" se fondent sur la disponibilité d'un serveur syslog/gestionnaire SNMP valide.
Les erreurs de transmission sont rapportées quand elles sont détectées. Si un MTA ne peut pas détecter une situation d'erreur, la valeur du bit va être réglée à "0".
On notera que toutes les conditions qui sont indiquées par cet objet de MIB ne sont pas détectables par tous les appareils, et quand elles sont détectées, elles peuvent n'être pas précises. Il est destiné à fournir un rapport de l'état déterminé par l'appareil durant les transmissions d'événement."
  ::= { pktcEventStatus 1 }

---
-- Description des événements
---

TYPE D'OBJET pktcEventTable 
SYNTAXE : SÉQUENCE DE PktcEventEntry
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Ce tableau de MIB contient tous les événements de gestion possibles qui peuvent être générés par l'appareil. Cela inclut les événements définis par PacketCable et IPCablecom et les événements spécifiques du fabricant."
  ::= { pktcEvents 1 }

TYPE D'OBJET pktcEventEntry 
SYNTAXE : PktcEventEntry
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Une entrée dans ce tableau est créée pour chaque événement que le MTA qui met en œuvre cette MIB est capable de rapporter. Les entrées dans ce tableau sont persistants à travers les réinitialisations et réamorçages."
INDEX { pktcEventOrganization, pktcEventIdentifier }
  ::= { pktcEventTable 1 }

PktcEventEntry::= SEQUENCE {
       pktcEventOrganization    Unsigned32,
       pktcEventIdentifier          Unsigned32,
       pktcEventFacility             SyslogFacility,
       pktcEventSeverityLevel   SyslogSeverity,
       pktcEventReporting          BITS,
       pktcEventText                  SnmpAdminString,
       pktcEventClass                 SnmpAdminString
   }

TYPE D'OBJET pktcEventOrganization 
SYNTAXE : Unsigned32(1..4294967295)
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Cet objet de MIB donne le numéro d'entreprise IANA de l'organisation qui définit l'événement. Donc, tous les événements définis par PacketCable ou IPCablecom vont contenir le numéro d'entreprise IANA de PacketCable ou IPCablecom, et tous les événements spécifiques de fabricant vont contenir le numéro d'entreprise IANA de l'organisation qui les définit."
RÉFÉRENCE : "IANA Private Enterprise Number assignment, [IANA-ENTERPRISE]."
  ::= { pktcEventEntry 1 }

TYPE D'OBJET pktcEventIdentifier
SYNTAXE : Unsigned32(1..4294967295)
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'identifiant d'événement pour l'événement correspondant."
RÉFÉRENCE : "PacketCable Management Event Mechanism Specification, [PKT-SP-MEM1.5] ; PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]."
  ::= { pktcEventEntry 2 }

TYPE D'OBJET pktcEventFacility
SYNTAXE : SyslogFacility
MAX-ACCESS : lecture seule
STATUT :  courant
DESCRIPTION : "Cet objet de MIB contient la facilité pour l'événement. Pour les événements PacketCable, IPCablecom, ou ETSI, ce DOIT être réglé à la valeur de local0(16)."
RÉFÉRENCE : "Protocole Syslog" [RFC5424] ; "Conventions textuelles pour la gestion syslog" [RFC5427]."
  ::= { pktcEventEntry 3 }

TYPE D'OBJET pktcEventSeverityLevel
SYNTAXE : SyslogSeverity
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le niveau de sévérité applicable à l'événement spécifié."
RÉFÉRENCE : "Protocole syslog" [RFC5424] ; Conventions textuelles pour la gestion syslog" [RFC5427]."
  ::= { pktcEventEntry 4 }

TYPE D'OBJET pktcEventReporting
SYNTAXE : BITS {
                   local(0),
                   syslog(1),
                   snmpTrap(2),
                   snmpInform(3)
                   }
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB définit l'action à entreprendre sur une occurrence de cet événement. Le bit local(0) se réfère à l'enregistrement local des événements ; le bit sylog(1) se réfère à la transmission des événements utilisant syslog ; le bit snmpTrap(2) se réfère à la transmission d'événements utilisant les alertes SNMP (SNMPv2-Trap-PDU) ; et le bit snmpInform(3) se réfère à la transmission des événements utilisant des INFORM SNMP. Régler un bit à une valeur de "1" indique que l'action correspondante va être effectuée sur une occurrence de cet événement. Si aucun des bits n'est établi, aucune action n'est alors effectuée sur une occurrence de l'événement. Le succès de transmission utilisant syslog et SNMP dépend de la configuration du MTA. Par exemple, une adresse valide de serveur syslog est exigée pour la transmission de message syslog. La spécification d'un événement de gestion n'inclut pas nécessairement les actions à effectuer à sa génération, c'est-à-dire, elle n'a pas besoin de spécifier si un événement généré doit être transmis via SNMP ou syslog, ou mémorisé en local. Donc, certaines valeurs par défaut sont spécifiées, sur la base du niveau de sévérité de l'événement spécifié par l'objet de MIB pktcEventSeverityLevel, comme suit :
-	Si le niveau de sévérité d'un événement est emerg(0), alert(1), crit(2), ou err(3), on règle les bits pour local(0), syslog(1), et snmpInform(3) à la valeur "1" et on règle les bits restants à la valeur "'0".
-	Pour un événement avec tout autre niveau de sévérité, on règle les bits pour local(0) et syslog(1) à la valeur "1" et on règle le reste des bits à la valeur "0".
 ::= { pktcEventEntry 5 }

TYPE D'OBJET pktcEventText
SYNTAXE : SnmpAdminString (TAILLE (0..127))
MAX-ACCESS : lecture-écriture
STATUT : courant
DESCRIPTION : "Cet objet de MIB donne une description lisible par l'homme de l'événement. Les descriptions doivent tenir compte des exigences de la définition de SnmpAdminString comme l'utilisation de la séquence de code de contrôle CR LF pour représenter une nouvelle ligne."
  ::= { pktcEventEntry 6 }

TYPE D'OBJET pktcEventClass
SYNTAXE : SnmpAdminString (TAILLE (0..100))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB représente la classe d'événements qui affecte l'événement. Si un événement est associé à seulement une classe d'événements, alors son nom (pktcEventClassName) est rapporté. Si un événement est associé à plus d'une classe d'événements, alors le nom de la classe d'événements avec le plus faible index dans le tableau de classe d'événements (pktcEventClassTable) est rapporté. Voir le tableau de MIB pktcEventClassTable pour une description des classes d'événements et de leur usage. Les descriptions doivent tenir compte des exigences de définition de SnmpAdminString, comme l'utilisation de la séquence de code de contrôle CR LF pour représenter une nouvelle ligne."
  ::= { pktcEventEntry 7 }

---
-- Enregistrement des événements générés
---

TYPE D'OBJET pktcEventLogTable
SYNTAXE : SEQUENCE OF PktcEventLogEntry
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Ce tableau de MIB contient un enregistrement des événements générés par le MTA. Une description de tous les événements qui peuvent être générés par l'appareil peut être obtenue du tableau de MIB pktcEventTable.
Un MTA n'est pas obligé de conserver le contenu de ce tableau à travers les réinitialisations."
  ::= { pktcEventLog 1 }

TYPE D'OBJET pktcEventLogEntry
SYNTAXE : PktcEventLogEntry
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Chaque entrée de ce tableau décrit un événement qui s'est produit, indexé dans l'ordre chronologique de génération. Les détails de l'événement sont empruntés aux paramètres associés à l'entrée d'événement correspondante dans pktcEventTable au moment de la génération de l'événement. Bien que toutes les entrées créées à ce titre puissent être supprimées en utilisant l'objet de MIB pktcEventReset, les entrées d'événement elles-mêmes ne peuvent pas être supprimées individuellement."
INDEX { pktcEventLogIndex }
  ::= { pktcEventLogTable 1 }

PktcEventLogEntry ::= S1QUENCE {
       pktcEventLogIndex                 Unsigned32,
       pktcEventLogTime                  DateAndTime,
       pktcEventLogOrganization     Unsigned32,
       pktcEventLogIdentifier           Unsigned32,
       pktcEventLogText                   SnmpAdminString,
       pktcEventLogEndpointName  SnmpAdminString,
       pktcEventLogType                  BITS,
       pktcEventLogTargetInfo         SnmpAdminString,
       pktcEventLogCorrelationId     Unsigned32,
       pktcEventLogAdditionalInfo   SnmpAdminString
       }

TYPE D'OBJET pktcEventLogIndex
SYNTAXE : Unsigned32(1..4294967295)
MAX-ACCESS : non accessible
STATUT : courant
DESCRIPTION : "Cet objet de MIB donne l'ordre relatif des objets dans l'enregistrement d'événements.
Si le MTA met en œuvre une mémorisation non volatile, alors cet objet va toujours augmenter sauf quand l'objet de MIB atteint une valeur de 2^32-1.
Si le MTA ne met pas en œuvre une mémorisation non volatile, alors cet objet va toujours augmenter sauf quand l'objet de MIB atteint la valeur de 2^32-1 ou quand le MTA est réinitialisé.
Quand la valeur atteint 2^32-1, ou quand le MTA qui ne met pas en œuvre une mémorisation non volatile est réinitialisé, de nouveaux événements vont être mémorisés en commençant par une valeur d'index de "1" (rotation cyclique)."
  ::= { pktcEventLogEntry 1 }

TYPE D'OBJET pktcEventLogTime
SYNTAXE : DateAndTime
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB donne une description lisible par l'homme de la date et heure à laquelle l'événement s'est produit. La valeur de date et heure contenue dans cet objet de MIB DEVRAIT refléter la date et heure utilisée dans le message syslog résultant de l'événement associé, si un tel message syslog a été transmis."
  ::= { pktcEventLogEntry 2 }

TYPE D'OBJET pktcEventLogOrganization
SYNTAXE : Unsigned32(1..4294967295)
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB donne le numéro d'entreprise IANA de l'organisation qui définit l'événement. Donc, tous les événements PacketCable ou IPCablecom définis vont contenir le numéro d'entreprise IANA de CableLabs ou d'IPCablecom, et tous les événements spécifiques de fabricant vont contenir le numéro d'entreprise IANA de l'organisation qui définit l'événement."
  ::= { pktcEventLogEntry 3 }

TYPE D'OBJET pktcEventLogIdentifier
SYNTAXE : Unsigned32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'identifiant d'événement de l'événement correspondant."
  ::= { pktcEventLogEntry 4 }

TYPE D'OBJET pktcEventLogText
SYNTAXE : SnmpAdminString (TAILLE (0..127))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le contenu de l'objet de MIB pktcEventText, correspondant à l'événement, au moment de sa génération."
  ::= { pktcEventLogEntry 5 }

TYPE D'OBJET pktcEventLogEndpointName
SYNTAXE : SnmpAdminString (TAILLE (0..255))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'identifiant univoque du point d'extrémité de MTA qui a généré l'événement correspondant. Si l'événement généré n'était pas associé à un point d'extrémité spécifique sur le MTA, alors cet objet de MIB contient l'identifiant du MTA.
Un point d'extrémité de MTA peut être identifié de façon univoque en utilisant une combinaison de l'identifiant du MTA et du numéro de point d'extrémité. Le MTA est identifié par son nom de domaine pleinement qualifié (FQDN, Fully-Qualified Domain Name) et l'adresse IP associée à ce moment donné.
Le format de la valeur contenue par cet objet de MIB est le suivant :
aaln/n:<FQDN>/<IP>, quand il identifie un point d'extrémité, 'n' étant le numéro de point d'extrémité ;
ou,
<FQDN>/<IP>, quand il identifie un MTA.
La valeur contenue par cet objet de MIB doit observer les exigences de définition de SnmpAdminString."
  ::= { pktcEventLogEntry 6 }

TYPE D'OBJET pktcEventLogType
SYNTAXE : BITS {
                   local(0),
                   syslog(1),
                   snmpTrap(2),
                   snmpInform(3)
                   }
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient le type des actions effectuées par le MTA quand s'est produit l'événement indiqué par l'objet de MIB pktcEventLogIdentifier.
Un bit de valeur "1" indique que l'action correspondante a été effectuée. Le régler à la valeur "0" indique que l'action correspondante n'a pas été effectuée.
Un événement peut déclencher une ou plusieurs actions (par exemple, syslog et SNMP) ou résulter seulement en un enregistrement local. Une action peut aussi être empêchée du fait de la modération, et dans ce cas elle n'est pas rapportée par cet objet de MIB."
  ::= { pktcEventLogEntry 7 }

TYPE D'OBJET pktcEventLogTargetInfo
SYNTAXE : SnmpAdminString (TAILLE (0..255))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient une liste séparée de virgules des actions effectuées pour des notifications externes, avec l'adresse IP cible pour les événements générés. Les événements mémorisés en local NE DOIVENT PAS être enregistrés dans cet objet de MIB.
La syntaxe est : <action-1/IP>,<action-2/IP>,<action-3/IP>
Où <action-n/IP> est à noter comme suit :
Pour les événements syslog : syslog/<adresse IP du serveur syslog>
Pour les alertes SNMP : snmpTrap/<adresse IP du serveur SNMP>
Pour les INFORM SNMP : snmpInform/<adresse IP du serveur SNMP>
Si il y a plusieurs cibles pour le même type (des alertes SNMP envoyées à plusieurs adresses IP) ou si il y a plusieurs types de message envoyés à la même adresse IP (syslog et SNMP envoyés à la même adresse IP) ils doivent être rapportés individuellement.
On note que cet objet de MIB peut dans certains cas n'être pas capable de mémoriser toutes les données (par exemple, plusieurs adresses IPv6) et alors certaines actions peuvent n'être pas rapportées. Dans ce cas, le MTA DOIT présenter une valeur de "..." à la fin de la valeur.
Les valeurs contenues par cet objet de MIB doivent observer les exigences de définition de SnmpAdminString."
  ::= { pktcEventLogEntry 8 }

TYPE D'OBJET pktcEventLogCorrelationId
SYNTAXE : Unsigned32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient l'identifiant de corrélation généré par le MTA durant l'initiation du dernier flux de provisionnement, dans, ou à la suite de, la survenue de l'événement.
Bien qu'un identifiant de corrélation ne change pas une fois généré après une réinitialisation de MTA jusqu'à la prochaine réinitialisation, la valeur de cet objet va différer pour les événements préservés à travers les réinitialisations de MTA dans le cas d'un tableau pktcEventLogTable persistant.
Pour plus d'informations sur la génération des identifiants de corrélation, voir les spécifications correspondantes de provisionnement d'appareil PacketCable/IPCablecom."
RÉFÉRENCE : "PacketCable MTA Device Provisioning Specification, [PKT-SP-PROV]."
  ::= { pktcEventLogEntry 9 }

TYPE D'OBJET pktcEventLogAdditionalInfo
SYNTAXE : SnmpAdminString (TAILLE (0..255))
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION : "Cet objet de MIB contient des informations supplémentaires en relation avec l'événement correspondant qu'un MTA pourrait souhaiter rapporter, comme des données paramétrées ou des informations de débogage. Le format est spécifique du fabricant.
Si le MTA ne peut pas fournir d'informations supplémentaires pour l'événement particulier généré, il DOIT remplir cet objet de MIB avec une CHAINE D'OCTETS de longueur zéro. Les fabricants qui fournissent cette information doivent observer les exigences de définition de SnmpAdminString, comme l'utilisation de la séquence de code de contrôle CR LF pour une nouvelle ligne."
  ::= { pktcEventLogEntry 10 }

---
-- Notifications
---

TYPE DE NOTIFICATION pktcEventNotification
OBJECTS {
       pktcEventLogTime,
       pktcEventLogOrganization,
       pktcEventLogIdentifier,
       pktcEventLogEndpointName,
       pktcEventLogCorrelationId,
       ifPhysAddress
       }
STATUT :  courant
DESCRIPTION : "Cet objet de MIB Notification contient le contenu du rapport d'événement. Il contient l'heure d'enregistrement de l'événement, l'identifiant de l'organisation, l'identifiant de l'événement, l'identifiant du point d'extrémité, l'identifiant de corrélation, et l'adresse MAC du MTA."
  ::= { pktcEventNotifications 1 }

---
-- Conformité
---

IDENTIFIANT D'OBJET pktcEventCompliances ::= { pktcEventConformance  1 }
IDENTIFIANT D'OBJET pktcEventGroups          ::= { pktcEventConformance  2 }

CONFORMITÉ DE MODULE pktcEventBasicCompliance 
STATUT : courant
DESCRIPTION : "Déclaration de conformité pour les appareils qui mettent en œuvre la caractéristique de rapport d'événement."
MODULE  --pktcIetfEventMib
GROUPES OBLIGATOIRES {
                    pktcEventGroup,
                    pktcEventNotificationGroup
                    }
MODULE SNMP-TARGET-MIB
GROUPES OBLIGATOIRES {
                  snmpTargetBasicGroup,
                  snmpTargetResponseGroup
              }
MODULE SNMP-NOTIFICATION-MIB
GROUPES OBLIGATOIRES {
                   snmpNotifyGroup,
                   snmpNotifyFilterGroup
              }
  ::= { pktcEventCompliances 3 }

GROUPE D'OBJETS pktcEventGroup 
OBJETS {
            pktcEventReset,
            pktcEventSyslogCapabilities,
            pktcEventSyslogAddressType,
            pktcEventSyslogAddress,
            pktcEventSyslogTransport,
            pktcEventSyslogPort,
            pktcEventSyslogMessageFormat,
            pktcEventThrottleAdminStatus,
            pktcEventThrottleThreshold,
            pktcEventThrottleInterval,
            pktcEventTransmissionStatus,
            pktcEventFacility,
            pktcEventSeverityLevel,
            pktcEventReporting,
            pktcEventText,
            pktcEventLogTime,
            pktcEventLogOrganization,
            pktcEventLogIdentifier,
            pktcEventLogText,
            pktcEventLogEndpointName,
            pktcEventLogType,
            pktcEventLogTargetInfo,
            pktcEventLogCorrelationId,
            pktcEventLogAdditionalInfo,
            pktcEventClass,
            pktcEventClassName,
            pktcEventClassStatus,
            pktcEventClassSeverity
         }
STATUT :  courant
DESCRIPTION : "Groupe des objets de MIB pour la MIB d'événement de gestion de PacketCable."
  ::= { pktcEventGroups 1 }

GROUPE DE NOTIFICATION pktcEventNotificationGroup 
NOTIFICATIONS { pktcEventNotification }
STATUT : courant
DESCRIPTION : "Groupe d'objets de MIB pour les notifications relatives à des changements d'état de l'appareil MTA."
  ::= { pktcEventGroups 2 }

FIN

 	7.	Considérations relatives à l’IANA

Le module de MIB dans ce document utilise les valeurs d'IDENTIFIANT D'OBJET allouées par l'IANA suivantes enregistrées dans le registre des numéros de SMI :

Descripteur	Valeur d'IDENTIFIANT D'OBJET
pktcIetfEventMib 	{ mib-2 182 }

 	8.	Considérations sur la sécurité

Un certain nombre d'objets de gestion sont définis dans ce module de MIB avec une clause MAX-ACCESS de lecture-écriture. De tels objets peuvent être considérés comme sensibles ou vulnérables dans certains environnements de réseau. La prise en charge des opérations SET dans un environnement non sûr sans une protection appropriée peut avoir un effet négatif sur les opérations du réseau. Les menaces pour la sécurité incluent des événements non rapportés dans les erreurs, une redirection des événements (délibérée ou non) ou une minimisation des rapports d'erreurs. De telles menaces peuvent masquer certaines tentatives de modification de configuration et des attaques de déni de service qui peuvent être reconnues et déjouées via le rapport d'événement.

Les objets de MIB significatifs incluent :

- ceux qui contrôlent la génération d'événement, l'adresse cible syslog pour les événements et l'état de rapport, c'est-à-dire :
pktcEventReset
pktcEventSyslogAddressType
pktcEventSyslogAddress
pktcEventSyslogPort
pktcEventSyslogMessageFormat
pktcEventSyslogTransport
pktcEventClassStatus

- ceux relatifs aux classes d'événements, c'est-à-dire : pktcEventClassSeverity

- ceux relatifs à la modération, c'est-à-dire : pktcEventThrottleAdminStatus pktcEventThrottleThreshold pktcEventThrottleInterval

- ceux relatifs aux capacités de rapport d'événement d'un MTA, c'est-à-dire : pktcEventSeverityLevel pktcEventReporting pktcEventText

L'objet de MIB pktcEventReset mérite une mention particulière car l'accès à cet objet de MIB peut être utilisé pour perturber la collecte d'événements par les stations de gestion. Par exemple, si on considère une station de gestion qui modifie les descriptions dans le tableau d'événements pktcEventTable. Elle s'attendrait alors à ce que les événements de gestion générés par le MTA reflètent les valeurs modifiées. Une station de gestion félonne qui a accès à pktcEventReset peut réinitialiser le tableau d'événements, avec pour résultat que la station de gestion ne reçoit plus les événements avec les descriptions attendues. De plus, une station de gestion félonne avec accès à pktcEventReset peut aussi supprimer les enregistrements locaux, éliminant les enregistrements locaux des événements générés pour les stations de gestion qui ne sont pas configurées à recevoir les messages syslog ou SNMP. Les mêmes soucis s'appliquent quand des stations de gestion autorisées à effectuer de telles opérations sont dans l'ignorance des autres stations de gestion qui peuvent dépendre du tableau d'événements ou du tableau d'enregistrement d'événements pour la gestion ou la surveillance. Ce module de MIB ne traite pas de telles discussions multi gestionnaires, et recommande que l'objet de MIB pktcEventReset soit utilisé avec prudence.

Certains des objets lisibles de ce module de MIB (c'est-à-dire, les objets avec un MAX-ACCESS autre que non accessible) peuvent être considérés comme sensibles ou vulnérables dans certains environnements de réseau. Il est donc important de contrôler même l'accès GET et/ou NOTIFY à ces objets et possiblement même de chiffrer les valeurs de ces objets quand on les envoie sur le réseau via SNMP. Ce sont les tableaux et objets et leur sensibilité/vulnérabilité :

pktcEventLogTable : Ce tableau contient l'enregistrement des messages d'événement générés. L'accès en lecture à ce tableau pourrait révéler des informations spécifiques qui devraient rester confidentielles.

pktcEventTransmissionStatus : Cet objet de MIB révèle l'état de la transmission d'événement et PEUT être sensible dans certains environnements.

Les versions de SNMP antérieures à SNMPv3 n'incluaient pas de sécurité adéquate. Même si le réseau lui-même est sûr (par exemple en utilisant IPsec) il n'y a même alors pas de contrôle sur qui sur le réseau sûr a la permission d'accéder et faire des opérations GET/SET (lire/changer/créer/supprimer) sur les objets de ce module de MIB.

Il est RECOMMANDÉ que les mises en œuvre examinent les caractéristiques de sécurité telles que fournies par le cadre SNMPv3 (voir la [RFC3410], section 8) incluant la pleine prise en charge des mécanismes cryptographiques pour SNMPv3 (pour l'authentification et la confidentialité).

De plus, le déploiement des versions SNMP antérieures à SNMPv3 n'est PAS RECOMMANDÉ. Il est plutôt RECOMMANDÉ de déployer SNMPv3 et d'activer la sécurité cryptographique. Il est alors de la responsabilité du consommateur/opérateur de s'assurer que l'entité SNMP qui donne accès à une instance de ce module de MIB, est configurée de façon appropriée pour donner accès aux objets aux seuls principaux (utilisateurs) qui ont des droits légitimes pour effectuer des opérations GET ou SET (changer/créer/supprimer).

 	9.	Remerciements

Les auteurs tiennent à remercier les membres du groupe de travail de l'IETF IP sur réseaux de données par câble (IPCDN) et l'équipe d'étude du provisionnement CableLabs PacketCable de leurs contributions, commentaires, et suggestions.

Des remerciements particuliers sont adressés aux personnes suivantes (par ordre alphabétique des prénoms) : Dan Romascanu, David Harrington, Greg Nakanishi, Jean-François Mule, John Berg, Kevin Marez, Paul Duffy, Peter Bates, Randy Presuhn, Rich Woundy, Rick Vetter, Roy Spitzer, et Satish Kumar.

Le principal éditeur (Sumanth) souhaite remercier les docteurs en MIB David Harrington et Dan Romascanu, Lars Eggert et Pasi Eronen, ainsi que Rich Woundy pour leurs retours d'expert et leurs nombreuses suggestions pour améliorer ce document.

 	10.	Références normatives

[IANA-ENTERPRISE]	"IANA Private Enterprise Numbers", http://www.iana.org/

[ITU-T-J176]	Recommandation UIT-T J.176, "MIB de mécanisme d'événement de gestion IPCablecom", août 2002.

[PKT-SP-EVEMIB1.5] "PacketCable(TM) Management Event MIB Specification", PKT-SP-EVEMIB1.5-I02-050812, août 2005.

[PKT-SP-MEM1.5]	"PacketCable(TM) Management Event Mechanism Specification", PKT-SP-MEM1.5-I02-050812, août 2005.

[PKT-SP-PROV]	 "PacketCable MTA Device Provisioning Specification", PKT-SP-PROV-I11-050812.

[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

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

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

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

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

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

[RFC3195]	D. New, M. Rose, "Livraison fiable pour syslog", novembre 2001. (P.S.)

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

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

[RFC4001]	M. Daniele et autres, "Conventions textuelles pour les adresses réseau Internet", février 2005. (P.S.)

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

[RFC5425]	F. Miao et autres, "Sécurité de la couche Transport (TLS) : transposition de Transport pour Syslog", mars 2009. (P. S.)

[RFC5426]	A. Okmianski, "Transmission de messages Syslog sur UDP" mars 2009. (P. S.)

[RFC5427]	G. Keeni, "Conventions textuelles pour gestion Syslog", mars 2009. (P. S.)

[TS101909-22]	ETSI TS 101 909-22, "Digital Broadband Cable Access to the Public Telecommunications Network, IP Multimedia Time Critical Services, Part 22, Management Event Messages".

 	11.	Références pour information

[PKT-SP-CODEC]	"Packetcable Audio/Video Codecs Specification", PKT-SP-CODEC-I06-050812.

[PKT-SP-MGCP]	"Packetcable Network-Based Call Signaling Protocol Specification", PKT-SP-EC-MGCP-I11-050812.

[RFC3164]	C. Lonvick, "Protocole BSD de Syslog", août 2001. (Information)

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

[RFC3435]	F. Andreasen, B. Foster, "Protocole de contrôle de passerelle de prise en charge (MGCP) version 1.0", janvier 2003. (MàJ par RFC3661) (Information)

[RFC4682]	E. Nechamkin, J-F. Mule, "Base de données d'informations de gestion d'adaptateur de terminal multimédia (MTA) pour appareils conformes à PacketCable et IPCablecom", décembre 2006. (P.S.)

 	Adresse des auteurs

Sumanth Channabasappa	Wim De Ketelaere	Eugene Nechamkin	
Cable Television Laboratories, Inc.	tComLabs	Broadcom Corporation	
858 Coal Creek Circle,	Gildestraat 8	200 - 13711 International Place	
Louisville, CO 80027, USA	9000 Gent, Belgium	Richmond, BC, V6V 2Z8, Canada	
téléphone : +1 303-661-3307	téléphone : +32 9 269 22 90	téléphone : +1 604 233 8500	
mél : Sumanth@cablelabs.com	mél : deketelaere@tComLabs.com	mél : enechamkin@broadcom.com