From opsawg-bounces@ietf.org Tue Jan 13 13:27:21 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D01F3A689E; Tue, 13 Jan 2009 13:27:21 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3827B3A689E for ; Tue, 13 Jan 2009 13:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHv9Zbsb9cIN for ; Tue, 13 Jan 2009 13:27:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 13FC43A67DF for ; Tue, 13 Jan 2009 13:27:18 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357F3C00B8; Tue, 13 Jan 2009 22:27:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kvgqhwDvJhtO; Tue, 13 Jan 2009 22:26:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF556C00B0; Tue, 13 Jan 2009 22:26:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03FD58F1678; Tue, 13 Jan 2009 22:26:54 +0100 (CET) Date: Tue, 13 Jan 2009 22:26:54 +0100 From: Juergen Schoenwaelder To: "Scott O. Bradner" , Dan Romascanu Message-ID: <20090113212654.GA4299@elstar.local> Mail-Followup-To: "Scott O. Bradner" , Dan Romascanu , opsawg@ietf.org References: <20081215204943.6CE7A111953A@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081215204943.6CE7A111953A@newdev.eecs.harvard.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: > there was some discussion of the WG adopting the SNMP <-> SYSLOG > mapping documents on the list back in november - at the > time there was some support for the idea > > see > http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html > > I'd like to see if what level of support there is at this point May I ask where we are with this? This is now waiting for a decision since the Dublin IETF (about half a year ago)... Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Jan 14 03:55:30 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F0F3A6842; Wed, 14 Jan 2009 03:55:30 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66BA73A6842 for ; Wed, 14 Jan 2009 03:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw3wreDTdDFh for ; Wed, 14 Jan 2009 03:55:28 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 056F73A67B0 for ; Wed, 14 Jan 2009 03:55:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,263,1231131600"; d="scan'208";a="134016472" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jan 2009 06:55:11 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Jan 2009 06:55:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 12:55:08 +0100 Message-ID: In-Reply-To: <20090113212654.GA4299@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, Thread-Index: Acl1xa+dyCLM2jMTQxei6UFobFN47wAeRWjg References: <20081215204943.6CE7A111953A@newdev.eecs.harvard.edu> <20090113212654.GA4299@elstar.local> From: "Romascanu, Dan (Dan)" To: , "Scott O. Bradner" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Are there at least three people who are not editors or ADs committed to read and review the documents in the WG? Dan > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, January 13, 2009 11:27 PM > To: Scott O. Bradner; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > documents, > > On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: > > > there was some discussion of the WG adopting the SNMP <-> SYSLOG > > mapping documents on the list back in november - at the > time there was > > some support for the idea > > > > see > > http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html > > > > I'd like to see if what level of support there is at this point > > May I ask where we are with this? This is now waiting for a > decision since the Dublin IETF (about half a year ago)... > > Thanks, > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Jan 14 04:43:58 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36BD28C103; Wed, 14 Jan 2009 04:43:58 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEC128C103 for ; Wed, 14 Jan 2009 04:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDlr9wBe+oRD for ; Wed, 14 Jan 2009 04:43:56 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id DC77428B797 for ; Wed, 14 Jan 2009 04:43:55 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 3PPU1b00316LCl053Qjins; Wed, 14 Jan 2009 12:43:42 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 3QjQ1b00J0UQ6dC3SQjQPH; Wed, 14 Jan 2009 12:43:25 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , "'Scott O. Bradner'" References: <20081215204943.6CE7A111953A@newdev.eecs.harvard.edu><20090113212654.GA4299@elstar.local> Date: Wed, 14 Jan 2009 07:43:40 -0500 Message-ID: <010201c97645$ba82e010$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acl1xa+dyCLM2jMTQxei6UFobFN47wAeRWjgAAGqYiA= Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org There were approximately ten responses from people were are not editors or ADs that said "yes, accept this". You can see them by following the link Juergen provided. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Wednesday, January 14, 2009 6:55 AM > To: j.schoenwaelder@jacobs-university.de; Scott O. Bradner > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > documents, > > Are there at least three people who are not editors or ADs > committed to > read and review the documents in the WG? > > Dan > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Tuesday, January 13, 2009 11:27 PM > > To: Scott O. Bradner; Romascanu, Dan (Dan) > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > > documents, > > > > On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: > > > > > there was some discussion of the WG adopting the SNMP <-> SYSLOG > > > mapping documents on the list back in november - at the > > time there was > > > some support for the idea > > > > > > see > > > http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html > > > > > > I'd like to see if what level of support there is at this point > > > > May I ask where we are with this? This is now waiting for a > > decision since the Dublin IETF (about half a year ago)... > > > > Thanks, > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Jan 14 05:13:37 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DDE428C10F; Wed, 14 Jan 2009 05:13:37 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73ED228C10F for ; Wed, 14 Jan 2009 05:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsiPyITrQoFg for ; Wed, 14 Jan 2009 05:13:34 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 2489228C103 for ; Wed, 14 Jan 2009 05:13:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,263,1231131600"; d="scan'208";a="148550069" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 14 Jan 2009 08:13:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jan 2009 08:13:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 14:13:15 +0100 Message-ID: In-Reply-To: <010201c97645$ba82e010$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, Thread-Index: Acl1xa+dyCLM2jMTQxei6UFobFN47wAeRWjgAAGqYiAAAQGFoA== References: <20081215204943.6CE7A111953A@newdev.eecs.harvard.edu><20090113212654.GA4299@elstar.local> <010201c97645$ba82e010$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , , "Scott O. Bradner" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Assuming 'accept' also means 'will participate in discussions and reviews' I see no problem with the WG adopting this work item. WG chairs? Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, January 14, 2009 2:44 PM > To: Romascanu, Dan (Dan); > j.schoenwaelder@jacobs-university.de; 'Scott O. Bradner' > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > documents, > > There were approximately ten responses from people were are > not editors or ADs that said "yes, accept this". You can see > them by following the link Juergen provided. > > dbh > > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Wednesday, January 14, 2009 6:55 AM > > To: j.schoenwaelder@jacobs-university.de; Scott O. Bradner > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > > documents, > > > > Are there at least three people who are not editors or ADs > committed > > to read and review the documents in the WG? > > > > Dan > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Tuesday, January 13, 2009 11:27 PM > > > To: Scott O. Bradner; Romascanu, Dan (Dan) > > > Cc: opsawg@ietf.org > > > Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping > > > documents, > > > > > > On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: > > > > > > > there was some discussion of the WG adopting the SNMP <-> SYSLOG > > > > > mapping documents on the list back in november - at the > > > time there was > > > > some support for the idea > > > > > > > > see > > > > > http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html > > > > > > > > I'd like to see if what level of support there is at this point > > > > > > May I ask where we are with this? This is now waiting for > a decision > > > since the Dublin IETF (about half a year ago)... > > > > > > Thanks, > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > Germany > > > Fax: +49 421 200 3103 > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Wed Jan 14 05:26:56 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5863A67B0; Wed, 14 Jan 2009 05:26:56 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F98D3A67B0 for ; Wed, 14 Jan 2009 05:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn11q34Y8gor for ; Wed, 14 Jan 2009 05:26:54 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 519523A63EC for ; Wed, 14 Jan 2009 05:26:54 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3E6D82C01C9FC; Wed, 14 Jan 2009 14:26:39 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk6jxwr7-IQx; Wed, 14 Jan 2009 14:26:39 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 031922C0000EB; Wed, 14 Jan 2009 14:26:19 +0100 (CET) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Jan 2009 13:26:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jan 2009 14:23:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, thread-index: Acl1xa+dyCLM2jMTQxei6UFobFN47wAeRWjgAAMduCQ= From: "Juergen Quittek" To: "Dan Romascanu" , "Juergen Schoenwaelder" , "Scott O. Bradner" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1652377807==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1652377807== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="B_3314787786_1601879"; protocol="application/pkcs7-signature"; micalg=sha1 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3314787786_1601879 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I will review them. Juergen Q. On 14.01.09 12:55 "Dan Romascanu" wrote: > Are there at least three people who are not editors or ADs committed to > read and review the documents in the WG? > > Dan > > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Tuesday, January 13, 2009 11:27 PM >> To: Scott O. Bradner; Romascanu, Dan (Dan) >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping >> documents, >> >> On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: >> >>> there was some discussion of the WG adopting the SNMP <-> SYSLOG >>> mapping documents on the list back in november - at the >> time there was >>> some support for the idea >>> >>> see >>> http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html >>> >>> I'd like to see if what level of support there is at this point >> >> May I ask where we are with this? This is now waiting for a >> decision since the Dublin IETF (about half a year ago)... >> >> Thanks, >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3314787786_1601879 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRTDSLeC1oryzvkKv2L sB9XbWfhVzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAx MTQxMzIzMDZaMA0GCSqGSIb3DQEBAQUABIIBAHu3ebGaDqmI/Lwf77fvSI4X9k/VEKd4ChRJ yniLLjtta46kDoLTMNJ0j6+WEiOLA9RrSqoc+xQoWNnOKEz67x658y6lZWUSi16qN/pYbC2c 21Dg2KNhFVIZkg8Zz3lx9aB0EfUdQ6uXw5+i/53+YFTPJCJ70OAv37JLDgZHkqY5CqetEBjn lptc/GK/4PZNAp22wHeCACCU7N0LaEkH2IjwVbyRgLwNRu13yAF99pHyiBm+IwLzLmtmlWL1 loT2Cg/tjKACm0YCGsRvvIaMfvvwbOkbP4Kp/R1k0yS4fhltj9FO0LvbwSCgaNjO7i8X9lDS yRDIXfdK+uf0myGJGls= --B_3314787786_1601879-- --===============1652377807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============1652377807==-- From opsawg-bounces@ietf.org Fri Jan 16 11:00:08 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5A13A6AF6; Fri, 16 Jan 2009 11:00:08 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F523A6AF5 for ; Fri, 16 Jan 2009 11:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBt0FRZcflVT for ; Fri, 16 Jan 2009 11:00:06 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id C65303A6AF4 for ; Fri, 16 Jan 2009 11:00:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EFCFC9B84BA; Fri, 16 Jan 2009 10:59:51 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18236-07; Fri, 16 Jan 2009 10:59:51 -0800 (PST) Received: from [155.53.44.238] (nurnberg.redback.com [155.53.44.238]) by prattle.redback.com (Postfix) with ESMTP id D5E2E9B84B9; Fri, 16 Jan 2009 10:59:51 -0800 (PST) Message-ID: <4970D927.8040002@redback.com> Date: Fri, 16 Jan 2009 10:59:51 -0800 From: Michael Thatcher User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: opsawg@ietf.org X-Virus-Scanned: by amavisd-new at redback.com Subject: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org I would like to add to the enumeration for PhysicalClass to include disk & memory. What needs to happen? mike thatcher _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jan 18 02:15:22 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE773A6B4C; Sun, 18 Jan 2009 02:15:22 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D233A3A6B4A for ; Sun, 18 Jan 2009 02:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6RbNBJf2rIQ for ; Sun, 18 Jan 2009 02:15:21 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 145B83A677E for ; Sun, 18 Jan 2009 02:15:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,283,1231131600"; d="scan'208";a="158188734" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Jan 2009 05:15:05 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Jan 2009 05:15:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 11:14:37 +0100 Message-ID: In-Reply-To: <4970D927.8040002@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] ENTITY-MIB PhysicalClass extensions Thread-Index: Acl4DMc7TGWYxDBhT4iub3099AISFgBSAj5w References: <4970D927.8040002@redback.com> From: "Romascanu, Dan (Dan)" To: "Michael Thatcher" , Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This looks like an update to RFC 4133. Such incremental updates are within the scope of the OPSAWG. Probably the best thing to do is to write an Internet-Draft and ask the WG to consider it as part of the charter. Dan > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Michael Thatcher > Sent: Friday, January 16, 2009 9:00 PM > To: opsawg@ietf.org > Subject: [OPSAWG] ENTITY-MIB PhysicalClass extensions > > I would like to add to the enumeration for PhysicalClass to > include disk & memory. What needs to happen? > > mike thatcher > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jan 18 02:45:47 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2228A3A68D2; Sun, 18 Jan 2009 02:45:47 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62E53A68A2 for ; Sun, 18 Jan 2009 02:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QUCKZkJE-5l for ; Sun, 18 Jan 2009 02:45:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A88A53A6B4F for ; Sun, 18 Jan 2009 02:45:44 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87CE8C0005; Sun, 18 Jan 2009 11:45:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3iT+vfbq2k-G; Sun, 18 Jan 2009 11:45:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 515C6C002C; Sun, 18 Jan 2009 11:45:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3DBC08F9645; Sun, 18 Jan 2009 11:45:18 +0100 (CET) Date: Sun, 18 Jan 2009 11:45:18 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090118104518.GA15606@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Michael Thatcher , opsawg@ietf.org References: <4970D927.8040002@redback.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Sun, Jan 18, 2009 at 11:14:37AM +0100, Romascanu, Dan (Dan) wrote: > This looks like an update to RFC 4133. Such incremental updates are > within the scope of the OPSAWG. Probably the best thing to do is to > write an Internet-Draft and ask the WG to consider it as part of the > charter. It seems an appropriate solution would be to move the definition of PhysicalClass to a separate MIB module and perhaps even make IANA responsible for maintaining the MIB module (by using a suitable review process). Spinning a new revision of RFC 4133 is somewhat heavy to add an enumeration to PhysicalClass and since this can take some time, a temporary workaround is the value other(1) and a one column table augmenting entPhysicalTable where the column provides additional values. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jan 18 03:27:01 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC3B3A67D8; Sun, 18 Jan 2009 03:27:01 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB663A677E for ; Sun, 18 Jan 2009 03:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJxCT6ATgcTR for ; Sun, 18 Jan 2009 03:26:59 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1905B3A6407 for ; Sun, 18 Jan 2009 03:26:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,283,1231131600"; d="scan'208";a="158191127" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Jan 2009 06:26:41 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Jan 2009 06:26:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Jan 2009 12:26:18 +0100 Message-ID: In-Reply-To: <20090118104518.GA15606@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] ENTITY-MIB PhysicalClass extensions Thread-Index: Acl5WeYieNWGCYALQa2qFJ34ryzDbAABO3Jg References: <4970D927.8040002@redback.com> <20090118104518.GA15606@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org I agree that making the TC part of separate IANA-administered seems a better and more flexible solution. We need to revise RFC 4133 for this purpose, right? Dan > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Sunday, January 18, 2009 12:45 PM > To: Romascanu, Dan (Dan) > Cc: Michael Thatcher; opsawg@ietf.org > Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions > > On Sun, Jan 18, 2009 at 11:14:37AM +0100, Romascanu, Dan (Dan) wrote: > > This looks like an update to RFC 4133. Such incremental updates are > > within the scope of the OPSAWG. Probably the best thing to do is to > > write an Internet-Draft and ask the WG to consider it as > part of the > > charter. > > It seems an appropriate solution would be to move the > definition of PhysicalClass to a separate MIB module and > perhaps even make IANA responsible for maintaining the MIB > module (by using a suitable review process). Spinning a new > revision of RFC 4133 is somewhat heavy to add an enumeration > to PhysicalClass and since this can take some time, a > temporary workaround is the value other(1) and a one column > table augmenting entPhysicalTable where the column provides > additional values. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jan 18 04:31:01 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B960D3A6839; Sun, 18 Jan 2009 04:31:01 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3273A6839 for ; Sun, 18 Jan 2009 04:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkDTlKgBwGUX for ; Sun, 18 Jan 2009 04:30:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 54CA73A65A5 for ; Sun, 18 Jan 2009 04:30:59 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 827CAC002F; Sun, 18 Jan 2009 13:30:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iDP2D9778k+7; Sun, 18 Jan 2009 13:30:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4FF6C0012; Sun, 18 Jan 2009 13:30:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CA6938F9721; Sun, 18 Jan 2009 13:30:34 +0100 (CET) Date: Sun, 18 Jan 2009 13:30:34 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090118123034.GA15667@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Michael Thatcher , opsawg@ietf.org References: <4970D927.8040002@redback.com> <20090118104518.GA15606@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan (Dan) wrote: > I agree that making the TC part of separate IANA-administered seems a > better and more flexible solution. We need to revise RFC 4133 for this > purpose, right? When Bert Wijnen was AD, we had several meetings discussing simpler processes for updating MIB modules. I am not sure we ever converged on a solution that was actually implemented - but Bert might recall better than I do. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jan 18 15:26:55 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC083A6963; Sun, 18 Jan 2009 15:26:55 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41F73A6963 for ; Sun, 18 Jan 2009 15:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1Wg6rUwKmka for ; Sun, 18 Jan 2009 15:26:53 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 928FF3A6784 for ; Sun, 18 Jan 2009 15:26:51 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LOh2H-0004dt-KA; Mon, 19 Jan 2009 00:26:33 +0100 Message-ID: <4A54E56C595945CAA7D770C122C08FDD@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Romascanu, Dan \(Dan\)" References: <4970D927.8040002@redback.com><20090118104518.GA15606@elstar.local> <20090118123034.GA15667@elstar.local> In-Reply-To: <20090118123034.GA15667@elstar.local> Date: Mon, 19 Jan 2009 00:26:18 +0100 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0849591410==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============0849591410== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0537_01C979CC.8BBC1BE0" This is a multi-part message in MIME format. ------=_NextPart_000_0537_01C979CC.8BBC1BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think we really ever converged. In any event, if we want to transfer any such thing to IANA, it needs to go in a separate MIB module (maintained by IANA) and we need to document what the rules are for IANA to make dditions or changes. That could be a = small separate document which "updates 4133" or it could be a 4133bis with just that small change. I know... in theory this should be a very simple task. In practice we get through all the WG LC, IETF LC, IESG approval, = RFC-publication, IANA picking up the MIB module, Determining who will be technical = advisors/experts to IANA. Oh well... you ge the gist Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Romascanu, Dan (Dan)=20 Cc: opsawg@ietf.org=20 Sent: Sunday, January 18, 2009 1:30 PM Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan (Dan) wrote: > I agree that making the TC part of separate IANA-administered seems = a > better and more flexible solution. We need to revise RFC 4133 for = this > purpose, right? When Bert Wijnen was AD, we had several meetings discussing simpler processes for updating MIB modules. I am not sure we ever converged on a solution that was actually implemented - but Bert might recall better than I do. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0537_01C979CC.8BBC1BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't think we really ever converged.
In any event, if we want to transfer any such thing = to IANA,=20 it needs to
go in a separate MIB module (maintained by IANA) and = we need=20 to document
what the rules are for IANA to make dditions or = changes. That=20 could be a small
separate document which "updates 4133" or it could = be a=20 4133bis with
just that small change.
 
I know... in theory this should be a very simple=20 task.
In practice we get through all the WG LC, IETF LC, = IESG=20 approval, RFC-publication,
IANA picking up the MIB module, Determining who will = be=20 technical advisors/experts to IANA.
Oh well... you ge the gist
 
Bert
 
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Sunday, January 18, 2009 = 1:30=20 PM
Subject: Re: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, = Dan (Dan)=20 wrote:

> I agree that making the TC part of separate=20 IANA-administered seems a
> better and more flexible solution. = We need=20 to revise RFC 4133 for this
> purpose, right?

When Bert = Wijnen=20 was AD, we had several meetings discussing simpler
processes for = updating=20 MIB modules. I am not sure we ever converged on
a solution that was = actually implemented - but Bert might recall
better than I=20 do.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
------=_NextPart_000_0537_01C979CC.8BBC1BE0-- --===============0849591410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============0849591410==-- From opsawg-bounces@ietf.org Mon Jan 19 03:14:30 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D92628C196; Mon, 19 Jan 2009 03:14:30 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F0628C165 for ; Mon, 19 Jan 2009 03:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjGGH6f+3auT for ; Mon, 19 Jan 2009 03:14:27 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 81E8C28C140 for ; Mon, 19 Jan 2009 03:14:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,288,1231131600"; d="scan'208,217";a="149059361" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 19 Jan 2009 06:14:10 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jan 2009 06:14:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 12:13:54 +0100 Message-ID: In-Reply-To: <4A54E56C595945CAA7D770C122C08FDD@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] ENTITY-MIB PhysicalClass extensions Thread-Index: Acl5xDoxbo4VtG3AShGdaOs2/xdfswAVtTJg References: <4970D927.8040002@redback.com><20090118104518.GA15606@elstar.local> <20090118123034.GA15667@elstar.local> <4A54E56C595945CAA7D770C122C08FDD@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0867517013==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============0867517013== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A27.04F02A08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A27.04F02A08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unless I am missing something completely I fail to see how we can avoid revising RFC 4133. The PhysicalClass TC is in the MIB module defined there, in order to take it out and place it in a MIB module maintained by IANA we need a new version of the MIB module. Otherwise I agree with all that Bert says - it's not a technically complicated change but it has a certain overhead. Also, as a participant, I believe that such a revision of RFC 4133 is within the charter of OPSAWG and support doing it here.=20 =20 Dan =20 ________________________________ From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Monday, January 19, 2009 1:26 AM To: j.schoenwaelder@jacobs-university.de; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions =09 =09 I don't think we really ever converged. In any event, if we want to transfer any such thing to IANA, it needs to go in a separate MIB module (maintained by IANA) and we need to document what the rules are for IANA to make dditions or changes. That could be a small separate document which "updates 4133" or it could be a 4133bis with just that small change. =20 I know... in theory this should be a very simple task. In practice we get through all the WG LC, IETF LC, IESG approval, RFC-publication, IANA picking up the MIB module, Determining who will be technical advisors/experts to IANA. Oh well... you ge the gist =20 Bert =20 ----- Original Message -----=20 From: Juergen Schoenwaelder =20 To: Romascanu, Dan (Dan) =20 Cc: opsawg@ietf.org=20 Sent: Sunday, January 18, 2009 1:30 PM Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan (Dan) wrote: =09 > I agree that making the TC part of separate IANA-administered seems a > better and more flexible solution. We need to revise RFC 4133 for this > purpose, right? =09 When Bert Wijnen was AD, we had several meetings discussing simpler processes for updating MIB modules. I am not sure we ever converged on a solution that was actually implemented - but Bert might recall better than I do. =09 /js =09 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =09 ------_=_NextPart_001_01C97A27.04F02A08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Unless I am missing something completely I fail to = see how we=20 can avoid revising RFC 4133. The PhysicalClass TC is in the = MIB module=20 defined there, in order to take it out and place it in a MIB module = maintained=20 by IANA we need a new version of the MIB module. Otherwise I agree with = all that=20 Bert says - it's not a technically complicated change but it has a = certain=20 overhead. Also, as a participant, I believe that such a revision of = RFC=20 4133 is within the charter of OPSAWG and support doing it here.=20
 
Dan
 

From: Bert Wijnen (IETF)=20 [mailto:bertietf@bwijnen.net]
Sent: Monday, January 19, = 2009 1:26=20 AM
To: j.schoenwaelder@jacobs-university.de; Romascanu, Dan=20 (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

I don't think we really ever = converged.
In any event, if we want to transfer any such = thing to IANA,=20 it needs to
go in a separate MIB module (maintained by IANA) = and we need=20 to document
what the rules are for IANA to make dditions or = changes.=20 That could be a small
separate document which "updates 4133" or it could = be a=20 4133bis with
just that small change.
 
I know... in theory this should be a very simple=20 task.
In practice we get through all the WG LC, IETF LC, = IESG=20 approval, RFC-publication,
IANA picking up the MIB module, Determining who = will be=20 technical advisors/experts to IANA.
Oh well... you ge the gist
 
Bert
 
----- Original Message -----
From:=20 Juergen = Schoenwaelder=20
Sent: Sunday, January 18, = 2009 1:30=20 PM
Subject: Re: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, = Dan=20 (Dan) wrote:

> I agree that making the TC part of separate = IANA-administered seems a
> better and more flexible solution. = We need=20 to revise RFC 4133 for this
> purpose, right?

When Bert = Wijnen=20 was AD, we had several meetings discussing simpler
processes for = updating=20 MIB modules. I am not sure we ever converged on
a solution that = was=20 actually implemented - but Bert might recall
better than I=20 do.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring 1, = 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
= ------_=_NextPart_001_01C97A27.04F02A08-- --===============0867517013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============0867517013==-- From opsawg-bounces@ietf.org Mon Jan 19 03:52:38 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3943A6B91; Mon, 19 Jan 2009 03:52:38 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97C23A693F for ; Mon, 19 Jan 2009 03:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0I1mRDCo02N for ; Mon, 19 Jan 2009 03:52:36 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 64B5D3A6831 for ; Mon, 19 Jan 2009 03:52:34 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LOsfv-0005Am-4l; Mon, 19 Jan 2009 12:52:15 +0100 Message-ID: <2A4358C678B446C79D9752B084A3E0A9@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Romascanu, Dan \(Dan\)" , References: <4970D927.8040002@redback.com><20090118104518.GA15606@elstar.local> <20090118123034.GA15667@elstar.local> <4A54E56C595945CAA7D770C122C08FDD@BertLaptop> In-Reply-To: Date: Mon, 19 Jan 2009 12:51:54 +0100 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0718295294==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============0718295294== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0683_01C97A34.B4E7ADA0" This is a multi-part message in MIME format. ------=_NextPart_000_0683_01C97A34.B4E7ADA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An Update to RFC4133 would be=20 - explain we are adding one enumeration to the TC - explain we are splitting the TC off into an IANA MIB module - Add IANA instructions for new assignments - the 2 MIB modules. All the other text would no need to be repeated. It may be easier to just do a 4133bis.=20 Depends on how you look at it. I agree it would fiot in the charter of OPSAWG Bert ----- Original Message -----=20 From: Romascanu, Dan (Dan)=20 To: Bert Wijnen (IETF) ; j.schoenwaelder@jacobs-university.de=20 Cc: opsawg@ietf.org=20 Sent: Monday, January 19, 2009 12:13 PM Subject: RE: [OPSAWG] ENTITY-MIB PhysicalClass extensions Unless I am missing something completely I fail to see how we can = avoid revising RFC 4133. The PhysicalClass TC is in the MIB module = defined there, in order to take it out and place it in a MIB module = maintained by IANA we need a new version of the MIB module. Otherwise I = agree with all that Bert says - it's not a technically complicated = change but it has a certain overhead. Also, as a participant, I believe = that such a revision of RFC 4133 is within the charter of OPSAWG and = support doing it here.=20 Dan -------------------------------------------------------------------------= --- From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Monday, January 19, 2009 1:26 AM To: j.schoenwaelder@jacobs-university.de; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions I don't think we really ever converged. In any event, if we want to transfer any such thing to IANA, it = needs to go in a separate MIB module (maintained by IANA) and we need to = document what the rules are for IANA to make dditions or changes. That could = be a small separate document which "updates 4133" or it could be a 4133bis with just that small change. I know... in theory this should be a very simple task. In practice we get through all the WG LC, IETF LC, IESG approval, = RFC-publication, IANA picking up the MIB module, Determining who will be technical = advisors/experts to IANA. Oh well... you ge the gist Bert ----- Original Message -----=20 From: Juergen Schoenwaelder=20 To: Romascanu, Dan (Dan)=20 Cc: opsawg@ietf.org=20 Sent: Sunday, January 18, 2009 1:30 PM Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan (Dan) = wrote: > I agree that making the TC part of separate IANA-administered = seems a > better and more flexible solution. We need to revise RFC 4133 = for this > purpose, right? When Bert Wijnen was AD, we had several meetings discussing = simpler processes for updating MIB modules. I am not sure we ever = converged on a solution that was actually implemented - but Bert might recall better than I do. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0683_01C97A34.B4E7ADA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
An Update to RFC4133 would be
- explain we are adding one enumeration to the = TC
- explain we are splitting the TC off into an IANA = MIB=20 module
- Add IANA instructions for new = assignments
- the 2 MIB modules.
 
All the other text would no need to be = repeated.
It may be easier to just do a 4133bis.
Depends on how you look at it.
 
I agree it would fiot in the charter of = OPSAWG
 
Bert
----- Original Message -----
From:=20 Romascanu, Dan=20 (Dan)
To: Bert Wijnen (IETF) ; j.schoenwaelder@jaco= bs-university.de=20
Sent: Monday, January 19, 2009 = 12:13=20 PM
Subject: RE: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

Unless I am missing something completely I fail = to see how=20 we can avoid revising RFC 4133. The PhysicalClass TC is in = the MIB=20 module defined there, in order to take it out and place it in a MIB = module=20 maintained by IANA we need a new version of the MIB module. Otherwise = I agree=20 with all that Bert says - it's not a technically complicated change = but it has=20 a certain overhead. Also, as a participant, I believe that such a = revision of RFC 4133 is within the charter of OPSAWG and support = doing it=20 here.
 
Dan
 

From: Bert Wijnen (IETF)=20 [mailto:bertietf@bwijnen.net]
Sent: Monday, January 19, = 2009 1:26=20 AM
To: j.schoenwaelder@jacobs-university.de; Romascanu, = Dan=20 (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG]=20 ENTITY-MIB PhysicalClass extensions

I don't think we really ever = converged.
In any event, if we want to transfer any such = thing to=20 IANA, it needs to
go in a separate MIB module (maintained by IANA) = and we=20 need to document
what the rules are for IANA to make dditions or = changes.=20 That could be a small
separate document which "updates 4133" or it = could be a=20 4133bis with
just that small change.
 
I know... in theory this should be a very simple = task.
In practice we get through all the WG LC, IETF = LC, IESG=20 approval, RFC-publication,
IANA picking up the MIB module, Determining who = will be=20 technical advisors/experts to IANA.
Oh well... you ge the gist
 
Bert
 
----- Original Message ----- =
From:=20 Juergen=20 Schoenwaelder
Sent: Sunday, January 18, = 2009 1:30=20 PM
Subject: Re: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

On Sun, Jan 18, 2009 at 12:26:18PM +0100, = Romascanu, Dan=20 (Dan) wrote:

> I agree that making the TC part of = separate=20 IANA-administered seems a
> better and more flexible = solution. We=20 need to revise RFC 4133 for this
> purpose, = right?

When Bert=20 Wijnen was AD, we had several meetings discussing = simpler
processes for=20 updating MIB modules. I am not sure we ever converged on
a = solution=20 that was actually implemented - but Bert might recall
better = than I=20 do.

/js

--
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring = 1, 28759=20 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
<= /BODY> ------=_NextPart_000_0683_01C97A34.B4E7ADA0-- --===============0718295294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============0718295294==-- From opsawg-bounces@ietf.org Mon Jan 19 04:00:47 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C9728C1B5; Mon, 19 Jan 2009 04:00:47 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3261728C15B for ; Mon, 19 Jan 2009 04:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsgMhDUWGZ6Y for ; Mon, 19 Jan 2009 04:00:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3AA0528C1AB for ; Mon, 19 Jan 2009 04:00:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,289,1231131600"; d="scan'208,217";a="134463702" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Jan 2009 06:59:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 19 Jan 2009 06:59:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jan 2009 12:59:36 +0100 Message-ID: In-Reply-To: <2A4358C678B446C79D9752B084A3E0A9@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] ENTITY-MIB PhysicalClass extensions Thread-Index: Acl6LGLQ4mb73p7xQnezAOI9tD1RIwAAG86g References: <4970D927.8040002@redback.com><20090118104518.GA15606@elstar.local> <20090118123034.GA15667@elstar.local> <4A54E56C595945CAA7D770C122C08FDD@BertLaptop> <2A4358C678B446C79D9752B084A3E0A9@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1911628181==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --===============1911628181== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A2D.670F5804" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A2D.670F5804 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, yes, but in RFC 4133 the MIB definition is already more than 50% of the text, so if you add mandatory boilerplate and other text the update document may end by being same or almost the same size as the document itself, plus now we have the complexity of having two documents to look at.=20 =20 Anyway, we can let the WG decide what path to take in case they agree to adopt this as a WG item, of course.=20 =20 Dan =20 ________________________________ From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Monday, January 19, 2009 1:52 PM To: Romascanu, Dan (Dan); j.schoenwaelder@jacobs-university.de Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions =09 =09 An Update to RFC4133 would be=20 - explain we are adding one enumeration to the TC - explain we are splitting the TC off into an IANA MIB module - Add IANA instructions for new assignments - the 2 MIB modules. =20 All the other text would no need to be repeated. It may be easier to just do a 4133bis.=20 Depends on how you look at it. =20 I agree it would fiot in the charter of OPSAWG =20 Bert ----- Original Message -----=20 From: Romascanu, Dan (Dan) =20 To: Bert Wijnen (IETF) ; j.schoenwaelder@jacobs-university.de=20 Cc: opsawg@ietf.org=20 Sent: Monday, January 19, 2009 12:13 PM Subject: RE: [OPSAWG] ENTITY-MIB PhysicalClass extensions Unless I am missing something completely I fail to see how we can avoid revising RFC 4133. The PhysicalClass TC is in the MIB module defined there, in order to take it out and place it in a MIB module maintained by IANA we need a new version of the MIB module. Otherwise I agree with all that Bert says - it's not a technically complicated change but it has a certain overhead. Also, as a participant, I believe that such a revision of RFC 4133 is within the charter of OPSAWG and support doing it here.=20 =20 Dan =20 ________________________________ From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net]=20 Sent: Monday, January 19, 2009 1:26 AM To: j.schoenwaelder@jacobs-university.de; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions =09 =09 I don't think we really ever converged. In any event, if we want to transfer any such thing to IANA, it needs to go in a separate MIB module (maintained by IANA) and we need to document what the rules are for IANA to make dditions or changes. That could be a small separate document which "updates 4133" or it could be a 4133bis with just that small change. =20 I know... in theory this should be a very simple task. In practice we get through all the WG LC, IETF LC, IESG approval, RFC-publication, IANA picking up the MIB module, Determining who will be technical advisors/experts to IANA. Oh well... you ge the gist =20 Bert =20 ----- Original Message -----=20 From: Juergen Schoenwaelder =20 To: Romascanu, Dan (Dan) =20 Cc: opsawg@ietf.org=20 Sent: Sunday, January 18, 2009 1:30 PM Subject: Re: [OPSAWG] ENTITY-MIB PhysicalClass extensions On Sun, Jan 18, 2009 at 12:26:18PM +0100, Romascanu, Dan (Dan) wrote: =09 > I agree that making the TC part of separate IANA-administered seems a > better and more flexible solution. We need to revise RFC 4133 for this > purpose, right? =09 When Bert Wijnen was AD, we had several meetings discussing simpler processes for updating MIB modules. I am not sure we ever converged on a solution that was actually implemented - but Bert might recall better than I do. =09 /js =09 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 =09 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org =09 https://www.ietf.org/mailman/listinfo/opsawg =09 ------_=_NextPart_001_01C97A2D.670F5804 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well, yes, but in RFC 4133 the MIB definition is = already more=20 than 50% of the text, so if you add mandatory boilerplate and other text = the=20 update document may end by being same or almost the same size as the = document=20 itself, plus now we have the complexity of having two documents to look = at.=20
 
Anyway, we can let the WG decide what path to take in case they = agree to=20 adopt this as a WG item, of course.
 
Dan
 

From: Bert Wijnen (IETF)=20 [mailto:bertietf@bwijnen.net]
Sent: Monday, January 19, = 2009 1:52=20 PM
To: Romascanu, Dan (Dan);=20 j.schoenwaelder@jacobs-university.de
Cc:=20 opsawg@ietf.org
Subject: Re: [OPSAWG] ENTITY-MIB = PhysicalClass=20 extensions

An Update to RFC4133 would be
- explain we are adding one enumeration to the=20 TC
- explain we are splitting the TC off into an IANA = MIB=20 module
- Add IANA instructions for new = assignments
- the 2 MIB modules.
 
All the other text would no need to be=20 repeated.
It may be easier to just do a 4133bis. =
Depends on how you look at it.
 
I agree it would fiot in the charter of = OPSAWG
 
Bert
----- Original Message -----
From:=20 Romascanu, Dan=20 (Dan)
To: Bert Wijnen (IETF) ; j.schoenwaelder@jaco= bs-university.de=20
Sent: Monday, January 19, = 2009 12:13=20 PM
Subject: RE: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

Unless I am missing something completely I fail = to see=20 how we can avoid revising RFC 4133. The PhysicalClass = TC is in the=20 MIB module defined there, in order to take it out and place it in a = MIB=20 module maintained by IANA we need a new version of the MIB module. = Otherwise=20 I agree with all that Bert says - it's not a technically complicated = change=20 but it has a certain overhead. Also, as a participant, I believe=20 that such a revision of RFC 4133 is within the charter of = OPSAWG=20 and support doing it here.
 
Dan
 

From: Bert Wijnen (IETF)=20 [mailto:bertietf@bwijnen.net]
Sent: Monday, January 19, = 2009=20 1:26 AM
To: j.schoenwaelder@jacobs-university.de; = Romascanu, Dan=20 (Dan)
Cc: opsawg@ietf.org
Subject: Re: = [OPSAWG]=20 ENTITY-MIB PhysicalClass extensions

I don't think we really ever = converged.
In any event, if we want to transfer any such = thing to=20 IANA, it needs to
go in a separate MIB module (maintained by = IANA) and we=20 need to document
what the rules are for IANA to make dditions = or changes.=20 That could be a small
separate document which "updates 4133" or it = could be a=20 4133bis with
just that small change.
 
I know... in theory this should be a very = simple=20 task.
In practice we get through all the WG LC, IETF = LC, IESG=20 approval, RFC-publication,
IANA picking up the MIB module, Determining = who will be=20 technical advisors/experts to IANA.
Oh well... you ge the gist
 
Bert
 
----- Original Message ----- =
From:=20 Juergen=20 Schoenwaelder
Sent: Sunday, January 18, = 2009 1:30=20 PM
Subject: Re: [OPSAWG] = ENTITY-MIB=20 PhysicalClass extensions

On Sun, Jan 18, 2009 at 12:26:18PM +0100, = Romascanu, Dan=20 (Dan) wrote:

> I agree that making the TC part of = separate=20 IANA-administered seems a
> better and more flexible = solution. We=20 need to revise RFC 4133 for this
> purpose, = right?

When=20 Bert Wijnen was AD, we had several meetings discussing=20 simpler
processes for updating MIB modules. I am not sure we = ever=20 converged on
a solution that was actually implemented - but = Bert=20 might recall
better than I do.

/js

-- =
Juergen=20 = Schoenwaelder          = =20 Jacobs University Bremen gGmbH
Phone: +49 421 200=20 3587         Campus Ring = 1,=20 28759 Bremen, Germany
Fax:   +49 421 200=20 3103         <http://www.jacobs-university.de= />
_______________________________________________
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg
<= /BLOCKQUOTE> ------_=_NextPart_001_01C97A2D.670F5804-- --===============1911628181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============1911628181==-- From opsawg-bounces@ietf.org Sat Jan 24 17:18:13 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16613A6850; Sat, 24 Jan 2009 17:18:13 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8183E3A6850 for ; Sat, 24 Jan 2009 17:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zypAzGDeTI1M for ; Sat, 24 Jan 2009 17:18:12 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1DFAF3A6848 for ; Sat, 24 Jan 2009 17:18:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 752A62C0008DF; Sun, 25 Jan 2009 02:17:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDOHN51DU8Yj; Sun, 25 Jan 2009 02:17:53 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 3688C2C00030D; Sun, 25 Jan 2009 02:17:33 +0100 (CET) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Sun, 25 Jan 2009 01:17:33 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Sun, 25 Jan 2009 02:17:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, thread-index: Acl1xa+dyCLM2jMTQxei6UFobFN47wAeRWjgAhL8ef4= From: "Juergen Quittek" To: "Dan Romascanu" , "Juergen Schoenwaelder" , "Scott O. Bradner" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1066079788==" Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1066079788== Content-Type: multipart/signed; boundary="B_3315694661_13650732"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3315694661_13650732 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, Below please find a review of draft-schoenw-syslog-msg-mib-01. The draft is clearly written, well elaborated and already in a mature state. Most of the comments I have are editorial, nits, or requests for clarification. Juergen Q. 1. Section 4, line 1: Why do you consider only the conversion of received SYSLOG messages to entries in the SyslogMsg tables? If you report log messages concerning the host of the syslog MIB module, couldn't it also make sense to directly generate table entries for local log messages without sending messages using the SYSLOG protocol to a local SYSLOG receiver and converter? If it does not make sense, it may be worth clarifying why. 2. Section 5, paragraph 2, line 8: I am not sure it is really "needed", because requirements for this MIB module are not elaborated to that detail. I would suggest "needed" -> "provided". 3. Section 6: It would be nice to have a text section before the MIB definitions that - gives an overview of included groups and tables - describes the mapping of SYSLOG messages to tables - gives and example of representing structured data (SD) in the syslogMsgSDTable, particularly including a case of an SD element having more than one parameter 4. syslogMsgTableMaxSize, DESCRIPTION clause, lines 2-3: "A particular setting does not guarantee that much data can be held." is a foggy phrasing. What does it mean? Do you want to say that it cannot be guaranteed that there may not be sufficient memory available for the maximum number of table entries indicated by this object? 5. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 1: "changes" -> "reduces" 6. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 2: What is the "oldest" syslog message? The one that is in the syslogMsgTable for the longest time. The one that was received by the SYSLOG receiver the longest time ago? The one with the oldest timestamp? In the last case: What if there is not timestamp? The SYSLOG protocol specification says that the timestamp is optional. 7. syslogMsgFacility, syslogMsgSeverity: Wouldn't it be useful to add a reference to section 6.2.1 of draft-ietf-syslog-protocol where the semantics and encoding of these objects is described? 8. syslogMsgVersion, DESCRIPTION clause: Why do you need a value indicating that the version is unknown? Your assumption in section 4 is that all entries come from a SYSLOG to SNMP converter. In the SYSLOG protocol the version number is mandatory. Thus it would always be known. 9. syslogMsgTimestamp: The timestamp is optional in the SYSLOG protocol. You should specify an encoding of an unknown timestamp. 10. syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID: Also for these objects it would be helpful to add a reference to Sections 6.2.4, 6.2.5, 6.2.6, or 6.2.7, respectively of draft-ietf-syslog-protocol 11. syslogMsgMsg, syslogMsgFlags: Can you always know if a SYSLOG message has been truncated? What if it has been truncated already by a SYSLOG relay? 12. syslogMsgMsg, DESCRIPTION clause, line 6: "truncated" -> "truncated by the SYSLOG to SNMP converter"? 13. syslogMsgMsg: Would't it be helpful to have a (read-only) object in the control group called syslogMsgMaxMsgSize? 14. syslogMsgFlags, DESCRIPTION clause, one but last line: "truncted" -> "truncated" 15. syslogMsgNotification, DESCRIPTION clause, last line: Can you give a reference to a description of notification message constraints? 16. syslogMsgReadOnlyCompliance, OBJECT syslogMsgEnableNotifications, DESCRIPTION clause, second sentence: What do you mean with "to be useful"? The MIB module can even be useful without sending notifications. 17. syslogMsgSDGroup, DESCRIPTION clause: the group contains just a single object. Do you really want to call this a "collection of objects"? On 14.01.09 12:55 "Dan Romascanu" wrote: > Are there at least three people who are not editors or ADs committed to > read and review the documents in the WG? > > Dan > > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Tuesday, January 13, 2009 11:27 PM >> To: Scott O. Bradner; Romascanu, Dan (Dan) >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping >> documents, >> >> On Mon, Dec 15, 2008 at 03:49:43PM -0500, Scott O. Bradner wrote: >> >>> there was some discussion of the WG adopting the SNMP <-> SYSLOG >>> mapping documents on the list back in november - at the >> time there was >>> some support for the idea >>> >>> see >>> http://www.ietf.org/mail-archive/web/opsawg/current/msg00326.html >>> >>> I'd like to see if what level of support there is at this point >> >> May I ask where we are with this? This is now waiting for a >> decision since the Dublin IETF (about half a year ago)... >> >> Thanks, >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3315694661_13650732 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBThJq2VZXeGpe6ONHUf lK5g7gCslTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAx MjUwMTE3NDBaMA0GCSqGSIb3DQEBAQUABIIBADQxW78G8Cf9qDIgZYbC7oxsQksoFRpvMnk6 TaLw1nfcPDw1LNj4S1yMsRKtbzDKE3+GGOmoJYwlaO0Vc/zz3feAI0c7gfPlF40r+vEQy9LR M9v8YfFHwV6PuVx/7EXBMuk5BezvmC3h2LXOObCZQkkvZEvgacxamv25LE/p/DFCNTDpbD8R KqETyP+9joP+3QhlvEmr5hOD1msPr6rA5+dhYKDLmLCNVRFcchGpC47YKSU/qG7La2Oy4SHA QNVgI5e26djvNyrH9Fn0NAHAT5DVyTPrFpLdz7GaY1Mvetptn0Tt1+bDsHZPFQ7wwNJ9jhZR DwtiBp+hBedW/t5NBmI= --B_3315694661_13650732-- --===============1066079788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============1066079788==-- From opsawg-bounces@ietf.org Sun Jan 25 08:40:34 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147DC3A6977; Sun, 25 Jan 2009 08:40:34 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53FD3A684B for ; Sun, 25 Jan 2009 08:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mv-zOXI6kyu for ; Sun, 25 Jan 2009 08:40:32 -0800 (PST) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 3E2B53A6977 for ; Sun, 25 Jan 2009 08:40:32 -0800 (PST) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 802B5129CDC6; Sun, 25 Jan 2009 11:40:13 -0500 (EST) To: opsawg@ietf.org Message-Id: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> Date: Sun, 25 Jan 2009 11:40:13 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a (hopefully final) WGLC for draft-ietf-opsawg-operations-and-management there was not enough respose to the last one back in October please let the list know what you think of the draft thanks Scott & Ted _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jan 27 00:38:15 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCD33A6B3A; Tue, 27 Jan 2009 00:38:15 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EB83A6B3A for ; Tue, 27 Jan 2009 00:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4kjl3sfto0K for ; Tue, 27 Jan 2009 00:38:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8C6793A6A53 for ; Tue, 27 Jan 2009 00:38:13 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD611C001F; Tue, 27 Jan 2009 09:37:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dD1X5EHqFoUw; Tue, 27 Jan 2009 09:37:48 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B811C0007; Tue, 27 Jan 2009 09:37:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC8C591B247; Tue, 27 Jan 2009 09:37:43 +0100 (CET) Date: Tue, 27 Jan 2009 09:37:43 +0100 From: Juergen Schoenwaelder To: "Scott O. Bradner" Message-ID: <20090127083743.GB12355@elstar.local> Mail-Followup-To: "Scott O. Bradner" , opsawg@ietf.org References: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Sun, Jan 25, 2009 at 11:40:13AM -0500, Scott O. Bradner wrote: > This is a (hopefully final) WGLC for > draft-ietf-opsawg-operations-and-management there was not enough > respose to the last one back in October My review of draft-ietf-opsawg-operations-and-management-05.txt: I find this a difficult document to review and I like to state clearly upfront that I very much appreciate the efforts spend on putting this document together. The reason for starting with this diclaimer is that I find it difficult to provide constructive comments in the form of concrete suggestions for changes. While reading, I observed the following: - The document makes a distinction between "Operational Considerations" (section 3) and "Management Considerations" (section 4) and I am not sure where the difference really is. I appears that section 4 is much more management technology oriented and organized following the FCAPS model but in general, I do not really see why some issues are operational considerations and others management considerations. Perhaps the document can be streamlined by merging these two sections together. (For example, 3.6 and 4.3.1 do in my view pretty much belong together.) - At times, the document reads like a collection of text fragments taken from other documents without a very clear story line. I sometimes had the feeling that things were not developing in a "natural way" (but it is difficult for me to say what such a "natural way" would look like without going through the whole exercise to dissect the document into its fragments and reassembling the puzzle again). - I am not sure the discussion what the "IETF Management Framework" means (historically and today) is that useful for designers of new protocols and it might raise controversial discussions. Why not replace this material with a section that provide a high-level summary of the management technologies that can be considered by protocol designers? In terms of structure, this could mean that the document should have this structure (in terms of top-level sections): 1. Introduction 2. Available Management Technologies (briefly mention SNMP, SYSLOG, RADIUS/DIAMETER, NETCONF, IPFIX, CLIs, GUIs, ... and outline where they are particularly strong and where not; this should be short and not a long elaboration) 3. Operational and Management Considerations 4. Documentation Guidelines .. ... This would lift some of the text currently in section 4 into section 2. I also killed the current section 2 since the core of this is already discussed in the introduction. As an alterntative, one could keep a section "Design for Operations and Management" but then some of the discussion currently in the introduction should be moved. - The "Terminology" section explains why RFC 2119 language is not used and then defines the terms "new protocol" and "protocol designers". The document later has quite some text related to terminology (e.g. the discussion of information model vs. data model). One option to consider is to move all text discussing or clarifying terminology into this "Terminology" section (including the text fragments pointing to RFC 3198 and RFC 3444). Some editorial nits: - Define the acronym CLI the first time it is used. - Is "later/never phase" a typo or there by intention? - I am not sure this sentence is correct: This document sets forth a list of subjective guidelines and a list of objective criteria by which a protocol designer can evaluate whether the protocol that he/she has developed addresses common operations and management needs. I am actually not sure whether the distinction between "subjective guidelines" and "objective criteria" is worth to have. What I believe is valuable is the checklist phrased as a collection of questions to consider. - The first paragraph in 2.1 should in my opinion cite RFC 3410. But as mentioned above, I am not a big fan of this discussion at all. - s/algoithms/algorithms - Some text on top of page 8 that looks scratch pad text. - s/should there be/Should there be - s/gyaranteed/guaranteed - garbaled sentence or can the right counters that can be polled as needed? - s/desoigners/designer - s/For example, Sometimes/For example, sometimes - s/should they stop counting/Should they stop counting - A.1: Make it clear that scalability in terms of operations and management is meant, not in terms of the primary protocol functions. OLD Does the solution scale well? NEW Does the solution scale well from the operational and management perspective? - A.1: Capitalize the sentences with the questions consistently. - A.1: Add the following: Are there any coexistance issues? - A.1: Add some more detailed questions for the items refering to 3.5, 3.6 and 4.1. - Appendix A tries to make a distinction between Operational Considerations and Management Considerations and I am not sure this is a clear cut line. Earlier, the document talks about a single "Manageability Considerations" section. See also my more general comments above. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jan 27 01:14:05 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026993A6A50; Tue, 27 Jan 2009 01:14:05 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144AE3A6A50 for ; Tue, 27 Jan 2009 01:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88LzQyUVkrfX for ; Tue, 27 Jan 2009 01:14:03 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id E02793A69E0 for ; Tue, 27 Jan 2009 01:14:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,331,1231131600"; d="scan'208";a="149919161" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 27 Jan 2009 04:13:43 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2009 04:13:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jan 2009 10:13:37 +0100 Message-ID: In-Reply-To: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management Thread-Index: Acl/C6gsyhiJ7mUNRL+ckBVQkJvzcABU4pJg References: <20090125164013.802B5129CDC6@newdev.eecs.harvard.edu> From: "Romascanu, Dan (Dan)" To: "Scott O. Bradner" , Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Scott & Ted, This is in my opinion one of the most important documents currently in works in the OPSAWG and in the whole area. I would recommend that as many people as possible review and comment it. Clarification question - what is date for the WGLC to expire? Thanks and Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Sunday, January 25, 2009 6:40 PM > To: opsawg@ietf.org > Subject: [OPSAWG] (final) WGLC on > draft-ietf-opsawg-operations-and-management > > > This is a (hopefully final) WGLC for > draft-ietf-opsawg-operations-and-management > > there was not enough respose to the last one back in October > > please let the list know what you think of the draft > > thanks > > Scott & Ted > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jan 27 04:50:06 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85483A67A5; Tue, 27 Jan 2009 04:50:06 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A305F3A6ABB for ; Tue, 27 Jan 2009 04:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiWpoYZySqg3 for ; Tue, 27 Jan 2009 04:50:05 -0800 (PST) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id F39893A67A5 for ; Tue, 27 Jan 2009 04:50:04 -0800 (PST) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id DA46F12B70C7; Tue, 27 Jan 2009 07:49:45 -0500 (EST) To: dromasca@avaya.com, opsawg@ietf.org, sob@harvard.edu In-Reply-To: Message-Id: <20090127124945.DA46F12B70C7@newdev.eecs.harvard.edu> Date: Tue, 27 Jan 2009 07:49:45 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) Subject: Re: [OPSAWG] (final) WGLC on draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org > Clarification question - what is date for the WGLC to expire? =20 good question :-) feb 9 Scott & Ted _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jan 29 15:01:28 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616F33A68F1; Thu, 29 Jan 2009 15:01:28 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4F33A68F1 for ; Thu, 29 Jan 2009 15:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXPu0J9O86M8 for ; Thu, 29 Jan 2009 15:01:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D08E23A689F for ; Thu, 29 Jan 2009 15:01:25 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E9E4C0053; Fri, 30 Jan 2009 00:01:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qyqCl5oM4PYq; Fri, 30 Jan 2009 00:01:00 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA73FC000F; Fri, 30 Jan 2009 00:00:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 558F291D453; Fri, 30 Jan 2009 00:00:54 +0100 (CET) Date: Fri, 30 Jan 2009 00:00:53 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20090129230053.GA14953@elstar.local> Mail-Followup-To: Juergen Quittek , Dan Romascanu , "Scott O. Bradner" , opsawg@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org On Sun, Jan 25, 2009 at 02:17:40AM +0100, Juergen Quittek wrote: > Below please find a review of draft-schoenw-syslog-msg-mib-01. Thanks for your detailed and helpful review. > 1. Section 4, line 1: > Why do you consider only the conversion of received SYSLOG messages > to entries in the SyslogMsg tables? If you report log messages > concerning the host of the syslog MIB module, couldn't it also make > sense to directly generate table entries for local log messages > without sending messages using the SYSLOG protocol to a local > SYSLOG receiver and converter? > If it does not make sense, it may be worth clarifying why. My understanding is that the SYSLOG protocol itself does not discuss any forms of "local" or "direct" SYSLOG message delivery. On most Unix systems, even locally generated SYSLOG content is usually send via some local communication path to a SYSLOG daemon. So there is not really a distinction between messages originating form the local system and messages originating from remote systems. While it might be possible to add a sentence that implementations may bypass the generation of messages, I am not sure this is needed (you can always implement things in whatever way you like as long as it shows the right behaviour) and I am also not convinced this is necessarily a good idea to do. So for now, I have made no change. > 2. Section 5, paragraph 2, line 8: > I am not sure it is really "needed", because requirements for this > MIB module are not elaborated to that detail. I would suggest > "needed" -> "provided". OK > 3. Section 6: > It would be nice to have a text section before the MIB definitions that > - gives an overview of included groups and tables > - describes the mapping of SYSLOG messages to tables > - gives and example of representing structured data (SD) in the > syslogMsgSDTable, particularly including a case of an SD element > having more than one parameter I have added text and examples; please check the upcoming revised ID. > 4. syslogMsgTableMaxSize, DESCRIPTION clause, lines 2-3: > "A particular setting does not guarantee that much data can be held." > is a foggy phrasing. What does it mean? Do you want to say that > it cannot be guaranteed that there may not be sufficient memory > available for the maximum number of table entries indicated by this > object? Yes. I will change the wording to make this clearer. > 5. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 1: > "changes" -> "reduces" OK > 6. syslogMsgTableMaxSize, DESCRIPTION clause, paragraph 2, line 2: > What is the "oldest" syslog message? The one that is in the > syslogMsgTable for the longest time. The one that was received > by the SYSLOG receiver the longest time ago? The one with the > oldest timestamp? In the last case: What if there is not timestamp? > The SYSLOG protocol specification says that the timestamp is optional. New text: If an application reduces the limit while there are syslog messages in the syslogMsgTable, the syslog messages that are in the syslogMsgTable for the longest time MUST be discarded to bring the table down to the new limit. > 7. syslogMsgFacility, syslogMsgSeverity: > Wouldn't it be useful to add a reference to section 6.2.1 of > draft-ietf-syslog-protocol where the semantics and encoding of these > objects is described? Added REFERENCE clauses. > 8. syslogMsgVersion, DESCRIPTION clause: > Why do you need a value indicating that the version is unknown? > Your assumption in section 4 is that all entries come from a SYSLOG > to SNMP converter. In the SYSLOG protocol the version number is > mandatory. Thus it would always be known. This covers the case where an implementation also traditional SYSLOG messages where a version number might not be known. > 9. syslogMsgTimestamp: > The timestamp is optional in the SYSLOG protocol. You should specify > an encoding of an unknown timestamp. Good catch. I clarified that implementations use '0000000000000000'H for unknown timestamps. > 10. syslogMsgHostName, syslogMsgAppName, syslogMsgProcID, syslogMsgMsgID: > Also for these objects it would be helpful to add a reference to > Sections 6.2.4, 6.2.5, 6.2.6, or 6.2.7, respectively of > draft-ietf-syslog-protocol OK > 11. syslogMsgMsg, syslogMsgFlags: > Can you always know if a SYSLOG message has been truncated? > What if it has been truncated already by a SYSLOG relay? The syslogMsgFlags description says that the truncated bit is set "if the converter had to truncate the message". I will clarify the description of syslogMsgMsg to make this perhaps a bit clearer. > 12. syslogMsgMsg, DESCRIPTION clause, line 6: > "truncated" -> "truncated by the SYSLOG to SNMP converter"? OK > 13. syslogMsgMsg: > Would't it be helpful to have a (read-only) object in the > control group called syslogMsgMaxMsgSize? This is a good question. I personally believe such an object is useful. At the same time, I am not convinced this MIB module is the right place to define it. Well, it depends on what the semantics are. If it reports a limit imposed by the converter, I am fine. If the idea is to report the limit imposed by a SYSLOG transport or SYSLOG application, I believe this belongs into some other MIB. Perhaps you can make a more concrete proposal? > 14. syslogMsgFlags, DESCRIPTION clause, one but last line: > "truncted" -> "truncated" OK > 15. syslogMsgNotification, DESCRIPTION clause, last line: > Can you give a reference to a description of notification message > constraints? Unfortunately, the SNMP message size constraints and how they are dealt with in SNMPv3 is spread over several SNMP specifications. So I am not sure which reference to add. Do you have a proposal? > 16. syslogMsgReadOnlyCompliance, OBJECT syslogMsgEnableNotifications, > DESCRIPTION clause, second sentence: > What do you mean with "to be useful"? The MIB module can even be > useful without sending notifications. I have removed this sentence. > 17. syslogMsgSDGroup, DESCRIPTION clause: > the group contains just a single object. Do you really want to call > this a "collection of objects"? I am planning for extensions. More seriously, I do consider the INDEX objects listed in comments as part of the group. It is an strange artefact of the SMIv2 that they cannot be formally included. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jan 29 18:10:45 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B456A3A6B00; Thu, 29 Jan 2009 18:10:45 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3BC3A6B00 for ; Thu, 29 Jan 2009 18:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z03YEiLGEtRd for ; Thu, 29 Jan 2009 18:10:42 -0800 (PST) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 715FF3A68DC for ; Thu, 29 Jan 2009 18:10:42 -0800 (PST) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id B4DA312DC3E3; Thu, 29 Jan 2009 21:10:22 -0500 (EST) To: opsawg@ietf.org Message-Id: <20090130021022.B4DA312DC3E3@newdev.eecs.harvard.edu> Date: Thu, 29 Jan 2009 21:10:22 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) Subject: Re: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org back on Nov 6th we sent out a WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt there was no response to that last call that I can find in the mail list archive (or in my memory) we gotta see a bit more interest than that to proceed with this document. So, I'll try again this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt please comment (one way or the other) by Feb 12 tnx Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Fri Jan 30 03:55:45 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F5D3A6800; Fri, 30 Jan 2009 03:55:45 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F0628C250 for ; Fri, 30 Jan 2009 03:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rezki2GNs5UW for ; Fri, 30 Jan 2009 03:55:43 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by core3.amsl.com (Postfix) with ESMTP id 642A028C23B for ; Fri, 30 Jan 2009 03:55:43 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c28so133209ika.5 for ; Fri, 30 Jan 2009 03:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=kLyiFELBopHpNr++yBo8bNicmfdIUISBF5sdqBahRPU=; b=gXTZ5ANtqT5XgKCCL34XJCzcwN/nmMy3VnjtQ6weuujd6+ReAuBD9tfuLGK2dUN9xH 6NBsDyc6xyqziDQ9ADdtphZQc9/HLTGPx+VazHUCqiRW74L1hBIFgQzziUlzcTHc66ps 9vrUqs+XWehFlclyYrNKsQKTKobEwtS8GQPMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=B8P1+6QUnNCOtg6SEmSSa5x4N5AcqEl+c2MwAXDou4AUH7xhUm1LNfRK0I/ka7UFuF 30qPW9drSjhFkMkE1S/KNz8zSye4yhCTR7alCJiU4n1YK5SSiAFW61M9Z6MbIecg5v0V G6zIhYc3859gEQcoLC5p3zAHl/kU5f9ULtGZ0= MIME-Version: 1.0 Received: by 10.210.43.11 with SMTP id q11mr1273960ebq.61.1233316523018; Fri, 30 Jan 2009 03:55:23 -0800 (PST) In-Reply-To: <20090129230053.GA14953@elstar.local> References: <20090129230053.GA14953@elstar.local> Date: Fri, 30 Jan 2009 12:55:22 +0100 Message-ID: From: Rainer Gerhards To: j.schoenwaelder@jacobs-university.de, Juergen Quittek , Dan Romascanu , "Scott O. Bradner" , opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Hi Juergen S. and Q., I have not yet commented because I was unsure whether or not the draft will be adopted. Anyhow, at least one point I would like to add. On Fri, Jan 30, 2009 at 12:00 AM, Juergen Schoenwaelder wrote: > On Sun, Jan 25, 2009 at 02:17:40AM +0100, Juergen Quittek wrote: > >> Below please find a review of draft-schoenw-syslog-msg-mib-01. > > Thanks for your detailed and helpful review. > >> 1. Section 4, line 1: >> Why do you consider only the conversion of received SYSLOG messages >> to entries in the SyslogMsg tables? If you report log messages >> concerning the host of the syslog MIB module, couldn't it also make >> sense to directly generate table entries for local log messages >> without sending messages using the SYSLOG protocol to a local >> SYSLOG receiver and converter? >> If it does not make sense, it may be worth clarifying why. > > My understanding is that the SYSLOG protocol itself does not discuss > any forms of "local" or "direct" SYSLOG message delivery. On most Unix > systems, even locally generated SYSLOG content is usually send via > some local communication path to a SYSLOG daemon. So there is not > really a distinction between messages originating form the local > system and messages originating from remote systems. While it might be > possible to add a sentence that implementations may bypass the > generation of messages, I am not sure this is needed (you can always > implement things in whatever way you like as long as it shows the > right behaviour) and I am also not convinced this is necessarily a > good idea to do. So for now, I have made no change. I concur to Juergen S' point of view. In the real-world *nix use case (the dominant scenario) almost all messages are not generated by the syslog subsystem itself. Typically, there is a single startup and shutdown message emitted by the syslog subsystem and maybe a finite number of error messages concerning the configuration. In contrast, the syslog subsystem processes an infinite number of messages it receives from various sources. Note that "local" delivery, in the real-world-scenario, means that an application (e.g. mail mta) creates a log record and submits it via a local communications channel to the syslogd, which then (locally) receives the message. Of course, there are some other (less dominating) real-world scenarios where the application emitting a message is actually the original creator of its content. However, if that application is capable to send snmp notifications, why should it model a syslog-type snmp notification and not native format? The only reason I can think about is that it expects that the snmp receiver actually is interested in syslog message and thus uses the notification only to tunnel that message. That use case, IMHO, is not a valid one. In such a case, I'd prefer to see the originator to emit a native snmp notification and a converter on the receiving end converting that to syslog format. So my conclusion is that there is no need to support direct generation of syslog-type snmp notifications without receiving a syslog message first. Rainer _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Fri Jan 30 07:01:14 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027AC3A69FF; Fri, 30 Jan 2009 07:01:14 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580103A69FF for ; Fri, 30 Jan 2009 07:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv1UA-4vQNFr for ; Fri, 30 Jan 2009 07:01:12 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 5C7903A69F8 for ; Fri, 30 Jan 2009 07:01:12 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 9pXa1b00r0xGWP854r0uEX; Fri, 30 Jan 2009 15:00:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 9r0u1b00E0UQ6dC3Yr0upd; Fri, 30 Jan 2009 15:00:54 +0000 From: "David Harrington" To: , "'Juergen Quittek'" References: <20090129230053.GA14953@elstar.local> Date: Fri, 30 Jan 2009 10:00:53 -0500 Message-ID: <024801c982eb$8c394a20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090129230053.GA14953@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmCZXyRm2W4lWfOQ+SacRNirq4U8wAgiesA Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Hi, A couple comments on this thread: > > 7. syslogMsgFacility, syslogMsgSeverity: > > Wouldn't it be useful to add a reference to section 6.2.1 of > > draft-ietf-syslog-protocol where the semantics and > encoding of these > > objects is described? > > Added REFERENCE clauses. Note that, per syslog WG consensus, syslog-protocol 6.2.1 does not define normative values for facility and severity, but the TC-MIB defines normative mappings between labels and values which represent facility and severity, for use in MIB modules. I suggest the reference be the document containing the SYSLOG-TC-MIB, rather than the protocol document, since these objects use the normative mappings from the TCs. Most syslog documents have been through auth48 and are awaiting resolution of the 5378 mess. The RFC #s are: 5424 protocol 5425 tls 5426 udp 5427 SYSLOG-TC-MIB > > 15. syslogMsgNotification, DESCRIPTION clause, last line: > > Can you give a reference to a description of notification message > > constraints? > > Unfortunately, the SNMP message size constraints and how they are > dealt with in SNMPv3 is spread over several SNMP specifications. So I > am not sure which reference to add. Do you have a proposal? How about: "Implementations may truncate the message part of the syslog message such that it fits into the size constraints imposed by the implementation environment and the notification message size constraints imposed by maxMessageSize [rfc3412] and SNMP transport mappings." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Fri Jan 30 08:18:35 2009 Return-Path: X-Original-To: opsawg-archive@optimus.ietf.org Delivered-To: ietfarch-opsawg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4093A6ABA; Fri, 30 Jan 2009 08:18:35 -0800 (PST) X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348853A6ABA for ; Fri, 30 Jan 2009 08:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.366 X-Spam-Level: X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sapg2u+3eHj for ; Fri, 30 Jan 2009 08:18:32 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A57F33A68EC for ; Fri, 30 Jan 2009 08:18:28 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0UGEAD05532 for ; Fri, 30 Jan 2009 16:14:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C982F6.55A8C894" Date: Fri, 30 Jan 2009 11:18:04 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41824B2E0@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposed update to syslog Alarm Thread-Index: AcmC9lRK5chC14ZjTdmi+Zx7V3/4oA== From: "Sharon Chisholm" To: Subject: [OPSAWG] Proposed update to syslog Alarm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C982F6.55A8C894 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Attached is the propose update to the Syslog Alarm draft as a result of comments received during working group last call. I believe it addresses all known issues. Please let me know if you have any comments or corrections and I can make any necessary changes before posting this as version -02. Thanks and thanks again for those who took the time to review the document. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C982F6.55A8C894 Content-Type: text/html; name="rfcdiff.htm" Content-Transfer-Encoding: base64 Content-Description: rfcdiff.htm Content-Disposition: attachment; filename="rfcdiff.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW9wc2F3Zy1zeXNsb2ctYWxhcm0t MDEudHh0IGRyYWZ0LWdlcmhhcmRzLWNoaXNob2xtLXN5c2xvZy1hbGFybS1taWIudHh0PC90aXRs ZT48L2hlYWQ+PGJvZHk+CjxwcmU+CgpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gQ2hpc2hvbG0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9ydGVsCklu dGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSLiBHZXJoYXJkcwpFeHBpcmVzOiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPk1heSA2LDwv Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPkF1Z3VzdCAzLDwvZm9u dD48L3N0cm9uZz4gMjAwOSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBZGlz Y29uIEdtYkgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPk5vdmVtYmVyIDIsIDIwMDg8L2ZvbnQ+ PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPkphbnVhcnkgMzAsIDIwMDk8L2Zv bnQ+PC9zdHJvbmc+CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxhcm1zIGluIFNZU0xP RwogICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZHJhZnQtaWV0Zi1v cHNhd2ctc3lzbG9nLWFsYXJtLTAxLnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAg ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZHJhZnQtaWV0Zi1vcHNhd2ctc3lzbG9nLWFs YXJtLTAyLnR4dDwvZm9udD48L3N0cm9uZz4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1 Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0 IGFueQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhl IG9yIHNoZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBh bnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQs IGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAg VGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5v dGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRz IGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3Ry YWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwu CgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+TWF5IDYsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+QXVndXN0IDMsPC9mb250Pjwvc3Ryb25nPiAyMDA5LgoKQ29weXJpZ2h0IE5vdGljZQoKICAg Q29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPigy MDA4KS48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4oMjAwOSku PC9mb250Pjwvc3Ryb25nPgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhv dyB0byBzZW5kIGFsYXJtIGluZm9ybWF0aW9uIGluIHN5c2xvZy4gIEl0CiAgIGluY2x1ZGVzIHRo ZSBtYXBwaW5nIG9mIElUVSBwZXJjZWl2ZWQgc2V2ZXJpdGllcyBvbnRvIHN5c2xvZyBtZXNzYWdl CiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZmllbGRzLjwvZm9udD48L3N0cmlrZT4KICAg PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmZpZWxkcyBhbmQgYSBudW1iZXIgb2YgYWxhcm0t c3BlY2lmaWMgU0QtUEFSQU0gZGVmaW5pdGlvbnMgZnJvbSBYLjczMwogICBhbmQgdGhlIElFVEYg QWxhcm0gTUlCLjwvZm9udD48L3N0cm9uZz4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50 cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMKICAgICAxLjEuICB0ZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDIuICBTZXZlcml0eSBNYXBwaW5nIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAzLiAgQWxhcm0gU1RSVUNU VVJFRC1EQVRBIEVsZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAg ICAzLjEuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFsYXJtZWRSZXNvdXJjZTwvZm9udD48 L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5yZXNvdXJjZSAuIC4gLiAuPC9m b250Pjwvc3Ryb25nPiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NQogICAgIDMuMi4gIHByb2JhYmxlQ2F1c2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDUKICAgICAzLjMuICBwZXJjZWl2ZWRTZXZlcml0eSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMy40LiAgZXZlbnRUeXBlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDMu NS4gIHRyZW5kSW5kaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDYKICAgICAzLjYuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnJlc291cmNlTWFw cGluZzwvZm9udD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5yZXNvdXJj ZU9JRCBhbmQgcmVzb3VyY2VVUkk8L2ZvbnQ+PC9zdHJvbmc+ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjYKICAgNC4gIEV4YW1wbGVz PC9mb250Pjwvc3Ryb25nPiAuIC4gLiAuIC4gLiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz42 CiAgIDQuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+LiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgNS48L2ZvbnQ+PC9zdHJv bmc+ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz43CiAgIDUuPC9mb250Pjwvc3Ry aWtlPiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjkKICAgNi48L2ZvbnQ+PC9zdHJvbmc+ ICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz44CiAgIDYuPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MTAKICAgNy48L2ZvbnQ+PC9zdHJvbmc+ICBB Y2tub3dsZWRnbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz45CiAgIDcuPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MTEKICAgOC48L2ZvbnQ+PC9zdHJvbmc+ICBSZWZl cmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjEwCiAgICAgNy4xLjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjEyCiAgICAgOC4xLjwvZm9udD48L3N0cm9uZz4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4xMAogICAgIDcuMi48L2ZvbnQ+PC9zdHJpa2U+ IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4xMgogICAgIDguMi48L2ZvbnQ+PC9zdHJvbmc+ ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+MTA8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz4xMjwvZm9udD48L3N0cm9uZz4KICAgQXV0aG9ycycgQWRkcmVz c2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzdHJp a2U+PGZvbnQgY29sb3I9J3JlZCc+MTE8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJz4xMzwvZm9udD48L3N0cm9uZz4KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzdHJpa2U+PGZvbnQg Y29sb3I9J3JlZCc+MTI8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz4xNDwvZm9udD48L3N0cm9uZz4KCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEluIGFkZGl0aW9uIHRv IHNlbmRpbmcgb3V0IGFsYXJtIGluZm9ybWF0aW9uIGFzeW5jaHJvbm91c2x5IHZpYQogICBwcm90 b2NvbHMgc3VjaCBhcyBTTk1QIG9yIE5ldGNvbmYsIG1hbnkgaW1wbGVtZW50YXRpb25zIGFsc28g bG9nCiAgIGFsYXJtcyB2aWEgc3lzbG9nLiAgVGhpcyBtZW1vIGRlZmluZXMgYSBzZXQgb2YgU0Qt UEFSQU0gdG8gc3VwcG9ydAogICBsb2dnaW5nIGFuZCBkZWZpbmVzIGEgbWFwcGluZyBvZiBzeXNs b2cgc2V2ZXJpdHkgdG8gdGhlIHNldmVyaXR5IG9mCiAgIHRoZSBhbGFybS4KCiAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5UaGUgQWxhcm0gTUlCIChSRkMgMzg3NykgaW5jbHVkZWQgbWFu ZGF0b3J5IGFsYXJtIGZpZWxkcyBmcm9tIFguNzMzCiAgIGFzIHdlbGwgYXMgaW5mb3JtYXRpb24g ZnJvbSBYLjczNi4gIEluIGFkZGl0aW9uYWwsIHRoZSBBbGFybSBNSUIKICAgaW50cm9kdWNlZCBp dHMgb3duIGFsYXJtIGZpZWxkcy4gIFRoaXMgbWVtbyByZXVzZXMgdGVybWlub2xvZ3kgYW5kCiAg IGZpZWxkcyBmcm9tIHRoZSBBbGFybSBNSUIuPC9mb250Pjwvc3Ryb25nPgoKMS4xLiAgdGVybWlu b2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMyMTE5IFtSRkMyMTE5XS4KCiAgIEFsYXJt IHJlbGF0ZWQgdGVybWlub2xvZ3kgaXMgZGVmaW5lZCBpbiBbUkZDMzg3N10uCgoyLiAgU2V2ZXJp dHkgTWFwcGluZwoKICAgVGhlIEFsYXJtIE1JQiBSRkMzODc3IFtSRkMzODc3XSBkZWZpbmVzIElU VSBwZXJjZWl2ZWQgc2V2ZXJpdGllcwogICB3aGljaCBhcmUgdXNlZnVsIHRvIGJlIGFibGUgdG8g cmVsYXRlIHRvIHRoZSBzeXNsb2cgbWVzc2FnZSBmaWVsZHMsCiAgIHBhcnRpY3VsYXJseSBpbiB0 aGUgY2FzZSB3aGVyZSBhbGFybXMgYXJlIGJlaW5nIGxvZ2dlZC4gIFRoaXMgbWVtbwogICBkZXNj cmliZXMgdGhlIHJlcHJlc2VudGF0aW9uIG9mIElUVSBwZXJjZWl2ZWQgc2V2ZXJpdGllcyBpbgog ICBhcHByb3ByaWF0ZSBzeXNsb2cgZmllbGRzIGRlc2NyaWJlZCBpbiBbU3lzbG9nXS4gIFN5c2xv ZyBvZmZlcnMgYm90aAogICBhIHNvLWNhbGxlZCBTRVZFUklUWSBhcyB3ZWxsIGFzIFNUUlVDVFVS RUQtREFUQS4gIER1ZSB0byBjb25zdHJhaW50cwogICBpbiBzeXNsb2csIHRoZXJlIGlzIG5vIG9u ZS10by1vbmUgbWFwcGluZyBwb3NzaWJsZSBmb3IgU0VWRVJJVFkuICBBCiAgIFNUUlVDVFVSRUQt REFUQSBlbGVtZW50IGlzIGRlZmluZWQgdG8gYWxsb3cgaW5jbHVzaW9uIG9mIHRoZQogICB1bm1v ZGlmaWVkIElUVSBwZXJjZWl2ZWQgc2V2ZXJpdHkuCgogICBTeXNsb2cgc3VwcG9ydHMgc2V2ZXJp dHkgdmFsdWVzIGRpZmZlcmVudCBmcm9tIElUVSBwZXJjZWl2ZWQKICAgc2V2ZXJpdGllcy4gIFRo ZXNlIGFyZSBkZWZpbmVkIGluIHNlY3Rpb24gNi4yLjEgb2YgW1N5c2xvZ10uICBUaGUKICAgbWFw cGluZyBzaG93biBpbiB0YWJsZSAxIGJlbG93IFNIT1VMRCBiZSB1c2VkIHRvIG1hcCBJVFUgcGVy Y2VpdmVkCiAgIHNldmVyaXRpZXMgdG8gc3lzbG9nIHNldmVyaXRpZXMuCgogICAgICAgICAgIElU VSBQZXJjZWl2ZWQgU2V2ZXJpdHkgICAgICBzeXNsb2cgU0VWRVJJVFkgKE5hbWUpCiAgICAgICAg ICAgQ3JpdGljYWwgICAgICAgICAgICAgICAgICAgIDEgKEFsZXJ0KQogICAgICAgICAgIE1ham9y ICAgICAgICAgICAgICAgICAgICAgICAyIChDcml0aWNhbCkKICAgICAgICAgICBNaW5vciAgICAg ICAgICAgICAgICAgICAgICAgMyAoRXJyb3IpCiAgICAgICAgICAgV2FybmluZyAgICAgICAgICAg ICAgICAgICAgIDQgKFdhcm5pbmcpCiAgICAgICAgICAgSW5kZXRlcm1pbmF0ZSAgICAgICAgICAg ICAgIDUgKE5vdGljZSkKICAgICAgICAgICBDbGVhcmVkICAgICAgICAgICAgICAgICAgICAgNSAo Tm90aWNlKQoKICAgICAgICBUYWJsZSAxLiBJVFVQZXJjZWl2ZWRTZXZlcml0eSB0byBzeXNsb2cg U0VWRVJJVFkgbWFwcGluZy4KCjMuICBBbGFybSBTVFJVQ1RVUkVELURBVEEgRWxlbWVudHMKCiAg IFNUUlVDVFVSRUQtREFUQSBhbGxvd3MgdG8gaW5jbHVkZSBhbnkgc3RydWN0dXJlZCBpbmZvcm1h dGlvbiBpbnRvIGEKICAgc3lzbG9nIG1lc3NhZ2UuICBUaGUgZm9sbG93aW5nIGFyZSBkZWZpbmVk IHRvIHN1cHBvcnQgc3RydWN0dXJpbmcKICAgYWxhcm0gaW5mb3JtYXRpb24uCgogICBvICBSZXNv dXJjZSBVbmRlciBBbGFybQoKICAgbyAgUHJvYmFibGUgQ2F1c2UKCiAgIG8gIEV2ZW50IFR5cGUK CiAgIG8gIFBlcmNlaXZlZCBTZXZlcml0eQoKICAgbyAgVHJlbmQgSW5kaWNhdGlvbgoKICAgbyAg UmVzb3VyY2UgTWFwcGluZwoKICAgU3VwcG9ydCBvZiB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJz5hbGFybTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJh bGFybSI8L2ZvbnQ+PC9zdHJvbmc+IFNELUlEIGlzIG9wdGlvbmFsLCBidXQgb25jZSBzdXBwb3J0 ZWQgc29tZSBvZgogICB0aGUgU0QtUEFSQVJNUyBhcmUgbWFuZGF0b3J5LgoKMy4xLiAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5hbGFybWVkUmVzb3VyY2U8L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+cmVzb3VyY2U8L2ZvbnQ+PC9zdHJvbmc+CgogICBJZiB0 aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5hbGFybTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJhbGFybSI8L2ZvbnQ+PC9zdHJvbmc+IFNELUlEIGlzIHN1 cHBvcnRlZCwgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+YWxhcm1SZXNvdXJjZTwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJhbGFybVJlc291cmNlIjwv Zm9udD48L3N0cm9uZz4gU0QtUEFSQU0gTVVTVAogICBiZSBzdXBwb3J0ZWQuICBUaGlzIGl0ZW0g dW5pcXVlbHkgaWRlbnRpZmllcyB0aGUgcmVzb3VyY2UgdW5kZXIgYWxhcm0KICAgd2l0aGluIHRo ZSBzY29wZSBvZiBhIG5ldHdvcmsgZWxlbWVudC4KCjMuMi4gIHByb2JhYmxlQ2F1c2UKCiAgIElm IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFsYXJtPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+ImFsYXJtIjwvZm9udD48L3N0cm9uZz4gU0QtSUQgaXMg c3VwcG9ydGVkLCB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5wcm9iYWJsZUNhdXNlPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+InByb2JhYmxlQ2F1c2Ui PC9mb250Pjwvc3Ryb25nPiBTRC1QQVJBTSBNVVNUCiAgIGJlIHN1cHBvcnRlZC4gIFRoaXMgcGFy YW1ldGVyIGlzIHRoZSBtbmVtb25pYyBhc3NvY2lhdGVkIHdpdGggdGhlCiAgIElBTkFJdHVQcm9i YWJsZUNhdXNlIG9iamVjdCBkZWZpbmVkIHdpdGhpbiBbUkZDMzg3N10gYW5kIGFueQogICBzdWJz ZXF1ZW50IGV4dGVuc2lvbnMgZGVmaW5lZCBieSBJQU5BLiAgRm9yIGV4YW1wbGUsCiAgIElBTkFJ dHVQcm9iYWJsZUNhdXNlIGRlZmluZXMgYSB0cmFuc21pc3Npb24gZmFpbHVyZSB0byBhIHByb2Jh YmxlCiAgIGNhdXNlIG9mICd0cmFuc21pc3Npb25FcnJvciAoMTApJy4gIFRoZSB2YWx1ZSBvZiB0 aGUgcGFyYW1ldGVyIGluCiAgIHRoaXMgY2FzZSB3b3VsZCBiZSAndHJhbnNtaXNzaW9uRXJyb3In IgoKMy4zLiAgcGVyY2VpdmVkU2V2ZXJpdHkKCiAgIElmIHRoZSA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPmFsYXJtPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ ImFsYXJtIjwvZm9udD48L3N0cm9uZz4gU0QtSUQgaXMgc3VwcG9ydGVkLCB0aGUgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5wZXJjZWl2ZWRTZXZlcml0eTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJwZXJjZWl2ZWRTZXZlcml0eSI8L2ZvbnQ+PC9zdHJvbmc+ IFNELVBBUkFNCiAgIE1VU1QgYmUgc3VwcG9ydGVkLiAgU2ltaWxhciB0byB0aGUgZGVmaW5pdGlv biBvZiBwZXJjZWl2ZWQgc2V2ZXJpdHkKICAgaW4gW1guNzM2XSBhbmQgW1JGQzM4NzddLCB0aGlz IG9iamVjdCBjYW4gdGFrZSB0aGUgZm9sbG93aW5nIHZhbHVlczoKCiAgIG8gIGNsZWFyZWQKCiAg IG8gIGluZGV0ZXJtaW5hdGUKICAgbyAgY3JpdGljYWwKCiAgIG8gIG1ham9yCgogICBvICBtaW5v cgoKICAgbyAgd2FybmluZwoKICAgU2VlIHNlY3Rpb24gMiBmb3IgdGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoaXMgc2V2ZXJpdHkgYW5kIHN5c2xvZwogICBzZXZlcml0eS4KCjMuNC4gIGV2ZW50 VHlwZQoKICAgSWYgdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+YWxhcm08L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz4iYWxhcm0iPC9mb250Pjwvc3Ryb25n PiBTRC1JRCBpcyBzdXBwb3J0ZWQsIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmV2ZW50 VHlwZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJldmVudFR5 cGUiPC9mb250Pjwvc3Ryb25nPiBTRC1QQVJBTSBTSE9VTEQgYmUKICAgc3VwcG9ydGVkLiAgVGhp cyBwYXJhbWV0ZXIgaXMgdGhlIG1uZW1vbmljIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgSUFOQUl0 dUV2ZW50VHlwZSBvYmplY3QgZGVmaW5lZCB3aXRoaW4gW1JGQzM4NzddIGFuZCBhbnkgc3Vic2Vx dWVudAogICBleHRlbnNpb25zIGRlZmluZWQgYnkgSUFOQS4gIEZvciBleGFtcGxlLCBJQU5BSXR1 RXZlbnRUeXBlIGRlZmluZXMgYQogICBlbnZpcm9ubWVudGFsIGFsYXJtIHRvIGEgZXZlbnQgdHlw ZSBvZiAnZW52aXJvbm1lbnRhbEFsYXJtICg2KScuICBUaGUKICAgdmFsdWUgb2YgdGhlIHBhcmFt ZXRlciBpbiB0aGlzIGNhc2Ugd291bGQgYmUgJ2Vudmlyb25tZW50YWxBbGFybSciCgozLjUuICB0 cmVuZEluZGljYXRpb24KCiAgIElmIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFsYXJt PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ImFsYXJtIjwvZm9u dD48L3N0cm9uZz4gU0QtSUQgaXMgc3VwcG9ydGVkLCB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0n cmVkJz50cmVuZEluZGljYXRpb248L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz4idHJlbmRJbmRpY2F0aW9uIjwvZm9udD48L3N0cm9uZz4gU0QtUEFSQU0KICAgU0hP VUxEIGJlIHN1cHBvcnRlZC4gIFNpbWlsYXIgdG8gdGhlIGRlZmluaXRpb24gb2YgcGVyY2VpdmVk IHNldmVyaXR5CiAgIGluIFtYLjczM10gYW5kIFtSRkMzODc3XSwgdGhpcyBvYmplY3QgY2FuIHRh a2UgdGhlIGZvbGxvd2luZyB2YWx1ZXM6CgogICBvICBtb3JlU2V2ZXJlCgogICBvICBub0NoYW5n ZQoKICAgbyAgbGVzc1NldmVyZQoKMy42LiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5yZXNv dXJjZU1hcHBpbmc8L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ cmVzb3VyY2VPSUQgYW5kIHJlc291cmNlVVJJPC9mb250Pjwvc3Ryb25nPgoKICAgSWYgdGhlIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+YWxhcm08L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz4iYWxhcm0iPC9mb250Pjwvc3Ryb25nPiBTRC1JRCBpcyBzdXBwb3J0 ZWQsIHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnJlc291cmNlTWFwcGluZyBTRC1QQVJB TTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJyZXNvdXJjZU9J RCIgYW5kCiAgICJyZXNvdXJjZVVSSSIgU0QtUEFSQU1zPC9mb250Pjwvc3Ryb25nPiBTSE9VTEQg YmUgc3VwcG9ydGVkLiAgVGhpcyA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+aXMgcGFydGlj dWxhcmx5CiAgIHVzZWZ1bCBmb3IgdGhlIHN5c3RlbXMgdGhhdCBhbHNvIHN1cHBvcnQgU05NUC4g IFRoZXNlPC9mb250Pjwvc3Ryb25nPiBpdGVtIHVuaXF1ZWx5CiAgIGlkZW50aWZpZXMgdGhlIHJl c291cmNlIHVuZGVyIGFsYXJtIHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBuZXR3b3JrCiAgIGVsZW1l bnQuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPlRoaXM8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9J2dyZWVuJz4icmVzb3VyY2VPSUQiPC9mb250Pjwvc3Ryb25nPiBtdXN0 IGJlIHRoZSBzYW1lIHZhbHVlIGFzCiAgIGFsYXJtQWN0aXZlUmVzb3VyY2VJZCBbUkZDMzg3N10g Zm9yIHRoaXMgYWxhcm0gb3IgZm9sbG93IHNpbWlsYXIKICAgc2VtYW50aWNzIGlmIHRoZSBBbGFy bSBNSUIgaXMgbm90IHN1cHBvcnRlZC4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPiJyZXNv dXJjZVVSSSIgaXMgdGhlCiAgIHNhbWUgcmVzb3VyY2UsIGJ1dCBkZWZpbmVkIHVzaW5nIHRoZSBT Tk1QIFVSSSBbUkZDNDA4OF0uCgogICDCpyBCb3RoIHRoZSAicmVzb3VyY2UiIGFuZCB0aGUgInJl c291cmNlT0lEIiBwYXJhbWV0ZXJzIHBvaW50IGF0IHRoZQogICByZXNvdXJjZSBleHBlcmllbmNp bmcgdGhlIGFsYXJtLCBidXQgdGhlICJyZXNvdXJjZU9JRCIgaGFzIHN5bnRhY3RpYwogICBjb25z dHJhaW50IHJlcXVpcmluZyB0aGlzIHRvIGJlIGFuIE9JRC4gIEZvciBleGFtcGxlLCBpbiB0aGUg Y2FzZSBvZgogICBhbiBpbnRlcmZhY2UsICJyZXNvdXJjZU9JRCIgbWlnaHQgdGFrZSBhIHZhbHVl IG9mCiAgIDEuMy42LjEuMi4xLjIuMi4xLjEuNDIsIHdoaWNoIGlzIGlmSW5kZXggd2l0aCBhbiBp bnN0YW5jZSB2YWx1ZSBvZgogICA0Mi4gIFRoaXMgbWFrZXMgaXQgZWFzeSB0byBjb3JyZWxhdGUg dGhpcyBzeXNsb2cgYWxhcm0gd2l0aCBhbnkgU05NUAogICB0cmFwcyB0aGF0IGFyZSByZWNlaXZl ZCBvciB0byB1c2UgU05NUCB0byBnZXQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbgogICBhYm91dCB0 aGlzIGludGVyZmFjZS48L2ZvbnQ+PC9zdHJvbmc+Cgo0LiAgPHN0cm9uZz48Zm9udCBjb2xvcj0n Z3JlZW4nPkV4YW1wbGVzCgogICBFeGFtcGxlIDEgLSBNYW5kYXRvcnkgQWxhcm0gSW5mb3JtYXRp b24KCiAgICAmbHQ7MTY1Jmd0OzEgMjAwMy0xMC0xMVQyMjoxNDoxNS4wMDNaIG15bWFjaGluZS5l eGFtcGxlLmNvbQogICAgZXZudHNsb2cgLSBJRDQ3IFtleGFtcGxlU0RJREAzMjQ3MyBpdXQ9IjMi IGV2ZW50U291cmNlPQogICAgIkFwcGxpY2F0aW9uIiBldmVudElEPSIxMDExIl1bYWxhcm0gYWxh cm1SZXNvdXJjZT0ic3Ugcm9vdCIKICAgIHByb2JhYmxlQ2F1c2U9InVuYXV0aG9yaXplZEFjY2Vz c0F0dGVtcHQiCiAgICBwZXJjZWl2ZWRTZXZlcml0eT0ibWFqb3IiXQogICAgQk9NQW4gYXBwbGlj YXRpb24gZXZlbnQgbG9nIGVudHJ5Li4uCgogICBJbiB0aGlzIGV4YW1wbGUsIGV4dGVuZGVkIGZy b20gW1N5c2xvZ10sIHRoZSBWRVJTSU9OIGlzIDEgYW5kIHRoZQogICBGYWNpbGl0eSBoYXMgdGhl IHZhbHVlIG9mIDQuICBUaGUgc2V2ZXJpdHkgaXMgMi4gIFRoZSBtZXNzYWdlIHdhcwogICBjcmVh dGVkIG9uIDExIE9jdG9iZXIgMjAwMyBhdCAxMDoxNDoxNXBtIFVUQywgMyBtaWxsaXNlY29uZHMg aW50byB0aGUKICAgbmV4dCBzZWNvbmQuICBUaGUgbWVzc2FnZSBvcmlnaW5hdGVkIGZyb20gYSBo b3N0IHRoYXQgaWRlbnRpZmllcwogICBpdHNlbGYgYXMgIm15bWFjaGluZS5leGFtcGxlLmNvbSIu ICBUaGUgQVBQLU5BTUUgaXMgInN1IiBhbmQgdGhlCiAgIFBST0NJRCBpcyB1bmtub3duLiAgVGhl IE1TR0lEIGlzICJJRDQ3Ii4gIFdlIGhhdmUgaW5jbHVkZWQgYm90aCB0aGUKICAgc3RydWN0dXJl ZCBkYXRhIGZyb20gdGhlIG9yaWdpbmFsIGV4YW1wbGUsIGEgc2luZ2xlIGVsZW1lbnQgd2l0aCB0 aGUKICAgdmFsdWUgIltleGFtcGxlU0RJREAwIGl1dD0iMyIgZXZlbnRTb3VyY2U9IkFwcGxpY2F0 aW9uIgogICBldmVudElEPSIxMDExIl0iIGFuZCBhIG5ldyBvbmUgd2l0aCB0aGUgYWxhcm0gaW5m b3JtYXRpb24gZGVmaW5lZCBpbgogICB0aGlzIG1lbW8uICBUaGUgYWxhcm0gU0QtSUQgY29udGFp bnMgdGhlIG1hbmRhdG9yeSBTRC1QQVJBTVMgb2YKICAgYWxhcm1SZXNvdXJjZSwgcHJvYmFibGVD YXVzZSBhbmQgcHJlY2VpdmVkU2V2ZXJpdHkuICBUaGUgTVNHIGl0c2VsZgogICBpcyAiQW4gYXBw bGljYXRpb24gZXZlbnQgbG9nIGVudHJ5Li4uIiAgVGhlIEJPTSBhdCB0aGUgYmVnaW5uaW5nIG9m CiAgIE1TRyBpbmRpY2F0ZXMgVVRGLTggZW5jb2RpbmcuCgogICBFeGFtcGxlIDIgLSBBZGRpdGlv bmFsIEFsYXJtIEluZm9ybWF0aW9uCgogICAmbHQ7MTY1Jmd0OzEgMjAwNC0xMS0xMFQyMDoxNTox NS4wMDNaIG15bWFjaGluZS5leGFtcGxlLmNvbQogICBldm50c2xvZyAtIElENDggW2FsYXJtIGFs YXJtUmVzb3VyY2U9ImludGVyZmFjZSA0MiIKICAgcHJvYmFibGVDYXVzZT0idW5hdXRob3JpemVk QWNjZXNzQXR0ZW1wdCIKICAgcGVyY2VpdmVkU2V2ZXJpdHk9Im1ham9yIgogICBldmVudFR5cGU9 ImNvbW11bmljYXRpb25zQWxhcm0iCiAgIHJlc291cmNlT0lEID0iMS4zLjYuMS4yLjEuMi4yLjEu MS40MiJdCgogICBJbiB0aGlzIGV4YW1wbGUsIHdlIGluY2x1ZGUgdHdvIG9wdGlvbmFsIGFsYXJt IGZpZWxkcyAtIGV2ZW50VHlwZSBhbmQKICAgcmVzb3VyY2VPSUQuCgo1LjwvZm9udD48L3N0cm9u Zz4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBJbiBhZGRpdGlvbiB0byBnZW5lcmFsIHN5 c2xvZyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4KICAgW1N5c2xvZ10sIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0aCBhbGFybXMgbWF5IHByb3ZpZGUgaGFja2Vycwog ICB3aXRoIGhlbHBmdWwgaW5mb3JtYXRpb24gYWJvdXQgcGFydHMgb2YgdGhlIHN5c3RlbSBjdXJy ZW50bHkKICAgZXhwZXJpZW5jaW5nIHN0cmVzcyBhcyB3ZWxsIGFzIGdlbmVyYWwgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHN5c3RlbQogICBzdWNoIGFzIGludmVudG9yeS4KCiAgIFVzZXJzIHNob3Vs ZCBub3QgaGF2ZSBhY2Nlc3MgdG8gaW5mb3JtYXRpb24gaW4gYWxhcm1zIHRoYXQgdGhlaXIKICAg bm9ybWFsIGFjY2VzcyBwZXJtaXNzaW9ucyB3b3VsZCBub3QgcGVybWl0IGlmIHRoZSBpbmZvcm1h dGlvbiB3YXMKICAgYWNjZXNzZWQgaW4gYW5vdGhlciBtYW5uZXIuCgo8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPjUuPC9mb250Pjwvc3RyaWtlPgoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPlRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCBhY2Nlc3MgY29udHJvbCBtb2RlbCBmb3IgU1lT TE9HIGFuZCBoZW5jZQogICB0aGUgYWJpbGl0eSB0byBmaWx0ZXIgYWxhcm1zIGJhc2VkIG9uIGEg bm90aW9uIG9mIGEgcmVjZWl2ZXIgaWRlbnRpdHkKICAgaXMgYXQgYmVzdCBpbXBsZW1lbnRhdGlv biBzcGVjaWZpYy4KCjYuPC9mb250Pjwvc3Ryb25nPiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gcmVnaXN0ZXIgdGhlIFNELUlEcyBhbmQgUEFSQU0tTkFNRXMg c2hvd24gYmVsb3c6CgogICBTRC1JRCAgICAgICAgICAgICAgUEFSQU0tTkFNRQogICBhbGFybSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9QVElPTkFMCiAgICAgICAgICAgICAgICAg ICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmFsYXJtZWRSZXNvdXJjZTwvZm9udD48L3N0 cmlrZT4KICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5y ZXNvdXJjZTwvZm9udD48L3N0cm9uZz4gICAgICAgICAgIE1BTkRBVE9SWQogICAgICAgICAgICAg ICAgICAgICAgcHJvYmFibGVDYXVzZSAgICAgIE1BTkRBVE9SWQogICAgICAgICAgICAgICAgICAg ICAgcGVyY2VpdmVkU2V2ZXJpdHkgIE1BTkRBVE9SWQogICAgICAgICAgICAgICAgICAgICAgZXZl bnRUeXBlICAgICAgICAgIE9QVElPTkFMCiAgICAgICAgICAgICAgICAgICAgICB0cmVuZEluZGlj YXRpb24gICAgT1BUSU9OQUwKICAgICAgICAgICAgICAgICAgICAgIDxzdHJpa2U+PGZvbnQgY29s b3I9J3JlZCc+cmVzb3VyY2VNYXBwaW5nPC9mb250Pjwvc3RyaWtlPgogICAgICAgICAgICAgICAg ICAgICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnJlc291cmNlT0lEPC9mb250Pjwvc3Ry b25nPiAgICAgICAgT1BUSU9OQUwKCjxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+Ni48L2ZvbnQ+ PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+cmVzb3VyY2VVUkkgICAgICAgIE9QVElPTkFMCgo3LjwvZm9udD48L3N0cm9uZz4gIEFja25v d2xlZGdtZW50cwoKICAgVGhhbmtzIHRvIG1lbWJlcnMgb2YgdGhlIFN5c2xvZyBhbmQgT1BTQVdH IHdvcmsgZ3JvdXAgd2hvIGNvbnRyaWJ1dGVkCiAgIHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4KCjxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+Ny48L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+V2UnZCBhbHNvIGxpa2UgdG8gdGhhbmsgSnVlcmdlbiBTY2hvZW53YWVs ZGVyCiAgIGZvciBoaXMgZGV0YWlsZWQgcmV2aWV3LgoKOC48L2ZvbnQ+PC9zdHJvbmc+ICBSZWZl cmVuY2VzCgo8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjcuMS48L2ZvbnQ+PC9zdHJpa2U+Cgo8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+OC4xLjwvZm9udD48L3N0cm9uZz4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIHMuLCAiS2V5IHdvcmRzIGZvciBS RkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50cwogICAgICAgICAgICAgIExldmVscyIsIFJGQyAy MTE5LCBNYXJjaCAxOTk3LgoKICAgW1JGQzM4NzddICBDaGlzaG9sbSwgUy4gYW5kIEQuIFJvbWFz Y2FudSwgIkFsYXJtIE1hbmFnZW1lbnQKICAgICAgICAgICAgICBJbmZvcm1hdGlvbiBCYXNlIChN SUIpIiwgUkZDIDM4NzcsIFNlcHRlbWJlciAyMDA0LgoKICAgW1N5c2xvZ10gICBHZXJoYXJkcywg UmFpbmVyLiwgIlRoZSBzeXNsb2cgUHJvdG9jb2wiLAogICAgICAgICAgICAgIElEIGRyYWZ0LWll dGYtc3lzbG9nLXByb3RvY29sLTE5LnR4dCwgTm92ZW1iZXIgMjAwNi4KCjxzdHJpa2U+PGZvbnQg Y29sb3I9J3JlZCc+Ny4yLjwvZm9udD48L3N0cmlrZT4KCjxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz44LjIuPC9mb250Pjwvc3Ryb25nPiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1gu NzMzXSAgICBJVFUtVCwgIiJJbmZvcm1hdGlvbiBUZWNobm9sb2d5IC0gT3BlbiBTeXN0ZW1zCiAg ICAgICAgICAgICAgSW50ZXJjb25uZWN0aW9uIC0gU3lzdGVtIE1hbmFnZW1lbnQ6IEFsYXJtIFJl cG9ydGluZwogICAgICAgICAgICAgIEZ1bmN0aW9uIiIsIElUVS1UIFguNzMzLCAxOTkyLgoKICAg W1guNzM2XSAgICBJVFUtVCwgIiJJbmZvcm1hdGlvbiBUZWNobm9sb2d5IC0gT3BlbiBTeXN0ZW1z CiAgICAgICAgICAgICAgSW50ZXJjb25uZWN0aW9uIC0gU3lzdGVtIE1hbmFnZW1lbnQ6IFNlY3Vy aXR5IEFsYXJtCiAgICAgICAgICAgICAgUmVwb3J0aW5nIEZ1bmN0aW9uIiIsIElUVS1UIFguNzM2 LCAxOTkyLgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBTaGFyb24gQ2hpc2hvbG0KICAgTm9ydGVs CiAgIDM1MDAgQ2FybGluZyBBdmUKICAgTmVwZWFuLCBPbnRhcmlvICBLMkggOEU5CiAgIENhbmFk YQoKICAgRW1haWw6IHNjaGlzaG9sQG5vcnRlbC5jb20KCiAgIFJhaW5lciBHZXJoYXJkcwogICBB ZGlzY29uIEdtYkgKICAgTW96YXJ0c3RyYXNzZSAyMQogICBHcm9zc3JpbmRlcmZlbGQsIEJXICA5 Nzk1MAogICBHZXJtYW55CgogICBFbWFpbDogcmdlcmhhcmRzQGFkaXNjb24uY29tCgpGdWxsIENv cHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz4oMjAwOCkuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+KDIwMDkpLjwvZm9udD48L3N0cm9uZz4KCiAgIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNv bnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJB UyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUg UkVQUkVTRU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBT T0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRB U0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwg SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G CiAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBP UiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCkludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhl IElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBv ZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhh dCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9y IHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0 aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0 IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0 IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2gg cmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRv IHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJD UCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNy ZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFp bGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdl bmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJp ZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmlj YXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y eSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMgYW55 IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJp Z2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFy eQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJl ZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZv cm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCkFja25vd2xlZGdt ZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBi eSB0aGUgSUVURgogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4KPC9w cmU+CjwvYm9keT48L2h0bWw+Cg== ------_=_NextPart_001_01C982F6.55A8C894 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------_=_NextPart_001_01C982F6.55A8C894--