idnits 2.17.1 draft-ietf-opsawg-syslog-snmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2009) is 5554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '7' on line 141 -- Looks like a reference, but probably isn't: '0' on line 157 -- Looks like a reference, but probably isn't: '1' on line 158 -- Looks like a reference, but probably isn't: '2' on line 159 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Marinov 3 Internet-Draft J. Schoenwaelder 4 Intended status: Standards Track Jacobs University Bremen 5 Expires: August 14, 2009 February 10, 2009 7 Mapping Simple Network Management Protocol (SNMP) Notifications to 8 SYSLOG Messages 9 draft-ietf-opsawg-syslog-snmp-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 14, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This memo defines a mapping from Simple Network Management Protocol 49 (SNMP) notifications to SYSLOG notifications. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 57 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 58 3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 5 59 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 61 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 SNMP and SYSLOG are two widely used protocols to communicate event 74 notifications. Although co-existence of several management protocols 75 in one operational environment is possible, certain environments 76 require that all event notifications are collected by a single system 77 daemon such as a SYSLOG collector or an SNMP notification receiver 78 via a single management protocol. In such environments, it is 79 necessary to translate event notifications between management 80 protocols. 82 The latest version of SYSLOG, specified in 83 [I-D.ietf-syslog-protocol], supports a structured data element 84 format. Structured data elements allow us to map between SNMP 85 notifications and SYSLOG messages without losing information. In 86 this memo we specify a concrete mapping from SNMP event notifications 87 [RFC3416] into SYSLOG messages [I-D.ietf-syslog-protocol]. We 88 specify how the SYSLOG message format should be utilized to carry the 89 information contained in an SNMP notification message. A new SYSLOG 90 structured data element is defined which carries the PDU portion of 91 an SNMP notification message. 93 1.1. Conventions 95 A system which has the capability of receiving SNMP notification 96 messages from an SNMP Notification Originator and sending the SNMP 97 data contained inside in a SYSLOG message format to a SYSLOG receiver 98 is referred in this memo as an "snmp-to-syslog translator". By 99 definition, such a system should have an SNMP Notification Receiver 100 application and a SYSLOG sender application running in order to be 101 able to perform the functions of an "snmp-to-syslog translator". 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Background 109 2.1. SNMP Notifications 111 A detailed introduction to the SNMP Management Framework can be found 112 in [RFC3410]. The SNMP Management Architecture is described in 113 [RFC3411]. Managed objects are accessed via a virtual information 114 store, termed the Management Information Base or MIB [RFC3418]. 115 Objects in the MIB are defined using the mechanisms defined in the 116 SMI [RFC2578]. 118 An SNMP notification message is generated and transmitted by an SNMP 119 entity on behalf of a Notification Originator application [RFC3413]. 120 SNMP notifications are often used to notify a Notification Receiver 121 application at a logically remote SNMP entity that an event has 122 occurred or that a certain condition is present. There are two types 123 of SNMP protocol operations that are associated with SNMP 124 notification messages [RFC3416]: 126 o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanisms 127 o InformRequest-PDU, a confirmed notification delivery mechanism 129 The scopedPDU portion of an SNMPv3 trap or inform message has the 130 following format [RFC3412]: 132 ScopedPDU ::= SEQUENCE { 133 contextEngineID OCTET STRING, 134 contextName OCTET STRING, 135 data ANY -- e.g., PDUs as defined in [RFC3416] 136 } 138 The data member of the SEQUENCE ScopedPDU carries a SNMPv2-Trap-PDU 139 or an InformRequest-PDU. They both have the same structure: 141 PDUs ::= [7] IMPLICIT SEQUENCE { 142 request-id INTEGER, 143 error-status INTEGER, -- ignored in notifications 144 error-index INTEGER, -- ignored in notifications 145 variable-bindings VarBindList 146 } 148 -- variable binding 150 VarBind ::= SEQUENCE { 151 name ObjectName, 153 CHOICE { 154 value ObjectSyntax, 155 unSpecified NULL, -- in retrieval requests 156 -- exceptions in responses 157 noSuchObject [0] IMPLICIT NULL, 158 noSuchInstance [1] IMPLICIT NULL, 159 endOfMibView [2] IMPLICIT NULL 160 } 161 } 163 -- variable-binding list 165 VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind 167 The first two variable bindings in the variable binding list of an 168 SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and 169 snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is 170 present in the invocation of the corresponding NOTIFICATION-TYPE 171 macro, then each corresponding variable, as instantiated by this 172 notification, is copied, in order, to the variable-bindings field. 173 If any additional variables are being included (at the option of the 174 generating SNMP entity), then each is copied to the variable-bindings 175 field. 177 In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID 178 and the contextName parameters are not present in notification 179 messages. In general, we assume that notifications from an SNMP 180 version preceding SNMPv3 are mapped into the notification format used 181 by SNMPv3 according to the coexistance rules defined in RFC 3584 182 [RFC3584]. 184 2.2. SYSLOG Notifications 186 The SYSLOG protocol is defined in [I-D.ietf-syslog-protocol]. The 187 message contains a global header and a number of structured data 188 elements. The ABNF [RFC4234] representation of a SYSLOG message is 189 defined in RFC XXXX [I-D.ietf-syslog-protocol]. The relevant 190 productions for structured data elements are: 192 STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT 193 SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" 194 SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 195 SD-ID = SD-NAME 196 PARAM-NAME = SD-NAME 197 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and 198 ; ']' MUST be escaped. 199 SD-NAME = 1*32PRINTUSASCII 200 ; except '=', SP, ']', %d34 (") 202 UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 203 ; "shortest form" MUST be used 205 OCTET = %d00-255 206 SP = %d32 207 PRINTUSASCII = %d33-126 208 NILVALUE = "-" 210 3. Mapping SNMP Notifications to SYSLOG Notifications 212 In this section, we define how the scopedPDU portion from a SNMP 213 notification message is used to generate a message in the SYSLOG 214 format. The notification receiver application at the snmp-to-syslog 215 translator is listening for incoming notifications. After a 216 notification is received by the SNMP engine the data portion is 217 forwarded to the notification receiver application. The data portion 218 contains the scopedPDU portion of the message which is used by the 219 SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG 220 notification and send it to a SYSLOG receiver. A common scenario is 221 the following: 223 +-------------------+ snmp +------------+ 224 | |notification |snmp | 225 +---------+ syslog | +-------------+ |-------------|notification| 226 |syslog |notification| |syslog sender| | |originator | 227 |collector|------------| +-------------+ | +------------+ 228 | | | +------------+ | snmp +------------+ 229 | | | |snmp | |notification |snmp | 230 +---------+ | |notification| |-------------|notification| 231 | |receiver | | |originator | 232 | +------------+ | +------------+ 233 | snmp-to-syslog |snmp +------------+ 234 | translator |notification |snmp | 235 | |-------------|notification| 236 +-------------------+ |originator | 237 +------------+ 239 There can be many SNMP notification originators which send SNMP event 240 notifications to a snmp-to-syslog translator. The snmp-to-syslog 241 translator extracts the data portion of the notification, generates a 242 SYSLOG message, and send the SYSLOG message to a SYSLOG collector, 243 which is responsible for collecting and storing all notification 244 messages. 246 The snmp-to-syslog translator is not transparent for a SYSLOG 247 receiver. The global header of the SYSLOG message generated by the 248 snmp-to-syslog translator is filled with parameters that are specific 249 for the system running the snmp-to-syslog translator such as its 250 hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or 251 PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained 252 in the structured data of the SYSLOG message. 254 Implementations MUST drop invalid SNMP messages before they are 255 passed to the snmp-to-syslog translator. 257 3.1. SYSLOG Header 259 The snmp-to-syslog translator fills the HEADER field of a SYSLOG 260 message with parameters specific to the system on which it is 261 running. The default facility level for SYSLOG messages containing 262 SNMP notifications should be 3, which corresponds to messages 263 generated by system daemons. The default severity level should be 5, 264 which correponds to "Notice: normal but significant condition". If 265 the snmp-to-syslog translator has a notion of the type of 266 notification that has been received it might choose other values for 267 facility and severity level. 269 The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID and MSGID fields 270 in the SYSLOG message header are filled with values that are specific 271 to the system on which the snmp-to-syslog translator is running. The 272 character set used in the HEADER MUST be seven-bit ASCII in an eight- 273 bit field as described in [I-D.ietf-syslog-protocol]. 275 3.2. Structured Data 277 The STRUCTURED-DATA field of a SYSLOG message will contain the 278 ScopedPDU (or PDU) portion of the SNMP notification message. For the 279 purpose of carrying SNMP notification data, a new SD-ID element is 280 defined. The ABNF [RFC4234] representation of the new structured 281 element is: 283 SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]" 284 SNMP-SD-ID = %x73.6E.6D.70 ; snmp 285 CTX = CTXENGINE CTXNAME 286 CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34 287 CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34 288 VARBIND = SP VARNAME SP [VARLABEL SP] VARVALUE 289 VARNAME = "v=" %d34 OID %d34 290 VARLABEL = "l=" %d34 PARAM-VALUE %d34 291 VARVALUE = VALOID / VALSTRING / VALCOUNTER32 / VALCOUNTER64 292 / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL 293 / VALOPAQUE / VALTIMETICKS 295 VALOID = "o=" %d34 OID %d34 296 VALSTRING = "x=" %d34 HEXSTRING %d34 297 VALCOUNTER32 = "c=" %d34 UNSIGNED32 %d34 298 VALCOUNTER64 = "C=" %d34 UNSIGNED64 %d34 299 VALUNSIGNED32 = "u=" %d34 UNSIGNED32 %d34 300 VALINTEGER32 = "d=" %d34 INTEGER32 %d34 301 VALIP = "i=" %d34 IPV4ADDRESS %d34 302 VALNULL = "n=" %d34 NULL %d34 303 VALOPAQUE = "p=" %d34 HEXSTRING %d34 304 VALTIMETICKS = "t=" %d34 UNSIGNED32 %d34 305 OID = OIDSTART *("." OIDSUBID) 306 OIDSTART = (("0." / "1.")[%d49-51] DIGIT) / ("2." OIDSUBID) 307 OIDSUBID = ZERO / (NONZERODIGIT *DIGIT) 309 PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and 310 ; ']' MUST be escaped. 311 UTF-8-STRING = *OCTET ; Any VALID UTF-8 String 312 ; "shortest form" MUST be used 313 HEXSTRING = *HEX 314 INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT 315 UNSIGNED32 = NONZERODIGIT 0*DIGIT 316 UNSIGNED64 = NONZERODIGIT 0*DIGIT 317 NULL = "" 318 IPV4ADDRESS = d8 "." d8 "." d8 "." d8 320 d8 = DIGIT ; 0-9 321 / %d49-57 DIGIT ; 10-99 322 / "1" 2DIGIT ; 100-199 323 / "2" %d48-52 DIGIT ; 200-249 324 / "25" %d48-53 ; 250-255 326 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 327 NONZERODIGIT = %d49-57 328 ZERO = %d48 329 DIGIT = ZERO / NONZERODIGIT 330 SP = %d32 332 Each SNMP-SD-ELEMENT starts with a SD-ID="snmp". The first two 333 PARAM-NAME elements are "ctxEngine" and "ctxName". They must be 334 present in an SNMPv3 notification and therefore they must be present 335 in a SYSLOG message generated by an snmp-to-syslog translator. The 336 contexdEngineID is encoded as as hexadecimal string and the 337 contextName is encoded as a hexadecimal string. 339 The remaining parameters correspond to the varbind list elements. 340 The name of a varbind is encoded as an OID in dotted notation and the 341 values are encoded according to the rules shown in Table 1: 343 +--------------------+------------+--------------------------+ 344 | SNMP Type | PARAM-NAME | Value Encoding | 345 +--------------------+------------+--------------------------+ 346 | OBJECT IDENTIFIER | o | dotted-decimal notation | 347 | OCTET STRING | x | hexadecimal string | 348 | Counter32 | c | unsigned decimal number | 349 | Counter64 | C | unsigned decimal number | 350 | Unsigned32 | u | unsigned decimal number | 351 | INTEGER, Integer32 | d | signed decimal number | 352 | IpAddress | i | dotted quad notation | 353 | Opaque | p | hexadecimal (BER) string | 354 | TimeTicks | t | unsigned decimal number | 355 | NULL | n | zero-length string | 356 +--------------------+------------+--------------------------+ 358 Table 1: Mapping of SNMP Types to SD Params 360 The SYSLOG message generated by the snmp-to-syslog translator may 361 include other structured data elements in its structured part in 362 addition to the SNMP-SD-ELEMENT. These structured data elements are 363 included in the SYSLOG message by the SYSLOG sender at the snmp-to- 364 syslog translator and must be compliant to the specification in 365 [I-D.ietf-syslog-protocol]. 367 In particular, the parameters in the "origin" SD-ID should identify 368 the originator of the SNMP notification. A suitable value for the 369 "ip" parameter may be taken from the snmpTrapAddress varbind if 370 present and a suitable value for the "enterpriseId" parameter may be 371 extracted from snmpTrapOID varbind. 373 3.3. MSG Data 375 The MSG part of the SYSLOG message is optional and may contain a 376 free-form message that provides a textual description of the SNMP 377 event notification. The character set used in MSG SHOULD be UNICODE, 378 encoded using UTF-8 as specified in [RFC3629]. If the sender can not 379 encode the MSG in Unicode, it MAY use any other encoding. 381 4. Usage Example 383 Here we provide an example how an SNMP linkUp trap message is mapped 384 into a SYSLOG message by using the mappings defined in Section 3.1 385 and Section 3.2. 387 The linkUp notification is defined in [RFC2863]: 389 linkUp NOTIFICATION-TYPE 390 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 391 STATUS current 392 DESCRIPTION 393 "A linkUp trap signifies that the SNMP entity, acting in an 394 agent role, has detected that the ifOperStatus object for 395 one of its communication links left the down state and 396 transitioned into some other state (but not into the 397 notPresent state). This other state is indicated by the 398 included value of ifOperStatus." 399 ::= { snmpTraps 4 } 401 The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 402 message format is show below (left columns shows the BER encoding 403 while the right column indicates the corresponding ASN.1 404 definitions): 406 30:7C SEQUENCE { 407 04:08:80:00:02:B8:04:61:62:63 800002b804616263 408 04:04:63:74:78:31 "ctx1" 409 A7:6A SNMPv2-Trap-PDU { 410 02:03:6D:08:67 INTEGER 7145575 411 02:01:00 INTEGER 0 412 02:01:00 INTEGER 0 413 30:5D SEQUENCE OF { 414 30:0F SEQUENCE { 415 06:08:2B:06:01:02:01:01:03:00 sysUpTime.0 416 43:03:01:72:8C 94860 } 417 30:17 SEQUENCE { 418 06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0 419 06:09:2B:06:01:06:03:01:01:05:04 linkUp } 420 30:0F SEQUENCE { 421 06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3 422 02:01:03 3 } 423 30:0F SEQUENCE { 424 06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3 425 02:01:01 up(1) } 426 30:0F SEQUENCE { 427 06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3 428 02:01:01 up(1) } } } } 430 The corresponding SYSLOG message generated by the snmp-to-syslog 431 translator is shown below. (SYSLOG examples should be considered to 432 be on one line. They are wrapped on multiple lines in this document 433 for readability purposes only.) 435 <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 436 [snmp ctxEngine="800002b804616263" ctxName="ctx1" 437 v="1.3.6.1.2.1.1.3.0" l="sysUpTime.0" d="94860" 438 v="1.3.6.1.6.3.1.1.4.1.0" l="snmpTrapOID.0" o="1.3.6.1.6.3.1.1.5.4" 439 v="1.3.6.1.2.1.2.2.1.1.3" d="3" 440 v="1.3.6.1.2.1.2.2.1.7.3" d="1" 441 v="1.3.6.1.2.1.2.2.1.8.3" d="1"] 443 The corresponding SYSLOG message has a priority value of 29 which 444 means a facility level of 3 (system daemons) and a severity level of 445 5 (Notice: Normal but significant condition) according to the 446 algorithm for calculation of priority value specified in section 447 6.2.1 of [I-D.ietf-syslog-protocol]. The rest of the fields in the 448 header of the SYSLOG message are parameters that are specific to the 449 system running the snmp-to-syslog translator. The SYSLOG version is 450 1 and the message was generated at 22:14:15.003Z on 2003-10-11T by 451 the host "mymachine.example.com". The application on the snmp-to- 452 syslog translator that generated the message was "snmptrapd", there 453 is no information about the process id and the message on the snmp- 454 to-syslog system is identified with the MSGID of ID47. 456 The SYSLOG message contains one structured data element with a SD-ID 457 of "snmp" which means that this is the scopedPDU portion of an SNMP 458 event notification message. The data which is contained in the 459 notification is associated with the ContextEngineID "123456" and 460 ContextName "ctx1". The request-id of the SNMP notification message 461 was "7145575". Then follows the data portion of the scopedPDU. The 462 first two variables contained in the data portion are always the 463 sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of 464 "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The 465 parameters v="1.3.6.1.2.1.2.2.1.1.3" d="3" mean that the SNMP 466 notification message is carrying the ifIndex object which has a type 467 INTEGER and has a value of 3. The parameters 468 v="1.3.6.1.2.1.2.2.1.7.3" d="1" mean that the SNMP notification 469 message is carrying the object ifAdminStatus which has type INTEGER 470 and a value of 1. The parameters v="1.3.6.1.2.1.2.2.1.8.3" d="1" 471 mean that the SNMP notification message is carrying the object 472 ifOperStatus which has type INTEGER and a value of "1". 474 5. IANA Considerations 476 IANA is requested to register the SD-ID value "snmp" together with 477 the PARAM-NAME values specified in Section 3.2 in the registry for 478 SYSLOG structured data id values according to section 9 in 479 [I-D.ietf-syslog-protocol]. 481 SD-ID PARAM-NAME 482 snmp OPTIONAL 483 ctxEngine OPTIONAL 484 ctxName OPTIONAL 485 v OPTIONAL 486 l OPTIONAL 487 o OPTIONAL 488 x OPTIONAL 489 c OPTIONAL 490 C OPTIONAL 491 u OPTIONAL 492 d OPTIONAL 493 i OPTIONAL 494 n OPTIONAL 495 p OPTIONAL 496 t OPTIONAL 498 6. Security Considerations 500 The security considerations discussed in [I-D.ietf-syslog-protocol] 501 apply to this document. 503 The SNMP architecture supports an access control mechanism ensuring 504 that SNMP notifications are only sent to receivers who are authorized 505 to receive the notification. Users of this mapping of SNMP 506 notifications to SYSLOG messages should enforce a consistent policy 507 preventing people from accessing SNMP notifications via the SYSLOG 508 mapping that would otherwise not be accessible. 510 7. Acknowledgments 512 The authors wish to thank Rainer Gerhards and all other people who 513 commented on various versions of this proposal. 515 8. References 517 8.1. Normative References 519 [I-D.ietf-syslog-protocol] 520 Gerhards, R., "The syslog Protocol", Internet Draft (work 521 in progress), September 2007. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 527 Architecture for Describing Simple Network Management 528 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 529 December 2002. 531 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 532 "Message Processing and Dispatching for the Simple Network 533 Management Protocol (SNMP)", STD 62, RFC 3412, 534 December 2002. 536 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 537 Management Protocol (SNMP) Applications", STD 62, 538 RFC 3413, December 2002. 540 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 541 Simple Network Management Protocol (SNMP)", STD 62, 542 RFC 3416, December 2002. 544 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 545 Simple Network Management Protocol (SNMP)", STD 62, 546 RFC 3418, December 2002. 548 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 549 "Coexistence between Version 1, Version 2, and Version 3 550 of the Internet-standard Network Management Framework.", 551 BCP 74, RFC 3584, August 2003. 553 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 554 Specifications: ABNF", RFC 4234, October 2005. 556 8.2. Informative References 558 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 559 "Structure of Management Information Version 2 (SMIv2)", 560 RFC 2578, STD 58, April 1999. 562 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 563 MIB", RFC 2863, June 2000. 565 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 566 "Introduction and Applicability Statements for Internet- 567 Standard Management Framework", RFC 3410, December 2002. 569 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 570 10646", STD 63, RFC 3629, November 2003. 572 Authors' Addresses 574 Vladislav Marinov 575 Jacobs University Bremen 576 Campus Ring 1 577 28725 Bremen 578 Germany 580 Email: v.marinov@jacobs-university.de 582 Juergen Schoenwaelder 583 Jacobs University Bremen 584 Campus Ring 1 585 28725 Bremen 586 Germany 588 Email: j.schoenwaelder@jacobs-university.de