draft-ietf-opsawg-syslog-snmp-02.txt   draft-ietf-opsawg-syslog-snmp-03.txt 
Network Working Group V. Marinov Network Working Group V. Marinov
Internet-Draft J. Schoenwaelder Internet-Draft J. Schoenwaelder
Intended status: Standards Track Jacobs University Bremen Intended status: Standards Track Jacobs University Bremen
Expires: September 27, 2009 March 26, 2009 Expires: November 16, 2009 May 15, 2009
Mapping Simple Network Management Protocol (SNMP) Notifications to Mapping Simple Network Management Protocol (SNMP) Notifications to
SYSLOG Messages SYSLOG Messages
draft-ietf-opsawg-syslog-snmp-02.txt draft-ietf-opsawg-syslog-snmp-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 27, 2009. This Internet-Draft will expire on November 16, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This memo defines a mapping from Simple Network Management Protocol This memo defines a mapping from Simple Network Management Protocol
(SNMP) notifications to SYSLOG notifications. (SNMP) notifications to SYSLOG messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 6 3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 6
3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10 4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
SNMP and SYSLOG are two widely used protocols to communicate event SNMP and SYSLOG are two widely used protocols to communicate event
notifications. Although co-existence of several management protocols notifications. Although co-existence of several management protocols
in one operational environment is possible, certain environments in one operational environment is possible, certain environments
require that all event notifications are collected by a single system require that all event notifications are collected by a single system
daemon such as a SYSLOG collector or an SNMP notification receiver daemon such as a SYSLOG collector or an SNMP notification receiver
skipping to change at page 3, line 30 skipping to change at page 3, line 30
event notifications [RFC3416] into SYSLOG messages [RFC5424]. We event notifications [RFC3416] into SYSLOG messages [RFC5424]. We
specify how the SYSLOG message format should be utilized to carry the specify how the SYSLOG message format should be utilized to carry the
information contained in an SNMP notification message. A new SYSLOG information contained in an SNMP notification message. A new SYSLOG
structured data element is defined which carries the PDU portion of structured data element is defined which carries the PDU portion of
an SNMP notification message. an SNMP notification message.
1.1. Conventions 1.1. Conventions
A system which has the capability of receiving SNMP notification A system which has the capability of receiving SNMP notification
messages from an SNMP Notification Originator and sending the SNMP messages from an SNMP Notification Originator and sending the SNMP
data contained inside in a SYSLOG message format to a SYSLOG receiver data contained inside in a SYSLOG message format to a SYSLOG
is referred in this memo as an "snmp-to-syslog translator". By collector is referred in this memo as an "snmp-to-syslog translator".
definition, such a system should have an SNMP Notification Receiver By definition, such a system should have an SNMP Notification
application and a SYSLOG sender application running in order to be Receiver application and a SYSLOG originator running in order to be
able to perform the functions of an "snmp-to-syslog translator". able to perform the functions of an "snmp-to-syslog translator".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
2.1. SNMP Notifications 2.1. SNMP Notifications
skipping to change at page 5, line 26 skipping to change at page 5, line 26
messages. messages.
This document assumes that notifications are in the format defined in This document assumes that notifications are in the format defined in
RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format
must be translated as described in Section 3.1 of RFC 3584 [RFC3584]. must be translated as described in Section 3.1 of RFC 3584 [RFC3584].
2.2. SYSLOG Notifications 2.2. SYSLOG Notifications
The SYSLOG protocol is defined in [RFC5424]. The message contains a The SYSLOG protocol is defined in [RFC5424]. The message contains a
global header and a number of structured data elements. The ABNF global header and a number of structured data elements. The ABNF
[RFC4234] representation of a SYSLOG message is defined in RFC XXXX [RFC4234] representation of a SYSLOG message is defined in RFC 5424
[RFC5424]. The relevant productions for structured data elements [RFC5424]. The relevant productions for structured data elements
are: are:
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME SD-ID = SD-NAME
PARAM-NAME = SD-NAME PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped. ; ']' MUST be escaped.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
; except '=', SP, ']', %d34 (") ; except '=', SP, ']', %d34 (")
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used ; "shortest form" MUST be used
OCTET = %d00-255 OCTET = %d00-255
SP = %d32 SP = %d32
PRINTUSASCII = %d33-126 PRINTUSASCII = %d33-126
NILVALUE = "-" NILVALUE = "-"
3. Mapping SNMP Notifications to SYSLOG Notifications 3. Mapping SNMP Notifications to SYSLOG Messages
In this section, we define how the scopedPDU portion from a SNMP In this section, we define how the scopedPDU portion from a SNMP
notification message is used to generate a message in the SYSLOG notification message is used to generate a message in the SYSLOG
format. The notification receiver application at the snmp-to-syslog format. The notification receiver application at the snmp-to-syslog
translator is listening for incoming notifications. After a translator is listening for incoming notifications. After a
notification is received by the SNMP engine the data portion is notification is received by the SNMP engine the data portion is
forwarded to the notification receiver application. The data portion forwarded to the notification receiver application. The data portion
contains the scopedPDU portion of the message which is used by the contains the scopedPDU of the message which is used by the SYSLOG
SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG originator on the snmp-to-syslog translator to generate a SYSLOG
notification and send it to a SYSLOG receiver. A common scenario is message and send it to a SYSLOG collector (or proxy). Note that
the following: every SNMP notification maps to exactly one SYSLOG message.
+-------------------+ snmp +------------+ +------------+ +------------------+
| |notification |snmp | |snmp | snmp | | syslog +---------+
+---------+ syslog | +-------------+ |<------------|notification| |notification| notification | +------------+ | message |syslog |
|syslog |notification| |syslog sender| | |originator | |originator |------------->| |syslog | |-------->|collector|
|collector|<-----------| +-------------+ | +------------+ +------------+ | |originator | | +---------+
| | | +------------+ | snmp +------------+ +------------+ | +------------+ |
| | | |snmp | |notification |snmp | |snmp | snmp | +------------+ | syslog +---------+
+---------+ | |notification| |<------------|notification| |notification| notification | |snmp | | message |syslog |
| |receiver | | |originator | |originator |------------->| |notification| |-------->|collector|
| +------------+ | +------------+ +------------+ | |receiver | | +---------+
| snmp-to-syslog |snmp +------------+ +------------+ | +------------+ |
| translator |notification |snmp | |snmp | snmp | |
| |<------------|notification| |notification| notification | snmp-to-syslog |
+-------------------+ |originator | |originator |------------->| translator |
+------------+ +------------------+
There can be many SNMP notification originators which send SNMP event A common deployment scenario is shown above. There can be many SNMP
notifications to a snmp-to-syslog translator. The snmp-to-syslog notification originators which send SNMP event notifications to a
translator extracts the data portion of the notification, generates a snmp-to-syslog translator. The snmp-to-syslog translator extracts
SYSLOG message, and send the SYSLOG message to a SYSLOG collector, the data portion of the notification, generates a SYSLOG message, and
which is responsible for collecting and storing all notification send the SYSLOG message to a SYSLOG collector, which is responsible
messages. for collecting and storing all notification messages.
The snmp-to-syslog translator is not transparent for a SYSLOG The snmp-to-syslog translator is not transparent for a SYSLOG
receiver. The global header of the SYSLOG message generated by the collector. The global header of the SYSLOG message generated by the
snmp-to-syslog translator is filled with parameters that are specific snmp-to-syslog translator is filled with parameters that are specific
for the system running the snmp-to-syslog translator such as its for the system running the snmp-to-syslog translator such as its
hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or
PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained
in the structured data of the SYSLOG message. in the structured data of the SYSLOG message.
Implementations MUST drop invalid SNMP messages before they are Implementations MUST drop invalid SNMP messages before they are
passed to the snmp-to-syslog translator. passed to the snmp-to-syslog translator.
3.1. SYSLOG Header 3.1. SYSLOG Header
skipping to change at page 8, line 39 skipping to change at page 8, line 39
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57 NONZERODIGIT = %d49-57
ZERO = %d48 ZERO = %d48
DIGIT = ZERO / NONZERODIGIT DIGIT = ZERO / NONZERODIGIT
SP = %d32 SP = %d32
Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two
SD-ID parameters are "ctxEngine" and "ctxName". They must be present SD-ID parameters are "ctxEngine" and "ctxName". They must be present
in an SNMPv3 notification and therefore they must be present in a in an SNMPv3 notification and therefore they must be present in a
SYSLOG message generated by an snmp-to-syslog translator from an SYSLOG message generated by an snmp-to-syslog translator from an
SNMPv3 notification. The contexdEngineID is encoded as as SNMPv3 notification. The contexdEngineID is encoded as an
hexadecimal string while the contextName is encoded as a UTF8 string. hexadecimal string while the contextName is encoded as a UTF8 string.
The remaining parameters in the "snmp" SD-ID correspond to the The remaining parameters in the "snmp" SD-ID correspond to the
varbind list elements contained in the SNMP PDU. The name of a varbind list elements contained in the SNMP PDU. The name of a
varbind is encoded as an OID in dotted notation. The rendered OID is varbind is encoded as an OID in dotted notation. The rendered OID is
carried in a "vN" parameter, where N identifies the position of the carried in a "vN" parameter, where N identifies the position of the
varbind in the varbind list of the SNMP message (the first varbind varbind in the varbind list of the SNMP message (the first varbind
having the position 1). A MIB aware implementation may in addition having the position 1). A MIB aware implementation may in addition
generate a parameter "lN" carrying the descriptor of the associated generate a parameter "lN" carrying the descriptor of the associated
MIB object plus the instance identifier suffix (also called an OID MIB object plus the instance identifier suffix (also called an OID
skipping to change at page 9, line 48 skipping to change at page 9, line 48
| Opaque | pN | hexadecimal (BER) string | | Opaque | pN | hexadecimal (BER) string |
| TimeTicks | tN | unsigned decimal number | | TimeTicks | tN | unsigned decimal number |
| NULL | nN | zero-length string | | NULL | nN | zero-length string |
+--------------------+------------+--------------------------+ +--------------------+------------+--------------------------+
Table 1: Mapping of SNMP Types to SD Params Table 1: Mapping of SNMP Types to SD Params
The SYSLOG message generated by the snmp-to-syslog translator may The SYSLOG message generated by the snmp-to-syslog translator may
include other structured data elements in its structured part in include other structured data elements in its structured part in
addition to the SNMP-SD-ELEMENT. These structured data elements are addition to the SNMP-SD-ELEMENT. These structured data elements are
included in the SYSLOG message by the SYSLOG sender at the snmp-to- included in the SYSLOG message by the SYSLOG originator at the snmp-
syslog translator and must be compliant to the specification in to-syslog translator and must be compliant to the specification in
[RFC5424]. [RFC5424].
In particular, the parameters in the "origin" SD-ID should identify In particular, the parameters in the "origin" SD-ID should identify
the originator of the SNMP notification. A suitable value for the the originator of the SNMP notification. A suitable value for the
"ip" parameter may be taken from the snmpTrapAddress varbind if "ip" parameter may be taken from the snmpTrapAddress varbind if
present and a suitable value for the "enterpriseId" parameter may be present and a suitable value for the "enterpriseId" parameter may be
extracted from snmpTrapOID varbind. extracted from snmpTrapOID varbind.
3.3. MSG Data 3.3. MSG Data
The MSG part of the SYSLOG message is optional and may contain a The MSG part of the SYSLOG message is optional and may contain a
free-form message that provides a textual description of the SNMP free-form message that provides a textual description of the SNMP
event notification. The character set used in MSG SHOULD be UNICODE, event notification. The character set used in MSG SHOULD be UNICODE,
encoded using UTF-8 as specified in [RFC3629]. If the sender can not encoded using UTF-8 as specified in [RFC3629]. If the originator can
encode the MSG in Unicode, it MAY use any other encoding. not encode the MSG in Unicode, it MAY use any other encoding.
4. Relationship to the SYSLOG-MSG-MIB 4. Relationship to the SYSLOG-MSG-MIB
A companion document defines an SNMP MIB module to represent SYSLOG A companion document defines an SNMP MIB module to represent SYSLOG
messages and to send SYSLOG messages as SNMP notifications to SNMP messages and to send SYSLOG messages as SNMP notifications to SNMP
notification receivers [I-D.ietf-opsawg-syslog-msg-mib]. This notification receivers [I-D.ietf-opsawg-syslog-msg-mib]. This
section discusses the possibilities of using both specifications in section discusses the possibilities of using both specifications in
combination to create notification "tunnels". combination.
A SYSLOG receiver supporting an SNMP notification originator A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the
implementing this specification SHOULD translate received SYSLOG mapping of SNMP notifications to SYSLOG messages may be configured to
messages containing SNMP notifications back into the SNMP translate received SYSLOG messages containing SNMP notifications back
notifications. This allows operators to build a forwarding chain into the original SNMP notification. In this case, the relevant
where SNMP notifications are "tunneled" through SYSLOG messages. tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG
messages carrying SNMP notifications. This configuration allows
operators to build a forwarding chain where SNMP notifications are
"tunneled" through SYSLOG messages. Due to size restrictions of the
SYSLOG transports and the more verbose textual encoding used by
SYSLOG, there is a possibility that SNMP notification content gets
truncated while tunneled through SYSLOG and thus the resulting SNMP
notification may be incomplete.
Due to size restrictions of the SYSLOG transports and the more An SNMP management application supporting the SYSLOG-MSG-MIB and the
verbose textual encoding used by SYSLOG, there is a possibility that mapping of SNMP notifications to SYSLOG messages may process
SNMP notification content gets truncated while tunneled through information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message
SYSLOG and thus the resulting SNMP notification may be incomplete. representing the SYSLOG message recorded in the SYSLOG-MSG-MIB
module. This configuration allows operators to build a forwarding
chain where SYSLOG messages are "tunneled" through SNMP messages. A
notification receiver can determine whether a syslogMsgNotification
contained all structured data element parameters of a SYSLOG message.
In case parameters are missing, a forwarding application MUST
retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular
polling of the SYSLOG-MSG-MIB can be used to take care of any lost
SNMP notifications.
5. Usage Example 5. Usage Example
Here we provide an example how an SNMP linkUp trap message is mapped Here we provide an example how an SNMP linkUp trap message is mapped
into a SYSLOG message by using the mappings defined in Section 3.1 into a SYSLOG message by using the mappings defined in Section 3.1
and Section 3.2. and Section 3.2.
The linkUp notification is defined in [RFC2863]: The linkUp notification is defined in [RFC2863]:
linkUp NOTIFICATION-TYPE linkUp NOTIFICATION-TYPE
skipping to change at page 11, line 18 skipping to change at page 11, line 26
DESCRIPTION DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an "A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and one of its communication links left the down state and
transitioned into some other state (but not into the transitioned into some other state (but not into the
notPresent state). This other state is indicated by the notPresent state). This other state is indicated by the
included value of ifOperStatus." included value of ifOperStatus."
::= { snmpTraps 4 } ::= { snmpTraps 4 }
The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3
message format is show below (left columns shows the BER encoding message format is shown below (left columns shows the BER encoding
while the right column indicates the corresponding ASN.1 while the right column indicates the corresponding ASN.1
definitions): definitions):
30:7C SEQUENCE { 30:7C SEQUENCE {
04:08:80:00:02:B8:04:61:62:63 800002b804616263 04:08:80:00:02:B8:04:61:62:63 800002b804616263
04:04:63:74:78:31 "ctx1" 04:04:63:74:78:31 "ctx1"
A7:6A SNMPv2-Trap-PDU { A7:6A SNMPv2-Trap-PDU {
02:03:6D:08:67 INTEGER 7145575 02:03:6D:08:67 INTEGER 7145575
02:01:00 INTEGER 0 02:01:00 INTEGER 0
02:01:00 INTEGER 0 02:01:00 INTEGER 0
skipping to change at page 13, line 38 skipping to change at page 13, line 45
The SNMP architecture supports an access control mechanism ensuring The SNMP architecture supports an access control mechanism ensuring
that SNMP notifications are only sent to receivers who are authorized that SNMP notifications are only sent to receivers who are authorized
to receive the notification. Users of this mapping of SNMP to receive the notification. Users of this mapping of SNMP
notifications to SYSLOG messages should enforce a consistent policy notifications to SYSLOG messages should enforce a consistent policy
preventing people from accessing SNMP notifications via the SYSLOG preventing people from accessing SNMP notifications via the SYSLOG
mapping that would otherwise not be accessible. mapping that would otherwise not be accessible.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Martin Bjorklund, Washam Fan, Rainer The authors wish to thank Martin Bjorklund, Washam Fan, Rainer
Gerhards and all other people who commented on various versions of Gerhards, Tom Petch and all other people who commented on various
this proposal. versions of this proposal.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-opsawg-syslog-msg-mib] [I-D.ietf-opsawg-syslog-msg-mib]
Schoenwaelder, J., Clemm, A., and A. Karmakar, Schoenwaelder, J., Clemm, A., and A. Karmakar,
"Definitions of Managed Objects for Mapping SYSLOG "Definitions of Managed Objects for Mapping SYSLOG
Messages to Simple Network Management Protocol (SNMP) Messages to Simple Network Management Protocol (SNMP)
Notifications", Internet Draft (work in progress), Notifications", Internet Draft (work in progress),
 End of changes. 22 change blocks. 
58 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/