From rgerhards@hq.adiscon.com Mon Nov 2 09:24:15 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49B73A6904 for ; Mon, 2 Nov 2009 09:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gfHdJaCXVKs for ; Mon, 2 Nov 2009 09:24:14 -0800 (PST) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 8F38D3A68D0 for ; Mon, 2 Nov 2009 09:24:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 11E0F241C012; Mon, 2 Nov 2009 18:07:24 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OteyW+HM2pkI; Mon, 2 Nov 2009 18:07:23 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC4581.dip.t-dialin.net [84.172.69.129]) by mailin.adiscon.com (Postfix) with ESMTP id 3FAD5241C002; Mon, 2 Nov 2009 18:07:23 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 18:24:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103312@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt Thread-Index: AcpNCyNWa1ezmQ7JSmSmM7H6xmRwVQACPg6QA7LphAA= References: From: "Rainer Gerhards" To: "Joseph Salowey \(jsalowey\)" , Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:24:15 -0000 Some additional thoughts: > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Wednesday, October 14, 2009 11:24 PM > To: syslog@ietf.org > Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt >=20 > I Just posted a -00 version of the syslog DTLS draft > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt). I > tried to merge the two proposals together and keep consistent with the > Syslog TLS draft. Below are some issues I have identified, I'm sure > there are others. >=20 > 1. Transport >=20 > DTLS can run over several different transports, right now the draft > requires UDP and recommends DCCP. I think these are the most well > defined. The draft also forbids DTLS over TCP and favors TLS over TCP > to keep things consistent. I left out SCTP, I'm not sure where SCTP > over DTLS is in the process and there also is a TLS option for SCTP. I think we should limit the scope to pure datagram services. Rest as in = reply to Tom. >=20 > 2. Port Number >=20 > DTLS could use the same port and TLS, which seems simple. The > difficulty could be that for some transports you could use either TLS > or > DTLS (SCTP for example). In theory you could tell the difference > between TLS and DTLS by version number so maybe this isn't a problem. The problem would be resolved if we disallow stream bindings - can we? > 3. Initiation >=20 > One of the drafts allowed either side to initiate. I did not include > this. If we have a use case for it we could bring it back in. I thought a bit more about this. I do not see any use case where a server-side open would be required.=20 > 4. Dead Peer Detection >=20 > There has been a lot of discussion on DPD on the list. I don't have > any > specific remedy in the draft, just a warning that it could be a > problem. > Its likely that some work on this will happen in DTLS, but I'm not > confident on the timeframe at this point. I think the best solution is to simply include a warning and leave the = rest to future DTLS work. Doesn't make sense to (re-)invent that wheel. >=20 > 5. Message Size >=20 > The text on message size could use some review. commented on that in reply to Tom as well. I have one more comment to 5.1.2, especially "If reliability is required, then Syslog over TLS may be used" This comes with the co-notation that Syslog over TLS is reliable. = However, as no app-level ACKs are used, it is not totally reliable. RFC5425 contains = such a note. I find it important to not create the impression that RFC5425 is = a fully reliable protocol. All too often in practice I work with folks = that try to build an audit-grade syslog system and, often late enough, then find = out the hard way that some message loss can currently not be prevented. This creates a lot of frustration and wastes many resources. We have not yet managed to create an audit-grade syslog transport other = than RFC3195. I, too, was an advocate for the simple model RFC5425 utilizes, = and there were good reasons for doing so (all those that seemingly make = RFC3195 so far a failure). When we are through with -sign and -dtls, we should probably look into rechartering for RFC3195bis and/or an extension to = RFC5425 to provide the missing bits for reliability, but I think getting -sign = and -DTLS out of the door should have priority. All in all, I really like the good work Joe has done! I think (and hope) = we do not need too many revisions to create a version that can be = published. Rainer >=20 > Cheers, >=20 > Joe >=20 > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf > Of Internet-Drafts@ietf.org > Sent: Wednesday, October 14, 2009 1:15 PM > To: i-d-announce@ietf.org > Cc: syslog@ietf.org > Subject: [Syslog] I-D Action:draft-ietf-syslog-dtls-00.txt >=20 > 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. >=20 >=20 > Title : Datagram Transport Layer Security (DTLS) > Transport Mapping for Syslog > Author(s) : J. Salowey, et al. > Filename : draft-ietf-syslog-dtls-00.txt > Pages : 18 > Date : 2009-10-14 >=20 > This document describes the transport of syslog messages over DTLS > (Datagram Transport Level Security). It provides a secure transport > for > syslog messages in cases where a connection-less transport is desired. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From rgerhards@hq.adiscon.com Mon Nov 2 09:26:48 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3843A6A4D for ; Mon, 2 Nov 2009 09:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TegOProGYdY9 for ; Mon, 2 Nov 2009 09:26:47 -0800 (PST) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 3A02A3A67A5 for ; Mon, 2 Nov 2009 09:26:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 7FBD8241C012; Mon, 2 Nov 2009 18:09:54 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHzZ0xGMF05u; Mon, 2 Nov 2009 18:09:54 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC4581.dip.t-dialin.net [84.172.69.129]) by mailin.adiscon.com (Postfix) with ESMTP id 97EE0241C002; Mon, 2 Nov 2009 18:09:53 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 18:27:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103313@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt Thread-Index: AcpW8cJT2GpzHAAPS3aokQOTfX3HNAE7FU+w References: <012201ca56e8$f0e4ac40$0601a8c0@allison> From: "Rainer Gerhards" To: "tom.petch" Cc: syslog@ietf.org Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:26:48 -0000 I thankfully have now also been able to review the document. > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Tuesday, October 27, 2009 10:13 AM > To: Joseph Salowey (jsalowey); syslog@ietf.org > Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt >=20 > Good stuff. full ack! > Ports; I like the idea of a common port, because it makes operational > deployment (eg filtering in Middle boxes) so much simpler and less > error prone. I agree, especially if we intend to prohibit DTLS use over TCP (what I = think is a good idea). > DTLS has an updated I-D in Working Group Last Call > draft-ietf-tls-rfc4347-bis > which I think we should reference. It covers DTLS over DCCP properly, > which its predecessor might not be seen to. >=20 > Message size I think needs more coverage. I would include a summary = of > the > advice on PMTU discovery in DTLS 4.1.1.1 and specifically mention the > 2**14 > limit on records in DTLS. Earlier discussions on this list showed a > desire for > 2**16 > syslog messages which, to me, implies fragmentation by the transport > sender. This is a hard issue. I think we should review our use case for DTLS. To = me, the primary driver behind DTLS in a syslog system is the ability to = encrypt messages, while still retaining the ability to send single-frame = messages, which may be the only way to convey any information inside a broken = network. This is properly described in Section 1. When this is our ultimate goal, we need to preserve that capability. = That means we can not permit fragmentation. While I am always an advocate for longer message sizes, I do not think that the reasoning behind that fits = in into the DTLS scenario. Larger size messages are almost exclusively seen = in audit-like systems (e.g. IHE), much less in network management. RFC5426 defines a lower limit of 480 octets, which is hard, but fact. It then recommends 2K and specifies an upper limit of 64K. I think we should = follow that route with a lower limit of 512, recommended 2K (should be well sufficient for management info) and 16K being the upper bound. As of my understanding, that should solve the size limit issue without hurting = anyone. The lower limit is higher than in RFC5426, the recommended size is the = same, only the upper limit is lower, but still on the save side for management information. As a side-note, it may make sense to spell out - if we agree on that - = that DTLS is NOT a transport to be used for auditing purposes. > Dead Peer Detection I would sit on until something more happens with > the > TLS Working Group. sounds reasonable. Rainer Gerhards >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" > To: > Sent: Wednesday, October 14, 2009 10:23 PM > Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt >=20 >=20 > I Just posted a -00 version of the syslog DTLS draft > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt). I > tried to merge the two proposals together and keep consistent with the > Syslog TLS draft. Below are some issues I have identified, I'm sure > there are others. >=20 > 1. Transport >=20 > DTLS can run over several different transports, right now the draft > requires UDP and recommends DCCP. I think these are the most well > defined. The draft also forbids DTLS over TCP and favors TLS over TCP > to keep things consistent. I left out SCTP, I'm not sure where SCTP > over DTLS is in the process and there also is a TLS option for SCTP. >=20 > 2. Port Number >=20 > DTLS could use the same port and TLS, which seems simple. The > difficulty could be that for some transports you could use either TLS > or > DTLS (SCTP for example). In theory you could tell the difference > between TLS and DTLS by version number so maybe this isn't a problem. >=20 > 3. Initiation >=20 > One of the drafts allowed either side to initiate. I did not include > this. If we have a use case for it we could bring it back in. >=20 > 4. Dead Peer Detection >=20 > There has been a lot of discussion on DPD on the list. I don't have > any > specific remedy in the draft, just a warning that it could be a > problem. > Its likely that some work on this will happen in DTLS, but I'm not > confident on the timeframe at this point. >=20 > 5. Message Size >=20 > The text on message size could use some review. >=20 > Cheers, >=20 > Joe >=20 > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog From hartmans@mit.edu Tue Nov 3 03:49:06 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C425728C183 for ; Tue, 3 Nov 2009 03:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbZ2w2-AHHvc for ; Tue, 3 Nov 2009 03:49:06 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 11BAA28C17D for ; Tue, 3 Nov 2009 03:49:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2796B201C9; Tue, 3 Nov 2009 06:49:22 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F56D4476; Tue, 3 Nov 2009 06:49:18 -0500 (EST) To: "Rainer Gerhards" References: <012201ca56e8$f0e4ac40$0601a8c0@allison> <0cc801ca5752$e24aad00$0600a8c0@china.huawei.com> <4AE834B4.6090209@cisco.com> <9B6E2A8877C38245BFB15CC491A11DA7103310@GRFEXC.intern.adiscon.com> From: Sam Hartman Date: Tue, 03 Nov 2009 06:49:18 -0500 In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103310@GRFEXC.intern.adiscon.com> (Rainer Gerhards's message of "Mon\, 2 Nov 2009 18\:00\:52 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 03 Nov 2009 08:40:23 -0800 Cc: "Woundy, Richard" , deketelaere@tComLabs.com, enechamkin@broadcom.com, "Ong, Lyndon" , Wes Hardaker , Margaret Wasserman , Sumanth Channabasappa , Andi Kosich , Sam Hartman , v.marinov@jacobs-university.de, akarmaka@cisco.com, Huang Min , syslog@ietf.org, Jeffrey Hutzelman Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:49:06 -0000 I think including a script to generate certificates and configure their use would meet this requirement, so I definitely think it is something that you could do. I'm not at all convinced that generating a cert if you don't have one would be wrong. Debian has chosen to do that for a number of applications we ship and it seems to work out well. From rgerhards@hq.adiscon.com Mon Nov 2 09:00:40 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE483A6911 for ; Mon, 2 Nov 2009 09:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75cVQ9XQpReD for ; Mon, 2 Nov 2009 09:00:38 -0800 (PST) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 1028028C198 for ; Mon, 2 Nov 2009 09:00:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 7ADC8241C009; Mon, 2 Nov 2009 17:44:05 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD-+pHalTJuL; Mon, 2 Nov 2009 17:44:04 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC4581.dip.t-dialin.net [84.172.69.129]) by mailin.adiscon.com (Postfix) with ESMTP id 14490241C002; Mon, 2 Nov 2009 17:44:03 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2009 18:00:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103310@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt Thread-Index: AcpX24IHyRa0paDvR/6Clejva+hffAEAYNBw References: <012201ca56e8$f0e4ac40$0601a8c0@allison><0cc801ca5752$e24aad00$0600a8c0@china.huawei.com><4AE834B4.6090209@cisco.com> From: "Rainer Gerhards" To: "Sam Hartman" , "Eliot Lear" X-Mailman-Approved-At: Tue, 03 Nov 2009 08:40:37 -0800 Cc: "Woundy, Richard" , deketelaere@tComLabs.com, enechamkin@broadcom.com, "Ong, Lyndon" , Margaret Wasserman , Wes Hardaker , Sumanth Channabasappa , Andi Kosich , v.marinov@jacobs-university.de, akarmaka@cisco.com, Huang Min , syslog@ietf.org, Jeffrey Hutzelman Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:00:40 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, October 28, 2009 3:22 PM > To: Eliot Lear > Cc: David Harrington; 'tom.petch'; 'Joseph Salowey (jsalowey)'; > syslog@ietf.org; 'Wes Hardaker'; 'Juergen Schoenwaelder'; 'Huang Min'; > Rainer Gerhards; 'Sharon Chisholm'; alex@cisco.com; 'Glenn M. Keeni'; > 'Miao Fuyou'; 'Anton Okmyanskiy (aokmians)'; akarmaka@cisco.com; > v.marinov@jacobs-university.de; 'Woundy, Richard'; 'Sumanth > Channabasappa'; deketelaere@tComLabs.com; enechamkin@broadcom.com; > 'Richard Graveman'; 'Ong, Lyndon'; 'Andi Kosich'; 'Sam Hartman'; > 'Margaret Wasserman'; 'Jeffrey Hutzelman' > Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt =20 > Why isn't usability sufficient for a MUST in this case? Here's the > argument. Unless turning on security is as easy as not doing so, then > there is a sigfificant cost to security and we will not get the > benefits we should. As a result, especially because there are > significant passive attacks protected against by using DTLS, the > security of the protocol will be significantly improved by requiring > implementations provide a easy-to-enable security solution. >=20 > Generating a self-signed cert on a Mac or Linux box is *not* easy > compared to running syslogd. >=20 > Sam, with his painless-security.com hat on. I agree to the argument, but from the technical perspective it is hard = to do this in a typical linux syslogd. The problem is that all "user = interface" you can expect to have is a config file and a text editor. Blindly = generating certificates if they are not specified in the config file is not = appropriate, I think. So the user needs to run an external tool in any case. I fully = agree that openssl is not what we have on our mind when thinking about ease of = use. But any more graphical front end will most probably not be delivered by default by the distro's package managers. They, for good reason, try to = keep the syslogd footprint to as small as possible. In the end result, a = specific syslogd might support a GUI for certificate generation, but the user = will probably need to run through the process of compiling that functionality = from source, what is also a showstopper for many users. On the other hand, a small shell script working as a "front end" to = openssl (or whatever) will probably be included in the distro's syslogd (or syslogd-dtls) package. For this reason, I would prefer to see a RECOMMENDED, but I definitely = would not object a MUST. However, we need to be aware that there are many = parties involved in making this MUST actually happen, so it will not be much = stronger than a RECOMMENDED in practice. Rainer=20 From rgerhards@hq.adiscon.com Fri Nov 6 08:59:10 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6B428C0ED for ; Fri, 6 Nov 2009 08:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVERH+V3jI9i for ; Fri, 6 Nov 2009 08:59:09 -0800 (PST) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 5E8B128C149 for ; Fri, 6 Nov 2009 08:59:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 10DA5241C00A for ; Fri, 6 Nov 2009 17:55:04 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St9YKY2NV0bL for ; Fri, 6 Nov 2009 17:55:03 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC4D22.dip.t-dialin.net [84.172.77.34]) by mailin.adiscon.com (Postfix) with ESMTP id 9954B241C001 for ; Fri, 6 Nov 2009 17:55:03 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 Nov 2009 17:59:29 +0100 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA710337B@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: documenting industry-standard "plain tcp syslog" Thread-Index: AcpfAoFSSCgEExuATdGcMRPy7849Aw== From: "Rainer Gerhards" To: Subject: [Syslog] documenting industry-standard "plain tcp syslog" X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:59:10 -0000 Hi WG, I would like to ask about the proper procedure - and potential = acceptance of such an effort - before I invest any real time into an effort. I am = often in the situation that I need to talk to other folks about the current = practice of "plain tcp syslog". This "protocol" is not standardized and the IETF = has no intention to do so (and I applaud that for various reasons). However, = it is often unfortunate to have no reference for how it is done, especially = as it will be present for at least another five, very probably more, years = from now. So I have to admit I have a somewhat urgent need to get a reference out = for this protocol some way or the other. One route I could take is create an informational personal I-D that describes what we see in practice (much = like RFC3164 described how UDP was done). I know this cannot be a WG deliverable under the current charter and I = know that we cannot recharter (nor would I like to do so) before we have = completed the current items. So I wonder if there is any way to publish such an informational RFC and if there would be support, or at least no = objection, from this WG. Any advise and/or comment would be appreciated. Thanks, Rainer From j.schoenwaelder@jacobs-university.de Fri Nov 6 10:23:56 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46E03A69D9 for ; Fri, 6 Nov 2009 10:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi-lfJPWpk+j for ; Fri, 6 Nov 2009 10:23:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E88913A69D6 for ; Fri, 6 Nov 2009 10:23:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F750C0018; Fri, 6 Nov 2009 19:24:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id auiek+qw5n0b; Fri, 6 Nov 2009 19:24:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAD0DC0049; Fri, 6 Nov 2009 19:24:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5E976DA5703; Fri, 6 Nov 2009 19:24:18 +0100 (CET) Date: Fri, 6 Nov 2009 19:24:18 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Message-ID: <20091106182418.GA13524@elstar.local> Mail-Followup-To: Rainer Gerhards , "syslog@ietf.org" References: <9B6E2A8877C38245BFB15CC491A11DA710337B@GRFEXC.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA710337B@GRFEXC.intern.adiscon.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "syslog@ietf.org" Subject: Re: [Syslog] documenting industry-standard "plain tcp syslog" X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 18:23:56 -0000 On Fri, Nov 06, 2009 at 05:59:29PM +0100, Rainer Gerhards wrote: > I know this cannot be a WG deliverable under the current charter and I know > that we cannot recharter (nor would I like to do so) before we have completed > the current items. So I wonder if there is any way to publish such an > informational RFC and if there would be support, or at least no objection, > from this WG. I support having a reference specification how SYSLOG over TCP is commonly done. The path forward with an individual ID is fine with me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Mon Nov 9 19:49:40 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE8B3A689E for ; Mon, 9 Nov 2009 19:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs8PaXUQ07AS for ; Mon, 9 Nov 2009 19:49:39 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 61F6F3A68DB for ; Mon, 9 Nov 2009 19:49:39 -0800 (PST) Received: from OMTA17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 3FiJ1d0011afHeLA7Fq7tr; Tue, 10 Nov 2009 03:50:07 +0000 Received: from Harrington73653 ([133.93.19.161]) by OMTA17.emeryville.ca.mail.comcast.net with comcast id 3FpY1d0093UX6v18dFpcVh; Tue, 10 Nov 2009 03:50:05 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Rainer Gerhards'" References: <9B6E2A8877C38245BFB15CC491A11DA710337B@GRFEXC.intern.adiscon.com> <20091106182418.GA13524@elstar.local> Date: Tue, 10 Nov 2009 12:49:34 +0900 Message-ID: <031f01ca61b8$e4fcf420$a1135d85@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091106182418.GA13524@elstar.local> Thread-Index: AcpfDl7pjkauFxHKSSGi6gQtYvAreACqW1Tw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org Subject: Re: [Syslog] documenting industry-standard "plain tcp syslog" X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:49:40 -0000 Hi, The chairs have discussed this proposed work with the security and ops area directors. The area directors are comfortable with this work being done in the OPS area, preferably in the OPSAWG WG. As with any proposal, the WG will need to decide to accept the draft as a WG draft. The WG can request an update to the OPSAWG charter. The OPSAWG chairs will oversee the process. The WG can decide to submit this for publication as Informational or standards-track. The IESG (representing the IETF) can choose which publication status is appropriate for the document. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Saturday, November 07, 2009 3:24 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] documenting industry-standard "plain tcp syslog" > > On Fri, Nov 06, 2009 at 05:59:29PM +0100, Rainer Gerhards wrote: > > > I know this cannot be a WG deliverable under the current > charter and I know > > that we cannot recharter (nor would I like to do so) before > we have completed > > the current items. So I wonder if there is any way to > publish such an > > informational RFC and if there would be support, or at > least no objection, > > from this WG. > > I support having a reference specification how SYSLOG over TCP is > commonly done. The path forward with an individual ID is fine with me. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > From rgerhards@hq.adiscon.com Tue Nov 10 07:19:09 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099CF28C196 for ; Tue, 10 Nov 2009 07:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8WFabzaTKBo for ; Tue, 10 Nov 2009 07:19:07 -0800 (PST) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 5F6D928C137 for ; Tue, 10 Nov 2009 07:19:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 06746241C02D; Tue, 10 Nov 2009 16:01:36 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYC2hLHnl59q; Tue, 10 Nov 2009 16:01:35 +0100 (CET) Received: from GRFEXC.intern.adiscon.com (p54AC7A4F.dip.t-dialin.net [84.172.122.79]) by mailin.adiscon.com (Postfix) with ESMTP id 6BC25241C003; Tue, 10 Nov 2009 16:01:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Nov 2009 16:19:29 +0100 Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71033BC@GRFEXC.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] documenting industry-standard "plain tcp syslog" Thread-Index: AcpfDl7pjkauFxHKSSGi6gQtYvAreACqW1TwABhWBKA= References: <9B6E2A8877C38245BFB15CC491A11DA710337B@GRFEXC.intern.adiscon.com> <20091106182418.GA13524@elstar.local> <031f01ca61b8$e4fcf420$a1135d85@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , "Juergen Schoenwaelder" Cc: syslog@ietf.org Subject: Re: [Syslog] documenting industry-standard "plain tcp syslog" X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:19:09 -0000 Thank you everyone, I will see that I get something to be discussed out = of the door soon! Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, November 10, 2009 4:50 AM > To: 'Juergen Schoenwaelder'; Rainer Gerhards > Cc: syslog@ietf.org; 'Chris Lonvick' > Subject: RE: [Syslog] documenting industry-standard "plain tcp syslog" >=20 > Hi, >=20 > The chairs have discussed this proposed work with the security and ops > area directors. > The area directors are comfortable with this work being done in the > OPS area, preferably in the OPSAWG WG. >=20 > As with any proposal, the WG will need to decide to accept the draft > as a WG draft. > The WG can request an update to the OPSAWG charter. The OPSAWG chairs > will oversee the process. > The WG can decide to submit this for publication as Informational or > standards-track. > The IESG (representing the IETF) can choose which publication status > is appropriate for the document. >=20 > dbh >=20 > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Saturday, November 07, 2009 3:24 AM > > To: Rainer Gerhards > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] documenting industry-standard "plain tcp > syslog" > > > > On Fri, Nov 06, 2009 at 05:59:29PM +0100, Rainer Gerhards wrote: > > > > > I know this cannot be a WG deliverable under the current > > charter and I know > > > that we cannot recharter (nor would I like to do so) before > > we have completed > > > the current items. So I wonder if there is any way to > > publish such an > > > informational RFC and if there would be support, or at > > least no objection, > > > from this WG. > > > > I support having a reference specification how SYSLOG over TCP is > > commonly done. The path forward with an individual ID is fine with > me. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > From ietfdbh@comcast.net Mon Nov 30 08:16:36 2009 Return-Path: X-Original-To: syslog@core3.amsl.com Delivered-To: syslog@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CBD28C129 for ; Mon, 30 Nov 2009 08:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHmoyT2EFvu6 for ; Mon, 30 Nov 2009 08:16:35 -0800 (PST) Received: from QMTA13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id AEC1028C123 for ; Mon, 30 Nov 2009 08:16:34 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA13.westchester.pa.mail.comcast.net with comcast id BRxc1d00B0EZKEL5DUGUiN; Mon, 30 Nov 2009 16:16:28 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA01.westchester.pa.mail.comcast.net with comcast id BUGT1d00e284sdk3MUGUew; Mon, 30 Nov 2009 16:16:28 +0000 From: "David Harrington" To: "'Chris Lonvick'" , References: Date: Mon, 30 Nov 2009 11:16:26 -0500 Message-ID: <0de301ca71d8$77fec3a0$a1135d85@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpxyMJCiThs1z0ORJmIKm5OYDQoCAABcWgw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org, opsawg@ietf.org Subject: [Syslog] review for draft-gerhards-syslog-plain-tcp-00 (fwd) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:16:36 -0000 Hi, Here are a few comments on this draft. (As syslog co-chair I will point out this is NOT a syslog WG item because it is not a secure transport, and out of scope of the syslog WG charter. I have cross-posted since there may be interested parties in the syslog WG who will not know it is being proposed in the OPSAWG WG.) Most of my comments are editorial. 1) Is there such a thing as an RFC3164 message? Isn't rfc3164 just a description of a bunch of implementations, each of which has its own message format? 2) In the intro, the last sentence mentions syslog transport receivers and legacy syslog senders. Is this text consistent with the RFC5424 terminology? 3) I suggest a small diagram showing the stack-oriented approach of rf5424 and its transport models, with an arrow showing that this document discusses interactions between the sender and receiver transport implementations. 4) Diagram 2 is labelled Diagram 1 5) octet-counting and octet-stuffing are not described before the discussion of MUST/MAY is addressed. It would help to point to the sections that define these (i.e. provide a forward reference). 6) the discussion of MUST/MAY and REQUIRED/RECOMMENDED is redundant. You only need the sentence with REQUIRED/RECOMMENDED (which also discusses why) 7) Is ABNF a figure? Do you need both diagrams and figures? 8) I'm not an expert on ABNF. Will this ABNF parse in standard parsers with APP-DEFINED not specified? 9) " A transport receiver MUST accept that the TRAILER character is a USASCII LF." sounds like the receiver is talking with a shrink ;-) How about "A transport receiver MUST accept USASCII LF as a TRAILER character."? 10) s/octect/octet/g 11) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. I would reverse their order 12) 3.3.1 is NOT RECOMMENDED; 3.3.2 is RECOMMENDED. But if I read 3.3, they are MAY/MUST and RECOMMENDED/REQUIRED. There is inconsistency of RECOMMENDED vs MAY vs NOT RECOMMENDED for stuffing, and of MUST vs REQUIRED vs RECOMMENDED for counting. 13) " It is recommended and current practice that a transport receiver assumes that octet counted framing is used if a syslog frame starts with a digit." You are defining a standard; make this a MUST for compliance to this standard. 14) " SYSLOG-MSG is defined in [RFC5424]. Most senders use the format described in [RFC3164] as an alternate format." This sounds like an implicit recommendation to use the rfc3164 format, since that's what most senders use. Again, you are defining a standard; I think you should at least RECOMMEND the rfc5424 format for compliance with this TCP transport standard. 15) section 3.4 says to discard the TRAILER. How will this work with syslog sign? Should the hash be calculated before the TRAILER is added? And for octet counting, is the hash calculated before the count is prepended? 16) section 3.5 says "It then initiates a TCP session closure." Not being knowledgeable about TCP details, I thught this meant it would start a closure conversation with the peer. Would this be clearer if it said "It then initiates a local TCP session closure."? Obviously, the text that follows clarifies this, but it was distracting. 17) Some people prefer that non-normative sections be handled as appendices. Would it be good to move section for to an appendix? 18) section 4 uses terms "encouraged" and "should". This is not consistent with RFC2119. 19) section 4 - same coments as in 13) 20) section 4.1 - is this advice consistent with earlier statements about having to close and re-init the connection? If the difference is that the earlier discussed requirements for compliance ("conservative in what you send"), and this talks about "liberal in what you receive", I recommend you discuss it in those terms. (Is that Postel's law, or something like that?) 21) 4.2 and 4.3 mention what is REQUIRED; but section 4 is non-normative and only informational. The REQUIRED seems out of place here. I think a discussion of interoperability with legacy devices (ala Postel) might be called for in both sections, rather than RFC2119 required/may discussions. 22) "In that" is unnecessary and makes the sentence harder to parse. 23) "In this legacy implementation" - should this be "In some legacy implementations"? That whole paragragh could use cleanup. 24) octet-counting and octet-stuffing sections should be ordered consistently with 11) 25) section 5.1 "representing itself as another machine" it is not clear who is doing the misrepresenting in this sentence - the sender or the receiver. Needs wordsmithing. 26) "indeed" is seldom necessary 27) 5.6 "cannot always know" - does it ever know? 28) You should have a "Note to the RFC Editor" to discuss replacing the in the text associated with the port assignment requested in section 7. (Oh, I found it in secton 9; why not just put it into section 7?) 29) I think the acknowledgement of xml2rfc is not needed. Acknowledgements are for technical contributors. If you wrote the draft using MS-Word or Notepad or Emacs, would you acknowledge them? 30) You don't need to have section 6; xml2rfc automatically generates a section (unnumbered per RFC editor rules) for Authors' Addresses. > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Monday, November 30, 2009 9:24 AM > To: Dan Romascanu; pasi.eronen@nokia.com > Cc: rgerhards@adiscon.com; ietfdbh@comcast.net > Subject: New Version Notification for > draft-gerhards-syslog-plain-tcp-00 (fwd) > > Hi Dan, > > A few weeks ago we were talking about documenting syslog/TCP > and moving it > into the OPSAWG - it no longer fits in the syslog WG charter. > Rainer and > I wrote up the initial draft for this. > > Would you please look it over and see if it is of sufficient > quality and > interest to become an OPSAWG product? If so, should I take > this to the > OPSAWG Chairs? > > Best regards, > Chris > > ---------- Forwarded message ---------- > Date: Mon, 30 Nov 2009 06:02:36 -0800 (PST) > From: IETF I-D Submission Tool > To: rgerhards@adiscon.com > Cc: clonvick@cisco.com > Subject: New Version Notification for > draft-gerhards-syslog-plain-tcp-00 > > > A new version of I-D, draft-gerhards-syslog-plain-tcp-00.txt > has been successfuly submitted by Rainer Gerhards and posted > to the IETF repository. > > Filename: draft-gerhards-syslog-plain-tcp > Revision: 00 > Title: Transmission of Syslog Messages over TCP > Creation_date: 2009-11-30 > WG ID: Independent Submission > Number_of_pages: 14 > > Abstract: > This document describes the transport for syslog messages over TCP/ > IPv4 or TCP/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. > > There have been many implementations and deployments of traditional > syslog over TCP for many years. That protocol has evolved without > being standardized and has proven to be quite interoperable in > practice. > > The aim of this specification is to document three things: how to > transmit standardized syslog over TCP, how this has been done for > traditional syslog, and how the new syslog architecture can > interoperate with the traditional deployments. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and 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 June 3, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > >