From syslog-bounces@lists.ietf.org Sat Jul 01 21:46:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwr2V-0001xj-9S; Sat, 01 Jul 2006 21:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwr2T-0001xe-W4 for syslog@ietf.org; Sat, 01 Jul 2006 21:46:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwr2S-0005uA-KX for syslog@ietf.org; Sat, 01 Jul 2006 21:46:21 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2006 18:46:20 -0700 X-IronPort-AV: i="4.06,198,1149490800"; d="scan'208"; a="1834415647:sNHT28413064" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k621kKlV020673 for ; Sat, 1 Jul 2006 18:46:20 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k621kJkf001958 for ; Sat, 1 Jul 2006 18:46:19 -0700 (PDT) Date: Sat, 1 Jul 2006 18:46:19 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=956; t=1151804780; x=1152668780; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Payload=20stuff=20is=20out=20of=20scope=20for=20our=20WG; X=v=3Dcisco.com=3B=20h=3Dlq9KnBctRn1co7ESLvk8EOGhahM=3D; b=n8nItQ88fhuxqN3PqPsKW56b0UISPyHcoD5KFyFP5oaaeaXi6gKp9WrK63slpyMB7GhV4rsq JIDzrDLxWPnX2kR4XBMkUsPNzZayqgkMYO3m1fY5yIeVA+R/eUtAoY+d; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Syslog] Payload stuff is out of scope for our WG 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, I've seen a lot of discussion about payload format on the list lately. I think that everyone already knows the charter of the WG but I want to be clear about this; we're not going to address that issue within our WG. I'm OK with having some discussion around this as it makes us think about the header information that we've defined in syslog-protocol. However, we are not going to define the payload format in our Working Group. I would encourage everyone interested in this topic to follow David's advice and get involved with the discussions going on in the Operations and Management area of the IETF and in other Standards Developing Organizations. For the IETF, please take a look at the latest IESG retreat notes here: http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt See section 11. Similarly, it might be good for interested people to hold a BoF at IETF 67 (San Diego in November). Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jul 03 15:28:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxU5J-0003Eh-54; Mon, 03 Jul 2006 15:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxU5I-0003Ec-Ly for syslog@ietf.org; Mon, 03 Jul 2006 15:27:52 -0400 Received: from dsl-202-45-110-141-static.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxU5G-0000Zg-P9 for syslog@ietf.org; Mon, 03 Jul 2006 15:27:52 -0400 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id k63JRhc9028495; Tue, 4 Jul 2006 05:27:43 +1000 (EST) From: Darren Reed Message-Id: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim In-Reply-To: To: Chris Lonvick Date: Tue, 4 Jul 2006 05:27:28 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: syslog@ietf.org 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 Chris, The approach I'd like to take is to see what Balazs Scheidler can come up with, that is different to the proposed approach, to make syslog function over a TLS transport in syslog-ng and look at turning that into an i-d. While it may not guarantee us any better situation with respect to patents, etc, I have more faith working on documenting something that is written to be open and free than involving people who have a financial interest in the protocol going in certain diretions. I suppose this is a get working code first and then refine/ document it. Thoughts? Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jul 04 03:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxf6r-0003XB-Dh; Tue, 04 Jul 2006 03:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxf6p-0003OC-CO for syslog@ietf.org; Tue, 04 Jul 2006 03:14:11 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxf6m-0003zv-Uk for syslog@ietf.org; Tue, 04 Jul 2006 03:14:11 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 0885527C065; Tue, 4 Jul 2006 09:10:04 +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 04804-04; Tue, 4 Jul 2006 09:10:03 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id BBBCD27C061; Tue, 4 Jul 2006 09:10:03 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 09:14:06 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jul 2006 09:14:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174B04@grfint2.intern.adiscon.com> In-Reply-To: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: Acae1uG+YwEeR4Y/Q3isPC6ygN25WwAYi4Ug From: "Rainer Gerhards" To: "Darren Reed" , "Chris Lonvick" X-OriginalArrivalTime: 04 Jul 2006 07:14:06.0156 (UTC) FILETIME=[6FA340C0:01C69F39] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: syslog@ietf.org 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 Darren, I think this is a good proposal, though most importantly Balazs needs to like it ;) I just see one problem. We need to deliver a secure transport by November. Implementing, documenting and discussing a new approach is probably beyond that time frame (especially given the summer holidays). So it might still make sense to use either the current -transport-tls or do a very minimalistic 3195bis. So we agree on the medium-term approach but not necessarily on the short-term one. Rainer > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Monday, July 03, 2006 9:27 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim >=20 > Chris, >=20 > The approach I'd like to take is to see what Balazs Scheidler can > come up with, that is different to the proposed approach, to make > syslog function over a TLS transport in syslog-ng and look at turning > that into an i-d. >=20 > While it may not guarantee us any better situation with respect to > patents, etc, I have more faith working on documenting something > that is written to be open and free than involving people who have > a financial interest in the protocol going in certain diretions. >=20 > I suppose this is a get working code first and then refine/ > document it. >=20 > Thoughts? >=20 > Darren >=20 > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Tue Jul 04 18:34:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtTW-0005t7-Ij; Tue, 04 Jul 2006 18:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtTV-0005t2-7w for syslog@ietf.org; Tue, 04 Jul 2006 18:34:33 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxtTS-0001im-ER for syslog@ietf.org; Tue, 04 Jul 2006 18:34:33 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060704223428m1100ari7re>; Tue, 4 Jul 2006 22:34:28 +0000 From: "David Harrington" To: Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Tue, 4 Jul 2006 18:33:14 -0400 Message-ID: <0ed501c69fb9$d72e26d0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa3EiOng4KrbaFSXKf9aYL7q19aQAfVmewABM/w6AAIN0g0AAL14WwAAiAfgAAz11v4A== In-Reply-To: <98AE08B66FAD1742BED6CB9522B7312201A1CDE9@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d67762704726a1bed57e7f4595960d34 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 Anton, I am not proposing to drop anything that has been developed by this WG so far; I am proposing that we focus our current and future discussions on what we are suppposed to be delivering. I have concerns that there are numerous discussions that deal with issues other than security-related issues, and I think those discussions belong in the OPS area rather than the Security area. dbh > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, June 30, 2006 3:43 PM > To: David Harrington; Rainer Gerhards; Chris Lonvick > (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > David: > > Please clarify... > > Are you suggesting we drop syslog-protocol, which actually > defines message format, and just do a generic secure > transport for events? Something that just does framing, > app-level ack and had generic payload? > > And then we continue to live without syslog standard, waiting > for others to standardize payload? > > Anton. > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, June 30, 2006 11:58 AM > > To: 'Rainer Gerhards'; Chris Lonvick (clonvick); syslog@ietf.org > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi, > > > > [posting as a contributor] > > > > I recommend this WG make a clear separation (as much as is possible) > > between issues of security and issues of network management. > > > > Issues such as harmonization with the work of other SDOs, > integration > > with netconf, message formatting, content standardization, > and so on, > > are about syslog as a network management protocol. I strongly beleve > > this work should **not** be done by the syslog-sec WG, but in a WG > > chartered in the OPS area or the Application area, not the Security > > area. There are many contributors who have worked on, and are > > currently working on, other network management protocols and have > > addressed issues similar to those facing syslog. > > > > In addition, there is an effort by the new OPS Management AD to > > address the current isolated decision making (silos) that > is occurring > > regarding the management plane throughout the IETF. The contributors > > to this WG should be involved in that discussion, which is likely to > > be centered in the OPS area. > > > > This WG is about security for syslog, and we should focus > our efforts > > on solving the security problems, whether with tls or ssh > or beep, and > > publish. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Friday, June 30, 2006 6:11 AM > > > To: David Harrington; Chris Lonvick; syslog@ietf.org > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > David, > > > > > > I fully agree with your thought. I, too, think we must > put emphasis > > on > > > the delivery of documents. In my personal opinion, this > > > leaves only two > > > realistic options: > > > > > > a) rfc 3195bis as you have described it (without the "rathole > > > discussion") > > > b) -transport-tls more or less as it is now > > > > > > I think there are enough comments on a) already in the > list archive. > > I > > > will not repeat them. > > > > > > Comments on b) currently tend to focus on the IPR issue. Let's > > ignore > > > that for a moment and look at other arguments. We have > > > intially opted in > > > favor of -transport-tls because it already is in widespread > > > use. What is > > > done currently can not be standardized literally, but we can > > > standardize > > > something that is quite close to it. It was our opinion that > > > -transport-tls should by fairly easy to implement, thus bringing > > some > > > immediate value to the community. > > > > > > Now some technical issues have come up on the list, things like > > > app-layer ACKs, opening and closeing conversations. I have brought > > up > > > some of them. I am also of the view that we could craft a better > > > framing, probably borrowing from NETCONF (and thus easing > conversion > > - > > > the "big picture"). This is still sufficiently easy, but > it is a big > > > departure from the "let's standardize what is used in practice" > > > approach. I fear that discussing a better framing/session > management > > > again takes up a lot of time and includes a high risk of > missing our > > > milestones again. BTW: we are scheduled to deliver by > > > November 2006, and > > > I do not expect that we will be granted an extension this time > > again. > > > November will be very soon, especially looking at the > summer break. > > > > > > So I propose that we do NOT enter any new discussion. We > > > should deliver > > > either a) or b) (above), without introducing any new features > > > or ideas. > > > That means that the result will be sub-optimal. But > > > delivering something > > > usable is much better than aiming for the perfect one that will > > never > > > appear. > > > > > > Once we have delivered, we should discuss what to do next > (but only > > > AFTER delivery). I have to admit that I now see some good > points in > > a > > > -transport-ssh and consider it implementable with > reasonable effort. > > > However, -transport-ssh should be done after we have reconsidered > > the > > > framing. Given the track record of this WG, I would suspect > > > this can not > > > be done in less than 12 to 24 month. There are also the > issues that > > > Anton brought up and the general question on > configuration and event > > > data models for syslog. A lot of useful work lying ahead (but > > > depending > > > on our ability to finish the base stuff first). > > > > > > I think this work can never be done if this WG fails. So I am > > > desperately trying to get us to publish. I think what we have > > > is useful > > > and well-enough. If we do not publish soon, we will never > be able to > > > publish at all. IMHO, we have already received our third > chance and > > > there will be no fourth... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Thursday, June 29, 2006 8:32 PM > > > > To: Rainer Gerhards; 'Chris Lonvick'; syslog@ietf.org > > > > Subject: RE: [Syslog] Decisions to make about the > Huawei IPR claim > > > > > > > > Hi Rainer, > > > > > > > > [speaking as a contributor] > > > > > > > > This WG needs to deliver documents soon or the WG could > be closed. > > > > > > We need to deliver a secure transport solution. > > > > If the WG decides to do a 3195bis as the secure transport > > > solution, I > > > > recommend the short-term deliverable be "good enough" > to work with > > > > syslog-protocol. That way we can get 3195bis AND the other > > documents > > > > (-protocol- and -udp-) published and onto the standards > > > track, so the > > > > industry can begin to implement, and the WG can stay open to do > > > > additional work. > > > > > > > > Then we can address whether the 3195 design should be > modified in > > > > other ways. There have been suggestions to modify 3195 to > > > "harmonize" > > > > with the work of other Standards Development > Organizations such as > > > > OASIS and W3C. Doing that work would likely not be > quick or easy. > > I > > > > fear it would be a real rathole that would prevent us > > > getting 3195bis > > > > published at all, and if 3195bis is the WG's choice as > the secure > > > > transport protocol, then that rathole would also prevent the > > > > publication of -protocol- and -udp- on a timely basis. > > > > > > > > As a 14-year veteran of IETF WG efforts, I think it would > > > be a bad WG > > > > decision to put 3195bis on the critical path and to > open it up to > > a > > > > rathole discussion. If 3195bis is on the critical path, > we need to > > > > avoid the rathole discussion for now; it can be considered for a > > > > future "release". If the WG feels the rathole > discussion is really > > > > necessary, and 3195bis should not be done without > having had such > > a > > > > possible-rathole discussion, then 3195bis should not be > put on the > > > > critical path. > > > > > > > > My $.02 > > > > David Harrington > > > > ietfdbh@comcast.net > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > > > Sent: Thursday, June 29, 2006 5:11 AM > > > > > To: Chris Lonvick; syslog@ietf.org > > > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR > > claim > > > > > > > > > > Besides the somewhat political issue, I think there is also > > > > technical > > > > > issue that affects the question. I think we should > consider that > > > > > question in parallel to the IPR question. > > > > > > > > > > This question is if this WG intends to do a revision of 3195. > > And, > > > > if > > > > > so, I think the very close next question is if we > "just" update > > it > > > > to > > > > > support syslog-protocol or if we intend to make any > > > > > substantial changes. > > > > > > > > > > I see a relationship between the IPR and the 3195bis issue > > because > > > > > 3195bis modifies the "cost" of finding alternate solutions. > > Coming > > > > to > > > > > this point, it would probably be helpful if we could actually > > > > > weigh cost > > > > > vs. utlity of the different approaches. IPR, IMHO, is just a > > cost, > > > > > obviously one whose weight we need to decide on. But > I think it > > is > > > > not > > > > > the only cost. If the WG finds such a "cost vs. utility" > > > discussion > > > > > useful, I could document my point of view as a > starting point. I > > > > > volunteer to create a summary document (a public web > page, not a > > > > I-D) > > > > > where I track all contributions to this discussion (for an > > example > > > > of > > > > > what I have in mind see Juergen Schoenwaelder's page > on netconf > > > > > notification requirements: > > > > > > > > > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > > > > > > > > > I would find such a page very helpful. It documents the > > > > > decision process > > > > > and the decision criteria. In doing that, it helps us > come to a > > > > better > > > > > decison because we than have all facts at a single place. > > > > > Thus, it also > > > > > provides good argument when dealing with the IESG (in the case > > we > > > > need > > > > > to justify the decision). > > > > > > > > > > Thanks, > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > > > To: syslog@ietf.org > > > > > > Subject: [Syslog] Decisions to make about the > Huawei IPR claim > > > > > > > > > > > > Hi Folks, > > > > > > > > > > > > It's looking like we have a primary decision to make about > > > > > > the IPR claim > > > > > > that Huawei has made on syslog-transport-tls. First and > > > > > > foremost, I want > > > > > > everyone to be informed of the IETF stand on IPR claims and > > > > > > on the IETF > > > > > > process that we will follow. > > > > > > > > > > > > This is the position of the IETF on IPR claims: > > > > > > > -------------------------------------------------------------- > > > > > > ----------- > > > > > > 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. > > > > > > > -------------------------------------------------------------- > > > > > > ----------- > > > > > > This is at the bottom of all RFCs. It's pretty > clear that we > > > > > > (our Working > > > > > > Group) has no place to appeal claims of IPR to. > > > > > > > > > > > > Also, the more detailed explanation of the IETF position is > > > > > in BCP 79: > > > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > > > I will ask that everyone read through this before > > > expressing their > > > > > > > > > > opinion. > > > > > > > > > > > > One additional source of information for our process is > > > RFC 3669: > > > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > > > "Guidelines for Working Groups on Intellectual Property > > Issues" > > > > > > > -------------------------------------------------------------- > > > > > > ----------- > > > > > > 1. Introduction > > > > > > > > > > > > This memo lays out a conceptual framework and rules of > > thumb > > > > to > > > > > > assist working groups dealing with IPR issues. The > > > goal is to > > > > > > achieve a balance between the needs of IPR claimants and > > the > > > > > > implementers of IETF standards which is appropriate to > > > > > > current times. > > > > > > As part of trying to distill out principles for dealing > > > > > > with IPR in > > > > > > IETF working groups, it provides case studies of > > > > > working group IPR > > > > > > treatment. In other words, it documents the > running code > > > > > > of the IETF > > > > > > process. > > > > > > > > > > > > This memo does not describe IPR procedures for document > > > > > authors or > > > > > > IPR claimants. Those are covered in two other > memos, on > > > > > > submission > > > > > > rights [5] and IPR in the IETF [6]. Rather, > this memo is > > > > > > for working > > > > > > groups that are trying to decide what to do about > > technology > > > > > > contributions which have associated IPR claims. > > > > > > > -------------------------------------------------------------- > > > > > > ----------- > > > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > > > This document contains a lot of really good advice that we > > > > > > should be aware > > > > > > of while we make our decision. > > > > > > > > > > > > One part of RFC 3669 is a recommendation to take a critical > > > > > > look at the > > > > > > terms of the claim - Section 5.6. Essentially, if > we can get > > > > > > consensus > > > > > > that the terms are acceptable for implementation, then the > > > > > > IPR claim may > > > > > > not be an issue - we can continue to progress > > > > > > syslog-transport-tls. On > > > > > > the other hand, if the terms are not acceptable > then we can't > > > > > > expect any > > > > > > implementations. > > > > > > > > > > > > I'm going to ask that everyone please start > considering these > > > > > > inputs and > > > > > > openly discuss your thoughts about the IETF process and the > > > > options > > > > > > available to our Working Group on the mailing list. > > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > > Do not declare your opinion yet. > > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > > In a week or so I will ask the group to decide how > we should > > > > > > process. I > > > > > > want everyone to take the time now to get > acquainted with the > > > > > > process and > > > > > > the information that we have available to us. > > > > > > > > > > > > I believe that ultimately, we will need to decide > on whether > > > > > > to continue > > > > > > to progress syslog-transport-tls, or if we will want to > > > > > > accept a different > > > > > > path. If we start down a new path, then we will still need > > > > > > to make sure > > > > > > that we are meeting the security objectives that we > feel are > > > > > > important. > > > > > > This discussion has already been started, which is good in > > > > > that it can > > > > > > bringing to light some of the issues that need to be > > > > > > discussed around the > > > > > > secure transport of syslog. Once we get this primary issue > > > > > > resolved then > > > > > > we can decide upon that. > > > > > > > > > > > > Also, the Milestone about delivering a TLS solution can be > > > > > > easily changed. > > > > > > I did submit it that way to the IESG and Tom Petch > noted that > > > > > > the Charter > > > > > > just said "security" protocol while the Goal specified > > > a specific > > > > > > solution. Sam didn't want to change it after it had gone > > > > > in but I'm > > > > > > certain that it's not going to be a problem if we > do want to > > > > > > change it. > > > > > > > > > > > > Thanks, > > > > > > Chris > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 Wed Jul 05 05:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy3kh-0000xQ-Fk; Wed, 05 Jul 2006 05:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy3kg-0000xL-FU for syslog@ietf.org; Wed, 05 Jul 2006 05:32:58 -0400 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy3kf-0007jx-5p for syslog@ietf.org; Wed, 05 Jul 2006 05:32:58 -0400 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id B71424C043 for ; Wed, 5 Jul 2006 11:32:55 +0200 (CEST) Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim From: Balazs Scheidler To: Darren Reed In-Reply-To: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> References: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> Content-Type: text/plain Date: Wed, 05 Jul 2006 11:32:54 +0200 Message-Id: <1152091974.6196.10.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@ietf.org 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 On Tue, 2006-07-04 at 05:27 +1000, Darren Reed wrote: > Chris, > > The approach I'd like to take is to see what Balazs Scheidler can > come up with, that is different to the proposed approach, to make > syslog function over a TLS transport in syslog-ng and look at turning > that into an i-d. > > While it may not guarantee us any better situation with respect to > patents, etc, I have more faith working on documenting something > that is written to be open and free than involving people who have > a financial interest in the protocol going in certain diretions. > > I suppose this is a get working code first and then refine/ > document it. Sorry, for being absent from the group for a couple of weeks, I was getting married and it took some time and distracted a bit from my work. But I'm back again. About the proposal. Thanks Darren, I'm honored. However, I'm not sure this is a very good idea. I was really pondering with the idea of implementing something in syslog-ng that works now and avoid waiting for the results of this group indefinitely. However I don't think this would respect the work of this group, and probably what I'd come up with would not be that different from what was defined here so far, especially as I was trying to be involved in the discussion. RFC3195bis is a nice idea, even though I previously disliked that protocol myself. I'll have to reread that RFC to form my opinion. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 05 12:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyA6R-0007nJ-7Z; Wed, 05 Jul 2006 12:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9wt-00073c-2q for syslog@ietf.org; Wed, 05 Jul 2006 12:09:59 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9wp-0007lo-KX for syslog@ietf.org; Wed, 05 Jul 2006 12:09:59 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060705160952m1100i6528e>; Wed, 5 Jul 2006 16:09:52 +0000 From: "David Harrington" To: Date: Wed, 5 Jul 2006 12:08:39 -0400 Message-ID: <004f01c6a04d$4777b030$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0050_01C6A02B.C0661030" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcagP+ZuhlOcFvbaTUWPULYFwv/CegADLyPQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ac741ff89468ff514aee0fdec571438 X-Mailman-Approved-At: Wed, 05 Jul 2006 12:19:49 -0400 Cc: Subject: [Syslog] FW: Initial Logging capabiltiies document 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 This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C6A02B.C0661030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI. -----Original Message----- From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of patrick cain Sent: Wednesday, July 05, 2006 10:33 AM To: opsec@ops.ietf.org Subject: Initial Logging capabiltiies document Hi, I promised to get out a version of the logging capabiltiies document. Since I missed the initial draft cutoff date, I spent some extra time flushing it out. And it is attached. It will go to the IETF repository as soon as it re-opens. Please advise me of correction, complaints, and aditions, and feel free to spam it others you may know who are into logging. I asked for agenda time at the Montreal OPSEC meeting, but I don't think this one needs much presenting. Pat Cain ------=_NextPart_000_0050_01C6A02B.C0661030 Content-Type: text/plain; name="draft-cain-logging-caps-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-cain-logging-caps-00.txt" =0A= =0A= =0A= OPSEC P. Cain=0A= Internet-Draft The Cooper-Cain Group, Inc.=0A= Expires: December 28, 2006 June 26, 2006=0A= =0A= =0A= Logging Capabilities for IP Network Infrastructure=0A= draft-cain-logging-caps-00=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on December 28, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document lists logging capabilities needed to support the=0A= current practices described in Operational Security Current Practices=0A= [CURPRAC] and logical enhancements to those practices if the=0A= capability existed. Logging is defined as the delivery to another=0A= entity or system of messages about the device, the data passing=0A= through the device, or the device's interaction with another device.=0A= =0A= Capabilities are defined without reference to specific technologies.=0A= This is done to leave room for deployment of new technologies that=0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 1]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= implement the capability. Each capability cites the practices it=0A= supports. Current implementations that support the capability are=0A= cited. Special considerations are discussed as appropriate listing=0A= operational and resource constraints, limitations of current=0A= implementations, trade offs, etc.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.2. Capabilities or Requirements ? . . . . . . . . . . . . . . 3=0A= 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2. Functional Capabilities of Log Generating Systems . . . . . . 5=0A= 2.1. Logging Facility Uses Protocols Subject To Open Review . . 5=0A= 2.2. Logs Sent To Remote Servers . . . . . . . . . . . . . . . 6=0A= 2.3. Ability to Select Reliable Delivery . . . . . . . . . . . 6=0A= 2.4. Ability to Remotely Log Securely . . . . . . . . . . . . . 7=0A= 2.5. Ability to Log Locally . . . . . . . . . . . . . . . . . . 8=0A= 2.6. Ability to Log Different Severities to Different=0A= Destinations . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 2.7. Ability to Log to Multiple Destinations . . . . . . . . . 10=0A= 2.8. Ability to Maintain Accurate System Time . . . . . . . . . 11=0A= 2.9. Display Timezone And UTC Offset . . . . . . . . . . . . . 12=0A= 2.10. Default Timezone Should Be UTC . . . . . . . . . . . . . . 13=0A= 2.11. Log Entries Must Be Timestamped . . . . . . . . . . . . . 13=0A= 2.12. Log on Exception or Identifed Event . . . . . . . . . . . 14=0A= 2.13. Logs Contain Untranslated IP Addresses . . . . . . . . . . 15=0A= 2.14. Logs Contain Records Of Security Events . . . . . . . . . 16=0A= 2.15. Logs Do Not Contain Passwords . . . . . . . . . . . . . . 17=0A= 2.16. Devices Should Log Every Message . . . . . . . . . . . . . 18=0A= 2.17. Syslog-specific Capabilties . . . . . . . . . . . . . . . 19=0A= 2.17.1. Configurable Facility Values . . . . . . . . . . . . 19=0A= 2.17.2. Configurable Destination TCP Port . . . . . . . . . . 19=0A= 3. Functional Capabilities of Log Storage Systems . . . . . . . . 21=0A= 3.1. Configurable Retention Period . . . . . . . . . . . . . . 21=0A= 3.2. Ability to Compress Log Data Before Storage . . . . . . . 21=0A= 4. Additional Operational Practices . . . . . . . . . . . . . . . 23=0A= 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25=0A= 7. Normative References . . . . . . . . . . . . . . . . . . . . . 25=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 27=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 2]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= The Framework for Operational Security Capabilities [FRMWK] outlines=0A= the proposed effort of the IETF OPSEC working group. This includes=0A= producing a series of drafts to codify knowledge gained through=0A= operational experience about feature sets that are needed to securely=0A= deploy and operate managed network elements providing transit=0A= services at the data link and IP layers. Current plans include=0A= separate capabilities documents for Packet Filtering; Event Logging;=0A= In-Band and Out-of-Band Management; Configuration and Management=0A= Interfaces; AAA; and Documentation and Assurance. [CURPRAC] defines=0A= the goals, motivation, scope, definitions, intended audience, threat=0A= model, potential attacks and give justifications for each of the=0A= practices.=0A= =0A= 1.1. Threat Model=0A= =0A= The logging capabilities are derived from real world observations=0A= where unexpected activities in a network infrastructure caused=0A= concern to the network operator. Examples of such activities are:=0A= =0A= An adversary or unauthorized user login into an infrastructure=0A= device. The risk is that the configuration or other operating=0A= parameter could be modified.=0A= =0A= A device becomes overwhelmed, throttles, or crashes. An unaware=0A= operator cannot return the device to optimal operating conditions=0A= =0A= Network problems cannot be properly diagnosed without information.=0A= Information does not exist unless generated=0A= =0A= Threats to the network devices may be classified into broad=0A= categories such as the device status or configuration is modified=0A= without notice by the network operator, captured data traffic or=0A= notification messages from the device are intercepted by a third=0A= party, or logging data may not be properly stored rendering forensic=0A= activity worthless.=0A= =0A= The main technical issues revolve around what events generate a log=0A= entry, how long are logs retained and what mechanisms are used to=0A= secure the logged information while it is in transit and while it is=0A= stored. A good overview of building and operating a log=0A= infrastructure can be found in NIST Publication 800-62 [SP800-92]=0A= =0A= 1.2. Capabilities or Requirements ?=0A= =0A= Capabilities may or may not be requirements. That is a local=0A= determination that must be made by each operator with reference to=0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 3]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= the policies that they must support. This document, together with=0A= [CURPRAC] will assist network operators in identifying their security=0A= capability requirements and communicating them clearly to vendors.=0A= =0A= 1.3. Format=0A= =0A= Each capability has the following subsections:=0A= =0A= o Capability (what)=0A= =0A= o Discussion=0A= =0A= o Supported Practices (why)=0A= =0A= o Current Implementations (how)=0A= =0A= o Considerations (caveats, resource issues, protocol issues, etc.)=0A= =0A= The Capability section describes a feature to be supported by the=0A= device. The Supported Practice section cites practices described in=0A= [CURPRAC] that are supported by this capability. The Current=0A= Implementation section is intended to give examples of=0A= implementations of the capability, citing technology and standards=0A= current at the time of writing. It is expected that the choice of=0A= features to implement the capabilities will change over time. The=0A= Considerations section lists operational and resource constraints,=0A= limitations of current implementations, trade offs, etc.=0A= =0A= 1.4. Definitions=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= The use of the RFC 2119 keywords is an attempt, by the author, to=0A= assign an expectation level ("MUST", "SHOULD", "MAY") to the each=0A= capability. It must be noted that different organizations,=0A= operational environments, policies and legal environments will=0A= generate different requirement levels.=0A= =0A= NOTE: This document defines capabilities. This document does not=0A= define requirements, and there is no requirement that any particular=0A= capability be implemented or deployed. The use of the terms MUST,=0A= SHOULD, and so on are in the context of each capability in the sense=0A= that if you conform to any particular capability then you MUST or=0A= SHOULD do what is specified for that capability, but there is no=0A= requirement that you actually do conform to any particular=0A= capability.=0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 4]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 2. Functional Capabilities of Log Generating Systems=0A= =0A= The capabilities in this section are intended to list testable,=0A= functional capabilities that are needed to operate devices securely=0A= and meet the obligations of Section Threat Model.=0A= =0A= 2.1. Logging Facility Uses Protocols Subject To Open Review=0A= =0A= Capability=0A= =0A= The device MUST provide a logging facility that is based on=0A= protocols subject to open review. Custom or proprietary logging=0A= protocols MAY be implemented provided the same information is made=0A= available.=0A= =0A= Discussion=0A= =0A= The use of logging based on protocols subject to open review=0A= permits the operator to perform archival and analysis of logs=0A= without relying on vendor-supplied software and servers. .=0A= =0A= =0A= Supported Practices.=0A= =0A= * syslog=0A= =0A= * syslog with reliable delivery=0A= =0A= =0A= Current Implementations=0A= =0A= This capability can be satisfied by the use of one or more of=0A= syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+=0A= [RFC1492] or RADIUS [RFC2865].=0A= =0A= The current best solution seems to be the following:=0A= =0A= * Implement syslog [RFC3164].=0A= =0A= * Consider implementing syslog with reliable delivery [RFC3195].=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 5]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 2.2. Logs Sent To Remote Servers=0A= =0A= Capability=0A= =0A= The device MUST support transmission of records of security=0A= related events to one or more remote collection devices. There=0A= MUST be configuration settings on the device that allow selection=0A= of destination servers.=0A= =0A= Discussion=0A= =0A= None.=0A= =0A= =0A= Supported Practices=0A= =0A= * Use multiple collection devices to enhance reliability.=0A= =0A= * Use different collection devices to segregate different event=0A= sensitivity levels.=0A= =0A= =0A= Current Implementations=0A= =0A= This capability may be satisfied by the use of one or more of:=0A= syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+=0A= [RFC1492], or RADIUS [RFC2865].=0A= =0A= =0A= Considerations=0A= =0A= This is important because it supports individual accountability.=0A= It is important to store them on a separate server to preserve=0A= them in case of failure or compromise of the managed device.=0A= =0A= Note that there may be privacy or legal considerations when=0A= logging/monitoring user activity.=0A= =0A= High volumes of logging may generate excessive network traffic=0A= and/or compete for scarce memory and CPU resources on the device.=0A= =0A= =0A= 2.3. Ability to Select Reliable Delivery=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 6]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Capability=0A= =0A= It SHOULD be possible to select reliable delivery of log messages.=0A= =0A= Discussion=0A= =0A= Reliable delivery is important to the extent that log data is=0A= depended upon to make operational decisions and forensic analysis.=0A= Without reliable delivery, log data becomes a collection of hints=0A= instead of a true record of events.=0A= =0A= =0A= Supported Practices=0A= =0A= * Use syslog-ng.=0A= =0A= * Tunnel the logging stream over a TCP-based connection.=0A= =0A= * Use an out-of-band network to connect critical logging devices=0A= to the collection device.=0A= =0A= =0A= Current Implementations=0A= =0A= One example of reliable syslog delivery is defined in [RFC3195].=0A= Syslog-ng provides another example, although the protocol has not=0A= been standardized=0A= =0A= =0A= Considerations=0A= =0A= Reliable delivery should be used if the path from log event=0A= generator to the collection device transits administrative domains=0A= or uses unreliable channels, as it is important that the entire=0A= stream of leg events is captured.=0A= =0A= =0A= 2.4. Ability to Remotely Log Securely=0A= =0A= Capability=0A= =0A= The log data stream SHOULD be able to be delivered to the=0A= collection device in a confidential manner.=0A= =0A= Discussion=0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 7]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= While syslog *could* provide this capability, it has many security=0A= issues and by itself does not address issues from the threat=0A= model. See the security considerations section of [RFC3164] for a=0A= list of issues. Syslog with reliable delivery provides solutions=0A= to most/all of these issues, however at the time of this writing=0A= there are few implementations. Other possible solutions might be=0A= to tunnel syslog over a secure transport...but this often raises=0A= difficult key management and scalability issues.=0A= =0A= =0A= Supported Practices=0A= =0A= * Log data tunnelled within IPSec or SSH.=0A= =0A= * Use syslog-ng.=0A= =0A= =0A= Current Implementations=0A= =0A= There is no common implementation of this capability.=0A= =0A= =0A= Considerations=0A= =0A= As is the reliable delivery capability, delivering log data across=0A= untrusted streams or including sensitive data in a event data may=0A= require additional countermeasures to protect the data. This=0A= concern should not be addressed lightly.=0A= =0A= ISPs are fully aware that there is no security with syslog but=0A= IPSec is considered too operationally expensive and cumbersome to=0A= deploy. Syslog-ng and stunnel could be used for better=0A= authentication and integrity protected solutions. Mechanisms to=0A= prevent unauthorized personnel from tampering with logs is=0A= constrained to auditing who has access to the logging servers and=0A= files.=0A= =0A= =0A= 2.5. Ability to Log Locally=0A= =0A= Capability=0A= =0A= It SHOULD be possible to log locally on the device itself. Local=0A= logging SHOULD be written to non-volatile storage. .=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 8]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Discussion=0A= =0A= Logging of failed authentication attempts to local non-volatile=0A= storage is critical as it provides a record of events if the=0A= device gets isolated from its authentication interfaces or an=0A= attack overwhelms the console interface. Local logging is also=0A= important for viewing information when connected to the device and=0A= it provides some backup of log data in case remote logging fails.=0A= =0A= Local logging also provides a way to quickly view logs relevant to=0A= one device without having to sort through a possibly large set of=0A= logs from other devices at the collection device.=0A= =0A= =0A= Supported Practices=0A= =0A= * To conserve space, only failed device logins and network=0A= connectivity issues are logged locally.=0A= =0A= =0A= Current Implementations=0A= =0A= =0A= =0A= One example of local logging would be a memory buffer that=0A= receives copies of messages sent to the remote log server.=0A= =0A= Another example might be a local syslog server (assuming the=0A= device is capable of running syslog and has some local=0A= storage).=0A= =0A= =0A= =0A= Considerations=0A= =0A= Storage on the device may be limited.; high volumes of log=0A= messages may quickly fill the available storage, in which case=0A= there are two options: new logs overwrite old logs (possibly via=0A= the use of a circular memory buffer or log file rotation), or=0A= logging stops.=0A= =0A= =0A= 2.6. Ability to Log Different Severities to Different Destinations=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 9]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Capability=0A= =0A= The device SHOULD allow specified severity levels of log message=0A= to be delivered to different collection destinations.=0A= =0A= Discussion=0A= =0A= A network of multiple devices may generate a significant amount of=0A= log data. The ability to send critical log messages, for example=0A= a root login, to a specific destination device will enhance the=0A= ability of the network operator to notice the critical event.=0A= =0A= =0A= Supported Practices=0A= =0A= * Email critical event notices to a 24-hour watched mailbox.=0A= =0A= * Send critical event notices to a separate log collector that=0A= scrolls received messages upon a large display in the NOC.=0A= =0A= =0A= Current Implementations=0A= =0A= There are no common implementations of this capability.=0A= =0A= =0A= Considerations=0A= =0A= The use of multiple collectors will incur maintenance and=0A= reliability issues. In some cases, multiple filters watching a=0A= single collection point may be more efficient than using multiple=0A= collectors.=0A= =0A= =0A= 2.7. Ability to Log to Multiple Destinations=0A= =0A= Capability=0A= =0A= The device SHOULD allow log message to be delivered to multiple=0A= collection destinations.=0A= =0A= Discussion=0A= =0A= All ISPs have multiple syslog servers - some ISPs choose to use=0A= separate syslog servers for varying infrastructure devices (i.e.,=0A= one syslog server for backbone routers, one syslog server for=0A= customer edge routers, etc.) This provides a backup mechanism to=0A= see what is going on in the network in the event that a device may=0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 10]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 'forget' to do syslog if the CPU is busy.=0A= =0A= =0A= Supported Practices=0A= =0A= * Use multiple log servers to enhance reliability.=0A= =0A= =0A= Current Implementations=0A= =0A= Most ISPs use multiple, sometimes gegraphic-driven, log=0A= collectors.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= 2.8. Ability to Maintain Accurate System Time=0A= =0A= Capability=0A= =0A= The device MUST maintain accurate, "high resolution" system time.=0A= =0A= Discussion=0A= =0A= Accurate time is important to the generation of reliable log data.=0A= Accurate time is also important to the correct operation of some=0A= authentication mechanisms.=0A= =0A= The ability to correlate network events from different devices is=0A= directly related to the accuracy of the log timestamps. If a=0A= timeline cannot be constructed, the event logs and forensic data=0A= is useless.=0A= =0A= =0A= Supported Practices=0A= =0A= * The time is derived from NTP which is generally configured as a=0A= flat hierarchy at stratum1 and stratum2 servers to have less=0A= configuration and less maintenance issues.=0A= =0A= * Each router is configured with one stratum1 peer both locally=0A= and remotely.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 11]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Current Implementations=0A= =0A= This capability may be satisfied by supporting Network Time=0A= Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct=0A= connection to an accurate time source.=0A= =0A= =0A= Considerations=0A= =0A= System clock chips are inaccurate to varying degrees. System time=0A= should not be relied upon unless it is regularly checked and=0A= synchronized with a known, accurate external time source (such as=0A= an NTP stratum-1 server). Also note that if network time=0A= synchronization is used, an attacker may be able to manipulate the=0A= clock unless cryptographic authentication is used..=0A= =0A= =0A= 2.9. Display Timezone And UTC Offset=0A= =0A= Capability=0A= =0A= All displays and logs of system time MUST include a timezone or=0A= offset from UTC.=0A= =0A= Discussion=0A= =0A= None.=0A= =0A= =0A= Supported Practices=0A= =0A= * The log timestamps include a timezone indicator like "-05:00".=0A= =0A= =0A= Current Implementations=0A= =0A= =0A= =0A= =0A= Considerations=0A= =0A= Knowing the timezone or UTC offset makes correlation of data and=0A= coordination with data in other timezones possible. Bob is in=0A= Newfoundland, Canada which is UTC -3:30. Alice is somewhere in=0A= Indiana, USA. Some parts of Indiana switch to daylight savings=0A= time while others do not. A user on Bob's network attacks a user=0A= on Alice's network. Both are using logs with local timezones and=0A= no indication of UTC offset. Correlating these logs will be=0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 12]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= difficult and error prone. Including timezone, or better, UTC=0A= offset, eliminates these difficulties.=0A= =0A= Notice that a physical location may have different offsets from=0A= UTC during a year as summertime, daylight savings time, or other=0A= local customs are applied.=0A= =0A= =0A= 2.10. Default Timezone Should Be UTC=0A= =0A= Capability=0A= =0A= The default timezone for display and logging SHOULD be UTC. The=0A= device MAY support a mechanism to allow the operator to specify=0A= the display and logging of times in a timezone other than UTC.=0A= =0A= Discussion=0A= =0A= Knowing the timezone or UTC offset makes correlation of data and=0A= coordination with data in other timezones possible.=0A= =0A= Supported Practices=0A= =0A= * The timezone offset can be entered as part of configuration of=0A= a device.=0A= =0A= =0A= Implementation=0A= =0A= Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or=0A= UTC -6 depending on the time of year and exact county in Indiana)=0A= are working an incident together using their logs. Both left the=0A= default settings, which was UTC, so there was no translation of=0A= time necessary to correlate the logs.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= 2.11. Log Entries Must Be Timestamped=0A= =0A= Capability=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 13]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= By default, the device MUST timestamp all log messages. The=0A= timestamp MUST be accurate to within a second or less. The=0A= timestamp MUST include a timezone. There MAY be a mechanism to=0A= disable the generation of timestamps.=0A= =0A= Discussion=0A= =0A= Accurate timestamps are necessary for correlating events,=0A= particularly across multiple devices or with other organizations.=0A= This applies when it is necessary to analyze logs..=0A= =0A= =0A= Supported Practices=0A= =0A= * Each entry into the log contains a time value.=0A= =0A= =0A= Current Implementations=0A= =0A= This capability may be satisfied by writing timestamps into syslog=0A= messages.=0A= =0A= =0A= Considerations=0A= =0A= It is difficult to correlate logs from different time zones.=0A= Security events on the Internet often involve machines and logs=0A= from a variety of physical locations. For that reason, UTC is=0A= preferred, all other things being equal..=0A= =0A= =0A= 2.12. Log on Exception or Identifed Event=0A= =0A= Capability=0A= =0A= Log entries should be generated on exceptions (e.g., failures) or=0A= event matching (e.g., generate a log entry if an event happens)=0A= via a configurable value.=0A= =0A= Discussion=0A= =0A= Traditionally log events are generated on exceptions -- failures=0A= or errors. Many times this is not sufficient as a network=0A= operator cannot tell if an attacker failed to log into a device=0A= once, or failed once and then succeeded on the second try.=0A= Devices should be configurable to allow for log messages on=0A= failures, successes, or everything.=0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 14]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Supported Practices=0A= =0A= * Log all login events to a device but only have the collection=0A= device alert on failures.=0A= =0A= * Log on successful device configuration changes since one must=0A= be aware of all modifications on some types of devices.=0A= =0A= =0A= Current Implementations=0A= =0A= Some ISPs put in passive devices to see routing updates and=0A= withdrawals and not rely solely on the device for log files.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= 2.13. Logs Contain Untranslated IP Addresses=0A= =0A= Capability=0A= =0A= Log messages MUST NOT list translated addresses (DNS names)=0A= associated with the address without listing the untranslated IP=0A= address where the IP address is available to the device generating=0A= the log message.=0A= =0A= Discussion=0A= =0A= Although some times less obtuse than DNS names, IP address=0A= assignments tend to be more stable than DNS entries. If an=0A= operator is trying to correlate a historical event, the DNS name=0A= may have been changed from that used at the event. TO ease this=0A= confusion, the IP address of the source of the action that caused=0A= the log event should be retained in the log entry.=0A= =0A= =0A= Supported Practices=0A= =0A= * Include the source IP address in all log messages.=0A= =0A= * Although a corresponding DNS name is useful, DNS lookups can be=0A= slow and consume resources.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 15]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Current Implementations=0A= =0A= Most devices include the source IP in event logs=0A= =0A= =0A= Considerations=0A= =0A= A failed network login should generate a record with the source=0A= address of the login attempt, but the Source addresses may be=0A= spoofed. Network-based attacks often use spoofed source addresses=0A= so they should not be completely trusted unless verified by other=0A= means. Having accurate timestamps in the logs increases the=0A= chances that the use of an address can be correlated to an=0A= individual.=0A= =0A= =0A= 2.14. Logs Contain Records Of Security Events=0A= =0A= Capability=0A= =0A= The device MUST be able to send a record of at least the following=0A= events: * authentication successes, * authentication failures, *=0A= session Termination, * authorization changes, * configuration=0A= changes, * device status changes.=0A= =0A= The device SHOULD be able to send a record of all other security=0A= related events including filtering (or ACL) exceptions, routing=0A= protocol state changes, all device access (regardless of=0A= authentication success or failure), all commands issued to a=0A= device, and all routing events (boot-up/flaps).=0A= =0A= Discussion=0A= =0A= The main function of any of these log messages is to see what the=0A= device is doing as well as to try and ascertain what certain=0A= malicious attackers are trying to do.=0A= =0A= Typically the data logged will contain the source and destination=0A= IP addresses and layer 4 port numbers as well as a timestamp.=0A= =0A= =0A= Supported Practices=0A= =0A= * Examples of events recorded include: user logins, bad login=0A= attempts, logouts, user privilege level changes, individual=0A= configuration commands issued by users and system startup/=0A= shutdown events.=0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 16]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Current Implementations=0A= =0A= Most devices crudely support this capability.=0A= =0A= =0A= Considerations=0A= =0A= This list is far from complete. Note that there may be privacy or=0A= legal considerations when logging/monitoring user activity or=0A= personal information.=0A= =0A= This is an important capability because it supports individual=0A= accountability and auditing as well as forensics. See section=0A= 4.5.4.4 of .=0A= =0A= =0A= 2.15. Logs Do Not Contain Passwords=0A= =0A= Capability=0A= =0A= Passwords SHOULD be excluded, by default configuration, from all=0A= audit records, including records of successful or failed=0A= authentication attempts.=0A= =0A= Discussion=0A= =0A= A user may make small mistakes in entering a password such as=0A= using incorrect capitalization ("my password" vs. "My Password").=0A= Event logs are traditional disperse widely so unexpected events=0A= will be noticed. Unauthorized access to event logs that contain=0A= these mistakes may compromise more than just the network devices=0A= as most users do not have independent passwords for every system.=0A= =0A= =0A= Supported Practices=0A= =0A= * Login failure log messages include the failed username,=0A= timestamp, and source IP address, but not the password used.=0A= =0A= =0A= Current Implementations=0A= =0A= Access control and authorization requirements differ for=0A= accounting records (logs) and authorization databases (passwords).=0A= Logging passwords may grant unauthorized access to individuals=0A= with access to the logs. Logging failed passwords may also give=0A= hints about actual passwords. See section 4.5.4.4 of [RFC2196]=0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 17]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= =0A= =0A= =0A= Considerations=0A= =0A= There may be situations where it is appropriate/required to log=0A= passwords, such as when performing real-time attack analysis.=0A= Caution is advised in these rare circumstances.=0A= =0A= =0A= 2.16. Devices Should Log Every Message=0A= =0A= Capability=0A= =0A= Devices should be configurable to either log every event or to=0A= drop events due to congestion.=0A= =0A= Discussion=0A= =0A= Many devices implement logging as an afterthought with the device=0A= dropping log messages or failing to log critical events when the=0A= device is "busy". This behaviour makes forensic analysis=0A= difficult, if not impossible. Devices should be configurable to=0A= not drop log events at those operator-defined times when this=0A= behaviour s expected.=0A= =0A= =0A= Supported Practices=0A= =0A= * Use multiple logging devices and collectors to capture enough=0A= extra messages to be able to recreate a full log.=0A= =0A= =0A= Current Implementations=0A= =0A= Use multiple logging devices.=0A= =0A= =0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 18]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 2.17. Syslog-specific Capabilties=0A= =0A= The predominant logging mechanism within network infrastructures is=0A= BSD-syslog and its' variants. With such widespread uses, this=0A= section identifies capabilities specific to syslog.=0A= =0A= 2.17.1. Configurable Facility Values=0A= =0A= Capability=0A= =0A= The device SHOULD allow for the selection of the syslog facility=0A= number via configuration.=0A= =0A= Discussion=0A= =0A= A network operator may have many similar devices in their network.=0A= The ability to segregate different severity events by the=0A= strategic use of the syslog facility number is extremely useful.=0A= =0A= =0A= Supported Practices=0A= =0A= * Authentication log entries are marked at a different facility=0A= code to allow for easier segregation at the event collector.=0A= =0A= =0A= Current Implementations=0A= =0A= Some devices support this capability via a configuration variable.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= 2.17.2. Configurable Destination TCP Port=0A= =0A= Capability=0A= =0A= Devices should allow for the configuration of the destination=0A= syslog TCP port number.=0A= =0A= Discussion=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 19]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= In large logging environments, spreading the load amongst multiple=0A= receiving daemons is a useful optimization. This capability also=0A= allows to differentiate different device functions very easily,=0A= for example all backbone router log to port 512 and all access=0A= router log to port 513.=0A= =0A= =0A= Supported Practices=0A= =0A= * Send all backbone routers log to port 512 and all access router=0A= log to port 513.=0A= =0A= =0A= Current Implementations=0A= =0A= Some devices support this capability via a configuration variable.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 20]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 3. Functional Capabilities of Log Storage Systems=0A= =0A= Alongside the generation and transport of log messages, there are=0A= capabilities required at the collection device. This section=0A= identifies capabilities necessary for collection devices.=0A= =0A= 3.1. Configurable Retention Period=0A= =0A= Capability=0A= =0A= The collection device should retain log data for a configurable=0A= period before deletion. A collection device may also set a=0A= maximum size of retained log data and deleted the oldest data when=0A= new data arrives.=0A= =0A= Discussion=0A= =0A= Log messages may overwhelm even the largest storage media.=0A= Collection devices should retain log message for a set time period=0A= or until a set amount is collected and then purge the oldest data=0A= as new data is received.=0A= =0A= Supported Practices=0A= =0A= * Logs older than 60 days are automatically deleted via a cron=0A= job on log servers.=0A= =0A= =0A= Current Implementations=0A= =0A= Unknown.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= 3.2. Ability to Compress Log Data Before Storage=0A= =0A= Capability=0A= =0A= A collection device should be able to support the compressing of=0A= received log messages before storing them.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 21]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Discussion=0A= =0A= In collaboration with the previous capability, this capability=0A= allows the collection device to store the maximum amount of log=0A= data on a media.=0A= =0A= Supported Practices=0A= =0A= * None=0A= =0A= =0A= Current Implementations=0A= =0A= Log messages destined for archival storage are compressed before=0A= writing to CDRom.=0A= =0A= =0A= Considerations=0A= =0A= None.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 22]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 4. Additional Operational Practices=0A= =0A= This section describes practices not covered in [CURPRAC]. They are=0A= included here to provide justification for capabilities that=0A= reference them.=0A= =0A= This section will be populated from comments received on this=0A= internet-draft.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 23]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 5. Security Considerations=0A= =0A= Security capabilities of network devices is the subject matter of=0A= this entire memo. The capabilities listed cite practices in=0A= [CURPRAC] that they are intended to support. [CURPRAC] also defines=0A= the general threat model, practices, and lists justifications for=0A= each practice.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 24]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= There are no IANA actions required by this document.=0A= =0A= 7. Normative References=0A= =0A= [CURPRAC] Kaeo, M., "Operational Security Current Practices",=0A= May 2006.=0A= =0A= [FRMWK] Jones, G., Ed., "Framework for Operational Security=0A= Capabilities for IP Network Infrastructure,=0A= draft-ietf-opsec-framework-03 (work in progress)",=0A= October 2005, .=0A= =0A= [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called=0A= TACACS", RFC 1492, July 1993.=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,=0A= September 1997.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,=0A= August 2001.=0A= =0A= [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog",=0A= RFC 3195, November 2001.=0A= =0A= [SP800-92]=0A= Souppaya, M. and K. Kent, "Guide to Security Log=0A= Management", FIPS 800-92, April 2006.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 25]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Author's Address=0A= =0A= Patrick Cain=0A= The Cooper-Cain Group, Inc.=0A= P.O. Box 400992=0A= Cambridge, MA 02140=0A= U.S.A.=0A= =0A= Phone: +1 617-848-1950=0A= Email: pcain@coopercain.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 26]=0A= =0C=0A= Internet-Draft Logging Capabilities June 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Cain Expires December 28, 2006 [Page 27]=0A= =0C=0A= ------=_NextPart_000_0050_01C6A02B.C0661030 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_000_0050_01C6A02B.C0661030-- From syslog-bounces@lists.ietf.org Wed Jul 05 12:25:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyABv-0005qq-A3; Wed, 05 Jul 2006 12:25:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyABu-0005od-04 for syslog@ietf.org; Wed, 05 Jul 2006 12:25:30 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyABs-0008JZ-OF for syslog@ietf.org; Wed, 05 Jul 2006 12:25:29 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060705162526m120009tc5e>; Wed, 5 Jul 2006 16:25:27 +0000 From: "David B Harrington" To: Date: Wed, 5 Jul 2006 12:24:13 -0400 Message-ID: <006401c6a04f$74363d10$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcagTwJDGI8QF9OnTkuWJ4tJyiDaSQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.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 FYI. This document defines a MIB that, as part of its definition, manages syslog servers. I am the MIB Doctor for this document and would be interested in your comments. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-07 .txt David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 05 12:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAZA-0003uz-P5; Wed, 05 Jul 2006 12:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAZ9-0003uu-Qp for syslog@ietf.org; Wed, 05 Jul 2006 12:49:31 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAZ8-0001Eh-Hi for syslog@ietf.org; Wed, 05 Jul 2006 12:49:31 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2006 09:25:56 -0700 X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208"; a="1835354474:sNHT4483145954" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k65GPu3w025667; Wed, 5 Jul 2006 09:25:56 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k65GPtCV023389; Wed, 5 Jul 2006 09:25:56 -0700 (PDT) Date: Wed, 5 Jul 2006 09:25:55 -0700 (PDT) From: Chris Lonvick To: Darren Reed Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim In-Reply-To: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> Message-ID: References: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1284; t=1152116756; x=1152980756; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20Decisions=20to=20make=20about=20the=20Huawei=20IPR=20 claim; X=v=3Dcisco.com=3B=20h=3D2UeNiXRuQEiQz15WwS3a0DsgBbU=3D; b=RzxjtB/j3/GbJvBG+IOKFi9loQt3Zo4eigEp8n456jN6EhQH0huIBlINOk5LzpKd5oqD3KkK lgxeQYjkG/L0t6OBS9CERJxT83lwCzRRm93uCb+q6PVZl5FCyICobRpk; Authentication-Results: sj-dkim-1.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: syslog@ietf.org 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 Darren, There is no need for Bazsi to write a different i-d. draft-ietf-syslog-transport-tls is a Working Group document and the final revision must reflect WG consensus. If Bazsi (or anybody else) can propose changes to draft-ietf-syslog-transport-tls and the WG reaches consensus on the proposed changes, then the document will be revised to reflect that. Please check me if I'm wrong on this, but I think that the only changes between syslog-ng and what's in syslog-transport-tls are - framing, - changes to address the threat model (listed in our Charter). Thanks, Chris On Tue, 4 Jul 2006, Darren Reed wrote: > Chris, > > The approach I'd like to take is to see what Balazs Scheidler can > come up with, that is different to the proposed approach, to make > syslog function over a TLS transport in syslog-ng and look at turning > that into an i-d. > > While it may not guarantee us any better situation with respect to > patents, etc, I have more faith working on documenting something > that is written to be open and free than involving people who have > a financial interest in the protocol going in certain diretions. > > I suppose this is a get working code first and then refine/ > document it. > > Thoughts? > > Darren > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 05 12:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAeX-0004Gc-U7; Wed, 05 Jul 2006 12:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAeW-0004GX-P9 for syslog@ietf.org; Wed, 05 Jul 2006 12:55:04 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAeV-0001Pc-FQ for syslog@ietf.org; Wed, 05 Jul 2006 12:55:04 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k65GsxaP006710; Wed, 5 Jul 2006 10:55:00 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] draft-ietf-ipcdn-pktc-eventmess-07.txt Date: Wed, 5 Jul 2006 10:54:59 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Thread-Index: AcagTwJDGI8QF9OnTkuWJ4tJyiDaSQABDoKg From: "Jean-Francois Mule" To: "David B Harrington" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: enechamkin@broadcom.com, Sumanth Channabasappa , "Richard Woundy @ Comcast" , deketelaere@tComLabs.com 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 Good redirection David. Please copy the ID co-authors and the syslog list on any comments you have. Jean-Francois. =20 > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, July 05, 2006 10:24 AM > To: syslog@ietf.org > Subject: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt >=20 > FYI. > This document defines a MIB that, as part of its definition, manages > syslog servers. > I am the MIB Doctor for this document and would be interested in your > comments. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-07 > .txt >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=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 Wed Jul 05 13:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAwN-0008HO-Ok; Wed, 05 Jul 2006 13:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAwN-0008HD-1H for syslog@ietf.org; Wed, 05 Jul 2006 13:13:31 -0400 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAwL-0002jf-N5 for syslog@ietf.org; Wed, 05 Jul 2006 13:13:31 -0400 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 72A0D4C040 for ; Wed, 5 Jul 2006 19:13:28 +0200 (CEST) Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> Content-Type: text/plain Date: Wed, 05 Jul 2006 19:13:27 +0200 Message-Id: <1152119607.10476.0.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: syslog@ietf.org, Darren Reed 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 On Wed, 2006-07-05 at 09:25 -0700, Chris Lonvick wrote: > Hi Darren, > > There is no need for Bazsi to write a different i-d. > draft-ietf-syslog-transport-tls is a Working Group document and the > final revision must reflect WG consensus. > > If Bazsi (or anybody else) can propose changes to > draft-ietf-syslog-transport-tls and the WG reaches consensus on the > proposed changes, then the document will be revised to reflect that. > > Please check me if I'm wrong on this, but I think that the only changes > between syslog-ng and what's in syslog-transport-tls are > - framing, > - changes to address the threat model (listed in our Charter). > Yes, the changes are about as simple as that. syslog-ng currently uses EOL characters for record termination, and we agreed to using byte-counted records instead to permit any kind of character within the message. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 05 18:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFmg-00008P-Pg; Wed, 05 Jul 2006 18:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFmf-00008K-DU for syslog@ietf.org; Wed, 05 Jul 2006 18:23:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyFme-000427-0S for syslog@ietf.org; Wed, 05 Jul 2006 18:23:49 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2006 15:23:48 -0700 X-IronPort-AV: i="4.06,210,1149490800"; d="scan'208"; a="303379045:sNHT31318456" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k65MNlb1030734 for ; Wed, 5 Jul 2006 15:23:47 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k65MNlcM018204 for ; Wed, 5 Jul 2006 15:23:47 -0700 (PDT) Date: Wed, 5 Jul 2006 15:23:46 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1962; t=1152138227; x=1153002227; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Need=20your=20input=20on=20the=20Hauwei=20IPR=20claim; X=v=3Dcisco.com=3B=20h=3D2wgLMpwUGP1UY3Opw1lpGdDYHJY=3D; b=j7ROrUCk4WbCRpkwv0DOZq768/zEMjPxBbVe7MeR+EQ12Lccsr2ZJpMRjwuaP2niK3TtSFkD lNHsnH0FqoRuvAQYZqfiYp1IU6KAiCpJaNfn92bErl16R2Cg0Sq9Nj40; Authentication-Results: sj-dkim-8.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Syslog] Need your input on the Hauwei IPR claim 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, Everyone has now had a week to think about the IETF process on IPR claims. The first decision that we need to make is about the terms of the claim. I'd like to hear what people think about the terms that Huawei has presented. https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 Please keep in mind that we can (and should) proceed with syslog-transport-tls if the terms appear reasonable and you (as implementors) are willing to accept them. Let's keep this discussion focused. - We do not need a discussion of the terms. - We do not need any legal opinions. - We do not need a discussion of technical alternatives on this thread. >From that, I'd like to hear either: A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. or B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a Working Group document. I'll leave this open until the 19th (so people going to the IETF can catch their collective breaths and give a good opinion. If the consensus appears to be "A" then we can get straight back to work. If the consensus appears to be "B" then I will very briefly ask if there are changes to the terms that would make them acceptable. I'll only ask that if the consensus appears to be "B" so don't insert your opinions on that at this time. I'm (just barely) willing to ask that (once) of the Huawei lawyers but I feel that negotiating terms is not going to move us forward; it's likely to be a rat-hole discussion and I won't let us go down there. If the consensus remains "B" then we will likely move away from syslog-transport-tls. Where we move to will be a different discussion so please don't insert your opinion about that on this discussion thread. David has opened that discussion on a separate thread so you may discuss it on the list, but I'm not focused on that at this time. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 05 19:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGsY-0006xY-Ll; Wed, 05 Jul 2006 19:33:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGsX-0006wj-Ca for syslog@ietf.org; Wed, 05 Jul 2006 19:33:57 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyGsW-0004PY-Vo for syslog@ietf.org; Wed, 05 Jul 2006 19:33:57 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 05 Jul 2006 17:33:49 -0600 Message-Id: <44ABF7F4.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 05 Jul 2006 17:33:40 -0600 From: "John Calcote" To: "Chris Lonvick" , Subject: Re: [Syslog] Need your input on the Hauwei IPR claim References: In-Reply-To: Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: , Content-Type: multipart/mixed; boundary="===============1994503954==" Errors-To: syslog-bounces@lists.ietf.org --===============1994503954== Content-Type: multipart/alternative; boundary="=__Part88AD6D44.1__=" --=__Part88AD6D44.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I vote for A). I don't know how Huawei managed to get a patent on mapping an existing well-known protocol onto an existing well-known transport. Which concept did they patent - tunneling? But as you stated in your request, that's neither here nor there. It appears that their terms are reasonable. I say go ahead. John >>> Chris Lonvick 07/05/06 4:23 PM >>> Hi Folks, Everyone has now had a week to think about the IETF process on IPR claims. The first decision that we need to make is about the terms of the claim. I'd like to hear what people think about the terms that Huawei has presented. https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 Please keep in mind that we can (and should) proceed with syslog-transport-tls if the terms appear reasonable and you (as implementors) are willing to accept them. Let's keep this discussion focused. - We do not need a discussion of the terms. - We do not need any legal opinions. - We do not need a discussion of technical alternatives on this thread. >From that, I'd like to hear either: A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. or B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a Working Group document. I'll leave this open until the 19th (so people going to the IETF can catch their collective breaths and give a good opinion. If the consensus appears to be "A" then we can get straight back to work. If the consensus appears to be "B" then I will very briefly ask if there are changes to the terms that would make them acceptable. I'll only ask that if the consensus appears to be "B" so don't insert your opinions on that at this time. I'm (just barely) willing to ask that (once) of the Huawei lawyers but I feel that negotiating terms is not going to move us forward; it's likely to be a rat-hole discussion and I won't let us go down there. If the consensus remains "B" then we will likely move away from syslog-transport-tls. Where we move to will be a different discussion so please don't insert your opinion about that on this discussion thread. David has opened that discussion on a separate thread so you may discuss it on the list, but I'm not focused on that at this time. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --=__Part88AD6D44.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: HTML
I vote for A).
 
I don't know how Huawei managed to get a patent on mapping an existing well-known protocol onto an existing well-known transport. Which concept did they patent - tunneling? But as you stated in your request, that's neither here nor there. It appears that their terms are reasonable. I say go ahead.
 
John

>>> Chris Lonvick <clonvick@cisco.com> 07/05/06 4:23 PM >>>
Hi Folks,

Everyone has now had a week to think about the IETF process on IPR claims.
The first decision that we need to make is about the terms of the claim.
I'd like to hear what people think about the terms that Huawei has
presented.
   https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724

Please keep in mind that we can (and should) proceed with
syslog-transport-tls if the terms appear reasonable and you (as
implementors) are willing to accept them.  Let's keep this discussion
focused.
- We do not need a discussion of the terms.
- We do not need any legal opinions.
- We do not need a discussion of technical alternatives on this thread.

>From that, I'd like to hear either:

A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working
Group document.

or

B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a
Working Group document.

I'll leave this open until the 19th (so people going to the IETF can catch
their collective breaths and give a good opinion.

If the consensus appears to be "A" then we can get straight back to work.

If the consensus appears to be "B" then I will very briefly ask if there
are changes to the terms that would make them acceptable.  I'll only ask
that if the consensus appears to be "B" so don't insert your opinions on
that at this time.  I'm (just barely) willing to ask that (once) of the
Huawei lawyers but I feel that negotiating terms is not going to move us
forward; it's likely to be a rat-hole discussion and I won't let us go
down there.

If the consensus remains "B" then we will likely move away from
syslog-transport-tls.  Where we move to will be a different discussion so
please don't insert your opinion about that on this discussion thread.
David has opened that discussion on a separate thread so you may discuss
it on the list, but I'm not focused on that at this time.

Thanks,
Chris

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
--=__Part88AD6D44.1__=-- --===============1994503954== 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 --===============1994503954==-- From syslog-bounces@lists.ietf.org Thu Jul 06 05:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPpw-0006TF-AL; Thu, 06 Jul 2006 05:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPpu-0006TA-Qd for syslog@ietf.org; Thu, 06 Jul 2006 05:07:50 -0400 Received: from gmpea-pix-1.sun.com ([192.18.1.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPpt-0006AH-FB for syslog@ietf.org; Thu, 06 Jul 2006 05:07:50 -0400 Received: from d1-emea-03.sun.com (d1-emea-03.sun.com [192.18.2.113] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6697m56008442 for ; Thu, 6 Jul 2006 10:07:48 +0100 (BST) Received: from conversion-daemon.d1-emea-03.sun.com by d1-emea-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J1Z00E0153HXK00@d1-emea-03.sun.com> (original mail from Darren.Moffat@Sun.COM) for syslog@ietf.org; Thu, 06 Jul 2006 10:07:48 +0100 (BST) Received: from [129.156.173.199] by d1-emea-03.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1Z006255D0WI10@d1-emea-03.sun.com> for syslog@ietf.org; Thu, 06 Jul 2006 10:07:48 +0100 (BST) Date: Thu, 06 Jul 2006 10:07:48 +0100 From: Darren J Moffat Subject: Re: [Syslog] Need your input on the Hauwei IPR claim In-reply-to: To: syslog@ietf.org Message-id: <44ACD2E4.3060702@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: User-Agent: Mail/News 1.5.0.2 (X11/20060603) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 The terms are not acceptable to me as written. For the record but as Chris requested not for discussion, it is this part that concerns me most: "and Huawei retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard." -- Darren J Moffat _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 05:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPsd-0007I6-TT; Thu, 06 Jul 2006 05:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyPsc-0007I1-Ts for syslog@ietf.org; Thu, 06 Jul 2006 05:10:38 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyPsb-0006cE-ID for syslog@ietf.org; Thu, 06 Jul 2006 05:10:38 -0400 Received: from pc6 (1Cust108.tnt106.lnd4.gbr.da.uu.net [213.116.60.108]) by astro.systems.pipex.net (Postfix) with SMTP id 924A7E0002C3; Thu, 6 Jul 2006 10:10:35 +0100 (BST) Message-ID: <003601c6a0d3$10be7a20$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" References: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim Date: Thu, 6 Jul 2006 09:56:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Darren Reed" Cc: Sent: Wednesday, July 05, 2006 6:25 PM Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim > Hi Darren, > > There is no need for Bazsi to write a different i-d. > draft-ietf-syslog-transport-tls is a Working Group document and the > final revision must reflect WG consensus. > I think that draft-ietf-syslog-transport-tls is seriously flawed and I have already made some comments on this, have others pending. But I am now reluctant to make any constructive suggestions lest my text be slightly modified, incorporated into this I-D and then made subject to an IPR claim. I believe we need a new document, or at least a new editor who is prepared to rewrite everything. I am not saying it should be that of Bazsi, just anyone who does not have H*** in their e-mail address. Tom Petch > If Bazsi (or anybody else) can propose changes to > draft-ietf-syslog-transport-tls and the WG reaches consensus on the > proposed changes, then the document will be revised to reflect that. > > Please check me if I'm wrong on this, but I think that the only changes > between syslog-ng and what's in syslog-transport-tls are > - framing, > - changes to address the threat model (listed in our Charter). > > Thanks, > Chris > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 06:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQhD-0004yI-P7; Thu, 06 Jul 2006 06:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyQhC-0004y0-HI for syslog@ietf.org; Thu, 06 Jul 2006 06:02:54 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyQhC-0002ao-19 for syslog@ietf.org; Thu, 06 Jul 2006 06:02:54 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5F0BC27C065; Thu, 6 Jul 2006 11:58:42 +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 02335-05; Thu, 6 Jul 2006 11:58:42 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0F5FD27C061; Thu, 6 Jul 2006 11:58:41 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 12:02:51 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jul 2006 12:02:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174B5A@grfint2.intern.adiscon.com> In-Reply-To: <003601c6a0d3$10be7a20$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Decisions to make about the Huawei IPR claim Thread-Index: Acag3BA2mSuI4xYFTS6JSt27ExsVHAABV5CA From: "Rainer Gerhards" To: "Tom Petch" , "Chris Lonvick" X-OriginalArrivalTime: 06 Jul 2006 10:02:51.0069 (UTC) FILETIME=[5761DED0:01C6A0E3] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: syslog@ietf.org 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 Tom, I do not know if rewriting really helps. I suspect Huawei's patent lawyers, like patent lawyers everywhere, did a good job in wording the patent application so generally that probably evertyhing we do in respect to syslog/tls would fall under their claim. Eventually, that would even apply to anything that securely transports syslog. You do not know without the claim details. I'd guess it says something like "transporting system logs over a secure channel" ;). My personal opinion is that we should continue with -transport-tls, Chris' A) option. My reasoning: 1. the proposed licensing terms look fair enough to me 2. the patent is probably quite "trollish" and it is=20 questionable if a) it will be granted at all b) survive appeal (if somebody appeals) 3. I'd like to see documented and standardized a tls transport as it is already in use today. This hopefully helps getting it quickly implemented. A technical issue regarding 3: I know that the current approach is flawed. Maybe I do not see all the seriousness of it. I still think it is good enough as a starting point, bringing together what is done in practice already. Once we are finished with transport-tls, we can look into better alternatives. One such is 3195bis, the other -transport-ssh. -transport-ssh probably has most potential when it comes in trying to converge different NM protocols. But we could also end up defining no separate transport but using NETCONF notifications with a syslog event message data model. I do not know how to prevent that your comments (and mine and anybody elses) comment become part of Huawei's IP. Maybe it would help to publish them as a separate document, if the volume justifies that. All in all, I still go for option A) as the best compromise. This is made on the understanding that we do *not* modify/enhance -transport-tls much further (just the bare necessities). This argument is based on my "we must publish" POV. Rainer > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, July 06, 2006 9:56 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim >=20 > > Tom Petch >=20 > ----- Original Message ----- > From: "Chris Lonvick" > To: "Darren Reed" > Cc: > Sent: Wednesday, July 05, 2006 6:25 PM > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim >=20 >=20 > > Hi Darren, > > > > There is no need for Bazsi to write a different i-d. > > draft-ietf-syslog-transport-tls is a Working Group document and the > > final revision must reflect WG consensus. > > >=20 > I think that draft-ietf-syslog-transport-tls is seriously=20 > flawed and I have > already made some comments on this, have others pending. But=20 > I am now reluctant > to make any constructive suggestions lest my text be slightly=20 > modified, > incorporated into this I-D and then made subject to an IPR claim. >=20 > I believe we need a new document, or at least a new editor=20 > who is prepared to > rewrite everything. I am not saying it should be that of=20 > Bazsi, just anyone who > does not have H*** in their e-mail address. >=20 > Tom Petch >=20 > > If Bazsi (or anybody else) can propose changes to > > draft-ietf-syslog-transport-tls and the WG reaches consensus on the > > proposed changes, then the document will be revised to reflect that. > > > > Please check me if I'm wrong on this, but I think that the=20 > only changes > > between syslog-ng and what's in syslog-transport-tls are > > - framing, > > - changes to address the threat model (listed in our Charter). > > > > Thanks, > > Chris > > > > >=20 >=20 > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Jul 06 09:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTyF-00067F-5E; Thu, 06 Jul 2006 09:32:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTyD-00066x-Ci for syslog@ietf.org; Thu, 06 Jul 2006 09:32:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTyD-0004hb-Ai for syslog@ietf.org; Thu, 06 Jul 2006 09:32:41 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyTyA-0005Pi-5n for syslog@ietf.org; Thu, 06 Jul 2006 09:32:41 -0400 Received: from pc6 (1Cust64.tnt30.lnd3.gbr.da.uu.net [62.188.122.64]) by astro.systems.pipex.net (Postfix) with SMTP id CD335E00006D; Thu, 6 Jul 2006 14:32:02 +0100 (BST) Message-ID: <00cc01c6a0f7$988ecee0$0601a8c0@pc6> From: "Tom Petch" To: "Jean-Francois Mule" , References: Subject: Re: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Date: Thu, 6 Jul 2006 14:26:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -2.4 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: enechamkin@broadcom.com, Sumanth Channabasappa , "Richard Woundy @ Comcast" , deketelaere@tComLabs.com X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 Mmm... I struggle to see anything relating to the management of a syslog server here. Rather it allows the customisation of the port/address type/address of the server in the syslog agent, which is rather different. I wonder if all the references to RFC3164 should be revisited in the light of Rainer's work on syslog-protocol, or is this an environment which is accurately described by RFC3164? The normative references to documents I will probably never see make it difficult to take this very far. I did look at all five MIB I-Ds listed on the ipcdn webpage in case the reference was to the wrong I-D (it wasn't) and did think they would all benefit from a paragraph summarising the relationships between them. The work of disman, for example, spans many MIB modules and RFC3877 (eg) comments on the relationships; the work of rmonmib goes further and has its own RFC [RFC3577] spelling out the relationships. (In draft-ietf-ipcdn-device-mibv2-11, I did like the comment that ipv4 and SNMPv1 were the mandatory to implement options; trusted and true technology). Tom Petch ----- Original Message ----- From: "Jean-Francois Mule" To: "David B Harrington" ; Cc: ; "Sumanth Channabasappa" ; "Richard Woundy @ Comcast" ; Sent: Wednesday, July 05, 2006 6:54 PM Subject: RE: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Good redirection David. Please copy the ID co-authors and the syslog list on any comments you have. Jean-Francois. > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, July 05, 2006 10:24 AM > To: syslog@ietf.org > Subject: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt > > FYI. > This document defines a MIB that, as part of its definition, manages > syslog servers. > I am the MIB Doctor for this document and would be interested in your > comments. > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-07 > .txt > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 09:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTyE-000672-0f; Thu, 06 Jul 2006 09:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTyC-00066s-K0 for syslog@ietf.org; Thu, 06 Jul 2006 09:32:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTyC-0004hX-Hr for syslog@ietf.org; Thu, 06 Jul 2006 09:32:40 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyTyA-0005Pj-5n for syslog@ietf.org; Thu, 06 Jul 2006 09:32:40 -0400 Received: from pc6 (1Cust64.tnt30.lnd3.gbr.da.uu.net [62.188.122.64]) by astro.systems.pipex.net (Postfix) with SMTP id 00D5BE000248; Thu, 6 Jul 2006 14:32:08 +0100 (BST) Message-ID: <00cd01c6a0f7$9a6c6880$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Need your input on the Hauwei IPR claim Date: Thu, 6 Jul 2006 14:27:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -2.3 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 B) As the document is technically inadequate as a standard for syslog over TLS, we would also benefit from a fresh start with an editor without H*** in their e-mail address. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Thursday, July 06, 2006 12:23 AM Subject: [Syslog] Need your input on the Hauwei IPR claim > Hi Folks, > > Everyone has now had a week to think about the IETF process on IPR claims. > The first decision that we need to make is about the terms of the claim. > I'd like to hear what people think about the terms that Huawei has > presented. > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 > > Please keep in mind that we can (and should) proceed with > syslog-transport-tls if the terms appear reasonable and you (as > implementors) are willing to accept them. Let's keep this discussion > focused. > - We do not need a discussion of the terms. > - We do not need any legal opinions. > - We do not need a discussion of technical alternatives on this thread. > > >From that, I'd like to hear either: > > A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working > Group document. > > or > > B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a > Working Group document. > > I'll leave this open until the 19th (so people going to the IETF can catch > their collective breaths and give a good opinion. > > If the consensus appears to be "A" then we can get straight back to work. > > If the consensus appears to be "B" then I will very briefly ask if there > are changes to the terms that would make them acceptable. I'll only ask > that if the consensus appears to be "B" so don't insert your opinions on > that at this time. I'm (just barely) willing to ask that (once) of the > Huawei lawyers but I feel that negotiating terms is not going to move us > forward; it's likely to be a rat-hole discussion and I won't let us go > down there. > > If the consensus remains "B" then we will likely move away from > syslog-transport-tls. Where we move to will be a different discussion so > please don't insert your opinion about that on this discussion thread. > David has opened that discussion on a separate thread so you may discuss > it on the list, but I'm not focused on that at this time. > > Thanks, > Chris > > _______________________________________________ > 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 Thu Jul 06 10:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUes-0004yv-Bx; Thu, 06 Jul 2006 10:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUeq-0004vL-SM for syslog@ietf.org; Thu, 06 Jul 2006 10:16:44 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUeq-0006uL-7N for syslog@ietf.org; Thu, 06 Jul 2006 10:16:44 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5A46927C065; Thu, 6 Jul 2006 16:12:32 +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 08154-01; Thu, 6 Jul 2006 16:12:32 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E999427C061; Thu, 6 Jul 2006 16:12:31 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 16:16:42 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagrams MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jul 2006 16:16:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174B62@grfint2.intern.adiscon.com> In-Reply-To: <064a01c695e0$f52e4120$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams Thread-Index: AcaV6e6Aboeoksq9RbKHqx01CjgHWwLGYscg From: "Rainer Gerhards" To: "Tom Petch" , X-OriginalArrivalTime: 06 Jul 2006 14:16:42.0218 (UTC) FILETIME=[CDDAC4A0:01C6A106] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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 Tom, I think your and Anton's commetn below so far is the most important comment on -transport-tls technical issues (assuming that the certificate issue can relatively easy be fixed by specifying a cipher suite). IMHO the comment applies to any shim layer for stream protocols, not just TLS. I think a compromise to get something like -transport-tls going is that we might actually define LF to be the end of record marker and require the message inside the "frame" to escape LF. That would require two characters to be escaped (of for the LF and one for the escape character itself). Such a compromise would also be consistent with what is currently done in practice. And, indeed, we could avoid the byte-counting. That would fully bring us in sync to what is done today (syslog-ng, cisco Pix, rsyslog, Kiwi Syslog, MonitorWare to name a few). I still consider this to be a non-perfect framing, but I think it would be acceptable. In the medium term, we should look into a more sophisticated framing, maybe borrowed from NETCONF. But that should come after we have delivered something. If that might be a compromise, I could quickly draft an I-D that *documents* the way TCP based stream transport is used today. -transport-tls would then just need to add description of TLS handshaking. Or the I-D could be informational describing what can be found in practice. I do not know if that would have any effect on the patent office's decision (but I can claim publically-available previous work, around Jan 2003 - see http://adiscon.org/specs/selp-2003-01-15.txt). For the legal folks: I have running implementations and public documents describing the method outlined above. It is fraudulent if somebody claims he has invented the method I have described here, at least if he hasn't invented it roughly 10 years or so ago. Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, June 22, 2006 11:47 AM > To: Anton Okmianski (aokmians); syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams >=20 > > ----- Original Message ----- > From: "Anton Okmianski (aokmians)" > To: "Tom Petch" ; > Sent: Tuesday, June 20, 2006 8:18 PM > Subject: RE: [Syslog] delineated datagrams >=20 >=20 > Tom: >=20 > I think these are valid concerns. They span different layers: >=20 > 1. If we only care about network-layer reliability (as in=20 > byte insert/remove > examples): client/server can be recommended to reset=20 > connection every so often. > Decent corruption detection is already part of TCP/IP and=20 > layer 2 protocols. >=20 > 2. If we care about app-layer reliability (as in=20 > encode/decode error examples): > app-level ACK. As in RFC 3195, for example. This certainly=20 > expands the scope > quite a bit beyond just secure transport. >=20 > Anton >=20 > My concern was in between, the shim between TCP and syslog=20 > that is TLS. >=20 > With UDP transport, a Relay receives a datagram and sends it=20 > on its way, no > processing required; probability of corruption small enough to ignore, > consequences when it does, one corrupted packet. >=20 > With TLS, the packet must be decrypted, unpadded,=20 > decompressed split into > 'datagrams' on the basis of a string of decimal digits and=20 > then re-packaged to > send on its way. If a byte is lost here, chances are the=20 > string of decimal > digits will point into the middle of a valid string of=20 > decimal digits, which > will give a truncated second 'datagram' and point into who knows what. > Eventually, the pointer will not point to a string of decimal=20 > digits and the > Relay will realise it is lost. By then, it may have=20 > forwarded several corrupted > or truncated 'datagrams'. And the chance of recovering sync=20 > is, IMO, nil; tear > down the connection and set it up again. >=20 > By contrast, there are protocols which rely on detecting=20 > sync, use it initially, > error detect and error recover with it. Of course, they have=20 > more to go on than > a string of decimal digits, they have structures which are=20 > distinctive in the > context of the datastream (I would for example expect to=20 > recover sync with BER.1 > encoding of SNMP, although I don't know anyone who does that). >=20 > So my thinking is should we have more than a string of=20 > decimal digits, like > > or something else that is obviously invalid so that errors=20 > are likely to be > detected immediately and the Relay has a chance of scanning=20 > the stream to > recover sync. >=20 > You may recall we have had discussions of length v end of=20 > record marker before > (and yes, I do like end of record markers:-) >=20 > Tom Petch >=20 > Anton. >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Tuesday, June 20, 2006 8:43 AM > > To: syslog@ietf.org > > Subject: Re: [Syslog] delineated datagrams > > wasdraft-ietf-syslog-transport-tls-01.txt > > > > I wonder if others share my concern about the lack of > > robustness in the way in > > which datagrams are delineated in the stream protocol (a TCP > > rather than a TLS > > issue). > > > > The system works as long as > > - the frame length is encoded perfectly > > - the frame length is decoded perfectly > > - no bytes are inserted or removed in error > > which is doubtless true in some networks, but I would prefer > > not to rely on it. > > > > So, when an error occurs, can the Collector/Relay detect=20 > it? Can the > > Collector/Relay recover synch? If not, what does the > > Collector/Relay do? > > > > There is very little redundancy in the definition of frame > > length, and syslog > > messages have very little structure to help the application, > > so I think that > > this is an issue we should address. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Tuesday, May 09, 2006 4:26 PM > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > > > > Hi, > > > > A new revision of the syslog/TLS draft is available. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > .txt > > > > We need reviewers. > > Can we get > > 1) a person to check the grammar? > > 2) a person to check the syslog technical parts? > > 3) a person to check compatibility with the other WG documents? > > 4) a person to check the TLS technical parts? > > > > We also need general reviews of the document by multiple people. > > > > Thanks, > > David Harrington > > co-chair, Syslog WG > > ietfdbh@comcast.net > > > > > > _______________________________________________ > > 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 > > >=20 >=20 > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Jul 06 12:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWgX-000829-Pi; Thu, 06 Jul 2006 12:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWgW-000820-GE for syslog@ietf.org; Thu, 06 Jul 2006 12:26:36 -0400 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWgU-0003CF-1V for syslog@ietf.org; Thu, 06 Jul 2006 12:26:36 -0400 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id A46CC4C020 for ; Thu, 6 Jul 2006 18:26:32 +0200 (CEST) Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim From: Balazs Scheidler To: Darren Reed In-Reply-To: <1152091974.6196.10.camel@bzorp.balabit> References: <200607031927.k63JRSSI006164@firewall.reed.wattle.id.au> <1152091974.6196.10.camel@bzorp.balabit> Content-Type: text/plain Date: Thu, 06 Jul 2006 18:26:30 +0200 Message-Id: <1152203190.6816.26.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: syslog@ietf.org 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 On Wed, 2006-07-05 at 11:32 +0200, Balazs Scheidler wrote: > On Tue, 2006-07-04 at 05:27 +1000, Darren Reed wrote: > RFC3195bis is a nice idea, even though I previously disliked that > protocol myself. I'll have to reread that RFC to form my opinion. I have now refreshed my memories on RFC3195, and my technical opinion is as follows: beep in general: - I like its extensibility and multiple channels, and its support for optional authentication/encryption - I don't like its complexity as we have to think with embedded devices in mind - depends on a whole lot of things, and as I see generating the XML constructs should use a real DOM implementation, as constructing XML with sprintf is asking for trouble (ie: escaping) syslog/raw profile: - this profile does not offer anything more than simple syslog over TCP as currently implemented in syslog-ng and other products, it has significant overhead though: - bandwidth wise: about 30 octets per message, - code wise: the beep framework (beep itself, xml, character sets, entities etc), this can be simplified significantly by supporting a single channel only, always using utf8 and hand-crafting XML with sprintf/parsing it with sax/handmade parser - this profile does not solve record termination, where the latest consensus was to be completely transparent for any unicode character, in syslog/raw CRLF line termination is used when multiple messages are included in a single BEEP frame. - the profile permits a maximum of 1024 bytes per message syslog/cooked profile: - I like the fact that every hop in the message path is properly identified, and proper identification of senders can be performed, - I like that application layer ACKs are present, however I think that it is too verbose (about 30-35 bytes to acknowledge a single message, about 35-40 to nack it) - I don't like that the new format still uses BSD timestamp, no year and no timezone information So as I see, there is absolutely no point in implementing syslog/raw, using the existing protocols is enough for legacy support and implementing syslog/raw is not any easier than using syslog/cooked. And it has issues with record termination and maximum message length. syslog/cooked could be updated with the latest header changes in syslog-transport-udp and with some adjustments it could provide a nice platform for new protocol features in the long run. What this boils down, is that I could support RFC3195bis, especially if we decide that we are bothered by the IPR claim of Huawei. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 12:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWtM-0005S1-Kc; Thu, 06 Jul 2006 12:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWdG-0007aP-9V for syslog@ietf.org; Thu, 06 Jul 2006 12:23:14 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWdD-00033z-1p for syslog@ietf.org; Thu, 06 Jul 2006 12:23:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] draft-ietf-ipcdn-pktc-eventmess-07.txt Date: Thu, 6 Jul 2006 12:22:32 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9676689F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Thread-Index: AcahALpWwfhClOnISpGj05zzUA2pFwAFNFIA From: "Woundy, Richard" To: "Tom Petch" , "Jean-Francois Mule" , X-OriginalArrivalTime: 06 Jul 2006 16:22:33.0265 (UTC) FILETIME=[62A11A10:01C6A118] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-Mailman-Approved-At: Thu, 06 Jul 2006 12:39:51 -0400 Cc: enechamkin@broadcom.com, Sumanth Channabasappa , "Woundy, Richard" , deketelaere@tComLabs.com 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 Tom, Thanks for the good questions. Here are some responses, not as IPCDN co-chair. >I struggle to see anything relating to the management of a syslog server here. You are correct; this MIB module enables management of a syslog agent and other components, within a voice over IP endpoint known as a PacketCable Multimedia Terminal Adapter (MTA). As a comparison, draft-ietf-ipcdn-device-mibv2-11 is targeted for DOCSIS cable modems, whereas draft-ietf-ipcdn-pktc-eventmess-07 is targeted for MTAs. Cable modems and MTAs may or may not be co-located in the same device, per section 3.3 of the draft. >I wonder if all the references to RFC3164 should be revisited in the light of Rainer's work on syslog-protocol, or is this an environment which is accurately described by RFC3164? The current DOCSIS and PacketCable syslog agent/server environments are accurately described by RFC 3164. >I did look at all five MIB I-Ds listed on the ipcdn webpage in case the reference was to the wrong I-D (it wasn't) and did think they would all benefit from a paragraph summarising the relationships between them. Maybe a good compromise would be to add a paragraph in this draft to state the relationship between draft-ietf-ipcdn-device-mibv2 and draft-ietf-ipcdn-pktc-eventmess? -- Rich -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Thursday, July 06, 2006 8:26 AM To: Jean-Francois Mule; syslog@ietf.org Cc: enechamkin@broadcom.com; Sumanth Channabasappa; Woundy, Richard; deketelaere@tComLabs.com Subject: Re: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Mmm... I struggle to see anything relating to the management of a syslog server here. Rather it allows the customisation of the port/address type/address of the server in the syslog agent, which is rather different. I wonder if all the references to RFC3164 should be revisited in the light of Rainer's work on syslog-protocol, or is this an environment which is accurately described by RFC3164? The normative references to documents I will probably never see make it difficult to take this very far. I did look at all five MIB I-Ds listed on the ipcdn webpage in case the reference was to the wrong I-D (it wasn't) and did think they would all benefit from a paragraph summarising the relationships between them. The work of disman, for example, spans many MIB modules and RFC3877 (eg) comments on the relationships; the work of rmonmib goes further and has its own RFC [RFC3577] spelling out the relationships. (In draft-ietf-ipcdn-device-mibv2-11, I did like the comment that ipv4 and SNMPv1 were the mandatory to implement options; trusted and true technology). Tom Petch ----- Original Message ----- From: "Jean-Francois Mule" To: "David B Harrington" ; Cc: ; "Sumanth Channabasappa" ; "Richard Woundy @ Comcast" ; Sent: Wednesday, July 05, 2006 6:54 PM Subject: RE: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Good redirection David. Please copy the ID co-authors and the syslog list on any comments you have. Jean-Francois. > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, July 05, 2006 10:24 AM > To: syslog@ietf.org > Subject: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt > > FYI. > This document defines a MIB that, as part of its definition, manages=20 > syslog servers. I am the MIB Doctor for this document and would be=20 > interested in your comments. > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-07 > .txt > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > _______________________________________________ > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 13:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXdC-0004eP-U6; Thu, 06 Jul 2006 13:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXdC-0004eK-D9 for syslog@ietf.org; Thu, 06 Jul 2006 13:27:14 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXdB-0006SR-2u for syslog@ietf.org; Thu, 06 Jul 2006 13:27:14 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc14) with SMTP id <20060706172711m14009jmvre>; Thu, 6 Jul 2006 17:27:11 +0000 From: "David Harrington" To: "'Tom Petch'" , "'Chris Lonvick'" Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Date: Thu, 6 Jul 2006 13:25:57 -0400 Message-ID: <00fd01c6a121$3e8edaa0$0400a8c0@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: <003601c6a0d3$10be7a20$0601a8c0@pc6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acag3A0e/qsoqu6hS0W4b9NKH8nDmAAQ0Dzw X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: syslog@ietf.org 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 Tom, The editors' responsibility is to make the document reflect WG consensus, as best they can. The co-chairs and the AD are responsible for ensuring that the editors represented the WG consensus in the document, and to determine WG consensus if it is not clear to the editors. Please propose text worded as you wish to see it, and ask for WG comments. If Chris feels there is WG consensus on the wording, then that wording would go into the document, without being slightly modified. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Thursday, July 06, 2006 3:56 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim > > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: "Darren Reed" > Cc: > Sent: Wednesday, July 05, 2006 6:25 PM > Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim > > > > Hi Darren, > > > > There is no need for Bazsi to write a different i-d. > > draft-ietf-syslog-transport-tls is a Working Group document and the > > final revision must reflect WG consensus. > > > > I think that draft-ietf-syslog-transport-tls is seriously > flawed and I have > already made some comments on this, have others pending. But > I am now reluctant > to make any constructive suggestions lest my text be slightly > modified, > incorporated into this I-D and then made subject to an IPR claim. > > I believe we need a new document, or at least a new editor > who is prepared to > rewrite everything. I am not saying it should be that of > Bazsi, just anyone who > does not have H*** in their e-mail address. > > Tom Petch > > > If Bazsi (or anybody else) can propose changes to > > draft-ietf-syslog-transport-tls and the WG reaches consensus on the > > proposed changes, then the document will be revised to reflect that. > > > > Please check me if I'm wrong on this, but I think that the > only changes > > between syslog-ng and what's in syslog-transport-tls are > > - framing, > > - changes to address the threat model (listed in our Charter). > > > > Thanks, > > Chris > > > > > > > _______________________________________________ > 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 Thu Jul 06 17:15:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybBh-0006yd-Gv; Thu, 06 Jul 2006 17:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FybBh-0006yY-1w for syslog@ietf.org; Thu, 06 Jul 2006 17:15:05 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FybBf-0003Bx-PH for syslog@ietf.org; Thu, 06 Jul 2006 17:15:05 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id D805127C065; Thu, 6 Jul 2006 23:10:50 +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 15952-09; Thu, 6 Jul 2006 23:10:50 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9755427C061; Thu, 6 Jul 2006 23:10:50 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 23:14:27 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jul 2006 23:14:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174B76@grfint2.intern.adiscon.com> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D9676689F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Thread-Index: AcahALpWwfhClOnISpGj05zzUA2pFwAFNFIAAArbsVA= From: "Rainer Gerhards" To: "Woundy, Richard" , "Tom Petch" , "Jean-Francois Mule" , X-OriginalArrivalTime: 06 Jul 2006 21:14:27.0126 (UTC) FILETIME=[29B43560:01C6A141] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: enechamkin@broadcom.com, Sumanth Channabasappa , deketelaere@tComLabs.com 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 > >I wonder if all the references to RFC3164 should be revisited in the > light of Rainer's work on syslog-protocol, or is this an environment > which is accurately described by RFC3164? >=20 > The current DOCSIS and PacketCable syslog agent/server=20 > environments are > accurately described by RFC 3164. Small, (but important?) glitch: RFC 3164 is informational, so you can't use it as a normative reference. Other than that, I've not been able to check much more. So I can't judge if that poses a problem. Rainer=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 06 20:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyeR1-0000NO-Os; Thu, 06 Jul 2006 20:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyeNn-0006So-O6 for syslog@ietf.org; Thu, 06 Jul 2006 20:39:47 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyeNm-00010B-Gg for syslog@ietf.org; Thu, 06 Jul 2006 20:39:47 -0400 Received: from ([10.52.116.10]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.22131836; Thu, 06 Jul 2006 20:39:28 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 20:39:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] draft-ietf-ipcdn-pktc-eventmess-07.txt Date: Thu, 6 Jul 2006 20:39:27 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D967668AF@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt Thread-Index: AcahALpWwfhClOnISpGj05zzUA2pFwAFNFIAAArbsVAABwLYUA== From: "Woundy, Richard" To: "Rainer Gerhards" , "Tom Petch" , "Jean-Francois Mule" , , "Dan Romascanu" X-OriginalArrivalTime: 07 Jul 2006 00:39:28.0282 (UTC) FILETIME=[CDC3A7A0:01C6A15D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 06 Jul 2006 20:43:06 -0400 Cc: enechamkin@broadcom.com, Sumanth Channabasappa , "Woundy, Richard" , deketelaere@tComLabs.com 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 >Small, (but important?) glitch: RFC 3164 is informational, so you can't use it as a normative reference. Thanks for pointing out this "interesting" problem for . also uses RFC 3164 as a normative reference, but that draft is on the RFC Editor's Queue as a Proposed Standard. It would be nice if we could be consistent. :^) I'll need to check with my Area Director advisor to see what he suggests. Dan? -- Rich -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 Sent: Thursday, July 06, 2006 5:15 PM To: Woundy, Richard; Tom Petch; Jean-Francois Mule; syslog@ietf.org Cc: enechamkin@broadcom.com; Sumanth Channabasappa; deketelaere@tComLabs.com Subject: RE: [Syslog] draft-ietf-ipcdn-pktc-eventmess-07.txt > >I wonder if all the references to RFC3164 should be revisited in the > light of Rainer's work on syslog-protocol, or is this an environment=20 > which is accurately described by RFC3164? >=20 > The current DOCSIS and PacketCable syslog agent/server > environments are > accurately described by RFC 3164. Small, (but important?) glitch: RFC 3164 is informational, so you can't use it as a normative reference. Other than that, I've not been able to check much more. So I can't judge if that poses a problem. Rainer=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jul 07 05:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymbH-0008Ej-W0; Fri, 07 Jul 2006 05:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FymbG-0008Ee-GQ for syslog@ietf.org; Fri, 07 Jul 2006 05:26:14 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FymbD-0006uq-0P for syslog@ietf.org; Fri, 07 Jul 2006 05:26:14 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6155A27C065; Fri, 7 Jul 2006 11:21:56 +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 29068-08; Fri, 7 Jul 2006 11:21:56 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 038B627C061; Fri, 7 Jul 2006 11:21:55 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 11:26:09 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] FW: Initial Logging capabiltiies document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 11:25:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174B85@grfint2.intern.adiscon.com> In-Reply-To: <004f01c6a04d$4777b030$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: Initial Logging capabiltiies document Thread-Index: AcagP+ZuhlOcFvbaTUWPULYFwv/CegADLyPQAFWVl9A= From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 07 Jul 2006 09:26:09.0061 (UTC) FILETIME=[614BDD50:01C6A1A7] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: pcain@coopercain.com 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 Quick review: Section 2.3: It looks like the syslog-ng option is vendor specific. In practice, there are many implementations that interoperate with "plain tcp syslog". At least these I know: Cisco PIX, Kiwi Syslog Daemon, rsyslog, Adiscon MonitorWare, EventReporter & WinSyslog and probably SDSC syslogd (not totally sure about that). Some of them are running on Windows, so the protocol also works cross-platform. Considerations: It should be stated that it sometimes is more desirable to have unreliable delivery. Reliable delivery means that the sender must slow down when the receiver can not process fast enough. There have been reports that such a slow-down might be unacceptable if that means a high-performance application needs to wait for the logging. What is more desirable obviously depends on the actual situation and the operator's choice (and/or legal requirements). Reliable delivery could cause a "domino DoS effect", if the senders block while reconnecting. Popular samples are blocking PIXes whom's syslogd has died. The same can be constructed for *nix systems reporting via reliable syslog to a died central one. In that case, applications (e.g. SMTP MTA) log synchronously to the syslogd, which tries to forward. The local syslogd block. The synchronous logging API blocks shortly after. This results to a standstill of the system as whole. I see this is somewhat covered in 2.16, maybe a pointer would be helpful. Section 2.4 Supported Practices add Tunneling via SSL Current Implementations Using stunnel together with syslog/plain tcp capable applications (e.g. syslog-ng) is common practice. Some samples: http://www.google.com/search?sourceid=3Dnavclient-ff&ie=3DUTF-8&rls=3DGGG= L,GGG L:2006-13,GGGL:en&q=3Dsyslog+ssl http://www.stunnel.org/examples/syslog-ng.html=20 http://freshmeat.net/articles/view/1781/ General common on timestamp-related sections:=20 current syslog practice is inadequate. syslog-protocol is trying to fix that. Even after syslog-protocol has become a RFC, inadequate timestamps will stay for a long time IMO. A mitigation is that the receiver records the time of reception. Given a sufficiently fast network, that reception timestamp could be sufficient by itself. It would also be possible to compute a delta between the message and the reception timestamp and try to find a correction factor. I do not know of any effort to try such a thing. Section 2.17.2 I think the first sentence should not read "TCP port numer" but "port number". Syslog usually travels via UDP and only occasionally via TCP (RFC 3195 & non-standard but widespread used plain tcp syslog). Section 3 general comment: current syslog servers "compress" repeat messages ("message repeated n times"). The compression happens at the sender. This is sometimes desirable, but can lead to information loss. I suggest this method is described. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, July 05, 2006 6:09 PM > To: syslog@ietf.org > Subject: [Syslog] FW: Initial Logging capabiltiies document >=20 > FYI. >=20 > -----Original Message----- > From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of > patrick cain > Sent: Wednesday, July 05, 2006 10:33 AM > To: opsec@ops.ietf.org > Subject: Initial Logging capabiltiies document >=20 > Hi, >=20 > I promised to get out a version of the logging capabiltiies document. > Since > I missed the initial draft cutoff date, I spent some extra time > flushing it > out. And it is attached. It will go to the IETF repository as soon as > it > re-opens. Please advise me of correction, complaints, and aditions, > and > feel free to spam it others you may know who are into logging. >=20 > I asked for agenda time at the Montreal OPSEC meeting, but I don't > think > this one needs much presenting. >=20 > Pat Cain >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jul 11 09:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IAU-00042C-I3; Tue, 11 Jul 2006 09:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IAT-0003yV-2e for syslog@ietf.org; Tue, 11 Jul 2006 09:20:49 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IAR-0005gd-Pz for syslog@ietf.org; Tue, 11 Jul 2006 09:20:49 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2006 06:20:47 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k6BDKlZD028903; Tue, 11 Jul 2006 06:20:47 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BDKksU017054; Tue, 11 Jul 2006 06:20:47 -0700 (PDT) Date: Tue, 11 Jul 2006 06:20:46 -0700 (PDT) From: Chris Lonvick To: Tom Petch Subject: Re: [Syslog] Need your input on the Hauwei IPR claim In-Reply-To: <00cd01c6a0f7$9a6c6880$0601a8c0@pc6> Message-ID: References: <00cd01c6a0f7$9a6c6880$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1116; t=1152624047; x=1153488047; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Re=3A=20[Syslog]=20Need=20your=20input=20on=20the=20Hauwei=20IPR=20claim; X=v=3Dcisco.com=3B=20h=3DIXf4hvr7dMjnHbzIUmZ2ZHcp94o=3D; b=vTa/d5TtKpc8KvZ1zg8L+nvYiDonSPCaOYCdGV/nih9m5iLtqLm8LSfkkneouUCQVfSndf1w B8ylbVoRGMdtFt13qdtuZlNiHiddPpFYOabzP8wJ3XdGEGyyTro3Hbn2; Authentication-Results: sj-dkim-4.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org 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 On Thu, 6 Jul 2006, Tom Petch wrote: > B) As the document is technically inadequate as a standard for syslog over TLS, > we > would also benefit from a fresh start with an editor without H*** in their > e-mail address. > > Tom Petch Tom, This is inappropriate. First, remarks that discredit any group or company are not permitted within the IETF. We make progress by seeking consensus. Attacking any group or company will drive wedges between our group and I will not permit it on this mailing list. Second, Huawei has been complying with the rules specified in RFC 3979. They have claimed some IPR in syslog-transport-tls; they have notified the Working Group; and have specified their terms in the IPR claim repository. Changing authors will not change the fact that Huawei has an IPR claim associated with the work. The authors have been responsive and active in seeking input and trying to gain consensus on the technical merits of the document. I see no reason for them to be removed or replaced. Please do not make comments of this nature in the future. -Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jul 14 05:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KGQ-0004sd-F1; Fri, 14 Jul 2006 05:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KGP-0004s9-G3 for syslog@ietf.org; Fri, 14 Jul 2006 05:47:13 -0400 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1K9m-0008Df-WD for syslog@ietf.org; Fri, 14 Jul 2006 05:40:24 -0400 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 730DB294037 for ; Fri, 14 Jul 2006 11:40:21 +0200 (CEST) Subject: Re: [Syslog] Need your input on the Hauwei IPR claim From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain Date: Fri, 14 Jul 2006 11:40:17 +0200 Message-Id: <1152870017.8936.2.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: syslog@ietf.org 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 On Wed, 2006-07-05 at 15:23 -0700, Chris Lonvick wrote: > Hi Folks, > > Everyone has now had a week to think about the IETF process on IPR claims. > The first decision that we need to make is about the terms of the claim. > I'd like to hear what people think about the terms that Huawei has > presented. > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 > > Please keep in mind that we can (and should) proceed with > syslog-transport-tls if the terms appear reasonable and you (as > implementors) are willing to accept them. Let's keep this discussion > focused. > - We do not need a discussion of the terms. > - We do not need any legal opinions. > - We do not need a discussion of technical alternatives on this thread. > > >From that, I'd like to hear either: > > A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working > Group document. > Sorry for the late reply, I had a tough time deciding this, my opinion is A), we should continue working on the new transport-tls documents. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jul 14 07:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1LdH-0007vc-2f; Fri, 14 Jul 2006 07:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1LdG-0007vX-MQ for syslog@ietf.org; Fri, 14 Jul 2006 07:14:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1LdF-0006uI-BO for syslog@ietf.org; Fri, 14 Jul 2006 07:14:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2006 04:14:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EBEqtL021666 for ; Fri, 14 Jul 2006 04:14:52 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6EBEqJj011089 for ; Fri, 14 Jul 2006 04:14:52 -0700 (PDT) Date: Fri, 14 Jul 2006 04:14:52 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Subject: REMINDER - voting still open until July 19 - Re: [Syslog] Need your input on the Huawei IPR claim In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2396; t=1152875692; x=1153739692; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:REMINDER=20-=20voting=20still=20open=20until=20July=2019=20-=20Re=3A=20[ Syslog]=20Need=20your=0A=20input=20on=20the=20Huawei=20IPR=20claim; X=v=3Dcisco.com=3B=20h=3Dqyhe9C1vbiOuRFX8VwC9zfqGG3I=3D; b=E99Q6nFTp8i4V7gNbFe7av+OLjmfqq/SDNV1YpW4SwHJohLzhqK2F94z45pv/7cm8tCXhJlN MucLN6TupKRY8dDcfKwlvj1me0XRfo5dsHC6yEAvKqLruzbH4mDnClWO; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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, Please continue to send in your opinion on this. I'll determine consensus next Thursday and outline our steps to go forward. Thanks, Chris On Wed, 5 Jul 2006, Chris Lonvick wrote: > Hi Folks, > > Everyone has now had a week to think about the IETF process on IPR claims. > The first decision that we need to make is about the terms of the claim. > I'd like to hear what people think about the terms that Huawei has presented. > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 > > Please keep in mind that we can (and should) proceed with > syslog-transport-tls if the terms appear reasonable and you (as implementors) > are willing to accept them. Let's keep this discussion focused. > - We do not need a discussion of the terms. > - We do not need any legal opinions. > - We do not need a discussion of technical alternatives on this thread. > >> From that, I'd like to hear either: > > A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working > Group document. > > or > > B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a > Working Group document. > > I'll leave this open until the 19th (so people going to the IETF can catch > their collective breaths and give a good opinion. > > If the consensus appears to be "A" then we can get straight back to work. > > If the consensus appears to be "B" then I will very briefly ask if there are > changes to the terms that would make them acceptable. I'll only ask that if > the consensus appears to be "B" so don't insert your opinions on that at this > time. I'm (just barely) willing to ask that (once) of the Huawei lawyers but > I feel that negotiating terms is not going to move us forward; it's likely to > be a rat-hole discussion and I won't let us go down there. > > If the consensus remains "B" then we will likely move away from > syslog-transport-tls. Where we move to will be a different discussion so > please don't insert your opinion about that on this discussion thread. David > has opened that discussion on a separate thread so you may discuss it on the > list, but I'm not focused on that at this time. > > Thanks, > Chris > > _______________________________________________ > 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 Wed Jul 19 01:21:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34V3-0001JV-GG; Wed, 19 Jul 2006 01:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G34V1-0001JQ-V1 for syslog@ietf.org; Wed, 19 Jul 2006 01:21:31 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G34V0-0002aM-8y for syslog@ietf.org; Wed, 19 Jul 2006 01:21:31 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k6J5LRm9012442 for ; Wed, 19 Jul 2006 14:21:27 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k6J5LL5x026112 for ; Wed, 19 Jul 2006 14:21:27 +0900 (JST) Message-ID: <44BDC151.7050301@cysols.com> Date: Wed, 19 Jul 2006 14:21:21 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: REMINDER - voting still open until July 19 - Re: [Syslog] Need your input on the Huawei IPR claim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 A. Glenn Chris Lonvick wrote: > Hi Folks, > > Please continue to send in your opinion on this. I'll determine > consensus next Thursday and outline our steps to go forward. > > Thanks, > Chris > > On Wed, 5 Jul 2006, Chris Lonvick wrote: > >> Hi Folks, >> >> Everyone has now had a week to think about the IETF process on IPR >> claims. The first decision that we need to make is about the terms of >> the claim. >> I'd like to hear what people think about the terms that Huawei has >> presented. >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 >> >> Please keep in mind that we can (and should) proceed with >> syslog-transport-tls if the terms appear reasonable and you (as >> implementors) are willing to accept them. Let's keep this discussion >> focused. >> - We do not need a discussion of the terms. >> - We do not need any legal opinions. >> - We do not need a discussion of technical alternatives on this thread. >> >>> From that, I'd like to hear either: >> >> A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a >> Working Group document. >> >> or >> >> B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as >> a Working Group document. >> >> I'll leave this open until the 19th (so people going to the IETF can >> catch their collective breaths and give a good opinion. >> >> If the consensus appears to be "A" then we can get straight back to >> work. >> >> If the consensus appears to be "B" then I will very briefly ask if >> there are changes to the terms that would make them acceptable. I'll >> only ask that if the consensus appears to be "B" so don't insert your >> opinions on that at this time. I'm (just barely) willing to ask that >> (once) of the Huawei lawyers but I feel that negotiating terms is not >> going to move us forward; it's likely to be a rat-hole discussion and >> I won't let us go down there. >> >> If the consensus remains "B" then we will likely move away from >> syslog-transport-tls. Where we move to will be a different >> discussion so please don't insert your opinion about that on this >> discussion thread. David has opened that discussion on a separate >> thread so you may discuss it on the list, but I'm not focused on that >> at this time. >> >> Thanks, >> Chris >> >> _______________________________________________ >> 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jul 19 02:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35er-0001XK-AD; Wed, 19 Jul 2006 02:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G35ep-0001XF-FU for syslog@ietf.org; Wed, 19 Jul 2006 02:35:43 -0400 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G35eo-0000RC-77 for syslog@ietf.org; Wed, 19 Jul 2006 02:35:43 -0400 Received: (qmail 58317 invoked from network); 19 Jul 2006 06:35:40 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 19 Jul 2006 06:35:40 -0000 X-pair-Authenticated: 222.153.31.95 From: "Andrew Ross" To: Date: Wed, 19 Jul 2006 18:35:35 +1200 Organization: Kiwi Enterprises Message-ID: <000001c6aafd$8cb7c760$d9a8a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <44BDC151.7050301@cysols.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Syslog] Syslog TLS and the Huawei IPR claim X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew@kiwisyslog.com 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 Chris, After reading the IPR document, my vote is for A. A. The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. Regards Andrew Kiwi Enterprises Chris Lonvick wrote: > Hi Folks, > > Please continue to send in your opinion on this. I'll determine > consensus next Thursday and outline our steps to go forward. > > Thanks, > Chris > > On Wed, 5 Jul 2006, Chris Lonvick wrote: > >> Hi Folks, >> >> Everyone has now had a week to think about the IETF process on IPR >> claims. The first decision that we need to make is about the terms of >> the claim. >> I'd like to hear what people think about the terms that Huawei has >> presented. >> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=724 >> >> Please keep in mind that we can (and should) proceed with >> syslog-transport-tls if the terms appear reasonable and you (as >> implementors) are willing to accept them. Let's keep this discussion >> focused. >> - We do not need a discussion of the terms. >> - We do not need any legal opinions. >> - We do not need a discussion of technical alternatives on this thread. >> >>> From that, I'd like to hear either: >> >> A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a >> Working Group document. >> >> or >> >> B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as >> a Working Group document. >> >> I'll leave this open until the 19th (so people going to the IETF can >> catch their collective breaths and give a good opinion. >> >> If the consensus appears to be "A" then we can get straight back to >> work. >> >> If the consensus appears to be "B" then I will very briefly ask if >> there are changes to the terms that would make them acceptable. I'll >> only ask that if the consensus appears to be "B" so don't insert your >> opinions on that at this time. I'm (just barely) willing to ask that >> (once) of the Huawei lawyers but I feel that negotiating terms is not >> going to move us forward; it's likely to be a rat-hole discussion and >> I won't let us go down there. >> >> If the consensus remains "B" then we will likely move away from >> syslog-transport-tls. Where we move to will be a different >> discussion so please don't insert your opinion about that on this >> discussion thread. David has opened that discussion on a separate >> thread so you may discuss it on the list, but I'm not focused on that >> at this time. >> >> Thanks, >> Chris >> >> _______________________________________________ >> 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 _______________________________________________ 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 Thu Jul 20 03:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3SuY-0007xh-GU; Thu, 20 Jul 2006 03:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3SuW-0007px-5i for syslog@ietf.org; Thu, 20 Jul 2006 03:25:28 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3SuU-0007Hu-Rj for syslog@ietf.org; Thu, 20 Jul 2006 03:25:28 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6703A27C065 for ; Thu, 20 Jul 2006 09:20:26 +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 10705-05 for ; Thu, 20 Jul 2006 09:20:26 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2774A27C061 for ; Thu, 20 Jul 2006 09:20:26 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 09:25:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 09:25:14 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174C96@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: syslog over ssh thread-index: AcarzaSJAWaBc4icQOCKcuSeq9wpLg== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 20 Jul 2006 07:25:17.0727 (UTC) FILETIME=[A688DAF0:01C6ABCD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Syslog] syslog over ssh 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 WG, I just wanted to let you know that I have posted the individual submission on syslog over ssh: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg11360.html I have done this idependendly of the transport-tls issue. It is, at best, loosely connected (in that the work was spawned out of that discussion). I think the idea of syslog over ssh is generally worth thinking about and it is not implying that I expect -transport-tls to be discarded. I am still of the opinion that work in that area should progress (vote A). Please read the draft in that spirit. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 20 09:35:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Yfv-0008Rv-PZ; Thu, 20 Jul 2006 09:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Yfv-0008Ro-7h for syslog@ietf.org; Thu, 20 Jul 2006 09:34:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Yfv-0008Iv-62 for syslog@ietf.org; Thu, 20 Jul 2006 09:34:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3YXH-0002if-BO for syslog@ietf.org; Thu, 20 Jul 2006 09:25:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2006 06:25:51 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KDPo2v032307 for ; Thu, 20 Jul 2006 06:25:50 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KDPo2E014469 for ; Thu, 20 Jul 2006 06:25:50 -0700 (PDT) Date: Thu, 20 Jul 2006 06:25:50 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1237; t=1153401950; x=1154265950; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Consensus=20on=20the=20Huawei=20IPR=20claim; X=v=3Dcisco.com=3B=20h=3DO4nmzdsDVb37HHTeB0AZltAcpqo=3D; b=YguX7WLSN1mcvCCv2XImCCyVPswZysdCJGUhS6dpwCk78UGl3+sgSuqC84MvRxMIh+B4ZW4+ VH4jOTunJ6d5Hs327gwdd5zBZmrsDjCfApxBhIQtJpau/ELRCS0r0HMe; Authentication-Results: sj-dkim-3.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Syslog] Consensus on the Huawei IPR claim 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, The consensus reached is that: The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. There were numerous votes cast for this option. Most were public and are in the archive and I recieved two additional private responses for this. I saw very few votes for not continuing with this document on the list, and I received none privately. I want to thank everyone for taking the time to consider the IETF position on IPR, and for reviewing the Huawei terms. I also want to thank David Harrington for his professional attitude. There are no rules in the IETF saying that he had to recuse himself from this discussion, but I know that he felt that the discussion would proceed more smoothly if he did. And last, I want to thank Huawei for following the process on claiming IPR. I will mention one more time that the IETF, and our Working Group cannot and will not make any determination on the validity of any IPR claims. And with that... Let's get back to work. :-) We have a short timeframe to finish syslog-transport-tls and get it to the IESG. Please get your comments in to the mailing list and let's move this forward. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jul 20 10:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Zhc-0003BH-CR; Thu, 20 Jul 2006 10:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Zhb-0003Au-KS for syslog@ietf.org; Thu, 20 Jul 2006 10:40:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ZWy-0003tn-5N for syslog@ietf.org; Thu, 20 Jul 2006 10:29:36 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Z69-0003Ui-5i for syslog@ietf.org; Thu, 20 Jul 2006 10:01:57 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id E461727C065; Thu, 20 Jul 2006 15:56:49 +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 21012-04; Thu, 20 Jul 2006 15:56:49 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 707DF27C061; Thu, 20 Jul 2006 15:56:49 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:01:43 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagrams MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 16:01:42 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174CB0@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA174B62@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagrams thread-index: AcaV6e6Aboeoksq9RbKHqx01CjgHWwLGYscgAsBD4WA= From: "Rainer Gerhards" To: "Rainer Gerhards" , "Tom Petch" , X-OriginalArrivalTime: 20 Jul 2006 14:01:43.0633 (UTC) FILETIME=[080A1410:01C6AC05] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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 WG, now with the consensus on moving forward with -transport-tls, I would like to re-state my thoughts on delineated datagrams: I think a compromise to get -transport-tls going is that we might actually define LF to be the end of record marker and require the message inside the "frame" to escape LF. That would require two characters to be escaped (of for the LF and one for the escape character itself). Such a compromise would also be consistent with what is currently done in practice. And, indeed, we could avoid the byte-counting. That would fully bring us in sync to what is done today (syslog-ng, cisco Pix, rsyslog, Kiwi Syslog, MonitorWare to name a few). I still consider this to be a non-perfect framing, but I think it would be acceptable. In the medium term, we should look into a more sophisticated framing, maybe borrowed from NETCONF. But that should come after we have delivered something.=20 A byte-count could be prefixed to each record, but that would break compatibility with existing implementations (this is not absolutely necessary, but I consider it a very-nice-to-have, especially if the price for it is low). Comments appreciated, Rainer =20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Thursday, July 06, 2006 4:17 PM > To: Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] delineated datagrams >=20 > Tom, >=20 > I think your and Anton's commetn below so far is the most important > comment on -transport-tls technical issues (assuming that the > certificate issue can relatively easy be fixed by specifying a cipher > suite). >=20 > IMHO the comment applies to any shim layer for stream protocols, not > just TLS. I think a compromise to get something like -transport-tls > going is that we might actually define LF to be the end of=20 > record marker > and require the message inside the "frame" to escape LF. That would > require two characters to be escaped (of for the LF and one for the > escape character itself). Such a compromise would also be consistent > with what is currently done in practice. And, indeed, we=20 > could avoid the > byte-counting. That would fully bring us in sync to what is done today > (syslog-ng, cisco Pix, rsyslog, Kiwi Syslog, MonitorWare to=20 > name a few). > I still consider this to be a non-perfect framing, but I=20 > think it would > be acceptable. In the medium term, we should look into a more > sophisticated framing, maybe borrowed from NETCONF. But that=20 > should come > after we have delivered something. If that might be a compromise, I > could quickly draft an I-D that *documents* the way TCP based stream > transport is used today. -transport-tls would then just need to add > description of TLS handshaking. Or the I-D could be informational > describing what can be found in practice. I do not know if that would > have any effect on the patent office's decision (but I can claim > publically-available previous work, around Jan 2003 - see > http://adiscon.org/specs/selp-2003-01-15.txt). >=20 > For the legal folks: I have running implementations and=20 > public documents > describing the method outlined above. It is fraudulent if somebody > claims he has invented the method I have described here, at=20 > least if he > hasn't invented it roughly 10 years or so ago. >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Thursday, June 22, 2006 11:47 AM > > To: Anton Okmianski (aokmians); syslog@ietf.org > > Subject: Re: [Syslog] delineated datagrams > >=20 > > > > ----- Original Message ----- > > From: "Anton Okmianski (aokmians)" > > To: "Tom Petch" ; > > Sent: Tuesday, June 20, 2006 8:18 PM > > Subject: RE: [Syslog] delineated datagrams > >=20 > >=20 > > Tom: > >=20 > > I think these are valid concerns. They span different layers: > >=20 > > 1. If we only care about network-layer reliability (as in=20 > > byte insert/remove > > examples): client/server can be recommended to reset=20 > > connection every so often. > > Decent corruption detection is already part of TCP/IP and=20 > > layer 2 protocols. > >=20 > > 2. If we care about app-layer reliability (as in=20 > > encode/decode error examples): > > app-level ACK. As in RFC 3195, for example. This certainly=20 > > expands the scope > > quite a bit beyond just secure transport. > >=20 > > Anton > >=20 > > My concern was in between, the shim between TCP and syslog=20 > > that is TLS. > >=20 > > With UDP transport, a Relay receives a datagram and sends it=20 > > on its way, no > > processing required; probability of corruption small enough=20 > to ignore, > > consequences when it does, one corrupted packet. > >=20 > > With TLS, the packet must be decrypted, unpadded,=20 > > decompressed split into > > 'datagrams' on the basis of a string of decimal digits and=20 > > then re-packaged to > > send on its way. If a byte is lost here, chances are the=20 > > string of decimal > > digits will point into the middle of a valid string of=20 > > decimal digits, which > > will give a truncated second 'datagram' and point into who=20 > knows what. > > Eventually, the pointer will not point to a string of decimal=20 > > digits and the > > Relay will realise it is lost. By then, it may have=20 > > forwarded several corrupted > > or truncated 'datagrams'. And the chance of recovering sync=20 > > is, IMO, nil; tear > > down the connection and set it up again. > >=20 > > By contrast, there are protocols which rely on detecting=20 > > sync, use it initially, > > error detect and error recover with it. Of course, they have=20 > > more to go on than > > a string of decimal digits, they have structures which are=20 > > distinctive in the > > context of the datastream (I would for example expect to=20 > > recover sync with BER.1 > > encoding of SNMP, although I don't know anyone who does that). > >=20 > > So my thinking is should we have more than a string of=20 > > decimal digits, like > > > > or something else that is obviously invalid so that errors=20 > > are likely to be > > detected immediately and the Relay has a chance of scanning=20 > > the stream to > > recover sync. > >=20 > > You may recall we have had discussions of length v end of=20 > > record marker before > > (and yes, I do like end of record markers:-) > >=20 > > Tom Petch > >=20 > > Anton. > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Tuesday, June 20, 2006 8:43 AM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] delineated datagrams > > > wasdraft-ietf-syslog-transport-tls-01.txt > > > > > > I wonder if others share my concern about the lack of > > > robustness in the way in > > > which datagrams are delineated in the stream protocol (a TCP > > > rather than a TLS > > > issue). > > > > > > The system works as long as > > > - the frame length is encoded perfectly > > > - the frame length is decoded perfectly > > > - no bytes are inserted or removed in error > > > which is doubtless true in some networks, but I would prefer > > > not to rely on it. > > > > > > So, when an error occurs, can the Collector/Relay detect=20 > > it? Can the > > > Collector/Relay recover synch? If not, what does the > > > Collector/Relay do? > > > > > > There is very little redundancy in the definition of frame > > > length, and syslog > > > messages have very little structure to help the application, > > > so I think that > > > this is an issue we should address. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > > > > > > > Hi, > > > > > > A new revision of the syslog/TLS draft is available. > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > .txt > > > > > > We need reviewers. > > > Can we get > > > 1) a person to check the grammar? > > > 2) a person to check the syslog technical parts? > > > 3) a person to check compatibility with the other WG documents? > > > 4) a person to check the TLS technical parts? > > > > > > We also need general reviews of the document by multiple people. > > > > > > Thanks, > > > David Harrington > > > co-chair, Syslog WG > > > ietfdbh@comcast.net > > > > > > > > > _______________________________________________ > > > 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 > > > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Fri Jul 21 03:08:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3p7U-0008HQ-BQ; Fri, 21 Jul 2006 03:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3p63-0007XG-Gx for syslog@ietf.org; Fri, 21 Jul 2006 03:06:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3otT-0000oC-KW for syslog@ietf.org; Fri, 21 Jul 2006 02:53:51 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3orc-0000QV-24 for syslog@ietf.org; Fri, 21 Jul 2006 02:51:58 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 69FEA27C066; Fri, 21 Jul 2006 08:46:57 +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 14061-10; Fri, 21 Jul 2006 08:46:57 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2A98327C061; Fri, 21 Jul 2006 08:46:57 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 08:51:53 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] syslog over ssh MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jul 2006 08:51:47 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174CB7@grfint2.intern.adiscon.com> In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog over ssh thread-index: AcasGvtsnWqSQYEHTWKlpmbGxKhOkAAdrCVg From: "Rainer Gerhards" To: "Anton Chuvakin" X-OriginalArrivalTime: 21 Jul 2006 06:51:53.0286 (UTC) FILETIME=[26352E60:01C6AC92] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: syslog@ietf.org 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 Anton,=20 > -----Original Message----- > From: anton.chuvakin@gmail.com=20 > [mailto:anton.chuvakin@gmail.com] On Behalf Of Anton Chuvakin > Sent: Thursday, July 20, 2006 6:13 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] syslog over ssh >=20 > Rainer and all, >=20 > Just curious, how does it compare performance-wise to syslog-tls under > whatever common implementations? Can you say that you'd recommended it > sometimes over syslog-tls? There are few current implementations, none native (tunnel mode is used). The main intent of this effort was not performance. So I did not seriously consider performance implications. The main intent is that SSH is becoming increasingly popular among operators for use with network management protocols. For example, NETCONF now seems to focus pretty much on ssh. So the overall idea is that a standardized syslog over ssh capability helps with NM protocol convergence. >From the performance point of view, I do not expect a significant difference to syslog over TLS, at least after the initial session setup is done. Initial setup, I think, will be more expensive for SSH based syslog. I hope this provides at least some clues to an answer ;) Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jul 21 06:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ro5-00006n-TN; Fri, 21 Jul 2006 06:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ro4-00006R-OA for syslog@ietf.org; Fri, 21 Jul 2006 06:00:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ro2-0003xB-TX for syslog@ietf.org; Fri, 21 Jul 2006 06:00:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2R004WP07Q23@szxga03-in.huawei.com> for syslog@ietf.org; Fri, 21 Jul 2006 18:09:26 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2R000K007PZH@szxga03-in.huawei.com> for syslog@ietf.org; Fri, 21 Jul 2006 18:09:26 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Q00INMZVRBQ@szxml03-in.huawei.com> for syslog@ietf.org; Fri, 21 Jul 2006 18:02:18 +0800 (CST) Date: Fri, 21 Jul 2006 17:59:34 +0800 From: Miao Fuyou Subject: RE: [Syslog] delineated datagrams wasdraft-ietf-syslog-transport-tls-01.txt In-reply-to: <000201c69486$3a6a2080$0601a8c0@pc6> To: 'Tom Petch' , syslog@ietf.org Message-id: <00b401c6acac$5e59e5a0$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaUjzSUvTEyQOf2ReyXqKuPnkIuJwYGjHEA X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 TLS uses SHA-1 or MD5 in ciphersuite for message integrity verification. If bytes lost happens during transferring, the message will be dropped by TLS. That is also the cause that we need a security mechanism for Syslog. As for error of encoding/decoding, I believe if an application does encoding/decoding in a wrong way, you must not expect it do it right with other mechanism, such as LF. Redundancy to improve robustness is good idea, but I don't think it applies to this case. > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, June 20, 2006 8:43 PM > To: syslog@ietf.org > Subject: Re: [Syslog] delineated datagrams > wasdraft-ietf-syslog-transport-tls-01.txt > > I wonder if others share my concern about the lack of > robustness in the way in which datagrams are delineated in > the stream protocol (a TCP rather than a TLS issue). > > The system works as long as > - the frame length is encoded perfectly > - the frame length is decoded perfectly > - no bytes are inserted or removed in error which is > doubtless true in some networks, but I would prefer not to rely on it. > > So, when an error occurs, can the Collector/Relay detect it? > Can the Collector/Relay recover synch? If not, what does the > Collector/Relay do? > > There is very little redundancy in the definition of frame > length, and syslog messages have very little structure to > help the application, so I think that this is an issue we > should address. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > ietfdbh@comcast.net > > > _______________________________________________ > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jul 21 06:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3s7q-00085c-5m; Fri, 21 Jul 2006 06:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3s68-00064L-Kv for syslog@ietf.org; Fri, 21 Jul 2006 06:19:08 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3s3n-0005Pq-VY for syslog@ietf.org; Fri, 21 Jul 2006 06:16:45 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 550CE27C065; Fri, 21 Jul 2006 12:11:45 +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 29257-07; Fri, 21 Jul 2006 12:11:45 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0899127C061; Fri, 21 Jul 2006 12:11:44 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 12:16:42 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] delineated datagramswasdraft-ietf-syslog-transport-tls-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jul 2006 12:16:28 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174CC2@grfint2.intern.adiscon.com> In-Reply-To: <00b401c6acac$5e59e5a0$8c0c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] delineated datagramswasdraft-ietf-syslog-transport-tls-01.txt thread-index: AcaUjzSUvTEyQOf2ReyXqKuPnkIuJwYGjHEAAAFMJFA= From: "Rainer Gerhards" To: "Miao Fuyou" , "Tom Petch" , X-OriginalArrivalTime: 21 Jul 2006 10:16:42.0054 (UTC) FILETIME=[C2E25E60:01C6ACAE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Miao, I agree with your comments. However, using the LF as a record delimited would still allow us to interop with existing syslog/tls implementations. This is my major point. I think it is worth it. Rainer=20 > -----Original Message----- > From: Miao Fuyou [mailto:miaofy@huawei.com]=20 > Sent: Friday, July 21, 2006 12:00 PM > To: 'Tom Petch'; syslog@ietf.org > Subject: RE: [Syslog] delineated=20 > datagramswasdraft-ietf-syslog-transport-tls-01.txt >=20 >=20 > TLS uses SHA-1 or MD5 in ciphersuite for message integrity=20 > verification. If > bytes lost happens during transferring, the message will be=20 > dropped by TLS. > That is also the cause that we need a security mechanism for Syslog. =20 >=20 > As for error of encoding/decoding, I believe if an application does > encoding/decoding in a wrong way, you must not expect it do=20 > it right with > other mechanism, such as LF.=20 >=20 > Redundancy to improve robustness is good idea, but I don't=20 > think it applies > to this case. >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Tuesday, June 20, 2006 8:43 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] delineated datagrams=20 > > wasdraft-ietf-syslog-transport-tls-01.txt > >=20 > > I wonder if others share my concern about the lack of=20 > > robustness in the way in which datagrams are delineated in=20 > > the stream protocol (a TCP rather than a TLS issue). > >=20 > > The system works as long as > > - the frame length is encoded perfectly > > - the frame length is decoded perfectly > > - no bytes are inserted or removed in error which is=20 > > doubtless true in some networks, but I would prefer not to=20 > rely on it. > >=20 > > So, when an error occurs, can the Collector/Relay detect it? =20 > > Can the Collector/Relay recover synch? If not, what does the=20 > > Collector/Relay do? > >=20 > > There is very little redundancy in the definition of frame=20 > > length, and syslog messages have very little structure to=20 > > help the application, so I think that this is an issue we=20 > > should address. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Tuesday, May 09, 2006 4:26 PM > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > >=20 > >=20 > > Hi, > >=20 > > A new revision of the syslog/TLS draft is available. > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > .txt > >=20 > > We need reviewers. > > Can we get > > 1) a person to check the grammar? > > 2) a person to check the syslog technical parts? > > 3) a person to check compatibility with the other WG documents? > > 4) a person to check the TLS technical parts? > >=20 > > We also need general reviews of the document by multiple people. > >=20 > > Thanks, > > David Harrington > > co-chair, Syslog WG > > ietfdbh@comcast.net > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Mon Jul 24 09:33:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50Yz-0005E5-Je; Mon, 24 Jul 2006 09:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50Yy-0005E0-2C for syslog@ietf.org; Mon, 24 Jul 2006 09:33:36 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G50Yx-0007yC-3i for syslog@ietf.org; Mon, 24 Jul 2006 09:33:36 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00MQLTQQ7A@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 24 Jul 2006 21:35:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00M3DTQQYO@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 24 Jul 2006 21:35:14 +0800 (CST) Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W005Q7TR8EU@szxml03-in.huawei.com> for syslog@ietf.org; Mon, 24 Jul 2006 21:35:35 +0800 (CST) Date: Mon, 24 Jul 2006 21:32:44 +0800 From: Miao Fuyou Subject: RE: [Syslog] delineated datagrams In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174CC2@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , 'Tom Petch' , syslog@ietf.org Message-id: <00f801c6af25$a5423c30$8c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaUjzSUvTEyQOf2ReyXqKuPnkIuJwYGjHEAAAFMJFAAnWQIUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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, Rainer, Interop is a compelling reason for protocol design, so I tend to agree with you that it is a feature nice to have. I am wondering whether we should define procedures for frame delineating processing in syslog-tls draft because we have both octect-counter and LF in a record. Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, July 21, 2006 6:16 PM > To: Miao Fuyou; Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] delineated > datagramswasdraft-ietf-syslog-transport-tls-01.txt > > Miao, > > I agree with your comments. However, using the LF as a record > delimited would still allow us to interop with existing > syslog/tls implementations. This is my major point. I think > it is worth it. > > Rainer > > > -----Original Message----- > > From: Miao Fuyou [mailto:miaofy@huawei.com] > > Sent: Friday, July 21, 2006 12:00 PM > > To: 'Tom Petch'; syslog@ietf.org > > Subject: RE: [Syslog] delineated > > datagramswasdraft-ietf-syslog-transport-tls-01.txt > > > > > > TLS uses SHA-1 or MD5 in ciphersuite for message integrity > > verification. If bytes lost happens during transferring, > the message > > will be dropped by TLS. > > That is also the cause that we need a security mechanism > for Syslog. > > > > As for error of encoding/decoding, I believe if an application does > > encoding/decoding in a wrong way, you must not expect it do > it right > > with other mechanism, such as LF. > > > > Redundancy to improve robustness is good idea, but I don't > think it > > applies to this case. > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Tuesday, June 20, 2006 8:43 PM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] delineated datagrams > > > wasdraft-ietf-syslog-transport-tls-01.txt > > > > > > I wonder if others share my concern about the lack of > robustness in > > > the way in which datagrams are delineated in the stream > protocol (a > > > TCP rather than a TLS issue). > > > > > > The system works as long as > > > - the frame length is encoded perfectly > > > - the frame length is decoded perfectly > > > - no bytes are inserted or removed in error which is > doubtless true > > > in some networks, but I would prefer not to > > rely on it. > > > > > > So, when an error occurs, can the Collector/Relay detect it? > > > Can the Collector/Relay recover synch? If not, what does the > > > Collector/Relay do? > > > > > > There is very little redundancy in the definition of > frame length, > > > and syslog messages have very little structure to help the > > > application, so I think that this is an issue we should address. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > > > > > > > Hi, > > > > > > A new revision of the syslog/TLS draft is available. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > .txt > > > > > > We need reviewers. > > > Can we get > > > 1) a person to check the grammar? > > > 2) a person to check the syslog technical parts? > > > 3) a person to check compatibility with the other WG documents? > > > 4) a person to check the TLS technical parts? > > > > > > We also need general reviews of the document by multiple people. > > > > > > Thanks, > > > David Harrington > > > co-chair, Syslog WG > > > ietfdbh@comcast.net > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > > _______________________________________________ > > 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 Mon Jul 24 17:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G584f-0000aZ-T5; Mon, 24 Jul 2006 17:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G584e-0000Zs-Mt for syslog@ietf.org; Mon, 24 Jul 2006 17:34:48 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G584d-000229-Fn for syslog@ietf.org; Mon, 24 Jul 2006 17:34:48 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc14) with SMTP id <2006072421344601400908ege>; Mon, 24 Jul 2006 21:34:47 +0000 From: "David Harrington" To: Date: Mon, 24 Jul 2006 17:33:25 -0400 Message-ID: <049101c6af68$cbcff160$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcavaHxcBjVXiitPQ36K4w8lUvbFGg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Syslog] Internet-draft sources 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, As WG co-chair, I like to have a copy of the sources for all the WG's documents, just in case we lose contact with the author/editor. Can the primary editor for each document please send me a copy of the sources for either the last published revision, or your latest current sources, or both? If you are using nroff macros, makefiles, xml2rfc external entities, etc., please send me and/or Chris the files needed to reproduce the WG internet-drafts. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jul 24 18:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59Ia-0003Oo-Dr; Mon, 24 Jul 2006 18:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G59IZ-0003Oj-LE for syslog@ietf.org; Mon, 24 Jul 2006 18:53:15 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G59IY-0002zt-ED for syslog@ietf.org; Mon, 24 Jul 2006 18:53:15 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060724225313b110090dfue>; Mon, 24 Jul 2006 22:53:13 +0000 From: "David Harrington" To: Date: Mon, 24 Jul 2006 18:51:51 -0400 Message-ID: <04a201c6af73$c1244f80$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acavb1CjvKlkxlZpQGy50xyxtvwdyA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Syslog] Syslog MIB document 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, The syslog MIB document has now been declared "dead" and is no longer available from the i-d repository. This is rather unfortunate since it is a milestone in our charter to deliver this. Can we get a new revision posted please so everybody can access it? The WG needs to make a decision about whether the syslog MIB document is what the WG wants. I have seen some feedback that the mib does not provide the management desired. At this point, we need to decide if this document represents WG consensus or not, and, if not, then we need to plan to work on it. Chris is unavailable this week. I believe that Chris required a stuckee for reviews for each document in the new charter. Who was the stuckee for the MIB document review? Can we please get a review of the document? Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jul 25 15:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Suw-0006k7-1P; Tue, 25 Jul 2006 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Suv-0006ja-BU; Tue, 25 Jul 2006 15:50:09 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Sut-0007lQ-00; Tue, 25 Jul 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PJo1p0005471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 19:50:06 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5Sun-0002ic-NC; Tue, 25 Jul 2006 15:50:01 -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: Tue, 25 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-08.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 : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-08.txt Pages : 34 Date : 2006-7-25 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-08.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-device-mib-08.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-device-mib-08.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: <2006-7-25123019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-25123019.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 Tue Jul 25 17:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U9q-0003Kw-7h; Tue, 25 Jul 2006 17:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5U9o-0003Km-Rd for syslog@ietf.org; Tue, 25 Jul 2006 17:09:36 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5U9n-0005OZ-J8 for syslog@ietf.org; Tue, 25 Jul 2006 17:09:36 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Z007LA9APUX@usaga01-in.huawei.com> for syslog@ietf.org; Tue, 25 Jul 2006 14:06:26 -0700 (PDT) Received: from Harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net [24.61.222.235]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Z004RR9AOCA@usaga01-in.huawei.com> for syslog@ietf.org; Tue, 25 Jul 2006 14:06:25 -0700 (PDT) Date: Tue, 25 Jul 2006 17:08:11 -0400 From: David Harrington To: syslog@ietf.org Message-id: <059801c6b02e$7046cc30$0400a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcawJBXwACRejnEITG663escatrXpAACaXsQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.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 Hi, I had draft-ietf-syslog-device-mib-08.txt resurrected. Please review this document to determine if it needs additional work or not, so we can plan to get the work completed by the November deadline. Thanks, David Harrington ietfdbh@comcast.net co-chair, Syslog WG -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org] Sent: Tuesday, July 25, 2006 3:50 PM To: Glenn M. Keeni Cc: David Harrington; Chris Lonvick; Sam Hartman; Steven Bellovin Subject: Posting of draft-ietf-syslog-device-mib-08.txt As you requested, draft-ietf-syslog-device-mib-08.txt, an updated version of an expired Internet-Drafts, has been posted. The draft will expire on January 26, 2007 unless it is replaced by an updated version, or the Secretariat has been notified that the document is under official review by the IESG or has been passed to the RFC Editor for review and/or publication as an RFC. The IETF Secretariat. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jul 25 18:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vbp-0004IW-N1; Tue, 25 Jul 2006 18:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Vbo-0004IQ-9C for syslog@ietf.org; Tue, 25 Jul 2006 18:42:36 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Vbn-0006jM-0m for syslog@ietf.org; Tue, 25 Jul 2006 18:42:36 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc11) with SMTP id <20060725224234b1100o0350e>; Tue, 25 Jul 2006 22:42:34 +0000 From: "David Harrington" To: "'David Harrington'" , Subject: RE: [Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.txt Date: Tue, 25 Jul 2006 18:41:11 -0400 Message-ID: <05ab01c6b03b$6e4f07f0$0400a8c0@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: <059801c6b02e$7046cc30$0400a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcawJBXwACRejnEITG663escatrXpAACaXsQAAMzDKA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Whoops. I apparently did not get the draft resurrected; Glenn posted a new revision. Thanks Glenn. Please review this document to determine if it needs additional work or not, so we can plan to get the work completed by the November deadline. dbh > -----Original Message----- > From: David Harrington [mailto:dharrington@huawei.com] > Sent: Tuesday, July 25, 2006 5:08 PM > To: syslog@ietf.org > Subject: [Syslog] FW: Posting of draft-ietf-syslog-device-mib-08.txt > > Hi, > > I had draft-ietf-syslog-device-mib-08.txt resurrected. > > Please review this document to determine if it needs additional work > or not, so we can plan to get the work completed by the November > deadline. > > Thanks, > David Harrington > ietfdbh@comcast.net > co-chair, Syslog WG > > -----Original Message----- > From: IETF Secretariat [mailto:ietf-secretariat-reply@ietf.org] > Sent: Tuesday, July 25, 2006 3:50 PM > To: Glenn M. Keeni > Cc: David Harrington; Chris Lonvick; Sam Hartman; Steven Bellovin > Subject: Posting of draft-ietf-syslog-device-mib-08.txt > > As you requested, draft-ietf-syslog-device-mib-08.txt, an updated > version of an > expired Internet-Drafts, has been posted. The draft will expire on > January 26, > 2007 unless it is replaced by an updated version, or the Secretariat > has been > notified that the document is under official review by the IESG or has > been > passed to the RFC Editor for review and/or publication as an RFC. > > The IETF Secretariat. > > > _______________________________________________ > 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