From mailman-admin@ietf.org Sun Feb 1 09:12:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13316 for ; Sun, 1 Feb 2004 09:12:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIKm-00052N-ED for disman-archive@lists.ietf.org; Sun, 01 Feb 2004 09:12:24 -0500 Date: Sun, 01 Feb 2004 09:12:24 -0500 Message-ID: <20040201141224.1364.17460.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From exim@www1.ietf.org Sun Feb 1 10:14:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24493 for ; Sun, 1 Feb 2004 10:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIR-0003zK-3U for disman-archive@odin.ietf.org; Sun, 01 Feb 2004 10:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11FE34c015324 for disman-archive@odin.ietf.org; Sun, 1 Feb 2004 10:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJIQ-0003z5-Ur for disman-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:14:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24179 for ; Sun, 1 Feb 2004 10:13:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJIN-0004xI-00 for disman-web-archive@ietf.org; Sun, 01 Feb 2004 10:13:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnInD-0004dP-00 for disman-web-archive@ietf.org; Sun, 01 Feb 2004 09:41:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnIPU-0006hK-00 for disman-web-archive@ietf.org; Sun, 01 Feb 2004 09:17:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnIC1-0003vw-6U for disman-web-archive@ietf.org; Sun, 01 Feb 2004 09:03:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIBx-0003pI-3k for disman-web-archive@ietf.org; Sun, 01 Feb 2004 09:03:17 -0500 Date: Sun, 01 Feb 2004 09:03:17 -0500 Message-ID: <20040201140317.1364.87015.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-web-archive@ietf.org: List Password // URL ---- -------- disman@ietf.org carehu https://www1.ietf.org/mailman/options/disman/disman-web-archive%40ietf.org From disman-admin@ietf.org Thu Feb 5 22:38:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26284 for ; Thu, 5 Feb 2004 22:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowob-0008E9-RT; Thu, 05 Feb 2004 22:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aownz-00081V-0C for disman@optimus.ietf.org; Thu, 05 Feb 2004 22:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26251 for ; Thu, 5 Feb 2004 22:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aownv-0006z2-00 for disman@ietf.org; Thu, 05 Feb 2004 22:37:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aowmx-0006wN-00 for disman@ietf.org; Thu, 05 Feb 2004 22:36:20 -0500 Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by ietf-mx with esmtp (Exim 4.12) id 1Aowm2-0006tp-00 for disman@ietf.org; Thu, 05 Feb 2004 22:35:22 -0500 Received: from h-68-164-93-15.snvacaid.dynamic.covad.net ([68.164.93.15] helo=oemcomputer) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aowly-0003Kh-00; Thu, 05 Feb 2004 19:35:18 -0800 Message-ID: <01ce01c3ec62$5ea61a40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Lou Berger" Cc: , "Disman \(E-mail\)" References: <4.3.2.7.2.20040130092632.03e9af00@mo-ex1> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Re: disman MIB Followup on gmpls-alarm-spec- Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Feb 2004 19:36:04 -0800 Hi - Looks ok to me. I've CC-ed the disman WG so folks there will be aware that you WG has found an application for our work. Thanks for keeping us posted. Randy ----- Original Message ----- > From: "Lou Berger" > To: "Tom Petch" ; "Randy Presuhn" > Cc: "Wijnen, Bert (Bert)" ; > Sent: Friday, January 30, 2004 7:01 AM > Subject: disman MIB Followup on gmpls-alarm-spec- > > Tom, (Randy) > > Thank you for providing this input. What we're looking for is a > reference that provides enumerated values for alarms. The ITU specs that > we found all provide text strings, which is what we're trying to avoid. It > seems that the disman MIB provides exactly what we're looking for. > > Please let us know if our intended use of the values defined in the MIB > makes sense from your (disman WG's) perspective, or if you recommend an > alternate approach. > > Thank you, > Lou > > PS The text in the new rev (submitted today) of the draft reads: > [from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] > 3.1.3. Error Codes and Values > > The Error Codes and Values used in ALARM_SPEC objects are the same as > those used in ERROR_SPEC objects. New Error Code values for use with > both ERROR_SPEC and ALARM_SPEC objects may be assigned to support > alarm types defined by other standards. > > In this document we define one new Error Code. The Error Code uses > the value TBA (by IANA) and is referred to as "Alarms". The values > used in the Error Values field are the same as the values used for > IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. > > The error values field is carried in an object with the format: > [from: rfc3473] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class-Num (6) | C-Type (3) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Error Node Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Error Code | Error Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > At 10:20 AM 11/19/2003, Tom Petch wrote: > >FYI > > > > > >As a member of the disman WG, I have followed the development of the alarm > >mib, > >currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has > >included formal liaison with SG4 and some contact with SG15 over such > >issues as > >who owns the code points and who can define them. SG4 have expressed > >satisfaction with the way in which the liaison with disman WG has worked > >(as on > >the IETF web site). > > > >But > > > >1) not knowing the working procedures of the ITU, I don't know if the > >agreement > >with disman extends to other IETF WG - the wording suggests not to me. > > > >2) the alarm mib is currently under debate between authors and WG chair with a > >list of some 80 issues being resolved; the most difficult to resolve > >appear IMO > >to be the ones relating to the existence of the ITU alarm table as an > >augmentation of the basic disman alarm table (and perhaps IMHO the lack of > >suitable features in SMIv2). The alarm mib is complex, not one I would expect > >people to be able to dip into and readily extract a part thereof. > > > >3) I have lost track of the start of this thread and just what it was that > >this, > >ccamp, WG > >wanted to include in what (and my Acrobat viewer renders the text of the > >bullet > >points in AlarmSpec as black blobs of varying size:-(! But whatever it is, I > >suggest you contact the > >disman chair, randy presuhn, to clarify the niceties of any interaction > >with the > >output of disman, whatever form that finally takes. It may be that M.3100 > >related material should be in a common MIB module and not included in the > >alarm > >mib because of issues of future updates and cross references from multiple > >WGs.. > > > >I think this is known as cross-functional review:-) > > > >Tom Petch > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) > >To: Brungard, Deborah A, ALABS ; Wijnen, Bert (Bert) > >; Adrian Farrel ; Lou Berger > > > >Cc: ccamp@ops.ietf.org > >Date: 18 November 2003 23:10 > >Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > >the disman mib has enumerations I believe! > > > > > >Thanks, > > >Bert > > > > > >> -----Original Message----- > > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > >> Sent: dinsdag 18 november 2003 23:06 > > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Thanks Bert. > > >> > > >> M.3100 provides the generic information model, X.733 and > > >> X.736 define OSI generics pointing to X.721, and X.721 > > >> provides abstract syntax. We were looking for an enumeration > > >> to use vs. needing to support abstract syntax strings in > > >> signaling. Any suggestions are welcome. > > >> Deborah > > >> > > >> -----Original Message----- > > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > >> Sent: Tuesday, November 11, 2003 11:46 AM > > >> To: Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Things to potentially look at: > > >> > > >> draft-ietf-disman-alarm-mib-15.txt > > >> > > >> [M.3100] ITU Recommendation M.3100, "Generic Network Information > > >> Model", 1995 > > >> > > >> [X.733] ITU Recommendation X.733, "Information Technology - Open > > >> Systems Interconnection - System Management: Alarm > > >> Reporting Function", 1992 > > >> > > >> [X.736] ITU Recommendation X.736, "Information Technology - Open > > >> Systems Interconnection - System Management: Security > > >> Alarm Reporting Function", 1992 > > >> > > >> Thanks, > > >> Bert > > >> > > >> > -----Original Message----- > > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> > Sent: dinsdag 11 november 2003 17:28 > > >> > To: Lou Berger > > >> > Cc: ccamp@ops.ietf.org > > >> > Subject: Re: Taking to the > > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > > >> > > > >> > Lou, > > >> > > > >> > I believe the alarm reference was M.3100. > > >> > > > >> > Can someone confirm? > > >> > > > >> > Adrian > > >> > > > >> > > > >> > > In the morning's meeting the AD's asked to bring the > > >> proposed Alarm > > >> > > communication extension to "the list". For today's > > >> > presentation see: > > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > > >> > > > > >> > > I believe the issues to be discussed are: > > >> > > 1) Is there general interest in this work? > > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > >> > > (We think there's some value, particularly with string > > >> > > and timestamp) > > >> > > 3) Are there good references for alarm code points? > > >> > > > > >> > > Thank, > > >> > > Lou (and co-authors) > > >> > > > >> > > > >> > > > > From exim@www1.ietf.org Thu Feb 5 22:39:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26328 for ; Thu, 5 Feb 2004 22:39:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowpx-0008Lz-C0 for disman-archive@odin.ietf.org; Thu, 05 Feb 2004 22:39:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i163dP86032107 for disman-archive@odin.ietf.org; Thu, 5 Feb 2004 22:39:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowpx-0008Lm-72 for disman-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 22:39:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26313 for ; Thu, 5 Feb 2004 22:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aowpt-00074G-00 for disman-web-archive@ietf.org; Thu, 05 Feb 2004 22:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aowox-000726-00 for disman-web-archive@ietf.org; Thu, 05 Feb 2004 22:38:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aowob-00070E-00 for disman-web-archive@ietf.org; Thu, 05 Feb 2004 22:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aowob-0008E9-RT; Thu, 05 Feb 2004 22:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aownz-00081V-0C for disman@optimus.ietf.org; Thu, 05 Feb 2004 22:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26251 for ; Thu, 5 Feb 2004 22:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aownv-0006z2-00 for disman@ietf.org; Thu, 05 Feb 2004 22:37:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aowmx-0006wN-00 for disman@ietf.org; Thu, 05 Feb 2004 22:36:20 -0500 Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by ietf-mx with esmtp (Exim 4.12) id 1Aowm2-0006tp-00 for disman@ietf.org; Thu, 05 Feb 2004 22:35:22 -0500 Received: from h-68-164-93-15.snvacaid.dynamic.covad.net ([68.164.93.15] helo=oemcomputer) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aowly-0003Kh-00; Thu, 05 Feb 2004 19:35:18 -0800 Message-ID: <01ce01c3ec62$5ea61a40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Lou Berger" Cc: , "Disman \(E-mail\)" References: <4.3.2.7.2.20040130092632.03e9af00@mo-ex1> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: disman MIB Followup on gmpls-alarm-spec- Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 5 Feb 2004 19:36:04 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - Looks ok to me. I've CC-ed the disman WG so folks there will be aware that you WG has found an application for our work. Thanks for keeping us posted. Randy ----- Original Message ----- > From: "Lou Berger" > To: "Tom Petch" ; "Randy Presuhn" > Cc: "Wijnen, Bert (Bert)" ; > Sent: Friday, January 30, 2004 7:01 AM > Subject: disman MIB Followup on gmpls-alarm-spec- > > Tom, (Randy) > > Thank you for providing this input. What we're looking for is a > reference that provides enumerated values for alarms. The ITU specs that > we found all provide text strings, which is what we're trying to avoid. It > seems that the disman MIB provides exactly what we're looking for. > > Please let us know if our intended use of the values defined in the MIB > makes sense from your (disman WG's) perspective, or if you recommend an > alternate approach. > > Thank you, > Lou > > PS The text in the new rev (submitted today) of the draft reads: > [from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] > 3.1.3. Error Codes and Values > > The Error Codes and Values used in ALARM_SPEC objects are the same as > those used in ERROR_SPEC objects. New Error Code values for use with > both ERROR_SPEC and ALARM_SPEC objects may be assigned to support > alarm types defined by other standards. > > In this document we define one new Error Code. The Error Code uses > the value TBA (by IANA) and is referred to as "Alarms". The values > used in the Error Values field are the same as the values used for > IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. > > The error values field is carried in an object with the format: > [from: rfc3473] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class-Num (6) | C-Type (3) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Error Node Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Error Code | Error Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > At 10:20 AM 11/19/2003, Tom Petch wrote: > >FYI > > > > > >As a member of the disman WG, I have followed the development of the alarm > >mib, > >currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has > >included formal liaison with SG4 and some contact with SG15 over such > >issues as > >who owns the code points and who can define them. SG4 have expressed > >satisfaction with the way in which the liaison with disman WG has worked > >(as on > >the IETF web site). > > > >But > > > >1) not knowing the working procedures of the ITU, I don't know if the > >agreement > >with disman extends to other IETF WG - the wording suggests not to me. > > > >2) the alarm mib is currently under debate between authors and WG chair with a > >list of some 80 issues being resolved; the most difficult to resolve > >appear IMO > >to be the ones relating to the existence of the ITU alarm table as an > >augmentation of the basic disman alarm table (and perhaps IMHO the lack of > >suitable features in SMIv2). The alarm mib is complex, not one I would expect > >people to be able to dip into and readily extract a part thereof. > > > >3) I have lost track of the start of this thread and just what it was that > >this, > >ccamp, WG > >wanted to include in what (and my Acrobat viewer renders the text of the > >bullet > >points in AlarmSpec as black blobs of varying size:-(! But whatever it is, I > >suggest you contact the > >disman chair, randy presuhn, to clarify the niceties of any interaction > >with the > >output of disman, whatever form that finally takes. It may be that M.3100 > >related material should be in a common MIB module and not included in the > >alarm > >mib because of issues of future updates and cross references from multiple > >WGs.. > > > >I think this is known as cross-functional review:-) > > > >Tom Petch > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) > >To: Brungard, Deborah A, ALABS ; Wijnen, Bert (Bert) > >; Adrian Farrel ; Lou Berger > > > >Cc: ccamp@ops.ietf.org > >Date: 18 November 2003 23:10 > >Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > >the disman mib has enumerations I believe! > > > > > >Thanks, > > >Bert > > > > > >> -----Original Message----- > > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > >> Sent: dinsdag 18 november 2003 23:06 > > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Thanks Bert. > > >> > > >> M.3100 provides the generic information model, X.733 and > > >> X.736 define OSI generics pointing to X.721, and X.721 > > >> provides abstract syntax. We were looking for an enumeration > > >> to use vs. needing to support abstract syntax strings in > > >> signaling. Any suggestions are welcome. > > >> Deborah > > >> > > >> -----Original Message----- > > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > >> Sent: Tuesday, November 11, 2003 11:46 AM > > >> To: Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Things to potentially look at: > > >> > > >> draft-ietf-disman-alarm-mib-15.txt > > >> > > >> [M.3100] ITU Recommendation M.3100, "Generic Network Information > > >> Model", 1995 > > >> > > >> [X.733] ITU Recommendation X.733, "Information Technology - Open > > >> Systems Interconnection - System Management: Alarm > > >> Reporting Function", 1992 > > >> > > >> [X.736] ITU Recommendation X.736, "Information Technology - Open > > >> Systems Interconnection - System Management: Security > > >> Alarm Reporting Function", 1992 > > >> > > >> Thanks, > > >> Bert > > >> > > >> > -----Original Message----- > > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> > Sent: dinsdag 11 november 2003 17:28 > > >> > To: Lou Berger > > >> > Cc: ccamp@ops.ietf.org > > >> > Subject: Re: Taking to the > > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > > >> > > > >> > Lou, > > >> > > > >> > I believe the alarm reference was M.3100. > > >> > > > >> > Can someone confirm? > > >> > > > >> > Adrian > > >> > > > >> > > > >> > > In the morning's meeting the AD's asked to bring the > > >> proposed Alarm > > >> > > communication extension to "the list". For today's > > >> > presentation see: > > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > > >> > > > > >> > > I believe the issues to be discussed are: > > >> > > 1) Is there general interest in this work? > > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > >> > > (We think there's some value, particularly with string > > >> > > and timestamp) > > >> > > 3) Are there good references for alarm code points? > > >> > > > > >> > > Thank, > > >> > > Lou (and co-authors) > > >> > > > >> > > > >> > > > > From disman-admin@ietf.org Fri Feb 6 20:29:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03622 for ; Fri, 6 Feb 2004 20:29:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHHI-0006PU-S7; Fri, 06 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHGP-0006Nf-7I for disman@optimus.ietf.org; Fri, 06 Feb 2004 20:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03577 for ; Fri, 6 Feb 2004 20:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHGN-0003mu-00 for disman@ietf.org; Fri, 06 Feb 2004 20:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHFO-0003ik-00 for disman@ietf.org; Fri, 06 Feb 2004 20:27:02 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1ApHES-0003ef-00 for disman@ietf.org; Fri, 06 Feb 2004 20:26:04 -0500 Received: from h-68-164-83-229.snvacaid.dynamic.covad.net ([68.164.83.229] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ApHES-0004dF-00 for disman@ietf.org; Fri, 06 Feb 2004 17:26:04 -0800 Message-ID: <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <01e701c3ec66$04a2bfe0$7f1afea9@oemcomputer> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Disman work items Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 6 Feb 2004 17:27:00 -0800 Hi - We need to decide whether we as a working group want to request a charter update, since we've practically completed our currently chartered work. For *each* of the following, I need feedback! If you think there is no point in doing the work, or if you think it has value, let me know. I *think* the schedule for these first three is realistic, given the level of implementation and review already seen, but sanity checks are most welcome! 1) advance remote operations MIB to Draft standard. We have an editor (Juergen Quittek) and active discussion on the list. I'd suggest February 2004 WG last call February 2004 implementation reports March 2004 submitted to IESG for consideration as Draft Standard 2) advance script MIB to Draft standard March 2004 WG last call March 2004 implementation reports April 2004 submitted to IESG for consideration as Draft standard 3) advance schedule MIB to Draft standard March 2004 WG last call March 2004 implementation reports April 2004 submitted to IESG for consideration as Draft Standard For these next three, in addition to gauging interest, I would need to recruit editors, since Ram's current duties do not permit him sufficient time to continue in his current role here. 4) log MIB 5) expression MIB 6) event MIB Randy From exim@www1.ietf.org Fri Feb 6 20:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03715 for ; Fri, 6 Feb 2004 20:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHJL-0006bL-38 for disman-archive@odin.ietf.org; Fri, 06 Feb 2004 20:31:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i171V7PC025369 for disman-archive@odin.ietf.org; Fri, 6 Feb 2004 20:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHJK-0006b6-Ve for disman-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 20:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03693 for ; Fri, 6 Feb 2004 20:31:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHJI-00040g-00 for disman-web-archive@ietf.org; Fri, 06 Feb 2004 20:31:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHII-0003wH-00 for disman-web-archive@ietf.org; Fri, 06 Feb 2004 20:30:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHHL-0003rF-00 for disman-web-archive@ietf.org; Fri, 06 Feb 2004 20:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHHI-0006PU-S7; Fri, 06 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHGP-0006Nf-7I for disman@optimus.ietf.org; Fri, 06 Feb 2004 20:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03577 for ; Fri, 6 Feb 2004 20:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHGN-0003mu-00 for disman@ietf.org; Fri, 06 Feb 2004 20:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHFO-0003ik-00 for disman@ietf.org; Fri, 06 Feb 2004 20:27:02 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1ApHES-0003ef-00 for disman@ietf.org; Fri, 06 Feb 2004 20:26:04 -0500 Received: from h-68-164-83-229.snvacaid.dynamic.covad.net ([68.164.83.229] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ApHES-0004dF-00 for disman@ietf.org; Fri, 06 Feb 2004 17:26:04 -0800 Message-ID: <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <01e701c3ec66$04a2bfe0$7f1afea9@oemcomputer> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Disman work items Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 6 Feb 2004 17:27:00 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - We need to decide whether we as a working group want to request a charter update, since we've practically completed our currently chartered work. For *each* of the following, I need feedback! If you think there is no point in doing the work, or if you think it has value, let me know. I *think* the schedule for these first three is realistic, given the level of implementation and review already seen, but sanity checks are most welcome! 1) advance remote operations MIB to Draft standard. We have an editor (Juergen Quittek) and active discussion on the list. I'd suggest February 2004 WG last call February 2004 implementation reports March 2004 submitted to IESG for consideration as Draft Standard 2) advance script MIB to Draft standard March 2004 WG last call March 2004 implementation reports April 2004 submitted to IESG for consideration as Draft standard 3) advance schedule MIB to Draft standard March 2004 WG last call March 2004 implementation reports April 2004 submitted to IESG for consideration as Draft Standard For these next three, in addition to gauging interest, I would need to recruit editors, since Ram's current duties do not permit him sufficient time to continue in his current role here. 4) log MIB 5) expression MIB 6) event MIB Randy From disman-admin@ietf.org Mon Feb 9 02:48:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05047 for ; Mon, 9 Feb 2004 02:48:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq69B-0004wk-Lj; Mon, 09 Feb 2004 02:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq68M-0004qv-8B for disman@optimus.ietf.org; Mon, 09 Feb 2004 02:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04758 for ; Mon, 9 Feb 2004 02:47:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq68I-0004M9-00 for disman@ietf.org; Mon, 09 Feb 2004 02:47:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq66Y-00043l-00 for disman@ietf.org; Mon, 09 Feb 2004 02:45:18 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aq65O-0003nw-00 for disman@ietf.org; Mon, 09 Feb 2004 02:44:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i197hVZW017654 for ; Mon, 9 Feb 2004 08:43:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i197hRHJ017653 for ; Mon, 9 Feb 2004 08:43:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i197hQZU017651; Mon, 09 Feb 2004 08:43:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4DC2FF0364; Mon, 9 Feb 2004 08:43:24 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Disman work items Message-ID: <2147483647.1076316227@[10.1.1.171]> In-Reply-To: <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> References: <01e701c3ec66$04a2bfe0$7f1afea9@oemcomputer> <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 08:43:47 +0100 Content-Transfer-Encoding: 7bit Hi Randy, --On 06.02.2004 17:27 Uhr -0800 Randy Presuhn wrote: > Hi - > > We need to decide whether we as a working group want to > request a charter update, since we've practically completed > our currently chartered work. > > For *each* of the following, I need feedback! If you think there is > no point in doing the work, or if you think it has value, let me know. > > I *think* the schedule for these first three is realistic, given the > level of implementation and review already seen, but sanity checks > are most welcome! > > 1) advance remote operations MIB to Draft standard. We have an > editor (Juergen Quittek) and active discussion on the list. I'd > suggest > February 2004 WG last call > February 2004 implementation reports > March 2004 submitted to IESG for consideration as Draft Standard That's fine with me. There are just a few open issues. But we have to close them this week. If I do not submit a new version by next Monday, we cannot have last call in February. > 2) advance script MIB to Draft standard > March 2004 WG last call > March 2004 implementation reports > April 2004 submitted to IESG for consideration as Draft standard > > 3) advance schedule MIB to Draft standard > March 2004 WG last call > March 2004 implementation reports > April 2004 submitted to IESG for consideration as Draft Standard > > For these next three, in addition to gauging interest, I would need to recruit > editors, since Ram's current duties do not permit him sufficient time to > continue in his current role here. > > 4) log MIB > 5) expression MIB > 6) event MIB Didn't we discuss moving the Expression MIB to 'historic'? If we do so, what is the issue of editing it? Thanks, Juergen > Randy > > > From exim@www1.ietf.org Mon Feb 9 02:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05287 for ; Mon, 9 Feb 2004 02:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6BR-0005Ga-Ah for disman-archive@odin.ietf.org; Mon, 09 Feb 2004 02:50:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i197oLsa020242 for disman-archive@odin.ietf.org; Mon, 9 Feb 2004 02:50:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6BQ-0005GP-KC for disman-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 02:50:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05207 for ; Mon, 9 Feb 2004 02:50:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6BM-0004wr-00 for disman-web-archive@ietf.org; Mon, 09 Feb 2004 02:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6A6-0004ie-00 for disman-web-archive@ietf.org; Mon, 09 Feb 2004 02:48:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq69E-0004XN-00 for disman-web-archive@ietf.org; Mon, 09 Feb 2004 02:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq69B-0004wk-Lj; Mon, 09 Feb 2004 02:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq68M-0004qv-8B for disman@optimus.ietf.org; Mon, 09 Feb 2004 02:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04758 for ; Mon, 9 Feb 2004 02:47:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq68I-0004M9-00 for disman@ietf.org; Mon, 09 Feb 2004 02:47:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq66Y-00043l-00 for disman@ietf.org; Mon, 09 Feb 2004 02:45:18 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aq65O-0003nw-00 for disman@ietf.org; Mon, 09 Feb 2004 02:44:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i197hVZW017654 for ; Mon, 9 Feb 2004 08:43:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i197hRHJ017653 for ; Mon, 9 Feb 2004 08:43:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i197hQZU017651; Mon, 09 Feb 2004 08:43:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4DC2FF0364; Mon, 9 Feb 2004 08:43:24 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Disman work items Message-ID: <2147483647.1076316227@[10.1.1.171]> In-Reply-To: <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> References: <01e701c3ec66$04a2bfe0$7f1afea9@oemcomputer> <006101c3ed19$7c09fae0$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 09 Feb 2004 08:43:47 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy, --On 06.02.2004 17:27 Uhr -0800 Randy Presuhn wrote: > Hi - > > We need to decide whether we as a working group want to > request a charter update, since we've practically completed > our currently chartered work. > > For *each* of the following, I need feedback! If you think there is > no point in doing the work, or if you think it has value, let me know. > > I *think* the schedule for these first three is realistic, given the > level of implementation and review already seen, but sanity checks > are most welcome! > > 1) advance remote operations MIB to Draft standard. We have an > editor (Juergen Quittek) and active discussion on the list. I'd > suggest > February 2004 WG last call > February 2004 implementation reports > March 2004 submitted to IESG for consideration as Draft Standard That's fine with me. There are just a few open issues. But we have to close them this week. If I do not submit a new version by next Monday, we cannot have last call in February. > 2) advance script MIB to Draft standard > March 2004 WG last call > March 2004 implementation reports > April 2004 submitted to IESG for consideration as Draft standard > > 3) advance schedule MIB to Draft standard > March 2004 WG last call > March 2004 implementation reports > April 2004 submitted to IESG for consideration as Draft Standard > > For these next three, in addition to gauging interest, I would need to recruit > editors, since Ram's current duties do not permit him sufficient time to > continue in his current role here. > > 4) log MIB > 5) expression MIB > 6) event MIB Didn't we discuss moving the Expression MIB to 'historic'? If we do so, what is the issue of editing it? Thanks, Juergen > Randy > > > From disman-admin@ietf.org Tue Feb 10 18:49:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00679 for ; Tue, 10 Feb 2004 18:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhci-00057B-VG; Tue, 10 Feb 2004 18:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhc0-00054r-Uz for disman@optimus.ietf.org; Tue, 10 Feb 2004 18:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00587 for ; Tue, 10 Feb 2004 18:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqhbx-0001TO-00 for disman@ietf.org; Tue, 10 Feb 2004 18:48:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqhb4-0001Ny-00 for disman@ietf.org; Tue, 10 Feb 2004 18:47:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aqhai-0001HE-00 for disman@ietf.org; Tue, 10 Feb 2004 18:46:56 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1ANkPZW066455 for ; Wed, 11 Feb 2004 00:46:26 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1ANkOog066454 for ; Wed, 11 Feb 2004 00:46:24 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1ANkOZU066452; Wed, 11 Feb 2004 00:46:24 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EDCCC1054D6; Wed, 11 Feb 2004 00:46:20 +0100 (CET) From: Juergen Quittek To: Giorgio Nunzi , disman@ietf.org Subject: Re: [Disman] ping-mib-3, traceroute-mib-4 Message-ID: <2147483647.1076460404@[10.1.1.26]> In-Reply-To: <4017992E.1090404@netlab.nec.de> References: <4017992E.1090404@netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 00:46:45 +0100 Content-Transfer-Encoding: 7bit Dear all, I support Giorgio's proposal to add another value called completed(3) to pingResultsOperStatus and traceRouteResultsOperStatus. If nobody objects, I'll add it to the next version and modify the DESCRIPTION clauses appropriately. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 28.01.2004 12:12 Uhr +0100 Giorgio Nunzi wrote: > Dear all, > > my second note involves again both the ping-mib and traceroute-mib. > > Refering to the ping-mib, it's not totally clear to me if the object > pingResultsOperStatus tells if the ping test has been completed. > > pingResultsOperStatus OBJECT-TYPE > SYNTAX INTEGER { > enabled(1), -- test is in progress > disabled(2) -- test has stopped > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Reflects the operational state of a pingCtlEntry: > enabled(1) - Test is active. > disabled(2) - Test has stopped." > ::= { pingResultsEntry 1 } > > If the related value of pingCtlFrequency is 0 and the test is > finished, no other tests are scheduled. At this point we cannot say > that the 'test is in progress'; on the other hand it's not clear if > the value disabled(2) should be set. I suggest two alternatives: > - extend the definition of the disabled(2) to include the case when no > more tests are scheduled; > - add a new value completed(3). > > I personally find more convenient the second solution to outline that > the values of the conceptual row will not change. > > Analogous considerations are valid concerning the objects > traceRouteResultsOperStatus and traceRouteCtlFrequency; the solutions > are the same as well. > > traceRouteResultsOperStatus OBJECT-TYPE > SYNTAX INTEGER { > enabled(1), -- test is in progress > disabled(2) -- test has stopped > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Reflects the operational state of an traceRouteCtlEntry: > > enabled(1) - Test is active. > disabled(2) - Test has stopped." > ::= { traceRouteResultsEntry 1 } > > Please let me know if you find this remark convenient. > > Giorgio > > -- > Giorgio Nunzi > Network Laboratories Heidelberg, Germany > NEC Europe Ltd. http://www.netlab.nec.de > > > From exim@www1.ietf.org Tue Feb 10 18:50:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00773 for ; Tue, 10 Feb 2004 18:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhe2-0005Cr-Ev for disman-archive@odin.ietf.org; Tue, 10 Feb 2004 18:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ANoMtv020012 for disman-archive@odin.ietf.org; Tue, 10 Feb 2004 18:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhe2-0005Ch-BE for disman-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00747 for ; Tue, 10 Feb 2004 18:50:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqhdz-0001gP-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 18:50:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqhd4-0001ao-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 18:49:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqhck-0001Us-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 18:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhci-00057B-VG; Tue, 10 Feb 2004 18:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhc0-00054r-Uz for disman@optimus.ietf.org; Tue, 10 Feb 2004 18:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00587 for ; Tue, 10 Feb 2004 18:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqhbx-0001TO-00 for disman@ietf.org; Tue, 10 Feb 2004 18:48:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqhb4-0001Ny-00 for disman@ietf.org; Tue, 10 Feb 2004 18:47:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aqhai-0001HE-00 for disman@ietf.org; Tue, 10 Feb 2004 18:46:56 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1ANkPZW066455 for ; Wed, 11 Feb 2004 00:46:26 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1ANkOog066454 for ; Wed, 11 Feb 2004 00:46:24 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1ANkOZU066452; Wed, 11 Feb 2004 00:46:24 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EDCCC1054D6; Wed, 11 Feb 2004 00:46:20 +0100 (CET) From: Juergen Quittek To: Giorgio Nunzi , disman@ietf.org Subject: Re: [Disman] ping-mib-3, traceroute-mib-4 Message-ID: <2147483647.1076460404@[10.1.1.26]> In-Reply-To: <4017992E.1090404@netlab.nec.de> References: <4017992E.1090404@netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 00:46:45 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I support Giorgio's proposal to add another value called completed(3) to pingResultsOperStatus and traceRouteResultsOperStatus. If nobody objects, I'll add it to the next version and modify the DESCRIPTION clauses appropriately. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 28.01.2004 12:12 Uhr +0100 Giorgio Nunzi wrote: > Dear all, > > my second note involves again both the ping-mib and traceroute-mib. > > Refering to the ping-mib, it's not totally clear to me if the object > pingResultsOperStatus tells if the ping test has been completed. > > pingResultsOperStatus OBJECT-TYPE > SYNTAX INTEGER { > enabled(1), -- test is in progress > disabled(2) -- test has stopped > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Reflects the operational state of a pingCtlEntry: > enabled(1) - Test is active. > disabled(2) - Test has stopped." > ::= { pingResultsEntry 1 } > > If the related value of pingCtlFrequency is 0 and the test is > finished, no other tests are scheduled. At this point we cannot say > that the 'test is in progress'; on the other hand it's not clear if > the value disabled(2) should be set. I suggest two alternatives: > - extend the definition of the disabled(2) to include the case when no > more tests are scheduled; > - add a new value completed(3). > > I personally find more convenient the second solution to outline that > the values of the conceptual row will not change. > > Analogous considerations are valid concerning the objects > traceRouteResultsOperStatus and traceRouteCtlFrequency; the solutions > are the same as well. > > traceRouteResultsOperStatus OBJECT-TYPE > SYNTAX INTEGER { > enabled(1), -- test is in progress > disabled(2) -- test has stopped > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Reflects the operational state of an traceRouteCtlEntry: > > enabled(1) - Test is active. > disabled(2) - Test has stopped." > ::= { traceRouteResultsEntry 1 } > > Please let me know if you find this remark convenient. > > Giorgio > > -- > Giorgio Nunzi > Network Laboratories Heidelberg, Germany > NEC Europe Ltd. http://www.netlab.nec.de > > > From disman-admin@ietf.org Tue Feb 10 19:03:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01073 for ; Tue, 10 Feb 2004 19:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhqH-0005iv-Os; Tue, 10 Feb 2004 19:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhpa-0005hg-8Y for disman@optimus.ietf.org; Tue, 10 Feb 2004 19:02:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01057 for ; Tue, 10 Feb 2004 19:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhpW-0002hL-00 for disman@ietf.org; Tue, 10 Feb 2004 19:02:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqhod-0002bs-00 for disman@ietf.org; Tue, 10 Feb 2004 19:01:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aqhnp-0002QM-00 for disman@ietf.org; Tue, 10 Feb 2004 19:00:29 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1ANxwZW066537 for ; Wed, 11 Feb 2004 00:59:59 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1ANxsoX066536 for ; Wed, 11 Feb 2004 00:59:54 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1ANxsZU066534; Wed, 11 Feb 2004 00:59:54 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 26BC6105500; Wed, 11 Feb 2004 00:59:52 +0100 (CET) From: Juergen Quittek To: Giorgio Nunzi , disman@ietf.org Subject: Re: [Disman] traceroute-mib-5, ping-mib-4, lookup-2 Message-ID: <2147483647.1076461216@[10.1.1.26]> In-Reply-To: <401799AA.3050808@netlab.nec.de> References: <401799AA.3050808@netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 01:00:17 +0100 Content-Transfer-Encoding: 7bit Giorgio, Thanks! I'll add this to the next version. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 28.01.2004 12:14 Uhr +0100 Giorgio Nunzi wrote: > Dear all, > > my last note involves all the three REMOPS MIBs. > I describe the traceroute-mib first. > > traceRouteMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active traceroute requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { traceRouteObjects 1 } > > An ambiguity holds when a value is set for this object and the agent > has already more active requests than the value specified. > The solutions possible are: > - kill the exceeding requests (for instance the ones started recently) > and start them again later; > - continue to process them. > I suggest the second case and to add the following sentence at the > bottom of the DESCRIPTION clause. > "The limit applies only to the new rquests being activated. When a > new value is set, the agent will process all the requests already > active, even if they exceed the limit just imposed." > > Analogous considerations (and solutions) are valid for the objects > pingMaxConcurrentRequests and lookupMaxConcurrentRequests. > > pingMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active ping requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { pingObjects 1 } > > > lookupMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active lookup requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { lookupObjects 1 } > > > Giorgio > > -- > Giorgio Nunzi > Network Laboratories Heidelberg, Germany > NEC Europe Ltd. http://www.netlab.nec.de > > > > > > From exim@www1.ietf.org Tue Feb 10 19:04:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01136 for ; Tue, 10 Feb 2004 19:04:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhrc-0005x0-Aa for disman-archive@odin.ietf.org; Tue, 10 Feb 2004 19:04:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B04O7r022868 for disman-archive@odin.ietf.org; Tue, 10 Feb 2004 19:04:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhrc-0005wl-7M for disman-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:04:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01106 for ; Tue, 10 Feb 2004 19:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhrY-0002vM-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 19:04:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhqZ-0002oh-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 19:03:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqhqH-0002iz-00 for disman-web-archive@ietf.org; Tue, 10 Feb 2004 19:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhqH-0005iv-Os; Tue, 10 Feb 2004 19:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhpa-0005hg-8Y for disman@optimus.ietf.org; Tue, 10 Feb 2004 19:02:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01057 for ; Tue, 10 Feb 2004 19:02:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhpW-0002hL-00 for disman@ietf.org; Tue, 10 Feb 2004 19:02:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqhod-0002bs-00 for disman@ietf.org; Tue, 10 Feb 2004 19:01:19 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aqhnp-0002QM-00 for disman@ietf.org; Tue, 10 Feb 2004 19:00:29 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1ANxwZW066537 for ; Wed, 11 Feb 2004 00:59:59 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1ANxsoX066536 for ; Wed, 11 Feb 2004 00:59:54 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1ANxsZU066534; Wed, 11 Feb 2004 00:59:54 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 26BC6105500; Wed, 11 Feb 2004 00:59:52 +0100 (CET) From: Juergen Quittek To: Giorgio Nunzi , disman@ietf.org Subject: Re: [Disman] traceroute-mib-5, ping-mib-4, lookup-2 Message-ID: <2147483647.1076461216@[10.1.1.26]> In-Reply-To: <401799AA.3050808@netlab.nec.de> References: <401799AA.3050808@netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 01:00:17 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Giorgio, Thanks! I'll add this to the next version. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 28.01.2004 12:14 Uhr +0100 Giorgio Nunzi wrote: > Dear all, > > my last note involves all the three REMOPS MIBs. > I describe the traceroute-mib first. > > traceRouteMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active traceroute requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { traceRouteObjects 1 } > > An ambiguity holds when a value is set for this object and the agent > has already more active requests than the value specified. > The solutions possible are: > - kill the exceeding requests (for instance the ones started recently) > and start them again later; > - continue to process them. > I suggest the second case and to add the following sentence at the > bottom of the DESCRIPTION clause. > "The limit applies only to the new rquests being activated. When a > new value is set, the agent will process all the requests already > active, even if they exceed the limit just imposed." > > Analogous considerations (and solutions) are valid for the objects > pingMaxConcurrentRequests and lookupMaxConcurrentRequests. > > pingMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active ping requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { pingObjects 1 } > > > lookupMaxConcurrentRequests OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "requests" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of concurrent active lookup requests > that are allowed within an agent implementation. A value > of 0 for this object implies that there is no limit for > the number of concurrent active requests in effect." > DEFVAL { 10 } > ::= { lookupObjects 1 } > > > Giorgio > > -- > Giorgio Nunzi > Network Laboratories Heidelberg, Germany > NEC Europe Ltd. http://www.netlab.nec.de > > > > > > From disman-admin@ietf.org Wed Feb 11 15:47:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21595 for ; Wed, 11 Feb 2004 15:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1G8-0003og-VT; Wed, 11 Feb 2004 15:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Fk-0003ne-ME for disman@optimus.ietf.org; Wed, 11 Feb 2004 15:46:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21487; Wed, 11 Feb 2004 15:46:34 -0500 (EST) Message-Id: <200402112046.PAA21487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-18.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:46:34 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-18.txt Pages : 71 Date : 2004-2-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11155620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11155620.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Feb 11 15:49:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22084 for ; Wed, 11 Feb 2004 15:49:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1I8-0003xs-Tr for disman-archive@odin.ietf.org; Wed, 11 Feb 2004 15:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKn4q4015234 for disman-archive@odin.ietf.org; Wed, 11 Feb 2004 15:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1I8-0003xb-Ou for disman-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21978 for ; Wed, 11 Feb 2004 15:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1I7-0003Jz-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:49:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1HB-0003D9-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:48:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1GE-00036B-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1G8-0003og-VT; Wed, 11 Feb 2004 15:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Fk-0003ne-ME for disman@optimus.ietf.org; Wed, 11 Feb 2004 15:46:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21487; Wed, 11 Feb 2004 15:46:34 -0500 (EST) Message-Id: <200402112046.PAA21487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-18.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:46:34 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-18.txt Pages : 71 Date : 2004-2-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11155620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11155620.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Feb 11 15:49:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22104 for ; Wed, 11 Feb 2004 15:49:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1IA-0003yB-5b for disman-archive@odin.ietf.org; Wed, 11 Feb 2004 15:49:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKn6cA015253 for disman-archive@odin.ietf.org; Wed, 11 Feb 2004 15:49:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1IA-0003xw-1E for disman-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21982 for ; Wed, 11 Feb 2004 15:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1I8-0003KE-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:49:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1HC-0003DJ-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:48:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1GE-00036C-00 for disman-web-archive@ietf.org; Wed, 11 Feb 2004 15:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1G9-0003oo-7Z; Wed, 11 Feb 2004 15:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Fq-0003nr-74 for disman@optimus.ietf.org; Wed, 11 Feb 2004 15:46:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21506; Wed, 11 Feb 2004 15:46:40 -0500 (EST) Message-Id: <200402112046.PAA21506@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:46:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-01.txt Pages : 76 Date : 2004-2-11 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-remops-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11155640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11155640.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Wed Feb 11 16:36:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21596 for ; Wed, 11 Feb 2004 15:47:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1G9-0003oo-7Z; Wed, 11 Feb 2004 15:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Fq-0003nr-74 for disman@optimus.ietf.org; Wed, 11 Feb 2004 15:46:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21506; Wed, 11 Feb 2004 15:46:40 -0500 (EST) Message-Id: <200402112046.PAA21506@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Feb 2004 15:46:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-01.txt Pages : 76 Date : 2004-2-11 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-remops-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11155640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11155640.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Fri Feb 13 10:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15999 for ; Fri, 13 Feb 2004 10:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfdh-00073t-Jp; Fri, 13 Feb 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfcl-00072n-6L for disman@optimus.ietf.org; Fri, 13 Feb 2004 10:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15963 for ; Fri, 13 Feb 2004 10:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfci-0004TC-00 for disman@ietf.org; Fri, 13 Feb 2004 10:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfbn-0004Pp-00 for disman@ietf.org; Fri, 13 Feb 2004 10:52:05 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArfbC-0004J6-00 for disman@ietf.org; Fri, 13 Feb 2004 10:51:27 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 08:50:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB495D542.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 08:50:42 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB495D542.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All, At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the features that we are working, a brief description of features is being posted in this WG. Please do share your comments, inputs, additional features etc. Thanks,Shailaja. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resourcesMIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified. (d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection: In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated. --=__PartB495D542.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 

At the moment a group of us are working on a draft-00-.

 

The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the features that we are working, a brief description of features is being posted in this WG.

 

Please do share your comments, inputs, additional features etc.

 

Thanks,

Shailaja.

 

 

Discussion:

 

Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects.

  

It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements.

 

Features:

 

(a) Goal: Simple configuration and Instance Management:

 

Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way.

 

  The OID of a columnar object variable consists of two parts: a columnar OID and an index.

 

Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter.

 

There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes.

 

 A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above.

 

(b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection.

 

Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always.

 

For example, consider the hrSWRunTable table in the Host resources

MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process

like notepad.exe.

 

If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized.

 

Strictly speaking, this problem should not arise if the indices of

tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the

case of the hrSWRunTable, the name of the software could serve as a good identifier.

 

This problem is addressed by introducing a concept of

'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time.

 

(c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object.

 

Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances.

 

For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services.

 

The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified.

 

(d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection:

 

In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated.

 

 

--=__PartB495D542.0__=-- From exim@www1.ietf.org Fri Feb 13 10:56:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16092 for ; Fri, 13 Feb 2004 10:56:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arffh-0007AK-9k for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 10:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFu5sZ027538 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 10:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arffh-0007A5-4E for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:56:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16083 for ; Fri, 13 Feb 2004 10:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arffe-0004e6-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 10:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfef-0004a8-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 10:55:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arfdh-0004Ws-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 10:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfdh-00073t-Jp; Fri, 13 Feb 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfcl-00072n-6L for disman@optimus.ietf.org; Fri, 13 Feb 2004 10:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15963 for ; Fri, 13 Feb 2004 10:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfci-0004TC-00 for disman@ietf.org; Fri, 13 Feb 2004 10:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfbn-0004Pp-00 for disman@ietf.org; Fri, 13 Feb 2004 10:52:05 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArfbC-0004J6-00 for disman@ietf.org; Fri, 13 Feb 2004 10:51:27 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 08:50:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB495D542.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 08:50:42 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB495D542.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All, At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the features that we are working, a brief description of features is being posted in this WG. Please do share your comments, inputs, additional features etc. Thanks,Shailaja. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resourcesMIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified. (d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection: In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated. --=__PartB495D542.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 

At the moment a group of us are working on a draft-00-.

 

The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the features that we are working, a brief description of features is being posted in this WG.

 

Please do share your comments, inputs, additional features etc.

 

Thanks,

Shailaja.

 

 

Discussion:

 

Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects.

  

It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements.

 

Features:

 

(a) Goal: Simple configuration and Instance Management:

 

Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way.

 

  The OID of a columnar object variable consists of two parts: a columnar OID and an index.

 

Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter.

 

There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes.

 

 A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above.

 

(b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection.

 

Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always.

 

For example, consider the hrSWRunTable table in the Host resources

MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process

like notepad.exe.

 

If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized.

 

Strictly speaking, this problem should not arise if the indices of

tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the

case of the hrSWRunTable, the name of the software could serve as a good identifier.

 

This problem is addressed by introducing a concept of

'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time.

 

(c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object.

 

Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances.

 

For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services.

 

The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified.

 

(d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection:

 

In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated.

 

 

--=__PartB495D542.0__=-- From disman-admin@ietf.org Fri Feb 13 11:11:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17042 for ; Fri, 13 Feb 2004 11:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfu9-0008Ss-Ar; Fri, 13 Feb 2004 11:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArftE-0008DV-Ri for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16972 for ; Fri, 13 Feb 2004 11:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArftC-00062D-00 for disman@ietf.org; Fri, 13 Feb 2004 11:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfsE-0005yB-00 for disman@ietf.org; Fri, 13 Feb 2004 11:09:04 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArfrK-0005qj-00 for disman@ietf.org; Fri, 13 Feb 2004 11:08:06 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 09:07:35 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartDEFFBF2C.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 09:07:24 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDEFFBF2C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified. (d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection: In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated. --=__PartDEFFBF2C.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All
 
At the moment a group of us are working on a draft-00-.
The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below.
 
Discussion:
 
Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects.
  
It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements.
 
Features:
 
(a) Goal: Simple configuration and Instance Management:
 
Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way.
 
  The OID of a columnar object variable consists of two parts: a columnar OID and an index.
 
Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter.
 
There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes.
 
 A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above.
 
(b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection.
 
Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always.
 
For example, consider the hrSWRunTable table in the Host resources
MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process
like notepad.exe.
 
If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized.
 
Strictly speaking, this problem should not arise if the indices of
tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the
case of the hrSWRunTable, the name of the software could serve as a good identifier.
 
This problem is addressed by introducing a concept of
'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time.
 
(c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object.
 
Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances.
 
For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services.
 
The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified.
 
(d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection:
 
In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated.
 

 
--=__PartDEFFBF2C.0__=-- From disman-admin@ietf.org Fri Feb 13 11:19:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17462 for ; Fri, 13 Feb 2004 11:19:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg1t-0000h1-0K; Fri, 13 Feb 2004 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg0v-0000bi-Pm for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17417 for ; Fri, 13 Feb 2004 11:17:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg0u-0006kY-00 for disman@ietf.org; Fri, 13 Feb 2004 11:18:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfzv-0006f1-00 for disman@ietf.org; Fri, 13 Feb 2004 11:17:02 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ArfzE-0006Yd-00 for disman@ietf.org; Fri, 13 Feb 2004 11:16:16 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGFDdZ015849 for ; Fri, 13 Feb 2004 11:15:13 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGFBdZ015760 for ; Fri, 13 Feb 2004 11:15:12 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F24C.ACBBD407" Subject: RE: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features Thread-Index: AcPySbQDuDQGwoeRQrqHraQ03+7uWAAAW9qA From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 18:16:02 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F24C.ACBBD407 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shailadja, =20 I did not see yet your draft-00, so it is difficult for me to make too = intelligent comments in the absence of the details. However, here are a = few preliminary thoughts, triggered by your mail. =20 1. There may be some prior work - for example, in the RMON WG, during = the work for the INTERFACETOPN-MIB (RFC 3144) we played with the idea of = a userTopN function, that looks quite close to the idea of sorting = instances of the columnar objects. The archives of the WG list may give = you some ideas of what was discussed then, and old I-Ds may contain some = MIB work discarded later - as we decided to focus the work on interface = counters specific parameters 2. psamp does a lot of work in defining packet filtering for monitoring = purposes 3. It is not clear what is the combination of threshold monitoring with = history collection. How would this be different from the Alarms and = Events mechanism in RFC 2819? 4. Why do you think this work would belong in disman?=20 =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 13 February, 2004 5:51 PM To: disman@ietf.org Cc: Hemanth Kumar; Raja Shekar; Hemanth Yamijala Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement = and proposal on advanced features Hi All, =20 At the moment a group of us are working on a draft-00-. =20 The work is about object definition for configuring and controlling the = periodic statistical sampling of user specified Data (ASN.1 INTEGER). As = you might be aware that usr history group of RMON2 (RFC2021) does = address this kind of requirement. Our proposed framework apart from = containing the mechanisms seen in the alarm and usr history groups of = RMON2 contains also the additional features and functionality. In order = to get the ideas and inputs from congenial minds on the features that we = are working, a brief description of features is being posted in this WG. =20 Please do share your comments, inputs, additional features etc. =20 Thanks, Shailaja. =20 =20 Discussion: =20 Suppose if the user needs to collect history for all the instances of a = columnar object say e.g., on the interface related statistics (ifTable = of MIB-II) like packets sent for all the interfaces by using the = usrHistory group object definition, the user is required to carry out = configuration for each instance separately. The usr History group does = not provide a single point of configuration for all the instances of the = columnar objects. =20 It has to be noted that there are some special requirements that arise = because of the above such condition. Following features address some = such special requirements. =20 Features: =20 (a) Goal: Simple configuration and Instance Management: =20 Objective: It must be possible to configure and control the history = collection for all the instances of the columnar object in a simple way. =20 The OID of a columnar object variable consists of two parts: a = columnar OID and an index. =20 Usually, the index part of the OID is defined by implementers of the MIB = or is dependent on the specific type of the parameter that is being = monitored. Hence it can have arbitrary values. Also, these indices can = vary from machine to machine. For example, the index of the ifTable is a = column called ifIndex. The value of this ifIndex is not pre-determined = and can be any arbitrary integer value. It is difficult for a user to = determine the complete OID for such parameter.=20 =20 There is another problem that arises vis-a-vis the history collection of = columnar variables. The numbers of instances for these parameters are = not fixed. This means that there could be new instances that are added = or existing ones removed, as per the dynamic behavior of the system = being monitored. For example, new interfaces added to the system could = result in new rows in the ifTable. Interfaces removed would result in = the deletion of existing rows. It becomes difficult if an user needs to = keep track of these additions and deletions and make sure that the = history collection configuration reflects these changes. =20 A simple resolution to these kind of requirement being providing the = capability to the user to define only the columnar part of the OID and = allow the implementing application to find all the instances of the = table automatically. At the same time, this would also allow the agent = to keep track of additions and deletions that occur as stated above. =20 (b) Consistent reference to the resource: It must be possible to track = changing instances and automatically adjust the history collection. =20 Normally, the index part of columnar variables maps to an instance of = the system resource being monitored. However, if the resource being = monitored changes, it could result in a change to the index part of the = columnar variables also. As it is again left to implementation what the = index part is, there is no guarantee that an index is mapped to the same = instance of the system resource always.=20 =20 For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called = hrSWRunIndex. The HTTP server process might initially be associated with = index 7219. However, if it is restarted, it could get the index 9029. = Also, it is likely that a row with index 7219 might actually represent a = new process=20 like notepad.exe.=20 =20 If some columnar variable related to the above table need statistical = sampling, it cannot rely just on the OID of that variable. It may result = in the data not being collected for the instance even if it is actually = available. Or worse, it may collect incorrect data assuming that the OID = still represents the same instance. It is also very difficult for an = user to keep these synchronized. =20 Strictly speaking, this problem should not arise if the indices of=20 tables are defined and implemented in such a way that their mapping to = the underlying resource is ensured to be always unique. However, it is = observed in practice that indices of tables are usually just integer = valued numbers. It is also observed that there would be other columns in = the table which identify the resources in a more permanent manner. For = example, in the=20 case of the hrSWRunTable, the name of the software could serve as a good = identifier. =20 This problem is addressed by introducing a concept of=20 'Identifier Object'. The Identifier Objects are one or more Columnar = Objects that will serve to uniquely identify one instance among several = ones of selected columnar objects. The MIB definition allows the user to = associate Identifier Objects to the columnar Object being sampled. By = doing so, it is now left to the monitoring application to make sure that = data is being collected for the right resource even if it changes with = time. =20 (c) Instance Filtering: It must be possible to selectively collect = history on certain instances of a columnar object. =20 Sometimes, the user may not be interested in all the instances of a = given table. In such a case, usr can specify the OIDs of the specific = instances of interest. However, as described in the above points, = specifying the complete OID will again have a problem if there is a = change to the index part of such instances.=20 =20 For example, consider again the hrSWRunTable in the Host resources MIB. = This would include all processes running on the system. However the user = might be interested in monitoring only certain important processes like = a HTTP server or other major services.=20 =20 The current draft allows the user to define filter criteria specifying = the instances to be monitored. The monitoring application can now ensure = that instances satisfying these criteria can be monitored. Combined with = the other points mentioned above, this would handle cases where = instances satisfying the criteria get added, removed or modified. =20 (d) Threshold Monitoring: Combining the aspect of threshold monitoring = with history collection: =20 In addition to the above considerations, the current object definition = also tries to combine the functionality of threshold-based monitoring = with the history collection functionality. It allows the user to define = thresholds on the data being monitored. Any violation of the threshold = would result in a trap being generated.=20 =20 =20 ------_=_NextPart_001_01C3F24C.ACBBD407 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Shailadja,
 
I did not see yet your draft-00, = so it is=20 difficult for me to make too intelligent comments in the absence of the = details.=20 However, here are a few preliminary thoughts, triggered by your=20 mail.
 
1. There may be some prior work - = for=20 example, in the RMON WG, during the work for the INTERFACETOPN-MIB (RFC = 3144) we=20 played with the idea of a userTopN function, that looks quite close to = the idea=20 of sorting instances of the columnar objects. The archives of the WG = list may=20 give you some ideas of what was discussed then, and old I-Ds may contain = some=20 MIB work discarded later - as we decided to focus the work on interface = counters=20 specific parameters
2. psamp does a lot of work in = defining=20 packet filtering for monitoring purposes
3. It is not clear what is the = combination=20 of threshold monitoring with history collection. How would this be = different=20 from the Alarms and Events mechanism in RFC 2819?
4. Why do you think this work = would belong=20 in disman?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 13 February, 2004 5:51 PM
To:=20 disman@ietf.org
Cc: Hemanth Kumar; Raja Shekar; Hemanth=20 Yamijala
Subject: [Disman] Statistical Sampling of Data- = Discussion=20 onrequirement and proposal on advanced features

Hi All,
 

At=20 the moment a group of us are working on a = draft-00-.

 

The=20 work is about object definition for configuring and controlling the = periodic=20 statistical sampling of user specified Data (ASN.1 INTEGER). As you = might be=20 aware that usr history group of RMON2 (RFC2021) does address this kind = of=20 requirement. Our proposed framework apart from containing the = mechanisms seen=20 in the alarm and usr history groups of RMON2 contains also the = additional=20 features and functionality. In order to get the ideas and inputs from=20 congenial minds on the features that we are working, a brief = description of=20 features is being posted in this WG.

 

Please=20 do share your comments, inputs, additional features = etc.

 

Thanks,

Shailaja.

 

 

Discussion:

 

Suppose=20 if the user needs to collect history for all the instances of a = columnar=20 object say e.g., on the interface related statistics (ifTable of = MIB-II) like=20 packets sent for all the interfaces by using the usrHistory group = object=20 definition, the user is required to carry out configuration for each = instance=20 separately. The usr History group does not provide a single point of=20 configuration for all the instances of the columnar=20 objects.

  

It=20 has to be noted that there are some special requirements that arise = because of=20 the above such condition. Following features address some such special = requirements.

 

Features:

 

(a)=20 Goal: Simple configuration and Instance = Management:

 

Objective:=20 It must be possible to configure and control the history collection = for all=20 the instances of the columnar object in a simple = way.

 

  The OID of a columnar object = variable=20 consists of two parts: a columnar OID and an = index.

 

Usually,=20 the index part of the OID is defined by implementers of the MIB or is=20 dependent on the specific type of the parameter that is being = monitored. Hence=20 it can have arbitrary values. Also, these indices can vary from = machine to=20 machine. For example, the index of the ifTable is a column called = ifIndex. The=20 value of this ifIndex is not pre-determined and can be any arbitrary = integer=20 value. It is difficult for a user to determine the complete OID for = such=20 parameter.

 

There=20 is another problem that arises vis-a-vis the history collection of = columnar=20 variables. The numbers of instances for these parameters are not = fixed. This=20 means that there could be new instances that are added or existing = ones=20 removed, as per the dynamic behavior of the system being monitored. = For=20 example, new interfaces added to the system could result in new rows = in the=20 ifTable. Interfaces removed would result in the deletion of existing = rows. It=20 becomes difficult if an user needs to keep track of these additions = and=20 deletions and make sure that the history collection configuration = reflects=20 these changes.

 

 A simple resolution to these = kind of=20 requirement being providing the capability to the user to define only = the=20 columnar part of the OID and allow the implementing application to = find all=20 the instances of the table automatically. At the same time, this would = also=20 allow the agent to keep track of additions and deletions that occur as = stated=20 above.

 

(b)=20 Consistent reference to the resource: It must be possible to track = changing=20 instances and automatically adjust the history=20 collection.

 

Normally,=20 the index part of columnar variables maps to an instance of the system = resource being monitored. However, if the resource being monitored = changes, it=20 could result in a change to the index part of the columnar variables = also. As=20 it is again left to implementation what the index part is, there is no = guarantee that an index is mapped to the same instance of the system = resource=20 always.

 

For=20 example, consider the hrSWRunTable table in the Host=20 resources

MIB.=20 The index of this table is again an integer valued variable called=20 hrSWRunIndex. The HTTP server process might initially be associated = with index=20 7219. However, if it is restarted, it could get the index 9029. Also, = it is=20 likely that a row with index 7219 might actually represent a new = process=20

like=20 notepad.exe.

 

If=20 some columnar variable related to the above table need statistical = sampling,=20 it cannot rely just on the OID of that variable. It may result in the = data not=20 being collected for the instance even if it is actually available. Or = worse,=20 it may collect incorrect data assuming that the OID still represents = the same=20 instance. It is also very difficult for an user to keep these=20 synchronized.

 

Strictly=20 speaking, this problem should not arise if the indices of=20

tables=20 are defined and implemented in such a way that their mapping to the = underlying=20 resource is ensured to be always unique. However, it is observed in = practice=20 that indices of tables are usually just integer valued numbers. It is = also=20 observed that there would be other columns in the table which identify = the=20 resources in a more permanent manner. For example, in the=20

case=20 of the hrSWRunTable, the name of the software could serve as a good=20 identifier.

 

This=20 problem is addressed by introducing a concept of =

'Identifier=20 Object'. The Identifier Objects are one or more Columnar Objects that = will=20 serve to uniquely identify one instance among several ones of selected = columnar objects. The MIB definition allows the user to associate = Identifier=20 Objects to the columnar Object being sampled. By doing so, it is now = left to=20 the monitoring application to make sure that data is being collected = for the=20 right resource even if it changes with time.

 

(c)=20 Instance Filtering: It must be possible to selectively collect history = on=20 certain instances of a columnar object.

 

Sometimes,=20 the user may not be interested in all the instances of a given table. = In such=20 a case, usr can specify the OIDs of the specific instances of = interest.=20 However, as described in the above points, specifying the complete OID = will=20 again have a problem if there is a change to the index part of such = instances.=20

 

For=20 example, consider again the hrSWRunTable in the Host resources MIB. = This would=20 include all processes running on the system. However the user might be = interested in monitoring only certain important processes like a HTTP = server=20 or other major services.

 

The=20 current draft allows the user to define filter criteria specifying the = instances to be monitored. The monitoring application can now ensure = that=20 instances satisfying these criteria can be monitored. Combined with = the other=20 points mentioned above, this would handle cases where instances = satisfying the=20 criteria get added, removed or modified.

 

(d)=20 Threshold Monitoring: Combining the aspect of threshold monitoring = with=20 history collection:

 

In=20 addition to the above considerations, the current object definition = also tries=20 to combine the functionality of threshold-based monitoring with the = history=20 collection functionality. It allows the user to define thresholds on = the data=20 being monitored. Any violation of the threshold would result in a trap = being=20 generated.

 

 

------_=_NextPart_001_01C3F24C.ACBBD407-- From exim@www1.ietf.org Fri Feb 13 11:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17577 for ; Fri, 13 Feb 2004 11:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg3q-0000xT-Fg for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 11:21:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGL2wH003677 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 11:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg3q-0000xE-7e for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:21:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17543 for ; Fri, 13 Feb 2004 11:20:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg3o-000706-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:21:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arg2t-0006v5-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:20:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arg1t-0006px-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg1t-0000h1-0K; Fri, 13 Feb 2004 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arg0v-0000bi-Pm for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17417 for ; Fri, 13 Feb 2004 11:17:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arg0u-0006kY-00 for disman@ietf.org; Fri, 13 Feb 2004 11:18:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfzv-0006f1-00 for disman@ietf.org; Fri, 13 Feb 2004 11:17:02 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ArfzE-0006Yd-00 for disman@ietf.org; Fri, 13 Feb 2004 11:16:16 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGFDdZ015849 for ; Fri, 13 Feb 2004 11:15:13 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1DGFBdZ015760 for ; Fri, 13 Feb 2004 11:15:12 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F24C.ACBBD407" Subject: RE: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features Thread-Index: AcPySbQDuDQGwoeRQrqHraQ03+7uWAAAW9qA From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 18:16:02 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F24C.ACBBD407 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shailadja, =20 I did not see yet your draft-00, so it is difficult for me to make too = intelligent comments in the absence of the details. However, here are a = few preliminary thoughts, triggered by your mail. =20 1. There may be some prior work - for example, in the RMON WG, during = the work for the INTERFACETOPN-MIB (RFC 3144) we played with the idea of = a userTopN function, that looks quite close to the idea of sorting = instances of the columnar objects. The archives of the WG list may give = you some ideas of what was discussed then, and old I-Ds may contain some = MIB work discarded later - as we decided to focus the work on interface = counters specific parameters 2. psamp does a lot of work in defining packet filtering for monitoring = purposes 3. It is not clear what is the combination of threshold monitoring with = history collection. How would this be different from the Alarms and = Events mechanism in RFC 2819? 4. Why do you think this work would belong in disman?=20 =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 13 February, 2004 5:51 PM To: disman@ietf.org Cc: Hemanth Kumar; Raja Shekar; Hemanth Yamijala Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement = and proposal on advanced features Hi All, =20 At the moment a group of us are working on a draft-00-. =20 The work is about object definition for configuring and controlling the = periodic statistical sampling of user specified Data (ASN.1 INTEGER). As = you might be aware that usr history group of RMON2 (RFC2021) does = address this kind of requirement. Our proposed framework apart from = containing the mechanisms seen in the alarm and usr history groups of = RMON2 contains also the additional features and functionality. In order = to get the ideas and inputs from congenial minds on the features that we = are working, a brief description of features is being posted in this WG. =20 Please do share your comments, inputs, additional features etc. =20 Thanks, Shailaja. =20 =20 Discussion: =20 Suppose if the user needs to collect history for all the instances of a = columnar object say e.g., on the interface related statistics (ifTable = of MIB-II) like packets sent for all the interfaces by using the = usrHistory group object definition, the user is required to carry out = configuration for each instance separately. The usr History group does = not provide a single point of configuration for all the instances of the = columnar objects. =20 It has to be noted that there are some special requirements that arise = because of the above such condition. Following features address some = such special requirements. =20 Features: =20 (a) Goal: Simple configuration and Instance Management: =20 Objective: It must be possible to configure and control the history = collection for all the instances of the columnar object in a simple way. =20 The OID of a columnar object variable consists of two parts: a = columnar OID and an index. =20 Usually, the index part of the OID is defined by implementers of the MIB = or is dependent on the specific type of the parameter that is being = monitored. Hence it can have arbitrary values. Also, these indices can = vary from machine to machine. For example, the index of the ifTable is a = column called ifIndex. The value of this ifIndex is not pre-determined = and can be any arbitrary integer value. It is difficult for a user to = determine the complete OID for such parameter.=20 =20 There is another problem that arises vis-a-vis the history collection of = columnar variables. The numbers of instances for these parameters are = not fixed. This means that there could be new instances that are added = or existing ones removed, as per the dynamic behavior of the system = being monitored. For example, new interfaces added to the system could = result in new rows in the ifTable. Interfaces removed would result in = the deletion of existing rows. It becomes difficult if an user needs to = keep track of these additions and deletions and make sure that the = history collection configuration reflects these changes. =20 A simple resolution to these kind of requirement being providing the = capability to the user to define only the columnar part of the OID and = allow the implementing application to find all the instances of the = table automatically. At the same time, this would also allow the agent = to keep track of additions and deletions that occur as stated above. =20 (b) Consistent reference to the resource: It must be possible to track = changing instances and automatically adjust the history collection. =20 Normally, the index part of columnar variables maps to an instance of = the system resource being monitored. However, if the resource being = monitored changes, it could result in a change to the index part of the = columnar variables also. As it is again left to implementation what the = index part is, there is no guarantee that an index is mapped to the same = instance of the system resource always.=20 =20 For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called = hrSWRunIndex. The HTTP server process might initially be associated with = index 7219. However, if it is restarted, it could get the index 9029. = Also, it is likely that a row with index 7219 might actually represent a = new process=20 like notepad.exe.=20 =20 If some columnar variable related to the above table need statistical = sampling, it cannot rely just on the OID of that variable. It may result = in the data not being collected for the instance even if it is actually = available. Or worse, it may collect incorrect data assuming that the OID = still represents the same instance. It is also very difficult for an = user to keep these synchronized. =20 Strictly speaking, this problem should not arise if the indices of=20 tables are defined and implemented in such a way that their mapping to = the underlying resource is ensured to be always unique. However, it is = observed in practice that indices of tables are usually just integer = valued numbers. It is also observed that there would be other columns in = the table which identify the resources in a more permanent manner. For = example, in the=20 case of the hrSWRunTable, the name of the software could serve as a good = identifier. =20 This problem is addressed by introducing a concept of=20 'Identifier Object'. The Identifier Objects are one or more Columnar = Objects that will serve to uniquely identify one instance among several = ones of selected columnar objects. The MIB definition allows the user to = associate Identifier Objects to the columnar Object being sampled. By = doing so, it is now left to the monitoring application to make sure that = data is being collected for the right resource even if it changes with = time. =20 (c) Instance Filtering: It must be possible to selectively collect = history on certain instances of a columnar object. =20 Sometimes, the user may not be interested in all the instances of a = given table. In such a case, usr can specify the OIDs of the specific = instances of interest. However, as described in the above points, = specifying the complete OID will again have a problem if there is a = change to the index part of such instances.=20 =20 For example, consider again the hrSWRunTable in the Host resources MIB. = This would include all processes running on the system. However the user = might be interested in monitoring only certain important processes like = a HTTP server or other major services.=20 =20 The current draft allows the user to define filter criteria specifying = the instances to be monitored. The monitoring application can now ensure = that instances satisfying these criteria can be monitored. Combined with = the other points mentioned above, this would handle cases where = instances satisfying the criteria get added, removed or modified. =20 (d) Threshold Monitoring: Combining the aspect of threshold monitoring = with history collection: =20 In addition to the above considerations, the current object definition = also tries to combine the functionality of threshold-based monitoring = with the history collection functionality. It allows the user to define = thresholds on the data being monitored. Any violation of the threshold = would result in a trap being generated.=20 =20 =20 ------_=_NextPart_001_01C3F24C.ACBBD407 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Shailadja,
 
I did not see yet your draft-00, = so it is=20 difficult for me to make too intelligent comments in the absence of the = details.=20 However, here are a few preliminary thoughts, triggered by your=20 mail.
 
1. There may be some prior work - = for=20 example, in the RMON WG, during the work for the INTERFACETOPN-MIB (RFC = 3144) we=20 played with the idea of a userTopN function, that looks quite close to = the idea=20 of sorting instances of the columnar objects. The archives of the WG = list may=20 give you some ideas of what was discussed then, and old I-Ds may contain = some=20 MIB work discarded later - as we decided to focus the work on interface = counters=20 specific parameters
2. psamp does a lot of work in = defining=20 packet filtering for monitoring purposes
3. It is not clear what is the = combination=20 of threshold monitoring with history collection. How would this be = different=20 from the Alarms and Events mechanism in RFC 2819?
4. Why do you think this work = would belong=20 in disman?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 13 February, 2004 5:51 PM
To:=20 disman@ietf.org
Cc: Hemanth Kumar; Raja Shekar; Hemanth=20 Yamijala
Subject: [Disman] Statistical Sampling of Data- = Discussion=20 onrequirement and proposal on advanced features

Hi All,
 

At=20 the moment a group of us are working on a = draft-00-.

 

The=20 work is about object definition for configuring and controlling the = periodic=20 statistical sampling of user specified Data (ASN.1 INTEGER). As you = might be=20 aware that usr history group of RMON2 (RFC2021) does address this kind = of=20 requirement. Our proposed framework apart from containing the = mechanisms seen=20 in the alarm and usr history groups of RMON2 contains also the = additional=20 features and functionality. In order to get the ideas and inputs from=20 congenial minds on the features that we are working, a brief = description of=20 features is being posted in this WG.

 

Please=20 do share your comments, inputs, additional features = etc.

 

Thanks,

Shailaja.

 

 

Discussion:

 

Suppose=20 if the user needs to collect history for all the instances of a = columnar=20 object say e.g., on the interface related statistics (ifTable of = MIB-II) like=20 packets sent for all the interfaces by using the usrHistory group = object=20 definition, the user is required to carry out configuration for each = instance=20 separately. The usr History group does not provide a single point of=20 configuration for all the instances of the columnar=20 objects.

  

It=20 has to be noted that there are some special requirements that arise = because of=20 the above such condition. Following features address some such special = requirements.

 

Features:

 

(a)=20 Goal: Simple configuration and Instance = Management:

 

Objective:=20 It must be possible to configure and control the history collection = for all=20 the instances of the columnar object in a simple = way.

 

  The OID of a columnar object = variable=20 consists of two parts: a columnar OID and an = index.

 

Usually,=20 the index part of the OID is defined by implementers of the MIB or is=20 dependent on the specific type of the parameter that is being = monitored. Hence=20 it can have arbitrary values. Also, these indices can vary from = machine to=20 machine. For example, the index of the ifTable is a column called = ifIndex. The=20 value of this ifIndex is not pre-determined and can be any arbitrary = integer=20 value. It is difficult for a user to determine the complete OID for = such=20 parameter.

 

There=20 is another problem that arises vis-a-vis the history collection of = columnar=20 variables. The numbers of instances for these parameters are not = fixed. This=20 means that there could be new instances that are added or existing = ones=20 removed, as per the dynamic behavior of the system being monitored. = For=20 example, new interfaces added to the system could result in new rows = in the=20 ifTable. Interfaces removed would result in the deletion of existing = rows. It=20 becomes difficult if an user needs to keep track of these additions = and=20 deletions and make sure that the history collection configuration = reflects=20 these changes.

 

 A simple resolution to these = kind of=20 requirement being providing the capability to the user to define only = the=20 columnar part of the OID and allow the implementing application to = find all=20 the instances of the table automatically. At the same time, this would = also=20 allow the agent to keep track of additions and deletions that occur as = stated=20 above.

 

(b)=20 Consistent reference to the resource: It must be possible to track = changing=20 instances and automatically adjust the history=20 collection.

 

Normally,=20 the index part of columnar variables maps to an instance of the system = resource being monitored. However, if the resource being monitored = changes, it=20 could result in a change to the index part of the columnar variables = also. As=20 it is again left to implementation what the index part is, there is no = guarantee that an index is mapped to the same instance of the system = resource=20 always.

 

For=20 example, consider the hrSWRunTable table in the Host=20 resources

MIB.=20 The index of this table is again an integer valued variable called=20 hrSWRunIndex. The HTTP server process might initially be associated = with index=20 7219. However, if it is restarted, it could get the index 9029. Also, = it is=20 likely that a row with index 7219 might actually represent a new = process=20

like=20 notepad.exe.

 

If=20 some columnar variable related to the above table need statistical = sampling,=20 it cannot rely just on the OID of that variable. It may result in the = data not=20 being collected for the instance even if it is actually available. Or = worse,=20 it may collect incorrect data assuming that the OID still represents = the same=20 instance. It is also very difficult for an user to keep these=20 synchronized.

 

Strictly=20 speaking, this problem should not arise if the indices of=20

tables=20 are defined and implemented in such a way that their mapping to the = underlying=20 resource is ensured to be always unique. However, it is observed in = practice=20 that indices of tables are usually just integer valued numbers. It is = also=20 observed that there would be other columns in the table which identify = the=20 resources in a more permanent manner. For example, in the=20

case=20 of the hrSWRunTable, the name of the software could serve as a good=20 identifier.

 

This=20 problem is addressed by introducing a concept of =

'Identifier=20 Object'. The Identifier Objects are one or more Columnar Objects that = will=20 serve to uniquely identify one instance among several ones of selected = columnar objects. The MIB definition allows the user to associate = Identifier=20 Objects to the columnar Object being sampled. By doing so, it is now = left to=20 the monitoring application to make sure that data is being collected = for the=20 right resource even if it changes with time.

 

(c)=20 Instance Filtering: It must be possible to selectively collect history = on=20 certain instances of a columnar object.

 

Sometimes,=20 the user may not be interested in all the instances of a given table. = In such=20 a case, usr can specify the OIDs of the specific instances of = interest.=20 However, as described in the above points, specifying the complete OID = will=20 again have a problem if there is a change to the index part of such = instances.=20

 

For=20 example, consider again the hrSWRunTable in the Host resources MIB. = This would=20 include all processes running on the system. However the user might be = interested in monitoring only certain important processes like a HTTP = server=20 or other major services.

 

The=20 current draft allows the user to define filter criteria specifying the = instances to be monitored. The monitoring application can now ensure = that=20 instances satisfying these criteria can be monitored. Combined with = the other=20 points mentioned above, this would handle cases where instances = satisfying the=20 criteria get added, removed or modified.

 

(d)=20 Threshold Monitoring: Combining the aspect of threshold monitoring = with=20 history collection:

 

In=20 addition to the above considerations, the current object definition = also tries=20 to combine the functionality of threshold-based monitoring with the = history=20 collection functionality. It allows the user to define thresholds on = the data=20 being monitored. Any violation of the threshold would result in a trap = being=20 generated.

 

 

------_=_NextPart_001_01C3F24C.ACBBD407-- From disman-admin@ietf.org Fri Feb 13 11:44:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18850 for ; Fri, 13 Feb 2004 11:44:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgQ4-0002sl-Jp; Fri, 13 Feb 2004 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgP9-0002oH-SM for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18736 for ; Fri, 13 Feb 2004 11:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgP8-0001Y9-00 for disman@ietf.org; Fri, 13 Feb 2004 11:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgNQ-0001BL-00 for disman@ietf.org; Fri, 13 Feb 2004 11:41:19 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArgL6-0000gO-00 for disman@ietf.org; Fri, 13 Feb 2004 11:38:52 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 09:38:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: RE: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced featur Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part86A7E77F.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 09:38:07 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part86A7E77F.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, Thanks for your response. >I did not see yet your draft-00, so it is difficult for me to make too intelligent comments in the absence of >the details. However, here are a few preliminary thoughts, triggered by your mail. Not yet be submitted, will be submitting it soon. >1. There may be some prior work - for example, in the RMON WG, during the work for the >INTERFACETOPN-MIB (RFC 3144) we played with the idea of a userTopN function, that looks quite close >to the idea of sorting instances of the columnar objects. The archives of the WG list may give you some >ideas of what was discussed then, and old I-Ds may contain some MIB work discarded later - as we >decided to focus the work on interface counters specific parameters Ok. I will go over the archives of WG. >2. psamp does a lot of work in defining packet filtering for monitoring purposes - >3. It is not clear what is the combination of threshold monitoring with history collection. How would this >be different from the Alarms and Events mechanism in RFC 2819? Yes, monitoring and thresholding is not a new concept. I agree. >4. Why do you think this work would belong in disman? - This is the basic trigger lead to work on the draft was, today if the user wants to monitor behavior of any mib attribute there is no single mib definition which comprises of history collection, alarm generation, filtering. About posting the proposed features list in this WG, I did had doubt about the WG, either disman or rmon, people in this WG suggested me to post the draft and based on the content of the draft WG people would decide which would be the best WG. Thanks, Shailaja. --=__Part86A7E77F.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Dan,
 
Thanks for your response.
 
>I did not see yet your draft-00, so it is difficult for me to make too intelligent comments in the absence of >the details. However, here are a few preliminary thoughts, triggered by your mail.
 
Not yet be submitted, will be submitting it soon.
 
>1. There may be some prior work - for example, in the RMON WG, during the work for the >INTERFACETOPN-MIB (RFC 3144) we played with the idea of a userTopN function, that looks quite close >to the idea of sorting instances of the columnar objects. The archives of the WG list may give you some >ideas of what was discussed then, and old I-Ds may contain some MIB work discarded later - as we >decided to focus the work on interface counters specific parameters
 
Ok. I will go over the archives of WG.
 
>2. psamp does a lot of work in defining packet filtering for monitoring purposes
 
-
 
>3. It is not clear what is the combination of threshold monitoring with history collection. How would this >be different from the Alarms and Events mechanism in RFC 2819?
 
Yes, monitoring and thresholding is not a new concept. I agree.
 
>4. Why do you think this work would belong in disman?
 
-
This is the basic trigger lead to work on the draft was, today if the user wants to monitor behavior of any mib attribute there is no single mib definition which comprises of history collection, alarm generation, filtering. 
 
About posting the proposed features list in this WG, I did had doubt about the WG, either disman or rmon, people in this WG suggested me to post the draft and based on the content of the draft WG people would decide which would be the best WG.
 
Thanks,
Shailaja.
 
 
--=__Part86A7E77F.1__=-- From exim@www1.ietf.org Fri Feb 13 11:48:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19454 for ; Fri, 13 Feb 2004 11:48:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTV-0003UC-14 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 11:47:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGlW12013394 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 11:47:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgTU-0003Tx-TL for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:47:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19392 for ; Fri, 13 Feb 2004 11:47:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgTT-0002WU-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:47:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgSI-0002Gh-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:46:20 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArgQF-0001nw-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:44:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArgQE-00046W-UQ for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgQ4-0002sl-Jp; Fri, 13 Feb 2004 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArgP9-0002oH-SM for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18736 for ; Fri, 13 Feb 2004 11:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArgP8-0001Y9-00 for disman@ietf.org; Fri, 13 Feb 2004 11:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArgNQ-0001BL-00 for disman@ietf.org; Fri, 13 Feb 2004 11:41:19 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArgL6-0000gO-00 for disman@ietf.org; Fri, 13 Feb 2004 11:38:52 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 09:38:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: RE: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced featur Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part86A7E77F.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 09:38:07 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part86A7E77F.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, Thanks for your response. >I did not see yet your draft-00, so it is difficult for me to make too intelligent comments in the absence of >the details. However, here are a few preliminary thoughts, triggered by your mail. Not yet be submitted, will be submitting it soon. >1. There may be some prior work - for example, in the RMON WG, during the work for the >INTERFACETOPN-MIB (RFC 3144) we played with the idea of a userTopN function, that looks quite close >to the idea of sorting instances of the columnar objects. The archives of the WG list may give you some >ideas of what was discussed then, and old I-Ds may contain some MIB work discarded later - as we >decided to focus the work on interface counters specific parameters Ok. I will go over the archives of WG. >2. psamp does a lot of work in defining packet filtering for monitoring purposes - >3. It is not clear what is the combination of threshold monitoring with history collection. How would this >be different from the Alarms and Events mechanism in RFC 2819? Yes, monitoring and thresholding is not a new concept. I agree. >4. Why do you think this work would belong in disman? - This is the basic trigger lead to work on the draft was, today if the user wants to monitor behavior of any mib attribute there is no single mib definition which comprises of history collection, alarm generation, filtering. About posting the proposed features list in this WG, I did had doubt about the WG, either disman or rmon, people in this WG suggested me to post the draft and based on the content of the draft WG people would decide which would be the best WG. Thanks, Shailaja. --=__Part86A7E77F.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Dan,
 
Thanks for your response.
 
>I did not see yet your draft-00, so it is difficult for me to make too intelligent comments in the absence of >the details. However, here are a few preliminary thoughts, triggered by your mail.
 
Not yet be submitted, will be submitting it soon.
 
>1. There may be some prior work - for example, in the RMON WG, during the work for the >INTERFACETOPN-MIB (RFC 3144) we played with the idea of a userTopN function, that looks quite close >to the idea of sorting instances of the columnar objects. The archives of the WG list may give you some >ideas of what was discussed then, and old I-Ds may contain some MIB work discarded later - as we >decided to focus the work on interface counters specific parameters
 
Ok. I will go over the archives of WG.
 
>2. psamp does a lot of work in defining packet filtering for monitoring purposes
 
-
 
>3. It is not clear what is the combination of threshold monitoring with history collection. How would this >be different from the Alarms and Events mechanism in RFC 2819?
 
Yes, monitoring and thresholding is not a new concept. I agree.
 
>4. Why do you think this work would belong in disman?
 
-
This is the basic trigger lead to work on the draft was, today if the user wants to monitor behavior of any mib attribute there is no single mib definition which comprises of history collection, alarm generation, filtering. 
 
About posting the proposed features list in this WG, I did had doubt about the WG, either disman or rmon, people in this WG suggested me to post the draft and based on the content of the draft WG people would decide which would be the best WG.
 
Thanks,
Shailaja.
 
 
--=__Part86A7E77F.1__=-- From disman-admin@ietf.org Fri Feb 13 12:37:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22100 for ; Fri, 13 Feb 2004 12:37:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhFO-0007ym-Fm; Fri, 13 Feb 2004 12:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh6v-0007Di-Fj for disman@optimus.ietf.org; Fri, 13 Feb 2004 12:28:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21541 for ; Fri, 13 Feb 2004 12:28:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh6t-0006MN-00 for disman@ietf.org; Fri, 13 Feb 2004 12:28:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh64-0006Gq-00 for disman@ietf.org; Fri, 13 Feb 2004 12:27:25 -0500 Received: from revab.best.vwh.net ([192.220.64.133]) by ietf-mx with smtp (Exim 4.12) id 1Arh5Q-0006B1-00 for disman@ietf.org; Fri, 13 Feb 2004 12:26:44 -0500 Received: (qmail 67141 invoked by uid 16517); 13 Feb 2004 17:26:39 -0000 Message-ID: <20040213172639.67140.qmail@revab.best.vwh.net> Mime-Version: 1.0 X-Mailer: Webmail From: "" To: yshailaja@novell.com, disman@ietf.org Cc: HeKumar@novell.com, RShekar@novell.com, YHemanth@novell.com Subject: RE: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Feb 2004 09:26:39 PST Content-Transfer-Encoding: 7bit Before you go too far with this work you should find out the status of the patent that Hewlett-Packard had (it may now be held by Agilent) for statistical sampling of network data. The RMON WG decided some years ago not to support a statistical sampling MIB because HP would not release their patent rights at that time. Reva Bailey revab@best.com ------- Original Message ------- On Fri, 13 Feb 2004 09:07:24 -0700 Shailaja Yadawad?wrote: Hi All At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where From exim@www1.ietf.org Fri Feb 13 12:39:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22293 for ; Fri, 13 Feb 2004 12:39:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhHQ-0008Vw-3U for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 12:39:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DHd8Ee032722 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 12:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhHP-0008Vh-Vg for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 12:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22222 for ; Fri, 13 Feb 2004 12:39:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhHO-0007O4-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 12:39:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhGR-0007IK-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 12:38:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArhFV-0007Cn-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 12:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhFO-0007ym-Fm; Fri, 13 Feb 2004 12:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arh6v-0007Di-Fj for disman@optimus.ietf.org; Fri, 13 Feb 2004 12:28:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21541 for ; Fri, 13 Feb 2004 12:28:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arh6t-0006MN-00 for disman@ietf.org; Fri, 13 Feb 2004 12:28:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arh64-0006Gq-00 for disman@ietf.org; Fri, 13 Feb 2004 12:27:25 -0500 Received: from revab.best.vwh.net ([192.220.64.133]) by ietf-mx with smtp (Exim 4.12) id 1Arh5Q-0006B1-00 for disman@ietf.org; Fri, 13 Feb 2004 12:26:44 -0500 Received: (qmail 67141 invoked by uid 16517); 13 Feb 2004 17:26:39 -0000 Message-ID: <20040213172639.67140.qmail@revab.best.vwh.net> Mime-Version: 1.0 X-Mailer: Webmail From: "" To: yshailaja@novell.com, disman@ietf.org Cc: HeKumar@novell.com, RShekar@novell.com, YHemanth@novell.com Subject: RE: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: 13 Feb 2004 09:26:39 PST X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Before you go too far with this work you should find out the status of the patent that Hewlett-Packard had (it may now be held by Agilent) for statistical sampling of network data. The RMON WG decided some years ago not to support a statistical sampling MIB because HP would not release their patent rights at that time. Reva Bailey revab@best.com ------- Original Message ------- On Fri, 13 Feb 2004 09:07:24 -0700 Shailaja Yadawad?wrote: Hi All At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where From disman-admin@ietf.org Fri Feb 13 13:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23650 for ; Fri, 13 Feb 2004 13:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arht3-0003Dt-7u; Fri, 13 Feb 2004 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhsE-0003CU-Bx for disman@optimus.ietf.org; Fri, 13 Feb 2004 13:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23636 for ; Fri, 13 Feb 2004 13:17:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhsC-00030M-00 for disman@ietf.org; Fri, 13 Feb 2004 13:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhrE-0002x4-00 for disman@ietf.org; Fri, 13 Feb 2004 13:16:09 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1Arhqy-0002tZ-00 for disman@ietf.org; Fri, 13 Feb 2004 13:15:52 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Arhrn-0002Se-00 for disman@ietf.org; Fri, 13 Feb 2004 10:16:44 -0800 Message-ID: <003101c3f25d$95127140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20040213172639.67140.qmail@revab.best.vwh.net> Subject: Re: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 10:16:31 -0800 Hi - > From: > To: ; > Cc: ; ; > Sent: Friday, February 13, 2004 9:26 AM > Subject: RE: [Disman] Statistical Sampling of Data- Discussion on requirement and > proposal on advanced features > > Before you go too far with this work you should find out the status of the > patent that Hewlett-Packard had (it may now be held by Agilent) for > statistical sampling of network data. The RMON WG decided some years > ago not to support a statistical sampling MIB because HP would not release > their patent rights at that time. All participants are strongly urged to check out the clarification of RFC 2026 in http://www.ietf.org/internet-drafts/draft-ietf-ipr-technology-rights-12.txt especially clauses 1 (n) and 6 with subclauses. If HP (or anyone else) is claiming IPR with respect to this proposed work (we haven't even seen a -00- draft yet!) please let the WG know what it is and whether there is an applicable statement at http://www.ietf.org/ipr.html In any case, the existence of IPR claims does not of itself preclude a WG from pursuing a work item. See http://www.ietf.org/internet-drafts/draft-ietf-ipr-wg-guidelines-05.txt for details of the current thinking. One of the things it encourages is early discussion of potential IPR issues like this. > Reva Bailey > revab@best.com ... Randy, as disman chair From exim@www1.ietf.org Fri Feb 13 13:20:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23734 for ; Fri, 13 Feb 2004 13:20:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhv4-0003Kg-7e for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 13:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIK6kP012804 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 13:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arhv3-0003KR-Rb for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 13:20:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23698 for ; Fri, 13 Feb 2004 13:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arhv1-0003Bu-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 13:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arhu3-00037t-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 13:19:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arht4-00033D-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 13:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arht3-0003Dt-7u; Fri, 13 Feb 2004 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArhsE-0003CU-Bx for disman@optimus.ietf.org; Fri, 13 Feb 2004 13:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23636 for ; Fri, 13 Feb 2004 13:17:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArhsC-00030M-00 for disman@ietf.org; Fri, 13 Feb 2004 13:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArhrE-0002x4-00 for disman@ietf.org; Fri, 13 Feb 2004 13:16:09 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1Arhqy-0002tZ-00 for disman@ietf.org; Fri, 13 Feb 2004 13:15:52 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Arhrn-0002Se-00 for disman@ietf.org; Fri, 13 Feb 2004 10:16:44 -0800 Message-ID: <003101c3f25d$95127140$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20040213172639.67140.qmail@revab.best.vwh.net> Subject: Re: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 10:16:31 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - > From: > To: ; > Cc: ; ; > Sent: Friday, February 13, 2004 9:26 AM > Subject: RE: [Disman] Statistical Sampling of Data- Discussion on requirement and > proposal on advanced features > > Before you go too far with this work you should find out the status of the > patent that Hewlett-Packard had (it may now be held by Agilent) for > statistical sampling of network data. The RMON WG decided some years > ago not to support a statistical sampling MIB because HP would not release > their patent rights at that time. All participants are strongly urged to check out the clarification of RFC 2026 in http://www.ietf.org/internet-drafts/draft-ietf-ipr-technology-rights-12.txt especially clauses 1 (n) and 6 with subclauses. If HP (or anyone else) is claiming IPR with respect to this proposed work (we haven't even seen a -00- draft yet!) please let the WG know what it is and whether there is an applicable statement at http://www.ietf.org/ipr.html In any case, the existence of IPR claims does not of itself preclude a WG from pursuing a work item. See http://www.ietf.org/internet-drafts/draft-ietf-ipr-wg-guidelines-05.txt for details of the current thinking. One of the things it encourages is early discussion of potential IPR issues like this. > Reva Bailey > revab@best.com ... Randy, as disman chair From disman-admin@ietf.org Fri Feb 13 17:24:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11371 for ; Fri, 13 Feb 2004 17:24:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arlj7-0002pW-5B; Fri, 13 Feb 2004 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArliS-0002mf-Vg for disman@optimus.ietf.org; Fri, 13 Feb 2004 17:23:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11309 for ; Fri, 13 Feb 2004 17:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArliQ-0003tV-00 for disman@ietf.org; Fri, 13 Feb 2004 17:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arlhf-0003ph-00 for disman@ietf.org; Fri, 13 Feb 2004 17:22:32 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArlhJ-0003kt-00 for disman@ietf.org; Fri, 13 Feb 2004 17:22:09 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArlhI-0001Lg-00 for disman@ietf.org; Fri, 13 Feb 2004 14:22:08 -0800 Message-ID: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Disman session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 14:23:22 -0800 Hi - There has been some recent discussion about possible new work in the disman working group. There is also the question of advancing some of the specifications that have come from this working group. In order to help reach some kind of closure, I've requested a one-hour slot for disman in Seoul. Disman's session is *currently* scheduled on Tuesday, March second in the 17:00-18:00 time slot. Since the agenda has not yet been finalized, this date/time may change, so watch for the final agenda. I'd like to get a good sense of whether there is sufficient interest and need to continue work as a working group. If there is, I'd like to know which items enjoy adequate support. At our last face-to-face meeting, there seemed to be some interest in advancing some of our documents to Draft Standard, but follow-through has been uneven. Of course, I *strongly* encourage folks to get those discussions underway on this mailing list, so we can use our meeting time productively and provide our AD with the information he needs to make a decision on how to proceed. Please post to this mailing list any other pertinent topics you would like to discuss, so I can submit an agenda in time for the Tuesday, February 24th deadline. Lack of discussion will be interpreted as disinterest, and I do not want to waste resources on uninteresting work. Randy From exim@www1.ietf.org Fri Feb 13 17:25:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11411 for ; Fri, 13 Feb 2004 17:25:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlkK-0002zN-TY for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 17:25:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DMPGXv011485 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 17:25:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlkK-0002zA-IH for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 17:25:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11401 for ; Fri, 13 Feb 2004 17:25:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlkI-00040h-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 17:25:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArljO-0003xf-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 17:24:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arlj6-0003u9-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 17:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arlj7-0002pW-5B; Fri, 13 Feb 2004 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArliS-0002mf-Vg for disman@optimus.ietf.org; Fri, 13 Feb 2004 17:23:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11309 for ; Fri, 13 Feb 2004 17:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArliQ-0003tV-00 for disman@ietf.org; Fri, 13 Feb 2004 17:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arlhf-0003ph-00 for disman@ietf.org; Fri, 13 Feb 2004 17:22:32 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArlhJ-0003kt-00 for disman@ietf.org; Fri, 13 Feb 2004 17:22:09 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArlhI-0001Lg-00 for disman@ietf.org; Fri, 13 Feb 2004 14:22:08 -0800 Message-ID: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Disman session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 14:23:22 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - There has been some recent discussion about possible new work in the disman working group. There is also the question of advancing some of the specifications that have come from this working group. In order to help reach some kind of closure, I've requested a one-hour slot for disman in Seoul. Disman's session is *currently* scheduled on Tuesday, March second in the 17:00-18:00 time slot. Since the agenda has not yet been finalized, this date/time may change, so watch for the final agenda. I'd like to get a good sense of whether there is sufficient interest and need to continue work as a working group. If there is, I'd like to know which items enjoy adequate support. At our last face-to-face meeting, there seemed to be some interest in advancing some of our documents to Draft Standard, but follow-through has been uneven. Of course, I *strongly* encourage folks to get those discussions underway on this mailing list, so we can use our meeting time productively and provide our AD with the information he needs to make a decision on how to proceed. Please post to this mailing list any other pertinent topics you would like to discuss, so I can submit an agenda in time for the Tuesday, February 24th deadline. Lack of discussion will be interpreted as disinterest, and I do not want to waste resources on uninteresting work. Randy From disman-admin@ietf.org Fri Feb 13 18:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12558 for ; Fri, 13 Feb 2004 18:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmI0-0005z9-As; Fri, 13 Feb 2004 18:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmHF-0005kh-Kl for disman@optimus.ietf.org; Fri, 13 Feb 2004 17:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12481 for ; Fri, 13 Feb 2004 17:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmHC-0006Om-00 for disman@ietf.org; Fri, 13 Feb 2004 17:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmGB-0006Jw-00 for disman@ietf.org; Fri, 13 Feb 2004 17:58:12 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArmFF-0006GH-00 for disman@ietf.org; Fri, 13 Feb 2004 17:57:13 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArmFF-0003l0-00 for disman@ietf.org; Fri, 13 Feb 2004 14:57:13 -0800 Message-ID: <00d001c3f284$e43fd7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 14:58:26 -0800 Hi - > From: "Shailaja Yadawad" > To: > Cc: "Hemanth Kumar" ; "Raja Shekar" ; "Hemanth Yamijala" > Sent: Friday, February 13, 2004 7:50 AM > Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features ... > At the moment a group of us are working on a draft-00-. The work is You've missed the deadline for submitting -00- drafts. However, since this does appear relevant to discussion of advancing or updating the event and expression MIBs, I'd encourage you to make the URL for your work available until the i-d can be posted. The rest of my comments are as a technical contributor. ... > Thanks,Shailaja. Discussion: Suppose if the user needs to collect > history for all the instances of a columnar object say e.g., on the > interface related statistics (ifTable of MIB-II) like packets sent for > all the interfaces by using the usrHistory group object definition, the > user is required to carry out configuration for each instance > separately. The usr History group does not provide a single point of ... How would you compare this with what can be done with RFC 2982 section 2.3.2? See also the WG archives for May of 2002. Further note that last year we were toying with the idea of making that document "Historic", so I think it's really important for us to understand how this approach is better and more likely to be widely implemented. ... > for such parameter. There is another problem that arises vis-a-vis the > history collection of columnar variables. The numbers of instances for > these parameters are not fixed. This means that there could be new > instances that are added or existing ones removed, as per the dynamic > behavior of the system being monitored. For example, new interfaces ... This could also happen as a result of a change to an access control policy. ... > find all the instances of the table automatically. At the same time, > this would also allow the agent to keep track of additions and deletions > that occur as stated above. (b) Consistent reference to the resource: It ... Looking at this from an RFC 2741 perspective, how could it distinguish between, for example, something being deleted and its becoming invisible due to access control? Does this distinction matter, either operationally or mathematically? ... > example, in the case of the hrSWRunTable, the name of the software could > serve as a good identifier. This problem is addressed by introducing a > concept of 'Identifier Object'. The Identifier Objects are one or more > Columnar Objects that will serve to uniquely identify one instance among > several ones of selected columnar objects. The MIB definition allows the > user to associate Identifier Objects to the columnar Object being > sampled. By doing so, it is now left to the monitoring application to > make sure that data is being collected for the right resource even if it > changes with time. (c) Instance Filtering: It must be possible to ... This sounds like an automated way to take advantage of objects like RFC 2863's ifAlias. ... > or modified. (d) Threshold Monitoring: Combining the aspect of threshold > monitoring with history collection: In addition to the above > considerations, the current object definition also tries to combine the > functionality of threshold-based monitoring with the history collection > functionality. It allows the user to define thresholds on the data being > monitored. Any violation of the threshold would result in a trap being > generated. ... How does this differ from what RFC 2981 provides? One last general comment: the phrase "statistical sampling" can mean several very different things. If you think that it is the correct term for what you're proposing, it'd be helpful to define fairly precisely the sense in which you intend to use it, particularly due to the unfortunate events associated with the phrase in RMON. Randy From exim@www1.ietf.org Fri Feb 13 18:01:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12611 for ; Fri, 13 Feb 2004 18:01:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmJJ-0006mJ-Aw for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 18:01:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DN1P9P026042 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 18:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmJJ-0006lt-10 for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12600 for ; Fri, 13 Feb 2004 18:01:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmJG-0006Zs-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmIL-0006Vb-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:00:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArmI1-0006RH-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmI0-0005z9-As; Fri, 13 Feb 2004 18:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmHF-0005kh-Kl for disman@optimus.ietf.org; Fri, 13 Feb 2004 17:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12481 for ; Fri, 13 Feb 2004 17:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmHC-0006Om-00 for disman@ietf.org; Fri, 13 Feb 2004 17:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmGB-0006Jw-00 for disman@ietf.org; Fri, 13 Feb 2004 17:58:12 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArmFF-0006GH-00 for disman@ietf.org; Fri, 13 Feb 2004 17:57:13 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArmFF-0003l0-00 for disman@ietf.org; Fri, 13 Feb 2004 14:57:13 -0800 Message-ID: <00d001c3f284$e43fd7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 14:58:26 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - > From: "Shailaja Yadawad" > To: > Cc: "Hemanth Kumar" ; "Raja Shekar" ; "Hemanth Yamijala" > Sent: Friday, February 13, 2004 7:50 AM > Subject: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced features ... > At the moment a group of us are working on a draft-00-. The work is You've missed the deadline for submitting -00- drafts. However, since this does appear relevant to discussion of advancing or updating the event and expression MIBs, I'd encourage you to make the URL for your work available until the i-d can be posted. The rest of my comments are as a technical contributor. ... > Thanks,Shailaja. Discussion: Suppose if the user needs to collect > history for all the instances of a columnar object say e.g., on the > interface related statistics (ifTable of MIB-II) like packets sent for > all the interfaces by using the usrHistory group object definition, the > user is required to carry out configuration for each instance > separately. The usr History group does not provide a single point of ... How would you compare this with what can be done with RFC 2982 section 2.3.2? See also the WG archives for May of 2002. Further note that last year we were toying with the idea of making that document "Historic", so I think it's really important for us to understand how this approach is better and more likely to be widely implemented. ... > for such parameter. There is another problem that arises vis-a-vis the > history collection of columnar variables. The numbers of instances for > these parameters are not fixed. This means that there could be new > instances that are added or existing ones removed, as per the dynamic > behavior of the system being monitored. For example, new interfaces ... This could also happen as a result of a change to an access control policy. ... > find all the instances of the table automatically. At the same time, > this would also allow the agent to keep track of additions and deletions > that occur as stated above. (b) Consistent reference to the resource: It ... Looking at this from an RFC 2741 perspective, how could it distinguish between, for example, something being deleted and its becoming invisible due to access control? Does this distinction matter, either operationally or mathematically? ... > example, in the case of the hrSWRunTable, the name of the software could > serve as a good identifier. This problem is addressed by introducing a > concept of 'Identifier Object'. The Identifier Objects are one or more > Columnar Objects that will serve to uniquely identify one instance among > several ones of selected columnar objects. The MIB definition allows the > user to associate Identifier Objects to the columnar Object being > sampled. By doing so, it is now left to the monitoring application to > make sure that data is being collected for the right resource even if it > changes with time. (c) Instance Filtering: It must be possible to ... This sounds like an automated way to take advantage of objects like RFC 2863's ifAlias. ... > or modified. (d) Threshold Monitoring: Combining the aspect of threshold > monitoring with history collection: In addition to the above > considerations, the current object definition also tries to combine the > functionality of threshold-based monitoring with the history collection > functionality. It allows the user to define thresholds on the data being > monitored. Any violation of the threshold would result in a trap being > generated. ... How does this differ from what RFC 2981 provides? One last general comment: the phrase "statistical sampling" can mean several very different things. If you think that it is the correct term for what you're proposing, it'd be helpful to define fairly precisely the sense in which you intend to use it, particularly due to the unfortunate events associated with the phrase in RMON. Randy From disman-admin@ietf.org Fri Feb 13 18:26:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14974 for ; Fri, 13 Feb 2004 18:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armh7-0005YP-9u; Fri, 13 Feb 2004 18:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmgS-0005XV-V9 for disman@optimus.ietf.org; Fri, 13 Feb 2004 18:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14911 for ; Fri, 13 Feb 2004 18:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmgP-0000hL-00 for disman@ietf.org; Fri, 13 Feb 2004 18:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmfN-0000cZ-00 for disman@ietf.org; Fri, 13 Feb 2004 18:24:14 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArmeP-0000YO-00 for disman@ietf.org; Fri, 13 Feb 2004 18:23:13 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArmeO-00031k-00 for disman@ietf.org; Fri, 13 Feb 2004 15:23:12 -0800 Message-ID: <00e701c3f288$858eace0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: Visa letters - next to last chapter....? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 15:24:26 -0800 Hi - In case you are planning to attend the Seoul meeting, and you are a US citizen, and you are not on the big IETF mailing list: > From: "Harald Tveit Alvestrand" > To: > Sent: Friday, February 13, 2004 2:46 PM > Subject: Visa letters - next to last chapter....? > > Some glitch at the secretariat has led to the letters Gene Gaines has been > so helpful in procuring not being posted to the Web before the weekend. > > As an interim measure, I have posted them to my personal web site. > > Look at http://www.alvestrand.no/ietf/korean-visa.html > > Take care! > > Harald Alvestrand If you're wondering what this is all about, please see to the IETF archives, since it's far too complexificated to re-hash on this list. Randy From exim@www1.ietf.org Fri Feb 13 18:27:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15019 for ; Fri, 13 Feb 2004 18:27:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmiS-0005cx-7W for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 18:27:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DNROWS021625 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 18:27:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmiR-0005ci-KP for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 18:27:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15013 for ; Fri, 13 Feb 2004 18:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmiO-0000t6-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:27:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Armha-0000pH-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:26:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Armh8-0000kI-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 18:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Armh7-0005YP-9u; Fri, 13 Feb 2004 18:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArmgS-0005XV-V9 for disman@optimus.ietf.org; Fri, 13 Feb 2004 18:25:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14911 for ; Fri, 13 Feb 2004 18:25:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArmgP-0000hL-00 for disman@ietf.org; Fri, 13 Feb 2004 18:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArmfN-0000cZ-00 for disman@ietf.org; Fri, 13 Feb 2004 18:24:14 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1ArmeP-0000YO-00 for disman@ietf.org; Fri, 13 Feb 2004 18:23:13 -0500 Received: from h-68-164-93-176.snvacaid.dynamic.covad.net ([68.164.93.176] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ArmeO-00031k-00 for disman@ietf.org; Fri, 13 Feb 2004 15:23:12 -0800 Message-ID: <00e701c3f288$858eace0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Visa letters - next to last chapter....? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 15:24:26 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - In case you are planning to attend the Seoul meeting, and you are a US citizen, and you are not on the big IETF mailing list: > From: "Harald Tveit Alvestrand" > To: > Sent: Friday, February 13, 2004 2:46 PM > Subject: Visa letters - next to last chapter....? > > Some glitch at the secretariat has led to the letters Gene Gaines has been > so helpful in procuring not being posted to the Web before the weekend. > > As an interim measure, I have posted them to my personal web site. > > Look at http://www.alvestrand.no/ietf/korean-visa.html > > Take care! > > Harald Alvestrand If you're wondering what this is all about, please see to the IETF archives, since it's far too complexificated to re-hash on this list. Randy From disman-admin@ietf.org Sun Feb 15 10:11:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13264 for ; Sun, 15 Feb 2004 10:11:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNvC-00013N-UP; Sun, 15 Feb 2004 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNuj-0000vx-Nl for disman@optimus.ietf.org; Sun, 15 Feb 2004 10:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13184 for ; Sun, 15 Feb 2004 10:10:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsNuh-0004I4-00 for disman@ietf.org; Sun, 15 Feb 2004 10:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsNtl-0004Fs-00 for disman@ietf.org; Sun, 15 Feb 2004 10:09:34 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsNtU-0004DU-00 for disman@ietf.org; Sun, 15 Feb 2004 10:09:16 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1FF5S2B022064 for ; Sun, 15 Feb 2004 10:05:29 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1FF5Q2B022044 for ; Sun, 15 Feb 2004 10:05:27 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Disman session in Seoul X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Disman session in Seoul Thread-Index: AcPygQp7TbGINL8mTT6IWUOQc3aYIQBVDg4w From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 17:09:13 +0200 Content-Transfer-Encoding: quoted-printable Randy, Can you help us with a list of issues and pointer to the relevant = drafts? I know that they may have been announced on the list, but = getting them listed in one mail can help. One issue which IMO does not fall under the scope of Disman is the = latest proposal by Shailaja Yadawad on statistical sampling.=20 Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 14 February, 2004 12:23 AM > To: Disman (E-mail) > Subject: [Disman] Disman session in Seoul >=20 >=20 > Hi - >=20 > There has been some recent discussion about possible new > work in the disman working group. There is also the question > of advancing some of the specifications that have come from this > working group. In order to help reach some kind of closure, > I've requested a one-hour slot for disman in Seoul. >=20 > Disman's session is *currently* scheduled on Tuesday, March second > in the 17:00-18:00 time slot. Since the agenda has not yet been > finalized, this date/time may change, so watch for the final agenda. >=20 > I'd like to get a good sense of whether there is sufficient=20 > interest and > need to continue work as a working group. If there is, I'd=20 > like to know > which items enjoy adequate support. At our last face-to-face meeting, > there seemed to be some interest in advancing some of our documents > to Draft Standard, but follow-through has been uneven. Of course, > I *strongly* encourage folks to get those discussions underway on > this mailing list, so we can use our meeting time=20 > productively and provide > our AD with the information he needs to make a decision on=20 > how to proceed. >=20 > Please post to this mailing list any other pertinent topics=20 > you would like to > discuss, so I can submit an agenda in time for the Tuesday,=20 > February 24th > deadline. >=20 > Lack of discussion will be interpreted as disinterest, and I=20 > do not want > to waste resources on uninteresting work. >=20 > Randy >=20 >=20 >=20 >=20 From exim@www1.ietf.org Sun Feb 15 10:13:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13398 for ; Sun, 15 Feb 2004 10:13:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNwh-0001eb-TY for disman-archive@odin.ietf.org; Sun, 15 Feb 2004 10:12:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FFCZW6006351 for disman-archive@odin.ietf.org; Sun, 15 Feb 2004 10:12:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNwh-0001eG-NX for disman-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 10:12:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13358 for ; Sun, 15 Feb 2004 10:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsNwf-0004O8-00 for disman-web-archive@ietf.org; Sun, 15 Feb 2004 10:12:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsNvj-0004Lc-00 for disman-web-archive@ietf.org; Sun, 15 Feb 2004 10:11:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsNvG-0004Io-00 for disman-web-archive@ietf.org; Sun, 15 Feb 2004 10:11:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNvC-00013N-UP; Sun, 15 Feb 2004 10:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsNuj-0000vx-Nl for disman@optimus.ietf.org; Sun, 15 Feb 2004 10:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13184 for ; Sun, 15 Feb 2004 10:10:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsNuh-0004I4-00 for disman@ietf.org; Sun, 15 Feb 2004 10:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsNtl-0004Fs-00 for disman@ietf.org; Sun, 15 Feb 2004 10:09:34 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsNtU-0004DU-00 for disman@ietf.org; Sun, 15 Feb 2004 10:09:16 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1FF5S2B022064 for ; Sun, 15 Feb 2004 10:05:29 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1FF5Q2B022044 for ; Sun, 15 Feb 2004 10:05:27 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Disman session in Seoul X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Disman session in Seoul Thread-Index: AcPygQp7TbGINL8mTT6IWUOQc3aYIQBVDg4w From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 15 Feb 2004 17:09:13 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Randy, Can you help us with a list of issues and pointer to the relevant = drafts? I know that they may have been announced on the list, but = getting them listed in one mail can help. One issue which IMO does not fall under the scope of Disman is the = latest proposal by Shailaja Yadawad on statistical sampling.=20 Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 14 February, 2004 12:23 AM > To: Disman (E-mail) > Subject: [Disman] Disman session in Seoul >=20 >=20 > Hi - >=20 > There has been some recent discussion about possible new > work in the disman working group. There is also the question > of advancing some of the specifications that have come from this > working group. In order to help reach some kind of closure, > I've requested a one-hour slot for disman in Seoul. >=20 > Disman's session is *currently* scheduled on Tuesday, March second > in the 17:00-18:00 time slot. Since the agenda has not yet been > finalized, this date/time may change, so watch for the final agenda. >=20 > I'd like to get a good sense of whether there is sufficient=20 > interest and > need to continue work as a working group. If there is, I'd=20 > like to know > which items enjoy adequate support. At our last face-to-face meeting, > there seemed to be some interest in advancing some of our documents > to Draft Standard, but follow-through has been uneven. Of course, > I *strongly* encourage folks to get those discussions underway on > this mailing list, so we can use our meeting time=20 > productively and provide > our AD with the information he needs to make a decision on=20 > how to proceed. >=20 > Please post to this mailing list any other pertinent topics=20 > you would like to > discuss, so I can submit an agenda in time for the Tuesday,=20 > February 24th > deadline. >=20 > Lack of discussion will be interpreted as disinterest, and I=20 > do not want > to waste resources on uninteresting work. >=20 > Randy >=20 >=20 >=20 >=20 From disman-admin@ietf.org Mon Feb 16 06:55:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12803 for ; Mon, 16 Feb 2004 06:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshL5-0007kM-El; Mon, 16 Feb 2004 06:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshKF-0007iR-Qo for disman@optimus.ietf.org; Mon, 16 Feb 2004 06:54:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12783 for ; Mon, 16 Feb 2004 06:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshKB-0005rh-00 for disman@ietf.org; Mon, 16 Feb 2004 06:54:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshJI-0005of-00 for disman@ietf.org; Mon, 16 Feb 2004 06:53:13 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1AshIT-0005it-00 for disman@ietf.org; Mon, 16 Feb 2004 06:52:21 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 16 Feb 2004 04:51:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Subject: Re: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced featur Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part6E4F13D8.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 04:51:36 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6E4F13D8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, >You've missed the deadline for submitting -00- drafts. However, since >this does appear relevant to discussion of advancing or updating the >event and expression MIBs, I'd encourage you to make the URL for >your work available until the i-d can be posted. I will. May be after 4 days because of some problem. >How would you compare this with what can be done with RFC 2982 >section 2.3.2? See also the WG archives for May of 2002. Further >note that last year we were toying with the idea of making that document >"Historic", so I think it's really important for us to understand how >this approach is better and more likely to be widely implemented. section 2.3.2 functionality as what we are proposing but in our framework, we do not let wildcard. And hence we monitor either the scalar object or selective or all instances of a columnaar object. ... > for such parameter. There is another problem that arises vis-a-vis the > history collection of columnar variables. The numbers of instances for > these parameters are not fixed. This means that there could be new > instances that are added or existing ones removed, as per the dynamic > behavior of the system being monitored. For example, new interfaces ... Yes you are correct that the above mentioned phenomena could happend because of the change in the access control . >Looking at this from an RFC 2741 perspective, how could it distinguish >between, for example, something being deleted and its becoming >invisible due to access control? Does this distinction matter, either >operationally or mathematically? While designing we did not consider about the access control but this is how it should behave, Operationally: No distinction. No matter due to what reason the instance is not available, best is to stop collecting the history data. Mathematically: Yes distinct. suppose a instance is deleted it never gets into the filter criteria where as a invisiable instance is considered for filtering. >How does this differ from what RFC 2981 provides? I would like to give more thought on this above point before I answer anything. >One last general comment: the phrase "statistical sampling" can mean >several very different things. If you think that it is the correct term for >what you're proposing, it'd be helpful to define fairly precisely the >sense in which you intend to use it, particularly due to the unfortunate >events associated with the phrase in RMON. I used "statistical sampling" for history collection. I used statistical sampling word from RMON, it was my thought that people are already have associated history collection to statistical sampling andso continue to use. I will give a second thought about the word "statistical sampling". Regards, Shailaja. --=__Part6E4F13D8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi,

>You've missed the deadline for submitting -00- drafts.  However, since
>this does appear relevant to discussion of advancing or updating the
>event and expression MIBs, I'd encourage you to make the URL for
>your work available until the i-d can be posted.
 
 
I will. May be after 4 days because of some problem.


>How would you compare this with what can be done with RFC 2982
>section 2.3.2?  See also the WG archives for May of 2002.  Further
>note that last year we were toying with the idea of making that document
>"Historic", so I think it's really important for us to understand how
>this approach is better and more likely to be widely implemented.
 
section 2.3.2  functionality as what we are proposing but in our framework, we do not let wildcard. And hence we monitor either the scalar object or selective or all instances of a columnaar object.
 
...
> for such parameter.  There is another problem that arises vis-a-vis the
> history collection of columnar variables. The numbers of instances for
> these parameters are not fixed. This means that there could be new
> instances that are added or existing ones removed, as per the dynamic
> behavior of the system being monitored. For example, new interfaces
...

Yes you are correct that the above mentioned phenomena could happend because of the change in the access control .

>Looking at this from an RFC 2741 perspective, how could it distinguish
>between, for example, something being deleted and its becoming
>invisible due to access control?  Does this distinction matter, either
>operationally or mathematically?
While designing we did not consider about the access control but this is how it should behave,
 
Operationally: No distinction. No matter due to what reason the instance is not available, best is to stop collecting the history data.
 
Mathematically:  Yes distinct. suppose a instance is deleted it never gets into the filter criteria where as a invisiable instance is considered for filtering.
 

>How does this differ from what RFC 2981 provides?
 
I would like to give more thought on this above point before I answer anything.


>One last general comment:  the phrase "statistical sampling" can mean
>several very different things.  If you think that it is the correct term for
>what you're proposing, it'd be helpful to define fairly precisely the
>sense in which you intend to use it, particularly due to the unfortunate
>events associated with the phrase in RMON.
I used "statistical sampling" for history collection. I used statistical sampling word from RMON, it was my thought that people are already have associated  history collection to  statistical sampling andso continue to use. I will give a second thought about the word "statistical sampling".



Regards,
Shailaja.


 
--=__Part6E4F13D8.0__=-- From exim@www1.ietf.org Mon Feb 16 06:56:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12855 for ; Mon, 16 Feb 2004 06:56:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshMH-0007pM-FL for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 06:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GBuHQn030071 for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 06:56:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshMH-0007ob-5i for disman-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 06:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12847 for ; Mon, 16 Feb 2004 06:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshMC-0005ys-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 06:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshLJ-0005wP-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 06:55:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AshL3-0005tL-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 06:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshL5-0007kM-El; Mon, 16 Feb 2004 06:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshKF-0007iR-Qo for disman@optimus.ietf.org; Mon, 16 Feb 2004 06:54:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12783 for ; Mon, 16 Feb 2004 06:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshKB-0005rh-00 for disman@ietf.org; Mon, 16 Feb 2004 06:54:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshJI-0005of-00 for disman@ietf.org; Mon, 16 Feb 2004 06:53:13 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1AshIT-0005it-00 for disman@ietf.org; Mon, 16 Feb 2004 06:52:21 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 16 Feb 2004 04:51:52 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Subject: Re: [Disman] Statistical Sampling of Data- Discussion onrequirement and proposal on advanced featur Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part6E4F13D8.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 04:51:36 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6E4F13D8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, >You've missed the deadline for submitting -00- drafts. However, since >this does appear relevant to discussion of advancing or updating the >event and expression MIBs, I'd encourage you to make the URL for >your work available until the i-d can be posted. I will. May be after 4 days because of some problem. >How would you compare this with what can be done with RFC 2982 >section 2.3.2? See also the WG archives for May of 2002. Further >note that last year we were toying with the idea of making that document >"Historic", so I think it's really important for us to understand how >this approach is better and more likely to be widely implemented. section 2.3.2 functionality as what we are proposing but in our framework, we do not let wildcard. And hence we monitor either the scalar object or selective or all instances of a columnaar object. ... > for such parameter. There is another problem that arises vis-a-vis the > history collection of columnar variables. The numbers of instances for > these parameters are not fixed. This means that there could be new > instances that are added or existing ones removed, as per the dynamic > behavior of the system being monitored. For example, new interfaces ... Yes you are correct that the above mentioned phenomena could happend because of the change in the access control . >Looking at this from an RFC 2741 perspective, how could it distinguish >between, for example, something being deleted and its becoming >invisible due to access control? Does this distinction matter, either >operationally or mathematically? While designing we did not consider about the access control but this is how it should behave, Operationally: No distinction. No matter due to what reason the instance is not available, best is to stop collecting the history data. Mathematically: Yes distinct. suppose a instance is deleted it never gets into the filter criteria where as a invisiable instance is considered for filtering. >How does this differ from what RFC 2981 provides? I would like to give more thought on this above point before I answer anything. >One last general comment: the phrase "statistical sampling" can mean >several very different things. If you think that it is the correct term for >what you're proposing, it'd be helpful to define fairly precisely the >sense in which you intend to use it, particularly due to the unfortunate >events associated with the phrase in RMON. I used "statistical sampling" for history collection. I used statistical sampling word from RMON, it was my thought that people are already have associated history collection to statistical sampling andso continue to use. I will give a second thought about the word "statistical sampling". Regards, Shailaja. --=__Part6E4F13D8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi,

>You've missed the deadline for submitting -00- drafts.  However, since
>this does appear relevant to discussion of advancing or updating the
>event and expression MIBs, I'd encourage you to make the URL for
>your work available until the i-d can be posted.
 
 
I will. May be after 4 days because of some problem.


>How would you compare this with what can be done with RFC 2982
>section 2.3.2?  See also the WG archives for May of 2002.  Further
>note that last year we were toying with the idea of making that document
>"Historic", so I think it's really important for us to understand how
>this approach is better and more likely to be widely implemented.
 
section 2.3.2  functionality as what we are proposing but in our framework, we do not let wildcard. And hence we monitor either the scalar object or selective or all instances of a columnaar object.
 
...
> for such parameter.  There is another problem that arises vis-a-vis the
> history collection of columnar variables. The numbers of instances for
> these parameters are not fixed. This means that there could be new
> instances that are added or existing ones removed, as per the dynamic
> behavior of the system being monitored. For example, new interfaces
...

Yes you are correct that the above mentioned phenomena could happend because of the change in the access control .

>Looking at this from an RFC 2741 perspective, how could it distinguish
>between, for example, something being deleted and its becoming
>invisible due to access control?  Does this distinction matter, either
>operationally or mathematically?
While designing we did not consider about the access control but this is how it should behave,
 
Operationally: No distinction. No matter due to what reason the instance is not available, best is to stop collecting the history data.
 
Mathematically:  Yes distinct. suppose a instance is deleted it never gets into the filter criteria where as a invisiable instance is considered for filtering.
 

>How does this differ from what RFC 2981 provides?
 
I would like to give more thought on this above point before I answer anything.


>One last general comment:  the phrase "statistical sampling" can mean
>several very different things.  If you think that it is the correct term for
>what you're proposing, it'd be helpful to define fairly precisely the
>sense in which you intend to use it, particularly due to the unfortunate
>events associated with the phrase in RMON.
I used "statistical sampling" for history collection. I used statistical sampling word from RMON, it was my thought that people are already have associated  history collection to  statistical sampling andso continue to use. I will give a second thought about the word "statistical sampling".



Regards,
Shailaja.


 
--=__Part6E4F13D8.0__=-- From disman-admin@ietf.org Mon Feb 16 16:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26784 for ; Mon, 16 Feb 2004 16:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqBl-0007r1-Ij; Mon, 16 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqBN-0007qD-JD for disman@optimus.ietf.org; Mon, 16 Feb 2004 16:21:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26712 for ; Mon, 16 Feb 2004 16:21:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqBL-0001sb-00 for disman@ietf.org; Mon, 16 Feb 2004 16:21:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asq9u-0001bY-00 for disman@ietf.org; Mon, 16 Feb 2004 16:20:07 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Asq95-0001L6-00 for disman@ietf.org; Mon, 16 Feb 2004 16:19:15 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1GLIbx8068614 for ; Mon, 16 Feb 2004 22:18:38 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1GLIZ62068613 for ; Mon, 16 Feb 2004 22:18:35 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1GLIYx6068611; Mon, 16 Feb 2004 22:18:35 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A26DD1086B2; Mon, 16 Feb 2004 22:18:32 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Disman session in Seoul Message-ID: <2147483647.1076969942@[10.1.1.26]> In-Reply-To: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 22:19:02 +0100 Content-Transfer-Encoding: quoted-printable Randy, In January Giorgio posted our draft of the Check MIB (draft-nunzi-check-mib-00.txt), a light-weight combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. If there is a disman session in Seoul, I would like to present this MIB module and ask if there is any interest in standardizing it. Thanks, J=FCrgen --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 13.02.2004 14:23 Uhr -0800 Randy Presuhn wrote: > Hi - > > There has been some recent discussion about possible new > work in the disman working group. There is also the question > of advancing some of the specifications that have come from this > working group. In order to help reach some kind of closure, > I've requested a one-hour slot for disman in Seoul. > > Disman's session is *currently* scheduled on Tuesday, March second > in the 17:00-18:00 time slot. Since the agenda has not yet been > finalized, this date/time may change, so watch for the final agenda. > > I'd like to get a good sense of whether there is sufficient interest and > need to continue work as a working group. If there is, I'd like to know > which items enjoy adequate support. At our last face-to-face meeting, > there seemed to be some interest in advancing some of our documents > to Draft Standard, but follow-through has been uneven. Of course, > I *strongly* encourage folks to get those discussions underway on > this mailing list, so we can use our meeting time productively and provide > our AD with the information he needs to make a decision on how to proceed. > > Please post to this mailing list any other pertinent topics you would like to > discuss, so I can submit an agenda in time for the Tuesday, February 24th > deadline. > > Lack of discussion will be interpreted as disinterest, and I do not want > to waste resources on uninteresting work. > > Randy > > > From exim@www1.ietf.org Mon Feb 16 16:42:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29320 for ; Mon, 16 Feb 2004 16:42:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqV8-0000k2-Kb for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 16:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLg26q002840 for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 16:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqV8-0000jc-27 for disman-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:42:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29290 for ; Mon, 16 Feb 2004 16:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqV5-0004m1-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqU4-0004b1-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:40:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsqSR-0004Ib-04 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:39:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AsqBr-0003wc-26 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqBl-0007r1-Ij; Mon, 16 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqBN-0007qD-JD for disman@optimus.ietf.org; Mon, 16 Feb 2004 16:21:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26712 for ; Mon, 16 Feb 2004 16:21:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqBL-0001sb-00 for disman@ietf.org; Mon, 16 Feb 2004 16:21:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asq9u-0001bY-00 for disman@ietf.org; Mon, 16 Feb 2004 16:20:07 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Asq95-0001L6-00 for disman@ietf.org; Mon, 16 Feb 2004 16:19:15 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1GLIbx8068614 for ; Mon, 16 Feb 2004 22:18:38 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1GLIZ62068613 for ; Mon, 16 Feb 2004 22:18:35 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1GLIYx6068611; Mon, 16 Feb 2004 22:18:35 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A26DD1086B2; Mon, 16 Feb 2004 22:18:32 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Disman session in Seoul Message-ID: <2147483647.1076969942@[10.1.1.26]> In-Reply-To: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 22:19:02 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Randy, In January Giorgio posted our draft of the Check MIB (draft-nunzi-check-mib-00.txt), a light-weight combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. If there is a disman session in Seoul, I would like to present this MIB module and ask if there is any interest in standardizing it. Thanks, J=FCrgen --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 13.02.2004 14:23 Uhr -0800 Randy Presuhn wrote: > Hi - > > There has been some recent discussion about possible new > work in the disman working group. There is also the question > of advancing some of the specifications that have come from this > working group. In order to help reach some kind of closure, > I've requested a one-hour slot for disman in Seoul. > > Disman's session is *currently* scheduled on Tuesday, March second > in the 17:00-18:00 time slot. Since the agenda has not yet been > finalized, this date/time may change, so watch for the final agenda. > > I'd like to get a good sense of whether there is sufficient interest and > need to continue work as a working group. If there is, I'd like to know > which items enjoy adequate support. At our last face-to-face meeting, > there seemed to be some interest in advancing some of our documents > to Draft Standard, but follow-through has been uneven. Of course, > I *strongly* encourage folks to get those discussions underway on > this mailing list, so we can use our meeting time productively and provide > our AD with the information he needs to make a decision on how to proceed. > > Please post to this mailing list any other pertinent topics you would like to > discuss, so I can submit an agenda in time for the Tuesday, February 24th > deadline. > > Lack of discussion will be interpreted as disinterest, and I do not want > to waste resources on uninteresting work. > > Randy > > > From disman-admin@ietf.org Mon Feb 16 16:51:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29734 for ; Mon, 16 Feb 2004 16:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asqdp-0001Jj-CW; Mon, 16 Feb 2004 16:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqdM-0001Io-P9 for disman@optimus.ietf.org; Mon, 16 Feb 2004 16:50:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29720 for ; Mon, 16 Feb 2004 16:50:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqdK-0005Qe-00 for disman@ietf.org; Mon, 16 Feb 2004 16:50:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqcV-0005O5-00 for disman@ietf.org; Mon, 16 Feb 2004 16:49:40 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Asqbd-0005Gd-00 for disman@ietf.org; Mon, 16 Feb 2004 16:48:45 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1GLmEx6068900 for ; Mon, 16 Feb 2004 22:48:14 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B3AB0108693 for ; Mon, 16 Feb 2004 22:48:11 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Subject: Re: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <2147483647.1076971720@[10.1.1.26]> In-Reply-To: <200402112046.PAA21506@ietf.org> References: <200402112046.PAA21506@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 22:48:41 +0100 Content-Transfer-Encoding: 7bit Dear all, Below please find the list of changes in the remops I-D (draft-ietf-disman-remops-mib-v2-01.txt) since the last version (except a set of pure editorial changes). Randy, it looks like we are ready to enter WG last call. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de DISMAN-NSLOOKUP-MIB: - added value enabled(1) to SYNTAX clause of lookupCtlOperStatus DISMAN-PING-MIB: - correctly considered IPv6 in DESCRIPTION clause of pingCtlDataSize - added DEFVAL { {} } to definition of pingCtlTrapGeneration - extended DESCRIPTION clause of pingResultsTable describing re-initialization of entries - changed SYNTAX of pingResultsProbeResponses and pingResultsSentProbes from Unsigned32 to Gauge32 DISMAN-TRACEROUTE-MIB: - correctly considered IPv6 in DESCRIPTION clause of object traceRouteCtlDataSize - clarified DESCRIPTION clause of object traceRouteResultsLastGoodPath - changed range of object traceRouteCtlInitialTtl from (0..255) to (1..255) - extended DESCRIPTION clause of traceRouteResultsTable describing re-initialization of entries - changed SYNTAX of traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses from Unsigned32 to Gauge32 all three: - replaced references to RFC 2575 by RFC 3415 - replaced references to RFC 2571 by RFC 3411 - replaced references to RFC 2851 by RFC 3291 --On 11.02.2004 15:46 h -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Distributed Management Working Group of the IETF. > > Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations > Author(s) : J. Quittek, K. White > Filename : draft-ietf-disman-remops-mib-v2-01.txt > Pages : 76 > Date : 2004-2-11 > > This memo defines Management Information Bases (MIBs) for performing > remote ping, traceroute and lookup operations at a remote host. When > managing a network it is useful to be able to initiate and retrieve > the results of ping or traceroute operations when performed at a > remote host. A Lookup capability is defined in order to enable > resolving of either an IP address to an DNS name or an DNS name to an > IP address at a remote host. > Currently, there are several enterprise-specific MIBs for performing > remote ping or traceroute operations. The purpose of this memo is to > define a standards-based solution to enable interoperability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-disman-remops-mib-v2-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From exim@www1.ietf.org Mon Feb 16 16:53:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29797 for ; Mon, 16 Feb 2004 16:53:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqfM-0001Ti-1w for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 16:52:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GLqaF7005676 for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 16:52:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqfL-0001TT-Uy for disman-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 16:52:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29765 for ; Mon, 16 Feb 2004 16:52:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqfJ-0005Vw-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:52:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqeL-0005TY-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:51:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asqdp-0005RB-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 16:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asqdp-0001Jj-CW; Mon, 16 Feb 2004 16:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqdM-0001Io-P9 for disman@optimus.ietf.org; Mon, 16 Feb 2004 16:50:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29720 for ; Mon, 16 Feb 2004 16:50:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqdK-0005Qe-00 for disman@ietf.org; Mon, 16 Feb 2004 16:50:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqcV-0005O5-00 for disman@ietf.org; Mon, 16 Feb 2004 16:49:40 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Asqbd-0005Gd-00 for disman@ietf.org; Mon, 16 Feb 2004 16:48:45 -0500 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1GLmEx6068900 for ; Mon, 16 Feb 2004 22:48:14 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B3AB0108693 for ; Mon, 16 Feb 2004 22:48:11 +0100 (CET) From: Juergen Quittek To: disman@ietf.org Subject: Re: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <2147483647.1076971720@[10.1.1.26]> In-Reply-To: <200402112046.PAA21506@ietf.org> References: <200402112046.PAA21506@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 22:48:41 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, Below please find the list of changes in the remops I-D (draft-ietf-disman-remops-mib-v2-01.txt) since the last version (except a set of pure editorial changes). Randy, it looks like we are ready to enter WG last call. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de DISMAN-NSLOOKUP-MIB: - added value enabled(1) to SYNTAX clause of lookupCtlOperStatus DISMAN-PING-MIB: - correctly considered IPv6 in DESCRIPTION clause of pingCtlDataSize - added DEFVAL { {} } to definition of pingCtlTrapGeneration - extended DESCRIPTION clause of pingResultsTable describing re-initialization of entries - changed SYNTAX of pingResultsProbeResponses and pingResultsSentProbes from Unsigned32 to Gauge32 DISMAN-TRACEROUTE-MIB: - correctly considered IPv6 in DESCRIPTION clause of object traceRouteCtlDataSize - clarified DESCRIPTION clause of object traceRouteResultsLastGoodPath - changed range of object traceRouteCtlInitialTtl from (0..255) to (1..255) - extended DESCRIPTION clause of traceRouteResultsTable describing re-initialization of entries - changed SYNTAX of traceRouteResultsTestAttempts and traceRouteResultsTestSuccesses from Unsigned32 to Gauge32 all three: - replaced references to RFC 2575 by RFC 3415 - replaced references to RFC 2571 by RFC 3411 - replaced references to RFC 2851 by RFC 3291 --On 11.02.2004 15:46 h -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Distributed Management Working Group of the IETF. > > Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations > Author(s) : J. Quittek, K. White > Filename : draft-ietf-disman-remops-mib-v2-01.txt > Pages : 76 > Date : 2004-2-11 > > This memo defines Management Information Bases (MIBs) for performing > remote ping, traceroute and lookup operations at a remote host. When > managing a network it is useful to be able to initiate and retrieve > the results of ping or traceroute operations when performed at a > remote host. A Lookup capability is defined in order to enable > resolving of either an IP address to an DNS name or an DNS name to an > IP address at a remote host. > Currently, there are several enterprise-specific MIBs for performing > remote ping or traceroute operations. The purpose of this memo is to > define a standards-based solution to enable interoperability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-disman-remops-mib-v2-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From disman-admin@ietf.org Mon Feb 16 17:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03712 for ; Mon, 16 Feb 2004 17:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrEb-00042g-5J; Mon, 16 Feb 2004 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrES-00042J-Eh for disman@optimus.ietf.org; Mon, 16 Feb 2004 17:28:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03636 for ; Mon, 16 Feb 2004 17:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrEP-0002cC-00 for disman@ietf.org; Mon, 16 Feb 2004 17:28:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrDB-0002Me-00 for disman@ietf.org; Mon, 16 Feb 2004 17:27:33 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AsrBu-000286-00 for disman@ietf.org; Mon, 16 Feb 2004 17:26:14 -0500 Received: from h-68-164-94-28.snvacaid.dynamic.covad.net ([68.164.94.28] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AsrBs-0000vD-00 for disman@ietf.org; Mon, 16 Feb 2004 14:26:12 -0800 Message-ID: <000601c3f4dc$11ec7f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> <2147483647.1076969942@[10.1.1.26]> Subject: Re: [Disman] Disman session in Seoul X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 14:26:57 -0800 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Monday, February 16, 2004 1:19 PM > Subject: Re: [Disman] Disman session in Seoul ... > In January Giorgio posted our draft of the Check MIB > (draft-nunzi-check-mib-00.txt), a light-weight combination > of the Event MIB and the Expression MIB for remote health > check operations on a large set of small managed devices. > > If there is a disman session in Seoul, I would like to present this > MIB module and ask if there is any interest in standardizing it. ... Ok, I'll make sure this is on the agenda. We're currently scheduled to meet at 17:00 on 2004-03-02 in Seoul. Randy From exim@www1.ietf.org Mon Feb 16 17:41:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05013 for ; Mon, 16 Feb 2004 17:41:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrQ1-0005f1-2J for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 17:40:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GMem0f021753 for disman-archive@odin.ietf.org; Mon, 16 Feb 2004 17:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrQ0-0005em-52 for disman-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 17:40:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04818 for ; Mon, 16 Feb 2004 17:40:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrPx-0004DM-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 17:40:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrO2-0003o3-00 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 17:38:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AsrMk-0003Y4-02 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 17:37:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AsrEc-0005Sn-Q0 for disman-web-archive@ietf.org; Mon, 16 Feb 2004 17:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrEb-00042g-5J; Mon, 16 Feb 2004 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrES-00042J-Eh for disman@optimus.ietf.org; Mon, 16 Feb 2004 17:28:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03636 for ; Mon, 16 Feb 2004 17:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrEP-0002cC-00 for disman@ietf.org; Mon, 16 Feb 2004 17:28:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrDB-0002Me-00 for disman@ietf.org; Mon, 16 Feb 2004 17:27:33 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AsrBu-000286-00 for disman@ietf.org; Mon, 16 Feb 2004 17:26:14 -0500 Received: from h-68-164-94-28.snvacaid.dynamic.covad.net ([68.164.94.28] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AsrBs-0000vD-00 for disman@ietf.org; Mon, 16 Feb 2004 14:26:12 -0800 Message-ID: <000601c3f4dc$11ec7f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> <2147483647.1076969942@[10.1.1.26]> Subject: Re: [Disman] Disman session in Seoul X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Feb 2004 14:26:57 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Monday, February 16, 2004 1:19 PM > Subject: Re: [Disman] Disman session in Seoul ... > In January Giorgio posted our draft of the Check MIB > (draft-nunzi-check-mib-00.txt), a light-weight combination > of the Event MIB and the Expression MIB for remote health > check operations on a large set of small managed devices. > > If there is a disman session in Seoul, I would like to present this > MIB module and ask if there is any interest in standardizing it. ... Ok, I'll make sure this is on the agenda. We're currently scheduled to meet at 17:00 on 2004-03-02 in Seoul. Randy From disman-admin@ietf.org Tue Feb 17 17:16:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11950 for ; Tue, 17 Feb 2004 17:16:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDVa-0005xk-RU; Tue, 17 Feb 2004 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDV0-0005uf-Tu for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:15:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11842 for ; Tue, 17 Feb 2004 17:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDUy-00055M-00 for disman@ietf.org; Tue, 17 Feb 2004 17:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDTz-0004yq-00 for disman@ietf.org; Tue, 17 Feb 2004 17:14:24 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDT6-0004ok-00 for disman@ietf.org; Tue, 17 Feb 2004 17:13:28 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDT3-0005Qb-00 for disman@ietf.org; Tue, 17 Feb 2004 14:13:25 -0800 Message-ID: <001a01c3f5a3$74089620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: Educational Sessions in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:14:46 -0800 Hi - Forwarded for your information. All of these are worthwhile, though the time slots overlap. I especially recommend the Editors Training session for anyone submitting internet drafts. Randy > From: "Margaret Wasserman" > To: ; ; ; > Sent: Tuesday, February 17, 2004 1:32 PM > Subject: Educational Sessions in Seoul > > > Hi All, > > The EDU Team is offering several training sessions on Sunday afternoon in Seoul > that are open to ALL IETF ATTENDEES. These sessions include: > > - Newcomers Training (in both English and Korean) > - Editors Training > - Introductory WG Chairs Training > - Security Tutorial > > Details about these sessions can be found below. > > Please note that you do not need to be a current Editor or WG Chair to attend > those sessions, these sessions are all open to everyone! So, show up early > and learn more about how to work effectively within the IETF. > > Margaret > > > > Sunday, February 29, 2004 > ========================= > > 1300-1400 Newcomer's Training in English -- Location?? (Spencer Dawkins) > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1400-1500 Newcomer's Training in Korean -- Location?? (ChangJoon Kim) > > [Include description on agenda in Korean, if possible.] > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1300-1500 Editor's Training -- Location?? (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1300-1500 Intro WG Chairs Training -- Location?? (Margaret Wasserman) > > Introductory training for new or aspiring WG > chairs. Covers the role and responsibilities of > a WG chair, and includes advice on how to run a > WG that is fair, open and productive. This class > is open to all IETF attendees. > > 1500-1700 Security Tutorial -- Location?? (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > According to the final agenda, the locations will be: 1300-1400 Newcomer's Training (English) - Sapphire 4 1400-1500 Newcomer's Training (Korean) - Sapphire 4 1300-1500 Editor's Training - Gardenia A-2 1300-1500 Intro WG Chairs Training - Astor 1500-1700 Security Tutorial - Sapphire 4 Randy From disman-admin@ietf.org Tue Feb 17 17:17:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12032 for ; Tue, 17 Feb 2004 17:17:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDWW-00061j-Na; Tue, 17 Feb 2004 17:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDW2-0005yg-Op for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:16:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11928 for ; Tue, 17 Feb 2004 17:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDW0-0005Be-00 for disman@ietf.org; Tue, 17 Feb 2004 17:16:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDUv-00054y-00 for disman@ietf.org; Tue, 17 Feb 2004 17:15:22 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDTz-0004yW-00 for disman@ietf.org; Tue, 17 Feb 2004 17:14:23 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDTy-0005hr-00 for disman@ietf.org; Tue, 17 Feb 2004 14:14:22 -0800 Message-ID: <001f01c3f5a3$95c07bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: Milestone addition to disman charter Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:15:43 -0800 Hi - Forwarded for your information. Randy > From: "Wijnen, Bert (Bert)" > To: ; "Randy Presuhn" > Cc: "David Kessens (E-mail)" > Sent: Tuesday, February 17, 2004 11:55 AM > Subject: RE: Milestone addition to disman charter > > approved by AD > > Thanks, > Bert > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: dinsdag 17 februari 2004 20:05 > > To: Wijnen, Bert (Bert) > > Cc: David Kessens (E-mail); ietf-action@ietf.org > > Subject: Re: Milestone addition to disman charter > > > > > > Hi - > > > > Please add the following milestones to the disman WG charter. > > > > February 2004 WG last call on updates to Remote Operations MIB > > March 2004 Implementation Report on Remote Operations MIB > > March 2004 Remote Operations MIB submitted to IESG for > > consideration as Draft Standard > > > > Randy Presuhn > > disman WG chair > > > > From exim@www1.ietf.org Tue Feb 17 17:18:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12104 for ; Tue, 17 Feb 2004 17:18:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDX7-00066q-Ie for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:17:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMHb0I023478 for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:17:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDX7-00066b-E8 for disman-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:17:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12064 for ; Tue, 17 Feb 2004 17:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDX5-0005Jj-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:17:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDWQ-0005Fh-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:16:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDVh-00059K-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDVa-0005xk-RU; Tue, 17 Feb 2004 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDV0-0005uf-Tu for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:15:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11842 for ; Tue, 17 Feb 2004 17:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDUy-00055M-00 for disman@ietf.org; Tue, 17 Feb 2004 17:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDTz-0004yq-00 for disman@ietf.org; Tue, 17 Feb 2004 17:14:24 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDT6-0004ok-00 for disman@ietf.org; Tue, 17 Feb 2004 17:13:28 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDT3-0005Qb-00 for disman@ietf.org; Tue, 17 Feb 2004 14:13:25 -0800 Message-ID: <001a01c3f5a3$74089620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Educational Sessions in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:14:46 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - Forwarded for your information. All of these are worthwhile, though the time slots overlap. I especially recommend the Editors Training session for anyone submitting internet drafts. Randy > From: "Margaret Wasserman" > To: ; ; ; > Sent: Tuesday, February 17, 2004 1:32 PM > Subject: Educational Sessions in Seoul > > > Hi All, > > The EDU Team is offering several training sessions on Sunday afternoon in Seoul > that are open to ALL IETF ATTENDEES. These sessions include: > > - Newcomers Training (in both English and Korean) > - Editors Training > - Introductory WG Chairs Training > - Security Tutorial > > Details about these sessions can be found below. > > Please note that you do not need to be a current Editor or WG Chair to attend > those sessions, these sessions are all open to everyone! So, show up early > and learn more about how to work effectively within the IETF. > > Margaret > > > > Sunday, February 29, 2004 > ========================= > > 1300-1400 Newcomer's Training in English -- Location?? (Spencer Dawkins) > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1400-1500 Newcomer's Training in Korean -- Location?? (ChangJoon Kim) > > [Include description on agenda in Korean, if possible.] > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1300-1500 Editor's Training -- Location?? (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1300-1500 Intro WG Chairs Training -- Location?? (Margaret Wasserman) > > Introductory training for new or aspiring WG > chairs. Covers the role and responsibilities of > a WG chair, and includes advice on how to run a > WG that is fair, open and productive. This class > is open to all IETF attendees. > > 1500-1700 Security Tutorial -- Location?? (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > According to the final agenda, the locations will be: 1300-1400 Newcomer's Training (English) - Sapphire 4 1400-1500 Newcomer's Training (Korean) - Sapphire 4 1300-1500 Editor's Training - Gardenia A-2 1300-1500 Intro WG Chairs Training - Astor 1500-1700 Security Tutorial - Sapphire 4 Randy From exim@www1.ietf.org Tue Feb 17 17:18:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12157 for ; Tue, 17 Feb 2004 17:18:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDXr-00069O-Dh for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:18:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMINg5023636 for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:18:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDXr-000699-AW for disman-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:18:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12131 for ; Tue, 17 Feb 2004 17:18:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDXo-0005Mm-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:18:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDX5-0005Jr-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:17:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDWV-0005Fv-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDWW-00061j-Na; Tue, 17 Feb 2004 17:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDW2-0005yg-Op for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:16:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11928 for ; Tue, 17 Feb 2004 17:16:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDW0-0005Be-00 for disman@ietf.org; Tue, 17 Feb 2004 17:16:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDUv-00054y-00 for disman@ietf.org; Tue, 17 Feb 2004 17:15:22 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDTz-0004yW-00 for disman@ietf.org; Tue, 17 Feb 2004 17:14:23 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDTy-0005hr-00 for disman@ietf.org; Tue, 17 Feb 2004 14:14:22 -0800 Message-ID: <001f01c3f5a3$95c07bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Milestone addition to disman charter Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:15:43 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - Forwarded for your information. Randy > From: "Wijnen, Bert (Bert)" > To: ; "Randy Presuhn" > Cc: "David Kessens (E-mail)" > Sent: Tuesday, February 17, 2004 11:55 AM > Subject: RE: Milestone addition to disman charter > > approved by AD > > Thanks, > Bert > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: dinsdag 17 februari 2004 20:05 > > To: Wijnen, Bert (Bert) > > Cc: David Kessens (E-mail); ietf-action@ietf.org > > Subject: Re: Milestone addition to disman charter > > > > > > Hi - > > > > Please add the following milestones to the disman WG charter. > > > > February 2004 WG last call on updates to Remote Operations MIB > > March 2004 Implementation Report on Remote Operations MIB > > March 2004 Remote Operations MIB submitted to IESG for > > consideration as Draft Standard > > > > Randy Presuhn > > disman WG chair > > > > From disman-admin@ietf.org Tue Feb 17 17:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12997 for ; Tue, 17 Feb 2004 17:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDk7-0007Hf-OB; Tue, 17 Feb 2004 17:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDjk-0007Fj-9j for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12946 for ; Tue, 17 Feb 2004 17:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDjh-0006Zj-00 for disman@ietf.org; Tue, 17 Feb 2004 17:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDir-0006UT-00 for disman@ietf.org; Tue, 17 Feb 2004 17:29:46 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDiI-0006P9-00 for disman@ietf.org; Tue, 17 Feb 2004 17:29:10 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDiH-0002Or-00 for disman@ietf.org; Tue, 17 Feb 2004 14:29:09 -0800 Message-ID: <003101c3f5a5$a59f5f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <200402112046.PAA21506@ietf.org> <2147483647.1076971720@[10.1.1.26]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Begin WG last call on remote operations MIB update Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:30:28 -0800 Hi - I'd like to begin a BRIEF working group last call on the updates to the disman Remote Operations MIBs, currently a proposed standard. This WG last call will end on March 2, 2004, after the face-to-face meeting in Seoul. The current internet draft is at http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt Since there has been no real controversy about the updates, I believe this will be sufficient time for review. However, if anyone committed to reviewing the document needs additional time, please let me know. I would like to hear from *everyone* who reads the draft. I will be soliciting implementation reports, with the objective of being able to recommend that this be advanced to Draft Standard. Randy Presuhn disman WG chair > From: "Juergen Quittek" > To: > Sent: Monday, February 16, 2004 1:48 PM > Subject: Re: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt > > Dear all, > > Below please find the list of changes in the remops I-D > (draft-ietf-disman-remops-mib-v2-01.txt) since the last > version (except a set of pure editorial changes). > > Randy, it looks like we are ready to enter WG last call. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > DISMAN-NSLOOKUP-MIB: > - added value enabled(1) to SYNTAX clause of lookupCtlOperStatus > > DISMAN-PING-MIB: > - correctly considered IPv6 in DESCRIPTION clause of > pingCtlDataSize > - added DEFVAL { {} } to definition of pingCtlTrapGeneration > - extended DESCRIPTION clause of pingResultsTable describing > re-initialization of entries > - changed SYNTAX of pingResultsProbeResponses and > pingResultsSentProbes from Unsigned32 to Gauge32 > > DISMAN-TRACEROUTE-MIB: > - correctly considered IPv6 in DESCRIPTION clause of object > traceRouteCtlDataSize > - clarified DESCRIPTION clause of object > traceRouteResultsLastGoodPath > - changed range of object traceRouteCtlInitialTtl from (0..255) > to (1..255) > - extended DESCRIPTION clause of traceRouteResultsTable > describing re-initialization of entries > - changed SYNTAX of traceRouteResultsTestAttempts and > traceRouteResultsTestSuccesses from Unsigned32 to Gauge32 > > all three: > - replaced references to RFC 2575 by RFC 3415 > - replaced references to RFC 2571 by RFC 3411 > - replaced references to RFC 2851 by RFC 3291 > > > --On 11.02.2004 15:46 h -0500 Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Distributed Management Working Group of the IETF. > > > > Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations > > Author(s) : J. Quittek, K. White > > Filename : draft-ietf-disman-remops-mib-v2-01.txt > > Pages : 76 > > Date : 2004-2-11 > > > > This memo defines Management Information Bases (MIBs) for performing > > remote ping, traceroute and lookup operations at a remote host. When > > managing a network it is useful to be able to initiate and retrieve > > the results of ping or traceroute operations when performed at a > > remote host. A Lookup capability is defined in order to enable > > resolving of either an IP address to an DNS name or an DNS name to an > > IP address at a remote host. > > Currently, there are several enterprise-specific MIBs for performing > > remote ping or traceroute operations. The purpose of this memo is to > > define a standards-based solution to enable interoperability. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-disman-remops-mib-v2-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > From exim@www1.ietf.org Tue Feb 17 17:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13042 for ; Tue, 17 Feb 2004 17:32:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDlT-0007af-8w for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:32:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HMWRAn029176 for disman-archive@odin.ietf.org; Tue, 17 Feb 2004 17:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDlT-0007aV-5m for disman-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13039 for ; Tue, 17 Feb 2004 17:32:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDlQ-0006gc-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:32:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDkW-0006df-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:31:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDk6-0006ac-00 for disman-web-archive@ietf.org; Tue, 17 Feb 2004 17:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDk7-0007Hf-OB; Tue, 17 Feb 2004 17:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDjk-0007Fj-9j for disman@optimus.ietf.org; Tue, 17 Feb 2004 17:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12946 for ; Tue, 17 Feb 2004 17:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDjh-0006Zj-00 for disman@ietf.org; Tue, 17 Feb 2004 17:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDir-0006UT-00 for disman@ietf.org; Tue, 17 Feb 2004 17:29:46 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AtDiI-0006P9-00 for disman@ietf.org; Tue, 17 Feb 2004 17:29:10 -0500 Received: from h-68-164-87-146.snvacaid.dynamic.covad.net ([68.164.87.146] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtDiH-0002Or-00 for disman@ietf.org; Tue, 17 Feb 2004 14:29:09 -0800 Message-ID: <003101c3f5a5$a59f5f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <200402112046.PAA21506@ietf.org> <2147483647.1076971720@[10.1.1.26]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Begin WG last call on remote operations MIB update Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Feb 2004 14:30:28 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - I'd like to begin a BRIEF working group last call on the updates to the disman Remote Operations MIBs, currently a proposed standard. This WG last call will end on March 2, 2004, after the face-to-face meeting in Seoul. The current internet draft is at http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt Since there has been no real controversy about the updates, I believe this will be sufficient time for review. However, if anyone committed to reviewing the document needs additional time, please let me know. I would like to hear from *everyone* who reads the draft. I will be soliciting implementation reports, with the objective of being able to recommend that this be advanced to Draft Standard. Randy Presuhn disman WG chair > From: "Juergen Quittek" > To: > Sent: Monday, February 16, 2004 1:48 PM > Subject: Re: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-01.txt > > Dear all, > > Below please find the list of changes in the remops I-D > (draft-ietf-disman-remops-mib-v2-01.txt) since the last > version (except a set of pure editorial changes). > > Randy, it looks like we are ready to enter WG last call. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > DISMAN-NSLOOKUP-MIB: > - added value enabled(1) to SYNTAX clause of lookupCtlOperStatus > > DISMAN-PING-MIB: > - correctly considered IPv6 in DESCRIPTION clause of > pingCtlDataSize > - added DEFVAL { {} } to definition of pingCtlTrapGeneration > - extended DESCRIPTION clause of pingResultsTable describing > re-initialization of entries > - changed SYNTAX of pingResultsProbeResponses and > pingResultsSentProbes from Unsigned32 to Gauge32 > > DISMAN-TRACEROUTE-MIB: > - correctly considered IPv6 in DESCRIPTION clause of object > traceRouteCtlDataSize > - clarified DESCRIPTION clause of object > traceRouteResultsLastGoodPath > - changed range of object traceRouteCtlInitialTtl from (0..255) > to (1..255) > - extended DESCRIPTION clause of traceRouteResultsTable > describing re-initialization of entries > - changed SYNTAX of traceRouteResultsTestAttempts and > traceRouteResultsTestSuccesses from Unsigned32 to Gauge32 > > all three: > - replaced references to RFC 2575 by RFC 3415 > - replaced references to RFC 2571 by RFC 3411 > - replaced references to RFC 2851 by RFC 3291 > > > --On 11.02.2004 15:46 h -0500 Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Distributed Management Working Group of the IETF. > > > > Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations > > Author(s) : J. Quittek, K. White > > Filename : draft-ietf-disman-remops-mib-v2-01.txt > > Pages : 76 > > Date : 2004-2-11 > > > > This memo defines Management Information Bases (MIBs) for performing > > remote ping, traceroute and lookup operations at a remote host. When > > managing a network it is useful to be able to initiate and retrieve > > the results of ping or traceroute operations when performed at a > > remote host. A Lookup capability is defined in order to enable > > resolving of either an IP address to an DNS name or an DNS name to an > > IP address at a remote host. > > Currently, there are several enterprise-specific MIBs for performing > > remote ping or traceroute operations. The purpose of this memo is to > > define a standards-based solution to enable interoperability. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-disman-remops-mib-v2-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > From disman-admin@ietf.org Wed Feb 18 23:04:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11479 for ; Wed, 18 Feb 2004 23:04:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfPt-0006fJ-A5; Wed, 18 Feb 2004 23:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfPk-0006ep-I6 for disman@optimus.ietf.org; Wed, 18 Feb 2004 23:03:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11440 for ; Wed, 18 Feb 2004 23:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtfPg-0007Pu-00 for disman@ietf.org; Wed, 18 Feb 2004 23:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfNy-0007M4-00 for disman@ietf.org; Wed, 18 Feb 2004 23:02:03 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AtfNI-0007J0-00 for disman@ietf.org; Wed, 18 Feb 2004 23:01:21 -0500 Received: from h-68-165-64-27.snvacaid.dynamic.covad.net ([68.165.64.27] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtfNI-0005Cc-00 for disman@ietf.org; Wed, 18 Feb 2004 20:01:20 -0800 Message-ID: <00a801c3f69d$3848cf60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: Jabber at IETF 59? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Feb 2004 20:02:40 -0800 Hi - Would some brave soul be willing to serve as a jabber scribe at the disman session in Seoul? Randy > From: "Melinda Shore" > To: > Cc: > Sent: Wednesday, February 18, 2004 5:32 AM > Subject: Re: Jabber at IETF 59? > > On Wednesday, February 18, 2004, at 12:28 AM, john.loughney@nokia.com > wrote: > > Will there be Jabber services offered at IETF 59? Some folks want > > the possibility to participate remotely. > > Yes - the wg chatrooms at ietf.xmpp.org are still up and running. I'm > hopeful that chairs will make an extra super-duper all-out effort to get > jabber scribes for this meeting. > > Melinda From exim@www1.ietf.org Wed Feb 18 23:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11623 for ; Wed, 18 Feb 2004 23:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfSu-0007KJ-Uj for disman-archive@odin.ietf.org; Wed, 18 Feb 2004 23:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J478V4028159 for disman-archive@odin.ietf.org; Wed, 18 Feb 2004 23:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfSt-0007Jy-MJ for disman-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 23:07:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11595 for ; Wed, 18 Feb 2004 23:07:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtfSo-0007a5-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:07:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfRH-0007V5-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:05:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtfPw-0007R2-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfPt-0006fJ-A5; Wed, 18 Feb 2004 23:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtfPk-0006ep-I6 for disman@optimus.ietf.org; Wed, 18 Feb 2004 23:03:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11440 for ; Wed, 18 Feb 2004 23:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtfPg-0007Pu-00 for disman@ietf.org; Wed, 18 Feb 2004 23:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfNy-0007M4-00 for disman@ietf.org; Wed, 18 Feb 2004 23:02:03 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AtfNI-0007J0-00 for disman@ietf.org; Wed, 18 Feb 2004 23:01:21 -0500 Received: from h-68-165-64-27.snvacaid.dynamic.covad.net ([68.165.64.27] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtfNI-0005Cc-00 for disman@ietf.org; Wed, 18 Feb 2004 20:01:20 -0800 Message-ID: <00a801c3f69d$3848cf60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Jabber at IETF 59? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Feb 2004 20:02:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - Would some brave soul be willing to serve as a jabber scribe at the disman session in Seoul? Randy > From: "Melinda Shore" > To: > Cc: > Sent: Wednesday, February 18, 2004 5:32 AM > Subject: Re: Jabber at IETF 59? > > On Wednesday, February 18, 2004, at 12:28 AM, john.loughney@nokia.com > wrote: > > Will there be Jabber services offered at IETF 59? Some folks want > > the possibility to participate remotely. > > Yes - the wg chatrooms at ietf.xmpp.org are still up and running. I'm > hopeful that chairs will make an extra super-duper all-out effort to get > jabber scribes for this meeting. > > Melinda From disman-admin@ietf.org Wed Feb 18 23:20:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12132 for ; Wed, 18 Feb 2004 23:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtffN-0001AD-8k; Wed, 18 Feb 2004 23:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtffD-00019C-BD for disman@optimus.ietf.org; Wed, 18 Feb 2004 23:19:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12091 for ; Wed, 18 Feb 2004 23:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtffB-0000Xb-00 for disman@ietf.org; Wed, 18 Feb 2004 23:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfeD-0000UI-00 for disman@ietf.org; Wed, 18 Feb 2004 23:18:50 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AtfdN-0000RJ-00 for disman@ietf.org; Wed, 18 Feb 2004 23:17:58 -0500 Received: from h-68-165-64-27.snvacaid.dynamic.covad.net ([68.165.64.27] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtfdO-0001AK-00 for disman@ietf.org; Wed, 18 Feb 2004 20:17:58 -0800 Message-ID: <016701c3f69f$8b32c8a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Fw: I-D ACTION:draft-glenn-mo-aggr-mib-04.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Feb 2004 20:19:18 -0800 Hi - Although this is not a disman work item, it has received some discussion on the WG mailing list and at our meetings. As we consider whether to {update / extend / refine / forget about} the disman expression MIB, this document seems of interest in that it examines other dimensions of that problem space. I've not seen any signs of support that would justify taking on this work - I'm just pointing it out as potentially interesting food for thought. Randy > From: > To: > Sent: Wednesday, February 18, 2004 6:57 AM > Subject: I-D ACTION:draft-glenn-mo-aggr-mib-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Managed Object Aggregation MIB > Author(s) : G. Keeni > Filename : draft-glenn-mo-aggr-mib-04.txt > Pages : 34 > Date : 2004-2-18 > > This memo defines a portion of the Management Information Base (MIB), > the AggrMIB, for use with network management protocols in the Internet > community. The AggrMIB is used to configure an agent to aggregate > the values of a (user) specified set of MO instances and to service > queries related to the aggregated MO instances. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-glenn-mo-aggr-mib-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-glenn-mo-aggr-mib-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-glenn-mo-aggr-mib-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From exim@www1.ietf.org Wed Feb 18 23:22:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12244 for ; Wed, 18 Feb 2004 23:22:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atfh7-0001Vd-Jk for disman-archive@odin.ietf.org; Wed, 18 Feb 2004 23:21:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J4LnXa005801 for disman-archive@odin.ietf.org; Wed, 18 Feb 2004 23:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atfh7-0001VO-Eb for disman-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 23:21:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12230 for ; Wed, 18 Feb 2004 23:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atfh5-0000fw-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfgF-0000dA-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:20:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtffM-0000ZJ-00 for disman-web-archive@ietf.org; Wed, 18 Feb 2004 23:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtffN-0001AD-8k; Wed, 18 Feb 2004 23:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtffD-00019C-BD for disman@optimus.ietf.org; Wed, 18 Feb 2004 23:19:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12091 for ; Wed, 18 Feb 2004 23:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtffB-0000Xb-00 for disman@ietf.org; Wed, 18 Feb 2004 23:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtfeD-0000UI-00 for disman@ietf.org; Wed, 18 Feb 2004 23:18:50 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AtfdN-0000RJ-00 for disman@ietf.org; Wed, 18 Feb 2004 23:17:58 -0500 Received: from h-68-165-64-27.snvacaid.dynamic.covad.net ([68.165.64.27] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AtfdO-0001AK-00 for disman@ietf.org; Wed, 18 Feb 2004 20:17:58 -0800 Message-ID: <016701c3f69f$8b32c8a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-glenn-mo-aggr-mib-04.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Feb 2004 20:19:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - Although this is not a disman work item, it has received some discussion on the WG mailing list and at our meetings. As we consider whether to {update / extend / refine / forget about} the disman expression MIB, this document seems of interest in that it examines other dimensions of that problem space. I've not seen any signs of support that would justify taking on this work - I'm just pointing it out as potentially interesting food for thought. Randy > From: > To: > Sent: Wednesday, February 18, 2004 6:57 AM > Subject: I-D ACTION:draft-glenn-mo-aggr-mib-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Managed Object Aggregation MIB > Author(s) : G. Keeni > Filename : draft-glenn-mo-aggr-mib-04.txt > Pages : 34 > Date : 2004-2-18 > > This memo defines a portion of the Management Information Base (MIB), > the AggrMIB, for use with network management protocols in the Internet > community. The AggrMIB is used to configure an agent to aggregate > the values of a (user) specified set of MO instances and to service > queries related to the aggregated MO instances. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-glenn-mo-aggr-mib-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-glenn-mo-aggr-mib-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-glenn-mo-aggr-mib-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From disman-admin@ietf.org Mon Feb 23 23:22:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12342 for ; Mon, 23 Feb 2004 23:22:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU53-0008Ml-CT; Mon, 23 Feb 2004 23:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU4h-0008IT-SN for disman@optimus.ietf.org; Mon, 23 Feb 2004 23:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12259 for ; Mon, 23 Feb 2004 23:21:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvU4f-0002dE-00 for disman@ietf.org; Mon, 23 Feb 2004 23:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU3h-0002VP-00 for disman@ietf.org; Mon, 23 Feb 2004 23:20:37 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AvU2h-0002NB-00; Mon, 23 Feb 2004 23:19:35 -0500 Received: from h-68-164-80-173.snvacaid.dynamic.covad.net ([68.164.80.173] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvU2V-0003Uo-00; Mon, 23 Feb 2004 20:19:23 -0800 Message-ID: <008201c3fa8d$98976fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , Cc: , , "Disman \(E-mail\)" References: <6F53CD2F0BBDF446AAA318921B68E5B5027B9214@MAILSRV5.itu.ch> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Disman] Re: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 20:20:54 -0800 Hi - As chair of the IETF disman WG, I'd like to thank you for sending the liaison statement. I will forward a copy to the disman WG mailing list, and will also post a plain-text summary. Randy Presuhn > From: > To: ; > Cc: ; > Sent: Monday, February 23, 2004 8:43 AM > Subject: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause > > > Please find enclosed a liaison statement from ITU-T SG 13 meeting (Geneva, > 3-12 February 2004) addressed to the IETF DISMAN WG on Reply to the Liaison > on structured probable cause. > > Best regards > > > Georges Sebek > ITU-T SG 13 Secretariat > > From exim@www1.ietf.org Mon Feb 23 23:24:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12436 for ; Mon, 23 Feb 2004 23:24:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU6h-0008SK-Kz for disman-archive@odin.ietf.org; Mon, 23 Feb 2004 23:23:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O4NhTs032503 for disman-archive@odin.ietf.org; Mon, 23 Feb 2004 23:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU6h-0008SA-DT for disman-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 23:23:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12421 for ; Mon, 23 Feb 2004 23:23:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvU6f-0002qL-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:23:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU5q-0002mT-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:22:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvU56-0002hE-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU53-0008Ml-CT; Mon, 23 Feb 2004 23:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU4h-0008IT-SN for disman@optimus.ietf.org; Mon, 23 Feb 2004 23:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12259 for ; Mon, 23 Feb 2004 23:21:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvU4f-0002dE-00 for disman@ietf.org; Mon, 23 Feb 2004 23:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU3h-0002VP-00 for disman@ietf.org; Mon, 23 Feb 2004 23:20:37 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AvU2h-0002NB-00; Mon, 23 Feb 2004 23:19:35 -0500 Received: from h-68-164-80-173.snvacaid.dynamic.covad.net ([68.164.80.173] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvU2V-0003Uo-00; Mon, 23 Feb 2004 20:19:23 -0800 Message-ID: <008201c3fa8d$98976fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , Cc: , , "Disman \(E-mail\)" References: <6F53CD2F0BBDF446AAA318921B68E5B5027B9214@MAILSRV5.itu.ch> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 20:20:54 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi - As chair of the IETF disman WG, I'd like to thank you for sending the liaison statement. I will forward a copy to the disman WG mailing list, and will also post a plain-text summary. Randy Presuhn > From: > To: ; > Cc: ; > Sent: Monday, February 23, 2004 8:43 AM > Subject: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause > > > Please find enclosed a liaison statement from ITU-T SG 13 meeting (Geneva, > 3-12 February 2004) addressed to the IETF DISMAN WG on Reply to the Liaison > on structured probable cause. > > Best regards > > > Georges Sebek > ITU-T SG 13 Secretariat > > From disman-admin@ietf.org Mon Feb 23 23:26:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12485 for ; Mon, 23 Feb 2004 23:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU8u-0008Up-Po; Mon, 23 Feb 2004 23:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU8d-0008U6-Va for disman@optimus.ietf.org; Mon, 23 Feb 2004 23:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12478 for ; Mon, 23 Feb 2004 23:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvU8b-0002z5-00 for disman@ietf.org; Mon, 23 Feb 2004 23:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU7i-0002vj-00 for disman@ietf.org; Mon, 23 Feb 2004 23:24:51 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AvU6x-0002ro-00 for disman@ietf.org; Mon, 23 Feb 2004 23:23:59 -0500 Received: from h-68-164-80-173.snvacaid.dynamic.covad.net ([68.164.80.173] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvU6v-0004PU-00 for disman@ietf.org; Mon, 23 Feb 2004 20:23:57 -0800 Message-ID: <008c01c3fa8e$3bf4b9e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,HTML_30_40, LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_SPAM_ADDR, UPPERCASE_50_75 autolearn=no version=2.60 Subject: [Disman] Fw: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 20:25:29 -0800 Hi - > From: > To: ; > Cc: ; > Sent: Monday, February 23, 2004 8:43 AM > Subject: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause > > Please find enclosed a liaison statement from ITU-T SG 13 meeting (Geneva, > 3-12 February 2004) addressed to the IETF DISMAN WG on Reply to the Liaison > on structured probable cause. > > Best regards > > > Georges Sebek > ITU-T SG 13 Secretariat > > Here's a plain-text excerpt from the document. The .pdf file is attached to this message. Question(s): 12, 17, 18/4; 3/13 Geneva, 3-12 February 2004 Ref. : TD 34 (PLEN) Source: ITU-T SG 13 (Geneva, 3-12 February 2004) Title: Reply to the Liaison on structured probable cause LIAISON STATEMENT To: SG4; cc: ITU-T SG 11, SG 15, SG 17, ETSI TISPAN WG8, ETSI for forwarding to 3GPP, T1M1, IETF DISMAN WG, TeleManagement Forum Approval: Agreed to at SG 13 meeting For: Information Contact: Hiroshi Ohta NTT Japan Tel: +81 422 59 3617 Fax: +81 422 59 3782 Email: ohta.hiroshi@lab.ntt.co.jp Q.3/13 appreciates your information on your recent development of structured probable cause. We appreciate it if you would inform us on information related to this work. begin 666 COM13-LS19.pdf M)5!$1BTQ+C,-)>+CS],-"C(W(# @;V)J#3P\( TO3&EN96%R:7IE9" Q( TO M3R S," -+T@@6R Q,# T(#(S-"!=( TO3" W,34Q." -+T4@-CDQ,C$@#2]. M(#$@#2]4(#F4@-#D-+TEN9F\@,34@,"!2( TO4F]O=" R." P(%(@#2]0 M')E9@TP#24E14] @(" @#3(X(# @;V)J#3P\( TO5'EP92 O0V%T M86QO9R -+U!A9V5S(#$V(# @4B -+T]U=&QI;F5S(#,Q(# @4B -+TYA;65S M(#(Y(# @4B -+T]P96Y!8W1I;VX@6R S," P(%(@+T9I=$@@.#4P(%T@#2]0 M86=E36]D92 O57-E3W5T;&EN97,@#2]*5" R-B P(%(@#2]086=E3&%B96QS M(#$T(# @4B -/CX@#65N9&]B:@TR.2 P(&]B:@T\/" -+T1E09O@ `#`+?##;,-96YD'1'4W1A=&4@/#P@+T=3,2 T-B P(%(@/CX@#2]#;VQO M7!E("]4]-57?+DKTVD[F@ MIJOK_E5U]9=DNLRWRC:OR@O[G\DOI,/3.CSF1D&( M4I*K"?%R7_'2*M("8%5M)%0UV $+K+0H[,""ZMD.661!^RIMG[D6;' WM:<< MUZVL\U3M%C;:$UJ&LVWI3/9J1TQ8<@UMI58H(V_TD<+PY4U50M.FQ*#EDWA9 MMD8-[7S DU'==$\_9$9G=R(7R74+U- 98T"+ MA$Q]C!N-1,L4&$.DM7W=I`>LJZS8V)]WH*@.MQ%'B/533B]]E2)@,K= /2 >'0^7P M-, />:Q^;U&\;*"L6MC6\DWMR=*06GU&0H=.5\_#[TKD)E49+>"YJHT#K4E8 M7K:R7*-?=!RV7;VM&GD&3UV+9\:*>@9RN9;;NEIWBI(1)C6WHJ-R1!CTBE0$ MO)@)9X?176Q=[?PVK5NR6=N#>DM<(>;2/D>&^R"*NQR)7D[W5%"2M#THX#U7 M80BMJC,1"C$B::<6[6M5Y_]1IW4MN IT3"N=)Q,..9#E;@019TX$#O,BF*J? MM9P\_XP6!8;FQ3X+@C'5]WSFBQ.LGQ*-3H<%AN1QYHU)+@;K!-)9"'V?Q89% M=4L1]U# )JN@L+"G/B)R21_72N8/RYE9VE.!L%S<&=+,IO9V`\G\9GYY=WO[ M76\OC8#+GFUQ9PCJ/'SO#_1RH&_*IO%SE\61-EVM/.$RLEPPIW>6(!R0X=J' M4/F--B '_!=N5L!C_,XI$(C&WR?HM:\D!FA"I(,7.A[S! K,\$I9;#A<59-O M%.+A>N F@F@8%YB/'8)*C.]N^=5GQ!WG!"74U<;$H+ 1<'6 M+JC+Q>4,0[A4XDP[#'W2,!W:K5IR;AIB,EM>S1ZN%O^P><@XYHF,LI20U?PR MN7N @VOP!%B".-JWC>_ XGJ]KN]7?[?I*K#@?OZ S<=#`'&$R9W>O<)?,.G" M<>CWV.)3H1<(N)\F'B]]++#0"5GL#)EWXB'S*O[S\J7(FU>HRN)#I4(PSOV8 M8N6'L;?7]*P[O!3R,BTNP+"I:MDE6D$C"#S&1UC3.3$CQ;=.-KI/6H]6\VA? M'$83)7A8NJ3/=.S?+"[.@(?X/SKW_@+N.>(4L^*[CF]=RU*^I6?@3E']5_E4 M=VG]00'S^F[JN\S#;$08#<(@Q81#8=T">S!^ D\]"5 M1&'"K ?YS. "@P^HZ]&ZOYDO'VU=HSQ@CJNT!O[^1&&MJJ[.Y$5?M4=SN5]O MA$-$'UY\TP16U]1['C_)IK%A\&*JA),MP0ZB?.@J2=X6\F+?'!7W81+0/09[ MTKZ)XM#$![DM/G \I($5;O)439AJR*R[K.UJ'$=Q*'E*GPH)64ICT+ZE$2$, MJXI&KK[O!'TKH!75Q`%T7PN$X-OTYXC@2(_@$ZARW O,*^IO_64AS7V9,18B$I&<9( M/G2XP"!_3I&-K30WAOB.5:'[[!5C81,0,2!_+=(G5K8MRRJF]GX0\KBU/:Q] M= *#?*KV-?5X[6N:P*")<>V[OH>3X7%6ER:_@1;CO?YIU_!(E7-\PG,.[HT1 M-$RFOC%ULZ=8-3++\>'8P =>*_@J,^CD!IWX3Q'P&+X.82W?9%%M]0G:P!?= MR=[,`'ZU8WI7TO@<6V,`>*/F82:TP1AZE.;/I!C>JZY8#V;A^[-KR*C1CC:T ME@5RKO7=D3?(6/^+C32:-FQ"$$ GQ:A*YB7A%S&A%L"22$(]H/)9W MJ:"M8!I#4Z_.4*&FZ6JN>@5%BJE.&T*5L; (4A,E96:5&I5[YDO,FK9S_G76 MVH]___O[7]^&`&B,-Z"1//+W8>&3AJ4<`K:6<34I(R<]]UK-G.[ IB! OLV8 M-]>1EE==Q;WK@)?7Y-PI.9\FYH1SS#7SRI09"RP)X/,9YT'9.7,7C/NG=S/.*X%6(3->RTB7#_?,`%Y_ MRGEH3OJ"7)]CLH%XME/?,3,])VM]VCH;L"6 >-[*?6W.7.+FM_EIW7[N[*S< MZ06C*H#.7D!3M_D'M#>'U_]M]$:T!JQ;_(G5JO8,M9Z;T^'T3+,JM1^M!;WX M__L%8R6"4(U"G, $?*TTXJ4[4F!(`%I"25\,$U_XPQ1OA,")84A&B)[R4!RR48([$-'9"$%HC%>FR7P=8]+,=%F8IBGMXC,>B$X9)HW<0H)%N' M> ?0'^]AB_B@/7>\Q6G=H(4Y> M'J MJY%@_8 85!MB93.B?NA%F8D/6/T0-GN"IA,A46:JB59X9 M7KO<.H".]#"&-H9@#&;@8^DH,3*.9[>I^6JI6J8/ZNM&B/'0BK).P88PZN;A M(_IU#A?Q=^8K04;(9;54[S/?M!83;QBRZ<5*[,)A/!93&D@C>4D&XV-4]Z+G@J&?4Z.STP@C(!D[&(L2ZEG,)5 MT=):VM'20!E*2Q-ELBR1`GE7=LIN.2AGY+SA#2L^&G&LKNGD M@I4HP+MXGS'?C[.XQ+J[62]5>,0<_"PV5E-+(NH@3NDDH?1NC*3(?,F7#5(D M7\@MJ9+G"JJ1ZD#IHGJKH6J\RE,/U'/MK9TZ5B_0[^EO]#-CH1E.*38/F(]L M5?9@K_+G6VMO>."9ZBGT;+4B68LV5IX?>RX"@UAS0YGE3,RBS,8\S&>,%C'B MVU@Y)?@41_$ERAG["EPC0]7AK9-[S,2/J(5'%/-IBA?E!?8>S$PG&&>,"/4\T MAY@3S0QSC;G#W&F>-+\RJTS+ML'V@:W45FWWMO>V)]M'VU?;_V(_:K]NM[PZ ML9Y&$'UG_/)MD'%&F"H02Y72[^-JKOY:;93B7VG S">"3$Q4I?J8>G])@;ZM M/U9Y@.&JWQY(%BO'9R@W+QK-S6J<4:WP`_EPHTY7Q]5F%2"]=7]CE5%.UEE( MG#O53657)=2XSVQ,Q"O2$O\R7L5#QK_"S&=,$]0-*59?J*&LY"LH4D>Q&=N1 M)7V(+A,'\ SKY;!VR$'6W3*K1\S=%A&66=49^L^ MN_Z6K,(U_8RU_ZHD21AVXPZS?DDBI+WA,5KC`IFO';:R:O^!?>S!KXP@=M!C M'-812#4JF?.PVK]Y7.9J%BFT[^>N4?6L3$Y>!.YJHY'?5#"2B"+U'?T M?9R5#HSB1=M5;,$[.**;(UCO4F\H2W]I./!'5.KAO/5U\E,;B:"E'$RE'P[K MKJ>(%J8A"E$R25+AXDXBVEDY1+Z;7!1CC;/FV=M/;& 7;N56;R- M'_EJ."2#L?@>/['6![%[0MD_L421R#=LAAJKCR%.6B&7'!A"WA[$&*0RDW-H M)0]KV4^[^(:0;O]Z*=87B%69^#W63'%;*/*YEHARZ, MTS/QD2@UE_?5\6PA>;:,F*[C+IG#JL<5*OW%Q>QEX*>Z7N8-O9$L>_DF'T1? MOI0N78[O$,37=1![M(CGTE@;/FB+ON8=40CU)%E1:JH^)BWX&OJPJD;S91\H MLXBB"?VH17,9B4C/8%HK)I[?0 MKETZAW3J&!SD[!#H:-^N;9O6K5H&^+=H_I)?LZ:^37P:-VKHW<#+;C,-K02A M\[8YK;Z.A,3.Q6-W>F7$GZKXW:DU:LY?JL90\W)_Z<9 M\T(SYG^:XNL8@ '=0AWQ3H?[K,OI*)7442D.<<5G>W4*QU[LAAPTY* M_\M2/U#^\?WV*G@U)BAW*ZF9[N11*?&NUH'_8;U*8Z.Z MKO!YR[P9TP&/3+7 M[]QY;Q@;J]"JB,_GWG/N@W:1 I9D>%$,H(K8QM8CI M%MOHV_DT=%0?" T;?4,^:H\'O9V!SK;-45-IB_$>&4'L6V7._.Y[LVYWL7AF M)'HXU9JC&-6SMNO<-8S#NGFZ,9IJ]?/?6 QK8*Z<5Q,W:K!U'X+8T*QC-_E0 M+&I*A["ESB?A4R7.MR50S9KX#MU,"U0&MAD[XKB:;,.DIGW^P>SL\#GK'TV1HMS_<9<9-YDJ0:[$[;# ;-HB*FB#N" M.X6/7Q;]Y<6AO4/RLX%=/AT"X:,-B&U;K'P1PN_W\P4?'0I3.SIF3V,TT=>I M/6>0PHN",5..LV78L61M9$N/8TE.CP? Y)>(?Z!DF9[\Y/]TWXSIU=O*36G& M?S!O2=@;F@,-C:U1O=J(V[%M:!G72]A+DS:[94Z/1)48_KBM8F_L2E^_SU.&K(^YEE"W)YFNVF6!\?W M*\;UQ[GG-10XK.;+#2VMAC%EG*T&&<@P:@)ZC1$WVH:LGO: [@L8Y_"Y4F#L MJHX[-SIDG3^:8];TQ7"(;5(YV"I3Y4! ZFT<"$N]S:W1<_A=I_>V1 =E28[$ M*V,#\V&+GM.)PD(K)[7RC?QT9RX^FS:[7R>?:1$'(1B '[4+U75JHE5$S$%3FB+$S MT%X(6[[[&!5BW!ST-V#<,I;HYZO=M /V>K07\YHX1R;D-" 3>C_VO\(^0T;4 M7]"3*EDWT<['VILQ-Z@["NT@8K.&]>+L MW50`K,.^&9"+@ S8LY0">EZZ1,]"?D4M)*\X-\:([OJ<*A@>LK[ N=X#9JB=E([^=?C9Z'J)EG,?F"; WZDGX=.GM ZVH/84 M+81^F?P`.+:5%LH_IU(MC])POE:,K0*Z!?>8"YW4@ONP(*>J[U,V;/.!?-SA M63M./HX-^GR_.)_U$?RX@3&-0#-S2_"KDWS8GV/.=Y\A;1H#-ZWKL'T5^#K. M50$\"/LWP>&8F(/Y6+?"YF%A4@+,O10L8!\<\#TY2'"$LH#[;!0`EX"#P!/ M+F KC\&Z11C//.G"FM7HSV-^,#>P%M]#O\%;X'YR-QBSCB2^2UX?T9ZA<_)=YXB)-)OS/YS?AR*0_>)_\1EBJ0\E7D"\`7A]R;0J/QG%N$BX)Z?!U$AFTN20D\QEY[4U;OF7+6Y A<+* M:P/G9ZX/G*.!VB1?'5X64 BRP>'G1)[:_%QG\_-.7MZ62R$C=FWAW)W)[Q1[ MN>TWNYGS(^,GRN3\?GH:9WA#Y.'+F)MXUW.!(!""?9^=1Y"' MK8,B'W9:>]PUUAZUV-JCE5F]VH>0VZR]\GYK9[*FJO2 G0:Y[TKJA/$$K1-VLI2U*G,IXKC)(Z:Y' MR>_Z,VK9?NMCL1[7*TC6L?_:5EK%N<"U4]3>'78^#O'=>S3R>E0J$&,N(S>- M4B:?1<2@GN:)./#<1XEX+?=UFJN6B3CH##'G'^3E>'",QL4B49OKQ9JC(I]- M$VN/8L\_T":&-I?JW6\A9_)>.RF>)G->M*[9-;L.];1.>0[?05XBP?_+Y%5* M* >ULL;&:O7[B'DWQIZTORM8(N^+>G\+N0H<<1VA)O$]P;8?XKOG55K-4/MI MOK82^;$"N7\/Y6IS$*,6"@A>KTGL#7V=^#[A.L7?"?Q>5I!7BV,^WH7P@>L- MKUTH8EL'CJ[R3$%M::=TN5^2P+U<\>W7CWOOE_@[ZO$4_-C6Y2:DY)>OB?K* MMEOR1?FL?-'J$O6^A$+*;U ?/T*.?P5\F$TKY XJE0TJ5=/P;?80VM^C4N77 MP''$8+\UJLY$#J^"_F? 8! MJZ]!C@+_Q+PO49_R`O5I/CHD=UC'Q?J,_6-_9_!Z/ ]8Y$CVU<&D/O^2O)/Z M6W7;SZ2/D_C':_"Z8AZ/*;%&B:R_`'D).=8H'Z,SP&GY3H$-@*H>H%.0Q9 ?`"/ 2> "<$M=CE@"])M.G0OV;=3ZU[UI"90PY9)UGW#'^%"U3OX-< MN]@ZSU#V(C\`VC2\6P_R_E^AWX1Y$_JN!?2T^@C=?S=_[@;IC[18Q#"!\+V< M\5[!WVA)Y"G7)OB?H>X5^POV!*P\J3:1,U*/]$,/I3[S7N_6Q[O94.#QPX%Y"889Z M%>.!B7U/S[^YK];8-J\R?"Z.$\?Y;"=ITRZ]?)[M=JF;U-Z7K"E!))][&67@ M-JTBL;*IR8\1:1LTH4B@E6YVAQ @5:NE(492M(9UT#(&3<\WJ-LLU#^@&U13 ML@HIZ3::T@M;QY:$LFSTEO"<8SO+G(;0P?X@ZWF?]SWG/1>?<[[SOH>8$G9Y MQBJGVY/CSH0F4H-UNMO6A+FHP#?C+K-RK]>8LJZWBO7E:=D6]5>[4_VG.?N#]H2V^\07RX0 M'_3R7)X\WYG[XB-G?E/ZO$_:\BZYF./SX3?QX;>!;V6F/O^?@&_GC\!+P(E/ M=!R<(4T$'(C1LBUXX1<3T&_#NX'=R%&E(-_#810 M]D/P&O!\X%74?8 X@I1]O-563I[*Y)6H&]\(OR> 9+J?\3+H5>C_;\!^X/LH MOPBT`EY ^MV3P7;4OY%N._Y-\/=@7P5_`SB)LLWP>13Z\\#]T(>!?P)/`Z%T M?]?@=^V(S$=N\@[]W_(,[X__E-/O#1+,36]->?O,],;Y"./\.*8"N;0?.:5/YM$REY7YL\P?LZS>;;@/,N.73F&7 MS%]E[BSS5[!ZW^5=(HU8YU63\\K&D2EW*ZLD7P;*,L"]1]; YQ3.VB@]2-ST MX,18.@T3]2^ MU1CY,6+JQ@P>S$&VO#6#W/I0!CZ)W%A\JY@M=G_L6#Y#C)X:I_];.QOGLY@M M+\W-`V:S9^OO5NWRE\YER?&]9Y'QWMPI\ MIZMM;1.GL]]K=@XYWW'AY/>6L>TQLA98EV7<'Q6X1Y8!NS/O+C]TQ+.)'> M M!=>)4?!+8L!&C)WXC;QSP%MD'7@W?0&Y-*(L[._ SL==+'WOS6#+;.B!P0[UQ^86(,?8W-E O. MQ'CG;9?O/=ANV.YCI&DB9>/6NG6&F00O7Z%85"PSCLH*4;[0Z+5QUD'N(#H* MJ"A;H&J(6+TZHZQ(8;S_<]_-'R#)4_Y3OP G0^4'^&%F@ MW$X+5WJ$9ZY M1B^_Q!\F<^!U`5[S=',**B69&DN(Q5Q(,I3K/AE MK/AE-=I[UM)5!HDLY;M)&&!8U//0SD/S\&%HP]BF86S-,+9F&+,81F9+^+NH M>1<^(7Z&M//720+8!]V&+A\16,&C2@E4&$?YHWPG5L+3@[6C*'W,KM5[,]:DY?]:"LJF'?QZ'9"/? M(![0,<%-`HUE[09K59T1[N$;U!_>('1_NEB4WJ:4NX4C?7C66(7%R!-H 6(`UU "A@%\DD?K\(X5? .0\:!;F (L&%# M*C&/2M25<"^Y44"(3F*LPZRC,1*C,1;C,5LL+^:)%1>8=RVI-,R'I%@A105$ M;8NCW1%W\+##=#0ZN,?A=;#D1$KDUU6#S!)[7?5KT;>C5Z.\I#9A3^2SOD@1 M+29#P C 21_UP/+ \IC?Y7WU0_4C];PO.A0=B?*^,T-G1L[POJJAJI$J;D87 MU!FUS;2-QN@>:M-IB#;0C=36S-MXC._A-IV'> /.@JW%V>Z,.WG8:3H;G=SC M]#I9PMGE[':FG/W.O&Y[RMYO/VL?M>]%C,^0^8 C@2.?VD@:@35FZ]&![(4W6:=U1:<23K%,L MQ44(\J5I<9H6*K)N*S>:(V[6B2X[T64G.I&6#C1(:R+%.L1:Z=LA/I.FNNJA M2"U"I9Q*!SD$,&3<'>A!:B'(!J4=4C[N2;L;\JS2VB&[)MLU*TV'S+;EK!._ M#FANM@.E.TPG(V5E2$M*B@M*DNR8>+!$3[(71(4'9*5)2(J4,HZUU^BPDK]2 M^%!QNUGNTR[ZM#_[M",^[3F?]J1/N]^G;?)I7_#)KBJ(EVALD91T MJY(+S7E>[;I7^XM7.^G57O9J/_%J6[Q:G1?N]#*"ID9_K.132MYUI$;3:[1% M-=HQAIN)WB?+Z!+00A&-@!:(Z&90N8AN!Y6* MZ)-ZQ,'<]# R$IVYZ.$"R44BN O5SC05B.!64)X(?DI/TG$1](.NB=9%H*NB M=3'H?=%:`QJ3]"+]!UY5Z(;^7;0^C>[IVZ1"=DO?)$O9+\!)$6V ]Y'TZ$@H MZ^D2% LDC=+M>1'$Y.A!$:P`'1#!`.AG_R*^ZF.;NJ[X/==VWDL\[OGW??>>3GQ(\4CHOBADJA'<5%)O(GB>TIB%L7;BGL?\W>!N%4_ MYXE+E4DE4H'F,27"/!Q4(@TH#B@1+XJ]BN\^BMV*;Y9-W05IP)T-">)1F0XI M"0^:7UE:2)RX5?-VXE4]OZ!$6$IZF),N`X26%A*$;E;800#2JA=9\30BS*=X M7"@ZN_@!Z$E"]5A 7/#V37$!_3[U96";(OY; MSO"@B)^[4=P4_Q$9%O\>R6!9*_X-;^$K-\5/$/K0AT-9+_[),RO^,5$E_M*# M"+E"_(6G7IQV'18S[KOB]4BEF$9BJ<2P>"VA>OB)"Z-\5!K\IXA^>^V.]5UQ!.J"M:[U,-+R;ZQ!YD@ 8_,R"# M=;@OFW!JO?"U/><(36IQ9G)$E@D^OXCR!B3PMZ[7J6*"LQX[5 M)!1X2C:0E$43IN'^0*I-"F>XQ;[46BFMJ>>]#LS M4+!Y(*5S!B!E#I/PEH -P2GZ6@;(EF@&%MF,XQ4I1 W<^"-*>@6P5U:TZIH(NY@![D@0%E M)A"FVT<\:D"/;I\*LS%8VN5"3PD7@Z2;7 A(NYI4\^9ELSMGOIHS7V7F#,"R MW>O*L743EQK!1=V(D?Z/;23P/TR"ZYV']D=#(\[0H#,T@N=@ZM2A45OJZ+#= MGMY_B!GL*8UK<'CG*)-#(ZE#SI%@:K\S:$]W1I]CCC)SIS.8)M'0EF@Z*H\$ ME4ZY,^0<"L:N]QY;._:E6">_B+7VV'.<'6/.UK)8O6//,8\QT!":) M7HJE"IV!E %/9JKKJNMB)KREF:D(U<8ED^W(.D?%'9A<,@FH-CD#9-P6VAW$ M7Q+;^/@$-LQQ,IG+M2UG&)="JAT!XS@:5QLB<4F23DL24K= MT70D$K+M#E9@$7^=U=U2+$DD*1=0D@C&Q%6KA;Y5+?3U>=;FWT7^&GD,Y@A5^IF?(]\,WX-%.1!Y$9Q#Y\\'#FH6:J[D'=3)VF M;8D!"Q4#9+A\3$C)"::60%VMNF[\.RXE);;D_^8`_TE,R[*"+:=7YTGH1?IB MKK0\2.:,$^J4G#:YO('QN;J"$-T*'7[UX9=4X :%Z3PNH^%E"]%IIS6D@--. M`RGC\W335',/ND@^5,,V8I.$)QT+';W"HX[(0@?QXUB8QVY-H\/D,%5C!RNT M9-ZNF9J7=>0IL6NGV&.\+YN@9W1[B9ELDMTGBFX9:9OV/'TK?Y)>RM?!AT13 M^*'!8B@L1&QCL9%CGRP:+D//ROFR`,(VRX%S+'!\+H[1!3R(?\X_MZ:1Q"$. M)7D<'B;!7&HM+7$1DT#HF=$U05?C2^&6^#^S:>C5[:T/=@V16AMQB*K<^N:I5>T+WFC%CU)ZC%_+?I>_E:Y&=!=EAE@3. MOL3*M)&Q*L;71F&AH='2=Q+9/5*)J22?86?QMK;A81)HC:O&:V7LRD;7=-?D MR,'&;#J;J ]U#;R1@J^ &UY0R64-V7O9GVE)U@ZS/TVLR M8)'U]OS&?)I?5G@`(_<*\_'('&$1HX0YP%+ ,8QH._H55O!4N87'\.2E! MC952N?H1L=%2^$3= M+;.X5^+QCHBP$&?[Q6]N?SPW#X\EB$M(V%1LM38WESB\S4VMK5Y3B\OEK.)J MJND[UIZ(N-"ZZJ4-Y>8U]N;U9OA,-_KTRC="JZNKW3U'Z<]V-#CLJV;9BAR+ M?]&\CBN2R*]ED3.6&D>EP]+QDN/6=RQGK>^9W[7>L>CK5OA7T&(>,H!;BA"! M51<./99_@UB-..BO\#WT,2DG/#X5#*86GCT=S"4HZ<RF]6$IV@H[J,IN"6Z3>D5JBEM3B63<92*"VO,U9"I6PI::DL6WT' MHO =PJ[3K#0F/!F+S,4?X49^M&!J;R@KG^L@-K^_?$Z2A(598=;6\Z*/7%4U;!+W-Q4BMEK:D4,-+P:E0\/O#%<_>*? M7S]]:^O+$U_/WL]FW]_8'I <*X7IK1OV3-%)IZ-]HJ/_:V\9+D^^GPR?\K9? M/O+;[._;W?[ZKB+^^Q,#)S_%Q#3C#KF*^2P@!G)!MOD-T R@(5K*Y1?H>$,A MT?(&@UZ?@>VR0* 8+X&>`,?K#: E=V&>Z$@!%>1"'G1\H8%@^4?YNYI\=,S! MH&QKT/JUU*@5_\-UU<]^S[WQG^[[LN_/7Q><[W]G.)][W.5GRZ^?W\3SG@JX(3^ 2$6'N M\T\;Y4'JJ92G"W6F%)&B;A?$?!Z(4E[*[\LZKB>$JSS/-VH3`#DQ)YO(=!)= M"3$']^[+=V^2Y]$_4H@T<;D49/ ME#HC-B,E++\M6M%(+*)%2,JR=_9@1U$1*;JH69%C5DAR$+H`(@%R&,P52A94Q(KBR7_NBW:O;#_VQI8_ M;]G^]H_>J V #-L<:@NG.V.I10!WU)7D$>I!*=%X@PZHMA*3"'6D;0OF62 MER>7,2V79""'0^]=KQ<#@3ASSZ.!<[\K!>YWJ._6;:F_?\FL4Y%7^AM.U3^S M]2O/@DBNA/LTPB]!)$%[Z9 A>*7B.F%8V&[N$\;,7_G/"_3/_&?\$"1-2!BF MF6 YK\:JB9"F>AG 0(_&***L*:BFA*$\;O*";A()(0$3)DRTBD)0% 43F@F8 MYO@@Q_%PF ,6J@R2!KA A5(%P MN1$K]R>T4"C0A<)L=W1 `C$BB'MC8NZ\>5U(S$HCR75V-4B3(DGRX5HB'\M& M!VH+ESWZ(/@H`#Y>VFITSPQ&>W2%@K&!/]T`3^U=Y.2C@L>RO(_]PC7_SN1S MF;C;LA2A20HPBSX#;]5:D1OWWOW0O1)UTR30+A#*W=$S##LG-M58J=G5C];2 M*K3Q19CHO$ Y,J;\)#(1'8]Y-HF;I!%Q1!H77Z(F_2?4WZO7HBRE$/9BY8'8 MJ/)C=2RZ-W;>=;&);;,WQ+=3P_[AZ%C@59[NXD0IJ1&KH0:0R0=+:)MX690X M]X!&<@,R`]:TB4",#-K EJP?7 "==4->_$B)X=DX"]ER.#Q=_K@2/=/855$.<13 1MP4:"F[&^@65(:(R5!2 MV-CQ(_?*5,M_CC[Y=D>Q[^KQT7>&MWYQXJ^U4^>O@557)I[O"^MMM'M3K7GJ MZL'A(Q?.U=[Y^>#X#[=O>@4LG;H"^BYW)]MR6#U1I)XA]S?1Z@!OJ2\RB@IO MXB#@X."P/K AM-XZEIE*N]>+&U%R1#RJO!B@'N-H72,,PZ-KG&'&LCP'C;G1 M*.&16F.\%M>@UNUII\$*&M!/M"P\V]#^$)H,<;]'Q14(6["A72:"0K ]2 ;G MH9*B(I^SR^U!4,^JJ]!,(%2+!=0`&X5]%!?V(=,1(E) #$ JGN98LF$1CE"XYZ'XTS!1G.;PS-$U M.W28"[ZBWU"Y498;?) MN[/CY,&@>YP]2AYE#\F3Y"1+Z<$'Y5)N16Z$=+,DR\)<*>@K'G8=9UYTO<*< M#+I]@*![?;YK'HW6=2UD&$YO1\>'+9I#]0)PS:U1"5W+&":@"!_M)V1!AK+B M!&6%5&E5.2-E0QWI#,CZ?*$,#'DHFJ=[:%A$88(^15^G/Z I'L^)=&?NE'/) M@6U.T>EQUCA;G">=">=YQ^,\+2B#R@&%5"*E',@1O#_NA_[NA![NG*5'G1RS MXJH,H=98&=K:AMM]HV,*U6IAU@'S%72CRT'"^X009F:7>RDIN&=-SAFJH \Q M!$0,:$XTL]!LS)4X)1M.5P>ZWB$1U%A[: >ST3W;!-OVE=?U!^;,[_W=1YW6 MPCO?;UV0C'!>-QNU%[6ZMMC:QN]][9BK-O/>"\_-S-]V.%=[:K!3/_V;6J\E M->QP^P8R^W,',B>=9UE7W>]SMYRW6)ONV^S+*=K0S($L`/\_%.@CJB QEF$:J&!*\IO";?J7YK% MZO/*_ZU8Z]@+&Y#5,<,:O.]EH.M^9=Z#*Y=:O;7'9YJ!ES>E5"3&F04-J+ P M73LRW..;"R\@H-Z:-[IY9N5KNVK]6([W4,+[VJ[QO5&^H4'X;X11G-A?:DV4 MNF)%5M>@841T33*,J*X!P_3JFFB8_^.[^F.;N.[X>^ACB#V,1I(-X@16V3DE:#AA:/'Z.0JBA+LA4C$!/::$/'M*6@X40M&YH@ MJ[8_QB"EIMLJ5#'*NFIEL"ELJSJT36*:FHE)$:(CN>S[;*,&;9JM^[[ON_IGQ3#GQY+)-F:*J9.IARK^DF4#9S/SLY#W4"#G^^<+742*B\6:L'6 MJ(GC_X4KUN +5R"[XE[/HJBO/U2+6C(C6X=WCSV7Q1_:B?\1_JZ;!N $\GA]<21&N",=P][8_AC5VMZ=[VO_(;J"7):2QV545LKJ2VA4&54G MU-?5?ZC_5IFA]IOM5%R(!^)!/L%;+D[@`EP0)9#ES;L7%TU+AYHT&J<8[U M MP\QJ:LXPJPN'BVN0JF@8H;0B!Q5%1OD\0LO46%!58PCG5<41QU&4SU&82EJJ M(O@]"*ULE_DHCJ[V?4#_F:;H:#NI+:\2:ZO]H7;"H+RA<%M[+)[.MI U/UEK MN=E"76RYVD*U1%:V5_$7SNE0=56\],5,YO'94JWH`*29D0R!*20H0F J0162 M#[$UL246/""W7$ [891J3D;*9!IU6BJ-$!J#AC,8/UB@BZ&+3>P/$GE*WH7S MB[/LN(J'J/32SD2$H\-K"TOG.^O^_%UI_K:+?:IDMS8O>SQ-4["8H9;@WSB^ M!EG5I6?GOKX(T#/W,L[WY[IWB,N[+ O'V[+T,XZG=ZU(6<#0D0HLM (YU_'P M64$`7-X]RQ;(4"PS!5Y1.%Y158[M4#TUM(N&076H38;IU]1P3T,;0-_5>47$ MG*JNKNM<53:0GVO&6!5U#S1:1(EA#^?%1#>P> N+V0-])C9Y?UI!,NZ3,9*_ M#/ X8-2@S\\.ET9(`GI)EZQYI*G6!8!P7^>"(9Q_U'G@$H*74IW?DZ,?Y3L/ M7!KE+V&2A37]%Q!:.%/,!'*(X[F5:$0;T@]J!_57T!@WIHWI4VA*9YV:4U_B M3-%&8$G4S5<7GCD;R,$P60P(.2=&?!#S_!@^J9SASR@>!+^"ATN936LV][_! M>X)R%VR]6?0*4A?R- >Z4'7A=F/&!;NXZL*M<[ 'QC^>;1:[:@PK`WIU$\;D MHFT"-#=3(3\I@WIEY*$"4M#(<]BF3IBMP_CBQH=T8^[YY[LU.S[4KV8^O]K5 M,_)O$%9<'OU079O@\9@40S_ MN+AB@!\(C/NFA>G(C>@-95J])7B;I*:82$F,&!65%)\*I(+IJ"]&J*Y(3*@A M1+A%@H2,'@*K'42ID%V8&*&"CU,3[@G/<:;"3E*3S+NN=[V7U6D\S;*4L\GC M]KI](A8ID1'9L.K=&=FI['65F3V1/6J%.R^=5Z?EVQYZ8W-S#CG"N2:O0$?B M@_VU3VW28\.4B]\ &H7>FOD3( M,\B3.F]^@O#F3ASC+3493'HM5S(2E:*4FV,%"\Y)MG#(`Y[H!L_/-%N852BP M.. +6RCJ!)/)=,*W3I5KV02]@H9+4 Y3'K=0<%479HNT4* DH<# 0U47_G[6 M7V"J"Q_#X"(SMN"%V4_9`LHT/IOP?0]*"R>0GV^B="V5]//(!9W#S]=IMI#C M@1F)P)*_6[EB'[./7OD>?A6WO[5M_;X-$[NZ^[?O>-6UA;$'[6NV?NWL) ML[@%'^MY^S7[0_OTY%>7%W'D+_".'B2*IPT8V&E ?Q3:] <7D ;H9PH:0?]F MNK ^B2O2'?&.]HGA7.)1$&8T0+Z!-=5MF"QIY:;<(J 617$'!! #'E['^D=; MPP?#WP=:^\TL*$B9PW%,X64L8GB&ZF.V,A1SP$H^P)=(NVT((<)U9TJUJ[Y. M/+_^BVMD>6T)F&#"/C6V[9;NWW?HT#>H MG?;AP8)A66;[H&.(>%=?._1S0Z+&Y\]3KXQ7OD5.L,_^MNM?@+ P2N)?%;N= M]$!D0-EE.06:\P4>X1X)C+)'N)?YEX4C@=&0;RU>XQLP=ED3;(6O"!.A2>E' MVJGD>]Q[`39,,*01PS0P%FN,?&.4".:ZP$G6X$8,0EZOS\?0+L;-^P1?^'/\ MH\)+W.$`4V;*_-YPV=AC'?%5I,OXLL_[1//;/@RMZ491XOQM=!K,)/HK^IAV M(-J4Q9S?T02WXSEK:5M3%>>G')]UYUQ5_&S13\>O(8_[*:$YDDKOU@DD(6<$ MDBPR>9,R>X/1BT"-R=5*LT);NDYU:K#,E.X06+ZY:,\;9(M,@$D69S;]#9#9 M>6=F=B;3-4,:>P&::ZD.U!X"U#R3U &H$.II=5RF_9?WKTCGT=C^,.7,#'[7?L MP:GM3^[?6!G?L+]W*_/B2YY5R?-GVO ^[,:M^)B]V_ZM?=?>YW+][(3]D7WJ M]1>^XM=&Z(CT?&0PV-*YF/1=N9"/\N^HET+W(OZLIZF"KU^ZD::FL. M`2XX_V&[[&.;..\X?L]S/OOL7F2O=*3&9_'T@($E&HXE&IAY0FME*1+DHC'[LF2:AYK8V!I'-6*" U5K RI]8?!G4 MHE>X$B.^_- M''YZV;? >0,.S.W[;YYT7=IS='->F,ML<@MD$ [ MUROGU+'M$]_%SFQ@_K8A@,B2!7$MRZ)LPH7L2HQ"3K&D#WV6X.X6R[,X]I9GJVM]>=$(ES[ZN":2 M#,G"8"2D##!/L;N9Y]F7(V/*.'N6N:$C"3;E5;//I.&_D>$_'=V;=UE\NG)4]_OOZ1 MN7]]J T_EA*\[8Y@,';_R-"8NFW?Y1,;/W_[H7QR?[W77T-MG^LX_;MG'H[+ MR43@T1W;MKU\^DMOHS,<@<3-.[O7I7K7+7EB](=])V8XZQ)Q,:YJ-YIN*YIN MD3A[F9 0;WEO6L+HS'&.M"AI:.1^*1E2: '!+9/I`:HA+_HX23*+/A;EI5M> M[P._3S!YPX0(.98FA@`N=F,GH,$ MR0$.B_PI0Q/V:9L4*5- MH@](DB#Z>$F*B@D?(37:<8J1>8\'H'=:!QK-*(6((P+H$^8%*+R02FFI0FHH M]:,4E:)9DV""IGPD4HB"Z O)A72"KS57 I7P%)"H3-K"44"MJ" M3)!.$DWA&IE#;B5@;K(F"59"-WS$ND(M0*DTC 1JN!8'1>-"3%R 3Q.F#][6 MXZ,1J1)*!SJ53"GXCKPV5]?V8O^S$ZM#OO@CX$\-V1Y[36?Y#Q?Z]S[MU1ZC M>H*!]N6(-TLA@(B&NKU2^^.//DMKU2?B]'5D)X%H$4'>V MH%HX@4=C`.?P=R*5Y3O=N$%3#G\:^4:*8'S SE#GJ4GCFUS9;.@W[C3NI\:, MX]2X\4UJDINB+AC?X:[:K0NSRUH80-"U1K>+X;+VFFFA'+5-K!31D" "@O:$3Q"V,TX+>`AGKH!O1U^/5Z +=3P_1HS1% M;R2FX5\UKY.^0 /:0EC#3BJY9K% M4I($W%RYN&;9EJY/2P2NX'YJ=0(E2)0I[7K$!-P-[H:.%B0:V)R#`&K\UC:5 M# #4^C9HDFL-GSRX`^"EE;O.!IK:[H=(_XT=P>5[UJ%CIGKN$Y[&=T_,N2EH MJED]NAD<0GW\M?E_DA^3OR*:B0[8K;F,')OH2A_,?,)R8R)\$4 MF**MJ@F,YE\W?#_^@V8#D2_DGW3WYX<]1UWGPD@]KOY4_87Z M6_66.JLR0RI0,5\S&T3T`Q)F#E%O&ES5."T_ MFH=:OC\/\S]Q`5<]_N_"A7#G?#VH5X@VK@VVM5":'$P/4O^@8(K2J +53QFH MNL6+-O#3H'E,'^Z2LGJV5"XI[Q81',M%%$[0L-_#BM7IR"I)]'O4)V443KA* M>8:K:MBP`]_L6=VH9+D;--=AZ^@@B@H8KD[!6U;>QT.BN$FG0\NB]@;9PI$& M%CG;0) )94,VO]U/6$6S'TAR.]GF)[B&&C^P2.BVR)#SXW2##$R5%CHP7GH) M#)>*!+I 22&PLPTB,(20H 6QMF$L8P5$>:>ZBW0.2V&5*VT>3)%0D]U8?4IM M@2O/O%(8F 89CQ9>$O4VA%;F.C<,?_CLV(3'9G'6>.O]+=N["KV6YW--@;IX MRZO'GEJ[_M05>Y>7'HH>FQO7`ER0[UZZ:AQD'U[7 MVI;X-]55']O$><;OO8OO8OOL.W_;L7-GG\]VG/-7DG.^L5^2AJ5 `A4K'REN M&5#6%MHLV0I%;"O0+[I.A0Y-_,$FTDT:T]8I$6$HT#_(-*424R7,)B%6_@!M MT;0QA8(&U:0M8<_[VJR;);_/^[Z^>WWW>Y[G]WN>>)BPR^BC1>XYB/LX?'&]<.<*]K;W!O.^\X_NJSMC8^\J-&J]5@&N7&:"/76+%$_0Q:XY]# M+>?#28\`O:$R*]JM5!OL`)H?AS33_R)#L(.EQ)!FUSK4&+IFM-0;MN>Q",!70?5#L3KVA(*-D>7*(D'?,$BN M&@;5WZ4'RT2"'U06@;(G:)I!2C4G@H%0@.4C;E5AFKQ^!2FNL(("/A@8VA*T MDL;0($Z:0+&:'VK9D8*L<8.O!/.QFWQ<9?F1=6SH:_T[N[7U

K>S??/B:ZN[8=CH.4 PP##<`U7P6 M&7@[SB/>H^JLQ#."RLM"0ZL!6I=VR0Y1=#,.IR%+HJX*"QK257XA+H75<#G, M30.-M2>/^E#6^48&+H'5QP%F6\FK^5I[+@S"B()7J4-@,*FD-@]5.I/.? MW#B,7Y=+L9%:LB"W0D%L3#X@EQ M2N09419WT&E5O"<*8BB:+^397/YWL4MH-^*AG3,F1H$\)TE"],N+$XL30)MT M]A?Y"^/!;\![1&4!:E)H]I.R"7*&)) ,5"GW]PO$UD=4J2DNM&$!?Q=4FR46 M*LUB1S%E?ID^))>*)BWK?0%?AP_=\D8W+_^Q7/0>.X;^*2?#:I4)P^L!/O0I?BHAVZ5R)O&.]5CV9/K7#1>MY](7SN*>%DRBQA187!%S0+)41^GG4'S=(^<>5;$/LLO1BWK;@Y," MBR95`>4)KW$\3F<&,-P$@U3.#R!I0!U@!X9C,MF4Z::,)%F%HGN.LV!OTBS M4:R))%,U61/'DD:&_)\*NQG(;;F*EFV,R!$9!6Z#6(GXW% M?N)O>8D44O5QN3+Q;XB1);IM&+5$[E\V^D%'\TM$;^OZZ<5JS#2V+1F4`8S: M[D6F!*^=`/C@,BK>V(]^W_ZWADI_#+WHU?: M6CK[=I_<9.E+ZSDVA]]Z^KU86]N60N[)$)X<.EIHFWKQW2NE5^=^./[*F=G5 MA7_==ZG%CDUK!T,NQ4^T= W#-'1#I9Y!MRXR_*-[Y^P].9J]ZXJF90W+;LQ5 M=EYVLF'$>'35.Q"XMI:M:7+/JJB,> MC^AJ;([]#.^*M^AJ)AY'8;B5@99-T&(QI]-A:U2MR-KJ]>#8ZK('#WW%].!5 M10\>A&]/+RP*;3"D6F PLC!H.@P0W1XLN\RK'B1Y4-1SU>^09 H%.J0EX:TN*;L&#W4NA M?&H^54UQ9&NVJ]>D%G*'6G@H>JFU.6:F0MG1(S5EAP]$*'!3I5^N5UI :5 $ M$E[[[ZLSDJ=O)=D7@+4 MXGRV8,X$T/$`8@)R@ TG0?B`<=] M4:'D4W,;%.YU!2HO42:A4!OH2TWI]/P_SH!IB+\,$^^-P)V^Q,8_EVDZ0L=>0(68V:YKV.D+$XCA M-&-'_R&[_&/C-LLX[M>^.U_.OK//Y_OA^V'?V7=V[MSKY1*G2=:$<]>NZ<^0 MHBDL*B%C5=G8"B1E(-JB76$=0S":,JV%4J%-95K52JBC6=-L0EJFHG;EGT5L M;!I(6P5!#-: H%6E"27E>5]??XS^\SYGZ_%[]ON\[^?Y?JQFV M_/=;MSZ>>?,A_/$M-O5 _[1I'V;31V>YOK8`JN+W[-W9,P6PLP6PDP/747'5%;<1AUG"KFOV)*"K M?]'#V%W\RGO\RM_DEX#YE;_)+X&H3LPO`?-+^']^0;O=C?7TV&[L3%'\#O/Y M:8*Q=VVN\QL.;-G^;5FT/K-L=2=%R4Z/;+*ZERV"+^;$GJ'!G9O[CB\_MXO@ MJZ3L0"]\H[^P;YG[2B]+X+6+%@F\8#$W@2,Z!_LP3!70_6[J8AI9/)(^'XR8 M842Q29-M"W(YUT?6&R2,SS5M1_ A7]K '[2YFX1!+S1(F.X;<'!TB^ .YXQY M@Z8,UWC0P#_]KO&\01N"I$FTY,YSB&LY&Q)A:AQGP-!PB@YS['_%ZNZ=!-G< M*I[G*%M]YCKVE8N45Z#^1>)FUJ&""%954_,J'9!C\1@=")B9;#JK9)F $)8L M^,J*C8E8IM?W?M`VZ]'?6A MC6BCN(?W3P2:?%.<4/8'IO@I<;_R)GU!"S79B?"$T$Q-L?O#^X6I5! \[=CD M*.@IA-N2S'K&5DKJ`5!'R03HHQXH**ZGB9;W_OZK._>^]_;"W]_JVIB,/'[QU'[^4O('MSZE]\]-C:X2=$'QE'A5#,7QQ6TEC?Y M(!'$2PT][BI2+8@M$Q7%IDF,!F(UL%;8*6%H'Z=4#3IUX)CB%P_7Y.MU1=^O#]8FZKRZU\!N60&MW M\"X_S,^!_?'S2L?0I*=JR6'A81JE0-S3="I/XIFDAH_#*"8JE!57E:36O=1Z M*[5^1^IUV $8OHM>=\(',@*VR#-#4/^\N2*E*B7;S)E6:46J;"%3A:&2KEJH M/5NR**I56B@KKNOJHML8= P\-%--M6DV5_@>EYO*1.X[QH35M)^2GS&.R#]- M'56/ZL>*+\DG]5/%&?DW16E='%%06U#+]F@)#FBBZ\X36HC#3Z)'/ UM6J3> MGA%CT>EDQ_JECTEW0#^H=VT<>?CD`]M_]>C6M9T](P^M,IP^T]VY9GSYQ0U. MJE2B"\D'F3_AGKEO0[[VO;\>./CQ/CW]XMZ^^Z_\9W3UL[B7; 9#]C78`65D M@:\QN3Y.YD7O2 &0(?YM.@.ZO]7;(.X_HW63RYSJW19$$EU+3CBBC8YPAVR: M4\)11\A1*E76^FG!'J%%RU'XB7 M[6D(#^,F0Y4#:BXDC%&AU] XY4/CYPZQ\^QEEH']^)K+464AJ8%*J1BZM]]T MT@T8[)Z\FP@:Y=&UM<%!<\U0(TL&V\ M.5BR.?#>`(G8ZM]@H.R;N/7T#"D*6)MX/(E/)F$M+B2X%X#MI;%GUO2N7;.R M>X@-A7/I.;Y^849AB MT=^WE_8/)[)I/U8[VVXLT.] C3KII]TO$3PV59S)5]`3DA7RA=,-\7 M_R%^(K)EL53I%5=5GN8.&X>+)[E?&K/<*P;GY_WA8#G.#W*;^8#+N3PM=6K4 M,5I#"/<=A/WH\[B9H_O<&'5,JL$-IW;53FG*L8R63F.P0LJA-$K/HL=<0SF6 MN"I)?M-F)=64N-8Y=J6X@[9+5$$LT$2*%R/&S D2G )K]YJG+@#7-\-Z&\]6,A[MN&R MVP8S%+X(3^,WGX8)2(0Y2(1I<#QS:R9[=(',X"K(;4_!"F:C,(@9&"))&,() M+W&4:BSB/U)556BHLS?^/,W+7H0,',] .DDD>:]2?M!3$N3Z54CTJY#EEV^F MB%>PND;BXK5%2KR"@><*-3<4;=3<-@$&^!:" MKBA506' U=MN&_PH54%TE&9O_'L:6 EQX1S&;!9 2MU2-Z/4)!P%S"T`%XH9 MQ"#A=N2[12HX"@;3A?L3X J.AH7E?E=G$M_HH9\3]($GUY3OD?/('!LZ.+)V M0N4*B8*H5W^QOF.@_Y&CU7L/_WC+8"8J)5+,&\MO''RDIYA1RA=_-#)T9+C" M=:+A`P=65SK6#S[:^[D=NTZ7! &:$V7>N$H?\2U1"O4S-S+%3?$T&3B>4F;1 M#)3')\M,_$D:!?)[;6>$HYE9%'%S?FZ&3V>0ST<)?LU/^RNQ1'R/ M+,=<6/P8WD]B3G=JL;G8?(R)*6E,#MA[L+P@!*\1K0?B;DB$U@*75&-I8:S1 MOX3OP242+X'"GZ0F4;0K;A#.=_8D/6AT1PW@1 ^:_> #P137W*-NFQG=%PWM M?>+7]_J6ED_M6'I]6RVW(S&W8T _@CXQ1G^[![.Z<6/!5V=.4#IZ]E6J"&_W M$JC]XGR1;N,S?(7?R/OZ^)]G3V9GL[Y_L?\,TKK+A9T"'L 7Q< 5Q7P?LNA_ M[%=M:%O7&7[.E72D1-:]U];WE7(E6]>2;+F2Y;,VZ+C_6EH9L^U'&R,8@(^N/4O:CM FAV:"0P@89%%(*93 &,[2$ MX>$U+>XVUEK>>^Z]CK>E7=I1]NN>RW/.>^[YT-5YSGG?YZQZF;@093**D0IF M,KJ1:LMD/'0;BL]M\&_THZV-%H"#=]K16>="O'-2\YP$/!<"G@OMSH5LYT*V MZK2: M:6;#EO"BK,5)/%PS6,IXQ9!*QDE#,D*I, MW*L*O7*:)95O!R[:"EZW)3+<3 M)"%_2V8E^9K\ENR2XQE;TJ]=RB:%I%]3AB(MU_^U)D+$DJGIZ3$5HZGGZX]9 M5]N">29.W;['B:.0S=JQW&:];XM9=;V9'VP\,_SK6DM$B36 M@A;F[M8/1 _$9O37FA;T6[I7%Q$ZT*N+/YY-IBI#D>G(/N[RRKZ4UQUET40L M%;5889X4CZCA5.3JZKG:$07)="*9'%74D**H##BHR&3)29G!S=4T.0A5.,MN MM:9*:B*J)%1%9IXD!3VOE_,D_(F_J4]V*S5E1G$I=7F1U6B(&5[2["*3Q&:Z MP5QL1GS9Y8'IBOF%B4RNHM<"2D75'](OZ@NZ6]79*_0_I$VD$UR76]^@$U>P MV%A^C,[=2GRYOAQ;,F.UX*,E6F7-+=4J-9%YMEB0SZB_/NLIQDRC$(.ZQ-1K M5E[_]\(DKRZN8[6P+CY6%Q\KJE-YY M)J-M:&]OCNCMAQL_9Z6G^U(YJ;V=]SV[TB9.>7-CU+5$/)?8PU>40"H@-0FG M_7(PO,W-0FP M^::?E%["2]KOX@&:-5 *-)5DWN1-\7 \D@JK'N9A[A3%EF JU!G.Y8V"7"J- M:O&0IL6;`H$8!9[ 0; 0`C(8:RUI<3G0!&\X5X(A3.;Q:,9BX7E=,1;U<(@B M@(=K\#]47BC?*KM,Q1\(Y2OE:%13PJ6P%"8Z:U%/1TN=:I'7,C-PNG;E,]J2X-+2TU$\U$.!-E2_6LKUBP M*)=MRF$U5C^->2OW^M0!WP"Q7Z\74"<:;=;N(%$2%R\KA$6BD:AUD-F'C;=' MMA?9!^5\S\5C]Y:WL6IQZTCCH[GRCD?VS'^ETC/(F,^GQ!+YOJQTY<).F51X M6RQ[LO%#EOCQO>U=Q+1G\-65B<8G`WL?'-ZZJS:<]?LW=9XGCE;?9Q?D^]B:%)NJJRUMY6M_KQ']VM[ *%!3L=_?Q@/L*+ MGX*_KD.Z;L$=(RS>"=Y)^,5GP[?/PH8_`?YO`8']@/S).I2;ZU"I3\L?@-"O M@,CO@5@2T(X#R<0.@BD%^]$V\QGHWVGA>R+%O(C0,C]-K#E.Q:J:6!@`!C,`T-98+N\CF&?@R\=VQPX<.# @0,'#APX M<.# @0,'#APX<.# @0,'_PL@@4&D$%S"8AJ!XZ[)99?^)I$WB_&1J#"3FZP& M`]EJK=_^P+RNY<8WR3J3)VDAY!XHHHX*MV$Y?/H;[\0!F\3 >Q5&9/KKCU\.&S/ MZ4*<1I3 ME#^!W3A!]5E:V"[<1_91'*)WI>7^XN/_'R/$2O/OX4,,T M.*ZNB M1+L*WK.TBUQ4IT5ES\,#GYLL45LK<5AJH>&WTW_2.T0)-=J'YWUBFC=]O:[3 M-LNT-R[TO#WUH#+PD2_N,WN_\&[OJ"A_^?>"F5N9'-T;.<:]8%5ZQX$!M7TK+RN#6S9$3#A=- MVM(Y<]O[60O2YIVO7'H\9^6]_+5/)JP]4;3QV?*-QS]OVU&Y_<6 M>N!2Z^$WRX[=ZSGY[L_),]O./IA[[NVD\Q^/GK^[^NK[F=>_G+_Y=,^M-\ON M?=]Q[_.O^P]O/'R][_GKW\>OM3W^>?OW[[ON?[]]_ M_OO^[=//O]]___WWYP^0^/__/\,H& 44`( ``P"D)6PPV,-6X"P!I U;&&1'011"$D(`1)"2-@%040% M%$5$A*J5,M9M=$9/19TNKF.M#M9]ZM(#]3#JZ#BT%M>.G1O>=\YCG:Q J-5H&S*6>=0J,P\6F< M5]<9E3@CJ3AWU:F5]3A?Q=FERJA1X_S<%*M1RFH!0.DFNT$I+\?9#V>Z/B=+ M@O,"`,ATU3M<^@X;E T&TZ4DU;I&O5I5;L#SM.3S+F> M0?P+;VT_YU<]"H!X%J_-^K>VTBT`C*\$P/+F6YO+^P`P\;X=OOC.??BF>2DW M&'1AOK[U]?4^:J7&W6*M0&=;464VO_4Q-_ M9=A/-#_7N+ACKP&OV >P+O(`\K<+`.72`%*T#=^!WO0ME9(',O UW^'>_-S/ M"?KW4^$^TZ-6K9J+DV3E8'*COFY^S_19`@*@`B;@`2M@#YR!.Q "?Q "PD$T MB ?)(!WD@ *P%,A!.= `/:@'+: ==($>L!YL`L-@.Q@#N\%^!P_!H_ ^^#!\`CX/7X,GX8?P+ (0&L)''!$A M(D8D2#I2B)0A>J05Z48&D5%D/W(,.8M<02:11\@+E(AR40P5HN%H$IJ+RM$: MM!7M18?17>AA]#1Z!9U"9]#7! ;!EN!%""-("8L(*D(]H8LP2-A)^(APAG"- M,$UX2B02^40!,8281"P@5A";B;W$K<0#Q./$2\2[Q%D2B61%\B)%D-)),I*! MU$7:0MI'^HQTF31->DZFD1W(_N0$8C%H7E MQI*P9*Q6U@CK*.L&:Y;-98O8Z6P-NY>]AWV.?9]#XKAQXCD*3B?G`\XISETN MPG7F2KAR[@KN&/<,=YI'Y EX4EX%KX?W6]X$;\:<8QYHGF?>8#YB_HGY)!_A MN_&E_"I^'_\@_SK_I86=18R%TF*-Q7Z+RQ;/+&TLHRV5EMV6!RRO6;ZTPJSB MK2JM-EB-6]VQ1JT]K3.MZZVW69^Q?F3#LPFWD=MTVQRTN6D+VWK:9MDVVWY@ M>\%VUL[>+M%.9[?%[I3=(WN^?;1]A?V _:?V#QRX#I$.:H"6[[;*;=SMOL!2(!4T"?8*;KLSW*/<:]Q' MW:]Z$#W$'I4>6SV^](0]@SS+/4<\+WK!7L%>:J^M7I>\"=ZAWEKO4>\;0KHP M1E@GW"N<\N'[I/IT^(S[//9U\2WTW>![UO>U7Y!?E=^8WRT11Y0LZA =$WWG M[^DO]Q_QOQK "$@(: LX$O!MH%>@,G!;X)^#N$%I0:N"3@;](S@D6!^\/_A! MB$M(22@A-#:T+?3CT!=AP6&&L(-A?P\7AE>&[PF_OT"P M0+E@;,'="*<(6<2.B,E(++(D\OW(R2C'*%G4:-0WT<[1BNB=T?=B/&(J8O;% M/([UB]7'?A3[3!(F628Y'H?$)<9UQTW$<^)SXX?COTYP2E E[$V820Q*;$X\ MGD1(2DG:D'1#:B>52W=+9Y)#DIN2S=9$U:S MJ69&GZ+?60O5+JD]8N#A/U,7C.[&E<:INLBZD;KG]7GUAQK8#=J&"XV>C6L: M[S4E-/VF&6V6-Y]L<6QI;YE:%K-L1RO46MIZLLVYK;-M>GGB\EWMU/;*]C]U M^'7T=WR_(G_%L4Z[SN6==U=VM MZ/ZBQZ]GL.>'7GGO%VM%:X?6_KBN;-U$7W#?MO7$]=KUUS=$;=C5S^YOZK^[ M,6WCX0%LH'O@^TW%F\X-!@YNWTS=;-P\.93ZSP"D`5O^F+B9))F0F?R::)K5 MFT*;KYP0)ZNGQV?BY_ZH&F@V*%'H;:B)J*6HP:C=J/FI%:D MQZ4XI:FF&J:+IOVG;J?@J%*HQ*DWJ:FJ'*J/JP*K=:OIK%RLT*U$K;BN+:ZA MKQ:OB[ `L'6PZK%@L=:R2[+"LSBSKK0EM)RU$[6*M@&V>;;PMVBWX+A9N-&Y M2KG"NCNZM;LNNZ>\(;R;O16]C[X*OH2^_[]ZO_7 <,#LP6?!X\)?PMO#6,/4 MQ%'$SL5+QHM\IWZ_@-N"]X43AS.)3XMOC8^/KY'/D_.6$Y@WF MENV<[BCNM.] [\SP6/#E\7+Q__*, M\QGSI_0T],+U4/7>]FWV^_>*^!GXJ/DX^\19M MR8V0!)'K4<5HT7@M\6@M]9A%RAB-5D=OM!0U;9C2017U-NK14H\I-:J66>*> M^9)YK';NM_Z[]CEGGW.^O<\^WX$`",5<:&0,&!S7(3M]Q#3@>@Y[^X\I\/F' M/!R5#5S+`&3^F.G37#][+L[CV"7 >6B>RH^U/=1T#-\VRWR"N8-J.L9]@1MBN M1C$3"\?X=-&YC<"7+=CV%/AF^$.5_)[S4^COFN0K&!M[*.IS]I_]\0!16XQVTP'UICP,H1Q^\BQ>0@57HA>/X$#4Q4X["@ALI MV(HHB8!"*L+%QCI^!&&+N8V_].QV.RA5PB2L1U[ M9:(,1ASM-.61-MQYA2E'.&+,,7.>K0VX(2U,&=)H_8 Z:(DY> MU,1Y'3$5E M!I&-4IDMMQ&)+!1;\=82,P%=L1-G))U6/\RTSU??B8FP&(RWH%RU58GVQOA0C2>1W_X./H[7)!ZTEXGF9:FIUG'WE(\4&W4(>TD MCS;HC=%8ADW,QEESG'@^E M'7VX@VZNIUG-K&EVAZ?S&&$.UN,$3I+'9>;]%SR6UL0U];J:8X:;K>8&N51# M!!(P$"-1B.EX%7_@J1[ %_B'/%'5Z7G<.FC/LN^;E]L^>YO3%YP4/&G2S7SF0N @KY;P(!Z=63_C6$T3R,]/ M3,%LS,,2+&>]K,1&;&/;3RT$$&P5?#*X.[@_>-,/,3/*/0BS:DNDB MLES'&MQ"O,]*W(5#^ KGJK@^$"4V*[ZAN%D-'IY:#^DEO8E^,I 82@R7D81/ MLB6/F"-SY0TIDOFR3-ZNPEK&MD7>DUW$)[*7."-7Y >Y(P\4BUAI5G.4:JGB M5!=&FJQZJ0%J$)&K"@F_FJ*F\X1*U4=JCSJKZ^DH':M]>K)>I[?K`_JT_J>E M+(\59W6SAEFY5I%UW#IIG;>>V!&VU\ZS2^P#CL:.>,=0QWC'6L>'CEN."J?# MF>',=LYVGG:::E%4JR\9]T[\^A?G."Y3[?K6#'6%]Z*A]MN+9"@SYE!#]$2] M7']CCY/[VB4798G.UQ/,9IVJ'NM"&:8^E^8ZPD[4X[ 41K:I:^JANFDUD"'J MML18;\DGJE G*T?E)O8IJX%59-\"U#DDJM>D7!W41;K(_!F)=HEKO!6+U)K..EKE:^*,<**MY\@GWE_SY[!?'=7BZ6U/FV5X(9VJY_EOJRF M:AR3/E8+-4IUD6U4W*?2#'=E,OSR-I+D4_E6=D-DJRZ5ONH9GE9 A4IG/D+' M=*2YSBA.XI0);[!+-'2CK7SWU\0DW@#5JF6U#0O MU>24=$!#K*'>/PSNJU1L^[Q=S#K;I#T8A'9X61U%(N_($%J(#]K(&%Z.= M6HO99J[D4/?[43\5=LMXQ$D-JF4XNQ&FFE,+1W/7Q]3_(U3]=+F'5\7% MFU6.&*MR9*GEI3)E47^+B1R\S-9ZK'3LM$]A@(0#EBM8PBJ_A%%\<[[G_HW0 MC?Q&8I/E(6L7E7DR9ZP/IB&)6(BCHO :.7?G/<^PTJB\J\UX1IC/-ZHOW\3# MR#=KD,RS&V2*3#%&FTWF)>1BL-E*_9UN=J 3%MF9:IC=QHJGQAZ6+_@>_4V* MJ=MIN$@]BI*&N$-L)__N]J=88IVC=O8P2\T9-& ^FC-#V7Q%KZ,`]YBW-%V. MYX+]59E)U7Z^4%PMK%TD]1PZ)*E']^>[ M=4WLDM"Y4\?XYSJT;Q?7-M;3IG6KF);142W4IM5S=TB_6XO&Y7X%B*V[5;1@X<07M9 MBCO3%;A;9?>KLM^LLD-I1T9R@LO;,"_%%9 LES>0.CUOB3/ M#8GUH"RD!LT:M +A;G^9A'>7*D.%>Q/+%*J%DE2@D3O%&WC6G5+)(*"CO+Z< M0,; $=Z4QI&1F;&>@"2/<6<'X.X9J-6FR@7)_V*]:F"C.H[PO'WO?D)L?/[A MSV?('8\SLL_&_)2?,P6NV'-\H856 MM?S=[,[L[,[.SNSLD\N8[CK3(Y<)K./=T)Y ;]6@L;??1ZM2X;Q.O;.C/6&J M'4E>HS",=>O-<=_^>/R=+B8OJDOLRI;Z52,V?EV NX:Q*V >:4ID2X/\FTQB M#E.$XBDCCH7WPH6-S0&L)78D$Z:R`PL&>!^\)WMW:_08T07I1EY^=F--1B9;YK'/VOF MD;%Z'H;A+ZE R^S$>:PS'ZA+&;Y:\'VL;[I"/CU@W"2DI''+]) M_'TQQO269_X+?&.+8VMK367L?Q"OL>6-S7IC4ULB$#-2:=\VMHSHV?)Y&5FZ MI=@".-S40O#4$AVAM[PMP0S\NT)Q/;8NU8!4@XUF<5U"]8NDW1)^54Z%^&W/ MS,R=1![/I87<,OX[^SU>!+#D*(&XZ4LUV+_)4<'@?2KU6Y^QEB1WU-)[,FO# M(_OS1_1'F)=GJ#!8*Q>-+6V&,6J$+([+RC#B>B!NI(R.?JM[E1[PZ<: FE 3 MQH98RCG^?NO4'K\9WYO$)M8JM0AM08M[=65W4V]4V=WSY KF,I,[`>Z@OB$K^H17CO!_RC: M"X!\Z'Q91*S5:!>BO0"^*40[#XA![Q;K8'P^;.R$O 1]P6.Q;CZHG\=BS@KU M@N)7#N)-=8%ZM18J@7RT!/;->W;VQ/:S3?\&<;8O&[9]$FRKN&/;%R!RL$:= M)<]J>WJOA\0YVJ >L:ZCK;M+*,;P7*!)V-\G0$3KI F>B=9?8>,2UYLT&WTO M,%Z"YSQ$.]4;%(4L['X%<=-)"\4,"&9;M\5W:*([1 ]CO_ W387M28X]Q,(4 MC&N6^ITT2;M,I6A'&5ZB/V?\!-_@[!M!Z^#WJUZR/L4<=0S,,P"<@?XXK%_# M/N!S5UJ'>S#V"F3/`!L1(Q. <9#OD3$,'=;'.E_A->QS()^,08!C#YCI('T^ M#AYT(/U_7&(L, Z8"_"ZKP`_!QX!7N8QF'C_1CH7/CGL,S! M:]H/Z&.Q@X1GD*IPEIR[K^;0`PS/D+(>\PW"E^7:.7I5TB$Q61M27*X>ZXJK M1SQGPVEGTUPH@[:,*2-;]M_R_Q>(\ZX>>A+MO[F&+$L;HA>Q5_+\79D.!!P* M?A_0#51ZP\H!;Y?2[UE!/L3-#>!I+8KOURC-U09ID39&YET(_!68NT;KHOG0 M4_&E]H*Z@HZZ>^A+ZA#.$6N)\_0\@^<'W9")H]R8^V(L2>K$ZUTHYT"^0V5. M1:P_R+R*6'^4.1FQAFU*$:X-?#_+^D#R;BYTXC43EZ]1N7HS*SYSXC0K/N=# MSY<;EUET---T;-S:4;_./6+X]8'\AX^ M1VU.7@,S@!#DOTC?([B'<=Y<,_=9[>YGK'9UJ=6.??[4O0OTNG523+5Z,S4U M1#/3=UFI4TO93ZYS5):IHR%Z-'V?A;B>:L=0P^TZ6BSKYU]HO.NZO-MF2GLY M#SD':W#O344=_X=U6RNBI]07B%3D)?,1(TTLT[PT1OT3[MREM$D];/U.W2_O MH)@Z3$DUC!R&+GPVWB6HS%5/C= A.1^/`64>V^_6$)]\%S2@C[-R[F4^>_=M MR@>FNJ[B/FK%F.-RKR%YCQ^@*>P'J;L9=05S><)4I D*I\>$I,XW\5Z0_L = MF.6+=&U>R'.ZE\N8+9 ZLZS;WB**,%ROTQRL'Y)K-5"M-T+EKE;KJGQ7%-$C MZEF:KC;00VB7RKC?A1I5@7K9@/H(J!\!PXA-G]V7M5I2ZY:L]]MD/<]SU=!* M^9Y@F9LFN2MH&D/3(4M1M?HZYGD:<74;[3EZV 1^@+T>UGX?II7 M9E,E*-ZC5BEKH0_%:7%"G+:Z^!VHOD]/J#_$^9V@H-J&^OTV:N-\U/"E\-5O M**'^&NW)X!\&MN#MMXD*M +J5"]AW$S(-D#O'.8X"CEC)W0N@KY!"]1?TCIU M$.^#2_Q&H*"V&?1QH)[JE!]3E[A%7>XYJ,GSK=?D_(Q-UMZ6MV7:RC7>QC^?@>:4>QF@:%1!9%X&038>;Q#[J`8Z(]S'V MJ[15.6:=4@Y17+D,'$KC)]0@:2_0A!R;K3P+3--FT\^ [6A7@9X&3MA].@A\ M`.S W&= 3[KQJ< 0BQ'/H. =!@X`OW)DV>"U[L;/ALMOG1K1?PNU!E!N8 \W M1LKDFMMI#M:;HRVP3C'4*Z@A@'L;E7BV4(DZ%?Q)T,OIN_RXY]ZB*?>RYUY0 MWJ7ITHSQ_L%YR[7Y__7?/<+G.\VX'%IPU7 MC+L40+\:_6+'G\XY@?^2Y.><'V*%5++^F>>Z[WZXB0]D0TG#C+Q\"(M M9&B+,![([7O?H7]Q7ZVQ41U7>.;.]=U=ENM=%D.$C1F;]6(;+[%92DQ@&]\E M)L0/Q4Y#@;A2EO(($@_9%-JHJAU#6UI(T]H-)!!(L$-Q$]5VO=S%9'FT6*I( ME"@!5ZK:JE+!M%3]455U'E#1VKC?S-YKS#K(<9K^J5;?^>:<,Z^=.S/GS$," MVD7X+H[7U=-UK8;D"RAYF&NF:(,S!XSJEW&O`J*N;*\C M7@+R[ +**<1B8-2_&'<^,&9='Q#KRHXD_?;WL;]+ZO?!_ SU$E"'?/82*0$_ M`8[8/+J_K?OBKCW_>'*_C^KB+OE+2IT[9^+.V?_T_ V7D7>!MXZW\] M%B78JX 7D#GJ,K)"6XS<!\85\W0;=A'$$<8^)B:B?R=D'T`^KC=D&P[?!-X)MG'\#E"_OU["[N2[8>> M!QZ!#YG9T"G@#>#G0#G:V/W\&/H.\*^@KTSV-83R\#7@^T 5<"C)0\\!PN_" M&+\3^<@GO$,_5[[7^^/3LO7."-L\[@TQ&5[VJ?BN-X?]_2=B^RWQ"2S7P9J_ M-F8^]WKCW,78/ZZQ0"[M%SFER*-%+IN&_%GDCZ,LWFV/2IYN]6.S1\1 D3N+ M_#5M$7+FY#NO:,Q[<(4=-\;>K?1C<@SP`ED6;T6=6WCK7$)L\N!.O8'_=T) MQC81UP#,][+T_W;D@J@#?A]Z-OB&'=/LNW7<'3M!3/N\]+*8*'9_YEA^CQ@]-D[_M[H=YVU,E)>.RP,FT"?J;[)Z:MXQ M:3TE+['U5(SSI^X].Y_)))FC2#EWDX5X6ZB]=W)_>PZIYWCTO-EOA&;$U#' M/5" F%4(',=]40)D`S[@!=B>=0Z1D+.;A*#W`J=A^SMXH_"!V^@/<;G='!F& M_FWH7O5]67>MA8T3[>?4?2OR_M7A[8NR_ M*N<)$>],']H<&(#@-ES^*FIH23=O9'$@,48K _Q//FA=HNL/?@?Y>]0S;* M9N^8^K00.GR;O4E\A+/3K-?R],;3IX5(9"=""B5]D/W `# (J*2>O4Z:@1:@ M!U")!Y(#Q4"-L+!.UHEY=J"]![(8J =:`)6L8C^#?:N0[ VVA2-F'IF[!R35BY)J+"U6C7:4S66< :4:<1=1I1IQ&K4L)V M8KR=(EF ] (Y`,.Z[\2Z"WL,L@_HE_;O0K8"[4)CSV ="S&K_6R+6<"QR3;' M'S1"9>?8TUAJ@ST=GY4=:KFCN::(C0A.M]@CZFZ2WDUQUU1AW13/S$XR:FV- MI+,-Y%N @JMQ`\D#O@"4`RK;8.85\[/L,;+=28QTWJPTLV:U.4TM*:>^"RQ$ M:I%)<^)C"T@8%0IY-$Q+U[D:7+M=S.O*<96X#%>M*ZV>-;,6QC@K9F6LAD59 M6F*DSW0L700R5FI+%[6ZV]TQ=Y^[WYT6T_JT?FU &]32KUNI0UKD;W+O=S.O.<9>X#7>M.XT[:'MD+UN/OTD@O4 #T JH6.,H M[#GL*2"*KQ'%4CP%.X$DT+Q /\H#X#1H'M3SH)X'5@^L'E@)I/#4`NN !LNK MC7KL-J+^H/ `>!:P=%C3L;8#D(.B!%1"TZ'IT'34ZE>&,$,O9 Y0"S!I&P"P M:R!M7XGE7P=HTC\HZ]@^0[15AHROYO<5TE@A;2^DK874")=%0L9<")_/%_5' M`]&":(=:[Z\/U!?4=Z@U_II 34%-AUKF+PN4%91UJ,7^XD!Q07&'ROT\P MX MA]I2W5-]H?IRM1JMKJ]NKF:E^'1QLZ@D)'EN0'"O.2LS5.J)+%-Z\'>BD&W M58 1#ED,E 'U@*KT0'*E&]9N6+M)#1 %TM"B6UPOD-SR"7N;](F2\"MW^1G^ M>)>Y=%%-I!)7;A1H`QCZ[H*_2]9.EGJD/08Y(.TU5OUV:>>0=AN&"ZY.7G-U M.'YUI R(`@U &KG,UI"K`'J&Y$ #T .HK Z_-6R-THU?E]+%@H:^< 8G,V<2 M0GS3G-Z(5YF*/: CN IY6,K]4I9)F6>D5^HW*_5?5NK?J]3S45 *2 2.@U+F M&NZ(?BJBUT3TPHB.WNXCN4179DBI"4G_)N5C4@:-C%S]5J[^4:[^0:[^:JZ^ M(U?_8JYH-QMG5U8:;ZV]Q?0W72[D>T>DQBM')D'#U1,US($PJ11$?,< 1TVPRO! V;X6.@?YGA`_P\O45E M2*,WS;SK/#*#?DPK5*%_9/$'M()T@@?!F\$_)6$:`)\PPWM$_9^@_1'HQ\E< MIZC_&JF5[=IHA;2_:K5[Q0RNQZA'S> W,>H1$I2C'C*#UV$]8 ;W@UXP@]M M+69 3'"+&9[/(]/H9I*GB+H;2$ 1,ZFV1GP4/6\#KTPV7F$&1:MR,4""/FSZ M%X+RQ2S/4S^IE<-QTR__9#;QRRYF$[^<=!8)2$ZG'CEYG]"+=BIP MG?\S?$[\<7*#>LQC_,_G\?]60_T3K3 [^:_/B.4R^>5@@@9.\TO^<_QB7H*N M-GE?,.&$XT(PH=!>?A*+'$-=A9[F/<'-O-LOO1U^>/&IV\(+^%%_'7\Y`-WD M>X+GQ33(=OSCU7 _&7R(5X<[^2.!!(7;"&,P8PI?ZO\:?Q#F)0E:$>_D"_,2 M8BHEZ*/S-)^/$>?YY52^7'I664P<].M&T+'+L=ZQVO&X8YECD6.!(\>1[9CM MR'#ZG%YGNG.JFL2JEZ8CF-^:I(U:KEL=*BJH1CY$NQ)455,6?M5]:>I/1'3T*+*?L2 ME*Q:BPTJ3'NS8KZ'UYXAE!;O_0_K51_;U'7%[[W/S_:+D]C/CNWG?&$_^SDC M#_+MA*2OY"6Q:<&$A015=L#%20@?0R,$VTRCM$DWM1UL-'1;@:U9DVE3VA4F M;++2$+3"*&C]^ .DKI,Z(0UIF8361NM:"FLA9N<^1]!J_#-I5^^<< M=^ZY[]Y[J(3*_<\F;/? >>>M[TZRW74".O:U"JW4EW[PJ M^ `67^3R_2;(7VU"6?I(N">2?JTLFJZCG;MET7#ZD1[WIL@9,DR&0L$S9#<5 MT<@9O(\,A[KI.-X7C-Z#(9'L!AA2J*"P:212&!+QM 9;J\&@3,50,".*.= % MO)J"H'PN:*!M.5L^< &VNJ@`&"E'/LV6CY13&-1#SICYJ\;R$39KQLSY2#-6 M2D$920+(,HE",DT2`#)2DZ8^?E_ME7+A1)&D^9%P5/.#\7W,-W(8J()%##$" M1OY_ML'V_P&,I_NN;AD(#7I#<6]H$"B>_N'>[4)ZM-_MSFRY2A7N-../]P]L MI[)O,'W5.QA,;_$&W9F^@0>H!ZBZSQO,H('0ADAF0!T,GNI3^T+>OF!T>FJD M(_PU7P?N^>H8>8"Q$6JL@_J:"C] ':;J*>HK3'V%J:\I=4KS%>YNQ^&N2,:( MVJ,=FW)RFICR8#W$2SS1=H=E]TIM<3SD$9XJF=4AV+9,V(QD)H1W!>T\BD4A22J5DX,F4 MH(TE8=%Z>L+I5>M[(VDEK832:CP8Q70Z4HNM(Z):SBF7%3*DC"ACRH1R4F%3 MJ2@,6\^)ET6R61P21\0Q<4(\*>JI8E/DM*I,B/\4F114$TY""P4UGRF0\-"? MR52"-@0.$D Y=W)*[HBTB6@`3KL83N;+D0W("U0/U /$HK> OP_T-Z#/@'3H M^\!_`O0KH&DZPBQGEH>$'4'J,2K3CX[ U$W7!.I6S(#LVYJ3/;TY&5J7DTI; MG0#R5&M]7IL9#MX8S0)_%^@O0/\`^A*(9>J8.LUX*E>UT01*R!C"1_ C25E" M3F(9.IBF.YF0942)%CC,`$!E_/6Z1SB10I *F! 0`-)&$_1O*2KO`^$;7(H0 M6TI/R\B .C,$GR5OPC'50,Z=0JQNAKSY.P;E&6CG=8Q<1CU[#O0$,7@IXO!. M_#@29,M-94%99[FA="XHJ!7ZECO :FL\O(>7@.%2';KC9L[?45ET&[EUYR$3 M&[)KR'[V>61#+:KW"/\*3Y[-/\"3O&,=RKA6*7'NM'BS8\3IW$ MYA<4Q0(>YEOG:VM0#,>PW5_A)P$+:K+K]<1>Y"PG9/_1P3([)*W=^@(^^"?F*BT^,*[V>W5(:W_CC[G0^R[V;Q+BGT$=YYZ8/TP2D:@80.Z3;JWD(F M-*$65Y-JQFUT<[IJY(9[5+5I" V9X"*%]5 ]ZY&!J4!Y($U0QA5P"5D/FZ@1 M>ARS_K3)A.(L9G\/@_2.!)RI> /'C=AX5F^:82K48C8.[LZZ20U189NZ0E@W MP613?B27V>$;,9BQN1BJGI^SS,4LBN7&O/8LS,5RJ99X3\##U_,>NX-_9_*'H>C\=O(B7K4BBB).B\Z&,X9=UUQ,1Q& M!IW.;+2BTU8UWZ1K,=N7V$?MC'T&5\)1Q;S93,PN81R2#)44ZUR(S4..YZS- MF+V8M@"OB6NIK5R4V;\O0Z'KP*(G P9M!K:J;L*-E6QI'6$R/(VF&0<2" MNW <'\:3^ K6XQG<\#H:U6WHI0E:B-$YKYX'3D.1;9"&'L(NW";.H]3R"W?G M\!"Z`',CJZ5(U9L8E5-;`IS:&MC,X0GN)$>X9_*_M8_:&MXCR_3=:FLD+?K< MFV!4K;955;6U7=!X5;5*[3)WY\A*J% &=:L<8M];LJT1"I-.: %AB@B!L&$% MF] ,7J(6N9D:)L[L9B:9:XR>.8M_2][3S>"AS%^IU_D;-*%*J_(<6R4_:;E8 M6R-C[,5D9=;>A3]BG__R,?8UL(76W+W.O,%N1Q;D0[.G^HQN.,V>8ED[%04% MQ3/8K%JY8N17_43UQ_V3_FM^G9^GPX6;T1 :06-H$KZI+FD6ET-J%V=S?ITE M-GRSL4J/*RJ=M#=8FJ ZG@R\B MD.$*?Y/%Z:BO:VQJY*& ]_N)6]GGFQ;\\)W'S]I42-Y^&>[#C, MT2>PX/20,0^% M"?XW,N,=R $C"'^JPFW"3#B"6-.O, M+N&YQ>3*2J<%5JVBS2Y/%TPS^GS^#OYF;,J2^ I'GD$JEMIU?_SE[>?VK"@GDD3*:O>1JS^M=)WV&775C<9=E= MV)4/V5TBEM'7C_@1B)@Q$4E#09)!%!*%1!-0AI7@X!>!IM':VH%-%./'9")! M<4$G)IW8-JU3^T=;8SN=4$N3D YM_["3F@KVW(7$,,.]+_-NXG9<@7OH,P4H M3:TE.T@GZ2/7R$WR*?D7,1#'@G%X[:&>)\OF%%WS.-I*U8TU/5/34K9LIF58 M("N?W'RY3X)KTDV),#4MU:%)'6')SEA+2XDZ]RL7.QR]#GQ?;2[K4?F.C\QH M26AIK<&.Z8,Y!*PGRC#1"+9*$+TE>&[0 M[W/^=6GVWXO5 M17H0VH@NWX3]+(:*,<;X8.(]N51*//B ELFERZ5'C:M-Y=G<30GR\A;GT4A= MY&9D(O*5460BL%SJ]+87G,L9RQDO^+C@4^^GOC\7?)D]Y9/7&?(2<&0D-U=E M$F1RY'=%4)1@(Y=87K6!+0&#EUPT5!AQ)6#EB*KDY5Z!1B:5D)G$;(+H"4VW+INNF;:6%LXQJ*2@,,MOM'!" MML?KR?'X/)S ^\Q^OQ'A4LCEUT.6!4\>4Z >C%*!4%0/"Q273ANU;#YQ!??A M5])CK4Q+**25))F#?;(EF^69'U)V-)].GVB2/7ZO5_>AWEFQ<,= ML9VOS_[CX+.%'HC8>G?EX-I]=2<:N<<.'MU>^?0;`XM& M]US8=V95P+70P"\33 /-E>6+7;G+LXP_Z*[X*[JDLDJR!FB3)PL(@^RY+V 1\1=-A6=)> M%JA#7DU86(M 11 =YN]XJ*4LV:$R-! >/U/UY+BLM!"31YDZKZ4>+Q8)$:\4TTM(*:=X4+V82".,-V+'1H9F?DUTO#,WFP-W79G\* M#3&VZ_X1\N9,KM1[&U_!>""+KCS%@;4Z:UM6)]\I=+J.<+TN,4JBGJ?8 MI]Q5GJ;,W7Q;9@\YY#R4>9(](\6]$UX+XP6+FF+5TFQV0RI.7E8O58K;@R.7 M8D7#7)O5"5Q#WCT/T(E-U7C*E$=V>-P%*:2%9NL0 M1.C@&>=I4M!(?9TR/8:"$(_E8O0?YD!#E59H):WN+N@B76X!B:.#!CF#:Q4U M-7$[K,]E[>1WNOB::@Q9HD?D= 4+PG\H\#H#A>6/[QH>./S\5>#XBG.C@8$#B:;16."1C<69(=43&>[<\XTVOFSNDF[[IGR"P$('V\ZUV_;;N3)#KL"S7D>N M0V#=M1AED1VC;C_X_18,9[TCZ0ROAY,1BX)[%5"]1]1J,!R>" M7- Q5W=\Q6BJYM:*-*KU:W%-U!QY#R/*?0RLBTNNN9;!DO MS#<918=&$AF09F;%;[BN9Y24B#6G) Q"6NJW%4?XL\>ZWS[9E-/_P\,WMNZ] M<7C+^Z^#Y;]-,S>L:U:'UU4=/-#AK^(;?4KE6[\\^.S$A7-'SCTS`JY16#N[ M>695S\:ZOZXH/'7\_-=N=$'%@TEV"%U@8CX<8[@'$R-:QE(^\6""AO#@, #/ M!J45#%7JE+CR:_B8? *?D D%2PHF8!2JL(3G,%'^B#I9DLJRA&,5GJZ)\G= MP)MP!U#F"?C):-P$)H?,CY,O&)9\3F6&4SG*;>#B',]=)9\Q\GS=]6UJ,HGK MN_H$#:G3H;E\VF/N^&A>O-)+_$M"-]\MN9Q34F?2M=B_J[1#JS<'XF3"TT_%J7.W""\+! MP(YP>W;,%)-CSEA&ER_F/Q0^FS[D?-LW(E]T7O9?"5PW7C?=4FPB8P1!(4XI M8%/L3I_B,Y?#$7A5V6\^RYB_QRR!J_B"Q8]$$0/&(OLU-YO9^V.R#C\CR_FX3* M].3=N82N"Q[TK0M%7APJS,I.L7&&-)^']V(<%UWUL# U6,\46'$B9G,X(K/T M.!ZRY=C/?"7S6M>5KPGZ;7Y: MPL$W:VZBO6IMZ79D MT!/HA#.H"3L3`)F&]P1N\[>R;P>X_Y-=+.NFDDRQC M6<:R\1/CH),`8V.,#8DI;G H(<0>TZ&8F(>3H7&2-@(GC2EI4R@A(4,A,-"" M36S+4$C2H4P,91(:VDD?), $0EO,9%J'X1&)[IW<#)F>M/O?K?9.>_O___=_ M7P?=H]G$/,UN,&PT]E@V^%]B7K#DL$Q_&,U@-%.GWSJ) M2OE$3V/KBZWQ944_](30.IA[>.7%D<&7#O0=O'MC$5LAX&I.\DF]$B5](+AR.Y]6'=>8)O* 4% 02Y-51O'G MJI]45\&N;RV8*J]0`UX1IM_47?(K=$\N_K'V+E:GTX=X:TEU0T6BO9\:D+-K ME^_>+0ST-UN,K)6M+BVI?6I9^P!YF^696EVAYA60`(_ BW+G/K O?B-.$1CT M8)?-T^QJ\:RWZR &^=?!/^.7%M^:0R]IWF?;9_]H,>UO]B_T+UKFI"7@AX27 M-]$=8"5J]R8!W0/ZP+TX-<#$$XG2!&A:5)*((T#K:7=!4[P4T;,$D*(2,HMG MPID=8!:<1:Y&$EQM'DCH/,>I!/E_@9H[-/^Y"K'6D:(6RA6ZVJ*RBIQ%[715 M24G+8GUM0.OVM)M5]5D MR>8,F83'DMA4H^;-C-D-E0]IBN?6U=;-J:.T,ZIKJI&V,(\-V?+\(7,H-R^? ME/C9#]5W@X;*>B_01FDO8*;JNZ'=1R3ENJ/ Z743.P(]@LN-0\J8[ 6F*61& M7?6L;CBO:KX7:(IU7I 3T74#J^10[W)YLI8/1; M1T%!%E25HZJ**$Q(_0\R^?(RE!L,T,AFY>E2/["4(B %I4PKIY$,J*I5DU_2NBWLB_OISV_9F/A[^(M/]Q5FXY@+4P0/= MU=_-Y&7.W\QT7+D-W[WW(6S\S9ZOM\QOY'\V.'ONZA.O/_7HK%8L_:ZAL:MY MQMS"ZMZ7_57UU,E,UZ6-N?[";;!N\" ,[/PJ4W;[6F;S^Y @8^9FYM!EN.LV M9. 8A K^_=8EL:8E(TO??"*Q M@$0X!D!S1+,*>( /.0>0RA=XZ!.1Z 6$E0&O#Q)N9CU)70$.TG2DY5!79 ># M/"+%,1Z[%_C6P%Z((&0XQ(!H3('58*A<,4>+EY2I-E*DVL%P=MB? MEQUVB]EAASH\:%.-_ ML*3-R>O+PZ=P\KA;7BTU2*_<=W&)=(G9R[;A#7(][ MZ:2ICTOB)+]%W.S;R>W$.\P[Q5%N%)]PCXIGN3/X`^\9\6_<)_A?W'5\7;S# MW<9WO'?$0I9K$)"/L"^R2< KBA[6E".P=H]#L#-()S VLU6P;10Y[,>BQQ,P M8ZMYC1F:,6TVR.86*CS:)4$RA&[+)+YN:35^:*-/;_E5]*GZ[W"1GG6Y%THPKA8U\2#]! M1$ZZ)FG**IEDFZG(&4EJ-IV*. $>A_B]_^^3>-.I&ET-^:K2YIM,@6N)II'4 MN';8I'(2V)6P%-JS%PKMO#Z7\LG)Z_ M^MH->/K/35-\45THQ#F+7Z67WMN^>:$F%**+I,)ET(ARTW]7U.6\^Y$:'=0<3-,[:-]I]0??9=U&ON0]1Q MBC50)AIYZZA62A-EL#F7X"?4#"$!PF,$21N&_;_4Y'LHF$*?#9DC1S#$*2H^ MU&]\TXB,*2HJ1ZTL.@0@A-/PH<-FZ#/'S,CLEHE,8FO\3L@Y?4[D)$(4M3CK M0T^L4*M2I&UM(X'*MEMKNPA8=BG5J6NB;>):;/S&!-E.A0V.J9CHMPE:@R[D MSM/GV4-:@9T*##;2,2[-5)CC,$Y5& 1\D#^L):K&$E2)@@)!"II4.K1TT*_0 M/#Y7X1.ETX@7Z/,^W\QK;R7_NFG]^/8?G>GQ/9GY\GCF\&C?,(R=>+6_@!>L M;KUF5:;TP^$MF0N?I3+_WMJUWSJT_^ZQK\_"1X[7V2U"L5*Q@P0!>HBBL1/F M1,FM>D'O?1'_'/\):];C]=8DWF[981L3QKP7,.,T\U:O2.EL,.G>+*)\1NL3 M"#;J?()1"CHDER_?9#(B5[[=#AA/31,/LW2MF)=Y#9^Z_^FPLH=\?5#)T9FQ M"E(!26'UF)!+0X#QRF],M5!$-6 ,6K1JH-:MS*H?2.P?-(' MD4A-8UKM";-;&[FE.B7+[D@S_Y?NLH]MXZSC^#W/.?;9<9RS$\=GGYV[Y\YG M.[G8OM0O[6C27%A3CU5KPYJFVL"TI5G;T4YUTG9MT*6 D-!65*EH$V]JD$I):0N#!3K1QN'W/$F6;3!%=_?H7BSE^_G] MOK_O<]]]ILD81".MC4'1:$ZT-D8'420(IYA?&41R4WAP47ZZH1R&8A_.%:B\ M!3\-$GJ!J.#XHLM)DJ ZYQ$DT^E,,I9*'NBQ,7:_M_/SHXC9;5 M?OWFHWN-Y60OOWM4[3".UBYH8K?5VCG.<`\5SJ&CW MV(4=T8/1;UG/21/6R]9401@,5YP5UZ@PZAYSCKF."YGOW4@,]%A*NDL?+H[,J&"6U^% M)+&AOU"!+1%?X$2&2F141(9*U(PX0Q5G-^,,57P\/_4B.L*")L7$6$'/E&_/ ME*_-`J[R[2Z1`;L%;@67&K,MF"!=LUTTYHFW;W'BOTRT<*4XN3(J(S^A'9#S MZXDD- KQ-[>TY&B?P#V>,'Y+`&DOP0I-H/9]R;S3,'R^P,,;:Z^+J177]^ZT M5O6F]M^]:5FF&HK$!RQ'L#$9S"U+/5:'9Z?US+Y::EM43]5Z'TV&U.RJS]0F MC)!H;^.'/]>:,FIO[.H/-E*B!(@J0#2-VG^4RE91J[W<&"JZ'6[/F2S_3?,E M\Y?F;_DKY@W'#<]=QUV/NU)7<8X"X[&Z,>;Q4E[ 9!=L44 M.40T)T"E=]KJ9*=/D5N(WJK(":*;'2F/X'7484 -\H?2G)[@4F(*IRAI(YE, MX):0D#13$UP;XMHLV"A58']TW.E47&B]"[W"-ESG[0SG8R1]#)J/D?1IK3%& M,L9NQAC)V'CF?YIN!GJN"R;0,-M1`;V_E=^!Q[94;$=E+M";7;P"0G"X,D1W M/T4&$#-8U_VP)P)CRP7)4OLM\H/GZ'MW-JYO, R4[%M]I\&C=EB=LR]9`PFI MP:- 4?#_:- C?8]]"J#=7+NG5EC_H%$;W$'"` M@&GS?9@V>52V!SR.-1D<3D926)3$,%:+=G%+\9!0D2KA0^W'I>/A,]*9<'TZ M>Z#^2#TO%3.1_F*E^*3C><=4T>'EOU0_6>0?$("+])86H-3T/)L_9]G\06 `W!M8',/7. MTJ-->@PTE4?2LY=]*91O6&+\V])V"WSX\PD_7H"$PR.LB HDKCP_PD\^>A M80LD2/=H03\D:#;6H'%9AF:O.&X`]H'#%VJS1X:?>FML[9.]2N_#N"&\+M:\ M=^HKM8.OG1S<_N,3KSYX>,^*IB:9AQ$W<.JC^R\]__>?U29/) STY>T]))'( M&T_4MJ[ZT+V?WCG[[,\?WR2U!?4D3-$ZU/D543# MBNPA>I,BRT2'P9$F>D&1NXD."NCQN+RJN[N^WH,SZ70T*@N!)@W;&KJJ(;H_ MK&BGM,O:E.;4JEBU(V)I2VFRQ*LE5.HSM$)_?DL>Y\?7;/V#9#XDSHR &72) MPR/,#&:[EA(H_,U;P6*0A%A9-A$-DTN]SY0]ZIQ]><$BX GN`Q$AR+V!OK!SWAA"8N_0O1-+ M+H&>J6U[EV?L>M=KU#-R$)8.0>4HW$5[#V%3F+#2(7:J$"9;_4-%09$QT21% M#A MK,B(Z&Y%]A,]X >C%J0PIE43%FB5A!WTT[#FK@ACPI3 SPG($OJ%+0*_ M69@4+@N\X*"O":P"A>K&3!JYE!SU.@9^,#=%TD@0^]3SH0E4EJO,=/Z?K>U]F:Y9JY/_%^ M4$CG;M@K^P)H<]/F9CP4JH2^Z/U!XZ11%Y"09=@&C@CS0L681"U25&P)8X2M M9KL9]S>CYBKO.1].-;ACT>KD7,:Y"ZI^*&U7<>99,?5;BGR\_FUF)V%".RQQOQ1E>B>H]<'U[)P1SK8CXW4H;$V+2D')B9QKQL MT*'Q[@ MQ]_1M V2Q0N@JO#=+!Q,+ MS<[26M'Q%-EW]WINT BR,+U]]R95]"[[_+9O?W8G.NBJ'3=6J/OX731(&ZC= M/GQO8H,2;,[L!U4TCG/^$U2QT*_LZ48)^3@AY LWI!K;&ML=EBO0C;JSCTA[ MT$[IB>QAZ1OHZ>RKTN^D:713:FB08-OEM-98?%$J6B6);[&24L+B_\MWU<]YSH.TV38G?]_'9.OG>Y_E]UE$^7WI?.RY.EBG19OARZ6/J4 M?"%]9J1N@V[IEN(*6"[=57Q VAPZ*Y\QWI7?-2[)EPRW)Z:X5"T>4\*J5H@I MNLW8O)H0;)>GQI0,)BHT# 3\1 X1",GR!'W3NMDH^@U9,HIR$8KXVZ5P*"11 M%\\38A@9G3>^C2P5*A:T>%S=JQY5&2M<5.O5/58)2D#9+9H$3]SCI=_R[&FU MZ0)[R3A\,?/EK,#Y+U:QH3:%7Z-R"3%A#O.%G&.K\ ;NLEW(7S([-J6)Z2<%,4HA0_.^&WV;?<_1/]!IZO1IFB@PK=54IK4:Q_J: M\+.^)D31"Y1JHN8710T1NL_R9 Y#@\L%5 GSHHNS^]$HWNGUQ@5#L 1.F)B^ M^(H7FR-<(SQ6C-L!:T^693VAJVQE(9Z%O=F+69KU^=DM`JIJ:'!:0U]B^Q#; M#&K,%C;8#B6DK]QW#;4UOF/M7C>0LPD0ZS\RY>ZJ];I2&:ZUF:"!-^T6.X5. M%KP&YO=:NDL,B5GH(J;80VX7OT-6B/WD`7%0_"DU?8WZ36EZ3S+@,F-G95)$^#H=JSM?T+?&? M4V:'0P76QB8%S;):25Q]5TCTX6&R0.F[JB'8X%EUU]TWK[YV M?7".+)CMMEIWBP>-1*TJCWD[!%7=1CROFHJ[NR'=KZ0O] M?&6QL"[W*2ML)V^+5 D43VI6.ISVI=V-WCQ10,Z#WXE5T(&5T-"4AQ#%1>0# M>2+5!6SC?OVP`=-D!7AXK#I8_:CZ8?6Q M]T]]-KYF^XX'CYWZ?/L:M-_]U=]5WZJNAAW0"?/??KE[^$#U9/658]N@!>;! MW8>V(24QQJ[+V>YI-FP^00KXJ#^:6RX6-LH;E V1[^MK"\]$G%ODX\E?Z!>4 M"Y'WDO6AC%#0TV;*S'3H1F%%YO[,VL)08=99`N%(-K(P\OO0!<5Q0(??),]+ M[R7/9\[I'R7K(U8BJO-N1J4:Q!2GFD"B#:@)$HW/;HGJ78F>!(9-9Z!%#P8# ME'?R(@D+82-LA=>&'>'N`FO!S5UE4@"K<+1 GR^<+DP6N,)LL 42;"D$6R!! M\[AMM+GMBVY;']U[\H4)>.B8NO)>9C%J*CE5TTH;;WV+YR,8TES^SXJ]59;; MSDRHH.,H]F$L,\6:@F)3(\FL%)%3>CHKI=L@&<$E$VII@Y2"26:F>8\\0KJ7 MHDEI1OI)=-1IS?$.;&&,@)W(2([%,;)N`,-8'W/?_\VP#!HE/ L_,R^9H&U; M6$33G/!B)+UXSM2KJ,]^!?49_C[^VUT7?MTZ,*]\1W3U[ML>7]JVA#YO7$*1;.M7#G4)3O(EZFF)-M*D[ M\[\0] &>>J4/<=3951$^J6')JOSF/3Z4TXN;B0^Y@'A(B+KD<'CW^VPUJP;^9+O0Y@D$ID$XFF2FD MY1K6_ 2N0^V&=EOSN"=757:/5,]6_[1JU]+!81@!M"SP!&)O<+S_Z1UKQDZN M'[[=?,US=']CW''?L?OFSEL)RNM@P ^K#U;?^;RZK>[RHR]4CU:/CV[?O@\Z M_[%_: M#8((0QVI$H$[F4&J-)F4VMBE[>(3@?KXX_!T M\O',3Y(OP8MT?_)(_E3^G/%Q?CK?))(@A*FH(\I:YQ;F&JN2]Q<;6G@:B4 @ MIGA4C:1TA6 B<&,68#DV8='9J612H^#'V)0\3./4V9)]RMQN`,*+*GY_M+?,-FM!3YFH1U3:@Z:( MJF-".UCM:]LGV[GV.;R-;-X^!]Y&-J\%`S:R`_;%@(WLP)[RRA,0(E^:7QO6 M0A]+OKD<0W6QANKB#*IGS%.E(B"L^P:*N2F\$ H+E6$WVB?45Q#-,+*$4 'A M=&Y8<&Q]H]60&>[SK% BH::,:+=R.54%&_+_CQ*< M@!,+I1E20$YPK*X^6RVWQ9N:A4AZ4=DF!]N\PU_/O;/SA4,@WS/2?_4F7\3U MRS///S;W7CI(`:J;ODX170_W\V/?P4$W>13,/S7SHHB=SO[EFY03X40GN=D*!UYH`3[@(WD'X:,T(N?4 M-X*-).9[0 ]9 MH6 8RE"!B=6%U<5UGG7-57Z39[.P*;=)CRE (:6\4I0ZJJ%JN!H9:A_)CQ1& MBB,=PZN\#I[/B;R42_'QP MG1*QDY3.@G(!4>OY2F>,*-2;*!&N) M$E@+0BOA7JOINQ!83B[>J2,2JT^6#'U%>]B\A:T!*E!4ZU[L"0CA@T44TG>0 M*\2M&A!VW;D'K1UIR(A:EF_A\D3.ATE-1 4#4=?5ZLX3O+M%5P5$<3YOKCD3 M0#3'&C2.>=VF,[M8T2PH^E'LUY @Y;;RVSV/"5MUJC94`XACB5V$[4+]AA)FDGY\S*Y$N9J-IW-%@L=^7:, MR1VK'#_.!&IG1L8.Z3U___FSO1^^V550WHZ$8TPF$QF\N&/Z^55E=>F'1_IN M_&3'WLZF2,*%%)$^>W++S$!/OG=Z^^-'!TYG MGJL>_D,QK!@X\GN0-GK5UD8?6^5A,$P.QX;E<3!.CL?&9=9(5!(;$\>HV"CC7^- M:/7S\4=K(5U IF&QA@%/1@#+%_$"K_&^`MI@_9;0;P:X1J1(QE<5GD/H?',)J'1V+2+WDR_*B\ECU,E+D1OTM+,]_ M,*H5UC-9P=FW](MJNKSJT\7/I3CE]HH[1D /WE5^^8;S'-K5-O"MGQ(0V8YF MHP"Q_8BG[=JJ-D8+&EVF^^B]/BJ3RJCMJ79U36J-^K+*Y-222O;#*7Z?[X1Z M6?U7EN[V(HHB$TE%D<*)9+,B@41*5*10(A4.A1!/D1G-PS4CC_;Q!;QKJ''; M-G!V`^]@#CLU@>-8RUUB+2126,B2++)WEC\8Q-QC\Q"-OXQ'7[<)*6+_T@?4@;D"2U':!>LP6J/8CSVJ8NW9:AO0-[SZUB4>IF$YK+GTRD$B3MRZB9 MM#?>2@C^K#O7"GA70LBT$AJ?P:X"K(@?I'QPCJ)<)';AE 5?.+ @;?-.%G'- M_<8L:.??/09RO =NY/OUAH$[5_]R&\;7/)PGUQ>JZ7"L[]MC3__^8<0X3C63 M>4#95?_SU9LOG7AJZ)]D8'I#)E-,3];/;;PZN7[JXI_(S$R\!<6!M'R3F49Q M4'+(YTCR@>K@ZQSHS&6#_@7'7[&])%4RRD&)X@,DSQ*&44%@5JD(]6OHN@(, M$TI6F*,]C)MU<8S+!>D2$_"&Q)(;/1*.)Y8KH'H_KJ.HMMY'C0ZN:*SGAJA! M[A1'9VF=;>$UMR9JD9S4K*EF!UV*%.!#](-,+[].JM*#S" [Y!IT#T8&8=7\ M*OTHLX,?BXQ)X_G=U&YZ-[/;M8??Y]X7V2--1_?$OV$\33W'/A,]9!R"<^9A MYCA_1#P2.AXY)AW57C".PGGV-'>:/QV9EUZ)GHZ=,LXSY]DW7 N1"_ W\"Y[ ME_\L=C>^?LS8!L?,.8[JE';(.Y6OMU+;F&WL&.?HY?J4=5JO00U)FXT!Z.AG M^MEAWD$QA N17+31:([F%),I\=PY&F^G%2,"764)++,$#21"C 0E43-RDA9PHU54 M.2NI);-3*BTL3YR7>%=\87FG%80L$W?S?%)";TN1:%3F7"Z<7 U2% U$C1C+ M)J$1A- P:8;!,U%HHJXI!E1-0Q:+('F7BV49KNO[],LF.K/7K**)8:QL5U:V M%1:@N=_\CNG8:(Z:CY@3=N>&^9')FN^S?^.^S$L7(_PE,DY$P+\MWG+WNZ^Y M'>Y3Y:X%\FOG$^//(%WW2>W.K;!P*R34%VV)J-=O?Z$*[4KHGG6VZ;/>Z5^B M.G1?@[W7P'2JZXA0L4+\_R4C>+M9=#-"]Q &UGL7RCYL%%$"8D8,:EJCIR+C M(@Y1H80"?&7%22)). 0:$!$BS9<"Z&.#LIV"34+&S!? WM3C2T&(X+.9((=U9: 44(%MB MC=G5SKY,MI Z\.G/'%L_^QZU_W-[E6? M;9I3Z; S3),$;& :M#CLATZG$_U3K8&D$D0.DSAUY]N2K4L_ MUM V:2OP:D;52DAC<2HJ!AIS:;NJ*]N")CZ$-G4?94)LHA]+TY2",% H7Y'* M5*0B41:A()5!4)#::6)+P_\]I].$L'3W/OS>W;WW?K_?__<7#J8.=D_FZKC. M'Q6.INK=]=RI[M?QZ\PKN2O:'[6%G'Z,/RX<3[%88"*X&99C"3T20ZE,!#4# M=%31(M'.A!(*@=D(P#X*3B?!9#R9@E9*282R*2'G3 G)A,+%9(Q0+!8E`3T4 MG%O]SPP1>JCC*7M)-CRSA)4MH.;L\*@]*6PLJ;WI28H/V8FN8X[FF8.RB8,(5=9PZ'U M"=0UZTT9F!E*#"495&G"KU8C-@Q/88MF)]SJ@MT"B,,I@CAR4^96;T'"(C0+ M^.Y;YR3JTC!U:A5,409H_!]?@!/_!X,0,*[A/X7#^[:7[EY2$]O3*PWB$^Y^ M_8'LID""&8EFMVW $>PN:?W]@+G,Q&=75NZ^=<\TX/N9P7WK.MRFF4YW/GIW M,W[MT8R:;D>(0:.K2^P)]@Q:AS:PH\WH8>MEF^QVV28GTQ81,J93%)EQDX9A M$TEYR+ALT>=CQO-!,@3:?Z&6($\.KXT<69Z.S1<%6@H]&7)LN@NF9/(HZNA* MY_HDVP4/E6Q-(W5K!">Q4Z0I'-J%!*.U 67#EH1L4' M'AU^\]D5*]?+W M7;-NUF?YGD)/Y9]!)\63!5[S!8?D*LB@H0P1TJK$ZK0X)#FD$N#DAMTE%KY4G%#:K M/*TPRE>!)F3%N9)=8F#9DSWU'J:G`/LVQSYD>QUBIM&#>ZHFRGLDJ:\/-OXC M. %^/'\9'T"=R"1O;"DB,V;6S6G389O+)E,WL2F30>9E9A@)J W"0:S8-H8MDC&5EF]PYSTH8F /)%&4?S94V%M:K'9Q_ M8+!_D.%=3K>3X8VX'F?X@EC4D5?SJ\CG;XUY5!SO6,\5533H[--QH4_TJ;** M6^)P&^)+*J%4,VU:\V7=W6#,#@,S@:&0+D&NM/M\V4?DOV*A*6#K3"^L%!"Y M<%ZFQ6Q+<4"'M3>9"L6"+8I%11>+(;A4@O:P6'3#40ZD2.F&T@VE"TH7I?0G M?WM@G2:(+UC 0M] ?_\`T)<:P%"@V4?SKE 0#&$P2"@_T$;MHA?F`.&AB]GX M7&?_AKU?B7;][I^[=I3-!)--F-FSI[[\R'K5YPZURE);:7)_[Q#^=GK;R,3@ MEJ./>]N_]OGAWI$O372>V!^/IX,ER0EA!R,RT],IS=@NV!8H U%3)=H[&$$XKJ7RC>M):K" ME*''%8:@EWS.!S.D#95_ M721=DI0PO500@/@-4IM?>]\\>1TQN$_*"7R:G^4O"._%'%QBV%/IUQ-?9 \Y MGF&/.]Y@WW0*&P4\Y PD/??[HX$1)20A1R2(9 -__"6],6Z:8ZIV:-[*YY! ^P_V*IX*F:/]_/)6C9S^# `'C .46G/'@PP"[8%A":V2 2)"TDS[_42T/6O M81*O/_;=Y]YY[>2;8]^;:-45M;L%^WORCQ<__?++^PJ%%//^I7__X?8WZT-# M[(67'@[+'9,KJ94_K\O_^J=G?Q()@$=Y"#"T":*'@>^<=SKPO?C!A'F:HO$T M?>-I#."#9JM+J!J3!F/ EEP@>#(T4/P9/^2&4/GM+(DH6B\+$@_R;57*5Y8H M4.:O$(3X.HB,'NSNZ4,=Y/1"GET74 Z7#$0#*0A(L YP$75J!L, M,F1#-\8,LJYIXQ7CK-$PKAD+QK+A,?9K[[;BUJM!TR7 \FZ<#Q1)80_ZBK!( MT?A]3,+;I!)G7^1QO\QP_'!^^Q'P#46!-U;8N5:9J*[7*8HW"RK+*2TLU*MV+OC6* MN7=HG],.:NR+&NAQ;0]P8W!P$ _B6H7 !DU1'SV#9(5D?LNS_B(GRT5,,@>9 M*&/CG-P4/&P!Q&J89+I,H0]1K$$]2:-(R_=PGCF^ ][T^NC M7K&CX[Y]&S[UZHG''AGHPY^Y\ O,OWL#M[RP-9%-M!V*13<]]NKI#X5L`HR"#>E:D I64-2)+'D)GG2)`$VG MHZ'W`YM"4E?(#%W]$?M7I)% #2TMYB/2)?MM5PLS[@\@$PXNG6:IXR#*E84+ MKSF,F^ O&A2/\WPV0U5MWFJ*F]68MRPB%SR 0\ '"0DU9 DD0,!S$Y5J7:5.)%:I M6M2*=)2AT$J)D$J;2B-LZ]J-_4$6PC!(+9E&:6&-&FT3HTP4)J%.&O.4;0A- MJE+V?>=TJ$[NON^]>^_>C_M^/Y_/=R%7`60#@(/8N("2#^?/=G>GDR1$-NE- MZ>'DR\S+EF/,6/),?7-(I545J^")XNQU8<'.[VJL^J7[/]IQZ4)U&T^II[@)WI=$>Y=WU MCHU2T-TIU]4K&P/!NLX0#+,S<=D\M5 5,>6,0H>4 M2852[C7TL;#6L[&F-+'GNS-L1U/'H2H^@LI8+A7;E]O)#]0[@&.%P*-HXB,2 M'\'DJJC.\/5:E&]0D<[ +<9I*FZTQ$U@Q%5(+*XE'@[^/8I+HT7@9V#G*A%+ M0,291\A8I6.O977&U43]WX>ICSO&\B?N_/=W+_4"0J[2:[ KX0PK_H3]ZZ4F MMGU?:YPC-=Z[_ZZ"/'>,5X#N'$UP0":813, 4Y)2!L K00"$DP@T.RL1* M4C!<+A>4D-VON3C$B1S%D<=D-&>B*_3CF/+#Z^8(*%P[3Z*!:;;;36 @"AH\ MB'A5L5@TW1KH.+DP_XB,Z^0Q= K@B%9-=**KBZC.R)-)C AQ89%3N1F.1MPP M",=3',,=9W[*S#(TF8J#K9%(C!)W]GA"0=@G*<)NP>W);L% U@1-@A *?IO" M]85%PN+%R\6B_KBY5E@I<7?#)PW5%GW#:-ASG;;XU #(M$!6,0+9$%F5K2.? MYD.$(D*FB\729G-_8U/:S_JL@^XGE2'OWMK"*@[35I:S\@Z+_ 0[3KW!'G4< M$X_4_8SZ5>TY]Y^HSYTWQ?O4?VBW-,P-\R.PNW'K;[E/G$L<,!U7\QI%6TF< ML! G^59K%]5M[0T-4 /6IZ@2->X>]TVYW[6^:ROSYZPSMH^IOU%W'/=M'GZ1 MPXA;Y*A18LG93<*AS7 L]PKC02E%)DMU2UEI2#XD3\NW94:6_7]D,'S!12 0 MADA4-S$WC"U2EISQ=_V8?!'N4UZ)^;-.!>]7#BD3"JW<]WC&>)SB)WDJQ4_P MMWE:Y T>=L+/\'=XEC\MR P:)WY%QPTI)1A"GT C0114@5X2L$!68H6S%#J" M'2O*!5* GN51(EM&BV JH/-%0C0EXE)ZR06?"+3V?AFT-J0'[< \0#U ,;B( MUJY%HT7<,3C'(DQ1HWO,Y(#\3$5^`7$PFWUUUF$DLC5P\81Q8EFN:@A&S/JK M-7_UV4K-5JW9JC6K63,$:U86?5F?ZLK6P&5"P;=4^IX]>]RLE^B@-=X5!I,( M@VEA8"^ `_8F?OKIHWN/)$+RM;=_?N]?OWGGRO)1_ N+Z-O7VG^86O?I\\_O M>]$S_E>,/[^'N=^?;AN,K#5>!3W4BQ!]T/(&TBE^);JUA,E7"8/03L(@@>W7 ML2BPF!<:,$_J6(*S_KLAD0`5)#/T39(26$)/5N D&Q_1@EZ$G W.,O;/2BR/ MDKG*O#B?6ZB(E2HIS1,Y?5F\0OXND\3W&UJZ@)SF& 1#C;H&-@)OXANP&8B8 M)1&(35UM+N.&83>CT6R'^DU37PM"(OX-!=TB-YA^88'H5A*.&UY7I^2I*-U) M=SJV^([01QR6=QB<3!P*3[*3W#0_;3TIGG3-)*PB"S@UU#BD4P%>F ORQQ_# M&T:=O:JC:7J]I(LVD-)1!.3PJ8N/B0,"+, M"XL"*_CB%VF6YJH*JEAURIX*N*Z9V;:#^;)XMP0LE ,R6BZUYY8ALX6#,/E' MTNH]2E23HYH2"Z!Z3R2 5UB'4 V""T22RP.>UB*',^!NK1G7ZDP+I(!F#F@J MIJI@@LQ/;I'Q>P%M0__RK8;8)M_L[."YT6<'V])!;TL^%(HV&8%_T-N6WQM[ M+!Z)Q#J?HO9N:1__\$!G8FTP$_Z!V]W\S/5-6\#]T/JON^B_@"9?AYY >^BW MC!]*2M];T:E6&B7$`O5"XPO]%&IDF]@=KZM,;DUO8?^:`]&1P@0S83GL?:UV M(G-LP^'-$UM_U/NF]\W:J=XR<\$RYYVKO9J^NG6^L%BX4U@J^%>IGPF?"E,!U>&6-:&!*&OD;M M9![G#6C-&]"4CY/0R?=YL*>,><.]G\>'>"BXX#5\AIWJP!UENMEP^/*VI _W M^<9\E.\#Z@^(A>#J0>WPR,9RONUX>SSN[/F03@'?!>&>13UTR@B)*;P_-9&: M3M&I6L*O*0<)B50FVT2/#> !LK<:B%8H7)L3/6;ABSG2!0I+AJT&`FE "\5P MS/1![ZKT1 SWQD9B\['%&!,32$]X='^.A#P4_FE(!#!B!]1"JF 43L&96PID M:,#N2!>$B1-=N$LD@[J:504[E1'E,P#[\L-_&RXR3G$08:"8:U3*U >&>RJ' M<\TINH^F^FB,:)&F:'*4OKJT:>&M-)F>R&12.$_V2#^[MW 1OPAYG>W7X[6Z M_H"$!6!YI;1L%BIZZ:ZHCSXP*WJ)H+\^*MX%[08)K5A9(87E+PE%Y,1*B62] M13"D/W0&EIC[+'P[3 %/E.Y70)3II$6[K4%+B02>"\0M( ZY,+'P;T;&?][@#>M;NNS0_=_>O0MN:\BK?F,ZT&U:$"CF]@ MV@/X.\GM`=3?L%U%F[W_X[I:8]NVKC O)5$F38FDY-BD+(ND14NV&%&.HQ<3 MI:8=)TV3QC6:.(Z[.7&;;@.Z87X`>R![U-TP9#^&1EO1#4B*Q<"PHMC^)*F7 M.-B&>8$1[,><97^"_5B!K!N"%8VQ8$N#H4N4G7,II4%EZ][#PYKZS\>>WJJ;@\GYZ[MFYEYYZW^__]Z!=J44/EZT M7;)E_\MCQ8EG7]JSO?'?PN".EW^[\LOMQ3-_(^,#;TQ_?]T+<7Q70@AQ^^:7 M+G5DW [%" <#(3XR__S"B1]-#955M6^4/Z%OT]/'V%-?/?G3J='%D^=>&'WP MVO:C?8/64Z_N*W9V!D'TF0@4I_] -U=F3S>UL:?J(7%E01&H$ JJA=MJ`C=4 M:-8H)R"XY=$.3XTB2-4,JJ6.B8Q9+&7SQ R*(CMITFN8>16OD5]]]/$*9B&X MOX([\BV.07#'DZ@HT^OE"71A(P)(;0R^??#MAV^6*8+P2B6/AW-+92:K]&P- MA@'6A0+V@J"Z=^X`*)O](#6M\OJU(7G=]C,;T""N/]$;'BW&D)(E.L(=LT6X M*%Y2R0I4?@4JN0*594&E*96F5)I2U6J%F#1MTK1)TR:LYBZM-A#\>P5W0/#@ M,N[+YZN5IFI3T6[&&VBZ8!701FXHE%<`XFZO4/5R):$Z"[Y9ZI,R2]5Z-7B^ MNE:]40W8')FHSE;G,>55B=&F#J24U8#D*;WY@51V?Z\PD)+WI\V!5&8U$/6< M="GKC!13I3%B9,L,7278*D61!4VU^+I S@M$$N:%<\*?A*" 1:HOSYB6H^2(2U)PFV)< _*,Y"6"O3"(C-#H'C9*-&HQTA#U.K. MIE970*QI<\B%:6L(V:%*N96$CI$[>QHY=Z0Y5TA-;"E$2"[W^\*63>XY\UOM%XS=3AIJTK&Q&'B=C/SY6*#[7 M2!YS=,N*"]4C@5U^]\B +:_!$ :^M#.][#,^8ZXP%@A!#\(Y%J%PCY@J(ME4 M$=EF7 WPH""TED-PBP*?QRX0=T-P_1(>S4?45L6'X/V5)MUNM>AV\U>4;<8J M,*#K.7/.?!5DN'<..#S+$8XZ673DE_$"7"\7!S=X$XKZQHS\GM]*`LC\$2@! M-=->1XRUF! Q* =,.N)U5@X<: 8C(W[@:94*-^EQA.&6.19ORC"&V1N.X_+N M>TD\D^>M=(3R(<(B[".4#[@RGP\J$I_R!S*7?0I9Z28\-O?VQC>F*'] M2),*6MTBL]:\5;>6K;M6R+ F+-;#P4+!'!HJTKFZPY_S@_Z<[J.SYVB)(A D MOK\W,I"*`2VRVHB1,L=$38S782DNP_2*X7A,J/.$=U&#+^XNX>1)PZ7 %T4Q MHD4LU;-=%7.)\HYB7243*IE5Y]6ZNJS>54/JQ?3%GU$ZX,_>1 Z ]&[Z-A64 M%Y8F-\E EP0?@/H,602L#S5M)^A(_#&N*:RS+5P/Y';NS.5J.[^M;1MI[-[M M=//A5"+9'R4=H==Q1RV7V]DP'QI'7 !RHC9)7GQSJZ%)UCS#/CK1V$M.ATX# M:@?(>K/.M_?':1,4U_']W5O!`DV#)CQOM>#Y%R_NX]/'MH#IB+[ZJ$%/@> . M/06"O])3=#R%QU-TAAO((E[%?DB ?1KH[+XN,X7-C0)6ZYL;35C:=@N8]C7H M72Z]E2"<1FQ\TL.54L2^".7/LR?LNOU.])V>99LS8&/)#LB0N6$'$FW]66,D MF^H?TW!)W&0\P>>T;F- #'>NDJ@7D1E&#,.=I7-Q$E\E7_!J.?\U>T^7`H[= MU96 ]^NC-DA1VT91:^EZW2"206:-9>.N$3 ,/,18??01=(QP@'$Q9__9Q'=N MC]^C3JQV4$8K5AN7]WQN[/;!>_#VP6R!/@T/^SP[SVUTKU"\;2Y.RU @785: MJ9CM,A0;M$C*R514ZNE+2GJ2I*+=Z')(JW\!F8 &YE. :4;8OG1N_Q1N^NU: MS09X+/UA^3-'MYF);N5%4W4Z/T'/:;H[9]<:QH//?_B/T71Z*!*>ZIOZ(?N# MG]@F11!A%(8)BE#W*H'?-?%C)ZC\:W0T1(2 0D="1\@@`CIQ!&_P3XH1##S; M-PGEK*.3ICT(TD+)4B MKY_>""W[K\$M9)@28"]6IFZA7&$RFDA_F@B0O,2+$0KOP/L7! [>D+UI-TW$ M0WMM;0VM[A,VPEZ[!E43\ G497SJ8DVZ(KFZR\8XF<#_&_R;0KV]+IZ5SBAG M8V?T<^Z[@N!J;N*X?%PYKG])GE/F]+,L_V%J4V>7^->BUP+7I _8#Z1-Y5^Q MMF%E6!W6J\:PNU=:%+XBM178G&ST&9F"6R55.;Q%GB3/RX>-8%J>(E/2;?DC M.?2,LD^_RE\5_BZ$NOA.6>_1]3WLJ,2U*U(\DA![I%14YPX%)H.'0M/R8>5P MG-.DGIZ4?H@--LM^H:Q23!,Y(&1+\(R^*1+Q&\ -@=.RH@BW;KH;D;H;>.BW M:1U'TTSK. 0?TSKN.&[U$U]#;0WZF0T0(&IINJBEZ?8F98FP2BP>ES4]D=(< ML"K97H'E4P(ZE6RZG"V,E%+E,:; M$/=L0R]PR"LH8,W'"1L!R$L,1A#CY-@ MEI4$65:%"L-TK9([WK.J^,?V=H$#Y&N:*K0/BDLB>UO(_AO1EP/(]M3@UW#=?U46S-@X "U MJ0#R)I'7_/$4[EL/AZ?A^2PN+BS,,#.+9(9^F 5F`9J5*XP,M.F ?D7OA\X+ MOCT>`*]?+_V:[>V";. M,W[O^7*^V!?_B>T[_XGMBWV.>>_\\?L_O[_D]OZ]BE@]\I?_KI-U)Y/?)\<[(GUMO\.#)0:PY,I4-NKT>+AOK\ MS-=VZ?'R7_=TRG(PSFL:/S!VM_FWL]V#'I>NLU! '6+'FG<:.\-,U_UNM?M% MQ^[+TS%_&IGF.5!87F":$'NCI:]4D!>DKX*RR)R,.(,19S#B#":CS$;:`.,! M51AR2T+)*+20,,"X=P/7R&TW@1PDN)Q<``C"'0@20P1#T($44,1"@K4JAAS6 M#+Y;VZJ&;(!44C!(N0:6<9R3D=!A%"R,D@ANRA8]LDU>9-BB1Y95Y1GA/P$Q M8NN<7ZVHZ^KGJD-%]3(Q-8QW:]?HV#!3W^Y8&IE5F:7.JHOJLKJB7H&)3ME( M.&=2S$B(V70PVU$.)()[8$M.T<4QO4/>=".3;#''AE=D-BNS17E97I&OR)_+ M;?+;RC;98LOWB?&G0F6!G6#(=J13GM4F+629#C:ZV?^MDO_ M*<_MC),.<5@_F[;5,V41,>^XRAUQ_'DSBZ@-JC8;%IZ5ZJ>C]=>K^1;?Y_% M\?BPQ_+B&>=S-"M7*$VU9DVU9F&/U8VSILK399I7)J"4"2CE:A!_K=I:5VWE MEVK+`1C_MB(XM^I"-]4<+<_1\EP)#M!R8T?)A\O@^2^6&]>5NM Q/#^PDCBU MQ-,XCSY*?O+A)Q]^#7,@^=#RE"C7-MZW?6A]Z .>_VZY<:K&;XX_!HR"'TV) M#!;W[D-!I4T?KELX9[#.#M2_6[]0=]3GQ.E".-/O=H[WMSE1H2LAM(7\;@^YPP7IOV$>+\F M4!K)B0CS'/7E2F5Z*M-3N0KO\8# KVGS\#]]2:%!!LX"XY\T6BK-5S''8V>U M%4%@?$FCU6IC?C-P_%NM#W9.%[P"1^_\X<0$DC*@=[6C*ZG8TM:ZL:KZTQ MT_*6C(&7N[N8QYOR9+J $GSC.5N4<@LY!IJTP2!?@ 955+M5 M0OZ@:M/%4"N79($Q(.6H3WEDJ]LI.O]_Y3/$9IOJ6OO5RIU'>=:YZ:TY2DKJN^M'^6_6AYP#+WN7/-RDL#T E9Z2#T M%:QX?ZD9.CH2T_786)V]]-/^EAZ6.<[Q+V"R(7Z+R4QBLCSIX0*U'LFKI)$2 M!O I'=<-B2A)(CZ0B \D1<=E2A0'%!GC7&G1$QCWB)7 ^,SJP>D*%Z?%<7(4 M)Q=Q(XPN#!+.1DL@&[9$(\,F.0.YS84K#*Z+U_-().T%JLP*Q8[?0$+TP96" M*X,CNEE'L-5IT M82"9X S#,(>?BE);E6[EW$%X+52FHZ1,4<[O,JT^4S(Q_O/FK+EH+ILK9ML. M@5ED7X2G55-<->^8_*K)%J%CW73$)<5(>-<<7LN?,HR$/I.2C(1G)ATW$FD@ M"&L@7FR=%L2I#7^IA4S MAN)Z7]*8-1:-94.X:*P8JX:#,WP&;V >;X> -Q:'(=0A;5.40XP_L>\M58H! M/3JZ%S 0@U,%;[(5AX_>K\R-GVM^ M_T@RTJ7KV1[O`7;ZE1.O-N,+2APB;7J)'7YK7Q3CC ?2_LCQ+L29EXOS\F:D M=8$,)$4GDYRS:SJ?VPUM5,#8P4$TK !V"C1-4#.2VY?A[,Q(^/V0@ NZJX73 M=AS'>5%<'$-,184@(2XH^TC!^4B^":0#T!2$A"PG$P@L2D4(+LA%]"/@V-K; M>3'$?J&\H_R!?=#^^_C==K'S8Q?;U[Y7.1)ZC;W>_D/OW9@S:15-(3D)L+N< M9+="'T1Y*\GV2ZW== IXZ#G0_P<`B@*[@^VLL"@L"RO"JB *#V4+!BWY,I0X MDXG)2CCW@N^+[^5JCQ90TU56>P]55F=?/'I-3NR_EA3V'SPZ?Y.3-]8Y`:[D MQCJFP,GY7W-11Y$3N*"C>-]W/[;M$;)#8_.%`$0C+-Z9\?3PF:X>5T;L\7N# M&A=G48TI[6"%G6 %.GP:BSF@";E5C8NT06,7(%L?2!L,]2:@CDW.6_Z3_$GQ MC.N,YTSGR\K)\,DN::$!A1 4/U9[E\\_&H,K!'_Z-?FH`1(N SZ HIE/9 M'G-X9$1-B6(HV(F8A,S!^=,A\_CNRZ]^_?RWIAU7W_S! MU;./+[[UXU^>_^IT>>+-7X2B8^.KYHSC/(=S4$40<).T=OKE/PB-'W M@%M5+#E ?@QD/",-T9DE%N:(A3D&Z 2&!>7VB B74O*@3;3KZ[Y;0*R#A-@6 MM;[+%3<>WT @%EV(R3":+M?8+M@=X39 '!G0[!P@XJ8^LV(DUC28U2MZLAR+ M>& S;MP-;@!/>L)G,R.S&1/(\[]\5W]L&U<=OW?G'^<[V_?+/^[.CGV.?YQ_ M7.PD3E.N+^OO?NO9>[ MSWU^++7)<[&$4?T,MQ&CU19WB(^(IR3720MMM$8V[K(>L0Y)AZRC[#'IF/4< M^R/O3?;?OD#_QCW5L:'#0RYG(ZJP3+X@*V"KM).]"I@K,TV9J5$S06VAY5*> M<97%881W0GOQGC0U.#B0Y&8X>H*KZE%I*N5,3&WZSJQ-F-HF$%:=;.-"TX-^:EJ*VV&%$)BAB_T,0;536>0-L M=BCGS_5GUWD'#50)P*GJ&S;0`%\V*.H.=($HIZ9KU%0-(,ADJV'L=# .O02' M9M? 5"/K/PY([C9A@@5:US$Z--)SVT^/?GWOU N3+^\5,)B M.J%FT9 O^.5/']S\\%YG3W\EP]C35X\]>OBY*ZVY$V&A;_7FOFHBFT41?N @ MLW^L7PV>6'WY2'K#G@<__\H?IAY499RT`@#H"X#E/#K?07*^2)#L248EDU@( M4TVB3N"Z.Y\DN^XCV?4-28P9"0,Y2>)3DAB-),DE9" 2&36B_1K K5(Y@'-P MU#QBGC 9,^]5_0Q :A'GD!:DD/_Q#F+SMUV_T&7A-)XN!_<>\9WPT3Z80/7 M3@F<)9(S\!X_)'!.XMR&B1D7%W!?,EDL?"SY,#]5&5E9TB&B^B),8B)"GG"RB(B5EDLFD@>K&C$%3A@@^_I*Q9+B-B<*/GR!D?,>)3R]/ M36,\;A);TZV:U';<-M6%)3B1:5!AH+FS] M?4.9].ZP'.[K5P*?VKQ:VM:K<>Y 6D^:' HS9]]\\U[+'-X:*NQ;W7&_"1*; MB1#7>^"E3\:QS )>#JXMTW\"O RXACIX,:L$+U4':RB-5/S^D8K?-Q)B.FOZ M\74S)336WB&"*V"Z&\3]PH"7-8642RZYT3$W.NQ&[FP%(53T:D\FT($$2F0- M'4WHDSJMRSPUTJS50*DJT$)3`\H;P1 !=5Z\LBA>:?/='70,I@23=14C";GL MIHL#WO8TFKS+C;[D?MI-N[-%[Y8$.ICX2H).9&4>X1V^[^@8+8)0'=39(/&: MIHP;TZP.=GBMV6Z;H'2U&C[$9K,V(C9E&SI@4Q@Z!9^E6;0LEQW>MO*\K8;& M_)_+S8DO9MR]0C5!C*L6K6$WW'K=/H-'V:J8?K>CU6CY_J.UT."$B@.<;G]\0YZ_7>WZ?9 M.!,)R?%(CU:(6;.^66[..),^D^'E4B!O[;1&J^/5IPI/62>#/TF?K=Y@KL?] M!78@05VD$RB)*HA3:H"Z6&TAWI**:T"[&$GI21Z)NP)/#G=K%".[LE>5, M.L"[!),T[@3Z'56N% '2[\A(R2_E7H[]6Z*2368 MD,-/"FA"F!1F!$9HH&%',W6MG&01:\V;:,*<-.LF8YC])FW^"AG4(#)^OJO[ M<3S0FKY-+.Q*[=X]"VLI5!NS*Z#^"VL(2F#PUC+T@S!A<[LLMCI9-6J#=^# M36<"?"@0X)\/EDO!XV)S3*7$6[=;M6DDMFZWVC4IVR#Z1=GP!8:HTABA_WB^ MD#1$R>--2A!O/04V#I]P(DYY\^XX:E/_L\]BAPQK^3[R?B!^('V4=]7&(/C" MIPH7M7DT3\\S\_SW`S/A&7TF-A.?[?UN>K[/#R:FA*8H\#DPC*^D*YEO6'.9 M.SW-,XNPR6+'#[;+R;DD:"!3R#T M"S&;-)J=::S=6%#L=+OQ0_-+Q;94I3V7W)Y+D&$)&9:0;B:5>W+OML\:R?'O7+[XU<\<3H6C@50J_H/]6W<_NOK7 MOKZYIX_?4 M]Z)"4 4."ZW]@][D>HV*H94.AV5['!DXK,?!!,7[5:Q>_K""W HI%2)D2F/M M7T3P%*Q\Q-+A9^'']R@\:PF1D*N!8@L4\H"2K2PM5EK-CH9=`T]6^6]^TJ(D MY4;(.7Q7#>_C!DFG>K?0H'!"N)KD$2_$4/CQ$-H10F0Y!Z (:_,QY"86SDTB MKYNHH!LV^'^LE2K71(7Q6:M'75+)7BM ML5>H`&S@'K\]CL9I>J1G5IK57@V_&FEH-S3O? \ZI:-1_VA@W#\>^*<*>3&L MFBH3":N:SB!\"L5>0DRXO[-;II^FD<>_#F\Z\E;X[?"[82;\6"CV!L4WT"W' M,D \RY6>I6JX318,0RS*DX(N=PZ M*;UN&'1S/=IY]6HUG]HLF>GZEO*>XK?7'^V+%EROK?YQV\K/QC87\OL/5,)W?A)G<3`Q2WS^.!["!<&> M+)NY#O:D_[!=M;%MG'7\'K_=FV/?V8Y]=[;/Y]C/O6#[+JM]26Q%LLOZ%M;2 M:&B%%EDM@@D5":V)U$V3&L5\8$DE4! J'S9 J2I!QP=$V[1INFA;.@'JEVS] M0*NMT@1"93!13Z4JU:0U@?]SEXPB<'+__W./S_?V_'Z__^]/(@1A'7:\L$: MV 80>D8,_. ZJ:@N,HY!F=0,4A\N&*$&/UIH:?L*^[2PPB0/DOZ@>%#%1HDQ MT$Y:979I/,XS*VAW)\E1&$-)(L\3XWB.YXL::0QBU 6$XN@$6D3OH1!:";S9 MP0E9*2<2D\D?)0,]"!>200(Z;0MV`#K]G=G_]FE0B@!^@#Z*X*WM`[%/[OQS MIP:E0\CFXF(NKN0H0$%.>\<^$2^XV#L&WT6YQ"YVP M9[C!;\:+Z8(1V_RD]N*IW0>FJKG1?6CGX7;EN\\TCP3/;-Q:W)L32U/O]+YX M^ <]].K.'5F$-W[:FQS9'Z"_/!K @%$1,-H'C&J!ZSY&EUF64A*1U%N )Q$V M#;9 \,\7*9"P?O_>O;8#%<&!!=C"RE,2QV89EATJPN_X5)JL;RH9$;_@V>U$ M).#-`+\U;Z"1\ZQ7_O.?\#O%#]>A;R3+RB:^PGU-^KHT6YY0CC,_8UYE?ZZ\ MEET<^A7U.O,+]IQ\3GD]^Q9SA5WFEJ6K\AO*:G9MZ);TB'LD?:;4%EE$KK*T MXUC#RY6G_*Q:?MZ[U\^&X>=2R<^BZ.5.1\XUXD.GJ&DT'3@1/J5]+_Q]<6&( M;3$-KB$UL[^/K!7?5^AY[K0T)P='$_ND0%)*J4DJJZE4@A-58,$KG2JKR)HD MR\,LEV)9+JLH99:!$4-'PJ$0`Y8LF0#;1$44F9=6$)2GHQP2N#*WR"US?^#" MW R;)2 6.A'G+'.->1?8.\/*)Y55E*4TBH7[C2<:++EO.>_E2SMDC&3 O/53Z)$]+ M?;\U\;!.U'7.MU-S85OR!A7P57TDK#T9H:* :Y_:=@0>]"MH&OS-%4Y+#[1! MO/YV%3);!K\,S0*X% Y2ATLV&0UL"FS(KTC$3!P^G"P.^D8BF0378("M<(N# M$>B 4 GINJ$;(OI-SK &;]W.,/Q0`U4:J5)N<]7:O)8V"^*.X!FL:Z7AS4A@ M8"P?8^,\QB%1W?/XDV!XQ!%8!M@R\*^[XE$58X'J"E%>BM4E M)F3B0B0>(3!OMQTGTQ0V;L)G[0G.7*-TJ)Z[B.Y).:^E\"+T24 0QH^2SH8H MTSOYRU54I4YBA/F3)C)Y_^S5:JU8M&N$.J"5Y%KM;KLK?-CU+B9Z78?W5K,7 M$S8!::[MI@UH,$5L:/91^SA[POX8?VQ^BC\UH^2 2TG7.^Y&MM HVK;UK9&\ M+!>R)<$.<7I>K^I-_;G,^\QSA@'K#FZ9[0 M$W^(Y\UYJV>_)IPA!^-5X1J^9KYMW\ WS _P!^9-NT"%0W1D,)1A,6VP9L1R M,T\+3XN3X6?I0]*SUFE^09B73LNG2_-X7N_9F3GVE5B24Y(D6WI)EC(<\(^#=5A%]X!$ M*KJW5$!QD>P)5 R\"51!02@4-(T*D$E$5>$0(*FTBKY#88I!O^S$S0[<;+EL M\MKC^/,<]%07+Z]1SUNE%<1T!CM99U)&9V7TIOR>_$=0O1^7':!W]JH6QTB M12=4Y*,-O(H$2J<&@>'1#N<98FPI"=M%#/0I0E6)K5L2Y8:]9-B[:.U3YW3?V'E>Z4K/0W[D+3 M,[7%;9A28 *^ENXJ8*7(1LA.J*X0/]4>)Q9K?.O/'_?]/@O8[ZM #%2 V98# MYLF9RO\3AO^-M,",,^.>8$RA+BC%-&DANA6B%;J0BK9)8[($.4ET(M_,/)%2 M)-V_E&EBD@:]O8N#OG20CZ\<$5\X#*(3OFQL"\G6/BH%?1T90#THP[_]74,R MTN/H\CXUQ=R\GC*:J/A5:_-=ZR^;_\2;=_)CXZ G(357J&[\`_UZ;CP3"V(< MS BEU.#&`_39B)94`Q@/''_\]\#$QM5@8*(^0#QCEJ*"?P6%&0L^V/*,49V3 M&GJH1L&I'-"9R[6D$!B#P3)54T5?:!R'J,R:%[P&EXA-9RZQFT,+`PNQ!7%. MGVOC=; ?-"WK#;=1=W%B M(>V(2'3!EJ:C^1EY4D6J@U\HS98"I842*LG8MIOUV@/+,NJ3\+9G7.2&PS26 M:;KLXI3KXFC:,(;KT52]'H65E]AHIFY@F1]S=(D+1ANT&\^A7 %6PK'),D ! M%T52E>U0#=5JJIKGHF QK[R01FD;KZ#8DB8CF>AJ5' [\@7Y3_)].40F2#66 M5P,C5)VBT;K!$U5%]-7"=:E*MP(&EXCI0L_*HVW_8%S8JW-(]X2[7?*.[WHO.M'L M.EV8$?[-?K7'QE&<\6]V]^YV]^YV]YY[#]O<^2[WVK-]/MOG+)C=OQ( MFH0XY' "<;"K/&S'D,3@2A5**10!$GU$",EJ514%)-XUIK12A?Q7!5)4AT_.ZO??+^9W=F9G9G]S?<91>7!J\AL MO-(C]3PL*3US2TO4+/%+-C0\UH[@'SA=+M.C>@JF\.=[`^SX3XFZ'4.3UP5= MC32YB\C??Q6MCP:I0H.KZ"R%E6* UF*!VI)'E8J6DMM>M 4P*U!V*W5%T*93 M,GW;M059WQ"1Z8&__(JLV^B/+.MY- M.O.$T:DJR6T]$*%Q8YZ+MT&4TG(17 MW#7CJKD,8:>NX 2X$&K)K2N*K+L0V9)/]]14P5\S;GH4^O00EDH>GU[@?7HJ MY]73"!?OUP7C97X]77(A?'J>`GM6:>\(VOQEUZ?:#AQ\!;Q\7M"OD:4I4#S M]+.5Q7/M;#SNE52UO+1TIRN09.)QB[?Q3/7Z\6[\5QR5;>PJ*E.>::XK$WJG M6H:%LTF2;,2((4 #42\5)I=!790R!F4HS1LTO[@>3&@?:%?Q*K:]4UZ7K+I2 M- D:-'I=S&R>Y,&-\A";I7W(7F\'0&?')T[/;\M+&!<:VD#CJ_;<2TK_W@,_ MAW#U;Q"L7H,0"KVH;,0T$BX]+RBXO23MNVG&T]GJ/UIXR'+>R@B"Q4,)(>Z.AQ+:1E)P=X6WN\>%<7$B>"QT3W@\>Y8_)YX+G@G-A,]F'Q$?"5Z M"\+W0]_3WH1+G7^PQM GT;1L)B,2PU,/4O<^FZ^[]PD^$@R%%HDVTQO5'N5-50D'H+X2=$E! M_>GA3*:H-&@W<\4-7]P(9[LZ"QUYU8ADNTG".'0=Y'E?2TOTRCLN&]^LD''W;;NZ MB$K%ZR?/?ZLWF^GPRYM&YIE7;VF-.10'[MXTGJO'V$8#LC#/C;,J9)'OHO;(U_A+LFV^JY,$5;ULS(C61S] M%O* A0Q;#EL82\YA[97)C$Q&Y5,R(^<8$8IK*))&1A6Y%N'J&-K"1XJRV=<$ M]D42+^4MEM?$)CLGR7*L\?E;KL)/DG"7GI)-UAMK4HCJDLJJCU=X%#&&"?O4'M2-D M<'5J8'5E4"E_A!M@M;RBX(7GR-ITCY&MCY$.$X&QV\-S2P&B?(!N[H=U8T@_ M3&L8I!FZ+U4OE014>3:'&4#6N8"/TO<7?$AE@[XLWRB:J(@CA(UVD6@SW36Q[JB/1/-4\-A#]NO+S.'* MY2,]GC"7LK*P]C09G.A7%3L)5OX49S/!6+ZOLN'ZY5@V> M[^CL*G1OA%NAI]ZP=^NV[3MV]O7O&A@<&MZ]YZNP;_\=!T8.WGFH_,6=_R\2 M!Y.8^T'!3[5"!-)P&VR&/M@'=\ (WINM5O%^!%*@00FVP"ZC_@A,5ZO5]SY_ MU6?Y7R7VIG?6$P_'ZNU97">H=6Y&_M'.[;,C2@[9TX,79Z<.S,GE,GCIS\LG6P$X9Q9K; $ S@;.R% M"3@!8W :!C$_`WO@%):/P$ED8W OW ?'Z3Q]Z5;_[>=PQJR/PE]QCNX'&\Z0 M`FVP'\#R2UQ1%LLX.>1)L #/(:.E=0O'&#=._B?IL\M4Q(1[(0*S/'W-V[S$ MGJZO%JYQJ'CWW*C<\R$?Y(VG?_A>XUO4OO'N3U)_GUE[3 %>PB)=/^/-_Q@` ML0(_3 IE;F1S=')E86T-96YD;V)J#30U(# @;V)J#3P\("]4>7!E("]83V)J M96-T("]3=6)T>7!E("]);6%G92 O5VED=&@@-S0@+TAE:6=H=" X,2 O0FET MQR.BC-%?0B<,*7E>PN,( M456 ^J0R=JEX0)31V5*>"DO -?LW(&8:QB+;LJT&`>>H0-)?2XBF*5S."EELA$EM MUZ3_QVE-FLT-(\FXEI2KQ4>0=.-:APQ,D]DB+FPN*\'.]TFFDT6Q8"=Y::!!%6V]P7T,8521-)V"Z*,]"*IK@7W M9-UPK^DCM0':".H"J9+\2[F;("D"4)YM5D"::4D(BJU K5HK^$Z36JM D^DT M1E$%O:EVF\"Z91AYED/2C7FE)57<0DLM$F*RUBA/P!I((2!9\*/X.E4[1GT` M19J4H[^YD@29U774U&W=GCU;G("TJLFI9D;@Z MEH.H'0@R!TVK^6*Q6"F2\:))C5)TQF?3GI $B6H@50`#%+13WF?*A6RS,-MN M-MLR3P$R&^)%R='&KF/G8;7C"ZH6&G*J&TQK1O*Z(K!QWHNVQ>?P`2B7CZ6I M:DH`R9Y,IACPSQI(>W@WU1?Z)SRZMB/PO7JZ'9*(^E\3L]O3`$E\&=60]8D* MV$5/QE,QN1- ZA+]-NDZ2!-D>*H_[#E1Q13"1I&>$C%)]GD^'TF]+OV^PWK2 MUT[NN@54TYEX7=IQ8*KZ_DK*D60R2DV-,BDCTQO2P=.=`4F3KJJX0W9=%_/H M"RE(/B8"!RJA2>?W=]CB$R0==&;.*]%"$?2:JN/2]&.H@:^DB!;)%,YCX[TG M'9Y>ZC:9J!KO26L7JT#VI&IC9BZT@>47=V8N$_8"5?5+D2:3\QDJ:GVC*?&@ MPN6H*3 #J"BZO-;T408\ER?Y!-V@U:3I*87B[)(.-.D\34Y PK(<2"S@H(F$ MUYIV,86IHD92[VX"^;76N./JYE;30-JSH.0<4AE>:]K9OM[#BY$T.3>U:Z5J MVRA-<$4$:M=IDA^4I0.'#(E0U.C.57T%CI;Y2#J!CX-'W%T[9/S@Q9"EJB<) M.(FPH&[=?7QF^BC/B]E .NBF*6#$^%?7T]E+(>&R)Q7PZVB*[IZO-"5%/\J5 M57%#4LTEZ4D'MVADE<9JYW45C'T9D*;^\_/S15.\W6;]5-!X%Q*8P6;5U_@9 MCG5F41=)D^YXS/,MN)ORZ#I/-L^'X>F:I&'-8="$9W-5:7<`RC>PA0FY=O=1 M1[VG0+UI I^G3&H<7/Y'#Z/>?K,&.M%]9I@MZAY!=;] M/&A2I]- PE^_03T)PB!15Z0,CBR%&DFSV4ZS^CQ-#FOD'"O="]!=Z'==RLCR MBE3"L1"0):):M]\ML)L33>KK:=4BZ"C/$ZT)_CH<5"?FL&M-KWC$, X+>-&D M#U(XD[NIOK1KX5AI0=)TPH"TR1F>+FP)HFY)VZU#@Y%T1I(Q+S QL?[9Q()[ M(ENU]$3"OZBC.J+];]?U)GWZS!%%4^^L[\F3".]A>&5.S M74S"(&T&4EULE+^\3+JAGLY/2I6Q*&&K64-[5SRO*P$430-]WH75@0]]WSZ4 MBI35.VOXRV[W9&A9Z[+J3G0\;LA)*D*H$\N# M$"NXVA5"HT!667?0L$S3M+Q#5^%(DA'L3A@G$A4[\5FN5_O]OI#9JQHU]JKX M9"%6:2'+,NE1LS3GI51GNBP59TDCG@ZSBA.&C(5+$WO><_2*HK1%3%A ':S4 MS:QG_2/T_9KRE6<37>[U!42$W5 M/I'TBM/4.,)FJ\7,N(V?< ?)N)I-(Y9>2)W+$&72\**JGV SL9@;]V+F96J" M?_-O[\Z(@Z(C+$@TVNY5.[2]0^H(5:3PV2%5?./1P'P1- MKT<]`XO2*X^@C/'1HJ>OL>_WFY=PB3_(BL"C242X=1QB]%%D7!3\7ZL?L3"&29 MS+_2!-2G?O[]R2WD3#JC"R',C 8^KX#(,?QE] #UNJ(F+T\ MP%I;1 MS"-S7*F703.$51)!^[T_G^]R#L8=:?XM?3?/%(OAZ$ M/5(2#\=_`P`1HG,B"F5N9'-T7!E("]%>'1'4W1A=&4@#2]302!F86QS92 -+U--(# N,#(@#2]/4"!F86QS M92 -+V]P(&9A;'-E( TO3U!-(#$@#2]"1S(@+T1E9F%U;'0@#2]50U(R("]$ M969A=6QT( TO5%(R("]$969A=6QT( T^/B -96YD;V)J#3$@,"!O8FH-/#P@ M#2]$(%L@,S @,"!2("]865H@;G5L;" V-S4@;G5L;"!=( T^/B -96YD;V)J M#3(@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" W-#@@;G5L;"!= M( T^/B -96YD;V)J#3,@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L M;" V.#$@;G5L;"!=( T^/B -96YD;V)J#30@,"!O8FH-/#P@#2]$(%L@,S @ M,"!2("]865H@;G5L;" W-S$@;G5L;"!=( T^/B -96YD;V)J#34@,"!O8FH- M/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" W,C8@;G5L;"!=( T^/B -96YD M;V)J#38@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" V-#$@;G5L M;"!=( T^/B -96YD;V)J#3<@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@ M;G5L;" W-C4@;G5L;"!=( T^/B -96YD;V)J#3@@,"!O8FH-/#P@#2]$(%L@ M,S @,"!2("]865H@;G5L;" V-C$@;G5L;"!=( T^/B -96YD;V)J#3D@,"!O M8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" V,C$@;G5L;"!=( T^/B - M96YD;V)J#3$P(# @;V)J#3P\( TO1"!;(#,P(# @4B O6%E:(&YU;&P@-S8U M(&YU;&P@72 -/CX@#65N9&]B:@TQ,2 P(&]B:@T\/" -+TQI;6ETF4@,C<-+TE$6SPX.3; Mon, 23 Feb 2004 23:28:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUAa-00009H-74 for disman-archive@odin.ietf.org; Mon, 23 Feb 2004 23:27:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O4RiGV000565 for disman-archive@odin.ietf.org; Mon, 23 Feb 2004 23:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUAZ-000092-Vw for disman-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 23:27:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12567 for ; Mon, 23 Feb 2004 23:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvUAX-00038Z-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:27:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU9f-00034r-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:26:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvU8t-00030o-00 for disman-web-archive@ietf.org; Mon, 23 Feb 2004 23:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU8u-0008Up-Po; Mon, 23 Feb 2004 23:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvU8d-0008U6-Va for disman@optimus.ietf.org; Mon, 23 Feb 2004 23:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12478 for ; Mon, 23 Feb 2004 23:25:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvU8b-0002z5-00 for disman@ietf.org; Mon, 23 Feb 2004 23:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvU7i-0002vj-00 for disman@ietf.org; Mon, 23 Feb 2004 23:24:51 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AvU6x-0002ro-00 for disman@ietf.org; Mon, 23 Feb 2004 23:23:59 -0500 Received: from h-68-164-80-173.snvacaid.dynamic.covad.net ([68.164.80.173] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvU6v-0004PU-00 for disman@ietf.org; Mon, 23 Feb 2004 20:23:57 -0800 Message-ID: <008c01c3fa8e$3bf4b9e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 20:25:29 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,HTML_30_40, LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_SPAM_ADDR, UPPERCASE_50_75 autolearn=no version=2.60 Hi - > From: > To: ; > Cc: ; > Sent: Monday, February 23, 2004 8:43 AM > Subject: Liaison statement from ITU-T SG 13 to IETF DISMAN WG on Structured probable cause > > Please find enclosed a liaison statement from ITU-T SG 13 meeting (Geneva, > 3-12 February 2004) addressed to the IETF DISMAN WG on Reply to the Liaison > on structured probable cause. > > Best regards > > > Georges Sebek > ITU-T SG 13 Secretariat > > Here's a plain-text excerpt from the document. The .pdf file is attached to this message. Question(s): 12, 17, 18/4; 3/13 Geneva, 3-12 February 2004 Ref. : TD 34 (PLEN) Source: ITU-T SG 13 (Geneva, 3-12 February 2004) Title: Reply to the Liaison on structured probable cause LIAISON STATEMENT To: SG4; cc: ITU-T SG 11, SG 15, SG 17, ETSI TISPAN WG8, ETSI for forwarding to 3GPP, T1M1, IETF DISMAN WG, TeleManagement Forum Approval: Agreed to at SG 13 meeting For: Information Contact: Hiroshi Ohta NTT Japan Tel: +81 422 59 3617 Fax: +81 422 59 3782 Email: ohta.hiroshi@lab.ntt.co.jp Q.3/13 appreciates your information on your recent development of structured probable cause. We appreciate it if you would inform us on information related to this work. begin 666 COM13-LS19.pdf M)5!$1BTQ+C,-)>+CS],-"C(W(# @;V)J#3P\( TO3&EN96%R:7IE9" Q( TO M3R S," -+T@@6R Q,# T(#(S-"!=( TO3" W,34Q." -+T4@-CDQ,C$@#2]. M(#$@#2]4(#F4@-#D-+TEN9F\@,34@,"!2( TO4F]O=" R." P(%(@#2]0 M')E9@TP#24E14] @(" @#3(X(# @;V)J#3P\( TO5'EP92 O0V%T M86QO9R -+U!A9V5S(#$V(# @4B -+T]U=&QI;F5S(#,Q(# @4B -+TYA;65S M(#(Y(# @4B -+T]P96Y!8W1I;VX@6R S," P(%(@+T9I=$@@.#4P(%T@#2]0 M86=E36]D92 O57-E3W5T;&EN97,@#2]*5" R-B P(%(@#2]086=E3&%B96QS M(#$T(# @4B -/CX@#65N9&]B:@TR.2 P(&]B:@T\/" -+T1E09O@ `#`+?##;,-96YD'1'4W1A=&4@/#P@+T=3,2 T-B P(%(@/CX@#2]#;VQO M7!E("]4]-57?+DKTVD[F@ MIJOK_E5U]9=DNLRWRC:OR@O[G\DOI,/3.CSF1D&( M4I*K"?%R7_'2*M("8%5M)%0UV $+K+0H[,""ZMD.661!^RIMG[D6;' WM:<< MUZVL\U3M%C;:$UJ&LVWI3/9J1TQ8<@UMI58H(V_TD<+PY4U50M.FQ*#EDWA9 MMD8-[7S DU'==$\_9$9G=R(7R74+U- 98T"+ MA$Q]C!N-1,L4&$.DM7W=I`>LJZS8V)]WH*@.MQ%'B/533B]]E2)@,K= /2 >'0^7P M-, />:Q^;U&\;*"L6MC6\DWMR=*06GU&0H=.5\_#[TKD)E49+>"YJHT#K4E8 M7K:R7*-?=!RV7;VM&GD&3UV+9\:*>@9RN9;;NEIWBI(1)C6WHJ-R1!CTBE0$ MO)@)9X?176Q=[?PVK5NR6=N#>DM<(>;2/D>&^R"*NQR)7D[W5%"2M#THX#U7 M80BMJC,1"C$B::<6[6M5Y_]1IW4MN IT3"N=)Q,..9#E;@019TX$#O,BF*J? MM9P\_XP6!8;FQ3X+@C'5]WSFBQ.LGQ*-3H<%AN1QYHU)+@;K!-)9"'V?Q89% M=4L1]U# )JN@L+"G/B)R21_72N8/RYE9VE.!L%S<&=+,IO9V`\G\9GYY=WO[ M76\OC8#+GFUQ9PCJ/'SO#_1RH&_*IO%SE\61-EVM/.$RLEPPIW>6(!R0X=J' M4/F--B '_!=N5L!C_,XI$(C&WR?HM:\D!FA"I(,7.A[S! K,\$I9;#A<59-O M%.+A>N F@F@8%YB/'8)*C.]N^=5GQ!WG!"74U<;$H+ 1<'6 M+JC+Q>4,0[A4XDP[#'W2,!W:K5IR;AIB,EM>S1ZN%O^P><@XYHF,LI20U?PR MN7N @VOP!%B".-JWC>_ XGJ]KN]7?[?I*K#@?OZ S<=#`'&$R9W>O<)?,.G" M<>CWV.)3H1<(N)\F'B]]++#0"5GL#)EWXB'S*O[S\J7(FU>HRN)#I4(PSOV8 M8N6'L;?7]*P[O!3R,BTNP+"I:MDE6D$C"#S&1UC3.3$CQ;=.-KI/6H]6\VA? M'$83)7A8NJ3/=.S?+"[.@(?X/SKW_@+N.>(4L^*[CF]=RU*^I6?@3E']5_E4 M=VG]00'S^F[JN\S#;$08#<(@Q81#8=T">S!^ D\]"5 M1&'"K ?YS. "@P^HZ]&ZOYDO'VU=HSQ@CJNT!O[^1&&MJJ[.Y$5?M4=SN5]O MA$-$'UY\TP16U]1['C_)IK%A\&*JA),MP0ZB?.@J2=X6\F+?'!7W81+0/09[ MTKZ)XM#$![DM/G \I($5;O)439AJR*R[K.UJ'$=Q*'E*GPH)64ICT+ZE$2$, MJXI&KK[O!'TKH!75Q`%T7PN$X-OTYXC@2(_@$ZARW O,*^IO_64AS7V9,18B$I&<9( M/G2XP"!_3I&-K30WAOB.5:'[[!5C81,0,2!_+=(G5K8MRRJF]GX0\KBU/:Q] M= *#?*KV-?5X[6N:P*")<>V[OH>3X7%6ER:_@1;CO?YIU_!(E7-\PG,.[HT1 M-$RFOC%ULZ=8-3++\>'8P =>*_@J,^CD!IWX3Q'P&+X.82W?9%%M]0G:P!?= MR=[,`'ZU8WI7TO@<6V,`>*/F82:TP1AZE.;/I!C>JZY8#V;A^[-KR*C1CC:T ME@5RKO7=D3?(6/^+C32:-FQ"$$ GQ:A*YB7A%S&A%L"22$(]H/)9W MJ:"M8!I#4Z_.4*&FZ6JN>@5%BJE.&T*5L; (4A,E96:5&I5[YDO,FK9S_G76 MVH]___O[7]^&`&B,-Z"1//+W8>&3AJ4<`K:6<34I(R<]]UK-G.[ IB! OLV8 M-]>1EE==Q;WK@)?7Y-PI.9\FYH1SS#7SRI09"RP)X/,9YT'9.7,7C/NG=S/.*X%6(3->RTB7#_?,`%Y_ MRGEH3OJ"7)]CLH%XME/?,3,])VM]VCH;L"6 >-[*?6W.7.+FM_EIW7[N[*S< MZ06C*H#.7D!3M_D'M#>'U_]M]$:T!JQ;_(G5JO8,M9Z;T^'T3+,JM1^M!;WX M__L%8R6"4(U"G, $?*TTXJ4[4F!(`%I"25\,$U_XPQ1OA,")84A&B)[R4!RR48([$-'9"$%HC%>FR7P=8]+,=%F8IBGMXC,>B$X9)HW<0H)%N' M> ?0'^]AB_B@/7>\Q6G=H(4Y> M'J MJY%@_8 85!MB93.B?NA%F8D/6/T0-GN"IA,A46:JB59X9 M7KO<.H".]#"&-H9@#&;@8^DH,3*.9[>I^6JI6J8/ZNM&B/'0BK).P88PZN;A M(_IU#A?Q=^8K04;(9;54[S/?M!83;QBRZ<5*[,)A/!93&D@C>4D&XV-4]Z+G@J&?4Z.STP@C(!D[&(L2ZEG,)5 MT=):VM'20!E*2Q-ELBR1`GE7=LIN.2AGY+SA#2L^&G&LKNGD M@I4HP+MXGS'?C[.XQ+J[62]5>,0<_"PV5E-+(NH@3NDDH?1NC*3(?,F7#5(D M7\@MJ9+G"JJ1ZD#IHGJKH6J\RE,/U'/MK9TZ5B_0[^EO]#-CH1E.*38/F(]L M5?9@K_+G6VMO>."9ZBGT;+4B68LV5IX?>RX"@UAS0YGE3,RBS,8\S&>,%C'B MVU@Y)?@41_$ERAG["EPC0]7AK9-[S,2/J(5'%/-IBA?E!?8>S$PG&&>,"/4\T MAY@3S0QSC;G#W&F>-+\RJTS+ML'V@:W45FWWMO>V)]M'VU?;_V(_:K]NM[PZ ML9Y&$'UG_/)MD'%&F"H02Y72[^-JKOY:;93B7VG S">"3$Q4I?J8>G])@;ZM M/U9Y@.&JWQY(%BO'9R@W+QK-S6J<4:WP`_EPHTY7Q]5F%2"]=7]CE5%.UEE( MG#O53657)=2XSVQ,Q"O2$O\R7L5#QK_"S&=,$]0-*59?J*&LY"LH4D>Q&=N1 M)7V(+A,'\ SKY;!VR$'6W3*K1\S=%A&66=49^L^ MN_Z6K,(U_8RU_ZHD21AVXPZS?DDBI+WA,5KC`IFO';:R:O^!?>S!KXP@=M!C M'-812#4JF?.PVK]Y7.9J%BFT[^>N4?6L3$Y>!.YJHY'?5#"2B"+U'?T M?9R5#HSB1=M5;,$[.**;(UCO4F\H2W]I./!'5.KAO/5U\E,;B:"E'$RE'P[K MKJ>(%J8A"E$R25+AXDXBVEDY1+Z;7!1CC;/FV=M/;& 7;N56;R- M'_EJ."2#L?@>/['6![%[0MD_L421R#=LAAJKCR%.6B&7'!A"WA[$&*0RDW-H M)0]KV4^[^(:0;O]Z*=87B%69^#W63'%;*/*YEHARZ, MTS/QD2@UE_?5\6PA>;:,F*[C+IG#JL<5*OW%Q>QEX*>Z7N8-O9$L>_DF'T1? MOI0N78[O$,37=1![M(CGTE@;/FB+ON8=40CU)%E1:JH^)BWX&OJPJD;S91\H MLXBB"?VH17,9B4C/8%HK)I[?0 MKETZAW3J&!SD[!#H:-^N;9O6K5H&^+=H_I)?LZ:^37P:-VKHW<#+;C,-K02A M\[8YK;Z.A,3.Q6-W>F7$GZKXW:DU:LY?JL90\W)_Z<9 M\T(SYG^:XNL8@ '=0AWQ3H?[K,OI*)7442D.<<5G>W4*QU[LAAPTY* M_\M2/U#^\?WV*G@U)BAW*ZF9[N11*?&NUH'_8;U*8Z.Z MKO!YR[P9TP&/3+7 M[]QY;Q@;J]"JB,_GWG/N@W:1 I9D>%$,H(K8QM8CI M%MOHV_DT=%0?" T;?4,^:H\'O9V!SK;-45-IB_$>&4'L6V7._.Y[LVYWL7AF M)'HXU9JC&-6SMNO<-8S#NGFZ,9IJ]?/?6 QK8*Z<5Q,W:K!U'X+8T*QC-_E0 M+&I*A["ESB?A4R7.MR50S9KX#MU,"U0&MAD[XKB:;,.DIGW^P>SL\#GK'TV1HMS_<9<9-YDJ0:[$[;# ;-HB*FB#N" M.X6/7Q;]Y<6AO4/RLX%=/AT"X:,-B&U;K'P1PN_W\P4?'0I3.SIF3V,TT=>I M/6>0PHN",5..LV78L61M9$N/8TE.CP? Y)>(?Z!DF9[\Y/]TWXSIU=O*36G& M?S!O2=@;F@,-C:U1O=J(V[%M:!G72]A+DS:[94Z/1)48_KBM8F_L2E^_SU.&K(^YEE"W)YFNVF6!\?W M*\;UQ[GG-10XK.;+#2VMAC%EG*T&&<@P:@)ZC1$WVH:LGO: [@L8Y_"Y4F#L MJHX[-SIDG3^:8];TQ7"(;5(YV"I3Y4! ZFT<"$N]S:W1<_A=I_>V1 =E28[$ M*V,#\V&+GM.)PD(K)[7RC?QT9RX^FS:[7R>?:1$'(1B '[4+U75JHE5$S$%3FB+$S MT%X(6[[[&!5BW!ST-V#<,I;HYZO=M /V>K07\YHX1R;D-" 3>C_VO\(^0T;4 M7]"3*EDWT<['VILQ-Z@["NT@8K.&]>+L MW50`K,.^&9"+@ S8LY0">EZZ1,]"?D4M)*\X-\:([OJ<*A@>LK[ N=X#9JB=E([^=?C9Z'J)EG,?F"; WZDGX=.GM ZVH/84 M+81^F?P`.+:5%LH_IU(MC])POE:,K0*Z!?>8"YW4@ONP(*>J[U,V;/.!?-SA M63M./HX-^GR_.)_U$?RX@3&-0#-S2_"KDWS8GV/.=Y\A;1H#-ZWKL'T5^#K. M50$\"/LWP>&8F(/Y6+?"YF%A4@+,O10L8!\<\#TY2'"$LH#[;!0`EX"#P!/ M+F KC\&Z11C//.G"FM7HSV-^,#>P%M]#O\%;X'YR-QBSCB2^2UX?T9ZA<_)=YXB)-)OS/YS?AR*0_>)_\1EBJ0\E7D"\`7A]R;0J/QG%N$BX)Z?!U$AFTN20D\QEY[4U;OF7+6Y A<+* M:P/G9ZX/G*.!VB1?'5X64 BRP>'G1)[:_%QG\_-.7MZ62R$C=FWAW)W)[Q1[ MN>TWNYGS(^,GRN3\?GH:9WA#Y.'+F)MXUW.!(!""?9^=1Y"' MK8,B'W9:>]PUUAZUV-JCE5F]VH>0VZR]\GYK9[*FJO2 G0:Y[TKJA/$$K1-VLI2U*G,IXKC)(Z:Y' MR>_Z,VK9?NMCL1[7*TC6L?_:5EK%N<"U4]3>'78^#O'=>S3R>E0J$&,N(S>- M4B:?1<2@GN:)./#<1XEX+?=UFJN6B3CH##'G'^3E>'",QL4B49OKQ9JC(I]- M$VN/8L\_T":&-I?JW6\A9_)>.RF>)G->M*[9-;L.];1.>0[?05XBP?_+Y%5* M* >ULL;&:O7[B'DWQIZTORM8(N^+>G\+N0H<<1VA)O$]P;8?XKOG55K-4/MI MOK82^;$"N7\/Y6IS$*,6"@A>KTGL#7V=^#[A.L7?"?Q>5I!7BV,^WH7P@>L- MKUTH8EL'CJ[R3$%M::=TN5^2P+U<\>W7CWOOE_@[ZO$4_-C6Y2:DY)>OB?K* MMEOR1?FL?-'J$O6^A$+*;U ?/T*.?P5\F$TKY XJE0TJ5=/P;?80VM^C4N77 MP''$8+\UJLY$#J^"_F? 8! MJZ]!C@+_Q+PO49_R`O5I/CHD=UC'Q?J,_6-_9_!Z/ ]8Y$CVU<&D/O^2O)/Z M6W7;SZ2/D_C':_"Z8AZ/*;%&B:R_`'D).=8H'Z,SP&GY3H$-@*H>H%.0Q9 ?`"/ 2> "<$M=CE@"])M.G0OV;=3ZU[UI"90PY9)UGW#'^%"U3OX-< MN]@ZSU#V(C\`VC2\6P_R_E^AWX1Y$_JN!?2T^@C=?S=_[@;IC[18Q#"!\+V< M\5[!WVA)Y"G7)OB?H>X5^POV!*P\J3:1,U*/]$,/I3[S7N_6Q[O94.#QPX%Y"889Z M%>.!B7U/S[^YK];8-J\R?"Z.$\?Y;"=ITRZ]?)[M=JF;U-Z7K"E!))][&67@ M-JTBL;*IR8\1:1LTH4B@E6YVAQ @5:NE(492M(9UT#(&3<\WJ-LLU#^@&U13 ML@HIZ3::T@M;QY:$LFSTEO"<8SO+G(;0P?X@ZWF?]SWG/1>?<[[SOH>8$G9Y MQBJGVY/CSH0F4H-UNMO6A+FHP#?C+K-RK]>8LJZWBO7E:=D6]5>[4_VG.?N#]H2V^\07RX0 M'_3R7)X\WYG[XB-G?E/ZO$_:\BZYF./SX3?QX;>!;V6F/O^?@&_GC\!+P(E/ M=!R<(4T$'(C1LBUXX1<3T&_#NX'=R%&E(-_#810 M]D/P&O!\X%74?8 X@I1]O-563I[*Y)6H&]\(OR> 9+J?\3+H5>C_;\!^X/LH MOPBT`EY ^MV3P7;4OY%N._Y-\/=@7P5_`SB)LLWP>13Z\\#]T(>!?P)/`Z%T M?]?@=^V(S$=N\@[]W_(,[X__E-/O#1+,36]->?O,],;Y"./\.*8"N;0?.:5/YM$REY7YL\P?LZS>;;@/,N.73F&7 MS%]E[BSS5[!ZW^5=(HU8YU63\\K&D2EW*ZLD7P;*,L"]1]; YQ3.VB@]2-ST MX,18.@T3]2^ MU1CY,6+JQ@P>S$&VO#6#W/I0!CZ)W%A\JY@M=G_L6#Y#C)X:I_];.QOGLY@M M+\W-`V:S9^OO5NWRE\YER?&]9Y'QWMPI\ MIZMM;1.GL]]K=@XYWW'AY/>6L>TQLA98EV7<'Q6X1Y8!NS/O+C]TQ+.)'> M M!=>)4?!+8L!&C)WXC;QSP%MD'7@W?0&Y-*(L[._ SL==+'WOS6#+;.B!P0[UQ^86(,?8W-E O. MQ'CG;9?O/=ANV.YCI&DB9>/6NG6&F00O7Z%85"PSCLH*4;[0Z+5QUD'N(#H* MJ"A;H&J(6+TZHZQ(8;S_<]_-'R#)4_Y3OP G0^4'^&%F@ MW$X+5WJ$9ZY M1B^_Q!\F<^!U`5[S=',**B69&DN(Q5Q(,I3K/AE MK/AE-=I[UM)5!HDLY;M)&&!8U//0SD/S\&%HP]BF86S-,+9F&+,81F9+^+NH M>1<^(7Z&M//720+8!]V&+A\16,&C2@E4&$?YHWPG5L+3@[6C*'W,KM5[,]:DY?]:"LJF'?QZ'9"/? M(![0,<%-`HUE[09K59T1[N$;U!_>('1_NEB4WJ:4NX4C?7C66(7%R!-H 6(`UU "A@%\DD?K\(X5? .0\:!;F (L&%# M*C&/2M25<"^Y44"(3F*LPZRC,1*C,1;C,5LL+^:)%1>8=RVI-,R'I%@A105$ M;8NCW1%W\+##=#0ZN,?A=;#D1$KDUU6#S!)[7?5KT;>C5Z.\I#9A3^2SOD@1 M+29#P C 21_UP/+ \IC?Y7WU0_4C];PO.A0=B?*^,T-G1L[POJJAJI$J;D87 MU!FUS;2-QN@>:M-IB#;0C=36S-MXC._A-IV'> /.@JW%V>Z,.WG8:3H;G=SC M]#I9PMGE[':FG/W.O&Y[RMYO/VL?M>]%C,^0^8 C@2.?VD@:@35FZ]&![(4W6:=U1:<23K%,L MQ44(\J5I<9H6*K)N*S>:(V[6B2X[T64G.I&6#C1(:R+%.L1:Z=LA/I.FNNJA M2"U"I9Q*!SD$,&3<'>A!:B'(!J4=4C[N2;L;\JS2VB&[)MLU*TV'S+;EK!._ M#FANM@.E.TPG(V5E2$M*B@M*DNR8>+!$3[(71(4'9*5)2(J4,HZUU^BPDK]2 M^%!QNUGNTR[ZM#_[M",^[3F?]J1/N]^G;?)I7_#)KBJ(EVALD91T MJY(+S7E>[;I7^XM7.^G57O9J/_%J6[Q:G1?N]#*"ID9_K.132MYUI$;3:[1% M-=HQAIN)WB?+Z!+00A&-@!:(Z&90N8AN!Y6* MZ)-ZQ,'<]# R$IVYZ.$"R44BN O5SC05B.!64)X(?DI/TG$1](.NB=9%H*NB M=3'H?=%:`QJ3]"+]!UY5Z(;^7;0^C>[IVZ1"=DO?)$O9+\!)$6V ]Y'TZ$@H MZ^D2% LDC=+M>1'$Y.A!$:P`'1#!`.AG_R*^ZF.;NJ[X/==VWDL\[OGW??>>3GQ(\4CHOBADJA'<5%)O(GB>TIB%L7;BGL?\W>!N%4_ MYXE+E4DE4H'F,27"/!Q4(@TH#B@1+XJ]BN\^BMV*;Y9-W05IP)T-">)1F0XI M"0^:7UE:2)RX5?-VXE4]OZ!$6$IZF),N`X26%A*$;E;800#2JA=9\30BS*=X M7"@ZN_@!Z$E"]5A 7/#V37$!_3[U96";(OY; MSO"@B)^[4=P4_Q$9%O\>R6!9*_X-;^$K-\5/$/K0AT-9+_[),RO^,5$E_M*# M"+E"_(6G7IQV'18S[KOB]4BEF$9BJ<2P>"VA>OB)"Z-\5!K\IXA^>^V.]5UQ!.J"M:[U,-+R;ZQ!YD@ 8_,R"# M=;@OFW!JO?"U/><(36IQ9G)$E@D^OXCR!B3PMZ[7J6*"LQX[5 M)!1X2C:0E$43IN'^0*I-"F>XQ;[46BFMJ>>]#LS M4+!Y(*5S!B!E#I/PEH -P2GZ6@;(EF@&%MF,XQ4I1 W<^"-*>@6P5U:TZIH(NY@![D@0%E M)A"FVT<\:D"/;I\*LS%8VN5"3PD7@Z2;7 A(NYI4\^9ELSMGOIHS7V7F#,"R MW>O*L743EQK!1=V(D?Z/;23P/TR"ZYV']D=#(\[0H#,T@N=@ZM2A45OJZ+#= MGMY_B!GL*8UK<'CG*)-#(ZE#SI%@:K\S:$]W1I]CCC)SIS.8)M'0EF@Z*H\$ ME4ZY,^0<"L:N]QY;._:E6">_B+7VV'.<'6/.UK)8O6//,8\QT!":) M7HJE"IV!E %/9JKKJNMB)KREF:D(U<8ED^W(.D?%'9A<,@FH-CD#9-P6VAW$ M7Q+;^/@$-LQQ,IG+M2UG&)="JAT!XS@:5QLB<4F23DL24K= MT70D$K+M#E9@$7^=U=U2+$DD*1=0D@C&Q%6KA;Y5+?3U>=;FWT7^&GD,Y@A5^IF?(]\,WX-%.1!Y$9Q#Y\\'#FH6:J[D'=3)VF M;8D!"Q4#9+A\3$C)"::60%VMNF[\.RXE);;D_^8`_TE,R[*"+:=7YTGH1?IB MKK0\2.:,$^J4G#:YO('QN;J"$-T*'7[UX9=4X :%Z3PNH^%E"]%IIS6D@--. M`RGC\W335',/ND@^5,,V8I.$)QT+';W"HX[(0@?QXUB8QVY-H\/D,%5C!RNT M9-ZNF9J7=>0IL6NGV&.\+YN@9W1[B9ELDMTGBFX9:9OV/'TK?Y)>RM?!AT13 M^*'!8B@L1&QCL9%CGRP:+D//ROFR`,(VRX%S+'!\+H[1!3R(?\X_MZ:1Q"$. M)7D<'B;!7&HM+7$1DT#HF=$U05?C2^&6^#^S:>C5[:T/=@V16AMQB*K<^N:I5>T+WFC%CU)ZC%_+?I>_E:Y&=!=EAE@3. MOL3*M)&Q*L;71F&AH='2=Q+9/5*)J22?86?QMK;A81)HC:O&:V7LRD;7=-?D MR,'&;#J;J ]U#;R1@J^ &UY0R64-V7O9GVE)U@ZS/TVLR M8)'U]OS&?)I?5G@`(_<*\_'('&$1HX0YP%+ ,8QH._H55O!4N87'\.2E! MC952N?H1L=%2^$3= M+;.X5^+QCHBP$&?[Q6]N?SPW#X\EB$M(V%1LM38WESB\S4VMK5Y3B\OEK.)J MJND[UIZ(N-"ZZJ4-Y>8U]N;U9OA,-_KTRC="JZNKW3U'Z<]V-#CLJV;9BAR+ M?]&\CBN2R*]ED3.6&D>EP]+QDN/6=RQGK>^9W[7>L>CK5OA7T&(>,H!;BA"! M51<./99_@UB-..BO\#WT,2DG/#X5#*86GCT=S"4HZ<RF]6$IV@H[J,IN"6Z3>D5JBEM3B63<92*"VO,U9"I6PI::DL6WT' MHO =PJ[3K#0F/!F+S,4?X49^M&!J;R@KG^L@-K^_?$Z2A(598=;6\Z*/7%4U;!+W-Q4BMEK:D4,-+P:E0\/O#%<_>*? M7S]]:^O+$U_/WL]FW]_8'I <*X7IK1OV3-%)IZ-]HJ/_:V\9+D^^GPR?\K9? M/O+;[._;W?[ZKB+^^Q,#)S_%Q#3C#KF*^2P@!G)!MOD-T R@(5K*Y1?H>$,A MT?(&@UZ?@>VR0* 8+X&>`,?K#: E=V&>Z$@!%>1"'G1\H8%@^4?YNYI\=,S! MH&QKT/JUU*@5_\-UU<]^S[WQG^[[LN_/7Q><[W]G.)][W.5GRZ^?W\3SG@JX(3^ 2$6'N M\T\;Y4'JJ92G"W6F%)&B;A?$?!Z(4E[*[\LZKB>$JSS/-VH3`#DQ)YO(=!)= M"3$']^[+=V^2Y]$_4H@T<;D49/ ME#HC-B,E++\M6M%(+*)%2,JR=_9@1U$1*;JH69%C5DAR$+H`(@%R&,P52A94Q(KBR7_NBW:O;#_VQI8_ M;]G^]H_>J V #-L<:@NG.V.I10!WU)7D$>I!*=%X@PZHMA*3"'6D;0OF62 MER>7,2V79""'0^]=KQ<#@3ASSZ.!<[\K!>YWJ._6;:F_?\FL4Y%7^AM.U3^S M]2O/@DBNA/LTPB]!)$%[Z9 A>*7B.F%8V&[N$\;,7_G/"_3/_&?\$"1-2!BF MF6 YK\:JB9"F>AG 0(_&***L*:BFA*$\;O*";A()(0$3)DRTBD)0% 43F@F8 MYO@@Q_%PF ,6J@R2!KA A5(%P MN1$K]R>T4"C0A<)L=W1 `C$BB'MC8NZ\>5U(S$HCR75V-4B3(DGRX5HB'\M& M!VH+ESWZ(/@H`#Y>VFITSPQ&>W2%@K&!/]T`3^U=Y.2C@L>RO(_]PC7_SN1S MF;C;LA2A20HPBSX#;]5:D1OWWOW0O1)UTR30+A#*W=$S##LG-M58J=G5C];2 M*K3Q19CHO$ Y,J;\)#(1'8]Y-HF;I!%Q1!H77Z(F_2?4WZO7HBRE$/9BY8'8 MJ/)C=2RZ-W;>=;&);;,WQ+=3P_[AZ%C@59[NXD0IJ1&KH0:0R0=+:)MX690X M]X!&<@,R`]:TB4",#-K EJP?7 "==4->_$B)X=DX"]ER.#Q=_K@2/=/855$.<13 1MP4:"F[&^@65(:(R5!2 MV-CQ(_?*5,M_CC[Y=D>Q[^KQT7>&MWYQXJ^U4^>O@557)I[O"^MMM'M3K7GJ MZL'A(Q?.U=[Y^>#X#[=O>@4LG;H"^BYW)]MR6#U1I)XA]S?1Z@!OJ2\RB@IO MXB#@X."P/K AM-XZEIE*N]>+&U%R1#RJO!B@'N-H72,,PZ-KG&'&LCP'C;G1 M*.&16F.\%M>@UNUII\$*&M!/M"P\V]#^$)H,<;]'Q14(6["A72:"0K ]2 ;G MH9*B(I^SR^U!4,^JJ]!,(%2+!=0`&X5]%!?V(=,1(E) #$ JGN98LF$1CE"XYZ'XTS!1G.;PS-$U M.W28"[ZBWU"Y498;?) MN[/CY,&@>YP]2AYE#\F3Y"1+Z<$'Y5)N16Z$=+,DR\)<*>@K'G8=9UYTO<*< M#+I]@*![?;YK'HW6=2UD&$YO1\>'+9I#]0)PS:U1"5W+&":@"!_M)V1!AK+B M!&6%5&E5.2-E0QWI#,CZ?*$,#'DHFJ=[:%A$88(^15^G/Z I'L^)=&?NE'/) M@6U.T>EQUCA;G">=">=YQ^,\+2B#R@&%5"*E',@1O#_NA_[NA![NG*5'G1RS MXJH,H=98&=K:AMM]HV,*U6IAU@'S%72CRT'"^X009F:7>RDIN&=-SAFJH \Q M!$0,:$XTL]!LS)4X)1M.5P>ZWB$1U%A[: >ST3W;!-OVE=?U!^;,[_W=1YW6 MPCO?;UV0C'!>-QNU%[6ZMMC:QN]][9BK-O/>"\_-S-]V.%=[:K!3/_V;6J\E M->QP^P8R^W,',B>=9UE7W>]SMYRW6)ONV^S+*=K0S($L`/\_%.@CJB QEF$:J&!*\IO";?J7YK% MZO/*_ZU8Z]@+&Y#5,<,:O.]EH.M^9=Z#*Y=:O;7'9YJ!ES>E5"3&F04-J+ P M73LRW..;"R\@H-Z:-[IY9N5KNVK]6([W4,+[VJ[QO5&^H4'X;X11G-A?:DV4 MNF)%5M>@841T33*,J*X!P_3JFFB8_^.[^F.;N.[X>^ACB#V,1I(-X@16V3DE:#AA:/'Z.0JBA+LA4C$!/::$/'M*6@X40M&YH@ MJ[8_QB"EIMLJ5#'*NFIEL"ELJSJT36*:FHE)$:(CN>S[;*,&;9JM^[[ON_IGQ3#GQY+)-F:*J9.IARK^DF4#9S/SLY#W4"#G^^<+742*B\6:L'6 MJ(GC_X4KUN +5R"[XE[/HJBO/U2+6C(C6X=WCSV7Q1_:B?\1_JZ;!N $\GA]<21&N",=P][8_AC5VMZ=[VO_(;J"7):2QV545LKJ2VA4&54G MU-?5?ZC_5IFA]IOM5%R(!^)!/L%;+D[@`EP0)9#ES;L7%TU+AYHT&J<8[U M MP\QJ:LXPJPN'BVN0JF@8H;0B!Q5%1OD\0LO46%!58PCG5<41QU&4SU&82EJJ M(O@]"*ULE_DHCJ[V?4#_F:;H:#NI+:\2:ZO]H7;"H+RA<%M[+)[.MI U/UEK MN=E"76RYVD*U1%:V5_$7SNE0=56\],5,YO'94JWH`*29D0R!*20H0F J0162 M#[$UL246/""W7$ [891J3D;*9!IU6BJ-$!J#AC,8/UB@BZ&+3>P/$GE*WH7S MB[/LN(J'J/32SD2$H\-K"TOG.^O^_%UI_K:+?:IDMS8O>SQ-4["8H9;@WSB^ M!EG5I6?GOKX(T#/W,L[WY[IWB,N[+ O'V[+T,XZG=ZU(6<#0D0HLM (YU_'P M64$`7-X]RQ;(4"PS!5Y1.%Y158[M4#TUM(N&076H38;IU]1P3T,;0-_5>47$ MG*JNKNM<53:0GVO&6!5U#S1:1(EA#^?%1#>P> N+V0-])C9Y?UI!,NZ3,9*_ M#/ X8-2@S\\.ET9(`GI)EZQYI*G6!8!P7^>"(9Q_U'G@$H*74IW?DZ,?Y3L/ M7!KE+V&2A37]%Q!:.%/,!'*(X[F5:$0;T@]J!_57T!@WIHWI4VA*9YV:4U_B M3-%&8$G4S5<7GCD;R,$P60P(.2=&?!#S_!@^J9SASR@>!+^"ATN936LV][_! M>X)R%VR]6?0*4A?R- >Z4'7A=F/&!;NXZL*M<[ 'QC^>;1:[:@PK`WIU$\;D MHFT"-#=3(3\I@WIEY*$"4M#(<]BF3IBMP_CBQH=T8^[YY[LU.S[4KV8^O]K5 M,_)O$%9<'OU079O@\9@40S_ MN+AB@!\(C/NFA>G(C>@-95J])7B;I*:82$F,&!65%)\*I(+IJ"]&J*Y(3*@A M1+A%@H2,'@*K'42ID%V8&*&"CU,3[@G/<:;"3E*3S+NN=[V7U6D\S;*4L\GC M]KI](A8ID1'9L.K=&=FI['65F3V1/6J%.R^=5Z?EVQYZ8W-S#CG"N2:O0$?B M@_VU3VW28\.4B]\ &H7>FOD3( M,\B3.F]^@O#F3ASC+3493'HM5S(2E:*4FV,%"\Y)MG#(`Y[H!L_/-%N852BP M.. +6RCJ!)/)=,*W3I5KV02]@H9+4 Y3'K=0<%479HNT4* DH<# 0U47_G[6 M7V"J"Q_#X"(SMN"%V4_9`LHT/IOP?0]*"R>0GV^B="V5]//(!9W#S]=IMI#C M@1F)P)*_6[EB'[./7OD>?A6WO[5M_;X-$[NZ^[?O>-6UA;$'[6NV?NWL) ML[@%'^MY^S7[0_OTY%>7%W'D+_".'B2*IPT8V&E ?Q3:] <7D ;H9PH:0?]F MNK ^B2O2'?&.]HGA7.)1$&8T0+Z!-=5MF"QIY:;<(J 617$'!! #'E['^D=; MPP?#WP=:^\TL*$B9PW%,X64L8GB&ZF.V,A1SP$H^P)=(NVT((<)U9TJUJ[Y. M/+_^BVMD>6T)F&#"/C6V[9;NWW?HT#>H MG?;AP8)A66;[H&.(>%=?._1S0Z+&Y\]3KXQ7OD5.L,_^MNM?@+ P2N)?%;N= M]$!D0-EE.06:\P4>X1X)C+)'N)?YEX4C@=&0;RU>XQLP=ED3;(6O"!.A2>E' MVJGD>]Q[`39,,*01PS0P%FN,?&.4".:ZP$G6X$8,0EZOS\?0+L;-^P1?^'/\ MH\)+W.$`4V;*_-YPV=AC'?%5I,OXLL_[1//;/@RMZ491XOQM=!K,)/HK^IAV M(-J4Q9S?T02WXSEK:5M3%>>G')]UYUQ5_&S13\>O(8_[*:$YDDKOU@DD(6<$ MDBPR>9,R>X/1BT"-R=5*LT);NDYU:K#,E.X06+ZY:,\;9(M,@$D69S;]#9#9 M>6=F=B;3-4,:>P&::ZD.U!X"U#R3U &H$.II=5RF_9?WKTCGT=C^,.7,#'[7?L MP:GM3^[?6!G?L+]W*_/B2YY5R?-GVO ^[,:M^)B]V_ZM?=?>YW+][(3]D7WJ M]1>^XM=&Z(CT?&0PV-*YF/1=N9"/\N^HET+W(OZLIZF"KU^ZD::FL. M`2XX_V&[[&.;..\X?L]S/OOL7F2O=*3&9_'T@($E&HXE&IAY0FME*1+DHC'[LF2:AYK8V!I'-6*" U5K RI]8?!G4 MHE>X$B.^_- M''YZV;? >0,.S.W[;YYT7=IS='->F,ML<@MD$ [ MUROGU+'M$]_%SFQ@_K8A@,B2!7$MRZ)LPH7L2HQ"3K&D#WV6X.X6R[,X]I9GJVM]>=$(ES[ZN":2 M#,G"8"2D##!/L;N9Y]F7(V/*.'N6N:$C"3;E5;//I.&_D>$_'=V;=UE\NG)4]_OOZ1 MN7]]J T_EA*\[8Y@,';_R-"8NFW?Y1,;/W_[H7QR?[W77T-MG^LX_;MG'H[+ MR43@T1W;MKU\^DMOHS,<@<3-.[O7I7K7+7EB](=])V8XZQ)Q,:YJ-YIN*YIN MD3A[F9 0;WEO6L+HS'&.M"AI:.1^*1E2: '!+9/I`:HA+_HX23*+/A;EI5M> M[P._3S!YPX0(.98FA@`N=F,GH,$ MR0$.B_PI0Q/V:9L4*5- MH@](DB#Z>$F*B@D?(37:<8J1>8\'H'=:!QK-*(6((P+H$^8%*+R02FFI0FHH M]:,4E:)9DV""IGPD4HB"Z O)A72"KS57 I7P%)"H3-K"44"MJ" M3)!.$DWA&IE#;B5@;K(F"59"-WS$ND(M0*DTC 1JN!8'1>-"3%R 3Q.F#][6 MXZ,1J1)*!SJ53"GXCKPV5]?V8O^S$ZM#OO@CX$\-V1Y[36?Y#Q?Z]S[MU1ZC M>H*!]N6(-TLA@(B&NKU2^^.//DMKU2?B]'5D)X%H$4'>V MH%HX@4=C`.?P=R*5Y3O=N$%3#G\:^4:*8'S SE#GJ4GCFUS9;.@W[C3NI\:, MX]2X\4UJDINB+AC?X:[:K0NSRUH80-"U1K>+X;+VFFFA'+5-K!31D" "@O:$3Q"V,TX+>`AGKH!O1U^/5Z +=3P_1HS1% M;R2FX5\UKY.^0 /:0EC#3BJY9K% M4I($W%RYN&;9EJY/2P2NX'YJ=0(E2)0I[7K$!-P-[H:.%B0:V)R#`&K\UC:5 M# #4^C9HDFL-GSRX`^"EE;O.!IK:[H=(_XT=P>5[UJ%CIGKN$Y[&=T_,N2EH MJED]NAD<0GW\M?E_DA^3OR*:B0[8K;F,')OH2A_,?,)R8R)\$4 MF**MJ@F,YE\W?#_^@V8#D2_DGW3WYX<]1UWGPD@]KOY4_87Z M6_66.JLR0RI0,5\S&T3T`Q)F#E%O&ES5."T_ MFH=:OC\/\S]Q`5<]_N_"A7#G?#VH5X@VK@VVM5":'$P/4O^@8(K2J +53QFH MNL6+-O#3H'E,'^Z2LGJV5"XI[Q81',M%%$[0L-_#BM7IR"I)]'O4)V443KA* M>8:K:MBP`]_L6=VH9+D;--=AZ^@@B@H8KD[!6U;>QT.BN$FG0\NB]@;9PI$& M%CG;0) )94,VO]U/6$6S'TAR.]GF)[B&&C^P2.BVR)#SXW2##$R5%CHP7GH) M#)>*!+I 22&PLPTB,(20H 6QMF$L8P5$>:>ZBW0.2V&5*VT>3)%0D]U8?4IM M@2O/O%(8F 89CQ9>$O4VA%;F.C<,?_CLV(3'9G'6>.O]+=N["KV6YW--@;IX MRZO'GEJ[_M05>Y>7'HH>FQO7`ER0[UZZ:AQD'U[7 MVI;X-]55']O$><;OO8OO8OOL.W_;L7-GG\]VG/-7DG.^L5^2AJ5 `A4K'REN M&5#6%MHLV0I%;"O0+[I.A0Y-_,$FTDT:T]8I$6$HT#_(-*424R7,)B%6_@!M MT;0QA8(&U:0M8<_[VJR;);_/^[Z^>WWW>Y[G]WN>>)BPR^BC1>XYB/LX?'&]<.<*]K;W!O.^\X_NJSMC8^\J-&J]5@&N7&:"/76+%$_0Q:XY]# M+>?#28\`O:$R*]JM5!OL`)H?AS33_R)#L(.EQ)!FUSK4&+IFM-0;MN>Q",!70?5#L3KVA(*-D>7*(D'?,$BN M&@;5WZ4'RT2"'U06@;(G:)I!2C4G@H%0@.4C;E5AFKQ^!2FNL(("/A@8VA*T MDL;0($Z:0+&:'VK9D8*L<8.O!/.QFWQ<9?F1=6SH:_T[N[7U

K>S??/B:ZN[8=CH.4 PP##<`U7P6 M&7@[SB/>H^JLQ#."RLM"0ZL!6I=VR0Y1=#,.IR%+HJX*"QK257XA+H75<#G, M30.-M2>/^E#6^48&+H'5QP%F6\FK^5I[+@S"B()7J4-@,*FD-@]5.I/.? MW#B,7Y=+L9%:LB"W0D%L3#X@EQ M2N09419WT&E5O"<*8BB:+^397/YWL4MH-^*AG3,F1H$\)TE"],N+$XL30)MT M]A?Y"^/!;\![1&4!:E)H]I.R"7*&)) ,5"GW]PO$UD=4J2DNM&$!?Q=4FR46 M*LUB1S%E?ID^))>*)BWK?0%?AP_=\D8W+_^Q7/0>.X;^*2?#:I4)P^L!/O0I?BHAVZ5R)O&.]5CV9/K7#1>MY](7SN*>%DRBQA187!%S0+)41^GG4'S=(^<>5;$/LLO1BWK;@Y," MBR95`>4)KW$\3F<&,-P$@U3.#R!I0!U@!X9C,MF4Z::,)%F%HGN.LV!OTBS M4:R))%,U61/'DD:&_)\*NQG(;;F*EFV,R!$9!6Z#6(GXW% M?N)O>8D44O5QN3+Q;XB1);IM&+5$[E\V^D%'\TM$;^OZZ<5JS#2V+1F4`8S: M[D6F!*^=`/C@,BK>V(]^W_ZWADI_#+WHU?: M6CK[=I_<9.E+ZSDVA]]Z^KU86]N60N[)$)X<.EIHFWKQW2NE5^=^./[*F=G5 MA7_==ZG%CDUK!T,NQ4^T= W#-'1#I9Y!MRXR_*-[Y^P].9J]ZXJF90W+;LQ5 M=EYVLF'$>'35.Q"XMI:M:7+/JJB,> MC^AJ;([]#.^*M^AJ)AY'8;B5@99-T&(QI]-A:U2MR-KJ]>#8ZK('#WW%].!5 M10\>A&]/+RP*;3"D6F PLC!H.@P0W1XLN\RK'B1Y4-1SU>^09 H%.J0EX:TN*;L&#W4NA M?&H^54UQ9&NVJ]>D%G*'6G@H>JFU.6:F0MG1(S5EAP]$*'!3I5^N5UI :5 $ M$E[[[ZLSDJ=O)=D7@+4 MXGRV8,X$T/$`8@)R@ TG0?B`<=] M4:'D4W,;%.YU!2HO42:A4!OH2TWI]/P_SH!IB+\,$^^-P)V^Q,8_EVDZ0L=>0(68V:YKV.D+$XCA M-&-'_R&[_&/C-LLX[M>^.U_.OK//Y_OA^V'?V7=V[MSKY1*G2=:$<]>NZ<^0 MHBDL*B%C5=G8"B1E(-JB76$=0S":,JV%4J%-95K52JBC6=-L0EJFHG;EGT5L M;!I(6P5!#-: H%6E"27E>5]??XS^\SYGZ_%[]ON\[^?Y?JQFV M_/=;MSZ>>?,A_/$M-O5 _[1I'V;31V>YOK8`JN+W[-W9,P6PLP6PDP/747'5%;<1AUG"KFOV)*"K M?]'#V%W\RGO\RM_DEX#YE;_)+X&H3LPO`?-+^']^0;O=C?7TV&[L3%'\#O/Y M:8*Q=VVN\QL.;-G^;5FT/K-L=2=%R4Z/;+*ZERV"+^;$GJ'!G9O[CB\_MXO@ MJZ3L0"]\H[^P;YG[2B]+X+6+%@F\8#$W@2,Z!_LP3!70_6[J8AI9/)(^'XR8 M842Q29-M"W(YUT?6&R2,SS5M1_ A7]K '[2YFX1!+S1(F.X;<'!TB^ .YXQY M@Z8,UWC0P#_]KO&\01N"I$FTY,YSB&LY&Q)A:AQGP-!PB@YS['_%ZNZ=!-G< M*I[G*%M]YCKVE8N45Z#^1>)FUJ&""%954_,J'9!C\1@=")B9;#JK9)F $)8L M^,J*C8E8IM?W?M`VZ]'?6A MC6BCN(?W3P2:?%.<4/8'IO@I<;_R)GU!"S79B?"$T$Q-L?O#^X6I5! \[=CD M*.@IA-N2S'K&5DKJ`5!'R03HHQXH**ZGB9;W_OZK._>^]_;"W]_JVIB,/'[QU'[^4O('MSZE]\]-C:X2=$'QE'A5#,7QQ6TEC?Y M(!'$2PT][BI2+8@M$Q7%IDF,!F(UL%;8*6%H'Z=4#3IUX)CB%P_7Y.MU1=^O#]8FZKRZU\!N60&MW M\"X_S,^!_?'S2L?0I*=JR6'A81JE0-S3="I/XIFDAH_#*"8JE!57E:36O=1Z M*[5^1^IUV $8OHM>=\(',@*VR#-#4/^\N2*E*B7;S)E6:46J;"%3A:&2KEJH M/5NR**I56B@KKNOJHML8= P\-%--M6DV5_@>EYO*1.X[QH35M)^2GS&.R#]- M'56/ZL>*+\DG]5/%&?DW16E='%%06U#+]F@)#FBBZ\X36HC#3Z)'/ UM6J3> MGA%CT>EDQ_JECTEW0#^H=VT<>?CD`]M_]>C6M9T](P^M,IP^T]VY9GSYQ0U. MJE2B"\D'F3_AGKEO0[[VO;\>./CQ/CW]XMZ^^Z_\9W3UL[B7; 9#]C78`65D M@:\QN3Y.YD7O2 &0(?YM.@.ZO]7;(.X_HW63RYSJW19$$EU+3CBBC8YPAVR: M4\)11\A1*E76^FG!'J%%RU'XB7 M[6D(#^,F0Y4#:BXDC%&AU] XY4/CYPZQ\^QEEH']^)K+464AJ8%*J1BZM]]T MT@T8[)Z\FP@:Y=&UM<%!<\U0(TL&V\ M.5BR.?#>`(G8ZM]@H.R;N/7T#"D*6)MX/(E/)F$M+B2X%X#MI;%GUO2N7;.R M>X@-A7/I.;Y^849AB MT=^WE_8/)[)I/U8[VVXLT.] C3KII]TO$3PV59S)5]`3DA7RA=,-\7 M_R%^(K)EL53I%5=5GN8.&X>+)[E?&K/<*P;GY_WA8#G.#W*;^8#+N3PM=6K4 M,5I#"/<=A/WH\[B9H_O<&'5,JL$-IW;53FG*L8R63F.P0LJA-$K/HL=<0SF6 MN"I)?M-F)=64N-8Y=J6X@[9+5$$LT$2*%R/&S D2G )K]YJG+@#7-\-Z&\]6,A[MN&R MVP8S%+X(3^,WGX8)2(0Y2(1I<#QS:R9[=(',X"K(;4_!"F:C,(@9&"))&,() M+W&4:BSB/U)556BHLS?^/,W+7H0,',] .DDD>:]2?M!3$N3Z54CTJY#EEV^F MB%>PND;BXK5%2KR"@><*-3<4;=3<-@$&^!:" MKBA506' U=MN&_PH54%TE&9O_'L:6 EQX1S&;!9 2MU2-Z/4)!P%S"T`%XH9 MQ"#A=N2[12HX"@;3A?L3X J.AH7E?E=G$M_HH9\3]($GUY3OD?/('!LZ.+)V M0N4*B8*H5W^QOF.@_Y&CU7L/_WC+8"8J)5+,&\MO''RDIYA1RA=_-#)T9+C" M=:+A`P=65SK6#S[:^[D=NTZ7! &:$V7>N$H?\2U1"O4S-S+%3?$T&3B>4F;1 M#)3')\M,_$D:!?)[;6>$HYE9%'%S?FZ&3V>0ST<)?LU/^RNQ1'R/ M+,=<6/P8WD]B3G=JL;G8?(R)*6E,#MA[L+P@!*\1K0?B;DB$U@*75&-I8:S1 MOX3OP242+X'"GZ0F4;0K;A#.=_8D/6AT1PW@1 ^:_> #P137W*-NFQG=%PWM M?>+7]_J6ED_M6'I]6RVW(S&W8T _@CXQ1G^[![.Z<6/!5V=.4#IZ]E6J"&_W M$JC]XGR1;N,S?(7?R/OZ^)]G3V9GL[Y_L?\,TKK+A9T"'L 7Q< 5Q7P?LNA_ M[%=M:%O7&7[.E72D1-:]U];WE7(E6]>2;+F2Y;,VZ+C_6EH9L^U'&R,8@(^N/4O:CM FAV:"0P@89%%(*93 &,[2$ MX>$U+>XVUEK>>^Z]CK>E7=I1]NN>RW/.>^[YT-5YSGG?YZQZF;@093**D0IF M,KJ1:LMD/'0;BL]M\&_THZV-%H"#=]K16>="O'-2\YP$/!<"G@OMSH5LYT*V MZK2: M:6;#EO"BK,5)/%PS6,IXQ9!*QDE#,D*I, MW*L*O7*:)95O!R[:"EZW)3+<3 M)"%_2V8E^9K\ENR2XQE;TJ]=RB:%I%]3AB(MU_^U)D+$DJGIZ3$5HZGGZX]9 M5]N">29.W;['B:.0S=JQW&:];XM9=;V9'VP\,_SK6DM$B36 M@A;F[M8/1 _$9O37FA;T6[I7%Q$ZT*N+/YY-IBI#D>G(/N[RRKZ4UQUET40L M%;5889X4CZCA5.3JZKG:$07)="*9'%74D**H##BHR&3)29G!S=4T.0A5.,MN MM:9*:B*J)%1%9IXD!3VOE_,D_(F_J4]V*S5E1G$I=7F1U6B(&5[2["*3Q&:Z MP5QL1GS9Y8'IBOF%B4RNHM<"2D75'](OZ@NZ6]79*_0_I$VD$UR76]^@$U>P MV%A^C,[=2GRYOAQ;,F.UX*,E6F7-+=4J-9%YMEB0SZB_/NLIQDRC$(.ZQ-1K M5E[_]\(DKRZN8[6P+CY6%Q\KJE-YY M)J-M:&]OCNCMAQL_9Z6G^U(YJ;V=]SV[TB9.>7-CU+5$/)?8PU>40"H@-0FG M_7(PO,W-0FP M^::?E%["2]KOX@&:-5 *-)5DWN1-\7 \D@JK'N9A[A3%EF JU!G.Y8V"7"J- M:O&0IL6;`H$8!9[ 0; 0`C(8:RUI<3G0!&\X5X(A3.;Q:,9BX7E=,1;U<(@B M@(=K\#]47BC?*KM,Q1\(Y2OE:%13PJ6P%"8Z:U%/1TN=:I'7,C-PNG;E,]J2X-+2TU$\U$.!-E2_6LKUBP M*)=MRF$U5C^->2OW^M0!WP"Q7Z\74"<:;=;N(%$2%R\KA$6BD:AUD-F'C;=' MMA?9!^5\S\5C]Y:WL6IQZTCCH[GRCD?VS'^ETC/(F,^GQ!+YOJQTY<).F51X M6RQ[LO%#EOCQO>U=Q+1G\-65B<8G`WL?'-ZZJS:<]?LW=9XGCE;?9Q?D^]B:%)NJJRUMY6M_KQ']VM[ *%!3L=_?Q@/L*+ MGX*_KD.Z;L$=(RS>"=Y)^,5GP[?/PH8_`?YO`8']@/S).I2;ZU"I3\L?@-"O M@,CO@5@2T(X#R<0.@BD%^]$V\QGHWVGA>R+%O(C0,C]-K#E.Q:J:6!@`!C,`T-98+N\CF&?@R\=VQPX<.# @0,'#APX M<.# @0,'#APX<.# @0,'_PL@@4&D$%S"8AJ!XZ[)99?^)I$WB_&1J#"3FZP& M`]EJK=_^P+RNY<8WR3J3)VDAY!XHHHX*MV$Y?/H;[\0!F\3 >Q5&9/KKCU\.&S/ MZ4*<1I3 ME#^!W3A!]5E:V"[<1_91'*)WI>7^XN/_'R/$2O/OX4,,T M.*ZNB M1+L*WK.TBUQ4IT5ES\,#GYLL45LK<5AJH>&WTW_2.T0)-=J'YWUBFC=]O:[3 M-LNT-R[TO#WUH#+PD2_N,WN_\&[OJ"A_^?>"F5N9'-T;.<:]8%5ZQX$!M7TK+RN#6S9$3#A=- MVM(Y<]O[60O2YIVO7'H\9^6]_+5/)JP]4;3QV?*-QS]OVU&Y_<6 M>N!2Z^$WRX[=ZSGY[L_),]O./IA[[NVD\Q^/GK^[^NK[F=>_G+_Y=,^M-\ON M?=]Q[_.O^P]O/'R][_GKW\>OM3W^>?OW[[ON?[]]_ M_OO^[=//O]]___WWYP^0^/__/\,H& 44`( ``P"D)6PPV,-6X"P!I U;&&1'011"$D(`1)"2-@%040% M%$5$A*J5,M9M=$9/19TNKF.M#M9]ZM(#]3#JZ#BT%M>.G1O>=\YCG:Q J-5H&S*6>=0J,P\6F< M5]<9E3@CJ3AWU:F5]3A?Q=FERJA1X_S<%*M1RFH!0.DFNT$I+\?9#V>Z/B=+ M@O,"`,ATU3M<^@X;E T&TZ4DU;I&O5I5;L#SM.3S+F> M0?P+;VT_YU<]"H!X%J_-^K>VTBT`C*\$P/+F6YO+^P`P\;X=OOC.??BF>2DW M&'1AOK[U]?4^:J7&W6*M0&=;464VO_4Q-_ M9=A/-#_7N+ACKP&OV >P+O(`\K<+`.72`%*T#=^!WO0ME9(',O UW^'>_-S/ M"?KW4^$^TZ-6K9J+DV3E8'*COFY^S_19`@*@`B;@`2M@#YR!.Q "?Q "PD$T MB ?)(!WD@ *P%,A!.= `/:@'+: ==($>L!YL`L-@.Q@#N\%^!P_!H_ ^^#!\`CX/7X,GX8?P+ (0&L)''!$A M(D8D2#I2B)0A>J05Z48&D5%D/W(,.8M<02:11\@+E(AR40P5HN%H$IJ+RM$: MM!7M18?17>AA]#1Z!9U"9]#7! ;!EN!%""-("8L(*D(]H8LP2-A)^(APAG"- M,$UX2B02^40!,8281"P@5A";B;W$K<0#Q./$2\2[Q%D2B61%\B)%D-)),I*! MU$7:0MI'^HQTF31->DZFD1W(_N0$8C%H7E MQI*P9*Q6U@CK*.L&:Y;-98O8Z6P-NY>]AWV.?9]#XKAQXCD*3B?G`\XISETN MPG7F2KAR[@KN&/<,=YI'Y EX4EX%KX?W6]X$;\:<8QYHGF?>8#YB_HGY)!_A MN_&E_"I^'_\@_SK_I86=18R%TF*-Q7Z+RQ;/+&TLHRV5EMV6!RRO6;ZTPJSB MK2JM-EB-6]VQ1JT]K3.MZZVW69^Q?F3#LPFWD=MTVQRTN6D+VWK:9MDVVWY@ M>\%VUL[>+M%.9[?%[I3=(WN^?;1]A?V _:?V#QRX#I$.:H"6[[;*;=SMOL!2(!4T"?8*;KLSW*/<:]Q' MW:]Z$#W$'I4>6SV^](0]@SS+/4<\+WK!7L%>:J^M7I>\"=ZAWEKO4>\;0KHP M1E@GW"N<\N'[I/IT^(S[//9U\2WTW>![UO>U7Y!?E=^8WRT11Y0LZA =$WWG M[^DO]Q_QOQK "$@(: LX$O!MH%>@,G!;X)^#N$%I0:N"3@;](S@D6!^\/_A! MB$M(22@A-#:T+?3CT!=AP6&&L(-A?P\7AE>&[PF_OT"P M0+E@;,'="*<(6<2.B,E(++(D\OW(R2C'*%G4:-0WT<[1BNB=T?=B/&(J8O;% M/([UB]7'?A3[3!(F628Y'H?$)<9UQTW$<^)SXX?COTYP2E E[$V820Q*;$X\ MGD1(2DG:D'1#:B>52W=+9Y)#DIN2S=9$U:S MJ69&GZ+?60O5+JD]8N#A/U,7C.[&E<:INLBZD;KG]7GUAQK8#=J&"XV>C6L: M[S4E-/VF&6V6-Y]L<6QI;YE:%K-L1RO46MIZLLVYK;-M>GGB\EWMU/;*]C]U M^'7T=WR_(G_%L4Z[SN6==U=VM MZ/ZBQZ]GL.>'7GGO%VM%:X?6_KBN;-U$7W#?MO7$]=KUUS=$;=C5S^YOZK^[ M,6WCX0%LH'O@^TW%F\X-!@YNWTS=;-P\.93ZSP"D`5O^F+B9))F0F?R::)K5 MFT*;KYP0)ZNGQV?BY_ZH&F@V*%'H;:B)J*6HP:C=J/FI%:D MQZ4XI:FF&J:+IOVG;J?@J%*HQ*DWJ:FJ'*J/JP*K=:OIK%RLT*U$K;BN+:ZA MKQ:OB[ `L'6PZK%@L=:R2[+"LSBSKK0EM)RU$[6*M@&V>;;PMVBWX+A9N-&Y M2KG"NCNZM;LNNZ>\(;R;O16]C[X*OH2^_[]ZO_7 <,#LP6?!X\)?PMO#6,/4 MQ%'$SL5+QHM\IWZ_@-N"]X43AS.)3XMOC8^/KY'/D_.6$Y@WF MENV<[BCNM.] [\SP6/#E\7+Q__*, M\QGSI_0T],+U4/7>]FWV^_>*^!GXJ/DX^\19M MR8V0!)'K4<5HT7@M\6@M]9A%RAB-5D=OM!0U;9C2017U-NK14H\I-:J66>*> M^9)YK';NM_Z[]CEGGW.^O<\^WX$`",5<:&0,&!S7(3M]Q#3@>@Y[^X\I\/F' M/!R5#5S+`&3^F.G37#][+L[CV"7 >6B>RH^U/=1T#-\VRWR"N8-J.L9]@1MBN M1C$3"\?X=-&YC<"7+=CV%/AF^$.5_)[S4^COFN0K&!M[*.IS]I_]\0!16XQVTP'UICP,H1Q^\BQ>0@57HA>/X$#4Q4X["@ALI MV(HHB8!"*L+%QCI^!&&+N8V_].QV.RA5PB2L1U[ M9:(,1ASM-.61-MQYA2E'.&+,,7.>K0VX(2U,&=)H_8 Z:(DY> MU,1Y'3$5E M!I&-4IDMMQ&)+!1;\=82,P%=L1-G))U6/\RTSU??B8FP&(RWH%RU58GVQOA0C2>1W_X./H[7)!ZTEXGF9:FIUG'WE(\4&W4(>TD MCS;HC=%8ADW,QEESG'@^E M'7VX@VZNIUG-K&EVAZ?S&&$.UN,$3I+'9>;]%SR6UL0U];J:8X:;K>8&N51# M!!(P$"-1B.EX%7_@J1[ %_B'/%'5Z7G<.FC/LN^;E]L^>YO3%YP4/&G2S7SF0N @KY;P(!Z=63_C6$T3R,]/ M3,%LS,,2+&>]K,1&;&/;3RT$$&P5?#*X.[@_>-,/,3/*/0BS:DNDB MLES'&MQ"O,]*W(5#^ KGJK@^$"4V*[ZAN%D-'IY:#^DEO8E^,I 82@R7D81/ MLB6/F"-SY0TIDOFR3-ZNPEK&MD7>DUW$)[*7."-7Y >Y(P\4BUAI5G.4:JGB M5!=&FJQZJ0%J$)&K"@F_FJ*F\X1*U4=JCSJKZ^DH':M]>K)>I[?K`_JT_J>E M+(\59W6SAEFY5I%UW#IIG;>>V!&VU\ZS2^P#CL:.>,=0QWC'6L>'CEN."J?# MF>',=LYVGG:::E%4JR\9]T[\^A?G."Y3[?K6#'6%]Z*A]MN+9"@SYE!#]$2] M7']CCY/[VB4798G.UQ/,9IVJ'NM"&:8^E^8ZPD[4X[ 41K:I:^JANFDUD"'J MML18;\DGJE G*T?E)O8IJX%59-\"U#DDJM>D7!W41;K(_!F)=HEKO!6+U)K..EKE:^*,<**MY\@GWE_SY[!?'=7BZ6U/FV5X(9VJY_EOJRF M:AR3/E8+-4IUD6U4W*?2#'=E,OSR-I+D4_E6=D-DJRZ5ONH9GE9 A4IG/D+' M=*2YSBA.XI0);[!+-'2CK7SWU\0DW@#5JF6U#0O MU>24=$!#K*'>/PSNJU1L^[Q=S#K;I#T8A'9X61U%(N_($%J(#]K(&%Z.= M6HO99J[D4/?[43\5=LMXQ$D-JF4XNQ&FFE,+1W/7Q]3_(U3]=+F'5\7% MFU6.&*MR9*GEI3)E47^+B1R\S-9ZK'3LM$]A@(0#EBM8PBJ_A%%\<[[G_HW0 MC?Q&8I/E(6L7E7DR9ZP/IB&)6(BCHO :.7?G/<^PTJB\J\UX1IC/-ZHOW\3# MR#=KD,RS&V2*3#%&FTWF)>1BL-E*_9UN=J 3%MF9:IC=QHJGQAZ6+_@>_4V* MJ=MIN$@]BI*&N$-L)__N]J=88IVC=O8P2\T9-& ^FC-#V7Q%KZ,`]YBW-%V. MYX+]59E)U7Z^4%PMK%TD]1PZ)*E']^>[ M=4WLDM"Y4\?XYSJT;Q?7-M;3IG6KF);142W4IM5S=TB_6XO&Y7X%B*V[5;1@X<07M9 MBCO3%;A;9?>KLM^LLD-I1T9R@LO;,"_%%9 LES>0.CUOB3/ M#8GUH"RD!LT:M +A;G^9A'>7*D.%>Q/+%*J%DE2@D3O%&WC6G5+)(*"CO+Z< M0,; $=Z4QI&1F;&>@"2/<6<'X.X9J-6FR@7)_V*]:F"C.H[PO'WO?D)L?/[A MSV?('8\SLL_&_)2?,P6NV'-\H856 MM?S=[,[L[,[.SNSLD\N8[CK3(Y<)K./=T)Y ;]6@L;??1ZM2X;Q.O;.C/6&J M'4E>HS",=>O-<=_^>/R=+B8OJDOLRI;Z52,V?EV NX:Q*V >:4ID2X/\FTQB M#E.$XBDCCH7WPH6-S0&L)78D$Z:R`PL&>!^\)WMW:_08T07I1EY^=F--1B9;YK'/VOF MD;%Z'H;A+ZE R^S$>:PS'ZA+&;Y:\'VL;[I"/CU@W"2DI''+]) M_'TQQO269_X+?&.+8VMK367L?Q"OL>6-S7IC4ULB$#-2:=\VMHSHV?)Y&5FZ MI=@".-S40O#4$AVAM[PMP0S\NT)Q/;8NU8!4@XUF<5U"]8NDW1)^54Z%^&W/ MS,R=1![/I87<,OX[^SU>!+#D*(&XZ4LUV+_)4<'@?2KU6Y^QEB1WU-)[,FO# M(_OS1_1'F)=GJ#!8*Q>-+6V&,6J$+([+RC#B>B!NI(R.?JM[E1[PZ<: FE 3 MQH98RCG^?NO4'K\9WYO$)M8JM0AM08M[=65W4V]4V=WSY KF,I,[`>Z@OB$K^H17CO!_RC: M"X!\Z'Q91*S5:!>BO0"^*40[#XA![Q;K8'P^;.R$O 1]P6.Q;CZHG\=BS@KU M@N)7#N)-=8%ZM18J@7RT!/;->W;VQ/:S3?\&<;8O&[9]$FRKN&/;%R!RL$:= M)<]J>WJOA\0YVJ >L:ZCK;M+*,;P7*!)V-\G0$3KI F>B=9?8>,2UYLT&WTO M,%Z"YSQ$.]4;%(4L['X%<=-)"\4,"&9;M\5W:*([1 ]CO_ W387M28X]Q,(4 MC&N6^ITT2;M,I6A'&5ZB/V?\!-_@[!M!Z^#WJUZR/L4<=0S,,P"<@?XXK%_# M/N!S5UJ'>S#V"F3/`!L1(Q. <9#OD3$,'=;'.E_A->QS()^,08!C#YCI('T^ M#AYT(/U_7&(L, Z8"_"ZKP`_!QX!7N8QF'C_1CH7/CGL,S! M:]H/Z&.Q@X1GD*IPEIR[K^;0`PS/D+(>\PW"E^7:.7I5TB$Q61M27*X>ZXJK M1SQGPVEGTUPH@[:,*2-;]M_R_Q>(\ZX>>A+MO[F&+$L;HA>Q5_+\79D.!!P* M?A_0#51ZP\H!;Y?2[UE!/L3-#>!I+8KOURC-U09ID39&YET(_!68NT;KHOG0 M4_&E]H*Z@HZZ>^A+ZA#.$6N)\_0\@^<'W9")H]R8^V(L2>K$ZUTHYT"^0V5. M1:P_R+R*6'^4.1FQAFU*$:X-?#_+^D#R;BYTXC43EZ]1N7HS*SYSXC0K/N=# MSY<;EUET---T;-S:4;_./6+X]8'\AX^ M1VU.7@,S@!#DOTC?([B'<=Y<,_=9[>YGK'9UJ=6.??[4O0OTNG523+5Z,S4U M1#/3=UFI4TO93ZYS5):IHR%Z-'V?A;B>:L=0P^TZ6BSKYU]HO.NZO-MF2GLY M#SD':W#O344=_X=U6RNBI]07B%3D)?,1(TTLT[PT1OT3[MREM$D];/U.W2_O MH)@Z3$DUC!R&+GPVWB6HS%5/C= A.1^/`64>V^_6$)]\%S2@C[-R[F4^>_=M MR@>FNJ[B/FK%F.-RKR%YCQ^@*>P'J;L9=05S><)4I D*I\>$I,XW\5Z0_L = MF.6+=&U>R'.ZE\N8+9 ZLZS;WB**,%ROTQRL'Y)K-5"M-T+EKE;KJGQ7%-$C MZEF:KC;00VB7RKC?A1I5@7K9@/H(J!\!PXA-G]V7M5I2ZY:L]]MD/<]SU=!* M^9Y@F9LFN2MH&D/3(4M1M?HZYGD:<74;[3EZV 1^@+T>UGX?II7 M9E,E*-ZC5BEKH0_%:7%"G+:Z^!VHOD]/J#_$^9V@H-J&^OTV:N-\U/"E\-5O M**'^&NW)X!\&MN#MMXD*M +J5"]AW$S(-D#O'.8X"CEC)W0N@KY!"]1?TCIU M$.^#2_Q&H*"V&?1QH)[JE!]3E[A%7>XYJ,GSK=?D_(Q-UMZ6MV7:RC7>QC^?@>:4>QF@:%1!9%X&038>;Q#[J`8Z(]S'V MJ[15.6:=4@Y17+D,'$KC)]0@:2_0A!R;K3P+3--FT\^ [6A7@9X&3MA].@A\ M`.S W&= 3[KQJ< 0BQ'/H. =!@X`OW)DV>"U[L;/ALMOG1K1?PNU!E!N8 \W M1LKDFMMI#M:;HRVP3C'4*Z@A@'L;E7BV4(DZ%?Q)T,OIN_RXY]ZB*?>RYUY0 MWJ7ITHSQ_L%YR[7Y__7?/<+G.\VX'%IPU7 MC+L40+\:_6+'G\XY@?^2Y.><'V*%5++^F>>Z[WZXB0]D0TG#C+Q\"(M M9&B+,![([7O?H7]Q7ZVQ41U7>.;.]=U=ENM=%D.$C1F;]6(;+[%92DQ@&]\E M)L0/Q4Y#@;A2EO(($@_9%-JHJAU#6UI(T]H-)!!(L$-Q$]5VO=S%9'FT6*I( ME"@!5ZK:JE+!M%3]455U'E#1VKC?S-YKS#K(<9K^J5;?^>:<,Z^=.S/GS$," MVD7X+H[7U=-UK8;D"RAYF&NF:(,S!XSJEW&O`J*N;*\C M7@+R[ +**<1B8-2_&'<^,&9='Q#KRHXD_?;WL;]+ZO?!_ SU$E"'?/82*0$_ M`8[8/+J_K?OBKCW_>'*_C^KB+OE+2IT[9^+.V?_T_ V7D7>!MXZW\] M%B78JX 7D#GJ,K)"6XS<!\85\W0;=A'$$<8^)B:B?R=D'T`^KC=D&P[?!-X)MG'\#E"_OU["[N2[8>> M!QZ!#YG9T"G@#>#G0#G:V/W\&/H.\*^@KTSV-83R\#7@^T 5<"C)0\\!PN_" M&+\3^<@GO$,_5[[7^^/3LO7."-L\[@TQ&5[VJ?BN-X?]_2=B^RWQ"2S7P9J_ M-F8^]WKCW,78/ZZQ0"[M%SFER*-%+IN&_%GDCZ,LWFV/2IYN]6.S1\1 D3N+ M_#5M$7+FY#NO:,Q[<(4=-\;>K?1C<@SP`ED6;T6=6WCK7$)L\N!.O8'_=T) MQC81UP#,][+T_W;D@J@#?A]Z-OB&'=/LNW7<'3M!3/N\]+*8*'9_YEA^CQ@]-D[_M[H=YVU,E)>.RP,FT"?J;[)Z:MXQ M:3TE+['U5(SSI^X].Y_)))FC2#EWDX5X6ZB]=W)_>PZIYWCTO-EOA&;$U#' M/5" F%4(',=]40)D`S[@!=B>=0Z1D+.;A*#W`J=A^SMXH_"!V^@/<;G='!F& M_FWH7O5]67>MA8T3[>?4?2OR_M7A[8NR_ M*N<)$>],']H<&(#@-ES^*FIH23=O9'$@,48K _Q//FA=HNL/?@?Y>]0S;* M9N^8^K00.GR;O4E\A+/3K-?R],;3IX5(9"=""B5]D/W `# (J*2>O4Z:@1:@ M!U")!Y(#Q4"-L+!.UHEY=J"]![(8J =:`)6L8C^#?:N0[ VVA2-F'IF[!R35BY)J+"U6C7:4S66< :4:<1=1I1IQ&K4L)V M8KR=(EF ] (Y`,.Z[\2Z"WL,L@_HE_;O0K8"[4)CSV ="S&K_6R+6<"QR3;' M'S1"9>?8TUAJ@ST=GY4=:KFCN::(C0A.M]@CZFZ2WDUQUU1AW13/S$XR:FV- MI+,-Y%N @JMQ`\D#O@"4`RK;8.85\[/L,;+=28QTWJPTLV:U.4TM*:>^"RQ$ M:I%)<^)C"T@8%0IY-$Q+U[D:7+M=S.O*<96X#%>M*ZV>-;,6QC@K9F6LAD59 M6F*DSW0L700R5FI+%[6ZV]TQ=Y^[WYT6T_JT?FU &]32KUNI0UKD;W+O=S.O.<9>X#7>M.XT[:'MD+UN/OTD@O4 #T JH6.,H M[#GL*2"*KQ'%4CP%.X$DT+Q /\H#X#1H'M3SH)X'5@^L'E@)I/#4`NN !LNK MC7KL-J+^H/ `>!:P=%C3L;8#D(.B!%1"TZ'IT'34ZE>&,$,O9 Y0"S!I&P"P M:R!M7XGE7P=HTC\HZ]@^0[15AHROYO<5TE@A;2^DK874")=%0L9<")_/%_5' M`]&":(=:[Z\/U!?4=Z@U_II 34%-AUKF+PN4%91UJ,7^XD!Q07&'ROT\P MX MA]I2W5-]H?IRM1JMKJ]NKF:E^'1QLZ@D)'EN0'"O.2LS5.J)+%-Z\'>BD&W M58 1#ED,E 'U@*KT0'*E&]9N6+M)#1 %TM"B6UPOD-SR"7N;](F2\"MW^1G^ M>)>Y=%%-I!)7;A1H`QCZ[H*_2]9.EGJD/08Y(.TU5OUV:>>0=AN&"ZY.7G-U M.'YUI R(`@U &KG,UI"K`'J&Y$ #T .HK Z_-6R-THU?E]+%@H:^< 8G,V<2 M0GS3G-Z(5YF*/: CN IY6,K]4I9)F6>D5^HW*_5?5NK?J]3S45 *2 2.@U+F M&NZ(?BJBUT3TPHB.WNXCN4179DBI"4G_)N5C4@:-C%S]5J[^4:[^0:[^:JZ^ M(U?_8JYH-QMG5U8:;ZV]Q?0W72[D>T>DQBM')D'#U1,US($PJ11$?,< 1TVPRO! V;X6.@?YGA`_P\O45E M2*,WS;SK/#*#?DPK5*%_9/$'M()T@@?!F\$_)6$:`)\PPWM$_9^@_1'HQ\E< MIZC_&JF5[=IHA;2_:K5[Q0RNQZA'S> W,>H1$I2C'C*#UV$]8 ;W@UXP@]M M+69 3'"+&9[/(]/H9I*GB+H;2$ 1,ZFV1GP4/6\#KTPV7F$&1:MR,4""/FSZ M%X+RQ2S/4S^IE<-QTR__9#;QRRYF$[^<=!8)2$ZG'CEYG]"+=BIP MG?\S?$[\<7*#>LQC_,_G\?]60_T3K3 [^:_/B.4R^>5@@@9.\TO^<_QB7H*N M-GE?,.&$XT(PH=!>?A*+'$-=A9[F/<'-O-LOO1U^>/&IV\(+^%%_'7\Y`-WD M>X+GQ33(=OSCU7 _&7R(5X<[^2.!!(7;"&,P8PI?ZO\:?Q#F)0E:$>_D"_,2 M8BHEZ*/S-)^/$>?YY52^7'I664P<].M&T+'+L=ZQVO&X8YECD6.!(\>1[9CM MR'#ZG%YGNG.JFL2JEZ8CF-^:I(U:KEL=*BJH1CY$NQ)455,6?M5]:>I/1'3T*+*?L2 ME*Q:BPTJ3'NS8KZ'UYXAE!;O_0_K51_;U'7%[[W/S_:+D]C/CNWG?&$_^SDC M#_+MA*2OY"6Q:<&$A015=L#%20@?0R,$VTRCM$DWM1UL-'1;@:U9DVE3VA4F M;++2$+3"*&C]^ .DKI,Z(0UIF8361NM:"FLA9N<^1]!J_#-I5^^<< M=^ZY[]Y[J(3*_<\F;/? >>>M[TZRW74".O:U"JW4EW[PJ M^ `67^3R_2;(7VU"6?I(N">2?JTLFJZCG;MET7#ZD1[WIL@9,DR&0L$S9#<5 MT<@9O(\,A[KI.-X7C-Z#(9'L!AA2J*"P:212&!+QM 9;J\&@3,50,".*.= % MO)J"H'PN:*!M.5L^< &VNJ@`&"E'/LV6CY13&-1#SICYJ\;R$39KQLSY2#-6 M2D$920+(,HE",DT2`#)2DZ8^?E_ME7+A1)&D^9%P5/.#\7W,-W(8J()%##$" M1OY_ML'V_P&,I_NN;AD(#7I#<6]H$"B>_N'>[4)ZM-_MSFRY2A7N-../]P]L MI[)O,'W5.QA,;_$&W9F^@0>H!ZBZSQO,H('0ADAF0!T,GNI3^T+>OF!T>FJD M(_PU7P?N^>H8>8"Q$6JL@_J:"C] ':;J*>HK3'V%J:\I=4KS%>YNQ^&N2,:( MVJ,=FW)RFICR8#W$2SS1=H=E]TIM<3SD$9XJF=4AV+9,V(QD)H1W!>T\BD4A22J5DX,F4 MH(TE8=%Z>L+I5>M[(VDEK832:CP8Q70Z4HNM(Z):SBF7%3*DC"ACRH1R4F%3 MJ2@,6\^)ET6R61P21\0Q<4(\*>JI8E/DM*I,B/\4F114$TY""P4UGRF0\-"? MR52"-@0.$D Y=W)*[HBTB6@`3KL83N;+D0W("U0/U /$HK> OP_T-Z#/@'3H M^\!_`O0KH&DZPBQGEH>$'4'J,2K3CX[ U$W7!.I6S(#LVYJ3/;TY&5J7DTI; MG0#R5&M]7IL9#MX8S0)_%^@O0/\`^A*(9>J8.LUX*E>UT01*R!C"1_ C25E" M3F(9.IBF.YF0942)%CC,`$!E_/6Z1SB10I *F! 0`-)&$_1O*2KO`^$;7(H0 M6TI/R\B .C,$GR5OPC'50,Z=0JQNAKSY.P;E&6CG=8Q<1CU[#O0$,7@IXO!. M_#@29,M-94%99[FA="XHJ!7ZECO :FL\O(>7@.%2';KC9L[?45ET&[EUYR$3 M&[)KR'[V>61#+:KW"/\*3Y[-/\"3O&,=RKA6*7'NM'BS8\3IW$ MYA<4Q0(>YEOG:VM0#,>PW5_A)P$+:K+K]<1>Y"PG9/_1P3([)*W=^@(^^"?F*BT^,*[V>W5(:W_CC[G0^R[V;Q+BGT$=YYZ8/TP2D:@80.Z3;JWD(F M-*$65Y-JQFUT<[IJY(9[5+5I" V9X"*%]5 ]ZY&!J4!Y($U0QA5P"5D/FZ@1 M>ARS_K3)A.(L9G\/@_2.!)RI> /'C=AX5F^:82K48C8.[LZZ20U189NZ0E@W MP613?B27V>$;,9BQN1BJGI^SS,4LBN7&O/8LS,5RJ99X3\##U_,>NX-_9_*'H>C\=O(B7K4BBB).B\Z&,X9=UUQ,1Q& M!IW.;+2BTU8UWZ1K,=N7V$?MC'T&5\)1Q;S93,PN81R2#)44ZUR(S4..YZS- MF+V8M@"OB6NIK5R4V;\O0Z'KP*(G P9M!K:J;L*-E6QI'6$R/(VF&0<2" MNW <'\:3^ K6XQG<\#H:U6WHI0E:B-$YKYX'3D.1;9"&'L(NW";.H]3R"W?G M\!"Z`',CJZ5(U9L8E5-;`IS:&MC,X0GN)$>X9_*_M8_:&MXCR_3=:FLD+?K< MFV!4K;955;6U7=!X5;5*[3)WY\A*J% &=:L<8M];LJT1"I-.: %AB@B!L&$% MF] ,7J(6N9D:)L[L9B:9:XR>.8M_2][3S>"AS%^IU_D;-*%*J_(<6R4_:;E8 M6R-C[,5D9=;>A3]BG__R,?8UL(76W+W.O,%N1Q;D0[.G^HQN.,V>8ED[%04% MQ3/8K%JY8N17_43UQ_V3_FM^G9^GPX6;T1 :06-H$KZI+FD6ET-J%V=S?ITE M-GRSL4J/*RJ=M#=8FJ ZG@R\B MD.$*?Y/%Z:BO:VQJY*& ]_N)6]GGFQ;\\)W'S]I42-Y^&>[#C, MT2>PX/20,0^% M"?XW,N,=R $C"'^JPFW"3#B"6-.O, M+N&YQ>3*2J<%5JVBS2Y/%TPS^GS^#OYF;,J2^ I'GD$JEMIU?_SE[>?VK"@GDD3*:O>1JS^M=)WV&775C<9=E= MV)4/V5TBEM'7C_@1B)@Q$4E#09)!%!*%1!-0AI7@X!>!IM':VH%-%./'9")! M<4$G)IW8-JU3^T=;8SN=4$N3D YM_["3F@KVW(7$,,.]+_-NXG9<@7OH,P4H M3:TE.T@GZ2/7R$WR*?D7,1#'@G%X[:&>)\OF%%WS.-I*U8TU/5/34K9LIF58 M("N?W'RY3X)KTDV),#4MU:%)'6')SEA+2XDZ]RL7.QR]#GQ?;2[K4?F.C\QH M26AIK<&.Z8,Y!*PGRC#1"+9*$+TE>&[0 M[W/^=6GVWXO5 M17H0VH@NWX3]+(:*,<;X8.(]N51*//B ELFERZ5'C:M-Y=G<30GR\A;GT4A= MY&9D(O*5460BL%SJ]+87G,L9RQDO^+C@4^^GOC\7?)D]Y9/7&?(2<&0D-U=E M$F1RY'=%4)1@(Y=87K6!+0&#EUPT5!AQ)6#EB*KDY5Z!1B:5D)G$;(+H"4VW+INNF;:6%LXQJ*2@,,MOM'!" MML?KR?'X/)S ^\Q^OQ'A4LCEUT.6!4\>4Z >C%*!4%0/"Q273ANU;#YQ!??A M5])CK4Q+**25))F#?;(EF^69'U)V-)].GVB2/7ZO5_>AWEFQ<,= ML9VOS_[CX+.%'HC8>G?EX-I]=2<:N<<.'MU>^?0;`XM& M]US8=V95P+70P"\33 /-E>6+7;G+LXP_Z*[X*[JDLDJR!FB3)PL(@^RY+V 1\1=-A6=)> M%JA#7DU86(M 11 =YN]XJ*4LV:$R-! >/U/UY+BLM!"31YDZKZ4>+Q8)$:\4TTM(*:=X4+V82".,-V+'1H9F?DUTO#,WFP-W79G\* M#3&VZ_X1\N9,KM1[&U_!>""+KCS%@;4Z:UM6)]\I=+J.<+TN,4JBGJ?8 MI]Q5GJ;,W7Q;9@\YY#R4>9(](\6]$UX+XP6+FF+5TFQV0RI.7E8O58K;@R.7 M8D7#7)O5"5Q#WCT/T(E-U7C*E$=V>-P%*:2%9NL0 M1.C@&>=I4M!(?9TR/8:"$(_E8O0?YD!#E59H):WN+N@B76X!B:.#!CF#:Q4U M-7$[K,]E[>1WNOB::@Q9HD?D= 4+PG\H\#H#A>6/[QH>./S\5>#XBG.C@8$#B:;16."1C<69(=43&>[<\XTVOFSNDF[[IGR"P$('V\ZUV_;;N3)#KL"S7D>N M0V#=M1AED1VC;C_X_18,9[TCZ0ROAY,1BX)[%5"]1]1J,!R>" M7- Q5W=\Q6BJYM:*-*KU:W%-U!QY#R/*?0RLBTNNN9;!DO MS#<918=&$AF09F;%;[BN9Y24B#6G) Q"6NJW%4?XL\>ZWS[9E-/_P\,WMNZ] M<7C+^Z^#Y;]-,S>L:U:'UU4=/-#AK^(;?4KE6[\\^.S$A7-'SCTS`JY16#N[ M>695S\:ZOZXH/'7\_-=N=$'%@TEV"%U@8CX<8[@'$R-:QE(^\6""AO#@, #/ M!J45#%7JE+CR:_B8? *?D D%2PHF8!2JL(3G,%'^B#I9DLJRA&,5GJZ)\G= MP)MP!U#F"?C):-P$)H?,CY,O&)9\3F6&4SG*;>#B',]=)9\Q\GS=]6UJ,HGK MN_H$#:G3H;E\VF/N^&A>O-)+_$M"-]\MN9Q34F?2M=B_J[1#JS<'XF3"TT_%J7.W""\+! MP(YP>W;,%)-CSEA&ER_F/Q0^FS[D?-LW(E]T7O9?"5PW7C?=4FPB8P1!(4XI M8%/L3I_B,Y?#$7A5V6\^RYB_QRR!J_B"Q8]$$0/&(OLU-YO9^V.R#C\CR_FX3* M].3=N82N"Q[TK0M%7APJS,I.L7&&-)^']V(<%UWUL# U6,\46'$B9G,X(K/T M.!ZRY=C/?"7S6M>5KPGZ;7Y: MPL$W:VZBO6IMZ79D MT!/HA#.H"3L3`)F&]P1N\[>R;P>X_Y-=+.NFDDRQC M6<:R\1/CH),`8V.,#8DI;G H(<0>TZ&8F(>3H7&2-@(GC2EI4R@A(4,A,-"" M36S+4$C2H4P,91(:VDD?), $0EO,9%J'X1&)[IW<#)F>M/O?K?9.>_O___=_ M7P?=H]G$/,UN,&PT]E@V^%]B7K#DL$Q_&,U@-%.GWSJ) M2OE$3V/KBZWQ944_](30.IA[>.7%D<&7#O0=O'MC$5LAX&I.\DF]$B5](+AR.Y]6'=>8)O* 4% 02Y-51O'G MJI]45\&N;RV8*J]0`UX1IM_47?(K=$\N_K'V+E:GTX=X:TEU0T6BO9\:D+-K ME^_>+0ST-UN,K)6M+BVI?6I9^P!YF^696EVAYA60`(_ BW+G/K O?B-.$1CT M8)?-T^QJ\:RWZR &^=?!/^.7%M^:0R]IWF?;9_]H,>UO]B_T+UKFI"7@AX27 M-]$=8"5J]R8!W0/ZP+TX-<#$$XG2!&A:5)*((T#K:7=!4[P4T;,$D*(2,HMG MPID=8!:<1:Y&$EQM'DCH/,>I!/E_@9H[-/^Y"K'6D:(6RA6ZVJ*RBIQ%[715 M24G+8GUM0.OVM)M5]5D MR>8,F83'DMA4H^;-C-D-E0]IBN?6U=;-J:.T,ZIKJI&V,(\-V?+\(7,H-R^? ME/C9#]5W@X;*>B_01FDO8*;JNZ'=1R3ENJ/ Z743.P(]@LN-0\J8[ 6F*61& M7?6L;CBO:KX7:(IU7I 3T74#J^10[W)YLI8/1; M1T%!%E25HZJ**$Q(_0\R^?(RE!L,T,AFY>E2/["4(B %I4PKIY$,J*I5DU_2NBWLB_OISV_9F/A[^(M/]Q5FXY@+4P0/= MU=_-Y&7.W\QT7+D-W[WW(6S\S9ZOM\QOY'\V.'ONZA.O/_7HK%8L_:ZAL:MY MQMS"ZMZ7_57UU,E,UZ6-N?[";;!N\" ,[/PJ4W;[6F;S^Y @8^9FYM!EN.LV M9. 8A K^_=8EL:8E(TO??"*Q M@$0X!D!S1+,*>( /.0>0RA=XZ!.1Z 6$E0&O#Q)N9CU)70$.TG2DY5!79 ># M/"+%,1Z[%_C6P%Z((&0XQ(!H3('58*A<,4>+EY2I-E*DVL%P=MB? MEQUVB]EAASH\:%.-_ ML*3-R>O+PZ=P\KA;7BTU2*_<=W&)=(G9R[;A#7(][ MZ:2ICTOB)+]%W.S;R>W$.\P[Q5%N%)]PCXIGN3/X`^\9\6_<)_A?W'5\7;S# MW<9WO'?$0I9K$)"/L"^R2< KBA[6E".P=H]#L#-()S VLU6P;10Y[,>BQQ,P M8ZMYC1F:,6TVR.86*CS:)4$RA&[+)+YN:35^:*-/;_E5]*GZ[W"1GG6Y%THPKA8U\2#]! M1$ZZ)FG**IEDFZG(&4EJ-IV*. $>A_B]_^^3>-.I&ET-^:K2YIM,@6N)II'4 MN';8I'(2V)6P%-JS%PKMO#Z7\LG)Z_ M^MH->/K/35-\45THQ#F+7Z67WMN^>:$F%**+I,)ET(ARTW]7U.6\^Y$:'=0<3-,[:-]I]0??9=U&ON0]1Q MBC50)AIYZZA62A-EL#F7X"?4#"$!PF,$21N&_;_4Y'LHF$*?#9DC1S#$*2H^ MU&]\TXB,*2HJ1ZTL.@0@A-/PH<-FZ#/'S,CLEHE,8FO\3L@Y?4[D)$(4M3CK M0T^L4*M2I&UM(X'*MEMKNPA8=BG5J6NB;>):;/S&!-E.A0V.J9CHMPE:@R[D MSM/GV4-:@9T*##;2,2[-5)CC,$Y5& 1\D#^L):K&$E2)@@)!"II4.K1TT*_0 M/#Y7X1.ETX@7Z/,^W\QK;R7_NFG]^/8?G>GQ/9GY\GCF\&C?,(R=>+6_@!>L M;KUF5:;TP^$MF0N?I3+_WMJUWSJT_^ZQK\_"1X[7V2U"L5*Q@P0!>HBBL1/F M1,FM>D'O?1'_'/\):];C]=8DWF[981L3QKP7,.,T\U:O2.EL,.G>+*)\1NL3 M"#;J?()1"CHDER_?9#(B5[[=#AA/31,/LW2MF)=Y#9^Z_^FPLH=\?5#)T9FQ M"E(!26'UF)!+0X#QRF],M5!$-6 ,6K1JH-:MS*H?2.P?-(' MD4A-8UKM";-;&[FE.B7+[D@S_Y?NLH]MXZSC^#W/.?;9<9RS$\=GGYV[Y\YG M.[G8OM0O[6C27%A3CU5KPYJFVL"TI5G;T4YUTG9MT*6 D-!65*EH$V]JD$I):0N#!3K1QN'W/$F6;3!%=_?H7BSE^_G] MOK_O<]]]ILD81".MC4'1:$ZT-D8'420(IYA?&41R4WAP47ZZH1R&8A_.%:B\ M!3\-$GJ!J.#XHLM)DJ ZYQ$DT^E,,I9*'NBQ,7:_M_/SHXC9;5 M?OWFHWN-Y60OOWM4[3".UBYH8K?5VCG.<`\5SJ&CW MV(4=T8/1;UG/21/6R]9401@,5YP5UZ@PZAYSCKF."YGOW4@,]%A*NDL?+H[,J&"6U^% M)+&AOU"!+1%?X$2&2F141(9*U(PX0Q5G-^,,57P\/_4B.L*")L7$6$'/E&_/ ME*_-`J[R[2Z1`;L%;@67&K,MF"!=LUTTYHFW;W'BOTRT<*4XN3(J(S^A'9#S MZXDD- KQ-[>TY&B?P#V>,'Y+`&DOP0I-H/9]R;S3,'R^P,,;:Z^+J177]^ZT M5O6F]M^]:5FF&HK$!RQ'L#$9S"U+/5:'9Z?US+Y::EM43]5Z'TV&U.RJS]0F MC)!H;^.'/]>:,FIO[.H/-E*B!(@J0#2-VG^4RE91J[W<&"JZ'6[/F2S_3?,E M\Y?F;_DKY@W'#<]=QUV/NU)7<8X"X[&Z,>;Q4E[ 9!=L44 M.40T)T"E=]KJ9*=/D5N(WJK(":*;'2F/X'7484 -\H?2G)[@4F(*IRAI(YE, MX):0D#13$UP;XMHLV"A58']TW.E47&B]"[W"-ESG[0SG8R1]#)J/D?1IK3%& M,L9NQAC)V'CF?YIN!GJN"R;0,-M1`;V_E=^!Q[94;$=E+M";7;P"0G"X,D1W M/T4&$#-8U_VP)P)CRP7)4OLM\H/GZ'MW-JYO, R4[%M]I\&C=EB=LR]9`PFI MP:- 4?#_:- C?8]]"J#=7+NG5EC_H%$;W$'"` M@&GS?9@V>52V!SR.-1D<3D926)3$,%:+=G%+\9!0D2KA0^W'I>/A,]*9<'TZ M>Z#^2#TO%3.1_F*E^*3C><=4T>'EOU0_6>0?$("+])86H-3T/)L_9]G\06 `W!M8',/7. MTJ-->@PTE4?2LY=]*91O6&+\V])V"WSX\PD_7H"$PR.LB HDKCP_PD\^>A M80LD2/=H03\D:#;6H'%9AF:O.&X`]H'#%VJS1X:?>FML[9.]2N_#N"&\+M:\ M=^HKM8.OG1S<_N,3KSYX>,^*IB:9AQ$W<.JC^R\]__>?U29/) STY>T]))'( M&T_4MJ[ZT+V?WCG[[,\?WR2U!?4D3-$ZU/D543# MBNPA>I,BRT2'P9$F>D&1NXD."NCQN+RJN[N^WH,SZ70T*@N!)@W;&KJJ(;H_ MK&BGM,O:E.;4JEBU(V)I2VFRQ*LE5.HSM$)_?DL>Y\?7;/V#9#XDSHR &72) MPR/,#&:[EA(H_,U;P6*0A%A9-A$-DTN]SY0]ZIQ]><$BX GN`Q$AR+V!OK!SWAA"8N_0O1-+ M+H&>J6U[EV?L>M=KU#-R$)8.0>4HW$5[#V%3F+#2(7:J$"9;_4-%09$QT21% M#A MK,B(Z&Y%]A,]X >C%J0PIE43%FB5A!WTT[#FK@ACPI3 SPG($OJ%+0*_ M69@4+@N\X*"O":P"A>K&3!JYE!SU.@9^,#=%TD@0^]3SH0E4EJO,=/Z?K>U]F:Y9JY/_%^ M4$CG;M@K^P)H<]/F9CP4JH2^Z/U!XZ11%Y"09=@&C@CS0L681"U25&P)8X2M M9KL9]S>CYBKO.1].-;ACT>KD7,:Y"ZI^*&U7<>99,?5;BGR\_FUF)V%".RQQOQ1E>B>H]<'U[)P1SK8CXW4H;$V+2D')B9QKQL MT*'Q[@ MQ]_1M V2Q0N@JO#=+!Q,+ MS<[26M'Q%-EW]WINT BR,+U]]R95]"[[_+9O?W8G.NBJ'3=6J/OX731(&ZC= M/GQO8H,2;,[L!U4TCG/^$U2QT*_LZ48)^3@AY LWI!K;&ML=EBO0C;JSCTA[ MT$[IB>QAZ1OHZ>RKTN^D:713:FB08-OEM-98?%$J6B6);[&24L+B_\MWU<]YSH.TV38G?]_'9.OG>Y_E]UE$^7WI?.RY.EBG19OARZ6/J4 M?"%]9J1N@V[IEN(*6"[=57Q VAPZ*Y\QWI7?-2[)EPRW)Z:X5"T>4\*J5H@I MNLW8O)H0;)>GQI0,)BHT# 3\1 X1",GR!'W3NMDH^@U9,HIR$8KXVZ5P*"11 M%\\38A@9G3>^C2P5*A:T>%S=JQY5&2M<5.O5/58)2D#9+9H$3]SCI=_R[&FU MZ0)[R3A\,?/EK,#Y+U:QH3:%7Z-R"3%A#O.%G&.K\ ;NLEW(7S([-J6)Z2<%,4HA0_.^&WV;?<_1/]!IZO1IFB@PK=54IK4:Q_J: M\+.^)D31"Y1JHN8710T1NL_R9 Y#@\L%5 GSHHNS^]$HWNGUQ@5#L 1.F)B^ M^(H7FR-<(SQ6C-L!:T^693VAJVQE(9Z%O=F+69KU^=DM`JIJ:'!:0U]B^Q#; M#&K,%C;8#B6DK]QW#;4UOF/M7C>0LPD0ZS\RY>ZJ];I2&:ZUF:"!-^T6.X5. M%KP&YO=:NDL,B5GH(J;80VX7OT-6B/WD`7%0_"DU?8WZ36EZ3S+@,F-G95)$^#H=JSM?T+?&? M4V:'0P76QB8%S;):25Q]5TCTX6&R0.F[JB'8X%EUU]TWK[YV M?7".+)CMMEIWBP>-1*TJCWD[!%7=1CROFHJ[NR'=KZ0O] M?&6QL"[W*2ML)V^+5 D43VI6.ISVI=V-WCQ10,Z#WXE5T(&5T-"4AQ#%1>0# M>2+5!6SC?OVP`=-D!7AXK#I8_:CZ8?6Q M]T]]-KYF^XX'CYWZ?/L:M-_]U=]5WZJNAAW0"?/??KE[^$#U9/658]N@!>;! MW8>V(24QQJ[+V>YI-FP^00KXJ#^:6RX6-LH;E V1[^MK"\]$G%ODX\E?Z!>4 M"Y'WDO6AC%#0TV;*S'3H1F%%YO[,VL)08=99`N%(-K(P\OO0!<5Q0(??),]+ M[R7/9\[I'R7K(U8BJO-N1J4:Q!2GFD"B#:@)$HW/;HGJ78F>!(9-9Z!%#P8# ME'?R(@D+82-LA=>&'>'N`FO!S5UE4@"K<+1 GR^<+DP6N,)LL 42;"D$6R!! M\[AMM+GMBVY;']U[\H4)>.B8NO)>9C%J*CE5TTH;;WV+YR,8TES^SXJ]59;; MSDRHH.,H]F$L,\6:@F)3(\FL%)%3>CHKI=L@&<$E$VII@Y2"26:F>8\\0KJ7 MHDEI1OI)=-1IS?$.;&&,@)W(2([%,;)N`,-8'W/?_\VP#!HE/ L_,R^9H&U; M6$33G/!B)+UXSM2KJ,]^!?49_C[^VUT7?MTZ,*]\1W3U[ML>7]JVA#YO7$*1;.M7#G4)3O(EZFF)-M*D[ M\[\0] &>>J4/<=3951$^J6')JOSF/3Z4TXN;B0^Y@'A(B+KD<'CW^VPUJP;^9+O0Y@D$ID$XFF2FD MY1K6_ 2N0^V&=EOSN"=757:/5,]6_[1JU]+!81@!M"SP!&)O<+S_Z1UKQDZN M'[[=?,US=']CW''?L?OFSEL)RNM@P ^K#U;?^;RZK>[RHR]4CU:/CV[?O@\Z M_[%_: M#8((0QVI$H$[F4&J-)F4VMBE[>(3@?KXX_!T M\O',3Y(OP8MT?_)(_E3^G/%Q?CK?))(@A*FH(\I:YQ;F&JN2]Q<;6G@:B4 @ MIGA4C:1TA6 B<&,68#DV8='9J612H^#'V)0\3./4V9)]RMQN`,*+*GY_M+?,-FM!3YFH1U3:@Z:( MJF-".UCM:]LGV[GV.;R-;-X^!]Y&-J\%`S:R`_;%@(WLP)[RRA,0(E^:7QO6 M0A]+OKD<0W6QANKB#*IGS%.E(B"L^P:*N2F\$ H+E6$WVB?45Q#-,+*$4 'A M=&Y8<&Q]H]60&>[SK% BH::,:+=R.54%&_+_CQ*< M@!,+I1E20$YPK*X^6RVWQ9N:A4AZ4=DF!]N\PU_/O;/SA4,@WS/2?_4F7\3U MRS///S;W7CI(`:J;ODX170_W\V/?P4$W>13,/S7SHHB=SO[EFY03X40GN=D*!UYH`3[@(WD'X:,T(N?4 M-X*-).9[0 ]9 MH6 8RE"!B=6%U<5UGG7-57Z39[.P*;=)CRE (:6\4I0ZJJ%JN!H9:A_)CQ1& MBB,=PZN\#I[/B;R42_'QP MG1*QDY3.@G(!4>OY2F>,*-2;*!&N) M$E@+0BOA7JOINQ!83B[>J2,2JT^6#'U%>]B\A:T!*E!4ZU[L"0CA@T44TG>0 M*\2M&A!VW;D'K1UIR(A:EF_A\D3.ATE-1 4#4=?5ZLX3O+M%5P5$<3YOKCD3 M0#3'&C2.>=VF,[M8T2PH^E'LUY @Y;;RVSV/"5MUJC94`XACB5V$[4+]AA)FDGY\S*Y$N9J-IW-%@L=^7:, MR1VK'#_.!&IG1L8.Z3U___FSO1^^V550WHZ$8TPF$QF\N&/Z^55E=>F'1_IN M_&3'WLZF2,*%%)$^>W++S$!/OG=Z^^-'!TYG MGJL>_D,QK!@X\GN0-GK5UD8?6^5A,$P.QX;E<3!.CL?&9=9(5!(;$\>HV"CC7^- M:/7S\4=K(5U IF&QA@%/1@#+%_$"K_&^`MI@_9;0;P:X1J1(QE<5GD/H?',)J'1V+2+WDR_*B\ECU,E+D1OTM+,]_ M,*H5UC-9P=FW](MJNKSJT\7/I3CE]HH[1D /WE5^^8;S'-K5-O"MGQ(0V8YF MHP"Q_8BG[=JJ-D8+&EVF^^B]/BJ3RJCMJ79U36J-^K+*Y-222O;#*7Z?[X1Z M6?U7EN[V(HHB$TE%D<*)9+,B@41*5*10(A4.A1!/D1G-PS4CC_;Q!;QKJ''; M-G!V`^]@#CLU@>-8RUUB+2126,B2++)WEC\8Q-QC\Q"-OXQ'7[<)*6+_T@?4@;D"2U':!>LP6J/8CSVJ8NW9:AO0-[SZUB4>IF$YK+GTRD$B3MRZB9 MM#?>2@C^K#O7"GA70LBT$AJ?P:X"K(@?I'QPCJ)<)';AE 5?.+ @;?-.%G'- M_<8L:.??/09RO =NY/OUAH$[5_]R&\;7/)PGUQ>JZ7"L[]MC3__^8<0X3C63 M>4#95?_SU9LOG7AJZ)]D8'I#)E-,3];/;;PZN7[JXI_(S$R\!<6!M'R3F49Q M4'+(YTCR@>K@ZQSHS&6#_@7'7[&])%4RRD&)X@,DSQ*&44%@5JD(]6OHN@(, M$TI6F*,]C)MU<8S+!>D2$_"&Q)(;/1*.)Y8KH'H_KJ.HMMY'C0ZN:*SGAJA! M[A1'9VF=;>$UMR9JD9S4K*EF!UV*%.!#](-,+[].JM*#S" [Y!IT#T8&8=7\ M*OTHLX,?BXQ)X_G=U&YZ-[/;M8??Y]X7V2--1_?$OV$\33W'/A,]9!R"<^9A MYCA_1#P2.AXY)AW57C".PGGV-'>:/QV9EUZ)GHZ=,LXSY]DW7 N1"_ W\"Y[ ME_\L=C>^?LS8!L?,.8[JE';(.Y6OMU+;F&WL&.?HY?J4=5JO00U)FXT!Z.AG M^MEAWD$QA N17+31:([F%),I\=PY&F^G%2,"764)++,$#21"C 0E43-RDA9PHU54 M.2NI);-3*BTL3YR7>%=\87FG%80L$W?S?%)";TN1:%3F7"Z<7 U2% U$C1C+ M)J$1A- P:8;!,U%HHJXI!E1-0Q:+('F7BV49KNO[],LF.K/7K**)8:QL5U:V M%1:@N=_\CNG8:(Z:CY@3=N>&^9')FN^S?^.^S$L7(_PE,DY$P+\MWG+WNZ^Y M'>Y3Y:X%\FOG$^//(%WW2>W.K;!P*R34%VV)J-=O?Z$*[4KHGG6VZ;/>Z5^B M.G1?@[W7P'2JZXA0L4+\_R4C>+M9=#-"]Q &UGL7RCYL%%$"8D8,:EJCIR+C M(@Y1H80"?&7%22)). 0:$!$BS9<"Z&.#LIV"34+&S!? WM3C2T&(X+.9((=U9: 44(%MB MC=G5SKY,MI Z\.G/'%L_^QZU_W-[E6? M;9I3Z; S3),$;& :M#CLATZG$_U3K8&D$D0.DSAUY]N2K4L_ MUM V:2OP:D;52DAC<2HJ!AIS:;NJ*]N")CZ$-G4?94)LHA]+TY2",% H7Y'* M5*0B41:A()5!4)#::6)+P_\]I].$L'3W/OS>W;WW?K_?__<7#J8.=D_FZKC. M'Q6.INK=]=RI[M?QZ\PKN2O:'[6%G'Z,/RX<3[%88"*X&99C"3T20ZE,!#4# M=%31(M'.A!(*@=D(P#X*3B?!9#R9@E9*282R*2'G3 G)A,+%9(Q0+!8E`3T4 MG%O]SPP1>JCC*7M)-CRSA)4MH.;L\*@]*6PLJ;WI28H/V8FN8X[FF8.RB8,(5=9PZ'U M"=0UZTT9F!E*#"495&G"KU8C-@Q/88MF)]SJ@MT"B,,I@CAR4^96;T'"(C0+ M^.Y;YR3JTC!U:A5,409H_!]?@!/_!X,0,*[A/X7#^[:7[EY2$]O3*PWB$^Y^ M_8'LID""&8EFMVW $>PN:?W]@+G,Q&=75NZ^=<\TX/N9P7WK.MRFF4YW/GIW M,W[MT8R:;D>(0:.K2^P)]@Q:AS:PH\WH8>MEF^QVV28GTQ81,J93%)EQDX9A M$TEYR+ALT>=CQO-!,@3:?Z&6($\.KXT<69Z.S1<%6@H]&7)LN@NF9/(HZNA* MY_HDVP4/E6Q-(W5K!">Q4Z0I'-J%!*.U 67#EH1L4' M'AU^\]D5*]?+W M7;-NUF?YGD)/Y9]!)\63!5[S!8?D*LB@H0P1TJK$ZK0X)#FD$N#DAMTE%KY4G%#:K M/*TPRE>!)F3%N9)=8F#9DSWU'J:G`/LVQSYD>QUBIM&#>ZHFRGLDJ:\/-OXC M. %^/'\9'T"=R"1O;"DB,V;6S6G389O+)E,WL2F30>9E9A@)J W"0:S8-H8MDC&5EF]PYSTH8F /)%&4?S94V%M:K'9Q_ M8+!_D.%=3K>3X8VX'F?X@EC4D5?SJ\CG;XUY5!SO6,\5533H[--QH4_TJ;** M6^)P&^)+*J%4,VU:\V7=W6#,#@,S@:&0+D&NM/M\V4?DOV*A*6#K3"^L%!"Y M<%ZFQ6Q+<4"'M3>9"L6"+8I%11>+(;A4@O:P6'3#40ZD2.F&T@VE"TH7I?0G M?WM@G2:(+UC 0M] ?_\`T)<:P%"@V4?SKE 0#&$P2"@_T$;MHA?F`.&AB]GX M7&?_AKU?B7;][I^[=I3-!)--F-FSI[[\R'K5YPZURE);:7)_[Q#^=GK;R,3@ MEJ./>]N_]OGAWI$O372>V!^/IX,ER0EA!R,RT],IS=@NV!8H U%3)=H[&$$XKJ7RC>M):K" ME*''%8:@EWS.!S.D#95_ M721=DI0PO500@/@-4IM?>]\\>1TQN$_*"7R:G^4O"._%'%QBV%/IUQ-?9 \Y MGF&/.]Y@WW0*&P4\Y PD/??[HX$1)20A1R2(9 -__"6],6Z:8ZIV:-[*YY! ^P_V*IX*F:/]_/)6C9S^# `'C .46G/'@PP"[8%A":V2 2)"TDS[_42T/6O M81*O/_;=Y]YY[>2;8]^;:-45M;L%^WORCQ<__?++^PJ%%//^I7__X?8WZT-# M[(67'@[+'9,KJ94_K\O_^J=G?Q()@$=Y"#"T":*'@>^<=SKPO?C!A'F:HO$T M?>-I#."#9JM+J!J3!F/ EEP@>#(T4/P9/^2&4/GM+(DH6B\+$@_R;57*5Y8H M4.:O$(3X.HB,'NSNZ4,=Y/1"GET74 Z7#$0#*0A(L YP$75J!L, M,F1#-\8,LJYIXQ7CK-$PKAD+QK+A,?9K[[;BUJM!TR7 \FZ<#Q1)80_ZBK!( MT?A]3,+;I!)G7^1QO\QP_'!^^Q'P#46!-U;8N5:9J*[7*8HW"RK+*2TLU*MV+OC6* MN7=HG],.:NR+&NAQ;0]P8W!P$ _B6H7 !DU1'SV#9(5D?LNS_B(GRT5,,@>9 M*&/CG-P4/&P!Q&J89+I,H0]1K$$]2:-(R_=PGCF^ ][T^NC M7K&CX[Y]&S[UZHG''AGHPY^Y\ O,OWL#M[RP-9%-M!V*13<]]NKI#X5L`HR"#>E:D I64-2)+'D)GG2)`$VG MHZ'W`YM"4E?(#%W]$?M7I)% #2TMYB/2)?MM5PLS[@\@$PXNG6:IXR#*E84+ MKSF,F^ O&A2/\WPV0U5MWFJ*F]68MRPB%SR 0\ '"0DU9 DD0,!S$Y5J7:5.)%:I M6M2*=)2AT$J)D$J;2B-LZ]J-_4$6PC!(+9E&:6&-&FT3HTP4)J%.&O.4;0A- MJE+V?>=TJ$[NON^]>^_>C_M^/Y_/=R%7`60#@(/8N("2#^?/=G>GDR1$-NE- MZ>'DR\S+EF/,6/),?7-(I545J^")XNQU8<'.[VJL^J7[/]IQZ4)U&T^II[@)WI=$>Y=WU MCHU2T-TIU]4K&P/!NLX0#+,S<=D\M5 5,>6,0H>4 M2852[C7TL;#6L[&F-+'GNS-L1U/'H2H^@LI8+A7;E]O)#]0[@&.%P*-HXB,2 M'\'DJJC.\/5:E&]0D<[ +<9I*FZTQ$U@Q%5(+*XE'@[^/8I+HT7@9V#G*A%+ M0,291\A8I6.O977&U43]WX>ICSO&\B?N_/=W+_4"0J[2:[ KX0PK_H3]ZZ4F MMGU?:YPC-=Z[_ZZ"/'>,5X#N'$UP0":813, 4Y)2!L K00"$DP@T.RL1* M4C!<+A>4D-VON3C$B1S%D<=D-&>B*_3CF/+#Z^8(*%P[3Z*!:;;;36 @"AH\ MB'A5L5@TW1KH.+DP_XB,Z^0Q= K@B%9-=**KBZC.R)-)C AQ89%3N1F.1MPP M",=3',,=9W[*S#(TF8J#K9%(C!)W]GA"0=@G*<)NP>W);L% U@1-@A *?IO" M]85%PN+%R\6B_KBY5E@I<7?#)PW5%GW#:-ASG;;XU #(M$!6,0+9$%F5K2.? MYD.$(D*FB\729G-_8U/:S_JL@^XGE2'OWMK"*@[35I:S\@Z+_ 0[3KW!'G4< M$X_4_8SZ5>TY]Y^HSYTWQ?O4?VBW-,P-\R.PNW'K;[E/G$L<,!U7\QI%6TF< ML! G^59K%]5M[0T-4 /6IZ@2->X>]TVYW[6^:ROSYZPSMH^IOU%W'/=M'GZ1 MPXA;Y*A18LG93<*AS7 L]PKC02E%)DMU2UEI2#XD3\NW94:6_7]D,'S!12 0 MADA4-S$WC"U2EISQ=_V8?!'N4UZ)^;-.!>]7#BD3"JW<]WC&>)SB)WDJQ4_P MMWE:Y T>=L+/\'=XEC\MR P:)WY%QPTI)1A"GT C0114@5X2L$!68H6S%#J" M'2O*!5* GN51(EM&BV JH/-%0C0EXE)ZR06?"+3V?AFT-J0'[< \0#U ,;B( MUJY%HT7<,3C'(DQ1HWO,Y(#\3$5^`7$PFWUUUF$DLC5P\81Q8EFN:@A&S/JK M-7_UV4K-5JW9JC6K63,$:U86?5F?ZLK6P&5"P;=4^IX]>]RLE^B@-=X5!I,( M@VEA8"^ `_8F?OKIHWN/)$+RM;=_?N]?OWGGRO)1_ N+Z-O7VG^86O?I\\_O M>]$S_E>,/[^'N=^?;AN,K#5>!3W4BQ!]T/(&TBE^);JUA,E7"8/03L(@@>W7 ML2BPF!<:,$_J6(*S_KLAD0`5)#/T39(26$)/5N D&Q_1@EZ$G W.,O;/2BR/ MDKG*O#B?6ZB(E2HIS1,Y?5F\0OXND\3W&UJZ@)SF& 1#C;H&-@)OXANP&8B8 M)1&(35UM+N.&83>CT6R'^DU37PM"(OX-!=TB-YA^88'H5A*.&UY7I^2I*-U) M=SJV^([01QR6=QB<3!P*3[*3W#0_;3TIGG3-)*PB"S@UU#BD4P%>F ORQQ_# M&T:=O:JC:7J]I(LVD-)1!.3PJ8N/B0,"+, M"XL"*_CB%VF6YJH*JEAURIX*N*Z9V;:#^;)XMP0LE ,R6BZUYY8ALX6#,/E' MTNH]2E23HYH2"Z!Z3R2 5UB'4 V""T22RP.>UB*',^!NK1G7ZDP+I(!F#F@J MIJI@@LQ/;I'Q>P%M0__RK8;8)M_L[."YT6<'V])!;TL^%(HV&8%_T-N6WQM[ M+!Z)Q#J?HO9N:1__\$!G8FTP$_Z!V]W\S/5-6\#]T/JON^B_@"9?AYY >^BW MC!]*2M];T:E6&B7$`O5"XPO]%&IDF]@=KZM,;DUO8?^:`]&1P@0S83GL?:UV M(G-LP^'-$UM_U/NF]\W:J=XR<\$RYYVKO9J^NG6^L%BX4U@J^%>IGPF?"E,!U>&6-:&!*&OD;M M9![G#6C-&]"4CY/0R?=YL*>,><.]G\>'>"BXX#5\AIWJP!UENMEP^/*VI _W M^<9\E.\#Z@^(A>#J0>WPR,9RONUX>SSN[/F03@'?!>&>13UTR@B)*;P_-9&: M3M&I6L*O*0<)B50FVT2/#> !LK<:B%8H7)L3/6;ABSG2!0I+AJT&`FE "\5P MS/1![ZKT1 SWQD9B\['%&!,32$]X='^.A#P4_FE(!#!B!]1"JF 43L&96PID M:,#N2!>$B1-=N$LD@[J:504[E1'E,P#[\L-_&RXR3G$08:"8:U3*U >&>RJ' M<\TINH^F^FB,:)&F:'*4OKJT:>&M-)F>R&12.$_V2#^[MW 1OPAYG>W7X[6Z M_H"$!6!YI;1L%BIZZ:ZHCSXP*WJ)H+\^*MX%[08)K5A9(87E+PE%Y,1*B62] M13"D/W0&EIC[+'P[3 %/E.Y70)3II$6[K4%+B02>"\0M( ZY,+'P;T;&?][@#>M;NNS0_=_>O0MN:\BK?F,ZT&U:$"CF]@ MV@/X.\GM`=3?L%U%F[W_X[I:8]NVKC O)5$F38FDY-BD+(ND14NV&%&.HQ<3 MI:8=)TV3QC6:.(Z[.7&;;@.Z87X`>R![U-TP9#^&1EO1#4B*Q<"PHMC^)*F7 M.-B&>8$1[,><97^"_5B!K!N"%8VQ8$N#H4N4G7,II4%EZ][#PYKZS\>>WJJ;@\GYZ[MFYEYYZW^__]Z!=J44/EZT M7;)E_\MCQ8EG7]JSO?'?PN".EW^[\LOMQ3-_(^,#;TQ_?]T+<7Q70@AQ^^:7 M+G5DW [%" <#(3XR__S"B1]-#955M6^4/Z%OT]/'V%-?/?G3J='%D^=>&'WP MVO:C?8/64Z_N*W9V!D'TF0@4I_] -U=F3S>UL:?J(7%E01&H$ JJA=MJ`C=4 M:-8H)R"XY=$.3XTB2-4,JJ6.B8Q9+&7SQ R*(CMITFN8>16OD5]]]/$*9B&X MOX([\BV.07#'DZ@HT^OE"71A(P)(;0R^??#MAV^6*8+P2B6/AW-+92:K]&P- MA@'6A0+V@J"Z=^X`*)O](#6M\OJU(7G=]C,;T""N/]$;'BW&D)(E.L(=LT6X M*%Y2R0I4?@4JN0*594&E*96F5)I2U6J%F#1MTK1)TR:LYBZM-A#\>P5W0/#@ M,N[+YZN5IFI3T6[&&VBZ8!701FXHE%<`XFZO4/5R):$Z"[Y9ZI,R2]5Z-7B^ MNE:]40W8')FHSE;G,>55B=&F#J24U8#D*;WY@51V?Z\PD)+WI\V!5&8U$/6< M="GKC!13I3%B9,L,7278*D61!4VU^+I S@M$$N:%<\*?A*" 1:HOSYB6H^2(2U)PFV)< _*,Y"6"O3"(C-#H'C9*-&HQTA#U.K. MIE970*QI<\B%:6L(V:%*N96$CI$[>QHY=Z0Y5TA-;"E$2"[W^\*63>XY\UOM%XS=3AIJTK&Q&'B=C/SY6*#[7 M2!YS=,N*"]4C@5U^]\B +:_!$ :^M#.][#,^8ZXP%@A!#\(Y%J%PCY@J(ME4 M$=EF7 WPH""TED-PBP*?QRX0=T-P_1(>S4?45L6'X/V5)MUNM>AV\U>4;<8J M,*#K.7/.?!5DN'<..#S+$8XZ673DE_$"7"\7!S=X$XKZQHS\GM]*`LC\$2@! M-=->1XRUF! Q* =,.N)U5@X<: 8C(W[@:94*-^EQA.&6.19ORC"&V1N.X_+N M>TD\D^>M=(3R(<(B[".4#[@RGP\J$I_R!S*7?0I9Z28\-O?VQC>F*'] M2),*6MTBL]:\5;>6K;M6R+ F+-;#P4+!'!HJTKFZPY_S@_Z<[J.SYVB)(A D MOK\W,I"*`2VRVHB1,L=$38S782DNP_2*X7A,J/.$=U&#+^XNX>1)PZ7 %T4Q MHD4LU;-=%7.)\HYB7243*IE5Y]6ZNJS>54/JQ?3%GU$ZX,_>1 Z ]&[Z-A64 M%Y8F-\E EP0?@/H,602L#S5M)^A(_#&N*:RS+5P/Y';NS.5J.[^M;1MI[-[M M=//A5"+9'R4=H==Q1RV7V]DP'QI'7 !RHC9)7GQSJZ%)UCS#/CK1V$M.ATX# M:@?(>K/.M_?':1,4U_']W5O!`DV#)CQOM>#Y%R_NX]/'MH#IB+[ZJ$%/@> . M/06"O])3=#R%QU-TAAO((E[%?DB ?1KH[+XN,X7-C0)6ZYL;35C:=@N8]C7H M72Z]E2"<1FQ\TL.54L2^".7/LR?LNOU.])V>99LS8&/)#LB0N6$'$FW]66,D MF^H?TW!)W&0\P>>T;F- #'>NDJ@7D1E&#,.=I7-Q$E\E7_!J.?\U>T^7`H[= MU96 ]^NC-DA1VT91:^EZW2"206:-9>.N$3 ,/,18??01=(QP@'$Q9__9Q'=N MC]^C3JQV4$8K5AN7]WQN[/;!>_#VP6R!/@T/^SP[SVUTKU"\;2Y.RU @785: MJ9CM,A0;M$C*R514ZNE+2GJ2I*+=Z')(JW\!F8 &YE. :4;8OG1N_Q1N^NU: MS09X+/UA^3-'MYF);N5%4W4Z/T'/:;H[9]<:QH//?_B/T71Z*!*>ZIOZ(?N# MG]@F11!A%(8)BE#W*H'?-?%C)ZC\:W0T1(2 0D="1\@@`CIQ!&_P3XH1##S; M-PGEK*.3ICT(TD+)4B MKY_>""W[K\$M9)@28"]6IFZA7&$RFDA_F@B0O,2+$0KOP/L7! [>D+UI-TW$ M0WMM;0VM[A,VPEZ[!E43\ G497SJ8DVZ(KFZR\8XF<#_&_R;0KV]+IZ5SBAG M8V?T<^Z[@N!J;N*X?%PYKG])GE/F]+,L_V%J4V>7^->BUP+7I _8#Z1-Y5^Q MMF%E6!W6J\:PNU=:%+XBM178G&ST&9F"6R55.;Q%GB3/RX>-8%J>(E/2;?DC M.?2,LD^_RE\5_BZ$NOA.6>_1]3WLJ,2U*U(\DA![I%14YPX%)H.'0M/R8>5P MG-.DGIZ4?H@--LM^H:Q23!,Y(&1+\(R^*1+Q&\ -@=.RH@BW;KH;D;H;>.BW M:1U'TTSK. 0?TSKN.&[U$U]#;0WZF0T0(&IINJBEZ?8F98FP2BP>ES4]D=(< ML"K97H'E4P(ZE6RZG"V,E%+E,:; M$/=L0R]PR"LH8,W'"1L!R$L,1A#CY-@ MEI4$65:%"L-TK9([WK.J^,?V=H$#Y&N:*K0/BDLB>UO(_AO1EP/(]M3@UW#=?U46S-@X "U MJ0#R)I'7_/$4[EL/AZ?A^2PN+BS,,#.+9(9^F 5F`9J5*XP,M.F ?D7OA\X+ MOCT>`*]?+_V:[>V";. M,W[O^7*^V!?_B>T[_XGMBWV.>>_\\?L_O[_D]OZ]BE@]\I?_KI-U)Y/?)\<[(GUMO\.#)0:PY,I4-NKT>+AOK\ MS-=VZ?'R7_=TRG(PSFL:/S!VM_FWL]V#'I>NLU! '6+'FG<:.\-,U_UNM?M% MQ^[+TS%_&IGF.5!87F":$'NCI:]4D!>DKX*RR)R,.(,19S#B#":CS$;:`.,! M51AR2T+)*+20,,"X=P/7R&TW@1PDN)Q<``C"'0@20P1#T($44,1"@K4JAAS6 M#+Y;VZJ&;(!44C!(N0:6<9R3D=!A%"R,D@ANRA8]LDU>9-BB1Y95Y1GA/P$Q M8NN<7ZVHZ^KGJD-%]3(Q-8QW:]?HV#!3W^Y8&IE5F:7.JHOJLKJB7H&)3ME( M.&=2S$B(V70PVU$.)()[8$M.T<4QO4/>=".3;#''AE=D-BNS17E97I&OR)_+ M;?+;RC;98LOWB?&G0F6!G6#(=J13GM4F+629#C:ZV?^MDO_ M*<_MC),.<5@_F[;5,V41,>^XRAUQ_'DSBZ@-JC8;%IZ5ZJ>C]=>K^1;?Y_% M\?BPQ_+B&>=S-"M7*$VU9DVU9F&/U8VSILK399I7)J"4"2CE:A!_K=I:5VWE MEVK+`1C_MB(XM^I"-]4<+<_1\EP)#M!R8T?)A\O@^2^6&]>5NM Q/#^PDCBU MQ-,XCSY*?O+A)Q]^#7,@^=#RE"C7-MZW?6A]Z .>_VZY<:K&;XX_!HR"'TV) M#!;W[D-!I4T?KELX9[#.#M2_6[]0=]3GQ.E".-/O=H[WMSE1H2LAM(7\;@^YPP7IOV$>+\F M4!K)B0CS'/7E2F5Z*M-3N0KO\8# KVGS\#]]2:%!!LX"XY\T6BK-5S''8V>U M%4%@?$FCU6IC?C-P_%NM#W9.%[P"1^_\X<0$DC*@=[6C*ZG8TM:ZL:KZTQ MT_*6C(&7N[N8QYOR9+J $GSC.5N4<@LY!IJTP2!?@ 955+M5 M0OZ@:M/%4"N79($Q(.6H3WEDJ]LI.O]_Y3/$9IOJ6OO5RIU'>=:YZ:TY2DKJN^M'^6_6AYP#+WN7/-RDL#T E9Z2#T M%:QX?ZD9.CH2T_786)V]]-/^EAZ6.<[Q+V"R(7Z+R4QBLCSIX0*U'LFKI)$2 M!O I'=<-B2A)(CZ0B \D1<=E2A0'%!GC7&G1$QCWB)7 ^,SJP>D*%Z?%<7(4 M)Q=Q(XPN#!+.1DL@&[9$(\,F.0.YS84K#*Z+U_-().T%JLP*Q8[?0$+TP96" M*X,CNEE'L-5IT M82"9X S#,(>?BE);E6[EW$%X+52FHZ1,4<[O,JT^4S(Q_O/FK+EH+ILK9ML. M@5ED7X2G55-<->^8_*K)%J%CW73$)<5(>-<<7LN?,HR$/I.2C(1G)ATW$FD@ M"&L@7FR=%L2I#7^IA4S MAN)Z7]*8-1:-94.X:*P8JX:#,WP&;V >;X> -Q:'(=0A;5.40XP_L>\M58H! M/3JZ%S 0@U,%;[(5AX_>K\R-GVM^ M_T@RTJ7KV1[O`7;ZE1.O-N,+2APB;7J)'7YK7Q3CC ?2_LCQ+L29EXOS\F:D M=8$,)$4GDYRS:SJ?VPUM5,#8P4$TK !V"C1-4#.2VY?A[,Q(^/V0@ NZJX73 M=AS'>5%<'$-,184@(2XH^TC!^4B^":0#T!2$A"PG$P@L2D4(+LA%]"/@V-K; M>3'$?J&\H_R!?=#^^_C==K'S8Q?;U[Y7.1)ZC;W>_D/OW9@S:15-(3D)L+N< M9+="'T1Y*\GV2ZW== IXZ#G0_P<`B@*[@^VLL"@L"RO"JB *#V4+!BWY,I0X MDXG)2CCW@N^+[^5JCQ90TU56>P]55F=?/'I-3NR_EA3V'SPZ?Y.3-]8Y`:[D MQCJFP,GY7W-11Y$3N*"C>-]W/[;M$;)#8_.%`$0C+-Z9\?3PF:X>5T;L\7N# M&A=G48TI[6"%G6 %.GP:BSF@";E5C8NT06,7(%L?2!L,]2:@CDW.6_Z3_$GQ MC.N,YTSGR\K)\,DN::$!A1 4/U9[E\\_&H,K!'_Z-?FH`1(N SZ HIE/9 M'G-X9$1-B6(HV(F8A,S!^=,A\_CNRZ]^_?RWIAU7W_S! MU;./+[[UXU^>_^IT>>+-7X2B8^.KYHSC/(=S4$40<).T=OKE/PB-'W M@%M5+#E ?@QD/",-T9DE%N:(A3D&Z 2&!>7VB B74O*@3;3KZ[Y;0*R#A-@6 MM;[+%3<>WT @%EV(R3":+M?8+M@=X39 '!G0[!P@XJ8^LV(DUC28U2MZLAR+ M>& S;MP-;@!/>L)G,R.S&1/(\[]\5W]L&U<=OW?G'^<[V_?+/^[.CGV.?YQ_ M7.PD3E.N+^OO?NO9>[ MSWU^++7)<[&$4?T,MQ&CU19WB(^(IR3720MMM$8V[K(>L0Y)AZRC[#'IF/4< M^R/O3?;?OD#_QCW5L:'#0RYG(ZJP3+X@*V"KM).]"I@K,TV9J5$S06VAY5*> M<97%881W0GOQGC0U.#B0Y&8X>H*KZE%I*N5,3&WZSJQ-F-HF$%:=;.-"TX-^:EJ*VV&%$)BAB_T,0;536>0-L M=BCGS_5GUWD'#50)P*GJ&S;0`%\V*.H.=($HIZ9KU%0-(,ADJV'L=# .O02' M9M? 5"/K/PY([C9A@@5:US$Z--)SVT^/?GWOU N3+^\5,)B M.J%FT9 O^.5/']S\\%YG3W\EP]C35X\]>OBY*ZVY$V&A;_7FOFHBFT41?N @ MLW^L7PV>6'WY2'K#G@<__\H?IAY499RT`@#H"X#E/#K?07*^2)#L248EDU@( M4TVB3N"Z.Y\DN^XCV?4-28P9"0,Y2>)3DAB-),DE9" 2&36B_1K K5(Y@'-P MU#QBGC 9,^]5_0Q :A'GD!:DD/_Q#F+SMUV_T&7A-)XN!_<>\9WPT3Z80/7 M3@F<)9(S\!X_)'!.XMR&B1D7%W!?,EDL?"SY,#]5&5E9TB&B^B),8B)"GG"RB(B5EDLFD@>K&C$%3A@@^_I*Q9+B-B<*/GR!D?,>)3R]/ M36,\;A);TZV:U';<-M6%)3B1:5!AH+FS] M?4.9].ZP'.[K5P*?VKQ:VM:K<>Y 6D^:' HS9]]\\U[+'-X:*NQ;W7&_"1*; MB1#7>^"E3\:QS )>#JXMTW\"O RXACIX,:L$+U4':RB-5/S^D8K?-Q)B.FOZ M\74S)336WB&"*V"Z&\3]PH"7-8642RZYT3$W.NQ&[FP%(53T:D\FT($$2F0- M'4WHDSJMRSPUTJS50*DJT$)3`\H;P1 !=5Z\LBA>:?/='70,I@23=14C";GL MIHL#WO8TFKS+C;[D?MI-N[-%[Y8$.ICX2H).9&4>X1V^[^@8+8)0'=39(/&: MIHP;TZP.=GBMV6Z;H'2U&C[$9K,V(C9E&SI@4Q@Z!9^E6;0LEQW>MO*\K8;& M_)_+S8DO9MR]0C5!C*L6K6$WW'K=/H-'V:J8?K>CU6CY_J.UT."$B@.<;G]\0YZ_7>WZ?9 M.!,)R?%(CU:(6;.^66[..),^D^'E4B!O[;1&J^/5IPI/62>#/TF?K=Y@KL?] M!78@05VD$RB)*HA3:H"Z6&TAWI**:T"[&$GI21Z)NP)/#G=K%".[LE>5, M.L"[!),T[@3Z'56N% '2[\A(R2_E7H[]6Z*2368 MD,-/"FA"F!1F!$9HH&%',W6MG&01:\V;:,*<-.LF8YC])FW^"AG4(#)^OJO[ M<3S0FKY-+.Q*[=X]"VLI5!NS*Z#^"VL(2F#PUC+T@S!A<[LLMCI9-6J#=^# M36<"?"@0X)\/EDO!XV)S3*7$6[=;M6DDMFZWVC4IVR#Z1=GP!8:HTABA_WB^ MD#1$R>--2A!O/04V#I]P(DYY\^XX:E/_L\]BAPQK^3[R?B!^('V4=]7&(/C" MIPH7M7DT3\\S\_SW`S/A&7TF-A.?[?UN>K[/#R:FA*8H\#DPC*^D*YEO6'.9 M.SW-,XNPR6+'#[;+R;DD:"!3R#T M"S&;-)J=::S=6%#L=+OQ0_-+Q;94I3V7W)Y+D&$)&9:0;B:5>W+OML\:R?'O7+[XU<\<3H6C@50J_H/]6W<_NOK7 MOKZYIX_?4 M]Z)"4 4."ZW]@][D>HV*H94.AV5['!DXK,?!!,7[5:Q>_K""W HI%2)D2F/M M7T3P%*Q\Q-+A9^'']R@\:PF1D*N!8@L4\H"2K2PM5EK-CH9=`T]6^6]^TJ(D MY4;(.7Q7#>_C!DFG>K?0H'!"N)KD$2_$4/CQ$-H10F0Y!Z (:_,QY"86SDTB MKYNHH!LV^'^LE2K71(7Q6:M'75+)7BM ML5>H`&S@'K\]CL9I>J1G5IK57@V_&FEH-S3O? \ZI:-1_VA@W#\>^*<*>3&L MFBH3":N:SB!\"L5>0DRXO[-;II^FD<>_#F\Z\E;X[?"[82;\6"CV!L4WT"W' M,D \RY6>I6JX318,0RS*DX(N=PZ M*;UN&'1S/=IY]6HUG]HLF>GZEO*>XK?7'^V+%EROK?YQV\K/QC87\OL/5,)W?A)G<3`Q2WS^.!["!<&> M+)NY#O:D_[!=M;%MG'7\'K_=FV/?V8Y]=[;/Y]C/O6#[+JM]26Q%LLOZ%M;2 M:&B%%EDM@@D5":V)U$V3&L5\8$DE4! J'S9 J2I!QP=$V[1INFA;.@'JEVS] M0*NMT@1"93!13Z4JU:0U@?]SEXPB<'+__W./S_?V_'Z__^]/(@1A'7:\L$: MV 80>D8,_. ZJ:@N,HY!F=0,4A\N&*$&/UIH:?L*^[2PPB0/DOZ@>%#%1HDQ MT$Y:979I/,XS*VAW)\E1&$-)(L\3XWB.YXL::0QBU 6$XN@$6D3OH1!:";S9 MP0E9*2<2D\D?)0,]"!>200(Z;0MV`#K]G=G_]FE0B@!^@#Z*X*WM`[%/[OQS MIP:E0\CFXF(NKN0H0$%.>\<^$2^XV#L&WT6YQ"YVP M9[C!;\:+Z8(1V_RD]N*IW0>FJKG1?6CGX7;EN\\TCP3/;-Q:W)L32U/O]+YX M^ <]].K.'5F$-W[:FQS9'Z"_/!K @%$1,-H'C&J!ZSY&EUF64A*1U%N )Q$V M#;9 \,\7*9"P?O_>O;8#%<&!!=C"RE,2QV89EATJPN_X5)JL;RH9$;_@V>U$ M).#-`+\U;Z"1\ZQ7_O.?\#O%#]>A;R3+RB:^PGU-^KHT6YY0CC,_8UYE?ZZ\ MEET<^A7U.O,+]IQ\3GD]^Q9SA5WFEJ6K\AO*:G9MZ);TB'LD?:;4%EE$KK*T MXUC#RY6G_*Q:?MZ[U\^&X>=2R<^BZ.5.1\XUXD.GJ&DT'3@1/J5]+_Q]<6&( M;3$-KB$UL[^/K!7?5^AY[K0T)P='$_ND0%)*J4DJJZE4@A-58,$KG2JKR)HD MR\,LEV)9+JLH99:!$4-'PJ$0`Y8LF0#;1$44F9=6$)2GHQP2N#*WR"US?^#" MW R;)2 6.A'G+'.->1?8.\/*)Y55E*4TBH7[C2<:++EO.>_E2SMDC&3 O/53Z)$]+ M?;\U\;!.U'7.MU-S85OR!A7P57TDK#T9H:* :Y_:=@0>]"MH&OS-%4Y+#[1! MO/YV%3);!K\,S0*X% Y2ATLV&0UL"FS(KTC$3!P^G"P.^D8BF0378("M<(N# M$>B 4 GINJ$;(OI-SK &;]W.,/Q0`U4:J5)N<]7:O)8V"^*.X!FL:Z7AS4A@ M8"P?8^,\QB%1W?/XDV!XQ!%8!M@R\*^[XE$58X'J"E%>BM4E M)F3B0B0>(3!OMQTGTQ0V;L)G[0G.7*-TJ)Z[B.Y).:^E\"+T24 0QH^2SH8H MTSOYRU54I4YBA/F3)C)Y_^S5:JU8M&N$.J"5Y%KM;KLK?-CU+B9Z78?W5K,7 M$S8!::[MI@UH,$5L:/91^SA[POX8?VQ^BC\UH^2 2TG7.^Y&MM HVK;UK9&\ M+!>R)<$.<7I>K^I-_;G,^\QSA@'K#FZ9[0 M$W^(Y\UYJV>_)IPA!^-5X1J^9KYMW\ WS _P!^9-NT"%0W1D,)1A,6VP9L1R M,T\+3XN3X6?I0]*SUFE^09B73LNG2_-X7N_9F3GVE5B24Y(D6WI)EC(<\(^#=5A%]X!$ M*KJW5$!QD>P)5 R\"51!02@4-(T*D$E$5>$0(*FTBKY#88I!O^S$S0[<;+EL M\MKC^/,<]%07+Z]1SUNE%<1T!CM99U)&9V7TIOR>_$=0O1^7':!W]JH6QTB M12=4Y*,-O(H$2J<&@>'1#N<98FPI"=M%#/0I0E6)K5L2Y8:]9-B[:.U3YW3?V'E>Z4K/0W[D+3 M,[7%;9A28 *^ENXJ8*7(1LA.J*X0/]4>)Q9K?.O/'_?]/@O8[ZM #%2 V98# MYLF9RO\3AO^-M,",,^.>8$RA+BC%-&DANA6B%;J0BK9)8[($.4ET(M_,/)%2 M)-V_E&EBD@:]O8N#OG20CZ\<$5\X#*(3OFQL"\G6/BH%?1T90#THP[_]74,R MTN/H\CXUQ=R\GC*:J/A5:_-=ZR^;_\2;=_)CXZ G(357J&[\`_UZ;CP3"V(< MS BEU.#&`_39B)94`Q@/''_\]\#$QM5@8*(^0#QCEJ*"?P6%&0L^V/*,49V3 M&GJH1L&I'-"9R[6D$!B#P3)54T5?:!R'J,R:%[P&EXA-9RZQFT,+`PNQ!7%. MGVOC=; ?-"WK#;=1=W%B M(>V(2'3!EJ:C^1EY4D6J@U\HS98"I842*LG8MIOUV@/+,NJ3\+9G7.2&PS26 M:;KLXI3KXFC:,(;KT52]'H65E]AHIFY@F1]S=(D+1ANT&\^A7 %6PK'),D ! M%T52E>U0#=5JJIKGHF QK[R01FD;KZ#8DB8CF>AJ5' [\@7Y3_)].40F2#66 M5P,C5)VBT;K!$U5%]-7"=:E*MP(&EXCI0L_*HVW_8%S8JW-(]X2[7?*.[WHO.M'L M.EV8$?[-?K7'QE&<\6]V]^YV]^YV]YY[#]O<^2[WVK-]/MOG+)C=OQ( MFH0XY' "<;"K/&S'D,3@2A5**10!$GU$",EJ514%)-XUIK12A?Q7!5)4AT_.ZO??+^9W=F9G9G]S?<91>7!J\AL MO-(C]3PL*3US2TO4+/%+-C0\UH[@'SA=+M.C>@JF\.=[`^SX3XFZ'4.3UP5= MC32YB\C??Q6MCP:I0H.KZ"R%E6* UF*!VI)'E8J6DMM>M 4P*U!V*W5%T*93 M,GW;M059WQ"1Z8&__(JLV^B/+.MY- M.O.$T:DJR6T]$*%Q8YZ+MT&4TG(17 MW#7CJKD,8:>NX 2X$&K)K2N*K+L0V9)/]]14P5\S;GH4^O00EDH>GU[@?7HJ MY]73"!?OUP7C97X]77(A?'J>`GM6:>\(VOQEUZ?:#AQ\!;Q\7M"OD:4I4#S M]+.5Q7/M;#SNE52UO+1TIRN09.)QB[?Q3/7Z\6[\5QR5;>PJ*E.>::XK$WJG M6H:%LTF2;,2((4 #42\5)I=!790R!F4HS1LTO[@>3&@?:%?Q*K:]4UZ7K+I2 M- D:-'I=S&R>Y,&-\A";I7W(7F\'0&?')T[/;\M+&!<:VD#CJ_;<2TK_W@,_ MAW#U;Q"L7H,0"KVH;,0T$BX]+RBXO23MNVG&T]GJ/UIXR'+>R@B"Q4,)(>Z.AQ+:1E)P=X6WN\>%<7$B>"QT3W@\>Y8_)YX+G@G-A,]F'Q$?"5Z M"\+W0]_3WH1+G7^PQM GT;1L)B,2PU,/4O<^FZ^[]PD^$@R%%HDVTQO5'N5-50D'H+X2=$E! M_>GA3*:H-&@W<\4-7]P(9[LZ"QUYU8ADNTG".'0=Y'E?2TOTRCLN&]^LD''W;;NZ MB$K%ZR?/?ZLWF^GPRYM&YIE7;VF-.10'[MXTGJO'V$8#LC#/C;,J9)'OHO;(U_A+LFV^JY,$5;ULS(C61S] M%O* A0Q;#EL82\YA[97)C$Q&Y5,R(^<8$8IK*))&1A6Y%N'J&-K"1XJRV=<$ M]D42+^4MEM?$)CLGR7*L\?E;KL)/DG"7GI)-UAMK4HCJDLJJCU=X%#&&"?O4'M2-D M<'5J8'5E4"E_A!M@M;RBX(7GR-ITCY&MCY$.$X&QV\-S2P&B?(!N[H=U8T@_ M3&L8I!FZ+U4OE014>3:'&4#6N8"/TO<7?$AE@[XLWRB:J(@CA(UVD6@SW36Q[JB/1/-4\-A#]NO+S.'* MY2,]GC"7LK*P]C09G.A7%3L)5OX49S/!6+ZOLN'ZY5@V> M[^CL*G1OA%NAI]ZP=^NV[3MV]O7O&A@<&MZ]YZNP;_\=!T8.WGFH_,6=_R\2 M!Y.8^T'!3[5"!-)P&VR&/M@'=\ (WINM5O%^!%*@00FVP"ZC_@A,5ZO5]SY_ MU6?Y7R7VIG?6$P_'ZNU97">H=6Y&_M'.[;,C2@[9TX,79Z<.S,GE,GCIS\LG6P$X9Q9K; $ S@;.R% M"3@!8W :!C$_`WO@%):/P$ED8W OW ?'Z3Q]Z5;_[>=PQJR/PE]QCNX'&\Z0 M`FVP'\#R2UQ1%LLX.>1)L #/(:.E=0O'&#=._B?IL\M4Q(1[(0*S/'W-V[S$ MGJZO%JYQJ'CWW*C<\R$?Y(VG?_A>XUO4OO'N3U)_GUE[3 %>PB)=/^/-_Q@` ML0(_3 IE;F1S=')E86T-96YD;V)J#30U(# @;V)J#3P\("]4>7!E("]83V)J M96-T("]3=6)T>7!E("]);6%G92 O5VED=&@@-S0@+TAE:6=H=" X,2 O0FET MQR.BC-%?0B<,*7E>PN,( M456 ^J0R=JEX0)31V5*>"DO -?LW(&8:QB+;LJT&`>>H0-)?2XBF*5S."EELA$EM MUZ3_QVE-FLT-(\FXEI2KQ4>0=.-:APQ,D]DB+FPN*\'.]TFFDT6Q8"=Y::!!%6V]P7T,8521-)V"Z*,]"*IK@7W M9-UPK^DCM0':".H"J9+\2[F;("D"4)YM5D"::4D(BJU K5HK^$Z36JM D^DT M1E$%O:EVF\"Z91AYED/2C7FE)57<0DLM$F*RUBA/P!I((2!9\*/X.E4[1GT` M19J4H[^YD@29U774U&W=GCU;G("TJLFI9D;@Z MEH.H'0@R!TVK^6*Q6"F2\:))C5)TQF?3GI $B6H@50`#%+13WF?*A6RS,-MN M-MLR3P$R&^)%R='&KF/G8;7C"ZH6&G*J&TQK1O*Z(K!QWHNVQ>?P`2B7CZ6I M:DH`R9Y,IACPSQI(>W@WU1?Z)SRZMB/PO7JZ'9*(^E\3L]O3`$E\&=60]8D* MV$5/QE,QN1- ZA+]-NDZ2!-D>*H_[#E1Q13"1I&>$C%)]GD^'TF]+OV^PWK2 MUT[NN@54TYEX7=IQ8*KZ_DK*D60R2DV-,BDCTQO2P=.=`4F3KJJX0W9=%_/H M"RE(/B8"!RJA2>?W=]CB$R0==&;.*]%"$?2:JN/2]&.H@:^DB!;)%,YCX[TG M'9Y>ZC:9J!KO26L7JT#VI&IC9BZT@>47=V8N$_8"5?5+D2:3\QDJ:GVC*?&@ MPN6H*3 #J"BZO-;T408\ER?Y!-V@U:3I*87B[)(.-.D\34Y PK(<2"S@H(F$ MUYIV,86IHD92[VX"^;76N./JYE;30-JSH.0<4AE>:]K9OM[#BY$T.3>U:Z5J MVRA-<$4$:M=IDA^4I0.'#(E0U.C.57T%CI;Y2#J!CX-'W%T[9/S@Q9"EJB<) M.(FPH&[=?7QF^BC/B]E .NBF*6#$^%?7T]E+(>&R)Q7PZVB*[IZO-"5%/\J5 M57%#4LTEZ4D'MVADE<9JYW45C'T9D*;^\_/S15.\W6;]5-!X%Q*8P6;5U_@9 MCG5F41=)D^YXS/,MN)ORZ#I/-L^'X>F:I&'-8="$9W-5:7<`RC>PA0FY=O=1 M1[VG0+UI I^G3&H<7/Y'#Z/>?K,&.M%]9I@MZAY!=;] M/&A2I]- PE^_03T)PB!15Z0,CBR%&DFSV4ZS^CQ-#FOD'"O="]!=Z'==RLCR MBE3"L1"0):):M]\ML)L33>KK:=4BZ"C/$ZT)_CH<5"?FL&M-KWC$, X+>-&D M#U(XD[NIOK1KX5AI0=)TPH"TR1F>+FP)HFY)VZU#@Y%T1I(Q+S QL?[9Q()[ M(ENU]$3"OZBC.J+];]?U)GWZS!%%4^^L[\F3".]A>&5.S M74S"(&T&4EULE+^\3+JAGLY/2I6Q*&&K64-[5SRO*P$430-]WH75@0]]WSZ4 MBI35.VOXRV[W9&A9Z[+J3G0\;LA)*D*H$\N# M$"NXVA5"HT!667?0L$S3M+Q#5^%(DA'L3A@G$A4[\5FN5_O]OI#9JQHU]JKX M9"%6:2'+,NE1LS3GI51GNBP59TDCG@ZSBA.&C(5+$WO><_2*HK1%3%A ':S4 MS:QG_2/T_9KRE6<37>[U!42$W5 M/I'TBM/4.,)FJ\7,N(V?< ?)N)I-(Y9>2)W+$&72\**JGV SL9@;]V+F96J" M?_-O[\Z(@Z(C+$@TVNY5.[2]0^H(5:3PV2%5?./1P'P1- MKT<]`XO2*X^@C/'1HJ>OL>_WFY=PB3_(BL"C242X=1QB]%%D7!3\7ZL?L3"&29 MS+_2!-2G?O[]R2WD3#JC"R',C 8^KX#(,?QE] #UNJ(F+T\ MP%I;1 MS"-S7*F703.$51)!^[T_G^]R#L8=:?XM?3?/%(OAZ$ M/5(2#\=_`P`1HG,B"F5N9'-T7!E("]%>'1'4W1A=&4@#2]302!F86QS92 -+U--(# N,#(@#2]/4"!F86QS M92 -+V]P(&9A;'-E( TO3U!-(#$@#2]"1S(@+T1E9F%U;'0@#2]50U(R("]$ M969A=6QT( TO5%(R("]$969A=6QT( T^/B -96YD;V)J#3$@,"!O8FH-/#P@ M#2]$(%L@,S @,"!2("]865H@;G5L;" V-S4@;G5L;"!=( T^/B -96YD;V)J M#3(@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" W-#@@;G5L;"!= M( T^/B -96YD;V)J#3,@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L M;" V.#$@;G5L;"!=( T^/B -96YD;V)J#30@,"!O8FH-/#P@#2]$(%L@,S @ M,"!2("]865H@;G5L;" W-S$@;G5L;"!=( T^/B -96YD;V)J#34@,"!O8FH- M/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" W,C8@;G5L;"!=( T^/B -96YD M;V)J#38@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" V-#$@;G5L M;"!=( T^/B -96YD;V)J#3<@,"!O8FH-/#P@#2]$(%L@,S @,"!2("]865H@ M;G5L;" W-C4@;G5L;"!=( T^/B -96YD;V)J#3@@,"!O8FH-/#P@#2]$(%L@ M,S @,"!2("]865H@;G5L;" V-C$@;G5L;"!=( T^/B -96YD;V)J#3D@,"!O M8FH-/#P@#2]$(%L@,S @,"!2("]865H@;G5L;" V,C$@;G5L;"!=( T^/B - M96YD;V)J#3$P(# @;V)J#3P\( TO1"!;(#,P(# @4B O6%E:(&YU;&P@-S8U M(&YU;&P@72 -/CX@#65N9&]B:@TQ,2 P(&]B:@T\/" -+TQI;6ETF4@,C<-+TE$6SPX.3; Tue, 24 Feb 2004 01:54:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWS8-0003ZK-Sz; Tue, 24 Feb 2004 01:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWRZ-0003Yt-Fn for disman@optimus.ietf.org; Tue, 24 Feb 2004 01:53:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20470 for ; Tue, 24 Feb 2004 01:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvWRW-000219-00 for disman@ietf.org; Tue, 24 Feb 2004 01:53:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvWQi-0001v3-00 for disman@ietf.org; Tue, 24 Feb 2004 01:52:33 -0500 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1AvWPc-0001ej-00; Tue, 24 Feb 2004 01:51:24 -0500 Received: from h-68-164-153-14.snvacaid.dynamic.covad.net ([68.164.153.14] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvWPU-0003hN-00; Mon, 23 Feb 2004 22:51:16 -0800 Message-ID: <003d01c3faa2$d0cc4600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Disman WG Agenda for Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 22:52:41 -0800 Hi - Here's the proposed agenda for the disman WG session in Seoul. Discussion welcomed on the disman WG mailing list. Randy disman WG chair =============================== Distributed Management WG (disman) Tuesday, March 2, 2003 at 17:00-18:00 =============================== CHAIR: Randy Presuhn AGENDA: 1. Administrative matters (5 minutes) Working group charter is at http://www.ietf.org/html.charters/disman-charter.html 1.1 introductions 1.2 selection of minute-taker PLEASE read http://www.ietf.org/instructions/minutes.html volunteers PRIOR to the meeting greatly appreciated! 1.3 circulation of sign-up sheet 1.4 Review of Agenda 1.5 Allocation of time 2. Status of Current work: (15 minutes) 2.1 Alarm Report Control (RFC queue) http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-10.txt 2.2 Alarm MIB http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-18.txt 2.3 Remote Operations MIB: RFC 2925 (Proposed Standard) - updates in http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt - conlusion of WG last call - implementation experience 2.4 Script MIB: RFC 3165 (Proposed Standard), advancement? 2.5 Schedule MIB: RFC 3231 (Proposed Standard), advancement? 2.6 Expression MIB: RFC 2982 (Proposed Standard) - need editor if there is interest in updating this 2.7 Event MIB: RFC 2981 (Proposed Standard) - need editor if there is interest in updating this 2.8 Notification/Log MIB: RFC 3014 (Proposed Standard) - need editor if there is interest ing updateing this 3. Other relevant work (25 minutes) 3.1 ITU-T liaison statements 3.2 http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt Juergen Quittek will describe a light-weight combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. 3.3 Shailaja Yadawad's proposals for possible new work. 4. Charter updates. (10 minutes) Please see http://www.ietf.org/html.charters/disman-charter.html 4.1 Set dates for completion of updates to existing work (see (2) above) 4.1 Requests for new work? (see (3) above) 6. Wrap-up (5 minutes) 6.1 review of action items 6.2 reminders to minute-takers and presenters PLEASE read http://www.ietf.org/instructions/minutes.html and http://www.ietf.org/instructions/slides.html, respectively. 6.3 retrieval of sign-up sheet From exim@www1.ietf.org Tue Feb 24 01:56:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20538 for ; Tue, 24 Feb 2004 01:56:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWTr-0003eM-If for disman-archive@odin.ietf.org; Tue, 24 Feb 2004 01:55:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O6tlKj014026 for disman-archive@odin.ietf.org; Tue, 24 Feb 2004 01:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWTr-0003e9-CR for disman-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 01:55:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20534 for ; Tue, 24 Feb 2004 01:55:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvWTo-0002D0-00 for disman-web-archive@ietf.org; Tue, 24 Feb 2004 01:55:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvWSt-00029G-00 for disman-web-archive@ietf.org; Tue, 24 Feb 2004 01:54:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvWSC-00025a-00 for disman-web-archive@ietf.org; Tue, 24 Feb 2004 01:54:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvWSE-00012t-GH for disman-web-archive@ietf.org; Tue, 24 Feb 2004 01:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWS8-0003ZK-Sz; Tue, 24 Feb 2004 01:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvWRZ-0003Yt-Fn for disman@optimus.ietf.org; Tue, 24 Feb 2004 01:53:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20470 for ; Tue, 24 Feb 2004 01:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvWRW-000219-00 for disman@ietf.org; Tue, 24 Feb 2004 01:53:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvWQi-0001v3-00 for disman@ietf.org; Tue, 24 Feb 2004 01:52:33 -0500 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1AvWPc-0001ej-00; Tue, 24 Feb 2004 01:51:24 -0500 Received: from h-68-164-153-14.snvacaid.dynamic.covad.net ([68.164.153.14] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AvWPU-0003hN-00; Mon, 23 Feb 2004 22:51:16 -0800 Message-ID: <003d01c3faa2$d0cc4600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Disman WG Agenda for Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Feb 2004 22:52:41 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Here's the proposed agenda for the disman WG session in Seoul. Discussion welcomed on the disman WG mailing list. Randy disman WG chair =============================== Distributed Management WG (disman) Tuesday, March 2, 2003 at 17:00-18:00 =============================== CHAIR: Randy Presuhn AGENDA: 1. Administrative matters (5 minutes) Working group charter is at http://www.ietf.org/html.charters/disman-charter.html 1.1 introductions 1.2 selection of minute-taker PLEASE read http://www.ietf.org/instructions/minutes.html volunteers PRIOR to the meeting greatly appreciated! 1.3 circulation of sign-up sheet 1.4 Review of Agenda 1.5 Allocation of time 2. Status of Current work: (15 minutes) 2.1 Alarm Report Control (RFC queue) http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-10.txt 2.2 Alarm MIB http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-18.txt 2.3 Remote Operations MIB: RFC 2925 (Proposed Standard) - updates in http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-01.txt - conlusion of WG last call - implementation experience 2.4 Script MIB: RFC 3165 (Proposed Standard), advancement? 2.5 Schedule MIB: RFC 3231 (Proposed Standard), advancement? 2.6 Expression MIB: RFC 2982 (Proposed Standard) - need editor if there is interest in updating this 2.7 Event MIB: RFC 2981 (Proposed Standard) - need editor if there is interest in updating this 2.8 Notification/Log MIB: RFC 3014 (Proposed Standard) - need editor if there is interest ing updateing this 3. Other relevant work (25 minutes) 3.1 ITU-T liaison statements 3.2 http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt Juergen Quittek will describe a light-weight combination of the Event MIB and the Expression MIB for remote health check operations on a large set of small managed devices. 3.3 Shailaja Yadawad's proposals for possible new work. 4. Charter updates. (10 minutes) Please see http://www.ietf.org/html.charters/disman-charter.html 4.1 Set dates for completion of updates to existing work (see (2) above) 4.1 Requests for new work? (see (3) above) 6. Wrap-up (5 minutes) 6.1 review of action items 6.2 reminders to minute-takers and presenters PLEASE read http://www.ietf.org/instructions/minutes.html and http://www.ietf.org/instructions/slides.html, respectively. 6.3 retrieval of sign-up sheet From disman-admin@ietf.org Wed Feb 25 17:09:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18187 for ; Wed, 25 Feb 2004 17:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7DB-0007zr-4j; Wed, 25 Feb 2004 17:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7CJ-0007wW-Pe for disman@optimus.ietf.org; Wed, 25 Feb 2004 17:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18164 for ; Wed, 25 Feb 2004 17:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7CH-0003TS-00 for disman@ietf.org; Wed, 25 Feb 2004 17:08:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7BV-0003P2-00 for disman@ietf.org; Wed, 25 Feb 2004 17:07:18 -0500 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7B1-0003JL-00 for disman@ietf.org; Wed, 25 Feb 2004 17:06:47 -0500 Received: from h-68-164-93-142.snvacaid.dynamic.covad.net ([68.164.93.142] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aw7B0-000383-00 for disman@ietf.org; Wed, 25 Feb 2004 14:06:46 -0800 Message-ID: <003601c3fbeb$e31e3580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Fw: RFC Copyrights and Disclaimers for IPRs Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Feb 2004 14:08:23 -0800 Hi - Forwarded for your information. If you have internet-drafts that are intended for eventual publication as RFCs, please update them accordingly. (If your document is already in the RFC editor queue, you'll be able to hash this out with the RFC editor during the publication process.) Randy > From: Joyce Reynolds > To: iab@ietf.org, iesg@ietf.org > Cc: rfc-editor@rfc-editor.org, rfc-interest@rfc-editor.org > Date: Thu, 19 Feb 2004 09:05:39 -0800 (PST) > Subject: [rfc-i] RFC Copyrights and Disclaimers for IPRs > Reply-To: Joyce Reynolds > > > > Following the publication of BCP 78 (RFC 3667), BCP 79 (RFC 3668), and > RFC 3669 on Feb 18, 2004, the RFC Editor has begun to incorporate into > all documents slated for RFC publication the copyright and intellectual > property rights statements called for by these documents. > > We have placed on our web pages the current RFC Editor rules governing > RFC copyrights and disclaimers for intellectual property rights, > derived from the above IETF documents: > > http://www.rfc-editor.org/copyright.html > > Joyce > (for RFC Editor) ... From exim@www1.ietf.org Wed Feb 25 17:11:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18262 for ; Wed, 25 Feb 2004 17:11:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7F9-00086u-5b for disman-archive@odin.ietf.org; Wed, 25 Feb 2004 17:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMB2Wd031166 for disman-archive@odin.ietf.org; Wed, 25 Feb 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7F8-00086W-G2 for disman-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18235 for ; Wed, 25 Feb 2004 17:10:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7F6-0003ie-00 for disman-web-archive@ietf.org; Wed, 25 Feb 2004 17:11:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7E9-0003dO-00 for disman-web-archive@ietf.org; Wed, 25 Feb 2004 17:10:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7DB-0003Y3-00 for disman-web-archive@ietf.org; Wed, 25 Feb 2004 17:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7DB-0007zr-4j; Wed, 25 Feb 2004 17:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7CJ-0007wW-Pe for disman@optimus.ietf.org; Wed, 25 Feb 2004 17:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18164 for ; Wed, 25 Feb 2004 17:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7CH-0003TS-00 for disman@ietf.org; Wed, 25 Feb 2004 17:08:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7BV-0003P2-00 for disman@ietf.org; Wed, 25 Feb 2004 17:07:18 -0500 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7B1-0003JL-00 for disman@ietf.org; Wed, 25 Feb 2004 17:06:47 -0500 Received: from h-68-164-93-142.snvacaid.dynamic.covad.net ([68.164.93.142] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Aw7B0-000383-00 for disman@ietf.org; Wed, 25 Feb 2004 14:06:46 -0800 Message-ID: <003601c3fbeb$e31e3580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: RFC Copyrights and Disclaimers for IPRs Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Feb 2004 14:08:23 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Forwarded for your information. If you have internet-drafts that are intended for eventual publication as RFCs, please update them accordingly. (If your document is already in the RFC editor queue, you'll be able to hash this out with the RFC editor during the publication process.) Randy > From: Joyce Reynolds > To: iab@ietf.org, iesg@ietf.org > Cc: rfc-editor@rfc-editor.org, rfc-interest@rfc-editor.org > Date: Thu, 19 Feb 2004 09:05:39 -0800 (PST) > Subject: [rfc-i] RFC Copyrights and Disclaimers for IPRs > Reply-To: Joyce Reynolds > > > > Following the publication of BCP 78 (RFC 3667), BCP 79 (RFC 3668), and > RFC 3669 on Feb 18, 2004, the RFC Editor has begun to incorporate into > all documents slated for RFC publication the copyright and intellectual > property rights statements called for by these documents. > > We have placed on our web pages the current RFC Editor rules governing > RFC copyrights and disclaimers for intellectual property rights, > derived from the above IETF documents: > > http://www.rfc-editor.org/copyright.html > > Joyce > (for RFC Editor) ... From disman-admin@ietf.org Thu Feb 26 14:48:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05147 for ; Thu, 26 Feb 2004 14:48:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRUH-0005Tp-T9; Thu, 26 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRTI-0005IX-Dh for disman@optimus.ietf.org; Thu, 26 Feb 2004 14:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05048 for ; Thu, 26 Feb 2004 14:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRTF-0004VG-00 for disman@ietf.org; Thu, 26 Feb 2004 14:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRSD-0004P5-00 for disman@ietf.org; Thu, 26 Feb 2004 14:45:54 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1AwRRb-0004JT-00 for disman@ietf.org; Thu, 26 Feb 2004 14:45:16 -0500 Received: from h-68-164-85-161.snvacaid.dynamic.covad.net ([68.164.85.161] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AwRSb-0006f3-00 for disman@ietf.org; Thu, 26 Feb 2004 11:46:17 -0800 Message-ID: <000e01c3fca1$4932b520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> <2147483647.1076969942@[10.1.1.26]> Subject: Re: [Disman] Disman session in Seoul X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 26 Feb 2004 11:46:53 -0800 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Monday, February 16, 2004 1:19 PM > Subject: Re: [Disman] Disman session in Seoul ... > In January Giorgio posted our draft of the Check MIB > (draft-nunzi-check-mib-00.txt), a light-weight combination > of the Event MIB and the Expression MIB for remote health > check operations on a large set of small managed devices. > > If there is a disman session in Seoul, I would like to present this > MIB module and ask if there is any interest in standardizing it. ... In preparation for the session, are there any specific issues you'd like us to think about here? Randy From exim@www1.ietf.org Thu Feb 26 14:50:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05255 for ; Thu, 26 Feb 2004 14:50:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRW3-0005eS-Co for disman-archive@odin.ietf.org; Thu, 26 Feb 2004 14:49:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QJnpto021723 for disman-archive@odin.ietf.org; Thu, 26 Feb 2004 14:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRW3-0005eI-7U for disman-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 14:49:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05226 for ; Thu, 26 Feb 2004 14:49:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRW0-0004oR-00 for disman-web-archive@ietf.org; Thu, 26 Feb 2004 14:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRV6-0004in-00 for disman-web-archive@ietf.org; Thu, 26 Feb 2004 14:48:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwRUJ-0004dL-00 for disman-web-archive@ietf.org; Thu, 26 Feb 2004 14:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRUH-0005Tp-T9; Thu, 26 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRTI-0005IX-Dh for disman@optimus.ietf.org; Thu, 26 Feb 2004 14:47:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05048 for ; Thu, 26 Feb 2004 14:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRTF-0004VG-00 for disman@ietf.org; Thu, 26 Feb 2004 14:46:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRSD-0004P5-00 for disman@ietf.org; Thu, 26 Feb 2004 14:45:54 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1AwRRb-0004JT-00 for disman@ietf.org; Thu, 26 Feb 2004 14:45:16 -0500 Received: from h-68-164-85-161.snvacaid.dynamic.covad.net ([68.164.85.161] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AwRSb-0006f3-00 for disman@ietf.org; Thu, 26 Feb 2004 11:46:17 -0800 Message-ID: <000e01c3fca1$4932b520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c401c3f27f$fda01100$7f1afea9@oemcomputer> <2147483647.1076969942@[10.1.1.26]> Subject: Re: [Disman] Disman session in Seoul X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 26 Feb 2004 11:46:53 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Monday, February 16, 2004 1:19 PM > Subject: Re: [Disman] Disman session in Seoul ... > In January Giorgio posted our draft of the Check MIB > (draft-nunzi-check-mib-00.txt), a light-weight combination > of the Event MIB and the Expression MIB for remote health > check operations on a large set of small managed devices. > > If there is a disman session in Seoul, I would like to present this > MIB module and ask if there is any interest in standardizing it. ... In preparation for the session, are there any specific issues you'd like us to think about here? Randy From disman-admin@ietf.org Sun Feb 29 19:00:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17152 for ; Sun, 29 Feb 2004 19:00:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaqr-0007Z4-H1; Sun, 29 Feb 2004 19:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaq7-0007W0-6i for disman@optimus.ietf.org; Sun, 29 Feb 2004 18:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16974 for ; Sun, 29 Feb 2004 18:59:14 -0500 (EST) From: bwijnen@lucent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axaq4-0007f7-00 for disman@ietf.org; Sun, 29 Feb 2004 18:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxapA-0007YW-00 for disman@ietf.org; Sun, 29 Feb 2004 18:58:20 -0500 Received: from genaust-dsl.onthe.net.au ([203.22.202.103] helo=curie1) by ietf-mx with smtp (Exim 4.12) id 1AxaoN-0007TA-00 for disman@ietf.org; Sun, 29 Feb 2004 18:57:31 -0500 To: disman@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wpvlnfqtsnflelmckibs" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Disman] Price Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 10:57:22 +1000 ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.E in file eixqpegg.exe (in dbaeadba.zip) The file is deleted. --------------------------------------------------------- ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Response ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) dbaeadba.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------wpvlnfqtsnflelmckibs-- From exim@www1.ietf.org Sun Feb 29 19:02:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17283 for ; Sun, 29 Feb 2004 19:02:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxasQ-0007ps-2V for disman-archive@odin.ietf.org; Sun, 29 Feb 2004 19:01:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2101g3M030114 for disman-archive@odin.ietf.org; Sun, 29 Feb 2004 19:01:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxasP-0007pd-Tz for disman-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 19:01:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17260 for ; Sun, 29 Feb 2004 19:01:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxasM-0000Dd-00 for disman-web-archive@ietf.org; Sun, 29 Feb 2004 19:01:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxarW-00005d-00 for disman-web-archive@ietf.org; Sun, 29 Feb 2004 19:00:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axaqu-0007kG-00 for disman-web-archive@ietf.org; Sun, 29 Feb 2004 19:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaqr-0007Z4-H1; Sun, 29 Feb 2004 19:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axaq7-0007W0-6i for disman@optimus.ietf.org; Sun, 29 Feb 2004 18:59:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16974 for ; Sun, 29 Feb 2004 18:59:14 -0500 (EST) From: bwijnen@lucent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axaq4-0007f7-00 for disman@ietf.org; Sun, 29 Feb 2004 18:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxapA-0007YW-00 for disman@ietf.org; Sun, 29 Feb 2004 18:58:20 -0500 Received: from genaust-dsl.onthe.net.au ([203.22.202.103] helo=curie1) by ietf-mx with smtp (Exim 4.12) id 1AxaoN-0007TA-00 for disman@ietf.org; Sun, 29 Feb 2004 18:57:31 -0500 To: disman@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wpvlnfqtsnflelmckibs" Subject: [Disman] Price Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 10:57:22 +1000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.E in file eixqpegg.exe (in dbaeadba.zip) The file is deleted. --------------------------------------------------------- ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Response ----------wpvlnfqtsnflelmckibs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) dbaeadba.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------wpvlnfqtsnflelmckibs--