From nobody Fri May 1 09:31:57 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A91A8935; Fri, 1 May 2015 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEtOkYfGn64y; Fri, 1 May 2015 09:31:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391DB1A8AA7; Fri, 1 May 2015 09:31:50 -0700 (PDT) Received: from [192.168.2.100] ([79.246.25.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTSrf-1Yfjdr3pyh-00SQp5; Fri, 01 May 2015 18:31:49 +0200 Message-ID: <5543AA71.5030702@gmx.net> Date: Fri, 01 May 2015 18:31:45 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tony@yaanatech.com, saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org References: <5540ED82.5060905@gmx.net> <5542974B.9080208@yaanatech.com> In-Reply-To: <5542974B.9080208@yaanatech.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hRGVc6/5ST5b4qHWzzc1rxUu1AuMIrOwfylxQhajmxXfm2S+Be7 MDs7GRaSbTGFE+HUz8HwRidjkO9hUxqg+ezxw4MPk8XHggNTM+RzTfwf52SWQGAbu8r7bUL bGupLzaVXOskKrCK6M06DzDjX64UcGCRxmtQEMkBG6hvyupKl1XBq5c92WWU4ojNitL4IoB O7ME09PkVgTFH+390HqFg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OPSAWG] [sacm] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:31:53 -0000 Hi Tony, thanks for your question. You are not the first one who ask in context to STIX or CybOX. So this seems to be an important point, which I have to take care about. The STIX project is very interesting and covers a wide field of cyber security. Currently I make me still familiarise with STIX and CybOX with special focus on interoperability with and provisions by IDPEF. My work is close to the IDMEF and IDXP of the IETF and is focused on IDS federation and interoperability only. So I decide at the start of IDPEF to be close to IDMEF and IDXP. By my point of view the STIX project is more focussed on communication of standardized cyber threat information (reporting). The focus of IDPEF is to improve the management of IDS under one independent central management system for all operated IDS Anlayzers. So IDPEF customizes the Analyzer to the individual environment and implementation of the IDS entity. So STIX is more the output of an IDS and IDPEF more the interoperability and combination between IDS Analyzers under one independent central Manager. For me this are two separate working focus. I am open to align IDPEF closer to other frameworks like STIX, CybOX, etc. but by now the structure and notation of IDPEF is close to IODEF and IDMEF. Currently all standardization is focussed on reporting and alerting to exchange threat and incident information structured and in a secure manner (STIX, IODEF, IDMEF, etc.). IDPEF intended usage is to operate all IDS Analyzers under a independent management system. So IDPEF focus is more the interoperability and combination between IDS Analyzers under one independent central Manager. For me this are two separate working focus. Did you have an other point of view, please let us discus so that I have the chance to adjust IDPEF closer to STIX. A small STIX notation based on an example of Appendix A will be great and very helpful for me. Thanks. Kind regards Bjoern-C. Am 30.04.2015 um 22:57 schrieb Tony Rutkowski: > How is this not like STIX? > > -t > > On 2015-04-29 10:41 AM, B.-C. Boesch wrote: >> Abstract >> >> The Intrusion Detection Parametrization Exchange Format (IDPEF) >> defines data formats and exchange procedures to standardize >> parametrization information exchange into intrusion detection and >> response systems from an independent central Manager to any Analyzer. >> The IDPEF enables a combination of different (vendor and analyzing >> technique) IDS Analyzers under one independent central Manager. A >> separate operations of IDS is not longer needed. Base is a new >> parametrization methodology where IDS operating parameters >> (configurations) are separated in an environmental parametrization >> part and a vendor-specific analyzing part. >> >> This Internet-Draft describes a data model to represent >> parametrization information of intrusion detection system entities, >> and explains the rationale for using this model. An implementation of >> the data model in the Extensible Markup Language (XML) is presented, >> a XML Document Type Definition is developed, and parametrization >> examples are provided. > > From nobody Sat May 2 05:32:47 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267BE1A8739; Sat, 2 May 2015 05:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4LTmEAe_1mS; Sat, 2 May 2015 05:32:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7F71A8738; Sat, 2 May 2015 05:32:42 -0700 (PDT) Received: from [192.168.2.105] ([79.246.2.1]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3d9B-1Z6Bs60wSH-00rFSq; Sat, 02 May 2015 14:32:39 +0200 Message-ID: <5544C3E2.5020807@gmx.net> Date: Sat, 02 May 2015 14:32:34 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> In-Reply-To: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BBzRzFzrebAHwmzWbUmZzhuhlJABLbGNbZrzEEpi8JgGmt6tzkd LndxLaAS9F1kfutyENK4rKGCnm+k0gOp/e59AzbyRPhZXjgqRY6SX6ifY8ddAEkg7VID7cA 9A+yXtMvAj+PZ7Xc1DGVWzR5uXnQUWhfVbhF06slrc6Gale9F7nNaPFUwnZVgNJaWtJGDnm b8oVfxi1UsxZXb2Kyxoog== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 12:32:45 -0000 Hi Randy, thanks for your feedback and the start of a discussion about IDPEF and its management features / options. IDXP provide already an interface for configuration exchange. Therefore IDPEF was developed close to IDMEF and IDXP. An important argument was that only one transport protocol is need for configuration and signalling. That reduces the probability of vulnerabilities in the implementation (one implementation instead of two). The key point for IDPEF is that the parametrization of the Analyzer will be harmonized and the Manager become independent. Based on this you are able to combine different (vendor and analyzing technique) IDS Analyzers under one independent central Manager. With YANG and netconf the configuration will be still vendor-specific and vendor-specific adjustments are still needed on site of the central Manager. That is why I preferred a specialized format. Maybe there are some other good points which plead for YANG as IDS configuration format that we should put focus on. Kind regards Bjoern-C. Am 01.05.2015 um 00:45 schrieb Randy Presuhn: > Hi - > > Has there been some discussion of the reasons why this work > doesn't emply one of the established management information > data modeling languages, such as Yang or SNMP SMI? > > Randy > > -----Original Message----- >> From: "B.-C. Boesch" >> Sent: Apr 29, 2015 7:41 AM >> To: saag@ietf.org, sacm@ietf.org, ietf@ietf.org, OPSAWG@ietf.org, Kathleen Moriarty >> Cc: Stephen Farrell >> Subject: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) >> >> Dear community, >> >> I have post the attached draft and looking for feedback from people with >> security management and / or security (IDS) operations expertise >> (including IDS developer). I am particularly interested in your opinions >> on the communication proceedings, the parametrization methodology and >> the provided attributes (and such I did not think of). If the text needs >> updating by your point of view, please let me know that as well. Here is >> the link to the new draft: >> >> http://www.ietf.org/id/draft-boesch-idxp-idpef-01.txt >> >> At the first view the draft looks very long but after page 44 a lot of >> examples and definitions are included for better understanding. So the >> first 43 pages are primary in scope for feedback but feedback for the >> other pages is welcome, too. >> >> Abstract >> >> The Intrusion Detection Parametrization Exchange Format (IDPEF) defines >> data formats and exchange procedures to standardize parametrization >> information exchange into intrusion detection and response systems from >> an independent central Manager to any Analyzer. The IDPEF enables a >> combination of different (vendor and analyzing technique) IDS Analyzers >> under one independent central Manager. A separate operations of IDS is >> not longer needed. Base is a new parametrization methodology where IDS >> operating parameters (configurations) are separated in an environmental >> parametrization part and a vendor-specific analyzing part. >> >> This Internet-Draft describes a data model to represent parametrization >> information of intrusion detection system entities, and explains the >> rationale for using this model. An implementation of the data model in >> the Extensible Markup Language (XML) is presented, a XML Document Type >> Definition is developed, and parametrization examples are provided. >> >> >> >> I am looking forward to your suggestions, feedback, notations, hints, >> recommendations, etc. to improve the Internet Draft. Also native speaker >> feedback with scope on wording and typo is welcome. >> >> Kind regards, >> >> Bjoern-C. >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From nobody Sat May 2 10:35:31 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5401A892A; Sat, 2 May 2015 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyLhojP3Sxiu; Sat, 2 May 2015 10:35:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A22D1A86E3; Sat, 2 May 2015 10:35:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B18D1F8F; Sat, 2 May 2015 19:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id O2x9gAYu5x_M; Sat, 2 May 2015 19:35:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 May 2015 19:35:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BD212002C; Sat, 2 May 2015 19:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id INR4_zrXXwor; Sat, 2 May 2015 19:35:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCFEB20013; Sat, 2 May 2015 19:35:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7E6533026A0; Sat, 2 May 2015 19:35:21 +0200 (CEST) Date: Sat, 2 May 2015 19:35:21 +0200 From: Juergen Schoenwaelder To: "B.-C. Boesch" Message-ID: <20150502173521.GA60090@elstar.local> Mail-Followup-To: "B.-C. Boesch" , Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5544C3E2.5020807@gmx.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , OPSAWG@ietf.org, ietf@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 17:35:30 -0000 On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: > > [...] With YANG and netconf the > configuration will be still vendor-specific and vendor-specific > adjustments are still needed on site of the central Manager. > This argument likely needs an explanation. There are people working quite hard towards standardized YANG models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat May 2 11:19:04 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950C1A87E2; Sat, 2 May 2015 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNj3czYnwz0m; Sat, 2 May 2015 11:19:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AEF1A8731; Sat, 2 May 2015 11:19:02 -0700 (PDT) Received: from [192.168.2.105] ([79.246.2.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M8m7Q-1YyYAg3dF6-00C7vL; Sat, 02 May 2015 20:18:59 +0200 Message-ID: <5545150E.80207@gmx.net> Date: Sat, 02 May 2015 20:18:54 +0200 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> <20150502173521.GA60090@elstar.local> In-Reply-To: <20150502173521.GA60090@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:kxJJX4304WEkBJCeyON0wPyTh7LBoF/oM51rU8Fot9adguBid4v 0gqD2W0IuwbzO42aXP5kDqYaxFZCpzf4zxMtJFXPm/Kdw88LBZFhNHOgCuoUv9JIRv6svXF S8JlH0Hj/8HFYerS2IcnbhlqW1F0wwRKZOhJWvDPVH09pee/93xEhZhvs3F8gtviqskJ3XI Qm708KdiLVeHeOi+IizQQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:19:03 -0000 Hi Jürgen, netconf will be used between a netconf server (Manager) and a networking device (netconf client = Analyzer). IDPEF standardize the exchanged content so that no additional information is needed at the Manager to interpret the exchanged data. With IDPEF it is not relevant which vendors of Analyzers and Manager are combined. How could the Manager interpret the configuration data of the Analyzer without any additional information (e.g. MIB) in the YANG environment? How could I change options (e.g. thresholds) of an IDS signature of any IDS vendor with YANG without additional information on the netconf server? kind regards Björn-C. Am 02.05.2015 um 19:35 schrieb Juergen Schoenwaelder: > On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: >> [...] With YANG and netconf the >> configuration will be still vendor-specific and vendor-specific >> adjustments are still needed on site of the central Manager. >> > This argument likely needs an explanation. There are people working > quite hard towards standardized YANG models. > > /js > From nobody Sat May 2 13:05:11 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C21A8FD2; Sat, 2 May 2015 13:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 476GyfgsQ7id; Sat, 2 May 2015 13:05:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED5B1A8F4E; Sat, 2 May 2015 13:04:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 31110FC6; Sat, 2 May 2015 22:04:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2tbQCUWdR6XW; Sat, 2 May 2015 22:04:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 May 2015 22:04:39 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BBB82002B; Sat, 2 May 2015 22:04:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0TTBQBBkI_Q1; Sat, 2 May 2015 22:04:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64C8820013; Sat, 2 May 2015 22:04:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 798933302773; Sat, 2 May 2015 22:04:36 +0200 (CEST) Date: Sat, 2 May 2015 22:04:35 +0200 From: Juergen Schoenwaelder To: "B.-C. Boesch" Message-ID: <20150502200435.GA60318@elstar.local> Mail-Followup-To: "B.-C. Boesch" , Randy Presuhn , ietf@ietf.org, OPSAWG@ietf.org, saag@ietf.org, sacm@ietf.org References: <21625111.1430433958137.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <5544C3E2.5020807@gmx.net> <20150502173521.GA60090@elstar.local> <5545150E.80207@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <5545150E.80207@gmx.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Randy Presuhn , OPSAWG@ietf.org, ietf@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [OPSAWG] [saag] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 20:05:06 -0000 I am confused by 'netconf server (Manager) and a networking device (netconf client = Analyzer)'. This is not how NETCONF usually works: A device runs a NETCONF server and a management application a NETCONF client. Anyway, the way things work with NETCONF and YANG is that you define a YANG data model that is understood by both the NETCONF server and the NETCONF client. I admit that I do not know much about your specific use case but if you make statements that sound like YANG models have to proprietary and hence IDPEF has an advantage because it is standardized, then you need to be able to defend that. /js On Sat, May 02, 2015 at 08:18:54PM +0200, B.-C. Boesch wrote: > Hi Jürgen, > > netconf will be used between a netconf server (Manager) and a networking > device (netconf client = Analyzer). IDPEF standardize the exchanged > content so that no additional information is needed at the Manager to > interpret the exchanged data. With IDPEF it is not relevant which > vendors of Analyzers and Manager are combined. How could the Manager > interpret the configuration data of the Analyzer without any additional > information (e.g. MIB) in the YANG environment? How could I change > options (e.g. thresholds) of an IDS signature of any IDS vendor with > YANG without additional information on the netconf server? > > kind regards > > Björn-C. > > Am 02.05.2015 um 19:35 schrieb Juergen Schoenwaelder: > >On Sat, May 02, 2015 at 02:32:34PM +0200, B.-C. Boesch wrote: > >>[...] With YANG and netconf the > >>configuration will be still vendor-specific and vendor-specific > >>adjustments are still needed on site of the central Manager. > >> > >This argument likely needs an explanation. There are people working > >quite hard towards standardized YANG models. > > > >/js > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon May 4 07:37:08 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443661A1A9A; Mon, 4 May 2015 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zMAMrABR27V; Mon, 4 May 2015 07:37:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 038FE1A1A5A; Mon, 4 May 2015 07:37:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150504143704.28863.35780.idtracker@ietfa.amsl.com> Date: Mon, 04 May 2015 07:37:04 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Management Information Base for Virtual Machines Controlled by a Hypervisor) to Proposed Standard X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:37:05 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Management Information Base for Virtual Machines Controlled by a Hypervisor' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 6 23:49:01 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F61AD1EC; Wed, 6 May 2015 23:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baaMq2B41Giw; Wed, 6 May 2015 23:48:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF12C1AD0D1; Wed, 6 May 2015 23:48:56 -0700 (PDT) Received: from ams3-vpn-dhcp4455.cisco.com (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id EE8B31AE046E; Thu, 7 May 2015 08:48:55 +0200 (CEST) From: Stefan Wallin Content-Type: multipart/alternative; boundary="Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D" Message-Id: Date: Thu, 7 May 2015 08:48:55 +0200 To: netmod@ietf.org, opsawg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [OPSAWG] YANG Alarm Module X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:48:58 -0000 --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! We have posted a YANG alarm module: = http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00 = Please review and send any comments and most important of all, is this = needed? Being able to read alarm status and get alarm notifications is a basic requirement for any manageable device. Device alarm interfaces needs to = be integrated to alarm management systems at service providers. A standardised interface for that integration would help a lot. = Currently, service providers need to read and understand various proprieatary alarm interfaces including enterprise specific MIBs. Many devices does not = even have a clear notion of alarms, just events in general. The telecom industry have been pushing standardised alarm interfaces for = every new generation of mangement interface protocol. This is usually the the = first data-model that is defined in telco standards. IETF did this a bit too = late for SNMP with the Alarm MIB (RFC 3877). All vendors already had implemented = alarm instrumentation and good or bad MIBs, so vendors argued about adding = support for this MIB afterwards and the MIB had to support fairly complex mapping capabilities to existing proprietary alarm MIBs. We have a chance to resolve this issue with a Alarm YANG Module. Going = forward vendors will write their own alarm modules if we do not provide an IETF = module. All feed-back welcome! Module summary: This YANG module defines an alarm interface for network devices. It includes functions for alarm list management and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. br Stefan and Martin --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi!

We have posted a YANG alarm module: http://tools.ietf.org/html/draft-vallin-alarm-yang-module-00

Please review and send any comments and = most important of all, is this needed?

Being = able to read alarm status and get alarm notifications is a basic
requirement for any manageable device. Device alarm = interfaces needs to be
integrated to alarm management = systems at service providers.
A standardised interface for = that integration would help a lot. Currently,
service = providers need to read and understand various proprieatary alarm
interfaces including enterprise specific MIBs. Many devices = does not even have
a clear notion of alarms, just events = in general.

The telecom industry have been = pushing standardised alarm interfaces for every
new = generation of mangement interface protocol. This is usually the the = first
data-model that is defined in telco standards. IETF = did this a bit too late for
SNMP with the Alarm MIB (RFC = 3877). All vendors already had implemented alarm
instrumentation and good or bad MIBs, so vendors argued about = adding support for
this MIB afterwards and the MIB had to = support fairly complex mapping
capabilities to existing = proprietary alarm MIBs.

We have a chance to = resolve this issue with a Alarm YANG Module. Going forward
vendors will write their own alarm modules if we do not = provide an IETF module.

All feed-back = welcome!

Module summary:
  This YANG module defines an alarm interface for = network devices.  It
  includes functions = for alarm list management and notifications to
  inform management systems.  There are also = RPCs to manage the
  operator state of an alarm = and administrative alarm procedures.  The
  module carefully maps to relevant alarm = standards.


br Stefan and = Martin

= --Apple-Mail=_5B05F310-44D4-4B19-9A56-7E0FE690778D-- From nobody Thu May 7 09:24:20 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA31A0167 for ; Thu, 7 May 2015 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upiXu8Pm6Afx for ; Thu, 7 May 2015 09:24:17 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525E51A0158 for ; Thu, 7 May 2015 09:24:17 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so17750727wic.1 for ; Thu, 07 May 2015 09:24:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=siFRqOh9FkM8DzRRtKZLmCDkGQN1lzaquHPCBIoDK50=; b=mMShTfCohxV7SI6HPjeWRHcHs2zr8z7yTXT5prT8T5NDegpQzUSOL/3DngPqgud2t3 Waf7HusD8Q+F05/2HkRzchM2508xGgOOy6QvzyX1hXmn5/hmU6d1FxEGSrUH/boQsd9f yAwSSw8tO2efTKcRtd4sjcGLNTstoN8O0r21sl79rmcfeLh2YW0vFuPrI2uEQxB+xdD1 yFnxt3aaRPI8/PJbLvnZmXheuisHsHOrojCM327q1hf7CBHzQyl7tuXEcX+GljKUFd5s xxqhq4bitI/f6jYPvN1qLflKDctbGI2neFM+uvdNw8PQGOe198eheqMZnLL02eL/GFQ9 CCxg== X-Gm-Message-State: ALoCoQljXQ1RcPcbmNEwREyepQ2Z2pp9Ghg6q/yxT+gUmZeMxoZdunCLp45Yjg9sJEuUNpMtmwVr MIME-Version: 1.0 X-Received: by 10.180.210.171 with SMTP id mv11mr8022810wic.61.1431015856092; Thu, 07 May 2015 09:24:16 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 7 May 2015 09:24:15 -0700 (PDT) Date: Thu, 7 May 2015 12:24:15 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] A reminder about RFC 6982 - The Implementation Status Section. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:24:18 -0000 Hi all, A quick reminder to the WG about RFC 6982: Improving Awareness of Running Code: The Implementation Status Section. Authors, if you are aware of implementations of your proposal, please include an "Implementation Status" section in your draft. Showing that there are implementations demonstrates interest and shows that your idea actually works in practice. It also makes reviewer's,and document shepherd's, lives easier. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue May 12 12:27:46 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF581ACC87; Tue, 12 May 2015 12:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sisK1SKBaS6Z; Tue, 12 May 2015 12:27:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA271A872F; Tue, 12 May 2015 12:27:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512192743.10483.85863.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 12:27:43 -0700 Archived-At: Cc: opsawg@ietf.org, opsawg-chairs@ietf.org Subject: [OPSAWG] Kathleen Moriarty's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:27:44 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft! It's great to see the improvements in security. This is just a comment and not critical at all… I found this sentence at the bottom of the second bullet of 4.1 a little odd: as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- SHA-96. Since the guideline is to truncate the size in half and have 80 or more bits for a HMAC, you are covered and already cite the appropriate RFCs. Is this there just for history of previous solutions? Or would it be better to just state the guidance so folks understand why you chose the truncation size? You can do nothing with my comment, it's just a question as the text had me curious. And I see that you have included the HMAC truncation guidance in the security considerations section already. From nobody Wed May 13 15:23:35 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2881B3170; Wed, 13 May 2015 15:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G5BsxqyBc54; Wed, 13 May 2015 15:23:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4F1B2D37; Wed, 13 May 2015 15:23:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 56A192CC6F; Thu, 14 May 2015 01:23:30 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl0OIWdXOGKa; Thu, 14 May 2015 01:23:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 6D8922CC5A; Thu, 14 May 2015 01:23:29 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_7AFA44C0-3FAC-4F81-BB2A-E8453EE84CCD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7DC0B3@ESESSMB209.ericsson.se> Date: Thu, 14 May 2015 00:23:29 +0200 Message-Id: <026F7A59-466E-4981-898A-A0E0606865E2@piuha.net> References: <7594FB04B1934943A5C02806D1A2204B1D793917@ESESSMB209.ericsson.se> <020c01d0769f$0076aec0$4001a8c0@gateway.2wire.net> <7594FB04B1934943A5C02806D1A2204B1D7986AF@ESESSMB209.ericsson.se> <55350CC0.40403@secunet.com> <7594FB04B1934943A5C02806D1A2204B1D7DC0B3@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "gen-art@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@tools.ietf.org" Subject: Re: [OPSAWG] [Gen-art] Gen-ART review of draft-ietf-opsawg-hmac-sha-2-usm-snmp-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:23:33 -0000 --Apple-Mail=_7AFA44C0-3FAC-4F81-BB2A-E8453EE84CCD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Many thanks for your review, Christer. And for the updates, Tom and others. Jari --Apple-Mail=_7AFA44C0-3FAC-4F81-BB2A-E8453EE84CCD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVU87hAAoJEM80gCTQU46qJlMP/0D+zDVwl+wW1hCspTTfOENa 0exFl3A8O4i8ipfZY5VCyq59wUov53GAb9d/X0u+BPdi2QA5ZmsDaHcpRax3RAQb 4JoN5bHOgD6TPpC8BvCOZ7yNTRVFPgYaw3o3HnIwgl0P2QVeVH5RsmPauZt8xzfA gYrrBLnbYC8AxyKPjiujl/6hC/A7VlpQWbDsoHHCXwgwSagaxMMaBJU7yS5RmyhA FwF3oIuLdtZlHEhnKFDeCxXQExJlNL+pYdwM7/w4G6WfzNl6+xQVeocIpP15MZ+7 OjSRobhz5O5XMl5NIZwoj/5019zrsgzo+Ru3H49UqTZueVBmEwg/2owVereLmOsN eFWXhv9jUeZ9vYwI/Rh8iho72TDMk+OyZEPGmf0DoTKYLFbQdrCuJSSlhxB6soAY UXjUbJj047e5xPS2fQWJCK1iFQuFIYSktCOfqxsYJGPuEAQMT0ddmoodCvqFDCqu gG/Y+LZLsyWc9Ldz5dWffFWmw1J9S1BvFGIXa24oMuYDsex3nBGMwU3h1JGFIOwD Zfb+EZlpIeEBD38H6s4AYUBI3l2dycS4jZNwhyemXFDA0MLjVqPUHLdrYV0jGiDx KEartkIgltwyz9ohxm2AmMs+3eyWX5b/3l9UcQRMIhG7CqPhVsg1LYRfcPV9Fl1Z 2hBLgqwNF9/95E+KTYDt =GyKd -----END PGP SIGNATURE----- --Apple-Mail=_7AFA44C0-3FAC-4F81-BB2A-E8453EE84CCD-- From nobody Wed May 13 15:56:55 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357DA1B31A6; Wed, 13 May 2015 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGWK0hyHGkav; Wed, 13 May 2015 15:56:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 266D31B31A2; Wed, 13 May 2015 15:56:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7B9CA180452; Wed, 13 May 2015 15:55:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150513225504.7B9CA180452@rfc-editor.org> Date: Wed, 13 May 2015 15:55:04 -0700 (PDT) Archived-At: Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7547 on Management of Networks with Constrained Devices: Problem Statement and Requirements X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:56:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7547 Title: Management of Networks with Constrained Devices: Problem Statement and Requirements Author: M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg Status: Informational Stream: IETF Date: May 2015 Mailbox: mehmet.ersue@nsn.com, dromasca@avaya.com, j.schoenwaelder@jacobs-university.de, ulrich@herberg.name Pages: 44 Characters: 87357 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-coman-probstate-reqs-05.txt URL: https://www.rfc-editor.org/info/rfc7547 DOI: http://dx.doi.org/10.17487/RFC7547 This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 13 15:57:24 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86731B31B1; Wed, 13 May 2015 15:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veAo3r8NhNdm; Wed, 13 May 2015 15:57:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B57271B31B5; Wed, 13 May 2015 15:57:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 165F0180452; Wed, 13 May 2015 15:55:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150513225522.165F0180452@rfc-editor.org> Date: Wed, 13 May 2015 15:55:22 -0700 (PDT) Archived-At: Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7548 on Management of Networks with Constrained Devices: Use Cases X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:57:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7548 Title: Management of Networks with Constrained Devices: Use Cases Author: M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal Status: Informational Stream: IETF Date: May 2015 Mailbox: mehmet.ersue@nsn.com, dromasca@avaya.com, j.schoenwaelder@jacobs-university.de, s.anuj@jacobs-university.de Pages: 26 Characters: 71103 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-coman-use-cases-05.txt URL: https://www.rfc-editor.org/info/rfc7548 DOI: http://dx.doi.org/10.17487/RFC7548 This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547). This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 14 02:09:29 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339DA1A1BD9; Thu, 14 May 2015 02:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQODYus-DsWF; Thu, 14 May 2015 02:09:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 074401A1B20; Thu, 14 May 2015 02:09:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514090925.17639.73092.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 02:09:25 -0700 Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org Subject: [OPSAWG] Stephen Farrell's Discuss on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:09:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for defining these. I do have a thing do briefly discuss before balloting yes. I'll be getting out of your way very shortly, but I want to check first to see if you agree with me that this could be simpler and more useful. I note the following: - You're defining a bunch of HMAC options. - Additional options for fun isn't a good idea with crypto. - There may be platforms that do not have good APIs for SHA224 or SHA384. - HMAC-SHA256 without any truncation is considered perfectly fine for this purpose and is widely used elsewhere. - You don't need truncation for protocol reasons. To me, that implies that this would be better if it *only* defined a non-truncated HMAC-SHA256 option and if all of the rest were removed. Do you agree that doing so would achieve just as much of a security improvement, but with less complexity for implementation, test and interop? If so, should we just do that? From nobody Thu May 14 06:21:03 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0A81A8FD2; Thu, 14 May 2015 06:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYmq2HQvEf-h; Thu, 14 May 2015 06:20:56 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266671A87C8; Thu, 14 May 2015 06:20:50 -0700 (PDT) Authentication-Results: cs.tcd.ie; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 14 May 2015 13:20:28 +0000 Message-ID: <04ac01d08e48$7b643a60$4001a8c0@gateway.2wire.net> From: t.petch To: Stephen Farrell , The IESG References: <20150514090925.17639.73092.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 14:18:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR08CA0025.eurprd08.prod.outlook.com (25.163.102.163) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMSPR07MB051; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB051; X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(52604005)(13464003)(62236002)(44716002)(23756003)(40100003)(122386002)(189998001)(19580395003)(42186005)(5001960100002)(19580405001)(50466002)(230783001)(33646002)(77096005)(15975445007)(50226001)(61296003)(87976001)(81686999)(81816999)(76176999)(14496001)(46102003)(50986999)(92566002)(62966003)(77156002)(84392001)(5001770100001)(86362001)(66066001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2015 13:20:28.7624 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org Subject: Re: [OPSAWG] Stephen Farrell's Discuss on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:20:58 -0000 ----- Original Message ----- From: "Stephen Farrell" To: "The IESG" Sent: Thursday, May 14, 2015 10:09 AM > Stephen Farrell has entered the following ballot position for > draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Discuss > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for defining these. I do have a thing do briefly > discuss before balloting yes. I'll be getting out of your way > very shortly, but I want to check first to see if you agree > with me that this could be simpler and more useful. > > I note the following: > > - You're defining a bunch of HMAC options. > - Additional options for fun isn't a good idea with crypto. > - There may be platforms that do not have good APIs for > SHA224 or SHA384. > - HMAC-SHA256 without any truncation is considered perfectly > fine for this purpose and is widely used elsewhere. > - You don't need truncation for protocol reasons. > > To me, that implies that this would be better if it *only* > defined a non-truncated HMAC-SHA256 option and if all of the > rest were removed. > > Do you agree that doing so would achieve just as much of a > security improvement, but with less complexity for > implementation, test and interop? If so, should we just do > that? > Stephen, This was raised prior to adoption by OPSAWG, advice was sought and Uri Blumenthal said, 23 Sep 14 " I am for HMAC truncation. " and " There probably is no doubt that protocols based on SHA-256 and SHA-384 need to be there. SHA-512 might cause some raised brows, as could SHA-224. I still would add them - SHA-512 as SHOULD, and SHA-224 as MAY. " which convinced me to support the current position. (At one stage, the list was even longer:-). Tom Petch From nobody Thu May 14 06:30:19 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05E21A8ACB; Thu, 14 May 2015 06:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0Qu4EvNBXKr; Thu, 14 May 2015 06:30:14 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76E21A8ABB; Thu, 14 May 2015 06:30:13 -0700 (PDT) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.154.19; Thu, 14 May 2015 13:29:51 +0000 Message-ID: <04ca01d08e49$caf5af40$4001a8c0@gateway.2wire.net> From: t.petch To: Kathleen Moriarty , The IESG References: <20150512192743.10483.85863.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 14:27:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR08CA0001.eurprd08.prod.outlook.com (25.163.102.139) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(51704005)(377454003)(13464003)(62236002)(44716002)(40100003)(122386002)(189998001)(19580395003)(42186005)(5001960100002)(19580405001)(23676002)(50466002)(230783001)(33646002)(77096005)(15975445007)(50226001)(61296003)(87976001)(81686999)(81816999)(76176999)(14496001)(46102003)(50986999)(92566002)(62966003)(77156002)(84392001)(5001770100001)(5820100001)(86362001)(66066001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 May 2015 13:29:51.9797 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: opsawg@ietf.org, opsawg-chairs@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:30:16 -0000 ----- Original Message ----- From: "Kathleen Moriarty" Sent: Tuesday, May 12, 2015 8:27 PM > Kathleen Moriarty has entered the following ballot position for > draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for your work on this draft! It's great to see the improvements > in security. > > This is just a comment and not critical at all… I found this sentence at > the bottom of the second bullet of 4.1 a little odd: > as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC- > SHA-96. > > Since the guideline is to truncate the size in half and have 80 or more > bits for a HMAC, you are covered and already cite the appropriate RFCs. > Is this there just for history of previous solutions? Or would it be > better to just state the guidance so folks understand why you chose the > truncation size? You can do nothing with my comment, it's just a > question as the text had me curious. And I see that you have included > the HMAC truncation guidance in the security considerations section > already. Kathleen I am puzzled. That section, 4.1, is entitled "Deviations from the HMAC-SHA-96 Authentication Protocol" (and HMAC-MD5-96 is then added in the first paragraph). It goes on to say "Precisely, they differ from the HMAC-MD5-96 and HMAC- SHA-96 authentication protocols in the following aspects: " so omitting that last sentence would seem, IMHO, to weaken that 'precisely'. As you say, the Security Considerations do do a good job of covering the idea of truncation in general. So I think that that sentence you comment on has a place in the I-D.. Tom Petch From nobody Thu May 14 06:42:07 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13481B29EC; Thu, 14 May 2015 06:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aShmf5AG5iL; Thu, 14 May 2015 06:42:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26721B29EF; Thu, 14 May 2015 06:40:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8ECA5BEAF; Thu, 14 May 2015 14:40:16 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fvZlCTGszNZ; Thu, 14 May 2015 14:40:16 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 411D6BEAA; Thu, 14 May 2015 14:40:16 +0100 (IST) Message-ID: <5554A5BF.3050004@cs.tcd.ie> Date: Thu, 14 May 2015 14:40:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "t.petch" , The IESG References: <20150514090925.17639.73092.idtracker@ietfa.amsl.com> <04ac01d08e48$7b643a60$4001a8c0@gateway.2wire.net> In-Reply-To: <04ac01d08e48$7b643a60$4001a8c0@gateway.2wire.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org, opsawg-chairs@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org Subject: Re: [OPSAWG] Stephen Farrell's Discuss on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:42:05 -0000 Hiya, On 14/05/15 14:18, t.petch wrote: > ----- Original Message ----- > From: "Stephen Farrell" > To: "The IESG" > Sent: Thursday, May 14, 2015 10:09 AM > > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Discuss >> >> The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for defining these. I do have a thing do briefly >> discuss before balloting yes. I'll be getting out of your way >> very shortly, but I want to check first to see if you agree >> with me that this could be simpler and more useful. >> >> I note the following: >> >> - You're defining a bunch of HMAC options. >> - Additional options for fun isn't a good idea with crypto. >> - There may be platforms that do not have good APIs for >> SHA224 or SHA384. >> - HMAC-SHA256 without any truncation is considered perfectly >> fine for this purpose and is widely used elsewhere. >> - You don't need truncation for protocol reasons. >> >> To me, that implies that this would be better if it *only* >> defined a non-truncated HMAC-SHA256 option and if all of the >> rest were removed. >> >> Do you agree that doing so would achieve just as much of a >> security improvement, but with less complexity for >> implementation, test and interop? If so, should we just do >> that? >> > > Stephen, > > This was raised prior to adoption by OPSAWG, advice was sought and Uri > Blumenthal said, 23 Sep 14 > > " > I am for HMAC truncation. > " > and > " > There probably is no doubt that protocols based on SHA-256 and SHA-384 > need to be there. SHA-512 might cause some raised brows, as could > SHA-224. > I still would add them - SHA-512 as SHOULD, and SHA-224 as MAY. > " > which convinced me to support the current position. (At one stage, the > list was even longer:-). Yeah, that's the problem with advice I guess - it's not always the same:-) I'll clear the discuss since the WG considered the issue (even if briefly) and because there are matters of personal preference here where good folks differ. But fwiw I still think adding more unnecessary options as is being done here is just a bad plan so I'm holding my nose whilst doing that;-) In case it helps, my main logic for not wanting all these options is that it is overwhelmingly more likely that the code to switch between them or react to which you've received or to configure things will (due to bugs etc.) weaken security much much much more than the existence of more than one of these options could ever strengthen security. (Put another way the probability of a security bug due to adding N things here is far far higher than the probability that having N things saves the day when N-1 of them are no longer considered good crypto at some point.) So by defining more of these you are doing worse than if you only defined one of these. (The fact that all sha2 digests have the same internal structure is part of but not all of this argument.) On truncation, I'd argue that if that was a significant benefit then it'd be used everywhere and it is not. In fact I don't believe truncation is used anywhere else when there's no protocol (e.g. PDU/fragmentation) issue that causes us to want shorter MACs. I also believe that even those who for truncation would agree that the benefit of reasonable-length truncation is definitely an insignificant benefit, if any, and would also agree that that's a matter of taste when it comes to sha2 variants of hmac (assuming the protocol can live with full length, as in this case). Bottom line: I'll clear and get out of the way, but with a heartfelt plea that you ditch all of these but one. And then ditch truncation too. And so end up with just adding hmac-sha2 as many other protocols have done. S. > > Tom Petch > From nobody Thu May 14 06:48:04 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5DF1A92BC; Thu, 14 May 2015 06:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_sKenEXSZEr; Thu, 14 May 2015 06:47:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 121901B29CA; Thu, 14 May 2015 06:47:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 06:47:56 -0700 Archived-At: Cc: draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org Subject: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:48:02 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a yes on this, but am still holding my nose:-) The yes is because it's a fine thing to make sure that up-to-date options for securing protocols are available. The nose-holding is because defining multiple options that aren't significantly different in strength (if one assumes that key management is the likely weakest link) is a bad plan. In case it helps, my main logic for not wanting all these options is that it is overwhelmingly more likely that the code to switch between them or react to which you've received or to configure things will (due to bugs etc.) weaken security much much much more than the existence of more than one of these options could ever strengthen security. (Put another way the probability of a security bug due to adding N things here is far far higher than the probability that having N things saves the day when N-1 of them are no longer considered good crypto at some point.) So by defining more of these you are doing worse than if you only defined one of these. (The fact that all sha2 digests have the same internal structure is part of but not all of this argument.) On truncation, I'd argue that if that was a significant benefit then it'd be used everywhere and it is not. In fact I don't believe truncation is used anywhere else when there's no protocol (e.g. PDU/fragmentation) issue that causes us to want shorter MACs. I also believe that even those who for truncation would agree that the benefit of reasonable-length truncation is definitely an insignificant benefit, if any, and would also agree that that's a matter of taste when it comes to sha2 variants of hmac (assuming the protocol can live with full length, as in this case). Bottom line: Discuss is cleared and I'm out of the way, but with a heartfelt plea that you ditch all of these but one. And then ditch truncation too. And so end up with just adding hmac-sha2 as many other protocols have done. From nobody Thu May 14 06:58:41 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62411B2A5F; Thu, 14 May 2015 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3ds5AWDZcXO; Thu, 14 May 2015 06:58:33 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC0F1B2A5C; Thu, 14 May 2015 06:58:33 -0700 (PDT) Received: by qkgy4 with SMTP id y4so49618417qkg.2; Thu, 14 May 2015 06:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=StCK3bb2nvKDObFGzPIJEM8P8/gMcEPq/K/dnWhc18k=; b=HGTe1ROOaOO0Z5z1xLYSS2fF0fbTLD2Eq9BwdcipW+nO8Fe0awLU0O6HmVoP01m1a0 UpRWxU/AOLoYIOUECWnI+Bc/Dpgx4Hivpnv4aQl+PqRElDQiS6bwZyS5Xnp5eitngvT0 Rv7Ds+vo2S9g7Vuq1VP2tHydin/Vyr+pRruyelqcuH0g4YeyDXioIJgCLZr+tyU9tmXA wZRXeMWH36kFUeZvyeJt6wckFa8Ifol9deuvq0MhwlowMS6oBoRiZdxilp1A0qC4sJ4J izwb0WgC1UYaqF09HJS73D1BNFdJBWQ6Ase9pmw60rkFG34Q2W2+M4+mTJgERTw6WEeC xihQ== X-Received: by 10.55.26.140 with SMTP id l12mr8953286qkh.32.1431611912396; Thu, 14 May 2015 06:58:32 -0700 (PDT) Received: from [10.7.18.87] (mobile-107-107-60-5.mycingular.net. [107.107.60.5]) by mx.google.com with ESMTPSA id m25sm17865732qkh.26.2015.05.14.06.58.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 06:58:31 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 09:58:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26C5E405-11BE-4EA5-A814-A7F99123B9E8@gmail.com> References: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> To: Stephen Farrell Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org" Subject: Re: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:58:36 -0000 Sent from my iPhone > On May 14, 2015, at 9:47 AM, "Stephen Farrell" = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > I'm a yes on this, but am still holding my nose:-) >=20 > The yes is because it's a fine thing to make sure that up-to-date > options for securing protocols are available. >=20 > The nose-holding is because defining multiple options that=20 > aren't significantly different in strength (if one assumes that=20 > key management is the likely weakest link) is a bad plan. >=20 > In case it helps, my main logic for not wanting all these > options is that it is overwhelmingly more likely that the > code to switch between them or react to which you've received > or to configure things will (due to bugs etc.) weaken > security much much much more than the existence of more > than one of these options could ever strengthen security. > (Put another way the probability of a security bug due > to adding N things here is far far higher than the > probability that having N things saves the day when N-1 > of them are no longer considered good crypto at some > point.) >=20 > So by defining more of these you are doing worse than > if you only defined one of these. (The fact that all sha2 > digests have the same internal structure is part of but > not all of this argument.) >=20 > On truncation, I'd argue that if that was a significant > benefit then it'd be used everywhere and it is not. In > fact I don't believe truncation is used anywhere else > when there's no protocol (e.g. PDU/fragmentation) issue > that causes us to want shorter MACs. >=20 > I also believe that even those who for truncation would > agree that the benefit of reasonable-length truncation is > definitely an insignificant benefit, if any, and would > also agree that that's a matter of taste when it comes > to sha2 variants of hmac (assuming the protocol can live > with full length, as in this case). >=20 > Bottom line: Discuss is cleared and I'm out of the way, but=20 > with a heartfelt plea that you ditch all of these but one. And > then ditch truncation too. And so end up with just adding > hmac-sha2 as many other protocols have done. >=20 I agree with Stephen. My yes was because more secure options are defined, b= ut less would be good. Thanks, Kathleen=20 >=20 From nobody Thu May 14 09:45:53 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8C31A89C7; Thu, 14 May 2015 09:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SEMf3CM3k2e; Thu, 14 May 2015 09:45:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988EF1A898A; Thu, 14 May 2015 09:45:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUGANzQVFWHCzIm/2dsb2JhbABcgkUhKVRksmMBAQEBAQEGmVACgUFMAQEBAQEBgQuEJAEBAxIIE0UHEgEVFRYBPyYBBA4NEweICgGlca5+AQEBBwEBAQEBAQEbhhaJUAoEGjGDHoEWBZJghnKFJ4ZVC45yI2GBBSADHIFSgXJCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,430,1427774400"; d="scan'208,217";a="102679482" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2015 12:45:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 May 2015 12:45:21 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 14 May 2015 18:45:19 +0200 From: "Romascanu, Dan (Dan)" To: "ops-dir@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AdCOZUs9a9WR/IksRea1PCRH7CN39Q== Date: Thu, 14 May 2015 16:45:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "opsawg@ietf.org" Subject: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:45:52 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. T= hese comments were written with the intent of improving the operational aspects = of the IETF drafts. Comments that are not addressed in last call may be included i= n AD reviews during the IESG review. Document editors and WG chairs should treat these = comments just like any other last call comments. Document Status: Ready with Issues This is a MIB document - however my review focuses on the perspective of an= operational and manageability review. I assume that a separate RFC 4181 re= view is or will be performed. 5706 check list: A.1. Operational Considerations 1. Has deployment been discussed? See Section 2.1. * Does the document include a description of how this protocol or technology is going to be deployed and managed? * Is the proposed specification deployable? If not, how could it be improved? * Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation? * Are there any coexistence issues? DR: there is some discussion about deployment, especially in relation to th= e read-only vs. write capabilities. 2. Has installation and initial setup been discussed? See Section 2.2. * Is the solution sufficiently configurable? * Are configuration parameters clearly identified? * Are configuration parameters normalized? * Does each configuration parameter have a reasonable default value? * Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server? * How will the devices and managers find and authenticate each other? DR: no, but I do not believe that there are any special or different proble= ms than the ones encountered when installing any new SNMP agent. 3. Has the migration path been discussed? See Section 2.3. * Are there any backward compatibility issues? DR: N/A - this is the first version of this MIB module. Relationship with o= ther MIB modules is discussed. 4. Have the Requirements on other protocols and functional components been discussed? See Section 2.4. * What protocol operations are expected to be performed relative to the new protocol or technology, and what protocols and data models are expected to be in place or recommended to ensure for interoperable management? DR: N/A 5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network? * Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network? DR: the number of notifications issued by the agent may be a problem and th= e tuning is quite course. See the more detailed comments. 6. Have suggestions for verifying correct operation been discussed? See Section 2.6. * How can one test end-to-end connectivity and throughput? * Which metrics are of interest? * Will testing have an impact on the protocol or the network? DR: N/A 7. Has management interoperability been discussed? See Section 3.1. * Is a standard protocol needed for interoperable management? * Is a standard information or data model needed to make properties comparable across devices from different vendors? DR: this is a standard data model, relationship with other MIB modules is d= iscussed 8. Are there fault or threshold conditions that should be reported? See Section 3.3. * Does specific management information have time utility? * Should the information be reported by notifications? Polling? Event-driven polling? * Is notification throttling discussed? * Is there support for saving state that could be used for root cause analysis? DR: standard MIB implementation conditions apply (like system time for time= object). As in any SNMP agent implementations the operators strategy may b= e notifications-triggered polling, but this is not explicitly mentioned. No= tification throttling is not applied, and it may be useful - see comment #1= 8 9. Is configuration discussed? See Section 3.4. * Are configuration defaults and default modes of operation considered? * Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)? DR: This is a mostly read-only MIB module. Two objects are defined to enabl= e/disable notifications, the compliance section does not make them mandator= y A.2. Management Considerations Do you anticipate any manageability issues with the specification? 1. Is management interoperability discussed? See Section 3.1. * Will it use centralized or distributed management? * Will it require remote and/or local management applications? * Are textual or graphical user interfaces required? * Is textual or binary format for management information preferred? DR: remote management is possible, this MIB module makes possible interoper= able management 2. Is management information discussed? See Section 3.2. * What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol? DR: yes, this is a MIB specification 3. Is fault management discussed? See Section 3.3. * Is Liveness Detection and Monitoring discussed? * Does the solution have failure modes that are difficult to diagnose or correct? Are faults and alarms reported and logged? DR: Yes 4. Is configuration management discussed? See Section 3.4. * Is protocol state information exposed to the user? How? Are significant state transitions logged? DR: Yes, configuration management is discussed, but only read operations ar= e possible with the exception of enabling and disabling notifications. 5. Is accounting management discussed? See Section 3.5. DR: N/A 6. Is performance management discussed? See Section 3.6. * Does the protocol have an impact on network traffic and network devices? Can performance be measured? * Is protocol performance information exposed to the user? DR: Yes 7. Is security management discussed? See Section 3.7. * Does the specification discuss how to manage aspects of security, such as access controls, managing key distribution, etc. DR: Yes, see detailed comments A few more detailed comments: 1. Page 5: s/the MIB objects are managed at a hypervisor/ the MIB obj= ects are managed at the hypervisor/ 2. Page 6: s/the relationship between other MIB modules/ s/the relati= onship with other MIB modules/ 3. Page 8: figure 2 - at the top did you mean 'Notation' rather than = 'Notification'? 4. Same - in general this figure does not really help. It is not clea= r how are the Blocked and Crashed states linked to the rest. I would at lea= st add the numbers of the states in the VirtualMachineOperState TC 5. Page 9: The statement about the MIB module providing writeable obj= ects that can be used for non-persistent changes like changing memory alloc= ation or CPU allocation seems to be a leftover from previous versions - in = any case it is not true any longer for this version of the MIB module. 6. I frankly do not know if the OID tree structure that spreads in pa= ges 9 to 11 is useful at all. Who needs it? And if anybody needs this, it c= an be obtained from any MIB tool. I believe that a short list of the MIB gr= oups and tables and a few words about what each of these does is sufficient= . 7. Page 12: I find the second paragraph in section 5 confusing - mayb= e it's a language issue. The last sentence for example does not makes sense= (what does 'the objects of this information' mean?) 8. Same about the 4th paragraph in the same section and page. What do= es the first sentence mean? ('the objects ... are not also included') 9. Page 15: the explanation of the destroy(5) value in the VirtualMa= chineAdminState TC may confuse. We do not allow changing VM admin states by= write operations. Of course, an agent implementing this MIB module may rea= d this state and reflect it in an object that uses this SYNTAX. I believe t= hat some text about this usage of the TC needs to be added. 10. Page 20: is there any reason that the TC VirtualMachineStorageAccess = has no 'unknown' enumeration defined? 11. Page 20-21: Why is the VirtualMachineStorageType limited to two media= types only? Would not an IANA-administered TC be more appropriate here? 12. Page 24: It is not clear to me what is an 'administered region' menti= oned in the DESCRIPTION clause of the vmUUID object 13. Page 25: why 'power' in the DESCRIPTION of the vmAdminState? 14. Page 26: it looks like the intent of the vmMemUnit is to use bytes as= unit of expressing memory size - this should be explicitly mentioned 15. Page 33: same comment relative to vmStorageSizeUnit 16. Page 34-35: I have a big question mark about how the vmStorageReadLat= ency and vmStorageWriteLatency objects need to be used. First the usage of = the Counter64 syntax seems odd as these objects do not count anything and t= heir increase is not unitary. Second I do not know how to interpret them. W= hat does say a reading of 'a million' or of 'a billion' mean? It really mak= es no sense if not interpreted in conjunction with the number of respective= I/O operations, media type, etc. I guess that the implementation of these = objects is not trivial and probably requires HW support taking into conside= ration the microseconds resolution. At a minimum I guess that some text rec= ommending to the operators how they are supposed to be used is needed. 17. I am concerned that the current way of defining the notifications swi= tches is too course. Hypervisors may have many VMs in charge, and if each g= enerates one notification per each state changes the numbers can become big= even in normal operation. Maybe some throttling mechanism would be useful.= Or maybe a couple of more switches that allow to enable only 'critical' no= tifications (e.g. vmCrashed). 18. The Security Considerations section does not include a description of= the security hazards of mis-configuration of the writeable objects (danger= of flooding the network with unwanted notifications) Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the Operational directorate'= s

ongoing effort to review all IETF documents being processed by the IE= SG.  These

comments were written with the intent of improving the operational as= pects of the

IETF drafts. Comments that are not addressed in last call may be incl= uded in AD reviews

during the IESG review.  Document editors and WG chairs should t= reat these comments

just like any other last call comments.

 

 

Document Status: Ready with Issues

 

This is a MIB document – however my review foc= uses on the perspective of an operational and manageability review. I assum= e that a separate RFC 4181 review is or will be performed.

 

5706 check list:

 

A.1.  Operational Considerations=

 
   1.  Has deployment been =
discussed?  See Section 2.1.
 
       *&nbs=
p; Does the document include a description of how this protocol<=
/span>
       =
   or technology is going to be deployed and managed?<=
/span>
 
       *&nbs=
p; Is the proposed specification deployable?  If not, how could
       =
   it be improved?
 
       *&nbs=
p; Does the solution scale well from the operational and<=
/pre>

       =
   management perspective?  Does the proposed approach have =
any


       =
   scaling issues that could affect usability for large-scale


       =
   operation?


 


       *&nbs=
p; Are there any coexistence issues?


 


DR: there is some discussion about deploym=
ent, especially in relation to the read-only vs. write capabilities. <=
/o:p>


 


   2.  Has installation and=
 initial setup been discussed?  See


       Secti=
on 2.2.


 


       *&nbs=
p; Is the solution sufficiently configurable?


 


       *&nbs=
p; Are configuration parameters clearly identified?


 


       *&nbs=
p; Are configuration parameters normalized?


 


       *&nbs=
p; Does each configuration parameter have a reasonable default


       =
   value?


 


       *&nbs=
p; Will configuration be pushed to a device by a configuration


       =
   manager, or pulled by a device from a configuration server?


 


       *&nbs=
p; How will the devices and managers find and authenticate each<=
/span>


       =
   other?


 


DR: no, but I do not believe that there ar=
e any special or different problems than the ones encountered when installi=
ng any new SNMP agent. 


 


   3.  Has the migration pa=
th been discussed?  See Section 2.3.


 


       * &nb=
sp;Are there any backward compatibility issues?


 


DR: N/A – this is the first version =
of this MIB module. Relationship with other MIB modules is discussed. =



 


 


   4.  Have the Requirement=
s on other protocols and functional


       compo=
nents been discussed?  See Section 2.4.


     *  What prot=
ocol operations are expected to be performed relative

       =
   to the new protocol or technology, and what protocols and data=



       =
   models are expected to be in place or recommended to ensure


       =
   for interoperable management?


 


DR: N/A


 


   5.  Has the impact on ne=
twork operation been discussed?  See


       Secti=
on 2.5.


 


       *&nbs=
p; Will the new protocol significantly increase traffic load on<=
/span>


       =
   existing networks?


 


       *&nbs=
p; Will the proposed management for the new protocol

       =
   significantly increase traffic load on existing networks?=



 


       *&nbs=
p; How will the new protocol impact the behavior of other=



       =
   protocols in the network?  Will it impact performance (e.=
g.,


       =
   jitter) of certain types of applications running in the same


       =
   network?


 


       *&nbs=
p; Does the new protocol need supporting services (e.g., DNS or<=
/span>


       =
   Authentication, Authorization, and Accounting - AAA) added to<=
o:p>


       =
   an existing network?


 


DR: the number of notifications issued by =
the agent may be a problem and the tuning is quite course. See the more det=
ailed comments. 


 


   6.  Have suggestions for=
 verifying correct operation been discussed?


       See S=
ection 2.6.


 


       *&nbs=
p; How can one test end-to-end connectivity and throughput?


 


       *&nbs=
p; Which metrics are of interest?


 


       *&nbs=
p; Will testing have an impact on the protocol or the network?


 


DR: N/A


 


   7.  Has management inter=
operability been discussed?  See Section 3.1.


 


       *&nbs=
p; Is a standard protocol needed for interoperable management?


 


       *&nbs=
p; Is a standard information or data model needed to make=



       =
   properties comparable across devices from different vendors?


 


DR: this is a standard data model, relatio=
nship with other MIB modules is discussed


 


   8.  Are there fault or t=
hreshold conditions that should be reported?


       See S=
ection 3.3.


 


       *&nbs=
p; Does specific management information have time utility?


 


       *&nbs=
p; Should the information be reported by notifications?  Polling?=



       =
   Event-driven polling?


 


       *&nbs=
p; Is notification throttling discussed?


*  Is there support for saving state =
that could be used for root


       =
   cause analysis?


 


DR: standard MIB implementation conditions=
 apply (like system time for time object). As in any SNMP agent implementat=
ions the operators strategy may be notifications-triggered polling, but thi=
s is not explicitly mentioned. Notification throttling is not applied, and =
it may be useful – see comment #18


 


 


   9.  Is configuration dis=
cussed?  See Section 3.4.


 


       *&nbs=
p; Are configuration defaults and default modes of operation


       =
   considered?


 


       *&nbs=
p; Is there discussion of what information should be preserved


       =
   across reboots of the device or the management system?  C=
an


       =
   devices realistically preserve this information through hard


       =
   reboots where physical configuration might change (e.g., cards=



       =
   might be swapped while a chassis is powered down)?<=
/span>


 


 


DR: This is a mostly read-only MIB module.=
 Two objects are defined to enable/disable notifications, the compliance se=
ction does not make them mandatory 


 


A.2.  Management Considerations<=
/o:p>


 


   Do you anticipate any managea=
bility issues with the specification?


 


   1.  Is management intero=
perability discussed?  See Section 3.1.


 


       *&nbs=
p; Will it use centralized or distributed management?

 


       *&nbs=
p; Will it require remote and/or local management applications?<=
/span>


 


       *&nbs=
p; Are textual or graphical user interfaces required?

 


       *&nbs=
p; Is textual or binary format for management information=



       =
   preferred?


 


DR: remote management is possible, this MI=
B module makes possible interoperable management


 


 


   2.  Is management inform=
ation discussed?  See Section 3.2.


 


       *&nbs=
p; What is the minimal set of management (configuration, faults,=



       =
   performance monitoring) objects that need to be instrumented


       =
   in order to manage the new protocol?


 


DR: yes, this is a MIB specification<=
/o:p>


 


   3.  Is fault management =
discussed?  See Section 3.3.


 


       *&nbs=
p; Is Liveness Detection and Monitoring discussed?


 


       *&nbs=
p; Does the solution have failure modes that are difficult to


       =
   diagnose or correct?  Are faults and alarms reported and<=
o:p>


       =
   logged?


 


DR: Yes


 


   4.  Is configuration man=
agement discussed?  See Section 3.4.


 


       *&nbs=
p; Is protocol state information exposed to the user?  How?  Are<=
o:p>


       =
   significant state transitions logged?


 


DR: Yes, configuration management is discu=
ssed, but only read operations are possible with the exception of enabling =
and disabling notifications. 


 


 


5.  Is accounting management discusse=
d?  See Section 3.5.


 


DR: N/A


 


 


   6.  Is performance manag=
ement discussed?  See Section 3.6.


 


       *&nbs=
p; Does the protocol have an impact on network traffic and


       =
   network devices?  Can performance be measured?=



 


       *&nbs=
p; Is protocol performance information exposed to the user?


 


DR: Yes


 


   7.  Is security manageme=
nt discussed?  See Section 3.7.


 


       *&nbs=
p; Does the specification discuss how to manage aspects of


       =
   security, such as access controls, managing key distribution,<=
o:p>


       =
   etc.




DR: Yes, see detailed comments


 


A few more detailed comments: 


 


1.     &=
nbsp;
Page 5: s/the MIB objects =
are managed at a hypervisor/ the MIB objects are managed at the hypervisor/=



2.     &=
nbsp;
Page 6: s/the relationship=
 between other MIB modules/ s/the relationship with other MIB modules/=



3.     &=
nbsp;
Page 8: figure 2 – a=
t the top did you mean ‘Notation’ rather than ‘Notificati=
on’?



4.     &=
nbsp;
Same – in general th=
is figure does not really help. It is not clear how are the Blocked and Cra=
shed states linked to the rest. I would at least add the numbers of the sta=
tes in the VirtualMachineOperState TC


5.     &=
nbsp;
Page 9: The statement abou=
t the MIB module providing writeable objects that can be used for non-persi=
stent changes like changing memory allocation or CPU allocation seems to be=
 a leftover from previous versions
 – in any case it is not true any longer for this version of the MIB =
module. 



6.     &=
nbsp;
I frankly do not know if t=
he OID tree structure that spreads in pages 9 to 11 is useful at all. Who n=
eeds it? And if anybody needs this, it can be obtained from any MIB tool. I=
 believe that a short list of the
 MIB groups and tables and a few words about what each of these does is suf=
ficient.


7.     &=
nbsp;
Page 12: I find the second=
 paragraph in section 5 confusing – maybe it’s a language issue=
. The last sentence for example does not makes sense (what does ‘the =
objects of this information’ mean?)


8.     &=
nbsp;
Same about the 4th paragraph in the same section and page. What does the first sentence me=
an? (‘the objects … are not also included’)

9.     &=
nbsp;
Page 15:  the explana=
tion of the destroy(5) value in the VirtualMachineAdminState TC may confuse=
. We do not allow changing VM admin states by write operations. Of course, =
an agent implementing this MIB module may
 read this state and reflect it in an object that uses this SYNTAX. I belie=
ve that some text about this usage of the TC needs to be added.



10.  
Page 20: is there any reas=
on that the TC VirtualMachineStorageAccess has no ‘unknown’ enu=
meration defined?


11.  
Page 20-21: Why is the Vir=
tualMachineStorageType limited to two media types only? Would not an IANA-a=
dministered TC be more appropriate here?


12.  
Page 24: It is not clear t=
o me what is an ‘administered region’ mentioned in the DESCRIPT=
ION clause of the vmUUID object


13.  
Page 25: why ‘power&=
#8217; in the DESCRIPTION of the vmAdminState?


14.  
Page 26: it looks like the=
 intent of the vmMemUnit is to use bytes as unit of expressing memory size =
– this should be explicitly mentioned


15.  
Page 33: same comment rela=
tive to vmStorageSizeUnit


16.  
Page 34-35: I have a big q=
uestion mark about how the vmStorageReadLatency and vmStorageWriteLatency o=
bjects need to be used. First the usage of the Counter64 syntax seems odd a=
s these objects do not count anything
 and their increase is not unitary. Second I do not know how to interpret t=
hem. What does say a reading of ‘a million’ or of ‘a bill=
ion’ mean? It really makes no sense if not interpreted in conjunction=
 with the number of respective I/O operations, media type,
 etc. I guess that the implementation of these objects is not trivial and p=
robably requires HW support taking into consideration the microseconds reso=
lution. At a minimum I guess that some text recommending to the operators h=
ow they are supposed to be used
 is needed. 


17.  
I am concerned that the cu=
rrent way of defining the notifications switches is too course. Hypervisors=
 may have many VMs in charge, and if each generates one notification per ea=
ch state changes the numbers can become
 big even in normal operation. Maybe some throttling mechanism would be use=
ful. Or maybe a couple of more switches that allow to enable only ‘cr=
itical’ notifications (e.g. vmCrashed).



18.  
The Security Consideration=
s section does not include a description of the security hazards of mis-con=
figuration of the writeable objects (danger of flooding the network with un=
wanted notifications)



 


Thanks and Regards,


 


Dan


 
--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27AZFFEXMB04globa_-- From nobody Mon May 18 08:46:22 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FC01AC3F1; Mon, 18 May 2015 08:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykm123zp_9rO; Mon, 18 May 2015 08:46:15 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9D31AC3F2; Mon, 18 May 2015 08:46:15 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C2D951A009B; Mon, 18 May 2015 17:45:57 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0AIOcXh6U-qn; Mon, 18 May 2015 17:45:56 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id B04851A0098; Mon, 18 May 2015 17:45:56 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 18 May 2015 17:46:09 +0200 Message-ID: <555A0940.80009@secunet.com> Date: Mon, 18 May 2015 17:46:08 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Stephen Farrell References: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> <26C5E405-11BE-4EA5-A814-A7F99123B9E8@gmail.com> In-Reply-To: <26C5E405-11BE-4EA5-A814-A7F99123B9E8@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.212] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org" Subject: Re: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:46:20 -0000 Kathleen Moriarty schrieb am 14.05.2015 um 15:58: > > I agree with Stephen. My yes was because more secure options are defined, but less would be good. There was some discussion on this (admittedly by quite few participants) and my summary was as follows > Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected? > - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted. > - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY > - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri. > - David: SHA-256-192 and SHA-512-384. > (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of > protocols in the current draft.) Then I suggested the subset as it is currently defined and everyone agreed. It was a compromise. But considering the individual opinions, It would be safe to delete the SHA-224 option. -- Johannes From nobody Mon May 18 09:24:58 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13061ACEFF for ; Mon, 18 May 2015 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0q8_d-sSkK5 for ; Mon, 18 May 2015 09:24:53 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2D21AD061 for ; Mon, 18 May 2015 09:24:50 -0700 (PDT) Received: by wgjc11 with SMTP id c11so33338660wgj.0 for ; Mon, 18 May 2015 09:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wvSObE+DmJU8tXTC0d6iTqBMiYZSrd2xAjOUzAm6FF4=; b=IxZTnVPXOYrclRYK7gqNsbnDkJv+I9DCojQ9dkM0YVI/I77+dLJIQCiuUoa4uXvQgs PpghGfXGB9TSnQEnTWecbRe4rNlg2GZFR88IQniSqoJ6xhEX0kH3EMmQH5RPrx2eS+BM 3DMwxIFC4Wkp124YT6wFSwndl5NE7m/firCNjpIm/7GpLNKDdWtXYQHBX3hKAHHWAveT DHPPq5rIs2XqBydS3O6VfvJaj5/fqo4aJZh1UaoNaW1cyCD8at7uh6tQ2Mm9NiXlWXea 5ibbN1678iVfkyDoM0jh9qIte6EuqlWptdB201p3mg18mG2z0aHHTeGhce+j42AOdTdo B3jw== X-Gm-Message-State: ALoCoQmLHF4lmR2W83+DgjU10/TyhH3jY7YRVPb5QcZeOngpyrj5A9OQQo7S3mArLEaqw+8ufkb0 MIME-Version: 1.0 X-Received: by 10.180.82.100 with SMTP id h4mr7109346wiy.61.1431966288826; Mon, 18 May 2015 09:24:48 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Mon, 18 May 2015 09:24:48 -0700 (PDT) In-Reply-To: <555A0940.80009@secunet.com> References: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> <26C5E405-11BE-4EA5-A814-A7F99123B9E8@gmail.com> <555A0940.80009@secunet.com> Date: Mon, 18 May 2015 18:24:48 +0200 Message-ID: From: Warren Kumari To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org" , Kathleen Moriarty , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org" , Stephen Farrell Subject: Re: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:24:54 -0000 On Mon, May 18, 2015 at 5:46 PM, Johannes Merkle wrote: > Kathleen Moriarty schrieb am 14.05.2015 um 15:58: >> >> I agree with Stephen. My yes was because more secure options are defined, but less would be good. > > There was some discussion on this (admittedly by quite few participants) and my summary was as follows > >> Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected? >> - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted. >> - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY >> - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri. >> - David: SHA-256-192 and SHA-512-384. >> (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of >> protocols in the current draft.) > > Then I suggested the subset as it is currently defined and everyone agreed. It was a compromise. But considering the > individual opinions, It would be safe to delete the SHA-224 option. Fine with me (chair / doc shepherd) W (this email not actually needed, but figured it'd didn't hurt to mention :-)) > > > > -- > Johannes -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon May 18 09:31:14 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89081AC44E; Mon, 18 May 2015 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Et8qXCxkvC; Mon, 18 May 2015 09:31:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0302C1A916B; Mon, 18 May 2015 09:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6025DBF01; Mon, 18 May 2015 17:31:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gOYS29_XDCI; Mon, 18 May 2015 17:31:01 +0100 (IST) Received: from [172.20.5.45] (unknown [122.112.117.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6C51FBE7D; Mon, 18 May 2015 17:30:55 +0100 (IST) Message-ID: <555A13B8.5080009@cs.tcd.ie> Date: Mon, 18 May 2015 17:30:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Johannes Merkle , Kathleen Moriarty References: <20150514134756.7646.39713.idtracker@ietfa.amsl.com> <26C5E405-11BE-4EA5-A814-A7F99123B9E8@gmail.com> <555A0940.80009@secunet.com> In-Reply-To: <555A0940.80009@secunet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp.shepherd@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp.ad@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp@ietf.org" Subject: Re: [OPSAWG] Stephen Farrell's Yes on draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:31:10 -0000 On 18/05/15 16:46, Johannes Merkle wrote: > Kathleen Moriarty schrieb am 14.05.2015 um 15:58: >> I agree with Stephen. My yes was because more secure options are defined, but less would be good. > There was some discussion on this (admittedly by quite few participants) and my summary was as follows > >> Question 3: Which (sub)set of protocols (hash function, MAC length) should be selected? >> - Johannes: SHA-256-192 as MUST, SHA-512-256 as SHOULD, all other can be MAY or omitted. >> - Uri: SHA-256-192 and SHA-384-320 as MUST, SHA-512-256 as SHOULD, and SHA-224-??? as MAY >> - Tom: AFAIU, he agrees with the preferences expressed by David, Johannes and Uri. >> - David: SHA-256-192 and SHA-512-384. >> (In all the above cases, the preferences were not that strong, there was mainly the wish to reduce the number of >> protocols in the current draft.) > Then I suggested the subset as it is currently defined and everyone agreed. It was a compromise. But considering the > individual opinions, It would be safe to delete the SHA-224 option. Thanks for taking the time to discuss this, and eliminating some options is good. That said, I (still:-) think we're slightly doing the wrong thing here; the additional options offer no real security benefit in this context that I can see and nor does the truncation and the existence of options has downsides. I suspect developers, testers and those deploying might curse us for being a committee of compromisers:-) But I asked and you thought about it, so in the absence of new information, we're all set, Thanks, S. From nobody Tue May 19 11:00:30 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24FF1A8A4B for ; Tue, 19 May 2015 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozuN2ok_2ouU for ; Tue, 19 May 2015 11:00:26 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573FA1A8A1F for ; Tue, 19 May 2015 11:00:26 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so26868601wgb.3 for ; Tue, 19 May 2015 11:00:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XE0rgu90Ek0pJRS7/DLDGoeibAot/ucjTECqwZYk5RI=; b=I36uzE06M4IPNuj5qh4atd33/BW1p+yb3G7k0P6vC6OmOvOQIqTlKBceVckXspzKDS tbOHf/H4kmUZcZIriCKGNaC4dQjZIL6q/zO/c6BR3WpjbiatBRsNBUJn3acHQqzBbJW1 sUyMkvvJVaibiqGm+YgV1Lz+qO5MduBQweKymaSKgX3xbdlpCfdK/Sv53P3SCHIC/tJg +LIZ2+sqK7LDCDvGQRq26bP2cp+A8aWMwpmeP29wG4QzVa/tC+dLbhtCjeIDon7dRVjF 8iRzZxPm1XvzvWgCbdry7DUhXLryB1vjrKnC/3pHA+hM4g8TOXEfydeGfONBDM4UflgE uaaA== X-Gm-Message-State: ALoCoQm/L2I21yCEytIBwV+OcRuTQ32N2NLYff5jC/O/oALzXN7n+iLGynuwBOtZYCyQnUpWsh+Y MIME-Version: 1.0 X-Received: by 10.180.188.13 with SMTP id fw13mr33354448wic.89.1432058423594; Tue, 19 May 2015 11:00:23 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Tue, 19 May 2015 11:00:23 -0700 (PDT) Date: Tue, 19 May 2015 14:00:23 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Call for agenda items for Prague. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:00:29 -0000 Hi all, We have requested a slot for the joint OpsAWG / OpsArea meeting in Prague. Please send over requests for agenda time. Please remember that we give time to drafts that have already received significant discussion on list. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 21 11:09:55 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738B1A034F for ; Thu, 21 May 2015 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AEZYZZxI5Xy for ; Thu, 21 May 2015 11:09:52 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2CB1A036F for ; Thu, 21 May 2015 11:09:51 -0700 (PDT) Received: by wizk4 with SMTP id k4so23731885wiz.1 for ; Thu, 21 May 2015 11:09:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=JzZYx5SJoxuMFhiCgfBiXln8PQYoHRiWNwdgkgzGDnM=; b=GVQD/Sg+gSZGtkM3RtcZdN+vEtV1/oABESHmDUU7mF0DQ6hjX5zibzvxvN6sdPfKyO Z00iNkfzqBUSqVkTwKOIEXcToAmWhMhZJYfEfR+h8OATiN21i0f43rb1BGOnLlIkffVj dzzvIuXDAvsL2Nbf3HeD842+HKfViAojZeNaqFaAcLMOGVanA9ifvbHOdkQK0nP2a17G r50NnIHpG4ma2IOZtWXgUhmQDNh2T606TNPgKeqWKfFpnaYRDe5pDUioCJrVV5vs+biE K3+/kZky7tfCK3PmWHSYSHMV08RVmF2n4FaUDvT5OP7Q1b8XPPYiE0A0ZJmKwroxtHqv 5Q0A== X-Gm-Message-State: ALoCoQkodijgGUjMj85dGA1OLfJz/9PemHu1bB19O0Gspy/itOI/u/I9lVAhAdBO6gp3k0Xgr2ST MIME-Version: 1.0 X-Received: by 10.181.27.131 with SMTP id jg3mr29444079wid.89.1432231790635; Thu, 21 May 2015 11:09:50 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Thu, 21 May 2015 11:09:50 -0700 (PDT) Date: Thu, 21 May 2015 14:09:50 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] NomCom 2015-2016 Call for Volunteers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:09:54 -0000 Hi all, I wanted to make sure that you had all seen the NomCom 2015-2016 Call for Volunteers emails form Harald. This should be viewed as an important responsibility - having a strong IAB and IESG is important to a well functioning IETF. *Please* consider volunteering - and remember, the more people who volunteer, the less likely any one of us is to be selected... ----- The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. 255 people volunteered by ticking the box on the IETF 92 registration form. 149 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 22 23:37:32 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710421A9133; Fri, 22 May 2015 23:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_1KVggr0miL; Fri, 22 May 2015 23:37:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC421A911D; Fri, 22 May 2015 23:37:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D9FE11315; Sat, 23 May 2015 08:37:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W08GE-qwstF0; Sat, 23 May 2015 08:37:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 23 May 2015 08:37:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25A982002B; Sat, 23 May 2015 08:37:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PrIATsovEl-E; Sat, 23 May 2015 08:37:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33FDA20013; Sat, 23 May 2015 08:37:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E026A3355520; Sat, 23 May 2015 08:37:16 +0200 (CEST) Date: Sat, 23 May 2015 08:37:16 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150523063714.GB58453@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "ops-dir@ietf.org" , "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "opsawg@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 06:37:28 -0000 On Thu, May 14, 2015 at 04:45:19PM +0000, Romascanu, Dan (Dan) wrote: [...] Dan, many thanks for the review. I am skipping over the smaller nits. > 16. Page 34-35: I have a big question mark about how the > vmStorageReadLatency and vmStorageWriteLatency objects need to be > used. First the usage of the Counter64 syntax seems odd as these > objects do not count anything and their increase is not > unitary. Second I do not know how to interpret them. What does say a > reading of 'a million' or of 'a billion' mean? It really makes no > sense if not interpreted in conjunction with the number of > respective I/O operations, media type, etc. I guess that the > implementation of these objects is not trivial and probably requires > HW support taking into consideration the microseconds resolution. At > a minimum I guess that some text recommending to the operators how > they are supposed to be used is needed. The only SMIv2 requirement for a Counter64 is that it increases monotonically which is the case here. There is no requirement that a counter increases unitary. By making this a counter, it is clear that one has to to look at the first derivative, that is the change of the counter over time. Obviously, on a lightly loaded hypervisor, the latency should be small but in situations where it increases significantly, you are likely hitting a slowdown of your VMs due to I/O contention instead of CPU limits. These objects are there to identify such situations (and the virtual storage devices involved). > 17. I am concerned that the current way of defining the > notifications switches is too course. Hypervisors may have many VMs > in charge, and if each generates one notification per each state > changes the numbers can become big even in normal operation. Maybe > some throttling mechanism would be useful. Or maybe a couple of more > switches that allow to enable only 'critical' notifications > (e.g. vmCrashed). The only situation I can think of where the number of notifications will be significant is during restart of a whole rack with many hypervisors inside. But even then, things usually take time. (I think our Xen hypervisors actually create virtual machines sequentially and hence the notifications get actually spaced over time.) It is not unlikely that the operating systems inside the hypervisors during startup generate significantly more network traffic compared to a few hypervisor notifications. That said, during the development of the MIB module we moved from generic state change notifications to a set of specific notifications and this allows to use SNMPv3 notification filtering to filter out notifications people find not useful. > 18. The Security Considerations section does not include a description of the security hazards of mis-configuration of the writeable objects (danger of flooding the network with unwanted notifications) > Perhaps text can be added but I am not sure I see that a data center network will experience any significant load due to these notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon May 25 17:23:50 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C191A0AFE; Mon, 25 May 2015 17:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMuX2d7vTpNo; Mon, 25 May 2015 17:23:45 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB621A0097; Mon, 25 May 2015 17:23:45 -0700 (PDT) Received: by iesa3 with SMTP id a3so81000951ies.2; Mon, 25 May 2015 17:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=MtyKizI/SqBBQwZ2lcqxn1DOSaX47OUc9Pwqj1/5yfk=; b=TjCfcMbQx9CHs4kHm4ShRUXmg9T33mxIGtSre4xWPc9uzKZuO2s7CKVzO26ldzs9JU JrFjv+SbPXuwn7mXBk+KNnljYAVqtWXvs/80LD6LsOGy9QfwSb/reOWZX3Ksprx4nIm8 OqxIJhiXnsMCS418skmDrHdVCRl88pqIHjdQCCk6aOGlo+aDY+qK4sZgm6DNAH9tsFSd biB47jvBP4pTm8rOR3t02afRdwPZuRUgT/fS0AVg4JYU1j/rNs1SxEW7OREQvNHwj+wJ 80ZrwvqjWnMlm3mu//Rh694mOaxSOWUGcEWFqgI866NniVftpuYWc2jXVj+iZxmlwqGq mhNQ== X-Received: by 10.107.137.170 with SMTP id t42mr31882420ioi.16.1432599824829; Mon, 25 May 2015 17:23:44 -0700 (PDT) Received: from [192.168.1.135] ([108.63.145.250]) by mx.google.com with ESMTPSA id c20sm9839574ioc.40.2015.05.25.17.23.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2015 17:23:44 -0700 (PDT) Message-ID: <5563BD0F.7080108@gmail.com> Date: Mon, 25 May 2015 20:23:43 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Spencer Dawkins Subject: [OPSAWG] Update of NATV2MIB -- draft-perrault-behave-natv2-mib-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 00:23:46 -0000 I have updated the NAT MIB document in response to Security, Operations and Management, and GEN-ART review comments. I hope that is the last substantive update. Thanks to Takeshi Takahashi, Sheng Jiang, Bert Wijnen, and Suresh Krishnan, whom I forgot to acknowledge in the document itself. I'll add them during AUTH48 if not sooner. Changes provided by the update: Re-typed the threshold values for the notifications from Unsigned32 to Integer32 so the notifications could all be disabled by setting them to -1 (had a mixture of 0 and -1 before -- human factors issue). Removed all text specifications of default values except one in the Management Considerations section that is more like an example, to avoid a potential maintenance issue where the DEFVAL gets updated but the text does not, or vice versa. Re-numbered the NATPoolEntry objects from 13 onward (there was a gap in numbering in version -03). Tom Taylor From nobody Mon May 25 18:45:56 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89601A8777; Mon, 25 May 2015 18:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps_E418STDmy; Mon, 25 May 2015 18:45:53 -0700 (PDT) Received: from mail.wide.ad.jp (mail.wide.ad.jp [IPv6:2001:200:0:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 089381A8776; Mon, 25 May 2015 18:45:52 -0700 (PDT) Received: from [202.214.86.179] ([202.214.86.179]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id t4Q1jovg026768 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO); Tue, 26 May 2015 10:45:50 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Keiichi SHIMA In-Reply-To: <20150523063714.GB58453@elstar.local> Date: Tue, 26 May 2015 10:45:48 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 01:45:56 -0000 Hi all, >> 17. I am concerned that the current way of defining the >> notifications switches is too course. Hypervisors may have many VMs >> in charge, and if each generates one notification per each state >> changes the numbers can become big even in normal operation. Maybe >> some throttling mechanism would be useful. Or maybe a couple of more >> switches that allow to enable only 'critical' notifications >> (e.g. vmCrashed). >=20 > The only situation I can think of where the number of notifications > will be significant is during restart of a whole rack with many > hypervisors inside. But even then, things usually take time. (I think > our Xen hypervisors actually create virtual machines sequentially and > hence the notifications get actually spaced over time.) It is not > unlikely that the operating systems inside the hypervisors during > startup generate significantly more network traffic compared to a few > hypervisor notifications. That said, during the development of the MIB > module we moved from generic state change notifications to a set of > specific notifications and this allows to use SNMPv3 notification > filtering to filter out notifications people find not useful. I and Asai talked locally and we agree Juergen that the number of = notification events is manageable. However we noticed that the 'vmBlocked' notification may be a problem. = The 'blocked' state is defined as 'The operational state of the virtual = machine indicating the execution of the virtual machine is currently = blocked, e.g., waiting for some action of the hypervisor to finish. = This is a transient state from/to other states.' This state transition = event may appear more frequently than other events, since the state is = caused by the I/O scheduler of the hyper visor implementation. We think we can simply remove the 'vmBlocked' notification. The = 'blocked' state is a transient state and typically return to the = previous state immediately (once the pending I/O requests completed). --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc > On 2015/05/23, at 15:37, Juergen Schoenwaelder = wrote: >=20 > On Thu, May 14, 2015 at 04:45:19PM +0000, Romascanu, Dan (Dan) wrote: >=20 > [...] >=20 > Dan, >=20 > many thanks for the review. I am skipping over the smaller nits. >=20 >> 16. Page 34-35: I have a big question mark about how the >> vmStorageReadLatency and vmStorageWriteLatency objects need to be >> used. First the usage of the Counter64 syntax seems odd as these >> objects do not count anything and their increase is not >> unitary. Second I do not know how to interpret them. What does say a >> reading of 'a million' or of 'a billion' mean? It really makes no >> sense if not interpreted in conjunction with the number of >> respective I/O operations, media type, etc. I guess that the >> implementation of these objects is not trivial and probably requires >> HW support taking into consideration the microseconds resolution. At >> a minimum I guess that some text recommending to the operators how >> they are supposed to be used is needed. >=20 > The only SMIv2 requirement for a Counter64 is that it increases > monotonically which is the case here. There is no requirement that a > counter increases unitary. By making this a counter, it is clear that > one has to to look at the first derivative, that is the change of the > counter over time. Obviously, on a lightly loaded hypervisor, the > latency should be small but in situations where it increases > significantly, you are likely hitting a slowdown of your VMs due to > I/O contention instead of CPU limits. These objects are there to > identify such situations (and the virtual storage devices involved). >=20 >> 17. I am concerned that the current way of defining the >> notifications switches is too course. Hypervisors may have many VMs >> in charge, and if each generates one notification per each state >> changes the numbers can become big even in normal operation. Maybe >> some throttling mechanism would be useful. Or maybe a couple of more >> switches that allow to enable only 'critical' notifications >> (e.g. vmCrashed). >=20 > The only situation I can think of where the number of notifications > will be significant is during restart of a whole rack with many > hypervisors inside. But even then, things usually take time. (I think > our Xen hypervisors actually create virtual machines sequentially and > hence the notifications get actually spaced over time.) It is not > unlikely that the operating systems inside the hypervisors during > startup generate significantly more network traffic compared to a few > hypervisor notifications. That said, during the development of the MIB > module we moved from generic state change notifications to a set of > specific notifications and this allows to use SNMPv3 notification > filtering to filter out notifications people find not useful. >=20 >> 18. The Security Considerations section does not include a = description of the security hazards of mis-configuration of the = writeable objects (danger of flooding the network with unwanted = notifications) >>=20 >=20 > Perhaps text can be added but I am not sure I see that a data center > network will experience any significant load due to these = notifications. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon May 25 19:56:18 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897C31A894A for ; Mon, 25 May 2015 19:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9q6FMPg7SXA for ; Mon, 25 May 2015 19:56:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCB11A88FD for ; Mon, 25 May 2015 19:56:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWM75174; Tue, 26 May 2015 02:56:09 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 03:56:07 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.68]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 26 May 2015 10:56:02 +0800 From: Youjianjie To: "opsawg@ietf.org" Thread-Topic: =?utf-8?B?bmV3IHZlcnNpb24gLy/nrZTlpI06IFJlOltPUFNBV0ddIOetlOWkjTogIA==?= =?utf-8?B?562U5aSNOiAgQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ=?= Thread-Index: AQHQd35riU7jBcxk40yAXi8/Q1dyUZ2NzlyA Date: Tue, 26 May 2015 02:56:01 +0000 Message-ID: References: <552c8b59000001b62a8187000cdcdc> <1429103876wo3tobl3kdqijlxinie7jq> In-Reply-To: <1429103876wo3tobl3kdqijlxinie7jq> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: multipart/alternative; boundary="_000_F6C28B32DA084644BB6C8D0BD65B669D187508nkgeml509mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OPSAWG] =?utf-8?b?bmV3IHZlcnNpb24gLy/nrZTlpI06IFJlOiDnrZTlpI06?= =?utf-8?q?__=E7=AD=94=E5=A4=8D=3A__Another_CAPWAP_document?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 02:56:16 -0000 --_000_F6C28B32DA084644BB6C8D0BD65B669D187508nkgeml509mbschina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpXZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gbWVyZ2luZyBhbGwgdGhl IGNvbW1lbnRzIHdl4oCZcmUgcmVjZWl2ZWQuDQoNClRoZXJlJ3JlIG5vIGR1cGxpY2F0aW9uIG9y IGNvbmZsaWN0aW9uIHdpdGggdGhlIGN1cnJlbnQgV0cgZHJhZnQuIFlvdXIgY29tbWVudHMgYXJl IGFwcHJlY2lhdGVkLg0KDQoNCg0KVGhhbmtzLA0KDQpKaWFuamllDQoNCg0KDQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1w LTAxLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5qaWUgWW91 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KDQoNCk5hbWU6ICAgICAgICAg ICAgICAgZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXANCg0KUmV2aXNp b246ICAwMQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgICBDQVBXQVAgQ29udHJvbCBhbmQgRGF0 YSBDaGFubmVsIFNlcGFyYXRpb24gZm9yIE11bHRpLXByb3ZpZGVyIFNjZW5hcmlvDQoNCkRvY3Vt ZW50IGRhdGU6ICAgICAgIDIwMTUtMDUtMjUNCg0KR3JvdXA6ICAgICAgICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAgICAgICAgIDkNCg0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15b3Utb3BzYXdn LWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFy YXRpb24tZm9yLW1wLw0KDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAxDQoNCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteW91LW9w c2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDENCg0KDQoNCkFic3RyYWN0Og0KDQogICBU aGUgQ0FQV0FQIGNvbnRyb2wgY2hhbm5lbCBhbmQgZGF0YSBjaGFubmVsIHNwbGl0IGFyY2hpdGVj dHVyZSBoYXMNCg0KICAgc29tZSBiZW5lZml0cywgc3VjaCBhcyByZWxpZXZpbmcgdGhlIGNhcGFj aXR5IHByZXNzdXJlIG9mIHRoZSBBQy4NCg0KICAgSG93ZXZlciwgdGhlIGN1cnJlbnQgZG9jdW1l bnRzIGFyZSBub3Qgc3BlY2lmaWMgdG8gdGhlIG11bHRpLXByb3ZpZGVyDQoNCiAgIHNjZW5hcmlv LiAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdGhlIHRoaXJkLXBhcnR5IFdMQU4gc2VydmljZQ0K DQogICBwcm92aWRlciBzY2VuYXJpbyAoaS5lLiAgVmlydHVhbCBOZXR3b3JrIE9wZXJhdG9yLCBW Tk8pLCBhbmQgcHJvcG9zZXMNCg0KICAgdG8gZXh0ZW5kIENBUFdBUCBmb3Igc3VwcG9ydGluZyB0 aGlzIHVzZSBjYXNlLg0KDQoNCuWPkeS7tuS6ujogemhhbmdyQGdzdGEuY29tIFttYWlsdG86emhh bmdyQGdzdGEuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0NOaciDE15pelIDIxOjE4DQrmlLbk u7bkuro6IFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikiIDsgIFdhcnJlbiBLdW1hcmk7ICAi b3BzYXdnQGlldGYub3JnIiA7IFlvdWppYW5qaWUNCuS4u+mimDogUmU6W09QU0FXR10g562U5aSN OiDnrZTlpI06IEFub3RoZXIgQ0FQV0FQIGRvY3VtZW50DQoNCg0KSGVsbG8gYWxsLA0KDQpTcGVh a2luZyBhcyB0aGUgYXV0aG9yIG9mIGJvdGggZHJhZnRzLCBJIGFtIHRoaW5raW5nIHRoYXQgMm5k IHdpbGwgZGVsaXZlcnkgbXVsdGlwbGUgQVIncyBpbmZvcm1hdGlvbiBiYXNlZCBvbiBwcm90b2Nv bC4NCg0KV2UgY291bGQgcmVzaGFwZSB0aGUgZG9jdW1lbnQgdG8gbm90IGltcGFjdCAxc3Qgb25l IGR1cmluZyB0aGUgV0cgZG9jdW1lbnQgcGVyaW9kLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClpIQU5H IFJvbmcNCi0tLS0tLS0tLS0tLS0tLS0tLSBPcmlnaW5hbCAtLS0tLS0tLS0tLS0tLS0tLS0NCkZy b206IFlvdWppYW5qaWUgPHlvdWppYW5qaWVAaHVhd2VpLmNvbTxtYWlsdG86eW91amlhbmppZUBo dWF3ZWkuY29tPj4NCkRhdGU6IDIwMTXlubQwNOaciDE05pelIDEx5pe2MzbliIYNClRvOiAiUmFq ZXNoIFBhemh5YW5udXIgKHJwYXpoeWFuKSIgPHJwYXpoeWFuQGNpc2NvLmNvbTxtYWlsdG86cnBh emh5YW5AY2lzY28uY29tPj4sIFdhcnJlbiBLdW1hcmk8d2FycmVuQGt1bWFyaS5uZXQ8bWFpbHRv OndhcnJlbkBrdW1hcmkubmV0Pj4sICJvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4iIDxvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbT1BTQVdHXSDnrZTlpI06IOetlOWkjTogQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQNCg0KSGkg UmFqZXNoLA0KDQpUaGFua3MgZm9yIHRoZSBxdWVzdGlvbnMhDQoNCltkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtYWx0LXR1bm5lbC0wNF0gZGVzY3JpYmVzOiAidGhlIEFDIHByb3ZpZGVzIHRoZSBh bHRlcm5hdGUgdHVubmVsIGVuY2Fwc3VsYXRpb24gbWVzc2FnZSBlbGVtZW50IGNvbnRhaW5pbmcg dGhlIHR1bm5lbCB0eXBlIGFuZCBhIHR1bm5lbC1zcGVjaWZpYyBpbmZvcm1hdGlvbiBlbGVtZW50 IHdoaWxlIGNvbmZpZ3VyaW5nIHRoZSBXVFAuIg0KDQpGcm9tIHRoZSBmb3JtYXQgb2YgQWx0ZXJu YXRlIFR1bm5lbCBFbmNhcHN1bGF0aW9ucyBUeXBlIChGaWd1cmUgNiksIGl0IHNlZW1zIG9ubHkg b25lIHR1bm5lbCBpcyBzcGVjaWZpZWQgYmV0d2VlbiB0aGUgV1RQIGFuZCBBUi4NCg0KW2RyYWZ0 LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAwXSBmb2N1c2VzIG9uIHRoZSBt dWx0aS1WTk9zIHNjZW5hcmlvLiBXaGVuIHRoZSBXVFAgam9pbnMgdGhlIEFDLCBpZiB0aGUgV1RQ IHNlcnZpY2VzIG11bHRpLVZOT3MgKGkuZS4gZGlmZmVyZW50IFNTSUQgZm9yIGRpZmZlcmVudCBW Tk8sIGFuZCB1c2VyIGRhdGEgY2FuIGJlIGRpcmVjdGx5IHN0ZWVyZWQgdG8gaXRzIGNvcnJlc3Bv bmRpbmcgVk5PIGRvbWFpbiB2aWEgdGhlIFdUUCBhbmQgQVIgdHVubmVsKSwgdGhlbiB0aGUgQUMg c2hvdWxkIHByb3ZpZGUgdGhlIFdUUCB3aXRoIG11bHRpcGxlIHR1bm5lbCBpbmZvcm1hdGlvbiAo ZS5nLiBTU0lELCBBUiBhZGRyZXNzIGZvciBlYWNoIHR1bm5lbCkuIEFjdHVhbGx5IHRoaXMgZHJh ZnQgaXMgbm90IGJvdW5kIHdpdGggdHVubmVsIGVuY2Fwc3VsYXRpb24gbmVnb3RpYXRpb24gcHJv cG9zZWQgaW4gW2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsLTA0XS4gVGhlc2Ug dHdvIGRyYWZ0cyBjYW4gYmUgY29tcGxlbWVudGFyeS4NCg0KU28gSSB0aGluayB0aGUgbWFpbiBn YXAgaXMgZHVyaW5nIHRoZSBXVFAgY29uZmlndXJhdGlvbiwgd2hhdCBraW5kIG9mIGluZm9ybWF0 aW9uIEFDIHNoYWxsIHByb3ZpZGU/IEFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbnM/IG11 bHRpcGxlIHR1bm5lbCBpbmZvcm1hdGlvbiBmb3IgZGlmZmVyZW50IFZOT3M/IEkgdGhpbmsgdGhp cyBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBzY2VuYXJpb3MuDQoNClRoYW5rcywNCg0KSmlhbmpp ZQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCg0KPiDlj5Hku7bkuro6IFJhamVzaCBQYXpo eWFubnVyIChycGF6aHlhbikgW21haWx0bzpycGF6aHlhbkBjaXNjby5jb21dDQoNCj4g5Y+R6YCB 5pe26Ze0OiAyMDE15bm0NOaciDE05pelIDQ6NDUNCg0KPiDmlLbku7bkuro6IFlvdWppYW5qaWU7 IFdhcnJlbiBLdW1hcmk7IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0K DQo+IOS4u+mimDogUmU6IFtPUFNBV0ddIOetlOWkjTogQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQN Cg0KPg0KDQo+IEhlbGxv4oCmDQoNCj4NCg0KPiBDYW4gdGhlIGF1dGhvcnMgZXhwbGFpbiB3aHkg dGhlIHByb2JsZW0gc3RhdGVtZW50IGZvciB0aGlzIGNhbm5vdCBiZQ0KDQo+IGFkZHJlc3NlZCB3 aXRoaW4gdGhlIGZyYW1ld29yayBvZiB0aGUgIkFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlv biBmb3INCg0KPiBEYXRhIEZyYW1lcyBpbiBDQVBXQVDigJ0uIFNwZWNpZmljYWxseSwgd2hhdCBh cmUgdGhlIGdhcHMgPw0KDQo+DQoNCj4gVGhlIGFsdGVybmF0ZSB0dW5uZWwgZHJhZnQgZG9lcyBh bGxvdyBmb3IgZGlmZmVyZW50IEFSIHRvIGJlIHNwZWNpZmllZCBmb3INCg0KPiBkaWZmZXJlbnQg V0xBTnMuDQoNCj4gT25lIGdhcCBpcyB3aGV0aGVyIHN1Y2ggY2FwYWJpbGl0eSAoc3VwcG9ydGlu ZyBvbmUgYWx0ZXJuYXRlIHR1bm5lbCB2ZXJzdXMNCg0KPiBtdWx0aXBsZSBhbHRlcm5hdGUgdHVu bmVscykgbmVlZHMgdG8gYmUgbmVnb3RpYXRlZCBvciBub3QgPw0KDQo+DQoNCj4NCg0KPiBSZWdh cmRzDQoNCj4NCg0KPiBSYWplc2gNCg0KPg0KDQo+IE9uIDQvMTMvMTUsIDE6MjggQU0sICJZb3Vq aWFuamllIiB3cm90ZToNCg0KPg0KDQo+ID5IaSwNCg0KPiA+DQoNCj4gPlRoaXMgZG9jdW1lbnQg c3VwcG9ydHMgdGhlIFdUUCBlc3RhYmxpc2hlcyBkYXRhIHR1bm5lbHMgd2l0aCBkaWZmZXJlbnQN Cg0KPiA+QWNjZXNzIFJvdXRlcnMgKEFScyksIHdoaWNoIG1heSBiZWxvbmcgdG8gZGlmZmVyZW50 IFZpcnR1YWwgTmV0d29yaw0KDQo+ID5PcGVyYXRvcnMgKFZOT3MpLg0KDQo+ID5UaGUgc2xpZGVz IGFyZSBhdmFpbGFibGU6DQoNCj4gPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzkyL3Ns aWRlcy9zbGlkZXMtOTItb3BzYXdnLTQucGRmDQoNCj4gPllvdXIgcXVlc3Rpb25zIGFuZCBjb21t ZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNCj4gPg0KDQo+ID5UaGFua3MsDQoNCj4gPkppYW5qaWUN Cg0KPiA+DQoNCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KDQo+ID4+IOWPkeS7tuS6ujog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBXYXJyZW4gS3Vt YXJpDQoNCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDE15bm0NOaciDEx5pelIDE6MDkNCg0KPiA+PiDm lLbku7bkuro6IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KDQo+ID4+ IOS4u+mimDogW09QU0FXR10gQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQNCg0KPiA+Pg0KDQo+ID4+ IEhpIGFsbCwNCg0KPiA+Pg0KDQo+ID4+IFBsZWFzZSB0YWtlIGEgbG9vayBhdCAiQ0FQV0FQIENv bnRyb2wgYW5kIERhdGEgQ2hhbm5lbCBTZXBhcmF0aW9uIGZvcg0KDQo+ID4+IE11bHRpLXByb3Zp ZGVyIFNjZW5hcmlvIg0KDQo+ID4+DQoNCj4gPj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wDQoNCj4gPj4tMDANCg0K PiA+PikNCg0KPiA+Pg0KDQo+ID4+IFRoaXMgZG9jdW1lbnQgd2FzIGRpc2N1c3NlZCBzb21ld2hh dCBhdCB0aGUgZmFjZSB0byBmYWNlIG1lZXRpbmcgaW4NCg0KPiA+PkRhbGxhcy4NCg0KPiA+PiBX ZSBoYXZlIGRpc2N1c3NlZCB0aGlzIGRvY3VtZW50IHdpdGggb3VyIEFEcyBhbmQgaGF2ZSBkZWNp ZGVkIHRoYXQgaXQNCg0KPiA+PmlzICBzdWZmaWNpZW50bHkgZGlmZmVyZW50IHRvIHRoZSBDQVBX QVAgQUxUIFR1bm5lbCAod2hpY2ggaXMgd2l0aCB0aGUNCg0KPiA+PklFU0cpLCBhbmQgIHRoYXQg QUxUIFR1bm5lbCBpcyBzdWZmaWNpZW50bHkgZmdhciBpbiB0aGUgcHJvY2VzcyB0aGF0DQoNCj4g Pj53ZSB3aWxsIGtlZXAgdGhpcyAgZG9jdW1lbnQgc2VwYXJhdGUuLi4NCg0KPiA+Pg0KDQo+ID4+ IFNvLCBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgaXQsIGFuZCBwcm92aWRlIGluaXRpYWwgZmVlZGJh Y2sgV2Ugd2lsbA0KDQo+ID4+Y29uc2lkZXIgaGF2aW5nICBhIGNhbGwgZm9yIGFkb3B0aW9uIGlm IHRoZXJlIGlzIGVub3VnaCBldmlkZW5jZSBvZg0KDQo+ID4+aW50ZXJlc3QuLi4uDQoNCj4gPj4N Cg0KPiA+PiBXDQoNCj4gPj4gLS0NCg0KPiA+PiBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24g aXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkDQoNCj4gPj5pZGVhIGluIHRo ZSAgZmlyc3QgcGxhY2UuDQoNCj4gPj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2Vs cyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXINCg0KPiA+PmV4cHJlc3NpbmcgcmVncmV0IGF0ICBo YXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQNCg0KPiA+PnRo YXQgcGFpciBvZiBwYW50cy4NCg0KPiA+PiAgICAtLS1tYWYNCg0KPiA+Pg0KDQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gPj4gT1BTQVdH IG1haWxpbmcgbGlzdA0KDQo+ID4+IE9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYu b3JnPg0KDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdn DQoNCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cj4gPk9QU0FXRyBtYWlsaW5nIGxpc3QNCg0KPiA+T1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNB V0dAaWV0Zi5vcmc+DQoNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3BzYXdnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCk9QU0FXRyBtYWlsaW5nIGxpc3QNCg0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dA aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdn DQo= --_000_F6C28B32DA084644BB6C8D0BD65B669D187508nkgeml509mbschina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQXJpYWwgTmFycm93IjsNCglwYW5vc2UtMToyIDExIDYgNiAyIDIgMiAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzl vI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gbWVy Z2luZyBhbGwgdGhlIGNvbW1lbnRzIHdlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+cmUgcmVjZWl2ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUncmUgbm8gZHVwbGljYXRpb24g b3IgY29uZmxpY3Rpb24gd2l0aCB0aGUgY3VycmVudCBXRyBkcmFmdC4gWW91ciBjb21tZW50cyBh cmUgYXBwcmVjaWF0ZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+SmlhbmppZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1t cC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWFu amllIFlvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC15b3Utb3Bz YXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXZpc2lvbjombmJzcDsgMDE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IENBUFdBUCBDb250cm9sIGFuZCBEYXRhIENoYW5uZWwgU2VwYXJhdGlvbiBmb3IgTXVsdGkt cHJvdmlkZXIgU2NlbmFyaW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNS0wNS0yNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Hcm91cDombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBhZ2VzOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVSTDombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS1vcHNhd2ct Y2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAxLnR4dCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAt MDEudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLyI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0 aW9uLWZvci1tcC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDEiPg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAx PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDEiPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2Fw LXNlcGFyYXRpb24tZm9yLW1wLTAxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWJzdHJh Y3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBUaGUgQ0FQV0FQIGNvbnRyb2wgY2hhbm5lbCBhbmQg ZGF0YSBjaGFubmVsIHNwbGl0IGFyY2hpdGVjdHVyZSBoYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 IHNvbWUgYmVuZWZpdHMsIHN1Y2ggYXMgcmVsaWV2aW5nIHRoZSBjYXBhY2l0eSBwcmVzc3VyZSBv ZiB0aGUgQUMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBIb3dldmVyLCB0aGUgY3VycmVudCBkb2N1 bWVudHMgYXJlIG5vdCBzcGVjaWZpYyB0byB0aGUgbXVsdGktcHJvdmlkZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7IHNjZW5hcmlvLiZuYnNwOyBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgdGhp cmQtcGFydHkgV0xBTiBzZXJ2aWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBwcm92aWRlciBzY2Vu YXJpbyAoaS5lLiZuYnNwOyBWaXJ0dWFsIE5ldHdvcmsgT3BlcmF0b3IsIFZOTyksIGFuZCBwcm9w b3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgdG8gZXh0ZW5kIENBUFdBUCBmb3Igc3VwcG9ydGlu ZyB0aGlzIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+IHpoYW5nckBnc3RhLmNvbSBbbWFpbHRvOnpoYW5nckBnc3RhLmNvbV0NCjxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+NDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTU8 L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAyMToxODxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSYWpl c2gmbmJzcDtQYXpoeWFubnVyJm5ic3A7KHJwYXpoeWFuKSZxdW90OyZuYnNwOzsgJm5ic3A7V2Fy cmVuJm5ic3A7S3VtYXJpOyAmbmJzcDsmcXVvdDtvcHNhd2dAaWV0Zi5vcmcmcXVvdDsmbmJzcDs7 IFlvdWppYW5qaWU8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6W09QU0FXR10gPC9zcGFuPg0K562U5aSNPHNw YW4gbGFuZz0iRU4tVVMiPjogPC9zcGFuPuetlOWkjTxzcGFuIGxhbmc9IkVOLVVTIj46IEFub3Ro ZXIgQ0FQV0FQIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhlbGxvIGFsbCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+U3BlYWtpbmcgYXMgdGhl IGF1dGhvciBvZiBib3RoIGRyYWZ0cywgSSBhbSB0aGlua2luZyB0aGF0IDJuZCB3aWxsIGRlbGl2 ZXJ5IG11bHRpcGxlIEFSJ3MgaW5mb3JtYXRpb24gYmFzZWQgb24gcHJvdG9jb2wuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPldlIGNvdWxkIHJlc2hhcGUgdGhl IGRvY3VtZW50IHRvIG5vdCBpbXBhY3QgMXN0IG9uZSBkdXJpbmcgdGhlIFdHIGRvY3VtZW50IHBl cmlvZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5aSEFO RyBSb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsIE5hcnJvdyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLS0tLS0t LS0tLS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3VqaWFuamllICZsdDs8 YSBocmVmPSJtYWlsdG86eW91amlhbmppZUBodWF3ZWkuY29tIj55b3VqaWFuamllQGh1YXdlaS5j b208L2E+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXRlOg0KPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIw MTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5bm0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ MDQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5pyIPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ MTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5pelPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ DQogMTE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5pe2 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+MzY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5YiG PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UbzoNCjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mcXVvdDtSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cnBhemh5YW5AY2lzY28uY29tIj5ycGF6aHlhbkBjaXNjby5jb208L2E+Jmd0OywgV2Fy cmVuIEt1bWFyaSZsdDs8YSBocmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiPndhcnJlbkBr dW1hcmkubmV0PC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9y ZyI+b3BzYXdnQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0Bp ZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNF RkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+U3ViamVjdDoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bT1BTQVdHXQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPuetlOWkjTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj7nrZTlpI08L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46IEFub3RoZXIgQ0FQV0FQIGRv Y3VtZW50DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+SGkgUmFqZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgcXVlc3Rpb25zITxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+W2RyYWZ0LWlldGYtb3BzYXdnLWNh cHdhcC1hbHQtdHVubmVsLTA0XSBkZXNjcmliZXM6ICZxdW90O3RoZSBBQyBwcm92aWRlcyB0aGUg YWx0ZXJuYXRlIHR1bm5lbCBlbmNhcHN1bGF0aW9uIG1lc3NhZ2UgZWxlbWVudCBjb250YWluaW5n IHRoZSB0dW5uZWwgdHlwZSBhbmQgYSB0dW5uZWwtc3BlY2lmaWMgaW5mb3JtYXRpb24gZWxlbWVu dCB3aGlsZSBjb25maWd1cmluZyB0aGUgV1RQLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbSB0aGUgZm9ybWF0IG9mIEFsdGVybmF0ZSBU dW5uZWwgRW5jYXBzdWxhdGlvbnMgVHlwZSAoRmlndXJlIDYpLCBpdCBzZWVtcyBvbmx5IG9uZSB0 dW5uZWwgaXMgc3BlY2lmaWVkIGJldHdlZW4gdGhlIFdUUCBhbmQgQVIuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5bZHJhZnQteW91LW9wc2F3Zy1jYXB3 YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDBdIGZvY3VzZXMgb24gdGhlIG11bHRpLVZOT3Mgc2NlbmFy aW8uIFdoZW4gdGhlIFdUUCBqb2lucyB0aGUgQUMsIGlmIHRoZSBXVFAgc2VydmljZXMgbXVsdGkt Vk5PcyAoaS5lLiBkaWZmZXJlbnQgU1NJRCBmb3IgZGlmZmVyZW50IFZOTywgYW5kIHVzZXIgZGF0 YSBjYW4gYmUgZGlyZWN0bHkgc3RlZXJlZCB0byBpdHMgY29ycmVzcG9uZGluZyBWTk8gZG9tYWlu IHZpYSB0aGUgV1RQIGFuZCBBUiB0dW5uZWwpLCB0aGVuIHRoZSBBQyBzaG91bGQgcHJvdmlkZSB0 aGUgV1RQIHdpdGggbXVsdGlwbGUgdHVubmVsIGluZm9ybWF0aW9uIChlLmcuIFNTSUQsIEFSIGFk ZHJlc3MgZm9yIGVhY2ggdHVubmVsKS4gQWN0dWFsbHkgdGhpcyBkcmFmdCBpcyBub3QgYm91bmQg d2l0aCB0dW5uZWwgZW5jYXBzdWxhdGlvbiBuZWdvdGlhdGlvbiBwcm9wb3NlZCBpbiBbZHJhZnQt aWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwtMDRdLiBUaGVzZSB0d28gZHJhZnRzIGNhbiBi ZSBjb21wbGVtZW50YXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+U28gSSB0aGluayB0aGUgbWFpbiBnYXAgaXMgZHVyaW5nIHRoZSBXVFAgY29uZmln dXJhdGlvbiwgd2hhdCBraW5kIG9mIGluZm9ybWF0aW9uIEFDIHNoYWxsIHByb3ZpZGU/IEFsdGVy bmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbnM/IG11bHRpcGxlIHR1bm5lbCBpbmZvcm1hdGlvbiBm b3IgZGlmZmVyZW50IFZOT3M/IEkgdGhpbmsgdGhpcyBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBz Y2VuYXJpb3MuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5KaWFuamllPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IC0tLS0tPC9zcGFuPumCruS7tuWOn+S7tjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3Nw YW4+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjogUmFqZXNoIFBhemh5YW5udXIgKHJwYXpo eWFuKSBbPGEgaHJlZj0ibWFpbHRvOnJwYXpoeWFuQGNpc2NvLmNvbSI+bWFpbHRvOnJwYXpoeWFu QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IDwvc3Bhbj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE1 PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xNDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDQ6NDU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPuaUtuS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46IFlvdWppYW5qaWU7IFdhcnJlbiBLdW1hcmk7IDxhIGhyZWY9Im1haWx0 bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPuS4u+mimDxzcGFuIGxh bmc9IkVOLVVTIj46IFJlOiBbT1BTQVdHXSA8L3NwYW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMi PjogQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEhlbGxv4oCmPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDYW4gdGhlIGF1dGhvcnMgZXhwbGFpbiB3aHkgdGhl IHByb2JsZW0gc3RhdGVtZW50IGZvciB0aGlzIGNhbm5vdCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBhZGRyZXNzZWQgd2l0aGluIHRoZSBm cmFtZXdvcmsgb2YgdGhlICZxdW90O0FsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBmb3I8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRGF0 YSBGcmFtZXMgaW4gQ0FQV0FQ4oCdLiBTcGVjaWZpY2FsbHksIHdoYXQgYXJlIHRoZSBnYXBzID88 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoZSBh bHRlcm5hdGUgdHVubmVsIGRyYWZ0IGRvZXMgYWxsb3cgZm9yIGRpZmZlcmVudCBBUiB0byBiZSBz cGVjaWZpZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IGRpZmZlcmVudCBXTEFOcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgT25lIGdhcCBpcyB3aGV0aGVyIHN1Y2ggY2FwYWJpbGl0 eSAoc3VwcG9ydGluZyBvbmUgYWx0ZXJuYXRlIHR1bm5lbCB2ZXJzdXM8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbXVsdGlwbGUgYWx0ZXJuYXRl IHR1bm5lbHMpIG5lZWRzIHRvIGJlIG5lZ290aWF0ZWQgb3Igbm90ID88bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBSZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBSYWplc2g8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IE9uIDQvMTMvMTUsIDE6Mjgg QU0sICZxdW90O1lvdWppYW5qaWUmcXVvdDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7SGksPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0O1RoaXMgZG9jdW1lbnQgc3Vw cG9ydHMgdGhlIFdUUCBlc3RhYmxpc2hlcyBkYXRhIHR1bm5lbHMgd2l0aCBkaWZmZXJlbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0O0Fj Y2VzcyBSb3V0ZXJzIChBUnMpLCB3aGljaCBtYXkgYmVsb25nIHRvIGRpZmZlcmVudCBWaXJ0dWFs IE5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgJmd0O09wZXJhdG9ycyAoVk5PcykuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDtUaGUgc2xpZGVzIGFyZSBhdmFpbGFibGU6PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS85Mi9zbGlkZXMvc2xpZGVzLTky LW9wc2F3Zy00LnBkZiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvOTIvc2xpZGVzL3Ns aWRlcy05Mi1vcHNhd2ctNC5wZGY8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDtZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJl IGFwcHJlY2lhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7ICZndDtUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDtKaWFuamllPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDsgLS0tLS08L3NwYW4+6YKu 5Lu25Y6f5Lu2PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IDwvc3Bhbj7lj5Hku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+OiBPUFNBV0cgWzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPC9zcGFuPuS7 o+ihqDxzcGFuIGxhbmc9IkVOLVVTIj4gV2FycmVuIEt1bWFyaTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+5Y+R6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxNTwvc3Bhbj7lubQ8c3BhbiBsYW5nPSJFTi1V UyI+NDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pelPHNwYW4gbGFuZz0i RU4tVVMiPiAxOjA5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7ICZndDsmZ3Q7IDwvc3Bhbj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+OiA8 YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7 IDwvc3Bhbj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+OiBbT1BTQVdHXSBBbm90aGVyIENBUFdB UCBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBIaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IFBsZWFzZSB0YWtlIGEg bG9vayBhdCAmcXVvdDtDQVBXQVAgQ29udHJvbCBhbmQgRGF0YSBDaGFubmVsIFNlcGFyYXRpb24g Zm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 ICZndDsmZ3Q7IE11bHRpLXByb3ZpZGVyIFNjZW5hcmlvJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7KDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1z ZXBhcmF0aW9uLWZvci1tcCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS1v cHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0Oy0wMDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0Oyk8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyZndDsgVGhpcyBkb2N1bWVudCB3YXMgZGlzY3Vzc2VkIHNvbWV3aGF0IGF0IHRoZSBmYWNlIHRv IGZhY2UgbWVldGluZyBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0O0RhbGxhcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDsgV2UgaGF2ZSBkaXNjdXNzZWQgdGhp cyBkb2N1bWVudCB3aXRoIG91ciBBRHMgYW5kIGhhdmUgZGVjaWRlZCB0aGF0IGl0PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7aXMm bmJzcDsgc3VmZmljaWVudGx5IGRpZmZlcmVudCB0byB0aGUgQ0FQV0FQIEFMVCBUdW5uZWwgKHdo aWNoIGlzIHdpdGggdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7SUVTRyksIGFuZCZuYnNwOyB0aGF0IEFMVCBUdW5uZWwgaXMg c3VmZmljaWVudGx5IGZnYXIgaW4gdGhlIHByb2Nlc3MgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0O3dlIHdpbGwga2VlcCB0 aGlzJm5ic3A7IGRvY3VtZW50IHNlcGFyYXRlLi4uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IFNvLCBwbGVhc2UgdGFr ZSBhIGxvb2sgYXQgaXQsIGFuZCBwcm92aWRlIGluaXRpYWwgZmVlZGJhY2sgV2Ugd2lsbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0 O2NvbnNpZGVyIGhhdmluZyZuYnNwOyBhIGNhbGwgZm9yIGFkb3B0aW9uIGlmIHRoZXJlIGlzIGVu b3VnaCBldmlkZW5jZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0O2ludGVyZXN0Li4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBXPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IC0t PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZn dDsmZ3Q7IEkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdh cyBvYnZpb3VzbHkgYSBiYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgJmd0OyZndDtpZGVhIGluIHRoZSZuYnNwOyBmaXJzdCBwbGFjZS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZn dDsgVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQg bGF0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgJmd0OyZndDtleHByZXNzaW5nIHJlZ3JldCBhdCZuYnNwOyBoYXZpbmcgY2hvc2VuIHRob3Nl IHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDt0aGF0IHBhaXIgb2YgcGFudHMuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLW1hZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBPUFNBV0cgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v cHNhd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0O09QU0FXRyBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgJmd0OzxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3BzYXdnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PUFNBV0cgbWFpbGluZyBsaXN0PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWls dG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vcHNhd2c8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F6C28B32DA084644BB6C8D0BD65B669D187508nkgeml509mbschina_-- From nobody Mon May 25 23:47:21 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6B71A90B8; Mon, 25 May 2015 23:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIBm4o8ryZIX; Mon, 25 May 2015 23:47:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908241A90C1; Mon, 25 May 2015 23:47:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3B269FD7; Tue, 26 May 2015 08:47:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id twaLE9ndgnZU; Tue, 26 May 2015 08:47:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 May 2015 08:47:15 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D5F62002B; Tue, 26 May 2015 08:47:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d9gWAxSXdndg; Tue, 26 May 2015 08:47:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83D9B20013; Tue, 26 May 2015 08:47:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D21C335691C; Tue, 26 May 2015 08:47:13 +0200 (CEST) Date: Tue, 26 May 2015 08:47:13 +0200 From: Juergen Schoenwaelder To: Keiichi SHIMA Message-ID: <20150526064713.GD63911@elstar.local> Mail-Followup-To: Keiichi SHIMA , "Romascanu, Dan (Dan)" , "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 06:47:20 -0000 On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > Hi all, > > >> 17. I am concerned that the current way of defining the > >> notifications switches is too course. Hypervisors may have many VMs > >> in charge, and if each generates one notification per each state > >> changes the numbers can become big even in normal operation. Maybe > >> some throttling mechanism would be useful. Or maybe a couple of more > >> switches that allow to enable only 'critical' notifications > >> (e.g. vmCrashed). > > > > The only situation I can think of where the number of notifications > > will be significant is during restart of a whole rack with many > > hypervisors inside. But even then, things usually take time. (I think > > our Xen hypervisors actually create virtual machines sequentially and > > hence the notifications get actually spaced over time.) It is not > > unlikely that the operating systems inside the hypervisors during > > startup generate significantly more network traffic compared to a few > > hypervisor notifications. That said, during the development of the MIB > > module we moved from generic state change notifications to a set of > > specific notifications and this allows to use SNMPv3 notification > > filtering to filter out notifications people find not useful. > > > I and Asai talked locally and we agree Juergen that the number of notification events is manageable. > > However we noticed that the 'vmBlocked' notification may be a problem. The 'blocked' state is defined as 'The operational state of the virtual machine indicating the execution of the virtual machine is currently blocked, e.g., waiting for some action of the hypervisor to finish. This is a transient state from/to other states.' This state transition event may appear more frequently than other events, since the state is caused by the I/O scheduler of the hyper visor implementation. > > We think we can simply remove the 'vmBlocked' notification. The 'blocked' state is a transient state and typically return to the previous state immediately (once the pending I/O requests completed). > Yes, this makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 26 00:23:44 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A5B1B29C4; Tue, 26 May 2015 00:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBEzRAWwXGOT; Tue, 26 May 2015 00:23:39 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1528B1B29C3; Tue, 26 May 2015 00:23:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFACMfZFWHCzIm/2dsb2JhbABZA4JmKlReBrEQAQaTX4V3AoFBTAEBAQEBAYELhCIBAQEBAxIoPwwCAgIBCA0BAgEEAQEBChQJBxsXFAkIAgQBDQUIGogKAQykUa4nAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSGEoUkhFQhEAcGC4MGgRYFkwiENYhBhiePISNhgSkcgVJvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,496,1427774400"; d="scan'208";a="103963527" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 May 2015 03:23:20 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 03:23:18 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 26 May 2015 09:23:17 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Keiichi SHIMA" Thread-Topic: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AQHQl1W07FYF97c7yUeZZUEal5KxcJ2Nr2WAgAAp9MA= Date: Tue, 26 May 2015 07:23:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3AC4F@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> <20150526064713.GD63911@elstar.local> In-Reply-To: <20150526064713.GD63911@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 07:23:42 -0000 Hi, I would still recommend that you add text in the Security Considerations se= ction in which you describe the risk of intentional or unintentional miscon= figuration of the two writeable objects in the MIB module. It would also be= useful to mention explicitly that the authors considered the risks of mult= iplication of notification and evaluated it as manageable for all reasonabl= y designed and sized networks.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, May 26, 2015 9:47 AM > To: Keiichi SHIMA > Cc: Romascanu, Dan (Dan); draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; > ops-dir@ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 >=20 > On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > > Hi all, > > > > >> 17. I am concerned that the current way of defining the > > >> notifications switches is too course. Hypervisors may have many VMs > > >> in charge, and if each generates one notification per each state > > >> changes the numbers can become big even in normal operation. Maybe > > >> some throttling mechanism would be useful. Or maybe a couple of > > >> more switches that allow to enable only 'critical' notifications > > >> (e.g. vmCrashed). > > > > > > The only situation I can think of where the number of notifications > > > will be significant is during restart of a whole rack with many > > > hypervisors inside. But even then, things usually take time. (I > > > think our Xen hypervisors actually create virtual machines > > > sequentially and hence the notifications get actually spaced over > > > time.) It is not unlikely that the operating systems inside the > > > hypervisors during startup generate significantly more network > > > traffic compared to a few hypervisor notifications. That said, > > > during the development of the MIB module we moved from generic > state > > > change notifications to a set of specific notifications and this > > > allows to use SNMPv3 notification filtering to filter out notificatio= ns > people find not useful. > > > > > > I and Asai talked locally and we agree Juergen that the number of > notification events is manageable. > > > > However we noticed that the 'vmBlocked' notification may be a problem. > The 'blocked' state is defined as 'The operational state of the virtual m= achine > indicating the execution of the virtual machine is currently blocked, e.g= ., > waiting for some action of the hypervisor to finish. This is a transient= state > from/to other states.' This state transition event may appear more > frequently than other events, since the state is caused by the I/O schedu= ler > of the hyper visor implementation. > > > > We think we can simply remove the 'vmBlocked' notification. The 'block= ed' > state is a transient state and typically return to the previous state > immediately (once the pending I/O requests completed). > > >=20 > Yes, this makes sense to me. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DMgxJDgRk1TpLrZ2hiPqtqSLH_gUN > Xo4hIzz7Czjm6c0&s=3D0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e > =3D > From nobody Tue May 26 01:52:48 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C7C1A1B7B; Tue, 26 May 2015 01:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KvANBkcUxI5; Tue, 26 May 2015 01:52:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E0E1A1B5C; Tue, 26 May 2015 01:52:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C3662FC1; Tue, 26 May 2015 10:52:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KC0xSh_RcGNI; Tue, 26 May 2015 10:52:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 May 2015 10:52:40 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C6D82002C; Tue, 26 May 2015 10:52:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q2wIiuTv38D1; Tue, 26 May 2015 10:52:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08F0020013; Tue, 26 May 2015 10:52:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F23C03356A2E; Tue, 26 May 2015 10:52:36 +0200 (CEST) Date: Tue, 26 May 2015 10:52:36 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150526085236.GA64205@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Keiichi SHIMA , "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> <20150526064713.GD63911@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CA3AC4F@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3AC4F@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:52:45 -0000 Keiichi, note that there is outdated text on page 9 that should be updated: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. In the security considerations, I assume Dan wants: OLD There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. NEW There are two objects defined in this MIB, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have a MAX-ACCESS clause of read-write. Enabling notifications can lead to a noticeable number of notifications if many virtual machines change their state concurrently. Hence, such objects may be considered sensitive or vulnerable in some network environments. /js On Tue, May 26, 2015 at 07:23:17AM +0000, Romascanu, Dan (Dan) wrote: > Hi, > > I would still recommend that you add text in the Security Considerations section in which you describe the risk of intentional or unintentional misconfiguration of the two writeable objects in the MIB module. It would also be useful to mention explicitly that the authors considered the risks of multiplication of notification and evaluated it as manageable for all reasonably designed and sized networks. > > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Tuesday, May 26, 2015 9:47 AM > > To: Keiichi SHIMA > > Cc: Romascanu, Dan (Dan); draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; > > ops-dir@ietf.org; opsawg@ietf.org > > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 > > > > On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > > > Hi all, > > > > > > >> 17. I am concerned that the current way of defining the > > > >> notifications switches is too course. Hypervisors may have many VMs > > > >> in charge, and if each generates one notification per each state > > > >> changes the numbers can become big even in normal operation. Maybe > > > >> some throttling mechanism would be useful. Or maybe a couple of > > > >> more switches that allow to enable only 'critical' notifications > > > >> (e.g. vmCrashed). > > > > > > > > The only situation I can think of where the number of notifications > > > > will be significant is during restart of a whole rack with many > > > > hypervisors inside. But even then, things usually take time. (I > > > > think our Xen hypervisors actually create virtual machines > > > > sequentially and hence the notifications get actually spaced over > > > > time.) It is not unlikely that the operating systems inside the > > > > hypervisors during startup generate significantly more network > > > > traffic compared to a few hypervisor notifications. That said, > > > > during the development of the MIB module we moved from generic > > state > > > > change notifications to a set of specific notifications and this > > > > allows to use SNMPv3 notification filtering to filter out notifications > > people find not useful. > > > > > > > > > I and Asai talked locally and we agree Juergen that the number of > > notification events is manageable. > > > > > > However we noticed that the 'vmBlocked' notification may be a problem. > > The 'blocked' state is defined as 'The operational state of the virtual machine > > indicating the execution of the virtual machine is currently blocked, e.g., > > waiting for some action of the hypervisor to finish. This is a transient state > > from/to other states.' This state transition event may appear more > > frequently than other events, since the state is caused by the I/O scheduler > > of the hyper visor implementation. > > > > > > We think we can simply remove the 'vmBlocked' notification. The 'blocked' > > state is a transient state and typically return to the previous state > > immediately (once the pending I/O requests completed). > > > > > > > Yes, this makes sense to me. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > 2Duniversity.de_&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=MgxJDgRk1TpLrZ2hiPqtqSLH_gUN > > Xo4hIzz7Czjm6c0&s=0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e > > = > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue May 26 02:00:43 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9712B1A1BF2; Tue, 26 May 2015 02:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VcRyev1kZGu; Tue, 26 May 2015 02:00:40 -0700 (PDT) Received: from mail.wide.ad.jp (mail.wide.ad.jp [IPv6:2001:200:0:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5231A1BF5; Tue, 26 May 2015 02:00:39 -0700 (PDT) Received: from [202.214.86.179] ([202.214.86.179]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.21) with ESMTP id t4Q90cYC010955 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO); Tue, 26 May 2015 18:00:38 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Keiichi SHIMA In-Reply-To: <20150526085236.GA64205@elstar.local> Date: Tue, 26 May 2015 18:00:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <055ACED8-B32E-4193-A864-0E405FB812E3@wide.ad.jp> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> <20150526064713.GD63911@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CA3AC4F@AZ-FFEXMB04.global.avaya.com> <20150526085236.GA64205@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:00:42 -0000 Juergen, thanks, I'm now working on updating the text with Hirochika. > note that there is outdated text on page 9 that should be updated: >=20 > The MIB module provides a few writable objects that can be used to > make non-persistent changes, e.g., changing the memory allocation or > the CPU allocation. It is not the goal of this MIB module to = provide > a configuration interface for virtual machines since other protocols > and data modeling languages are more suitable for this task. OK, we've removed the above paragraph. The latest text in the = repository does't have it. > OLD >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that = have > a MAX-ACCESS clause of read-write. Such objects may be considered > sensitive or vulnerable in some network environments. >=20 > NEW >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that > have a MAX-ACCESS clause of read-write. Enabling notifications can > lead to a noticeable number of notifications if many virtual > machines change their state concurrently. Hence, such objects may > be considered sensitive or vulnerable in some network environments. OK, the above text has been merged. --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc > On 2015/05/26, at 17:52, Juergen Schoenwaelder = wrote: >=20 > Keiichi, >=20 > note that there is outdated text on page 9 that should be updated: >=20 > The MIB module provides a few writable objects that can be used to > make non-persistent changes, e.g., changing the memory allocation or > the CPU allocation. It is not the goal of this MIB module to = provide > a configuration interface for virtual machines since other protocols > and data modeling languages are more suitable for this task. >=20 > In the security considerations, I assume Dan wants: >=20 > OLD >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that = have > a MAX-ACCESS clause of read-write. Such objects may be considered > sensitive or vulnerable in some network environments. >=20 > NEW >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that > have a MAX-ACCESS clause of read-write. Enabling notifications can > lead to a noticeable number of notifications if many virtual > machines change their state concurrently. Hence, such objects may > be considered sensitive or vulnerable in some network environments. >=20 > /js >=20 > On Tue, May 26, 2015 at 07:23:17AM +0000, Romascanu, Dan (Dan) wrote: >> Hi, >>=20 >> I would still recommend that you add text in the Security = Considerations section in which you describe the risk of intentional or = unintentional misconfiguration of the two writeable objects in the MIB = module. It would also be useful to mention explicitly that the authors = considered the risks of multiplication of notification and evaluated it = as manageable for all reasonably designed and sized networks.=20 >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- >>> university.de] >>> Sent: Tuesday, May 26, 2015 9:47 AM >>> To: Keiichi SHIMA >>> Cc: Romascanu, Dan (Dan); = draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; >>> ops-dir@ietf.org; opsawg@ietf.org >>> Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 >>>=20 >>> On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: >>>> Hi all, >>>>=20 >>>>>> 17. I am concerned that the current way of defining the >>>>>> notifications switches is too course. Hypervisors may have many = VMs >>>>>> in charge, and if each generates one notification per each state >>>>>> changes the numbers can become big even in normal operation. = Maybe >>>>>> some throttling mechanism would be useful. Or maybe a couple of >>>>>> more switches that allow to enable only 'critical' notifications >>>>>> (e.g. vmCrashed). >>>>>=20 >>>>> The only situation I can think of where the number of = notifications >>>>> will be significant is during restart of a whole rack with many >>>>> hypervisors inside. But even then, things usually take time. (I >>>>> think our Xen hypervisors actually create virtual machines >>>>> sequentially and hence the notifications get actually spaced over >>>>> time.) It is not unlikely that the operating systems inside the >>>>> hypervisors during startup generate significantly more network >>>>> traffic compared to a few hypervisor notifications. That said, >>>>> during the development of the MIB module we moved from generic >>> state >>>>> change notifications to a set of specific notifications and this >>>>> allows to use SNMPv3 notification filtering to filter out = notifications >>> people find not useful. >>>>=20 >>>>=20 >>>> I and Asai talked locally and we agree Juergen that the number of >>> notification events is manageable. >>>>=20 >>>> However we noticed that the 'vmBlocked' notification may be a = problem. >>> The 'blocked' state is defined as 'The operational state of the = virtual machine >>> indicating the execution of the virtual machine is currently = blocked, e.g., >>> waiting for some action of the hypervisor to finish. This is a = transient state >>> from/to other states.' This state transition event may appear more >>> frequently than other events, since the state is caused by the I/O = scheduler >>> of the hyper visor implementation. >>>>=20 >>>> We think we can simply remove the 'vmBlocked' notification. The = 'blocked' >>> state is a transient state and typically return to the previous = state >>> immediately (once the pending I/O requests completed). >>>>=20 >>>=20 >>> Yes, this makes sense to me. >>>=20 >>> /js >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> >> 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O >>> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DMgxJDgRk1TpLrZ2hiPqtqSLH_gUN >>> Xo4hIzz7Czjm6c0&s=3D0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e >>> =3D > >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue May 26 02:04:47 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF831A1BFF; Tue, 26 May 2015 02:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U2-YdFwRu2u; Tue, 26 May 2015 02:04:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9850A1A1EF6; Tue, 26 May 2015 02:04:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAOw2ZFXGmAcV/2dsb2JhbABZA4JmKlReBrB5EQEGk1+FdwKBREwBAQEBAQGBC4QiAQEBAQMSKD8MAgICAQgNAQIBBAEBAQoUCQcbFxQJCAIEDgUIGogKAQykRa4rAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSGEoUkhFQhEAcGC4MGgRYFkwiENYgDPoYnC48WI2GBKRyBUm8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208";a="117914302" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 May 2015 05:04:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 05:04:20 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 26 May 2015 11:04:18 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AQHQl1W07FYF97c7yUeZZUEal5KxcJ2Nr2WAgAAp9MD///kUAIAAJKgg Date: Tue, 26 May 2015 09:04:18 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ADF6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <20150523063714.GB58453@elstar.local> <20150526064713.GD63911@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5CA3AC4F@AZ-FFEXMB04.global.avaya.com> <20150526085236.GA64205@elstar.local> In-Reply-To: <20150526085236.GA64205@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:04:45 -0000 Yes - this addresses my concern.=20 Thanks and Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, May 26, 2015 11:53 AM > To: Romascanu, Dan (Dan) > Cc: Keiichi SHIMA; draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; ops- > dir@ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 >=20 > Keiichi, >=20 > note that there is outdated text on page 9 that should be updated: >=20 > The MIB module provides a few writable objects that can be used to > make non-persistent changes, e.g., changing the memory allocation or > the CPU allocation. It is not the goal of this MIB module to provide > a configuration interface for virtual machines since other protocols > and data modeling languages are more suitable for this task. >=20 > In the security considerations, I assume Dan wants: >=20 > OLD >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that have > a MAX-ACCESS clause of read-write. Such objects may be considered > sensitive or vulnerable in some network environments. >=20 > NEW >=20 > There are two objects defined in this MIB, > vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, that > have a MAX-ACCESS clause of read-write. Enabling notifications can > lead to a noticeable number of notifications if many virtual > machines change their state concurrently. Hence, such objects may > be considered sensitive or vulnerable in some network environments. >=20 > /js >=20 > On Tue, May 26, 2015 at 07:23:17AM +0000, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I would still recommend that you add text in the Security Consideration= s > section in which you describe the risk of intentional or unintentional > misconfiguration of the two writeable objects in the MIB module. It would > also be useful to mention explicitly that the authors considered the risk= s of > multiplication of notification and evaluated it as manageable for all > reasonably designed and sized networks. > > > > Thanks and Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Tuesday, May 26, 2015 9:47 AM > > > To: Keiichi SHIMA > > > Cc: Romascanu, Dan (Dan); > > > draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; > > > ops-dir@ietf.org; opsawg@ietf.org > > > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib- > 02 > > > > > > On Tue, May 26, 2015 at 10:45:48AM +0900, Keiichi SHIMA wrote: > > > > Hi all, > > > > > > > > >> 17. I am concerned that the current way of defining the > > > > >> notifications switches is too course. Hypervisors may have many > > > > >> VMs in charge, and if each generates one notification per each > > > > >> state changes the numbers can become big even in normal > > > > >> operation. Maybe some throttling mechanism would be useful. Or > > > > >> maybe a couple of more switches that allow to enable only > > > > >> 'critical' notifications (e.g. vmCrashed). > > > > > > > > > > The only situation I can think of where the number of > > > > > notifications will be significant is during restart of a whole > > > > > rack with many hypervisors inside. But even then, things usually > > > > > take time. (I think our Xen hypervisors actually create virtual > > > > > machines sequentially and hence the notifications get actually > > > > > spaced over > > > > > time.) It is not unlikely that the operating systems inside the > > > > > hypervisors during startup generate significantly more network > > > > > traffic compared to a few hypervisor notifications. That said, > > > > > during the development of the MIB module we moved from generic > > > state > > > > > change notifications to a set of specific notifications and this > > > > > allows to use SNMPv3 notification filtering to filter out > > > > > notifications > > > people find not useful. > > > > > > > > > > > > I and Asai talked locally and we agree Juergen that the number of > > > notification events is manageable. > > > > > > > > However we noticed that the 'vmBlocked' notification may be a > problem. > > > The 'blocked' state is defined as 'The operational state of the > > > virtual machine indicating the execution of the virtual machine is > > > currently blocked, e.g., waiting for some action of the hypervisor > > > to finish. This is a transient state from/to other states.' This > > > state transition event may appear more frequently than other events, > > > since the state is caused by the I/O scheduler of the hyper visor > implementation. > > > > > > > > We think we can simply remove the 'vmBlocked' notification. The > 'blocked' > > > state is a transient state and typically return to the previous > > > state immediately (once the pending I/O requests completed). > > > > > > > > > > Yes, this makes sense to me. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > > > > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DMgxJDgRk1TpLrZ2hiPqtqSLH_gUN > > > > Xo4hIzz7Czjm6c0&s=3D0FOhbeoR7FEAGZddNHtPDimJFq1MNfZlAEOjldkr1tA&e > > > =3D > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwIBAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DqQg5JHHnGYDVuGEwHHPY2bhg > mu5R0g- > xo8jGJBsC_nI&s=3DA7HwS6XPjZEsREWKTr7TANnfo2PZlxIg2bhFUlPeZUw&e=3D > From nobody Tue May 26 03:17:21 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94541B2A9F; Tue, 26 May 2015 03:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXraTmeUS-ow; Tue, 26 May 2015 03:17:17 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CEE1B2A9A; Tue, 26 May 2015 03:17:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFADpHZFWHCzIm/2dsb2JhbABcgmYqgTIGgxmtcgEGmVYCHIEqTAEBAQEBAYELhCIBAQEBAgESERFFDAQCAQgNAQMEAQEDAgYdAwICAjAUAQgIAgQOBQgaiAIIAaRailWjVQEBAQEBAQEBAgEBAQEBAQEBAQEBF4EhhHWFJIQsEBgxBwaCYi+BFgWLVYczjDiGZYtIg1kjYYMXbwGBAgEfI4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208";a="103978161" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 May 2015 06:17:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 06:17:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 26 May 2015 12:17:11 +0200 From: "Romascanu, Dan (Dan)" To: Hirochika Asai Thread-Topic: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AQHQl5q/7FYF97c7yUeZZUEal5KxcJ2OCPRA Date: Tue, 26 May 2015 10:17:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3B007@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <60DE664B-1300-4BA8-ABA6-0A02017BDDD0@hongo.wide.ad.jp> In-Reply-To: <60DE664B-1300-4BA8-ABA6-0A02017BDDD0@hongo.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 10:17:18 -0000 RGVhciBIaXJvY2hpdGEgQXNhaSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlIGFuZCBm b3IgYWRkcmVzc2luZyB0aGUgY29tbWVudHMgaW4gbXkgcmV2aWV3LiANCg0KTW9zdCBvZiB0aGUg cHJvcG9zYWxzIHlvdSBtYWRlIGFyZSBmdWxseSBhZGRyZXNzaW5nIG15IGNvbW1lbnRzLiANCg0K QSBjb3VwbGUgb2Ygb3BlbiBpc3N1ZXMgYXJlIGxlZnQuIFNlZSBiZWxvdy4NCg0KUmVnYXJkcywN Cg0KRGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIaXJvY2hp a2EgQXNhaSBbbWFpbHRvOnBhbmRhQGhvbmdvLndpZGUuYWQuanBdDQo+IFNlbnQ6IFR1ZXNkYXks IE1heSAyNiwgMjAxNSAxOjAwIFBNDQo+IFRvOiBSb21hc2NhbnUsIERhbiAoRGFuKQ0KPiBDYzog b3BzLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctdm1tLW1pYi5hbGxAdG9vbHMuaWV0 Zi5vcmc7DQo+IG9wc2F3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09QU0FXR10gT1BTLURJ UiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctdm1tLW1pYi0wMg0KPiANCj4gRGVhciBEYW4s DQo+IA0KPiANCj4gPiAxMS4gICBQYWdlIDIwLTIxOiBXaHkgaXMgdGhlIFZpcnR1YWxNYWNoaW5l U3RvcmFnZVR5cGUgbGltaXRlZCB0byB0d28NCj4gbWVkaWEgdHlwZXMgb25seT8gV291bGQgbm90 IGFuIElBTkEtYWRtaW5pc3RlcmVkIFRDIGJlIG1vcmUgYXBwcm9wcmlhdGUNCj4gaGVyZT8NCj4g QWx0aG91Z2ggZmV3IHBlb3BsZSBhcmUgdXNpbmcsIHRoZSB0eXBlIG9mIGZsb3BweSBkaXNrIHdh cyBtaXNzaW5nLiAgVGhlbiB3ZQ0KPiBhZGRlZCBpdC4NCj4gQXMgZm9yIHRoZSBJQU5BLWFkbWlu aXN0cmF0ZWQgVEMsIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIFN0b3JhZ2VUeXBlIGluDQo+ IFNOTVB2Mi1UQyBkZWZpbmVzIHRoZSBzdG9yYWdlIHR5cGVzLiBIb3dldmVyLCB0aGV5IGFyZSBu b3Qgd2hhdCB3ZQ0KPiBleHBlY3QgYXMgdGhlIG1lZGlhIHR5cGVzIG9mIHZpcnR1YWwgc3RvcmFn ZXMgYXR0YWNoZWQgdG8gYSB2aXJ0dWFsIG1hY2hpbmUuDQo+IA0KDQpUd28gaXNzdWVzIGhlcmU6 IA0KLSBtYXliZSBWaXJ0dWFsTWFjaGluZVN0b3JhZ2VNZWRpYVR5cGUgaXMgYSBiZXR0ZXIgbmFt ZSBmb3IgdGhlIFRDPyANCi0gbXkgc3VnZ2VzdGlvbiB0byBtYWtlIHRoZSBUQyBJQU5BLWFkbWlu aXN0ZXJlZCB3b3VsZCBhbGxvdyBmb3IgbmV3IG1lZGlhIHR5cGVzIHRvIGJlIGFkZGVkIGluIHRo ZSBmdXR1cmUgd2l0aG91dCB0aGUgbmVlZCB0byBtb2RpZnkgdGhlIGNvcmUgTUlCIG1vZHVsZS4g SG9wZWZ1bGx5LCB0aGlzIE1JQiBtb2R1bGUgd2lsbCBiZSB1c2VkIG1hbnkgeWVhcnMgYWhlYWQg YW5kIHlvdSBjYW5ub3QgcHJlZGljdCBpbiBhZHZhbmNlIHdoYXQgbmV3IG1lZGlhIHR5cGVzIHdp bGwgYmUgaW52ZW50ZWQgb3IgYmVjb21lIHBvcHVsYXIgaW4gdGhlIGZ1dHVyZS4gDQoNCj4gPiAx Mi4gICBQYWdlIDI0OiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCBpcyBhbiDigJhhZG1pbmlz dGVyZWQgcmVnaW9u4oCZDQo+IG1lbnRpb25lZCBpbiB0aGUgREVTQ1JJUFRJT04gY2xhdXNlIG9m IHRoZSB2bVVVSUQgb2JqZWN0DQo+IFdlIHdvdWxkIGxpa2UgdG8gbWVhbiBhbiDigJxhZG1pbmlz dHJhdGl2ZSBkb21haW7igJ0uICBEb2VzIHRoaXMgbWFrZSBzZW5zZT8NCj4gDQoNClllcy4gDQoN Cg0K From nobody Tue May 26 04:07:11 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F86A1B2CE4; Tue, 26 May 2015 04:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvijudXiFV03; Tue, 26 May 2015 04:07:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785D81B2CE1; Tue, 26 May 2015 04:07:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAPlSZFXGmAcV/2dsb2JhbABTCYJmKoEyBrEMAQaZVgKBRUwBAQEBAQGBC4QiAQEBAQMSKD8MBAIBCA0BAwQBAQsUCQcyFAkIAgQOBQgaiAoBpGSuKQEBAQEBBQEBAQEBAQEBAQEYhhaEIoEChCkDEBgxBwaDEYEWBYtVhzOMOINxgnSPISNhgxdvAYECAR8jgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208";a="122113612" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 May 2015 07:07:03 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 07:07:02 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 26 May 2015 13:07:01 +0200 From: "Romascanu, Dan (Dan)" To: Hirochika Asai Thread-Topic: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 Thread-Index: AQHQl5q/7FYF97c7yUeZZUEal5KxcJ2OCPRA///saACAACHQsA== Date: Tue, 26 May 2015 11:07:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3B05D@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA2EB27@AZ-FFEXMB04.global.avaya.com> <60DE664B-1300-4BA8-ABA6-0A02017BDDD0@hongo.wide.ad.jp> <9904FB1B0159DA42B0B887B7FA8119CA5CA3B007@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-vmm-mib.all@tools.ietf.org" , "ops-dir@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 11:07:09 -0000 Dear Hirochita Asai, Exactly, with two observations. 1. you need to prefix the new MIB module with IANA 2. You also need to add text about expanding the TC in the IANA considerat= ions section.=20 (see RFC 6933 as a working example) Thanks and Regards, Dan > -----Original Message----- > From: Hirochika Asai [mailto:panda@hongo.wide.ad.jp] > Sent: Tuesday, May 26, 2015 2:00 PM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; draft-ietf-opsawg-vmm-mib.all@tools.ietf.org; > opsawg@ietf.org > Subject: Re: [OPSAWG] OPS-DIR review of draft-ietf-opsawg-vmm-mib-02 >=20 > Dear Dan, >=20 > Thank you. >=20 > >>> 11. Page 20-21: Why is the VirtualMachineStorageType limited to two > >> media types only? Would not an IANA-administered TC be more > >> appropriate here? > >> Although few people are using, the type of floppy disk was missing. > >> Then we added it. > >> As for the IANA-administrated TC, if I understand correctly, > >> StorageType in SNMPv2-TC defines the storage types. However, they are > >> not what we expect as the media types of virtual storages attached to = a > virtual machine. > > Two issues here: > > - maybe VirtualMachineStorageMediaType is a better name for the TC? > It has already been the name VirtualMachineStorageMediaType. >=20 > > - my suggestion to make the TC IANA-administered would allow for new > media types to be added in the future without the need to modify the core > MIB module. Hopefully, this MIB module will be used many years ahead and > you cannot predict in advance what new media types will be invented or > become popular in the future. >=20 > Do you recommend to separate VirtualMachineStorageMediaType from VM- > MIB like the following? > (Please find the attached for the revised draft.) >=20 > NEW: >=20 > VM-STORAGE-TC-MIB DEFINITIONS ::=3D BEGIN >=20 > IMPORTS > MODULE-IDENTITY, mib-2 > FROM SNMPv2-SMI > TEXTUAL-CONVENTION > FROM SNMPv2-TC; > (snip) > VirtualMachineStorageMediaType ::=3D TEXTUAL-CONVENTION > (snip) > END >=20 > VM-MIB DEFINITIONS ::=3D BEGIN > (snip) >=20 >=20 > Best, > Hirochika Asai >=20 > -- > Hirochika Asai , The University of Tokyo From nobody Tue May 26 18:53:46 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D381B33AF for ; Tue, 26 May 2015 18:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWroc-6yE2WR for ; Tue, 26 May 2015 18:53:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7611B33AC for ; Tue, 26 May 2015 18:53:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ53635; Wed, 27 May 2015 01:53:37 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 May 2015 02:53:34 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.218]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 27 May 2015 09:53:24 +0800 From: Duzongpeng To: Youjianjie , "opsawg@ietf.org" Thread-Topic: =?utf-8?B?W09QU0FXR10gbmV3IHZlcnNpb24gLy/nrZTlpI06IFJlOiDnrZTlpI06ICA=?= =?utf-8?B?562U5aSNOiAgQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ=?= Thread-Index: AQHQd35riU7jBcxk40yAXi8/Q1dyUZ2NzlyAgAGBGJA= Date: Wed, 27 May 2015 01:53:24 +0000 Message-ID: References: <552c8b59000001b62a8187000cdcdc> <1429103876wo3tobl3kdqijlxinie7jq> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.160] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575E92E149nkgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] =?utf-8?b?bmV3IHZlcnNpb24gLy/nrZTlpI06IFJlOiDnrZTlpI06?= =?utf-8?q?__=E7=AD=94=E5=A4=8D=3A__Another_CAPWAP_document?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 01:53:44 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575E92E149nkgeml505mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEppYW5qaWUNCg0KDQpJIHN1cHBvcnQgdGhpcyBkb2N1bWVudCwgYW5kIHRoZSB3aG9sZSBz YWxlIHVzZSBjYXNlIGlzIGNvbW1vbiBhbmQgdmFsdWFibGUgaW4gUHVibGljIFdpRmkuDQoNCg0K QmVzdCByZWdhcmRzDQoNClpvbmdwZW5nIER1DQoNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3 Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW91amlhbmppZQ0KU2VudDogVHVlc2Rh eSwgTWF5IDI2LCAyMDE1IDEwOjU2IEFNDQpUbzogb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBb T1BTQVdHXSBuZXcgdmVyc2lvbiAvL+etlOWkjTogUmU6IOetlOWkjTog562U5aSNOiBBbm90aGVy IENBUFdBUCBkb2N1bWVudA0KDQoNCkhpLA0KDQoNCg0KV2UganVzdCB1cGxvYWRlZCBhIG5ldyB2 ZXJzaW9uIG1lcmdpbmcgYWxsIHRoZSBjb21tZW50cyB3ZeKAmXJlIHJlY2VpdmVkLg0KDQpUaGVy ZSdyZSBubyBkdXBsaWNhdGlvbiBvciBjb25mbGljdGlvbiB3aXRoIHRoZSBjdXJyZW50IFdHIGRy YWZ0LiBZb3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KDQoNClRoYW5rcywNCg0KSmlh bmppZQ0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15b3Utb3BzYXdnLWNh cHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMS50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBKaWFuamllIFlvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCg0KDQpOYW1lOiAgICAgICAgICAgICAgIGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFy YXRpb24tZm9yLW1wDQoNClJldmlzaW9uOiAgMDENCg0KVGl0bGU6ICAgICAgICAgICAgICAgICAg Q0FQV0FQIENvbnRyb2wgYW5kIERhdGEgQ2hhbm5lbCBTZXBhcmF0aW9uIGZvciBNdWx0aS1wcm92 aWRlciBTY2VuYXJpbw0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAyMDE1LTA1LTI1DQoNCkdyb3Vw OiAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAg ICAgICA5DQoNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDEudHh0DQoN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15 b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC8NCg0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0 aW9uLWZvci1tcC0wMQ0KDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAxDQoN Cg0KDQpBYnN0cmFjdDoNCg0KICAgVGhlIENBUFdBUCBjb250cm9sIGNoYW5uZWwgYW5kIGRhdGEg Y2hhbm5lbCBzcGxpdCBhcmNoaXRlY3R1cmUgaGFzDQoNCiAgIHNvbWUgYmVuZWZpdHMsIHN1Y2gg YXMgcmVsaWV2aW5nIHRoZSBjYXBhY2l0eSBwcmVzc3VyZSBvZiB0aGUgQUMuDQoNCiAgIEhvd2V2 ZXIsIHRoZSBjdXJyZW50IGRvY3VtZW50cyBhcmUgbm90IHNwZWNpZmljIHRvIHRoZSBtdWx0aS1w cm92aWRlcg0KDQogICBzY2VuYXJpby4gIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSB0aGly ZC1wYXJ0eSBXTEFOIHNlcnZpY2UNCg0KICAgcHJvdmlkZXIgc2NlbmFyaW8gKGkuZS4gIFZpcnR1 YWwgTmV0d29yayBPcGVyYXRvciwgVk5PKSwgYW5kIHByb3Bvc2VzDQoNCiAgIHRvIGV4dGVuZCBD QVBXQVAgZm9yIHN1cHBvcnRpbmcgdGhpcyB1c2UgY2FzZS4NCg0KDQrlj5Hku7bkuro6IHpoYW5n ckBnc3RhLmNvbTxtYWlsdG86emhhbmdyQGdzdGEuY29tPiBbbWFpbHRvOnpoYW5nckBnc3RhLmNv bV0NCuWPkemAgeaXtumXtDogMjAxNeW5tDTmnIgxNeaXpSAyMToxOA0K5pS25Lu25Lq6OiBSYWpl c2ggUGF6aHlhbm51ciAocnBhemh5YW4pIiA7ICBXYXJyZW4gS3VtYXJpOyAgIm9wc2F3Z0BpZXRm Lm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPiIgOyBZb3VqaWFuamllDQrkuLvpopg6IFJlOltP UFNBV0ddIOetlOWkjTog562U5aSNOiBBbm90aGVyIENBUFdBUCBkb2N1bWVudA0KDQoNCkhlbGxv IGFsbCwNCg0KU3BlYWtpbmcgYXMgdGhlIGF1dGhvciBvZiBib3RoIGRyYWZ0cywgSSBhbSB0aGlu a2luZyB0aGF0IDJuZCB3aWxsIGRlbGl2ZXJ5IG11bHRpcGxlIEFSJ3MgaW5mb3JtYXRpb24gYmFz ZWQgb24gcHJvdG9jb2wuDQoNCldlIGNvdWxkIHJlc2hhcGUgdGhlIGRvY3VtZW50IHRvIG5vdCBp bXBhY3QgMXN0IG9uZSBkdXJpbmcgdGhlIFdHIGRvY3VtZW50IHBlcmlvZC4NCg0KQmVzdCByZWdh cmRzLA0KDQpaSEFORyBSb25nDQotLS0tLS0tLS0tLS0tLS0tLS0gT3JpZ2luYWwgLS0tLS0tLS0t LS0tLS0tLS0tDQpGcm9tOiBZb3VqaWFuamllIDx5b3VqaWFuamllQGh1YXdlaS5jb208bWFpbHRv OnlvdWppYW5qaWVAaHVhd2VpLmNvbT4+DQpEYXRlOiAyMDE15bm0MDTmnIgxNOaXpSAxMeaXtjM2 5YiGDQpUbzogIlJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikiIDxycGF6aHlhbkBjaXNjby5j b208bWFpbHRvOnJwYXpoeWFuQGNpc2NvLmNvbT4+LCBXYXJyZW4gS3VtYXJpPHdhcnJlbkBrdW1h cmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldD4+LCAib3BzYXdnQGlldGYub3JnPG1haWx0 bzpvcHNhd2dAaWV0Zi5vcmc+IiA8b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5v cmc+Pg0KU3ViamVjdDogW09QU0FXR10g562U5aSNOiDnrZTlpI06IEFub3RoZXIgQ0FQV0FQIGRv Y3VtZW50DQoNCkhpIFJhamVzaCwNCg0KVGhhbmtzIGZvciB0aGUgcXVlc3Rpb25zIQ0KDQpbZHJh ZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwtMDRdIGRlc2NyaWJlczogInRoZSBBQyBw cm92aWRlcyB0aGUgYWx0ZXJuYXRlIHR1bm5lbCBlbmNhcHN1bGF0aW9uIG1lc3NhZ2UgZWxlbWVu dCBjb250YWluaW5nIHRoZSB0dW5uZWwgdHlwZSBhbmQgYSB0dW5uZWwtc3BlY2lmaWMgaW5mb3Jt YXRpb24gZWxlbWVudCB3aGlsZSBjb25maWd1cmluZyB0aGUgV1RQLiINCg0KRnJvbSB0aGUgZm9y bWF0IG9mIEFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbnMgVHlwZSAoRmlndXJlIDYpLCBp dCBzZWVtcyBvbmx5IG9uZSB0dW5uZWwgaXMgc3BlY2lmaWVkIGJldHdlZW4gdGhlIFdUUCBhbmQg QVIuDQoNCltkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMF0gZm9j dXNlcyBvbiB0aGUgbXVsdGktVk5PcyBzY2VuYXJpby4gV2hlbiB0aGUgV1RQIGpvaW5zIHRoZSBB QywgaWYgdGhlIFdUUCBzZXJ2aWNlcyBtdWx0aS1WTk9zIChpLmUuIGRpZmZlcmVudCBTU0lEIGZv ciBkaWZmZXJlbnQgVk5PLCBhbmQgdXNlciBkYXRhIGNhbiBiZSBkaXJlY3RseSBzdGVlcmVkIHRv IGl0cyBjb3JyZXNwb25kaW5nIFZOTyBkb21haW4gdmlhIHRoZSBXVFAgYW5kIEFSIHR1bm5lbCks IHRoZW4gdGhlIEFDIHNob3VsZCBwcm92aWRlIHRoZSBXVFAgd2l0aCBtdWx0aXBsZSB0dW5uZWwg aW5mb3JtYXRpb24gKGUuZy4gU1NJRCwgQVIgYWRkcmVzcyBmb3IgZWFjaCB0dW5uZWwpLiBBY3R1 YWxseSB0aGlzIGRyYWZ0IGlzIG5vdCBib3VuZCB3aXRoIHR1bm5lbCBlbmNhcHN1bGF0aW9uIG5l Z290aWF0aW9uIHByb3Bvc2VkIGluIFtkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5l bC0wNF0uIFRoZXNlIHR3byBkcmFmdHMgY2FuIGJlIGNvbXBsZW1lbnRhcnkuDQoNClNvIEkgdGhp bmsgdGhlIG1haW4gZ2FwIGlzIGR1cmluZyB0aGUgV1RQIGNvbmZpZ3VyYXRpb24sIHdoYXQga2lu ZCBvZiBpbmZvcm1hdGlvbiBBQyBzaGFsbCBwcm92aWRlPyBBbHRlcm5hdGUgVHVubmVsIEVuY2Fw c3VsYXRpb25zPyBtdWx0aXBsZSB0dW5uZWwgaW5mb3JtYXRpb24gZm9yIGRpZmZlcmVudCBWTk9z PyBJIHRoaW5rIHRoaXMgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWMgc2NlbmFyaW9zLg0KDQpUaGFu a3MsDQoNCkppYW5qaWUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQoNCj4g5Y+R5Lu25Lq6 OiBSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pIFttYWlsdG86cnBhemh5YW5AY2lzY28uY29t XQ0KDQo+IOWPkemAgeaXtumXtDogMjAxNeW5tDTmnIgxNOaXpSA0OjQ1DQoNCj4g5pS25Lu25Lq6 OiBZb3VqaWFuamllOyBXYXJyZW4gS3VtYXJpOyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZz4NCg0KPiDkuLvpopg6IFJlOiBbT1BTQVdHXSDnrZTlpI06IEFub3RoZXIgQ0FQ V0FQIGRvY3VtZW50DQoNCj4NCg0KPiBIZWxsb+KApg0KDQo+DQoNCj4gQ2FuIHRoZSBhdXRob3Jz IGV4cGxhaW4gd2h5IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3IgdGhpcyBjYW5ub3QgYmUNCg0K PiBhZGRyZXNzZWQgd2l0aGluIHRoZSBmcmFtZXdvcmsgb2YgdGhlICJBbHRlcm5hdGUgVHVubmVs IEVuY2Fwc3VsYXRpb24gZm9yDQoNCj4gRGF0YSBGcmFtZXMgaW4gQ0FQV0FQ4oCdLiBTcGVjaWZp Y2FsbHksIHdoYXQgYXJlIHRoZSBnYXBzID8NCg0KPg0KDQo+IFRoZSBhbHRlcm5hdGUgdHVubmVs IGRyYWZ0IGRvZXMgYWxsb3cgZm9yIGRpZmZlcmVudCBBUiB0byBiZSBzcGVjaWZpZWQgZm9yDQoN Cj4gZGlmZmVyZW50IFdMQU5zLg0KDQo+IE9uZSBnYXAgaXMgd2hldGhlciBzdWNoIGNhcGFiaWxp dHkgKHN1cHBvcnRpbmcgb25lIGFsdGVybmF0ZSB0dW5uZWwgdmVyc3VzDQoNCj4gbXVsdGlwbGUg YWx0ZXJuYXRlIHR1bm5lbHMpIG5lZWRzIHRvIGJlIG5lZ290aWF0ZWQgb3Igbm90ID8NCg0KPg0K DQo+DQoNCj4gUmVnYXJkcw0KDQo+DQoNCj4gUmFqZXNoDQoNCj4NCg0KPiBPbiA0LzEzLzE1LCAx OjI4IEFNLCAiWW91amlhbmppZSIgd3JvdGU6DQoNCj4NCg0KPiA+SGksDQoNCj4gPg0KDQo+ID5U aGlzIGRvY3VtZW50IHN1cHBvcnRzIHRoZSBXVFAgZXN0YWJsaXNoZXMgZGF0YSB0dW5uZWxzIHdp dGggZGlmZmVyZW50DQoNCj4gPkFjY2VzcyBSb3V0ZXJzIChBUnMpLCB3aGljaCBtYXkgYmVsb25n IHRvIGRpZmZlcmVudCBWaXJ0dWFsIE5ldHdvcmsNCg0KPiA+T3BlcmF0b3JzIChWTk9zKS4NCg0K PiA+VGhlIHNsaWRlcyBhcmUgYXZhaWxhYmxlOg0KDQo+ID5odHRwczovL3Rvb2xzLmlldGYub3Jn L2FnZW5kYS85Mi9zbGlkZXMvc2xpZGVzLTkyLW9wc2F3Zy00LnBkZg0KDQo+ID5Zb3VyIHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQo+ID4NCg0KPiA+VGhhbmtzLA0K DQo+ID5KaWFuamllDQoNCj4gPg0KDQo+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCg0KPiA+ PiDlj5Hku7bkuro6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggV2FycmVuIEt1bWFyaQ0KDQo+ID4+IOWPkemAgeaXtumXtDogMjAxNeW5tDTmnIgxMeaXpSAx OjA5DQoNCj4gPj4g5pS25Lu25Lq6OiBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NCg0KPiA+PiDkuLvpopg6IFtPUFNBV0ddIEFub3RoZXIgQ0FQV0FQIGRvY3VtZW50DQoN Cj4gPj4NCg0KPiA+PiBIaSBhbGwsDQoNCj4gPj4NCg0KPiA+PiBQbGVhc2UgdGFrZSBhIGxvb2sg YXQgIkNBUFdBUCBDb250cm9sIGFuZCBEYXRhIENoYW5uZWwgU2VwYXJhdGlvbiBmb3INCg0KPiA+ PiBNdWx0aS1wcm92aWRlciBTY2VuYXJpbyINCg0KPiA+Pg0KDQo+ID4+KGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcA0K DQo+ID4+LTAwDQoNCj4gPj4pDQoNCj4gPj4NCg0KPiA+PiBUaGlzIGRvY3VtZW50IHdhcyBkaXNj dXNzZWQgc29tZXdoYXQgYXQgdGhlIGZhY2UgdG8gZmFjZSBtZWV0aW5nIGluDQoNCj4gPj5EYWxs YXMuDQoNCj4gPj4gV2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBkb2N1bWVudCB3aXRoIG91ciBBRHMg YW5kIGhhdmUgZGVjaWRlZCB0aGF0IGl0DQoNCj4gPj5pcyAgc3VmZmljaWVudGx5IGRpZmZlcmVu dCB0byB0aGUgQ0FQV0FQIEFMVCBUdW5uZWwgKHdoaWNoIGlzIHdpdGggdGhlDQoNCj4gPj5JRVNH KSwgYW5kICB0aGF0IEFMVCBUdW5uZWwgaXMgc3VmZmljaWVudGx5IGZnYXIgaW4gdGhlIHByb2Nl c3MgdGhhdA0KDQo+ID4+d2Ugd2lsbCBrZWVwIHRoaXMgIGRvY3VtZW50IHNlcGFyYXRlLi4uDQoN Cj4gPj4NCg0KPiA+PiBTbywgcGxlYXNlIHRha2UgYSBsb29rIGF0IGl0LCBhbmQgcHJvdmlkZSBp bml0aWFsIGZlZWRiYWNrIFdlIHdpbGwNCg0KPiA+PmNvbnNpZGVyIGhhdmluZyAgYSBjYWxsIGZv ciBhZG9wdGlvbiBpZiB0aGVyZSBpcyBlbm91Z2ggZXZpZGVuY2Ugb2YNCg0KPiA+PmludGVyZXN0 Li4uLg0KDQo+ID4+DQoNCj4gPj4gVw0KDQo+ID4+IC0tDQoNCj4gPj4gSSBkb24ndCB0aGluayB0 aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJhZA0KDQo+ ID4+aWRlYSBpbiB0aGUgIGZpcnN0IHBsYWNlLg0KDQo+ID4+IFRoaXMgaXMgbGlrZSBwdXR0aW5n IHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyDQoNCj4gPj5leHByZXNzaW5n IHJlZ3JldCBhdCAgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMg YW5kDQoNCj4gPj50aGF0IHBhaXIgb2YgcGFudHMuDQoNCj4gPj4gICAgLS0tbWFmDQoNCj4gPj4N Cg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQo+ID4+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCg0KPiA+PiBPUFNBV0dAaWV0Zi5vcmc8bWFpbHRv Ok9QU0FXR0BpZXRmLm9yZz4NCg0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29wc2F3Zw0KDQo+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQo+ID5PUFNBV0cgbWFpbGluZyBsaXN0DQoNCj4gPk9QU0FXR0BpZXRmLm9y ZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KDQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29wc2F3Zw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpPUFNBV0cgbWFpbGluZyBsaXN0DQoNCk9QU0FXR0BpZXRmLm9yZzxt YWlsdG86T1BTQVdHQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29wc2F3Zw0K --_000_BAFEC9523F57BC48A51C20226A5589575E92E149nkgeml505mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXJpYWwgTmFycm93IjsNCglwYW5vc2UtMToyIDEx IDYgNiAyIDIgMiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglm b250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi 5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLCBKaWFu amllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQs IGFuZCB0aGUgd2hvbGUgc2FsZSB1c2UgY2FzZSBpcyBjb21tb24gYW5kIHZhbHVhYmxlIGluIFB1 YmxpYyBXaUZpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ab25ncGVuZyBEdTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9QU0FXRyBbbWFp bHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Zb3VqaWFu amllPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAyNiwgMjAxNSAxMDo1NiBBTTxicj4N CjxiPlRvOjwvYj4gb3BzYXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPUFNBV0dd IG5ldyB2ZXJzaW9uIC8vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7nrZTl pI08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46IFJlOg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7nrZTlpI08L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuetlOWkjTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjogQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlIGp1 c3QgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBtZXJnaW5nIGFsbCB0aGUgY29tbWVudHMgd2U8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5yZSByZWNlaXZlZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGVyZSdyZSBubyBkdXBsaWNhdGlvbiBvciBjb25mbGljdGlvbiB3aXRoIHRoZSBjdXJy ZW50IFdHIGRyYWZ0LiBZb3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5KaWFuamllPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlvdS1v cHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5oYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5qaWUgWW91IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5hbWU6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1w PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlJldmlzaW9uOiZuYnNwOyAwMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaXRsZTombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0FQV0FQIENvbnRyb2wgYW5kIERhdGEg Q2hhbm5lbCBTZXBhcmF0aW9uIGZvciBNdWx0aS1wcm92aWRlciBTY2VuYXJpbzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5E b2N1bWVudCBkYXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE1LTA1 LTI1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFs IFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDEu dHh0Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15b3Utb3Bz YXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMS50eHQ8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN0YXR1czom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAt c2VwYXJhdGlvbi1mb3ItbXAvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLzwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SHRt bGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9u LWZvci1tcC0wMSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW91LW9wc2F3 Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRpZmY6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC15b3Utb3BzYXdnLWNh cHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDE8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFRo ZSBDQVBXQVAgY29udHJvbCBjaGFubmVsIGFuZCBkYXRhIGNoYW5uZWwgc3BsaXQgYXJjaGl0ZWN0 dXJlIGhhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgc29tZSBiZW5lZml0cywgc3VjaCBhcyByZWxp ZXZpbmcgdGhlIGNhcGFjaXR5IHByZXNzdXJlIG9mIHRoZSBBQy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7IEhvd2V2ZXIsIHRoZSBjdXJyZW50IGRvY3VtZW50cyBhcmUgbm90IHNwZWNpZmljIHRvIHRo ZSBtdWx0aS1wcm92aWRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgc2NlbmFyaW8uJm5ic3A7IFRo aXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSB0aGlyZC1wYXJ0eSBXTEFOIHNlcnZpY2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7IHByb3ZpZGVyIHNjZW5hcmlvIChpLmUuJm5ic3A7IFZpcnR1YWwgTmV0 d29yayBPcGVyYXRvciwgVk5PKSwgYW5kIHByb3Bvc2VzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyB0 byBleHRlbmQgQ0FQV0FQIGZvciBzdXBwb3J0aW5nIHRoaXMgdXNlIGNhc2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWP keS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjxhIGhyZWY9Im1haWx0bzp6aGFuZ3JA Z3N0YS5jb20iPnpoYW5nckBnc3RhLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzp6aGFuZ3JAZ3N0 YS5jb20iPm1haWx0bzp6aGFuZ3JAZ3N0YS5jb208L2E+XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFu IGxhbmc9IkVOLVVTIj40PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xNTwvc3Bhbj7ml6U8 c3BhbiBsYW5nPSJFTi1VUyI+IDIxOjE4PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxh bmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJhamVzaCZuYnNwO1Bh emh5YW5udXImbmJzcDsocnBhemh5YW4pJnF1b3Q7Jm5ic3A7OyAmbmJzcDtXYXJyZW4mbmJzcDtL dW1hcmk7ICZuYnNwOyZxdW90OzxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3 Z0BpZXRmLm9yZzwvYT4mcXVvdDsmbmJzcDs7IFlvdWppYW5qaWU8YnI+DQo8L3NwYW4+PGI+5Li7 6aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6 W09QU0FXR10gPC9zcGFuPg0K562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogPC9zcGFuPuetlOWk jTxzcGFuIGxhbmc9IkVOLVVTIj46IEFub3RoZXIgQ0FQV0FQIGRvY3VtZW50PG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiPkhlbGxvIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+U3BlYWtpbmcgYXMgdGhlIGF1dGhvciBvZiBib3RoIGRyYWZ0cywgSSBhbSB0 aGlua2luZyB0aGF0IDJuZCB3aWxsIGRlbGl2ZXJ5IG11bHRpcGxlIEFSJ3MgaW5mb3JtYXRpb24g YmFzZWQgb24gcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPldlIGNvdWxkIHJlc2hhcGUgdGhlIGRvY3VtZW50IHRvIG5vdCBpbXBhY3QgMXN0IG9u ZSBkdXJpbmcgdGhlIFdHIGRvY3VtZW50IHBlcmlvZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5aSEFORyBSb25nPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIE5hcnJvdyZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0t LS0tLS0tLS0tLS0tLS0tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Zb3VqaWFuamllICZsdDs8YSBocmVmPSJtYWlsdG86eW91amlhbmppZUBodWF3 ZWkuY29tIj55b3VqaWFuamllQGh1YXdlaS5jb208L2E+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5EYXRlOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MDQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQogMTE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5pe2PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MzY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+5YiGPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtSYWplc2ggUGF6aHlhbm51ciAocnBh emh5YW4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnBhemh5YW5AY2lzY28uY29tIj5ycGF6 aHlhbkBjaXNjby5jb208L2E+Jmd0OywgV2FycmVuIEt1bWFyaSZsdDs8YSBocmVmPSJtYWlsdG86 d2FycmVuQGt1bWFyaS5uZXQiPndhcnJlbkBrdW1hcmkubmV0PC9hPiZndDssDQogJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPiZn dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3ViamVjdDoNCjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bT1BTQVdH XQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPuetlOWk jTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsYWNrIj7n rZTlpI08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj46IEFub3RoZXIgQ0FQV0FQIGRvY3VtZW50DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SGkgUmFqZXNoLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0 aGUgcXVlc3Rpb25zITxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+W2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsLTA0XSBkZXNjcmliZXM6 ICZxdW90O3RoZSBBQyBwcm92aWRlcyB0aGUgYWx0ZXJuYXRlIHR1bm5lbCBlbmNhcHN1bGF0aW9u IG1lc3NhZ2UgZWxlbWVudCBjb250YWluaW5nIHRoZSB0dW5uZWwgdHlwZSBhbmQgYSB0dW5uZWwt c3BlY2lmaWMgaW5mb3JtYXRpb24gZWxlbWVudCB3aGlsZSBjb25maWd1cmluZyB0aGUgV1RQLiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RnJv bSB0aGUgZm9ybWF0IG9mIEFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbnMgVHlwZSAoRmln dXJlIDYpLCBpdCBzZWVtcyBvbmx5IG9uZSB0dW5uZWwgaXMgc3BlY2lmaWVkIGJldHdlZW4gdGhl IFdUUCBhbmQgQVIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5bZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAtMDBdIGZvY3Vz ZXMgb24gdGhlIG11bHRpLVZOT3Mgc2NlbmFyaW8uIFdoZW4gdGhlIFdUUCBqb2lucyB0aGUgQUMs IGlmIHRoZSBXVFAgc2VydmljZXMgbXVsdGktVk5PcyAoaS5lLiBkaWZmZXJlbnQgU1NJRCBmb3Ig ZGlmZmVyZW50IFZOTywgYW5kIHVzZXIgZGF0YSBjYW4gYmUgZGlyZWN0bHkgc3RlZXJlZCB0byBp dHMgY29ycmVzcG9uZGluZyBWTk8gZG9tYWluIHZpYSB0aGUgV1RQIGFuZCBBUiB0dW5uZWwpLCB0 aGVuIHRoZSBBQyBzaG91bGQgcHJvdmlkZSB0aGUgV1RQIHdpdGggbXVsdGlwbGUgdHVubmVsIGlu Zm9ybWF0aW9uIChlLmcuIFNTSUQsIEFSIGFkZHJlc3MgZm9yIGVhY2ggdHVubmVsKS4gQWN0dWFs bHkgdGhpcyBkcmFmdCBpcyBub3QgYm91bmQgd2l0aCB0dW5uZWwgZW5jYXBzdWxhdGlvbiBuZWdv dGlhdGlvbiBwcm9wb3NlZCBpbiBbZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwt MDRdLiBUaGVzZSB0d28gZHJhZnRzIGNhbiBiZSBjb21wbGVtZW50YXJ5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U28gSSB0aGluayB0aGUgbWFpbiBn YXAgaXMgZHVyaW5nIHRoZSBXVFAgY29uZmlndXJhdGlvbiwgd2hhdCBraW5kIG9mIGluZm9ybWF0 aW9uIEFDIHNoYWxsIHByb3ZpZGU/IEFsdGVybmF0ZSBUdW5uZWwgRW5jYXBzdWxhdGlvbnM/IG11 bHRpcGxlIHR1bm5lbCBpbmZvcm1hdGlvbiBmb3IgZGlmZmVyZW50IFZOT3M/IEkgdGhpbmsgdGhp cyBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBzY2VuYXJpb3MuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5KaWFuamllPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0tLS0tPC9zcGFuPumCruS7tuWOn+S7 tjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi PjogUmFqZXNoIFBhemh5YW5udXIgKHJwYXpoeWFuKSBbPGEgaHJlZj0ibWFpbHRvOnJwYXpoeWFu QGNpc2NvLmNvbSI+bWFpbHRvOnJwYXpoeWFuQGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj7lj5HpgIHml7bp l7Q8c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE1PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj40 PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xNDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1V UyI+IDQ6NDU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgPC9zcGFuPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46IFlvdWppYW5qaWU7IFdh cnJlbiBLdW1hcmk7IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgPC9zcGFuPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46IFJlOiBbT1BTQVdHXSA8L3Nw YW4+562U5aSNPHNwYW4gbGFuZz0iRU4tVVMiPjogQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEhlbGxvPC9z cGFuPuKApjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IENhbiB0aGUgYXV0aG9ycyBleHBsYWluIHdoeSB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgZm9yIHRoaXMgY2Fubm90IGJlPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGFkZHJlc3NlZCB3aXRoaW4gdGhlIGZyYW1l d29yayBvZiB0aGUgJnF1b3Q7QWx0ZXJuYXRlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIGZvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBEYXRhIEZy YW1lcyBpbiBDQVBXQVA8L3NwYW4+4oCdPHNwYW4gbGFuZz0iRU4tVVMiPi4gU3BlY2lmaWNhbGx5 LCB3aGF0IGFyZSB0aGUgZ2FwcyA/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyBUaGUgYWx0ZXJuYXRlIHR1bm5lbCBkcmFmdCBkb2VzIGFsbG93IGZv ciBkaWZmZXJlbnQgQVIgdG8gYmUgc3BlY2lmaWVkIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBkaWZmZXJlbnQgV0xBTnMuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IE9uZSBnYXAgaXMg d2hldGhlciBzdWNoIGNhcGFiaWxpdHkgKHN1cHBvcnRpbmcgb25lIGFsdGVybmF0ZSB0dW5uZWwg dmVyc3VzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IG11bHRpcGxlIGFsdGVybmF0ZSB0dW5uZWxzKSBuZWVkcyB0byBiZSBuZWdvdGlhdGVkIG9y IG5vdCA/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgUmFqZXNoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyBPbiA0LzEzLzE1LCAxOjI4IEFNLCAmcXVvdDtZb3VqaWFuamllJnF1b3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0O0hp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 ICZndDtUaGlzIGRvY3VtZW50IHN1cHBvcnRzIHRoZSBXVFAgZXN0YWJsaXNoZXMgZGF0YSB0dW5u ZWxzIHdpdGggZGlmZmVyZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7ICZndDtBY2Nlc3MgUm91dGVycyAoQVJzKSwgd2hpY2ggbWF5IGJlbG9u ZyB0byBkaWZmZXJlbnQgVmlydHVhbCBOZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDtPcGVyYXRvcnMgKFZOT3MpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7VGhlIHNs aWRlcyBhcmUgYXZhaWxhYmxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9hZ2Vu ZGEvOTIvc2xpZGVzL3NsaWRlcy05Mi1vcHNhd2ctNC5wZGYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvYWdlbmRhLzkyL3NsaWRlcy9zbGlkZXMtOTItb3BzYXdnLTQucGRmPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7WW91ciBxdWVz dGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7SmlhbmppZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZn dDsmZ3Q7IC0tLS0tPC9zcGFuPumCruS7tuWOn+S7tjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7 Jmd0OyA8L3NwYW4+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjogT1BTQVdHIFs8YSBocmVm PSJtYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvcHNhd2ctYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIDwvc3Bhbj7ku6Pooag8c3BhbiBsYW5nPSJFTi1VUyI+IFdhcnJlbiBLdW1h cmk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg Jmd0OyZndDsgPC9zcGFuPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46IDIwMTU8L3Nw YW4+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjQ8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEx PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMTowOTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+5pS25Lu25Lq6 PHNwYW4gbGFuZz0iRU4tVVMiPjogPGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3Bz YXdnQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjog W09QU0FXR10gQW5vdGhlciBDQVBXQVAgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDsgSGkgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7Jmd0OyBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgJnF1b3Q7Q0FQV0FQIENvbnRyb2wgYW5kIERh dGEgQ2hhbm5lbCBTZXBhcmF0aW9uIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBNdWx0aS1wcm92aWRlciBTY2VuYXJpbyZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0OyAmZ3Q7Jmd0Oyg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1mb3ItbXAiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcDwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyZndDstMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgJmd0OyZndDspPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IFRoaXMgZG9jdW1lbnQgd2FzIGRpc2N1c3NlZCBz b21ld2hhdCBhdCB0aGUgZmFjZSB0byBmYWNlIG1lZXRpbmcgaW48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDtEYWxsYXMuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7 IFdlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgZG9jdW1lbnQgd2l0aCBvdXIgQURzIGFuZCBoYXZlIGRl Y2lkZWQgdGhhdCBpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyAmZ3Q7Jmd0O2lzJm5ic3A7IHN1ZmZpY2llbnRseSBkaWZmZXJlbnQgdG8gdGhl IENBUFdBUCBBTFQgVHVubmVsICh3aGljaCBpcyB3aXRoIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0O0lFU0cpLCBhbmQmbmJz cDsgdGhhdCBBTFQgVHVubmVsIGlzIHN1ZmZpY2llbnRseSBmZ2FyIGluIHRoZSBwcm9jZXNzIHRo YXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg Jmd0OyZndDt3ZSB3aWxsIGtlZXAgdGhpcyZuYnNwOyBkb2N1bWVudCBzZXBhcmF0ZS4uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAm Z3Q7Jmd0OyBTbywgcGxlYXNlIHRha2UgYSBsb29rIGF0IGl0LCBhbmQgcHJvdmlkZSBpbml0aWFs IGZlZWRiYWNrIFdlIHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgJmd0OyZndDtjb25zaWRlciBoYXZpbmcmbmJzcDsgYSBjYWxsIGZvciBh ZG9wdGlvbiBpZiB0aGVyZSBpcyBlbm91Z2ggZXZpZGVuY2Ugb2Y8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDtpbnRlcmVzdC4uLi48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgJmd0OyZndDsgVzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyAmZ3Q7Jmd0OyAtLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24g aXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7aWRlYSBpbiB0aGUm bmJzcDsgZmlyc3QgcGxhY2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IFRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNl bHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7ZXhwcmVzc2luZyByZWdyZXQgYXQmbmJz cDsgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7 dGhhdCBwYWlyIG9mIHBhbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAtLS1tYWY8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgJmd0OyZn dDsgT1BTQVdHIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYu b3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29wc2F3ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7ICZndDtPUFNBV0cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86T1BTQVdH QGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vcHNhd2c8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T1BT QVdHIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9yZyI+T1BTQVdHQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2ciPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BAFEC9523F57BC48A51C20226A5589575E92E149nkgeml505mbxchi_-- From nobody Wed May 27 11:53:03 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044031A88C9 for ; Wed, 27 May 2015 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpdjTbFfAQx5 for ; Wed, 27 May 2015 11:53:01 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706561A89B0 for ; Wed, 27 May 2015 11:53:00 -0700 (PDT) Received: by wgez8 with SMTP id z8so17606459wge.0 for ; Wed, 27 May 2015 11:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Cpm6+pyfw6QcA/lBX7S405zFWpoqCKZsfXzqAmC+n3Q=; b=fOhM8HE7mxAYNmKmw8pvx+e1sue2REoYx51plz/3eW+n3ujq8HDmPSTbouvkRCxb1/ OaaHGwQBCQxsevL4ilE12iSpRePbjbnlOFjW0xpgzrsnynkGGuqsrxPesI7mq+A4aH3R N3eTTfdfFdAbTR1qquX3lDRdWYieOkLGqhHGz5g5nkuA8Nb4PpxplXYrXs7fR9iiPKjF 9xiLqw2/ZKHSkf08BasCZTUvIgLetBJkhccpqaDNDXUn/Q+UnbQxrlDQDjca04JC7AGg vHCj6Pe6pRlpmXLOVOvJnI6B+jBSjhxLAAp6niioQvAwmawCaiE1/gIzKmcbz+sqYnFc 7Jfg== X-Gm-Message-State: ALoCoQnCNlgFGmqyq7AEqKE9078j58zLq5VSzGVevx9E7ZGVRPcOq0sRxXdn3IYCWlZPTLV96a2J MIME-Version: 1.0 X-Received: by 10.194.216.196 with SMTP id os4mr62183392wjc.117.1432752779130; Wed, 27 May 2015 11:52:59 -0700 (PDT) Received: by 10.194.47.36 with HTTP; Wed, 27 May 2015 11:52:59 -0700 (PDT) Date: Wed, 27 May 2015 14:52:59 -0400 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Call for agenda items for IETF93 (Prague) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:53:02 -0000 Hi there all, There will be a joint opsArea / OpsAWG meeting in Prague. Please let us know if you need any time on the OpsAWG part of the agenda. If we do not get enough material we will cancel our part of the meeting. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 28 03:39:48 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7361A8839; Thu, 28 May 2015 03:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTW6Cr0QIzYO; Thu, 28 May 2015 03:39:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1371A87EB; Thu, 28 May 2015 03:39:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528103944.24942.60702.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 03:39:44 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-vmm-mib-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 10:39:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Management Information Base for Virtual Machines Controlled by a Hypervisor Authors : Hirochika Asai Michael MacFaden Juergen Schoenwaelder Keiichi Shima Tina Tsou Filename : draft-ietf-opsawg-vmm-mib-03.txt Pages : 55 Date : 2015-05-28 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vmm-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/