idnits 2.17.1 draft-ietf-opsawg-syslog-alarm-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 64 lines 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2009) is 5449 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) == Missing Reference: 'Syslog' is mentioned on line 225, but not defined ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chisholm 3 Internet-Draft Nortel 4 Intended status: Standards Track R. Gerhards 5 Expires: November 27, 2009 Adiscon GmbH 6 May 26, 2009 8 Alarms in SYSLOG 9 draft-ietf-opsawg-syslog-alarm-02.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 other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 27, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes how to send alarm information in syslog. It 47 includes the mapping of ITU perceived severities onto syslog message 48 fields and a number of alarm-specific SD-PARAM definitions from X.733 49 and the IETF Alarm MIB. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Severity Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Alarm STRUCTURED-DATA Elements . . . . . . . . . . . . . . . . 5 56 3.1. resource . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. probableCause . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. perceivedSeverity . . . . . . . . . . . . . . . . . . . . 5 59 3.4. eventType . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.5. trendIndication . . . . . . . . . . . . . . . . . . . . . 6 61 3.6. resourceURI . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 14 72 1. Introduction 74 In addition to sending out alarm information asynchronously via 75 protocols such as SNMP or Netconf, many implementations also log 76 alarms via syslog. This memo defines a set of SD-PARAM to support 77 logging and defines a mapping of syslog severity to the severity of 78 the alarm. 80 The Alarm MIB (RFC 3877) included mandatory alarm fields from X.733 81 as well as information from X.736. In additional, the Alarm MIB 82 introduced its own alarm fields. This memo reuses terminology and 83 fields from the Alarm MIB. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 Alarm related terminology is defined in [RFC3877]. 91 2. Severity Mapping 93 The Alarm MIB [RFC3877] defines ITU perceived severities which are 94 useful to be able to relate to the syslog message fields, 95 particularly in the case where alarms are being logged. This memo 96 describes the representation of ITU perceived severities in 97 appropriate syslog fields described in [RFC5424]. Syslog offers both 98 a so-called SEVERITY as well as STRUCTURED-DATA. Due to constraints 99 in syslog, there is no one-to-one mapping possible for SEVERITY. A 100 STRUCTURED-DATA element is defined to allow inclusion of the 101 unmodified ITU perceived severity. 103 Syslog supports severity values different from ITU perceived 104 severities. These are defined in section 6.2.1 of [RFC5424]. The 105 mapping shown in table 1 below SHOULD be used to map ITU perceived 106 severities to syslog severities. 108 ITU Perceived Severity syslog SEVERITY (Name) 109 Critical 1 (Alert) 110 Major 2 (Critical) 111 Minor 3 (Error) 112 Warning 4 (Warning) 113 Indeterminate 5 (Notice) 114 Cleared 5 (Notice) 116 Table 1. ITUPerceivedSeverity to syslog SEVERITY mapping. 118 3. Alarm STRUCTURED-DATA Elements 120 STRUCTURED-DATA allows to include any structured information into a 121 syslog message. The following are defined to support structuring 122 alarm information. 124 o Resource Under Alarm 126 o Probable Cause 128 o Event Type 130 o Perceived Severity 132 o Trend Indication 134 o Resource URI 136 Support of the "alarm" SD-ID is optional, but once supported some of 137 the SD-PARARMS are mandatory. 139 3.1. resource 141 If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be 142 supported. This item uniquely identifies the resource under alarm 143 within the scope of a network element. 145 3.2. probableCause 147 If the "alarm" SD-ID is supported, the "probableCause" SD-PARAM MUST 148 be supported. This parameter is the mnemonic associated with the 149 IANAItuProbableCause object defined within [RFC3877] and any 150 subsequent extensions defined by IANA. For example, 151 IANAItuProbableCause defines a transmission failure to a probable 152 cause of 'transmissionError (10)'. The value of the parameter in 153 this case would be 'transmissionError'" 155 3.3. perceivedSeverity 157 If the "alarm" SD-ID is supported, the "perceivedSeverity" SD-PARAM 158 MUST be supported. Similar to the definition of perceived severity 159 in [X.736] and [RFC3877], this object can take the following values: 161 o cleared 163 o indeterminate 164 o critical 166 o major 168 o minor 170 o warning 172 See section 2 for the relationship between this severity and syslog 173 severity. 175 3.4. eventType 177 If the "alarm" SD-ID is supported, the "eventType" SD-PARAM SHOULD be 178 supported. This parameter is the mnemonic associated with the 179 IANAItuEventType object defined within [RFC3877] and any subsequent 180 extensions defined by IANA. For example, IANAItuEventType defines a 181 environmental alarm to a event type of 'environmentalAlarm (6)'. The 182 value of the parameter in this case would be 'environmentalAlarm'" 184 3.5. trendIndication 186 If the "alarm" SD-ID is supported, the "trendIndication" SD-PARAM 187 SHOULD be supported. Similar to the definition of perceived severity 188 in [X.733] and [RFC3877], this object can take the following values: 190 o moreSevere 192 o noChange 194 o lessSevere 196 3.6. resourceURI 198 If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD 199 be supported. This item uniquely identifies the resource under 200 alarm. 202 The value of this field MUST conform to the URI definition in 203 [RFC1738] and its updates. In the case of an SNMP resource, the 204 syntax in [RFC4088] MUST be used and "resourceURI" must point to the 205 same resource as alarmActiveResourceId [RFC3877] for this alarm. 207 Both the "resource" and the "resourceURI" parameters point at the 208 resource experiencing the alarm, but the "resourceURI" has syntactic 209 constraint requiring it to be a URI. This makes it easy to correlate 210 this syslog alarm with any alarms that are received via other 211 protocols, such as SNMP or to use SNMP or other protocols to get 212 additional information about this resource. 214 4. Examples 216 Example 1 - Mandatory Alarm Information 218 <165>1 2003-10-11T22:14:15.003Z mymachine.example.com 219 evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= 220 "Application" eventID="1011"][alarm resource="su root" 221 probableCause="unauthorizedAccessAttempt" 222 perceivedSeverity="major"] 223 BOMAn application event log entry... 225 In this example, extended from [Syslog], the VERSION is 1 and the 226 Facility has the value of 4. The severity is 2. The message was 227 created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the 228 next second. The message originated from a host that identifies 229 itself as "mymachine.example.com". The APP-NAME is "su" and the 230 PROCID is unknown. The MSGID is "ID47". We have included both the 231 structured data from the original example, a single element with the 232 value "[exampleSDID@0 iut="3" eventSource="Application" 233 eventID="1011"]" and a new one with the alarm information defined in 234 this memo. The alarm SD-ID contains the mandatory SD-PARAMS of 235 resource, probableCause and preceivedSeverity. The MSG itself is "An 236 application event log entry..." The BOM at the beginning of MSG 237 indicates UTF-8 encoding. 239 Example 2 - Additional Alarm Information 241 <165>1 2004-11-10T20:15:15.003Z mymachine.example.com 242 evntslog - ID48 [alarm resource="interface 42" 243 probableCause="unauthorizedAccessAttempt" 244 perceivedSeverity="major" 245 eventType="communicationsAlarm" 246 resourceURI ="snmp://example.com//1.3.6.1.2.1.2.2.1.1.42"] 248 In this example, we include two optional alarm fields - eventType and 249 resourceURI. 251 5. Security Considerations 253 In addition to general syslog security considerations discussed in 254 [RFC5424], the information contained with alarms may provide hackers 255 with helpful information about parts of the system currently 256 experiencing stress as well as general information about the system 257 such as inventory. 259 Users should not have access to information in alarms that their 260 normal access permissions would not permit if the information was 261 accessed in another manner. 263 There is no standardized access control model for SYSLOG and hence 264 the ability to filter alarms based on a notion of a receiver identity 265 is at best implementation specific. 267 6. IANA Considerations 269 IANA is requested to register the SD-IDs and PARAM-NAMEs shown below: 271 SD-ID PARAM-NAME 272 alarm OPTIONAL 273 resource MANDATORY 274 probableCause MANDATORY 275 perceivedSeverity MANDATORY 276 eventType OPTIONAL 277 trendIndication OPTIONAL 278 resourceURI OPTIONAL 280 7. Acknowledgments 282 Thanks to members of the Syslog and OPSAWG work group who contributed 283 to this specification. We'd also like to thank Juergen 284 Schoenwaelder, Dave Harrington, Wes Hardaker and Randy Presuhn for 285 their reviews. 287 8. References 289 8.1. Normative References 291 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 292 Resource Locators (URL)", RFC 1738, December 1994. 294 [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements 295 Levels", RFC 2119, March 1997. 297 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 298 Information Base (MIB)", RFC 3877, September 2004. 300 [RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform 301 Resource Identifier (URI) Scheme for the Simple Network 302 Management Protocol (SNMP)", RFC 4088, June 2005. 304 [RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009. 306 8.2. Informative References 308 [X.733] ITU-T, ""Information Technology - Open Systems 309 Interconnection - System Management: Alarm Reporting 310 Function"", ITU-T X.733, 1992. 312 [X.736] ITU-T, ""Information Technology - Open Systems 313 Interconnection - System Management: Security Alarm 314 Reporting Function"", ITU-T X.736, 1992. 316 Authors' Addresses 318 Sharon Chisholm 319 Nortel 320 3500 Carling Ave 321 Nepean, Ontario K2H 8E9 322 Canada 324 Email: schishol@nortel.com 326 Rainer Gerhards 327 Adiscon GmbH 328 Mozartstrasse 21 329 Grossrinderfeld, BW 97950 330 Germany 332 Email: rgerhards@adiscon.com