idnits 2.17.1 draft-lear-ietf-syslog-uri-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 366. 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 2, 2007) is 6201 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 == Outdated reference: A later version (-14) exists of draft-ietf-syslog-transport-tls-07 == Outdated reference: A later version (-12) exists of draft-ietf-syslog-transport-udp-09 == Outdated reference: A later version (-01) exists of draft-lear-ietf-syslog-rfc3195bis-00 ** Obsolete normative reference: RFC 4395 (ref. '6') (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 4234 (ref. '7') (Obsoleted by RFC 5234) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Standards Track May 2, 2007 5 Expires: November 3, 2007 7 syslog URIs 8 draft-lear-ietf-syslog-uri-00.txt 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 Internet-Draft will expire on November 3, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 syslog specifies both a logging format and a set of protocols to 42 communicate that format over. This memo specifies a set of URIs that 43 administrators and configuration systems may use to inform syslog 44 senders of their collectors or relays and protocols. 46 1. Introduction 48 The syslog protocol [1] has been used as a logging mechanism for 49 close to three decades, in one form or another. Its reach has 50 extended from UNIX mail systems to printers to routers to many 51 different devices. In many cases the logging configuration is as 52 simple as an IP address. This configuration may be in a file, 53 specified by an administrator on a device console, or perhaps 54 retrieved by a device through a configuration protocol, such as DHCP 55 [8]. 57 With the formal specification of the syslog transport protocols for 58 UDP [3], TLS [2], and BEEP [4], a simple means is needed to provide a 59 concise way to tell systems which host and which protocol to use as 60 either a collector or relay. Universal Resource Identifiers (URIs) 61 [5] provide a flexible and concise means to accomplish this task. 63 This memo specifies three such URIs. They are "syslog.udp", 64 "syslog.tls", and "syslog.beep;". A description of each URI scheme 65 follows in the next section. It is recommended that future syslog 66 transports include an appropriate URI scheme that begins with 67 "syslog.". 69 syslog terminology used in this draft is taken from [1]. 71 2. syslog URI Scheme Registrations and Description 73 Each section below consists of a completed template from RFC 4395 74 [6]. 76 2.1. syslog.udp Schema Registration 77 URI scheme name 79 syslog.udp 81 Status 83 Permanent 85 Syntax 87 The following syntax makes use of Augmented BNF (ABNF) [7] and the 88 definitions found in RFC 3986. 90 syslog-udp-uri = "syslog.udp:" host [ ":" port ] 92 URI semantics 94 This URI is used to specify a syslog collector or relay running 95 over a specific UDP port. syslog senders will make a connection to 96 the host and transmit any appropriate logging as prescribed by the 97 sender's configuration. 99 Encoding Considerations 101 As only a host and a port number are provided, encoding of these 102 portions of the URI are specified in [5]. 104 Applications/protocols that use this URI scheme name 106 syslog senders will primarily make use of this URI to configure 107 themselves. The syslog protocol is specified in [1]. UDP 108 transport of syslog is specified in [3]. 110 Interoperability considerations 112 None 114 Security Considerations 116 [3] discusses the underlying concerns of syslog over udp. 117 Additionally, as URIs tend to be portable, some additional concern 118 should be given to protecting the host in a syslog.udp URI from 119 unauthorized access. 121 Contact 123 The author section of this document. 125 Author/Change Control 127 The author of this scheme is the same as in the author section of 128 this document. Change control is vested with the IESG. 130 References 132 Please see the References section of this document. 134 2.2. syslog.tls Schema Registration 135 URI scheme name 137 syslog.tls 139 Status 141 Permanent 143 Syntax 145 The following syntax makes use of ABNF and the definitions found 146 in RFC 3986. 148 syslog-tls-uri = "syslog.tls:" host [ ":" port ] 150 URI semantics 152 This URI is used to specify a syslog collector or relay running 153 over TLS. syslog senders will make a connection to the host, 154 initiate TLS, and transmit any appropriate logging as prescribed 155 by the sender's configuration over the encrypted channel. 157 Encoding Considerations 159 As only a host and a port number are provided, encoding of these 160 portions of the URI are specified in [5]. 162 Applications/protocols that use this URI scheme name 164 syslog senders will primarily make use of this URI to configure 165 themselves. The syslog protocol is specified in [1]. TLS 166 transport of syslog is specified in [2]. 168 Interoperability considerations 170 None 172 Security Considerations 174 [2] discusses issues and concerns of using syslog over TLS. 175 Additionally, as URIs tend to be portable, some additional concern 176 should be given to protecting the host in a syslog.tls URI from 177 unauthorized access. 179 Contact 181 The author section of this document. 183 Author/Change Control 185 The author of this scheme is the same as in the author section of 186 this document. Change control is vested with the IESG. 188 References 190 Please see the References section of this document. 192 2.3. syslog.beep Schema Registration 193 URI scheme name 195 syslog.beep 197 Status 199 Permanent 201 Syntax 203 The following syntax makes use of ABNF and the definitions found 204 in RFC 3986. 206 syslog-beep-uri = "syslog.beep:" host [ ":" port ] 208 URI semantics 210 This URI is used to specify a syslog collector or relay running 211 over BEEP. syslog senders will make a TCP connection to the host, 212 utilize an appropriate BEEP profile for syslog, and transmit any 213 appropriate logging as prescribed by the sender's configuration 214 over the BEEP channel. 216 Encoding Considerations 218 As only a host and a port number are provided, encoding of these 219 portions of the URI are specified in [5]. 221 Applications/protocols that use this URI scheme name 223 syslog senders will primarily make use of this URI to configure 224 themselves. The syslog protocol is specified in [4]. BEEP 225 transport of syslog is specified in [4]. 227 Interoperability considerations 229 None 231 Security Considerations 233 [4] discusses issues and concerns of using syslog over BEEP. 234 Additionally, as URIs tend to be portable, some additional concern 235 should be given to protecting the host in a syslog.beep URI from 236 unauthorized access. 238 Contact 240 The author section of this document. 242 Author/Change Control 244 The author of this scheme is the same as in the author section of 245 this document. Change control is vested with the IESG. 247 References 249 Please see the References section of this document. 251 3. Operational Considerations 253 Use of a URI to configure the syslog service requires some thought 254 about potential circular dependencies. For instance, if a domain 255 name is used to configure the service, the URI cannot be resolved if 256 name service is unavailable. Implementers are reminded to obey the 257 rules set forth in Section 3.2.2 of [5]. Administrators must balance 258 the requirements of flexible management against the need for logging 259 resiliency, when making use of these URIs. In some cases devices may 260 be able to store messages locally until they are able to resolve the 261 address of a collector or relay. In other cases, logging information 262 may be time critical. 264 4. Security Considerations 266 Please see the above sections as well as the underlying protocol 267 documents for security considerations. Use of this URI to configure 268 devices should be considered in the same light as other potentially 269 sensitive configuration information. The underlying content being 270 logged may or may not warrant additional protections, depending on 271 environment and circumstances. 273 5. IANA Considerations 275 The IANA is requested to register the profiles in Section 2. 277 6. References 279 6.1. Normative References 281 [1] Gerhards, R., "The syslog Protocol", 282 draft-ietf-syslog-protocol-19 (work in progress), November 2006. 284 [2] Miao, F. and M. Yuzhi, "TLS Transport Mapping for Syslog", 285 draft-ietf-syslog-transport-tls-07 (work in progress), 286 April 2007. 288 [3] Okmianski, A., "Transmission of syslog messages over UDP", 289 draft-ietf-syslog-transport-udp-09 (work in progress), 290 March 2007. 292 [4] Lear, E., "Reliable Delivery for syslog", 293 draft-lear-ietf-syslog-rfc3195bis-00 (work in progress), 294 February 2007. 296 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 297 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 298 January 2005. 300 [6] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 301 Registration Procedures for New URI Schemes", BCP 115, RFC 4395, 302 February 2006. 304 [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 305 Specifications: ABNF", RFC 4234, October 2005. 307 6.2. Informational References 309 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 310 March 1997. 312 Appendix A. Changes 314 This seciton to be removed prior to publication. 315 o 00 Initial Revision. 317 Author's Address 319 Eliot Lear 320 Cisco Systems GmbH 321 Glatt-com 322 Glattzentrum, ZH CH-8301 323 Switzerland 325 Phone: +41 1 878 7525 326 Email: lear@cisco.com 328 Full Copyright Statement 330 Copyright (C) The IETF Trust (2007). 332 This document is subject to the rights, licenses and restrictions 333 contained in BCP 78, and except as set forth therein, the authors 334 retain all their rights. 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 339 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 340 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 341 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Intellectual Property 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the use of 358 such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org. 368 Acknowledgments 370 Funding for the RFC Editor function is provided by the IETF 371 Administrative Support Activity (IASA). This document was produced 372 using xml2rfc v1.32 (of http://xml.resource.org/) from a source in 373 RFC-2629 XML format.