Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Intended status: Standards Track May 2, 2007
Expires: November 3, 2007
syslog URIs
draft-lear-ietf-syslog-uri-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
syslog specifies both a logging format and a set of protocols to
communicate that format over. This memo specifies a set of URIs that
administrators and configuration systems may use to inform syslog
senders of their collectors or relays and protocols.
Lear Expires November 3, 2007 [Page 1]
Internet-Draft URIs for syslog May 2007
1. Introduction
The syslog protocol [1] has been used as a logging mechanism for
close to three decades, in one form or another. Its reach has
extended from UNIX mail systems to printers to routers to many
different devices. In many cases the logging configuration is as
simple as an IP address. This configuration may be in a file,
specified by an administrator on a device console, or perhaps
retrieved by a device through a configuration protocol, such as DHCP
[8].
With the formal specification of the syslog transport protocols for
UDP [3], TLS [2], and BEEP [4], a simple means is needed to provide a
concise way to tell systems which host and which protocol to use as
either a collector or relay. Universal Resource Identifiers (URIs)
[5] provide a flexible and concise means to accomplish this task.
This memo specifies three such URIs. They are "syslog.udp",
"syslog.tls", and "syslog.beep;". A description of each URI scheme
follows in the next section. It is recommended that future syslog
transports include an appropriate URI scheme that begins with
"syslog.".
syslog terminology used in this draft is taken from [1].
2. syslog URI Scheme Registrations and Description
Each section below consists of a completed template from RFC 4395
[6].
2.1. syslog.udp Schema Registration
URI scheme name
syslog.udp
Status
Permanent
Syntax
The following syntax makes use of Augmented BNF (ABNF) [7] and the
definitions found in RFC 3986.
syslog-udp-uri = "syslog.udp:" host [ ":" port ]
Lear Expires November 3, 2007 [Page 2]
Internet-Draft URIs for syslog May 2007
URI semantics
This URI is used to specify a syslog collector or relay running
over a specific UDP port. syslog senders will make a connection to
the host and transmit any appropriate logging as prescribed by the
sender's configuration.
Encoding Considerations
As only a host and a port number are provided, encoding of these
portions of the URI are specified in [5].
Applications/protocols that use this URI scheme name
syslog senders will primarily make use of this URI to configure
themselves. The syslog protocol is specified in [1]. UDP
transport of syslog is specified in [3].
Interoperability considerations
None
Security Considerations
[3] discusses the underlying concerns of syslog over udp.
Additionally, as URIs tend to be portable, some additional concern
should be given to protecting the host in a syslog.udp URI from
unauthorized access.
Contact
The author section of this document.
Author/Change Control
The author of this scheme is the same as in the author section of
this document. Change control is vested with the IESG.
References
Please see the References section of this document.
2.2. syslog.tls Schema Registration
Lear Expires November 3, 2007 [Page 3]
Internet-Draft URIs for syslog May 2007
URI scheme name
syslog.tls
Status
Permanent
Syntax
The following syntax makes use of ABNF and the definitions found
in RFC 3986.
syslog-tls-uri = "syslog.tls:" host [ ":" port ]
URI semantics
This URI is used to specify a syslog collector or relay running
over TLS. syslog senders will make a connection to the host,
initiate TLS, and transmit any appropriate logging as prescribed
by the sender's configuration over the encrypted channel.
Encoding Considerations
As only a host and a port number are provided, encoding of these
portions of the URI are specified in [5].
Applications/protocols that use this URI scheme name
syslog senders will primarily make use of this URI to configure
themselves. The syslog protocol is specified in [1]. TLS
transport of syslog is specified in [2].
Interoperability considerations
None
Security Considerations
[2] discusses issues and concerns of using syslog over TLS.
Additionally, as URIs tend to be portable, some additional concern
should be given to protecting the host in a syslog.tls URI from
unauthorized access.
Lear Expires November 3, 2007 [Page 4]
Internet-Draft URIs for syslog May 2007
Contact
The author section of this document.
Author/Change Control
The author of this scheme is the same as in the author section of
this document. Change control is vested with the IESG.
References
Please see the References section of this document.
2.3. syslog.beep Schema Registration
URI scheme name
syslog.beep
Status
Permanent
Syntax
The following syntax makes use of ABNF and the definitions found
in RFC 3986.
syslog-beep-uri = "syslog.beep:" host [ ":" port ]
URI semantics
This URI is used to specify a syslog collector or relay running
over BEEP. syslog senders will make a TCP connection to the host,
utilize an appropriate BEEP profile for syslog, and transmit any
appropriate logging as prescribed by the sender's configuration
over the BEEP channel.
Encoding Considerations
As only a host and a port number are provided, encoding of these
portions of the URI are specified in [5].
Lear Expires November 3, 2007 [Page 5]
Internet-Draft URIs for syslog May 2007
Applications/protocols that use this URI scheme name
syslog senders will primarily make use of this URI to configure
themselves. The syslog protocol is specified in [4]. BEEP
transport of syslog is specified in [4].
Interoperability considerations
None
Security Considerations
[4] discusses issues and concerns of using syslog over BEEP.
Additionally, as URIs tend to be portable, some additional concern
should be given to protecting the host in a syslog.beep URI from
unauthorized access.
Contact
The author section of this document.
Author/Change Control
The author of this scheme is the same as in the author section of
this document. Change control is vested with the IESG.
References
Please see the References section of this document.
3. Operational Considerations
Use of a URI to configure the syslog service requires some thought
about potential circular dependencies. For instance, if a domain
name is used to configure the service, the URI cannot be resolved if
name service is unavailable. Implementers are reminded to obey the
rules set forth in Section 3.2.2 of [5]. Administrators must balance
the requirements of flexible management against the need for logging
resiliency, when making use of these URIs. In some cases devices may
be able to store messages locally until they are able to resolve the
address of a collector or relay. In other cases, logging information
may be time critical.
Lear Expires November 3, 2007 [Page 6]
Internet-Draft URIs for syslog May 2007
4. Security Considerations
Please see the above sections as well as the underlying protocol
documents for security considerations. Use of this URI to configure
devices should be considered in the same light as other potentially
sensitive configuration information. The underlying content being
logged may or may not warrant additional protections, depending on
environment and circumstances.
5. IANA Considerations
The IANA is requested to register the profiles in Section 2.
6. References
6.1. Normative References
[1] Gerhards, R., "The syslog Protocol",
draft-ietf-syslog-protocol-19 (work in progress), November 2006.
[2] Miao, F. and M. Yuzhi, "TLS Transport Mapping for Syslog",
draft-ietf-syslog-transport-tls-07 (work in progress),
April 2007.
[3] Okmianski, A., "Transmission of syslog messages over UDP",
draft-ietf-syslog-transport-udp-09 (work in progress),
March 2007.
[4] Lear, E., "Reliable Delivery for syslog",
draft-lear-ietf-syslog-rfc3195bis-00 (work in progress),
February 2007.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[6] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, RFC 4395,
February 2006.
[7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Lear Expires November 3, 2007 [Page 7]
Internet-Draft URIs for syslog May 2007
6.2. Informational References
[8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
Appendix A. Changes
This seciton to be removed prior to publication.
o 00 Initial Revision.
Author's Address
Eliot Lear
Cisco Systems GmbH
Glatt-com
Glattzentrum, ZH CH-8301
Switzerland
Phone: +41 1 878 7525
Email: lear@cisco.com
Lear Expires November 3, 2007 [Page 8]
Internet-Draft URIs for syslog May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). This document was produced
using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
RFC-2629 XML format.
Lear Expires November 3, 2007 [Page 9]