From owner-agentx@dorothy.bmc.com Tue Jan 2 15:03:01 2001 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22260 for ; Tue, 2 Jan 2001 15:03:01 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f02JwV103323; Tue, 2 Jan 2001 13:58:31 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA19717 for agentx-list; Tue, 2 Jan 2001 11:55:43 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA19711 for agentx@dorothy.bmc.com; Tue, 2 Jan 2001 11:55:38 -0800 (PST) Date: Tue, 2 Jan 2001 11:55:38 -0800 (PST) From: Randy Presuhn Message-Id: <200101021955.LAA19711@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Fwd: Antwort: Re: How to detect when to report noSuchInstance error? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id f02JwV103323 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22260 Hi - Forwarding a posting from Frank. I've added his newest address to the agentx "posters" list. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA18988 > for ; Tue, 2 Jan 2001 08:05:52 -0800 (PST) > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f02G4h413321 > for ; Tue, 2 Jan 2001 10:04:43 -0600 (CST) > Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com > (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; > Tue, 2 Jan 2001 16:07:21 +0000 > Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP > (8.8.8+Sun/cvms-30) id QAA15504; Tue, 2 Jan 2001 16:06:34 GMT > Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569C8.00585EE1 ; Tue, 2 Jan 2001 16:05:14 +0000 > X-Lotus-FromDomain: MCMAIN@MCEXT > From: "Frank Fock" > Sender: "Frank Fock" > To: Randy Presuhn > cc: agentx@dorothy.bmc.com > Message-ID: <802569C8.00585D83.00@marconicomms.com> > Date: Tue, 2 Jan 2001 17:05:26 +0100 > Subject: Antwort: Re: How to detect when to report noSuchInstance error? > Mime-Version: 1.0 > Content-type: multipart/mixed; > Boundary="0__=r96ZD4ss1IEKiHXg8I9XYrCXRUEprT8vCVGUY0q1KxrdBJT7jPc0ImXv" > Content-Disposition: inline > > --0__=r96ZD4ss1IEKiHXg8I9XYrCXRUEprT8vCVGUY0q1KxrdBJT7jPc0ImXv > Content-type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-transfer-encoding: quoted-printable > > > > > Hi, > > that=B4s how I actually implemented it ;-) The only draw back > with this solution is the overhead for an additional subagent > that implements a couple of empty tables. But at least the > customers are responsible to decide whether they need > this degree of standard conformance or not (i.e., they may > run the additional subagent or not). > > Best regards, > Frank > > > > |--------+--------------------------> > | | Randy Presuhn | > | | | | y.bmc.com> | > | | | > | | 29.12.00 19:07 | > | | | > |--------+--------------------------> > >--------------------------------------------------------------------= > --------| > | = > | > | An: agentx@dorothy.bmc.com = > | > | Kopie: (Blindkopie: Frank Fock/MAIN/MC1) = > | > | Thema: Re: How to detect when to report noSuchInstance erro= > r? | > >--------------------------------------------------------------------= > --------| > > > > > = > > --0__=r96ZD4ss1IEKiHXg8I9XYrCXRUEprT8vCVGUY0q1KxrdBJT7jPc0ImXv > Content-type: text/plain; charset=us-ascii > Content-Disposition: inline > > > > Hi - > > This morning, it occurred to me that there IS a way to get the > noSuchInstance to happen in a pure AgentX environment. Just > have a "fallback" subagent claim the table's entire subtree, > and always respond to get requests with noSuchInstance. > > The only get requests dispatched to this subagent would be > the ones for which no other subagent has registered the > row in question. Viva le (la?) kludge! > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San Jos?, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > > > --0__=r96ZD4ss1IEKiHXg8I9XYrCXRUEprT8vCVGUY0q1KxrdBJT7jPc0ImXv-- > > From owner-agentx@dorothy.bmc.com Tue Jan 2 15:04:52 2001 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22309 for ; Tue, 2 Jan 2001 15:04:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f02K0aL04010; Tue, 2 Jan 2001 14:00:36 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA19822 for agentx-list; Tue, 2 Jan 2001 12:00:54 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA19816 for agentx@dorothy.bmc.com; Tue, 2 Jan 2001 12:00:50 -0800 (PST) Date: Tue, 2 Jan 2001 12:00:50 -0800 (PST) From: Randy Presuhn Message-Id: <200101022000.MAA19816@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Fwd: Re: How to detect when to report noSuchInstance error? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id f02K0aL04010 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22309 Hi - I'm forwarding a post from David Harrington; I've added his new address to the agentx "posters" list. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA17917; > Mon, 1 Jan 2001 18:34:55 -0800 (PST) > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f022Xlu06912; > Mon, 1 Jan 2001 20:33:47 -0600 (CST) > Received: (from uucp@localhost) > by ctron-dnm.ctron.com (8.8.7/8.8.7) id VAA07930; > Mon, 1 Jan 2001 21:41:28 -0500 (EST) > Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) > id xma007922; Mon, 1 Jan 01 21:41:00 -0500 > Received: from ctron-exc1.ctron.com (ctron-exc1.ctron.com [134.141.77.90]) > by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id VAA14173; > Mon, 1 Jan 2001 21:35:20 -0500 (EST) > Received: from ctron-exc1.ctron.com (localhost [127.0.0.1]) by ctron-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) > id ZM7PZN5R; Mon, 1 Jan 2001 21:35:22 -0500 > Received: from 134.141.150.20 by ctron-exc1.ctron.com (InterScan E-Mail VirusWall NT); Mon, 01 Jan 2001 21:35:13 -0500 (Eastern Standard Time) > Message-ID: <3A513D59.91820A12@enterasys.com> > Date: Mon, 01 Jan 2001 21:30:49 -0500 > From: David Harrington > Reply-To: dbh@enterasys.com > Organization: Enterasys Networks > X-Mailer: Mozilla 4.7 [en] (WinNT; I) > X-Accept-Language: en,pdf > MIME-Version: 1.0 > To: Randy Presuhn > CC: agentx@dorothy.bmc.com > Subject: Re: How to detect when to report noSuchInstance error? > References: <200012282358.PAA07307@dorothy.bmc.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > Randy Presuhn wrote: > > > > I think the noSuchName/noSuchObject/noSuchInstance distinction > > introduced with SNMPv2 has not proven to be useful, but > > eliminating it would be too painful to even contemplate. > > > > Do any management applications vary their behaviour based > > on which of these three error-status values shows up in > > a response? I suspect that most will handle them in the > > same way, making the question largely academic. > > > > As a developer for management applications, I think there is significant > benefit from the distinction. > > During the discovery process, an application may check to see whether > certain objects are supported by an agent to determine how to model the > agent. Being able to check many objects in the same request without > needing to predict which specific instances exist would certainly help > this. > > When doing row creation in some mibs, it is necessary to determine > whether an instance already exists in a table. With the noSuchxxx > distinctions, an application can send a single message with multiple > proposed indexes to determine whether the table is supported by the > agent, and to determine if one of the proposed indexes is available. > > Applications can properly respond to error conditions caused by the > removal of a board from a chassis. If the response is noSuchName, the > application can recognize that support for the table has been > discontinued, rather than that the instance does not exist. This would > be especially important when trying to determine an available row index. > > I suspect most applications do not use it currently because most > applications still do not support SNMPv2 or SNMPv3. > > -- > --- > David Harrington Network Management Standards Architect > dbh@enterasys.com Office of the CTO > +1 603 337 2614 - voice Enterasys Networks > +1 603 332 1524 - fax Rochester NH, USA > From owner-agentx@dorothy.bmc.com Mon Jan 15 05:41:46 2001 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00402 for ; Mon, 15 Jan 2001 05:41:46 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f0FAd7L22170; Mon, 15 Jan 2001 04:39:08 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA07474 for agentx-list; Mon, 15 Jan 2001 02:37:34 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA07469 for ; Mon, 15 Jan 2001 02:37:28 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f0FAaDv21696 for ; Mon, 15 Jan 2001 04:36:14 -0600 (CST) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id NAA13319 for ; Mon, 15 Jan 2001 13:58:53 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <45GLQCFR>; Mon, 15 Jan 2001 12:35:29 +0200 Message-ID: <00554D7E32E7D1118A8800805F31D8A3BF9AE8@tiger.seabridge.co.il> From: Nurit Sprecher To: "'agentx@dorothy.bmc.com'" Subject: Questions Regarding the Intialization Process of a Master Agent Date: Mon, 15 Jan 2001 12:35:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07EDE.E14079F4" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07EDE.E14079F4 Content-Type: text/plain; charset="windows-1255" Hi all, I have some questions regarding the AgentX protocol. It will be great if someone may make it clear to me. There are some uncertainty (for me) regarding the recovery process of a master agent. What is the initialization process of a starting up master agent? Apparently, the registration table can be kept in a non-volatile memory, and upon starting up; the master agent may restore the table. Is that the situation? Or may be it is expected to re-perform the registration process? Personally, I think that the later case is unreasonable. In such a case, the question is how the master agent handles a case where the master agent failed in a middle of a transaction? Is there a requirement for persistency of a transaction managed by the master agent? Thanks in advance, Nurit. ------_=_NextPart_001_01C07EDE.E14079F4 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Questions Regarding the Intialization Process of a Master = Agent

Hi all, =

I have = some questions = regarding the AgentX protocol. It will be great if someone may make it clear to = me.

There = are some uncertainty (for me) regarding the recovery process of a = master agent. What is the initialization process of a starting up = master agent?

Apparently, the registration table can be kept in a = non-volatile memory, and upon starting up; the master agent may restore = the table.  Is that the situation? Or may be it is expected to = re-perform the registration process? Personally, I think that the later = case is unreasonable. 

In such = a case, the question is how the master agent handles a case where the = master agent failed in a middle of a transaction? Is there a = requirement for persistency of a transaction managed by the master = agent? 

Thanks = in advance, Nurit.

------_=_NextPart_001_01C07EDE.E14079F4-- From owner-agentx@dorothy.bmc.com Tue Jan 16 08:52:50 2001 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11801 for ; Tue, 16 Jan 2001 08:52:50 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f0GDoTU24895; Tue, 16 Jan 2001 07:50:29 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA09833 for agentx-list; Tue, 16 Jan 2001 05:44:36 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA09828 for ; Tue, 16 Jan 2001 05:44:31 -0800 (PST) Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f0GDhGc23047 for ; Tue, 16 Jan 2001 07:43:16 -0600 (CST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 16 Jan 2001 13:45:49 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id NAA05057; Tue, 16 Jan 2001 13:39:31 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569D6.004AE4FF ; Tue, 16 Jan 2001 13:38:02 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Frank Fock" To: Nurit Sprecher cc: "'agentx@dorothy.bmc.com'" Message-ID: <802569D6.004AE2E2.00@marconicomms.com> Date: Tue, 16 Jan 2001 14:38:25 +0100 Subject: Antwort: Questions Regarding the Intialization Process of a Master Agent Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=Ay0ZZ1CvrEovmes2kaP0kT5mN24y3R1Gbi43wI3ilamVk9T0OySgdJz2" Content-Disposition: inline Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list --0__=Ay0ZZ1CvrEovmes2kaP0kT5mN24y3R1Gbi43wI3ilamVk9T0OySgdJz2 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Nurit, The registration process is always triggered by the subagents. Thus, the master must not store the registration table in non volatile memory, because it cannot restore the connections to subagents. So, upon starting up the master agent just waits until a subagent registers. Consequently, when a master agents reinitializes the related subagents should be reinitialized too. This can be done by a process manager (i.e., a script controlling the master / subagent processes) or by simply restarting/reinitializing a subagent when its connection to the master is broken. Regarding persistency of transactions, IMHO there is no persistency, because a transaction that hangs will time out and will then always be terminated by the master agent. (Hopefully before the manager times out its SNMP request!) Hope this helps. Best regards, Frank Nurit Sprecher 15.01.01 11:35 An: "'agentx@dorothy.bmc.com'" Kopie: (Blindkopie: Frank Fock/MAIN/MC1) Thema: Questions Regarding the Intialization Process of a Master Agent Hi all, I have some questions regarding the AgentX protocol. It will be great if someone may make it clear to me. There are some uncertainty (for me) regarding the recovery process of a master agent. What is the initialization process of a starting up master agent? Apparently, the registration table can be kept in a non-volatile memory, and upon starting up; the master agent may restore the table. Is that the situation? Or may be it is expected to re-perform the registration process? Personally, I think that the later case is unreasonable. In such a case, the question is how the master agent handles a case where the master agent failed in a middle of a transaction? Is there a requirement for persistency of a transaction managed by the master agent? Thanks in advance, Nurit. (See attached file: att1.htm) --0__=Ay0ZZ1CvrEovmes2kaP0kT5mN24y3R1Gbi43wI3ilamVk9T0OySgdJz2 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1NSI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRF TlQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDUuNS4yNjUwLjEyIj4NCjxUSVRMRT5RdWVz dGlvbnMgUmVnYXJkaW5nIHRoZSBJbnRpYWxpemF0aW9uIFByb2Nlc3Mgb2YgYSBNYXN0ZXIgQWdl bnQ8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQIEFMSUdOPUxFRlQ+PEZPTlQgQ09MT1I9 IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+SGkgYWxsLCA8L0ZPTlQ+PC9QPg0KDQo8UCBB TElHTj1MRUZUPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPkkgaGF2 ZSBzPC9GT05UPjxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPm9tZSBx dWVzdGlvbnMgcmVnYXJkaW5nIHRoZSBBZ2VudFggcHJvdG9jb2wuIEl0IHdpbGwgYmUgZ3JlYXQg aWY8L0ZPTlQ+IDxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPnNvbWVv bmU8L0ZPTlQ+IDxGT05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPm1heTwv Rk9OVD48Rk9OVCBDT0xPUj0iIzAwMDAwMCIgU0laRT0yIEZBQ0U9IkFyaWFsIj4gbWFrZSBpdCBj bGVhciB0byBtZS48L0ZPTlQ+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxGT05UIENPTE9SPSIjMDAw MDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZXJlIGFyZSBzb21lIHVuY2VydGFpbnR5IChmb3Ig bWUpIHJlZ2FyZGluZyB0aGUgcmVjb3ZlcnkgcHJvY2VzcyBvZiBhIG1hc3RlciBhZ2VudC4gV2hh dCBpcyB0aGUgaW5pdGlhbGl6YXRpb24gcHJvY2VzcyBvZiBhIHN0YXJ0aW5nIHVwIG1hc3RlciBh Z2VudD88L0ZPTlQ+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxGT05UIENPTE9SPSIjMDAwMDAwIiBT SVpFPTIgRkFDRT0iQXJpYWwiPkFwcGFyZW50bHksIHRoZSByZWdpc3RyYXRpb24gdGFibGUgY2Fu IGJlIGtlcHQgaW4gYSBub24tdm9sYXRpbGUgbWVtb3J5LCBhbmQgdXBvbiBzdGFydGluZyB1cDsg dGhlIG1hc3RlciBhZ2VudCBtYXkgcmVzdG9yZSB0aGUgdGFibGUuJm5ic3A7IElzIHRoYXQgdGhl IHNpdHVhdGlvbj8gT3IgbWF5IGJlIGl0IGlzIGV4cGVjdGVkIHRvIHJlLXBlcmZvcm0gdGhlIHJl Z2lzdHJhdGlvbiBwcm9jZXNzPyBQZXJzb25hbGx5LCBJIHRoaW5rIHRoYXQgdGhlIGxhdGVyIGNh c2UgaXMgdW5yZWFzb25hYmxlLiZuYnNwOyA8L0ZPTlQ+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxG T05UIENPTE9SPSIjMDAwMDAwIiBTSVpFPTIgRkFDRT0iQXJpYWwiPkluIHN1Y2ggYSBjYXNlLCB0 aGUgcXVlc3Rpb24gaXMgaG93IHRoZSBtYXN0ZXIgYWdlbnQgaGFuZGxlcyBhIGNhc2Ugd2hlcmUg dGhlIG1hc3RlciBhZ2VudCBmYWlsZWQgaW4gYSBtaWRkbGUgb2YgYSB0cmFuc2FjdGlvbj8gSXMg dGhlcmUgYSByZXF1aXJlbWVudCBmb3IgcGVyc2lzdGVuY3kgb2YgYSB0cmFuc2FjdGlvbiBtYW5h Z2VkIGJ5IHRoZSBtYXN0ZXIgYWdlbnQ/Jm5ic3A7IDwvRk9OVD48L1A+DQoNCjxQIEFMSUdOPUxF RlQ+PEZPTlQgQ09MT1I9IiMwMDAwMDAiIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhhbmtzIGluIGFk dmFuY2UsIE51cml0LjwvRk9OVD48L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=Ay0ZZ1CvrEovmes2kaP0kT5mN24y3R1Gbi43wI3ilamVk9T0OySgdJz2--