From syslog-bounces@lists.ietf.org Mon Aug 13 11:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbnn-0000Iu-Ti; Mon, 13 Aug 2007 11:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbnn-0000Il-4G for syslog@ietf.org; Mon, 13 Aug 2007 11:25:55 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbnl-0008KA-DH for syslog@ietf.org; Mon, 13 Aug 2007 11:25:55 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A2E7627C096; Mon, 13 Aug 2007 17:21:44 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15033-06; Mon, 13 Aug 2007 17:21:44 +0200 (CEST) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by hetzner.adiscon.com (Postfix) with ESMTP id 3B66B27C091; Mon, 13 Aug 2007 17:21:44 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Aug 2007 17:25:34 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2787A1@grfint2.intern.adiscon.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B731220355860A@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd) thread-index: AcfDxgzwvtFqQLUGRfyER+OWFxIfIAA4aiqABkVqnrA= References: <98AE08B66FAD1742BED6CB9522B731220355860A@xmb-rtp-20d.amer.cisco.com> From: "Rainer Gerhards" To: "Anton Okmyanskiy (aokmians)" , "Chris Lonvick (clonvick)" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi folks, I am sorry for the long silence. I was extremely busy with projects and have to admit will be more or less unavailable for the next 3 weeks. Beginning of September things will finally clear up and I hope to be able to publish a new, hopefully final, version of -protocol. Even though I was not directly active in regard to -protocol, I thought about this requirement here. I have a somewhat weak text to propose: --- In any implementation, a situation can arise in which an originator or relay would need to block sending messages. A common case is when an internal queue is full. This might happen due to rate-limiting or slow performance of the syslog application. In such cases, it is RECOMMENDED that the originator or relay drops messages of lower severity in favor of higher severity messages. Messages with a numerically lower SEVERITY value have a higher severity than those with a numerically higher one. To-be-dropped messages SHOULD simply be discarded. The syslog application may notify a collector or relay about the fact that it drops messages. If the underlying protocol supports congestion control, discarding of messages SHOULD be avoided. --- I have blogged about why I think this is the right thing to do, you may view the details of my thoughts here (sorry, I'd like not to duplicate text as I am already very short on time): http://rgerhards.blogspot.com/2007/08/on-reliability-and-need-to-discard _13.html I would appreciate comments and, even better, improvements to the proposed text. I may not be able to reply immediately, but I will definitely appreciate any comment and incorporate it. Sorry once again for the long silence. Rainer > -----Original Message----- > From: Anton Okmyanskiy (aokmians) [mailto:aokmians@cisco.com] > Sent: Thursday, July 12, 2007 7:32 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - > congenstioncontrol (fwd) >=20 > Chris: >=20 > Can we ask Mangus to provide suggested text? He mentioned it is just a > paragraph. This would make it a bit easier to get to the point of > what/how he wants addressed and evaluate if we agree with it. If his > suggested text is not too demanding on implementations, but rather a > recommendation, it is easier to accept it. >=20 > Is he now concerned with syslog reliability (dropping of arbitrary > messages due to congestion and queue overfill) instead of previously > raised concern of syslog being a bad citizen and causing congestion for > others? >=20 > For end-to-end reliability, we have a whole section describing many > aspects we did not intend to address in UDP draft. >=20 > Why is there an assumption of blocking application? Maybe my syslog > application writes messages to file first, returns to client app and > then asynchronously transmits them while listening for ICMP errors. I > also don't think we intended to cover any end-to-end guarantees from > application perspective. Even reliable network transport (TCP) does > not > means reliable application-to-application delivery. We had the > app-level-ack discussion and dismissed it. >=20 > So, yes, messages are not guaranteed to be delivered to their final > destination and processed there. They can be dropped, they can get > corrupted, receiver may crash right after getting message but before > processing it, relay may fail, etc. >=20 > Thanks, > Anton. >=20 > > -----Original Message----- > > From: Chris Lonvick (clonvick) > > Sent: Wednesday, July 11, 2007 7:16 AM > > To: syslog@ietf.org > > Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - > > congenstion control (fwd) > > > > Hi Folks, > > > > Here is clarification of what Magnus wants. We have so far > > received Eliot's proposal but I don't think that addresses > > the concern. > > > > I would like to hear from everyone. Do we want to push back > > on Magnus, or can someone propose some text around this? > > > > Thanks, > > Chris > > > > > > ---------- Forwarded message ---------- > > Date: Fri, 06 Jul 2007 18:08:12 +0200 > > From: Magnus Westerlund > > To: David Harrington > > Cc: Chris Lonvick , Lars Eggert > > > > Subject: Re: DISCUSS in draft-ietf-syslog-protocol - > > congenstion control (fwd) > > > > Hi David, > > > > I think you are missunderstanding things here. But thanks for > > protesting and not accepting crap. But let me make clear > > what I actually think is needed in regards to syslog to make > > it a working protocol to deploy. > > > > First, this starts as an issue with TLS over TCP and the > > syslog base protocol. > > It can also arise teorethically for UDP, but as I understand > > not in practice for todays usage. When you are using TCP, in > > case the syslog sender generates events at an rate that is > > higher than available rate over the path used there will be > > build up of a queue. So I would like to have some words > > somewhere saying what you do when you build up a queue of > > messages that should be transmitted, but the queue simply > > keeps growing. What do I do? To me this situation implies > > that one starts discarding syslog messages and starts with > > the least important ones. So I would like to have a paragraph on > this. > > > > I also included UDP in this in the case that you actually > > have reserved or determined that syslog is allowed to use a > > particular amount of bandwidth, but not more. In this case it > > could be possible that one implements a rate limiter and run > > into exactly the same issue as for TCP. > > > > Please do understand that if syslog was designed from scratch > > today it wouldn't get awy without a congestion control that > > guarantees that it isn't missbehaving in any situation. But > > being an "old" protocol we are accepting less than that. > > However, we do require it to contain the limitations and > > assumptions that it can be safely operated with. Using it as > > it currently is used is not an issue because the networks it > > is used in has many magnitudes more bandwidth that syslog > > generates. However, what would happen if some one starts > > using syslog in low-powered, low-bitrate sensor network for > > carrying some information. In that situation syslog becomes a > > potential threat to the stability of the network as it > > doesn't react at all to congestion if run over UDP. Network > > failures are also sitation that are problematic to ensure > > that the inteded resources are available. Thus we do like to > > protect the utility of what resources do exist. > > > > So the repeat: > > > > Please seriously consider adding a paragraph about how one > > can thinn a queue of syslog messages in the base protocol. > > This as I think it potentially applies to any transport. > > > > Also consider when updating the UDP draft and adds what has > > been discussed with Lars, to add a single sentece with a > > reference the above paragraph as a method to keep the traffic > > within the allowed resources. > > > > Regards > > > > Magnus > > > > > > > > David Harrington skrev: > > > > > > > > > Hi Magnus, > > > > > > Syslog is a fire-and-forget protocol. We have no feedback > > mechanism > > > that permits us to recognize congestion and rate limit > > traffic based > > > on that feedback. > > > > > > Syslog is not a brand new protocol; it is widely used in the > > > industry, and other aspects of standardization has been handled > > > through POSIX and BSD standardization. The industry has > > expressed no > > > interest in making this a two-way protocol. This protocol > > is widely > > > used by operators, amd I have seen no demand from > > operators to make > > > this a two-way protocol, or any demand to resolve > > congestion control > > > for syslog, because congestion caused by syslog apparently > > is not a > > > problem in the real world. > > > > > > > > We had discussion of rate-limiting during the IETF Last Call. We > > > actually had suggestions for ways to rate-limit syslog in > > the earlier > > > document, but the IETF community rejected our having that > > text in the > > > document because syslog is a fire-and-forget protocol, so > > there is no > > > reliable mechanism for detecting congestion. The IETF > > commmunity did > > > not ask us to make syslog two-way, so we could add rate > > limiting to > > > the protocol; they asked us to keep syslog working as is, > > and remove > > > the unreliable recommendations to rate limit. > > > > > > You are placing a whole new requirement, that no implementers or > > > operators are asking for, on a protocol that is already widely > > > implemented and deployed. Where is the customer demand for this? > > > > > > I am concerned you might drive the syslog community to not work > > > within the IETF, where they came to develop a standard > > message format > > > and a secure transport, not to change the basic nature of > > the protocol. > > > > > > David Harrington > > > dharrington@huawei.com > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > > > > > -- > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > --------------------------------------------------------------------- > - > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > --------------------------------------------------------------------- > - > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > --------------------------------------------------------------------- > - > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Aug 24 15:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOech-0000Bo-Eu; Fri, 24 Aug 2007 15:15:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOecZ-0000Aj-I1; Fri, 24 Aug 2007 15:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOecZ-0006Ye-3a; Fri, 24 Aug 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8D80C175A5; Fri, 24 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOecY-000717-2N; Fri, 24 Aug 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-22.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-22.txt Pages : 38 Date : 2007-8-24 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-22.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-22.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-22.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-24140753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-24140753.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Fri Aug 24 15:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOedF-0000qw-5K; Fri, 24 Aug 2007 15:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOed3-0000dH-Ks; Fri, 24 Aug 2007 15:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOed2-0003II-EE; Fri, 24 Aug 2007 15:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 398C83286C; Fri, 24 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOecY-00071D-3x; Fri, 24 Aug 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-udp-10.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Transmission of syslog messages over UDP Author(s) : A. Okmianski Filename : draft-ietf-syslog-transport-udp-10.txt Pages : 10 Date : 2007-8-24 This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-udp-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-udp-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-24141939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-udp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-udp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-24141939.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Aug 29 16:34:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUDj-0001yd-ER; Wed, 29 Aug 2007 16:32:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTwr-0000Iv-Kl; Wed, 29 Aug 2007 16:15:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQTwr-0000IU-23; Wed, 29 Aug 2007 16:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A630E175A7; Wed, 29 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQTwM-0004CG-4W; Wed, 29 Aug 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Aug 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-udp-11.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Transmission of syslog messages over UDP Author(s) : A. Okmianski Filename : draft-ietf-syslog-transport-udp-11.txt Pages : 10 Date : 2007-8-29 This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-udp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-udp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-29151332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-udp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-udp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-29151332.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart--