From syslog-bounces@lists.ietf.org Sun Oct 01 16:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU7gN-0000Wy-SV; Sun, 01 Oct 2006 16:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU7gM-0000Wr-F4 for syslog@ietf.org; Sun, 01 Oct 2006 16:13:02 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU7gL-0007pk-0U for syslog@ietf.org; Sun, 01 Oct 2006 16:13:02 -0400 Received: from pc6 (1Cust38.tnt30.lnd3.gbr.da.uu.net [62.188.122.38]) by astro.systems.pipex.net (Postfix) with SMTP id 3F43EE000187; Sun, 1 Oct 2006 21:12:43 +0100 (BST) Message-ID: <028f01c6e58c$b82ee120$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" References: <023f01c6d5b0$c7ebaf30$0400a8c0@china.huawei.com> <004001c6e307$caa31740$0601a8c0@pc6> <451E075C.7090208@cysols.com> Subject: Re: [Syslog] Working Group Last Call: syslog-mib document Date: Sun, 1 Oct 2006 20: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: 8de5f93cb2b4e3bee75302e9eacc33db 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 ----- Original Message ----- From: "Glenn M. Keeni" To: "tom.petch" Cc: Sent: Saturday, September 30, 2006 7:57 AM Subject: Re: [Syslog] Working Group Last Call: syslog-mib document > Tom, > Your observation is correct. I guess that other MIBs deal with > entities which are essentially singleton in the context of a host. > An SNMP agent on the host services the information rquired to > monitor "the" entity. > Some entities may not be singleton - syslog is one of them. The > syslog MIB nicely takes care of this case. It can service multiple > syslog daemons. For example, one can ask > - how many syslog messages were received by the experimental > syslogd that I am running on UDP port 10512? > - how many syslog messages were received by the standard > syslogd that I am running on TCP port 512 ? > etc. > > I think that this is a very nice feature. Am I missing something? No, you are missing nothing; I am just stating the obvious:-) I state it because, for me, it makes the MIB I-D stand out as something different, not like the other syslog I-Ds, and balancing the benefits of this feature against the costs of differentness (and the additional complexity in the MIB given that SMIv2 does not handle tables very well) I would prefer to give it up. So I raised the issue. Tom Petch > > Glenn > > tom.petch wrote: > > I have looked at this I-D and appreciate the increased explanation at the > > beginning. It leaves me clearer, but still thinking that this document steers a > > different course to the other syslog ones, in its focus on a group of syslog > > entities. It's not that there cannot be more than one syslog entity running in > > a given host, just that bundling them together into a table seems an artificial > > complication; other syslog MIB modules I see are scalar in approach. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "David B Harrington" > > To: > > Sent: Monday, September 11, 2006 4:44 PM > > Subject: [Syslog] Working Group Last Call: syslog-mib document > > > > > >> Hi, > >> > >> This message officially starts the Syslog Working Group Last Call for > >> the following document: > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > >> t > >> > >> The Working Group Last Call for this document will end September 25. > >> > >> To help get these document reviewed throughly, we are seeking > >> volunteers to review the documents for the following special reviews: > >> 1) Spelling and grammar, > >> 2) boilerplates and reference review, > >> 3) security review > >> > >> The chairs want to see a minimum number of content reviews before we > >> submit the documents to the IESG. If you review the document and it > >> looks fine, please post a statement that you have reviewed and found > >> the document acceptable. Obviously, if it does not look acceptable > >> please identify your objections, preferably with suggested text that > >> would make it acceptable. > >> > >> Thanks, > >> David Harrington > >> dharrington@huawei.com > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> co-chair, Syslog WG > > > > > > _______________________________________________ > > 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 Oct 02 15:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTO7-0002lg-P7; Mon, 02 Oct 2006 15:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTO6-0002la-Ra for syslog@lists.ietf.org; Mon, 02 Oct 2006 15:23:38 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUTO5-00046X-Js for syslog@lists.ietf.org; Mon, 02 Oct 2006 15:23:38 -0400 Received: (qmail 57982 invoked by uid 0); 2 Oct 2006 15:23:37 -0400 Received: from 209.123.118.212 by smtp-out1.oct (envelope-from , uid 0) with qmail-scanner-1.25 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1(209.123.118.212):. Processed in 0.298245 secs); 02 Oct 2006 19:23:37 -0000 Received: from unknown (HELO webmail.nac.net) (209.123.118.212) by smtp-out1.oct.nac.net with SMTP; 2 Oct 2006 15:23:36 -0400 Received: from 67.83.27.139 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Mon, 2 Oct 2006 15:23:37 -0400 (EDT) Message-ID: <33100.67.83.27.139.1159817017.squirrel@webmail.nac.net> Date: Mon, 2 Oct 2006 15:23:37 -0400 (EDT) From: rfgraveman@nac.net To: syslog@lists.ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Syslog] review of draft-ietf-syslog-protocol-17 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 reviewed this draft and believe it is in good shape and reflects the discussions on the list and consensus of the working group. After one more round, it should IMO be ready to go to the AD. In addition to or in agreement with the other review comments that have been posted, I sent some editorial comments to the author and also made a couple of small comments about: 1. replacing the reference to 3513 with 4291 2. clarifying the text about when UTF-8 versus "plain ASCII" is present in a SD-PARAMs versus the MSG 3. simplifying the overloaded use of HOSTNAME, Hostname, and hostname in Section 6.2.4. The details are below. Rich Graveman ------------------ If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [4]. If an IPv6 address is used, a valid textual representation described in RFC 3513 [10], Section 2.2, MUST be used. * RFC 4291 (DS) obsoletes 3513. Section number 2.2 is still correct. -------------------from 6.2.4 The NILVALUE SHOULD only be used when the sender has no way to obtain its real hostname. This situation is considered highly unlikely. * We now have HOSTNAME, Hostname, and hostname. Maybe just: * s/its real hostname/any of the names or addresses listed above/ -------------------from 6.4 If a sender encodes MSG in UTF-8, the string MUST start with the * s/MSG/a MSG with international characters/ * Comment: Above, if I am correct, the SD-PARAM MUST be encoded in UTF-8, * even though the examples show "plain ASCII." Technically, this is * correct, becasue plain ASCII is legal UTF-8. But here, plain-ASCII * UTF-8 should not require a BOM. Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The sender SHOULD also include an "meta" SD-ID with an "enc" parameter within the STRUCTURED-DATA. The sender MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence. If a receiver receives MSG starting with a BOM, it MUST assume UTF-8 encoding. For the reasons outlined in UNICODE TR36 [13], section 3.1, a receiver MUST NOT interpret messages in the "non-shortest form". It MUST NOT interpret invalid UTF-8 sequences. If a sender does not encode MSG in UTF-8, the string MUST NOT start with the Unicode BOM. If MSG is not encoded in UTF-8, the sender MAY use any other encoding (including binary data). * If the above comment makes sense, then turn it around and say: * If the MSG string starts with the Unicode BOM, then it MUST be interpreted * as UTF-8. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 02 18:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW4S-0001cA-PW; Mon, 02 Oct 2006 18:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUW4S-0001c5-FW for syslog@ietf.org; Mon, 02 Oct 2006 18:15:32 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUW4Q-0003Yu-Nl for syslog@ietf.org; Mon, 02 Oct 2006 18:15:32 -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 k92MFQm9022023 for ; Tue, 3 Oct 2006 07:15:27 +0900 (JST) Received: from [127.0.0.1] (kiras5.priv.cysol.co.jp [192.168.0.155]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k92MFP5x024377 for ; Tue, 3 Oct 2006 07:15:26 +0900 (JST) Message-ID: <45218F7E.8050007@cysols.com> Date: Tue, 03 Oct 2006 07:15:26 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: syslog@ietf.org Subject: [Syslog] WGLC results : Syslog-MIB References: <099201c6e406$7cb57000$0600a8c0@china.huawei.com> In-Reply-To: <099201c6e406$7cb57000$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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, The status of the draft is attached. Glenn Current draft: draft-ietf-syslog-device-mib-09.txt ( September 3, 2006) Comments: Editorial: None Closed Issues: 1. Comment: Tables in the MIB to serve "groups of" syslog entities look different in focus from the other syslog protocols o Reference Re: [Syslog] Working Group Last Call: syslog-mib document Tom Petch [2006/09/28 23:05] o Action: explained the usage and necessity of the tables to serve a group of syslog entities o Status: I think that the issue is closed. Open Issues: 1. Comments: should anything on syslog-sign be added? o Reference RE: [Syslog] MIB document decision Alexander Clemm [2006/09/21 6:47] o Action: sent back the question to the WG o Status: The Syslog-sign related module may be added now or later ( in a separate document, after a few implementations and some experience). If the working group does want it to be in this document, we will do it. Glenn David Harrington wrote: > Hi, > > Will the editors of the WGLC'd documents please collect the comments > made for each of your documents into a single document, preferably > text, and indicate what was done in the document to address the issue > raised. > > Send the summary document to the chairs, with a copy of your current > in-process document containing the fixes thus far, so the chairs can > review your fixes. Once we have reviewed the fixes, we may ask for > some changes. Then we will have you publish a new I-D, which we will > send to the WG. > > It would be good to separate the issues document into three sections: > > 1) purely editorial issues (spelling, grammar, etc.) > > 2) Closed issues > > Technical issues where consensus was obvious. For each issue, please > describe who raised the issue, and how the document was changed to > address the issue. The chairs will review the changes to make sure > they represent what the chairs consider to be WG consensus. > > 3) Open issues > > Technical issues where the resolution is unclear. Please identify who > raised the issue. If you have a proposed fix, please describe it. The > chairs will review the issues and determine whether it is an issue > that needs resolution, whether your proposal is acceptable and in > keeping with WG consensus, or whether it needs to be discussed further > by the WG. > > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Oct 03 14:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpMe-0005kh-Ff; Tue, 03 Oct 2006 14:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpMd-0005kc-2W for syslog@lists.ietf.org; Tue, 03 Oct 2006 14:51:35 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUpMZ-00053V-Qg for syslog@lists.ietf.org; Tue, 03 Oct 2006 14:51:35 -0400 Received: (qmail 2329 invoked by uid 0); 3 Oct 2006 14:51:28 -0400 Received: from 209.123.118.212 by smtp-out2.oct (envelope-from , uid 0) with qmail-scanner-1.25 (clamdscan: 0.88.2/1523. f-prot: 4.6.6/3.16.14. Clear:RC:1(209.123.118.212):. Processed in 0.316115 secs); 03 Oct 2006 18:51:28 -0000 Received: from unknown (HELO webmail.nac.net) (209.123.118.212) by smtp-out2.oct.nac.net with SMTP; 3 Oct 2006 14:51:28 -0400 Received: from 67.83.27.139 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Tue, 3 Oct 2006 14:51:29 -0400 (EDT) Message-ID: <32861.67.83.27.139.1159901489.squirrel@webmail.nac.net> In-Reply-To: <33100.67.83.27.139.1159817017.squirrel@webmail.nac.net> References: <33100.67.83.27.139.1159817017.squirrel@webmail.nac.net> Date: Tue, 3 Oct 2006 14:51:29 -0400 (EDT) From: rfgraveman@nac.net To: syslog@lists.ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Syslog] review of draft-ietf-syslog-transport-udp-07 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 reviewed this draft and found it well written and complete. I believe it is ready for publication. I had only one minor suggestion upon reading the text: In the section on out-of-order delivery, one may mention using the meta Structured Data sequenceId, if present, as well as time stamps. Rich Graveman _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Oct 09 10:32:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw9r-0004Lq-Ir; Mon, 09 Oct 2006 10:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWw7u-0002sO-MW for syslog@ietf.org; Mon, 09 Oct 2006 10:29:06 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWw7q-0001o9-8X for syslog@ietf.org; Mon, 09 Oct 2006 10:29:06 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k99ESuDr027610 for ; Mon, 9 Oct 2006 09:28:57 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Oct 2006 16:28:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550ACC0421@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: syslog@ietf.org Date: Mon, 9 Oct 2006 16:28:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:31:06 -0400 Cc: Subject: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-protocol-17.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 David Harrington (co-chair of the Syslog WG) specifically asked me for a review of documents in WG Last Call. I am not subscribed to the SYSLOG WG mailing list, so pls copy me explicitly on any reactions that you want me to see. Bert ----- draft-ietf-syslog-protocol-17.txt I see: 4.1. Example Deployment Scenarios Sample deployment scenarios are shown in Diagram 1. Other arrangements of these examples are also acceptable. As noted, in the following diagram, relays may pass along all or some of the messages >> that they receive and also pass along messages that they generate internally. The boxes represent syslog-enabled applications. I would change "pass along" into "send". The "pass along" to me sounds as if the message was received from someone else to beging with. table 1 on page 12 refers to "(note 1)" and "(note 2)" I cannot find these notes. Is that just me? Section 6.2.4 states, page 16, 2nd para: Senders SHOULD consistently use the same value in the HOSTNAME field for as long as possible. If the sender is multihomed, this value SHOULD be one of its actual IP addresses. If a sender is running on So does that mean that this "SHOULD" overwrites an earlier "SHOULD" in the 2nd para of section 6.2.4 on page 15: The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [3]. This format is called a Fully Qualified Domain Name (FQDN) in this document. To me it is unclear what I SHOULD do in case I am a multihomed system while I do have a FQDN available. I see in the ABNF specification: APP-NAME = NILVALUE / 1*48PRINTUSASCII And I see in section 6.2.5: 6.2.5. APP-NAME The APP-NAME field SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. I find the latter misleading. Because ABNF mandates PRINTUSASCII, and applications these days very often may have internationalized names that cannot easily be represented in PRINTUSASCII. What are implementers supposed/expected to do in that case? I see in the ABNF specification: PROCID = NILVALUE / 1*128PRINTUSASCII and in section 6.2.6 I see: 6.2.6. PROCID The PROCID field SHOULD be used to provide the sender's process name or process ID. The field does not have any specific syntax. So that last sentence is not very accurate I think. To me it means that if the process ID, that I must translate it to PRINTUSASCII. Merging the ABNF and the last sentence that says it does not have any syntax, I guess I can convert it to hexaxdecimal, or to decimal or some such as long as I represent it in PRINTUSASCII. I get confused by the 2nd para of section 6.4: The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 as specified in RFC 3629 [6]. If the sender can not encode the MSG in Unicode, it MAY use any other encoding. What exactly does that mean for the on-the-wire data? And in sect 64. in last para: If a receiver receives MSG not starting with a BOM, then the encoding of the content is implementation specific and it is RECOMMENDED that no assumption be made about the encoding of the content. So what is a receiver expecter and/or allowed to do? I guess a receiver MAY decide to discard the message? I think that in section 7.2.2 I would point to http://www.iana.org/cgi-bin/mod_ent.pl instead of just www.iana.org for the online form. It is not always so easy to find (specifically for novices). Further in section 7.2.2. I see: . Only that number and any-enterprise assigned ID below it MUST be specified in the "enterpriseId" parameter. If sub-identifiers are used, they MUST be separated by periods and be represented as decimal numbers ("9.1.30" and "11.2.3.7.5.12"). The I understand that the decimal numbers listed are examples. But I would still add a note/warning that these are indeed just examples and should not be used as is, the enterprise-IDs 9 and 11 respectively belong to PSI and HP respectively. And the actual numbers might even represent sometging totally different (maybe a MIB OID or an LDAP OID or some such). In sect 7.2.4 I see: The "software" parameter is a string. It MUST NOT be longer than 48 characters. If I understand it correctly, then the value has to be in UTF-8. And in that context, it is not clear if a "character" is one octet or multiple octets. I think you mean that the length of the value can be max 49 octets? If so, then I would use "octets" instead of "characters". Pls do realize that in some languages, 48 Octets may be just 6 "characters". Same for various other parameters In sect 8.5 I see: It may also be desirable to include rate-limiting features in syslog senders. This can reduce potential congestion problems when message bursts happen. Mmm... I know that the transport area (TSV) is very keen on MANDATING some sort of rate limiting on such UDP packet originators. So I would not be surprised if this gets brought up when this doc comes to IETF wide last call or to IESG review. Maybe we should say something about a max sending rate for UDP. I see a (normative) reference to ABNF RFC 2234, and note that 2234 has been obsoleted by RFC 4234. So I'd think that referencing the newer RFC is probably the right thing to do. Bert ----------- original review message: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt > > > > > > Transmission of syslog messages over UDP > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > > > .txt > > > > > > TLS Transport Mapping for SYSLOG > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > > > .txt > > > > > > Syslog Management Information Base > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > > > t > > > > > > Signed syslog Messages > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > > > (We expect this document to be updated this week.) > > > > > > 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 Oct 10 05:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpx-0003QT-6m; Tue, 10 Oct 2006 05:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpv-0003KR-G5 for syslog@ietf.org; Tue, 10 Oct 2006 05:23:43 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDpu-0003CJ-6c for syslog@ietf.org; Tue, 10 Oct 2006 05:23:43 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k9A9NZSn019140; Tue, 10 Oct 2006 04:23:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Oct 2006 11:23:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: syslog@ietf.org Date: Tue, 10 Oct 2006 11:23:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "Dan Romascanu \(E-mail\)" Subject: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-transport-tls-03.tx t 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 -----Original Message----- From: Wijnen, Bert (Bert) Sent: Monday, October 09, 2006 16:29 To: syslog@ietf.org Subject: RE: Request for Reviewers - draft-ietf-syslog-protocol-17.txt David Harrington (co-chair of the Syslog WG) specifically asked me for a review of documents in WG Last Call. I am not subscribed to the SYSLOG WG mailing list, so pls copy me explicitly on any reactions that you want me to see. I am not a security expert, and this WG is in the Security Area, so I am assuming that the security aspects are well reviewed by the respected WG members or colleagues in the SEC area. I also have a common/generic question: The ISMS and NETCONF WGs have defined as manadatory to implement SNMP-over-SSH and NETCONF-over-SSH. I think it would be really really good/best if the SYSLOG WG would also define a mandatory to implement SYSLOG-over-SSH, so that operators can use one and the same security infrastructure for the operational management and monitoring of their systems. In other words, I find it a pitty that the WG charted work-item: - A document will be produced that requires a secure transport for the delivery of syslog messages. Did not result in a mapping over SSH. Bert ----- draft-ietf-syslog-transport-tls-03.txt I am not sure I understand what this means (sect 4, last para): The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. I thought the porimary goal was to secure messages from draft-ietf-syslog-protocol-17 but I don;t see that mentioned in sect 4. Bert ----------- original review message: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt > > > > > > Transmission of syslog messages over UDP > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > > > .txt > > > > > > TLS Transport Mapping for SYSLOG > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > > > .txt > > > > > > Syslog Management Information Base > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > > > t > > > > > > Signed syslog Messages > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > > > (We expect this document to be updated this week.) > > > > > > 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 Oct 10 05:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpu-0003Gq-QR; Tue, 10 Oct 2006 05:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpt-0003E1-Q0 for syslog@ietf.org; Tue, 10 Oct 2006 05:23:41 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDpt-0003AR-83 for syslog@ietf.org; Tue, 10 Oct 2006 05:23:41 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k9A9NZbL019139 for ; Tue, 10 Oct 2006 04:23:37 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Oct 2006 11:23:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: syslog@ietf.org Date: Tue, 10 Oct 2006 11:23:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: Subject: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.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 David Harrington (co-chair of the Syslog WG) specifically asked me for a review of documents in WG Last Call. I am not subscribed to the SYSLOG WG mailing list, so pls copy me explicitly on any reactions that you want me to see. Bert ----- draft-ietf-syslog-device-mib-09.txt First some SMICng error messages resulting from syntax checking: C:\bwijnen\smicng\work>smicng syslog.inc W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not a valid extended UTC time E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be "number" or "name(number)" format W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row "syslEntOpsEntry" should have related names W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row "syslEntCtlEntry" should have related names E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create *** 4 errors and 3 warnings in parsing I see on page 3, sect 2: status or the occurence of events. These messages are handled by what has come to be known as the syslog application[RFCPROT] or device [RFC3164]. In this document we refer to a syslog application or Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application" or a "devie", are they? I see on page 5: The SyslogMIB module uses textual conventions defined in INET- ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP- FRAMEWORK-MIB[RFC3411]. I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419 and not in RFC4001. Page 6: LAST-UPDATED "200511250000Z" -- 25th November, 2005 While in the DESCRIPTION clause you have a copyright of 2006!!?? Further it is in conflict with the latest revision clause REVISION "200609R04000Z" -- 9th September, 2006 AND... that one has an R in there that is not valid either. Page 6: Copyright (C) The Internet Society (2006). The initial version of this MIB module was published in RFC yyyy; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html. " -- RFC Ed.: replace XXXX with the actual RFC number & remove this -- note I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync with the RFCEd. note. Further, I do NOT think that the copyrights for iana maintained MIB modules is applicable here. I think you picked up the incorrect template for MIB copyright. So probably you need to use: Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." The read-write objects under syslogSystem MUST add text to the DESCRIPTION clauses that state the expected persistency behaviour. For syslogDefaultTransport OBJECT-TYPE SYNTAX TransportAddressType I wonder how you represent syslog-transport over tls. I guess you could use "unknown" but that seems not very satisfactory. You could use one of the tcp transports I guess, but you would loose the info about the fact that it is over tls, no? Same question of course for syslEntCtlTransport object. >From the DESCRIPTION clause of syslEntOpsTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslDevOpsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing information about the syslog entities serviced by an SNMP agent. I cannot see why the "Ops" string is in the name??? It is OK if that is what the WG wants, but personally, I would rather name it syslogEntityTable which seems a much more meaningfull name. For syslEntCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslDevCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing static information about the syslog entity. " ::= { syslogDevice 2 } I think that in the description clause I would state that this table is to have control over the configuration of syslog Entities. I think I would name it syslogEntityCtlTable or syslogEntityControlTable I further note that I find it a naming inconsistency to use "sysl" as the prefix here instead of "syslog". This happens in the above 2 tables only. The rest of the MIB module nicely has syslog as prefix. I see: syslEntOpsTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslDevOpsEntry MAX-ACCESS not-accessible Normal practice is that the SEQUENCE OF would in tis case be: syslEntOpsTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslEntOpsEntry ^^^ Same story for: syslEntCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslDevCtlEntry For syslEntCtlEntry OBJECT-TYPE SYNTAX SyslDevCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The parameters pertaining to a syslog process." INDEX { syslEntOpsIndex } ::= { syslEntCtlTable 1 } I wonder if this is a sparse augmentation (it seems so because otherwise it might have been an AUGMENTs). I wonder though if this is intentional or accidental. I personally think I would have made this the base table and maybe used an AUGMENTS for the read-only (syslEntOpsTable). The Counter32 object in the syslEntOpsTable MUST specify if/when a discontinuity can occur and which timer indicates such discontinuity. Probably the only discontinuity is when the SNMP agent restarts, but I am not sure. If so it would be sysUptime that serves as the discontinuity timer. For: syslEntOpsLastMsgDeliveredTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The local time when the last message was delivered by the syslog process. " I would think it is better to say "was relayed or sent"? Because you do not actually know (in many cases) if the message indeed does get delivered to the other end, do you? For: syslEntOpsLastError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A description of the last error that was encountered by this process. " I am not sure I understand what "this process" is? Is it the agent (I guess not)? Is it the syslog entity? Or is it something else? For: syslEntOpsReference OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "If the Host resource MIB is serviced on the host then this entry will have the value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. Otherwise this object will be inaccessible, " First, I would change "is serviced" into "is instantiated" or "is supportted". Further I see that hrSWRunIndex is defined as: hrSWOSIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) So I would expect the SYNTAX for syslEntOpsReference to also be SYNTAX Integer32 (1..2147483647) But... The last sentence of the DESCRIPTION clause says: Otherwise this object will be inaccessible, (should have a period at the end instead of a comma by theway) and that is also something that is VERY UNCLEAR. Maybe a "nosuchInstance" exception would be better. Maybe the best is to define the object as: syslEntOpsReference OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If the Host resource MIB is instantiated on the host then this entry will have the value of the hrSWRunIndex of the corresponding entry in the hrSWRunTable. The special value of zero indicates that the Host resource MIB is not instantiated. " I see: syslEntCtlTable OBJECT-TYPE SYNTAX SEQUENCE OF SyslDevCtlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing static information about the syslog entity. " First I am not sure it is really static, because it allows to change the values. But in any event, I would describe that this table is intended to configure syslogEntities. For syslEntCtlProcDescr I wonder if this value is/can be used anywhere else. If yes, pls say something about it. For: syslEntCtlBindAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The specific IP address or hostname the syslog process will bind to. If a hostname is specified, the IPv4 or IPv6 address corresponding to the hostname will be used. " ::= { syslEntCtlEntry 3 } I am not sure what "if a hostname is specified..." means. If it is a FQDN, then the InetAddressType would be 'dns' And yoiu MUST specify when that name is resolved into an IP address. But probably you mean that if it is just some local hostname, that in that case an IPv4 or IPv6 address shoudl be specified. That is not 100% clear to me though. So pls clarify. You MUST also add some text that states that the format of this address is controlled by the value of the corresponding syslEntCtlBindAddrType object. For: syslEntCtlConfFileName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The fullpath name of the configuration file where the syslog entity's message selection and corresponding action rules will be read from. Data is loaded from this file into the syslogCtlSelectionTable and the syslogCtlLogActionTable. If the objects loaded from the file specified by this object have an access level of read-create, this file MUST be writable so that modifications to the corresponding objects, if any, will be effected in this file. If the system does not support the specification of a configuration file, this field will not be accessible. " DEFVAL { "/etc/syslog.conf" } ::= { syslEntCtlEntry 7 } I wonder where is/are the syslogCtlSelectionTable and the syslogCtlLogActionTable tables defined? I cannot find them so I am not sure what this means. I think that instead of If the system does not support the specification of a configuration file, this field will not be accessible. I would make this object a zero-length string. Much cleaner and much easier on both agent and NMS. For: syslEntCtlStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), started (2), suspended(3), stopped (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the process. " DEFVAL { unknown } What is "the process" ?? I think I would add a DEFVAL for syslEntCtlStorageType Any value that the WG feels appropriate is fine. For syslEntCtlRowStatus - s/iff/if/ - I am surprised to see that one needs to go to notInService state in order to change any column in the row. There are various that could very well be changed (maybe even all) while in active state. And such is much easier on both agent and manager. The two NOTIFICATIONs could easily be combined into a syslogEntitySTatusChanged NOTIFICATION-TYPE Just a minor optimization I guess I would think/hope that there is some relation between theobjects in the syslogSystemGroup and those in the syslogDevCtlGroup. For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize, then the maxmessagesize from syslogDefaultMaxMessageSize is used? But the DESCRIPTION clauses of the OBJCTS say nothing about this, so I am not sure how to determine which value to use when? I think I would change syslogCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB. " Into something like: syslogFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the SYSLOG-MIB with support for writable objects. Such an implentation can be both monitored and configured via SNMP. " I am not sure I completely understand the intent of syslogNotificationCompliance. Is it the idea that an implementation can claim compliance to just send notifications and nothing else? If so, you may want to make that clear. Even then, I think I would include the syslogNotificationGroup in both the other two MODULE-COMPLIANCE statements, so that if you support it all, you only have to claim compliance with a single MODULE-COMPLIANCE statement. On page 27 I see: Even if the network itself is secure (for example by using IPSec), I know that at least one of the SECURITY ADs will want you to s/IPSec/IPsec/. The latest MIB security template has the fix already in it. I see quite a few places where you use "MIB" while I think what you mean is the/a "MIB Module". I know this is a nit. Nevertheless, it seems you need to do a revision to at least fix the syntax errors, so might as well addres this. Bert ----------- original review message: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt > > > > > > Transmission of syslog messages over UDP > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > > > .txt > > > > > > TLS Transport Mapping for SYSLOG > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > > > .txt > > > > > > Syslog Management Information Base > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > > > t > > > > > > Signed syslog Messages > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > > > (We expect this document to be updated this week.) > > > > > > 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 Oct 10 05:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpx-0003PM-1H; Tue, 10 Oct 2006 05:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpu-0003Fi-I6 for syslog@ietf.org; Tue, 10 Oct 2006 05:23:42 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDpt-0003AO-83 for syslog@ietf.org; Tue, 10 Oct 2006 05:23:42 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k9A9NZbK019139 for ; Tue, 10 Oct 2006 04:23:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Oct 2006 11:23:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: syslog@ietf.org Date: Tue, 10 Oct 2006 11:23:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Syslog] FW: Request for Reviewers - draft-ietf-syslog-transport-udp-07.tx t 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 David Harrington (co-chair of the Syslog WG) specifically asked me for a review of documents in WG Last Call. I am not subscribed to the SYSLOG WG mailing list, so pls copy me explicitly on any reactions that you want me to see. Bert ----- draft-ietf-syslog-transport-udp-07.txt Seems fine to me. Two remarks - it may not be 100% clear that the reference [2] is to the new WG document: draft-ietf-syslog-protocol-17.txt - I hope it is OK with TSV area that there is no mandatory retae limiting in the number of syslog messages that can be sent. Bert ----------- original review message: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt > > > > > > Transmission of syslog messages over UDP > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > > > .txt > > > > > > TLS Transport Mapping for SYSLOG > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > > > .txt > > > > > > Syslog Management Information Base > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > > > t > > > > > > Signed syslog Messages > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > > > (We expect this document to be updated this week.) > > > > > > 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 Oct 10 09:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHxq-0002O9-9m; Tue, 10 Oct 2006 09:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHxp-0002Ny-KU for syslog@ietf.org; Tue, 10 Oct 2006 09:48:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHxo-00013f-5t for syslog@ietf.org; Tue, 10 Oct 2006 09:48:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2006 06:48:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9ADm6PM026345; Tue, 10 Oct 2006 06:48:06 -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 k9ADm6Ap011908; Tue, 10 Oct 2006 06:48:06 -0700 (PDT) Date: Tue, 10 Oct 2006 06:48:06 -0700 (PDT) From: Chris Lonvick To: "Wijnen, Bert (Bert)" Subject: syslog over ssh - was: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-transport-tls-03.tx t In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A5@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A5@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3834; t=1160488086; x=1161352086; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:syslog=20over=20ssh=20-=20was=3A=20[Syslog]=20RE=3A=20Request=20for=20Re viewers=20-=0A=20draft-ietf-syslog-transport-tls-03.tx=20t; X=v=3Dcisco.com=3B=20h=3DfjkE2H3ietvmk8J0xCIfw0X2Vco=3D; b=IY/OMEwqsT1mixAA9v2PTO3ySEb0U3I/eNY6tkFmPkZWGWCRzna09XzFc58cqk0+E+MPfZm/ PF30X1U+1cumnqZAgZmspFfHmlmql2y0AgGew1kuCgeZOWwOdj1g463v; 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: 2857c5c041d6c02d7181d602c22822c8 Cc: "Dan Romascanu \(E-mail\)" , 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 Bert, We appreciate your review of the document. As for syslog-over-ssh: We had been incontact with the ISMS and Netconf WGs and we did see that they had chosen SSH as a secure transport. We did discuss this within our own Working Group. The consensus was: - there are current implementations of syslog-over-ssl - ssh uses the concept that there is an interactive user which works well for ISMS and Netconf. However, syslog does not have a concept of a user but is more associated with the idea that this is an automated function of the device which works better with tls authentication mechanisms. With that said, I believe that there is interest from some members of the WG to pursue syslog-over-ssh and in fact, a starting point has been made with draft-gerhards-syslog-transport-ssh-00.txt We are under a tight timeline and since the topic has been discussed and agreed to in the past, we will complete the syslog-over-tls work. Thanks, Chris On Tue, 10 Oct 2006, Wijnen, Bert (Bert) wrote: > > > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Monday, October 09, 2006 16:29 > To: syslog@ietf.org > Subject: RE: Request for Reviewers - draft-ietf-syslog-protocol-17.txt > > > David Harrington (co-chair of the Syslog WG) specifically asked me > for a review of documents in WG Last Call. > > I am not subscribed to the SYSLOG WG mailing list, so pls copy > me explicitly on any reactions that you want me to see. > > I am not a security expert, and this WG is in the Security Area, so > I am assuming that the security aspects are well reviewed by the > respected WG members or colleagues in the SEC area. > > I also have a common/generic question: > > The ISMS and NETCONF WGs have defined as manadatory to implement > SNMP-over-SSH and NETCONF-over-SSH. > > I think it would be really really good/best if the SYSLOG WG would > also define a mandatory to implement SYSLOG-over-SSH, so that > operators can use one and the same security infrastructure for > the operational management and monitoring of their systems. > > In other words, I find it a pitty that the WG charted work-item: > > - A document will be produced that requires a secure transport > for the delivery of syslog messages. > > Did not result in a mapping over SSH. > > Bert > ----- draft-ietf-syslog-transport-tls-03.txt > > I am not sure I understand what this means (sect 4, last para): > > The security service is also applicable to BSD Syslog defined in > RFC3164 [7]. But, it is not ensured that the protocol specification > defined in this document is applicable to BSD Syslog. > > I thought the porimary goal was to secure messages from > draft-ietf-syslog-protocol-17 but I don;t see that mentioned in sect 4. > > Bert > > ----------- original review message: >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt >>>> >>>> Transmission of syslog messages over UDP >>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 >>>> .txt >>>> >>>> TLS Transport Mapping for SYSLOG >>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 >>>> .txt >>>> >>>> Syslog Management Information Base >>>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx >>>> t >>>> >>>> Signed syslog Messages >>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt >>>> (We expect this document to be updated this week.) >>>> >>>> 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 From syslog-bounces@lists.ietf.org Thu Oct 12 08:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXzuG-0008AV-Ic; Thu, 12 Oct 2006 08:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXzuF-00089z-0r for syslog@ietf.org; Thu, 12 Oct 2006 08:43:23 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXzuB-0007mk-E6 for syslog@ietf.org; Thu, 12 Oct 2006 08:43:23 -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 k9CChGm9005504; Thu, 12 Oct 2006 21:43:16 +0900 (JST) Received: from [127.0.0.1] (kiras2.priv.cysol.co.jp [192.168.0.152]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k9CChE5x001016; Thu, 12 Oct 2006 21:43:16 +0900 (JST) Message-ID: <452E3862.6040601@cysols.com> Date: Thu, 12 Oct 2006 21:43:14 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: Re: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-device-mib-09.txt References: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A3@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AD316A3@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 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 Bert, Thanks for the detailed review. Let me go through these and post a revised draft. I hope to make it before the 23rd cutoff. Cheers Glenn Wijnen, Bert (Bert) wrote: > David Harrington (co-chair of the Syslog WG) specifically asked me > for a review of documents in WG Last Call. > > I am not subscribed to the SYSLOG WG mailing list, so pls copy > me explicitly on any reactions that you want me to see. > > Bert > > ----- draft-ietf-syslog-device-mib-09.txt > > First some SMICng error messages resulting from syntax checking: > > C:\bwijnen\smicng\work>smicng syslog.inc > W: f(syslog.mi2), (47,17) REVISION value "200609R04000Z" is not > a valid extended UTC time > E: f(syslog.mi2), (97,15) Name of "auth" duplicates an existing one > E: f(syslog.mi2), (102,15) Name of "cron" duplicates an existing one > E: f(syslog.mi2), (54,20) Sub-Id for item "syslogMIB" must be > "number" or "name(number)" format > W: f(syslog.mi2), (245,4) Sequence "SyslDevOpsEntry" and Row > "syslEntOpsEntry" should have related names > W: f(syslog.mi2), (418,4) Sequence "SyslDevCtlEntry" and Row > "syslEntCtlEntry" should have related names > E: f(syslog.mi2), (418,4) Row "syslEntCtlEntry" may not have > columns with MAX-ACCESS of read-write if any column is read-create > > *** 4 errors and 3 warnings in parsing > > > I see on page 3, sect 2: > > status or the occurence of events. These messages are handled by what > has come to be known as the syslog application[RFCPROT] or device > [RFC3164]. In this document we refer to a syslog application or > > Mmm RFCPROT and RFC3164 are both a protocol spec, not an "application" > or a "devie", are they? > > I see on page 5: > > The SyslogMIB module uses textual conventions defined in INET- > ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC4001] and SNMP- > FRAMEWORK-MIB[RFC3411]. > > I believe that the TRANSPORT-ADDRESS-MIB is described in RFC3419 > and not in RFC4001. > > Page 6: > > LAST-UPDATED "200511250000Z" -- 25th November, 2005 > > While in the DESCRIPTION clause you have a copyright of 2006!!?? > > Further it is in conflict with the latest revision clause > REVISION "200609R04000Z" -- 9th September, 2006 > AND... that one has an R in there that is not valid either. > > Page 6: > Copyright (C) The Internet Society (2006). The initial > version of this MIB module was published in RFC yyyy; > for full legal notices see the RFC itself. Supplementary > information may be available at: > http://www.ietf.org/copyrights/ianamib.html. > " > -- RFC Ed.: replace XXXX with the actual RFC number & remove this > -- note > > I think the "RFC yyyy" should read "RFC XXXX" in order to bein sync > with the RFCEd. note. > Further, I do NOT think that the copyrights for iana maintained MIB > modules is applicable here. I think you picked up the incorrect > template for MIB copyright. So probably you need to use: > > Copyright (C) The Internet Society (2006). This version of this > MIB module is part of RFC XXXX; see the RFC itself for full > legal notices." > > > The read-write objects under syslogSystem MUST add text to the > DESCRIPTION clauses that state the expected persistency behaviour. > > For > syslogDefaultTransport OBJECT-TYPE > SYNTAX TransportAddressType > I wonder how you represent syslog-transport over tls. > I guess you could use "unknown" but that seems not very satisfactory. > You could use one of the tcp transports I guess, but you would loose > the info about the fact that it is over tls, no? > > Same question of course for syslEntCtlTransport object. > >>From the DESCRIPTION clause of > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevOpsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing information about the syslog entities > serviced by an SNMP agent. > > I cannot see why the "Ops" string is in the name??? > It is OK if that is what the WG wants, but personally, I would > rather name it > syslogEntityTable > which seems a much more meaningfull name. > > For > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing static information about > the syslog entity. > " > ::= { syslogDevice 2 } > > I think that in the description clause I would state that this table > is to have control over the configuration of syslog Entities. > I think I would name it > > syslogEntityCtlTable or syslogEntityControlTable > > > I further note that I find it a naming inconsistency to use "sysl" > as the prefix here instead of "syslog". This happens in the above > 2 tables only. The rest of the MIB module nicely has syslog as > prefix. > > I see: > > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevOpsEntry > MAX-ACCESS not-accessible > > Normal practice is that the SEQUENCE OF would in tis case be: > syslEntOpsTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslEntOpsEntry > ^^^ > Same story for: > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > > > For > syslEntCtlEntry OBJECT-TYPE > SYNTAX SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The parameters pertaining to a syslog process." > INDEX { syslEntOpsIndex } > ::= { syslEntCtlTable 1 } > > I wonder if this is a sparse augmentation (it seems so because > otherwise it might have been an AUGMENTs). > I wonder though if this is intentional or accidental. > I personally think I would have made this the base table > and maybe used an AUGMENTS for the read-only (syslEntOpsTable). > > The Counter32 object in the syslEntOpsTable MUST specify if/when > a discontinuity can occur and which timer indicates such discontinuity. > Probably the only discontinuity is when the SNMP agent restarts, > but I am not sure. If so it would be sysUptime that serves as the > discontinuity timer. > > For: > syslEntOpsLastMsgDeliveredTime OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The local time when the last message was delivered > by the syslog process. > " > > I would think it is better to say "was relayed or sent"? > Because you do not actually know (in many cases) if the > message indeed does get delivered to the other end, do you? > > For: > syslEntOpsLastError OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A description of the last error that was encountered > by this process. > " > > I am not sure I understand what "this process" is? > Is it the agent (I guess not)? Is it the syslog entity? > Or is it something else? > > For: > syslEntOpsReference OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the Host resource MIB is serviced on the host then > this entry will have the value of the hrSWRunIndex > of the corresponding entry in the hrSWRunTable. > Otherwise this object will be inaccessible, > " > > First, I would change "is serviced" into "is instantiated" or "is supportted". > Further I see that hrSWRunIndex is defined as: > hrSWOSIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > So I would expect the SYNTAX for syslEntOpsReference to also be > SYNTAX Integer32 (1..2147483647) > But... The last sentence of the DESCRIPTION clause says: > Otherwise this object will be inaccessible, > (should have a period at the end instead of a comma by theway) > and that is also something that is VERY UNCLEAR. > Maybe a "nosuchInstance" exception would be better. > Maybe the best is to define the object as: > syslEntOpsReference OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the Host resource MIB is instantiated on the host then > this entry will have the value of the hrSWRunIndex > of the corresponding entry in the hrSWRunTable. > The special value of zero indicates that the Host resource > MIB is not instantiated. > " > > I see: > syslEntCtlTable OBJECT-TYPE > SYNTAX SEQUENCE OF SyslDevCtlEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table containing static information about > the syslog entity. > " > > First I am not sure it is really static, because it allows to change > the values. But in any event, I would describe that this table is > intended to configure syslogEntities. > > For syslEntCtlProcDescr I wonder if this value is/can be used > anywhere else. If yes, pls say something about it. > > For: > syslEntCtlBindAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The specific IP address or hostname the syslog process > will bind to. If a hostname is specified, the IPv4 or > IPv6 address corresponding to the hostname will be used. > " > ::= { syslEntCtlEntry 3 } > > I am not sure what "if a hostname is specified..." means. > If it is a FQDN, then the InetAddressType would be 'dns' > And yoiu MUST specify when that name is resolved into an IP address. > But probably you mean that if it is just some local hostname, that > in that case an IPv4 or IPv6 address shoudl be specified. That is not > 100% clear to me though. So pls clarify. > > You MUST also add some text that states that the format of this address > is controlled by the value of the corresponding syslEntCtlBindAddrType > object. > > For: > syslEntCtlConfFileName OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The fullpath name of the configuration file where the > syslog entity's message selection and corresponding > action rules will be read from. > Data is loaded from this file into the > syslogCtlSelectionTable and the syslogCtlLogActionTable. > If the objects loaded from the file specified by this > object have an access level of read-create, this file MUST > be writable so that modifications to the corresponding > objects, if any, will be effected in this file. > If the system does not support the specification of a > configuration file, this field will not be accessible. > " > DEFVAL { "/etc/syslog.conf" } > ::= { syslEntCtlEntry 7 } > > I wonder where is/are the syslogCtlSelectionTable and the > syslogCtlLogActionTable tables defined? I cannot find them > so I am not sure what this means. > I think that instead of > If the system does not support the specification of a > configuration file, this field will not be accessible. > I would make this object a zero-length string. Much cleaner > and much easier on both agent and NMS. > > For: > syslEntCtlStatus OBJECT-TYPE > SYNTAX INTEGER { > unknown (1), > started (2), > suspended(3), > stopped (4) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The status of the process. > " > DEFVAL { unknown } > > What is "the process" ?? > > I think I would add a DEFVAL for syslEntCtlStorageType > Any value that the WG feels appropriate is fine. > > For syslEntCtlRowStatus > - s/iff/if/ > - I am surprised to see that one needs to go to notInService > state in order to change any column in the row. There are > various that could very well be changed (maybe even all) > while in active state. And such is much easier on both > agent and manager. > > The two NOTIFICATIONs could easily be combined into a > syslogEntitySTatusChanged NOTIFICATION-TYPE > Just a minor optimization I guess > > I would think/hope that there is some relation between theobjects in the > syslogSystemGroup and those in the syslogDevCtlGroup. > For example, if no maxMessage size is specified in syslEntCtlMaxMessageSize, > then the maxmessagesize from syslogDefaultMaxMessageSize is used? > But the DESCRIPTION clauses of the OBJCTS say nothing about this, > so I am not sure how to determine which value to use when? > > I think I would change > syslogCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities > which implement the SYSLOG-MIB. > " > Into something like: > syslogFullCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for SNMP entities which implement > the SYSLOG-MIB with support for writable objects. Such an > implentation can be both monitored and configured via SNMP. > " > > I am not sure I completely understand the intent of > syslogNotificationCompliance. Is it the idea that an implementation > can claim compliance to just send notifications and nothing else? > If so, you may want to make that clear. > > Even then, I think I would include the syslogNotificationGroup in > both the other two MODULE-COMPLIANCE statements, so that if you > support it all, you only have to claim compliance with a single > MODULE-COMPLIANCE statement. > > On page 27 I see: > > Even if the network itself is secure (for example by using IPSec), > > I know that at least one of the SECURITY ADs will want you to > s/IPSec/IPsec/. > The latest MIB security template has the fix already in it. > > I see quite a few places where you use "MIB" while I think what you > mean is the/a "MIB Module". I know this is a nit. Nevertheless, > it seems you need to do a revision to at least fix the syntax errors, > so might as well addres this. > > Bert > > ----------- original review message: >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt >>>> Transmission of syslog messages over UDP >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 >>>> .txt >>>> >>>> TLS Transport Mapping for SYSLOG >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 >>>> .txt >>>> >>>> Syslog Management Information Base >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx >>>> t >>>> >>>> Signed syslog Messages >>>> http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt >>>> (We expect this document to be updated this week.) >>>> >>>> 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 From syslog-bounces@lists.ietf.org Mon Oct 16 17:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaAT-0001lx-B8; Mon, 16 Oct 2006 17:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaAR-0001i0-Ku for syslog@ietf.org; Mon, 16 Oct 2006 17:38:39 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaAQ-0007pB-E1 for syslog@ietf.org; Mon, 16 Oct 2006 17:38:39 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc15) with SMTP id <2006101621383701500mb820e>; Mon, 16 Oct 2006 21:38:38 +0000 From: "David Harrington" To: Date: Mon, 16 Oct 2006 17:36:19 -0400 Message-ID: <055b01c6f16b$1e6b48e0$0600a8c0@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.2962 Thread-Index: AcbLB6M5QH3V/DkJTzuccOKfI+PU0QAfxYHgAAtaOrAJbUuiYA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Syslog] WG timeline 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 two co-chairs have really dropped the ball on meeting the WG scheduled dates. We need to review the comments and request revisions changes. We apparently will not get that done in time for editors to publish by the deadline. So this is the new schedule. Sep 29 Close all WGLCs - done Oct 16-Nov12 Chairs review comments and determine what changes are needed. (Hopefully, we'll get this done much sooner than these dates) Nov 13 publish revisions of sign, tls, mib, protocol, udp if needed Nov 13 start final WGLC on all modified documents if needed. Nov 27 end final WGLCs Nov 27 submit all final-WGLC-modified drafts to internet-drafts Nov 30 submit documents to the IESG. 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 From syslog-bounces@lists.ietf.org Sun Oct 22 19:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbmNp-0004uI-NB; Sun, 22 Oct 2006 19:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbmNo-0004pj-Dm for syslog@ietf.org; Sun, 22 Oct 2006 19:05:32 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbmHi-0006KD-1g for syslog@ietf.org; Sun, 22 Oct 2006 18:59:28 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc12) with SMTP id <20061022225913012001qbpce>; Sun, 22 Oct 2006 22:59:13 +0000 From: "David Harrington" To: Date: Sun, 22 Oct 2006 23:56:48 +0100 Message-ID: <057501c6f62d$5b7e8fa0$b07557c0@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.2962 Thread-Index: Acb2LLQKXZaxt/eyS/2isochxRKHIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [Syslog] Dbh Review of -mib-09, part 1 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 have finally found time to review the mib-09 document. 1) There are multiple pages that exceed the maximum allowed lines per page. 2) The headers and footers do not appear to be standard. There should an abbreviated title for easch page after the first. 3) the terminology is not consistent with the other WG documents. 4) "roles a syslog entity maybe in" would be better as "roles of a syslog entity" (although then entity should be changed according to #3. 5) I concur with Bert that the citations in section 2 seem inappropriate. 6) I find the references to SA-Li, RA-Rj confusing since these are not used in the diagram. 7) "The MIB comprises of four groups" would be better as "The MIB contains four groups" 8) Section 3 has a number of lists. You should decide if the list should contain sentences, or makes up one complete sentence. If it is one sentence, then each listed clause should end with a comma, and be consistent in style. If each item is a sentence, then the introductory phrase needs to be a sentence. I recommend making each item a sentence, so we can eliminate the "which" conrstructs. 9) "asynchronously monitor" s/b "asynchronously report" 10) the name of SyslogMIB or syslogMIB should be consistent in the text. I recommend using SYSLOG-MIB, which is the correct name for the MIB module. 11) in SyslogSeverity, I recommend removing the second sentnece in the description "The syslog protocol uses the values 0 (emergency) to 7 (debug)." since this is already spelled out in the SYNTAX clause, and shows that 99 (other) is also used. Why do we need 99? Are other values valid? 12) SyslogService - can we make this just a service name. The port semantics are really ambiguous. How do distinguish a UDP port# from a TCP port#? 13) For consistency with most other MIB modules being developed, I suggest defining a top-level breakdown of syslogNotifications (0), syslogObjects (1), and syslogConformance (2). Then put syslogSystem and syslogDevice under syslogObjects. See RFC4181 appendix D. 14) transportAddressType is designed to be used with specific types of transportAddress. The syslogDefaultTransport object should probably be syslogDefaultTransportType. A transportAddressType seems inappropriate for use with syslogDefaultService, which does not necessarily resolve to one of the enumerated options. We should have a syslogDefaultTransport that is a transport address. If we want a Default service, that should probably be a separate object. 15) some objects are named xxxSeverity, but the description uses priority. We need to be consistent with the other documents about what this is called. 16) the syslogDefaultMaxMessageSize description really needs work - 480 is the minimum maximum size, not the recommended maximum size, so it should not be the default. The maximum message size also may depend on the transport protocol and the target system, so I'm not sure a default is a useful object. Who is the user of this default? The local system? If so, then it is an implementation detail and does not need to exposed in a mIB object. If it is for use by the remote system, then it shouldn't be a default value, but the actual value supported by the implementation. 17) syslEntOpsTable uses abbreviated elements in the name. I don't see why they need to be abbreviated, or what the name actually means. The description does not mention "ops". 18) object prefixes should be consistent for the whole module. The DefaultXXX uses syslog as the prefix, but here we use sysl. Why? See RFC4181 appendix C for naming guidelines. 19) syslEntCtlTable contains static info; does that imply that syslEntOpsTable contains dynamci info? Or is syslEntOpsTable about the operational environment, and syslEntCtlTable about control info? The descritions should kae the purpose of the table unambiguous. 20) In the SNMPv2 effort, we found that using integer indices made using the tabels more difficut for human readers. It would be much easier for a human to interpret the statistics here is it is easy to tell what the systlog entity is. So I recommend using an SnmpAdminString as the index. For systems that cannot, for whatever reason, determine a human-readable identifier for the index, the SnmpAdminString can always be "1", "2", etc. 21) what is the persistence of the index? If syslog entities happen to start in a different order, will the index# refer to the same entity after a reboot? If the MIB says they must be persistent across reboots, how difficult will that be for the OS that starts the applications? What value will the system keep to match up to the integer indicies to make sure they remain the same? 22) syslEntOpsMsgsDropped counts messages that could not be relayed. What about messages that cannot be queued for transmission for an original sender? 23) syslEntOpsMsgsIgnored - where are the "allowed specifications" defined? We don't want a value that can be interpreted differently by different entities, because then the values canot be compared across systems, or have consistent baselines for comparison across products, etc. Objects shoud be defined to be interoperable and unambiguous. 24) syslEntOpsLastMsgDeliveredTime - the system does not know when the message was delivered, only when it was transmitted or received. 25) syslEntOpsLastError talks about "this process". Is this the syslog entity? This needs to be clear and unambiguous, and consistent with the terminology in the other WG documents. 26) syslEntOpsLastError talks about the last error this process "encountered". The definition of encountered needs to be made unclear and unambiguous. 27) what is the persistence of the syslEntOpsReference across reboots of the OS? Across reboots of the SNMP system? If it is not persistent, but the table is, what should the SNMP agent do - delete the references? Change the references to match the new SWRunIndex? 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 Sun Oct 22 23:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbqtQ-0004Tl-87; Sun, 22 Oct 2006 23:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbqtP-0004TD-FF for syslog@ietf.org; Sun, 22 Oct 2006 23:54:27 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbqtF-0003HV-3j for syslog@ietf.org; Sun, 22 Oct 2006 23:54:27 -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 <0J7K00JTYLNPGZ@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 23 Oct 2006 11:57:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7K009QMLNOPR@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 23 Oct 2006 11:57:25 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7K00KOXM2GY6@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 23 Oct 2006 12:06:19 +0800 (CST) Date: Mon, 23 Oct 2006 11:52:41 +0800 From: Miao Fuyou In-reply-to: To: syslog@ietf.org Message-id: <036101c6f656$b0f5d8c0$5c0c6f0a@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: Acb0eTe9fUEuaI6nTYWM2YH1+Pyv2wBxiU0Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: [Syslog] RE: syslog/tls - how to abort because of inconsistent versions 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, There are several possible options to solve this issue: 1, Using a TLS alert to signal the inconsistent versions as the current draft does. The drawback is it violate the layer, using TLS alert to notify an application event seems ugly. 2, Saving the data (TLS app-data, not syslog message, different to UDP transport) no matter what the version is. This may mean a receiver should be able to save a stream without any knowledge about the structure of the stream. The data can not be stored in the same file/database to the one for syslog messages, because it has no way to delimit frames. 3, Change the simplex of syslog, add an application level notification from receiver to sender, this may increase the effort of implementation greatly, 4, Do nothing, the sender may keep connecting the receiver. But, we can recommend in that specification like "if connections are closed just after successful TLS handshake for three times with same transport mapping version, the sender SHOULD not connect the receiver again with the same transport version". Does it work? My preference is 4 > 1 > 2 > 3. Miao > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Saturday, October 21, 2006 2:55 AM > To: Miao Fuyou > Cc: 'David Harrington'; myz@huawei.com > Subject: RE: syslog/tls - how to abort because of > inconsistent versions > > Hi Miao, > > We need this issue resolved in the WG. Please bring up the > discussion on the list with a proposal. I suggest that we > not use TLS to signal a failure in the upper level. > > Thanks, > Chris > > On Thu, 19 Oct 2006, Miao Fuyou wrote: > > > Hi, Eric, > > > > One clarification to version #: syslog/tls version is the one for > > "syslog/tls transport mapping", but syslog version # is the one for > > syslog-protocol, they are diffirent numbers. > > > > When a receiver gets a message with a **syslog version number** it > > does not understand, it could save the message in local storage or > > forward to other receiver because it know exact the boundary of the > > message (actually a receiver does not have to understand > the version > > of syslog protocol in most cases, because the only task for > receiver is to store or forward). > > > > But, this may not apply to syslog/tls transport mapping. Diffirent > > **syslog/tls version number** may mean diffirent APP-DATA format. A > > receiver with a diffrent version may not be able to parse > the stream > > or delimit syslog messages, the only thing that it can do > is to save > > the tls stream in local storage if it is linient. But, > saving stream > > seems ugly, maybe more ugly than making tls alert to serve > > application:-) > > > > Thanks! > > Miao > > > >> -----Original Message----- > >> From: EKR [mailto:ekr@networkresonance.com] > >> Sent: Thursday, October 19, 2006 10:02 AM > >> To: Miao Fuyou > >> Cc: 'David Harrington'; myz@huawei.com; 'Chris Lonvick' > >> Subject: Re: syslog/tls - how to abort because of inconsistent > >> versions > >> > >> Miao Fuyou wrote: > >>> Hi, Eric, > >>> > >>> The primary reason to use a TLS level notification to > >> notify an event > >>> for application level is to keep Syslog still simplex, > but it seem > >>> violative to clear layership. An application notification > >> will change > >>> that simplex of syslog, which is alien to syslog. The wg > is in the > >>> dilemma to process this issue. > >>> > >>> Your sugestion? > >> > >> Well, I see that draft-ietf-syslog-protocol-17.txt > contains a version > >> #. What do you do if that is something you don't understand? > >> > >> -Ekr > >> > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Oct 25 04:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gce7E-0004sV-Kn; Wed, 25 Oct 2006 04:28:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gce7D-0004sL-1F for syslog@ietf.org; Wed, 25 Oct 2006 04:27:59 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gce7B-0007zn-QY for syslog@ietf.org; Wed, 25 Oct 2006 04:27:59 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc14) with SMTP id <2006102508275601400q543me>; Wed, 25 Oct 2006 08:27:57 +0000 From: "David Harrington" To: Date: Wed, 25 Oct 2006 09:25:29 +0100 Message-ID: <001201c6f80f$22b39470$22021eac@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.2962 Thread-Index: Acb3yrMS6ODMYCInS4KDym8acG1uew== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Syslog] Mib-09- review, part 2 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 Continued ... 1) syslEntCtlTable should describe what type of information is stored in the table, and the description should be more than "static info". 2) syslEntCtlEnty - what type of parameters? What process? 3) syslEntCtlBindAddress - does this field contain an address or a hostname? What does the seond sentence mean? 4) syslEntCtlTransport - why is this "default" transport instead of just transport? 5) is there a mismatch between transportaddresstype and syslEntCtlService? Is there a transportAddressType for this type of "address"? 6) syslEntCtlConfFileName - using lots of abbreviations in the name makes it hard for people to remember how the words were abbreviated. It would be better to use something like syslogEntCtlFilename. Why do we need Ent in the name? we never deal with anything other than entities, do we? syslogControlFile would be much easier to remember than syslEntCtlConfFileName. 7) syslEntCtlConfFileName refers to syslogCtlSelectionTable and syslogCtlActionTable - where are these defined? 8) syslEntCtlStatus - again, what process? 9) syslEntCtlStorageType - is this definition exactly the same as the StorageType T-C? 10) ...RowStatus - spelling "iff" 11) syslEntStarted and syslEntStopped - spell out MO. I don't understand the second sentence; how does the manager know what syslEntOpsIndex is used? 12) It would be much better to use consistent naming between the objects/tables and the conformance clauses. The table refers to syslEnt, but conformance is for syslogDev; the objects are syslogDefault but the conformance is syslogSystem. Let'e make it easy to work with by being more consistent. 13) why are notifications not mandatory for compliance? 14) The MIB module exposes some info from syslog, such as last error. The security considerations talk about securing snmp, but that does not make sense if you do not also secure the syslog transport. The security considerations should recommend securing syslog to match the snmp security. 15) iana considerations talks about a base arc; this would be better reworded. 16) I thik rfc3164 is informative, no tnormative. 17) I suspect you are not usinng xml2rfc. If not, you need to make sure all the boilerplates are up-to-date. Please check the funding statement and the intellectual property clauses. 18) the change log is most effective if you track the chnages from published version to published version, not by MIB revision dates. 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 Oct 25 10:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckBc-0008MM-Rz; Wed, 25 Oct 2006 10:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckBb-0008M2-6v for syslog@ietf.org; Wed, 25 Oct 2006 10:56:55 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckBX-0002MV-02 for syslog@ietf.org; Wed, 25 Oct 2006 10:56:55 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc11) with SMTP id <20061025145650011005a66ue>; Wed, 25 Oct 2006 14:56:50 +0000 From: "David Harrington" To: Date: Wed, 25 Oct 2006 15:53:59 +0100 Message-ID: <012601c6f845$714c5e60$22021eac@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.2962 Thread-Index: Acb4N5+H/fEmvTXGRDK18Dy6B3C7sA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Syslog] -mib-, part 3 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 transport area directors have been requiring protocol specs to describe how to avoid congestion. This is especially problematic when we use UDP. I suggest adding a writable variable to the MIB module to enable rate limiting (messages per second) at the sender. This might be a transport-specific setting (since some transports already have congestion avoidance), or a system-wide setting. I think the WG should discuss how they want to handle this. 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 Oct 25 14:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnKy-00045N-Nj; Wed, 25 Oct 2006 14:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnKx-000438-R2 for syslog@ietf.org; Wed, 25 Oct 2006 14:18:47 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcnKw-0007j1-KU for syslog@ietf.org; Wed, 25 Oct 2006 14:18:47 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc13) with SMTP id <2006102518184401300h6h4ne>; Wed, 25 Oct 2006 18:18:45 +0000 From: "David Harrington" To: Date: Wed, 25 Oct 2006 19:16:18 +0100 Message-ID: <015201c6f861$ab9458e0$22021eac@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.2962 Thread-Index: Acb4YXhYV/6d2UVWQTqe+j/icY5c9A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Syslog] WGLC: syslog-sign 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 Alex, I have quickly checked sign-19. It appears to me that you did not resolve many of the editorial problems identified in the Liaison from the OIF posted by Chris on 9-13. The review can be found at https://datatracker.ietf.org/public/liaisons.cgi Please review their comments and address them as appropriate. Most are simple editorial fixes. If there are any questions, then please contact the chairs. I also note that -19 does not remove the unused references. You can get the list by running the document through the validator at http://tools.ietf.org/tools/idnits/idnits.pyht Since -19 was published we also had a discussion of APP-NAME, et al. so that needs to be addressed in -20. And there are a few editorial fixes I mentioned. Can you publish a sign-20 soon? There have been quite a few changes since -18-, so I think we'll need to do another WGLC. 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 Wed Oct 25 17:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqGx-0007bE-BO; Wed, 25 Oct 2006 17:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolJ-0003pC-RT; Wed, 25 Oct 2006 15:50:05 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolI-0007pj-B9; Wed, 25 Oct 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 34E9E26E58; Wed, 25 Oct 2006 19:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolI-0004rr-1b; Wed, 25 Oct 2006 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:04 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-10.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-10.txt Pages : 39 Date : 2006-10-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 entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25133422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25133422.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Oct 25 19:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrxU-00021O-Mk; Wed, 25 Oct 2006 19:14:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrxS-00021G-HB for syslog@ietf.org; Wed, 25 Oct 2006 19:14:50 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrxR-0001Ko-9X for syslog@ietf.org; Wed, 25 Oct 2006 19:14:50 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc15) with SMTP id <2006102523144801500lo1cte>; Wed, 25 Oct 2006 23:14:48 +0000 From: "David Harrington" To: Date: Thu, 26 Oct 2006 00:12:22 +0100 Message-ID: <045301c6f88b$078d9660$22021eac@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.2962 Thread-Index: Acb4irpkvpLwv3pwSGOBRniDmT0nrw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Syslog] Review of Mib-10, part 1 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 Glenn, -10- looks better than -09-. Thanks for getting this out. I sent some comments, and I think some still need to be addressed. Have you finished addressing all Bert's comments? Here are a couple things I spotted in -10- 1) syslEntCtlEntry should be changed to match the other prefixes (syslogEntityControlEntry) 2) the same for syslEntOpsEntry, syslEntStarted, syslEntStopped, etc. 3) I recommend chaging "operations related information" to "operations information" 4) I recommend changing syslogSystemGroup to syslogDefaultGroup if that's the prefix you keep on all the "Default" variables. 5) I recommend changing syslDevOpsGroup to syslogEntityOpsGroup, and syslDevCtlGroup to syslogEntityControlGroup. Why do we need two groups? Can you implement Ops without the Control table, now that one augments the other? 6) /implememt/implement/ 7) Is it possible to support notifications only, since the notifications contain data from the tables not implemented? Where do the values come from? 8) did you run the document through the idnits checker at http://tools.ietf.org/tools/idnits/? It still reports this problem: The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 60 lines 9) did you run the MIB module through the smilint utility? Instructions can be found at http://www.ibr.cs.tu-bs.de/projects/libsmi/mailrobot.html?lang=de 10) Can you add "Intended status: Standards Track" to the header (see syslog-sign for an example). 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 Oct 25 19:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsBz-0005r0-H9; Wed, 25 Oct 2006 19:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsBy-0005q9-Nz for syslog@ietf.org; Wed, 25 Oct 2006 19:29:50 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcsBv-0003Tp-Ht for syslog@ietf.org; Wed, 25 Oct 2006 19:29:50 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc14) with SMTP id <2006102523294601400q54f0e>; Wed, 25 Oct 2006 23:29:46 +0000 From: "David Harrington" To: Date: Thu, 26 Oct 2006 00:27:15 +0100 Message-ID: <045401c6f88d$1f25b580$22021eac@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.2962 Thread-Index: Acb4jQCEnZ+3iqmoSTmpHutMHDy04g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Syslog] All editors 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, Please make sure your documents contain "Intended Status: Standards Track" in the header. Note that if you use xml2rfc, this defaults to Informational, which can cause problems when it gets to the RFC editor. You need to fix the attribute or the category field in XXE. 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 Thu Oct 26 14:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9nX-0007Z1-NB; Thu, 26 Oct 2006 14:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9nX-0007Yw-DX for syslog@ietf.org; Thu, 26 Oct 2006 14:17:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9nV-0003n8-Sl for syslog@ietf.org; Thu, 26 Oct 2006 14:17:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 11:17:45 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QIHjZp002954; Thu, 26 Oct 2006 11:17:45 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QIHibG008154; Thu, 26 Oct 2006 11:17:44 -0700 (PDT) Date: Thu, 26 Oct 2006 11:17:44 -0700 (PDT) From: Chris Lonvick To: Miao Fuyou Subject: Re: [Syslog] RE: syslog/tls - how to abort because of inconsistent versions In-Reply-To: <036101c6f656$b0f5d8c0$5c0c6f0a@china.huawei.com> Message-ID: References: <036101c6f656$b0f5d8c0$5c0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=5051; t=1161886665; x=1162750665; c=relaxed/simple; s=sjdkim5002; 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]=20RE=3A=20syslog/tls=20-=20how=20to=20abort=20because=2 0of=20inconsistent=0A=20versions; X=v=3Dcisco.com=3B=20h=3Diy1+iUIwxV88jRtMpj3EKLFfwak=3D; b=sDnQmewVaZY7/WR6Mcv+zpZ28/ZDLVw8/jXD0Dbyh+g36CjhrI6OPkoTtPzzjoDcodRRHBG6 eqfGmxilmf46b9afifqgXxqghGs/pu82Zao/rMzExmH9eGRi4HqQyxpK; Authentication-Results: sj-dkim-5.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Miao and All, We had a discussion with Eric Rescorla (as a technical expert) about the use of a TLS alert to signal a version exchange problem. He recommended that TLS alerts are to be used by TLS and should not be used for signalling of upper-layer events. From that, we should not be considering #1 below. For #3, we are not going to examine the simplex nature of syslog for each new transport. That work has been done in RFC 3195. I recommend that we go with #4. This seems to be no different from current implementations of syslog/udp. In this, it is always wise to check that messages are being received from a syslog sender since the sender gets no indication that the message has been received from the server. It would be appropriate for the document to note this in the security considerations section and perhaps to even point out that #2 is a viable step. I would like to close this out very soon. Please comment back to the list if you have an opinion on this. Thanks, Chris On Mon, 23 Oct 2006, Miao Fuyou wrote: > > Hi, > > There are several possible options to solve this issue: > > 1, Using a TLS alert to signal the inconsistent versions as the current > draft does. The drawback is it violate the layer, using TLS alert to notify > an application event seems ugly. > > 2, Saving the data (TLS app-data, not syslog message, different to UDP > transport) no matter what the version is. This may mean a receiver should be > able to save a stream without any knowledge about the structure of the > stream. The data can not be stored in the same file/database to the one for > syslog messages, because it has no way to delimit frames. > > 3, Change the simplex of syslog, add an application level notification from > receiver to sender, this may increase the effort of implementation greatly, > > 4, Do nothing, the sender may keep connecting the receiver. But, we can > recommend in that specification like "if connections are closed just after > successful TLS handshake for three times with same transport mapping > version, the sender SHOULD not connect the receiver again with the same > transport version". Does it work? > > My preference is 4 > 1 > 2 > 3. > > Miao > > >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Saturday, October 21, 2006 2:55 AM >> To: Miao Fuyou >> Cc: 'David Harrington'; myz@huawei.com >> Subject: RE: syslog/tls - how to abort because of >> inconsistent versions >> >> Hi Miao, >> >> We need this issue resolved in the WG. Please bring up the >> discussion on the list with a proposal. I suggest that we >> not use TLS to signal a failure in the upper level. >> >> Thanks, >> Chris >> >> On Thu, 19 Oct 2006, Miao Fuyou wrote: >> >>> Hi, Eric, >>> >>> One clarification to version #: syslog/tls version is the one for >>> "syslog/tls transport mapping", but syslog version # is the one for >>> syslog-protocol, they are diffirent numbers. >>> >>> When a receiver gets a message with a **syslog version number** it >>> does not understand, it could save the message in local storage or >>> forward to other receiver because it know exact the boundary of the >>> message (actually a receiver does not have to understand >> the version >>> of syslog protocol in most cases, because the only task for >> receiver is to store or forward). >>> >>> But, this may not apply to syslog/tls transport mapping. Diffirent >>> **syslog/tls version number** may mean diffirent APP-DATA format. A >>> receiver with a diffrent version may not be able to parse >> the stream >>> or delimit syslog messages, the only thing that it can do >> is to save >>> the tls stream in local storage if it is linient. But, >> saving stream >>> seems ugly, maybe more ugly than making tls alert to serve >>> application:-) >>> >>> Thanks! >>> Miao >>> >>>> -----Original Message----- >>>> From: EKR [mailto:ekr@networkresonance.com] >>>> Sent: Thursday, October 19, 2006 10:02 AM >>>> To: Miao Fuyou >>>> Cc: 'David Harrington'; myz@huawei.com; 'Chris Lonvick' >>>> Subject: Re: syslog/tls - how to abort because of inconsistent >>>> versions >>>> >>>> Miao Fuyou wrote: >>>>> Hi, Eric, >>>>> >>>>> The primary reason to use a TLS level notification to >>>> notify an event >>>>> for application level is to keep Syslog still simplex, >> but it seem >>>>> violative to clear layership. An application notification >>>> will change >>>>> that simplex of syslog, which is alien to syslog. The wg >> is in the >>>>> dilemma to process this issue. >>>>> >>>>> Your sugestion? >>>> >>>> Well, I see that draft-ietf-syslog-protocol-17.txt >> contains a version >>>> #. What do you do if that is something you don't understand? >>>> >>>> -Ekr >>>> >>> >> > > > > _______________________________________________ > 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 Oct 26 19:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEyv-0006zt-Dq; Thu, 26 Oct 2006 19:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEyu-0006ze-52 for syslog@ietf.org; Thu, 26 Oct 2006 19:49:52 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEys-0001ZH-U9 for syslog@ietf.org; Thu, 26 Oct 2006 19:49:52 -0400 Received: from harrington73653 (unknown[83.71.141.73]) by comcast.net (sccrmhc12) with SMTP id <2006102623494901200ms1pje>; Thu, 26 Oct 2006 23:49:50 +0000 From: "David Harrington" To: Date: Fri, 27 Oct 2006 00:47:13 +0100 Message-ID: <065001c6f959$168c5920$22021eac@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.2962 Thread-Index: Acb5J7WaudOgruI+SlyGPAAB5qM/pw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [Syslog] Mib -10-, part 2 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 Glenn, I want to remind you of some outstanding issues to resolve: >From tom petch, 8-16: "I still have trouble with the mib document, not for any mibby reason but simply because, as I commented on the previous version, it seems to be written in a different language to the other I-D and, insofar as I understand that language, seems to be describing a different set of concepts to the other documents." And 9-28: "I have looked at this I-D and appreciate the increased explanation at the beginning. It leaves me clearer, but still thinking that this document steers a different course to the other syslog ones, in its focus on a group of syslog entities. It's not that there cannot be more than one syslog entity running in a given host, just that bundling them together into a table seems an artificial complication; other syslog MIB modules I see are scalar in approach." I am less concerned about the table of entities versus modeling a single entity. Having this in a table makes it easier than forcing the use of contexts to get at multiple instances of the MIB module on a host, and is consistent with the hrSwRunTable of the Host Resources MIB. Unless the WG raises objections, I believe the table approach is acceptable. Consistent concepts and terminology is important. WG consensus is that all the documents should be consistent. The other document editors aligned their terminology, and you must do so for this document as well. It is especially important that terminology used in the management interface be consistent with the technology being managed. Please plan on submitting another official revision before Nov 12, with all outstanding change requests addressed, so we can finish another 2-week WGLC and still meet our November deadline. If you question some of the change requests, please consult the chairs and we will make a determination. 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 Oct 30 09:58:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYZL-000591-Fh; Mon, 30 Oct 2006 09:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYZG-00057V-Ug for syslog@ietf.org; Mon, 30 Oct 2006 09:56:50 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYZC-0002r2-0P for syslog@ietf.org; Mon, 30 Oct 2006 09:56:50 -0500 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 k9UEuUe1027909; Mon, 30 Oct 2006 23:56:30 +0900 (JST) Received: from [127.0.0.1] (kiras7.priv.cysol.co.jp [192.168.0.157]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k9UEuKsN014812; Mon, 30 Oct 2006 23:56:30 +0900 (JST) Message-ID: <45461293.9010007@cysols.com> Date: Mon, 30 Oct 2006 23:56:19 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] Review of Mib-10, part 1 References: <045301c6f88b$078d9660$22021eac@china.huawei.com> In-Reply-To: <045301c6f88b$078d9660$22021eac@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "Wijnen, Bert \(Bert\)" , 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 Dave, Thanks for the comments. I hope to incorporate the changes by 5/11/06. Some (2) of Bert's comments are yet to be addressed. I wanted to get a version out before the submission deadline. Cheers Glenn > -10- looks better than -09-. Thanks for getting this out. > I sent some comments, and I think some still need to be addressed. > Have you finished addressing all Bert's comments? > > 1) syslEntCtlEntry should be changed to match the other prefixes > (syslogEntityControlEntry) > > 2) the same for syslEntOpsEntry, syslEntStarted, syslEntStopped, etc. > > 3) I recommend chaging "operations related information" to "operations > information" > > 4) I recommend changing syslogSystemGroup to syslogDefaultGroup if > that's the prefix you keep on all the "Default" variables. > > 5) I recommend changing syslDevOpsGroup to syslogEntityOpsGroup, and > syslDevCtlGroup to syslogEntityControlGroup. Why do we need two > groups? Can you implement Ops without the Control table, now that one > augments the other? > > 6) /implememt/implement/ > > 7) Is it possible to support notifications only, since the > notifications contain data from the tables not implemented? Where do > the values come from? > > 8) did you run the document through the idnits checker at > http://tools.ietf.org/tools/idnits/? > It still reports this problem: > The page length should not exceed 58 lines per page, but there was 38 > longer pages, the longest (page 2) being 60 lines > > 9) did you run the MIB module through the smilint utility? > Instructions can be found at > http://www.ibr.cs.tu-bs.de/projects/libsmi/mailrobot.html?lang=de > > 10) Can you add "Intended status: Standards Track" to the header (see > syslog-sign for an example). > > 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 From syslog-bounces@lists.ietf.org Mon Oct 30 19:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GehRx-0002vE-2g; Mon, 30 Oct 2006 19:25:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GehRv-0002v9-Lw for syslog@ietf.org; Mon, 30 Oct 2006 19:25:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GehRu-0006Aj-Bz for syslog@ietf.org; Mon, 30 Oct 2006 19:25:51 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2006 16:25:50 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V0PnPN023224 for ; Mon, 30 Oct 2006 16:25:49 -0800 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 k9V0PnW5009206 for ; Mon, 30 Oct 2006 16:25:49 -0800 (PST) Date: Mon, 30 Oct 2006 16:25:49 -0800 (PST) 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=1016; t=1162254349; x=1163118349; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:=22enc=22=20param=20in=20syslog-protocol; X=v=3Dcisco.com=3B=20h=3DTkqtOmJa7Tffiam6wrCJvrAqI50=3D; b=Kkv7UWjt6CLDziZThd6brGYgYqmJIz5PXHa1nExudlPXo3ndtiPQUSrIweRoKFWAJ/4B0nfN 2IXMr8GOIn6l0SpvtWUtYhE2KC7cyyGURkCEJz24UiIQO6yoxcXQP7NY; 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Syslog] "enc" param in syslog-protocol 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 All, I've been reviewing the use of "enc" (for defining the encapsulation type). This discussion has been going on for some time. http://www.mail-archive.com/syslog@lists.ietf.org/msg00241.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00252.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00300.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00313.html I know that several people would like a way to send binary data within syslog messages and that's what this param was intended for. However, without actually defining other encapsulation types, the parameter appears to be underspecified. I don't want this to hold up our effort at this time. I'm going to ask Rainer to remove references to "enc" from syslog-protocol. Once this standard is out, others can discuss other encapsulation types and put together a document that fully describes it and how it can be used to ship binary information, or other encapsulation types. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog