idnits 2.17.1 draft-ietf-syslog-tc-mib-08.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. 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 (May 23, 2008) is 5810 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: 'RFCPROT' is mentioned on line 467, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Syslog Working Group Glenn Mansfield Keeni 3 INTERNET-DRAFT Cyber Solutions Inc. 4 Intended Status: Proposed Standard 5 Expires: November 22, 2008 May 23, 2008 7 Textual Conventions for Syslog Management 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of the syslog Working Group. Comments 34 should be addressed to the authors or the mailing list at 35 syslog@ietf.org 37 This Internet-Draft will expire on November 22, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This MIB module defines textual conventions to represent 46 Facility and Severity information commonly used in syslog messages. 47 The intent is that these textual conventions will be imported and 48 used in MIB modules that would otherwise define their own 49 representations. 51 Table of Contents 53 1. The Internet-Standard Management Framework .... 3 54 2. Background .................................... 3 55 3. The Syslog Textual Conventions MIB ............ 4 56 4. Security Considerations ....................... 8 57 5. IANA Considerations ........................... 8 58 6. References .................................... 9 59 7 Acknowledgments ............................... 10 60 8. Author's Addresses ............................ 10 61 9. Full Copyright Statement ...................... 11 62 Appendix ...................................... 13 64 1. The Internet-Standard Management Framework 66 For a detailed overview of the documents that describe the current 67 Internet-Standard Management Framework, please refer to section 7 of 68 RFC 3410 [RFC3410]. 70 Managed objects are accessed via a virtual information store, termed 71 the Management Information Base or MIB. MIB objects are generally 72 accessed through the Simple Network Management Protocol (SNMP). 74 Objects in the MIB are defined using the mechanisms defined in the 75 Structure of Management Information (SMI). This memo specifies a MIB 76 module that is compliant to the SMIv2, which is described in STD 58, 77 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 78 [RFC2580]. 80 2. Background 82 Operating systems, processes and applications, collectively termed 83 "Facilities" in the following, generate messages indicating their own 84 status or the occurrence of events. These messages have come to be 85 known as syslog messages. A syslog message in general will contain 86 among other things a code representing the Facility that generated 87 the message and a code representing the Severity of the message. The 88 Facility and the Severity codes are commonly used to categorize and 89 select received syslog messages for processing and display. The 90 Facility codes have been useful in qualifying the originator of the 91 content of the messages but in some cases they are not specific 92 enough to explicitly identify the originator. Implementations of the 93 syslog protocol [RFCZZZZ] that contain Structured Data Elements 94 (SDEs) should use these SDEs to clarify the entity that originated 95 the content of the message. 97 This document defines a set of textual conventions (TCs) that can be 98 used to represent Facility and Severity codes commonly used in syslog 99 messages. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. The Syslog Textual Conventions MIB 107 SYSLOG-TC-MIB DEFINITIONS ::= BEGIN 109 IMPORTS 110 MODULE-IDENTITY, mib-2 111 FROM SNMPv2-SMI -- [RFC2578] 112 TEXTUAL-CONVENTION 113 FROM SNMPv2-TC; -- [RFC2579] 115 syslogTCMIB MODULE-IDENTITY 116 LAST-UPDATED "200805230000Z" -- 23rd May, 2008 117 ORGANIZATION "IETF Syslog Working Group" 118 CONTACT-INFO 119 " Glenn Mansfield Keeni 120 Postal: Cyber Solutions Inc. 121 6-6-3, Minami Yoshinari 122 Aoba-ku, Sendai, Japan 989-3204. 123 Tel: +81-22-303-4012 124 Fax: +81-22-303-4015 125 E-mail: glenn@cysols.com 127 Support Group E-mail: syslog@ietf.org 128 " 130 DESCRIPTION 131 "The MIB module containing textual conventions for syslog 132 messages. 134 Copyright (C) The IETF Trust (2008). This version of 135 this MIB module is part of RFC XXXX; see the RFC itself for 136 full legal notices. 137 " 138 -- RFC Ed.: replace XXXX with the actual RFC number & remove this 139 -- note 140 REVISION "200805230000Z" -- 23rd May, 2008 141 DESCRIPTION 142 "The initial version, published as RFC XXXX." 144 -- RFC Ed.: replace XXXX with the actual RFC number & remove this 145 -- note 147 ::= { mib-2 YYYY } -- Will be assigned by IANA 149 -- IANA Reg.: Please assign a value for "YYYY" under the 150 -- 'mib-2' subtree and record the assignment in the SMI 151 -- Numbers registry. 153 -- RFC Ed.: When the above assignment has been made, please 154 -- remove the above note 155 -- replace "YYYY" here with the assigned value and 156 -- remove this note. 158 -- ------------------------------------------------------------- 159 -- Textual Conventions 160 -- ------------------------------------------------------------- 161 SyslogFacility ::= TEXTUAL-CONVENTION 162 STATUS current 163 DESCRIPTION 164 "This textual convention enumerates the Facilities that 165 originate syslog messages. 167 The Facilities of syslog messages are numerically coded 168 with decimal values. For interoperability and backwards 169 compatibility reasons, this document specifies a 170 normative mapping between a label which represents a 171 Facility and the corresponding numeric value. This label 172 could be used in, for example, SNMP Manager user 173 interfaces. 175 The label itself is often semantically meaningless, 176 because it is impractical to attempt to enumerate all 177 possible Facilities, and many daemons and processes do 178 not have an explicitly assigned Facility code or label. 179 For example, there is no Facility label corresponding to 180 a HTTP service. A HTTP service implementation might log 181 messages as coming from, for example, 'local7' or 'uucp'. 182 This is typical current practice, and originators, relays 183 and collectors can be configured to properly handle this 184 situation. For improved accuracy, an application can also 185 include an APPNAME Structured Data Element. 187 Note that operating system mechanisms for configuring 188 syslog, such as syslog.conf, have not yet been standardized 189 and might use different set of Facility labels and/or 190 mapping between Facility labels and Facility codes than the 191 MIB. 193 In particular, the labels corresponding to Facility codes 4, 194 10, 13, and 14, and the code corresponding to the Facility 195 label 'cron' are known to vary across different operating 196 systems. This list is not intended to be exhaustive; other 197 differences might exist, and new differences might be 198 introduced in the future. 199 The mapping specified here MUST be used in SNMP contexts, 200 even though a particular syslog implementation would use 201 a different mapping. 202 " 203 REFERENCE "The syslog Protocol (RFCZZZZ): Table 1" 204 SYNTAX INTEGER 205 { 206 kern (0), -- kernel messages 207 user (1), -- user-level messages 208 mail (2), -- mail system messages 209 daemon (3), -- system daemons' messages 210 auth (4), -- authorization messages 211 syslog (5), -- messages generated internally by 212 -- syslogd 213 lpr (6), -- line printer subsystem messages 214 news (7), -- network news subsystem messages 215 uucp (8), -- UUCP subsystem messages 216 cron (9), -- clock daemon messages 217 authpriv (10),-- security/authorization messages 218 ftp (11),-- ftp daemon messages 219 ntp (12),-- NTP subsystem messages 220 audit (13),-- audit messages 221 console (14),-- console messages 222 cron2 (15),-- clock daemon messages 223 local0 (16), 224 local1 (17), 225 local2 (18), 226 local3 (19), 227 local4 (20), 228 local5 (21), 229 local6 (22), 230 local7 (23) 231 } 233 SyslogSeverity ::= TEXTUAL-CONVENTION 234 STATUS current 235 DESCRIPTION 236 "This textual convention enumerates the Severity levels 237 of syslog messages. 239 The Severity levels of syslog messages are numerically 240 coded with decimal values. For interoperability and 241 backwards compatibility reasons, this document specifies 242 a normative mapping between a label which represents a 243 Severity level and the corresponding numeric value. 244 This label could be used in, for example, SNMP Manager 245 user interfaces. 247 The label itself is often semantically meaningless, 248 because it is impractical to attempt to strictly define 249 the criteria for each Severity level, and the criteria 250 that is used by syslog originators is, and has 251 historically been, implementation-dependent. 253 Note that operating system mechanisms for configuring 254 syslog, such as syslog.conf, have not yet been standardized 255 and might use different set of Severity labels and/or 256 mapping between Severity labels and Severity codes than the 257 MIB. 259 For example, the foobar application might log messages as 260 'crit' based on some subjective criteria. Yet the operator 261 can configure syslog to forward these messages, even though 262 the criteria for 'crit' may differ from one originator to 263 another. This is typical current practice, and originators, 264 relays and collectors can be configured to properly handle 265 this situation. 266 " 267 REFERENCE "The syslog Protocol (RFCZZZZ): Table 2" 268 SYNTAX INTEGER 269 { 270 emerg (0), -- emergency; system is unusable 271 alert (1), -- action must be taken immediately 272 crit (2), -- critical condition 273 err (3), -- error condition 274 warning (4), -- warning condition 275 notice (5), -- normal but significant condition 276 info (6), -- informational message 277 debug (7) -- debug-level messages 279 } 281 END 283 4. Security Considerations 285 This module does not define any management objects. Instead, it 286 defines a set of textual conventions which may be used by other MIB 287 modules to define management objects. Meaningful security 288 considerations can only be written in the MIB modules that define 289 management objects. This document has therefore no impact on the 290 security of the Internet. Since objects defined using the TCs 291 defined in this document may introduce security issues, the user of 292 these TCs should read the security considerations section of 293 [RFCZZZZ]. 295 5. IANA Considerations 297 The MIB modules in this document use the following IANA-assigned 298 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 300 Descriptor OBJECT IDENTIFIER value 301 ---------- ----------------------- 303 syslogTCMIB { mib-2 YYYY } 305 IANA Reg.: Please assign a value under the 'mib-2' subtree 306 for the 'syslogTCMIB' MODULE-IDENTITY and record 307 the assignment in the SMI Numbers registry. 309 RFC Ed.: When the above assignments have been made, please 310 - remove the above note 311 - replace "YYYY" here with the assigned values and 312 - remove this note. 314 6. References 316 6.1 Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997 321 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 322 Rose, M., and S. Waldbusser, "Structure of Management 323 Information Version 2 (SMIv2)", STD 58, RFC 2578, 324 April 1999 326 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 327 Rose, M., and S. Waldbusser, "Textual Conventions for 328 SMIv2", STD 58, RFC 2579, April 1999 330 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 331 Rose, M., and S. Waldbusser, "Conformance Statements for 332 SMIv2", STD 58, RFC 2580, April 1999 334 [RFCZZZZ] Gerhards, R., "The syslog Protocol", 335 draft-ietf-syslog-protocol-23.txt, work in progress, 336 September 2007. 338 6.2 Informative References 340 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 341 "Introduction and Applicability Statements for the 342 Internet-Standard Management Framework", RFC 3410, 343 December 2002. 345 Note: The string "ZZZZ" in this 346 document will be replaced by the RFC number assigned 347 to the latest version of 348 draft-ietf-syslog-protocol-*.txt 349 and this note will be removed. 351 7. Acknowledgments 352 This document is a product of the Syslog Working Group. 354 8. Author's Addresses 356 Glenn Mansfield Keeni 357 Cyber Solutions Inc. 358 6-6-3 Minami Yoshinari 359 Aoba-ku, Sendai 989-3204 360 Japan 362 Phone: +81-22-303-4012 363 EMail: glenn@cysols.com 365 9. Full Copyright Statement 367 Copyright (C) The IETF Trust (2008). 369 This document is subject to the rights, licenses and restrictions 370 contained in BCP 78, and except as set forth therein, the authors 371 retain all their rights. 373 This document and the information contained herein are provided on 374 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 375 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 376 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 377 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 378 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 379 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 380 PARTICULAR PURPOSE. 382 Intellectual Property 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed 386 to pertain to the implementation or use of the technology 387 described in this document or the extent to which any license 388 under such rights might or might not be available; nor does it 389 represent that it has made any independent effort to identify any 390 such rights. Information on the procedures with respect to 391 rights in RFC documents can be found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use 396 of such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository 398 at http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention 401 any copyrights, patents or patent applications, or other 402 proprietary rights that may cover technology that may be required 403 to implement this standard. Please address the information to the 404 IETF at ietf-ipr@ietf.org. 406 Acknowledgment 408 Funding for the RFC Editor function is provided by the IETF 409 Administrative Support Activity (IASA). 411 APPENDIX 413 This section documents the development of the draft. It will be 414 deleted when the draft becomes an RFC. 416 Revision History: 417 Changes from draft-ietf-syslog-tc-mib-07.txt 418 to draft-ietf-syslog-tc-mib-08.txt 419 1. Polished the DESCRIPTION clauses of the textual 420 conventions. 421 2. Fixed authPriv -> authpriv 423 Changes from draft-ietf-syslog-tc-mib-06.txt 424 to draft-ietf-syslog-tc-mib-07.txt 425 1. Aligned the Facility and Severity labels with 426 POSIX labels. 427 2. Added comment to DESCRIPTION of Facility 428 textual convention cautioning the user that the 429 the label of a Facility in this textual 430 convention may not match the corresponding label 431 used by some operating system. 432 3. Editorial nits. 434 Changes from draft-ietf-syslog-tc-mib-02.txt 435 to draft-ietf-syslog-tc-mib-03.txt 436 1. Moved comments on the Facility and 437 Severity TCs to the DESCRIPTION clauses 438 2. Added text to Severity clause 439 3. Added REFERENCE clauses 440 4. Added text to the Security Considerations 441 section 443 Changes from draft-ietf-syslog-tc-mib-01.txt 444 to draft-ietf-syslog-tc-mib-02.txt 445 1. WG stance: The Facility codes are normative. 446 - added explanation in the Background part. 447 - removed comment in the MIB which said that the 448 Facility code is not normative. 449 2. Added reference RFCPROT. 451 Changes from draft-ietf-syslog-tc-mib-00.txt 452 to draft-ietf-syslog-tc-mib-01.txt 454 1. Revised the Background section. Added 455 The Facility and the Severity codes are commonly used to 456 categorize and select received syslog messages for processing and 457 display. 459 2. Revised the comments in the MIB. Added 460 -- Facility and Severity values are not normative but often used. 461 -- Some of the operating system daemons and processes are 462 -- traditionally designated by the Facility values given below. 464 3. Revised the DESCRIPTION and SYNTAX of SyslogFacility 465 Removed the "NoMap 99" enumeration. 467 4. Removed the reference to Syslog Protocol [RFCPROT].