idnits 2.17.1 draft-ietf-opsawg-syslog-alarm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 305. 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 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 (June 19, 2008) is 5761 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) == Outdated reference: A later version (-23) exists of draft-ietf-syslog-protocol-19 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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: December 21, 2008 Adiscon GmbH 6 June 19, 2008 8 Alarms in SYSLOG 9 draft-ietf-opsawg-syslog-alarm-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes how to send alarm information in syslog. It 43 includes the mapping of ITU perceived severities onto syslog message 44 fields. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2. Severity Mapping . . . . . . . . . . . . . . . . . . . . . 3 51 2. Alarm STRUCTURED-DATA Elements . . . . . . . . . . . . . . . . 4 52 2.1. alarmedResource . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. probableCause . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3. perceivedSeverity . . . . . . . . . . . . . . . . . . . . 4 55 2.4. eventType . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.5. trendIndication . . . . . . . . . . . . . . . . . . . . . 5 57 2.6. resourceMapping . . . . . . . . . . . . . . . . . . . . . 5 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 In addition to sending out alarm information asynchronously via 70 protocols such as SNMP or Netconf, many implementations also log 71 alarms via syslog. This memo defines a set of SD-PARAM to support 72 logging and defines a mapping of syslog severity to the severity of 73 the alarm. 75 1.1. terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC2119 [RFC2119]. 81 Alarm related terminology is defined in [RFC3877]. 83 1.2. Severity Mapping 85 The Alarm MIB RFC3877 [RFC3877] defines ITU perceived severities 86 which are useful to be able to relate to the syslog message fields, 87 particularly in the case where alarms are being logged. This memo 88 describes the representation of ITU perceived severities in 89 appropriate syslog fields described in [Syslog]. Syslog offers both 90 a so-called SEVERITY as well as STRUCTURED-DATA. Due to constraints 91 in syslog, there is no one-to-one mapping possible for SEVERITY. A 92 STRUCTURED-DATA element is defined to allow inclusion of the 93 unmodified ITU perceived severity. 95 Syslog supports severity values different from ITU perceived 96 severities. These are defined in section 6.2.1 of [Syslog]. The 97 mapping shown in table 1 below SHOULD be used to map ITU perceived 98 severities to syslog severities. 100 ITU Perceived Severity syslog SEVERITY (Name) 101 Critical 1 (Alert) 102 Major 2 (Critical) 103 Minor 3 (Error) 104 Warning 4 (Warning) 105 Indeterminate 5 (Notice) 106 Cleared 5 (Notice) 108 Table 1. ITUPerceivedSeverity to syslog SEVERITY mapping. 110 2. Alarm STRUCTURED-DATA Elements 112 STRUCTURED-DATA allows to include any structured information into a 113 syslog message. The following are defined to support structuring 114 alarm information. 116 o Resource Under Alarm 118 o Probable Cause 120 o Event Type 122 o Perceived Severity 124 o Trend Indication 126 o Resource Mapping 128 Support of the alarm SD-ID is optional, but once supported some of 129 the SD-PARARMS are mandatory. 131 2.1. alarmedResource 133 If the alarm SD-ID is supported, the alarmResource SD-PARAM MUST be 134 supported. This item uniquely identifies the resource under alarm 135 within the scope of a network element. 137 2.2. probableCause 139 If the alarm SD-ID is supported, the probableCause SD-PARAM MUST be 140 supported. This parameter is the mnemonic associated with the 141 IANAItuProbableCause object defined within [RFC3877] and any 142 subsequent extensions defined by IANA. For example, 143 IANAItuProbableCause defines a transmission failure to a probable 144 cause of 'transmissionError (10)'. The value of the parameter in 145 this case would be 'transmissionError'" 147 2.3. perceivedSeverity 149 If the alarm SD-ID is supported, the perceivedSeverity SD-PARAM MUST 150 be supported. Similar to the definition of perceived severity in 151 [X.736] and [RFC3877], this object can take the following values: 153 o cleared 155 o indeterminate 156 o critical 158 o major 160 o minor 162 o warning 164 See section X.X for the relationship between this severity and syslog 165 severity. 167 2.4. eventType 169 If the alarm SD-ID is supported, the eventType SD-PARAM SHOULD be 170 supported. This parameter is the mnemonic associated with the 171 IANAItuEventType object defined within [RFC3877] and any subsequent 172 extensions defined by IANA. For example, IANAItuEventType defines a 173 environmental alarm to a event type of 'environmentalAlarm (6)'. The 174 value of the parameter in this case would be 'environmentalAlarm'" 176 2.5. trendIndication 178 If the alarm SD-ID is supported, the trendIndication SD-PARAM SHOULD 179 be supported. Similar to the definition of perceived severity in 180 [X.733] and [RFC3877], this object can take the following values: 182 o moreSevere 184 o noChange 186 o lessSevere 188 2.6. resourceMapping 190 If the alarm SD-ID is supported, the resourceMapping SD-PARAM SHOULD 191 be supported. This item uniquely identifies the resource under alarm 192 within the scope of a network element. This must be the same value 193 as alarmActiveResourceId [RFC3877] for this alarm or follow similar 194 semantics if the Alarm MIB is not supported. 196 3. Security Considerations 198 In addition to general syslog security considerations discussed in 199 [Syslog], the information contained with alarms may provide hackers 200 with helpful information about parts of the system currently 201 experiencing stress as well as general information about the system 202 such as inventory. 204 Users should not have access to information in alarms that their 205 normal access permissions would not permit if the information was 206 accessed in another manner. 208 4. IANA Considerations 210 IANA is requested to register the SD-IDs and PARAM-NAMEs shown below: 212 SD-ID PARAM-NAME 213 alarm OPTIONAL 214 alarmedResource MANDATORY 215 probableCause MANDATORY 216 perceivedSeverity MANDATORY 217 eventType OPTIONAL 218 trendIndication OPTIONAL 219 resourceMapping OPTIONAL 221 5. Acknowledgments 223 Thanks to members of the Syslog work group who contributed to this 224 specification. 226 6. References 228 6.1. Normative References 230 [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements 231 Levels", RFC 2119, March 1997. 233 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 234 Information Base (MIB)", RFC 3877, September 2004. 236 [Syslog] Gerhards, Rainer., "The syslog Protocol", 237 ID draft-ietf-syslog-protocol-19.txt, November 2006. 239 6.2. Informative References 241 [X.733] ITU-T, ""Information Technology - Open Systems 242 Interconnection - System Management: Alarm Reporting 243 Function"", ITU-T X.733, 1992. 245 [X.736] ITU-T, ""Information Technology - Open Systems 246 Interconnection - System Management: Security Alarm 247 Reporting Function"", ITU-T X.736, 1992. 249 Authors' Addresses 251 Sharon Chisholm 252 Nortel 253 3500 Carling Ave 254 Nepean, Ontario K2H 8E9 255 Canada 257 Email: schishol@nortel.com 259 Rainer Gerhards 260 Adiscon GmbH 261 Mozartstrasse 21 262 Grossrinderfeld, BW 97950 263 Germany 265 Email: rgerhards@adiscon.com 267 Full Copyright Statement 269 Copyright (C) The IETF Trust (2008). 271 This document is subject to the rights, licenses and restrictions 272 contained in BCP 78, and except as set forth therein, the authors 273 retain all their rights. 275 This document and the information contained herein are provided on an 276 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 277 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 278 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 279 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 280 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 281 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 Intellectual Property 285 The IETF takes no position regarding the validity or scope of any 286 Intellectual Property Rights or other rights that might be claimed to 287 pertain to the implementation or use of the technology described in 288 this document or the extent to which any license under such rights 289 might or might not be available; nor does it represent that it has 290 made any independent effort to identify any such rights. Information 291 on the procedures with respect to rights in RFC documents can be 292 found in BCP 78 and BCP 79. 294 Copies of IPR disclosures made to the IETF Secretariat and any 295 assurances of licenses to be made available, or the result of an 296 attempt made to obtain a general license or permission for the use of 297 such proprietary rights by implementers or users of this 298 specification can be obtained from the IETF on-line IPR repository at 299 http://www.ietf.org/ipr. 301 The IETF invites any interested party to bring to its attention any 302 copyrights, patents or patent applications, or other proprietary 303 rights that may cover technology that may be required to implement 304 this standard. Please address the information to the IETF at 305 ietf-ipr@ietf.org. 307 Acknowledgment 309 Funding for the RFC Editor function is provided by the IETF 310 Administrative Support Activity (IASA).