From kwangkooglee@gmail.com Thu Aug 1 01:24:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0572521F8934 for ; Thu, 1 Aug 2013 01:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uot4dSP1UwK9 for ; Thu, 1 Aug 2013 01:24:47 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 89F8E21F994B for ; Thu, 1 Aug 2013 01:24:44 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id i11so945311qej.5 for ; Thu, 01 Aug 2013 01:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bX9pX1cSb1RToGQASW3l7hJyB1sXjwYlU8y9xmz3DTU=; b=Uiv7+o/QcZ44hYrgsTZD9Y+OjpPvrNWLkrDdhflq25UlH1m5wFfsAZWBAIXlN+KiJy 9C/OR9Yx5Lnj+/oC9kZjRVRIUTySdA9ySHEbtsSgGtE7Bm1eYXDUpBpDiNzHLJRoT1Xc Ajne17BFabLdzAZweIb7wEjvlHOMG2MndXXpGMjBGxmgm/UeatCZpTBjfLqPVetR1KtR f0BPKrPqMtcKQrzlPa8TUNZzfJskgyOBoAbmx4kPxJuVmk61R2d7JtM9PjA8Q0wSk0GC WYMHaTY6eayIp85OgvtYooPCz9vQ/ujJvAsDjrJN3cZfwwBod1UwDK5HNka7y4lTWLP0 elyA== MIME-Version: 1.0 X-Received: by 10.229.146.201 with SMTP id i9mr82949qcv.102.1375345481063; Thu, 01 Aug 2013 01:24:41 -0700 (PDT) Received: by 10.49.2.198 with HTTP; Thu, 1 Aug 2013 01:24:40 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> References: <51F8ED88.5050208@cisco.com> <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> Date: Thu, 1 Aug 2013 17:24:40 +0900 Message-ID: From: KwangKoog Lee To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=e89a8f5035f2d7bd2704e2de92d0 Cc: "i2rs@ietf.org" , "Joe Clarke \(jclarke\)" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:24:49 -0000 --e89a8f5035f2d7bd2704e2de92d0 Content-Type: text/plain; charset=ISO-8859-1 I also support WG adoption and agree with other members' comments. Also, I have a small comment about the Sec. 6.1. "Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms." Instead of this sentence, I think it needs to mention that I2RS protocol messages must be treated by the highest proirity even if the control network is under a congestion situation so that the communication is very highly reliable between I2RS client and I2RS agent. I think congestion control is little bit risky to I2RS operation because those messages have very impotant information and also problem statement document already mentions that responsiveness and reliability of i2rs is important. Thanks. Sincerely, Kwnag-koog Lee (Ph.D) KT (Korea Telecom) On Wed, Jul 31, 2013 at 8:14 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > > On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke wrote: > > Section 2: > > read scope: ... > > write scope: ... > > JMC: Should there be an event or notification scope in addition to read > and write? > > > +1 to this point. I think that it should also include some words about > pub/sub. > > Section 6.6 covers some of this though, so perhaps a forward reference. > > Thanks, > > -- Carlos. > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --e89a8f5035f2d7bd2704e2de92d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also support WG adoption and agree with other membe= rs' comments.
Also, I have a small comment about the Sec. 6.1= .
=A0
"Whatever transport is used for the data ex= change, it must also support suitable congestion control mechanisms."<= /div>
=A0
Instead of this sentence, I think it needs to mention th= at I2RS protocol messages=A0must be treated by the highest proirity even if= the control network is under a congestion situation so that the communicat= ion is very highly reliable between I2RS client and I2RS agent.
I think congestion control is little bit risky to I2RS operation becau= se those messages have very impotant information and also problem statement= =A0document already mentions that responsiveness and reliability of i2rs is= important.
Thanks.
=A0
Sincerely,
Kwnag-koog Lee (= Ph.D)
KT (Korea Telecom)

On Wed, Jul 31, 2013 at 8:14 PM, Carlos Pi= gnataro (cpignata) <cpignata@cisco.com> wrote:

O= n Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote:

Section 2:

read scope: ...

write= scope: ...

JMC: Should there be an e= vent or notification scope in addition to read
and write?

+1= to this point. I think that it should also include some words about pub/su= b.=A0

Section 6.6 covers some of this though, so p= erhaps a forward reference.

Thanks,

-- Carlos.
=
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--e89a8f5035f2d7bd2704e2de92d0-- From nabil.n.bitar@verizon.com Thu Aug 1 01:42:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FF921F894E for ; Thu, 1 Aug 2013 01:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DegAA6dPvTf for ; Thu, 1 Aug 2013 01:42:32 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) by ietfa.amsl.com (Postfix) with ESMTP id 252D021F9CE7 for ; Thu, 1 Aug 2013 01:42:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe01.verizonbusiness.com with ESMTP; 01 Aug 2013 08:42:10 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.89,792,1367971200"; d="ppt'32?scan'32,208,32";a="518475664" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi02.verizon.com with ESMTP; 01 Aug 2013 08:42:10 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Thu, 1 Aug 2013 04:42:09 -0400 To: Edward Crabbe , "i2rs@ietf.org" Date: Thu, 1 Aug 2013 04:41:53 -0400 Thread-Topic: [i2rs] presentations for the wg meeting Thread-Index: Ac6OkwH7CNyK5c72Qmm5NRSpfHv4+g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_CE1F9569942B3nabilnbitarverizoncom_" MIME-Version: 1.0 Subject: Re: [i2rs] presentations for the wg meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:42:33 -0000 --_002_CE1F9569942B3nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ed. Please, see attached. Thanks, Nabil --_002_CE1F9569942B3nabilnbitarverizoncom_ Content-Type: application/vnd.ms-powerpoint; name="i2rs_service_chaining_IETF87.ppt" Content-Description: i2rs_service_chaining_IETF87.ppt Content-Disposition: attachment; filename="i2rs_service_chaining_IETF87.ppt"; size=318976; creation-date="Thu, 01 Aug 2013 08:42:08 GMT"; modification-date="Thu, 01 Aug 2013 08:42:08 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAFAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAAIAAAACQAAAHwBAAD8AQAA//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////bAIAAP7///8EAAAABQAAAAYAAAAHAAAAEwAAAP3////9////CwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAADAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABz AAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAFIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAFqBpteSjs4B bQIAAIAAAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAAAF4UEAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEoCAABEMwAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAIAAAAQAAAAAAAAAQAA AP7///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9nAHIA YQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAI DAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAA AAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAA AAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAA CAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAA AAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIA AAEMAAAAAAAAABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAA AAAAAAEBAAAAAQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAA aG5hbWQAAABgAAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAAD AAAAAAAAACYATQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQA GAAAAAABBwAAAAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAA ABQAAAAgAAAAAQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAA AQAAAAAAAAECAAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABg AAAAAgAAAAQAAAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYA TQBvAG4AbwB0AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAA AAYAAAAAAAAAAAAEAAAADgAJABEAAAAaAAEAAAAIDAEAAAAAAAIAAAEMAAAAAAAAABQAAAAgAAAA AQAAAAEAAAAAAAAAAQAAAOgAAAAIAAAABAAAAAAAAAEAAAAAAQAAAAAAAAEBAAAAAQAAAAAAAAEC AAAAAQAAAAAAAAEDAAAAAQAAAAAAAAEEAAAAAQAAAAAAAAEFAAAAaG5hbWQAAABgAAAAAgAAAAQA AAAAAAAAAwAAAAAAAAAKAEEAcgBpAGEAbAAAAAAACAAAAAAAAAADAAAAAAAAACYATQBvAG4AbwB0 AHkAcABlACAAVAB5AHAAbwBnAHIAYQBwAGgAeQAAAAABBgAAAAQAGAAAAAABBwAAAAYAAAAAAAAA AAAEAAAADgAJABEAAAAaAAEPAIgXPAAAAAAAiRc0AAAAAAAAAAAAAAAAAAAAWAIAAAABAQABAQAA AQEBAAEAAAAAAAAAiM8AAAAAAAAAAAAAgAIB4A8A+AO/PgAAAgDvAxgAAAABAAAAAQIHCQgAAAAA AAAAAAAAAAIA/79gAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAA AAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAA AJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAA YADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAA WlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP// mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAA AP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIA gJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8Acg AAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQA AAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//ywAAAAAAwAAEACjD4AAAAAF AP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAA AAEAAIAFAAATINQBIAEAACIA//8UAIAFAAAiINACQAIAAAIAEgCABQAAEyDwA2ADAAACABAAgAUA ALsAEAWABAAAAgAOACAAow9wAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAA AgAAAP//7wAAAAAAAQAAAP//DAAAAAABAAAABQAAIAEgAQAAIAD//wAFAABAAkACAAAAAAAFAABg A2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAA IAEAAAAABwAAAP//7wAAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAA BQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAA AQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABg AKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAFAABAAAAAAAAAAIAEgACAAAA AAAAAAIAEAADAAAAAAAAAAIADgAEAAAAAAAAAAIADACAAKMPPgAAAAUAAAAAAAAAAAACABIAAQAA AAAAAAACABAAAgAAAAAAAAACAA4AAwAAAAAAAAACAAwABAAAAAAAAAACAAoAAAAjBBgHAABQSwME FAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLasMwEEX3hf6D 0LZYcroopdjOoo9dH4v0AwZ5bIvqhUYJyd937KQQSshqmMede7jNeu+d2GEmG0MrgQAAAIIAAACD AAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEA AACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAA AKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAA rgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8 AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoA AADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAA ANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA 5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1 AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMB AAAEAQAABQEAAAYBAAAHAQAACAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEA ABIBAAATAQAAFAEAABUBAAAWAQAAFwEAABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAA IAEAACEBAAAiAQAAIwEAACQBAAAlAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAu AQAALwEAADABAAAxAQAAMgEAADMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAADwB AAA9AQAAPgEAAD8BAABAAQAAQQEAAEIBAABDAQAARAEAAEUBAABGAQAARwEAAEgBAABJAQAASgEA AEsBAABMAQAATQEAAE4BAABPAQAAUAEAAFEBAABSAQAAUwEAAFQBAABVAQAAVgEAAFcBAABYAQAA WQEAAFoBAABbAQAAXAEAAF0BAABeAQAAXwEAAGABAABhAQAAYgEAAGMBAABkAQAAZQEAAGYBAABn AQAAaAEAAGkBAABqAQAAawEAAGwBAABtAQAAbgEAAG8BAABwAQAAcQEAAHIBAABzAQAAdAEAAHUB AAB2AQAAdwEAAHgBAAB5AQAAegEAAHsBAAB9AQAA/f///34BAAB/AQAAgAEAAA8A6APFFgAAAQDp AygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAACAAAAAAAAAAEAAAAAAAABDwDyA7IBAAAvAMgP DAAAADAA0g8EAAAAAQAAAA8A1QfkAAAAAAC3D0QAAABBAHIAaQBhAGwAAAD9/f39/f39/f39/f39 /f39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAtw9EAAAALf8z/yAA MP+0MLcwwzCvMAAA/f39/f39/f39/f39/f39/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIAAAAAgALcPRAAAAFcAaQBuAGcAZABpAG4AZwBzAAAA/f39/f39/f39/f39/f39/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAACkDwoAAACAAEIAAAAAABIAAAClDxAAAAAAACAILgAA AAD/AAAHAAAAAACpDwoAAAAHAAAAAgAQBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQA AAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABA AkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwTcAQAADwAA8NQBAAAAAAbwYAEAAAao AAArAAAAnAAAACoAAAABAAAABgAAAAIAAAABAAAAAwAAAAEAAAAEAAAAAQAAAAUAAAABAAAABgAA AAEAAAAHAAAAAQAAAAgAAAABAAAACQAAAAEAAAAKAAAAAQAAAAsAAAABAAAADAAAAAEAAAANAAAA AQAAAA4AAAAIAAAADwAAAAUAAAAQAAAABAAAABEAAAAFAAAAEgAAAAQAAAATAAAABQAAABQAAAAE AAAAFQAAAAUAAAAWAAAABAAAABcAAAAFAAAAGAAAAAQAAAAZAAAABQAAABoAAAAEAAAAGwAAAAUA AAAcAAAABAAAAB0AAAAFAAAAHgAAAAQAAAAfAAAABgAAACAAAAAGAAAAIQAAAAYAAAAiAAAABgAA ACMAAAAGAAAAJAAAAAYAAAAlAAAABgAAACYAAAAGAAAAJwAAAAYAAAAoAAAABgAAACkAAAAGAAAA KgAAAAYAAACDAAvwMAAAAIEBBAAACIMBAAAACIbBAAAAAL8BEAAQAMABAQAACMXBAAAAAP8BCAAI AAECAgAACFAAGvEUAAAA/wcSAAAAAADAwMAA//8AAP//ZgBAAB7xEAAAAP//////////AgAACPcA ABAfAPAPbAEAAAAA8wMUAAAAAwAAAAAAAAAAAAAAAwAAgAAAAAAAAPMDFAAAAAQAAAAAAAAAAAAA AFgAAIAAAAAAAADzAxQAAAAFAAAAAAAAAAAAAABZAACAAAAAAAAA8wMUAAAABgAAAAAAAAAAAAAA WgAAgAAAAAAAAPMDFAAAAAcAAAAAAAAAAAAAAFsAAIAAAAAAAADzAxQAAAAIAAAAAAAAAAAAAABc AACAAAAAAAAA8wMUAAAACQAAAAAAAAAAAAAAXQAAgAAAAAAAAPMDFAAAAAoAAAAAAAAAAAAAAF4A AIAAAAAAAADzAxQAAAALAAAAAAAAAAAAAABfAACAAAAAAAAA8wMUAAAADAAAAAAAAAAAAAAAYAAA gAAAAAAAAPMDFAAAAA0AAAAAAAAAAAAAAGEAAIAAAAAAAADzAxQAAAAOAAAAAAAAAAAAAABiAACA AAAAAAAA8wMUAAAADwAAAAAAAAAAAAAAYwAAgAAAAAAPANAHAAIAAB8AEwQ8AAAAAAD9AzQAAABk AAAAZAAAAGQAAABkAAAAf8fBYFix/78Qnf+/CAAAAEDQewH2UqxgAAAAAAAAAAAAAAAADwD6A2cA AAAAAP4DAwAAAAABAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAADiGfB8IAAAACAAAAMic/78DAAAA C7f/v6D5//+w////AACKJXAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAHBDwAAAAA AP0DNAAAACEAAABkAAAAIQAAAGQAAAB/x8FgWLH/vxCd/78IAAAAQNB7AR5WrGAAAAAAAAAAAAAA AAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAH/HwWBYsf+/EJ3/vwgAAABA0HsBCi2u YAAAAAAAAAAAAAAAAA8AiBO9AAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsT CQAAAAAAJQQBAAAAAA8AihOEAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2QAAAAPANYH TAAAAAAAtw9EAAAALf8z/yAAMP+0MLcwwzCvMAAA/f39/f39/f39/f39/f39/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAAAA AgBPANkPDAAAAAAA2g8EAAAAAAACAA8A8A/gAAAAAADzAxQAAAAQAAAABAAAAAAAAAAAAQAAAAAA AAAA8wMUAAAAEQAAAAQAAAAAAAAAHgEAAAAAAAAAAPMDFAAAABIAAAAEAAAAAAAAADEBAAAAAAAA AADzAxQAAAATAAAABAAAAAAAAAA0AQAAAAAAAAAA8wMUAAAAFAAAAAQAAAAAAAAANQEAAAAAAAAA APMDFAAAABUAAAAEAAAAAAAAADYBAAAAAAAAAADzAxQAAAAWAAAABAAAAAAAAAA5AQAAAAAAAAAA 8wMUAAAAFwAAAAQAAAAAAAAANwEAAAAAAAAvAPAP4AAAAAAA8wMUAAAAGAAAAAQAAAAAAAAAAAEA AAAAAAAAAPMDFAAAABkAAAAEAAAAAAAAAAEBAAAAAAAAAADzAxQAAAAaAAAABAAAAAAAAAACAQAA AAAAAAAA8wMUAAAAGwAAAAQAAAAAAAAAAwEAAAAAAAAAAPMDFAAAABwAAAAEAAAAAAAAAAQBAAAA AAAAAADzAxQAAAAdAAAABAAAAAAAAAAFAQAAAAAAAAAA8wMUAAAAHgAAAAQAAAAAAAAABgEAAAAA AAAAAPMDFAAAAB8AAAAEAAAAAAAAAAcBAAAAAAAAAAAoBMEHAABQSwMEFAAGAAgAAAAhAJ3GccL2 AAAAqQEAABMACAJbQ29udGVudF9UeXBlc10ueG1sIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHyQzWrDMBCE74W+g9C1WHJ7KKXE zqE/x7bQ9AG28toW0R/aTYjfvrKTQikhp0W7mpmPWa0P3ok9ZrIxNPJW1VJgMLGzYWjk1+a1epCC GEIHLgZs5IQk1+311WozJSRR1IEaOTKnR63JjOiBVEwYyqWP2QOXZx50ArOFAfVdXd9rEwNj4Ipn D9munrGHnWPxcijrI0mRS/F0/DdHNRJSctYAF1A9X/VZXUZHF4T70P2jq05kqigXcxptoptTwnup JtsOxQdkfgNfODTDt8NPnhySuox5Ji32vTXYRbPzpQGVMlKZS7B36o/1L4Feim5/AAAA//8DAFBL AwQUAAYACAAAACEA7eQMS7sAAAAmAQAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISPzQrCMBCE74Lv EPZuUz2ISNNeRPCq9QHWdPuDaRKSVezbm2MLgsfZYb7ZKarPaMSbQhycVbDNchBktWsG2ym41+fN AURktA0aZ0nBRBGqcr0qrmSQUyj2g48iUWxU0DP7o5RR9zRizJwnm5zWhRE5ydBJj/qJHcldnu9l mDOgXDDFpVEQLs0WRD351Pyf7dp20HRy+jWS5R8VkvFh6MaTSStEjaEjVjA7ZulbkGUhF+vKLwAA AP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAAA8AAAB0YWJsZVN0eWxlcy54bWwMzEkOgjAY QOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcGj3uD Y0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25DKRb+HvT lSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD//wMAUEsBAi0A FAAGAAgAAAAhAJ3GccL2AAAAqQEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54 bWxQSwECLQAUAAYACAAAACEA7eQMS7sAAAAmAQAACwAAAAAAAAAAAAAAAAAvAwAAX3JlbHMvLnJl bHNQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAADwAAAAAAAAAAAAAAAAAbBgAAdGFibGVTdHls ZXMueG1sUEsFBgAAAAADAAMAtwAAAPQGAAAAAAAA6gMAAAAAQAAaEGYFAAAFAAAAAAgMAQAAAAAA AgAAAQwAAAAAAAAAFAAAACAAAAABAAAAAQAAAAAAAAABAAAA6AAAAAgAAAAEAAAAAAAAAQAAAAAB AAAAAAAAAQEAAAABAAAAAAAAAQIAAAABAAAAAAAAAQMAAAABAAAAAAAAAQQAAAABAAAAAAAAAQUA AABobmFtZAAAAGAAAAACAAAABAAAAAAAAAADAAAAAAAAAAoAQQByAGkAYQBsAAAAAAAIAAAAAAAA AAMAAAAAAAAAJgBNAG8AbgBvAHQAeQBwAGUAIABUAHkAcABvAFeqlgKDib0NYyu/N2/VoxRUIPTg YsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7Jr XnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj +IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQ SwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQ kaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4 eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIp OqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP// AwBQSwMEFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFz dGVyMS54bWzsWktu2zAU3BfoHQRuA8eW/JFsWA6SFFllETTJAWiZstVQlEAxadxVkRyhN+i+aIEW 6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9N8OX7sGtj7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRi AS1ikAwgDgiywRhF4KD3+lU37LDbczbGKNL4FCTqQBuMGAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1 QOF7PrWPq0at1qr60CNAjadFxgeu6znoTeBc+4iweBKKMGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe2 5zGM5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe8JQc0Sv57AaEHcoufRghoI0gGfL9nl0Th4kOYqoo dI6Qq57OHKbdQDlRtdetzrUeumxFP9U6QO5bvrLogw0ajZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K 9xIgEo2NQ+RChzO957+rYCZ6wg6CqYbHhy+PD9+1x4dvk7sfk7ufk/v7yd1XoDkjSCMktykHOdF/ D+L7j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g7+GxDSp6rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh 5AhGFDnNkpwNI0cwoshpCXJ8SE95am2aXLKAPAEwl/TF2C3J8UWTzEJeFsAojMwZRm1dCpASIylY BDAKI2uGkV439VZ5kBKBJ5BRILVTIFmGZZUgJSAJZPhz1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5 Jj/E/oULy6d1Lzw08tet62D618fcO0gDYYM/Hz/HpiPla4xivkZPVrDa15DN8zUxayZnrZlmzbCa pvhhG1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V3bDUUcnazXlHE9Oi64262MrsazIMKxXDt+hr2io2 5i2MYoMjL5XYNLZtExuLX4lUA1vFy7x7iXkxak1ThOlt/Ep+/1oIXvpLppy1gle+bzGaekPGqn9/ LoV9zBNm+xzkxezblTby3ZDRNnUpYkvki1wfr3Xm8z1WLHYLhaLyzK++Y14qlfKNW92yWgWTc4n8 mshP3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgbIFK5PJ8pX9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1 oMnK0awGlq156TKUq1WIGlUcE68QFfVGcVaeW/vs+aSCYJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1i aBIQpnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA5XsIPXvvt8sALVHz8uKhDNE8Li8R3WajLgVIGaOX aGOOjrTpJUBLJGyraWYv93Y2i02VZlpcijKE+s+v3l8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsT Bbv6AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAAavciugDAAA/JgAAIQAAAAAAAAAAAAAAAAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlk ZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAAADkGAAAAAA8ADASPHQAADwAC8IcdAAAQAAjwCAAA AAUAAAAFBAAADwAD8CsdAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA AAQAAAUAAAAPAATwLgEAABIACvAIAAAAAgQAAAAKAACDAAvwSAAAAH8AAQDvAYAAmIprIL8AAAAG AL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAA EPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAAIA/78PAA3wngAAAAAAnw8EAAAAAQAA AAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRo aXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAA AAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8PcIAAASAArwCAAAAAMEAAAACgAA gwAL8EgAAAB/AAEA7wGAAAiSayC/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBS AGUAYwB0AGEAbgBnAGwAZQAgADMAAAATACLxBwgAAKnDAQgAAFBLAwQUAAYACAAAACEAMjy9PvsA AADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAj e5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtk vW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Biz ut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM 4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQU AAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2 QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaH E0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7B VAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPN S/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEAuYg5ZJ0DAADACAAAEAAAAGRycy9zaGFw ZXhtbC54bWysVdtuE0kQfV+Jf2j1O/gewGKCkmjDrmQiKw7iuWamJ551T/dsd48veQzfg0ACiZf8 TT4gv0BV9TjOLgixa/xgV7vrcurUpV+8XFdaLJXzpTWJ7D3pSqFMZvPSXCbyzcXp42dS+AAmB22N SuRGefny8NFvL+qxrwUaGz+uEzkPoR53Oj6bqwr8E1srg3eFdRUEPLrLTu2UVyZAwECV7vS73YNO BaWRh+jKLGf11JGUnS2nTpR5Ike9fncghYEKw56rDEFcaiUGstPqRRNAHBObLXwLBn4GTO5ghRn+ A4cw9pXDVHoY057MMZo6cs6u5gpyT39j3A4D3GI1CJWw1HMRNjWizAOSdYUAQBcSk1gnst+aRV20 36XqMWWRrl7bHE2hCRapgPG6cNW+qZAfWxQC4w9HT5FqKTaJPBgNhr1RlwDBWK2DyAhfbzA4IIUM NYZPD/pRoROBkGbtfHil7N6gBDlKpMNKcqKwnPhAnO5CUDhjT0ut92WAc9RmXzdilcjno/6IAUdk 7Lkqg3JCl1Uin3XpE0mlVvnd5KwSoNRRxgS1Yc6LApPHrPeFRazR/MX2C+tjm28oQIq/2FNxKv// IOA6wELNrbuSYuUAZ8L/3YBTUug/DY7C895wiB0T+MANJoV7eJM+vDFNdWI1zxWYDL0mEsckiicB T9R8tqohTMyszkhx23YX67fg6rZxArbsmZ3NoVbf65+oy+0UaSAn2odZ2ODW2JMS9rXUPWYcxrkq zpFnGvXeMBafirxVILkNzJn8iui0KypwE6YLhXMWMCT/libH3coi6Etc5FoKBHkB6Qwxcr2QZRei toKJOXYLLklhTThikxQ8VRgXtGmv0YTWIC7KaWMydB8ro6lMlJivs2kWxBKouvdjwO2+0zhWxb91 eVpQDe13t0dF+IFee5s2J9pdrHnA0mZ2dS+eYhr3hzN8qdoZTHHaWIwlo8HBdUNzgyvQ5FNwQJVc NFVZ2b/KSCrmnEhlHr+ZxXXONRZpZJq/m0QaDEJPoysXuL6NnbEkxUI5ekh56WY0O60idTYSauhJ 1OWV+oOPRLou6WHlu6mztiCZ8MWlcb91mFemyOoypyXJB3pxFbISyxDW8Z1Cch9qqe3mYS6aiWm5 ashNK3Pl+SErIENAR64EbKNsDs4r7i02VvBA5+7m/d3NJ3F38/H2+vPt9Zfbd+9urz98a5T5/2yE 6e4KFMvGW2+77XgBHn4FAAD//wMAUEsDBBQABgAIAAAAIQB5lT0W1gAAAP0AAAAPAAAAZHJzL2Rv d25yZXYueG1sRI/BasMwEETvhf6D2EIvpZHtUlPcKCEEQnOsHX/A1lrbSizJSEps/31ED+1xmOEN b72d9cBu5LyyRkC6SoCRaaxUphNQnw6vH8B8QCNxsIYELORhu3l8WGMh7WRKulWhYxFifIEC+hDG gnPf9KTRr+xIJnatdRpDjK7j0uEU4XrgWZLkXKMy8aHHkfY9NZfqqgW8ZEN+OqTT97lGVVZLTX6Z SYjnp3n3CSzQHP7HV5u3aP/KX9RRCnhPs+QNWPu1/DglS/SBnIDoF22jKfDNHQAA//8DAFBLAQIt ABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhALmIOWSdAwAAwAgAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFw ZXhtbC54bWxQSwECLQAUAAYACAAAACEAeZU9FtYAAAD9AAAADwAAAAAAAAAAAAAAAADzBQAAZHJz L2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAPYGAAAAAAAAEPAIAAAAFBAgAWAGQBEPABHwEAAA AAAAwwsIAAAAAgAAAAcB/78PAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAIAAKAAAA AP8HAAEAAAAAAAIADgAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA1AHQAvADEAUP AATwPgkAABIACvAIAAAABAQAAAAKAACDAAvwSAAAAH8AAQDvAYAAWIRrIL8AAAAGAL8BAQARAP8B AQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANAAAABMAIvFKCAAAqcNE CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7D MBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+W lVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5E sO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98Ou OJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92 K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJl bHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZ sniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo 1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gq BvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQDM 94FV3wMAAIcMAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWS24jNxDdB8gdCO5n9BnJYwvTHthCPBlA MQRLQZYG1c22OmKTHZKtj5ee8wQJkADZ+DY+gK+QV2TrM0kQJFE2A4wWdlEssl7Vq1fUm7frUrGl tK4wOuGdl23OpE5NVui7hH87vXpxypnzQmdCGS0TvpGOvz3/8os31cBVDIe1G1QJn3tfDVotl85l KdxLU0mNvdzYUngs7V2rstJJ7YVHoFK1uu32SasUhebnuEovJ9XYkpVeL8eWFVnC+51uu8eZFiXC 3sgUIO6UZD3eavziEQEcI5MuXANG/BMwmRUrZPgRDqbNO4tUOohphnNEkxfWmtVciszR14jbCgC3 WDWgEpZqzvymAsrcW1TrPuE/1MJ6iUWRrRP+qjka/XHHPl2HtNls9Y3JcFzU3qAcYrDObXlsOnSP yXNG8TvdHurN2SbhJ/1XvU6/TYjEQK49S+HQPT3rn5BDCo/e65NudGhFJORZWeffSXM0KkYXJdyC zpCpWI6cp8LuQ1A4ba4KpY4tQchR6WOvYauEn/W7/QA4Igs3lwUoZqooE37apk8sKvXLVzoLLl4U KtpIUOlQ8zxH8sj6WFhUNRJh7EG/vjTZhgLM8B9NFaX539WAmQCi5sbec7ayAsJw1NWSM/VeQw9n nV4PHePDotd/3cXCHu7MDnd0XQ6NCuISOsWtCfecRXPosaLmM2Ul/EhPqpQct203XX8nbNU0jkfL XpvJXFTyr/on+oZ2imWgS5TzE7/B6DiyJOGupeqQZIW6w7hMoXf6NpP5Db4k5Xd6pKPZdl4gejwR MG2RhNT+DzgEpRR2FOoH4yYYCBn+FzrDxA3mHi8D2KmYTYA1UEi0+egvxUhf2kVgKTfaX4QkZ8IR 6RjcutnGERqPGKDjWqcIEMlSxByl5qp0nHq2FET4ThlBAXuPS5n/0TcICG44v9+9yP3f+DW7s3qo 7HQdNDerJ/c78wpp7BbXeMEaWc4gwGBG6khLmEAkJTGIf1DZRV0Wpfm+iEVFxgkv/Iv30zjjD5hm 0aVOuEYIejBtscBA12YSLM4W0tLzGqZwSmJqHKnVUU5ND6Uq7uXXYUklVwU9t2FvbI3Jg50V1mNE t0PXxXmyG0i7CeOMKjKan6Fu9CJLVCfS4dfxHUORD73kdiiFmtQj3dSspmsaO3RAeOhykQLahS2E gmrnwjoZuiwcluLA5/nxx+fHX9jz489PD78+Pfz29OHD08NPfz6Uun99COnayJc/Z/FDHKJZaOdT 4ZG50g+VFGiOz6RG6rak3rLbW/YJUkqt91maWxbZxxRCmxVorgbb3yvhJ8z57wAAAP//AwBQSwME FAAGAAgAAAAhAMvrcHXXAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8FqwzAQRO+F/IPYQC8m kW3aEJwooRRCe6wdk/PG2thqLclIamz/fUUP7XGY4Q1vf5x0z+7kvLJGQLZOgZFprFSmFVCfT6st MB/QSOytIQEzeTgeFg97LKQdTUn3KrQsQowvUEAXwlBw7puONPq1HcjE7madxhCja7l0OEa47nme phuuUZn40OFArx01X9W3FpDk/eZ8ysaPzxpVWc01+XkiIR6X08sOWKAp/I/HJNhL8lf+ot6lgOcs T5+A3d7mq1OyRB/ICYh+0TaaAj/8AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3T AAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAMz3gVXf AwAAhwwAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA y+twddcAAAD9AAAADwAAAAAAAAAAAAAAAAA1BgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA 9QAAADkHAAAAAAAAEPAIAAAAFBCwB9AOQBEPABHwEAAAAAAAwwsIAAAAAwAAAAkC/78PAA3wXAAA AAAAnw8EAAAABAAAAAAAqA8OAAAASUVURjg3IGkycnMgV0cAAKEPHgAAAA8AAAAAACAICgAAAAD/ AQAHAA8AAAABAAIAAQAOAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8HgJAAASAArwCAAAAAUEAAAA CgAAgwAL8EgAAAB/AAEA7wGAAJiiayC/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAA AgBSAGUAYwB0AGEAbgBnAGwAZQAgADUAAAATACLxdAgAAKnDbggAAFBLAwQUAAYACAAAACEAMjy9 PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE 5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw 1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7 +Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q 8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBL AwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGU EF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5K CkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7P gG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/ xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEAlxsw4wgEAAAcDAAAEAAAAGRycy9z aGFwZXhtbC54bWzsVs1uGzcQvhfoOxC8K/qXJSHrQFasNIBiCJaKHgtql2ttxSW3JFc/Lnpxnqdo gBToxW/jB/ArdGa4stUfFG0VoJf4IA/F4fCb+eYb6uWrXa7YRlqXGR3x5osGZ1LHJsn0TcS/Xkxq fc6cFzoRymgZ8b10/NX5l1+8LIauYHBYu2ER8ZX3xbBed/FK5sK9MIXUsJcamwsPS3tTL6x0Unvh 4aJc1VuNRq+ei0zzcwilN/NiZtGKrzYzy7Ik4t1mq9HlTIscrr2WMYC4UZJ1eb3yC0cE4JiaeO0q MOKfgEms2EKGv8PBtHljIZUm3GnGK7hNjqw125UUicOv4d46ATxg1QAVsRQr5vcFoHQquSpzKNht xL8vhfXScshlF/FOdTocgTDPGTvInC2370wCEUTpDVREDHepzU/NCOOYNGVwf6/bbUPJOduj3e40 uw1EJIZy51kMDq1mu91Dhxg8Ome9VnCoByToWVjn30hzMiqGgSJugVHKVGymzmNtn6/A67SZZEqd WgLKUelTw7BtxAfdVpcAB2QUOc+AYqayPOL9Bv6FomLLXOqEXLzIVLAhQaWp5mkKyUPWp8LCqqEO Qxv63YVJ9njBEv5DUwV1/ndBwFgAolbG3nK2tQK04bCrJWfqrQZJDJqdDnSMp0Wne9aChT3eWR7v 6DIfG0X6EjqGqBH3nAVz7GGFzWfyQvipnhcxOh7abrH7RtiiahwPLXtl5itRyL/qn+BL7RTKgEGU 83O/h+lxYkko1kY1UbJC3cDEtIQhkek1fIW6b3ZCFyDbwZOwHBBQSp8CBkLIhZ1S3cC4JgOupP+Z TmDYknnAyQDkQizngJGIQ7J88JZiqi/smrhJjfYjSm0pHFINE1tX23AE5yJMzlmpYwgfKFLIFybm ingWe7YRSPOTHqjvnz0uZPpHX5INuMH5591R6v/Gr9pdlmNlFztS2rKc3z6ZE0jjaXEFT1clxiXI jsxAGSoI5g4KSAxTldDL88N41D67PGv1aheT/rjW73Yatf5lZ1Ib9EetSbs5aL8evP4RGr8a+hnU GsY+hrDAyrrMs9x8lwVCoF4Rz3zt7SK8C9QfbBlYos8y4hoA4jtrszU8AtrMyeJsLS2+yjS5YxRg 5YjyADI0vq8qu5Vf0RIJUxm+0rQ3s8akaCOwMHmeRhdxQuU1Kktw0tICn28JFQ0U+l149ICYYy95 GF9Ux3KqqzqXGKayqWuoQKmIAdDIZkKBvlfCOkl9SYelOPJ5vP/p8f4je7z/8HD3y8Pdrw/v3z/c /fznQ7H714cgXWAGU/wsG6zCJ5WNP/8WRQRqhU/QEF4gdTITVuBQ/CwHUB8O0aOu/f/l8ExQmIDw WQwPvyDoR8X5bwAAAP//AwBQSwMEFAAGAAgAAAAhADFIUxnYAAAA/QAAAA8AAABkcnMvZG93bnJl di54bWxEj1FLwzAUhd8F/0O4gi/ikhY2pFs2RBjKfLFdfb82d21mk5Qkru2/N/jgHg/n8B2+zW4y PbuQD9pZCdlCACPbOKVtK6E+7h+fgIWIVmHvLEmYKcBue3uzwUK50ZZ0qWLLEsSGAiV0MQ4F56Hp yGBYuIFs6k7OG4wp+pYrj2OCm57nQqy4QW3TQ4cDvXTUfFc/RsJD3q+O+2z8ONeoy2quKcwTSXl/ Nz2vgUWa4nXcHj7F++G//EO9KQnLLBdLYKfX+ctrVWKI5CUkv2SbTIFvfwEAAP//AwBQSwECLQAU AAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCXGzDjCAQAABwMAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4 bWwueG1sUEsBAi0AFAAGAAgAAAAhADFIUxnYAAAA/QAAAA8AAAAAAAAAAAAAAAAAXgYAAGRycy9k b3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAABjBwAAAAAAABDwCAAAABQQIBBgFUARDwAR8BAAAAAA AMMLCAAAAAQAAAAIAv+/DwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAA AAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACm DwwAAADwAAAA1AHQAvADEAUPAATwPAAAABIACvAIAAAAAQQAAAAMAABjAAvwJAAAAIEBAAAACIMB BQAACL8BEAAQAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAz M5kAAJmZAJnMAAAPAIgTzgAAAA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkA AAAAACQEAQAAAAoPAIoTlQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixN1AAAAAADrLggA AABKyccB4Ix4vwAAHRAEAAAAAAAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAAAAAD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAO BMEOAABQSwMEFAAGAAgAAAAhAJvocE/8AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHL asMwEEX3hf6D0LbYcroopdjOoo9dH4v0AwZ5bIvYIyFNQvL3HTsulBIChW4E0sy998yoXB/GQe0x Juep0qu80ArJ+sZRV+nPzUt2r1VioAYGT1jpIya9rq+vys0xYFKiplTpnjk8GJNsjyOk3AckqbQ+ jsByjZ0JYLfQobktijtjPTESZzx56Lp8whZ2A6vngzyfSESu1eOpb4qqNIQwOAssoGaqmrO6iEO6 INxT84suW8hyUc7mqXch3SwJ77Ka6BpUHxD5DUbhMCxD4s/zFUhGi/ll5jPRvm2dxcbb3SjryGfj xexPAKv/if7ONPPf1l8AAAD//wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMv LnJlbHOEj89qwzAMh++FvYPRfVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6u i/nhlOcgFpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xS rkJk0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnk YqGoL+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0 aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpB x6DSn9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9 I9WQha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAh AEmym+dMCQAAejkAABYAAAB0aGVtZS90aGVtZS90aGVtZTEueG1s7Ftbj6PGEn6PdP4D4n0zXAyG 0XojrjoPJ0q0s1GeGRvbZDFYwN7+far6Ztrgxp5B2RytbWkHN0V1dVV9delm3/7y9VBqn/OmLepq pZs/G7qWV+t6U1S7lf7Hh/SNp2ttl1WbrKyrfKV/y1v9l3f/+elt9tjt80OuwfNV+5it9H3XHR8f Hto1DGftz/Uxr+Detm4OWQc/m93Dpsm+AN9D+WAZhvtwyIpK16rsAGyLvNu+cX39HeeblMC86loc WJfNE3LNZWLNJOSbjyYStc3uOSob7XNWrnSDfPSHd28fskdGUHZDupR8GB0j2Hy0pvgRgrIb0nkG fgU/QpCt17CQ4dxhmBiJzWh7RPRyyNuGj+9L9D3+9kBmaW2UKSGil4sBvaSzHhG9dAb0cZDESSrJ Q4govTugt2Ir9gKJnhDty6L6OKA2DB8+jFqQbOvyv6Pkvh9FBlf8iQqsL5wHp9jWVTfmSjrePGR/ 1U0KFPijzLqi0rpvx3ybrcFBg6bIShQne8yz3jgdWrdnQzCxxO5QVLPyPrGDmU6rIms8yEv8bbst 1jlZ4bYoy6fuW5n/ryWLbOuy2KQwiM8R4OYCQsc9XDL9S3S7JiPPaE3d/Vl0+6d9dgQFUTDuWsZ6 12rHugUkkolHeeOkoOSOQtZB/6PabLPu13pDh+0+kgUbgusdCQ58IhsZXDuZvXzdZCaV6qLa5KWZ RDTiO9LSxJLBhsOlwaDQJvi8lmFENl0InSi71q6zMt+g3mmU42bBqfn1zCZiq6YL2WebnJpIGu6Z ziS24y5EAji41IjpbtOm0BoobVoI4hY8MLxYyZwBVyxZxDmayqqPrbLSvqx037EcXVtnx5W+hZAC l4cjGK2tdrqWlTtIueuuoV47iUXibacV++NeZRp8fOBVEoyPTdvFWbunNiS3mKnKCmei8lvOAp1t ngVQR32BFLYHLvLdpAA9yqbNt9t83fWN3RtB3dGfLBLWn7q8edpvvmjP5afmfQbmB53iejZF2610 Amj80ax01Da5JcdWFtdGKhycLSuP+4xFSw+fZnqm5MRVhQzkV088WNuo7GRxty8FET/XUvpu/IMt BdNBXuX2Bi2whgK5yTTE60qvm25fQxQ67ot12kCtQmIHeIsG0QWzrQZlOvnb5J/xL/UFygO5lcVu 370vdlpTQDrp9k2e/w5hiXjfBDOTpR7KkjMiHtUTtz1SsZ/zz3n5AWOgizFY1/bg6iSaMPckdOf+ J/9mCHreYY3Sx5sUQ0RUpxj4pwsXCmZYFFitl/0mEg8md1oh0efJ4zxH9heCN05V0oKjQkp+vs9g /0IRrknAvVxLI9ZgxZbDhQMrCqMQ/8BSDQZFPXPMur2G/0D+K5p1eSpPP9TvIbZq0MMhM3Ab8Oo3 GNXgEgMkvXqGuocOUmdCVnQGVpyi1niynrkKEvOeKRsl43gbrv5k7xuVLYooeToJi8PpXq5spmFJ 13TsoqphsnOIwtCW9yHEMGSzoN/U189/gaFjaK8+lbTNb4/wi+Dg+HtDvOu53nxjl2VLEy71Ouxh kLKs3udbrdh85f2H0ASFEO1FeYlMqPExrNzEg/ZY0yA/yOjxUZotxcPW9MPiCTIzhGzxMGkKxxjA TgQL3NjaAT1RYUtXDaoVmiqr16jsCuHHVTbaZ12rMtooKg31ApV1X9UqY5oC5Q0dL//aNRm0Jk8k /rKkIw+i7dac4r4NxTdmqM0t1A69vG9DRSIJXN6GAk/6NTtqzztzpSPWNfDelQ77lDqMWThm4Rhc wWYkNIp0B3Glc4ixEbjPDMBpbD5i85EFH1nwEYePQGNKH3f5iAtVGm6vwWYu/tE1vgToXtnOG4tL Q3QMRy7hhYadf9O2re/ily2N7esyXaNrS1vLaRinzg3btmnq+y7nzcz1PfGSxkkUyvIrt22TpRc4 EdMN8xeUX+zJStqJIhsKFkYtSLjzDJSJqhHkJyqI0sJ58JkfGy+0QPk34eWWYw7cmU/lYwJyFtKD wpkHDei/a36JgsQ6k1+Jl9AP/WR5LV7wUCfi6JrGS5C6SyHMHS/jx4ILUlK/Bi9wruWmvJ6c4Vjw pvzSP5LsJaFLePHiyBUu0SOil8N6LInSIJX9kxBR+tcfC44cOyrxskxD+3q8wLmxewNeDCOAdp2B 8Y6Xcbw4r8YL2jzmPcEMeFmSDzPbVD2Gk8v+rMwvGG+FB12BF2Sf8LX1QDUrXgIpXyjxYsWYYSR6 xTF6mjpwHsSop/MLFqt3vMCbJqzqpDsCZ/2+q8CLEzge0zZLQAwOUo2DPiVithIvvddJ2HspY6+d IDfxssQEXiCCLlxL8h8lXtzYTSMZX8p6LAgiI+IedwVe4gC/kjwkCdFHCRQk3QVB6IWyPEq8uJa7 CBcSfwVeDKNnmWm8IPmNeCEdPen3wfCs3wdXYf0+GI935bAjQHUA9+jF/2m/v7yIFycyT+qbAS9k a577ngIvcRpbPu+BJ/AidbTMIBgdmEkGLW2YLH2Xy9AjopfDeiwyAvhI/qmsx27FS2IBvGT+SrwE kRs78n6FAi9S5JnGS2wHlsmT13X12I+HF+8iXgzDtsVe0gx4wRMrkTcUeMGOvJevevF/+FojSnhW Xynzi2GEp3OzK/CCaIlkf54VL0EceomcH5V4AQ2eYhiVX4EX1I3Q5DReoPRcGiYLDne8jPcv9K1h BgepVkBf7Pk38cPX1WOIGGYOBV4SOwl7+wdKvCCmhYzUf5R4WbhesAilfNHjP8wviJez+D8vXoIg PsOjEi92uowXPPfOjhcjgbPqO15yVf9i0uPbMcBIjfcMCcb13NCJpwETm7EZcaeeKMh8wzc8OUAr AeMZfhLwpuyKBAPtdRDKBdCsgIlc+PKYTuVRAmZpe6kvy69IMGkaRaJEmE4wiR9HYjfhnmDGE4x5 +T+a2BDqxenYHIBxpYxFIjvDg5TZsB4TdcQEYFzD8ZccXFdkGBDBFbyvAYwXemcZYFbAhBBDQvkE SQkYJ3Ki63eUpfOpacCg2kW6vgPmAmAuH/HD/wIyTEdkhFeXZI5lJxaP1oqSLE4jw+OZaAIwXrQM l7yKuAIwXuqkluygypIstIM04Id+lP+sgIkALqEMeCVgPNNxLLmlUmSYKArhlVVmwWnAeBGkX07+ IwEGXmKQ34khL5bBKHkV8t3fAAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRo ZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbd iNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2Sw YIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQ e9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAG AAgAAAAhAJvocE/8AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAtAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAWAgAAdGhlbWUvdGhlbWUv dGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQBJspvnTAkAAHo5AAAWAAAAAAAAAAAAAAAA ANMCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAAAAAAAAAAAAAAAUwwAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BL BQYAAAAABQAFAF0BAABODQAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9 IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2No ZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4 MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFj Y2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2Vu dDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+ AAANKwQAAAAXxffIAAALKxMEAABQSwMEFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAABbQ29udGVu dF9UeXBlc10ueG1sfJDNasMwEITvhb6D0LVYcnsopcTOoT/QS9tD+gCLtLZF9YdWCcnbd+2kFErI adGuZuZjVut98GKHhVyKnbxVrRQYTbIujp382rw2D1JQhWjBp4idPCDJdX99tdocMpJgdaROTrXm R63JTBiAVMoY+TKkEqDys4w6g/mGEfVd295rk2LFWJs6e8h+9YwDbH0VL3teH0lYLsXT8d8c1UnI 2TsDlUH1fNVndQU9XRDuov1H15zIFCsXc5pcpptTwgdXU5xF8QmlvkNgDm0L6eoCN/QWh6Quk54J TMPgDNpktoFLULkg8Vyyg1d/zr8Meqm6/wEAAP//AwBQSwMEFAAGAAgAAAAhABdLaHu6AAAAKAEA AAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZuUz2ISFMvIvQq9QNCsm2DzSZko+jfm2MFwePs MG92mtPLz+KJiV0gBduqBoFkgnU0Krj1l80BBGdNVs+BUMEbGU7tetVccda5hHhykUWhECuYco5H KdlM6DVXISIVZwjJ61xkGmXU5q5HlLu63su0ZED7xRSdVZA6uwXRv2Np/s8Ow+AMnoN5eKT8o0Jm 58uwjoZQqDqNmBXYxIt7Vf4F2Tbya1/7AQAA//8DAFBLAwQUAAYACAAAACEAJUZEQQcBAADKAQAA EgAAAGRycy90aW1pbmdJbmZvLnhtbIyRQUvEMBCF74L/IeRu04qIlLZ7WTx5kvoDQjLdDTQzIZl1 3X/vtFsF8bKnmZC8x/deut1XnNUn5BIIe91UtVaAjnzAQ68/xteHF60KW/R2JoReX6Do3XB/16WW Q5RXSgywtLbXR+bUGlPcEaItFSVAuZsoR8tyzAfjsz2LJM7msa6fTbQB9abPt+hpmoKDPblTBOSr SYbZssCXY0jlxy3d4pYyFLFZ1X+QhiUcvhVelmTzMtyIKnhpSCt/EtiAHqaAgUEr8WGbudcI0qRW SB7GS5K2OL4T8S9V8/SPKwaXqdDElaNorgFNojPkRGHN2NTXoszQmQ1H5sa3bOs3DN8AAAD//wMA UEsBAi0AFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5 cGVzXS54bWxQSwECLQAUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAAAAAAAAAAAAAAApAQAAX3Jl bHMvLnJlbHNQSwECLQAUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAAAAAAAAAAAAAAAMAgAAZHJz L3RpbWluZ0luZm8ueG1sUEsFBgAAAAADAAMAugAAAEMDAAAAAAAAHAQEAAAAAQAAACAAug8OAAAA aQBlAHQAZgAtADYAOQAPAPgDuEQAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAACAP+/YADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYA AAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACv Z/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAA AAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/H AAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAA AACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAA M5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA 8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAV AN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAA AABAAgAAAAACAAAA///vAAAAAAABAAAA//8sAAAAAAMAABAAow+AAAAABQD//T8AAQAiIAAAZAAA AAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAACABQAAEyDUASAB AAAiAP//FACABQAAIiDQAkACAAACABIAgAUAABMg8ANgAwAAAgAQAIAFAAC7ABAFgAQAAAIADgAg AKMPcAAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEA AAD//wwAAAAAAQAAAAUAACABIAEAACAA//8ABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAACABAAAAAAcAAAD//+8A AAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA AIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAA AAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAA AAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABQAAQAAAAAAAAACABIAAgAAAAAAAAACABAAAwAAAAAA AAACAA4ABAAAAAAAAAACAAwAgACjDz4AAAAFAAAAAAAAAAAAAgASAAEAAAAAAAAAAgAQAAIAAAAA AAAAAgAOAAMAAAAAAAAAAgAMAAQAAAAAAAAAAgAKAAAAIwQYBwAAUEsDBBQABgAIAAAAIQCbEwW7 +gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L 9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrvndhhJhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBW HpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCA rSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJc PsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQSwME FAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9 iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK 3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMg dqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQ SwMEFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVy MS54bWzsWktu2zAU3BfoHQRuA8eW/JFsWA6SFFllETTJAWiZstVQlEAxadxVkRyhN+i+aIEW6KJZ 9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9N8OX7sGtj7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRiAS1i kAwgDgiywRhF4KD3+lU37LDbczbGKNL4FCTqQBuMGAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1QOF7 PrWPq0at1qr60CNAjadFxgeu6znoTeBc+4iweBKKMGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe25zGM 5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe8JQc0Sv57AaEHcoufRghoI0gGfL9nl0Th4kOYqoodI6Q q57OHKbdQDlRtdetzrUeumxFP9U6QO5bvrLogw0ajZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K9xIg Eo2NQ+RChzO957+rYCZ6wg6CqYbHhy+PD9+1x4dvk7sfk7ufk/v7yd1XoDkjSCMktykHOdF/D+L7 j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g7+GxDSp6rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh5AhG FDnNkpwNI0cwoshpCXJ8SE95am2aXLKAPAEwl/TF2C3J8UWTzEJeFsAojMwZRm1dCpASIylYBDAK I2uGkV439VZ5kBKBJ5BRILVTIFmGZZUgJSAJZPhz1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5Jj/E /oULy6d1Lzw08tet62D618fcO0gDYYM/Hz/HpiPla4xivkZPVrDa15DN8zUxayZnrZlmzbCapvhh G1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V3bDUUcnazXlHE9Oi64262MrsazIMKxXDt+hr2io25i2M YoMjL5XYNLZtExuLX4lUA1vFy7x7iXkxak1ThOlt/Ep+/1oIXvpLppy1gle+bzGaekPGqn9/LoV9 zBNm+xzkxezblTby3ZDRNnUpYkvki1wfr3Xm8z1WLHYLhaLyzK++Y14qlfKNW92yWgWTc4n8mshP 3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgbIFK5PJ8pX9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1oMnK 0awGlq156TKUq1WIGlUcE68QFfVGcVaeW/vs+aSCYJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1iaBIQ pnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA5XsIPXvvt8sALVHz8uKhDNE8Li8R3WajLgVIGaOXaGOO jrTpJUBLJGyraWYv93Y2i02VZlpcijKE+s+v3l8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6 AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAAavciugDAAA/JgAAIQAAAAAAAAAAAAAAAAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1h c3RlcjEueG1sUEsFBgAAAAADAAMAyQAAADkGAAAAAA8ADAQ5HQAADwAC8DEdAADwAQjwCAAAAAUA AAAFfAAADwAD8NUcAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAHwA AAUAAAAPAATwLgEAABIACvAIAAAAAnwAAAAKAACDAAvwSAAAAH8AAQDvAYAAyIt8H78AAAAGAL8B AQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAI AAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAAIA/78PAA3wngAAAAAAnw8EAAAAAQAAAAAA qA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJk IGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIA DQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8NYIAAASAArwCAAAAAN8AAAACgAAgwAL 8FYAAAB/AAEA7wGAALgbcB+/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEA dABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAABMAIvHYBwAAqcPSBwAAUEsDBBQABgAI AAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4s EEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/F jVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2Wk XOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44N T/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcA AAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA 38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefj YODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvG gfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05pa oB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCqBaF5bwMAAPUHAAAQ AAAAZHJzL3NoYXBleG1sLnhtbKxVzW4TMRC+I/EOlu+QpE1LidiitlBAClVEijjP7nq7S7z2YnvT pMfyPAgkkLj0bfoAfQVmxpum/AgBpYdmvJ7xfPN94/Gjx4tai7lyvrImkYP7fSmUyWxemZNEvj4+ vLcjhQ9gctDWqEQulZePd+/eedSMfCMw2PhRk8gyhGbU6/msVDX4+7ZRBvcK62oIuHQnvcYpr0yA gIlq3dvo97d7NVRG7uJRZj5tJo6s7Gg+caLKE7kthYEaUz6BoMREQ6ZKq3PlxKbsda4xChDK2GYz 3+GBP8GTOzjFIr+DIox95rCaASXoMZgVLoOwKGlTirBsEFUekJgzzAS6kAh4kciNLiz6Yvy6LI/l ifT0pc0xFNpgsWwYLQpX3xYznWOLQmD+4dYDpFWKJZK3tTkcbPUJEIzUIoiM8A02N7fJIUOP4YPt jejQi0DIs3E+PFP21qAEHZRIp7LAhcJ87ANxuk5B6bT5H9XXVcCm0FWdyJ0+/cWqSwX5U5MzAwEq HW1EoA2LS5KQomGxb/MlwUnxF2WKTf3vTYS3CWsvrTuT4tQB9pN/14JTUugXxify4WA4RBECL1gz KdzNnfTmjmnrA6upJwWYDE9NJHZeNA8CrkhPWzcQxmbaZOS4UvJ48QZc02kRsAuO7LSERv1KkujL CkUaWB8fpmGp1W0p4bPmesCMwyhXxauJi+2gV59JmC4d4/8fOenS1eDGTBIar9jAlPxbmRwHEpug T3D6aSkQ2jGkU7zXrBJy60L0VjA2+27GQhTWhD0OScGTrjjVTLeNISWYExwtk9ZkeHzUQ5M4VJhv skkWxBxI0+t25bZce+yr4kdf7mp0w/j17l4RfuPX7abtgXbHC74IaTs9uzYPsYzrxRGO9+6upPGy fi9Up50y+QQcoH5i1tZVbd9WkVSsOZHK3Hs9jXNxMKRJk0am+X+bSINJ6D1x1QznoLFTtqSYKUev D0+vjG5M50j9jKcYekd0daae85JI1xW9Rrw3cdYWZBMVdLlhZOxhpXXXYfzFW13l9JH5omdKIStR hrCIAx/JvemligLn14qLdmw6rlo6prNZeX4RCnyfErnnKsA2ykpwXnFvMacKbvhcXXy4uvgsri4+ XZ5/uTz/evn+/eX5x5+DMv/XQdgfa4HiuOVZt5px+Cb5ZvcbAAAA//8DAFBLAwQUAAYACAAAACEA tL6VANUAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP3UrDQBCF7wXfYRnBO7upP8HGbksRREG8 aO0DjNnJD2Zn091Jmry9ixd6eTiH7/Ctt5Pr1Eghtp4NLBcZKOLS25ZrA8fPl5tHUFGQLXaeycBM Ebaby4s1FtafeU/jQWqVIBwLNNCI9IXWsWzIYVz4njh1lQ8OJcVQaxvwnOCu07dZlmuHLaeHBnt6 bqj8PgwunSz1ML5Pu7vT/cPHcT6tVroOYsz11bR7AiU0yf948HmF/q/8Rb1ZAzmo6nX+Cq3dYxQK BpJbMk2WoDc/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAA AAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAKoFoXlvAwAA9QcAABAAAAAA AAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAtL6VANUAAAD5AAAA DwAAAAAAAAAAAAAAAADFBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAMcGAAAAAAAA EPAIAAAAFBAgAWAGQBEPABHwEAAAAAAAwwsIAAAAAgAAAAcB/78PAA3wWAAAAAAAnw8EAAAABAAA AAAAoQ8aAAAAAQAAAAAAIAAKAAAAAP8HAAEAAAAAAAIADgAAAKoPDgAAAAEAAAAHAAAAAAAJBAAA AACmDwwAAADwAAAA1AHQAvADEAUPAATwIgkAABIACvAIAAAABHwAAAAKAACDAAvwWgAAAH8AAQDv AYAAmM5hH78AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAA UABsAGEAYwBlAGgAbwBsAGQAZQByACAANAAAABMAIvEcCAAAqcMWCAAAUEsDBBQABgAIAAAAIQAy PL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCw BATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyM gbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzer Fjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtU z5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMA UEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mS oZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6 DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90 /s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+a HX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQDlUomysgMAAK0LAAAQAAAAZHJz L3NoYXBleG1sLnhtbOxWzW4bNxC+F+g7ELwn+on8EyHrwDbqNIBiCJGKHo3RLtfLiktuSa4s+eg8 T9ECDZCL38YP4FfozHDln7Yo2jqHFsgepOFyhvPzfTPcV6/XtREr5YN2NpOD530plM1doe15Jr+b nzzblyJEsAUYZ1UmNyrI1wdff/WqGYdGoLEN4yaTVYzNuNcLeaVqCM9doyzulc7XEHHpz3uNV0HZ CBEd1aY37Pd3ezVoKw/wKLuaNVNPUn66mnqhi0zuSWGhRpcnzkXlxdRAripnCpRHstcpJzvAYCYu X4YuIvg7ERUeLjDNR8EI6954zGdADnoczjYyi4GR06YScdNgXGX0WJvLTP7YgscIJYa9zuSLzjTp 4xn3yQVMUiwu3rkCzaGNDpOH8br09VPjpnNcWQryPxiOsLpSbDK5u/NiNNjpU0QwVusoclQY7r/c 2SWFHDVGe7vDpNBLkZBm40N8o9yToxJ0UCa9yiNnCqtJiFTYexfkztjPkX6tiSVG15nc79OTsq4U FN/YgisQQZskYwTGMsKECcEa10eu2FA4C/xHnBK3/z2TsKkw98r5SykuPCCpAhFFSWHe2pDJl4PR CEGIvBjt7A1x4R/uLB7u2LY+doaIKcDmeGom41Y8jrgiPF3dQJzYWZOT4hbJ+fp78E2HRUQWnLpZ BY36M0iSLiOUysD4hDiLG6OeWhI+a2UGXHEYF6p8P/WJDmb7moDp3HH8n8MndV0NfsJFQuE9C+iS /7UtcC6xCOYch2BOfY3BzWExw+5mnAibmPQVTOyRXzIUpbPxkI0WEAhZHG+220aTCuw5Tphpa3N0 kBAxBA+lFpp8mkexAkL1jrBMzHuNI1X+Xpd5jWpof797WMa/0Ot2F+2x8fM1t8KinV3eiSeYxt3i FOd81y2L1K6PoerQw6aBscfKLtta1+4HnYqKGWdSx2dv52k2DkY0aRZcraTSZtKiC7pWvF7iILRu xpIUS+XpEuLplVPHdIrEZzzF0nVi9KX6lpdUcqPpUuK9qXeuZLnQPuJo6zPBqc1hbN2JNqbjGr8J zuiCXnLd6N5SWJ0ER1yn+Y9FfqilyhIn2bYm7cR2NWvpmE5mBvAFUeJ1lclDr8Fga1bgg2KWcW0V PNC5vf7p9vpXcXv9y83Vx5urTzcfPtxc/fxHozz8YyPkCWJEKcYDkR6avkgW2mEI+ee/jaMIdTw2 CpAcX0BN0G1BPRNnZ+J/CCmx7ktrblEUjyHE3mz442T7UYJfkaE5+A0AAP//AwBQSwMEFAAGAAgA AAAhAKwRzYbWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV+g/WVOquOPQFpBiE +lCRqi6gfMAQD0nUeBxsE5K/76iLdnl1r87VmS9716iOQqw9GxiPMlDEhbc1lwZ2X283U1AxIVts PJOBgSIsF5cXc8ytP/OGum0qlUA45migSqnNtY5FRQ7jyLfE0h18cJgkhlLbgGeBu0bfZtmjdliz PFTY0nNFxff25ORkrE/dR7+6O94/fO6G42ymy5CMub7qV0+gEvXpfzzJXpr4+lf+otbWwATU4X3Y h9puMCYKBsRNTMUS9OIHAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAA CwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA5VKJsrIDAACtCwAA EAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCsEc2G1gAA APkAAAAPAAAAAAAAAAAAAAAAAAgGAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAACwcA AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAQAAAAAADDCwgAAAADAAAACQL/vw8ADfBcAAAAAACfDwQA AAAEAAAAAACoDw4AAABJRVRGNzMgaTJycyBXRwAAoQ8eAAAADwAAAAAAIAgKAAAAAP8BAAcADwAA AAEAAgABAA4AAACmDwwAAADwAAAA1AHQAvADEAUPAATwXwkAABIACvAIAAAABXwAAAAKAACDAAvw ZgAAAH8AAQDvAYAA2NynJb8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABp AGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAABMAIvE9CAAA qcM3CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSR QU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2g Wl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5 pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm 98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw /m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMv LnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faX MKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmg NJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHR V5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAA IQBR49A20wMAAFALAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWzW7jNhC+F+g7ELx7/Sc7qbHKwg7W 2wW8gbF20WMxkqhINUWqJOXYKXrJPk/RAi3QS94mD5BX6Awpx9m2KNomhx7WB3kozv83P3r5aldJ thXGllrFvP+ix5lQqc5KdRnzr9bzziln1oHKQGolYr4Xlr86+/yzl/XE1gyFlZ3UMS+cqyfdrk0L UYF9oWuh8C7XpgKHR3PZrY2wQjlwaKiS3UGvN+5WUCp+hqrUdlUvDVHpxXZpWJnFHA0rqNDkSpaZ YBdNlQjDlhJSUWiZIT3i3VYkSAO6tNDpxrZ+wT/xKzNwhcF+5BJT+o3BqPpkoOudOvin0D0yWhfM 7Wv0zsoMXcMkXcf8uwaME4aj/7uYR610EEE1xygtRsuSq3c6Qw3QOI1ZgMkuN9VTXSc9Os8Z2h+P RkNMM2d7oodRf9Qjj2Aido6lyDDoD4djYkiRIzoZDwJDN3hCnLWx7o3QT/aKkaKYG5E6HylsF9ZR bo8myJxUzxF+VSIGTJYV1lCPfiHqQkD2WmU+Aw5KGWj0QCoPMmFCyLrdTGd7cifBf8QpFPl/Lybs Loy90OaasysDWFeWCkVwJt8qG/Mv+lGEIDh/iEYnAzyYxzfJ4xvVVOdaUm0yUClqjbk7kOcOT4Sn rmpwC7WqU2I8ILnefQ2mbrFwWAUXelVALf4KksDrEQpp8PhYt3J7KZ6aEq9rK/s+4zDJRP5+aUI5 yMNrAqY15/1/DpvUdRWYhU8SEu89gSb9f6kyHFCeBHmJ0xAbGV1bQ7LC3vYoETIucAtYqJnZeCBy rdzUiyRgCVeccqq9RpEC1CWOmGWjUlQf8JAEDgVm63SZOrYFwvShXH1ZHjlmIv8jr69qZEP54+00 d3/D194mzbk0651vhKRZXT+Qcwzj4XCB477tlSQ068dAtdjlMvPT+vvxaHY+ms+mndlg0O+cjKKo cxq9PumcTmfRcDQezgfT+Q9Y5e3QxJGOlewrzyAqm6YqK/1tGQDBfMW8dJ236zBX+xFNqSSg5J9N zBU6SLvJlBscokqvPMXZRhjaZH7ypdRtLSP1AmpRtJNkeS2+9EcCTJa02fzd0midE01ppMEAE6Xn pZRtdfo3VuNGopc+17TyBGY0QOh2YWkgMI+5RJ7j7DvksVmoNs8NqWlpXzU+QTnuuJhPTQkSm7kA Y4WvS4+HgEc897c/3t/+wu5vf767+fXu5re7Dx/ubn76s1Bq/7UQ1hYiQyF+ahvKwrO2jTv7hpYf dis+sYfIgFDZEgzgKPzUDpiO/187HAEKXy7+s+HwuYDfd7Y++x0AAP//AwBQSwMEFAAGAAgAAAAh ABP/D9jWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQRfeV+AdrkLorDvShkmIQQqpa gVhAYT/EgxM1toNtQvL3HXXRLkd3dO49s0Vna9FSiJV3CsajDAS5wuvKGQWHr/eHVxAxodNYe0cK eoqwmA/uZphrf3M7avfJCIa4mKOCMqUmlzIWJVmMI9+Q4+zsg8XEZzBSB7wx3NZykmUv0mLluKHE hlYlFd/7q+WSsby2m275eHl63h76y3QqTUhK3Q+75RuIRF36fzbrY7ZZ/4W/qE+tgIefP/pTqPQO Y6KggN3YlC1Bzn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAA AAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAUePQNtMDAABQCwAAEAAA AAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQAT/w/Y1gAAAPkA AAAPAAAAAAAAAAAAAAAAACkGAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAALAcAAAAA AAAQ8AgAAAAUECAQYBVAEQ8AEfAQAAAAAADDCwgAAAAEAAAACAL/vw8ADfBsAAAAAACfDwQAAAAE AAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAAAAAAIAgKAAAAAP8CAAcAAgAAAAAAAgAOAAAA2A8EAAAA AAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8DwAAAASAArwCAAA AAF8AAAADAAAYwAL8CQAAACBAQAAAAiDAQUAAAi/ARAAEAD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE84AAAAPAIoTKQAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAyAAAAixMJAAAAAAAkBAEAAAAKDwCKE5UAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTdQAAAAAA6y4IAAAASsnHAeCMeL8AAB0QBAAAAAAAAAAAAAArBAAAAAAA AAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA/////xIAAAAPAD3xDQAA AEABQvEFAAAAAQkAAAAPAAIrAAAAAAAADgTFDgAAUEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMh TULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6v r8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8 n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAs Q+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAA ACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9 AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCG o3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3 YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrD IBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCyn G6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResr JgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQBNbVwlUAkAAHw5AAAWAAAAdGhlbWUvdGhlbWUvdGhl bWUxLnhtbOxbWY+jSBJ+X2n+A+K9pzgMhlK7R5yahx3NqKtH+7iibGwzjcEC+vr3E5GXSYMTuwpt z6ptS104CSIjI+KLI5N++8vXQ6l9zpu2qKuVbv5s6FperetNUe1W+p8f0jeerrVdVm2ysq7ylf4t b/Vf3v30r7fZY7fPD7kGz1ftY7bS9113fHx4aNcwnLU/18e8gnvbujlkHfxsdg+bJvsCfA/lg2UY 7sMhKypdq7IDsDX/W+Td9o3r6+8456QE9lXX4sC6bJ6Qb87IGbFmEvLNRxOJ2mb3HJWN9jkrV7pB PvrDu7cP2SMjKLshXUo+jI4RbD5aU/wIQdkN6TwDv4IfIcjWa1jIcO4wTIzEZrQ9Ino55G3Dx/cl +h5/eyCztDbKlBDRy8WAXtJZj4heOgP6OEjiJJXkIUSU3h3QW7EVe4FET4j2ZVF9HFAbhg8fRi1I tnX56yi570eRwRV/ogLrC+fBKbZ11Y25ko43D9lfdZMCBf4os66otO7bMd9ma3DRoCmyEsXJHvOs N06H1u3ZEEwssTsU1ay8T+xgptOqyBoP8hJ/326LdU5WuC3K8qn7Vub/bski27osNikM4nMEurmA 0HEPl0z/Et2uycgzWlN3/ym6/dM+OyKGyQy7lrHetdqxbgGJZHiUN04KSu4oZB30P6rNNut+qzd0 2O4jWbAhuN6R4MAnspHBtZPZy9dNZlKpLqpNXppJRCO+Iy1NLBlsOFwaDAptgs9rGcZk04XgibJr 7Tor8w3qnUY5bhacml/PbCK2arqQfbbJqYmk4Z7pTGI77kIkgINLjZjuNm0KrYHSpoUgbsEDw4uV zBlwxZJFnKOprPrYKivty0r3HcvRtXV2XOlbCClweTiC0dpqp2tZuYOku+4a6rWTWCTedlqxP+5V psHHB14lwfjYtF2ctXtqQ3KLmaqscCYqv+Us0NnmWQB11BdIYXvgIt9NCtCjbNp8u83XXd/YvRHU Hf3JImH9qcubp/3mi/ZcfmreZ2B+0CmuZ1O03UongMYfzUpHbZNbcmxlcW2kwsHZsvK4z1i09PBp pmdKTlxVyEB+9cSDtY3KThZ3+1IQ8XMtpe/GP9hSMB3kVW5v0AJrKJGbTEO8rvS66fY1RKHjvlin DdQqJHaAt2gQXTDbalCok79N/hn/Ul+gPJBbWez23ftipzUFpJNu3+T5HxCWiPdNMDNZ6qEsOSPi UT1x2yMV+zn/nJcfMAa6GIN1bQ+uTqIJc09Cd+5/8m+GoOcd1ih9vEkxRER1ioH/deFCwQyLAqv1 st9E4sHkTisk+jx5nOfI/kLwxqlKWnBUSMnP9xnsXyjCNQm4l2tpxBqs2HK4cGBFYRTiH1iqwaCo Z45Zt9fwH8h/RbMuT+Xph/o9xFYNejhkBm4DXv0GoxpcYoCkV89Q99BB6kzIis7AilPUGk/WM1dB Yt4zZaNkHG/D1Z/sfaOyRRElTydhcTjdy5XNNCzpmo5dVDVMdg5RGNryPoQYhmwX9Jv6+vkvMHQM 7dWnkrb57RF+ERwc/2iIdz3Xm2/ssmxpwqVehz0MUpbV+3yrFZuvvP8QmqAQor0oL5EJNT6GlZt4 0B5rGuQHGT0+SrOleNiaflg8QWaGkC0eJk3hGAPYiWCBG1s7oCcqbOmqQbVCU2X1GpVdIfy4ykb7 rGtVRhtFpaFeoLLuq1plTFOgvKHj5V+7JoPW5InEX5Z05EG03ZpT3Leh+MYMtbmF2qGX922oSCSB y9tQ4Em/ZUfteWeudMS6Bt670mGfUocxC8csHIMr2IyERpHuIK50DjE2AveZATiNzUdsPrLgIws+ 4vARaEzp4y4fcaFKw+012M7FP7rGlwDdK9t5Y3FpiI7hyCW80LDzT9q29V38sqWxfV2ma3RtaWs5 DePUuWHbNk193+W8mbm+J17SOIlCWX7ltm2y9AInYrph/oLyiz1ZSTtRZEPBwqgFCXeegTJRNYL8 RAVRWjgPPvNj44UWKP8kvNxyzIE786l8TEDOQnpQOPOgAf13zS9RkFhn8ivxEvqhnyyvxQse6kQc XdN4CVJ3KYS542X8WHBBSurX4AXOtdyU15MzHAvelF/6R5K9JHQJL14cucIlekT0cliPJVEapLJ/ EiJK//pjwZFjRyVelmloX48XODl2b8CLYQTQrjMw3vEyjhfn1XhBm8e8J5gBL0vyYWabqsdwctmf lfkF463woCvwguwTvrYeqGbFSyDlCyVerBgzjESvOEZPUwfOgxj1dH7BYvWOF3jThFWddEfgrN93 FXhxAsdj2mYJiMFBqnHQp0TMVuKl9zoJey9l7LUT5CZelpjAC0TQhWtJ/qPEixu7aSTjS1mPBUFk RNzjrsBLHOBXkockIfoogYKkuyAIvVCWR4kX13IX4ULir8CLYfQsM40XJL8RL6SjJ/0+GJ71++Aq rN8H4/GuHHYEqA7gHr34P+33lxfx4kTmSX0z4IVszXPfU+AlTmPL5z3wBF6kjpYZBKMDM8mgpQ2T pe9yGXpE9HJYj0VGAB/JP5X12K14SSyAl8xfiZcgcmNH3q9Q4EWKPNN4ie3AMnnyuq4e+/Hw4l3E i2HYtthLmgEveGIl8oYCL9iR9/JVL/4PX2tECc/qK2V+MYzwdG52BV4QLZHsz7PiJYhDL5HzoxIv oMFTDKPyK/CCuhGanMYLlJ5Lw2TB4Y6X8f6FvjXM4CDVCuiLPf8mfvi6egwRw8yhwEtiJ2Fv/0CJ F8S0kJH6jxIvC9cLFqGUL3r8h/kF8XIW/+fFSxDEZ3hU4sVOl/GC597Z8WIkcFZ9x0uu6l9Menw7 Bhip8Z4hwbieGzrxNGBiMzYj7tQTBZlv+IYnB2glYDzDTwLelF2RYKC9DkK5AJoVMJELXx7TqTxK wCxtL/Vl+RUJJk2jSJQI0wkm8eNI7CbcE8x4gjEv/0cTG0K9OB2bAzCulLFIZGd4kDIb1mOijpgA jGs4/pKD64oMAyK4gvc1gPFC7ywDzAqYEGJIKJ8gKQHjRE50/Y6ydD41DRhUu0jXd8BcAMzlI374 X0CG6YiM8OqSzLHsxOLRWlGSxWlkeDwTTQDGi5bhklcRVwDGS53Ukh1UWZKFdpAG/NCP8p8VMBHA JZQBrwSMZzqOJbdUigwTRSG8ssosOA0YL4L0y8l/JMDASwzyOzHkxTIYJa9CvvsbAAD//wMAUEsD BBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2Vy LnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplpu5ed yRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc0IpU +YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUFKKLG zOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAAL AAAAAAAAAAAAAAAAAC0BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAc AAAAAAAAAAAAAAAAABYCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgA AAAhAE1tXCVQCQAAfDkAABYAAAAAAAAAAAAAAAAA0wIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQ SwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAABXDAAAdGhlbWUvdGhlbWUv X3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAFINAAAAAAAADwQ6AQAA PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K PGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3 aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIg YWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNj ZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9 ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAA0rBAAAAI7XKdoAAAsrEwQAAFBLAwQUAAYA CAAAACEAMhkkzvgAAACrAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM1qwzAQhO+FvoPQtVhy eyilxM6hP9BL20P6AIu0tkX1h1YJydt37aQUSshp0a5m5mNW633wYoeFXIqdvFWtFBhNsi6Onfza vDYPUlCFaMGniJ08IMl1f3212hwykmB1pE5OteZHrclMGIBUyhj5MqQSoPKzjDqD+YYR9V3b3muT YsVYmzp7yH71jANsfRUve14fSVguxdPx3xzVScjZOwOVQfV81Wd1BT1dEO6i/UfXnMgUKxdzmlym m1PCB1dTnEXxCaW+Q2AObQvp6gI39BaHpC6TnglMw+AM2mS2gUtQuSDxXLKDV3/Ovwx6qbr/AQAA //8DAFBLAwQUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q 9m5TPYhIUy8i9Cr1A0KybYPNJmSj6N+bYwXB4+wwb3aa08vP4omJXSAF26oGgWSCdTQquPWXzQEE Z01Wz4FQwRsZTu161Vxx1rmEeHKRRaEQK5hyjkcp2UzoNVchIhVnCMnrXGQaZdTmrkeUu7rey7Rk QPvFFJ1VkDq7BdG/Y2n+zw7D4Ayeg3l4pPyjQmbny7COhlCoOo2YFdjEi3tV/gXZNvJrX/sBAAD/ /wMAUEsDBBQABgAIAAAAIQAlRkRBBwEAAMoBAAASAAAAZHJzL3RpbWluZ0luZm8ueG1sjJFBS8Qw EIXvgv8h5G7TioiUtntZPHmS+gNCMt0NNDMhmXXdf++0WwXxsqeZkLzH91663Vec1SfkEgh73VS1 VoCOfMBDrz/G14cXrQpb9HYmhF5foOjdcH/XpZZDlFdKDLC0ttdH5tQaU9wRoi0VJUC5myhHy3LM B+OzPYskzuaxrp9NtAH1ps+36GmagoM9uVME5KtJhtmywJdjSOXHLd3iljIUsVnVf5CGJRy+FV6W ZPMy3IgqeGlIK38S2IAepoCBQSvxYZu51wjSpFZIHsZLkrY4vhPxL1Xz9I8rBpep0MSVo2iuAU2i M+REYc3Y1NeizNCZDUfmxrds6zcM3wAAAP//AwBQSwECLQAUAAYACAAAACEAMhkkzvgAAACrAQAA EwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAXS2h7 ugAAACgBAAALAAAAAAAAAAAAAAAAACkBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAlRkRB BwEAAMoBAAASAAAAAAAAAAAAAAAAAAwCAABkcnMvdGltaW5nSW5mby54bWxQSwUGAAAAAAMAAwC6 AAAAQwMAAAAAEAAeBD8GAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVudF9U eXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXVaB53 7tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKDlKhH 8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5SolZ7Uq BCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL4Gf8 Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAAOAEA AAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783RguBx GObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcKhpTC QUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO59KNC 8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAI2fLskOAwAA 8ggAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWyslttu2zAMhu8H7B0E37eO nYNdo0mBdVtvesLSPoBiK4lRWRYkxUv29CN1iNOuAwqjN4ktk59I/qTsy6t9w0nHlK5bMY+S81FE mCjbqhabefT89PMsj4g2VFSUt4LNowPT0dXi65dLWWhe3dJDuzMEGEIXdB5tjZFFHOtyyxqqz1vJ BDxbt6qhBm7VJq4U/Q3shsfpaDSLG1qLyPurj/i363Vdsu9tuWuYMA6iGKcG4tfbWupAkx+hScU0 YKz365DMQUK2pjacRcSaqQ4WkmgBmZdLXhFBG1h4Qguy5HXF7CMtnxRjaCS6GyWX8lFZj/vuUZG6 QoL3jGL/wJvZWwFmcBG/cd8EEi32a9UsLmkBhSD7eQR6HfAXnGjB9oaUbrHsV8vtwzu25fbHO9Zx 2AAiOG4KUkuX0b/ppCEdV4jkmJUzpeB625YvmogW8sT0XXrlfRdgmDPi5Za4qpdGWZo3dc9tSYKL tmUNsR6LMcun+chVJE3Go0k6fV2XLMvSCRpgdZJJNho5i2PWtJBKmxvWNqC5NvNIsdKArrSg3a02 GHpvYmVykcjC7L+11QEtV/APWsNMgf+2VX9cDFybpTlwZoWCctICkoYfMOUUh42Js+clDFtjrjmj MIxeVLO45nX5QkxLWFUbcke1YYoY23gakRiUsaFZJBPVI1X01xuyD95GHaKFojpp/y/wOAi83K3c nikmBEMQFByksd6tnMYwFNCxoS0+rnUyzpKZF3uc5zM4Tl6LPQOlbTdYsbNpitauCG6GbPKu9UI9 gnpWpKAYysQ7nkDPkYaqWzt0tajg4LCXlG9ALWha2yir3T0clBZQsTWI4Lb0AM9Ke9ZkmmHoZAAQ KR447oEXycT2+AAgUjxw0gOPlR5ARIwnTk+IeZpbaQYQEeOJs56YpjnIO6yMiPHE7ISYTcZDhUGM J+Y9EXFDlUGMJ16cEGfTzM7AgDoixp4Zp23+CecSDPZnHk12SN0rFS7xxWvPHq7uqHzobE3gSwMO xGu7JOHbAgcOTHsTZIRvlcVfAAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAA OAEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAI2fLskOAwAA 8ggAACEAAAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBL BQYAAAAAAwADAMkAAABgBQAAAAAAAB0EBAAAAAEAAAAgALoPEgAAADEAXwBpAGUAdABmAC0ANgA5 AA8A+ANFRAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIA/79gAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDM MwAAmWYAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN72 8QAAAAAAlpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3 ADPMzAD/UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAH IAAAAIAAAAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM //8AM2bMAACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDl AABgAPAHIAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA//// AD4+XAD///8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8A zLQAAIyeoAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD/ /+8AAAAAAAEAAAD//ywAAAAAAwAAEACjD4AAAAAFAP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgA AABAAgAAAAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAIAFAAATINQBIAEAACIA//8UAIAFAAAi INACQAIAAAIAEgCABQAAEyDwA2ADAAACABAAgAUAALsAEAWABAAAAgAOACAAow9wAAAABQD//T8A AAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//DAAAAAABAAAA BQAAIAEgAQAAIAD//wAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAA BQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAIAEAAAAABwAAAP//7wAAAAAAAQAAAP//EgAA AAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMP UgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwAB CQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAA BQAAAAAAAAAAAAIAFAABAAAAAAAAAAIAEgACAAAAAAAAAAIAEAADAAAAAAAAAAIADgAEAAAAAAAA AAIADACAAKMPPgAAAAUAAAAAAAAAAAACABIAAQAAAAAAAAACABAAAgAAAAAAAAACAA4AAwAAAAAA AAACAAwABAAAAAAAAAACAAoAAAAjBBgHAABQSwMEFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAABb Q29udGVudF9UeXBlc10ueG1sfJDLasMwEEX3hf6D0LZYcroopdjOoo9dH4v0AwZ5bIvqhUYJyd93 7KQQSshqmMede7jNeu+d2GEmG0MrV6qWAoOJvQ1jK783b9WjFFQg9OBiwFYekOS6u71pNoeEJFgd qJVTKelJazITeiAVEwbeDDF7KNzmUScwPzCivq/rB21iKBhKVeYfsmtecICtK+J1z+MjCculeD7e zVathJScNVAYVM9bfVGX0dEV4S70/+iqE5li5fKcJpvo7uTwydFk26P4glw+wDOH7jNpcjx8Byqc 3HmzUtfBL/jHYbAG+2i2njNRKSNxXVC8U2dGf0x6ib77BQAA//8DAFBLAwQUAAYACAAAACEAjuoq +r4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I0IMX0Q9Ykm0bbJOQ jaJ/b44WBI/DMG9m6vY1T+JJka13CqqiBEFOe2PdoOB2PW32IDihMzh5RwrexNA261V9oQlTDvFo A4tMcaxgTCkcpGQ90oxc+EAuO72PM6Ys4yAD6jsOJLdluZPxmwHNgik6oyB2pgJxfYfc/J/t+95q Onr9mMmlHxWSJ2vojJwoZizGgZICE/nbWIiqyPtBNrVc/G0+AAAA//8DAFBLAwQUAAYACAAAACEA AavciugDAAA/JgAAIQAAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaS27bMBTc F+gdBG4Dx5b8kWxYDpIUWWURNMkBaJmy1VCUQDFp3FWRHKE36L5ogRbooln1KPUBcoWSFGVLtuyq RoLYsHaK+RE5Q703w5fuwa2PtRtEIy8gNtD3a0BDxAkGHhna4PLipGIBLWKQDCAOCLLBGEXgoPf6 VTfssNtzNsYo0vgUJOpAG4wYCzvVauSMkA+j/SBEhLe5AfUh43/SYXVA4Xs+tY+rRq3WqvrQI0CN p0XGB67rOehN4Fz7iLB4EoowZHz50cgLo2S2sMhsIUURn0aOziypJ7bnMYzkDntd2ME3WA/PqAbx kOPkMAo0yrANBF7wlBzRK/nsBoQdyi59GCGgjSAZ8v2eXROHiQ5iqih0jpCrns4cpt1AOVG1163O tR66bEU/1TpA7lu+suiDDRqNmnpHgL3BiYexHC74QMeYxm9itwZQ70r3EiASjY1D5EKHM73nv6tg JnrCDoKphseHL48P37XHh2+Tux+Tu5+T+/vJ3VegOSNIIyS3KQc50X8P4vuPdyOhUJiLBfBHY7fg P6QexEALPeaMTqDv4bENKnqtvYjzi5EjGFHk1EtyNowcwYgip1GSs2HkCEYUOc2SnA0jRzCiyGkJ cnxIT3lqbZpcsoA8ATCX9MXYLcnxRZPMQl4WwCiMzBlGbV0KkBIjKVgEMAoja4aRXjf1VnmQEoEn kFEgtVMgWYZllSAlIAlk+HPWk4SdfjAYLxiUOFrVG0Zb4OeRATc4XDkmP8T+hQvLp3UvPDTy163r YPrXx9w7SANhgz8fP8emI+VrjGK+Rk9WsNrXkM3zNTFrJmetmWbNsJqm+GEbWPu0yJo4EzIbpvmQ twNpN/o8rK0yThXdsNRRydrNeUcT06LrjbrYyuxrMgwrFcO36GvaKjbmLYxigyMvldg0tm0TG4tf iVQDW8XLvHuJeTFqTVOE6W38Sn7/Wghe+kumnLWCV75vMZp6Q8aqf38uhX3ME2b7HOTF7NuVNvLd kNE2dSliS+SLXB+vdebzPVYsdguFovLMr75jXiqV8o1b3bJaBZNzifyayE/dYMr/hZ2AjRCdukEu a89iY61cFOaFKBsgUrk8nylf1SWpbcV5PG03+OAL2D8XlSV1/bVgG3WgycrRrAaWrXnpMpSrVYga VRwTrxAV9UZxVp5b++z5pIJgnOAzNSnR4EQzOHgVLXHcotYn1pXUnWJoEhCmdmxn8ck3Stn7P26L dhafJdYle/e3ywDlewg9e++3ywAtUfPy4qEM0TwuLxHdZqMuBUgZo5doY46OtOklQEskbKtpZi/3 djaLTZVmWlyKMoT6z6/eXwAAAP//AwBQSwECLQAUAAYACAAAACEAmxMFu/oAAAC7AQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCO6ir6vgAAADgB AAALAAAAAAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQABq9yK6AMAAD8m AAAhAAAAAAAAAAAAAAAAABICAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwUG AAAAAAMAAwDJAAAAOQYAAAAADwAMBDIdAAAPAALwKh0AAAACCPAIAAAABQAAAAWAAAAPAAPwzhwA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAgAAABQAAAA8ABPAuAQAA EgAK8AgAAAACgAAAAAoAAIMAC/BIAAAAfwABAO8BgABYaYwbvwAAAAYAvwEBABEA/wEBABkAPwMA AAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8A EfAQAAAAAADDCwgAAAABAAAAAgD/vw8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0 byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRo IGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAA AKoPCgAAAFMAAAABAAAAAAAPAATw1ggAABIACvAIAAAAA4AAAAAKAACDAAvwVgAAAH8AAQDvAYAA mOtxH78AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUAIABQAGwAYQBj AGUAaABvAGwAZABlAHIAIAAzAAAAEwAi8dgHAACpw9IHAABQSwMEFAAGAAgAAAAhADI8vT77AAAA 4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uS WCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1u zs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rf yvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJh XGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAG AAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLW kEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNH MnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQH ZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvx T5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhAKoFoXlvAwAA9QcAABAAAABkcnMvc2hhcGV4 bWwueG1srFXNbhMxEL4j8Q6W75CkTUuJ2KK2UEAKVUSKOM/uertLvPZie9Okx/I8CCSQuPRt+gB9 BWbGm6b8CAGlh2a8nvF8833j8aPHi1qLuXK+siaRg/t9KZTJbF6Zk0S+Pj68tyOFD2By0NaoRC6V l49379551Ix8IzDY+FGTyDKEZtTr+axUNfj7tlEG9wrragi4dCe9ximvTICAiWrd2+j3t3s1VEbu 4lFmPm0mjqzsaD5xosoTuS2FgRpTPoGgxERDpkqrc+XEpux1rjEKEMrYZjPf4YE/wZM7OMUiv4Mi jH3msJoBJegxmBUug7AoaVOKsGwQVR6QmDPMBLqQCHiRyI0uLPpi/Losj+WJ9PSlzTEU2mCxbBgt ClffFjOdY4tCYP7h1gOkVYolkre1ORxs9QkQjNQiiIzwDTY3t8khQ4/hg+2N6NCLQMizcT48U/bW oAQdlEinssCFwnzsA3G6TkHptPkf1ddVwKbQVZ3InT79xapLBflTkzMDASodbUSgDYtLkpCiYbFv 8yXBSfEXZYpN/e9NhLcJay+tO5Pi1AH2k3/XglNS6BfGJ/LhYDhEEQIvWDMp3M2d9OaOaesDq6kn BZgMT00kdl40DwKuSE9bNxDGZtpk5LhS8njxBlzTaRGwC47stIRG/UqS6MsKRRpYHx+mYanVbSnh s+Z6wIzDKFfFq4mL7aBXn0mYLh3j/x856dLV4MZMEhqv2MCU/FuZHAcSm6BPcPppKRDaMaRTvNes EnLrQvRWMDb7bsZCFNaEPQ5JwZOuONVMt40hJZgTHC2T1mR4fNRDkzhUmG+ySRbEHEjT63bltlx7 7KviR1/uanTD+PXuXhF+49ftpu2BdscLvghpOz27Ng+xjOvFEY737q6k8bJ+L1SnnTL5BBygfmLW 1lVt31aRVKw5kcrcez2Nc3EwpEmTRqb5f5tIg0noPXHVDOegsVO2pJgpR68PT6+MbkznSP2Mpxh6 R3R1pp7zkkjXFb1GvDdx1hZkExV0uWFk7GGldddh/MVbXeX0kfmiZ0ohK1GGsIgDH8m96aWKAufX iot2bDquWjqms1l5fhEKfJ8SuecqwDbKSnBecW8xpwpu+FxdfLi6+CyuLj5dnn+5PP96+f795fnH n4My/9dB2B9rgeK45Vm3mnH4Jvlm9xsAAAD//wMAUEsDBBQABgAIAAAAIQC0vpUA1QAAAPkAAAAP AAAAZHJzL2Rvd25yZXYueG1sRI/dSsNAEIXvBd9hGcE7u6k/wcZuSxFEQbxo7QOM2ckPZmfT3Uma vL2LF3p5OIfv8K23k+vUSCG2ng0sFxko4tLblmsDx8+Xm0dQUZAtdp7JwEwRtpvLizUW1p95T+NB apUgHAs00Ij0hdaxbMhhXPieOHWVDw4lxVBrG/Cc4K7Tt1mWa4ctp4cGe3puqPw+DC6dLPUwvk+7 u9P9w8dxPq1Wug5izPXVtHsCJTTJ/3jweYX+r/xFvVkDOajqdf4Krd1jFAoGklsyTZagNz8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAqgWheW8DAAD1BwAAEAAAAAAAAAAAAAAAAAAoAgAA ZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAAAAAAAAAAAAA AMUFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAxwYAAAAAAAAQ8AgAAAAUECABYAZA EQ8AEfAQAAAAAADDCwgAAAACAAAABwH/vw8ADfBYAAAAAACfDwQAAAAEAAAAAAChDxoAAAABAAAA AAAgAAoAAAAA/wcAAQAAAAAAAgAOAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAKYPDAAAAPAAAADU AdAC8AMQBQ8ABPAZCQAAEgAK8AgAAAAEgAAAAAoAAIMAC/BaAAAAfwABAO8BgAC4r34fvwAAAAYA vwEBABEA/wERABkAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUAaABv AGwAZABlAHIAIAA0AAAAEwAi8RMIAACpww0IAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NC e3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11E VkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt 7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SU nfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAh AKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevu TM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33 stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU 6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPq xRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhADrUWEapAwAA5AkAABAAAABkcnMvc2hhcGV4bWwueG1s 5FbNbhs3EL4X6DsQvCf6ifwTIevANuo0gGIIkYoejdldrsWKS25Jriz56DxP0QINkIvfxg/gV+jM cGU5bVG0dQ4FqssOyY+cn29+9Or1ujZipXzQzmZy8LwvhbKFK7W9zOR387Nnh1KECLYE46zK5EYF +fro669eNePQCLxsw7jJ5CLGZtzrhWKhagjPXaMsnlXO1xBx6S97jVdB2QgRFdWmN+z393s1aCuP 8Cm7mjVTT1Jxvpp6octMHkhhoUaVZ85F5cXUQKEWzpQoj2SvA6d7gMZMXLEMnUXwdywqPVyhm58Z I6x749GfASnosTlbyywaRkqbhYibBu2qosfYXGfyxxY8WijR7HUmX3RXEx7f2DkX0EmRX71zJV6H Njp0HsbrytdPtZvecVUlSP9gOMLoSrHJ5P7ei9Fgr08WwVitoygQMDx8ubdPgAIRo4P9YQL0kiWE bHyIb5R7slWCHsqkV0VkT2E1CZECu1NB6oz9Eu7XmrLE6DqTh336Ja8XCspvbMkRiKBNktECY5lh 4oRojesTV27InBy/yFPK7X+fSVhU6PvC+WsprjxgUgVKFCWFeWtDJl8ORiMkIfJitHcwxIV/fJI/ PrFtfeoMJaYAW+CrmYxb8TTiivh0dQNxYmdNQcAtk/P19+CbjouIWXDuZgto1J9RkrDMUAoD8xPi LG6MempI+K2VGXDEYVyq6v3Up3Qw220iplPH9n8JnVR1NfgJBwmF9yygSv5qW2JfYhHMJTbBguoa jZtDPsPqZp6Im5jwCib2xC+ZisrZeMyXcgjELLY32x3jlQXYS+ww09YWqCAxYogeci00xbSIYgXE 6kPCcmLuECeq+j2W8xpheH93elzFv8B1p3l7avx8zaWQt7PrB/EM3XhYnGOf76olT+X6OVUde1g0 MPYY2WVb69r9oFNQ0eNM6vjs7Tz1xsGIOk3O0UqQNpMWVdBY8XqJjdC6GUtSLJWnIcTdq6CK6YCU z/iKpXFi9LX6lpcUcqNpKPHZ1DtXsVxqH7G14W6o46lRgI/2Odup5mFs3Zk2pks83gnO6JI2OYg0 xBSGKnET12kYYMQfo1RVYVvbBqid2C6ALT3TyZwOPC0qnF2ZPPYaDNbpAnxQnHIcaAWPMPe3P93f /irub3+5u/l4d/Pp7sOHu5uf/3ipCP/4EiYNEkYuxiORfhfi4gIl6siYQASgY2XLKXjA6vwvs0uW /u8J3VGVxirPtO0swz8foTn6DQAA//8DAFBLAwQUAAYACAAAACEA/QKip9YAAAD5AAAADwAAAGRy cy9kb3ducmV2LnhtbESPy0oDQRBF94L/0JTgJpie+M6YTgiCKAQXicF1OV2ZGZzunnRX5vH3Fi50 ebmXczmL1eAa1VFMdfAGZtMMFPki2NqXBvYfL1ePoBKjt9gETwZGSrBanp8tMLeh91vqdlwqgfiU o4GKuc21TkVFDtM0tOSlO4TokCXGUtuIvcBdo6+z7F47rL08VNjSc0XF9+7k5GSmT91mWN8cb+/e 9+NxPtdlZGMuL4b1Eyimgf/H/YTD5+Sv/EW9WQMPoA6v41es7RYTUzQgbmIqlqCXPwAAAP//AwBQ SwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVs cy8ucmVsc1BLAQItABQABgAIAAAAIQA61FhGqQMAAOQJAAAQAAAAAAAAAAAAAAAAACgCAABkcnMv c2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAAAAAAAAAAAAAAAA/wUA AGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAACBwAAAAAAABDwCAAAABQQsAfQDkARDwAR 8BAAAAAAAMMLCAAAAAMAAAAJAv+/DwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBp MnJzIFdHAAChDx4AAAAPAAAAAAAgCAoAAAAA/wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADU AdAC8AMQBQ8ABPBhCQAAEgAK8AgAAAAFgAAAAAoAAIMAC/BmAAAAfwABAO8BgAAYsH4fvwAAAAYA vwEBABEA/wERABkAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQ AGwAYQBjAGUAaABvAGwAZABlAHIAIAA1AAAAEwAi8T8IAACpwzkIAABQSwMEFAAGAAgAAAAhADI8 vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAE BOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyB sNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sW O/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TP kPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQ SwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKh lBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foO SgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+ z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5od f8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhAAQZaG3VAwAAUAsAABAAAABkcnMv c2hhcGV4bWwueG1s7FbNbttGEL4X6Dss9q7ox/pxhdCB5ERpAMUQIhU5FkNyabJa7rK7S1ly0Yvz PEUCJEAvfhs/gF8hM7uU5bRF0dY+9BAdqFnu/H/zw6fPtqVkG2FsoVXEu086nAmV6LRQ5xH/YTVr HXNmHagUpFYi4jth+bOTb795Wo1txVBY2XEV8dy5atxu2yQXJdgnuhIK7zJtSnB4NOftyggrlAOH hkrZ7nU6w3YJheInqEptltXCEJWcbRaGFWnE0bCCEk0uZZEKdlaXsTBsISERuZYp0gPebkSCNKBL c52sbeMX/BO/UgMXGOwXLjGlXxqMqksG2t6pvX8K3SOjVc7crkLvrEzRNUzSZcR/rsE4YTj6v414 v5EOIqjmEKXFaFl88VqnqAFqpzELMN5mpnyo66RHZxlD+8PB4AjTzNmO6KN+d9Ahj2Asto4lyNDr Hh0NiSFBjv5o2AsM7eAJcVbGupdCP9grRooibkTifKSwmVtHuT2YIHNSPUb4ZYEYMFmUWEMd+oWo cwHpC5X6DDgoZKDRA6k8yIQJIeu2U53uyJ0Y/xGnUOT/vZiwuzD2XJtLzi4MYF1ZKhTBmXylbMS/ 6/b7CILzh/5g1MODuX8T379RdXmqJdUmA5Wg1oi7PXnq8ER46rICN1fLKiHGPZKr7VswVYOFwyo4 08scKvFXkARej1BIg8fHuqXbSfHQlHhdG9n1GYdxKrI3CxPKQe5fEzCNOe//Y9ikrivBzH2SkHjj CTTp/wuV4oDyJMhznIbYyOjaCuIl9rZHiZBxgVvAXE3N2gORaeUmXiQGS7jilFPNNYrkoM5xxCxq laD6gIckcCgwWyWLxLENEKZ35erL8sAxFdkfeX1VIxvKH24nmfsbvuY2rk+lWW19I8T18vKOnGEY d4czHPdNr8ShWb8EqsEuk6mf1r90e6PR4Hg4ak07k2Hreac/a02HL563Jp3T7mAwO+6MZtNfscqb oYkjHSvZV55BVNZ1WZT6pyIAgvmKeOFar1Zhrnb7NKXigJJ/1hFX6CDtJlOscYgqvfQUZ2thaJP5 yZdQtzWM1AuoRdFOksWl+N4fCTBZ0GbzdwujdUY0pZEGA4yVnhVSNtXp31iNG4le+lzTyhOY0QCh 24algcDc5xJZhrNvn8d6rpo816SmoX3V+ARluOMiPjEFSGzmHIwVvi49HgLu8dxe/3Z7/ZHdXn+4 ufp0c/X7zbt3N1fv/yyU2H8thLWFyFCIX9uGsvCobeNOfqTlh92KT+whMiBUugADOAq/tgOm4//X DgeAwpeL/2zYfy7g952tTj4DAAD//wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAZHJz L2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy9x110S5H d3TuPbNFZ2vRUoiVdwrGowwEucLryhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3yQiGuJij gjKlJpcyFiVZjCPfkOPs7IPFxGcwUge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu+Xh5et4e +st0Kk1ISt0Pu+UbiERd+n8262O2Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA//8DAFBL AQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAAQZaG3VAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9z aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAAAAArBgAA ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAC4HAAAAAAAAEPAIAAAAFBAgEGAVQBEPABHw EAAAAAAAwwsIAAAABAAAAAgC/78PAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAA AAIAAAAAACAICgAAAAD/AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAA AAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABgAAAAAwAAGMAC/AkAAAAgQEA AAAIgwEFAAAIvwEQABAA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA u+DjADMzmQAAmZkAmcwAAA8AiBPOAAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAA AIsTCQAAAAAAJAQBAAAACg8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAA AOsuCAAAAErJxwHgjHi/AAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAA AAAAAA4Exg4AAFBLAwQUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyskctqwzAQRfeF/oPQtthyuiil2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhc H8ZB7TEm56nSq7zQCsn6xlFX6c/NS3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6Tc BySptD6OwHKNnQlgt9ChuS2KO2M9MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqa s7qIQ7og3FPziy5byHJRzuapdyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3Fxtvd KOvIZ+PF7E8Aq/+J/s4089/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABf cmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv 96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIP iNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRu N5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAA HAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2 AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPf SchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYA CAAAACEAHVtdbFEJAAB8OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPi vac4DIZSu0ecmocdzairR/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Op fc6btqirlW7+bOhaXq3rTVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO2 0vddd3x8eGjXMJy1P9fHvIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7C1/lvk3faN6+vv OOekBPZV1+LAumyekG/OyBmxZhLyzUcTidpm9xyVjfY5K1e6QT76w7u3D9kjIyi7IV1KPoyOEWw+ WlP8CEHZDek8A7+CHyHI1mtYyHDuMEyMxGa0PSJ6OeRtw8f3Jfoef3sgs7Q2ypQQ0cvFgF7SWY+I XjoD+jhI4iSV5CFElN4d0FuxFXuBRE+I9mVRfRxQG4YPH0YtSLZ1+esoue9HkcEVf6IC6wvnwSm2 ddWNuZKONw/ZX3WTAgX+KLOuqLTu2zHfZmtw0aApshLFyR7zrDdOh9bt2RBMLLE7FNWsvE/sYKbT qsgaD/ISf99ui3VOVrgtyvKp+1bm/27JItu6LDYpDOJzBLq5gNBxD5dM/xLdrsnIM1pTd/8puv3T PjuCgigYdy1jvWu1Y90CEsnEo7xxUlByRyHroP9RbbZZ91u9ocN2H8mCDcH1jgQHPpGNDK6dzF6+ bjKTSnVRbfLSTCIa8R1paWLJYMPh0mBQaBN8XsswJpsuBE+UXWvXWZlvUO80ynGz4NT8emYTsVXT heyzTU5NJA33TGcS23EXIgEcXGrEdLdpU2gNlDYtBHELHhherGTOgCuWLOIcTWXVx1ZZaV9Wuu9Y jq6ts+NK30JIgcvDEYzWVjtdy8odJN1111CvncQi8bbTiv1xrzINPj7wKgnGx6bt4qzdUxuSW8xU ZYUzUfktZ4HONs8CqKO+QArbAxf5blKAHmXT5tttvu76xu6NoO7oTxYJ609d3jztN1+05/JT8z4D 84NOcT2bou2g+OE/mpWO2ia35NjK4tpIhYOzZeVxn7Fo6eHTTM+UnLiqkIH86okHaxuVnSzu9qUg 4nFdcyyl78Y/2FIwHeRVbm/QAmsokZtMQ7yu9Lrp9jVEoeO+WKcN1CokdoC3aBBdMNtqUKiTv03+ Gf9SX6A8kFtZ7Pbd+2KnNQWkk27f5PkfEJaIySaYmSz1UJacEfGonrjtkYr9nH/Oyw8YA12Mwbq2 B1cn0YS5J6E79z/5N0PQ8w5rlD7epBgiojrFwP+6cKFghkWB1XrZbyLxYHKnFRJ9njzOc2R/IXjj VCUtOCqk5Of7DPYvFOGaBNzLtTRiDVZsOVw4sKIwCvEPLNVgUNQzx6zba/gP5L+iWZen8vRD/R5i qwY9HDIDtwGvfoNRDS4xqtCrZ6h76CB1JmRFZ2DFKWqNJ+uZqyAx75myUTKOt+HqT/a+UdmiiJKn k7A4nO7lymYalnRNxy6qGiY7hygMbXkfQgxDtgv6TX39/BcYOob26lNJ2/z2CL8IDo5/NMS7nuvN N3ZZtjThUq/DHgYpy+p9vtWKzVfefwhNUAjRXpSXyIQaH8PKTTxojzUN8oOMHh+l2VI8bE0/LJ4g M0PIFg+TpnCMAexEsMCNrR3QExW2dNWgWqGpsnqNyq4Qflxlo33WtSqjjaLSUC9QWfdVrTKmKVDe 0PHyr12TQWvyROIvSzryINpuzSnu21B8Y4ba3ELt0Mv7NlQkksDlbSjwpN+yo/a8M1c6Yl0D713p sE+pw5iFYxaOwRVsRkKjSHcQVzqHGBuB+8wAnMbmIzYfWfCRBR9x+Ag0pvRxl4+4UKXh9hps5+If XeNLgO6V7byxuDREx3DkEl5o2Pknbdv6Ln7Z0ti+LtM1ura0tZyGcercsG2bpr7vct7MXN8TL2mc RKEsv3LbNll6gRMx3TB/QfnFnqyknSiyoWBh1IKEO89AmagaQX6igigtnAef+bHxQguUfxJebjnm wJ35VD4mIGchPSicedCA/rvmlyhIrDP5lXgJ/dBPltfiBQ91Io6uabwEqbsUwtzxMn4suCAl9Wvw AudabsrryRmOBW/KL/0jyV4SuoQXL45c4RI9Ino5rMeSKA1S2T8JEaV//bHgyLGjEi/LNLSvxwuc HLs34MUwAmjXGRjveBnHi/NqvKDNY94TzICXJfkws03VYzi57M/K/ILxVnjQFXhB9glfWw9Us+Il kPKFEi9WjBlGolcco6epA+dBjHo6v2CxescLvGnCqk66I3DW77sKvDiB4zFtswTE4CDVOOhTImYr 8dJ7nYS9lzL22glyEy9LTOAFIujCtST/UeLFjd00kvGlrMeCIDIi7nFX4CUO8CvJQ5IQfZRAQdJd EIReKMujxItruYtwIfFX4MUwepaZxguS34gX0tGTfh8Mz/p9cBXW74PxeFcOOwJUB3CPXvyf9vvL i3hxIvOkvhnwQrbmue8p8BKnseXzHngCL1JHywyC0YGZZNDShsnSd7kMPSJ6OazHIiOAj+Sfynrs VrwkFsBL5q/ESxC5sSPvVyjwIkWeabzEdmCZPHldV4/9eHjxLuLFMGxb7CXNgBc8sRJ5Q4EX7Mh7 +aoX/4evNaKEZ/WVMr8YRng6N7sCL4iWSPbnWfESxKGXyPlRiRfQ4CmGUfkVeEHdCE1O4wVKz6Vh suBwx8t4/0LfGmZwkGoF9MWefxM/fF09hohh5lDgJbGTsLd/oMQLYlrISP1HiZeF6wWLUMoXPf7D /IJ4OYv/8+IlCOIzPCrxYqfLeMFz7+x4MRI4q77jJVf1LyY9vh0DjNR4z5BgXM8NnXgaMLEZmxF3 6omCzDd8w5MDtBIwnuEnAW/Krkgw0F4HoVwAzQqYyIUvj+lUHiVglraX+rL8igSTplEkSoTpBJP4 cSR2E+4JZjzBmJf/o4kNoV6cjs0BGFfKWCSyMzxImQ3rMVFHTADGNRx/ycF1RYYBEVzB+xrAeKF3 lgFmBUwIMSSUT5CUgHEiJ7p+R1k6n5oGDKpdpOs7YC4A5vIRP/wvIMN0REZ4dUnmWHZi8WitKMni NDI8nokmAONFy3DJq4grAOOlTmrJDqosyUI7SAN+6Ef5zwqYCOASyoBXAsYzHceSWypFhomiEF5Z ZRacBowXQfrl5D8SYOAlBvmdGPJiGYySVyHf/Q0AAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAHVtdbFEJAAB8OQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAi IGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0i aHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJn MT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBh Y2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2Nl bnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJm b2xIbGluayIvPgAADSsEAAAAmA+JggAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAAAKsBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oAi7S2RfWH VgnJ23ftpBRKyGnRrmbmY1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwgyXV/fbXa HDKSYHWkTk615ketyUwYgFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9FS97Xh9J WC7F0/HfHNVJyNk7A5VB9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5DYA5tC+nq Ajf0FoekLpOeCUzD4AzaZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAIAAAAIQAX S2h7ugAAACgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUDQrJtg80m ZKPo35tjBcHj7DBvdprTy8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrVXHHWuYR4 cpFFoRArmHKORynZTOg1VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9jaf7PDsPg DJ6DeXik/KNCZufLsI6GUKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgAAAAhACVG REEHAQAAygEAABIAAABkcnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2e1k8eZL6 A0Iy3Q00MyGZdd1/77RbBfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxetClv0diaE Xl+g6N1wf9ellkOUV0oMsLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020AfWmz7fo aZqCgz25UwTkq0mG2bLAl2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLYgB6mgIFB K/Fhm7nXCNKkVkgexkuStji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkNR+bGt2zr NwzfAAAA//8DAFBLAQItABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAA AAAAKQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAAAAAAAAAA AAAADAIAAGRycy90aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAAAgAB4E0gUAAFBL AwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI /IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0 Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQ t3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZI uT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfR D5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/B CsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhp b6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKg fmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGq Iu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA0VveuqECAAAzBwAAIQAAAGRycy9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQxLnhtbKRVy27bMBC8F+g/ELwn8qtJKsQOULfJJWmM2vkAhlpHaiiS IDeq3a/vkhQd5AXY6EU2qdnh7swudX6xaRXrwPnG6CkfHg84Ay1N1eiHKb9bXR6dceZR6Eooo2HK t+D5xezzp3NbelVdi615QkYc2pdiymtEWxaFlzW0wh8bC5rerY1rBdLSPRSVE3+Iu1XFaDA4KVrR aN7Hu33izXrdSPhu5FMLGhOJAyWQ8vd1Y31ms/uwWQeeaGL0y5Rwa6lac/+bswhyHS2HfEZ1y6Wq mBYtbawaVMBIHTY3GokpArxdOYAA1d2Vs0u7cDHuZ7dwrKkCTx/Pi/5FD4tLTTD6U7wKf8hMotys XTs7FyWJwTZTTp5tw5OCRAkbZDJtyuddWd++g5X1j3fQRT6AMtgdSnbbVNHbcka5nCTHcFdVggoK vTby0TNtqM5QfipP/uwyWag50NuaJeUxKNvj0suoR8b7qGlOdKfE5MsptVWUY3Q6ORmfvdTkbDT6 ehLeB2WGw8l4QIuQyzORdR6vwLTkuscpdyCDp6IU3bXHBM2QaFFKxJa4+WaqbUDe0y/5TDNF8bVx f1MOyuMStwqiSSSlKKlgehBUiTBsoI/uljRsLc4VCBrG3lCczVUjHxkaBlWD7EZ4BMeiQDSaRBny x1hFpARdLYQTv14x98nHrHO2pGmy9WNzx9ncvsPZQgkJtVEVJTEKtdFEZCMPtLqpqFFzN3zgcjwg 55vVjSK+VZSagqlO7aT7T4XDKEWB/QuFSe3oX3rkI2MZB5i6BGno3lDQgdqDPip9AP2qbtz+7OPU o3vrdWmeHNZ7Jz85lL5Zv8tOt9vBvR1bPN3H9Dfc3bFjlbsR9raLFdOniiZqHrcsfZzCpBD0GRI4 8sdu9g8AAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAA AAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDRW966oQIAADMHAAAhAAAAAAAAAAAA AAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAA 8wQAAAAAAAAdBAQAAAABAAAAIAC6DxIAAAAyAF8AaQBlAHQAZgAtADYAOQAPAPgDAUUAAAIA7wMY AAAAAQAAAAECBwkIAAAAAAAAAAAAAAACAP+/YADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMz mQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAA AP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA ////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABg APAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwf AADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/ AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A ////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBm Zv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4A AAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8s AAAAAAMAABAAow+AAAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP// 7wAAAAAAAQAAAP//GAAAAAABAACABQAAEyDUASABAAAiAP//FACABQAAIiDQAkACAAACABIAgAUA ABMg8ANgAwAAAgAQAIAFAAC7ABAFgAQAAAIADgAgAKMPcAAAAAUA//0/AAAAIiAAAGQAAAAAAAAA ZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//wwAAAAAAQAAAAUAACABIAEAACAA//8A BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiAAAGQA AAAAAAAAZAAAAAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEA AAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAA AQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAE AAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABQA AQAAAAAAAAACABIAAgAAAAAAAAACABAAAwAAAAAAAAACAA4ABAAAAAAAAAACAAwAgACjDz4AAAAF AAAAAAAAAAAAAgASAAEAAAAAAAAAAgAQAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAMAAQAAAAAAAAA AgAKAAAAIwQYBwAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrv ndhhJhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG 3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31R l9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvto tp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABf cmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2 NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKM XPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6Iyc KGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAAGr3IroAwAAPyYAACEA AABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWktu2zAU3BfoHQRuA8eW/JFsWA6S FFllETTJAWiZstVQlEAxadxVkRyhN+i+aIEW6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9N8OX 7sGtj7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRiAS1ikAwgDgiywRhF4KD3+lU37LDbczbGKNL4FCTq QBuMGAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1QOF7PrWPq0at1qr60CNAjadFxgeu6znoTeBc+4iw eBKKMGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe25zGM5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe8JQc 0Sv57AaEHcoufRghoI0gGfL9nl0Th4kOYqoodI6Qq57OHKbdQDlRtdetzrUeumxFP9U6QO5bvrLo gw0ajZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K9xIgEo2NQ+RChzO957+rYCZ6wg6CqYbHhy+PD9+1 x4dvk7sfk7ufk/v7yd1XoDkjSCMktykHOdF/D+L7j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g7+Gx DSp6rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh5AhGFDnNkpwNI0cwoshpCXJ8SE95am2aXLKAPAEw l/TF2C3J8UWTzEJeFsAojMwZRm1dCpASIylYBDAKI2uGkV439VZ5kBKBJ5BRILVTIFmGZZUgJSAJ ZPhz1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5Jj/E/oULy6d1Lzw08tet62D618fcO0gDYYM/Hz/H piPla4xivkZPVrDa15DN8zUxayZnrZlmzbCapvhhG1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V3bDU UcnazXlHE9Oi64262MrsazIMKxXDt+hr2io25i2MYoMjL5XYNLZtExuLX4lUA1vFy7x7iXkxak1T hOlt/Ep+/1oIXvpLppy1gle+bzGaekPGqn9/LoV9zBNm+xzkxezblTby3ZDRNnUpYkvki1wfr3Xm 8z1WLHYLhaLyzK++Y14qlfKNW92yWgWTc4n8mshP3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgbIFK5 PJ8pX9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1oMnK0awGlq156TKUq1WIGlUcE68QFfVGcVaeW/vs +aSCYJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1iaBIQpnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA5XsI PXvvt8sALVHz8uKhDNE8Li8R3WajLgVIGaOXaGOOjrTpJUBLJGyraWYv93Y2i02VZlpcijKE+s+v 3l8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtD b250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAA AAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAavciugDAAA/JgAAIQAAAAAAAAAAAAAA AAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAAADkG AAAAAA8ADAQxHQAADwAC8CkdAAAQAgjwCAAAAAUAAAAFhAAADwAD8M0cAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAASAAAAEAAAAAIACvAIAAAAAIQAAAUAAAAPAATwLgEAABIACvAIAAAAAoQAAAAK AACDAAvwSAAAAH8AAQDvAYAAKLuAJb8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAAC AFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAA AQAAAAIA/78PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIg dGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBs ZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAA AAAADwAE8NYIAAASAArwCAAAAAOEAAAACgAAgwAL8FYAAAB/AAEA7wGAADiRayC/AAAABgC/AQEA EQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy ACAAMwAAABMAIvHYBwAAqcPSBwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE 0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDne GsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG 0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ER us5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAA AI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7 uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk 9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzN LNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD/ /wMAUEsDBBQABgAIAAAAIQCqBaF5bwMAAPUHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxVzW4TMRC+ I/EOlu+QpE1LidiitlBAClVEijjP7nq7S7z2YnvTpMfyPAgkkLj0bfoAfQVmxpum/AgBpYdmvJ7x fPN94/Gjx4tai7lyvrImkYP7fSmUyWxemZNEvj4+vLcjhQ9gctDWqEQulZePd+/eedSMfCMw2PhR k8gyhGbU6/msVDX4+7ZRBvcK62oIuHQnvcYpr0yAgIlq3dvo97d7NVRG7uJRZj5tJo6s7Gg+caLK E7kthYEaUz6BoMREQ6ZKq3PlxKbsda4xChDK2GYz3+GBP8GTOzjFIr+DIox95rCaASXoMZgVLoOw KGlTirBsEFUekJgzzAS6kAh4kciNLiz6Yvy6LI/lifT0pc0xFNpgsWwYLQpX3xYznWOLQmD+4dYD pFWKJZK3tTkcbPUJEIzUIoiM8A02N7fJIUOP4YPtjejQi0DIs3E+PFP21qAEHZRIp7LAhcJ87ANx uk5B6bT5H9XXVcCm0FWdyJ0+/cWqSwX5U5MzAwEqHW1EoA2LS5KQomGxb/MlwUnxF2WKTf3vTYS3 CWsvrTuT4tQB9pN/14JTUugXxify4WA4RBECL1gzKdzNnfTmjmnrA6upJwWYDE9NJHZeNA8CrkhP WzcQxmbaZOS4UvJ48QZc02kRsAuO7LSERv1KkujLCkUaWB8fpmGp1W0p4bPmesCMwyhXxauJi+2g V59JmC4d4/8fOenS1eDGTBIar9jAlPxbmRwHEpugT3D6aSkQ2jGkU7zXrBJy60L0VjA2+27GQhTW hD0OScGTrjjVTLeNISWYExwtk9ZkeHzUQ5M4VJhvskkWxBxI0+t25bZce+yr4kdf7mp0w/j17l4R fuPX7abtgXbHC74IaTs9uzYPsYzrxRGO9+6upPGyfi9Up50y+QQcoH5i1tZVbd9WkVSsOZHK3Hs9 jXNxMKRJk0am+X+bSINJ6D1x1QznoLFTtqSYKUevD0+vjG5M50j9jKcYekd0daae85JI1xW9Rrw3 cdYWZBMVdLlhZOxhpXXXYfzFW13l9JH5omdKIStRhrCIAx/JvemligLn14qLdmw6rlo6prNZeX4R CnyfErnnKsA2ykpwXnFvMacKbvhcXXy4uvgsri4+XZ5/uTz/evn+/eX5x5+DMv/XQdgfa4HiuOVZ t5px+Cb5ZvcbAAAA//8DAFBLAwQUAAYACAAAACEAtL6VANUAAAD5AAAADwAAAGRycy9kb3ducmV2 LnhtbESP3UrDQBCF7wXfYRnBO7upP8HGbksRREG8aO0DjNnJD2Zn091Jmry9ixd6eTiH7/Ctt5Pr 1Eghtp4NLBcZKOLS25ZrA8fPl5tHUFGQLXaeycBMEbaby4s1FtafeU/jQWqVIBwLNNCI9IXWsWzI YVz4njh1lQ8OJcVQaxvwnOCu07dZlmuHLaeHBnt6bqj8PgwunSz1ML5Pu7vT/cPHcT6tVroOYsz1 1bR7AiU0yf948HmF/q/8Rb1ZAzmo6nX+Cq3dYxQKBpJbMk2WoDc/AAAA//8DAFBLAQItABQABgAI AAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAKoFoXlvAwAA9QcAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54 bWxQSwECLQAUAAYACAAAACEAtL6VANUAAAD5AAAADwAAAAAAAAAAAAAAAADFBQAAZHJzL2Rvd25y ZXYueG1sUEsFBgAAAAAEAAQA9QAAAMcGAAAAAAAAEPAIAAAAFBAgAWAGQBEPABHwEAAAAAAAwwsI AAAAAgAAAAcB/78PAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAIAAKAAAAAP8HAAEA AAAAAAIADgAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwGAkA ABIACvAIAAAABIQAAAAKAACDAAvwWgAAAH8AAQDvAYAAuHmoJb8AAAAGAL8BAQARAP8BEQAZAD8D AAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANAAA ABMAIvESCAAAqcMMCAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Z q/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4 DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqW qfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvE rwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAAL AAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TL oEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQx MJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ 3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsD BBQABgAIAAAAIQCi6wxqqAMAAOwJAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWzW4bNxC+F+g7ELwn +on8EyHrwDbqNIBiCJGKHo3ZXa7FiktuSa4s+eg8T9ECLdCL38YP4FfozHBl2W1RtHUOPXQP2uFy yPlmvvnRm7fr2oiV8kE7m8nBy74Uyhau1PYyk9/Mz14cShEi2BKMsyqTGxXk26Mvv3jTjEMj8LAN 4yaTixibca8XioWqIbx0jbK4VzlfQ8Slv+w1XgVlI0Q0VJvesN/f79WgrTzCq+xq1kw9ScX5auqF LjN5IIWFGk2eOReVF1MDhVo4U6I8kr1OOZ0DBDNxxTJ0iODvICo9XKGbT8AI69559GdABnoMZ4vM IjAy2ixE3DSIq4oeY3Odye9b8IhQIux1Jl91R5M+3rFzLqCTIr/64Eo8Dm106DyM15Wvn4ub7nFV Jcj+YDjC6EqxyeT+3qvRYK9PiGCs1lEUqDA8fL23TwoFaowO9odJoZeQkGbjQ3yn3LNRCbook14V kT2F1SRECuzOBJkz9nO4X2vKEqPrTB726UleLxSUX9mSIxBBmyQjAmOZYeKEaI3rE1duCE6Ob+Qp 5fa/zyQsKvR94fy1FFceMKkCJYqSwry3IZOvB6MRkhB5Mdo7GOLCP97JH+/Ytj51hhJTgC3w1kzG rXgacUV8urqBOLGzpiDFLZPz9bfgm46LiFlw7mYLaNSfUZJ0maEUBuYnxFncGPXckPBdKzPgiMO4 VNXHqU/pYLafiZjOHOP/HDap6mrwEw4SCh9ZQJP81rbEvsQimEtsggXVNYKbQz7D6maeiJuY9BVM 7IlfMhWVs/GYD+UQiFlsb7bbxiMLsJfYYaatLdBAYsQQPeRaaIppEcUKiNWHhOXE3GmcqOr3upzX qIbnd7vHVfwLvW43b0+Nn6+5FPJ2dv0gnqEbD4tz7PNdteSpXJ9S1bGHRQNjj5FdtrWu3Xc6BRU9 zqSOL97PU28cjKjT5BytpNJm0qIJGiteL7ERWjdjSYql8jSEuHsVVDGdIuUz3mJpnBh9rb7mJYXc aBpKvDf1zlUsl9pHbG34NdTx1CjAS/uc7VTzMLbuTBvTJR5/Cc7okj5yEGmIKQxV4iau0zDAiD/W UlWFbW0boHZiuwC2dE0nczrwtKhwdmXy2GswWKcL8EFxynGgFTzSub/94f72Z3F/+9PdzS93N7/e ffp0d/PjHw8V4R8fwqRBwsjFeCTScyEuLgT1Y0wf2mZS+ee/zSxB/J/MHZlPKEQiG55t25mGf0JC c/QbAAAA//8DAFBLAwQUAAYACAAAACEA/QKip9YAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESP y0oDQRBF94L/0JTgJpie+M6YTgiCKAQXicF1OV2ZGZzunnRX5vH3Fi50ebmXczmL1eAa1VFMdfAG ZtMMFPki2NqXBvYfL1ePoBKjt9gETwZGSrBanp8tMLeh91vqdlwqgfiUo4GKuc21TkVFDtM0tOSl O4TokCXGUtuIvcBdo6+z7F47rL08VNjSc0XF9+7k5GSmT91mWN8cb+/e9+NxPtdlZGMuL4b1Eyim gf/H/YTD5+Sv/EW9WQMPoA6v41es7RYTUzQgbmIqlqCXPwAAAP//AwBQSwECLQAUAAYACAAAACEA Mjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQCi6wxqqAMAAOwJAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsB Ai0AFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAAAAAAAAAAAAAAAA/gUAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPUAAAABBwAAAAAAABDwCAAAABQQsAfQDkARDwAR8BAAAAAAAMMLCAAAAAMA AAAJAv+/DwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdHAAChDx4AAAAP AAAAAAAgCAoAAAAA/wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPBhCQAA EgAK8AgAAAAFhAAAAAoAAIMAC/BmAAAAfwABAO8BgADYzGogvwAAAAYAvwEBABEA/wERABkAPwMA AAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwA ZABlAHIAIAA1AAAAEwAi8T8IAACpwzkIAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAABb Q29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NCe3sm bdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11EVkIT 13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt7g57 S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SUnfK0 51I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAhAKqL XQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevuTM6W scw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33stod acJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU6Zqq +Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPqxRu7 GwAAAP//AwBQSwMEFAAGAAgAAAAhAMBmmj/VAwAAUAsAABAAAABkcnMvc2hhcGV4bWwueG1s7FbN bttGEL4X6Dss9q7oj5IdIXRgK1IaQDWESEWPxZBcWqyWu+zuUpZc9OI8T9ECCdCL38YP4FfozC5l OU1QtLUPPUQHapY7/9/88MXLbSnZRhhbaBXz7rMOZ0KlOivURcy/W05bx5xZByoDqZWI+U5Y/vLk 669eVCNbMRRWdlTFfOVcNWq3bboSJdhnuhIK73JtSnB4NBftyggrlAOHhkrZ7nU6w3YJheInqEpt FtXcEJWeb+aGFVnM0bCCEk0uZJEJdl6XiTBsLiEVKy0zpAe83YgEaUCXZjpd28Yv+Cd+ZQYuMdiP XGJKvzYYVZcMtL1Te/8UukdGqxVzuwq9szJD1zBJVzH/qQbjhOHo/zbmUSMdRFDNIUqL0bLk8lud oQaoncYswGibm/KxrpMenecM7Q8Hgz6mmbMd0f2oO+iQRzASW8dSZOh1+/0hMaTIER0Ne4GhHTwh zspY91roR3vFSFHMjUidjxQ2M+sotwcTZE6qpwi/LBADJosSa6hDvxD1SkA2UZnPgINCBho9kMqD TJgQsm57prMduZPgP+IUivy/FxN2F8a+0uaKs0sDWFeWCkVwJt8oG/Pn3ShCEJw/RIOjHh7Mw5vk 4Y2qy7GWVJsMVIpaY+725NjhifDUZQVuphZVSox7JJfb78FUDRYOq+BcL1ZQic9BEng9QiENHh/r Fm4nxWNT4nVtZNdnHEaZyN/OTSgHuX9NwDTmvP9PYZO6rgQz80lC4q0n0KT/L1SGA8qTIC9wGmIj o2tLSBbY2x4lQsYFbgEzdWbWHohcK3fqRRKwhCtOOdVco8gK1AWOmHmtUlQf8JAEDgVmq3SeOrYB wvS+XH1ZHjjORP5XXl/VyIbyh9vT3P0NX3Ob1GNpllvfCEm9uLonpxjG/eEcx33TK0lo1o+BarDL Zean9c+vjk7Hk15v0Bp2j6PWeBD1W8eTV9PWeBI9Pzo+m07Gg+kvWOXN0MSRjpXsK88gKuu6LEr9 YxEAwXzFvHCtN8swV7sRTakkoOSfdcwVOki7yRRrHKJKLzzF2VoY2mR+8qXUbQ0j9QJqUbSTZHEl vvFHAkwWtNn83dxonRNNaaTBACOlp4WUTXX6N1bjRqKXPte08gRmNEDotmFpIDAPuUSe4+zb57Ge qSbPNalpaF81PkE57riYn5oCJDbzCowVvi49HgIe8Nzd/Hp3857d3fx+e/3h9vqP23fvbq9/+1Qo tf9aCGsLkaEQv7QNZeFJ28ad/EDLD7sVn9hDZECobA4GcBR+aQdMx/+vHQ4AhS8X/9mw/1zA7ztb nfwJAAD//wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/L bsIwEEX3lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy9x110S5Hd3TuPbNFZ2vRUoiVdwrG owwEucLryhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3yQiGuJijgjKlJpcyFiVZjCPfkOPs 7IPFxGcwUge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu+Xh5et4e+st0Kk1ISt0Pu+UbiERd +n8262O2Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA//8DAFBLAQItABQABgAIAAAAIQAy PL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAG AAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAG AAgAAAAhAMBmmj/VAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwEC LQAUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAAAAArBgAAZHJzL2Rvd25yZXYueG1s UEsFBgAAAAAEAAQA9QAAAC4HAAAAAAAAEPAIAAAAFBAgEGAVQBEPABHwEAAAAAAAwwsIAAAABAAA AAgC/78PAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAICgAAAAD/ AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAAAPAAAADU AdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABhAAAAAwAAGMAC/AkAAAAgQEAAAAIgwEFAAAIvwEQABAA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwA AA8AiBPOAAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJAQBAAAA Cg8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAErJxwHgjHi/ AAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAA4Exg4AAFBLAwQU AAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQ tthyuiil2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhcH8ZB7TEm56nSq7zQCsn6 xlFX6c/NS3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6TcBySptD6OwHKNnQlgt9Ch uS2KO2M9MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqas7qIQ7og3FPziy5byHJR zuapdyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3FxtvdKOvIZ+PF7E8Aq/+J/s40 89/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rD MAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoG w+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXb NGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhl qtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1l L3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3 zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1 K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEALUmiVFEJAAB8 OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPivac4DIZSu0ecmocdzair R/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Opfc6btqirlW7+bOhaXq3r TVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO20vddd3x8eGjXMJy1P9fH vIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7C1/1vk3faN6+vvOOekBPZV1+LAumyekG/O yBmxZhLyzUcTidpm9xyVjfY5K1e6QT76w7u3D9kjIyi7IV1KPoyOEWw+WlP8CEHZDek8A7+CHyHI 1mtYyHDuMEyMxGa0PSJ6OeRtw8f3Jfoef3sgs7Q2ypQQ0cvFgF7SWY+IXjoD+jhI4iSV5CFElN4d 0FuxFXuBRE+I9mVRfRxQG4YPH0YtSLZ1+esoue9HkcEVf6IC6wvnwSm2ddWNuZKONw/ZX3WTAgX+ KLOuqLTu2zHfZmtw0aApshLFyR7zrDdOh9bt2RBMLLE7FNWsvE/sYKbTqsgaD/ISf99ui3VOVrgt yvKp+1bm/27JItu6LDYpDOJzBLq5gNBxD5dM/xLdrsnIM1pTd/8puv3TPjuCgigYdy1jvWu1Y90C EsnEo7xxUlByRyHroP9RbbZZ91u9ocN2H8mCDcH1jgQHPpGNDK6dzF6+bjKTSnVRbfLSTCIa8R1p aWLJYMPh0mBQaBN8XsswJpsuBE+UXWvXWZlvUO80ynGz4NT8emYTsVXTheyzTU5NJA33TGcS23EX IgEcXGrEdLdpU2gNlDYtBHELHhherGTOgCuWLOIcTWXVx1ZZaV9Wuu9Yjq6ts+NK30JIgcvDEYzW Vjtdy8odJN1111CvncQi8bbTiv1xrzINPj7wKgnGx6bt4qzdUxuSW8xUZYUzUfktZ4HONs8CqKO+ QArbAxf5blKAHmXT5tttvu76xu6NoO7oTxYJ609d3jztN1+05/JT8z4D84NOcT2bou1WOgE0/mhW Omqb3JJjK4trIxUOzpaVx33GoqWHTzM9U3LiqkIG8qsnHqxtVHayuNuXgoifayl9N/7BloLpIK9y e4MWWEOJ3GQa4nWl1023ryEKHffFOm2gViGxA7xFg+iC2VaDQp38bfLP+Jf6AuWB3Mpit+/eFzut KSCddPsmz/+AsES8b4KZyVIPZckZEY/qidseqdjP+ee8/IAx0MUYrGt7cHUSTZh7Erpz/5N/MwQ9 77BG6eNNiiEiqlMM/K8LFwpmWBRYrZf9JhIPJndaIdHnyeM8R/YXgjdOVdKCo0JKfr7PYP9CEa5J wL1cSyPWYMWWw4UDKwqjEP/AUg0GRT1zzLq9hv9A/iuadXkqTz/U7yG2atDDITNwG/DqNxjV4BID JL16hrqHDlJnQlZ0BlacotZ4sp65ChLznikbJeN4G67+ZO8blS2KKHk6CYvD6V6ubKZhSdd07KKq YbJziMLQlvchxDBku6Df1NfPf4GhY2ivPpW0zW+P8Ivg4PhHQ7zrud58Y5dlSxMu9TrsYZCyrN7n W63YfOX9h9AEhRDtRXmJTKjxMazcxIP2WNMgP8jo8VGaLcXD1vTD4gkyM4Rs8TBpCscYwE4EC9zY 2gE9UWFLVw2qFZoqq9eo7Arhx1U22mddqzLaKCoN9QKVdV/VKmOaAuUNHS//2jUZtCZPJP6ypCMP ou3WnOK+DcU3ZqjNLdQOvbxvQ0UiCVzehgJP+i07as87c6Uj1jXw3pUO+5Q6jFk4ZuEYXMFmJDSK dAdxpXOIsRG4zwzAaWw+YvORBR9Z8BGHj0BjSh93+YgLVRpur8F2Lv7RNb4E6F7ZzhuLS0N0DEcu 4YWGnX/Stq3v4pctje3rMl2ja0tby2kYp84N27Zp6vsu583M9T3xksZJFMryK7dtk6UXOBHTDfMX lF/syUraiSIbChZGLUi48wyUiaoR5CcqiNLCefCZHxsvtED5J+HllmMO3JlP5WMCchbSg8KZBw3o v2t+iYLEOpNfiZfQD/1keS1e8FAn4uiaxkuQukshzB0v48eCC1JSvwYvcK7lpryenOFY8Kb80j+S 7CWhS3jx4sgVLtEjopfDeiyJ0iCV/ZMQUfrXHwuOHDsq8bJMQ/t6vMDJsXsDXgwjgHadgfGOl3G8 OK/GC9o85j3BDHhZkg8z21Q9hpPL/qzMLxhvhQddgRdkn/C19UA1K14CKV8o8WLFmGEkesUxepo6 cB7EqKfzCxard7zAmyas6qQ7Amf9vqvAixM4HtM2S0AMDlKNgz4lYrYSL73XSdh7KWOvnSA38bLE BF4ggi5cS/IfJV7c2E0jGV/KeiwIIiPiHncFXuIAv5I8JAnRRwkUJN0FQeiFsjxKvLiWuwgXEn8F XgyjZ5lpvCD5jXghHT3p98HwrN8HV2H9PhiPd+WwI0B1APfoxf9pv7+8iBcnMk/qmwEvZGue+54C L3EaWz7vgSfwInW0zCAYHZhJBi1tmCx9l8vQI6KXw3osMgL4SP6prMduxUtiAbxk/kq8BJEbO/J+ hQIvUuSZxktsB5bJk9d19diPhxfvIl4Mw7bFXtIMeMETK5E3FHjBjryXr3rxf/haI0p4Vl8p84th hKdzsyvwgmiJZH+eFS9BHHqJnB+VeAENnmIYlV+BF9SN0OQ0XqD0XBomCw53vIz3L/StYQYHqVZA X+z5N/HD19VjiBhmDgVeEjsJe/sHSrwgpoWM1H+UeFm4XrAIpXzR4z/ML4iXs/g/L16CID7DoxIv drqMFzz3zo4XI4Gz6jteclX/YtLj2zHASI33DAnG9dzQiacBE5uxGXGnnijIfMM3PDlAKwHjGX4S 8KbsigQD7XUQygXQrICJXPjymE7lUQJmaXupL8uvSDBpGkWiRJhOMIkfR2I34Z5gxhOMefk/mtgQ 6sXp2ByAcaWMRSI7w4OU2bAeE3XEBGBcw/GXHFxXZBgQwRW8rwGMF3pnGWBWwIQQQ0L5BEkJGCdy out3lKXzqWnAoNpFur4D5gJgLh/xw/8CMkxHZIRXl2SOZScWj9aKkixOI8PjmWgCMF60DJe8irgC MF7qpJbsoMqSLLSDNOCHfpT/rICJAC6hDHglYDzTcSy5pVJkmCgK4ZVVZsFpwHgRpF9O/iMBBl5i kN+JIS+WwSh5FfLd3wAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90 aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQD hOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm83 7RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmW UJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAA IQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1lL3RoZW1lL3RoZW1l TWFuYWdlci54bWxQSwECLQAUAAYACAAAACEALUmiVFEJAAB8OQAAFgAAAAAAAAAAAAAAAADTAgAA dGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAA AAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAA AAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYt OCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVtYXMu b3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9ImRr MSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2NlbnQy IiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1IiBh Y2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAADSsE AAAAhKSCqQAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oAi7S2RfWHVgnJ23ftpBRKyGnRrmbm Y1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwgyXV/fbXaHDKSYHWkTk615ketyUwY gFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9FS97Xh9JWC7F0/HfHNVJyNk7A5VB 9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5DYA5tC+nqAjf0FoekLpOeCUzD4Aza ZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAIAAAAIQAXS2h7ugAAACgBAAALAAAA X3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUDQrJtg80mZKPo35tjBcHj7DBvdprT y8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrVXHHWuYR4cpFFoRArmHKORynZTOg1 VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9jaf7PDsPgDJ6DeXik/KNCZufLsI6G UKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgAAAAhACVGREEHAQAAygEAABIAAABk cnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2e1k8eZL6A0Iy3Q00MyGZdd1/77Rb BfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxetClv0diaEXl+g6N1wf9ellkOUV0oM sLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020AfWmz7foaZqCgz25UwTkq0mG2bLA l2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLYgB6mgIFBK/Fhm7nXCNKkVkgexkuS tji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkNR+bGt2zrNwzfAAAA//8DAFBLAQIt ABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAAAAAAKQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAAAAAAAAAAAAAADAIAAGRycy90aW1p bmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAAAwAB4EjwYAAFBLAwQUAAYACAAAACEAR3I7 tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemCxwoB i/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHBKBcD tHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKDd80T 9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZGmAf Kpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8DAFBL AwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCR pr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0Bkfv SMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAsmOJs FMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA//8D AFBLAwQUAAYACAAAACEAPSqrsF4DAABGCQAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQxLnhtbJyW247aMBCG7yv1HSzftyThEDZaqNTt6WK7XZXtA3gds0R1nMj2UujT9x/HgdBuJcQN GGf8eQ7/DLl+t6s12yrrqsYsePo24UwZ2ZSVeVrwHw+f3sw5c16YUujGqAXfK8ffLV+/um4Lp8tb sW+ePQPDuEIs+Mb7thiNnNyoWri3TasMnq0bWwuPn/ZpVFrxC+xaj7IkmY1qURkez9tzzjfrdSXV h0Y+18r4DmKVFh7+u03Vup7WnkNrrXLAhNOnLvl9i2idkl+UKDkLhnaLrZQvEbtc6ZIZUWNjpSRd zshQ2fDUtQ9WKbIz28+2XbX3Nhy6295bVpUEiYf5KD6IZuGngRkWo7+OP/UkUezWtl5eiwLZYLsF R9H29IlDolA7z2S3KY+7cvPtBVu5+fiC9ai/AB4cLkW92y6if8PJ+nAeKq8VSw9RdaYCR28b+dMx 0yBOCr8LT95texjFTPh2w7rUe0JFu+5hyEdv70JOe0cPmcizbJyOQzomk2R2lfyVlDzPswk2GaUm Hc+yJJ+GS46k1jr/WTU1au78gluUF0UVhdjeOk9+i6I3CTXqPGkLv3vflHuyfMQ3Co2uwvlNY39z JozEYsE9XSYK7fzK7zUkgvVWpwiGCf2EDtThrlKtv2PL/V5weAt3H4NmpEDyhNbR43gyuDQkok6i QDbxAYgW1MrKvPmxQivX/kYrgYtiYvzyRlfyJ/MNU2Xl2VfhvLIsZB+NDx8pYB/uCEhlynthBbk3 JMfEhIz0mUDBOs38XzkoVddFDyTbey2k2jQafcQyChKN1kvkIhFRJTg6Du3Qa+4iLWVXySyHrkLx +gY71dI0SdJ5HivT9WeIv5N1n5KDOHpBPHbMYfl6QdTC3oberkyJIUVLqunj8x0mcfBkIBNM01BR FOsgi7DMSFsdajLNYYZ8nMFL50MeQaJWx0feVYoeO5c3G/IIEnmTIy8d5ymZnecgXd2pDgETJQKn A+A8m1McFwCJEoGzIzDL5nDwIiBRIjAfAPPJ+PyanIRMlAicH4FEO78oJ0CiRODVADib5hcWhSgv DyfCo2qHKRTuvXxYUUeGWeVOhhVN6pcGUujL7h8aS/orD5NG26+i/bYNvuDtBWPwJmy1eF8hocH0 aEKM/v1n+QcAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAA AAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQA9KquwXgMAAEYJAAAhAAAAAAAA AAAAAAAAABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJ AAAAsAUAAAAAAAAdBAQAAAABAAAAIAC6DxIAAAAzAF8AaQBlAHQAZgAtADYAOQAPAPgD80QAAAIA 7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAACAP+/YADwByAAAAD///8AAAAAAICAgAAAAAAAu+Dj ADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAH IAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAA AAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+Z AABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA//// AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAA Zsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABo a10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZ ewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACj Dz4AAAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA //8sAAAAAAMAABAAow+AAAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAA AP//7wAAAAAAAQAAAP//GAAAAAABAACABQAAEyDUASABAAAiAP//FACABQAAIiDQAkACAAACABIA gAUAABMg8ANgAwAAAgAQAIAFAAC7ABAFgAQAAAIADgAgAKMPcAAAAAUA//0/AAAAIiAAAGQAAAAA AAAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//wwAAAAAAQAAAAUAACABIAEAACAA //8ABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAAAAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACAB IAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkA AAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAA AAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAAC ABQAAQAAAAAAAAACABIAAgAAAAAAAAACABAAAwAAAAAAAAACAA4ABAAAAAAAAAACAAwAgACjDz4A AAAFAAAAAAAAAAAAAgASAAEAAAAAAAAAAgAQAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAMAAQAAAAA AAAAAgAKAAAAIwQYBwAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4 zXrvndhhJhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3og FRMG3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTP W31Rl9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2Gw Bvtotp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsA AABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBv Zur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRk PdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr 6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAAGr3IroAwAAPyYA ACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWktu2zAU3BfoHQRuA8eW/JFs WA6SFFllETTJAWiZstVQlEAxadxVkRyhN+i+aIEW6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9 N8OX7sGtj7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRiAS1ikAwgDgiywRhF4KD3+lU37LDbczbGKNL4 FCTqQBuMGAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1QOF7PrWPq0at1qr60CNAjadFxgeu6znoTeBc +4iweBKKMGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe25zGM5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe 8JQc0Sv57AaEHcoufRghoI0gGfL9nl0Th4kOYqoodI6Qq57OHKbdQDlRtdetzrUeumxFP9U6QO5b vrLogw0ajZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K9xIgEo2NQ+RChzO957+rYCZ6wg6CqYbHhy+P D9+1x4dvk7sfk7ufk/v7yd1XoDkjSCMktykHOdF/D+L7j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g 7+GxDSp6rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh5AhGFDnNkpwNI0cwoshpCXJ8SE95am2aXLKA PAEwl/TF2C3J8UWTzEJeFsAojMwZRm1dCpASIylYBDAKI2uGkV439VZ5kBKBJ5BRILVTIFmGZZUg JSAJZPhz1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5Jj/E/oULy6d1Lzw08tet62D618fcO0gDYYM/ Hz/HpiPla4xivkZPVrDa15DN8zUxayZnrZlmzbCapvhhG1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V 3bDUUcnazXlHE9Oi64262MrsazIMKxXDt+hr2io25i2MYoMjL5XYNLZtExuLX4lUA1vFy7x7iXkx ak1ThOlt/Ep+/1oIXvpLppy1gle+bzGaekPGqn9/LoV9zBNm+xzkxezblTby3ZDRNnUpYkvki1wf r3Xm8z1WLHYLhaLyzK++Y14qlfKNW92yWgWTc4n8mshP3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgb IFK5PJ8pX9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1oMnK0awGlq156TKUq1WIGlUcE68QFfVGcVae W/vs+aSCYJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1iaBIQpnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA 5XsIPXvvt8sALVHz8uKhDNE8Li8R3WajLgVIGaOXaGOOjrTpJUBLJGyraWYv93Y2i02VZlpcijKE +s+v3l8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAA AFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAA AAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAavciugDAAA/JgAAIQAAAAAAAAAA AAAAAAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAA ADkGAAAAAA8ADAQxHQAADwAC8CkdAAAgAgjwCAAAAAUAAAAFiAAADwAD8M0cAAAPAATwKAAAAAEA CfAQAAAAUBEpYgAAAAAAAAAARLSiJQIACvAIAAAAAIgAAAUAAAAPAATwLgEAABIACvAIAAAAAogA AAAKAACDAAvwSAAAAH8AAQDvAYAASMGAJb8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsI AAAAAQAAAAIA/78PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0 ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0 aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAA AQAAAAAADwAE8NUIAAASAArwCAAAAAOIAAAACgAAgwAL8FYAAAB/AAEA7wGAAEh9RR6/AAAABgC/ AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQA ZQByACAANAAAABMAIvHXBwAAqcPRBwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3Z IFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6 yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tV rSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdS N3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N 0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHM NXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnC Updk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmO HbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsA AAD//wMAUEsDBBQABgAIAAAAIQCp2UM+bgMAAPUHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxVzW4T MRC+I/EOlu+QpE1LidiitlBAClVEijjP7nq7S7zjxfamSY/leRBIIHHp2/QB+grM2Jum/AgBpYdm vJ7xfPN94/Gjx4tai7myrjKYyMH9vhQKM5NXeJLI18eH93akcB4wB21QJXKpnHy8e/fOo2bkGkHB 6EZNIkvvm1Gv57JS1eDum0Yh7RXG1uBpaU96jVVOoQdPiWrd2+j3t3s1VCh36SicT5uJZSs7mk+s qPJEbkuBUFPKJ+CVmGjIVGl0rqwYyl7nGqOAoIxNNnMdHvgTPLmFUyryOygCzTNL1Qw4QS+AWeFC gsVJm1L4ZUOock/EnFEm0IUkwItEbnRh0Zfi12U5Kk+kpy9NTqHQekNlw2hR2Pq2mPkcUxSC8g+3 HhCtUiyJvK3N4WCrz4BgpBZeZIxvsLm5zQ4ZeQwfbG9Eh14Ewp6Ndf6ZMrcGJfigRFqV+VAozMfO M6frFJxO4/+ovq48NYWu6kTu9PkvVl0qyJ9iHhjwUOloEwKNQVyWhBX1i32TLxlOSr8kU2zqf28i uk1Ue2nsmRSnFqif3LsWrJJCv0CXyIeD4ZBE8GERNJPC3txJb+5gWx8YzT0pADM6NZHUedE88LRi PU3dgB/jtMnYcaXk8eIN2KbTwlMXHJlpCY36lSTRNygUaQj6OD/1S61uS0k4a64HgXEY5ap4NbGx HfTqMwvTpQv4/0dOvnQ12HEgiYxXwaCU4bfCnAZSMEGf0PTTUhC0Y0indK+DSsSt9dFbwRj37SwI URj0eyEkBce60lTDbptCSsATGi2TFjM6PuqhWRwuzDXZJPNiDqzpdbuGtlx77KviR9/Q1eRG8evd vcL/xq/bTdsDbY8X4SKk7fTs2jykMq4XRzTeu7uSxsv6vVCddgrzCVgg/cSsravavK0iqVRzIhXe ez2Nc3Ew5EmTRqbD/zaRSEn4PbHVjOYgmmmwpJgpy69PmF4Z35jOkfuZTkF+R3R1pp6HJZOuK36N wt7EGlOwzVTw5YYRmsNK667DwhdndJXzx8AXP1OKWIky+EUc+ETuTS9VFDS/Vly0Y+y4avmYzg7K hxehoPcpkXu2AmqjrATrVOitwKmCGz5XFx+uLj6Lq4tPl+dfLs+/Xr5/f3n+8eegzP11EPXHWqA4 bsOsW804epNcs/sNAAD//wMAUEsDBBQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAZHJzL2Rvd25y ZXYueG1sRI/dSsNAEIXvBd9hGcE7u6k/wcZuSxFEQbxo7QOM2ckPZmfT3UmavL2LF3p5OIfv8K23 k+vUSCG2ng0sFxko4tLblmsDx8+Xm0dQUZAtdp7JwEwRtpvLizUW1p95T+NBapUgHAs00Ij0hdax bMhhXPieOHWVDw4lxVBrG/Cc4K7Tt1mWa4ctp4cGe3puqPw+DC6dLPUwvk+7u9P9w8dxPq1Wug5i zPXVtHsCJTTJ/3jweYX+r/xFvVkDOajqdf4Krd1jFAoGklsyTZagNz8AAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAqdlDPm4DAAD1BwAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAAAAAAAAAAAAAAMQFAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAxgYAAAAAAAAQ8AgAAAAUECABYAZAEQ8AEfAQAAAAAADD CwgAAAACAAAABwH/vw8ADfBYAAAAAACfDwQAAAAEAAAAAAChDxoAAAABAAAAAAAgAAoAAAAA/wcA AQAAAAAAAgAOAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAY CQAAEgAK8AgAAAAEiAAAAAoAAIMAC/BaAAAAfwABAO8BgABYg3MfvwAAAAYAvwEBABEA/wERABkA PwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA1 AAAAEwAi8RIIAACpwwwIAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAABbQ29udGVudF9U eXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/ P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bA CbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt7g57S1WtIcbRW8gi apap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SUnfK051I3cRG6zlss 28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEA AAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevuTM6Wscw1efu4lEIv ZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33stodacJSl2T0SVSl RDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfG ctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQ SwMEFAAGAAgAAAAhAP/RnueoAwAA7AkAABAAAABkcnMvc2hhcGV4bWwueG1s7FbNbhs3EL4X6DsQ vCf6iWQ7QtaBbdRpAMUQIgU9GrO7XO9WXHJLcmXJR+d5ihZogV78Nn4Av0JmhivLbouiiXPooXvQ DpdDzjfzzY9evV7XWqyU85U1iRw870uhTGbzylwk8sPi9NmBFD6AyUFboxK5UV6+Pvz2m1fNxDcC Dxs/aRJZhtBMej2flaoG/9w2yuBeYV0NAZfuotc45ZUJENBQrXvDfn+vV0Nl5CFeZVbzZuZIys5W MyeqPJH7Uhio0eSptUE5MdOQqdLqHOWx7HXK8RwgmKnNlr5DBP8GUe7gEt18BEYY+8ahPwMy0GM4 W2QGgZHRphRh0yCuIjiMzVUif2rBIUKJsNeJfNEdjfp4x845j06K9PKdzfE4tMGi8zBZF65+Km66 xxaFIPuD4QijK8UmkXvjF6PBuE+IYKLWQWSoMDx4Od4jhQw1Rvt7w6jQi0hIs3E+vFH2yagEXZRI p7LAnsJq6gMFdmeCzGnzNdyvK8oSXdWJPOjTE70uFeTfmZwjEKDSUUYE2jDDxAnRGtbHNt8QnBTf yFPM7S/PJCwq9L207kqKSweYVJ4SRUmh3xqfyJeD0QhJCLwYjfeHuHAPd9KHO6atT6ymxBRgMrw1 kWErngRcEZ+2biBMzbzJSHHL5GL9A7im4yJgFpzZeQmN+jtKoi4zFMPA/PgwDxutnhoSvmulBxxx mOSqeD9zMR309jMR05lj/F/DJlVdDW7KQULhPQtokt+VybEvsQj6AptgRnWN4BaQzrG6mSfiJkR9 BVNz7JZMRWFNOOJDKXhiFtub6bbxSAnmAjvMrDUZGoiMaKKHXPNNNsuCWAGxep+wnJg7jWNV/FmX 8xrV8Pxu96gI/6DX7abtiXaLNZdC2s6v7sVTdON+cYZ9vquWNJbrY6o69rBoYOIwssu2rmr7YxWD ih4nsgrP3i5ibxyMqNOkHK2o0ibSoAkaK65aYiM0ds6SFEvlaAhx98qoYjpFyme8xdA40dWV+p6X FHJd0VDivZmztmA5r1zA1oZffR1OtAK8tM/ZTjUPE2NPK627xOMv3uoqp48cRBpiCkMVuQnrOAww 4g+1VFFgW9sGqJ2aLoAtXdPJnA48LQqcXYk8chVorNMSnFecchxoBQ907m5+vrv5Tdzd/Hp7/fvt 9R+3Hz/eXv/y10OZ/+xDmDRIGLkYDkV8zsX5uaB+jOlD20wq//y3mSWI/5O5I/MRhUhkw7NtO9Pw T4hvDj8BAAD//wMAUEsDBBQABgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1s RI/LSgNBEEX3gv/QlOAmmJ74zphOCIIoBBeJwXU5XZkZnO6edFfm8fcWLnR5uZdzOYvV4BrVUUx1 8AZm0wwU+SLY2pcG9h8vV4+gEqO32ARPBkZKsFqeny0wt6H3W+p2XCqB+JSjgYq5zbVORUUO0zS0 5KU7hOiQJcZS24i9wF2jr7PsXjusvTxU2NJzRcX37uTkZKZP3WZY3xxv797343E+12VkYy4vhvUT KKaB/8f9hMPn5K/8Rb1ZAw+gDq/jV6ztFhNTNCBuYiqWoJc/AAAA//8DAFBLAQItABQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAP/RnueoAwAA7AkAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQ SwECLQAUAAYACAAAACEA/QKip9YAAAD5AAAADwAAAAAAAAAAAAAAAAD+BQAAZHJzL2Rvd25yZXYu eG1sUEsFBgAAAAAEAAQA9QAAAAEHAAAAAAAAEPAIAAAAFBCwB9AOQBEPABHwEAAAAAAAwwsIAAAA AwAAAAkC/78PAA3wXAAAAAAAnw8EAAAABAAAAAAAqA8OAAAASUVURjg3IGkycnMgV0cAAKEPHgAA AA8AAAAAACAICgAAAAD/AQAHAA8AAAABAAIAAQAOAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8GIJ AAASAArwCAAAAAWIAAAACgAAgwAL8GYAAAB/AAEA7wGAAJhvQRe/AAAABgC/AQEAEQD/AREAGQA/ AwAACACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8A bABkAGUAcgAgADYAAAATACLxQAgAAKnDOggAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAA AFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7 eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURW QhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3u DntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd 8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEA qotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5M zpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey 2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTp mqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rF G7sbAAAA//8DAFBLAwQUAAYACAAAACEAXtIXUdYDAABQCwAAEAAAAGRycy9zaGFwZXhtbC54bWzs Vs1u20YQvhfoOyz2rki0ZNkSQgeWI6UBVEOIVPRYDMmlxWq5y+4uZclFLs7zBAmQAL34bfwAfoXO 7FKW0xZFW/vQQ3SgZrnz/80Pn7/YlJKthbGFVjGPnnU4EyrVWaEuYv7DYtI65sw6UBlIrUTMt8Ly FyfffvO8GtqKobCywyrmS+eqYbtt06UowT7TlVB4l2tTgsOjuWhXRlihHDg0VMr2QafTb5dQKH6C qtR6Xs0MUen5emZYkcUcDSso0eRcFplg53WZCMNmElKx1DJDus/bjUiQBnRpqtOVbfyCf+JXZuAS g/3CJab0K4NRRWSg7Z3a+afQPTJaLZnbVuidlRm6hkm6ivkvNRgnDEf/NzHvNdJBBNXso7QYLUsu v9cZaoDaacwCDDe5KR/rOunRec7Qfv/wsItp5mxLdLcXHXbIIxiKjWMpMhxE3W6fGFLk6B31DwJD O3hCnJWx7pXQj/aKkaKYG5E6Hymsp9ZRbvcmyJxUTxF+WSAGTBYl1lCHfiHqpYBsrDKfAQeFDDR6 IJUHmTAhZN1mpLMtuZPgP+IUivy/FxN2F8a+1OaKs0sDWFeWCkVwJl8rG/NB1OshCM4feodHB3gw D2+ShzeqLs+0pNpkoFLUGnO3I88cnghPXVbgpmpepcS4Q3Kx+RFM1WDhsArO9XwJlfgrSAKvRyik weNj3dxtpXhsSryutYx8xmGYifzNzIRykLvXBExjzvv/FDap60owU58kJN54Ak36/0JlOKA8CfIC pyE2Mrq2gGSOve1RImRc4BYwVSOz8kDkWrlTL5KAJVxxyqnmGkWWoC5wxMxqlaL6gIckcCgwW6Wz 1LE1EKb35erLcs8xEvkfeX1VIxvK729Pc/c3fM1tUp9Js9j4Rkjq+dU9OcEw7g/nOO6bXklCs34J VINdLjM/rX8djMdH/aNR1JpEx6PW5GVv3BpMuv1W1OlFk25nMBgfv3yLVd4MTRzpWMm+8gyisqrL otQ/FwEQzFfMC9d6vQhzNerRlEoCSv5Zx1yhg7SbTLHCIar03FOcrYShTeYnX0rd1jBSL6AWRTtJ FlfiO38kwGRBm83fzYzWOdGURhoMMFR6UkjZVKd/YzVuJHrpc00rT2BGA4RuE5YGAvOQS+Q5zr5d HuupavJck5qG9lXjE5Tjjov5qSlAYjMvwVjh69LjIeABz93N+7ubT+zu5uPt9efb699u3727vf7w Z6HU/mshrC1EhkL82jaUhSdtG3fyEy0/7FZ8Yg+RAaGyGRjAUfi1HTAd/7922AMUvlz8Z8PucwG/ 72x18jsAAAD//wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1s RI/LbsIwEEX3lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy9x110S5Hd3TuPbNFZ2vRUoiV dwrGowwEucLryhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3yQiGuJijgjKlJpcyFiVZjCPf kOPs7IPFxGcwUge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu+Xh5et4e+st0Kk1ISt0Pu+Ub iERd+n8262O2Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA//8DAFBLAQItABQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAF7SF1HWAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQ SwECLQAUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAAAAAsBgAAZHJzL2Rvd25yZXYu eG1sUEsFBgAAAAAEAAQA9QAAAC8HAAAAAAAAEPAIAAAAFBAgEGAVQBEPABHwEAAAAAAAwwsIAAAA BAAAAAgC/78PAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAICgAA AAD/AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAAAPAA AADUAdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABiAAAAAwAAGMAC/AkAAAAgQEAAAAIgwEFAAAIvwEQ ABAA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkA mcwAAA8AiBPOAAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJAQB AAAACg8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAErJxwHg jHi/AAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAA4Exg4AAFBL AwQUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF /oPQtthyuiil2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhcH8ZB7TEm56nSq7zQ Csn6xlFX6c/NS3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6TcBySptD6OwHKNnQlg t9ChuS2KO2M9MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqas7qIQ7og3FPziy5b yHJRzuapdyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3FxtvdKOvIZ+PF7E8Aq/+J /s4089/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SP z2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAW mqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDS SkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9 kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3Ro ZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl 44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXd INa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAvTdf/lEJ AAB8OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPivac4DIZSu0ecmocd zairR/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Opfc6btqirlW7+bOha Xq3rTVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO20vddd3x8eGjXMJy1 P9fHvIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7Bd/LfIu+0b19ffcc5JCeyrrsWBddk8 Id+ckTNizSTkm48mErXN7jkqG+1zVq50g3z0h3dvH7JHRlB2Q7qUfBgdI9h8tKb4EYKyG9J5Bn4F P0KQrdewkOHcYZgYic1oe0T0csjbho/vS/Q9/vZAZmltlCkhopeLAb2ksx4RvXQG9HGQxEkqyUOI KL07oLdiK/YCiZ4Q7cui+jigNgwfPoxakGzr8tdRct+PIoMr/kQF1hfOg1Ns66obcyUdbx6yv+om BQr8UWZdUWndt2O+zdbgokFTZCWKkz3mWW+cDq3bsyGYWGJ3KKpZeZ/YwUynVZE1HuQl/r7dFuuc rHBblOVT963M/92SRbZ1WWxSGMTnCHRzAaHjHi6Z/iW6XZORZ7Sm7v5TdPunfXYEBVEw7lrGetdq x7oFJJKJR3njpKDkjkLWQf+j2myz7rd6Q4ftPpIFG4LrHQkOfCIbGVw7mb183WQmleqi2uSlmUQ0 4jvS0sSSwYbDpcGg0Cb4vJZhTDZdCJ4ou9auszLfoN5plONmwan59cwmYqumC9lnm5yaSBrumc4k tuMuRAI4uNSI6W7TptAaKG1aCOIWPDC8WMmcAVcsWcQ5msqqj62y0r6sdN+xHF1bZ8eVvoWQApeH IxitrXa6lpU7SLrrrqFeO4lF4m2nFfvjXmUafHzgVRKMj03bxVm7pzYkt5ipygpnovJbzgKdbZ4F UEd9gRS2By7y3aQAPcqmzbfbfN31jd0bQd3RnywS1p+6vHnab75oz+Wn5n0G5ged4no2RdutdAJo /NGsdNQ2uSXHVhbXRiocnC0rj/uMRUsPn2Z6puTEVYUM5FdPPFjbqOxkcbcvBRE/11L6bvyDLQXT QV7l9gYtsIYSuck0xOtKr5tuX0MUOu6LddpArUJiB3iLBtEFs60GhTr52+Sf8S/1BcoDuZXFbt+9 L3ZaU0A66fZNnv8BYYl43wQzk6UeypIzIh7VE7c9UrGf8895+QFjoIsxWNf24OokmjD3JHTn/if/ Zgh63mGN0sebFENEVKcY+F8XLhTMsCiwWi/7TSQeTO60QqLPk8d5juwvBG+cqqQFR4WU/Hyfwf6F IlyTgHu5lkaswYothwsHVhRGIf6BpRoMinrmmHV7Df+B/Fc06/JUnn6o30Ns1aCHQ2bgNuDVbzCq wSUGSHr1DHUPHaTOhKzoDKw4Ra3xZD1zFSTmPVM2SsbxNlz9yd43KlsUUfJ0EhaH071c2UzDkq7p 2EVVw2TnEIWhLe9DiGHIdkG/qa+f/wJDx9BefSppm98e4RfBwfGPhnjXc735xi7LliZc6nXYwyBl Wb3Pt1qx+cr7D6EJCiHai/ISmVDjY1i5iQftsaZBfpDR46M0W4qHremHxRNkZgjZ4mHSFI4xgJ0I FrixtQN6osKWrhpUKzRVVq9R2RXCj6tstM+6VmW0UVQa6gUq676qVcY0BcobOl7+tWsyaE2eSPxl SUceRNutOcV9G4pvzFCbW6gdennfhopEEri8DQWe9Ft21J535kpHrGvgvSsd9il1GLNwzMIxuILN SGgU6Q7iSucQYyNwnxmA09h8xOYjCz6y4CMOH4HGlD7u8hEXqjTcXoPtXPyja3wJ0L2ynTcWl4bo GI5cwgsNO/+kbVvfxS9bGtvXZbpG15a2ltMwTp0btm3T1PddzpuZ63viJY2TKJTlV27bJksvcCKm G+YvKL/Yk5W0E0U2FCyMWpBw5xkoE1UjyE9UEKWF8+AzPzZeaIHyT8LLLcccuDOfyscE5CykB4Uz DxrQf9f8EgWJdSa/Ei+hH/rJ8lq84KFOxNE1jZcgdZdCmDtexo8FF6Skfg1e4FzLTXk9OcOx4E35 pX8k2UtCl/DixZErXKJHRC+H9VgSpUEq+ychovSvPxYcOXZU4mWZhvb1eIGTY/cGvBhGAO06A+Md L+N4cV6NF7R5zHuCGfCyJB9mtql6DCeX/VmZXzDeCg+6Ai/IPuFr64FqVrwEUr5Q4sWKMcNI9Ipj 9DR14DyIUU/nFyxW73iBN01Y1Ul3BM76fVeBFydwPKZtloAYHKQaB31KxGwlXnqvk7D3UsZeO0Fu 4mWJCbxABF24luQ/Sry4sZtGMr6U9VgQREbEPe4KvMQBfiV5SBKijxIoSLoLgtALZXmUeHEtdxEu JP4KvBhGzzLTeEHyG/FCOnrS74PhWb8PrsL6fTAe78phR4DqAO7Ri//Tfn95ES9OZJ7UNwNeyNY8 9z0FXuI0tnzeA0/gRepomUEwOjCTDFraMFn6LpehR0Qvh/VYZATwkfxTWY/dipfEAnjJ/JV4CSI3 duT9CgVepMgzjZfYDiyTJ6/r6rEfDy/eRbwYhm2LvaQZ8IInViJvKPCCHXkvX/Xi//C1RpTwrL5S 5hfDCE/nZlfgBdESyf48K16COPQSOT8q8QIaPMUwKr8CL6gboclpvEDpuTRMFhzueBnvX+hbwwwO Uq2Avtjzb+KHr6vHEDHMHAq8JHYS9vYPlHhBTAsZqf8o8bJwvWARSvmix3+YXxAvZ/F/XrwEQXyG RyVe7HQZL3junR0vRgJn1Xe85Kr+xaTHt2OAkRrvGRKM67mhE08DJjZjM+JOPVGQ+YZveHKAVgLG M/wk4E3ZFQkG2usglAugWQETufDlMZ3KowTM0vZSX5ZfkWDSNIpEiTCdYBI/jsRuwj3BjCcY8/J/ NLEh1IvTsTkA40oZi0R2hgcps2E9JuqICcC4huMvObiuyDAggit4XwMYL/TOMsCsgAkhhoTyCZIS ME7kRNfvKEvnU9OAQbWLdH0HzAXAXD7ih/8FZJiOyAivLskcy04sHq0VJVmcRobHM9EEYLxoGS55 FXEFYLzUSS3ZQZUlWWgHacAP/Sj/WQETAVxCGfBKwHim41hyS6XIMFEUwiurzILTgPEiSL+c/EcC DLzEIL8TQ14sg1HyKuS7vwEAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVt ZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQ rdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCC jm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvV ABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1lL3RoZW1lL3Ro ZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAvTdf/lEJAAB8OQAAFgAAAAAAAAAAAAAAAADT AgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAA AAAAAAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUG AAAAAAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJV VEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9 ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2Nl bnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1 IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAA DSsEAAAAoFme1AAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oAi7S2RfWHVgnJ23ftpBRKyGnR rmbmY1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwgyXV/fbXaHDKSYHWkTk615ket yUwYgFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9FS97Xh9JWC7F0/HfHNVJyNk7 A5VB9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5DYA5tC+nqAjf0FoekLpOeCUzD 4AzaZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAIAAAAIQAXS2h7ugAAACgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUDQrJtg80mZKPo35tjBcHj7DBv dprTy8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrVXHHWuYR4cpFFoRArmHKORynZ TOg1VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9jaf7PDsPgDJ6DeXik/KNCZufL sI6GUKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgAAAAhACVGREEHAQAAygEAABIA AABkcnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2e1k8eZL6A0Iy3Q00MyGZdd1/ 77RbBfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxetClv0diaEXl+g6N1wf9ellkOU V0oMsLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020AfWmz7foaZqCgz25UwTkq0mG 2bLAl2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLYgB6mgIFBK/Fhm7nXCNKkVkge xkuStji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkNR+bGt2zrNwzfAAAA//8DAFBL AQItABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAAAAAAKQEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAAAAAAAAAAAAAADAIAAGRycy90 aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAABAAB4EgQYAAFBLAwQUAAYACAAAACEA R3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemC xwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHB KBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKD d80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZ GmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8D AFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7T ehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0 BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAs mOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA //8DAFBLAwQUAAYACAAAACEA++1mElADAAAFDgAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxLnhtbOxX23LaMBB970z/QeP3xGAMIZ5AZkqbvOTCFPIBii1iN7KkkRQH8vVdrS0uCSnQ 5qUzeQFZOjra3bOry9n5vOSkYtoUUgyC9nErIEykMivEwyC4m14c9QNiLBUZ5VKwQbBgJjgffv1y phLDsyu6kE+WAIcwCR0EubUqCUOT5qyk5lgqJmBsJnVJLXzqhzDT9Bm4Sx5GrVYvLGkhgma+3me+ nM2KlH2X6VPJhK1JNOPUgv0mL5TxbGofNqWZARqcvWmSXSjw1j7L2/tfAUGcrqCnHQzB9XTCMyJo CR3TZ0lGUligwSGjppoxBxLVpVYTNdY446Yaa1JkjqGZGYTNQAPDTwEwaISvpj94JprMZ7ocntEE IkHmgwAEW7hfmEQTNrckrTvTVW+a327BpvmPLejQLwAWLBcFrVXt0Vt3Iu/OtLCckfbSqxpKYeqV TB8NERL8dO7X7qU3lSdzPjt6lZMm7I6qwdWDGA+PNxhTb+gyEnH3BHIKwxGdxL1OfzMm/Sg67blx F5l2O+604MPZsiJS2thLJkvQ29hBoFnqNKUJra6MraEeghLVhqjEzr/JbOGQ9/APOkNBwfxc6pfa Bm7sxC44Q5EglDQBh+EHoJy6SmPi6G4ClVbaEWcUKrER1A5HvEgfiZWEZYUl19RYponFWBtH6ey3 6AVSMpGNqaY/XzE3xqPV3lqIaS3r++J2vLhNhpMxpynLJc/AiMj5BrXghTxQavMCEaJ8FkBVQMr6 vPgrvdsgrNMe4+uLIG51+kvB427UPe11NgTHANSp52PiFUQir5qTile83aRdxmYuvM7+qL/MoTUA NKMt2Hgd6wGA7WzBrnJzDQDN+C22vWGDBwC2uwvrAYDt7cJ6AGBPdmE9ALD9XVgPAOzpLmwNgHxf FwarCWYSYFiWzT9Wl8sgLC6zUV2wcr2aS4jlkpi4BxT0hKVSZISzivE96LHKDqCf5oXenx0L4gD2 C/mkbb638XFdkXvLcVHMtrLDyfah+1r8p30NY/Jh+xrqh8eX22mwsesc68V9f5B9bmx4tEFtf25s H3Bt+NzY3rtm/UcbG15b6kcGNN1TBK9hXF9TdVvhXguPL7gmjrBLwXPLXf8AuoI4Dv98G/4GAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA++1mElADAAAFDgAAIQAAAAAAAAAAAAAAAAATAgAA ZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAKIFAAAAAAAA HQQEAAAAAQAAACAAug8SAAAANABfAGkAZQB0AGYALQA2ADkADwD4A1RGAAACAO8DGAAAAAEAAAAB AgcJCAAAAAAAAAAAAAAAAgD/v2AA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD731MA/5lmAMwzAACZZgAAYADwByAAAAD///8AAAAA AICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA8AcgAAAA3vbxAAAAAACWlpYAAAAAAP///wCNxv8A AGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3AAAAAAD///cAM8zMAP9QUAD/mQAAYADwByAAAAAA gIAA////AABaWAD//5kAAGRiAG1vxwAA//8AAP8AAGAA8AcgAAAAgAAAAP///wBcHwAA39KTAMwz AAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD///8AADNmAMz//wAzZswAALAAAGbM/wD/5wEAYADw ByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAAaGtdAP///wB3d3cA 0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAAAGZmmQD///8APj5cAP///wBgWXsAZmb/AJnM/wD/ /5kAYADwByAAAABSPiYA////AC0gFQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAAow8+AAAAAQD//T8A AAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//LAAAAAADAAAQ AKMPgAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAIAAAD//+8AAAAAAAEA AAD//xgAAAAAAQAAgAUAABMg1AEgAQAAIgD//xQAgAUAACIg0AJAAgAAAgASAIAFAAATIPADYAMA AAIAEACABQAAuwAQBYAEAAACAA4AIACjD3AAAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAA AABAAgAAAAACAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASABAAAgAP//AAUAAEACQAIA AAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQA AAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABA AkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAA AQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAAB AIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAUAAEAAAAAAAAA AgASAAIAAAAAAAAAAgAQAAMAAAAAAAAAAgAOAAQAAAAAAAAAAgAMAIAAow8+AAAABQAAAAAAAAAA AAIAEgABAAAAAAAAAAIAEAACAAAAAAAAAAIADgADAAAAAAAAAAIADAAEAAAAAAAAAAIACgAAACME GAcAAFBLAwQUAAYACAAAACEAmxMFu/oAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtq wzAQRfeF/oPQtlhyuiil2M6ij10fi/QDBnlsi+qFRgnJ33fspBBKyGqYx517uM16753YYSYbQytX qpYCg4m9DWMrvzdv1aMUVCD04GLAVh6Q5Lq7vWk2h4QkWB2olVMp6UlrMhN6IBUTBt4MMXso3OZR JzA/MKK+r+sHbWIoGEpV5h+ya15wgK0r4nXP4yMJy6V4Pt7NVq2ElJw1UBhUz1t9UZfR0RXhLvT/ 6KoTmWLl8pwmm+ju5PDJ0WTbo/iCXD7AM4fuM2lyPHwHKpzcebNS18Ev+MdhsAb7aLaeM1EpI3Fd ULxTZ0Z/THqJvvsFAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJl bHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcK qqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8z pizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT +dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQABq9yK6AMAAD8mAAAhAAAAZHJzL3Ns aWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FpLbtswFNwX6B0EbgPHlvyRbFgOkhRZZRE0yQFo mbLVUJRAMWncVZEcoTfovmiBFuiiWfUo9QFyhZIUZUu27KpGgtiwdor5ETlDvTfDl+7BrY+1G0Qj LyA20PdrQEPECQYeGdrg8uKkYgEtYpAMIA4IssEYReCg9/pVN+yw23M2xijS+BQk6kAbjBgLO9Vq 5IyQD6P9IESEt7kB9SHjf9JhdUDhez61j6tGrdaq+tAjQI2nRcYHrus56E3gXPuIsHgSijBkfPnR yAujZLawyGwhRRGfRo7OLKkntucxjOQOe13YwTdYD8+oBvGQ4+QwCjTKsA0EXvCUHNEr+ewGhB3K Ln0YIaCNIBny/Z5dE4eJDmKqKHSOkKuezhym3UA5UbXXrc61HrpsRT/VOkDuW76y6IMNGo2aekeA vcGJh7EcLvhAx5jGb2K3BlDvSvcSIBKNjUPkQoczvee/q2AmesIOgqmGx4cvjw/ftceHb5O7H5O7 n5P7+8ndV6A5I0gjJLcpBznRfw/i+493I6FQmIsF8Edjt+A/pB7EQAs95oxOoO/hsQ0qeq29iPOL kSMYUeTUS3I2jBzBiCKnUZKzYeQIRhQ5zZKcDSNHMKLIaQlyfEhPeWptmlyygDwBMJf0xdgtyfFF k8xCXhbAKIzMGUZtXQqQEiMpWAQwCiNrhpFeN/VWeZASgSeQUSC1UyBZhmWVICUgCWT4c9aThJ1+ MBgvGJQ4WtUbRlvg55EBNzhcOSY/xP6FC8undS88NPLXretg+tfH3DtIA2GDPx8/x6Yj5WuMYr5G T1aw2teQzfM1MWsmZ62ZZs2wmqb4YRtY+7TImjgTMhum+ZC3A2k3+jysrTJOFd2w1FHJ2s15RxPT ouuNutjK7GsyDCsVw7foa9oqNuYtjGKDIy+V2DS2bRMbi1+JVANbxcu8e4l5MWpNU4TpbfxKfv9a CF76S6actYJXvm8xmnpDxqp/fy6FfcwTZvsc5MXs25U28t2Q0TZ1KWJL5ItcH6915vM9Vix2C4Wi 8syvvmNeKpXyjVvdsloFk3OJ/JrIT91gyv+FnYCNEJ26QS5rz2JjrVwU5oUoGyBSuTyfKV/VJalt xXk8bTf44AvYPxeVJXX9tWAbdaDJytGsBpateekylKtViBpVHBOvEBX1RnFWnlv77PmkgmCc4DM1 KdHgRDM4eBUtcdyi1ifWldSdYmgSEKZ2bGfxyTdK2fs/bot2Fp8l1iV797fLAOV7CD1777fLAC1R 8/LioQzRPC4vEd1moy4FSBmjl2hjjo606SVASyRsq2lmL/d2NotNlWZaXIoyhPrPr95fAAAA//8D AFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKwEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAAAAAAAAAAAAAAAAEgIAAGRy cy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAAA5BgAAAAAPAAwE Mx0AAA8AAvArHQAAMAII8AgAAAAFAAAABYwAAA8AA/DPHAAADwAE8CgAAAABAAnwEAAAAAcAAAAH AAAAAgAAAPiFpSUCAArwCAAAAACMAAAFAAAADwAE8C4BAAASAArwCAAAAAKMAAAACgAAgwAL8EgA AAB/AAEA7wGAAJhnqSW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0 AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAP+/ DwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5 bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIP HgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDZ CAAAEgAK8AgAAAADjAAAAAoAAIMAC/BWAAAAfwABAO8BgABoa6klvwAAAAYAvwEBABEA/wERABkA PwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADYAAAAT ACLx2wcAAKnD1QcAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1 dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwR SSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5 lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L 91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAA AF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BB v9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCW krZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz3 3j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQU AAYACAAAACEAaD3JT3IDAAD1BwAAEAAAAGRycy9zaGFwZXhtbC54bWysVVFPIzcQfj+p/8HyOySB kKMRywlooSflUHQB9Xl218tu4x1vbW9IeOR+z+kqtVJf+Df8AP5CZ+wN4XqnqnfAAxmvZzzffN94 fPBmWWuxUNZVBhM52O5LoTAzeYVXiby8ON3al8J5wBy0QZXIlXLyzeEPrw6asWsEBaMbN4ksvW/G vZ7LSlWD2zaNQtorjK3B09Je9RqrnEIPnhLVurfT7496NVQoD+koXMyaqWUrO19MrajyRI6kQKgp 5U/glZhqyFRpdK6sGMle5xqjgKBMTDZ3HR74P3hyC9dU5GdQBJozS9UMOEEvgFnjQoLFSZtS+FVD qHJPxNxQJtCFJMDLRO50YdGX4jdlOSpPpNfvTE6h0HpDZcN4Wdj6uZj5HFMUgvIP914TrVKsiLy9 3eFgr8+AYKyWXmSMb7C7O2KHjDyGr0c70aEXgbBnY50/U+bZoAQflEirMh8KhcXEeeZ0k4LTaXyJ 6uvKU1Poqk7kfp//YtWlgvxnzAMDHiodbUKgMYjLkrCifnls8hXDSemXZIpN/f1NRLeJai+NvZHi 2gL1k/u9Bauk0G/RJfLHwXBIIviwCJpJYZ/upE93sK1PjOaeFIAZnZpI6rxonnhasZ6mbsBPcNZk 7LhW8mL5K9im08JTF5ybWQmN+pok0TcoFGkI+jg/8yutnktJOGuhB4FxGOeqeD+1sR30+jML06UL +F8iJ1+6GuwkkETG+2BQyvBbYU4DKZigr2j6aSkI2gWkM7rXQSXi1vrorWCCx3YehCgM+qMQkoJj XWmqYbdNISXgFY2WaYsZHR/10CwOF+aabJp5sQDW9LFdQ1tuPI5V8W/f0NXkRvGb3aPC/4dft5u2 J9peLMNFSNvZzaN5SmU8Ls5pvHd3JY2X9XOhOu0U5lOwQPqJeVtXtfmtiqRSzYlUuHU5i3NxMORJ k0amw/82kUhJ+D2x1ZzmIJpZsKSYK8uvT5heGd+YzpH7mU5Bfkd0daN+CUsmXVf8GoW9qTWmYJup 4MsNYzSnldZdh4Uvzugq54+BL36mFLESZfDLOPCJ3Kdeqihofq25aCfYcdXyMZ0dlA8vQkHvUyKP bAXURlkJ1qnQW4FTBU98Hu4+Ptz9KR7u/ri//ev+9u/7Dx/ubz99GZS5bw6i/tgIFMdtmHXrGUdv kmsO/wEAAP//AwBQSwMEFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxE j91Kw0AQhe8F32EZwTu7qT/Bxm5LEURBvGjtA4zZyQ9mZ9PdSZq8vYsXenk4h+/wrbeT69RIIbae DSwXGSji0tuWawPHz5ebR1BRkC12nsnATBG2m8uLNRbWn3lP40FqlSAcCzTQiPSF1rFsyGFc+J44 dZUPDiXFUGsb8JzgrtO3WZZrhy2nhwZ7em6o/D4MLp0s9TC+T7u70/3Dx3E+rVa6DmLM9dW0ewIl NMn/ePB5hf6v/EW9WQM5qOp1/gqt3WMUCgaSWzJNlqA3PwAAAP//AwBQSwECLQAUAAYACAAAACEA Mjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQBoPclPcgMAAPUHAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsB Ai0AFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAAAAAAAAAAAAAAAAyAUAAGRycy9kb3ducmV2Lnht bFBLBQYAAAAABAAEAPUAAADKBgAAAAAAABDwCAAAABQQIAFgBkARDwAR8BAAAAAAAMMLCAAAAAIA AAAHAf+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAACAACgAAAAD/BwABAAAAAAAC AA4AAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BgJAAASAArw CAAAAASMAAAACgAAgwAL8FoAAAB/AAEA7wGAAIiWqSW/AAAABgC/AQEAEQD/AREAGQA/AwAACACA wyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADcAAAATACLx EggAAKnDDAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54 bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrV jIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZd SBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs4 8glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4 C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9y ZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3 Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZa ix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6i ahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYA CAAAACEABKPLJ6gDAADsCQAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1uGzcQvhfoOxC8J/qJ/BMh 68A26jSAYgiRih6N2V2uxYpLbkmuLPnoPE/RAi3Qi9/GD+BX6MxwZdltUbR1Dj10D9rhcsj5Zr75 0Zu369qIlfJBO5vJwcu+FMoWrtT2MpPfzM9eHEoRItgSjLMqkxsV5NujL79404xDI/CwDeMmk4sY m3GvF4qFqiG8dI2yuFc5X0PEpb/sNV4FZSNENFSb3rDf3+/VoK08wqvsatZMPUnF+WrqhS4zeSCF hRpNnjkXlRdTA4VaOFOifCB7nXI6Bwhm4opl6BDB30FUerhCN5+AEda98+jPgAz0GM4WmUVgZLRZ iLhpEFcVPcbmOpPft+ARoUTY60y+6o4mfbxj51xAJ0V+9cGVeBza6NB5GK8rXz8XN93jqkqQ/cFw hNGVYpPJ/b1Xo8FenxDBWK2jKFBhePh6b58UCtQYHewPk0IvISHNxof4TrlnoxJ0USa9KiJ7CqtJ iBTYnQkyZ+zncL/WlCVG15k87NOTvF4oKL+yJUcggjZJRgTGMsPECdEa1yeu3BCcHN/IU8rtf59J WFTo+8L5aymuPGBSBUoUJYV5b0MmXw9GIyQh8mK0dzDEhX+8kz/esW196gwlpgBb4K2ZjFvxNOKK +HR1A3FiZ01Bilsm5+tvwTcdFxGz4NzNFtCoP6Mk6TJDKQzMT4izuDHquSHhu1ZmwBGHcamqj1Of 0sFsPxMxnTnG/zlsUtXV4CccJBQ+soAm+a1tiX2JRTCX2AQLqmsEN4d8htXNPBE3MekrmNgTv2Qq KmfjMR/KIRCz2N5st41HFmAvscNMW1uggcSIIXrItdAU0yKKFRCrDwnLibnTOFHV73U5r1ENz+92 j6v4F3rdbt6eGj9fcynk7ez6QTxDNx4W59jnu2rJU7k+papjD4sGxh4ju2xrXbvvdAoqepxJHV+8 n6feOBhRp8k5WkmlzaRFEzRWvF5iI7RuxpIUS+VpCHH3KqhiOkXKZ7zF0jgx+lp9zUsKudE0lHhv 6p2rWC61j9ja8Guo46lRgJf2Odup5mFs3Zk2pks8/hKc0SV95CDSEFMYqsRNXKdhgBF/rKWqCtva NkDtxHYBbOmaTuZ04GlR4ezK5LHXYLBOF+CD4pTjQCt4pHN/+8P97c/i/vanu5tf7m5+vfv06e7m xz8eKsI/PoRJg4SRi/FIpOdCXFwI6seYPrTNpPLPf5tZgvg/mTsyn1CIRDY827YzDf+EhOboNwAA AP//AwBQSwMEFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tKA0EQ RfeC/9CU4CaYnvjOmE4IgigEF4nBdTldmRmc7p50V+bx9xYudHm5l3M5i9XgGtVRTHXwBmbTDBT5 Itjalwb2Hy9Xj6ASo7fYBE8GRkqwWp6fLTC3ofdb6nZcKoH4lKOBirnNtU5FRQ7TNLTkpTuE6JAl xlLbiL3AXaOvs+xeO6y9PFTY0nNFxffu5ORkpk/dZljfHG/v3vfjcT7XZWRjLi+G9RMopoH/x/2E w+fkr/xFvVkDD6AOr+NXrO0WE1M0IG5iKpaglz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77 AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEABKPLJ6gDAADsCQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQA BgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAAAAAAAAAAAAAAP4FAABkcnMvZG93bnJldi54bWxQSwUG AAAAAAQABAD1AAAAAQcAAAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAQAAAAAADDCwgAAAADAAAACQL/ vw8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRGODcgaTJycyBXRwAAoQ8eAAAADwAAAAAA IAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADwAAAA1AHQAvADEAUPAATwYAkAABIACvAI AAAABYwAAAAKAACDAAvwZgAAAH8AAQDvAYAAaKapJb8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDD NgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQBy ACAAOAAAABMAIvE+CAAAqcM4CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE 0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDne GsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG 0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ER us5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAA AI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7 uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk 9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzN LNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD/ /wMAUEsDBBQABgAIAAAAIQDybQm51AMAAFALAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWzW7jNhC+ F+g7ELx7bceykxqrLBw33i7gBsbaRY/FSKIi1RSpkpRjp+gl+zyLLdACveRt8gB5hc6Qcpxti6Jt cuhhfZCH4vx/86OXr7aVZBthbKlVzPsvepwJleqsVJcx/2Y165xwZh2oDKRWIuY7Yfmr088/e1mP bc1QWNlxHfPCuXrc7dq0EBXYF7oWCu9ybSpweDSX3doIK5QDh4Yq2T3q9UbdCkrFT1GV2izrhSEq vdgsDCuzmKNhBRWaXMoyE+yiqRJh2EJCKgotM6RPeLcVCdKALs11uratX/BP/MoMXGGwH7nElH5t MKo+Geh6p/b+KXSPjNYFc7savbMyQ9cwSdcx/6EB44Th6P825lErHURQzSFKi9Gy5OprnaEGaJzG LMB4m5vqqa6THp3nDO2PhsMBppmzHdGDqD/skUcwFlvHUmQ46g8GI2JIkSM6Hh0Fhm7whDhrY91r oZ/sFSNFMTcidT5S2Myto9weTJA5qZ4j/KpEDJgsK6yhHv1C1IWA7FxlPgMOShlo9EAqDzJhQsi6 7ZnOduROgv+IUyjy/15M2F0Ye6HNNWdXBrCuLBWK4Ey+UTbmX/SjCEFw/hANj4/wYB7fJI9vVFNN taTaZKBS1BpztyenDk+Ep65qcHO1rFNi3CO52n4Lpm6xcFgFF3pZQC3+CpLA6xEKafD4WLd0Oyme mhKvayP7PuMwzkT+dmFCOcj9awKmNef9fw6b1HUVmLlPEhJvPYEm/X+pMhxQngR5idMQGxldW0Gy xN72KBEyLnALmKszs/ZA5Fq5iRdJwBKuOOVUe40iBahLHDGLRqWoPuAhCRwKzNbpInVsA4TpQ7n6 sjxwnIn8j7y+qpEN5Q+3k9z9DV97mzRTaVZb3whJs7x+IGcYxsPhAsd92ytJaNaPgWqxy2Xmp/WP 0+NBvzeYTTvDyWTSGZxHs84kOp90RtHxyfkEp890+OVPWOXt0MSRjpXsK88gKuumKiv9fRkAwXzF vHSdN6swV/sRTakkoOSfTcwVOki7yZRrHKJKLz3F2VoY2mR+8qXUbS0j9QJqUbSTZHktvvJHAkyW tNn83cJonRNNaaTBAGOlZ6WUbXX6N1bjRqKXPte08gRmNEDotmFpIDCPuUSe4+zb57GZqzbPDalp aV81PkE57riYT0wJEpu5AGOFr0uPh4BHPPe37+9vf2H3tz/f3fx6d/Pb3bt3dzcf/iyU2n8thLWF yFCIn9qGsvCsbeNOv6Plh92KT+whMiBUtgADOAo/tQOm4//XDgeAwpeL/2zYfy7g952tT38HAAD/ /wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3 lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy9x110S5Hd3TuPbNFZ2vRUoiVdwrGowwEucLr yhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3yQiGuJijgjKlJpcyFiVZjCPfkOPs7IPFxGcw Uge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu+Xh5et4e+st0Kk1ISt0Pu+UbiERd+n8262O2 Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAA AOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh AKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh APJtCbnUAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYA CAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAAAAAqBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAA AAAEAAQA9QAAAC0HAAAAAAAAEPAIAAAAFBAgEGAVQBEPABHwEAAAAAAAwwsIAAAABAAAAAgC/78P AA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAICgAAAAD/AgAHAAIA AAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQ BQ8ABPA8AAAAEgAK8AgAAAABjAAAAAwAAGMAC/AkAAAAgQEAAAAIgwEFAAAIvwEQABAA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBPO AAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAAAAAAJAQBAAAACg8AihOV AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAErJxwHgjHi/AAAdEAQA AAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAA AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAA4EyA4AAFBLAwQUAAYACAAA ACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil 2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhcH8ZB7TEm56nSq7zQCsn6xlFX6c/N S3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6TcBySptD6OwHKNnQlgt9ChuS2KO2M9 MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqas7qIQ7og3FPziy5byHJRzuapdyHd LAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3FxtvdKOvIZ+PF7E8Aq/+J/s4089/WXwAA AP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9 g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to 4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eR cV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4 +db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1l TWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtL DVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzd Xrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAjSWgxlMJAAB8OQAAFgAA AHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPivac4DIZSu0ecmocdzairR/u4omxs M43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Opfc6btqirlW7+bOhaXq3rTVHtVvqf H9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO20vddd3x8eGjXMJy1P9fHvIJ727o5 ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7B1/lvk3faN6+vvOOekBPZV1+LAumyekG/OyBmxZhLy zUcTidpm9xyVjfY5K1e6QT76w7u3D9kjIyi7IV1KPoyOEWw+WlP8CEHZDek8A7+CHyHI1mtYyHDu MEyMxGa0PSJ6OeRtw8f3Jfoef3sgs7Q2ypQQ0cvFgF7SWY+IXjoD+jhI4iSV5CFElN4d0FuxFXuB RE+I9mVRfRxQG4YPH0YtSLZ1+esoue9HkcEVf6IC6wvnwSm2ddWNuZKONw/ZX3WTAgX+KLOuqLTu 2zHfZmtw0aApshLFyR7zrDdOh9bt2RBMLLE7FNWsvE/sYKbTqsgaD/ISf99ui3VOVrgtyvKp+1bm /27JItu6LDYpDOJzBLq5gNBxD5dM/xLdrsnIM1pTd/8puv3TPjuCgigYdy1jvWu1Y90CEsnEo7xx UlByRyHroP9RbbZZ91u9ocN2H8mCDcH1jgQHPpGNDK6dzF6+bjKTSnVRbfLSTCIa8R1paWLJYMPh 0mBQaBN8XsswJpsuBE+UXWvXWZlvUO80ynGz4NT8emYTsVXTheyzTU5NJA33TGcS23EXIgEcXGrE dLdpU2gNlDYtBHELHhherGTOgCuWLOIcTWXVx1ZZaV9Wuu9Yjq6ts+NK30JIgcvDEYzWVjtdy8od JN1111CvncQi8bbTiv1xrzINPj7wKgnGx6bt4qzdUxuSW8xUZYUzUfktZ4HONs8CqKO+QArbAxf5 blKAHmXT5tttvu76xu6NoO7oTxYJ609d3jztN1+05/JT8z4D84NOcT2bou1WOgE0/migECJ34JYc W1lcG6lwcLasPO4zFi09ZMz0TMmJqwoZyK+eeLC2UdnJ4m5fCiJ+rqX03fgHWwqmg7zK7Q1aYA0l cpNpiNeVXjfdvoYodNwX67SBWoXEDvAWDaILZlsNCnXyt8k/41/qC5QHciuL3b57X+y0poB00u2b PP8DwhLxvglmJks9lCVnRDyqJ257pGI/55/z8gPGQBdjsK7twdVJNGHuSejO/U/+zRD0vMMapY83 KYaIqE4x8L8uXCiYYVFgtV72m0g8mNxphUSfJ4/zHNlfCN44VUkLjgop+fk+g/0LRbgmAfdyLY1Y gxVbDhcOrCiMQvwDSzUYFPXMMev2Gv4D+a9o1uWpPP1Qv4fYqkEPh8zAbcCr32BUg0sMkPTqGeoe OkidCVnRGVhxilrjyfosmL62UBXznikbJeN4G67+ZO8blS2KKHk6CYvD6V6ubKZhSdd07KKqYbJz iMLQlvchxDBku6Df1NfPf4GhY2ivPpW0zW+P8Ivg4PhHQ7zrud58Y5dlSxMu9TrsYZCyrN7nW63Y fOX9h9AEhRDtRXmJTKjxMazcxIP2WNMgP8jo8VGaLcXD1vTD4gkyM4Rs8TBpCscYwE4EC9zY2gE9 UWFLVw2qFZoqq9eo7Arhx1U22mddqzKKP6WhXqCy7qtaZUxToLyh4+VfuyaD1uSJxF+WdORBtN2a U9y3ofjGDLW5hdqhl/dtqEgkgcvbUOBJv2VH7XlnrnTEugbeu9Jhn1KHMQvHLByDK9iMhEaR7iCu dA4xNgL3mQE4jc1HbD6y4CMLPuLwEWhM6eMuH3GhSsPtNdjOxT+6xpcA3SvbeWNxaYiO4cglvNCw 80/atvVd/LKlsX1dpmt0bWlrOQ3j1Llh2zZNfd/lvJm5vide0jiJQll+5bZtsvQCJ2K6Yf6C8os9 WUk7UWRDwcKoBQl3noEyUTWC/EQFUVo4Dz7zY+OFFij/JLzccsyBO/OpfExAzkJ6UDjzoAH9d80v UZBYZ/Ir8RL6oZ8sr8ULHupEHF3TeAlSdymEueNl/FhwQUrq1+AFzrXclNeTMxwL3pRf+keSvSR0 CS9eHLnCJXpE9HJYjyVRGqSyfxIiSv/6Y8GRY0clXpZpaF+PFzg5dm/Ai2EE0K4zMN7xMo4X59V4 QZvHvCeYAS9L8mFmm6rHcHLZn5X5BeOt8KAr8ILsE762HqhmxUsg5QslXqwYM4xErzhGT1MHzoMY 9XR+wWL1jhd404RVnXRH4KzfdxV4cQLHY9pmCYjBQapx0KdEzFbipfc6CXsvZey1E+QmXpaYwAtE 0IVrSf6jxIsbu2kk40tZjwVBZETc467ASxzgV5KHJCH6KIGCpLsgCL1QlkeJF9dyF+FC4q/Ai2H0 LDONFyS/ES+koyf9Phie9fvgKqzfB+Pxrhx2BKgO4B69+D/t95cX8eJE5kl9M+CFbM1z31PgJU5j y+c98ARepI6WGQSjAzPJoKUNk6Xvchl6RPRyWI9FRgAfyT+V9diteEksgJfMX4mXIHJjR96vUOBF ijzTeIntwDJ58rquHvvx8OJdxIth2LbYS5oBL3hiJfKGAi/YkffyVS/+D19rRAnP6itlfjGM8HRu dgVeEC2R7M+z4iWIQy+R86MSL6DBUwyj8ivwgroRmpzGC5SeS8NkweGOl/H+hb41zOAg1Qroiz3/ Jn74unoMEcPMocBLYidhb/9AiRfEtJCR+o8SLwvXCxahlC96/If5BfFyFv/nxUsQxGd4VOLFTpfx gufe2fFiJHBWfcdLrupfTHp8OwYYqfGeIcG4nhs68TRgYjM2I+7UEwWZb/iGJwdoJWA8w08C3pRd kWCgvQ5CuQCaFTCRC18e06k8SsAsbS/1ZfkVCSZNo0iUCNMJJvHjSOwm3BPMeIIxL/9HExtCvTgd mwMwrpSxSGRneJAyG9Zjoo6YAIxrOP6Sg+uKDAMiuIL3NYDxQu8sA8wKmBBiSCifICkB40ROdP2O snQ+NQ0YVLtI13fAXADM5SN++F9AhumIjPDqksyx7MTi0VpRksVpZHg8E00AxouW4ZJXEVcAxkud 1JIdVFmShXaQBvzQj/KfFTARwCWUAa8EjGc6jiW3VIoME0UhvLLKLDgNGC+C9MvJfyTAwEsM8jsx 5MUyGCWvQr77GwAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1l L19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUN Nj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeR SyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z /TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJvo cE/8AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAtAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAWAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5h Z2VyLnhtbFBLAQItABQABgAIAAAAIQCNJaDGUwkAAHw5AAAWAAAAAAAAAAAAAAAAANMCAAB0aGVt ZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAA AAAAWgwAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAF AF0BAABVDQAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBz dGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVu eG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBi ZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFj Y2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2Vu dDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAANKwQAAAC8 8pX/AAALKxMEAABQSwMEFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAABbQ29udGVudF9UeXBlc10u eG1sfJDNasMwEITvhb6D0LVYcnsopcTOoT/QS9tD+gCLtLZF9YdWCcnbd+2kFErIadGuZuZjVut9 8GKHhVyKnbxVrRQYTbIujp382rw2D1JQhWjBp4idPCDJdX99tdocMpJgdaROTrXmR63JTBiAVMoY +TKkEqDys4w6g/mGEfVd295rk2LFWJs6e8h+9YwDbH0VL3teH0lYLsXT8d8c1UnI2TsDlUH1fNVn dQU9XRDuov1H15zIFCsXc5pcpptTwgdXU5xF8QmlvkNgDm0L6eoCN/QWh6Quk54JTMPgDNpktoFL ULkg8Vyyg1d/zr8Meqm6/wEAAP//AwBQSwMEFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAABfcmVs cy8ucmVsc4SPwQrCMBBE74L/EPZuUz2ISFMvIvQq9QNCsm2DzSZko+jfm2MFwePsMG92mtPLz+KJ iV0gBduqBoFkgnU0Krj1l80BBGdNVs+BUMEbGU7tetVccda5hHhykUWhECuYco5HKdlM6DVXISIV ZwjJ61xkGmXU5q5HlLu63su0ZED7xRSdVZA6uwXRv2Np/s8Ow+AMnoN5eKT8o0Jm58uwjoZQqDqN mBXYxIt7Vf4F2Tbya1/7AQAA//8DAFBLAwQUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAGRycy90 aW1pbmdJbmZvLnhtbIyRQUvEMBCF74L/IeRu04qIlLZ7WTx5kvoDQjLdDTQzIZl13X/vtFsF8bKn mZC8x/deut1XnNUn5BIIe91UtVaAjnzAQ68/xteHF60KW/R2JoReX6Do3XB/16WWQ5RXSgywtLbX R+bUGlPcEaItFSVAuZsoR8tyzAfjsz2LJM7msa6fTbQB9abPt+hpmoKDPblTBOSrSYbZssCXY0jl xy3d4pYyFLFZ1X+QhiUcvhVelmTzMtyIKnhpSCt/EtiAHqaAgUEr8WGbudcI0qRWSB7GS5K2OL4T 8S9V8/SPKwaXqdDElaNorgFNojPkRGHN2NTXoszQmQ1H5sa3bOs3DN8AAAD//wMAUEsBAi0AFAAG AAgAAAAhADIZJM74AAAAqwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAAAAAAAAAAAAAAApAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAAAAAAAAAAAAAAAMAgAAZHJzL3RpbWluZ0lu Zm8ueG1sUEsFBgAAAAADAAMAugAAAEMDAAAAAFAAHgTeBwAAUEsDBBQABgAIAAAAIQBHcju1+wAA ALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGW PUks/JLHqZq/Z5IWCVDV1Wged+7RbbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk 2+76qtnNCZCROmDLx1LSg5SoR/AKRUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKF PR9ofCQhOWePx7vFquUqJWe1KgQql608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfl iUOajBIdDV/VHKfyp9mIy+Bn/GPfWw0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQA BgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYgg eBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwM bbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOp QNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsD BBQABgAIAAAAIQCW7gmorQQAANQXAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu eG1s7Fhbj9pGFH6v1P9g+T0BXwBjLUQqbfKy2V0V8gNm7WHtxva4MwML+fU954wHzC3ykkitVF7A l28+n+vn47n7sCkLZ82lykU1cb33fdfhVSLSvHqZuF8WH99FrqM0q1JWiIpP3C1X7ofpr7/c1bEq 0nu2FSvtAEelYjZxM63ruNdTScZLpt6LmldwbylkyTScypdeKtkrcJdFz+/3h72S5ZXbrJdd1ovl Mk/47yJZlbzShkTygmmwX2V5rSxb3YWtllwBDa0+NElva/BWv4rFZvEqHp//ch0CyzVc9twp+J/M i9SpWAkXZqKsmcyVqOiOqheSc8RU60+yntdPkhY8rJ+kk6dI0Cx0e82NBkanFcDgoHe0/MUysXiz lOX0jsUQDWczcSFpW/yFRSzmG+0k5mKyv5pkj2ewSfbHGXTPPgAs2D0U8l0bj07d8a07i1wX3PF2 Xhkog6X3IvmqnEqAn+i+cS95WFsy9Bnp68xpQo9UDc7cpHhYvKKYWkN3kQgHI6grCoc/CodBdBiT yPfHQ7yPkfG8MOjDCdqyJ6ql0p+4KCHdSk9cyRMNOWUxW98rbaAWQikyhtSx3vwm0i0in+Ef8gxN BeszIb8ZGwql53pbQFmwuFgXXuNAypd/mnS3LoM9bTgEnsUQHvgB4oJhb/Lq3Zc59GapZwVn0LtN +vV0VuTJV0cLh6e5dj4zpbl0NGVGoQHorSafiZJX6ROTDIw4YG5cJR+tb5ABUwSXSyHYlQLW4VPB Ep6JIgULfAwDdI3N+VVVgbF1oYWgvm0RXVUc3iAYeF5wWB1hP+x7EQgeVscwGI+GZPOuOMh9U6Y2 IrtssyqBVE/c54vJdkom76lX8yoF0cFDKpfVAygrxIbFphYc9W3i+iGW6bN1s1UbdOhD9TSEtuQ7 sWK9H7EiFT4cajLYs469kCzowupFp6xI1bCGe1YvGHnUf51oCXkYAuRqaAct2siPyIZraZGroR3u aX0/AhMgYNfSIldDO2rRjsKAROpaWuRqaKM9LXJ2T9mZ2CJXQztu0Q4Hox9KGXKR2pwoGj4Eqm4n XfT06xUOBYcETh0oHLQv6Cf0ru3ZDioWWhWbiUpDrx4IGanG9UKG3Z2xYtnImJEYfNVTmPBgThFD rTUJOXrb24YHkfK9URiNBt+RsWA88KA5ENFFx0iG2ok6eVPt1clQtgBwaMWkrWT7d2wLAIdWIlpY UpIdrwUA1vZ9G4tVucNaAGBtM1/EWgBgbYdexFoAYG3bXcRaAGBtL13EWgBgTYMcqD+J5M63/0YH URvBj21aev++YSyZ80RUqVPwNS/ONOgxPfXFG+gXWS67szdv/s6K81GspM46Gx+ajuxOny/PssM0 /1Ons4HVtcXxdEYWXy9qZmY30xkK3N8rJmHsbDSOog2y+waNG4aDvg/m4px+YVbzRqB8t1lt4t5m NXgT3ma1iRv8H2e1odW0c7MajUbXy9qplJFOXi1ll+a1vZTd5jWM+eH8c5vXLuzpfPeL53igus1r uIVmvgaPY/Nvzmv0OWr2i+EQN5Vpm6yQn1n9uKYREvbSYZia0aUads/xywCgewhy2N346T8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAlu4JqK0EAADUFwAAIQAAAAAAAAAAAAAAAAATAgAA ZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAP8GAAAAAAAA HQQEAAAAAQAAACAAug8SAAAANQBfAGkAZQB0AGYALQA2ADkADwD4A8ZDAAACAO8DGAAAAAEAAAAB AgcJCAAAAAAAAAAAAAAAAgD/v2AA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD731MA/5lmAMwzAACZZgAAYADwByAAAAD///8AAAAA AICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA8AcgAAAA3vbxAAAAAACWlpYAAAAAAP///wCNxv8A AGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3AAAAAAD///cAM8zMAP9QUAD/mQAAYADwByAAAAAA gIAA////AABaWAD//5kAAGRiAG1vxwAA//8AAP8AAGAA8AcgAAAAgAAAAP///wBcHwAA39KTAMwz AAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD///8AADNmAMz//wAzZswAALAAAGbM/wD/5wEAYADw ByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAAaGtdAP///wB3d3cA 0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAAAGZmmQD///8APj5cAP///wBgWXsAZmb/AJnM/wD/ /5kAYADwByAAAABSPiYA////AC0gFQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAAow8+AAAAAQD//T8A AAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//LAAAAAADAAAQ AKMPgAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAIAAAD//+8AAAAAAAEA AAD//xgAAAAAAQAAgAUAABMg1AEgAQAAIgD//xQAgAUAACIg0AJAAgAAAgASAIAFAAATIPADYAMA AAIAEACABQAAuwAQBYAEAAACAA4AIACjD3AAAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAA AABAAgAAAAACAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASABAAAgAP//AAUAAEACQAIA AAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQA AAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABA AkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAA AQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAAB AIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAUAAEAAAAAAAAA AgASAAIAAAAAAAAAAgAQAAMAAAAAAAAAAgAOAAQAAAAAAAAAAgAMAIAAow8+AAAABQAAAAAAAAAA AAIAEgABAAAAAAAAAAIAEAACAAAAAAAAAAIADgADAAAAAAAAAAIADAAEAAAAAAAAAAIACgAAACME GAcAAFBLAwQUAAYACAAAACEAmxMFu/oAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtq wzAQRfeF/oPQtlhyuiil2M6ij10fi/QDBnlsi+qFRgnJ33fspBBKyGqYx517uM16753YYSYbQytX qpYCg4m9DWMrvzdv1aMUVCD04GLAVh6Q5Lq7vWk2h4QkWB2olVMp6UlrMhN6IBUTBt4MMXso3OZR JzA/MKK+r+sHbWIoGEpV5h+ya15wgK0r4nXP4yMJy6V4Pt7NVq2ElJw1UBhUz1t9UZfR0RXhLvT/ 6KoTmWLl8pwmm+ju5PDJ0WTbo/iCXD7AM4fuM2lyPHwHKpzcebNS18Ev+MdhsAb7aLaeM1EpI3Fd ULxTZ0Z/THqJvvsFAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJl bHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcK qqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8z pizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT +dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQABq9yK6AMAAD8mAAAhAAAAZHJzL3Ns aWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FpLbtswFNwX6B0EbgPHlvyRbFgOkhRZZRE0yQFo mbLVUJRAMWncVZEcoTfovmiBFuiiWfUo9QFyhZIUZUu27KpGgtiwdor5ETlDvTfDl+7BrY+1G0Qj LyA20PdrQEPECQYeGdrg8uKkYgEtYpAMIA4IssEYReCg9/pVN+yw23M2xijS+BQk6kAbjBgLO9Vq 5IyQD6P9IESEt7kB9SHjf9JhdUDhez61j6tGrdaq+tAjQI2nRcYHrus56E3gXPuIsHgSijBkfPnR yAujZLawyGwhRRGfRo7OLKkntucxjOQOe13YwTdYD8+oBvGQ4+QwCjTKsA0EXvCUHNEr+ewGhB3K Ln0YIaCNIBny/Z5dE4eJDmKqKHSOkKuezhym3UA5UbXXrc61HrpsRT/VOkDuW76y6IMNGo2aekeA vcGJh7EcLvhAx5jGb2K3BlDvSvcSIBKNjUPkQoczvee/q2AmesIOgqmGx4cvjw/ftceHb5O7H5O7 n5P7+8ndV6A5I0gjJLcpBznRfw/i+493I6FQmIsF8Edjt+A/pB7EQAs95oxOoO/hsQ0qeq29iPOL kSMYUeTUS3I2jBzBiCKnUZKzYeQIRhQ5zZKcDSNHMKLIaQlyfEhPeWptmlyygDwBMJf0xdgtyfFF k8xCXhbAKIzMGUZtXQqQEiMpWAQwCiNrhpFeN/VWeZASgSeQUSC1UyBZhmWVICUgCWT4c9aThJ1+ MBgvGJQ4WtUbRlvg55EBNzhcOSY/xP6FC8undS88NPLXretg+tfH3DtIA2GDPx8/x6Yj5WuMYr5G T1aw2teQzfM1MWsmZ62ZZs2wmqb4YRtY+7TImjgTMhum+ZC3A2k3+jysrTJOFd2w1FHJ2s15RxPT ouuNutjK7GsyDCsVw7foa9oqNuYtjGKDIy+V2DS2bRMbi1+JVANbxcu8e4l5MWpNU4TpbfxKfv9a CF76S6actYJXvm8xmnpDxqp/fy6FfcwTZvsc5MXs25U28t2Q0TZ1KWJL5ItcH6915vM9Vix2C4Wi 8syvvmNeKpXyjVvdsloFk3OJ/JrIT91gyv+FnYCNEJ26QS5rz2JjrVwU5oUoGyBSuTyfKV/VJalt xXk8bTf44AvYPxeVJXX9tWAbdaDJytGsBpateekylKtViBpVHBOvEBX1RnFWnlv77PmkgmCc4DM1 KdHgRDM4eBUtcdyi1ifWldSdYmgSEKZ2bGfxyTdK2fs/bot2Fp8l1iV797fLAOV7CD1777fLAC1R 8/LioQzRPC4vEd1moy4FSBmjl2hjjo606SVASyRsq2lmL/d2NotNlWZaXIoyhPrPr95fAAAA//8D AFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKwEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAAAAAAAAAAAAAAAAEgIAAGRy cy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkAAAA5BgAAAAAPAAwE MR0AAA8AAvApHQAAQAII8AgAAAAFAAAABZAAAA8AA/DNHAAADwAE8CgAAAABAAnwEAAAAHIAZQBm AGUAcgBlAG4AYwACAArwCAAAAACQAAAFAAAADwAE8C4BAAASAArwCAAAAAKQAAAACgAAgwAL8EgA AAB/AAEA7wGAACj3hCW/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0 AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAP+/ DwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5 bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIP HgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDW CAAAEgAK8AgAAAADkAAAAAoAAIMAC/BWAAAAfwABAO8BgAD4+oQlvwAAAAYAvwEBABEA/wERABkA PwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADIAAAAT ACLx2AcAAKnD0gcAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1 dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwR SSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5 lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L 91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAA AF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BB v9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCW krZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz3 3j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQU AAYACAAAACEA6vTcrG8DAAD1BwAAEAAAAGRycy9zaGFwZXhtbC54bWysVc1uEzEQviPxDpbvkKRN S4m6RW2hgBSqiLTiPLvr7S7x2ovtTZMey/MgkEDi0rfpA/QVmBlv2vIjBJQemvF6xvPN943H208W tRZz5XxlTSIHD/tSKJPZvDIniTw+OniwJYUPYHLQ1qhELpWXT3bu39tuRr4RGGz8qElkGUIz6vV8 Vqoa/EPbKIN7hXU1BFy6k17jlFcmQMBEte6t9fubvRoqI3fwKDOfNhNHVnY4nzhR5YnclMJAjSmf QlBioiFTpdW5cmJN9jrXGAUIZWyzme/wwJ/gyR2cYpHfQRHGPndYzYAS9BjMCpdBWJS0KUVYNogq D0jMGWYCXUgEvEgk48Kw6MvGKtxjeSI9fWVzDIU2WCwbRovC1XfFTOfYohCYf7jxCGmVYonkbawP Bxt9qgNGahFERvgG6+ub5JChx/DR5lp06EUg5Nk4H54re2dQgg5KpFNZ4EJhPvaBOL1JQem0+R/V 11XAptBVncitPv3FqksF+TOTMwMBKh1tRKANi0uSkKJhsWfzJcFJ8Rdlik39702EtwlrL607k+LU AfaTf9eCU1Lol8Yn8vFgOEQRAi9YMync7Z309o5p632rqScFmAxPTSR2XjT3A65IT1s3EMZm2mTk uFLyaPEGXNNpEbALDu20hEb9SpLoywpFGlgfH6ZhqdVdKeGz5nrAjMMoV8XriYvtoFefSZguHeP/ Hznp0tXgxkwSGq/ZwJT8W5kcBxKboE9w+mkpENoRpFO816wScutC9FYwNntuxkIU1oRdDknBk644 1Uy3jSElmBMcLZPWZHh81EOTOFSYb7JJFsQcSNPrduW2vPHYU8WPvtzV6IbxN7u7RfiNX7ebtvva HS34IqTt9OzaPMAyrheHON67u5LGy/q9UJ12yuQTcID6iVlbV7V9W0VSseZEKvPgeBrn4mBIkyaN TPP/NpEGk9B74qoZzkFjp2xJMVOOXh+eXhndmM6R+hlPMfSO6OpMveAlka4reo14b+KsLcgmKuhy w8jYg0rrrsP4i7e6yukj80XPlEJWogxhEQc+knvbSxUFzq8VF+3YdFy1dExns/L8IhT4PiVy11WA bZSV4Lzi3mJOFdzyubr4cHXxWVxdfLo8/3J5/vXy/fvL848/B2X+r4OwP24EiuOWZ91qxuGb5Jud bwAAAP//AwBQSwMEFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj91K w0AQhe8F32EZwTu7qT/Bxm5LEURBvGjtA4zZyQ9mZ9PdSZq8vYsXenk4h+/wrbeT69RIIbaeDSwX GSji0tuWawPHz5ebR1BRkC12nsnATBG2m8uLNRbWn3lP40FqlSAcCzTQiPSF1rFsyGFc+J44dZUP DiXFUGsb8JzgrtO3WZZrhy2nhwZ7em6o/D4MLp0s9TC+T7u70/3Dx3E+rVa6DmLM9dW0ewIlNMn/ ePB5hf6v/EW9WQM5qOp1/gqt3WMUCgaSWzJNlqA3PwAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9 PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQDq9NysbwMAAPUHAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0A FAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAAAAAAAAAAAAAAAAxQUAAGRycy9kb3ducmV2LnhtbFBL BQYAAAAABAAEAPUAAADHBgAAAAAAABDwCAAAABQQIAFgBkARDwAR8BAAAAAAAMMLCAAAAAIAAAAH Af+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAACAACgAAAAD/BwABAAAAAAACAA4A AACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8BgJAAASAArwCAAA AASQAAAACgAAgwAL8FoAAAB/AAEA7wGAALh7qSW/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyoA AAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADMAAAATACLxEggA AKnDDAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyU kUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9 oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNk OabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glw JvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+U cP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxz Ly5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32 lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0p oDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx 0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAA ACEAs0AQfKgDAADsCQAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1uGzcQvhfoOxC8J/qJ/BMh68A2 6jSAYgiRgh6N2V2uxYpLbkmuLPnoPE/RAi3Qi9/GD+BXyMxw5Z+2KJo4hx66B+1wOeR8M9/86NXr dW3ESvmgnc3k4HlfCmULV2p7nskP85Nn+1KECLYE46zK5EYF+frg229eNePQCDxsw7jJ5CLGZtzr hWKhagjPXaMs7lXO1xBx6c97jVdB2QgRDdWmN+z3d3s1aCsP8Cq7mjVTT1Jxupp6octM7klhoUaT J85F5cXUQKEWzpQov5C9TjmdAwQzccUydIjg3yAqPVygm4/ACOveePRnQAZ6DGeLzCIwMtosRNw0 iKuKHmNzmcmfWvCIUCLsdSYZGx5N+ixsrwjopMgv3rkSj0MbHToP43Xl66fipntcVQmyPxiOMLpS bDK5u/NiNNjpkzMwVusoClQY7r/c2SWFAjVGe7vDpNBLSEiz8SG+Ue7JqARdlEmvisiewmoSIgX2 3gSZM/ZruF9ryhKj60zu9+lJXi8UlN/ZkiMQQZskIwJjmWHihGiN6yNXbghOjm/kKeX2l2cSFhX6 vnD+UooLD5hUgRJFSWHe2pDJl4PRCEmIvBjt7A1x4R/u5A93bFsfO0OJKcAWeGsm41Y8jrgiPl3d QJzYWVOQ4pbJ+foH8E3HRcQsOHWzBTTq7yhJusxQCgPzE+Isbox6akj4rpUZcMRhXKrq/dSndDDb z0RMZ47xfw2bVHU1+AkHCYX3LKBJfmtbYl9iEcw5NsGC6hrBzSGfYXUzT8RNTPoKJvbIL5mKytl4 yIdyCMQstjfbbeORBdhz7DDT1hZoIDFiiB5yLTTFtIhiBcTqXcJyYt5rHKnqz7qc16iG5+93D6v4 D3rdbt4eGz9fcynk7ezyTjxBN+4Wp9jnu2rJU7k+pqpjD4sGxh4ju2xrXbsfdQoqepxJHZ+9nafe OBhRp8k5WkmlzaRFEzRWvF5iI7RuxpIUS+VpCHH3KqhiOkXKZ7zF0jgx+lJ9z0sKudE0lHhv6p2r WC61j9ja8Guo47FRgJf2Odup5mFs3Yk2pks8/hKc0SV95CDSEFMYqsRNXKdhgBF/qKWqCtvaNkDt xHYBbOmaTuZ04GlR4ezK5KHXYLBOF+CD4pTjQCt4oHN7/fPt9W/i9vrXm6vfb67+uPn48ebql78e KsJnH8KkQcLIxXgg0nMmzs4E9WNMH9pmUvnnv80sQfyfzHsyH1GIRDY827YzDf+EhObgEwAAAP// AwBQSwMEFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tKA0EQRfeC /9CU4CaYnvjOmE4IgigEF4nBdTldmRmc7p50V+bx9xYudHm5l3M5i9XgGtVRTHXwBmbTDBT5Itja lwb2Hy9Xj6ASo7fYBE8GRkqwWp6fLTC3ofdb6nZcKoH4lKOBirnNtU5FRQ7TNLTkpTuE6JAlxlLb iL3AXaOvs+xeO6y9PFTY0nNFxffu5ORkpk/dZljfHG/v3vfjcT7XZWRjLi+G9RMopoH/x/2Ew+fk r/xFvVkDD6AOr+NXrO0WE1M0IG5iKpaglz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA 4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA qotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA s0AQfKgDAADsCQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAI AAAAIQD9AqKn1gAAAPkAAAAPAAAAAAAAAAAAAAAAAP4FAABkcnMvZG93bnJldi54bWxQSwUGAAAA AAQABAD1AAAAAQcAAAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAQAAAAAADDCwgAAAADAAAACQL/vw8A DfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRGODcgaTJycyBXRwAAoQ8eAAAADwAAAAAAIAgK AAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADwAAAA1AHQAvADEAUPAATwYQkAABIACvAIAAAA BZAAAAAKAACDAAvwZgAAAH8AAQDvAYAAqFijJb8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAA AL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAA NAAAABMAIvE/CAAAqcM5CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55 /z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2 wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvI ImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5b LNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8B AAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRC L2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElU pUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyX xnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMA UEsDBBQABgAIAAAAIQBYhhr21QMAAFALAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWzW7jNhC+F+g7 ELx7bfkvibHKIrbj7QJuYKxd9FiMJCpWTZEqSTl2il6yz1O0QAv0krfJA+QVOkPKSbYtirbJoYf1 QR6K8//Nj16/2ZWSbYWxhVYxj151OBMq1VmhLmP+1WrWOubMOlAZSK1EzPfC8jenn3/2uhrZiqGw sqMq5mvnqlG7bdO1KMG+0pVQeJdrU4LDo7lsV0ZYoRw4NFTKdrfTGbZLKBQ/RVVqu6wWhqj0Yrsw rMhijoYVlGhyKYtMsIu6TIRhCwmpWGuZId3n7UYkSAO6NNfpxjZ+wT/xKzNwhcF+5BJT+q3BqCIy 0PZOHfxT6B4ZrdbM7Sv0zsoMXcMkXcf8uxqME4aj/7uYe/dQOoh44qDFYrQsufpSZ6gBaqcxCzDa 5aZ8ruukR+c5Q/vDwaCHaeZsT3SvHw06FA+MxM6xFBm6Ua83JIYUOfpHw25gaAdPiLMy1r0V+tle MVIUcyNS5yOF7dw6yu2jCTIn1UuEXxaIAZNFiTXUoV+Iei0gO1eZz4CDQgYaPZDKg0yYELJuN9bZ ntxJ8B9xCkX+34sJuwtjX2tzzdmVAawrS4UiOJPvlI35SdTvIwjOH/qDoy4ezNOb5OmNqsuJllSb DFSKWmPuDuTE4Ynw1GUFbq6WVUqMByRXu6/BVA0WDqvgQi/XUIm/giTweoRCGjw+1i3dXornpsTr 2srIZxxGmcjfL0woB3l4TcA05rz/L2GTuq4EM/dJQuK9J9Ck/y9UhgPKkyAvcRpiI6NrK0iW2Nse JULGBW4BczU2Gw9ErpU78yIJWMIVp5xqrlFkDeoSR8yiVimqD3hIAocCs1W6SB3bAmH6UK6+LB85 xiL/I6+vamRD+cfbs9z9DV9zm9QTaVY73whJvbx+IGcYxsPhAsd90ytJaNaPgWqwy2Xmp/X3Z8ez bmca4cIYdKLW0aR/3jrpjqetSW88nJ5MZ8fT8+kPWOXN0MSRjpXsK88gKpu6LEr9bREAwXzFvHCt d6swV6M+TakkoOSfdcwVOki7yRQbHKJKLz3F2UYY2mR+8qXUbQ0j9QJqUbSTZHEtvvBHAkwWtNn8 3cJonRNNaaTBACOlZ4WUTXX6N1bjRqKXPte08gRmNEDodmFpIDBPuUSe4+w75LGeqybPNalpaF81 PkE57riYn5kCJDbzGowVvi49HgKe8Nzf/nh/+wu7v/357ubXu5vf7j58uLv56c9Cqf3XQlhbiAyF +KltKAsv2jbu9Btaftit+MQeIgNCZQswgKPwUztgOv5/7fAIUPhy8Z8Nh88F/L6z1envAAAA//8D AFBLAwQUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4 B2uQuisO9KGSYhBCqlqBWEBhP8SDEzW2g21C8vcdddEuR3d07j2zRWdr0VKIlXcKxqMMBLnC68oZ BYev94dXEDGh01h7Rwp6irCYD+5mmGt/cztq98kIhriYo4IypSaXMhYlWYwj35Dj7OyDxcRnMFIH vDHc1nKSZS/SYuW4ocSGViUV3/ur5ZKxvLabbvl4eXreHvrLdCpNSErdD7vlG4hEXfp/Nutjtln/ hb+oT62Ah58/+lOo9A5joqCA3diULUHOfwAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADi AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCq i10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBY hhr21QMAAFALAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgA AAAhABP/D9jWAAAA+QAAAA8AAAAAAAAAAAAAAAAAKwYAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA BAAEAPUAAAAuBwAAAAAAABDwCAAAABQQIBBgFUARDwAR8BAAAAAAAMMLCAAAAAQAAAAIAv+/DwAN 8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAA AAACAA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUP AATwPAAAABIACvAIAAAAAZAAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTzgAA AA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQEAQAAAAoPAIoTlQAA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixN1AAAAAADrLggAAABKyccB4Ix4vwAAHRAEAAAA AAAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAD/ ////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAOBMYOAABQSwMEFAAGAAgAAAAh AJvocE/8AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroopdjO oo9dH4v0AwZ5bIvYIyFNQvL3HTsulBIChW4E0sy998yoXB/GQe0xJuep0qu80ArJ+sZRV+nPzUt2 r1VioAYGT1jpIya9rq+vys0xYFKiplTpnjk8GJNsjyOk3AckqbQ+jsByjZ0JYLfQobktijtjPTES Zzx56Lp8whZ2A6vngzyfSESu1eOpb4qqNIQwOAssoGaqmrO6iEO6INxT84suW8hyUc7mqXch3SwJ 77Ka6BpUHxD5DUbhMCxD4s/zFUhGi/ll5jPRvm2dxcbb3SjryGfjxexPAKv/if7ONPPf1l8AAAD/ /wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPR fVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2 Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf 1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW /QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1h bmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1Z LJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65 JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAN0ToY9RCQAAfDkAABYAAAB0 aGVtZS90aGVtZS90aGVtZTEueG1s7FtZj6NIEn5faf4D4r2nOAyGUrtHnJqHHc2oq0f7uKJsbDON wQL6+vcTkZdJgxO7Cm3Pqm1LXTgJIiMj4osjk377y9dDqX3Om7aoq5Vu/mzoWl6t601R7Vb6nx/S N56utV1WbbKyrvKV/i1v9V/e/fSvt9ljt88PuQbPV+1jttL3XXd8fHho1zCctT/Xx7yCe9u6OWQd /Gx2D5sm+wJ8D+WDZRjuwyErKl2rsgOwdf9b5N32jevr7zjnpAT2VdfiwLpsnpBvzsgZsWYS8s1H E4naZvcclY32OStXukE++sO7tw/ZIyMouyFdSj6MjhFsPlpT/AhB2Q3pPAO/gh8hyNZrWMhw7jBM jMRmtD0iejnkbcPH9yX6Hn97ILO0NsqUENHLxYBe0lmPiF46A/o4SOIkleQhRJTeHdBbsRV7gURP iPZlUX0cUBuGDx9GLUi2dfnrKLnvR5HBFX+iAusL58EptnXVjbmSjjcP2V91kwIF/iizrqi07tsx 32ZrcNGgKbISxcke86w3TofW7dkQTCyxOxTVrLxP7GCm06rIGg/yEn/fbot1Tla4LcryqftW5v9u ySLbuiw2KQzicwS6uYDQcQ+XTP8S3a7JyDNaU3f/Kbr90z47goIoGHctY71rtWPdAhLJxKO8cVJQ ckch66D/UW22WfdbvaHDdh/Jgg3B9Y4EBz6RjQyuncxevm4yk0p1UW3y0kwiGvEdaWliyWDD4dJg UGgTfF7LMCabLgRPlF1r11mZb1DvNMpxs+DU/HpmE7FV04Xss01OTSQN90xnEttxFyIBHFxqxHS3 aVNoDZQ2LQRxCx4YXqxkzoArliziHE1l1cdWWWlfVrrvWI6urbPjSt9CSIHLwxGM1lY7XcvKHSTd dddQr53EIvG204r9ca8yDT4+8CoJxsem7eKs3VMbklvMVGWFM1H5LWeBzjbPAqijvkAK2wMX+W5S gB5l0+bbbb7u+sbujaDu6E8WCetPXd487TdftOfyU/M+A/ODTnE9m6LtVjoBNP5oVjpqm9ySYyuL ayMVDs6Wlcd9xqKlh08zPVNy4qpCBvKrJx6sbVR2srjbl4KIn2spfTf+wZaC6SCvcnuDFlhDidxk GuJ1pddNt68hCh33xTptoFYhsQO8RYPogtlWg0Kd/G3yz/iX+gLlgdzKYrfv3hc7rSkgnXT7Js// gLBEvG+CmclSD2XJGRGP6onbHqnYz/nnvPyAMdDFGKxre3B1Ek2YexK6c/+TfzMEPe+wRunjTYoh IqpTDPyvCxcKZlgUWK2X/SYSDyZ3WiHR58njPEf2F4I3TlXSgqNCSn6+z2D/QhGuScC9XEsj1mDF lsOFAysKoxD/wFINBkU9c8y6vYb/QP4rmnV5Kk8/1O8htmrQwyEzcBvw6jcY1eASAyS9eoa6hw5S Z0JWdAZWnKLWeLKeuQoS854pGyXjeBuu/mTvG5Utiih5OgmLw+lermymYUnXdOyiqmGyc4jC0Jb3 IcQwZLug39TXz3+BoWNorz6VtM1vj/CL4OD4R0O867nefGOXZUsTLvU67GGQsqze51ut2Hzl/YfQ BIUQ7UV5iUyo8TGs3MSD9ljTID/I6PFRmi3Fw9b0w+IJMjOEbPEwaQrHGMBOBAvc2NoBPVFhS1cN qhWaKqvXqOwK4cdVNtpnXasy2igqDfUClXVf1SpjmgLlDR0v/9o1GbQmTyT+sqQjD6Lt1pzivg3F N2aozS3UDr28b0NFIglc3oYCT/otO2rPO3OlI9Y18N6VDvuUOoxZOGbhGFzBZiQ0inQHcaVziLER uM8MwGlsPmLzkQUfWfARh49AY0ofd/mIC1Uabq/Bdi7+0TW+BOhe2c4bi0tDdAxHLuGFhp1/0rat 7+KXLY3t6zJdo2tLW8tpGKfODdu2aer7LufNzPU98ZLGSRTK8iu3bZOlFzgR0w3zF5Rf7MlK2oki GwoWRi1IuPMMlImqEeQnKojSwnnwmR8bL7RA+Sfh5ZZjDtyZT+VjAnIW0oPCmQcN6L9rfomCxDqT X4mX0A/9ZHktXvBQJ+LomsZLkLpLIcwdL+PHggtSUr8GL3Cu5aa8npzhWPCm/NI/kuwloUt48eLI FS7RI6KXw3osidIglf2TEFH61x8Ljhw7KvGyTEP7erzAybF7A14MI4B2nYHxjpdxvDivxgvaPOY9 wQx4WZIPM9tUPYaTy/6szC8Yb4UHXYEXZJ/wtfVANSteAilfKPFixZhhJHrFMXqaOnAexKin8wsW q3e8wJsmrOqkOwJn/b6rwIsTOB7TNktADA5SjYM+JWK2Ei+910nYeyljr50gN/GyxAReIIIuXEvy HyVe3NhNIxlfynosCCIj4h53BV7iAL+SPCQJ0UcJFCTdBUHohbI8Sry4lrsIFxJ/BV4Mo2eZabwg +Y14IR096ffB8KzfB1dh/T4Yj3flsCNAdQD36MX/ab+/vIgXJzJP6psBL2RrnvueAi9xGls+74En 8CJ1tMwgGB2YSQYtbZgsfZfL0COil8N6LDIC+Ej+qazHbsVLYgG8ZP5KvASRGzvyfoUCL1LkmcZL bAeWyZPXdfXYj4cX7yJeDMO2xV7SDHjBEyuRNxR4wY68l6968X/4WiNKeFZfKfOLYYSnc7Mr8IJo iWR/nhUvQRx6iZwflXgBDZ5iGJVfgRfUjdDkNF6g9FwaJgsOd7yM9y/0rWEGB6lWQF/s+Tfxw9fV Y4gYZg4FXhI7CXv7B0q8IKaFjNR/lHhZuF6wCKV80eM/zC+Il7P4Py9egiA+w6MSL3a6jBc8986O FyOBs+o7XnJV/2LS49sxwEiN9wwJxvXc0ImnARObsRlxp54oyHzDNzw5QCsB4xl+EvCm7IoEA+11 EMoF0KyAiVz48phO5VECZml7qS/Lr0gwaRpFokSYTjCJH0diN+GeYMYTjHn5P5rYEOrF6dgcgHGl jEUiO8ODlNmwHhN1xARgXMPxlxxcV2QYEMEVvK8BjBd6ZxlgVsCEEENC+QRJCRgncqLrd5Sl86lp wKDaRbq+A+YCYC4f8cP/AjJMR2SEV5dkjmUnFo/WipIsTiPD45loAjBetAyXvIq4AjBe6qSW7KDK kiy0gzTgh36U/6yAiQAuoQx4JWA803EsuaVSZJgoCuGVVWbBacB4EaRfTv4jAQZeYpDfiSEvlsEo eRXy3d8AAAD//wMAUEsDBBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3Jl bHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR 7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0m JFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJ Zy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAm+hwT/wA AAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAAAC0BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABYCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIu eG1sUEsBAi0AFAAGAAgAAAAhAN0ToY9RCQAAfDkAABYAAAAAAAAAAAAAAAAA0wIAAHRoZW1lL3Ro ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAABY DAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEA AFMNAAAAAAAADwQ6AQAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5k YWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxm b3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0i bHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50 Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0i YWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAA0rBAAAAOijpy4A AAsrEwQAAFBLAwQUAAYACAAAACEAMhkkzvgAAACrAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8 kM1qwzAQhO+FvoPQtVhyeyilxM6hP9BL20P6AIu0tkX1h1YJydt37aQUSshp0a5m5mNW633wYoeF XIqdvFWtFBhNsi6OnfzavDYPUlCFaMGniJ08IMl1f3212hwykmB1pE5OteZHrclMGIBUyhj5MqQS oPKzjDqD+YYR9V3b3muTYsVYmzp7yH71jANsfRUve14fSVguxdPx3xzVScjZOwOVQfV81Wd1BT1d EO6i/UfXnMgUKxdzmlymm1PCB1dTnEXxCaW+Q2AObQvp6gI39BaHpC6TnglMw+AM2mS2gUtQuSDx XLKDV3/Ovwx6qbr/AQAA//8DAFBLAwQUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAF9yZWxzLy5y ZWxzhI/BCsIwEETvgv8Q9m5TPYhIUy8i9Cr1A0KybYPNJmSj6N+bYwXB4+wwb3aa08vP4omJXSAF 26oGgWSCdTQquPWXzQEEZ01Wz4FQwRsZTu161Vxx1rmEeHKRRaEQK5hyjkcp2UzoNVchIhVnCMnr XGQaZdTmrkeUu7rey7RkQPvFFJ1VkDq7BdG/Y2n+zw7D4Ayeg3l4pPyjQmbny7COhlCoOo2YFdjE i3tV/gXZNvJrX/sBAAD//wMAUEsDBBQABgAIAAAAIQAlRkRBBwEAAMoBAAASAAAAZHJzL3RpbWlu Z0luZm8ueG1sjJFBS8QwEIXvgv8h5G7TioiUtntZPHmS+gNCMt0NNDMhmXXdf++0WwXxsqeZkLzH 91663Vec1SfkEgh73VS1VoCOfMBDrz/G14cXrQpb9HYmhF5foOjdcH/XpZZDlFdKDLC0ttdH5tQa U9wRoi0VJUC5myhHy3LMB+OzPYskzuaxrp9NtAH1ps+36GmagoM9uVME5KtJhtmywJdjSOXHLd3i ljIUsVnVf5CGJRy+FV6WZPMy3IgqeGlIK38S2IAepoCBQSvxYZu51wjSpFZIHsZLkrY4vhPxL1Xz 9I8rBpep0MSVo2iuAU2iM+REYc3Y1NeizNCZDUfmxrds6zcM3wAAAP//AwBQSwECLQAUAAYACAAA ACEAMhkkzvgAAACrAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQAXS2h7ugAAACgBAAALAAAAAAAAAAAAAAAAACkBAABfcmVscy8ucmVsc1BLAQIt ABQABgAIAAAAIQAlRkRBBwEAAMoBAAASAAAAAAAAAAAAAAAAAAwCAABkcnMvdGltaW5nSW5mby54 bWxQSwUGAAAAAAMAAwC6AAAAQwMAAAAAYAAeBFQFAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEA ABMAAABbQ29udGVudF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8 ksepmr9nkhYJUNXVaB537tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq 2c0JkJE6YMvHUtKDlKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8 JCE5Z4/Hu8Wq5SolZ7UqBCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qM Eh0NX9Ucp/Kn2YjL4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgA AAAhAHDwONy+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2A Jdm2wTYJ2Sj2783RguBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17V Vxox5RAPNrDIFMcKhpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQ m/+zfddZTUevnxO59KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAG AAgAAAAhAJ3WhAAjAgAAVgQAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWyM VE1z2jAQvXem/0Gje2IglFAPJjOlbS4kMCH5AVtZYE9kSSNtXNxf35VkQ5PmkIv19fZp31utFzfH RrFWOl8bXfDx5YgzqYUpa30o+NPjz4s5Zx5Bl6CMlgXvpOc3y8+fFjb3qlxDZ16QEYf2ORS8QrR5 lnlRyQb8pbFS09neuAaQlu6QlQ5+E3ejssloNMsaqDXv491H4s1+Xwv53YiXRmpMJE4qQMrfV7X1 A5v9CJt10hNNjH6dEnaW1GKNSm606jiLUNfS5pgvSb3YqZJpaGjjMaBYhIUTbx+dlGGm21tnd3br YsB9u3WsLgNBH8iz/qCHxaUmGE2yN+GHgQny4941ywXk5AU7FpxK1oUvBUEuj8hE2hTnXVFt3sGK 6sc76Gy4gDI4XRpUJUX/y5kMcpIP45OqBAUKXRvx7Jk2pDPIT/LEfTuQBc2B3lbsH+N7XDqMfgx4 Hz0dEj05Mf1yTa8q2jG5ns6u5q89mU8mX2fhPDgzHk+vRrQIuZyJrPN4K01D5fZYcCcFUrUhh3bt MUEHSCxRSsTmePxmyi4gf9FIdaaWovjKuD8pB+Vxh52SsUhkJeQkmD4EVRB6TeqLpx31WoMrJYF6 sS8oLleqFs8MDZNljewOPErH4sukziTKkD9GFZFS6nILDh7eMPfJx6yHbMnTUNY4pDdL0/Cw47NU 7g7spo2k1M106ypuWerfwEbQMyRwDP+D5V8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAA uwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA cPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA ndaEACMCAABWBAAAIQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDEueG1sUEsFBgAAAAADAAMAyQAAAHUEAAAAAAAAHQQEAAAAAQAAACAAug8SAAAANgBfAGkAZQB0 AGYALQA2ADkADwD4A+RCAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAgD/v2AA8AcgAAAA ////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD7 31MA/5lmAMwzAACZZgAAYADwByAAAAD///8AAAAAAICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA 8AcgAAAA3vbxAAAAAACWlpYAAAAAAP///wCNxv8AAGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3 AAAAAAD///cAM8zMAP9QUAD/mQAAYADwByAAAAAAgIAA////AABaWAD//5kAAGRiAG1vxwAA//8A AP8AAGAA8AcgAAAAgAAAAP///wBcHwAA39KTAMwzAAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD/ //8AADNmAMz//wAzZswAALAAAGbM/wD/5wEAYADwByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaK SwBmzP8A8OUAAGAA8AcgAAAAaGtdAP///wB3d3cA0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAA AGZmmQD///8APj5cAP///wBgWXsAZmb/AJnM/wD//5kAYADwByAAAABSPiYA////AC0gFQDfwI0A jHtwAI9fLwDMtAAAjJ6gAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIA AAAAAgAAAP//7wAAAAAAAQAAAP//LAAAAAADAAAQAKMPgAAAAAUA//0/AAEAIiAAAGQAAAAAAAAA ZAAUAAAA2AAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//xgAAAAAAQAAgAUAABMg1AEgAQAAIgD/ /xQAgAUAACIg0AJAAgAAAgASAIAFAAATIPADYAMAAAIAEACABQAAuwAQBYAEAAACAA4AIACjD3AA AAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8M AAAAAAEAAAAFAAAgASABAAAgAP//AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAA QACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAAB AAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAE AAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBA AgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAA cACjDz4AAAAFAAAAAAAAAAAAAgAUAAEAAAAAAAAAAgASAAIAAAAAAAAAAgAQAAMAAAAAAAAAAgAO AAQAAAAAAAAAAgAMAIAAow8+AAAABQAAAAAAAAAAAAIAEgABAAAAAAAAAAIAEAACAAAAAAAAAAIA DgADAAAAAAAAAAIADAAEAAAAAAAAAAIACgAAACMEGAcAAFBLAwQUAAYACAAAACEAmxMFu/oAAAC7 AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtqwzAQRfeF/oPQtlhyuiil2M6ij10fi/QDBnls i+qFRgnJ33fspBBKyGqYx517uM16753YYSYbQytXqpYCg4m9DWMrvzdv1aMUVCD04GLAVh6Q5Lq7 vWk2h4QkWB2olVMp6UlrMhN6IBUTBt4MMXso3OZRJzA/MKK+r+sHbWIoGEpV5h+ya15wgK0r4nXP 4yMJy6V4Pt7NVq2ElJw1UBhUz1t9UZfR0RXhLvT/6KoTmWLl8pwmm+ju5PDJ0WTbo/iCXD7AM4fu M2lyPHwHKpzcebNS18Ev+MdhsAb7aLaeM1EpI3FdULxTZ0Z/THqJvvsFAAD//wMAUEsDBBQABgAI AAAAIQCO6ir6vgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfR D1iSbRtsk5CNon9vjhYEj8Mwb2bq9jVP4kmRrXcKqqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0Dbr VX2hCVMO8WgDi0xxrGBMKRykZD3SjFz4QC47vY8zpizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9 h9z8n+373mo6ev2YyaUfFZIna+iMnChmLMaBkgIT+dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQA BgAIAAAAIQABq9yK6AMAAD8mAAAhAAAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s 7FpLbtswFNwX6B0EbgPHlvyRbFgOkhRZZRE0yQFombLVUJRAMWncVZEcoTfovmiBFuiiWfUo9QFy hZIUZUu27KpGgtiwdor5ETlDvTfDl+7BrY+1G0QjLyA20PdrQEPECQYeGdrg8uKkYgEtYpAMIA4I ssEYReCg9/pVN+yw23M2xijS+BQk6kAbjBgLO9Vq5IyQD6P9IESEt7kB9SHjf9JhdUDhez61j6tG rdaq+tAjQI2nRcYHrus56E3gXPuIsHgSijBkfPnRyAujZLawyGwhRRGfRo7OLKkntucxjOQOe13Y wTdYD8+oBvGQ4+QwCjTKsA0EXvCUHNEr+ewGhB3KLn0YIaCNIBny/Z5dE4eJDmKqKHSOkKuezhym 3UA5UbXXrc61HrpsRT/VOkDuW76y6IMNGo2aekeAvcGJh7EcLvhAx5jGb2K3BlDvSvcSIBKNjUPk Qoczvee/q2AmesIOgqmGx4cvjw/ftceHb5O7H5O7n5P7+8ndV6A5I0gjJLcpBznRfw/i+493I6FQ mIsF8Edjt+A/pB7EQAs95oxOoO/hsQ0qeq29iPOLkSMYUeTUS3I2jBzBiCKnUZKzYeQIRhQ5zZKc DSNHMKLIaQlyfEhPeWptmlyygDwBMJf0xdgtyfFFk8xCXhbAKIzMGUZtXQqQEiMpWAQwCiNrhpFe N/VWeZASgSeQUSC1UyBZhmWVICUgCWT4c9aThJ1+MBgvGJQ4WtUbRlvg55EBNzhcOSY/xP6FC8un dS88NPLXretg+tfH3DtIA2GDPx8/x6Yj5WuMYr5GT1aw2teQzfM1MWsmZ62ZZs2wmqb4YRtY+7TI mjgTMhum+ZC3A2k3+jysrTJOFd2w1FHJ2s15RxPTouuNutjK7GsyDCsVw7foa9oqNuYtjGKDIy+V 2DS2bRMbi1+JVANbxcu8e4l5MWpNU4TpbfxKfv9aCF76S6actYJXvm8xmnpDxqp/fy6FfcwTZvsc 5MXs25U28t2Q0TZ1KWJL5ItcH6915vM9Vix2C4Wi8syvvmNeKpXyjVvdsloFk3OJ/JrIT91gyv+F nYCNEJ26QS5rz2JjrVwU5oUoGyBSuTyfKV/VJaltxXk8bTf44AvYPxeVJXX9tWAbdaDJytGsBpat eekylKtViBpVHBOvEBX1RnFWnlv77PmkgmCc4DM1KdHgRDM4eBUtcdyi1ifWldSdYmgSEKZ2bGfx yTdK2fs/bot2Fp8l1iV797fLAOV7CD1777fLAC1R8/LioQzRPC4vEd1moy4FSBmjl2hjjo606SVA SyRsq2lmL/d2NotNlWZaXIoyhPrPr95fAAAA//8DAFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsB AAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7q Kvq+AAAAOAEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGr 3IroAwAAPyYAACEAAAAAAAAAAAAAAAAAEgIAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIx LnhtbFBLBQYAAAAAAwADAMkAAAA5BgAAAAAPAAwEMB0AAA8AAvAoHQAAUAII8AgAAAAFAAAABZQA AA8AA/DMHAAADwAE8CgAAAABAAnwEAAAAFQAbwAAAAAACAAAAF2hoSUCAArwCAAAAACUAAAFAAAA DwAE8C4BAAASAArwCAAAAAKUAAAACgAAgwAL8EgAAAB/AAEA7wGAAKi2qSW/AAAABgC/AQEAEQD/ AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAPAD IAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAACAP+/DwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAA AENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZl bA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAAD AAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDWCAAAEgAK8AgAAAADlAAAAAoAAIMAC/BWAAAA fwABAO8BgACIr6klvwAAAAYAvwEBABEA/wERABkAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAg AFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADEAAAATACLx2AcAAKnD0gcAAFBLAwQUAAYACAAAACEA Mjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbog sAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEc jIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3 qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7 VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8D AFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5 kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx +g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3f dP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdP mh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEAa+ErCG8DAAD1BwAAEAAAAGRy cy9zaGFwZXhtbC54bWysVc1uEzEQviPxDpbvkKRNS4m6RW2hgBSqiLTiPLvr7S7x2ovtTZMey/Mg kEDi0rfpA/QVmBlv2vIjBJQemvF6xvPN943H208WtRZz5XxlTSIHD/tSKJPZvDIniTw+OniwJYUP YHLQ1qhELpWXT3bu39tuRr4RGGz8qElkGUIz6vV8Vqoa/EPbKIN7hXU1BFy6k17jlFcmQMBEte6t 9fubvRoqI3fwKDOfNhNHVnY4nzhR5YnclMJAjSmfQlBioiFTpdW5cmIge51rjAKEMrbZzHd44E/w 5A5OscjvoAhjnzushhP0GMwKl0FYlLQpRVg2iCoPSMwZZgJdSAS8SOQa4cKw6MvGKtxjeSI9fWVz DIU2WCwbRovC1XfFTOfYohCYf7jxCGmVYonkbawPBxt9AgQjtQgiI3yD9fVNcsjQY/hocy069CIQ 8mycD8+VvTMoQQcl0qkscKEwH/tA5NykoHTa/I/q6ypgU+iqTuRWn/5i1aWC/JnJmYEAlY42ItCG VSJJSNGw2LP5kuCk+Isyxab+9ybC24S1l9adSXHqAPvJv2vBKSn0S+MT+XgwHKIIgResmRTu9k56 e8e09b7V1JMCTIanJhI7L5r7AVekp60bCGMzbTJyXCl5tHgDrum0CNgFh3ZaQqN+JUn0ZYUiDayP D9Ow1OqulPBZcz1gxmGUq+L1xMV20KvPJEyXjvH/j5x06WpwYyYJjddsYEr+rUyOA4lN0Cc4/bQU CO0I0inea1YJuXUheisYmz03YyEKa8Iuh6TgSVecaqbbxpASzAmOlklrMjw+6qFJHCrMN9kkC2IO pOl1u3Jb3njsqeJHX+5qdMP4m93dIvzGr9tN233tjhZ8EdJ2enZtHmAZ14tDHO/dXUnjZf1eqE47 ZfIJOED9xKytq9q+rSKpWHMilXlwPI1zcTCkSZNGpvl/m0iDSeg9cdUM56CxU7akmClHrw9Pr4xu TOdI/YynGHpHdHWmXvCSSNcVvUa8N3HWFmQTFXS5YWTsQaV112H8xVtd5fSR+aJnSiErUYawiAMf yb3tpYoC59eKi3ZsOq5aOqazWXl+EQp8nxK56yrANspKcF5xbzGnCm75XF18uLr4LK4uPl2ef7k8 /3r5/v3l+cefgzL/10HYHzcCxXHLs2414/BN8s3ONwAAAP//AwBQSwMEFAAGAAgAAAAhALS+lQDV AAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj91Kw0AQhe8F32EZwTu7qT/Bxm5LEURBvGjtA4zZ yQ9mZ9PdSZq8vYsXenk4h+/wrbeT69RIIbaeDSwXGSji0tuWawPHz5ebR1BRkC12nsnATBG2m8uL NRbWn3lP40FqlSAcCzTQiPSF1rFsyGFc+J44dZUPDiXFUGsb8JzgrtO3WZZrhy2nhwZ7em6o/D4M Lp0s9TC+T7u70/3Dx3E+rVa6DmLM9dW0ewIlNMn/ePB5hf6v/EW9WQM5qOp1/gqt3WMUCgaSWzJN lqA3PwAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAA W0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAA AAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBr4SsIbwMAAPUHAAAQAAAAAAAAAAAA AAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAAAA AAAAAAAAAAAAxQUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAADHBgAAAAAAABDwCAAA ABQQIAFgBkARDwAR8BAAAAAAAMMLCAAAAAIAAAAHAf+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEP GgAAAAEAAAAAACAACgAAAAD/BwABAAAAAAACAA4AAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8M AAAA8AAAANQB0ALwAxAFDwAE8BgJAAASAArwCAAAAASUAAAACgAAgwAL8FoAAAB/AAEA7wGAANi5 qSW/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABh AGMAZQBoAG8AbABkAGUAcgAgADIAAAATACLxEggAAKnDDAgAAFBLAwQUAAYACAAAACEAMjy9PvsA AADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAj e5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtk vW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Biz ut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM 4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQU AAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2 QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaH E0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7B VAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPN S/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEA7nqC8agDAADsCQAAEAAAAGRycy9zaGFw ZXhtbC54bWzsVs1uGzcQvhfoOxC8J/qJ/BMh68A26jSAYgiRih6N2V2uxYpLbkmuLPnoPE/RAi3Q i9/GD+BX6MxwZdltUbR1Dj10D9rhcsj5Zr750Zu369qIlfJBO5vJwcu+FMoWrtT2MpPfzM9eHEoR ItgSjLMqkxsV5NujL79404xDI/CwDeMmk4sYm3GvF4qFqiG8dI2yuFc5X0PEpb/sNV4FZSNENFSb 3rDf3+/VoK08wqvsatZMPUnF+WrqhS4zeSCFhRpNnjkXlRdTA4VaOFOiPJS9TjmdAwQzccUydIjg 7yAqPVyhm0/ACOveefRnQAZ6DGeLzCIwMtosRNw0iKuKHmNzncnvW/CIUCLsdSZfdUeTPt6xcy6g kyK/+uBKPA5tdOg8jNeVr5+Lm+5xVSXI/mA4wuhKscnk/t6r0WCvT4hgrNZRFKgwPHy9t08KBWqM DvaHSaGXkJBm40N8p9yzUQm6KJNeFZE9hdUkRArszgSZM/ZzuF9ryhKj60we9ulJXi8UlF/ZkiMQ QZskIwJjmWHihGiN6xNXbghOjm/kKeX2v88kLCr0feH8tRRXHjCpAiWKksK8tyGTrwejEZIQeTHa Oxjiwj/eyR/v2LY+dYYSU4At8NZMxq14GnFFfLq6gTixs6YgxS2T8/W34JuOi4hZcO5mC2jUn1GS dJmhFAbmJ8RZ3Bj13JDwXSsz4IjDuFTVx6lP6WC2n4mYzhzj/xw2qepq8BMOEgofWUCT/Na2xL7E IphLbIIF1TWCm0M+w+pmnoibmPQVTOyJXzIVlbPxmA/lEIhZbG+228YjC7CX2GGmrS3QQGLEED3k WmiKaRHFCojVh4TlxNxpnKjq97qc16iG53e7x1X8C71uN29PjZ+vuRTydnb9IJ6hGw+Lc+zzXbXk qVyfUtWxh0UDY4+RXba1rt13OgUVPc6kji/ez1NvHIyo0+QcraTSZtKiCRorXi+xEVo3Y0mKpfI0 hLh7FVQxnSLlM95iaZwYfa2+5iWF3GgaSrw39c5VLJfaR2xt+DXU8dQowEv7nO1U8zC27kwb0yUe fwnO6JI+chBpiCkMVeImrtMwwIg/1lJVhW1tG6B2YrsAtnRNJ3M68LSocHZl8thrMFinC/BBccpx oBU80rm//eH+9mdxf/vT3c0vdze/3n36dHfz4x8PFeEfH8KkQcLIxXgk0nMhLi4E9WNMH9pmUvnn v80sQfyfzB2ZTyhEIhuebduZhn9CQnP0GwAAAP//AwBQSwMEFAAGAAgAAAAhAP0CoqfWAAAA+QAA AA8AAABkcnMvZG93bnJldi54bWxEj8tKA0EQRfeC/9CU4CaYnvjOmE4IgigEF4nBdTldmRmc7p50 V+bx9xYudHm5l3M5i9XgGtVRTHXwBmbTDBT5Itjalwb2Hy9Xj6ASo7fYBE8GRkqwWp6fLTC3ofdb 6nZcKoH4lKOBirnNtU5FRQ7TNLTkpTuE6JAlxlLbiL3AXaOvs+xeO6y9PFTY0nNFxffu5ORkpk/d ZljfHG/v3vfjcT7XZWRjLi+G9RMopoH/x/2Ew+fkr/xFvVkDD6AOr+NXrO0WE1M0IG5iKpaglz8A AAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAs AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA7nqC8agDAADsCQAAEAAAAAAAAAAAAAAAAAAo AgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAAAAAAAAA AAAAAP4FAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAAQcAAAAAAAAQ8AgAAAAUELAH 0A5AEQ8AEfAQAAAAAADDCwgAAAADAAAACQL/vw8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJ RVRGODcgaTJycyBXRwAAoQ8eAAAADwAAAAAAIAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwA AADwAAAA1AHQAvADEAUPAATwYAkAABIACvAIAAAABZQAAAAKAACDAAvwZgAAAH8AAQDvAYAAiO5u IL8AAAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIA ZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAAMwAAABMAIvE+CAAAqcM4CAAAUEsDBBQABgAI AAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4s EEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/F jVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2Wk XOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44N T/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcA AAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA 38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefj YODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvG gfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05pa oB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQAjHu3c1AMAAFALAAAQ AAAAZHJzL3NoYXBleG1sLnhtbOxWzW7jNhC+F+g7ELx7bfkvjrHKwnGa7QLewFi76LEYSVSsmiJV knLsFL1kn6foAlugl7xNHiCv0BlSjrNtUbRNDj2sD/JQnP9vfvTy1baUbCOMLbSKefSiw5lQqc4K dRnzb5bnrRFn1oHKQGolYr4Tlr86+fKLl9XYVgyFlR1XMV85V43bbZuuRAn2ha6EwrtcmxIcHs1l uzLCCuXAoaFStrudzrBdQqH4CapSm0U1N0SlF5u5YUUWczSsoESTC1lkgl3UZSIMm0tIxUrLDOke bzciQRrQpZlO17bxC/6JX5mBKwz2E5eY0q8NRhWRgbZ3au+fQvfIaLViblehd1Zm6Bom6TrmP9Rg nDAc/d/GvN9IBxFUc4jSYrQsuXqrM9QAtdOYBRhvc1M+1XXSo/Ocof3hYNDDNHO2I7rXjwYd8gjG YutYigzdqNcbEkOKHP2jYTcwtIMnxFkZ614L/WSvGCmKuRGp85HCZmYd5fZggsxJ9RzhlwViwGRR Yg116BeiXgnIvlKZz4CDQgYaPZDKg0yYELJue6qzHbmT4D/iFIr8vxcTdhfGvtLmmrMrA1hXlgpF cCbfKBvz46jfRxCcP/QHR108mMc3yeMbVZdTLak2GagUtcbc7cmpwxPhqcsK3EwtqpQY90gut9+C qRosHFbBhV6soBJ/BUng9QiFNHh8rFu4nRRPTYnXtZGRzziMM5G/m5tQDnL/moBpzHn/n8MmdV0J ZuaThMQ7T6BJ/1+oDAeUJ0Fe4jTERkbXlpAssLc9SoSMC9wCZurUrD0QuVZu4kUSsIQrTjnVXKPI CtQljph5rVJUH/CQBA4FZqt0njq2AcL0oVx9WR44TkX+R15f1ciG8ofbSe7+hq+5TeqpNMutb4Sk Xlw/kOcYxsPhAsd90ytJaNZPgWqwy2Xmp/WPw9F0dHYUdVrRUXTcmvT6k9Zxd3TWmg6is86oGw36 vd5PWOXN0MSRjpXsK88gKuu6LEr9fREAwXzFvHCtN8swV6M+TakkoOSfdcwVOki7yRRrHKJKLzzF 2VoY2mR+8qXUbQ0j9QJqUbSTZHEtvvZHAkwWtNn83dxonRNNaaTBAGOlzwspm+r0b6zGjUQvfa5p 5QnMaIDQbcPSQGAec4k8x9m3z2M9U02ea1LT0L5qfIJy3HExn5gCJDbzCowVvi49HgIe8dzf/nx/ +5Hd3364u/n17ua3u/fv725++bNQav+1ENYWIkMhfm4bysKzto07+Y6WH3YrPrGHyIBQ2RwM4Cj8 3A6Yjv9fOxwACl8u/rNh/7mA33e2OvkdAAD//wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAP AAAAZHJzL2Rvd25yZXYueG1sRI/LbsIwEEX3lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy 9x110S5Hd3TuPbNFZ2vRUoiVdwrGowwEucLryhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3 yQiGuJijgjKlJpcyFiVZjCPfkOPs7IPFxGcwUge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu +Xh5et4e+st0Kk1ISt0Pu+UbiERd+n8262O2Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA //8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACMe7dzUAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIA AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAA AAAqBgAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAC0HAAAAAAAAEPAIAAAAFBAgEGAV QBEPABHwEAAAAAAAwwsIAAAABAAAAAgC/78PAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAA AKEPHAAAAAIAAAAAACAICgAAAAD/AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIA AAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABlAAAAAwAAGMAC/Ak AAAAgQEAAAAIgwEFAAAIvwEQABAA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBPOAAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMgAAAIsTCQAAAAAAJAQBAAAACg8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACL E3UAAAAAAOsuCAAAAErJxwHgjHi/AAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfx IAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAA DwACKwAAAAAAAA4Exg4AAFBLAwQUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5 cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTS zL33zKhcH8ZB7TEm56nSq7zQCsn6xlFX6c/NS3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwY k2yPI6TcBySptD6OwHKNnQlgt9ChuS2KO2M9MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4 CyygZqqas7qIQ7og3FPziy5byHJRzuapdyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+ bZ3FxtvdKOvIZ+PF7E8Aq/+J/s4089/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEA AAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cG CrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRul SLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMA AACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhF YrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4 GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBL AwQUAAYACAAAACEA7QFet1EJAAB8OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gS fl9p/gPivac4DIZSu0ecmocdzairR/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOT fvvL10Opfc6btqirlW7+bOhaXq3rTVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5 Bs9X7WO20vddd3x8eGjXMJy1P9fHvIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7Bd/rfI u+0b19ffcc5JCeyrrsWBddk8Id+ckTNizSTkm48mErXN7jkqG+1zVq50g3z0h3dvH7JHRlB2Q7qU fBgdI9h8tKb4EYKyG9J5Bn4FP0KQrdewkOHcYZgYic1oe0T0csjbho/vS/Q9/vZAZmltlCkhopeL Ab2ksx4RvXQG9HGQxEkqyUOIKL07oLdiK/YCiZ4Q7cui+jigNgwfPoxakGzr8tdRct+PIoMr/kQF 1hfOg1Ns66obcyUdbx6yv+omBQr8UWZdUWndt2O+zdbgokFTZCWKkz3mWW+cDq3bsyGYWGJ3KKpZ eZ/YwUynVZE1HuQl/r7dFuucrHBblOVT963M/92SRbZ1WWxSGMTnCHRzAaHjHi6Z/iW6XZORZ7Sm 7v5TdPunfXYEBVEw7lrGetdqx7oFJJKJR3njpKDkjkLWQf+j2myz7rd6Q4ftPpIFG4LrHQkOfCIb GVw7mb183WQmleqi2uSlmUQ04jvS0sSSwYbDpcGg0Cb4vJZhTDZdCJ4ou9auszLfoN5plONmwan5 9cwmYqumC9lnm5yaSBrumc4ktuMuRAI4uNSI6W7TptAaKG1aCOIWPDC8WMmcAVcsWcQ5msqqj62y 0r6sdN+xHF1bZ8eVvoWQApeHIxitrXa6lpU7SLrrrqFeO4lF4m2nFfvjXmUafHzgVRKMj03bxVm7 pzYkt5ipygpnovJbzgKdbZ4FUEd9gRS2By7y3aQAPcqmzbfbfN31jd0bQd3RnywS1p+6vHnab75o z+Wn5n0G5ged4no2RdutdAJo/NGsdNQ2uSXHVhbXRiocnC0rj/uMRUsPn2Z6puTEVYUM5FdPPFjb qOxkcbcvBRE/11L6bvyDLQXTQV7l9gYtsIYSuck0xOtKr5tuX0MUOu6LddpArUJiB3iLBtEFs60G hTr52+Sf8S/1BcoDuZXFbt+9L3ZaU0A66fZNnv8BYYl43wQzk6UeypIzIh7VE7c9UrGf8895+QFj oIsxWNf24OokmjD3JHTn/if/Zgh63mGN0sebFENEVKcY+F8XLhTMsCiwWi/7TSQeTO60QqLPk8d5 juwvBG+cqqQFR4WU/Hyfwf6FIlyTgHu5lkaswYothwsHVhRGIf6BpRoMinrmmHV7Df+B/Fc06/JU nn6o30Ns1aCHQ2bgNuDVbzCqwSUGSHr1DHUPHaTOhKzoDKw4Ra3xZD1zFSTmPVM2SsbxNlz9yd43 KlsUUfJ0EhaH071c2UzDkq7p2EVVw2TnEIWhLe9DiGHIdkG/qa+f/wJDx9BefSppm98e4RfBwfGP hnjXc735xi7LliZc6nXYwyBlWb3Pt1qx+cr7D6EJCiHai/ISmVDjY1i5iQftsaZBfpDR46M0W4qH remHxRNkZgjZ4mHSFI4xgJ0IFrixtQN6osKWrhpUKzRVVq9R2RXCj6tstM+6VmW0UVQa6gUq676q VcY0BcobOl7+tWsyaE2eSPxlSUceRNutOcV9G4pvzFCbW6gdennfhopEEri8DQWe9Ft21J535kpH rGvgvSsd9il1GLNwzMIxuILNSGgU6Q7iSucQYyNwnxmA09h8xOYjCz6y4CMOH4HGlD7u8hEXqjTc XoPtXPyja3wJ0L2ynTcWl4boGI5cwgsNO/+kbVvfxS9bGtvXZbpG15a2ltMwTp0btm3T1PddzpuZ 63viJY2TKJTlV27bJksvcCKmG+YvKL/Yk5W0E0U2FCyMWpBw5xkoE1UjyE9UEKWF8+AzPzZeaIHy T8LLLcccuDOfyscE5CykB4UzDxrQf9f8EgWJdSa/Ei+hH/rJ8lq84KFOxNE1jZcgdZdCmDtexo8F F6Skfg1e4FzLTXk9OcOx4E35pX8k2UtCl/DixZErXKJHRC+H9VgSpUEq+ychovSvPxYcOXZU4mWZ hvb1eIGTY/cGvBhGAO06A+MdL+N4cV6NF7R5zHuCGfCyJB9mtql6DCeX/VmZXzDeCg+6Ai/IPuFr 64FqVrwEUr5Q4sWKMcNI9Ipj9DR14DyIUU/nFyxW73iBN01Y1Ul3BM76fVeBFydwPKZtloAYHKQa B31KxGwlXnqvk7D3UsZeO0Fu4mWJCbxABF24luQ/Sry4sZtGMr6U9VgQREbEPe4KvMQBfiV5SBKi jxIoSLoLgtALZXmUeHEtdxEuJP4KvBhGzzLTeEHyG/FCOnrS74PhWb8PrsL6fTAe78phR4DqAO7R i//Tfn95ES9OZJ7UNwNeyNY89z0FXuI0tnzeA0/gRepomUEwOjCTDFraMFn6LpehR0Qvh/VYZATw kfxTWY/dipfEAnjJ/JV4CSI3duT9CgVepMgzjZfYDiyTJ6/r6rEfDy/eRbwYhm2LvaQZ8IInViJv KPCCHXkvX/Xi//C1RpTwrL5S5hfDCE/nZlfgBdESyf48K16COPQSOT8q8QIaPMUwKr8CL6gboclp vEDpuTRMFhzueBnvX+hbwwwOUq2Avtjzb+KHr6vHEDHMHAq8JHYS9vYPlHhBTAsZqf8o8bJwvWAR Svmix3+YXxAvZ/F/XrwEQXyGRyVe7HQZL3junR0vRgJn1Xe85Kr+xaTHt2OAkRrvGRKM67mhE08D JjZjM+JOPVGQ+YZveHKAVgLGM/wk4E3ZFQkG2usglAugWQETufDlMZ3KowTM0vZSX5ZfkWDSNIpE iTCdYBI/jsRuwj3BjCcY8/J/NLEh1IvTsTkA40oZi0R2hgcps2E9JuqICcC4huMvObiuyDAggit4 XwMYL/TOMsCsgAkhhoTyCZISME7kRNfvKEvnU9OAQbWLdH0HzAXAXD7ih/8FZJiOyAivLskcy04s Hq0VJVmcRobHM9EEYLxoGS55FXEFYLzUSS3ZQZUlWWgHacAP/Sj/WQETAVxCGfBKwHim41hyS6XI MFEUwiurzILTgPEiSL+c/EcCDLzEIL8TQ14sg1HyKuS7vwEAAP//AwBQSwMEFAAGAAgAAAAhAA3R kJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00K wjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumV cZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHI u9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTf AAAA//8DAFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29u dGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAA LQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAA FgIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA7QFet1EJAAB8 OQAAFgAAAAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAA IQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1h bmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9u PSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1s bnM6YT0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21h aW4iIGJnMT0ibHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2Nl bnQxIiBhY2NlbnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0 IiBhY2NlbnQ1PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhs aW5rPSJmb2xIbGluayIvPgAADSsEAAAA9AisBQAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAA AKsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oA i7S2RfWHVgnJ23ftpBRKyGnRrmbmY1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwg yXV/fbXaHDKSYHWkTk615ketyUwYgFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9 FS97Xh9JWC7F0/HfHNVJyNk7A5VB9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5D YA5tC+nqAjf0FoekLpOeCUzD4AzaZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAI AAAAIQAXS2h7ugAAACgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUD QrJtg80mZKPo35tjBcHj7DBvdprTy8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrV XHHWuYR4cpFFoRArmHKORynZTOg1VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9j af7PDsPgDJ6DeXik/KNCZufLsI6GUKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgA AAAhACVGREEHAQAAygEAABIAAABkcnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2 e1k8eZL6A0Iy3Q00MyGZdd1/77RbBfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxet Clv0diaEXl+g6N1wf9ellkOUV0oMsLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020 AfWmz7foaZqCgz25UwTkq0mG2bLAl2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLY gB6mgIFBK/Fhm7nXCNKkVkgexkuStji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkN R+bGt2zrNwzfAAAA//8DAFBLAQItABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAA AAAAAAAAAAAAKQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAA AAAAAAAAAAAADAIAAGRycy90aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAABwAB4E cwQAAFBLAwQUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtO wzAQRfdI/IPlLYqdskAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ ETVnEHQ0Ngwt/9y9VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYP Min9pQaQt3V9J3UMBUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/M P7rqRCZIuT7H0Sa8OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCq K4p34pfRD5Nco+++AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5y ZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVO QVWUIMhpb6zrFdxvp80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4 Ycoy9jKgfmBPcluWOxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oK TORvYyGqIu8H2dRy8bf5AAAA//8DAFBLAwQUAAYACAAAACEA/+70YUIBAABwAgAAIQAAAGRycy9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbIxSy07DMBC8I/EPlu/ULQeEoiaVeF6AVmr5gMVx mgi/tHZD8vds3AQE6qEXaz2eGe94vVx1RrNWYWiczfliNudMWenKxu5z/r57urrlLESwJWhnVc57 FfiquLxY+izo8gV6d4iMPGzIIOd1jD4TIshaGQgz55Wls8qhgUhb3IsS4Yu8jRbX8/mNMNBYPurx HL2rqkaqBycPRtl4NEGlIVL/oW58mNz8OW4eVSCbpP7bUuw9pf3QYD85SzRsCVjwgpLLrS6ZBUPA XWIMYPA7VGqobPuMfus3mLhv7QZZUw7aUcPFeDDS0tYSjQrxT76fnCDrKjTFEjJ6AtblnCbVDyuJ IFNdZPIIyl9U1usTXFk/nmCL6QLq4OdSqqdYVA6xU+caX8GvW8oHGc05KrxPkKfJHjPIX8rgMf2U 4hsAAP//AwBQSwECLQAUAAYACAAAACEAR3I7tfsAAAC7AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAAAAAAAAAAAAA ACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQD/7vRhQgEAAHACAAAhAAAAAAAAAAAAAAAA ABMCAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwUGAAAAAAMAAwDJAAAAlAMA AAAAAAAdBAQAAAABAAAAIAC6DxIAAAA3AF8AaQBlAHQAZgAtADYAOQAPAPgDtEUAAAIA7wMYAAAA AQAAAAECBwkIAAAAAAAAAAAAAAACAP+/YADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAA mZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP// /wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA//// AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAH IAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf 0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/n AQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A//// AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8A mcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAAB AP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8sAAAA AAMAABAAow+AAAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP//7wAA AAAAAQAAAP//GAAAAAABAACABQAAEyDUASABAAAiAP//FACABQAAIiDQAkACAAACABIAgAUAABMg 8ANgAwAAAgAQAIAFAAC7ABAFgAQAAAIADgAgAKMPcAAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAe AAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//wwAAAAAAQAAAAUAACABIAEAACAA//8ABQAA QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA AAAAZAAAAAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAA AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAA AAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJ AAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABQAAQAA AAAAAAACABIAAgAAAAAAAAACABAAAwAAAAAAAAACAA4ABAAAAAAAAAACAAwAgACjDz4AAAAFAAAA AAAAAAAAAgASAAEAAAAAAAAAAgAQAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAMAAQAAAAAAAAAAgAK AAAAIwQYBwAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht bHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrvndhh JhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwx eyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HR FeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4z USkjcV1QvFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVs cy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/i SZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhA Lju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYs xoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAABk cnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWktu2zAU3BfoHQRuA8eW/JFsWA6SFFll ETTJAWiZstVQlEAxadxVkRyhN+i+aIEW6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9N8OX7sGt j7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRiAS1ikAwgDgiywRhF4KD3+lU37LDbczbGKNL4FCTqQBuM GAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1QOF7PrWPq0at1qr60CNAjadFxgeu6znoTeBc+4iweBKK MGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe25zGM5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe8JQc0Sv5 7AaEHcoufRghoI0gGfL9nl0Th4kOYqoodI6Qq57OHKbdQDlRtdetzrUeumxFP9U6QO5bvrLogw0a jZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K9xIgEo2NQ+RChzO957+rYCZ6wg6CqYbHhy+PD9+1x4dv k7sfk7ufk/v7yd1XoDkjSCMktykHOdF/D+L7j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g7+GxDSp6 rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh5AhGFDnNkpwNI0cwoshpCXJ8SE95am2aXLKAPAEwl/TF 2C3J8UWTzEJeFsAojMwZRm1dCpASIylYBDAKI2uGkV439VZ5kBKBJ5BRILVTIFmGZZUgJSAJZPhz 1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5Jj/E/oULy6d1Lzw08tet62D618fcO0gDYYM/Hz/HpiPl a4xivkZPVrDa15DN8zUxayZnrZlmzbCapvhhG1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V3bDUUcna zXlHE9Oi64262MrsazIMKxXDt+hr2io25i2MYoMjL5XYNLZtExuLX4lUA1vFy7x7iXkxak1ThOlt /Ep+/1oIXvpLppy1gle+bzGaekPGqn9/LoV9zBNm+xzkxezblTby3ZDRNnUpYkvki1wfr3Xm8z1W LHYLhaLyzK++Y14qlfKNW92yWgWTc4n8mshP3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgbIFK5PJ8p X9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1oMnK0awGlq156TKUq1WIGlUcE68QFfVGcVaeW/vs+aSC YJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1iaBIQpnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA5XsIPXvv t8sALVHz8uKhDNE8Li8R3WajLgVIGaOXaGOOjrTpJUBLJGyraWYv93Y2i02VZlpcijKE+s+v3l8A AAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAAr AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAavciugDAAA/JgAAIQAAAAAAAAAAAAAAAAAS AgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAAADkGAAAA AA8ADAQwHQAADwAC8CgdAABgAgjwCAAAAAUAAAAFmAAADwAD8MwcAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAIAAAAyy9YJAIACvAIAAAAAJgAAAUAAAAPAATwLgEAABIACvAIAAAAApgAAAAKAACD AAvwSAAAAH8AAQDvAYAAOHGjJb8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAA AAIA/78PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4 dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZl bAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAA DwAE8NUIAAASAArwCAAAAAOYAAAACgAAgwAL8FYAAAB/AAEA7wGAALh7yRq/AAAABgC/AQEAEQD/ AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAA NAAAABMAIvHXBwAAqcPRBwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55 /z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2 wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvI ImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5b LNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8B AAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRC L2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElU pUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyX xnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMA UEsDBBQABgAIAAAAIQCp2UM+bgMAAPUHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxVzW4TMRC+I/EO lu+QpE1LidiitlBAClVEijjP7nq7S7zjxfamSY/leRBIIHHp2/QB+grM2Jum/AgBpYdmvJ7xfPN9 4/Gjx4tai7myrjKYyMH9vhQKM5NXeJLI18eH93akcB4wB21QJXKpnHy8e/fOo2bkGkHB6EZNIkvv m1Gv57JS1eDum0Yh7RXG1uBpaU96jVVOoQdPiWrd2+j3t3s1VCh36SicT5uJZSs7mk+sqPJEbkuB UFPKJ+CVmGjIVGl0rqwYyl7nGqOAoIxNNnMdHvgTPLmFUyryOygCzTNL1Qw4QS+AWeFCgsVJm1L4 ZUOock/EnFEm0IUkwItEbnRh0Zfi12U5Kk+kpy9NTqHQekNlw2hR2Pq2mPkcUxSC8g+3HhCtUiyJ vK3N4WCrz4BgpBZeZIxvsLm5zQ4ZeQwfbG9Eh14Ewp6Ndf6ZMrcGJfigRFqV+VAozMfOM6frFJxO 4/+ovq48NYWu6kTu9PkvVl0qyJ9iHhjwUOloEwKNQVyWhBX1i32TLxlOSr8kU2zqf28iuk1Ue2ns mRSnFqif3LsWrJJCv0CXyIeD4ZBE8GERNJPC3txJb+5gWx8YzT0pADM6NZHUedE88LRiPU3dgB/j tMnYcaXk8eIN2KbTwlMXHJlpCY36lSTRNygUaQj6OD/1S61uS0k4a64HgXEY5ap4NbGxHfTqMwvT pQv4/0dOvnQ12HEgiYxXwaCU4bfCnAZSMEGf0PTTUhC0Y0indK+DSsSt9dFbwRj37SwIURj0eyEk Bce60lTDbptCSsATGi2TFjM6PuqhWRwuzDXZJPNiDqzpdbuGtlx77KviR9/Q1eRG8evdvcL/xq/b TdsDbY8X4SKk7fTs2jykMq4XRzTeu7uSxsv6vVCddgrzCVgg/cSsravavK0iqVRzIhXeez2Nc3Ew 5EmTRqbD/zaRSEn4PbHVjOYgmmmwpJgpy69PmF4Z35jOkfuZTkF+R3R1pp6HJZOuK36Nwt7EGlOw zVTw5YYRmsNK667DwhdndJXzx8AXP1OKWIky+EUc+ETuTS9VFDS/Vly0Y+y4avmYzg7KhxehoPcp kXu2AmqjrATrVOitwKmCGz5XFx+uLj6Lq4tPl+dfLs+/Xr5/f3n+8eegzP11EPXHWqA4bsOsW804 epNcs/sNAAD//wMAUEsDBBQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1s RI/dSsNAEIXvBd9hGcE7u6k/wcZuSxFEQbxo7QOM2ckPZmfT3UmavL2LF3p5OIfv8K23k+vUSCG2 ng0sFxko4tLblmsDx8+Xm0dQUZAtdp7JwEwRtpvLizUW1p95T+NBapUgHAs00Ij0hdaxbMhhXPie OHWVDw4lxVBrG/Cc4K7Tt1mWa4ctp4cGe3puqPw+DC6dLPUwvk+7u9P9w8dxPq1Wug5izPXVtHsC JTTJ/3jweYX+r/xFvVkDOajqdf4Krd1jFAoGklsyTZagNz8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAqdlDPm4DAAD1BwAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBL AQItABQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAAAAAAAAAAAAAAMQFAABkcnMvZG93bnJldi54 bWxQSwUGAAAAAAQABAD1AAAAxgYAAAAAAAAQ8AgAAAAUECABYAZAEQ8AEfAQAAAAAADDCwgAAAAC AAAABwH/vw8ADfBYAAAAAACfDwQAAAAEAAAAAAChDxoAAAABAAAAAAAgAAoAAAAA/wcAAQAAAAAA AgAOAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAYCQAAEgAK 8AgAAAAEmAAAAAoAAIMAC/BaAAAAfwABAO8BgABYe8kavwAAAAYAvwEBABEA/wERABkAPwMAAAgA gMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA1AAAAEwAi 8RIIAACpwwwIAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10u eG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa 1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkm XUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVL OPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dX uAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABf cmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q 9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2 WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+ omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAG AAgAAAAhAP/RnueoAwAA7AkAABAAAABkcnMvc2hhcGV4bWwueG1s7FbNbhs3EL4X6DsQvCf6iWQ7 QtaBbdRpAMUQIgU9GrO7XO9WXHJLcmXJR+d5ihZogV78Nn4Av0JmhivLbouiiXPooXvQDpdDzjfz zY9evV7XWqyU85U1iRw870uhTGbzylwk8sPi9NmBFD6AyUFboxK5UV6+Pvz2m1fNxDcCDxs/aRJZ htBMej2flaoG/9w2yuBeYV0NAZfuotc45ZUJENBQrXvDfn+vV0Nl5CFeZVbzZuZIys5WMyeqPJH7 Uhio0eSptUE5MdOQqdLqHOWx7HXK8RwgmKnNlr5DBP8GUe7gEt18BEYY+8ahPwMy0GM4W2QGgZHR phRh0yCuIjiMzVUif2rBIUKJsNeJfNEdjfp4x845j06K9PKdzfE4tMGi8zBZF65+Km66xxaFIPuD 4QijK8UmkXvjF6PBuE+IYKLWQWSoMDx4Od4jhQw1Rvt7w6jQi0hIs3E+vFH2yagEXZRIp7LAnsJq 6gMFdmeCzGnzNdyvK8oSXdWJPOjTE70uFeTfmZwjEKDSUUYE2jDDxAnRGtbHNt8QnBTfyFPM7S/P JCwq9L207kqKSweYVJ4SRUmh3xqfyJeD0QhJCLwYjfeHuHAPd9KHO6atT6ymxBRgMrw1kWErngRc EZ+2biBMzbzJSHHL5GL9A7im4yJgFpzZeQmN+jtKoi4zFMPA/PgwDxutnhoSvmulBxxxmOSqeD9z MR309jMR05lj/F/DJlVdDW7KQULhPQtokt+VybEvsQj6AptgRnWN4BaQzrG6mSfiJkR9BVNz7JZM RWFNOOJDKXhiFtub6bbxSAnmAjvMrDUZGoiMaKKHXPNNNsuCWAGxep+wnJg7jWNV/FmX8xrV8Pxu 96gI/6DX7abtiXaLNZdC2s6v7sVTdON+cYZ9vquWNJbrY6o69rBoYOIwssu2rmr7YxWDih4nsgrP 3i5ibxyMqNOkHK2o0ibSoAkaK65aYiM0ds6SFEvlaAhx98qoYjpFyme8xdA40dWV+p6XFHJd0VDi vZmztmA5r1zA1oZffR1OtAK8tM/ZTjUPE2NPK627xOMv3uoqp48cRBpiCkMVuQnrOAww4g+1VFFg W9sGqJ2aLoAtXdPJnA48LQqcXYk8chVorNMSnFecchxoBQ907m5+vrv5Tdzd/Hp7/fvt9R+3Hz/e Xv/y10OZ/+xDmDRIGLkYDkV8zsX5uaB+jOlD20wq//y3mSWI/5O5I/MRhUhkw7NtO9PwT4hvDj8B AAD//wMAUEsDBBQABgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LSgNB EEX3gv/QlOAmmJ74zphOCIIoBBeJwXU5XZkZnO6edFfm8fcWLnR5uZdzOYvV4BrVUUx18AZm0wwU +SLY2pcG9h8vV4+gEqO32ARPBkZKsFqeny0wt6H3W+p2XCqB+JSjgYq5zbVORUUO0zS05KU7hOiQ JcZS24i9wF2jr7PsXjusvTxU2NJzRcX37uTkZKZP3WZY3xxv797343E+12VkYy4vhvUTKKaB/8f9 hMPn5K/8Rb1ZAw+gDq/jV6ztFhNTNCBuYiqWoJc/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0+ +wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAP/RnueoAwAA7AkAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAU AAYACAAAACEA/QKip9YAAAD5AAAADwAAAAAAAAAAAAAAAAD+BQAAZHJzL2Rvd25yZXYueG1sUEsF BgAAAAAEAAQA9QAAAAEHAAAAAAAAEPAIAAAAFBCwB9AOQBEPABHwEAAAAAAAwwsIAAAAAwAAAAkC /78PAA3wXAAAAAAAnw8EAAAABAAAAAAAqA8OAAAASUVURjg3IGkycnMgV0cAAKEPHgAAAA8AAAAA ACAICgAAAAD/AQAHAA8AAAABAAIAAQAOAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8GEJAAASAArw CAAAAAWYAAAACgAAgwAL8GYAAAB/AAEA7wGAACgObyC/AAAABgC/AQEAEQD/AREAGQA/AwAACACA wzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUA cgAgADYAAAATACLxPwgAAKnDOQgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250 ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBU xNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg5 3hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0h xtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdx EbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMA AACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5 +7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKX ZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28 zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA //8DAFBLAwQUAAYACAAAACEAstCeytUDAABQCwAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1u20YQ vhfoOyz2rujHlOQIoQNbsdMAqiFEKnoshuTSZLXcZXeXsuSiF+d5ihZIgF78Nn4Av0JndinLaYKi rX3oITpQs9z5/+aHL15uKsnWwthSq5j3n/U4EyrVWakuYv7d8qxzyJl1oDKQWomYb4XlL4++/upF PbE1Q2FlJ3XMC+fqSbdr00JUYJ/pWii8y7WpwOHRXHRrI6xQDhwaqmR30OuNuhWUih+hKrVe1HND VHq+nhtWZjFHwwoqNLmQZSbYeVMlwrC5hFQUWmZIj3i3FQnSgC7NdLqyrV/wT/zKDFxisB+5xJR+ bTCqPhnoeqd2/il0j4zWBXPbGr2zMkPXMElXMf+pAeOE4ej/JuZRKx1EUM0+SovRsuTyW52hBmic xizAZJOb6rGukx6d5wztj4bDA0wzZ1uiD6L+sEcewURsHEuRYdA/OBgRQ4oc0Xg0CAzd4Alx1sa6 10I/2itGimJuROp8pLCeWUe53Zsgc1I9RfhViRgwWVZYQz36hagLAdmpynwGHJQy0OiBVB5kwoSQ dZsTnW3JnQT/EadQ5P+9mLC7MPZCmyvOLg1gXVkqFMGZfKNszJ/3owhBcP4QDccDPJiHN8nDG9VU Uy2pNhmoFLXG3O3IqcMT4amrGtxMLeqUGHdILjffg6lbLBxWwbleFFCLz0ESeD1CIQ0eH+sWbivF Y1Pida1l32ccJpnI385NKAe5e03AtOa8/09hk7quAjPzSULirSfQpP8vVYYDypMgL3AaYiOja0tI FtjbHiVCxgVuATN1YlYeiFwrd+xFErCEK0451V6jSAHqAkfMvFEpqg94SAKHArN1Ok8dWwNhel+u viz3HCci/yuvr2pkQ/n97XHu/oavvU2aqTTLjW+EpFlc3ZNnGMb94RzHfdsrSWjWj4Fqsctl5qf1 z+No+nw0HYw743502Bm/ik46h4NXx53p2fR02OuPB6fD4S9Y5e3QxJGOlewrzyAqq6YqK/1jGQDB fMW8dJ03yzBX+xFNqSSg5J9NzBU6SLvJlCscokovPMXZShjaZH7ypdRtLSP1AmpRtJNkeSW+8UcC TJa02fzd3GidE01ppMEAE6XPSinb6vRvrMaNRC99rmnlCcxogNBtwtJAYB5yiTzH2bfLYzNTbZ4b UtPSvmp8gnLccTE/NiVIbOYCjBW+Lj0eAh7w3N38enfznt3d/H57/eH2+o/bd+9ur3/7VCi1/1oI awuRoRC/tA1l4Unbxh39QMsPuxWf2ENkQKhsDgZwFH5pB0zH/68d9gCFLxf/2bD7XMDvO1sf/QkA AP//AwBQSwMEFAAGAAgAAAAhABP/D9jWAAAA+QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAQ RfeV+AdrkLorDvShkmIQQqpagVhAYT/EgxM1toNtQvL3HXXRLkd3dO49s0Vna9FSiJV3CsajDAS5 wuvKGQWHr/eHVxAxodNYe0cKeoqwmA/uZphrf3M7avfJCIa4mKOCMqUmlzIWJVmMI9+Q4+zsg8XE ZzBSB7wx3NZykmUv0mLluKHEhlYlFd/7q+WSsby2m275eHl63h76y3QqTUhK3Q+75RuIRF36fzbr Y7ZZ/4W/qE+tgIefP/pTqPQOY6KggN3YlC1Bzn8AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77 AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAstCeytUDAABQCwAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQA BgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAAAAAAAAAAAAAACsGAABkcnMvZG93bnJldi54bWxQSwUG AAAAAAQABAD1AAAALgcAAAAAAAAQ8AgAAAAUECAQYBVAEQ8AEfAQAAAAAADDCwgAAAAEAAAACAL/ vw8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAAAAAAIAgKAAAAAP8CAAcA AgAAAAAAAgAOAAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALw AxAFDwAE8DwAAAASAArwCAAAAAGYAAAADAAAYwAL8CQAAACBAQAAAAiDAQUAAAi/ARAAEAD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCI E84AAAAPAIoTKQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAyAAAAixMJAAAAAAAkBAEAAAAKDwCK E5UAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTdQAAAAAA6y4IAAAASsnHAeCMeL8AAB0Q BAAAAAAAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAA AAAA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAADgTGDgAAUEsDBBQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6 KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKrvNAKyfrGUVfp z81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2dCWC30KG5LYo7 Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OLLlvIclHO5ql3 Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr/4n+zjTz39Zf AAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfv hb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/ y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/ p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Q tbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhl bWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTV m0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHv LN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQC86CoBUQkAAHw5AAAW AAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxbWY+jSBJ+X2n+A+K9pzgMhlK7R5yahx3NqKtH+7ii bGwzjcEC+vr3E5GXSYMTuwptz6ptS104CSIjI+KLI5N++8vXQ6l9zpu2qKuVbv5s6FperetNUe1W +p8f0jeerrVdVm2ysq7ylf4tb/Vf3v30r7fZY7fPD7kGz1ftY7bS9113fHx4aNcwnLU/18e8gnvb ujlkHfxsdg+bJvsCfA/lg2UY7sMhKypdq7IDsPX+W+Td9o3r6+8456QE9lXX4sC6bJ6Qb87IGbFm EvLNRxOJ2mb3HJWN9jkrV7pBPvrDu7cP2SMjKLshXUo+jI4RbD5aU/wIQdkN6TwDv4IfIcjWa1jI cO4wTIzEZrQ9Ino55G3Dx/cl+h5/eyCztDbKlBDRy8WAXtJZj4heOgP6OEjiJJXkIUSU3h3QW7EV e4FET4j2ZVF9HFAbhg8fRi1ItnX56yi570eRwRV/ogLrC+fBKbZ11Y25ko43D9lfdZMCBf4os66o tO7bMd9ma3DRoCmyEsXJHvOsN06H1u3ZEEwssTsU1ay8T+xgptOqyBoP8hJ/326LdU5WuC3K8qn7 Vub/bski27osNikM4nMEurmA0HEPl0z/Et2uycgzWlN3/ym6/dM+O4KCKBh3LWO9a7Vj3QISycSj vHFSUHJHIeug/1Fttln3W72hw3YfyYINwfWOBAc+kY0Mrp3MXr5uMpNKdVFt8tJMIhrxHWlpYslg w+HSYFBoE3xeyzAmmy4ET5Rda9dZmW9Q7zTKcbPg1Px6ZhOxVdOF7LNNTk0kDfdMZxLbcRciARxc asR0t2lTaA2UNi0EcQseGF6sZM6AK5Ys4hxNZdXHVllpX1a671iOrq2z40rfQkiBy8MRjNZWO13L yh0k3XXXUK+dxCLxttOK/XGvMg0+PvAqCcbHpu3irN1TG5JbzFRlhTNR+S1ngc42zwKoo75ACtsD F/luUoAeZdPm222+7vrG7o2g7uhPFgnrT13ePO03X7Tn8lPzPgPzg05xPZui7VY6ATT+aFY6apvc kmMri2sjFQ7OlpXHfcaipYdPMz1TcuKqQgbyqycerG1UdrK425eCiJ9rKX03/sGWgukgr3J7gxZY Q4ncZBridaXXTbevIQod98U6baBWIbEDvEWD6ILZVoNCnfxt8s/4l/oC5YHcymK3794XO60pIJ10 +ybP/4CwRLxvgpnJUg9lyRkRj+qJ2x6p2M/557z8gDHQxRisa3twdRJNmHsSunP/k38zBD3vsEbp 402KISKqUwz8rwsXCmZYFFitl/0mEg8md1oh0efJ4zxH9heCN05V0oKjQkp+vs9g/0IRrknAvVxL I9ZgxZbDhQMrCqMQ/8BSDQZFPXPMur2G/0D+K5p1eSpPP9TvIbZq0MMhM3Ab8Oo3GNXgEgMkvXqG uocOUmdCVnQGVpyi1niynrkKEvOeKRsl43gbrv5k7xuVLYooeToJi8PpXq5spmFJ13TsoqphsnOI wtCW9yHEMGS7oN/U189/gaFjaK8+lbTNb4/wi+Dg+EdDvOu53nxjl2VLEy71OuxhkLKs3udbrdh8 5f2H0ASFEO1FeYlMqPExrNzEg/ZY0yA/yOjxUZotxcPW9MPiCTIzhGzxMGkKxxjATgQL3NjaAT1R YUtXDaoVmiqr16jsCuHHVTbaZ12rMtooKg31ApV1X9UqY5oC5Q0dL//aNRm0Jk8k/rKkIw+i7dac 4r4NxTdmqM0t1A69vG9DRSIJXN6GAk/6LTtqzztzpSPWNfDelQ77lDqMWThm4RhcwWYkNIp0B3Gl c4ixEbjPDMBpbD5i85EFH1nwEYePQGNKH3f5iAtVGm6vwXYu/tE1vgToXtnOG4tLQ3QMRy7hhYad f9K2re/ily2N7esyXaNrS1vLaRinzg3btmnq+y7nzcz1PfGSxkkUyvIrt22TpRc4EdMN8xeUX+zJ StqJIhsKFkYtSLjzDJSJqhHkJyqI0sJ58JkfGy+0QPkn4eWWYw7cmU/lYwJyFtKDwpkHDei/a36J gsQ6k1+Jl9AP/WR5LV7wUCfi6JrGS5C6SyHMHS/jx4ILUlK/Bi9wruWmvJ6c4VjwpvzSP5LsJaFL ePHiyBUu0SOil8N6LInSIJX9kxBR+tcfC44cOyrxskxD+3q8wMmxewNeDCOAdp2B8Y6Xcbw4r8YL 2jzmPcEMeFmSDzPbVD2Gk8v+rMwvGG+FB12BF2Sf8LX1QDUrXgIpXyjxYsWYYSR6xTF6mjpwHsSo p/MLFqt3vMCbJqzqpDsCZ/2+q8CLEzge0zZLQAwOUo2DPiVithIvvddJ2HspY6+dIDfxssQEXiCC LlxL8h8lXtzYTSMZX8p6LAgiI+IedwVe4gC/kjwkCdFHCRQk3QVB6IWyPEq8uJa7CBcSfwVeDKNn mWm8IPmNeCEdPen3wfCs3wdXYf0+GI935bAjQHUA9+jF/2m/v7yIFycyT+qbAS9ka577ngIvcRpb Pu+BJ/AidbTMIBgdmEkGLW2YLH2Xy9AjopfDeiwyAvhI/qmsx27FS2IBvGT+SrwEkRs78n6FAi9S 5JnGS2wHlsmT13X12I+HF+8iXgzDtsVe0gx4wRMrkTcUeMGOvJevevF/+FojSnhWXynzi2GEp3Oz K/CCaIlkf54VL0EceomcH5V4AQ2eYhiVX4EX1I3Q5DReoPRcGiYLDne8jPcv9K1hBgepVkBf7Pk3 8cPX1WOIGGYOBV4SOwl7+wdKvCCmhYzUf5R4WbhesAilfNHjP8wviJez+D8vXoIgPsOjEi92uowX PPfOjhcjgbPqO15yVf9i0uPbMcBIjfcMCcb13NCJpwETm7EZcaeeKMh8wzc8OUArAeMZfhLwpuyK BAPtdRDKBdCsgIlc+PKYTuVRAmZpe6kvy69IMGkaRaJEmE4wiR9HYjfhnmDGE4x5+T+a2BDqxenY HIBxpYxFIjvDg5TZsB4TdcQEYFzD8ZccXFdkGBDBFbyvAYwXemcZYFbAhBBDQvkESQkYJ3Ki63eU pfOpacCg2kW6vgPmAmAuH/HD/wIyTEdkhFeXZI5lJxaP1oqSLE4jw+OZaAIwXrQMl7yKuAIwXuqk luygypIstIM04Id+lP+sgIkALqEMeCVgPNNxLLmlUmSYKArhlVVmwWnAeBGkX07+IwEGXmKQ34kh L5bBKHkV8t3fAAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1l L19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUN Nj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeR SyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z /TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJvo cE/8AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAtAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAWAgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5h Z2VyLnhtbFBLAQItABQABgAIAAAAIQC86CoBUQkAAHw5AAAWAAAAAAAAAAAAAAAAANMCAAB0aGVt ZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAA AAAAWAwAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc1BLBQYAAAAABQAF AF0BAABTDQAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBz dGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVu eG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBi ZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFj Y2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2Vu dDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAANKwQAAADQ 9bB4AAALKxMEAABQSwMEFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAABbQ29udGVudF9UeXBlc10u eG1sfJDNasMwEITvhb6D0LVYcnsopcTOoT/QS9tD+gCLtLZF9YdWCcnbd+2kFErIadGuZuZjVut9 8GKHhVyKnbxVrRQYTbIujp382rw2D1JQhWjBp4idPCDJdX99tdocMpJgdaROTrXmR63JTBiAVMoY +TKkEqDys4w6g/mGEfVd295rk2LFWJs6e8h+9YwDbH0VL3teH0lYLsXT8d8c1UnI2TsDlUH1fNVn dQU9XRDuov1H15zIFCsXc5pcpptTwgdXU5xF8QmlvkNgDm0L6eoCN/QWh6Quk54JTMPgDNpktoFL ULkg8Vyyg1d/zr8Meqm6/wEAAP//AwBQSwMEFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAABfcmVs cy8ucmVsc4SPwQrCMBBE74L/EPZuUz2ISFMvIvQq9QNCsm2DzSZko+jfm2MFwePsMG92mtPLz+KJ iV0gBduqBoFkgnU0Krj1l80BBGdNVs+BUMEbGU7tetVccda5hHhykUWhECuYco5HKdlM6DVXISIV ZwjJ61xkGmXU5q5HlLu63su0ZED7xRSdVZA6uwXRv2Np/s8Ow+AMnoN5eKT8o0Jm58uwjoZQqDqN mBXYxIt7Vf4F2Tbya1/7AQAA//8DAFBLAwQUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAGRycy90 aW1pbmdJbmZvLnhtbIyRQUvEMBCF74L/IeRu04qIlLZ7WTx5kvoDQjLdDTQzIZl13X/vtFsF8bKn mZC8x/deut1XnNUn5BIIe91UtVaAjnzAQ68/xteHF60KW/R2JoReX6Do3XB/16WWQ5RXSgywtLbX R+bUGlPcEaItFSVAuZsoR8tyzAfjsz2LJM7msa6fTbQB9abPt+hpmoKDPblTBOSrSYbZssCXY0jl xy3d4pYyFLFZ1X+QhiUcvhVelmTzMtyIKnhpSCt/EtiAHqaAgUEr8WGbudcI0qRWSB7GS5K2OL4T 8S9V8/SPKwaXqdDElaNorgFNojPkRGHN2NTXoszQmQ1H5sa3bOs3DN8AAAD//wMAUEsBAi0AFAAG AAgAAAAhADIZJM74AAAAqwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAAAAAAAAAAAAAAApAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAAAAAAAAAAAAAAAMAgAAZHJzL3RpbWluZ0lu Zm8ueG1sUEsFBgAAAAADAAMAugAAAEMDAAAAAIAAHgRDBwAAUEsDBBQABgAIAAAAIQBHcju1+wAA ALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07DMBBF90j8g+Utip2yQAgl6YLHCgGL8gGW PUks/JLHqZq/Z5IWCVDV1Wged+7RbbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U95xhUcEoFwO0fAbk 2+76qtnNCZCROmDLx1LSg5SoR/AKRUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwFQqnK8oN3zRP0anKF PR9ofCQhOWePx7vFquUqJWe1KgQql608q8vg8IJwH8w/uupEJki5PsfRJrw5ObxTNNkaYB8qlzfl iUOajBIdDV/VHKfyp9mIy+Bn/GPfWw0m6slTJiJlQKorinfil9EPk1yj774BAAD//wMAUEsDBBQA BgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYgg eBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+nzR4EJ3QGR+9IwUwM bbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7Gb8Z0CyY4mwUxLOp QNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLxt/kAAAD//wMAUEsD BBQABgAIAAAAIQD9ul/OEgQAAAYOAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu eG1szFfLkto4FN1P1fyDyvsEbGOgXQ2pGmaSTafTFcgHCFu0nciPktQE8vVzrmzRmDDBdM8iG7Dl c4/u+0q373aFZFuhdF6VM89/O/SYKJMqzcvHmfdl9f7N1GPa8DLlsirFzNsL7b2b//nHbR1rmd7x ffVkGDhKHfOZlxlTx4OBTjJRcP22qkWJb5tKFdzgVT0OUsW/g7uQg2A4HA8KnpdeK6/6yFebTZ6I v6vkqRClaUiUkNxAf53ltXZsdR+2WgkNGivdVcnsa1hbrb+udh6zMLXFgu/NYXmylCkreYGFRVUa MLDvucnYgtekh8XoeqWEIHS5/aDqZf2grOj99kGxPCWqlsIbtB9amH0tAcPD4ET80THxeLdRxfyW x/AI2808BG5PvxDisdgZljSLyfNqkn06g02yf86gB24DaHDYFDGvG4t+Nidw5qxyIwXzD1Y1UA7R uyr5pllZwU4yvzEvud86MrKZ6OuMNe43RNXimo/WHw6vrU+dogdPjKIJcsu6I5iEw+jEJ+FwOA39 0GPkGd8fBy3iYDGPa6XNB1EVCLw2M0+JxCCmPObbO21I7WeIDVGjSB2b3V9VuifkGv+IMwoL8lml fniMlwkeZt66CZHUZmn2EhnCY7mVPmxhXD6iCKXdKxWbz1jSP2YerIE5a+ezA94qcsyD4PAYLsQP RCWnGhblmy9L1HBhFlJw0LfuMPOFzJNvzFRMpLlhH7k2QjHrclQ8NCMzjd3DUooyfeCKk1LHzK07 rB+c/YhSkyj/nS7wf7eAHiRPRFbJFEoEr0uePEXqu/zqnzdhNIkoF6iOziVO5Ps+EE3iRNMo9JFF jflNLVqzmxR2nnCZABjC9nPIafko0iElbkPZ5oSV28qgTfUjbDA9xjoAxMIz2NEx1gGAHZ3BUrYd dHAAYKNLWAcAdnwJ6wDATi5hHQDY6SWsAwB7cwnbAJDlx4GxNQRJBoZDsbyypqgd25LSnZqiNkLx 7W5pE/eKMl6KpCpTJsVWyB70trauoF9luerPbgviCvb31ZPC4Oyr/IgS8xr6fHOWHRPyf+1mI9fN VhTq41ZmHYITg5tyL5qDNE3QwjEKMi43Ho4PaHA2kHYeUsuxD0ub8dR8aelXg9EfhZHf1PnzaaEz GUfjG384fnWDYwVXd1RHLC9THJTokVRbP93jPGmjedTT/E6foplIWFQitbeWyo33XnydfnrSI1u+ G39Eu/bTr9MbT/poy+eHE3/cl/DmF73W8U2DKbX6Xgp2+E76ccsXBFOo9xK+k57t+CYjO7au1++k r7d8RNY7IB17T3q/4xtHk5fF4/eYD6hsd5qwBwxb6+52gRW6jNgLhFQfef1pa0sGty+c5hZ2qcZ9 i+Y5oM8QonL3t/m/AAAA//8DAFBLAQItABQABgAIAAAAIQBHcju1+wAAALsBAAATAAAAAAAAAAAA AAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAHDwONy+AAAAOAEAAAsA AAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAP26X84SBAAABg4AACEA AAAAAAAAAAAAAAAAEwIAAGRycy9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbFBLBQYAAAAA AwADAMkAAABkBgAAAAAAAB0EBAAAAAEAAAAgALoPEgAAADgAXwBpAGUAdABmAC0ANgA5AA8A+AM0 RwAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAIA/79gAPAHIAAAAP///wAAAAAAgICAAAAA AAC74OMAMzOZAACZmQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYA AGAA8AcgAAAA////AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAA lpaWAAAAAAD///8Ajcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/ UFAA/5kAAGAA8AcgAAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAA AAD///8AXB8AAN/SkwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bM AACwAABmzP8A/+cBAGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAH IAAAAGhrXQD///8Ad3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD/ //8AYFl7AGZm/wCZzP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIye oAAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAA AAEAAAD//ywAAAAAAwAAEACjD4AAAAAFAP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgAAABAAgAA AAACAAAA///vAAAAAAABAAAA//8YAAAAAAEAAIAFAAATINQBIAEAACIA//8UAIAFAAAiINACQAIA AAIAEgCABQAAEyDwA2ADAAACABAAgAUAALsAEAWABAAAAgAOACAAow9wAAAABQD//T8AAAAiIAAA ZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//DAAAAAABAAAABQAAIAEg AQAAIAD//wAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAABQD//T8A AAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAIAEAAAAABwAAAP//7wAAAAAAAQAAAP//EgAAAAABAAAA BQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUA AAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAAB AGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAA AAAAAAIAFAABAAAAAAAAAAIAEgACAAAAAAAAAAIAEAADAAAAAAAAAAIADgAEAAAAAAAAAAIADACA AKMPPgAAAAUAAAAAAAAAAAACABIAAQAAAAAAAAACABAAAgAAAAAAAAACAA4AAwAAAAAAAAACAAwA BAAAAAAAAAACAAoAAAAjBBgHAABQSwMEFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAABbQ29udGVu dF9UeXBlc10ueG1sfJDLasMwEEX3hf6D0LZYcroopdjOoo9dH4v0AwZ5bIvqhUYJyd937KQQSshq mMede7jNeu+d2GEmG0MrV6qWAoOJvQ1jK783b9WjFFQg9OBiwFYekOS6u71pNoeEJFgdqJVTKelJ azITeiAVEwbeDDF7KNzmUScwPzCivq/rB21iKBhKVeYfsmtecICtK+J1z+MjCculeD7ezVathJSc NVAYVM9bfVGX0dEV4S70/+iqE5li5fKcJpvo7uTwydFk26P4glw+wDOH7jNpcjx8Byqc3HmzUtfB L/jHYbAG+2i2njNRKSNxXVC8U2dGf0x6ib77BQAA//8DAFBLAwQUAAYACAAAACEAjuoq+r4AAAA4 AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7TehCRpr2I0IMX0Q9Ykm0bbJOQjaJ/b44W BI/DMG9m6vY1T+JJka13CqqiBEFOe2PdoOB2PW32IDihMzh5RwrexNA261V9oQlTDvFoA4tMcaxg TCkcpGQ90oxc+EAuO72PM6Ys4yAD6jsOJLdluZPxmwHNgik6oyB2pgJxfYfc/J/t+95qOnr9mMml HxWSJ2vojJwoZizGgZICE/nbWIiqyPtBNrVc/G0+AAAA//8DAFBLAwQUAAYACAAAACEAAavciugD AAA/JgAAIQAAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaS27bMBTcF+gdBG4D x5b8kWxYDpIUWWURNMkBaJmy1VCUQDFp3FWRHKE36L5ogRbooln1KPUBcoWSFGVLtuyqRoLYsHaK +RE5Q703w5fuwa2PtRtEIy8gNtD3a0BDxAkGHhna4PLipGIBLWKQDCAOCLLBGEXgoPf6VTfssNtz NsYo0vgUJOpAG4wYCzvVauSMkA+j/SBEhLe5AfUh43/SYXVA4Xs+tY+rRq3WqvrQI0CNp0XGB67r OehN4Fz7iLB4EoowZHz50cgLo2S2sMhsIUURn0aOziypJ7bnMYzkDntd2ME3WA/PqAbxkOPkMAo0 yrANBF7wlBzRK/nsBoQdyi59GCGgjSAZ8v2eXROHiQ5iqih0jpCrns4cpt1AOVG1163OtR66bEU/ 1TpA7lu+suiDDRqNmnpHgL3BiYexHC74QMeYxm9itwZQ70r3EiASjY1D5EKHM73nv6tgJnrCDoKp hseHL48P37XHh2+Tux+Tu5+T+/vJ3VegOSNIIyS3KQc50X8P4vuPdyOhUJiLBfBHY7fgP6QexEAL PeaMTqDv4bENKnqtvYjzi5EjGFHk1EtyNowcwYgip1GSs2HkCEYUOc2SnA0jRzCiyGkJcnxIT3lq bZpcsoA8ATCX9MXYLcnxRZPMQl4WwCiMzBlGbV0KkBIjKVgEMAoja4aRXjf1VnmQEoEnkFEgtVMg WYZllSAlIAlk+HPWk4SdfjAYLxiUOFrVG0Zb4OeRATc4XDkmP8T+hQvLp3UvPDTy163rYPrXx9w7 SANhgz8fP8emI+VrjGK+Rk9WsNrXkM3zNTFrJmetmWbNsJqm+GEbWPu0yJo4EzIbpvmQtwNpN/o8 rK0yThXdsNRRydrNeUcT06LrjbrYyuxrMgwrFcO36GvaKjbmLYxigyMvldg0tm0TG4tfiVQDW8XL vHuJeTFqTVOE6W38Sn7/Wghe+kumnLWCV75vMZp6Q8aqf38uhX3ME2b7HOTF7NuVNvLdkNE2dSli S+SLXB+vdebzPVYsdguFovLMr75jXiqV8o1b3bJaBZNzifyayE/dYMr/hZ2AjRCdukEua89iY61c FOaFKBsgUrk8nylf1SWpbcV5PG03+OAL2D8XlSV1/bVgG3WgycrRrAaWrXnpMpSrVYgaVRwTrxAV 9UZxVp5b++z5pIJgnOAzNSnR4EQzOHgVLXHcotYn1pXUnWJoEhCmdmxn8ck3Stn7P26LdhafJdYl e/e3ywDlewg9e++3ywAtUfPy4qEM0TwuLxHdZqMuBUgZo5doY46OtOklQEskbKtpZi/3djaLTZVm WlyKMoT6z6/eXwAAAP//AwBQSwECLQAUAAYACAAAACEAmxMFu/oAAAC7AQAAEwAAAAAAAAAAAAAA AAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCO6ir6vgAAADgBAAALAAAA AAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQABq9yK6AMAAD8mAAAhAAAA AAAAAAAAAAAAABICAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwUGAAAAAAMA AwDJAAAAOQYAAAAADwAMBDEdAAAPAALwKR0AAHACCPAIAAAABQAAAAWcAAAPAAPwzRwAAA8ABPAo AAAAAQAJ8BAAAAAgAAAAAAAAAGgz0mQAAAAAAgAK8AgAAAAAnAAABQAAAA8ABPAuAQAAEgAK8AgA AAACnAAAAAoAAIMAC/BIAAAAfwABAO8BgABoJG8gvwAAAAYAvwEBABEA/wEBABkAPwMAAAgAgMMY AAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAA AADDCwgAAAABAAAAAgD/vw8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0byBlZGl0 IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVs DUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAA AFMAAAABAAAAAAAPAATw1QgAABIACvAIAAAAA5wAAAAKAACDAAvwVgAAAH8AAQDvAYAA+CBvIL8A AAAGAL8BAQARAP8BEQAZAD8DAAAIAIDDJgAAAL8DAAACAEQAYQB0AGUAIABQAGwAYQBjAGUAaABv AGwAZABlAHIAIAA0AAAAEwAi8dcHAACpw9EHAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMA AABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NC e3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11E VkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt 7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SU nfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAh AKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevu TM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33 stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU 6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPq xRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhAKnZQz5uAwAA9QcAABAAAABkcnMvc2hhcGV4bWwueG1s rFXNbhMxEL4j8Q6W75CkTUuJ2KK2UEAKVUSKOM/uertLvOPF9qZJj+V5EEggcenb9AH6CszYm6b8 CAGlh2a8nvF8833j8aPHi1qLubKuMpjIwf2+FAozk1d4ksjXx4f3dqRwHjAHbVAlcqmcfLx7986j ZuQaQcHoRk0iS++bUa/nslLV4O6bRiHtFcbW4GlpT3qNVU6hB0+Jat3b6Pe3ezVUKHfpKJxPm4ll KzuaT6yo8kRuS4FQU8on4JWYaMhUaXSurBjKXucao4CgjE02cx0e+BM8uYVTKvI7KALNM0vVDDhB L4BZ4UKCxUmbUvhlQ6hyT8ScUSbQhSTAi0RudGHRl+LXZTkqT6SnL01OodB6Q2XDaFHY+raY+RxT FILyD7ceEK1SLIm8rc3hYKvPgGCkFl5kjG+wubnNDhl5DB9sb0SHXgTCno11/pkytwYl+KBEWpX5 UCjMx84zp+sUnE7j/6i+rjw1ha7qRO70+S9WXSrIn2IeGPBQ6WgTAo1BXJaEFfWLfZMvGU5KvyRT bOp/byK6TVR7aeyZFKcWqJ/cuxaskkK/QJfIh4PhkETwYRE0k8Le3Elv7mBbHxjNPSkAMzo1kdR5 0TzwtGI9Td2AH+O0ydhxpeTx4g3YptPCUxccmWkJjfqVJNE3KBRpCPo4P/VLrW5LSThrrgeBcRjl qng1sbEd9OozC9OlC/j/R06+dDXYcSCJjFfBoJTht8KcBlIwQZ/Q9NNSELRjSKd0r4NKxK310VvB GPftLAhRGPR7ISQFx7rSVMNum0JKwBMaLZMWMzo+6qFZHC7MNdkk82IOrOl1u4a2XHvsq+JH39DV 5Ebx6929wv/Gr9tN2wNtjxfhIqTt9OzaPKQyrhdHNN67u5LGy/q9UJ12CvMJWCD9xKytq9q8rSKp VHMiFd57PY1zcTDkSZNGpsP/NpFISfg9sdWM5iCaabCkmCnLr0+YXhnfmM6R+5lOQX5HdHWmnocl k64rfo3C3sQaU7DNVPDlhhGaw0rrrsPCF2d0lfPHwBc/U4pYiTL4RRz4RO5NL1UUNL9WXLRj7Lhq +ZjODsqHF6Gg9ymRe7YCaqOsBOtU6K3AqYIbPlcXH64uPouri0+X518uz79evn9/ef7x56DM/XUQ 9cdaoDhuw6xbzTh6k1yz+w0AAP//AwBQSwMEFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAABkcnMv ZG93bnJldi54bWxEj91Kw0AQhe8F32EZwTu7qT/Bxm5LEURBvGjtA4zZyQ9mZ9PdSZq8vYsXenk4 h+/wrbeT69RIIbaeDSwXGSji0tuWawPHz5ebR1BRkC12nsnATBG2m8uLNRbWn3lP40FqlSAcCzTQ iPSF1rFsyGFc+J44dZUPDiXFUGsb8JzgrtO3WZZrhy2nhwZ7em6o/D4MLp0s9TC+T7u70/3Dx3E+ rVa6DmLM9dW0ewIlNMn/ePB5hf6v/EW9WQM5qOp1/gqt3WMUCgaSWzJNlqA3PwAAAP//AwBQSwEC LQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQCp2UM+bgMAAPUHAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hh cGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAAAAAAAAAAAAAAAAxAUAAGRy cy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAADGBgAAAAAAABDwCAAAABQQIAFgBkARDwAR8BAA AAAAAMMLCAAAAAIAAAAHAf+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAACAACgAA AAD/BwABAAAAAAACAA4AAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAF DwAE8BgJAAASAArwCAAAAAScAAAACgAAgwAL8FoAAAB/AAEA7wGAALhKbyC/AAAABgC/AQEAEQD/ AREAGQA/AwAACACAwyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUA cgAgADUAAAATACLxEggAAKnDDAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250 ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBU xNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg5 3hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0h xtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdx EbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMA AACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5 +7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKX ZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28 zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA //8DAFBLAwQUAAYACAAAACEA/9Ge56gDAADsCQAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1uGzcQ vhfoOxC8J/qJZDtC1oFt1GkAxRAiBT0as7tc71ZccktyZclH53mKFmiBXvw2fgC/QmaGK8tui6KJ c+ihe9AOl0PON/PNj169XtdarJTzlTWJHDzvS6FMZvPKXCTyw+L02YEUPoDJQVujErlRXr4+/Pab V83ENwIPGz9pElmG0Ex6PZ+Vqgb/3DbK4F5hXQ0Bl+6i1zjllQkQ0FCte8N+f69XQ2XkIV5lVvNm 5kjKzlYzJ6o8kftSGKjR5Km1QTkx05Cp0uoc5bHsdcrxHCCYqc2WvkME/wZR7uAS3XwERhj7xqE/ AzLQYzhbZAaBkdGmFGHTIK4iOIzNVSJ/asEhQomw14l80R2N+njHzjmPTor08p3N8Ti0waLzMFkX rn4qbrrHFoUg+4PhCKMrxSaRe+MXo8G4T4hgotZBZKgwPHg53iOFDDVG+3vDqNCLSEizcT68UfbJ qARdlEinssCewmrqAwV2Z4LMafM13K8ryhJd1Yk86NMTvS4V5N+ZnCMQoNJRRgTaMMPECdEa1sc2 3xCcFN/IU8ztL88kLCr0vbTuSopLB5hUnhJFSaHfGp/Il4PRCEkIvBiN94e4cA930oc7pq1PrKbE FGAyvDWRYSueBFwRn7ZuIEzNvMlIccvkYv0DuKbjImAWnNl5CY36O0qiLjMUw8D8+DAPG62eGhK+ a6UHHHGY5Kp4P3MxHfT2MxHTmWP8X8MmVV0NbspBQuE9C2iS35XJsS+xCPoCm2BGdY3gFpDOsbqZ J+ImRH0FU3PslkxFYU044kMpeGIW25vptvFICeYCO8ysNRkaiIxooodc8002y4JYAbF6n7CcmDuN Y1X8WZfzGtXw/G73qAj/oNftpu2Jdos1l0Lazq/uxVN0435xhn2+q5Y0lutjqjr2sGhg4jCyy7au avtjFYOKHieyCs/eLmJvHIyo06QcrajSJtKgCRorrlpiIzR2zpIUS+VoCHH3yqhiOkXKZ7zF0DjR 1ZX6npcUcl3RUOK9mbO2YDmvXMDWhl99HU60Ary0z9lONQ8TY08rrbvE4y/e6iqnjxxEGmIKQxW5 Ces4DDDiD7VUUWBb2waonZougC1d08mcDjwtCpxdiTxyFWis0xKcV5xyHGgFD3Tubn6+u/lN3N38 env9++31H7cfP95e//LXQ5n/7EOYNEgYuRgORXzOxfm5oH6M6UPbTCr//LeZJYj/k7kj8xGFSGTD s2070/BPiG8OPwEAAP//AwBQSwMEFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAABkcnMvZG93bnJl di54bWxEj8tKA0EQRfeC/9CU4CaYnvjOmE4IgigEF4nBdTldmRmc7p50V+bx9xYudHm5l3M5i9Xg GtVRTHXwBmbTDBT5Itjalwb2Hy9Xj6ASo7fYBE8GRkqwWp6fLTC3ofdb6nZcKoH4lKOBirnNtU5F RQ7TNLTkpTuE6JAlxlLbiL3AXaOvs+xeO6y9PFTY0nNFxffu5ORkpk/dZljfHG/v3vfjcT7XZWRj Li+G9RMopoH/x/2Ew+fkr/xFvVkDD6AOr+NXrO0WE1M0IG5iKpaglz8AAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEA/9Ge56gDAADsCQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAAAAAAAAAAAAAAP4FAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAAQcAAAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAQAAAAAADD CwgAAAADAAAACQL/vw8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRGODcgaTJycyBXRwAA oQ8eAAAADwAAAAAAIAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADwAAAA1AHQAvADEAUP AATwYgkAABIACvAIAAAABZwAAAAKAACDAAvwZgAAAH8AAQDvAYAAWCFvIL8AAAAGAL8BAQARAP8B EQAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBl AGgAbwBsAGQAZQByACAANgAAABMAIvFACAAAqcM6CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIB AAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgk Y8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7P VptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1 wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxi wwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAI AAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBC V2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJw JYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cg H9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Y af7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQDNNvv11gMAAFALAAAQAAAAZHJzL3NoYXBleG1s LnhtbOxWzW7bRhC+F8g7LPau6MeSbAuhA1uy0gCqIUQqegyG5NJktdxld5ey5KIX53mKFmiBXvw2 fgC/Qmd2KctJi6CtfeghOlCz3Pn/5oevXm9KydbC2EKriHdfdjgTKtFpoS4j/u1y2jrizDpQKUit RMS3wvLXJy++elWNbMVQWNlRFfHcuWrUbtskFyXYl7oSCu8ybUpweDSX7coIK5QDh4ZK2e51OsN2 CYXiJ6hKrRfV3BCVXKznhhVpxNGwghJNLmSRCnZRl7EwbC4hEbmWKdJD3m5EgjSgSzOdrGzjF/wT v1IDVxjsRy4xpd8YjKpLBtreqZ1/Ct0jo1XO3LZC76xM0TVM0nXEf6jBOGE4+r+JeL+RDiKoZh+l xWhZfPWNTlED1E5jFmC0yUz5VNdJj84yhvaHg8EBppmzLdEH/e6gQx7BSGwcS5Ch1z04GBJDghz9 w2EvMLSDJ8RZGeveCP1krxgpirgRifORwnpmHeV2b4LMSfUc4ZcFYsBkUWINdegXos4FpOcq9Rlw UMhAowdSeZAJE0LWbc50uiV3YvxHnEKR//diwu7C2HNtrjm7MoB1ZalQBGfyrbIRP+72+wiC84f+ 4LCHB/P4Jn58o+pyrCXVJgOVoNaIux05dngiPHVZgZupRZUQ4w7J5eY7MFWDhcMquNCLHCrxd5AE Xo9QSIPHx7qF20rx1JR4XWvZ9RmHUSqyd3MTykHuXhMwjTnv/3PYpK4rwcx8kpB45wk06f8LleKA 8iTIS5yG2Mjo2hLiBfa2R4mQcYFbwEydmZUHItPKnXqRGCzhilNONdcokoO6xBEzr1WC6gMeksCh wGyVzBPH1kCYPpSrL8s9x5nIPuX1VY1sKL+/Pc3cZ/ia27geS7Pc+EaI68X1AznFMB4OFzjum16J Q7N+DFSDXSZTP61/HJxOJufT8aQ1OT86bo2n/UnreDwctI57R8OjyeHwcNqb/oRV3gxNHOlYyb7y DKKyqsui1N8XARDMV8QL13q7DHO126cpFQeU/LOOuEIHaTeZYoVDVOmFpzhbCUObzE++hLqtYaRe QC2KdpIsrsXX/kiAyYI2m7+bG60zoimNNBhgpPS0kLKpTv/GatxI9NLnmlaewIwGCN0mLA0E5jGX yDKcfbs81jPV5LkmNQ3tq8YnKMMdF/FTU4DEZs7BWOHr0uMh4BHP/e3P97e/sfvbX+9ufr+7+ePu w4e7m1/+KpTYfy2EtYXIUIhf2oay8Kxt407e0/LDbsUn9hAZECqdgwEchV/aAdPx/2uHPUDhy8V/ Nuw+F/D7zlYnfwIAAP//AwBQSwMEFAAGAAgAAAAhABP/D9jWAAAA+QAAAA8AAABkcnMvZG93bnJl di54bWxEj8tuwjAQRfeV+AdrkLorDvShkmIQQqpagVhAYT/EgxM1toNtQvL3HXXRLkd3dO49s0Vn a9FSiJV3CsajDAS5wuvKGQWHr/eHVxAxodNYe0cKeoqwmA/uZphrf3M7avfJCIa4mKOCMqUmlzIW JVmMI9+Q4+zsg8XEZzBSB7wx3NZykmUv0mLluKHEhlYlFd/7q+WSsby2m275eHl63h76y3QqTUhK 3Q+75RuIRF36fzbrY7ZZ/4W/qE+tgIefP/pTqPQOY6KggN3YlC1Bzn8AAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAzTb79dYDAABQCwAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAAAAAAAAAAAAAACwGAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAALwcAAAAAAAAQ8AgAAAAUECAQYBVAEQ8AEfAQAAAAAADD CwgAAAAEAAAACAL/vw8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAAAAAA IAgKAAAAAP8CAAcAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8M AAAA8AAAANQB0ALwAxAFDwAE8DwAAAASAArwCAAAAAGcAAAADAAAYwAL8CQAAACBAQAAAAiDAQUA AAi/ARAAEAD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZ AACZmQCZzAAADwCIE84AAAAPAIoTKQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAyAAAAixMJAAAA AAAkBAEAAAAKDwCKE5UAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTdQAAAAAA6y4IAAAA SsnHAeCMeL8AAB0QBAAAAAAAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAAAAAAA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAADgTG DgAAUEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rD MBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbn qdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7A co2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDc U/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48Xs TwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5y ZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov5 4ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5C ZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKh qC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhl bWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg 0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPV kIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQCM +tU5UQkAAHw5AAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxbWY+jSBJ+X2n+A+K9pzgMhlK7 R5yahx3NqKtH+7iibGwzjcEC+vr3E5GXSYMTuwptz6ptS104CSIjI+KLI5N++8vXQ6l9zpu2qKuV bv5s6FperetNUe1W+p8f0jeerrVdVm2ysq7ylf4tb/Vf3v30r7fZY7fPD7kGz1ftY7bS9113fHx4 aNcwnLU/18e8gnvbujlkHfxsdg+bJvsCfA/lg2UY7sMhKypdq7IDsPX/W+Td9o3r6+8456QE9lXX 4sC6bJ6Qb87IGbFmEvLNRxOJ2mb3HJWN9jkrV7pBPvrDu7cP2SMjKLshXUo+jI4RbD5aU/wIQdkN 6TwDv4IfIcjWa1jIcO4wTIzEZrQ9Ino55G3Dx/cl+h5/eyCztDbKlBDRy8WAXtJZj4heOgP6OEji JJXkIUSU3h3QW7EVe4FET4j2ZVF9HFAbhg8fRi1ItnX56yi570eRwRV/ogLrC+fBKbZ11Y25ko43 D9lfdZMCBf4os66otO7bMd9ma3DRoCmyEsXJHvOsN06H1u3ZEEwssTsU1ay8T+xgptOqyBoP8hJ/ 326LdU5WuC3K8qn7Vub/bski27osNikM4nMEurmA0HEPl0z/Et2uycgzWlN3/ym6/dM+O4KCKBh3 LWO9a7Vj3QISycSjvHFSUHJHIeug/1Fttln3W72hw3YfyYINwfWOBAc+kY0Mrp3MXr5uMpNKdVFt 8tJMIhrxHWlpYslgw+HSYFBoE3xeyzAmmy4ET5Rda9dZmW9Q7zTKcbPg1Px6ZhOxVdOF7LNNTk0k DfdMZxLbcRciARxcasR0t2lTaA2UNi0EcQseGF6sZM6AK5Ys4hxNZdXHVllpXyCzOZaja+vsuNK3 EFLg8nAEo7XVTteycgdJd9011GsnsUi87bRif9yrTIOPD7xKgvGxabs4a/fUhuQWM1VZ4UxUfstZ oLPNswDqqC+QwvbARb6bFKBH2bT5dpuvu76xeyOoO/qTRcL6U5c3T/vNF+25/NS8z8D8oFNcz6Zo u5VOAI0/mpWO2ia35NjK4tpIhYOzZeVxn7Fo6eHTTM+UnLiqkIH86okHaxuVnSzu9qUg4udaSt+N f7ClYDrIq9zeoAXWUCI3mYZ4Xel10+1riELHfbFOG6hVSOwAb9EgumC21aBQJ3+b/DP+pb5AeSC3 stjtu/fFTmsKSCfdvsnzPyAsEe+bYGay1ENZckbEo3ritkcq9nP+OS8/YAx0MQbr2h5cnUQT5p6E 7tz/5N8MQc87rFH6eJNiiIjqFAP/68KFghkWBVbrZb+JxIPJnVZI9HnyOM+R/YXgjVOVtOCokJKf 7zPYv1CEaxJwL9fSiDVYseVw4cCKwijEP7BUg0FRzxyzbq/hP5D/imZdnsrTD/V7iK0a9HDIDNwG vPoNRjW4xABJr56h7qGD1JmQFZ2BFaeoNZ6sZ66CxLxnykbJON6Gqz/Z+0ZliyJKnk7C4nC6lyub aVjSNR27qGqY7ByiMLTlfQgxDNku6Df19fNfYOgY2qtPJW3z2yP8Ijg4/tEQ73quN9/YZdnShEu9 DnsYpCyr9/lWKzZfef8hNEEhRHtRXiITanwMKzfxoD3WNMgPMnp8lGZL8bA1/bB4gswMIVs8TJrC MQawE8ECN7Z2QE9U2NJVg2qFpsrqNSq7QvhxlY32WdeqjDaKSkO9QGXdV7XKmKZAeUPHy792TQat yROJvyzpyINouzWnuG9D8Y0ZanMLtUMv79tQkUgCl7ehwJN+y47a885c6Yh1Dbx3pcM+pQ5jFo5Z OAZXsBkJjSLdQVzpHGJsBO4zA3Aam4/YfGTBRxZ8xOEj0JjSx10+4kKVhttrsJ2Lf3SNLwG6V7bz xuLSEB3DkUt4oWHnn7Rt67v4ZUtj+7pM1+ja0tZyGsapc8O2bZr6vst5M3N9T7ykcRKFsvzKbdtk 6QVOxHTD/AXlF3uyknaiyIaChVELEu48A2WiagT5iQqitHAefObHxgstUP5JeLnlmAN35lP5mICc hfSgcOZBA/rvml+iILHO5FfiJfRDP1leixc81Ik4uqbxEqTuUghzx8v4seCClNSvwQuca7kprydn OBa8Kb/0jyR7SegSXrw4coVL9Ijo5bAeS6I0SGX/JESU/vXHgiPHjkq8LNPQvh4vcHLs3oAXwwig XWdgvONlHC/Oq/GCNo95TzADXpbkw8w2VY/h5LI/K/MLxlvhQVfgBdknfG09UM2Kl0DKF0q8WDFm GIlecYyepg6cBzHq6fyCxeodL/CmCas66Y7AWb/vKvDiBI7HtM0SEIODVOOgT4mYrcRL73US9l7K 2GsnyE28LDGBF4igC9eS/EeJFzd200jGl7IeC4LIiLjHXYGXOMCvJA9JQvRRAgVJd0EQeqEsjxIv ruUuwoXEX4EXw+hZZhovSH4jXkhHT/p9MDzr98FVWL8PxuNdOewIUB3APXrxf9rvLy/ixYnMk/pm wAvZmue+p8BLnMaWz3vgCbxIHS0zCEYHZpJBSxsmS9/lMvSI6OWwHouMAD6SfyrrsVvxklgAL5m/ Ei9B5MaOvF+hwIsUeabxEtuBZfLkdV099uPhxbuIF8OwbbGXNANe8MRK5A0FXrAj7+WrXvwfvtaI Ep7VV8r8Yhjh6dzsCrwgWiLZn2fFSxCHXiLnRyVeQIOnGEblV+AFdSM0OY0XKD2XhsmCwx0v4/0L fWuYwUGqFdAXe/5N/PB19RgihplDgZfETsLe/oESL4hpISP1HyVeFq4XLEIpX/T4D/ML4uUs/s+L lyCIz/CoxIudLuMFz72z48VI4Kz6jpdc1b+Y9Ph2DDBS4z1DgnE9N3TiacDEZmxG3KknCjLf8A1P DtBKwHiGnwS8KbsiwUB7HYRyATQrYCIXvjymU3mUgFnaXurL8isSTJpGkSgRphNM4seR2E24J5jx BGNe/o8mNoR6cTo2B2BcKWORyM7wIGU2rMdEHTEBGNdw/CUH1xUZBkRwBe9rAOOF3lkGmBUwIcSQ UD5BUgLGiZzo+h1l6XxqGjCodpGu74C5AJjLR/zwv4AM0xEZ4dUlmWPZicWjtaIki9PI8HgmmgCM Fy3DJa8irgCMlzqpJTuosiQL7SAN+KEf5T8rYCKASygDXgkYz3QcS26pFBkmikJ4ZZVZcBowXgTp l5P/SICBlxjkd2LIi2UwSl6FfPc3AAAA//8DAFBLAwQUAAYACAAAACEADdGQn7YAAAAbAQAAJwAA AHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQ kSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZ O2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUk vWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0A FAAGAAgAAAAhAJvocE/8AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54 bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAtAQAAX3JlbHMvLnJl bHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAWAgAAdGhlbWUvdGhl bWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQCM+tU5UQkAAHw5AAAWAAAAAAAAAAAA AAAAANMCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEA ACcAAAAAAAAAAAAAAAAAWAwAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVs c1BLBQYAAAAABQAFAF0BAABTDQAAAAAAAA8EOgEAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04IiBzdGFuZGFsb25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEi IHR4MT0iZGsxIiBiZzI9Imx0MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9 ImFjY2VudDIiIGFjY2VudDM9ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFj Y2VudDUiIGFjY2VudDY9ImFjY2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5r Ii8+AAANKwQAAADMXrtTAAALKxMEAABQSwMEFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAABbQ29u dGVudF9UeXBlc10ueG1sfJDNasMwEITvhb6D0LVYcnsopcTOoT/QS9tD+gCLtLZF9YdWCcnbd+2k FErIadGuZuZjVut98GKHhVyKnbxVrRQYTbIujp382rw2D1JQhWjBp4idPCDJdX99tdocMpJgdaRO TrXmR63JTBiAVMoY+TKkEqDys4w6g/mGEfVd295rk2LFWJs6e8h+9YwDbH0VL3teH0lYLsXT8d8c 1UnI2TsDlUH1fNVndQU9XRDuov1H15zIFCsXc5pcpptTwgdXU5xF8QmlvkNgDm0L6eoCN/QWh6Qu k54JTMPgDNpktoFLULkg8Vyyg1d/zr8Meqm6/wEAAP//AwBQSwMEFAAGAAgAAAAhABdLaHu6AAAA KAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZuUz2ISFMvIvQq9QNCsm2DzSZko+jfm2MF wePsMG92mtPLz+KJiV0gBduqBoFkgnU0Krj1l80BBGdNVs+BUMEbGU7tetVccda5hHhykUWhECuY co5HKdlM6DVXISIVZwjJ61xkGmXU5q5HlLu63su0ZED7xRSdVZA6uwXRv2Np/s8Ow+AMnoN5eKT8 o0Jm58uwjoZQqDqNmBXYxIt7Vf4F2Tbya1/7AQAA//8DAFBLAwQUAAYACAAAACEAJUZEQQcBAADK AQAAEgAAAGRycy90aW1pbmdJbmZvLnhtbIyRQUvEMBCF74L/IeRu04qIlLZ7WTx5kvoDQjLdDTQz IZl13X/vtFsF8bKnmZC8x/deut1XnNUn5BIIe91UtVaAjnzAQ68/xteHF60KW/R2JoReX6Do3XB/ 16WWQ5RXSgywtLbXR+bUGlPcEaItFSVAuZsoR8tyzAfjsz2LJM7msa6fTbQB9abPt+hpmoKDPblT BOSrSYbZssCXY0jlxy3d4pYyFLFZ1X+QhiUcvhVelmTzMtyIKnhpSCt/EtiAHqaAgUEr8WGbudcI 0qRWSB7GS5K2OL4T8S9V8/SPKwaXqdDElaNorgFNojPkRGHN2NTXoszQmQ1H5sa3bOs3DN8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhADIZJM74AAAAqwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAAAAAAAAAAAAAAApAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAJUZEQQcBAADKAQAAEgAAAAAAAAAAAAAAAAAMAgAA ZHJzL3RpbWluZ0luZm8ueG1sUEsFBgAAAAADAAMAugAAAEMDAAAAAJAAHgTCCAAAUEsDBBQABgAI AAAAIQBHcju1+wAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy07DMBBF90j8g+Utip2y QAgl6YLHCgGL8gGWPUks/JLHqZq/Z5IWCVDV1Wged+7RbbYH79geMtoYWr4RNWcQdDQ2DC3/3L1U 95xhUcEoFwO0fAbk2+76qtnNCZCROmDLx1LSg5SoR/AKRUwQaNPH7FWhNg8yKf2lBpC3dX0ndQwF QqnK8oN3zRP0anKFPR9ofCQhOWePx7vFquUqJWe1KgQql608q8vg8IJwH8w/uupEJki5PsfRJrw5 ObxTNNkaYB8qlzfliUOajBIdDV/VHKfyp9mIy+Bn/GPfWw0m6slTJiJlQKorinfil9EPk1yj774B AAD//wMAUEsDBBQABgAIAAAAIQBw8DjcvgAAADgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C /xD2btN6EJGmvYggeBL9gCXZtsE2Cdko9u/N0YLgcRjmzUzdvqdRvCiy9U5BVZQgyGlvrOsV3G+n zR4EJ3QGR+9IwUwMbbNe1VcaMeUQDzawyBTHCoaUwkFK1gNNyIUP5LLT+ThhyjL2MqB+YE9yW5Y7 Gb8Z0CyY4mwUxLOpQNzmkJv/s33XWU1Hr58TufSjQvJoDV1w9s+UsRh7SgpM5G9jIaoi7wfZ1HLx t/kAAAD//wMAUEsDBBQABgAIAAAAIQDcwZGgkQUAACQRAAAhAAAAZHJzL3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDEueG1srFjNbtw2EL4X6DsQuhbJWvvvRdZB4jZpgY2zyG7QM1eiLNUUpZLUeu1j 8jxFC7RAL3kbP0BeoTNDaiW5brDd+LKmyOEnzvCb+UZ+9nyXS7YV2mSFmgfh05OACRUVcaYu58H7 9asn04AZy1XMZaHEPLgRJnh+9u03z8qZkfGC3xSVZYChzIzPg9TactbrmSgVOTdPi1IoWEsKnXML j/qyF2t+Ddi57PVPTsa9nGcq8Pv1IfuLJMki8X0RVblQ1oFoIbmF85s0K02NVh6CVmphAIZ2d49k b0rwtsyi9S5gZKa3MBEGZ+B5tJIxUzyHiWUW2UoLdp3ZlJ3zEs9BNqZcayHQWm1f63JVLjVtvdgu NctihPIQQc8veDN6VGAGg9697Zc1Ep/tEp2fPeMziAjbzQO4uBv8hU18JnaWRW4yamaj9O0DtlH6 wwPWvfoFcIL9S+HOS+fRv93p1+6sMysFC/deOVMOWxdFdGWYKsBPdN+5F11sazD0GeHLlLnwW4Ty dm6R4lHbG4ppfdB9JMLJab8/Bd6C58MpsOzkXlRGw+l4CJMMYzMajyeDKb2kQSq1sa9FkcPNGzsP tIgsXCqf8e3CWDw3n9UmdEfuJOXM7l4W8Q1abuAvXDRkFuxPC30bMK4iGMyDDb6Mz6SxK3sjgSIw 3soQnGFcXkIWSnpXLJJ3MGVu5wGkCpx2Uwdtb08HaePA7fAZxBB+YKvkmMRCPXm/giTO7bkUHOB9 NOzZucyiK2YLJuLMsjfcWKEZxRxSHk6Gblp6B0EKFS+55nioNrIPB8Wh9h+uyTHlv/kyqPlSZ9BS 8kikhYzhEH0MEeRZzY2j2APJG0CmQRrUXDuOQ+OwP5mM3KXVidWh0DAMkWcdDlEEHJ3roDxIimvN IRnMrxXXImDyJ2XmwWk4HMJ9W3oYjiZ9eNDtlU17RVX5eSGpntQMszXZzi3wDYle5CW3C7UqIzRE giB/17ufuS49yS34dlGsUl4KMrjHdWdLbHDcJt4+wOGc6wW9NFMx1FYcoummugABIea3mD0Aavu4 +Rwg2K3sYzo4KIoAOHEIXr+5B8BDEI83aPAovIfiYZ1wDAc8BPF4wwYvHExCrDGHHRBTeQ+IKB5w 1AKcQvk6DhBRPOC4AYRyCAc86oSI4gEnLcDJkG7uCJcRxQNOG0BEo5J80CV3YogoHvC0BTgeTY68 FER5uLI28BBLIOc74jkQ4x7f93WcAdXXfLOCGl6zTltnLfhCvdRXtDMplH1BpX/DDZYBaEhUs5xC HYeeaVmpaJ9OEnMZ3TZltIws23IsARCYhl4ti5ciuW+LmlIzETAaixcJ1PwubsvOr26qc6nXO0rn TbW63Q9fgSv7h33GW75xwslnLvldBvibawnLVZVnefFL5gLb0S+IoeMc6CBSmX6reaCgrGCPqrMr 6MdUsaJRwK6EJrFjEVZYb4X1DzYr7Ehldit+pEeMusywvaW1pS6KhMZt0SSOKfxVxatMSp/ENGMK mcU4SZHD7ldAfNyl2J2THwhp20okCXQVdVSqhfJRqxDGj4kH1AsloI3z4LtcPZEWywe0eLy18PnT b58//ck+f/rj7sNfdx/+vvv48e7D71D3U66NINLQpsj8703QAzT3Q2kBTQaoW61qB0j9sJb6Ncpn W+cH6MvX6jzKERAA+JFymXjJpw4Cznac5I8G0BS6rrBppjuaPz2BJtK9pG4bvyD5FPx2o+bFzisc 0vkAsQw7YoQNI3HyaLEMO+L79WKJ5afRtkcQy9M23iNoZQfvEaSyg/cIStnBewSh7OA9gk528L4s k14UifhE0+M/SLBo0PeI6XyQ4DfYQ5WI0tB9e8MQP9WpxEj9hpdvt3QW+N8EfOpAhYapEpQVTomm jQli1P/dOPsHAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAA AAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA3MGRoJEFAAAkEQAAIQAAAAAA AAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMA yQAAAOMHAAAAAAAAHQQEAAAAAQAAACAAug8SAAAAOQBfAGkAZQB0AGYALQA2ADkADwD4A1lEAAAC AO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAgD/v2AA8AcgAAAA////AAAAAACAgIAAAAAAALvg 4wAzM5kAAJmZAJnMAABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD731MA/5lmAMwzAACZZgAAYADw ByAAAAD///8AAAAAAICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA8AcgAAAA3vbxAAAAAACWlpYA AAAAAP///wCNxv8AAGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3AAAAAAD///cAM8zMAP9QUAD/ mQAAYADwByAAAAAAgIAA////AABaWAD//5kAAGRiAG1vxwAA//8AAP8AAGAA8AcgAAAAgAAAAP// /wBcHwAA39KTAMwzAAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD///8AADNmAMz//wAzZswAALAA AGbM/wD/5wEAYADwByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAA aGtdAP///wB3d3cA0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAAAGZmmQD///8APj5cAP///wBg WXsAZmb/AJnM/wD//5kAYADwByAAAABSPiYA////AC0gFQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAA ow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAA AP//LAAAAAADAAAQAKMPgAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAIA AAD//+8AAAAAAAEAAAD//xgAAAAAAQAAgAUAABMg1AEgAQAAIgD//xQAgAUAACIg0AJAAgAAAgAS AIAFAAATIPADYAMAAAIAEACABQAAuwAQBYAEAAACAA4AIACjD3AAAAAFAP/9PwAAACIgAABkAAAA AAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASABAAAg AP//AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIg AABkAAAAAAAAAGQAAAAAAAAAAAAgAQAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAg ASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJ AAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMA AAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAA AgAUAAEAAAAAAAAAAgASAAIAAAAAAAAAAgAQAAMAAAAAAAAAAgAOAAQAAAAAAAAAAgAMAIAAow8+ AAAABQAAAAAAAAAAAAIAEgABAAAAAAAAAAIAEAACAAAAAAAAAAIADgADAAAAAAAAAAIADAAEAAAA AAAAAAIACgAAACMEGAcAAFBLAwQUAAYACAAAACEAmxMFu/oAAAC7AQAAEwAAAFtDb250ZW50X1R5 cGVzXS54bWx8kMtqwzAQRfeF/oPQtlhyuiil2M6ij10fi/QDBnlsi+qFRgnJ33fspBBKyGqYx517 uM16753YYSYbQytXqpYCg4m9DWMrvzdv1aMUVCD04GLAVh6Q5Lq7vWk2h4QkWB2olVMp6UlrMhN6 IBUTBt4MMXso3OZRJzA/MKK+r+sHbWIoGEpV5h+ya15wgK0r4nXP4yMJy6V4Pt7NVq2ElJw1UBhU z1t9UZfR0RXhLvT/6KoTmWLl8pwmm+ju5PDJ0WTbo/iCXD7AM4fuM2lyPHwHKpzcebNS18Ev+Mdh sAb7aLaeM1EpI3FdULxTZ0Z/THqJvvsFAAD//wMAUEsDBBQABgAIAAAAIQCO6ir6vgAAADgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2btN6EJGmvYjQgxfRD1iSbRtsk5CNon9vjhYEj8Mw b2bq9jVP4kmRrXcKqqIEQU57Y92g4HY9bfYgOKEzOHlHCt7E0DbrVX2hCVMO8WgDi0xxrGBMKRyk ZD3SjFz4QC47vY8zpizjIAPqOw4kt2W5k/GbAc2CKTqjIHamAnF9h9z8n+373mo6ev2YyaUfFZIn a+iMnChmLMaBkgIT+dtYiKrI+0E2tVz8bT4AAAD//wMAUEsDBBQABgAIAAAAIQABq9yK6AMAAD8m AAAhAAAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1s7FpLbtswFNwX6B0EbgPHlvyR bFgOkhRZZRE0yQFombLVUJRAMWncVZEcoTfovmiBFuiiWfUo9QFyhZIUZUu27KpGgtiwdor5ETlD vTfDl+7BrY+1G0QjLyA20PdrQEPECQYeGdrg8uKkYgEtYpAMIA4IssEYReCg9/pVN+yw23M2xijS +BQk6kAbjBgLO9Vq5IyQD6P9IESEt7kB9SHjf9JhdUDhez61j6tGrdaq+tAjQI2nRcYHrus56E3g XPuIsHgSijBkfPnRyAujZLawyGwhRRGfRo7OLKkntucxjOQOe13YwTdYD8+oBvGQ4+QwCjTKsA0E XvCUHNEr+ewGhB3KLn0YIaCNIBny/Z5dE4eJDmKqKHSOkKuezhym3UA5UbXXrc61HrpsRT/VOkDu W76y6IMNGo2aekeAvcGJh7EcLvhAx5jGb2K3BlDvSvcSIBKNjUPkQoczvee/q2AmesIOgqmGx4cv jw/ftceHb5O7H5O7n5P7+8ndV6A5I0gjJLcpBznRfw/i+493I6FQmIsF8Edjt+A/pB7EQAs95oxO oO/hsQ0qeq29iPOLkSMYUeTUS3I2jBzBiCKnUZKzYeQIRhQ5zZKcDSNHMKLIaQlyfEhPeWptmlyy gDwBMJf0xdgtyfFFk8xCXhbAKIzMGUZtXQqQEiMpWAQwCiNrhpFeN/VWeZASgSeQUSC1UyBZhmWV ICUgCWT4c9aThJ1+MBgvGJQ4WtUbRlvg55EBNzhcOSY/xP6FC8undS88NPLXretg+tfH3DtIA2GD Px8/x6Yj5WuMYr5GT1aw2teQzfM1MWsmZ62ZZs2wmqb4YRtY+7TImjgTMhum+ZC3A2k3+jysrTJO Fd2w1FHJ2s15RxPTouuNutjK7GsyDCsVw7foa9oqNuYtjGKDIy+V2DS2bRMbi1+JVANbxcu8e4l5 MWpNU4TpbfxKfv9aCF76S6actYJXvm8xmnpDxqp/fy6FfcwTZvsc5MXs25U28t2Q0TZ1KWJL5Itc H6915vM9Vix2C4Wi8syvvmNeKpXyjVvdsloFk3OJ/JrIT91gyv+FnYCNEJ26QS5rz2JjrVwU5oUo GyBSuTyfKV/VJaltxXk8bTf44AvYPxeVJXX9tWAbdaDJytGsBpateekylKtViBpVHBOvEBX1RnFW nlv77PmkgmCc4DM1KdHgRDM4eBUtcdyi1ifWldSdYmgSEKZ2bGfxyTdK2fs/bot2Fp8l1iV797fL AOV7CD1777fLAC1R8/LioQzRPC4vEd1moy4FSBmjl2hjjo606SVASyRsq2lmL/d2NotNlWZaXIoy hPrPr95fAAAA//8DAFBLAQItABQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAAAAAAAAAAAAAAAAA AABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAAAAAAAA AAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAAAAAAAA AAAAAAAAEgIAAGRycy9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLBQYAAAAAAwADAMkA AAA5BgAAAAAPAAwEMR0AAA8AAvApHQAAgAII8AgAAAAFAAAABaAAAA8AA/DNHAAADwAE8CgAAAAB AAnwEAAAADEAAAAAAAIAelNtTbABAAACAArwCAAAAACgAAAFAAAADwAE8C4BAAASAArwCAAAAAKg AAAACgAAgwAL8EgAAAB/AAEA7wGAAAitpR+/AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/ AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMML CAAAAAEAAAACAP+/DwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlm dGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAA AAEAAAAAAA8ABPDWCAAAEgAK8AgAAAADoAAAAAoAAIMAC/BWAAAAfwABAO8BgADo8IQlvwAAAAYA vwEBABEA/wERABkAPwMAAAgAgMMmAAAAvwMAAAIARABhAHQAZQAgAFAAbABhAGMAZQBoAG8AbABk AGUAcgAgADMAAAATACLx2AcAAKnD0gcAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtD b250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt 2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPX esg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntL Va0hxtFbyCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTn UjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotd DdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5Mzpax zDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1p wlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5 jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sb AAAA//8DAFBLAwQUAAYACAAAACEAqgWheW8DAAD1BwAAEAAAAGRycy9zaGFwZXhtbC54bWysVc1u EzEQviPxDpbvkKRNS4nYorZQQApVRIo4z+56u0u89mJ706TH8jwIJJC49G36AH0FZsabpvwIAaWH Zrye8XzzfePxo8eLWou5cr6yJpGD+30plMlsXpmTRL4+Pry3I4UPYHLQ1qhELpWXj3fv3nnUjHwj MNj4UZPIMoRm1Ov5rFQ1+Pu2UQb3CutqCLh0J73GKa9MgICJat3b6Pe3ezVURu7iUWY+bSaOrOxo PnGiyhO5LYWBGlM+gaDEREOmSqtz5cSm7HWuMQoQythmM9/hgT/Bkzs4xSK/gyKMfeawmgEl6DGY FS6DsChpU4qwbBBVHpCYM8wEupAIeJHIjS4s+mL8uiyP5Yn09KXNMRTaYLFsGC0KV98WM51ji0Jg /uHWA6RViiWSt7U5HGz1CRCM1CKIjPANNje3ySFDj+GD7Y3o0ItAyLNxPjxT9tagBB2USKeywIXC fOwDcbpOQem0+R/V11XAptBVncidPv3FqksF+VOTMwMBKh1tRKANi0uSkKJhsW/zJcFJ8Rdlik39 702EtwlrL607k+LUAfaTf9eCU1LoF8Yn8uFgOEQRAi9YMynczZ305o5p6wOrqScFmAxPTSR2XjQP Aq5IT1s3EMZm2mTkuFLyePEGXNNpEbALjuy0hEb9SpLoywpFGlgfH6ZhqdVtKeGz5nrAjMMoV8Wr iYvtoFefSZguHeP/Hznp0tXgxkwSGq/YwJT8W5kcBxKboE9w+mkpENoxpFO816wScutC9FYwNvtu xkIU1oQ9DknBk6441Uy3jSElmBMcLZPWZHh81EOTOFSYb7JJFsQcSNPrduW2XHvsq+JHX+5qdMP4 9e5eEX7j1+2m7YF2xwu+CGk7Pbs2D7GM68URjvfurqTxsn4vVKedMvkEHKB+YtbWVW3fVpFUrDmR ytx7PY1zcTCkSZNGpvl/m0iDSeg9cdUM56CxU7akmClHrw9Pr4xuTOdI/YynGHpHdHWmnvOSSNcV vUa8N3HWFmQTFXS5YWTsYaV112H8xVtd5fSR+aJnSiErUYawiAMfyb3ppYoC59eKi3ZsOq5aOqaz WXl+EQp8nxK55yrANspKcF5xbzGnCm74XF18uLr4LK4uPl2ef7k8/3r5/v3l+cefgzL/10HYH2uB 4rjlWbeacfgm+Wb3GwAAAP//AwBQSwMEFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAABkcnMvZG93 bnJldi54bWxEj91Kw0AQhe8F32EZwTu7qT/Bxm5LEURBvGjtA4zZyQ9mZ9PdSZq8vYsXenk4h+/w rbeT69RIIbaeDSwXGSji0tuWawPHz5ebR1BRkC12nsnATBG2m8uLNRbWn3lP40FqlSAcCzTQiPSF 1rFsyGFc+J44dZUPDiXFUGsb8JzgrtO3WZZrhy2nhwZ7em6o/D4MLp0s9TC+T7u70/3Dx3E+rVa6 DmLM9dW0ewIlNMn/ePB5hf6v/EW9WQM5qOp1/gqt3WMUCgaSWzJNlqA3PwAAAP//AwBQSwECLQAU AAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCqBaF5bwMAAPUHAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4 bWwueG1sUEsBAi0AFAAGAAgAAAAhALS+lQDVAAAA+QAAAA8AAAAAAAAAAAAAAAAAxQUAAGRycy9k b3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAADHBgAAAAAAABDwCAAAABQQIAFgBkARDwAR8BAAAAAA AMMLCAAAAAIAAAAHAf+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAAACAACgAAAAD/ BwABAAAAAAACAA4AAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE 8BgJAAASAArwCAAAAASgAAAACgAAgwAL8FoAAAB/AAEA7wGAAIgBhSW/AAAABgC/AQEAEQD/AREA GQA/AwAACACAwyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAg ADQAAAATACLxEggAAKnDDAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50 X1R5cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKe ef8/2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrD dsAJuAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFb yCJqlqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrO WyzbxK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACP AQAACwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iU Qi9ky6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJ VKVEMTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzc l8Zy0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8D AFBLAwQUAAYACAAAACEAousMaqgDAADsCQAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1uGzcQvhfo OxC8J/qJ/BMh68A26jSAYgiRih6N2V2uxYpLbkmuLPnoPE/RAi3Qi9/GD+BX6MxwZdltUbR1Dj10 D9rhcsj5Zr750Zu369qIlfJBO5vJwcu+FMoWrtT2MpPfzM9eHEoRItgSjLMqkxsV5NujL79404xD I/CwDeMmk4sYm3GvF4qFqiG8dI2yuFc5X0PEpb/sNV4FZSNENFSb3rDf3+/VoK08wqvsatZMPUnF +WrqhS4zeSCFhRpNnjkXlRdTA4VaOFOiPJK9TjmdAwQzccUydIjg7yAqPVyhm0/ACOveefRnQAZ6 DGeLzCIwMtosRNw0iKuKHmNzncnvW/CIUCLsdSZfdUeTPt6xcy6gkyK/+uBKPA5tdOg8jNeVr5+L m+5xVSXI/mA4wuhKscnk/t6r0WCvT4hgrNZRFKgwPHy9t08KBWqMDvaHSaGXkJBm40N8p9yzUQm6 KJNeFZE9hdUkRArszgSZM/ZzuF9ryhKj60we9ulJXi8UlF/ZkiMQQZskIwJjmWHihGiN6xNXbghO jm/kKeX2v88kLCr0feH8tRRXHjCpAiWKksK8tyGTrwejEZIQeTHaOxjiwj/eyR/v2LY+dYYSU4At 8NZMxq14GnFFfLq6gTixs6YgxS2T8/W34JuOi4hZcO5mC2jUn1GSdJmhFAbmJ8RZ3Bj13JDwXSsz 4IjDuFTVx6lP6WC2n4mYzhzj/xw2qepq8BMOEgofWUCT/Na2xL7EIphLbIIF1TWCm0M+w+pmnoib mPQVTOyJXzIVlbPxmA/lEIhZbG+228YjC7CX2GGmrS3QQGLEED3kWmiKaRHFCojVh4TlxNxpnKjq 97qc16iG53e7x1X8C71uN29PjZ+vuRTydnb9IJ6hGw+Lc+zzXbXkqVyfUtWxh0UDY4+RXba1rt13 OgUVPc6kji/ez1NvHIyo0+QcraTSZtKiCRorXi+xEVo3Y0mKpfI0hLh7FVQxnSLlM95iaZwYfa2+ 5iWF3GgaSrw39c5VLJfaR2xt+DXU8dQowEv7nO1U8zC27kwb0yUefwnO6JI+chBpiCkMVeImrtMw wIg/1lJVhW1tG6B2YrsAtnRNJ3M68LSocHZl8thrMFinC/BBccpxoBU80rm//eH+9mdxf/vT3c0v dze/3n36dHfz4x8PFeEfH8KkQcLIxXgk0nMhLi4E9WNMH9pmUvnnv80sQfyfzB2ZTyhEIhuebduZ hn9CQnP0GwAAAP//AwBQSwMEFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAABkcnMvZG93bnJldi54 bWxEj8tKA0EQRfeC/9CU4CaYnvjOmE4IgigEF4nBdTldmRmc7p50V+bx9xYudHm5l3M5i9XgGtVR THXwBmbTDBT5Itjalwb2Hy9Xj6ASo7fYBE8GRkqwWp6fLTC3ofdb6nZcKoH4lKOBirnNtU5FRQ7T NLTkpTuE6JAlxlLbiL3AXaOvs+xeO6y9PFTY0nNFxffu5ORkpk/dZljfHG/v3vfjcT7XZWRjLi+G 9RMopoH/x/2Ew+fkr/xFvVkDD6AOr+NXrO0WE1M0IG5iKpaglz8AAAD//wMAUEsBAi0AFAAGAAgA AAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEAousMaqgDAADsCQAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnht bFBLAQItABQABgAIAAAAIQD9AqKn1gAAAPkAAAAPAAAAAAAAAAAAAAAAAP4FAABkcnMvZG93bnJl di54bWxQSwUGAAAAAAQABAD1AAAAAQcAAAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAQAAAAAADDCwgA AAADAAAACQL/vw8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRGODcgaTJycyBXRwAAoQ8e AAAADwAAAAAAIAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADwAAAA1AHQAvADEAUPAATw YQkAABIACvAIAAAABaAAAAAKAACDAAvwZgAAAH8AAQDvAYAAqNyEJb8AAAAGAL8BAQARAP8BEQAZ AD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABsAGEAYwBlAGgA bwBsAGQAZQByACAANQAAABMAIvE/CAAAqcM5CAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tj Qnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptd RFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURw re4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNE lJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAA IQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr 7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF9 97LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa 1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z 6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQALV0jd1QMAAFALAAAQAAAAZHJzL3NoYXBleG1sLnht bOxWzW7jNhC+F+g7ELx7/Sc7G2OVhe0k2wXcwFi76LEYSVSsmiJVknLsFL1kn6fYBVqgl7xNHiCv 0BlSjrNtUbRNDj2sD/JQnP9vfvTq9baUbCOMLbSKefdFhzOhUp0V6jLm3yzPWy85sw5UBlIrEfOd sPz1yZdfvKpGtmIorOyoivnKuWrUbtt0JUqwL3QlFN7l2pTg8Ggu25URVigHDg2Vst3rdIbtEgrF T1CV2iyquSEqvdjMDSuymKNhBSWaXMgiE+yiLhNh2FxCKlZaZkgPeLsRCdKALs10uraNX/BP/MoM XGGwn7jElH5jMKouGWh7p/b+KXSPjFYr5nYVemdlhq5hkq5j/kMNxgnD0f9tzKNGOoigmkOUFqNl ydXXOkMNUDuNWYDRNjflU10nPTrPGdofDgZ9TDNnO6L7UXfQIY9gJLaOpcjQ6/b7Q2JIkSM6GvYC Qzt4QpyVse6N0E/2ipGimBuROh8pbGbWUW4PJsicVM8RflkgBkwWJdZQh34h6pWA7ExlPgMOChlo 9EAqDzJhQsi67URnO3InwX/EKRT5fy8m7C6MfaXNNWdXBrCuLBWK4Ey+VTbmx90oQhCcP0SDox4e zOOb5PGNqsupllSbDFSKWmPu9uTU4Ynw1GUFbqYWVUqMeySX22/BVA0WDqvgQi9WUIm/giTweoRC Gjw+1i3cToqnpsTr2siuzziMMpG/m5tQDnL/moBpzHn/n8MmdV0JZuaThMQ7T6BJ/1+oDAeUJ0Fe 4jTERkbXlpAssLc9SoSMC9wCZmpi1h6IXCs39iIJWMIVp5xqrlFkBeoSR8y8VimqD3hIAocCs1U6 Tx3bAGH6UK6+LA8cE5H/kddXNbKh/OF2nLu/4Wtuk3oqzXLrGyGpF9cP5DmG8XC4wHHf9EoSmvVT oBrscpn5af3jZBxNouPeoPVyen7aOjuPhq3x2TRqdY+Gk9P+ae/oeDz9Cau8GZo40rGSfeUZRGVd l0Wpvy8CIJivmBeu9XYZ5mo3oimVBJT8s465QgdpN5lijUNU6YWnOFsLQ5vMT76Uuq1hpF5ALYp2 kiyuxVf+SIDJgjabv5sbrXOiKY00GGCk9HkhZVOd/o3VuJHopc81rTyBGQ0Qum1YGgjMYy6R5zj7 9nmsZ6rJc01qGtpXjU9Qjjsu5mNTgMRmXoGxwtelx0PAI57725/vb39h97cf725+vbv57e79+7ub D38WSu2/FsLaQmQoxM9tQ1l41rZxJ9/R8sNuxSf2EBkQKpuDARyFn9sB0/H/a4cDQOHLxX827D8X 8PvOVie/AwAA//8DAFBLAwQUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAGRycy9kb3ducmV2Lnht bESPy27CMBBF95X4B2uQuisO9KGSYhBCqlqBWEBhP8SDEzW2g21C8vcdddEuR3d07j2zRWdr0VKI lXcKxqMMBLnC68oZBYev94dXEDGh01h7Rwp6irCYD+5mmGt/cztq98kIhriYo4IypSaXMhYlWYwj 35Dj7OyDxcRnMFIHvDHc1nKSZS/SYuW4ocSGViUV3/ur5ZKxvLabbvl4eXreHvrLdCpNSErdD7vl G4hEXfp/Nutjtln/hb+oT62Ah58/+lOo9A5joqCA3diULUHOfwAAAP//AwBQSwECLQAUAAYACAAA ACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQIt ABQABgAIAAAAIQALV0jd1QMAAFALAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1s UEsBAi0AFAAGAAgAAAAhABP/D9jWAAAA+QAAAA8AAAAAAAAAAAAAAAAAKwYAAGRycy9kb3ducmV2 LnhtbFBLBQYAAAAABAAEAPUAAAAuBwAAAAAAABDwCAAAABQQIBBgFUARDwAR8BAAAAAAAMMLCAAA AAQAAAAIAv+/DwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoA AAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADw AAAA1AHQAvADEAUPAATwPAAAABIACvAIAAAAAaAAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8B EAAQAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTzgAAAA8AihMpAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQE AQAAAAoPAIoTlQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixN1AAAAAADrLggAAABKyccB 4Ix4vwAAHRAEAAAAAAAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAAAAAD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAOBMYOAABQ SwMEFAAGAAgAAAAhAJvocE/8AAAAHAIAABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMwEEX3 hf6D0LbYcroopdjOoo9dH4v0AwZ5bIvYIyFNQvL3HTsulBIChW4E0sy998yoXB/GQe0xJuep0qu8 0ArJ+sZRV+nPzUt2r1VioAYGT1jpIya9rq+vys0xYFKiplTpnjk8GJNsjyOk3AckqbQ+jsByjZ0J YLfQobktijtjPTESZzx56Lp8whZ2A6vngzyfSESu1eOpb4qqNIQwOAssoGaqmrO6iEO6INxT84su W8hyUc7mqXch3SwJ77Ka6BpUHxD5DUbhMCxD4s/zFUhGi/ll5jPRvm2dxcbb3SjryGfjxexPAKv/ if7ONPPf1l8AAAD//wMAUEsDgQEAAIIBAACDAQAAhAEAAIUBAACGAQAAhwEAAIgBAACJAQAAigEA AIsBAACMAQAAjQEAAI4BAACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACVAQAAlgEAAJcBAACYAQAA mQEAAJoBAACbAQAAnAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMBAACkAQAApQEAAKYBAACn AQAAqAEAAKkBAACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEAALIBAACzAQAAtAEAALUB AAC2AQAAtwEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAAwAEAAMEBAADCAQAAwwEA AMQBAADFAQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADOAQAAzwEAANABAADRAQAA 0gEAANMBAADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwBAADdAQAA3gEAAN8BAADg AQAA4QEAAOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEAAOsBAADsAQAA7QEAAO4B AADvAQAA8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA+QEAAPoBAAD7AQAA/QEA AP3////+AQAA/wEAAAACAAAEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SP z2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAW mqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDS SkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9 kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3Ro ZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl 44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXd INa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEA7/zmQlEJ AAB9OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPivac4DIZSu0ecmocd zairR/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Opfc6btqirlW7+bOha Xq3rTVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO20vddd3x8eGjXMJy1 P9fHvIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7A1jf8Webd94/r6O846KYF/1bU4sC6b J2ScM3pGrJmEfPPRRKK22T1HZaN9zsqVbpCP/vDu7UP2yAjKbkiXkg+jYwSbj9YUP0JQdkM6z8Cv 4EcIsvUaFjKcOwwTI7EZbY+IXg552/DxfYm+x98eyCytjTIlRPRyMaCXdNYjopfOgD4OkjhJJXkI EaV3B/RWbMVeINETon1ZVB8H1Ibhw4dRC5JtXf46Su77UWRwxZ+owPrCeXCKbV11Y66k481D9lfd pECBP8qsKyqt+3bMt9kafDRoiqxEcbLHPOuN06F1ezYEE0vsDkU1K+8TO5jptCqyxoO8xN+322Kd kxVui7J86r6V+b9bssi2LotNCoP4HMFuLiB03MMl079Et2sy8ozW1N1/im7/tM+OCGIyw65lrHet dqxbQCIZHuWNk4KSOwpZB/2ParPNut/qDR22+0gWbAiudyQ48IlsZHDtZPbydZOZVKqLapOXZhLR iO9ISxNLBhsOlwaDQpvg81qGQdl0IXqi7Fq7zsp8g3qnUY6bBafm1zObiK2aLmSfbXJqImm4ZzqT 2I67EAng4FIjprtNm0JroLRpIYhb8MDwYiVzBlyxZBHnaCqrPrbKSvuy0n3HcnRtnR1X+hZCClwe jmC0ttrpWlbuIOuuu4Z67SQWibedVuyPe5Vp8PGBV0kwPjZtF2ftntqQ3GKmKiucicpvOQt0tnkW QB31BVLYHrjId5MC9CibNt9u83XXN3ZvBHVHf7JIWH/q8uZpv/miPZefmvcZmB90iuvZFG230gmg 8Uez0lHb5JYcW1lcG6lwcLasPO4zFi09fJrpmZITVxUykF898WBto7KTxd2+FET8XEvpu/EPthRM B3mV2xu0wBpq5CbTEK8rvW66fQ1R6Lgv1mkDtQqJHeAtGkQXzLYaVOrkb5N/xr/UFygP5FYWu333 vthpTQHppNs3ef4HhCXifRPMTJZ6KEvOiHhUT9z2SMV+zj/n5QeMgS7GYF3bg6uTaMLck9Cd+5/8 myHoeYc1Sh9vUgwRUZ1i4H9duFAww6LAar3sN5F4MLnTCok+Tx7nObK/ELxxqpIWHBVS8vN9BvsX inBNAu7lWhqxBiu2HC4cWFEYhfgHlmowKOqZY9btNfwH8l/RrMtTefqhfg+xVYMeDpmB24BXv8Go BpcYIOnVM9Q9dJA6E7KiM7DiFLXGk/XMVZCY90zZKBnH23D1J3vfqGxRRMnTSVgcTvdyZTMNS7qm YxdVDZOdQxSGtrwPIYYh+wX9pr5+/gsMHUN79amkbX57hF8EB8c/GuJdz/XmG7ssW5pwqddhD4OU ZfU+32rF5ivvP4QmKIRoL8pLZEKNj2HlJh60x5oG+UFGj4/SbCketqYfFk+QmSFki4dJUzjGAHYi WODG1g7oiQpbumpQrdBUWb1GZVcIP66y0T7rWpXRRlFpqBeorPuqVhnTFChv6Hj5167JoDV5IvGX JR15EG235hT3bSi+MUNtbqF26OV9GyoSSeDyNhR40m/ZUXvemSsdsa6B96502KfUYczCMQvH4Ao2 I6FRpDuIK51DjI3AfWYATmPzEZuPLPjIgo84fAQaU/q4y0dcqNJwew32c/GPrvElQPfKdt5YXBqi YzhyCS807PyTtm19F79saWxfl+kaXVvaWk7DOHVu2LZNU993OW9mru+JlzROolCWX7ltmyy9wImY bpi/oPxiT1bSThTZULAwakHCnWegTFSNID9RQZQWzoPP/Nh4oQXKPwkvtxxz4M58Kh8TkLOQHhTO PGhA/13zSxQk1pn8SryEfugny2vxgoc6EUfXNF6C1F0KYe54GT8WXJCS+jV4gXMtN+X15AzHgjfl l/6RZC8JXcKLF0eucIkeEb0c1mNJlAap7J+EiNK//lhw5NhRiZdlGtrX4wWOjt0b8GIYAbTrDIx3 vIzjxXk1XtDmMe8JZsDLknyY2abqMZxc9mdlfsF4KzzoCrwg+4SvrQeqWfESSPlCiRcrxgwj0SuO 0dPUgfMgRj2dX7BYveMF3jRhVSfdETjr910FXpzA8Zi2WQJicJBqHPQpEbOVeOm9TsLeSxl77QS5 iZclJvACEXThWpL/KPHixm4ayfhS1mNBEBkR97gr8BIH+JXkIUmIPkqgIOkuCEIvlOVR4sW13EW4 kPgr8GIYPctM4wXJb8QL6ehJvw+GZ/0+uArr98F4vCuHHQGqA7hHL/5P+/3lRbw4kXlS3wx4IVvz 3PcUeInT2PJ5DzyBF6mjZQbB6MBMMmhpw2Tpu1yGHhG9HNZjkRHAR/JPZT12K14SC+Al81fiJYjc 2JH3KxR4kSLPNF5iO7BMnryuq8d+PLx4F/FiGLYt9pJmwAueWIm8ocALduS9fNWL/8PXGlHCs/pK mV8MIzydm12BF0RLJPvzrHgJ4tBL5PyoxAto8BTDqPwKvKBuhCan8QKl59IwWXC442W8f6FvDTM4 SLUC+mLPv4kfvq4eQ8QwcyjwkthJ2Ns/UOIFMS1kpP6jxMvC9YJFKOWLHv9hfkG8nMX/efESBPEZ HpV4sdNlvOC5d3a8GAmcVd/xkqv6F5Me344BRmq8Z0gwrueGTjwNmNiMzYg79URB5hu+4ckBWgkY z/CTgDdlVyQYaK+DUC6AZgVM5MKXx3QqjxIwS9tLfVl+RYJJ0ygSJcJ0gkn8OBK7CfcEM55gzMv/ 0cSGUC9Ox+YAjCtlLBLZGR6kzIb1mKgjJgDjGo6/5OC6IsOACK7gfQ1gvNA7ywCzAiaEGBLKJ0hK wDiRE12/oyydT00DBtUu0vUdMBcAc/mIH/4XkGE6IiO8uiRzLDuxeLRWlGRxGhkez0QTgPGiZbjk VcQVgPFSJ7VkB1WWZKEdpAE/9KP8ZwVMBHAJZcArAeOZjmPJLZUiw0RRCK+sMgtOA8aLIP1y8h8J MPASg/xODHmxDEbJq5Dv/gYAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVt ZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQ rdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCC jm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvV ABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAI AAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1lL3RoZW1lL3Ro ZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA7/zmQlEJAAB9OQAAFgAAAAAAAAAAAAAAAADT AgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAA AAAAAAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUG AAAAAAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJV VEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDovL3NjaGVt YXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQxIiB0eDE9 ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQyPSJhY2Nl bnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJhY2NlbnQ1 IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGluayIvPgAA DSsEAAAA11fU2gAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oAi7S2RfWHVgnJ23ftpBRKyGnR rmbmY1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwgyXV/fbXaHDKSYHWkTk615ket yUwYgFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9FS97Xh9JWC7F0/HfHNVJyNk7 A5VB9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5DYA5tC+nqAjf0FoekLpOeCUzD 4AzaZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAIAAAAIQAXS2h7ugAAACgBAAAL AAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUDQrJtg80mZKPo35tjBcHj7DBv dprTy8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrVXHHWuYR4cpFFoRArmHKORynZ TOg1VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9jaf7PDsPgDJ6DeXik/KNCZufL sI6GUKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgAAAAhACVGREEHAQAAygEAABIA AABkcnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2e1k8eZL6A0Iy3Q00MyGZdd1/ 77RbBfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxetClv0diaEXl+g6N1wf9ellkOU V0oMsLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020AfWmz7foaZqCgz25UwTkq0mG 2bLAl2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLYgB6mgIFBK/Fhm7nXCNKkVkge xkuStji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkNR+bGt2zrNwzfAAAA//8DAFBL AQItABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAAAAAAKQEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAAAAAAAAAAAAAADAIAAGRycy90 aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAACgAB4E5QUAAFBLAwQUAAYACAAAACEA R3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqdskAIJemC xwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9VPecYVHB KBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UMBUKpyvKD d80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8OTm8UzTZ GmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++AQAA//8D AFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETvgv8Q9m7T ehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxvp80eBCd0 BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluWOxm/GdAs mOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy8bf5AAAA //8DAFBLAwQUAAYACAAAACEAzYmiB7QCAABqBwAAIQAAAGRycy9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxLnhtbKRVy27bMBC8F+g/ELwn8qtJKsQO0LTJJQ+jdnrfUutICEUSJKPa/fouSdGB0wSw 24tskbPD3Zld6vxi3UrWoXWNVlM+PB5whkroqlGPU/6wvDo648x5UBVIrXDKN+j4xezjh3NTOlnd wEY/e0YcypUw5bX3piwKJ2pswR1rg4r2Vtq24OnVPhaVhV/E3cpiNBicFC00ivfxdp94vVo1Ar9q 8dyi8onEogRP+bu6MS6zmX3YjEVHNDF6NyW/MVQtCeOXa84izna0MuQzKl0sZMUUtLSwbLxERgKx HwRuBEi2xLWPMGeWFjEEqO7amoWZ2xh9180ta6rA1rPwot/oYfFVEYz+FK/CHzMTlOuVbWfnUJIq bD3lZN4mPCkISkqCibQoXlZFff8GVtTf3kAX+QDKYHso+W5SRX+XM8rlJFGG26oSFCj0Rosnx5Sm OkP5qTxx12WyUHOgNzVLFvigb49Lm1GPjHdR05zoVonJp1PqryjH6HRyMj7b1eRsNPp8EvaDMsPh ZDygl5DLC5Gxzl+jbsl756fcogieQgndjfMJmiHRopSIKf36i642AfmTfsnn0EPUi9r+TjlI5xd+ IzGaRFJCSQXTg6ASwtShOnpY0NS1/lIi0FT2hvrZpWzEE/OaYdV4dgvOo2VRIJpRogz5+1hFpERV zcHC91fMffIx65wtaZpsfd/ccTZ3p8/ZXILAWsuKUhmFCmk6sp3/ZHiQjTNtGxrMNIGcZoUaOXfL O10Qj871vFIfIST9nv7UQkx2civ0f/oRBi/a4Xb8IG+i2+mRj4xFHdACCxSa7hqJHco96KMjB9Av 68buzz5Oiu6t15V+tr7eO/nJofTN6k12ugsPnoQ4EOn2pr/hvo+dLe0tmPsuVkxfOJq/y7hk6JsW 5oqgL5DAkb+Rsz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAA AAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAzYmiB7QCAABqBwAAIQAA AAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAAD AAMAyQAAAAYFAAAAAAAAHQQEAAAAAQAAACAAug8UAAAAMQAwAF8AaQBlAHQAZgAtADYAOQAPAPgD cUQAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAACAP+/YADwByAAAAD///8AAAAAAICAgAAA AAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlm AABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAA AJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA /1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACA AAAA////AFwfAADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNm zAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADw ByAAAABoa10A////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA ////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACM nqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAA AAABAAAA//8sAAAAAAMAABAAow+AAAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIA AAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAABAACABQAAEyDUASABAAAiAP//FACABQAAIiDQAkAC AAACABIAgAUAABMg8ANgAwAAAgAQAIAFAAC7ABAFgAQAAAIADgAgAKMPcAAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAAEAAAD//wwAAAAAAQAAAAUAACAB IAEAACAA//8ABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/ AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAACABAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAA AAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAF AAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAA AQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAA AAAAAAACABQAAQAAAAAAAAACABIAAgAAAAAAAAACABAAAwAAAAAAAAACAA4ABAAAAAAAAAACAAwA gACjDz4AAAAFAAAAAAAAAAAAAgASAAEAAAAAAAAAAgAQAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAM AAQAAAAAAAAAAgAKAAAAIwQYBwAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRl bnRfVHlwZXNdLnhtbHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErI apjHnXu4zXrvndhhJhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynp SWsyE3ogFRMG3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSU nDVQGFTPW31Rl9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LX wS/4x2GwBvtotp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAA OAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+O FgSPwzBvZur2NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGs YEwpHKRkPdKMXPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJ pR8Vkidr6IycKGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAAGr3Iro AwAAPyYAACEAAABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWktu2zAU3BfoHQRu A8eW/JFsWA6SFFllETTJAWiZstVQlEAxadxVkRyhN+i+aIEW6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2 ivkROUO9N8OX7sGtj7UbRCMvIDbQ92tAQ8QJBh4Z2uDy4qRiAS1ikAwgDgiywRhF4KD3+lU37LDb czbGKNL4FCTqQBuMGAs71WrkjJAPo/0gRIS3uQH1IeN/0mF1QOF7PrWPq0at1qr60CNAjadFxgeu 6znoTeBc+4iweBKKMGR8+dHIC6NktrDIbCFFEZ9Gjs4sqSe25zGM5A57XdjBN1gPz6gG8ZDj5DAK NMqwDQRe8JQc0Sv57AaEHcoufRghoI0gGfL9nl0Th4kOYqoodI6Qq57OHKbdQDlRtdetzrUeumxF P9U6QO5bvrLogw0ajZp6R4C9wYmHsRwu+EDHmMZvYrcGUO9K9xIgEo2NQ+RChzO957+rYCZ6wg6C qYbHhy+PD9+1x4dvk7sfk7ufk/v7yd1XoDkjSCMktykHOdF/D+L7j3cjoVCYiwXwR2O34D+kHsRA Cz3mjE6g7+GxDSp6rb2I84uRIxhR5NRLcjaMHMGIIqdRkrNh5AhGFDnNkpwNI0cwoshpCXJ8SE95 am2aXLKAPAEwl/TF2C3J8UWTzEJeFsAojMwZRm1dCpASIylYBDAKI2uGkV439VZ5kBKBJ5BRILVT IFmGZZUgJSAJZPhz1pOEnX4wGC8YlDha1RtGW+DnkQE3OFw5Jj/E/oULy6d1Lzw08tet62D618fc O0gDYYM/Hz/HpiPla4xivkZPVrDa15DN8zUxayZnrZlmzbCapvhhG1j7tMiaOBMyG6b5kLcDaTf6 PKytMk4V3bDUUcnazXlHE9Oi64262MrsazIMKxXDt+hr2io25i2MYoMjL5XYNLZtExuLX4lUA1vF y7x7iXkxak1ThOlt/Ep+/1oIXvpLppy1gle+bzGaekPGqn9/LoV9zBNm+xzkxezblTby3ZDRNnUp Ykvki1wfr3Xm8z1WLHYLhaLyzK++Y14qlfKNW92yWgWTc4n8mshP3WDK/4WdgI0QnbpBLmvPYmOt XBTmhSgbIFK5PJ8pX9UlqW3FeTxtN/jgC9g/F5Uldf21YBt1oMnK0awGlq156TKUq1WIGlUcE68Q FfVGcVaeW/vs+aSCYJzgMzUp0eBEMzh4FS1x3KLWJ9aV1J1iaBIQpnZsZ/HJN0rZ+z9ui3YWnyXW JXv3t8sA5XsIPXvvt8sALVHz8uKhDNE8Li8R3WajLgVIGaOXaGOOjrTpJUBLJGyraWYv93Y2i02V ZlpcijKE+s+v3l8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6AAAAuwEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAA AAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAAavciugDAAA/JgAAIQAA AAAAAAAAAAAAAAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAAD AAMAyQAAADkGAAAAAA8ADAQxHQAADwAC8CkdAACQAgjwCAAAAAUAAAAFpAAADwAD8M0cAAAPAATw KAAAAAEACfAQAAAANAAAAAAAAAAEAAEAAAAAAAIACvAIAAAAAKQAAAUAAAAPAATwLgEAABIACvAI AAAAAqQAAAAKAACDAAvwSAAAAH8AAQDvAYAAmI1vIL8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDD GAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAA AAAAwwsIAAAAAQAAAAIA/78PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRp dCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZl bA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoA AABTAAAAAQAAAAAADwAE8NYIAAASAArwCAAAAAOkAAAACgAAgwAL8FYAAAB/AAEA7wGAAGiRbyC/ AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYAAAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgA bwBsAGQAZQByACAAMwAAABMAIvHYBwAAqcPSBwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAAT AAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tj Qnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptd RFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURw re4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNE lJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAA IQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr 7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF9 97LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa 1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z 6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCqBaF5bwMAAPUHAAAQAAAAZHJzL3NoYXBleG1sLnht bKxVzW4TMRC+I/EOlu+QpE1LidiitlBAClVEijjP7nq7S7z2YnvTpMfyPAgkkLj0bfoAfQVmxpum /AgBpYdmvJ7xfPN94/Gjx4tai7lyvrImkYP7fSmUyWxemZNEvj4+vLcjhQ9gctDWqEQulZePd+/e edSMfCMw2PhRk8gyhGbU6/msVDX4+7ZRBvcK62oIuHQnvcYpr0yAgIlq3dvo97d7NVRG7uJRZj5t Jo6s7Gg+caLKE7kthYEaUz6BoMREQ6ZKq3PlxKbsda4xChDK2GYz3+GBP8GTOzjFIr+DIox95rCa ASXoMZgVLoOwKGlTirBsEFUekJgzzAS6kAh4kciNLiz6Yvy6LI/lifT0pc0xFNpgsWwYLQpX3xYz nWOLQmD+4dYDpFWKJZK3tTkcbPUJEIzUIoiM8A02N7fJIUOP4YPtjejQi0DIs3E+PFP21qAEHZRI p7LAhcJ87ANxuk5B6bT5H9XXVcCm0FWdyJ0+/cWqSwX5U5MzAwEqHW1EoA2LS5KQomGxb/MlwUnx F2WKTf3vTYS3CWsvrTuT4tQB9pN/14JTUugXxify4WA4RBECL1gzKdzNnfTmjmnrA6upJwWYDE9N JHZeNA8CrkhPWzcQxmbaZOS4UvJ48QZc02kRsAuO7LSERv1KkujLCkUaWB8fpmGp1W0p4bPmesCM wyhXxauJi+2gV59JmC4d4/8fOenS1eDGTBIar9jAlPxbmRwHEpugT3D6aSkQ2jGkU7zXrBJy60L0 VjA2+27GQhTWhD0OScGTrjjVTLeNISWYExwtk9ZkeHzUQ5M4VJhvskkWxBxI0+t25bZce+yr4kdf 7mp0w/j17l4RfuPX7abtgXbHC74IaTs9uzYPsYzrxRGO9+6upPGyfi9Up50y+QQcoH5i1tZVbd9W kVSsOZHK3Hs9jXNxMKRJk0am+X+bSINJ6D1x1QznoLFTtqSYKUevD0+vjG5M50j9jKcYekd0daae 85JI1xW9Rrw3cdYWZBMVdLlhZOxhpXXXYfzFW13l9JH5omdKIStRhrCIAx/JvemligLn14qLdmw6 rlo6prNZeX4RCnyfErnnKsA2ykpwXnFvMacKbvhcXXy4uvgsri4+XZ5/uTz/evn+/eX5x5+DMv/X Qdgfa4HiuOVZt5px+Cb5ZvcbAAAA//8DAFBLAwQUAAYACAAAACEAtL6VANUAAAD5AAAADwAAAGRy cy9kb3ducmV2LnhtbESP3UrDQBCF7wXfYRnBO7upP8HGbksRREG8aO0DjNnJD2Zn091Jmry9ixd6 eTiH7/Ctt5Pr1Eghtp4NLBcZKOLS25ZrA8fPl5tHUFGQLXaeycBMEbaby4s1FtafeU/jQWqVIBwL NNCI9IXWsWzIYVz4njh1lQ8OJcVQaxvwnOCu07dZlmuHLaeHBnt6bqj8PgwunSz1ML5Pu7vT/cPH cT6tVroOYsz11bR7AiU0yf948HmF/q/8Rb1ZAzmo6nX+Cq3dYxQKBpJbMk2WoDc/AAAA//8DAFBL AQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBl c10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxz Ly5yZWxzUEsBAi0AFAAGAAgAAAAhAKoFoXlvAwAA9QcAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9z aGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAtL6VANUAAAD5AAAADwAAAAAAAAAAAAAAAADFBQAA ZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAMcGAAAAAAAAEPAIAAAAFBAgAWAGQBEPABHw EAAAAAAAwwsIAAAAAgAAAAcB/78PAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAAAAAAIAAK AAAAAP8HAAEAAAAAAAIADgAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA1AHQAvAD EAUPAATwGAkAABIACvAIAAAABKQAAAAKAACDAAvwWgAAAH8AAQDvAYAACKNvIL8AAAAGAL8BAQAR AP8BEQAZAD8DAAAIAIDDKgAAAL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgAbwBsAGQA ZQByACAANAAAABMAIvESCAAAqcMMCAAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3Z IFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6 yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tV rSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdS N3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N 0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHM NXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnC Updk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmO HbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsA AAD//wMAUEsDBBQABgAIAAAAIQCi6wxqqAMAAOwJAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxWzW4b NxC+F+g7ELwn+on8EyHrwDbqNIBiCJGKHo3ZXa7FiktuSa4s+eg8T9ECLdCL38YP4FfozHBl2W1R tHUOPXQP2uFyyPlmvvnRm7fr2oiV8kE7m8nBy74Uyhau1PYyk9/Mz14cShEi2BKMsyqTGxXk26Mv v3jTjEMj8LAN4yaTixibca8XioWqIbx0jbK4VzlfQ8Slv+w1XgVlI0Q0VJvesN/f79WgrTzCq+xq 1kw9ScX5auqFLjN5IIWFGk2eOReVF1MDhVo4U6I8kr1OOZ0DBDNxxTJ0iODvICo9XKGbT8AI6955 9GdABnoMZ4vMIjAy2ixE3DSIq4oeY3Odye9b8IhQIux1Jl91R5M+3rFzLqCTIr/64Eo8Dm106DyM 15Wvn4ub7nFVJcj+YDjC6EqxyeT+3qvRYK9PiGCs1lEUqDA8fL23TwoFaowO9odJoZeQkGbjQ3yn 3LNRCbook14VkT2F1SRECuzOBJkz9nO4X2vKEqPrTB726UleLxSUX9mSIxBBmyQjAmOZYeKEaI3r E1duCE6Ob+Qp5fa/zyQsKvR94fy1FFceMKkCJYqSwry3IZOvB6MRkhB5Mdo7GOLCP97JH+/Ytj51 hhJTgC3w1kzGrXgacUV8urqBOLGzpiDFLZPz9bfgm46LiFlw7mYLaNSfUZJ0maEUBuYnxFncGPXc kPBdKzPgiMO4VNXHqU/pYLafiZjOHOP/HDap6mrwEw4SCh9ZQJP81rbEvsQimEtsggXVNYKbQz7D 6maeiJuY9BVM7IlfMhWVs/GYD+UQiFlsb7bbxiMLsJfYYaatLdBAYsQQPeRaaIppEcUKiNWHhOXE 3GmcqOr3upzXqIbnd7vHVfwLvW43b0+Nn6+5FPJ2dv0gnqEbD4tz7PNdteSpXJ9S1bGHRQNjj5Fd trWu3Xc6BRU9zqSOL97PU28cjKjT5BytpNJm0qIJGiteL7ERWjdjSYql8jSEuHsVVDGdIuUz3mJp nBh9rb7mJYXcaBpKvDf1zlUsl9pHbG34NdTx1CjAS/uc7VTzMLbuTBvTJR5/Cc7okj5yEGmIKQxV 4iau0zDAiD/WUlWFbW0boHZiuwC2dE0nczrwtKhwdmXy2GswWKcL8EFxynGgFTzSub/94f72Z3F/ +9PdzS93N7/effp0d/PjHw8V4R8fwqRBwsjFeCTScyEuLgT1Y0wf2mZS+ee/zSxB/J/MHZlPKEQi G55t25mGf0JCc/QbAAAA//8DAFBLAwQUAAYACAAAACEA/QKip9YAAAD5AAAADwAAAGRycy9kb3du cmV2LnhtbESPy0oDQRBF94L/0JTgJpie+M6YTgiCKAQXicF1OV2ZGZzunnRX5vH3Fi50ebmXczmL 1eAa1VFMdfAGZtMMFPki2NqXBvYfL1ePoBKjt9gETwZGSrBanp8tMLeh91vqdlwqgfiUo4GKuc21 TkVFDtM0tOSlO4TokCXGUtuIvcBdo6+z7F47rL08VNjSc0XF9+7k5GSmT91mWN8cb+/e9+NxPtdl ZGMuL4b1Eyimgf/H/YTD5+Sv/EW9WQMPoA6v41es7RYTUzQgbmIqlqCXPwAAAP//AwBQSwECLQAU AAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCi6wxqqAMAAOwJAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4 bWwueG1sUEsBAi0AFAAGAAgAAAAhAP0CoqfWAAAA+QAAAA8AAAAAAAAAAAAAAAAA/gUAAGRycy9k b3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAABBwAAAAAAABDwCAAAABQQsAfQDkARDwAR8BAAAAAA AMMLCAAAAAMAAAAJAv+/DwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdH AAChDx4AAAAPAAAAAAAgCAoAAAAA/wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQ BQ8ABPBhCQAAEgAK8AgAAAAFpAAAAAoAAIMAC/BmAAAAfwABAO8BgAB4mG8gvwAAAAYAvwEBABEA /wERABkAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBj AGUAaABvAGwAZABlAHIAIAA1AAAAEwAi8T8IAACpwzkIAABQSwMEFAAGAAgAAAAhADI8vT77AAAA 4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uS WCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1u zs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rf yvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJh XGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAG AAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLW kEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNH MnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQH ZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvx T5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhABiyBMHVAwAAUAsAABAAAABkcnMvc2hhcGV4 bWwueG1s7FbNbttGEL4X6Dss9q5IlCjHFkIHtBunARRDiFT0WAzJpcVqucvuLmXJRS/O8xQNkAK9 +G38AH6FzuxSltMWRVv70EN0oGa58//ND1+83NSSrYWxlVYJj54NOBMq10WlLhL+zeKsd8iZdaAK kFqJhG+F5S+Pv/ziRTOxDUNhZSdNwpfONZN+3+ZLUYN9phuh8K7UpgaHR3PRb4ywQjlwaKiW/eFg cNCvoVL8GFWp9byZGaLy8/XMsKpIOBpWUKPJuawKwc7bOhOGzSTkYqllgfSY9zuRIA3o0lTnK9v5 Bf/Er8LAJQb7iUtM6dcGo4rIQN87tfNPoXtktFkyt23QOysLdA2TdJXwH1owThiO/m8SHnfSQQTV 7KO0GC3LLt/qAjVA6zRmASab0tSPdZ306LJkaP9gPB5hmjnbEj2Ko/GAPIKJ2DiWI8MwGo0OiCFH jvj5wTAw9IMnxNkY614L/WivGClKuBG585HCemod5XZvgsxJ9RTh1xViwGRVYw0N6BeiXgooXqnC Z8BBJQONHkjlQSZMCFm3OdHFltzJ8B9xCkX+34sJuwtjX2pzxdmlAawrS4UiOJNvlE34URTHCILz h3j8fIgH8/Ame3ij2vpUS6pNBipHrQl3O/LU4Ynw1HUDbqrmTU6MOyQXm2/BNB0WDqvgXM+X0Ii/ giTweoRCGjw+1s3dVorHpsTrWsvIZxwmhSjfzUwoB7l7TcB05rz/T2GTuq4GM/VJQuKdJ9Ck/69U gQPKkyAvcBpiI6NrC8jm2NseJULGBW4BU3ViVh6IUiuXepEMLOGKU0511yiyBHWBI2bWqhzVBzwk gUOB2Saf5Y6tgTC9L1dflnuOE1H+kddXNbKh/P42Ld3f8HW3WXsqzWLjGyFr51f35BmGcX84x3Hf 9UoWmvVToDrsSln4af3jQZqOosNx2ovTQdQ7PYqHvXR4NO7FXx1Fg8OzND1JX/2EVd4NTRzpWMm+ 8gyismrrqtbfVwEQzFfCK9d7swhzNYppSmUBJf9sE67QQdpNplrhEFV67inOVsLQJvOTL6du6xip F1CLop0kqyvxtT8SYLKizebvZkbrkmhKIw0GmCh9VknZVad/YzVuJHrpc00rT2BGA4RuE5YGAvOQ S5Qlzr5dHtup6vLckpqO9lXjE1Tijkt4aiqQ2MxLMFb4uvR4CHjAc3fz893NR3Z38+H2+tfb699u 37+/vf7lz0K5/ddCWFuIDIX4uW0oC0/aNu74O1p+2K34xB4iA0IVMzCAo/BzO2A6/n/tsAcofLn4 z4bd5wJ+39nm+HcAAAD//wMAUEsDBBQABgAIAAAAIQAT/w/Y1gAAAPkAAAAPAAAAZHJzL2Rvd25y ZXYueG1sRI/LbsIwEEX3lfgHa5C6Kw70oZJiEEKqWoFYQGE/xIMTNbaDbULy9x110S5Hd3TuPbNF Z2vRUoiVdwrGowwEucLryhkFh6/3h1cQMaHTWHtHCnqKsJgP7maYa39zO2r3yQiGuJijgjKlJpcy FiVZjCPfkOPs7IPFxGcwUge8MdzWcpJlL9Ji5bihxIZWJRXf+6vlkrG8tptu+Xh5et4e+st0Kk1I St0Pu+UbiERd+n8262O2Wf+Fv6hPrYCHnz/6U6j0DmOioIDd2JQtQc5/AAAA//8DAFBLAQItABQA BgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhABiyBMHVAwAAUAsAABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXht bC54bWxQSwECLQAUAAYACAAAACEAE/8P2NYAAAD5AAAADwAAAAAAAAAAAAAAAAArBgAAZHJzL2Rv d25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAC4HAAAAAAAAEPAIAAAAFBAgEGAVQBEPABHwEAAAAAAA wwsIAAAABAAAAAgC/78PAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAA ACAICgAAAAD/AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYP DAAAAPAAAADUAdAC8AMQBQ8ABPA8AAAAEgAK8AgAAAABpAAAAAwAAGMAC/AkAAAAgQEAAAAIgwEF AAAIvwEQABAA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMz mQAAmZkAmcwAAA8AiBPOAAAADwCKEykAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMgAAAIsTCQAA AAAAJAQBAAAACg8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAA AErJxwHgjHi/AAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAA AAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAA4E xg4AAFBLAwQUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctq wzAQRfeF/oPQtthyuiil2M6ij10fi/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhcH8ZB7TEm 56nSq7zQCsn6xlFX6c/NS3avVWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6TcBySptD6O wHKNnQlgt9ChuS2KO2M9MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqas7qIQ7og 3FPziy5byHJRzuapdyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3FxtvdKOvIZ+PF 7E8Aq/+J/s4089/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8u cmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L +eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKu QmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRi oagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHH oNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j 1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEA 3+4ZelEJAAB9OQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsW1mPo0gSfl9p/gPivac4DIZS u0ecmocdzairR/u4omxsM43BAvr69xORl0mDE7sKbc+qbUtdOAkiIyPiiyOTfvvL10Opfc6btqir lW7+bOhaXq3rTVHtVvqfH9I3nq61XVZtsrKu8pX+LW/1X9799K+32WO3zw+5Bs9X7WO20vddd3x8 eGjXMJy1P9fHvIJ727o5ZB38bHYPmyb7AnwP5YNlGO7DISsqXauyA7A1zf8Webd94/r6O846KYF/ 1bU4sC6bJ2ScM3pGrJmEfPPRRKK22T1HZaN9zsqVbpCP/vDu7UP2yAjKbkiXkg+jYwSbj9YUP0JQ dkM6z8Cv4EcIsvUaFjKcOwwTI7EZbY+IXg552/DxfYm+x98eyCytjTIlRPRyMaCXdNYjopfOgD4O kjhJJXkIEaV3B/RWbMVeINETon1ZVB8H1Ibhw4dRC5JtXf46Su77UWRwxZ+owPrCeXCKbV11Y66k 481D9lfdpECBP8qsKyqt+3bMt9kafDRoiqxEcbLHPOuN06F1ezYEE0vsDkU1K+8TO5jptCqyxoO8 xN+322KdkxVui7J86r6V+b9bssi2LotNCoP4HMFuLiB03MMl079Et2sy8ozW1N1/im7/tM+OCGIy w65lrHetdqxbQCIZHuWNk4KSOwpZB/2ParPNut/qDR22+0gWbAiudyQ48IlsZHDtZPbydZOZVKqL apOXZhLRiO9ISxNLBhsOlwaDQpvg81qGQdl0IXqi7Fq7zsp8g3qnUY6bBafm1zObiK2aLmSfbXJq Imm4ZzqT2I67EAng4FIjprtNm0JroLRpIYhb8MDwYiVzBlyxZBHnaCqrPrbKSvuy0n3HcnRtnR1X +hZCClwejmC0ttrpWlbuIOuuu4Z67SQWibedVuyPe5Vp8PGBV0kwPjZtF2ftntqQ3GKmKiucicpv OQt0tnkWQB31BVLYHrjId5MC9CibNt9u83XXN3ZvBHVHf7JIWH/q8uZpv/miPZefmvcZmB90iuvZ FG230gmg8Uez0lHb5JYcW1lcG6lwcLasPO4zFi09fJrpmZITVxUykF898WBto7KTxd2+FET8XEvp u/EPthRMB3mV2xu0wBpq5CbTEK8rvW66fQ1R6Lgv1mkDtQqJHeAtGkQXzLYaVOrkb5N/xr/UFygP 5FYWu333vthpTQHppNs3ef4HhCXifRPMTJZ6KEvOiHhUT9z2SMV+zj/n5QeMgS7GYF3bg6uTaMLc k9Cd+5/8myHoeYc1Sh9vUgwRUZ1i4H9duFAww6LAar3sN5F4MLnTCok+Tx7nObK/ELxxqpIWHBVS 8vN9BvsXinBNAu7lWhqxBiu2HC4cWFEYhfgHlmowKOqZY9btNfwH8l/RrMtTefqhfg+xVYMeDpmB 24BXv8GoBpcYIOnVM9Q9dJA6E7KiM7DiFLXGk/XMVZCY90zZKBnH23D1J3vfqGxRRMnTSVgcTvdy ZTMNS7qmYxdVDZOdQxSGtrwPIYYh+wX9pr5+/gsMHUN79amkbX57hF8EB8c/GuJdz/XmG7ssW5pw qddhD4OUZfU+32rF5ivvP4QmKIRoL8pLZEKNj2HlJh60x5oG+UFGj4/SbCketqYfFk+QmSFki4dJ UzjGAHYiWODG1g7oiQpbumpQrdBUWb1GZVcIP66y0T7rWpXRRlFpqBeorPuqVhnTFChv6Hj5167J oDV5IvGXJR15EG235hT3bSi+MUNtbqF26OV9GyoSSeDyNhR40m/ZUXvemSsdsa6B96502KfUYczC MQvH4Ao2I6FRpDuIK51DjI3AfWYATmPzEZuPLPjIgo84fAQaU/q4y0dcqNJwew32c/GPrvElQPfK dt5YXBqiYzhyCS807PyTtm19F79saWxfl+kaXVvaWk7DOHVu2LZNU993OW9mru+JlzROolCWX7lt myy9wImYbpi/oPxiT1bSThTZULAwakHCnWegTFSNID9RQZQWzoPP/Nh4oQXKPwkvtxxz4M58Kh8T kLOQHhTOPGhA/13zSxQk1pn8SryEfugny2vxgoc6EUfXNF6C1F0KYe54GT8WXJCS+jV4gXMtN+X1 5AzHgjfll/6RZC8JXcKLF0eucIkeEb0c1mNJlAap7J+EiNK//lhw5NhRiZdlGtrX4wWOjt0b8GIY AbTrDIx3vIzjxXk1XtDmMe8JZsDLknyY2abqMZxc9mdlfsF4KzzoCrwg+4SvrQeqWfESSPlCiRcr xgwj0SuO0dPUgfMgRj2dX7BYveMF3jRhVSfdETjr910FXpzA8Zi2WQJicJBqHPQpEbOVeOm9TsLe Sxl77QS5iZclJvACEXThWpL/KPHixm4ayfhS1mNBEBkR97gr8BIH+JXkIUmIPkqgIOkuCEIvlOVR 4sW13EW4kPgr8GIYPctM4wXJb8QL6ehJvw+GZ/0+uArr98F4vCuHHQGqA7hHL/5P+/3lRbw4kXlS 3wx4IVvz3PcUeInT2PJ5DzyBF6mjZQbB6MBMMmhpw2Tpu1yGHhG9HNZjkRHAR/JPZT12K14SC+Al 81fiJYjc2JH3KxR4kSLPNF5iO7BMnryuq8d+PLx4F/FiGLYt9pJmwAueWIm8ocALduS9fNWL/8PX GlHCs/pKmV8MIzydm12BF0RLJPvzrHgJ4tBL5PyoxAto8BTDqPwKvKBuhCan8QKl59IwWXC442W8 f6FvDTM4SLUC+mLPv4kfvq4eQ8QwcyjwkthJ2Ns/UOIFMS1kpP6jxMvC9YJFKOWLHv9hfkG8nMX/ efESBPEZHpV4sdNlvOC5d3a8GAmcVd/xkqv6F5Me344BRmq8Z0gwrueGTjwNmNiMzYg79URB5hu+ 4ckBWgkYz/CTgDdlVyQYaK+DUC6AZgVM5MKXx3QqjxIwS9tLfVl+RYJJ0ygSJcJ0gkn8OBK7CfcE M55gzMv/0cSGUC9Ox+YAjCtlLBLZGR6kzIb1mKgjJgDjGo6/5OC6IsOACK7gfQ1gvNA7ywCzAiaE GBLKJ0hKwDiRE12/oyydT00DBtUu0vUdMBcAc/mIH/4XkGE6IiO8uiRzLDuxeLRWlGRxGhkez0QT gPGiZbjkVcQVgPFSJ7VkB1WWZKEdpAE/9KP8ZwVMBHAJZcArAeOZjmPJLZUiw0RRCK+sMgtOA8aL IP1y8h8JMPASg/xODHmxDEbJq5Dv/gYAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6 EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J 2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzF JL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQIt ABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1lL3Ro ZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA3+4ZelEJAAB9OQAAFgAAAAAAAAAA AAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsB AAAnAAAAAAAAAAAAAAAAAFgMAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJl bHNQSwUGAAAAAAUABQBdAQAAUw0AAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29k aW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDov L3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQx IiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQy PSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJh Y2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGlu ayIvPgAADSsEAAAAy/zf8QAACysTBAAAUEsDBBQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbHyQzWrDMBCE74W+g9C1WHJ7KKXEzqE/0EvbQ/oAi7S2RfWHVgnJ23ft pBRKyGnRrmbmY1brffBih4Vcip28Va0UGE2yLo6d/Nq8Ng9SUIVowaeInTwgyXV/fbXaHDKSYHWk Tk615ketyUwYgFTKGPkypBKg8rOMOoP5hhH1Xdvea5NixVibOnvIfvWMA2x9FS97Xh9JWC7F0/Hf HNVJyNk7A5VB9XzVZ3UFPV0Q7qL9R9ecyBQrF3OaXKabU8IHV1OcRfEJpb5DYA5tC+nqAjf0Foek LpOeCUzD4AzaZLaBS1C5IPFcsoNXf86/DHqpuv8BAAD//wMAUEsDBBQABgAIAAAAIQAXS2h7ugAA ACgBAAALAAAAX3JlbHMvLnJlbHOEj8EKwjAQRO+C/xD2blM9iEhTLyL0KvUDQrJtg80mZKPo35tj BcHj7DBvdprTy8/iiYldIAXbqgaBZIJ1NCq49ZfNAQRnTVbPgVDBGxlO7XrVXHHWuYR4cpFFoRAr mHKORynZTOg1VyEiFWcIyetcZBpl1OauR5S7ut7LtGRA+8UUnVWQOrsF0b9jaf7PDsPgDJ6DeXik /KNCZufLsI6GUKg6jZgV2MSLe1X+Bdk28mtf+wEAAP//AwBQSwMEFAAGAAgAAAAhACVGREEHAQAA ygEAABIAAABkcnMvdGltaW5nSW5mby54bWyMkUFLxDAQhe+C/yHkbtOKiJS2e1k8eZL6A0Iy3Q00 MyGZdd1/77RbBfGyp5mQvMf3XrrdV5zVJ+QSCHvdVLVWgI58wEOvP8bXhxetClv0diaEXl+g6N1w f9ellkOUV0oMsLS210fm1BpT3BGiLRUlQLmbKEfLcswH47M9iyTO5rGun020AfWmz7foaZqCgz25 UwTkq0mG2bLAl2NI5cct3eKWMhSxWdV/kIYlHL4VXpZk8zLciCp4aUgrfxLYgB6mgIFBK/Fhm7nX CNKkVkgexkuStji+E/EvVfP0jysGl6nQxJWjaK4BTaIz5ERhzdjU16LM0JkNR+bGt2zrNwzfAAAA //8DAFBLAQItABQABgAIAAAAIQAyGSTO+AAAAKsBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhABdLaHu6AAAAKAEAAAsAAAAAAAAAAAAAAAAAKQEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACVGREEHAQAAygEAABIAAAAAAAAAAAAAAAAADAIA AGRycy90aW1pbmdJbmZvLnhtbFBLBQYAAAAAAwADALoAAABDAwAAAACwAB4E/QUAAFBLAwQUAAYA CAAAACEAR3I7tfsAAAC7AQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kMtOwzAQRfdI/IPlLYqd skAIJemCxwoBi/IBlj1JLPySx6mav2eSFglQ1dVoHnfu0W22B+/YHjLaGFq+ETVnEHQ0Ngwt/9y9 VPecYVHBKBcDtHwG5Nvu+qrZzQmQkTpgy8dS0oOUqEfwCkVMEGjTx+xVoTYPMin9pQaQt3V9J3UM BUKpyvKDd80T9GpyhT0faHwkITlnj8e7xarlKiVntSoEKpetPKvL4PCCcB/MP7rqRCZIuT7H0Sa8 OTm8UzTZGmAfKpc35YlDmowSHQ1f1Ryn8qfZiMvgZ/xj31sNJurJUyYiZUCqK4p34pfRD5Nco+++ AQAA//8DAFBLAwQUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETv gv8Q9m7TehCRpr2IIHgS/YAl2bbBNgnZKPbvzdGC4HEY5s1M3b6nUbwosvVOQVWUIMhpb6zrFdxv p80eBCd0BkfvSMFMDG2zXtVXGjHlEA82sMgUxwqGlMJBStYDTciFD+Sy0/k4Ycoy9jKgfmBPcluW Oxm/GdAsmOJsFMSzqUDc5pCb/7N911lNR6+fE7n0o0LyaA1dcPbPlLEYe0oKTORvYyGqIu8H2dRy 8bf5AAAA//8DAFBLAwQUAAYACAAAACEAhXfTTswCAADlBwAAIQAAAGRycy9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxLnhtbKRVwVLbMBC9d6b/oNEdnJgkBA8J09LChUKmCb1vZQV7kCWNJNzk77uS rDCEMOO0FyeWdp9233trXV5tGkFabmyt5IwOTweUcMlUWcunGX1c3ZxMKbEOZAlCST6jW27p1fzz p0tdWFHewVa9OIIY0hYwo5VzusgyyyregD1VmkvcWyvTgMNX85SVBv4gdiOyfDCYZA3Uknb5pk++ Wq9rxr8p9tJw6SKI4QIc1m+rWtuEpvugacMtwoTstyW5rcZukRi3qp3gX2S52lAS4k2LO0M6RwrY UpREQoMLvzC0ZiBIiCfIGFnxjQthVq8M5z5BtrdGL/XChOz7dmFIXXq0DoVm3UYXFl4lhuGfbC/9 KSFBsVmbZn4JBbJDNjOKIm79E5OgwCIIi4vsdZVVDwdiWfX9QHSWDsAKdoei/jp29L6dPLWzR8pw 117MAcS4U+zZEqmwYc9D7JPdtwnVN+/P0RWJmjivByXK1KhclKjLiqGBppRtA9Wp/h1Bk0l+MRpE mvLz0eRs+parfDA+D/uesfF0PBzn43DIK5I21t1y1aAnLJZhOPNaQwHtnXW+CyhSSJAuVqILt/mq yq2P/I2/qL/32Ixy8FzFKoR1S7cVPMiHJEOBDOADgwX4ueTy5HGJc9m4a8EB57aT2s2vRc2eiVOE l7UjP8A6bkhgDKcYIX1ZLhQXILksF2Dg5x5yV36oO9WLtEbBP5b97L3s3nwLAYxXSpRYSu47xLlJ +v6TAzxxewbAKUKLJ/v0N8JofI7foTAuh3wwGQwvpn7/Ix8EVqJBE1FHCYv2JKIVOwX/U2hPd9DZ vhHae9E7KD7SkYGtI7y15EzhV03wlose8EHqI+BXVW36o5/FUenN1416Ma7qXfzoWPh6fRAdP79H j1jwVLww8K+/YsLICPMD9EMbOsbLFQf7OixpvE79wGLoa4jHSNfz/C8AAAD//wMAUEsBAi0AFAAG AAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAhXfTTswCAADlBwAAIQAAAAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAADAAMAyQAAAB4FAAAAAAAAHQQEAAAAAQAAACAA ug8UAAAAMQAxAF8AaQBlAHQAZgAtADYAOQAPAPgDp0QAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAA AAAAAAACAP+/YADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAGAA8AcgAAAA ////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAAAP///wAAAAAAgICAAAAAAACZ zP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA////AI3G/wAAZswAAKgAAGAA 8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABgAPAHIAAAAACAgAD///8AAFpY AP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwfAADf0pMAzDMAAL55YAD//5kA 06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/AP/nAQBgAPAHIAAAAAAAAAD/ //8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A////AHd3dwDR0csAkJCCAICe qAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBmZv8Amcz/AP//mQBgAPAHIAAA AFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4AAAABAP/9PwAAACIgAABkAAAA AAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAABAAAA//8sAAAAAAMAABAAow+AAAAABQD/ /T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP//7wAAAAAAAQAAAP//GAAAAAAB AACABQAAEyDUASABAAAiAP//FACABQAAIiDQAkACAAACABIAgAUAABMg8ANgAwAAAgAQAIAFAAC7 ABAFgAQAAAIADgAgAKMPcAAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAIA AAD//+8AAAAAAAEAAAD//wwAAAAAAQAAAAUAACABIAEAACAA//8ABQAAQAJAAgAAAAAABQAAYANg AwAAAAAABQAAgASABAAAAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAACAB AAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUA AGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEA IAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACj DwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABQAAQAAAAAAAAACABIAAgAAAAAA AAACABAAAwAAAAAAAAACAA4ABAAAAAAAAAACAAwAgACjDz4AAAAFAAAAAAAAAAAAAgASAAEAAAAA AAAAAgAQAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAMAAQAAAAAAAAAAgAKAAAAIwQYBwAAUEsDBBQA BgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbHyQy2rDMBBF94X+g9C2 WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrvndhhJhtDK1eqlgKDib0NYyu/ N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG3gwxeyjc5lEnMD8wor6v6wdt YigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31Rl9HRFeEu9P/oqhOZYuXynCab 6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvtotp4zUSkjcV1QvFNnRn9Meom+ +wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE 74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2NU/iSZGtdwqqogRBTntj3aDg dj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKMXPhALju9jzOmLOMgA+o7DiS3 ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6IycKGYsxoGSAhP521iIqsj7QTa1 XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAAGr3IroAwAAPyYAACEAAABkcnMvc2xpZGVNYXN0ZXJz L3NsaWRlTWFzdGVyMS54bWzsWktu2zAU3BfoHQRuA8eW/JFsWA6SFFllETTJAWiZstVQlEAxadxV kRyhN+i+aIEW6KJZ9Sj1AXKFkhRlS7bsqkaC2LB2ivkROUO9N8OX7sGtj7UbRCMvIDbQ92tAQ8QJ Bh4Z2uDy4qRiAS1ikAwgDgiywRhF4KD3+lU37LDbczbGKNL4FCTqQBuMGAs71WrkjJAPo/0gRIS3 uQH1IeN/0mF1QOF7PrWPq0at1qr60CNAjadFxgeu6znoTeBc+4iweBKKMGR8+dHIC6NktrDIbCFF EZ9Gjs4sqSe25zGM5A57XdjBN1gPz6gG8ZDj5DAKNMqwDQRe8JQc0Sv57AaEHcoufRghoI0gGfL9 nl0Th4kOYqoodI6Qq57OHKbdQDlRtdetzrUeumxFP9U6QO5bvrLogw0ajZp6R4C9wYmHsRwu+EDH mMZvYrcGUO9K9xIgEo2NQ+RChzO957+rYCZ6wg6CqYbHhy+PD9+1x4dvk7sfk7ufk/v7yd1XoDkj SCMktykHOdF/D+L7j3cjoVCYiwXwR2O34D+kHsRACz3mjE6g7+GxDSp6rb2I84uRIxhR5NRLcjaM HMGIIqdRkrNh5AhGFDnNkpwNI0cwoshpCXJ8SE95am2aXLKAPAEwl/TF2C3J8UWTzEJeFsAojMwZ Rm1dCpASIylYBDAKI2uGkV439VZ5kBKBJ5BRILVTIFmGZZUgJSAJZPhz1pOEnX4wGC8YlDha1RtG W+DnkQE3OFw5Jj/E/oULy6d1Lzw08tet62D618fcO0gDYYM/Hz/HpiPla4xivkZPVrDa15DN8zUx ayZnrZlmzbCapvhhG1j7tMiaOBMyG6b5kLcDaTf6PKytMk4V3bDUUcnazXlHE9Oi64262MrsazIM KxXDt+hr2io25i2MYoMjL5XYNLZtExuLX4lUA1vFy7x7iXkxak1ThOlt/Ep+/1oIXvpLppy1gle+ bzGaekPGqn9/LoV9zBNm+xzkxezblTby3ZDRNnUpYkvki1wfr3Xm8z1WLHYLhaLyzK++Y14qlfKN W92yWgWTc4n8mshP3WDK/4WdgI0QnbpBLmvPYmOtXBTmhSgbIFK5PJ8pX9UlqW3FeTxtN/jgC9g/ F5Uldf21YBt1oMnK0awGlq156TKUq1WIGlUcE68QFfVGcVaeW/vs+aSCYJzgMzUp0eBEMzh4FS1x 3KLWJ9aV1J1iaBIQpnZsZ/HJN0rZ+z9ui3YWnyXWJXv3t8sA5XsIPXvvt8sALVHz8uKhDNE8Li8R 3WajLgVIGaOXaGOOjrTpJUBLJGyraWYv93Y2i02VZlpcijKE+s+v3l8AAAD//wMAUEsBAi0AFAAG AAgAAAAhAJsTBbv6AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAAavciugDAAA/JgAAIQAAAAAAAAAAAAAAAAASAgAAZHJzL3NsaWRlTWFz dGVycy9zbGlkZU1hc3RlcjEueG1sUEsFBgAAAAADAAMAyQAAADkGAAAAAA8ADAQvHQAADwAC8Ccd AACgAgjwCAAAAAUAAAAFqAAADwAD8MscAAAPAATwKAAAAAEACfAQAAAAoBpZYQAAAAAAAAAAlP9p IAIACvAIAAAAAKgAAAUAAAAPAATwLgEAABIACvAIAAAAAqgAAAAKAACDAAvwSAAAAH8AAQDvAYAA yBFpIL8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABl ACAAMgAAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAAIA/78PAA3wngAAAAAA nw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25k IGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAA DQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8NUIAAASAArwCAAA AAOoAAAACgAAgwAL8FYAAAB/AAEA7wGAAMjfqSW/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwyYA AAC/AwAAAgBEAGEAdABlACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANAAAABMAIvHXBwAAqcPR BwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7D MBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+W lVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5E sO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98Ou OJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92 K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJl bHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZ sniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo 1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gq BvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCp 2UM+bgMAAPUHAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxVzW4TMRC+I/EOlu+QpE1LidiitlBAClVE ijjP7nq7S7zjxfamSY/leRBIIHHp2/QB+grM2Jum/AgBpYdmvJ7xfPN94/Gjx4tai7myrjKYyMH9 vhQKM5NXeJLI18eH93akcB4wB21QJXKpnHy8e/fOo2bkGkHB6EZNIkvvm1Gv57JS1eDum0Yh7RXG 1uBpaU96jVVOoQdPiWrd2+j3t3s1VCh36SicT5uJZSs7mk+sqPJEbkuBUFPKJ+CVmGjIVGl0rqwY yl7nGqOAoIxNNnMdHvgTPLmFUyryOygCzTNL1Qw4QS+AWeFCgsVJm1L4ZUOock/EnFEm0IUkwItE bnRh0Zfi12U5Kk+kpy9NTqHQekNlw2hR2Pq2mPkcUxSC8g+3HhCtUiyJvK3N4WCrz4BgpBZeZIxv sLm5zQ4ZeQwfbG9Eh14Ewp6Ndf6ZMrcGJfigRFqV+VAozMfOM6frFJxO4/+ovq48NYWu6kTu9Pkv Vl0qyJ9iHhjwUOloEwKNQVyWhBX1i32TLxlOSr8kU2zqf28iuk1Ue2nsmRSnFqif3LsWrJJCv0CX yIeD4ZBE8GERNJPC3txJb+5gWx8YzT0pADM6NZHUedE88LRiPU3dgB/jtMnYcaXk8eIN2KbTwlMX HJlpCY36lSTRNygUaQj6OD/1S61uS0k4a64HgXEY5ap4NbGxHfTqMwvTpQv4/0dOvnQ12HEgiYxX waCU4bfCnAZSMEGf0PTTUhC0Y0indK+DSsSt9dFbwRj37SwIURj0eyEkBce60lTDbptCSsATGi2T FjM6PuqhWRwuzDXZJPNiDqzpdbuGtlx77KviR9/Q1eRG8evdvcL/xq/bTdsDbY8X4SKk7fTs2jyk Mq4XRzTeu7uSxsv6vVCddgrzCVgg/cSsravavK0iqVRzIhXeez2Nc3Ew5EmTRqbD/zaRSEn4PbHV jOYgmmmwpJgpy69PmF4Z35jOkfuZTkF+R3R1pp6HJZOuK36Nwt7EGlOwzVTw5YYRmsNK667Dwhdn dJXzx8AXP1OKWIky+EUc+ETuTS9VFDS/Vly0Y+y4avmYzg7KhxehoPcpkXu2AmqjrATrVOitwKmC Gz5XFx+uLj6Lq4tPl+dfLs+/Xr5/f3n+8eegzP11EPXHWqA4bsOsW804epNcs/sNAAD//wMAUEsD BBQABgAIAAAAIQC0vpUA1QAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/dSsNAEIXvBd9hGcE7 u6k/wcZuSxFEQbxo7QOM2ckPZmfT3UmavL2LF3p5OIfv8K23k+vUSCG2ng0sFxko4tLblmsDx8+X m0dQUZAtdp7JwEwRtpvLizUW1p95T+NBapUgHAs00Ij0hdaxbMhhXPieOHWVDw4lxVBrG/Cc4K7T t1mWa4ctp4cGe3puqPw+DC6dLPUwvk+7u9P9w8dxPq1Wug5izPXVtHsCJTTJ/3jweYX+r/xFvVkD Oajqdf4Krd1jFAoGklsyTZagNz8AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMA AACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAqdlDPm4D AAD1BwAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQC0 vpUA1QAAAPkAAAAPAAAAAAAAAAAAAAAAAMQFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1 AAAAxgYAAAAAAAAQ8AgAAAAUECABYAZAEQ8AEfAQAAAAAADDCwgAAAACAAAABwH/vw8ADfBYAAAA AACfDwQAAAAEAAAAAAChDxoAAAABAAAAAAAgAAoAAAAA/wcAAQAAAAAAAgAOAAAAqg8OAAAAAQAA AAcAAAAAAAkEAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPAYCQAAEgAK8AgAAAAEqAAAAAoAAIMA C/BaAAAAfwABAO8BgADIW2IfvwAAAAYAvwEBABEA/wERABkAPwMAAAgAgMMqAAAAvwMAAAIARgBv AG8AdABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA1AAAAEwAi8RIIAACpwwwIAABQSwME FAAGAAgAAAAhADI8vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFBTsMwEEX3SNzB 8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBaX5aVVkg2OE99 rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm3kSw79Cjuaqq a2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3w644mpVC7sN5 8JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+b3Yr2AvO3+lm /0PNFwAAAP//AwBQSwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8ucmVsc6SQsWoD MQyG90DfwWjv+ZKhlBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcwqZmyeI4G1k0L iqJl5+Ng4PP08foOSgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0nCjWSc85YKlt HnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFXmCoG80DFgMvy m9bTmlqgH5s3T5odf8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAhAP/RnueoAwAA 7AkAABAAAABkcnMvc2hhcGV4bWwueG1s7FbNbhs3EL4X6DsQvCf6iWQ7QtaBbdRpAMUQIgU9GrO7 XO9WXHJLcmXJR+d5ihZogV78Nn4Av0JmhivLbouiiXPooXvQDpdDzjfzzY9evV7XWqyU85U1iRw8 70uhTGbzylwk8sPi9NmBFD6AyUFboxK5UV6+Pvz2m1fNxDcCDxs/aRJZhtBMej2flaoG/9w2yuBe YV0NAZfuotc45ZUJENBQrXvDfn+vV0Nl5CFeZVbzZuZIys5WMyeqPJH7Uhio0eSptUE5MdOQqdLq HOWx7HXK8RwgmKnNlr5DBP8GUe7gEt18BEYY+8ahPwMy0GM4W2QGgZHRphRh0yCuIjiMzVUif2rB IUKJsNeJfNEdjfp4x845j06K9PKdzfE4tMGi8zBZF65+Km66xxaFIPuD4QijK8UmkXvjF6PBuE+I YKLWQWSoMDx4Od4jhQw1Rvt7w6jQi0hIs3E+vFH2yagEXZRIp7LAnsJq6gMFdmeCzGnzNdyvK8oS XdWJPOjTE70uFeTfmZwjEKDSUUYE2jDDxAnRGtbHNt8QnBTfyFPM7S/PJCwq9L207kqKSweYVJ4S RUmh3xqfyJeD0QhJCLwYjfeHuHAPd9KHO6atT6ymxBRgMrw1kWErngRcEZ+2biBMzbzJSHHL5GL9 A7im4yJgFpzZeQmN+jtKoi4zFMPA/PgwDxutnhoSvmulBxxxmOSqeD9zMR309jMR05lj/F/DJlVd DW7KQULhPQtokt+VybEvsQj6AptgRnWN4BaQzrG6mSfiJkR9BVNz7JZMRWFNOOJDKXhiFtub6bbx SAnmAjvMrDUZGoiMaKKHXPNNNsuCWAGxep+wnJg7jWNV/FmX8xrV8Pxu96gI/6DX7abtiXaLNZdC 2s6v7sVTdON+cYZ9vquWNJbrY6o69rBoYOIwssu2rmr7YxWDih4nsgrP3i5ibxyMqNOkHK2o0ibS oAkaK65aYiM0ds6SFEvlaAhx98qoYjpFyme8xdA40dWV+p6XFHJd0VDivZmztmA5r1zA1oZffR1O tAK8tM/ZTjUPE2NPK627xOMv3uoqp48cRBpiCkMVuQnrOAww4g+1VFFgW9sGqJ2aLoAtXdPJnA48 LQqcXYk8chVorNMSnFecchxoBQ907m5+vrv5Tdzd/Hp7/fvt9R+3Hz/eXv/y10OZ/+xDmDRIGLkY DkV8zsX5uaB+jOlD20wq//y3mSWI/5O5I/MRhUhkw7NtO9PwT4hvDj8BAAD//wMAUEsDBBQABgAI AAAAIQD9AqKn1gAAAPkAAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LSgNBEEX3gv/QlOAmmJ74zphO CIIoBBeJwXU5XZkZnO6edFfm8fcWLnR5uZdzOYvV4BrVUUx18AZm0wwU+SLY2pcG9h8vV4+gEqO3 2ARPBkZKsFqeny0wt6H3W+p2XCqB+JSjgYq5zbVORUUO0zS05KU7hOiQJcZS24i9wF2jr7PsXjus vTxU2NJzRcX37uTkZKZP3WZY3xxv797343E+12VkYy4vhvUTKKaB/8f9hMPn5K/8Rb1ZAw+gDq/j V6ztFhNTNCBuYiqWoJc/AAAA//8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAA AAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEA AAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAP/RnueoAwAA7AkA ABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEA/QKip9YA AAD5AAAADwAAAAAAAAAAAAAAAAD+BQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAAEH AAAAAAAAEPAIAAAAFBCwB9AOQBEPABHwEAAAAAAAwwsIAAAAAwAAAAkC/78PAA3wXAAAAAAAnw8E AAAABAAAAAAAqA8OAAAASUVURjg3IGkycnMgV0cAAKEPHgAAAA8AAAAAACAICgAAAAD/AQAHAA8A AAABAAIAAQAOAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8GAJAAASAArwCAAAAAWoAAAACgAAgwAL 8GYAAAB/AAEA7wGAABjmqSW/AAAABgC/AQEAEQD/AREAGQA/AwAACACAwzYAAAC/AwAAAgBTAGwA aQBkAGUAIABOAHUAbQBiAGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADYAAAATACLxPggA AKnDOAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyU kUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9 oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNk OabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glw JvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+U cP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxz Ly5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32 lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0p oDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx 0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAA ACEAJpJNJdQDAABQCwAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1u4zYQvhfoOxC8e/0nO7GxysI2 4u0CbmCsXfRYjCQqVk2RKkk5dopess9TtEAL9JK3yQPkFTpDykm2LYq2yaGH9UEeivP/zY9ev9mX ku2EsYVWMe++6nAmVKqzQl3G/Kv1vHXKmXWgMpBaiZgfhOVvzj7/7HU1thVDYWXHVcw3zlXjdtum G1GCfaUrofAu16YEh0dz2a6MsEI5cGiolO1epzNsl1Aofoaq1G5VLQ1R6cVuaViRxRwNKyjR5EoW mWAXdZkIw5YSUrHRMkN6yNuNSJAGdGmh061t/IJ/4ldm4AqD/cglpvRbg1F1yUDbO3X0T6F7ZLTa MHeo0DsrM3QNk3Qd8+9qME4Yjv7vYx410kEE1TxGaTFallx9qTPUALXTmAUY73NTPtd10qPznKH9 4WDQxzRzdiC6H3UHHfIIxmLvWIoMvW6/PySGFDmik2EvMLSDJ8RZGeveCv1srxgpirkRqfORwm5h HeX20QSZk+olwi8LxIDJosQa6tAvRL0RkJ2rzGfAQSEDjR5I5UEmTAhZt5/q7EDuJPiPOIUi/+/F hN2FsW+0uebsygDWlaVCEZzJd8rGfNSNIgTB+UM0OOnhwTy9SZ7eqLqcaUm1yUClqDXm7kjOHJ4I T11W4BZqVaXEeERyvf8aTNVg4bAKLvRqA5X4K0gCr0copMHjY93KHaR4bkq8rp3s+ozDOBP5+6UJ 5SCPrwmYxpz3/yVsUteVYBY+SUi89wSa9P+FynBAeRLkJU5DbGR0bQ3JCnvbo0TIuMAtYKGmZuuB yLVyEy+SgCVcccqp5hpFNqAuccQsa5Wi+oCHJHAoMFuly9SxHRCmD+Xqy/KRYyryP/L6qkY2lH+8 neTub/ia26SeSbPe+0ZI6tX1AznHMB4OFzjum15JQrN+DFSDXS4zP62/706n89lsOGsNOp1J63Qa nbdGo/OTVhSdjubzQa8/GXV+wCpvhiaOdKxkX3kGUdnWZVHqb4sACOYr5oVrvVuHudqNaEolASX/ rGOu0EHaTabY4hBVeuUpzrbC0Cbzky+lbmsYqRdQi6KdJItr8YU/EmCyoM3m75ZG65xoSiMNBhgr PS+kbKrTv7EaNxK99LmmlScwowFCtw9LA4F5yiXyHGffMY/1QjV5rklNQ/uq8QnKccfFfGIKkNjM GzBW+Lr0eAh4wnN/++P97S/s/vbnu5tf725+u/vw4e7mpz8LpfZfC2FtITIU4qe2oSy8aNu4s29o +WG34hN7iAwIlS3BAI7CT+2A6fj/tcMjQOHLxX82HD8X8PvOVme/AwAA//8DAFBLAwQUAAYACAAA ACEAE/8P2NYAAAD5AAAADwAAAGRycy9kb3ducmV2LnhtbESPy27CMBBF95X4B2uQuisO9KGSYhBC qlqBWEBhP8SDEzW2g21C8vcdddEuR3d07j2zRWdr0VKIlXcKxqMMBLnC68oZBYev94dXEDGh01h7 Rwp6irCYD+5mmGt/cztq98kIhriYo4IypSaXMhYlWYwj35Dj7OyDxcRnMFIHvDHc1nKSZS/SYuW4 ocSGViUV3/ur5ZKxvLabbvl4eXreHvrLdCpNSErdD7vlG4hEXfp/Nutjtln/hb+oT62Ah58/+lOo 9A5joqCA3diULUHOfwAAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAA AAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAAL AAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAmkk0l1AMAAFALAAAQ AAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhABP/D9jWAAAA +QAAAA8AAAAAAAAAAAAAAAAAKgYAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAAtBwAA AAAAABDwCAAAABQQIBBgFUARDwAR8BAAAAAAAMMLCAAAAAQAAAAIAv+/DwAN8GwAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQA AAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwPAAAABIACvAI AAAAAagAAAAMAABjAAvwJAAAAIEBAAAACIMBBQAACL8BEAAQAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTzgAAAA8AihMpAAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADIAAACLEwkAAAAAACQEAQAAAAoPAIoTlQAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixN1AAAAAADrLggAAABKyccB4Ix4vwAAHRAEAAAAAAAAAAAAACsEAAAA AAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAD/////EgAAAA8APfEN AAAAQAFC8QUAAAABCQAAAA8AAisAAAAAAAAOBMYOAABQSwMEFAAGAAgAAAAhAJvocE/8AAAAHAIA ABMAAABbQ29udGVudF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroopdjOoo9dH4v0AwZ5bIvY IyFNQvL3HTsulBIChW4E0sy998yoXB/GQe0xJuep0qu80ArJ+sZRV+nPzUt2r1VioAYGT1jpIya9 rq+vys0xYFKiplTpnjk8GJNsjyOk3AckqbQ+jsByjZ0JYLfQobktijtjPTESZzx56Lp8whZ2A6vn gzyfSESu1eOpb4qqNIQwOAssoGaqmrO6iEO6INxT84suW8hyUc7mqXch3SwJ77Ka6BpUHxD5DUbh MCxD4s/zFUhGi/ll5jPRvm2dxcbb3SjryGfjxexPAKv/if7ONPPf1l8AAAD//wMAUEsDBBQABgAI AAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPRfVHSwxgldi+lkEMv o30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4 cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS 1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwME FAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxN CsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8 LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF 6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAI/YGDNRCQAAfTkAABYAAAB0aGVtZS90aGVtZS90 aGVtZTEueG1s7FtZj6NIEn5faf4D4r2nOAyGUrtHnJqHHc2oq0f7uKJsbDONwQL6+vcTkZdJgxO7 Cm3Pqm1LXTgJIiMj4osjk377y9dDqX3Om7aoq5Vu/mzoWl6t601R7Vb6nx/SN56utV1WbbKyrvKV /i1v9V/e/fSvt9ljt88PuQbPV+1jttL3XXd8fHho1zCctT/Xx7yCe9u6OWQd/Gx2D5sm+wJ8D+WD ZRjuwyErKl2rsgOwNa3/Fnm3feP6+jvOOimBf9W1OLAumydknDN6RqyZhHzz0USittk9R2Wjfc7K lW6Qj/7w7u1D9sgIym5Il5IPo2MEm4/WFD9CUHZDOs/Ar+BHCLL1GhYynDsMEyOxGW2PiF4Oedvw 8X2JvsffHsgsrY0yJUT0cjGgl3TWI6KXzoA+DpI4SSV5CBGldwf0VmzFXiDRE6J9WVQfB9SG4cOH UQuSbV3+Okru+1FkcMWfqMD6wnlwim1ddWOupOPNQ/ZX3aRAgT/KrCsqrft2zLfZGnw0aIqsRHGy xzzrjdOhdXs2BBNL7A5FNSvvEzuY6bQqssaDvMTft9tinZMVbouyfOq+lfm/W7LIti6LTQqD+BzB bi4gdNzDJdO/RLdrMvKM1tTdf4pu/7TPjghiMsOuZax3rXasW0AiGR7ljZOCkjsKWQf9j2qzzbrf 6g0dtvtIFmwIrnckOPCJbGRw7WT28nWTmVSqi2qTl2YS0YjvSEsTSwYbDpcGg0Kb4PNahkHZdCF6 ouxau87KfIN6p1GOmwWn5tczm4itmi5kn21yaiJpuGc6k9iOuxAJ4OBSI6a7TZtCa6C0aSGIW/DA 8GIlcwZcsWQR52gqqz62ykr7stJ9x3J0bZ0dV/oWQgpcHo5gtLba6VpW7iDrrruGeu0kFom3nVbs j3uVafDxgVdJMD42bRdn7Z7akNxipiornInKbzkLdLZ5FkAd9QVS2B64yHeTAvQomzbfbvN11zd2 bwR1R3+ySFh/6vLmab/5oj2Xn5r3GZgfdIrr2RRtt9IJoPFHs9JR2+SWHFtZXBupcHC2rDzuMxYt PXya6ZmSE1cVMpBfPfFgbaOyk8XdvhRE/FxL6bvxD7YUTAd5ldsbtMAaauQm0xCvK71uun0NUei4 L9ZpA7UKiR3gLRpEF8y2GlTq5G+Tf8a/1BcoD+RWFrt9977YaU0B6aTbN3n+B4Ql4n0TzEyWeihL zoh4VE/c9kjFfs4/5+UHjIEuxmBd24Ork2jC3JPQnfuf/Jsh6HmHNUofb1IMEVGdYuB/XbhQMMOi wGq97DeReDC50wqJPk8e5zmyvxC8caqSFhwVUvLzfQb7F4pwTQLu5VoasQYrthwuHFhRGIX4B5Zq MCjqmWPW7TX8B/Jf0azLU3n6oX4PsVWDHg6ZgduAV7/BqAaXGCDp1TPUPXSQOhOyojOw4hS1xpP1 zFWQmPdM2SgZx9tw9Sd736hsUUTJ00lYHE73cmUzDUu6pmMXVQ2TnUMUhra8DyGGIfsF/aa+fv4L DB1De/WppG1+e4RfBAfHPxriXc/15hu7LFuacKnXYQ+DlGX1Pt9qxeYr7z+EJiiEaC/KS2RCjY9h 5SYetMeaBvlBRo+P0mwpHramHxZPkJkhZIuHSVM4xgB2IljgxtYO6IkKW7pqUK3QVFm9RmVXCD+u stE+61qV0UZRaagXqKz7qlYZ0xQob+h4+deuyaA1eSLxlyUdeRBtt+YU920ovjFDbW6hdujlfRsq Ekng8jYUeNJv2VF73pkrHbGugfeudNin1GHMwjELx+AKNiOhUaQ7iCudQ4yNwH1mAE5j8xGbjyz4 yIKPOHwEGlP6uMtHXKjScHsN9nPxj67xJUD3ynbeWFwaomM4cgkvNOz8k7ZtfRe/bGlsX5fpGl1b 2lpOwzh1bti2TVPfdzlvZq7viZc0TqJQll+5bZssvcCJmG6Yv6D8Yk9W0k4U2VCwMGpBwp1noExU jSA/UUGUFs6Dz/zYeKEFyj8JL7ccc+DOfCofE5CzkB4UzjxoQP9d80sUJNaZ/Eq8hH7oJ8tr8YKH OhFH1zRegtRdCmHueBk/FlyQkvo1eIFzLTfl9eQMx4I35Zf+kWQvCV3CixdHrnCJHhG9HNZjSZQG qeyfhIjSv/5YcOTYUYmXZRra1+MFjo7dG/BiGAG06wyMd7yM48V5NV7Q5jHvCWbAy5J8mNmm6jGc XPZnZX7BeCs86Aq8IPuEr60HqlnxEkj5QokXK8YMI9ErjtHT1IHzIEY9nV+wWL3jBd40YVUn3RE4 6/ddBV6cwPGYtlkCYnCQahz0KRGzlXjpvU7C3ksZe+0EuYmXJSbwAhF04VqS/yjx4sZuGsn4UtZj QRAZEfe4K/ASB/iV5CFJiD5KoCDpLghCL5TlUeLFtdxFuJD4K/BiGD3LTOMFyW/EC+noSb8Phmf9 PrgK6/fBeLwrhx0BqgO4Ry/+T/v95UW8OJF5Ut8MeCFb89z3FHiJ09jyeQ88gRepo2UGwejATDJo acNk6btchh4RvRzWY5ERwEfyT2U9diteEgvgJfNX4iWI3NiR9ysUeJEizzReYjuwTJ68rqvHfjy8 eBfxYhi2LfaSZsALnliJvKHAC3bkvXzVi//D1xpRwrP6SplfDCM8nZtdgRdESyT786x4CeLQS+T8 qMQLaPAUw6j8CrygboQmp/ECpefSMFlwuONlvH+hbw0zOEi1Avpiz7+JH76uHkPEMHMo8JLYSdjb P1DiBTEtZKT+o8TLwvWCRSjlix7/YX5BvJzF/3nxEgTxGR6VeLHTZbzguXd2vBgJnFXf8ZKr+heT Ht+OAUZqvGdIMK7nhk48DZjYjM2IO/VEQeYbvuHJAVoJGM/wk4A3ZVckGGivg1AugGYFTOTCl8d0 Ko8SMEvbS31ZfkWCSdMoEiXCdIJJ/DgSuwn3BDOeYMzL/9HEhlAvTsfmAIwrZSwS2RkepMyG9Zio IyYA4xqOv+TguiLDgAiu4H0NYLzQO8sAswImhBgSyidISsA4kRNdv6MsnU9NAwbVLtL1HTAXAHP5 iB/+F5BhOiIjvLokcyw7sXi0VpRkcRoZHs9EE4DxomW45FXEFYDxUie1ZAdVlmShHaQBP/Sj/GcF TARwCWXAKwHjmY5jyS2VIsNEUQivrDILTgPGiyD9cvIfCTDwEoP8Tgx5sQxGyauQ7/4GAAD//wMA UEsDBBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5h Z2VyLnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02PyRR7O0NriwILodhvplp u5edyRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0VZ5FLKE0mJFIoLjGYcg4nSpOc 0IpU+YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa/7P9OBqJZy8fFl3+UUFz2YUF KKLGzOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEAm+hwT/wAAAAcAgAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYB AAALAAAAAAAAAAAAAAAAAC0BAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoA AAAcAAAAAAAAAAAAAAAAABYCAAB0aGVtZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAG AAgAAAAhAI/YGDNRCQAAfTkAABYAAAAAAAAAAAAAAAAA0wIAAHRoZW1lL3RoZW1lL3RoZW1lMS54 bWxQSwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAABYDAAAdGhlbWUvdGhl bWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAAFMNAAAAAAAADwQ6 AQAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/ Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9k cmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRr MiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIg YWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxp bms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAA0rBAAAAO8Bw4wAAAsrEwQAAFBLAwQU AAYACAAAACEAMhkkzvgAAACrAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWx8kM1qwzAQhO+FvoPQ tVhyeyilxM6hP9BL20P6AIu0tkX1h1YJydt37aQUSshp0a5m5mNW633wYoeFXIqdvFWtFBhNsi6O nfzavDYPUlCFaMGniJ08IMl1f3212hwykmB1pE5OteZHrclMGIBUyhj5MqQSoPKzjDqD+YYR9V3b 3muTYsVYmzp7yH71jANsfRUve14fSVguxdPx3xzVScjZOwOVQfV81Wd1BT1dEO6i/UfXnMgUKxdz mlymm1PCB1dTnEXxCaW+Q2AObQvp6gI39BaHpC6TnglMw+AM2mS2gUtQuSDxXLKDV3/Ovwx6qbr/ AQAA//8DAFBLAwQUAAYACAAAACEAF0toe7oAAAAoAQAACwAAAF9yZWxzLy5yZWxzhI/BCsIwEETv gv8Q9m5TPYhIUy8i9Cr1A0KybYPNJmSj6N+bYwXB4+wwb3aa08vP4omJXSAF26oGgWSCdTQquPWX zQEEZ01Wz4FQwRsZTu161Vxx1rmEeHKRRaEQK5hyjkcp2UzoNVchIhVnCMnrXGQaZdTmrkeUu7re y7RkQPvFFJ1VkDq7BdG/Y2n+zw7D4Ayeg3l4pPyjQmbny7COhlCoOo2YFdjEi3tV/gXZNvJrX/sB AAD//wMAUEsDBBQABgAIAAAAIQAlRkRBBwEAAMoBAAASAAAAZHJzL3RpbWluZ0luZm8ueG1sjJFB S8QwEIXvgv8h5G7TioiUtntZPHmS+gNCMt0NNDMhmXXdf++0WwXxsqeZkLzH91663Vec1SfkEgh7 3VS1VoCOfMBDrz/G14cXrQpb9HYmhF5foOjdcH/XpZZDlFdKDLC0ttdH5tQaU9wRoi0VJUC5myhH y3LMB+OzPYskzuaxrp9NtAH1ps+36GmagoM9uVME5KtJhtmywJdjSOXHLd3iljIUsVnVf5CGJRy+ FV6WZPMy3IgqeGlIK38S2IAepoCBQSvxYZu51wjSpFZIHsZLkrY4vhPxL1Xz9I8rBpep0MSVo2iu AU2iM+REYc3Y1NeizNCZDUfmxrds6zcM3wAAAP//AwBQSwECLQAUAAYACAAAACEAMhkkzvgAAACr AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAX S2h7ugAAACgBAAALAAAAAAAAAAAAAAAAACkBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAl RkRBBwEAAMoBAAASAAAAAAAAAAAAAAAAAAwCAABkcnMvdGltaW5nSW5mby54bWxQSwUGAAAAAAMA AwC6AAAAQwMAAAAAwAAeBDUGAABQSwMEFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAABbQ29udGVu dF9UeXBlc10ueG1sfJDLTsMwEEX3SPyD5S2KnbJACCXpgscKAYvyAZY9SSz8ksepmr9nkhYJUNXV aB537tFttgfv2B4y2hhavhE1ZxB0NDYMLf/cvVT3nGFRwSgXA7R8BuTb7vqq2c0JkJE6YMvHUtKD lKhH8ApFTBBo08fsVaE2DzIp/aUGkLd1fSd1DAVCqcryg3fNE/RqcoU9H2h8JCE5Z4/Hu8Wq5Sol Z7UqBCqXrTyry+DwgnAfzD+66kQmSLk+x9EmvDk5vFM02RpgHyqXN+WJQ5qMEh0NX9Ucp/Kn2YjL 4Gf8Y99bDSbqyVMmImVAqiuKd+KX0Q+TXKPvvgEAAP//AwBQSwMEFAAGAAgAAAAhAHDwONy+AAAA OAEAAAsAAABfcmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iCB4Ev2AJdm2wTYJ2Sj2783R guBxGObNTN2+p1G8KLL1TkFVlCDIaW+s6xXcb6fNHgQndAZH70jBTAxts17VVxox5RAPNrDIFMcK hpTCQUrWA03IhQ/kstP5OGHKMvYyoH5gT3JbljsZvxnQLJjibBTEs6lA3OaQm/+zfddZTUevnxO5 9KNC8mgNXXD2z5SxGHtKCkzkb2MhqiLvB9nUcvG3+QAAAP//AwBQSwMEFAAGAAgAAAAhAPeg7HcE AwAA7QoAACEAAABkcnMvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzsVttS2zAQfe9M/0Hj Z8C5mBA8JEybFl6AZJrwAUJWsIssaSThJnx9VysrTLhMA+WRF1/k1fHuOXsknZyuakEabmyl5Cjp HnQSwiVTRSVvR8n14mx/mBDrqCyoUJKPkjW3yen465cTnVtRXNC1uncEMKTN6SgpndN5mlpW8pra A6W5hG9LZWrq4NXcpoWhfwC7Fmmv0xmkNa1k0s43u8xXy2XF+A/F7msuXQAxXFAH+duy0jai6V3Q tOEWYHD2dkpuraFat/omi+nN74RgpGlgrJuMoXg2FwWRtIaBReUE3yMLvnJ7BJgiEyUdoGKc1QvD uZ8hm3Oj53pmcPpVMzOkKjxcC5Ok7Yc2DF8lhMFD+mT6bUSi+Wpp6vEJzYEYsholoN/aX2ESzSEj wsIgexxl5fSFWFb+fCE6jT+ADDY/Bel1qOh5Ob1YDrJCupuqQiiFqReK3VkiFdTpyw/lsasmgvma PbwuSauCJ7iNCx+RjxhvkdOY6IaJ7PAIWgzp6B1lg/5wm5Nhr3c88N89M91u1u/Ai8/lEUgb6865 qkF860aJ4cxrSnPaXFgXQmMIShQS0blbfVfF2kfewB10Bn/B/FKZh5CDsG7u1oKjSEAlzaFguECo oN54XO5fz8F4tZsITsGYraBuPBEVuyNOEV5UjlxS67ghzhMENgVIn7/DKhCSy2JGDf31BLlNHrOO 2QKnQdbXxe1vxPWdNROU8VKJAjLo+cLAFVHFd+ns2YKiH4AqKpYJ2AN6NzbIu4TvgsK+CZDo6Ias 0x9ulM8Oe4fHg/6W8shE6MFITpQSgZ7LBx1IRCM2Ov2nnD5TVNNuyQnSYrOES/wlEvSGDppzpmCR ErzhYgd4VPYN8IuyMrujI/FvQD9T98aVOyefBeV3luOsWr6IDkvphxopi0Zqt4otLyEn7/fSE/+g frhe+o7Gh38tnINsGFfOTwM9X4I/DfT69vSRBsJlOJye4NEfuHCLEeaS6mmDnoZDJux/ExzScKz0 +xqEPoZ4jHhMHf8FAAD//wMAUEsBAi0AFAAGAAgAAAAhAEdyO7X7AAAAuwEAABMAAAAAAAAAAAAA AAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAcPA43L4AAAA4AQAACwAA AAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA96DsdwQDAADtCgAAIQAA AAAAAAAAAAAAAAATAgAAZHJzL3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsFBgAAAAAD AAMAyQAAAFYFAAAAAAAAHQQEAAAAAQAAACAAug8UAAAAMQAyAF8AaQBlAHQAZgAtADYAOQAPAPAD WUMAAAEA8QMIAAAAAwAAgAIA/78PAAwEjC8AAA8AAvCELwAA4AAI8AgAAAAHAAAABzgAAA8AA/Ao LwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAjkGiJWlrZiACAArwCAAAAAA4AAAFAAAADwAE8O4I AAASAArwCAAAAAI4AAAACgAAgwAL8EgAAAB/AAEA7wGAABhKeR+/AAAABgC/AQEAEQD/AQEAGQA/ AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAATACLx/gcAAKnD+AcAAFBL AwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFOwzAQRfdI 3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpflpVWSDY4 T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabeRLDv0KO5 qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfDrjialULu w3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5vdivYC87f 6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5yZWxzpJCx agMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCpmbJ4jgbW TQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDScKNZJzzlg qW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeYKgbzQMWA y/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEACbYjiJED AACxCAAAEAAAAGRycy9zaGFwZXhtbC54bWysVctuGzcU3RfoPxDcJ7JUq4mFjAPbqNMCiiFYDrqm ZjjWVBxySnL08NL5nqIBUqAb/40/wL/Qcy9HkvtA0VbVYnRneB/nnvvgm7fr2oil9qFyNpP9l0dS aJu7orK3mfxwc/nitRQhKlso46zO5EYH+fb0yy/eNKPQCBjbMGoyOY+xGfV6IZ/rWoWXrtEWZ6Xz tYp49be9xuugbVQRgWrTGxwdfd2rVWXlKVzZ5bSZeJLyq+XEi6rI5PCrwRBorKoR9lrnAHFrtBjI XqeXTBRwjF2+CB0Y9U/AFF6tkOHvcAjr3nmk0kdMdzFHNH3mvVvNtSoCfUbcHgPcYrWASliauYib BijnhQdbd5n8sVU+at+ZJD3Y7tMMSFfMVu9dATPVRgca1Ghd+vrQNMiPK0uxziTY29ATwNVIr6PI 8XFw8qr/+ghHOc6Oh69QCIaZopNm40N8p93BSAQ5yqRH6Tg7tRyHSCTuQ1A46y4rYw5Nm3M09lA3 YpXJk+FgyIATMvZcVyinMFWdSZCHXyKVeuMbW7BKVJVJMhI0ljkvSySPrA+FRazRwKV+i+tzV2wo wAz/aKQ0hv+98zH/KNTc+TspVl5hCAJ1sJbCfGfR+yf942N0TOQX7hkp/POT2fMT29YXzvAgKZvD ayajFEm8iHij5nN1o+LYTpucFLdtd7P+Xvmma5yIlr1y07lq9F/1T9Lldko0kBMT4jRusCYOpIR9 LU2fGVejQpfX4JlGu78fGLNVoIJ3gTmT/yM6LYha+THTBeGaBYTk/8oWWKYsKnOLzW2kAMgbNZsC I9cLLPuYtLUa23O/4JKUzsYzNpmpQBXGRrbdMUxo72EzTlqbw32qjKEyUWKhySd5FEtF1d2NAbf7 XuNcl3/U3W4Y2O9Pz8r4N3rd6ay9MP5mzQM2a6d3O/ESaexernA1dTM4w7SxmEpGg4N1Q3ODFWiL ifKKKrlo66p2P1SJVOScSW1ffJim9c01FrPEND/bTFoEobvQVwvsbOumLEmx0J5uTmoLkdPsdIrU 2fhk6Q401Z3+ll+JdFPRTcpnE+9cSTLhS0tjt3V2ayQ4UxW0JJkvumI1WElliOt0MaE4z7X0dvMw F+3Ydly15KaTufJ8c5UqB6AzXym0UT5XPmjuLTbW6pnO08NPTw+fxdPDp8f7Xx7vf338+PHx/uc/ G+XhXxsh3X2BUtl46223HS/A098AAAD//wMAUEsDBBQABgAIAAAAIQCWYdNo2QAAAP0AAAAPAAAA ZHJzL2Rvd25yZXYueG1sRI/BbsIwEETvlfgHayv1UhWHVCAUMIhWQvTYhEhct/GSmMZ2arsk+fta PcBxdlZv9NbbQbfsSs4rawTMpgkwMpWVytQCyuP+ZQnMBzQSW2tIwEgetpvJwxozaXuT07UINYsQ 4zMU0ITQZZz7qiGNfmo7MrE7W6cxxOhqLh32Ea5bnibJgmtUJi402NF7Q9V38asFPKft4rif9Z+X ElVejCX5cSAhnh6H3QpYoCHcn98O3c/pdCv/UR9SwPw1nUeb82H8ckrm6AM5AfESbaMp8M0fAAAA //8DAFBLAQItABQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAAm2I4iRAwAAsQgAABAAAAAAAAAAAAAAAAAAKAIA AGRycy9zaGFwZXhtbC54bWxQSwECLQAUAAYACAAAACEAlmHTaNkAAAD9AAAADwAAAAAAAAAAAAAA AADnBQAAZHJzL2Rvd25yZXYueG1sUEsFBgAAAAAEAAQA9QAAAO0GAAAAAAAAEPAIAAAAAAAAAFAH IAEPABHwEAAAAAAAwwsIAAAAAAAAAAoC/78PAA3wWAAAAAAAnw8EAAAABAAAAAAAoQ8aAAAAAQAA AAAAIAAKAAAAAP8HAAEAAAAAAAIADAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA 1AHQAvADEAUPAATw8wgAABIACvAIAAAAAzgAAAAKAACDAAvwSAAAAH8AAQDvAYAAaGByH78AAAAG AL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMA IvEBCAAAqcP7BwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2 GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJ Jl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmV SzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3 V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA X3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/ 0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaS tlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3Pfe PqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQA BgAIAAAAIQCPRFR1lAMAALoIAAAQAAAAZHJzL3NoYXBleG1sLnhtbKxV224bNxB9L5B/IPieSLKt xBayDmyjTgsohmA56DO1y7W24pJbkquLH53vKVqgBfriv/EH+Bd6ZqiLe0HRRNHDanY5nDlnrm/f LWsj5tqHytlM9l51pdA2d0VlbzP58eby5bEUISpbKOOszuRKB/nu9MU3b5tBaAQu2zBoMjmNsRl0 OiGf6lqFV67RFmel87WKePW3ncbroG1UEY5q0znodl93alVZeQpTdj5uRp6k/Go+8qIqMtk/POj3 pLCqhttrnQPErdHiUHbWeumKAo6hy2dhDUb9HzCFVwsw/AsOYd17Dyrk011M4U2fee8WU62KQJ/h t8MAN1gtoBKWZiriqgHKIkpAX+6UkwZu7QgGEBWTxQdX4IJqo0MA1GBZ+npfAmTHlaWA/8Pj46PX vUMpVpnsEnA10MsochwdnLzpHXeR5hxnR/03SAQzSxhIs/EhvtdubzyCDGXSI3XMUc2HIVIQdy7I nXWXlTH7kmeOxu5rRiwyedI/6DPghIwt11XUXpiqziSCh18KKtXGt7Zglagqk2QQNJZjXpYgD9b7 wqKoUcOleovLc1esyMEE/yin1IZfXvnofyRq6vydFAuv0AThp1Z5LYX53qL2T3pHR6iYyC9cM1L4 5yeT5ye2rS+c4UZSNofVTKIvkngR8UbF5+pGxaEdNzkpbsruZvmD8s26cCJK9sqNp6rR/1Y/SZfL KYWBjJgQx3GFMbFnSNjW3PSoWZW5xWj0jKHQ5TU+hTug3nWOSZqMZYOAKX0NGAShVn7IcYNwzQJc 8n9lC0xVFjc4BUDeqMkYGDlxCLePSVuroT33M85N6Ww8Y2oTFSjVGM12fYwrNAAxIketzWE+pchQ vohYaPJRHsVcUZq3/cB1v9M41+XfdTejBvd3p2dl/A+99emkvTD+ZsmdNmnHd1vxEjS2L1fYUetm nKDtWEwpow7C3KEGwiy0xUh5RZmctXVVux+rFFRwzqS2Lz+OsfU2ORaTFGl+tpm0cEJL0VczjHDr xixJMdOeViiVhcipidaKVOL4ZGkZmupOf8evFHRT0Urls5F3riSZ8KXpsR0/23kSnKkKmpYcL9q1 GlFJaYjLtKGQnOdaejOCOBbt0K5j1ZKZtcyZ5xVWqhyAznylDDhMlQ+aa4sva/VM5+nh56eH38TT w6+P978/3v/x+OnT4/0v/7yUh8++BLq7BKW04dkMNmOPJ+HpnwAAAP//AwBQSwMEFAAGAAgAAAAh AJ3hhgvZAAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj1FLwzAUhd+F/YdwBV9kS1vZKHXZGMJQ 0Afb9QfcNXdttElKEtf23xt8cI+Hc/gO33Y/6Z5dyXlljYB0lQAj01ipTCugPh2XOTAf0EjsrSEB M3nY7xZ3WyykHU1J1yq0LEKML1BAF8JQcO6bjjT6lR3IxO5incYQo2u5dDhGuO55liQbrlGZ+NDh QC8dNd/VjxbwmPWb0zEdP79qVGU11+TniYR4uJ8Oz8ACTeE2zj94857/l3+oNylg/ZStU2CX1/ns lCzRB3ICol+0jabAd78AAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAA AAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAA CwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAj0RUdZQDAAC6CAAA EAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQCd4YYL2QAA AP0AAAAPAAAAAAAAAAAAAAAAAOoFAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAA8AYA AAAAAAAQ8AgAAAAAAI8J3xAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwD/vw8ADfBaAAAAAACfDwQA AAAEAAAAAAChDxwAAAABAAAAAAAgCAoAAAAA/wIABwABAAAAAAACAAwAAACqDw4AAAABAAAABwAA AAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8IgAAAASAArwCAAAAAQ4AAAACgAAgwAL8EgA AAB/AAQB7wGHAAEAAAC/AAAABgC/AQEAEQD/AQkAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0 AGEAbgBnAGwAZQAgADQAAAAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAP+/ DwAE8OQJAAASAArwCAAAAAU4AAAACgAAgwAL8EgAAAB/AAEA7wGAAPhfch+/AAAABgC/AQEAEQD/ AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADUAAAATACLxrggAAKnD qAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyUkUFO wzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1dhrVjIl9oFpf lpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwRSSZdSBNkOabe RLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5lUs48glwJvfD rjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L91e4C5+UcP5v divYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAAAF9yZWxzLy5y ZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BBv9D3Ce32lzCp mbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCWkrZaix0poDSc KNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz33j6iahkx0VeY KgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQUAAYACAAAACEA wqA+r0IEAACpFgAAEAAAAGRycy9zaGFwZXhtbC54bWzsWNtu4zYQfS/QfyD4WmQd+ZJ1jFUWSdBs F3ADI07Rx4CWqFiNRKokZTt5zH5P0QK7QF/yN/mA/ELPkHISby9o10GQAnYAZWQOhzNn5szIevN2 URZsJo3NtYp59GqbM6kSnebqPOY/nB5t9TmzTqhUFFrJmF9Ky9/uff3Vm2pgK4bNyg6qmE+dqwat lk2mshT2la6kwlqmTSkcbs15qzLSSuWEw0Fl0Wpvb++0SpErvgdTajauRoak5Hg2MixPY97rtHsd zpQoceyJTODEeSFZj7cavbBFwI+hTi5s44z4N86kRswR4YofTOl3BqFEOFMfTnGa3DdGz6dSpJa+ xrkt7+DSVwVXyZdqytxlBS8nOr0EXFcx/7kWxknDEcki5p1mb9gAIw/xWsTNJvPvdYr9onYaeIjB IjPluvGQHZ1lDOfv9Hv9bWT2MubdDv4gIxgxkAvHEqz3uv0d+pIlpBFFXdKmcIMnpFoZ695JvbZX jAzF3CCfPlIxG1oXjloeQccpfZQXxboQ+CALta4ZNo/5bq/d8w4Hz7zlMkeKWZGXMQdg+ARUqWC+ ValXcSIvggwsC+VBzzIEj6jXdYtQIxaGInSLA1QfHUBViKIK3PxyOqApIFFTba44mxsBZliqaslZ 8V6BELtRt4uScf6m23vdxo15vDJ5vKLq8lAXnl1CJbAac8dZEA8d7qj6dFkJN1TjKiHFZdmdLn4U pmoKx6Fmj/V4Kir5V/UTdH3lBhjISGHd2F2id6wJic/osul9MbA+LOSnFGbow4Zw4oViBoCAQ65S dEoviuIcbbngLJXZqZiM0Vo87oS1C9pSDNWBufDqmVZu32+ZCEuZQrtVD8vU1ND2RrVKvHkPDsFN gq2SUeLYTFCW7svZl+2DxoHMPtftLCsfqrDxoLGfuc91l10Fes3qpD4szOnCQzupx1f34hFCub85 xuxp+DQJ/UIMgMjJyBAJ0J2IA2IQLsD2oi7zUv+UB1gRdcxzt/X+NDTnCMOHs0nA2l/rmCscQaPO 5BfoxEqPvcTZhTQ0GP2WhFjQKFKNwoqiEVfkV/I7f0uwFzkNSr82MlpnJJN3gf73/eO+IVhd5Cm1 O48WTVAJTEIi3CLMHUD7WEsue4gHpR6qBqmazDSyz70fTJlI4NC+yQUKqcpdMj0SZV6g129F27vg 3VQYK31FeHtSPNp2d/PL3c1Hdnfz2+31p9vr328/fLi9/vXPmxL7nzcBARMS5/bYGT64hP/+2si0 cHZGWUY50ZaQcQLribnomxjytkpIPA9sCDmY1BtCUmd8uYT8J2JvRe1+eDhZoek3pdpKbPOkt0rF QL5nod1yoK3Srr2hHTrchnYvfQ4+Le3C4HuOYRd1Xkc79By0Sjv84t5Muw3tXvzj59PS7hmnXdRv 9/3LmFXedTe824y7/8HPvqfl3d+OO7zYWr7Q8u+49v4AAAD//wMAUEsDBBQABgAIAAAAIQBqzsiE 2AAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LasMwFET3hf6DuIVsSiPHIaG4UUIphGRZPz7g xrq21VqSKymx/fcRXbTLYYYznN1h0j27kfPKGgGrZQKMTG2lMq2Aqjy+vALzAY3E3hoSMJOHw/7x YYeZtKPJ6VaElkWI8RkK6EIYMs593ZFGv7QDmdg11mkMMbqWS4djhOuep0my5RqViQ8dDvTRUf1d XLWA57TflsfV+PlVocqLuSI/TyTE4ml6fwMWaAr/4wrLU/PzV/6izlLAZp1u1sCa03xxSuboAzkB 0S/aRlPg+zsAAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAA AAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAwqA+r0IEAACpFgAAEAAAAAAA AAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBqzsiE2AAAAP0AAAAP AAAAAAAAAAAAAAAAAJgGAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAnQcAAAAAAAAQ 8AgAAACwCrABMA/QFA8AEfAQAAAAAADDCwgAAAADAAAABgL/vw8ADfCeAAAAAACfDwQAAAACAAAA AACoD1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhp cmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAA AgANAAAAAwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATw/wgAABIACvAIAAAABjgAAAAKAACT AAvwTgAAAH8AAQDvAYAAGBWFJYcAAgAAAL8AAAAGAL8BAQARAP8BAQAZAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAANgAAABMAIvEJCAAAqcMDCAAAUEsDBBQABgAIAAAAIQAy PL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCw BATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyM gbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzer Fjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtU z5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMA UEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mS oZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6 DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90 /s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+a HX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQAyo6JrnAMAAL8IAAAQAAAAZHJz L3NoYXBleG1sLnhtbKxV224bNxB9L5B/IPie6BLJsYWsA9uokwKKIVgO+jy7y7W24pIbkquLH53v CVKgBfriv/EH+Bc6M1xJbhMESRQ9SENxLmduhy9frSotFsr50ppE9p51pVAms3lprhP57ur86aEU PoDJQVujErlWXr46fvLLy3rka4HGxo/qRM5CqEedjs9mqgL/zNbK4F1hXQUBj+66UzvllQkQMFCl O/1u96BTQWnkMboyi2k9cSRlF4uJE2WeyOHz/nAghYEKw16qDEFcayUOZKfViyaAOMY2m/sWDHwL mNzBEjP8Dw5h7GuHqfQwpj2bYTR14pxdzhTknv7GuB0GuMFqECphqWcirGtEWQSH1bpJ5PsGXFB4 KPNVIgetadRHH7t0PaYt0uVbm6M5NMFiOWC0Kly1bzrkxxaFwPjY03UiDw8Oh/3ec8ICI7UKIsOr /tGL3mEXFTLUGAxfYFsYbMRAmrXz4bWye+MR5CiRDhvJOcJi7AOVdBeCwhl7Xmq9b/Kcozb7uhHL RB4N+0MGHJGx56rE5gpdVljVLn1iUWlSfjU5qwQodZQxQW245kWByWPW+8KiqtH6xekLq1ObrylA ir84TnEpf3wPkA2wUTPrbqRYOsCV8DTPSgr9m8FNOOoNBjgxgQ88M1K4xzfp4xvTVGdW81qBydBr IlMpongW8ETDZ6sawthM64wUN2N3tfodXN0OTsCRvbDTGdTqS/MTdXmcYhnIifZhGtZIGnuWhH0t dI8rDqNcFZdYZ1r03m5h9EaBGt4G5kx+RnSiiQrcmMuFwiULGJJ/S5MjtbII+hp5XEuBIK8gnSJG 7hdW2YWorWBsTt2cW1JYE07YJAVPHUZ+Nu01mhALIk9OGpOh+9gZTW2ixHydTbIgFkDd3a4Bj/tO 41QV/9fdMAza725PivAVvfY2bc60u1rxgqXN9GYrnmMa28MFPlTtDqa4bSzGltHiIN3Q3iAFmnwC DqiT86YqK/tHGYuKOSdSmafvppHMuccijZXm7yaRBoPQy+jKOTK3sVOWpJgrR+8ojYXIaHdaRZps /MvQi6jLG/WGj1R0XdK7yncTZ21BMuGLpLFlnS2NeKvLnEiS60UPrsKqxDaEVXymsDmPtdSGebgW zdi0tWrITStz5/kdKyBDQCeuBByjbAbOK54tNlbwSOfh7uPD3V/i4e7P+9u/72//uf/w4f720+dG mf9uI0x316DYNma9DdsxAR7/CwAA//8DAFBLAwQUAAYACAAAACEAahGUSdkAAAD9AAAADwAAAGRy cy9kb3ducmV2LnhtbESPTU8CMRRF9yb8h+aRuJMO6CgZKQSIisYVHwnb5/QxnTBth/YJw7+3caHL m3tzbs5k1tlGnCnE2jsFw0EGglzpde0qBbvt690YRGR0GhvvSMGVIsymvZsJFtpf3JrOG65EgrhY oALD3BZSxtKQxTjwLbnUHXywyCmGSuqAlwS3jRxl2aO0WLv0YLClpaHyuPm2Ct6iWZy8DMfwqTs/ 5JfcPu0+lLrtd/NnEEwd/48Xq/a03/+Vv6h3rSC/H+UPIA6r61eo9RojU1CQ/JJtMgU5/QEAAP// AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRf VHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABf cmVscy8ucmVsc1BLAQItABQABgAIAAAAIQAyo6JrnAMAAL8IAAAQAAAAAAAAAAAAAAAAACgCAABk cnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAGoRlEnZAAAA/QAAAA8AAAAAAAAAAAAAAAAA 8gUAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUAAAD4BgAAAAAAABDwCAAAAF8VAABQB38W DwAR8BAAAAAAAMMLCAAAAAQAAAAJAv+/DwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKEPGgAAAAEAAAAA ACAACgAAAAD/BwABAAAAAAACAAwAAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB 0ALwAxAFDwAE8HwJAAASAArwCAAAAAc4AAAACgAAkwAL8E4AAAB/AAEA7wGAAEgchSWHAAIAAAC/ AAAABgC/AQEAEQD/AQEAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADcA AAATACLxcggAAKnDbAgAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5 cGVzXS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/ 2av1dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJ uAwRSSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJq lqn5lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzb xK8L91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAA CwAAAF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9k y6BBv9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVE MTCWkrZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy 0Nz33j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBL AwQUAAYACAAAACEArEEwZwYEAAAcDAAAEAAAAGRycy9zaGFwZXhtbC54bWzsVs1u4zYQvhfoOxC8 e/2fOMYqC8e72S7gDYw4RY8FLVGxGopUScpxUvSSfZ6iBVqgl7xNHiCv0G9IOU5/ULT1Ar2sD/JQ HM588/MN9fLVplRsLa0rjE5490WHM6lTkxX6MuFfXpy2Rpw5L3QmlNEy4TfS8VfHn3/2shq7iuGw duMq4Svvq3G77dKVLIV7YSqpsZcbWwqPpb1sV1Y6qb3wcFSqdq/TOWiXotD8GKb0elHNLUnp2Xpu WZElfNjvDYecaVHC7blMAeJSSXbI241ePCKAY2bSK9eAEf8ETGbFNSL8HQ6mzVuLULrwaaYreJMT a831SorM0Wv4bQeAW6waUAlLtWL+pgJKp7KzukTCbhP+bS2sl5Yjlg2CaU7HIzCzi9ghcra8fm8y WBC1N8iIGG9yW+4bEdkxec7gvz8aDQ66fc5uEj46GA17kBGPGMuNZykUekeH3VEH1U+hMRgeoj4B ckRCmpV1/q00e6NiZCjhFhUNkYr1zHnK7c4FudPmtFBq3xSEGJXe1wy7TvjRsDcMgCOyYLksUGKm ihJZ7dAvJpVa5o3OgooXhYoyAlQ65DzPETyi3hcWZY14GNvQb05MdkMOlvhHU0V2/ndCYCygUCtj bzm7tgLccNTVkjP1ToMSR93BAB3jwyL0DGf2+c7y+Y6uy6lRgV9Cp7Ca8CVnUZx6rKj5TFkJP9OL KiXFbdtdbL4Stmoax6Nlz8xiJSr5V/0TdUM7xTSQEeX8wt9geuyZkmBrrbpEWaEuMTFtwJDJ/Byv iPfdHXNU1AxYtghCSB8DBkEohZ2FvEE4DwJchv9CZxi2QdziZAB5IZYLYAyFQ7qtj9pSzPSJvQq1 yY32kxDaUjgqNSa2brZxhOYiJue81inMxxIpqhcF5qp0nnq2FlTmJz6Evt9pnMj8j7rbUYPzu91J 7v9Gr9ld1lNlLzaBact6cfskniKMp8UZrq6GjEvQLoixZMQgzB0ikBjnKgs3z3fTw5Npv9/vtSa9 zqDV7Q4OWpPpqNfqTE6OOof9169Ph2++R+M3Q79ArjH2yYRFVa7qsijNN0UsCPKV8MK33l3EeyH0 B1vGKoVnnXANgHTP2uIKl4A2iyBxdiUt3crUUiwlAjaKRA+80nS/quJWfhGWVDBV0C0d9ubWmJxk AhYnz9PoeppFzqgio0kbck3Xt0RGYwn9Jl56KOxzLbkdXyGP9Uw3ea7JTCOHrgkJykUKQBNbCIUY VsI6GfoyHJbimc7j/Q+P9z+zx/ufHu5+ebj79eHDh4e7H/98KHX/+hDCRWUoxE+0oSx8VNr446+J RGArnuAQOZA6mwsraCh+ogPYR0P0Wdf+/3TYFShOQDyr8fYLInxUHP8GAAD//wMAUEsDBBQABgAI AAAAIQBy9pL52AAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/LTsMwEEX3SPyDNUjsqNOiAA11 K6h4ilUfG3bTeBJbjcfBNm3691gsYHl1r87VmS0G14kDhWg9KxiPChDEtdeWWwXbzfPVHYiYkDV2 nknBiSIs5udnM6y0P/KKDuvUigzhWKECk1JfSRlrQw7jyPfEuWt8cJhyDK3UAY8Z7jo5KYob6dBy fjDY09JQvV9/OwUv0Tx+eRn24UMPfpyeSne7fVfq8mJ4uAeRaEj/40/b7KbLv/IX9aYVlNeTsgTR vJ52weoVxkRBQfbLttkU5PwHAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACP AQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEArEEwZwYEAAAc DAAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQBy9pL5 2AAAAP0AAAAPAAAAAAAAAAAAAAAAAFwGAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAA YQcAAAAAAAAQ8AgAAABfFY8J3xB/Fg8AEfAQAAAAAADDCwgAAAAFAAAACAL/vw8ADfBsAAAAAACf DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAAAAAAIAgKAAAAAP8CAAcAAgAAAAAAAgAMAAAA 2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8DwAAAAS AArwCAAAAAE4AAAADAAAYwAL8CQAAACBAQAAAAiDAQUAAAi/ARAAEAD/AQAACAAEAwkAAAA/AwEA AQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABzyccBAASNRQAADgRXDAAA UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQDnq3QW 4gYAAGkdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZzW8cNRS/I/E/WHNvsx9NyEbdVMnu poE2bZTdFvXonfXOuPGMR7Y3yd5Qe0RCQhTEBYkbBwRUaiUu5a8JFEGR+i/wbM9Mxhmn+SACBN1K zYzn957f93ueuX7jIGFojwhJedoNmlcbASJpyCc0jbrBvdHGleUASYXTCWY8Jd1gTmRwY/Xdd67j FRWThCCgT+UK7gaxUtnKwoIMYRnLqzwjKTybcpFgBbciWpgIvA98E7bQajSWFhJM0wClOAG2d6dT GhI00iyD1YL5gMFtqqReCJkYatYkpzCoyW5TP5MiGveYQHuYdYOG+QULq9cX8EoOYKqO2zC/HJcD Jrut0/gZAFN13HJD/yv5GQAOQ5C/vvf6+qAxaOfYCshe1nm34dfpOPgK/3ZNZkc3y9SA7OW1Gt6x WQVkLxdr+P7aoD/YcOQxIItfquFb/VZ/ec3BG1DMaLpbQzcaHfjl6BIy5WzTC+90er1GYfgjFHi/ jBm9xZSnyokgG3OBfpbgh1xsAEDfMKxoitQ8I1McQmz2MKNjQbU8eIXgyhO7FMrakt4LyVDQTHWD DzIMcX7E7/WL716/eIZev3h6+Oj54aMfDx8/Pnz0g+XlEG7iNKoSvvrm0z+++gj9/uzrV08+9+Nl Ff/L9x///NNnfqCqAl9+8fTX509ffvnJb98+8cDXBB5X4SOaEInukH20wxPQzRjGlZyMxfkoRjGm VYq1NJI4xXoXD/+Bih30nTlm2INbJ64F7wsKlcwDvDl76Ag8jMVM5S53NLsVJw5wi3O2zoXXCrf0 XhXHj2Zp5N9czKq4HYz3fHv3cOr4dzDLoCBSH8teTBwxtxlOFY5IShTSz/guIR4zPKDUsesWDQWX fKrQA4rWMfWaZETHTjQdEW3SBPwy9wkI/nZss3UfrXPm07pP9lwkZAVmHuFHhDlmvIlnCic+liOc sKrBb2MV+4QczkVYxQ2kAk9HhHE0mBApfTR3BehbcfotqB5+t2+xeeIihaK7Pp63MedVZJ/v9mKc ZD7skKZxFfu+3IUQxWibKx98i7sZou/BDzg90d33KXHcfXo1uEcjR6SjANFPZkL7Eqq1U4QTmr6t yGeuyGuCelNi81gdPgl3vPr2uJjQf3/x7eNZuk0g3usd6G3tfVt7g/987T0pn89acY+KLNRfPefY AdmMy8mJ0/KUMjZUc0ZuSzMwS2gYkw1Y1HTm/EfK01gWw2Ve4B1cJLChQYKrD6mKhzHOYNhumnk8 kjnrSKKMSzjUmWUvb70pDOzKnv4W9VHG1gOJ1Raf2OV29VBYsjFtJzLHy2KjtmZw1s3a7/21zZpW qhPN5qrWNKKZUueoVqoMPqyrBoulNWESQTC/gJWX4ASuZYdDCmZkou1um3DhFr11cX3JLsq1torE eEKsi5zliuuaxndFCJlXABBSHtedz5ql1cBopwthwqI4Y17YyAWDwrBGiePZxNJqbrEU7XeDzmJr MUAhzrrBFI6ncJlk4DSpZzfMInhzEypho/bUXDTRdqRxxx9VzUaxXosqJ40zIVUfy9j60DzKXcVS vZOVv7V4TQfb5ShgA/UCUrSXIUT+MSnAjq5ryXRKQlV1dmVF287e5pWQzxQRw3iyj8ZsJnYwuB9s qvWZUAlvGUxC6xvRDbS1zSO3tuZ1zfOyTO+GWRbjvFoua+rczhZuQrWUwdxVxAPdvLIb5c6vis74 y1KlGsb/M1V0O4ATf3uiPRDCe1aBkc7XbsCFijlUoSym4YaAvm9qB0QLguqiuy2Ct73mryB7+q+N BctDc2NwcFM7NEKCQjtRsSBkG8qSib5TmDXz1mNZFoxMRFXElZkVe0z2CBvpGrika3CAYgh1U03y 8DS44/Hn3ucZNI70jFLNN6eGlFXd5sDfPbjYZAalwGuV7ndK49HN3U5Ilt6QFz2yqoh+cDQlXSuy wml+nU6e9hcU4SwNuNJrbcWqadxaLIQDL5ZOMfGhRzVYLOeZDN7bIP0f9D8qQmY/HeiGOuI7UFsR fA7QzCBsIKqv6KoGl7pA2qsxzD120QaTZmV3yIdTbbWiWV/yFFTue8zYWrIi3+raH/n7nMYuhyh3 OycX69td3Ni5hR1b27UTTQ2bHU9RWJoW5xDjGPPNqfpZiI8fgqP78Kp+xuyHIpnBncmDbFuY6Brz yTy/ZNI2XBt1+gyjkSzdIVNEJwfF+aO0hE0h+1mjGJENWpPpQCsJ275Dg0uY4zWp7ZYlcet04pLC 7AwluyQ2r8p8DOCjVl649dEO8MaE0moNpi0txdK/YrIzCO83mfecdVaT2YPiGx11AZOpgzebLLcU GK8eeOQA3g7D0WRo6i80HRvpJmRX/wQAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6 EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J 2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzF JL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQIt ABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRoZW1lL3Ro ZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA56t0FuIGAABpHQAAFgAAAAAAAAAA AAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsB AAAnAAAAAAAAAAAAAAAAAOkJAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJl bHNQSwUGAAAAAAUABQBdAQAA5AoAAAAAAAAPBDoBAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29k aW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0cDov L3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0ibHQx IiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2NlbnQy PSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1PSJh Y2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xIbGlu ayIvPgAAJwSkBQAAUEsDBBQABgAIAAAAIQCbEwW7+gAAALsBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbHyQy2rDMBBF94X+g9C2WHK6KKXYzqKPXR+L9AMGeWyL6oVGCcnfd+ykEErIapjHnXu4zXrv ndhhJhtDK1eqlgKDib0NYyu/N2/VoxRUIPTgYsBWHpDkuru9aTaHhCRYHaiVUynpSWsyE3ogFRMG 3gwxeyjc5lEnMD8wor6v6wdtYigYSlXmH7JrXnCArSvidc/jIwnLpXg+3s1WrYSUnDVQGFTPW31R l9HRFeEu9P/oqhOZYuXynCab6O7k8MnRZNuj+IJcPsAzh+4zaXI8fAcqnNx5s1LXwS/4x2GwBvto tp4zUSkjcV1QvFNnRn9Meom++wUAAP//AwBQSwMEFAAGAAgAAAAhAI7qKvq+AAAAOAEAAAsAAABf cmVscy8ucmVsc4SPwQrCMBBE74L/EPZu03oQkaa9iNCDF9EPWJJtG2yTkI2if2+OFgSPwzBvZur2 NU/iSZGtdwqqogRBTntj3aDgdj1t9iA4oTM4eUcK3sTQNutVfaEJUw7xaAOLTHGsYEwpHKRkPdKM XPhALju9jzOmLOMgA+o7DiS3ZbmT8ZsBzYIpOqMgdqYCcX2H3Pyf7fveajp6/ZjJpR8Vkidr6Iyc KGYsxoGSAhP521iIqsj7QTa1XPxtPgAAAP//AwBQSwMEFAAGAAgAAAAhAObcV5J0AgAAWw4AACEA AABkcnMvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsl91q2zAUx+8Heweh25E6zqdj4pR0 I1e9KGv3ACeyHJvKspHULNll+jxjgw12k7fJA+QVpuM4xG5htBBGIfGVhHSOdP4/WedoeLlIBZlz pZNMBtS9aFLCJcvCRM4C+uVu0vAo0QZkCCKTPKBLrunl6P27Ye6bxa1ZCq6JdSG1DwGNjcl9x9Es 5inoiyzn0o5FmUrB2K6aOaGCr9Z1KpxWs9lzUkgkLe3VS+yzKEoY/5Sxh5RLs3OiuABjt6/jJNd7 b/lLvOWKa+umsK5taYThJUbwIkIHu9MsXBa90RB8MRdufqMIiJlVTVCijAgoagfX8krdF+0ok2Zc TJiC5pTEIGc29psHyQxOQEc6Z1c8Kls3zJA5WEftpv2oXdZ5MmMcmadzK/PK0ZBHn+3e9DfL06pM yT1XyBbbhXUmknCSCFF0kBX/KNRuZbNw9+tWZ6HAkphlziNg9hSMVQI26jwxLJ5AmohlQBtuc0AJ i0FpXsRn9w8+h4rZdv19u/5Ftuufm9XvzerP5vFxs/rx3IjpVxtZpXZxF6KVfHADttlCVCmo64B2 uv1CkjO4o4D71wFouC0PzxL4NZwfUtlgujxkdWTIqUTWPiAbuJ0OnuIzsjeIDDmVyDoHZG677/bO zI52Px73N0NQJbNuhZnX8rwzszfKDEGVzHoHZq2WZ3+z6t1oL9Q7mN7a1L/PdM8qE5eSIp0fCpV6 YeJSXOg/FBGYCYTZpYhamYADHF6XO1CVUqB+RaB+p13P9ycrEKpSCuQdBEJ16tn1ZAVCVUqBBhWB et1+PZWdrECoiq2ua0+h3M9MzNX+mWQH96/C0V8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJsTBbv6 AAAAuwEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAjuoq+r4AAAA4AQAACwAAAAAAAAAAAAAAAAArAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEA5txXknQCAABbDgAAIQAAAAAAAAAAAAAAAAASAgAAZHJzL3NsaWRlTWFzdGVycy9zbGlkZU1h c3RlcjEueG1sUEsFBgAAAAADAAMAyQAAAMUEAAAAAA8A7gPKBwAAAgDvAxgAAAAQAAAAAAAAAAAA AABYAACAAAEAAAcAAAAPAAwEyQYAAA8AAvDBBgAA8AAI8AgAAAAFAAAABDwAAA8AA/CpBgAADwAE 8CgAAAABAAnwEAAAAHRyaW5nPk5hYmlsPC9zdHICAArwCAAAAAA8AAAFAAAADwAE8PcAAACiDArw CAAAAAE8AAAACgAAgwAL8FoAAAB/AAEA7wGAACj0qSW/AAAABgC/AQAAEAD/ARAAGQA/AwAACACA wyoAAAC/AwAAAgBGAG8AbwB0AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADQAAAAAABDw CAAAABQQsAfQDkARDwAR8AkAAAAAACAEAQAAAAkPAA3wXAAAAAAAnw8EAAAABAAAAAAAqA8OAAAA SUVURjg3IGkycnMgV0cAAKEPHgAAAA8AAAAAACAICgAAAAD/AQAHAA8AAAABAAIAAQAOAAAApg8M AAAA8AAAANQB0ALwAxAFDwAE8BMBAACiDArwCAAAAAI8AAAACgAAgwAL8GYAAAB/AAEA7wGAAAi+ byC/AAAABgC/AQAAEAD/ARAAGQA/AwAACACAwzYAAAC/AwAAAgBTAGwAaQBkAGUAIABOAHUAbQBi AGUAcgAgAFAAbABhAGMAZQBoAG8AbABkAGUAcgAgADUAAAAAABDwCAAAABQQIBBgFUARDwAR8AkA AAAAACAEAQAAAAgPAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAI CgAAAAD/AgAHAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAA APAAAADUAdAC8AMQBQ8ABPCUAQAAEgAK8AgAAAADPAAAAAoAAIMAC/BIAAAAfwAAAO8BgAAI86Yl vwAAAAYAvwEBABEA/wEAABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAy AAAAAAAQ8AgAAADQAhgAOBaACg8AEfAcAAAAAADDCwgAAAD/////DwD/vwAAHwQEAAAAAgAAAA8A DfD4AAAAAACfDwQAAAAGAAAAAACoD4IAAABJbnRlcmZhY2UgdG8gdGhlIFJvdXRpbmcgU3lzdGVt IChJMlJTKSBmb3IgU2VydmljZSBDaGFpbmluZzogVXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHML CwtkcmFmdC1iaXRhci1pMnJzLXNlcnZpY2UtY2hhaW5pbmctMDAudHh0AAChDzoAAACDAAAAAAAA AAAAPAAAAAEAAgABABgAAQAAAAAEAgAABBgAGgAAAAEIAgABCBgALAAAAAAMAgAADBgAAACqDxgA AABXAAAABwAAAAAACQQAACwAAAABAAAAAAAPAATwuwIAABIACvAIAAAABDwAACACAAATAQvwfgAA AAQAAAAAAH8AAQDvAYAACA6nJYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgA AAAAAL8AAAAGAL8BAAARAP8BAAARAAEDAnwAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBu AGcAbABlACAANwAAAAAAEPAIAAAAQAhAAtAUkAwPABHwHAAAAAAAwwsIAAAA/////xAA/78AAB8E BAAAAAMAAAAPAA3w6QEAAAAAnw8EAAAABQAAAAAAqA+rAAAATi4gQml0YXIgKFZlcml6b24pLCAN Ry4gSGVyb24gJiBMLiBGYW5nIChDaXNjbykNUi4gS3Jpc2huYW4gKEJyb2NhZGUpDU4uIExleW1h bm4gKERldXRzaGUgVGVsZWtvbSkNSC4gU2hhaCAoQ2llbmEpDVMuIENoYWtyYWJhcnRpICYgVy4g SGFkZGFkIChFcmljc3NvbikNDUlFVEY4NyAtIEJlcmxpbg0NAAChDxYAAACsAAAAAAAAAAAArAAA AAAAIgAAABQAAACqD/AAAABGAAAABgAAAAkEAAADAAAABgAAAAsEAAAHAAAABwAAAAMACwQAAAIA AAAGAAAACwQAAAcAAAAHAAAAAwAHBAAACQAAAAYAAAAHBAAAAQAAAAYAAAALBAAACQAAAAYAAAAH BAAABQAAAAcAAAADAAcEAAACAAAABgAAAAcEAAADAAAABgAAAB8EAAALAAAABwAAAAMAHwQAAAMA AAAGAAAAHwQAAAMAAAAGAAAACgQAAAYAAAAHAAAAAwAKBAAAFgAAAAYAAAAKBAAABgAAAAcAAAAD AAoEAAACAAAABgAAAAoEAAABAAAABgAAAB8EAAAAAKYPDAAAAPAAAADUAdAC8AMQBRAA8AcgAAAA ////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8AihOVAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAADjFxwHA5VJeAAAdEAQAAAAAAAAAAAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAB0EBAAAAAEAAAAPAO4DEQ8AAAIA7wMYAAAAEAAA AAAAAAAAAAAAWQAAgAEBAAAHAAAADwAMBBAOAAAPAALwCA4AABABCPAIAAAABQAAAAREAAAPAAPw 8A0AAA8ABPAoAAAAAQAJ8BAAAAATAP9/BAAAAB4EAABABAAAAgAK8AgAAAAARAAABQAAAA8ABPD3 AAAAogwK8AgAAAABRAAAAAoAAIMAC/BaAAAAfwABAO8BgACIiYMlvwAAAAYAvwEAABAA/wEQABkA PwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA0 AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAJAAAAAAAgBAEAAAAJDwAN8FwAAAAAAJ8PBAAAAAQAAAAA AKgPDgAAAElFVEY4NyBpMnJzIFdHAAChDx4AAAAPAAAAAAAgCAoAAAAA/wEABwAPAAAAAQACAAEA DgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPATAQAAogwK8AgAAAACRAAAAAoAAIMAC/BmAAAAfwAB AO8BgACokIMlvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAA TgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA1AAAAAAAQ8AgAAAAUECAQYBVA EQ8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAAC AAAAAAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAA AACmDwwAAADwAAAA1AHQAvADEAUPAATw9wAAABIACvAIAAAAA0QAAAAKAACDAAvwSAAAAH8AAQDv AYAAqJqDJb8AAAAGAL8BAQARAP8BAAAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcA bABlACAAMgAAAAAAEPAIAAAArQAgAWAVfQMPABHwHAAAAAAAwwsIAAAA/////w0A/78AAB8EBAAA AAIAAAAPAA3wWwAAAAAAnw8EAAAAAAAAAAAAqA8HAAAAT3V0bGluZQAAoQ8YAAAACAAAAAAAAAAK AAcACAAAAAEAAgABABgAAACqDxgAAAAHAAAABwAAAAAACQQAAAEAAAABAAAAAAAPAATwnwoAABIA CvAIAAAABEQAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAAGKqDJYEAMGUBAIIAmLIAAIMAMGUB AIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAP8BAAARAAEDAoAAAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMAIvFwCAAAqcNqCAAAUEsDBBQABgAIAAAAIQAy PL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCw BATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyM gbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzer Fjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtU z5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMA UEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mS oZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6 DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90 /s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+a HX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQB/CL2tAgQAAPkcAAAQAAAAZHJz L3NoYXBleG1sLnhtbOxZzW7jNhC+F+g7ELxn7TjOpjEiLxIDaRcwAiP2Yo8FLdGxaorUkpRj55h9 nqIFWqCXvE0eIK/QbyjZVtN00e32kLTyQebPkDPzzR9FnbxZZYotpXWp0RHff9XmTOrYJKm+ivi7 yfneN5w5L3QilNEy4mvp+Jv+11+d5D2XMyzWrpdHfO593mu1XDyXmXCvTC415mbGZsKja69auZVO ai88GGWq1Wm3X7cykWrex1Z6Oc5HllrxxXJkWZpAlqPu/gFnWmRgeyljCHGlJDvgrYquXCIgx9DE C1cJI/6OMIkV19DwD3Iwbb61UGUfPM1gDm7y1FpzPZcicTQMvq0g4EZWDVFJlnzO/DqHlFOTrDmE X0W82znuHr8+6hwfVutKYmyw09VB56CMX51hZf9E9GgH6F/i+s9VgUE9cDD2hrNrK6CV+1AIKzlT bzWUOd7vdmFpHzrdw6MOOrY+M63P6CIbGBWQETrGrhH3nJXNgUcPq2OT5cIP9TiPiZB0ya3zk9V7 YXNGTSySK39hxnORy0AglkPnCdU6beiWMNAmyvmxX8PuXwgJ2IDLl+4SNoF9MmGHET+AkdvQHb3L AIJaAiUMpDqBq0d8b0Mh1BWiS3GWyNlETMc3lQkIdl+ukWKoz+wioDwz2p+GJVPhyGiIGl1NYwn5 Jrx3VOgYTEqwFSFP4rk8HsWeLQUZrE2/4IBAskZxJmePaRGQW1LssaM4nfnHtJstQVfNTouBQiyA PWUAiU4pgYhjINGpRNhSTYvxzVbKo8OKM9y/OIfqIZpmIkZEvYeelIscPGwurJNQOHAn2gtkpGBX L6alJ4keAL4MUUVOReEpelInI2EFhtmiyNLM/JCW1gKMEZd6790YOQ4mIQg4m5YmDM8i4hpMKAXa dAF5tBmHFmcLaWFS0McUXhUVOT+GNOU9ld7I70KXjKhSyp5hbmSNmYV2klq/phaJqTQ9tTlPlSqD ohxxRqUJDT4Br1+VaQm416nkbIZ8uYGkGOrJKuBU0DZVO/hUDelTmwo46GOUpajRPNz9+HD3C3u4 +/n+9tf729/uP368v/3pz4ti99mLYK6dncqUQPo2ERusXo/Hbdy8wIhFWbXBxSL+gXKC6H06dEP8 2mccuMxlfqCkCKmA9PnfRzGsFezaZ99XP2qw0KNKj2KCJ2goQRPlvxziSLF/WY8x11Ti8oC1qdef rsRVrWhKLQ6vTamtvc099QIVgrk5HD+Tw3FTav/zB+Z6qS2rbSi1m7pL/03FDeXu5bz7NhV3e3fQ VNz6/WlTcfGusLtwql9zPZOK21xHNRHbRGyoty/kAvlzz8i7G8qnbpJTv/d20twk8+d4k4zvbpuP bGi6vP87AAAA//8DAFBLAwQUAAYACAAAACEA1ZxcqtoAAAD9AAAADwAAAGRycy9kb3ducmV2Lnht bESPwU/CMBSH7yb8D80j8SYdYBQmhRgNKiczBgdvj/VtK6zt0nYw/OttPOjx5Xv5fvkWq1437EzO K2sEjEcJMDKFlcpUAnb5+m4GzAc0EhtrSMCVPKyWg5sFptJeTEbnbahYlBifooA6hDbl3Bc1afQj 25KJrLROY4inq7h0eIly3fBJkjxwjcrEhRpbeqmpOG07LeCgJjv8zvK3RM/X07Dp82P39SrE7bB/ fgIWqA//z/vPWdeVf/BX9SFjy+P9eAqsfL8enJIZ+kBOQOyLtZECX/4AAAD//wMAUEsBAi0AFAAG AAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEAfwi9rQIEAAD5HAAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1s LnhtbFBLAQItABQABgAIAAAAIQDVnFyq2gAAAP0AAAAPAAAAAAAAAAAAAAAAAFgGAABkcnMvZG93 bnJldi54bWxQSwUGAAAAAAQABAD1AAAAXwcAAAAAAAAQ8AgAAADwAyABYBUTDw8AEfBiAAAAAADD CwgAAAD/////DgD/vw8AiBM+AAAADwCKEzYAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExgA AAAAAKwPEAAAAAAAgAL//wAAAAAAAAAAAAAAAB8EBAAAAAMAAAAPAA3wFQEAAAAAnw8EAAAAAQAA AAAAqA8zAAAADU9iamVjdGl2ZSBhbmQgU2NvcGUNDVVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRz DQ0NAAChD6oAAAABAAAAAAD/AAoADgAiIAIASwAAAAAFBwAUAAAAAAD+AAoADwBxAAIASwAAAAAF BwABAAAAAABtAAoADABLAAAAAAUHABsAAAAAAP4ACgAPAHEAAgBLAAAAAAUHAAEAAAAAAG0ACgAM AEsAAAAABQcAAQAAAAAA/wAKAA4AIiACAEsAAAAABQcAAQAAAAAA/gAKAA8AcQACAEsAAAAABQcA NAAAAAAAAgAUAAAAqg8UAAAAMwAAAAYAAAAJBAAAAQAAAAAAAAAQAPAHIAAAAP///wAAAAAAgICA AAAAAAC74OMAMzOZAACZmQCZzAAADwCIE50AAAAPAIoTlQAAAAAAug8QAAAAXwBfAF8AUABQAFQA MQAwAAAAixN1AAAAAADrLggAAAAx7MgBgCPF6gAAHRAEAAAAAAAAAAAAACsEAAAAAAAAAB8ARPE9 AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAD/////EgAAAA8APfENAAAAQAFC8QUA AAABCQAAAA8AAisAAAAAAAAdBAQAAAABAAAADwDuA1sSAAACAO8DGAAAABAAAAAAAAAAAAAAAGMA AIACAQAABwAAAA8ADARaEQAADwAC8FIRAAAwAQjwCAAAAAUAAAAETAAADwAD8DoRAAAPAATwKAAA AAEACfAQAAAAxNnSZAAAAAAIAAAAwwCoJQIACvAIAAAAAEwAAAUAAAAPAATw9wAAAKIMCvAIAAAA AUwAAAAKAACDAAvwWgAAAH8AAQDvAYAAGImmJb8AAAAGAL8BAAAQAP8BEAAZAD8DAAAIAIDDKgAA AL8DAAACAEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAAAAAEPAIAAAA FBCwB9AOQBEPABHwCQAAAAAAIAQBAAAACQ8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRG ODcgaTJycyBXRwAAoQ8eAAAADwAAAAAAIAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADw AAAA1AECAAACAgAAAwIAAAQCAAAFAgAABgIAAAcCAAAIAgAACQIAAAoCAAALAgAADAIAAA0CAAAO AgAADwIAABACAAARAgAAEgIAABMCAAAUAgAAFQIAABYCAAAXAgAAGAIAABkCAAAaAgAAGwIAABwC AAAdAgAAHgIAAB8CAAAgAgAAIQIAACICAAAjAgAAJAIAACUCAAAmAgAAJwIAACgCAAApAgAAKgIA ACsCAAAsAgAALQIAAC4CAAAvAgAAMAIAADECAAAyAgAAMwIAADQCAAA1AgAANgIAADcCAAA4AgAA OQIAADoCAAA7AgAAPAIAAD0CAAA+AgAAPwIAAEACAABBAgAAQgIAAEMCAABEAgAARQIAAEYCAABH AgAASAIAAEkCAAD+////SwIAAEwCAABNAgAATgIAAE8CAABQAgAAUQIAAFICAABTAgAAVAIAAFUC AABWAgAAVwIAAFgCAABZAgAAWgIAAFsCAABcAgAAXQIAAF4CAABfAgAAYAIAAGECAABiAgAAYwIA AP7///9lAgAAZgIAAGcCAABoAgAAaQIAAGoCAABrAgAA/v////7////+//////////////////// //////////////////////////////////////////////////////////////////////////// ////AdAC8AMQBQ8ABPATAQAAogwK8AgAAAACTAAAAAoAAIMAC/BmAAAAfwABAO8BgAC4jaYlvwAA AAYAvwEAABAA/wEQABkAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIA IABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA2AAAAAAAQ8AgAAAAUECAQYBVAEQ8AEfAJAAAAAAAg BAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA /wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA 1AHQAvADEAUPAATwAwEAABIACvAIAAAAA0wAAAAKAACDAAvwSAAAAH8AAQDvAYAACJimJb8AAAAG AL8BAQARAP8BAAAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAA EPAIAAAAkABAApASYAMPABHwHAAAAAAAwwsIAAAA/////w0A/78AAB8EBAAAAAIAAAAPAA3wZwAA AAAAnw8EAAAAAAAAAAAAqA8TAAAAT2JqZWN0aXZlIGFuZCBTY29wZQAAoQ8YAAAAFAAAAAAAAAAK AAcAFAAAAAEAAgABABgAAACqDxgAAAATAAAABwAAAAAACQQAAAEAAAABAAAAAAAPAATw3Q0AABIA CvAIAAAABEwAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAAKHumJYEAMGUBAIIAmLIAAIMAMGUB AIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAP8BAAARAAEDAqgAAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMAIvHvCQAAqcPpCQAAUEsDBBQABgAIAAAAIQAy PL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCw BATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyM gbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzer Fjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtU z5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMA UEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mS oZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6 DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90 /s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+a HX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQDYa1Y+gQUAAKFCAAAQAAAAZHJz L3NoYXBleG1sLnhtbOxc3U4jNxS+r9R3sHzP5ocEQkRYARJtpQhFhNVeVs7EQ6bMeGY9Tghcss9T tVIr9Ya34QF4hX62ZzKTLN3Nhk1gqZFI/HPsOT6/Psee7L+dRiGZcJkGsejQ2psqJVx48TAQFx36 7vxkq0VJqpgYsjAWvEOveUrfHvz4w37SThOCwSJtJx06UippVyqpN+IRS9/ECRfo82MZMYWqvKgk kqdcKKbwoCis1KvVnUrEAkEPMJWY9JOe1CXvdNKTJBh2aH272dylRLAIjz3jHpC4CDnZppUMzg5h wKMbe5dphgxbBpmhZFdY4RweRMQ/SSylhmfGxyM8jR9KGV+NOBumuhnPrRgEc1wFUNW4JCOirhNg OYiH1yDXDVBgoU+xjGmHNup7jb2d3fpeM5vBDsNUxapTs3rWnvoyeuo6DvZZO/Z9gkdvt2rVKjh6 DfQbjd0WylgEa/OpIh76W9vVpm4kHiAadSBpISoWE7Nei1rSVtMjrE6P1qsEjyzvVyc3hE6BULG8 oeRKMlA+/TBmklMS/iJA8D2gDNSUqTSawI0SWe4ZlHvEODqOQ8M9JjzM2qGKEls8VqjpVcZRwlRX 9BNPA+q1JDJV59P3TCZEFzEItDmN+yOWcAPAJt1Uac6XYU3VkkFPEqaqr64hm08kieFNrlQrE9Ys C/yJmOxCBCB+msOonRkihBNQCQ2BGEIdO3Qrh2DhBSxASMmQ++ds0IcUGxZosis7hrOuOJKXhsp+ LNShGTJgqWYaNFtk3Rii9Qca1hsLDw+xxA415TV6aeL1PEUmDNMCu5nQlQGOuL8ICumcgWKKAuLQ V4uwRtLBNMBlvYPxcQh1RZM2UhwViwDzPBCibpQTwp1DDcb9mxmSu83syRrgBCs3Cu8zD0r/HsvU 5jKFgI2YTDnWm+kZJkOLae7QD1b3FBtYiWJtEPqsJzPh0qaEte0HuHc5joIo/i2wPAMxO5SLrXd9 a140JSgZGEZYkHGHChhobaxlcAm0RNw3JUouuQRjAe9pJcugtAqgSWgLHQY3/GdT1awMA23nTV9P xrFvysNAKtgItKaROg45MzNqjEOhP0V8EoShXYptSeMwGOrGR0iuptaaghdlKO77MPM5dcZdcT41 KjHW02RlI2Yl6h/KgEFmFynPWQnm4e73h7u/yMPdn/e3f9/f/nP/8eP97R+fDvLSrx4ECZOWc+qA /Jr9EaLNBURS967CVZDZcfWFcHXG1Jy55QbLcv2Z/+e9tsXUZnKRgRlY01/qsePxuSA6XAx7TDLY iWVNwsaFx1kB6HnBJ7tX0ERxrhxEmHPUM4f6P3DlhUS8WM11znxuw+bU2O3I3Y78te3I5zfj0PFk Db4Zm67/jLDR52Jrva1dMrbOIr3B+BQBrQkAPx8zL+1oazsuarY5i+ePmgumrW2/vIvUV/MTxUR6 d5b6qreayOw49bR5myXVs5QjeY7UV80krJH6At9ckmTVJEkSKG90wqIgRFZvq1bdK2XDtmr1VpYN nc9t5emKxe/5nMWaPKw5AficNjs9/roU9vrcrNNQ/nQ3u6SGOj/qjpBWOkJyfjTZnJbO+9FHzwbs AUBxfDB3DuB8an5uXBz6vsRcsvOpL/rA1/lUdy0DR1Jru5bhfOpz+9Q8NIUf3YQDdSmm7+p2VREs feFI1inyBhW54IpLBWuj5W5BLnkL0mnpBrV0MYTVkWo5ZkWZZDfb8vh2Ex7YpYVL56rf4mbzKwxh v/MLii5qdVGri1pf+ssES2rpI27UeE6T+M2j1/zbxbDuDaGzhTeEimjpSzFsfttp4xclnL/9Ri/v ufTSK00vPZtqvqYb/0t63MJguvSSSy9p31RIhHOh63mzdmXVxK8i5D80gGKaHPwLAAD//wMAUEsD BBQABgAIAAAAIQCuWxNi2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BbsIwEETvlfgHayv1 VpwGUUqKQagVBY4hCKm3JV4SQ2xHtoHQr6/VAz2OZvRGbzLrdMMu5LyyRsBLPwFGprRSmUrAtlg8 vwHzAY3ExhoScCMPs2nvYYKZtFeT02UTKhYhxmcooA6hzTj3ZU0afd+2ZGJ3sE5jiNFVXDq8Rrhu eJokr1yjMvGhxpY+aipPm7MWsFfpFn/y4ivR48UgrLvieP7+FOLpsZu/AwvUhf/xSi+P8929/EOt pIB0MByOgB2Wt71TMkcfyAmIftE2mgKf/gIAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADi AQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCq i10N0wAAAI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDY a1Y+gQUAAKFCAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgA AAAhAK5bE2LaAAAA/QAAAA8AAAAAAAAAAAAAAAAA1wcAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAA BAAEAPUAAADeCAAAAAAAABDwCAAAAJAD8ABgFRAODwAR8K4AAAAAAMMLCAAAAP////8OAf+/DwCI E4oAAAAPAIoTggAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTZAAAAAAArA9cAAAAAACAAv// AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA Av//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAB8EBAAAAAMAAAAPAA3wiAIAAAAAnw8EAAAA BwAAAAAAqA8+AQAAT2JqZWN0aXZlOiBkZXNjcmliZSBzZXJ2aWNlIGNoYWluaW5nIHVzZSBjYXNl cyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgcmVxdWlyZWQgaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBi ZSBjb250cm9sbGVkIHZpYSBpMnJzDQ1TY29wZToNDU11bHRpLXRlbmFuY3kgc2VydmljZSBjaGFp bmluZw0NU2VydmljZSB0b3BvbG9neSBkaXNjb3ZlcnkgYW5kIG1haW50ZW5hbmNlDQ1TZXJ2aWNl IG5vZGUgbW9uaXRvcmluZw0NQ29udHJvbGxpbmcgdGhlIHJvdXRpbmcgb24gYSBzZXJ2aWNlIGNo YWluDQ1PcGFxdWVuZXNzIHRvIGFjdHVhbCBzZXJ2aWNlIHByb3ZpZGVkDQ0NAAChDxoBAACEAAAA AAD+EAoADwBxAAIASwAAAAAFWgAHAAEAAAAAAG0QCgAMAEsAAAAABVoABwAfAAAAAQD+EAoADwBx AAIASwAAAAAFWgAHAAEAAAABAG0QCgAMAEsAAAAABVoABwArAAAAAQD+EAoADwBxAAIASwAAAAAF WgAHAAEAAAABAG0QCgAMAEsAAAAABVoABwBEAAAAAQD+EAoADwBxAAIASwAAAAAFWgAHAAEAAAAB AG0QCgAMAEsAAAAABVoABwApAAAAAQD+EAoADwBxAAIASwAAAAAFWgAHAAsAAAABAAAAAQByAAAA AAQAAAAEBwAAAAEIAAABCAEAAAABDAIAAQwQALcAAAAAEAAAABADAAAAABQCAAAUEAAAAKoPDAAA AD8BAAAGAAAACQQAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgT nQAAAA8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAADjFxwGg g1KkAAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAB0EBAAAAAEA AAAPAO4DpRYAAAIA7wMYAAAAEAAAAAAAAAAAAAAAYwAAgAMBAAAHAAAADwAMBKQVAAAPAALwnBUA AFABCPAIAAAABQAAAARUAAAPAAPwhBUAAA8ABPAoAAAAAQAJ8BAAAAAMAAAACACQQQAiBT8IAJBB AgAK8AgAAAAAVAAABQAAAA8ABPD3AAAAogwK8AgAAAABVAAAAAoAAIMAC/BaAAAAfwABAO8BgABY sYMlvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwA YQBjAGUAaABvAGwAZABlAHIAIAA1AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAJAAAAAAAgBAEAAAAJ DwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdHAAChDx4AAAAPAAAAAAAg CAoAAAAA/wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPATAQAAogwK8AgA AAACVAAAAAoAAIMAC/BmAAAAfwABAO8BgABI64QlvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMM2 AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIA IAA2AAAAAAAQ8AgAAAAUECAQYBVAEQ8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQA AAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAA AAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwNgEAABIACvAIAAAA A1QAAAAKAACDAAvwSAAAAH8AAQDvAYAA2AOFJb8AAAAGAL8BAQARAP8BAAAZAD8DAAAIAIDDGAAA AL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAkAAgBHAUYAMPABHwHAAAAAAA wwsIAAAA/////w0A/78AAB8EBAAAAAIAAAAPAA3wmgAAAAAAnw8EAAAAAAAAAAAAqA9GAAAAU2Vy dmljZSBUb3BvbG9neSBhbmQgUmVzb3VyY2UgRGlzY292ZXJ5L1JlcHJlc2VudGF0aW9uIGFuZCBN YWludGVuYW5jZQAAoQ8YAAAARwAAAAAAAAAKAAcARwAAAAEAAgABABgAAACqDxgAAABGAAAABwAA AAAACQQAAAEAAAABAAAAAAAPAATw9BEAABIACvAIAAAABFQAACACAAADAQvweAAAAAQAAAAAAH8A AQDvAYAASMieH4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAG AP8BAAARAAEDAqgAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMA IvEZCwAAqcMTCwAAUEsDBBQABgAIAAAAIQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNd LnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2 GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJ Jl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmV SzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3 V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAA X3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/ 0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaS tlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3Pfe PqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQA BgAIAAAAIQAmKfj4rAYAAPxhAAAQAAAAZHJzL3NoYXBleG1sLnhtbOxd227bRhB9L9B/IPju6GIp loXIgWPAbQEjECIHeTRWFGWxJpfMcuXIfky+p2iBFuhL/sYfkF/omV1enbRRJVuKnRFgidydJWdn 9szOzl787PkiCp1LX6VBLAdu60nTdXzpxZNAng/c16fHOz3XSbWQExHG0h+4V37qPj/48YdnST9N HBSWaT8ZuDOtk36jkXozPxLpkzjxJfKmsYqExq06byTKT32phcaLorDRbjafNiIRSPcAj5KXo2So 6Mp7eTlUTjAZuO3dbnfPdaSI8NpXvgcmzkPf2XUbGZ0tIsDHSexdpBkzYhlmJkq8Qw1rfDgy/kmh Ki28Mz6a4W3+oVLxu5kvJikl470Nw2DOqwSrxEsyc/RVAi7H8eQK4roGCyKcuqjGYuB22vud/ad7 7f1u9gRbDI8qa52a2ov+Yqqidetx8Ez04+nUwat3e61mExq9Avvt1j5kTiyIvr/Qjof83m6z2yMC DxSdNpi0FA3LiamvZS3p68UL1I5KUy2hI6v71cWNRqchqFhdu847JSD59O1cKN91wl8kBL7f6nTA mjY3nS54cx1VzRlXc+Q8OopDoz0hPTx14GrXsZdHGndUyzhKhD6Ro8QjQqpLolJ9ungjVOLQJQpB Ni/j0UwkviEQlyepJs1Xac2tFQM9JEz1SF+hba4pEqObHFQrC9ZUC/qJhDpBE0DzIw3j7pURQngJ KSEhkBPAceDu5BQiPIcFCF1n4k9PxXiEVmxUQGLXtowvTuQLdWGkPI2lPjRFxiIlpQHZMstGEcIP EDacSw8vscIOSfLEXpp4Q087lwKPBXdFo6sSvPCnt0nROgtSPKKkOJzq27SmpUNpoMtyx/OjEHBF EhkpHzeWAeF5EETbgBONO6caz0fXBZN73ezNRHCMmhvAT4UH0L9BNclcpmhgM6FSH/XNcIaHIcUk D9y3FntajG2LEn0I+tVQZY2LTIno2y9o72IeBVH8a2B1BmEOXF/uvB5Z80KScJ2xUYQlmQ9cCQNN xloFF2BLxiNz5ToXvoJiQe8RyDIqggCSJFnoMLj2fza3pMowIDtv8oYqjqfmehIoDRuB1DTSR6Ev zBOJ41DSt4yPgzC0VbEpaRwGE0r8gsj1wlpT6KJK5U+nMPO5dOYn8nRhIDGnx2TXpplVpH+oAoE2 e1vyvqjQfPr426ePfzqfPv5x8/6vm/d/33z4cPP+988Leen/LoQWpqzm9IFzdubgD19kLdAiKXMV pULKrNRvR6lQaf4h9doPKbtyXSSWqRWCs3qLQLtIqF3csanfg6nvou3UTT3cmcLUt3tdWDJ0i2zq oYOHYepbTzNTz1ZhDVOfBNqbHYsoCNGL7bSa+xXrv9Nq97Lev2bLMwBbpBdgN0jP7mwWQb7Izi/s r+kPqIQhyfLMTzXBlq51GmwiyLMo3cXS1yt8MvYGc2+QTUTiW198HW9wDRNR9P4Zwiv24KwGawy9 5WQolIDfv6yLz3b//u1+qRU70r8H7ywfZte9M1IuD8R5IM4D8WrcZP2BOLlchTHG9apWuOhaaRhl 4h8caKmFuDYYaNmAkeYh9GOMlhYgZlfq/l2p6hDajHzJDDufxURLMH/FD96e8sgJfMDR7SXHM6Ui 7s31ZavKVpXnoL48B7UkSqtWtfRray5ukZxf4NcpApMmEWa4CFWc1SMTHHDkgGM+XfnV2NT2+uTH NP28AvSNQ5V/5TgvMG4cLcJ8fbh7T9ButTq7ZhlCPaLVrkS02u2emb3i+UaKPzyQ+cYOzzduZTLB 9MzooU23TVCmYZNJNLimHPrUIlkMbUiA5wmXXDXWYmhvZ54wQ3MG5gLUm4Ayj7157M1j7zsfexsM 3+qeLcoNyE32JuDNTvijXN/NPfWWVvRkGCb82m7afhOoGc68XQPLtlbZrsFw3h6cCcn0qfwylHnn 1ao7rxjKW4QyQFz2xwbUDGveUHkXGyoZ1tuDdR3V5GpzB80dNHfQ29wavcLc9EZmpngXxWMMZxfH GfAC3TUW6N4+A+FudlHQuDn7Ky+oj8andMarN3nq7d/KdHZe0pJsIrLG82APynCUq5K/2eXh3+FS tFIr97ZWnCe0HtaEVtkkvgZUXnyyucUnpVYYqEYCvEasbBIM1P79ny225AC61AoDlYFq1nGWTYKB +l0B1ZxxighIfT9F5fw25PFOCgoWLLmTIjsycjx/iZMxzUmS/3345vLI29qZbLwn+Y7OxeV4EMeD +GTcfzsZ99vxXhmnjNO7xen32oXiHw7kZ/jjMk0O/gEAAP//AwBQSwMEFAAGAAgAAAAhAPXlESDZ AAAA/QAAAA8AAABkcnMvZG93bnJldi54bWxEj8tuwjAURPeV+AfrInVXHILoI8UgVERaliFs2F3i S2KI7cg2EPr1tbpol6MZndGZLXrdsis5r6wRMB4lwMhUVipTC9iV66dXYD6gkdhaQwLu5GExHzzM MJP2Zgq6bkPNIsT4DAU0IXQZ575qSKMf2Y5M7I7WaQwxuppLh7cI1y1Pk+SZa1QmPjTY0UdD1Xl7 0QIOKt3hd1HmiX5bT8KmL0+X/UqIx2G/fAcWqA//432+2tj8r/xFfUkB6WQ6fQF2/LwfnJIF+kBO QPSLttEU+PwHAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAA AAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAA AAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAJin4+KwGAAD8YQAAEAAAAAAA AAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQD15REg2QAAAP0AAAAP AAAAAAAAAAAAAAAAAAIJAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAACAoAAAAAAAAQ 8AgAAAAAA/AAYBWADQ8AEfAuAQAAAADDCwgAAAD/////DgH/vw8AiBMKAQAADwCKEwIBAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLE+QAAAAAAKwP3AAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8A AAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAA AACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAACAAv//AAAA AAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAA gAL//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8EBAAAAAMAAAAPAA3w9QQAAAAAnw8EAAAABwAA AAAAqA/xAgAAVXNlIENhc2U6IFJlcHJlc2VudGF0aW9uL2Rpc2NvdmVyeSBvZiBzZXJ2aWNlcyB0 b3BvbG9neSBhbmQgYXNzb2NpYXRlZCByZXNvdXJjZXMgDUNhbiBiZSB1c2VkIGJ5IGFuIG9yY2hl c3RyYXRpb24gc3lzdGVtIHRvIG1hcCBhbiBhYnN0cmFjdCBzZXJ2aWNlIGNoYWluICBhcHBsaWVk IHRvIGEgcGFja2V0L2Zsb3cgdG8gYSBzZXJ2aWNlIHBhdGgNQWlkIGluIG1vbml0b3Jpbmcgb2Yg c2VydmljZXMgcmVzb3VyY2VzDU5lZWRlZCBJbmZvcm1hdGlvbjoNU2VydmljZSBOb2RlIElEDU5v bi1jb21wb3NpdGUgKGF1dG9ub21vdXMpIHNlcnZpY2VzIG9mZmVyZWQgYnkgYSBzZXJ2aWNlIG5v ZGU6IFNlcnZpY2UgdHlwZQ1WYXJpb3VzIG5vZGUgYW5kIHJlc291cmNlIGF0dHJpYnV0ZXMsIGUu Zy46DUN1c3RvbWVyIElEIG9yIGxpc3Qgb2YgKGN1c3RvbWVyICBJRCwgVlJGKQ1OdW1iZXIgb2Yg dmlydHVhbCBjb250ZXh0cw1QZXIgc2VydmljZSBub2RlLCBjdXN0b21lciBJRCwgYW5kIHNlcnZp Y2UgdHlwZQ1QYWNrZXQgYW5kIGJpdCByYXRlcyBzdXBwb3J0ZWQNQXZhaWxhYmxlIFJJQiBhbmQg RklCIHNpemUNTnVtYmVycyBvZiBzdXBwb3J0ZWQgQUNMcyBwZXIgQUNMIHR5cGUNTnVtYmVyIG9m IHN1cHBvcnRlZCBmbG93cw1FdGMuDUNhbGxlZCBvdXQgdGhlIG5lZWQgZm9yIGRpc2NvdmVyaW5n L3JlcHJlc2VudGluZyBjdXN0b21lciB2aXJ0dWFsIG5ldHdvcmsgdG9wb2xvZ3ksIGluY2x1ZGlu ZyBhY2Nlc3MgcG9ydHMNDQ0NDQ0NAAChD9QBAABSAAAAAAD+EAoADwBxAAIASwAAAAAFWgAHAJwA AAABAP4QCgAPAHEAAgBLAAAAAAVaAAcAFAAAAAAA/hAKAA8AcQACAEsAAAAABVoABwCIAAAAAQD+ EAoADwBxAAIASwAAAAAFWgAHAEYAAAACAP4QCgAPAHEAAgBLAAAAAAVaAAcAMAAAAAEA/hAKAA8A cQACAEsAAAAABVoABwCAAAAAAgD+EAoADwBxAAIASwAAAAAFWgAHAGsAAAAAAP4QCgAPAHEAAgBL AAAAAAVaAAcAAQAAAAEA/hAKAA8AcQACAEsAAAAABVoABwADAAAAAgD+EAoADwBxAAIASwAAAAAF WgAHAAEAAAABAG0QCgAMAEsAAAAABVoABwACAAAAAQD+EAoADwBxAAIASwAAAAAFWgAHAAoAAAAB AAAAAQBIAAAAAAQAAAAEmwAAAAAIAgAACBAAAQAAAAAMAgAADBQAEwAAAAEQAAABEAEAAAABFAIA ARQQAIgAAAAAGAIAABgQAEYAAAAAHAIAABwOADAAAAAAIAIAACAQAIAAAAAAJAIAACQOAGsAAAAA KAAAACgBAAAAACwCAAAsEAADAAAAADACAAAwDgADAAAAADQCAAA0EAAAAKoPDAAAAPICAAAGAAAA CQQAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8AihOV AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAMGNzgEw3RWpAAAdEAQA AAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAA AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAB0EBAAAAAEAAAAPAO4DbRUA AAIA7wMYAAAAEAAAAAAAAAAAAAAAYwAAgAQBAAAHAAAADwAMBGwUAAAPAALwZBQAAHABCPAIAAAA BQAAAARcAAAPAAPwTBQAAA8ABPAoAAAAAQAJ8BAAAAAAAADg61FvQAAAAAAAcHFAAgAK8AgAAAAA XAAABQAAAA8ABPD3AAAAogwK8AgAAAABXAAAAAoAAIMAC/BaAAAAfwABAO8BgAC47YMlvwAAAAYA vwEAABAA/wEQABkAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUAaABv AGwAZABlAHIAIAA1AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAJAAAAAAAgBAEAAAAJDwAN8FwAAAAA AJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdHAAChDx4AAAAPAAAAAAAgCAoAAAAA/wEA BwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPATAQAAogwK8AgAAAACXAAAAAoA AIMAC/BmAAAAfwABAO8BgAC474MlvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMM2AAAAvwMAAAIA UwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA2AAAAAAAQ 8AgAAAAUECAQYBVAEQ8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA ACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACqDwoA AAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwBwEAABIACvAIAAAAA1wAAAAKAACD AAvwSAAAAH8AAQDvAYAAeCaEJb8AAAAGAL8BAQARAP8BAAAZAD8DAAAIAIDDGAAAAL8DAAACAFIA ZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAkAAAA1ATYAMPABHwHAAAAAAAwwsIAAAA//// /w0A/78AAB8EBAAAAAIAAAAPAA3wawAAAAAAnw8EAAAAAAAAAAAAqA8XAAAAU2VydmljZSBOb2Rl IE1vbml0b3JpbmcAAKEPGAAAABgAAAAAAAAACgAHABgAAAABAAIAAQAYAAAAqg8YAAAAFwAAAAcA AAAAAAkEAAABAAAAAQAAAAAADwAE8OsQAAASAArwCAAAAARcAAAgAgAAAwEL8HgAAAAEAAAAAAB/ AAEA7wGAAAguhCWBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAA BgD/AQAAEQABAwKoAAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAT ACLxlQsAAKnDjwsAAFBLAwQUAAYACAAAACEAMjy9PvsAAADiAQAAEwAAAFtDb250ZW50X1R5cGVz XS54bWyUkUFOwzAQRfdI3MHyFiUOLBBCTbogsAQE5QAje5JYJGPLY0J7eyZt2SBUxNKeef8/2av1 dhrVjIl9oFpflpVWSDY4T32t3zYPxY1WnIEcjIGw1jtkvW7Oz1abXURWQhPXesg53hrDdsAJuAwR SSZdSBNkOabeRLDv0KO5qqprYwNlpFzkJUM3qxY7+Bizut/K9cFEcK3uDntLVa0hxtFbyCJqlqn5 lUs48glwJvfDrjialULuw3nwkS+ODU/yNMk7VM+Q8iNM4mFcYsMDRJSd8rTnUjdxEbrOWyzbxK8L 91e4C5+UcP5vdivYC87f6Wb/Q80XAAAA//8DAFBLAwQUAAYACAAAACEAqotdDdMAAACPAQAACwAA AF9yZWxzLy5yZWxzpJCxagMxDIb3QN/BaO/5kqGUEF+2QtaQQldh6+5MzpaxzDV5+7iUQi9ky6BB v9D3Ce32lzCpmbJ4jgbWTQuKomXn42Dg8/Tx+g5KCkaHE0cycCWBffey2h1pwlKXZPRJVKVEMTCW krZaix0poDScKNZJzzlgqW0edEJ7xoH0pm3fdP7PgG7BVAdnIB/cGtTpmqr5jh28zSzcl8Zy0Nz3 3j6iahkx0VeYKgbzQMWAy/Kb1tOaWqAfmzdPmh1/xyPNS/FPmGn+8+rFG7sbAAAA//8DAFBLAwQU AAYACAAAACEAEV/MzCcHAAA+XwAAEAAAAGRycy9zaGFwZXhtbC54bWzsXN1u2zYUvh+wdxB0n/on duMYdYo0QLYBQWHUKXpZ0LIca5EolaJTJ1dD+ya7HzZgA3bTp1keoK+w75D6dYvGdmvZrmnAtkhR EnkOz3d+eMQnT2eBb924IvZC3rMbj+q25XInHHn8qme/vDw/6NhWLBkfMT/kbs++dWP76cmPPzyJ unFk4WIed6OePZEy6tZqsTNxAxY/CiOX49w4FAGTKIqrWiTc2OWSSTwo8GvNev1xLWAet09wK34z iPqCjpznN31heaOe3Txst49si7MAj33hOujEle9ah3YtaacvYejHRehcx0ln2CKdGQn2FiMs9cPi 4U8CQ2ngmeHZBE9zT4UI305cNoqpGs+tqQ6mfeXoKvUlmljyNkIvh+HoFuS6QxeYP7YxjFnPbjWP W8ePj5rH7eQO+jLcKh91rEbPurOxCL52HCdPWDccjy08+rDTqNfB0Vt0v9U66uAYg2BddyYtB+c7 h/U2VVoOWrSa6KRuUdM9UePVXYu6cvYMo6OraZTgkeb96uTGpJMgVCjubOutYKB8/GbKhGtb/i8c BD9Gl9E1qQqtNvpmW6J4Zlg8w6fBWegr7jHu4K49W9qWPjyTKNEowyBi8oIPIoca0lgiEcvL2Ssm IosOcRFo8zwcTFjkqgbs5iKWxPliW1XUZKCb+LEcyFvMza8kieJNKlQrE1YNC/wJmLjAFMD0Iw6j 9EIRwb8BlVDh8RHEsWcfpC2YfwUE8G1r5I4v2XCAWaxYQGSX+hqXXfBn4lpReRxyeaouGbKYmAbJ 5slpXELyAwnrT7mDh2hi+0R56l4cOX1HWjcMt0XvsklXbPDMHc83xezMmuIWeYvTsZxvq2Y6mIZ2 ydnh9MyHuKKKQMpFQXeAOQ4I0VTCicmdthpOB3dZJ4/ayZOpwTlGrgR+zBwI/SsMk+AyxgSbMBG7 GG8iZ7gZalR1z36jZU+yoZ5RrAtCv+iLZHIRlLCu/gH3rqeBF4S/eppnIGbPdvnBy4GGF6KEbQ0V I3STac/mAGgCa+Fdo1s8HKgj27p2BRiL9g4JWdKKRABVnBDa9+7cn1WRWOl7hPPqXF+E4Vgdjzwh gRGojQN55rtM3ZF67HP65eG55/t6KLomDn1vRJWfIbmcaTQFL4qt3PEYMJ9SZ3rBL2dKJKZ0m+RY TbMC9U+FxzBn5ynvskKbjx/++Pjhb+vjh7/u3/1z/+7f+/fv79/9+elFTrz0RZhhQnNOnlivX1v4 4ofQAjOSTq7CVFDZMHV7mAqWvlZ8pQP9IVarOirSuayBKqQV9E8fal6aE5gZEc2Mbwz2RwD7NmZP Gexh0GRg3+y0gWVQjAbswYPdAPvG4wTsK8cFmqI7jO+RJ53JOQs8H6rroFE/LkD+QaPZSVR+DuAl GU3B+0FlvDn+fE/KeFlmpcCa4C+KJe4ZhCXRze3t3FjOjFpjTqfm9OYk2CCsMqAfcHc2xx+DsDm+ JpZsDrwlwEVUiY/6TDC4tFvLzv0Qt5wROm5lPA2jB2HJw87dWsHcZ5xVwQSFqvgpFHQogUJKWaWu SoA4KZRQeE1m7ycxBXJFkwCyiSYsFzpOApnD6XPEa1V888sh4RzNH5DeLChceZzge5Le+UjyakHh nGlrU8Hpuk052FcQTLOyY1Z2zMqOQtjVhDgPDGqfJ9e+5VjTKq4PBeXVeppZuCstmVa4cFcBRpsF me9x9d2EoyJX5z58zer7sgH/zAlKIlJqrT1xhXJ8TjFa/evleJws1ab+VFpZhQPVaLQOVc5G2Vpr 5m7UQbPZUQt9yyzNwtpbKg+nbusIWB4PyVYDKFMsy65Z/8pB5gUN7rJDSqzJCoXMmf9++/0b5s40 VMYbcmeMm6RyZ5SBtJDaXURiWbdka2mAwCMQmJgzpxKxTKRQy6uSY/2TSif9q29JTBdfnN0ct12B tEPYeVuZMbUJrpdzYJaxmjfGxK1ZMKiMXxVYxUYZzmWlZkrPKMMNJ5JWJmZzyjDVdqT75hRdLpAP xH83Z9gYlFzDEqtBSYOSxnhUCfTIrceHHAH1mQPIBd+ZMPConehKXT3SZ8kndeSoOO8JbD0LjRNH Gk6eaF7OveGypqQDowCNAjQKMFWAu4ia++cXZG6dBkoduiweK0fPqL/Cu6Grv/VZvbNOnCxZn0b1 ETnMctH+vGpdvdApny/FUCN/etcCs1wL03AftzrYgPylsrdzZouxP6swVpBHUc5qKeQg49DksyBy snC2/9ZHwnZQpr6Y0v/5DJUq5GZN8S1knCyVE2b2Zlpwb6bFF2Jbm9qwYzvD1KvtzrRIthl8z5wr a3vTxgjqbm2ilk+JhzImjKBWl8idc2Vtgqp2ifzEHC3sf7WkObr3qjRLTPvW76pu7hWKrbFfd10r mnebdurdphx+H1KKG9tuzlivZlPIvd+ybAfkdF9VKLZsT3dBx2EcnfwPAAD//wMAUEsDBBQABgAI AAAAIQDoAOxR2gAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/BTsMwEETvSPyDtUjcqENKaQl1 KwQKlGOacshtG28TQ2xHttsmfD0WBziOZvRGb7kedMdO5LyyRsDtJAFGprZSmUbArsxvFsB8QCOx s4YEjORhvbq8WGIm7dkUdNqGhkWI8RkKaEPoM8593ZJGP7E9mdgdrNMYYnQNlw7PEa47nibJPdeo THxosafnluqv7VEL2Kt0h99F+Zroh3wa3ofy81i9CHF9NTw9Ags0hP9xld+N1cdf+YvaSAHpdDab Azu8jXunZIE+kBMQ/aJtNAW++gEAAP//AwBQSwECLQAUAAYACAAAACEAMjy9PvsAAADiAQAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCqi10N0wAA AI8BAAALAAAAAAAAAAAAAAAAACwBAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQARX8zMJwcA AD5fAAAQAAAAAAAAAAAAAAAAACgCAABkcnMvc2hhcGV4bWwueG1sUEsBAi0AFAAGAAgAAAAhAOgA 7FHaAAAA/QAAAA8AAAAAAAAAAAAAAAAAfQkAAGRycy9kb3ducmV2LnhtbFBLBQYAAAAABAAEAPUA AACECgAAAAAAABDwCAAAAJAD8ABgFRAODwAR8PIAAAAAAMMLCAAAAP////8OAf+/DwCIE84AAAAP AIoTxgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTqAAAAAAArA+gAAAAAACAAv//AAAAAAAA AAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAv//AAAA AAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAv//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwQEAAAAAwAAAA8ADfCsAwAAAACf DwQAAAAHAAAAAACoDwQCAABVc2UgQ2FzZTogTW9uaXRvciB0aGUgbGl2ZWxpbmVzcyBvZiBhIHNl cnZpY2Ugbm9kZSBhbmQgaXRzIHJlc291cmNlIHV0aWxpemF0aW9uIHRvOg1EZXRlY3Qgbm9kZSBm YWlsdXJlDVNlbGVjdCBhbiB1bmNvbmdlc3RlZCBzZXJ2aWNlIHBhdGgNQWRkIHJlc291cmNlcyBv ciBzZXJ2aWNlIG5vZGVzLCBvciByZS1ncm9vbSByZXNvdXJjZXMgYXMgbmVlZGVkDQ1OZWVkZWQg SW5mb3JtYXRpb24NUGVyIHNlcnZpY2Ugbm9kZSwgc2VydmljZSBjb250ZXh0LCBhbmQgc2Vydmlj ZSB0eXBlLCBhbmQgcGVyIGhvc3Rpbmcgc3lzdGVtIGFzIGl0IGFwcGxpZXMNQmFuZHdpZHRoIGFu ZCBwYWNrZXQgcmF0ZSB1dGlsaXphdGlvbiBvdmVyYWxsIGFuZCBwZXIgQ29TDU1lbW9yeSB1dGls aXphdGlvbg1SSUIgYW5kIEZJQiAgdXRpbGl6YXRpb24gcGVyIGFkZHJlc3MgZmFtaWx5ICANRmxv dyByZXNvdXJjZSB1dGlsaXphdGlvbiBwZXIgZmxvdyB0eXBlDUNQVSBVdGlsaXphdGlvbg1BdmFp bGFibGUgc3RvcmFnZQ0gDQ0NDQ0AAKEPXgEAAFQAAAAAAP4QCgAPAHEAAgBLAAAAAAVaAAcAdwAA AAEA/hAKAA8AcQACAEsAAAAABVoABwABAAAAAABtEAoADABLAAAAAAVaAAcAEwAAAAAA/hAKAA8A cQACAEsAAAAABVoABwBaAAAAAQD+EAoADwBxAAIASwAAAAAFWgAHAMUAAAACAAAAAAACAAAAAAAB AAAAAAACAAAAAgD+EAoADwBxAAIASwAAAAAFWgAHAAEAAAABAG0QCgAMAEsAAAAABVoABwACAAAA AQD+EAoADwBxAAIASwAAAAAFWgAHAAoAAAABAAAAAQBKAAAAAAQAAAAEdwAAAAAIAgAACBAAAQAA AAAMAAAADBIAAAABEAAAARABAAAAARQCAAEUEABaAAAAABgCAAAYEADFAAAAABwiAAAcAAASAAIA AAAAICIAACAAABIAAgAAAAAkAgAAJA4AAwAAAAAoAgAAKBAAAACqDyYAAABvAQAABgAAAAkEAAAD AAAABwAAAAMACQQAAJMAAAAGAAAACQQAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAAAPAIgTnQAAAA8AihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAA AOsuCAAAAPKNzgEQyMUqAAAdEAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAA AAAAAB0EBAAAAAEAAAAPAO4DgBcAAAIA7wMYAAAAEAAAAAAAAAAAAAAAYwAAgAUBAAAHAAAADwAM BH8WAAAPAALwdxYAAJABCPAIAAAABQAAAARkAAAPAAPwXxYAAA8ABPAoAAAAAQAJ8BAAAAAJAAAA AAAAAAgAAAAIAAAAAgAK8AgAAAAAZAAABQAAAA8ABPD3AAAAogwK8AgAAAABZAAAAAoAAIMAC/Ba AAAAfwABAO8BgADo4KglvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8A dABlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA1AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAJ AAAAAAAgBAEAAAAJDwAN8FwAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdHAACh Dx4AAAAPAAAAAAAgCAoAAAAA/wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8A BPATAQAAogwK8AgAAAACZAAAAAoAAIMAC/BmAAAAfwABAO8BgABI4aglvwAAAAYAvwEAABAA/wEQ ABkAPwMAAAgAgMM2AAAAvwMAAAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUA aABvAGwAZABlAHIAIAA2AAAAAAAQ8AgAAAAUECAQYBVAEQ8AEfAJAAAAAAAgBAEAAAAIDwAN8GwA AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAAC AA4AAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATw IwEAABIACvAIAAAAA2QAAAAKAACDAAvwSAAAAH8AAQDvAYAAGOaoJb8AAAAGAL8BAQARAP8BAAAZ AD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAkACQAKAU YAMPABHwHAAAAAAAwwsIAAAA/////w0A/78AAB8EBAAAAAIAAAAPAA3whwAAAAAAnw8EAAAAAAAA AAAAqA8zAAAAVHJhZmZpYyBDbGFzc2lmaWNhdGlvbiBhbmQgU2VydmljZSBDaGFpbmluZyBDb250 cm9sAAChDxgAAAA0AAAAAAAAAAoABwA0AAAAAQACAAEAGAAAAKoPGAAAADMAAAAHAAAAAAAJBAAA AQAAAAEAAAAAAA8ABPDiEgAAEgAK8AgAAAAEZAAAIAIAAAMBC/B4AAAABAAAAAAAfwABAO8BgAAI 8qglgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYA/wEAABEA AQMCqAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAEwAi8coKAACp w8QKAABQSwMEFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAABbQ29udGVudF9UeXBlc10ueG1slJFB TsMwEEX3SNzB8hYlDiwQQk26ILAEBOUAI3uSWCRjy2NCe3smbdkgVMTSnnn/P9mr9XYa1YyJfaBa X5aVVkg2OE99rd82D8WNVpyBHIyBsNY7ZL1uzs9Wm11EVkIT13rIOd4aw3bACbgMEUkmXUgTZDmm 3kSw79Cjuaqqa2MDZaRc5CVDN6sWO/gYs7rfyvXBRHCt7g57S1WtIcbRW8giapap+ZVLOPIJcCb3 w644mpVC7sN58JEvjg1P8jTJO1TPkPIjTOJhXGLDA0SUnfK051I3cRG6zlss28SvC/dXuAuflHD+ b3Yr2AvO3+lm/0PNFwAAAP//AwBQSwMEFAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAABfcmVscy8u cmVsc6SQsWoDMQyG90DfwWjv+ZKhlBBftkLWkEJXYevuTM6Wscw1efu4lEIvZMugQb/Q9wnt9pcw qZmyeI4G1k0LiqJl5+Ng4PP08foOSgpGhxNHMnAlgX33stodacJSl2T0SVSlRDEwlpK2WosdKaA0 nCjWSc85YKltHnRCe8aB9KZt33T+z4BuwVQHZyAf3BrU6Zqq+Y4dvM0s3JfGctDc994+omoZMdFX mCoG80DFgMvym9bTmlqgH5s3T5odf8cjzUvxT5hp/vPqxRu7GwAAAP//AwBQSwMEFAAGAAgAAAAh AEmcS0JdBgAAlE0AABAAAABkcnMvc2hhcGV4bWwueG1s7Fxfb9s2EH8fsO9A6D31n9iNY8Qp0gDZ BgSFUafoY0DLdKxFolSKTp08tp9n2IAN2Eu/TT5Av8J+R0qW5G6LnTR23bBAZYo8Sse7+92RRyoH L2ZRyK6ESoNY9rzGs7rHhPTjUSAvet6bs5OdjsdSzeWIh7EUPe9apN6Lwx9/OEi6acLQWabdpOdN tE66tVrqT0TE02dxIiTaxrGKuMatuqglSqRCaq7xoiisNev157WIB9I7xKPk1SDpKyr5r676igWj ntfcbbf3PCZ5hNe+Fj6YuAgF2/VqGZ3twsHHaexfphkzfBlmRoq/xwgrfDAZ/6QwlAbeGR9P8DZx pFT8fiL4KKVqvLdmGMx5lWCVeEkmTF8n4HIYj64hrhuwwMOxh2HMel6rud/af77X3G9nT7Dd8Khi 1KkZPe/Oxip66DgOD3g3Ho8ZXr3badTr0Og12G+19jooYxC8K2aa+Wjv7NbbVMl8ULSaYNJS1Cwn ZryWtaSrZy8xOupNo4SOrO7vL24YnYagYnXjsfeKQ/LpuylXwmPhLxIC3wfLYE2bm1YbvHlMlVuG 5RY5jY7j0GiPSx9P7XnaY7Z4rHFHo4yjhOtTOUh8IqSxJCrVZ7O3XCWMiugE2byKBxOeCEPAr05T TZov05pbKwZ6SJjqgb6GbT5QJEY3OajuLVgzLOgn4uoUJgDzIw3j7rURQngFKaEikCPAseft5BQ8 vIAHCD02EuMzPhzAio0KSOza9hH8VL5Ul0bK41jqI9NlyFNSGpAts2Z0IfwAYf2p9PESK+yQJE/s pYnf9zW74ngsuJsbXZngpRgvksI656R4REFxNNaLtMbSoTTQZa3D6XEIuKKKnJTAjWWA+z4E0TTg hHHnVMPp4GbO5F47ezMRnGDkBvBj7gP0bzFMcpcpDGzCVSow3gxneBhqTHXPe2exp/nQWhTvQtCv +yozLnIlvGsv0N7lNAqi+NfA6gzC7HlC7rwZWPdCkvDY0CjCkkx7noSDJmetgkuwJeOBKXnsUigo FvQ+gSyjIgigSpKHDoMb8bO5JVWGAfl509ZXcTw25VGgNHwEatNIH4eCmycSx6Gkq4xPgjC0Q7E1 aRwGI6r8F5HrmfWm0EWZSozHcPO5dKan8mxmIDGlx2RlY2Yl6R+pgMNmFyUveInm86ffPn/6k33+ 9Mfth79uP/x9+/Hj7Yffv+zkpyt3goUpqzl9yM7PGf7jwhj5C9gkNd9HrZCzU+u3o1Yo9dxolgpU NHo2dSjnlabFtmeVtikjsGTGPEo9qFPFWGAyCZnMV44De4gDbZhVNQ5grjOPA81OG24OMdPFAehg y+KAcxgPiANJoP3JCY+CECFup1HfL4WGnUazk00N5o6+BN8C2yjNfYGFP8KAoaSraTU/VFXUmzuH fzcPfOA80OF/jfi38M0nAdlvDvYKtg3saT6YtWbIz90BuYK8pdSUO4iMLHudfY+bLLhFo1s0lpaW 6140rjpZqPgDCvf459aHm1z231+Dc09s1ZhfTTVd8vZScR1zu0ajtWsSQtXFXbO8uGt2nlPKyC3u SCEbXtwJOepzxeHG70jzNUxyHmm+tU/vKAOxxZm9ZSDOu5V8n00k2gxmoSCb+H+EfEyeda9ClvTs 8vIuL796Xn7LAbuYv69Ac7n8PeXav0jFV8Jvnoy/0++67ZVE2M2tb2l7pbr0XV2ZLojSRMLsqG1k e+yBWFy7+txWZ2U7u+Jf87RVvuLJf2lJZMsLyfCK8vEot8dVOgxRnGSYnzhwZx02f9Zhy+dUyyyC KqAm8C7sRq8eZWlL2SxY3YmUylmgpULuqiozGssvLqu4hVnFSlxcHW1rnxQ9MZ9IDjHD19YtP76n +euqjnFhx3Wuw1yXuc/E7wICi9zfHcnZeZLAYXC1deWSuiwU8WhJWHcobqsORxcWcQc0G2avaxP7 Jk/Q5xZacTilWOI+Yigs4i6cIoaazxhcCN3WEOr2Mb/PENpsPXlofqWdkjUfLHCHgbbri7/lg+XG EOkmtY+xW+WA6oDqPs71/utwz7eTJTJ/ewArlOpRvdKnk2hz52pp6bvkudrsU+7h9BW+WDezrP// KH75ELmxvM/T2BYpFOFSPS7VQzZfWMRdqZ6NQdPNXh9j9uq2Tr7PvM/mtk6eagjFHwLL/7YWimly +A8AAAD//wMAUEsDBBQABgAIAAAAIQDYv1fB2QAAAP0AAAAPAAAAZHJzL2Rvd25yZXYueG1sRI/B TsMwEETvSPyDtUjcqE2qAk3rVhWoQI9peuG2jbeJIbYj201Svh6LAxxHM3qjt1yPpmU9+aCdlXA/ EcDIVk5pW0s4lNu7J2AholXYOksSLhRgvbq+WmKu3GAL6vexZgliQ44Smhi7nPNQNWQwTFxHNnUn 5w3GFH3NlcchwU3LMyEeuEFt00ODHT03VH3tz0bCUWcH/C7KV2Hm22ncjeXn+eNFytubcbMAFmmM /+N+4K3Y/JW/qHclIZvOZo/ATm+Xo9eqwBDJS0h+yTaZAl/9AAAA//8DAFBLAQItABQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0A FAAGAAgAAAAhAKqLXQ3TAAAAjwEAAAsAAAAAAAAAAAAAAAAALAEAAF9yZWxzLy5yZWxzUEsBAi0A FAAGAAgAAAAhAEmcS0JdBgAAlE0AABAAAAAAAAAAAAAAAAAAKAIAAGRycy9zaGFwZXhtbC54bWxQ SwECLQAUAAYACAAAACEA2L9XwdkAAAD9AAAADwAAAAAAAAAAAAAAAACzCAAAZHJzL2Rvd25yZXYu eG1sUEsFBgAAAAAEAAQA9QAAALkJAAAAAAAAEPAIAAAAkAPwAGAVEA4PABHwPgEAAAAAwwsIAAAA /////w4B/78PAIgTGgEAAA8AihMSAQAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixP0AAAAAACs D+wAAAAAAIAC//8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC //8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAA AAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAACAAv// AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAHwQEAAAAAwAAAA8ADfAiBgAAAACfDwQAAAAHAAAAAACgD1wEAABVAHMA ZQAgAEMAYQBzAGUAIAAxADoAIABDAG8AbgB0AHIAbwBsACAAdABoAGUAIABhAGMAdABpAG8AbgAo AHMAKQAgAHQAYQBrAGUAbgAgAG8AbgAgAGEAIABwAGEAYwBrAGUAdAAvAGYAbABvAHcAIABiAGEA cwBlAGQAIABvAG4AIABtAHUAbAB0AGkALQBmAGkAZQBsAGQAIABjAGwAYQBzAHMAaQBmAGkAYwBh AHQAaQBvAG4ALgAgAEEAYwB0AGkAbwBuAHMAIABpAG4AYwBsAHUAZABlADoADQBwAGEAYwBrAGUA dAAvAGYAbABvAHcAIABkAGkAcgBlAGMAdABpAG8AbgAgAG8AbgAgAGEAIABzAGUAcgB2AGkAYwBl ACAAcABhAHQAaAAgABMgIAB1AHMAaQBuAGcAIABoAG8AcAAtAGIAeQAtAGgAbwBwACAAcABvAGwA aQBjAHkAIABiAGEAcwBlAGQAIAByAG8AdQB0AGkAbgBnACAADQBBAGMAdABpAG8AbgBzADoAIABt AGkAcgByAG8AcgAsACAAbQBhAHIAawAsACAAcgBvAHUAdABlACwAIABzAHQAZQBlAHIAIABwAGEA YwBrAGUAdAAgAHQAbwAgAGEAIABWAFIARgAsACAAaQBuAHMAZQByAHQAIABzAG8AdQByAGMAZQAg AG8AcgAgAHMAbwB1AHIAYwBlACAAKwAgAHMAZQByAHYAaQBjAGUAIABoAGUAYQBkAGUAcgAgAHcA aQB0AGgAIABmAG8AcgBtAGEAdAAgAHQAbwAgAGIAZQAgAGQAZQBmAGkAbgBlAGQALAAgAGUAdABj AC4ADQBOAGUAZQBkAGUAZAAgAGYAdQBuAGMAdABpAG8AbgBhAGwAaQB0AHkAOgAgAEQAZQBmAGkA bgBlACAAYQBuAGQAIABwAHIAbwBnAHIAYQBtACAAYwBsAGEAcwBzAGkAZgBpAGMAYQB0AGkAbwBu ACAAcgB1AGwAZQAgAGEAbgBkACAAYQBzAHMAbwBjAGkAYQB0AGUAZAAgAGEAYwB0AGkAbwBuAHMA DQANAFUAcwBlACAAQwBhAHMAZQAgADIAOgAgAEIARwBQAC0AYgBhAHMAZQBkACAAdAByAGEAZgBm AGkAYwAgAHIAZQBkAGkAcgBlAGMAdABpAG8AbgAgAGEAbABvAG4AZwAgAGEAIABzAGUAcgB2AGkA YwBlACAAcABhAHQAaAANAE4AZQBlAGQAZQBkACAAZgB1AG4AYwB0AGkAbwBuAGEAbABpAHQAeQA6 ACAARABlAGYAaQBuAGUAIABhAG4AZAAgAHAAcgBvAGcAcgBhAG0AIABCAEcAUAAgAHAAbwBsAGkA YwB5ACAAdABoAGEAdAAgAGUAZgBmAGUAYwB0AHMAIAB0AHIAYQBmAGYAaQBjACAAcgBlAGQAaQBy AGUAYwB0AGkAbwBuAA0ADQANAA0ADQANAA0ADQAAAKEPlgEAAG8AAAAAAP4QCgAPAHEAAgBLAAAA AAVaAAcAIwEAAAEA/hAKAA8AcQACAEsAAAAABVoABwABAAAAAgD+EAoADwBxAAIASwAAAAAFWgAH AD8AAAAAAP4QCgAPAHEAAgBLAAAAAAVaAAcAVwAAAAEA/hAKAA8AcQACAEsAAAAABVoABwABAAAA AAD+EAoADwBxAAIASwAAAAAFWgAHAAIAAAACAP4QCgAPAHEAAgBLAAAAAAVaAAcAAQAAAAEAbRAK AAwASwAAAAAFWgAHAAIAAAABAP4QCgAPAHEAAgBLAAAAAAVaAAcADAAAAAEAAAABAGMAAAAABAAA AATPAAAAAAgCAAAIFAAWAAAAAQwCAAEMFAA+AAAAABACAAAQFAABAAAAABQiAAAUAAASAAsAAAAB GAAAARg0AAAAABwAAAAcFgAAAAEgAgABIBQAPwAAAAAkAgAAJBQAAQAAAAAoAgAAKBAAAQAAAAAs AgAALAwAAQAAAAAwIgAAMAAAGAACAAAAADQCAAA0DgADAAAAADgCAAA4EAAAAKoPDAAAAC8CAAAG AAAACQQAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8A ihOVAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAPaNzgFQT1nBAAAd EAQAAAAAAAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AAAAAP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAB0EBAAAAAEAAAAPAO4D NxMAAAIA7wMYAAAAEAAAAAAAAAAAAAAAYwAAgAYBAAAHAAAADwAMBDYSAAAPAALwLhIAALABCPAI AAAABQAAAARsAAAPAAPwFhIAAA8ABPAoAAAAAQAJ8BAAAAAAAIA/AACAPwgAAAAIAAAAAgAK8AgA AAAAbAAABQAAAA8ABPD3AAAAogwK8AgAAAABbAAAAAoAAIMAC/BaAAAAfwABAO8BgAAIRoQlvwAA AAYAvwEAABAA/wEQABkAPwMAAAgAgMMqAAAAvwMAAAIARgBvAG8AdABlAHIAIABQAGwAYQBjAGUA aABvAGwAZABlAHIAIAA1AAAAAAAQ8AgAAAAUELAH0A5AEQ8AEfAJAAAAAAAgBAEAAAAJDwAN8FwA AAAAAJ8PBAAAAAQAAAAAAKgPDgAAAElFVEY4NyBpMnJzIFdHAAChDx4AAAAPAAAAAAAgCAoAAAAA /wEABwAPAAAAAQACAAEADgAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPATAQAAogwK8AgAAAACbAAA AAoAAIMAC/BmAAAAfwABAO8BgACYR4QlvwAAAAYAvwEAABAA/wEQABkAPwMAAAgAgMM2AAAAvwMA AAIAUwBsAGkAZABlACAATgB1AG0AYgBlAHIAIABQAGwAYQBjAGUAaABvAGwAZABlAHIAIAA2AAAA AAAQ8AgAAAAUECAQYBVAEQ8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAP AgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAA4AAADYDwQAAAAAAAAAAACq DwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwJAEAABIACvAIAAAAA2wAAAAK AACDAAvwSAAAAH8AAQDvAYAAaOKDJb8AAAAGAL8BAQARAP8BAAAZAD8DAAAIAIDDGAAAAL8DAAAC AFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAkAAgATAVYAMPABHwHAAAAAAAwwsIAAAA /////w0A/78AAB8EBAAAAAIAAAAPAA3wiAAAAAAAnw8EAAAAAAAAAAAAqA80AAAAU2NhbGFiaWxp dHkgUmVxdWlyZW1lbnRzIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwAAoQ8YAAAANQAAAAAA AAAKAAcANQAAAAEAAgABABgAAACqDxgAAAA0AAAABwAAAAAACQQAAAEAAAABAAAAAAAPAATwmA4A ABIACvAIAAAABGwAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAASOWDJYEAMGUBAIIAmLIAAIMA MGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAP8BAAARAAEDAqgAAD8DAAAIAIDDGAAA AL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMAIvEgCgAAqcMaCgAAUEsDBBQABgAIAAAA IQAyPL0++wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJN uiCwBATlACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVac gRyMgbDWO2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQl QzerFjv4GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0 yTtUz5DyI0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD/ /wMAUEsDBBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo 7/mSoZQQX7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz 9PH6DkoKRocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSm bd90/s+AbsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+b N0+aHX/HI81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQBPf2kHsgUAAPs+AAAQAAAA ZHJzL3NoYXBleG1sLnhtbOxb3U4jNxS+r9R3sHzP5ocEQkRYsUi0ldAq2rDay8qZeMiUGc+sx4HA Jfs8VSu1Um/2bXgAXqGf7ZnMTIpKCE2ypOYi+OfYPj7nfOd4/HP4dhqF5IrLNIhFjzbe1CnhwotH gbjo0Y/npzsdSlLFxIiFseA9esNT+vbo++8Ok26aEDQWaTfp0bFSSbdWS70xj1j6Jk64QJ0fy4gp ZOVFLZE85UIxhYGisNas1/dqEQsEPUJX4mqQ9KVOee+v+pIEox5t7rbb+5QIFmHYD9wDExchJ7u0 ltHZJgx8nMXeZZoxwxZhZiTZNWZY4YOI+AeJqTQwZnwyxmj8WMr4eszZKNXFGLdmGMx5FWBV85KM ibpJwOUwHt1AXLdggYU+xTSmPdpqHrQO9vabB+2sB9sMXRWzTs3sWXfqy+il8zg6ZN3Y9wmG3u00 6nVo9Abst1r7HaQxCdblU0U81Hd2621dSDxQtJpg0lLULCdmvpa1pKum7zA73VrPEjqyul9e3DA6 BUHF8paSa8kg+fTzhElOSfiTgMAPwDJYUybTaoM3SmS5ZliuEZPoJA6N9pjw0GuPKkps8kQhp2cZ RwlTZ2KQeJpQzyWRqTqffmIyITqJRpDN+3gwZgk3BOzqLFVa82Vak7Vi0J2EqRqoG9jmC0VidJOD amnBmmlBPxGTZzABmJ/WMHIfjBDCK0gJBYEYAY49upNTsPACHiCkZMT9czYcwIqNCrTYlW3D2Zl4 Jy+NlP1YqGPTZMhSrTQgW2TVaKLxA4T1J8LDIFbYoZa8Zi9NvL6nyBVDt+BuZnRlgnfcnyeFdc5I 0UVBceyreVpj6VAa6LLa4eQkBFxRpJ0UR8YywDwPgmgacMK4c6rhZHA7Y3K/nY2sCU4xcwN4n3kA /SdMU7vLFAY2ZjLlmG+GM3SGElPco58t9hQbWotiXQj6Q19mxqVdCevaH2jvchIFUfxLYHUGYfYo FzsfB9a9aElQMjSKsCSTHhVw0NpZy+ASbIl4YFKUXHIJxYLe0yDLqDQEUCS0hw6DW/6jyWpVhoH2 86auL+PYN+lRIBV8BErTSJ2EnJkeNceh0L8iPg3C0E7FlqRxGIx04SMiV1PrTaGLMhX3fbj5XDqT M3E+NZCY6G6ytDGzkvSPZcBgs/OS56xE8/D114evf5CHr7/f3/15f/fX/Zcv93e//bORlz67ESxM Ws2pI/Lz7I9ofwGb1NXWd2gp/MfQ3ge029BIFdoIXzNoNzttWC7coIM2NPE6oN0wAdlBu0dfAu0k UN74lEVBCK+106gflNC+02h2rC+uAN4OZ13YI5gGuksAz9KPlhSFRWod/iAP5FV/APjP/EFO4fyB 1seG/QEXoz6TDCuAp4K9XpXrYK9VaX7XFey3Ob6X4V6oYmXBOoeeA+cMdm4djtW0W4eXInP22VQJ y4st3vVCe34dTorwqxfm6wjBbkm+jV/bjT33tW33Ola9JH8MxuajWkM5g3MV1Xmu+h85XVApzAsq haBxfsHtwi23C+f8QsI35xfmcGzchAvybksdH9TLbKlvDsyv/Ct7ka22SlyvBNyFjzw2p59tOvJ4 rrK0V80dbSWZFeJfXj2n1mJP5Yntrc0p9v8BvEIRbnNL26g7ZC4s4gloNlub2nneJp87fza93PZW obSVwdjtXr2q3avCIp6AccMdIC13QWTB1VKhiJVB0x0fbSc0Nxdhv5nFr7ni9fL7Wms+z200Wrvm El71QLdZum3RbHbMwYG7baGX3bNj381crCx89FPB0q1517epW2hlZZHTAfV13YAuTMIBtbv6O9Df zhLXPPHAFbdqQC1dZ0adC6XPCKXZjfnh5D0eBphV1r+/PVgcefl9CHchUV/HXHwB++2AzW31bOf3 5OwwZe3Q3KYdW4dT93wP77XwyfrM53suhK76zd7S0MR76/wJM5JpcvQ3AAAA//8DAFBLAwQUAAYA CAAAACEA49YPU9oAAAD9AAAADwAAAGRycy9kb3ducmV2LnhtbESPUU/CMBSF3038D8018U06hwgO CjEaEB/HwIS3y3rZqmu7tAWGv97GB3g8OSffyTeZdbphR3JeWSPgsZcAI1NaqUwlYF3MH0bAfEAj sbGGBJzJw2x6ezPBTNqTyem4ChWLEOMzFFCH0Gac+7Imjb5nWzKx21unMcToKi4dniJcNzxNkmeu UZn4UGNLbzWVP6uDFrBT6Rp/82KR6Jd5P3x2xfdh+y7E/V33OgYWqAvX8ejrabPQl/IftZQC0v5g MAS2/zjvnJI5+kBOQPSLttEU+PQPAAD//wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMA AACPAQAACwAAAAAAAAAAAAAAAAAsAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAT39pB7IF AAD7PgAAEAAAAAAAAAAAAAAAAAAoAgAAZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQDj 1g9T2gAAAP0AAAAPAAAAAAAAAAAAAAAAAAgIAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1 AAAADwkAAAAAAAAQ8AgAAACQA/AAYBUQDg8AEfDuAAAAAADDCwgAAAD/////DgH/vw8AiBPKAAAA DwCKE8IAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE6QAAAAAAKwPnAAAAAAAgAL//wAAAAAA AAAAAAAAAIAC//8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC //8AAAAAAAAAAAAAAACAAv//AAAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAAAIAC//8AAAAAAAAA AAAAAACAAv//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwQEAAAAAwAAAA8ADfDSAgAAAACfDwQA AAAHAAAAAACoDyoBAABTY2FsYWJpbGl0eToNRGlzY3Vzc2lvbiBvbiB0cmFuc2FjdGlvbiBzY2Fs ZSByZXF1aXJlbWVudCBiYXNlZCBvbiBkaWZmZXJlbnQgc2NlbmFyaW9zDQ1TZWN1cml0eSBDb25z aWRlcmF0aW9ucw1BdXRoZW50aWNhdGVkIGFuZCBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVs IGJldHdlZW4gbm9kZXMgb24gdGhlIHNlcnZpY2UgcGF0aCBhbmQgdGhlIGNvbnRyb2wgc3lzdGVt IA1DdXN0b21lciBwcml2YWN5IHByZXNlcnZhdGlvbg1Bdm9pZCBjb25nZXN0aW9uLXRyaWdnZXJl ZCBkZW5pYWwgb2Ygc2VydmljZQ0NDQ0NDQ0NAAChD3gBAAANAAAAAAD+EAoADwBxAAIASwAAAAAF WgAHAEkAAAABAP4QCgAPAHEAAgBLAAAAAAVaAAcAGQAAAAAA/hAKAA8AcQACAEsAAAAABVoABwC0 AAAAAQD+EAoADwBxAAIASwAAAAAFWgAHAAEAAAAAAP4QCgAPAHEAAgBLAAAAAAVaAAcAAQAAAAEA /hAKAA8AcQACAEsAAAAABVoABwABAAAAAAD+EAoADwBxAAIASwAAAAAFWgAHAAIAAAACAP4QCgAP AHEAAgBLAAAAAAVaAAcAAQAAAAEAbRAKAAwASwAAAAAFWgAHAAIAAAABAP4QCgAPAHEAAgBLAAAA AAVaAAcADQAAAAEAAAABAEkAAAABBCAAAQQAAAEAAAAACCIAAAgAABYAGAAAAAEMAAABDLQAAAAB EAIAARAQAAEAAAAAFAIAABQYAAEAAAAAGAIAABgMAAEAAAAAHCIAABwAABgAAgAAAAAgAgAAIA4A AwAAAAAkAgAAJBAAAACqDwwAAAArAQAABgAAAAkEAAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAADwCIE50AAAAPAIoTlQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixN1AAAAAADrLggAAABIjs4BMJPQvwAAHRAEAAAAAAAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn 8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAA AA8AAisAAAAAAAAdBAQAAAABAAAADwDuAzcRAAACAO8DGAAAABAAAAAAAAAAAAAAAGMAAIAHAQAA BwAAAA8ADAQ2EAAADwAC8C4QAADQAQjwCAAAAAUAAAAEdAAADwAD8BYQAAAPAATwKAAAAAEACfAQ AAAAAAAAAKDdBAAIAAAACAAAAAIACvAIAAAAAHQAAAUAAAAPAATw9wAAAKIMCvAIAAAAAXQAAAAK AACDAAvwWgAAAH8AAQDvAYAA2OhzH78AAAAGAL8BAAAQAP8BEAAZAD8DAAAIAIDDKgAAAL8DAAAC AEYAbwBvAHQAZQByACAAUABsAGEAYwBlAGgAbwBsAGQAZQByACAANQAAAAAAEPAIAAAAFBCwB9AO QBEPABHwCQAAAAAAIAQBAAAACQ8ADfBcAAAAAACfDwQAAAAEAAAAAACoDw4AAABJRVRGODcgaTJy cyBXRwAAoQ8eAAAADwAAAAAAIAgKAAAAAP8BAAcADwAAAAEAAgABAA4AAACmDwwAAADwAAAA1AHQ AvADEAUPAATwEwEAAKIMCvAIAAAAAnQAAAAKAACDAAvwZgAAAH8AAQDvAYAA2EdyH78AAAAGAL8B AAAQAP8BEAAZAD8DAAAIAIDDNgAAAL8DAAACAFMAbABpAGQAZQAgAE4AdQBtAGIAZQByACAAUABs AGEAYwBlAGgAbwBsAGQAZQByACAANgAAAAAAEPAIAAAAFBAgEGAVQBEPABHwCQAAAAAAIAQBAAAA CA8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAAAAAAIAgKAAAAAP8CAAcA AgAAAAAAAgAOAAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALw AxAFDwAE8AUBAAASAArwCAAAAAN0AAAACgAAgwAL8EgAAAB/AAEA7wGAALj4gCW/AAAABgC/AQEA EQD/AQAAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAA AJAAIARwFGADDwAR8BwAAAAAAMMLCAAAAP////8NAP+/AAAfBAQAAAACAAAADwAN8GkAAAAAAJ8P BAAAAAAAAAAAAKgPFQAAAAkJCQkJCQkJCQkJTmV4dCBTdGVwcwAAoQ8YAAAAFgAAAAAAAAAKAAcA FgAAAAEAAgABABgAAACqDxgAAAAVAAAABwAAAAAACQQAAAEAAAABAAAAAAAPAATwtwwAABIACvAI AAAABHQAACACAAADAQvweAAAAAQAAAAAAH8AAQDvAYAAuGSEJYEAMGUBAIIAmLIAAIMAMGUBAIQA mLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAP8BAAARAAEDAqgAAD8DAAAIAIDDGAAAAL8DAAAC AFIAZQBjAHQAYQBuAGcAbABlACAAMwAAABMAIvGcCQAAqcOWCQAAUEsDBBQABgAIAAAAIQAyPL0+ +wAAAOIBAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbJSRQU7DMBBF90jcwfIWJQ4sEEJNuiCwBATl ACN7klgkY8tjQnt7Jm3ZIFTE0p55/z/Zq/V2GtWMiX2gWl+WlVZINjhPfa3fNg/FjVacgRyMgbDW O2S9bs7PVptdRFZCE9d6yDneGsN2wAm4DBFJJl1IE2Q5pt5EsO/Qo7mqqmtjA2WkXOQlQzerFjv4 GLO638r1wURwre4Oe0tVrSHG0VvIImqWqfmVSzjyCXAm98OuOJqVQu7DefCRL44NT/I0yTtUz5Dy I0ziYVxiwwNElJ3ytOdSN3ERus5bLNvErwv3V7gLn5Rw/m92K9gLzt/pZv9DzRcAAAD//wMAUEsD BBQABgAIAAAAIQCqi10N0wAAAI8BAAALAAAAX3JlbHMvLnJlbHOkkLFqAzEMhvdA38Fo7/mSoZQQ X7ZC1pBCV2Hr7kzOlrHMNXn7uJRCL2TLoEG/0PcJ7faXMKmZsniOBtZNC4qiZefjYODz9PH6DkoK RocTRzJwJYF997LaHWnCUpdk9ElUpUQxMJaStlqLHSmgNJwo1knPOWCpbR50QnvGgfSmbd90/s+A bsFUB2cgH9wa1OmaqvmOHbzNLNyXxnLQ3PfePqJqGTHRV5gqBvNAxYDL8pvW05paoB+bN0+aHX/H I81L8U+Yaf7z6sUbuxsAAAD//wMAUEsDBBQABgAIAAAAIQCuR+KqLgUAAJwtAAAQAAAAZHJzL3No YXBleG1sLnhtbOxa204jORB9X2n/wfJ7JhcSCBHNCJDYXQmhiDCax5XTcZNeut09thMCj8z3jHal XWlf+Bs+gF/YU3bnAnPZcMkCs81D8KXsLlfVqbLL3no7SRM2ltrEmQp4/U2NM6nCbBCrk4C/O96v tDkzVqiBSDIlA34uDX+7/eMPW3nH5AyDlenkAR9am3eqVRMOZSrMmyyXCn1RplNhUdUn1VxLI5UV Fh9Kk2qjVluvpiJWfBtTqXEv72oqhYfjrmbxIOCNtVZrgzMlUnz2SIZg4iSRbI1XCzo/RICPgyw8 NQUzYhlmBlqcYYW3+GAq+0ljKXV8M9sb4mtyR+vsbCjFwFAzvlt1DE55VWCVeMmHzJ7n4LKfDc4h rguwIJKIYxmTgDcbm83N9Y3GZquYwQ/DVPNVG7d60ZlEOn3sOra3RCeLIoZPr7XrtRo0eg72m82N NspYhOjIiWUh+ttrtRY1shAUzQaY9BRVz4lbr2ct79jJLlZHo2mV0JHX/cPFDaOzEFSmLzg70wKS Nx9GQkvOkl8UBL4JlsGadZVmC7xxphd7+os9apTuZYnTnlAhZg245cwX9yxqtMoszYU9UL08JEJa S66NPZ68FzpnVMQgyOYw6w1FLh2BGB8YS5pfpHVVLwaaJDG2Z89hm48UidPNFFQPFqxbFvSTCn0A E4D5kYZRO3JCSMaQEhpiNQAcA16ZUojkBB4g4Wwgo2PR78GKnQpI7NaPkeJA7epTJ+UoU3bHDekL Q0oDslXRjSGEHyCsO1IhPuKFnZDkiT2Th93QsrHAtOBuZnSLBLsyuksK65yRYoo5xU5k79I6S4fS QFf09kd7CeCKJnJSEhXPgAhDCKLhwAnjnlL1R72LGZMbreLLRLCPlTvARyIE6N9jmeQuDQxsKLSR WG+BM0yGFtcc8A8ee1b0vUWJDgR91NWFcZErER3/A+2djtI4zX6Lvc4gzIBLVXnX8+6FJMFZ3yvS /Y4CruCgyVnr+BRsqaznSpydSg3Fgj4kkBVUBAE0KfLQSXwhf3ZVUmUSk593fV2dZZErD2Jt4SPQ alK7l0jhZiSOE0W/KtuPk8QvxbeYLIkH1PgFkduJ96bQxSKVjCK4+al0RgfqeOIgMaJpirIzswXp 7+hYwGbvSl6KBZqbq083V3+ym6s/ri//ur78+/rjx+vL3z8fFJp7D4KFaa85u81+9X/035fdr6sy Rh4EVkoDvDchuTwx2KGer+IcfSXCSfxLIrywt/7oELByZvht5Eo16AotAOgSu53Xgt250laGyWl4 /SowywBcBuAyADsP+zQB2MfeWRCeFpgPxBSjy1hMEng9u+0yFv8P9tFlLC4Pw+VheHZk/i4Owy7k UsQtDsTz4jxIz2lc75Ry3vzKojUO2vfKjdW4T6N8ITdG2dtZxmv14XoWZnsXsyIlu2aVJY/CSyax 6i71XCaxAu6TWG4L/PjE1WwySjXNclO3QIQbgGWzFc+nJI8K+n3m5OIK9DIX/8ryDvV6c81liW8n HhoLmf9Go71OeeQyL0joWDIvuJAiftLM/9wk/iV/WG+WuX9/8/KY3H8e23C4L9I4wbVGpV7bXLgO qNQb7eI6aK6VEqhOAqvfhZDHf8lXdHOTKIH6HyT6Xw5Q3RuEz67Y8FxkepVehtLCay4ZSu97rlge eW5b8xwnixezaX3YjfjLAdsG3q20vgW2SqPdwrOMcveK48lr2r0+GzS/p5crJU7L92XYJt//fVkZ Qlf9qOzB0MSD4OkbWxRNvv0PAAAA//8DAFBLAwQUAAYACAAAACEAPU3MoNoAAAD9AAAADwAAAGRy cy9kb3ducmV2LnhtbESPwU7DMBBE70j8g7VI3KhDqlIIdasKFKDHNL1w28abxDS2I9ttE74ei0N7 HM3ojd5iNeiOnch5ZY2Ax0kCjExlpTKNgF2ZPzwD8wGNxM4aEjCSh9Xy9maBmbRnU9BpGxoWIcZn KKANoc8491VLGv3E9mRiV1unMcToGi4dniNcdzxNkieuUZn40GJPby1Vh+1RC9irdIe/RfmR6Jd8 GjZD+XP8fhfi/m5YvwILNITreMzrdN5dyn/UlxSQTmezObD6c9w7JQv0gZyA6Bdtoynw5R8AAAD/ /wMAUEsBAi0AFAAGAAgAAAAhADI8vT77AAAA4gEAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50 X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAqotdDdMAAACPAQAACwAAAAAAAAAAAAAAAAAsAQAA X3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEArkfiqi4FAACcLQAAEAAAAAAAAAAAAAAAAAAoAgAA ZHJzL3NoYXBleG1sLnhtbFBLAQItABQABgAIAAAAIQA9Tcyg2gAAAP0AAAAPAAAAAAAAAAAAAAAA AIQHAABkcnMvZG93bnJldi54bWxQSwUGAAAAAAQABAD1AAAAiwgAAAAAAAAQ8AgAAACQA/AAYBUQ Dg8AEfCKAAAAAADDCwgAAAD/////DgH/vw8AiBNmAAAADwCKE14AAAAAALoPDgAAAF8AXwBfAFAA UABUADkAAACLE0AAAAAAAKwPOAAAAAAAgAL//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAC//8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfBAQAAAADAAAADwAN8NkBAAAAAJ8PBAAAAAcAAAAAAKgP nQAAAENvbW1lbnRzIGFuZCBpbnB1dCBmcm9tIHRoZSBXRw0NQWRkcmVzcyBjb21tZW50cyByZWNl aXZlZCBmcm9tIEFsaWEgQXRsYXMNDVVwZGF0ZSB0aGUgZHJhZnQgY29tcGxldGluZyBzb21lIHNl Y3Rpb25zLCBhbmQgcG90ZW50aWFsbHkgYWRkaW5nIHVzZSBjYXNlcw0gDQ0NDQ0AAKEP/gAAAB8A AAAAAP4QCgAPAHEAAgBLAAAAAAVaAAcAAQAAAAAAbRAKAAwASwAAAAAFWgAHACoAAAAAAP4QCgAP AHEAAgBLAAAAAAVaAAcAAQAAAAAAbRAKAAwASwAAAAAFWgAHAEwAAAAAAP4QCgAPAHEAAgBLAAAA AAVaAAcAAgAAAAAAAQAAAAAAAgAAAAIA/hAKAA8AcQACAEsAAAAABVoABwABAAAAAQBtEAoADABL AAAAAAVaAAcAAgAAAAEA/hAKAA8AcQACAEsAAAAABVoABwCXAAAAAAAAAAIAAAAABCIAAAQAABIA AgAAAAAIAgAACA4AAwAAAAAMAgAADBAAAACqDwwAAACeAAAABgAAAAkEAAAAAKYPBgAAABAAAAAg ARAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTnQAAAA8AihOVAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE3UAAAAAAOsuCAAAAPaNzgFQT1nBAAAdEAQAAAAA AAAAAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAP// //8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAB0EBAAAAAEAAAAPAPAD4wMAAAEA 8QMIAAAAAAEAAAcA/78PAAwEYwMAAA8AAvBbAwAAAAEI8AgAAAAEAAAAA0AAAA8AA/BDAwAADwAE 8CgAAAABAAnwEAAAAAAAAAAAACAAelNtTTgAAAACAArwCAAAAABAAAAFAAAADwAE8PsAAACiDArw CAAAAAFAAAAACgAAkwAL8E4AAAB/AAEA7wGAAGiYhCWHAAIAAAC/AAAABgC/AQAAEAD/AQAAGQA/ AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADcAAAAAABDwCAAAAF8VjwnfEH8W DwAR8AkAAAAAACAEAQAAAAgPAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIA AAAAACAICgAAAAD/AgAHAAIAAAAAAAIADAAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAA AKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCyAAAAEgAK8AgAAAACQAAAIAIAAPMAC/ByAAAABAAAAAAA fwAEAe8BgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEB ABEAAQMEOAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgA AACwAdACEA4gCg8AEfAQAAAAAADDCwgAAAAAAAAACwD/vw8ABPBOAQAAEgAK8AgAAAADQAAAIAIA AKMBC/C0AAAABAAAAAAAfwABAO8BgACo9aYlgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAA hwAAAAAAiAAAAAAAvwAAAAYAgAEAAAAAgQH///8AggEAAAEAvwEAABAAwAEAAAAAwQEAAAEAxAEA AAAAywE1JQAAzAEAAAgA1gEBAAAA/wEBABkAAQMFOAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMA dABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgAAACwCrABMA/QFA8AEfAQAAAAAADDCwgAAAABAAAADAD/ vw8ADfBSAAAAAACfDwQAAAACAAAAAAChDxQAAAABAAAAAAAAAAoABwABAAAAAAAAAAAAqg8OAAAA AQAAAAcAAAAAAAkEAAAAAKYPDAAAAPAAAADUAdAC8AMQBRAA8AcgAAAA////AAAAAACAgIAAAAAA ALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAOsuCAAAAIFJyQFQ7CFwDwDwA+MDAAABAPEDCAAAAB4BAAAHAP+/DwAMBGMDAAAP AALwWwMAACABCPAIAAAABAAAAANIAAAPAAPwQwMAAA8ABPAoAAAAAQAJ8BAAAAADAAAAaFfSZAAA AABoV9JkAgAK8AgAAAAASAAABQAAAA8ABPD7AAAAogwK8AgAAAABSAAAAAoAAJMAC/BOAAAAfwAB AO8BgACYAaklhwACAAAAvwAAAAYAvwEAABAA/wEAABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMA dABhAG4AZwBsAGUAIAA3AAAAAAAQ8AgAAABfFY8J3xB/Fg8AEfAJAAAAAAAgBAEAAAAIDwAN8GwA AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAAC AAwAAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATw sgAAABIACvAIAAAAAkgAACACAADzAAvwcgAAAAQAAAAAAH8ABAHvAYEAMGUBAIIAmLIAAIMAMGUB AIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAAAL8AAAAGAP8BAQARAAEDBDgAAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMgAAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsI AAAAAAAAAAsA/78PAATwTgEAABIACvAIAAAAA0gAACACAACjAQvwtAAAAAQAAAAAAH8AAQDvAYAA qDGqJYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAIABAAAA AIEB////AIIBAAABAL8BAAAQAMABAAAAAMEBAAABAMQBAAAAAMsBNSUAAMwBAAAIANYBAQAAAP8B AQAZAAEDBTgAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAI AAAAsAqwATAP0BQPABHwEAAAAAAAwwsIAAAAAQAAAAwA/78PAA3wUgAAAAAAnw8EAAAAAgAAAAAA oQ8UAAAAAQAAAAAAAAAKAAcAAQAAAAAAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADw AAAA1AHQAvADEAUQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgA AAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACBSckBkNLO dA8A8APjAwAAAQDxAwgAAAAxAQAABwD/vw8ADARjAwAADwAC8FsDAABAAQjwCAAAAAQAAAADUAAA DwAD8EMDAAAPAATwKAAAAAEACfAQAAAAGwAAAHwxvABQFZEfAADpgAIACvAIAAAAAFAAAAUAAAAP AATw+wAAAKIMCvAIAAAAAVAAAAAKAACTAAvwTgAAAH8AAQDvAYAAyC6qJYcAAgAAAL8AAAAGAL8B AAAQAP8BAAAZAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANwAAAAAAEPAI AAAAXxWPCd8QfxYPABHwCQAAAAAAIAQBAAAACA8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8cAAAAAgAAAAAAIAgKAAAAAP8CAAcAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8KAAAA AgAAAAEAAAAAAAAApg8MAAAA8AAAANQB0ALwAxAFDwAE8LIAAAASAArwCAAAAAJQAAAgAgAA8wAL 8HIAAAAEAAAAAAB/AAQB7wGBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAA AAC/AAAABgD/AQEAEQABAwQ4AAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAg ADIAAAAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAAAAAALAP+/DwAE8E4BAAASAArw CAAAAANQAAAgAgAAowEL8LQAAAAEAAAAAAB/AAEA7wGAAHhvbiCBADBlAQCCAJiyAACDADBlAQCE AJiyAACFAAAAAACHAAAAAACIAAAAAAC/AAAABgCAAQAAAACBAf///wCCAQAAAQC/AQAAEADAAQAA AADBAQAAAQDEAQAAAADLATUlAADMAQAACADWAQEAAAD/AQEAGQABAwU4AAA/AwAACACAwxgAAAC/ AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAALAKsAEwD9AUDwAR8BAAAAAAAMML CAAAAAEAAAAMAP+/DwAN8FIAAAAAAJ8PBAAAAAIAAAAAAKEPFAAAAAEAAAAAAAAACgAHAAEAAAAA AAAAAACqDw4AAAABAAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFEADwByAAAAD///8A AAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAgUnJAeBwPXwPAPAD4wMAAAEA8QMIAAAANAEAAAcA /78PAAwEYwMAAA8AAvBbAwAAYAEI8AgAAAAEAAAAA1gAAA8AA/BDAwAADwAE8CgAAAABAAnwEAAA AAwAAAAIAJBBAFDhPggAkEECAArwCAAAAABYAAAFAAAADwAE8PsAAACiDArwCAAAAAFYAAAACgAA kwAL8E4AAAB/AAEA7wGAAGgjhSWHAAIAAAC/AAAABgC/AQAAEAD/AQAAGQA/AwAACACAwxgAAAC/ AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADcAAAAAABDwCAAAAF8VjwnfEH8WDwAR8AkAAAAAACAE AQAAAAgPAA3wbAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAICgAAAAD/ AgAHAAIAAAAAAAIADAAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAAAPAAAADU AdAC8AMQBQ8ABPCyAAAAEgAK8AgAAAACWAAAIAIAAPMAC/ByAAAABAAAAAAAfwAEAe8BgQAwZQEA ggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEBABEAAQMEOAAAPwMA AAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAACwAdACEA4gCg8A EfAQAAAAAADDCwgAAAAAAAAACwD/vw8ABPBOAQAAEgAK8AgAAAADWAAAIAIAAKMBC/C0AAAABAAA AAAAfwABAO8BgAAIDXMfgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAA vwAAAAYAgAEAAAAAgQH///8AggEAAAEAvwEAABAAwAEAAAAAwQEAAAEAxAEAAAAAywE1JQAAzAEA AAgA1gEBAAAA/wEBABkAAQMFOAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA IAAzAAAAAAAQ8AgAAACwCrABMA/QFA8AEfAQAAAAAADDCwgAAAABAAAADAD/vw8ADfBSAAAAAACf DwQAAAACAAAAAAChDxQAAAABAAAAAAAAAAoABwABAAAAAAAAAAAAqg8OAAAAAQAAAAcAAAAAAAkE AAAAAKYPDAAAAPAAAADUAdAC8AMQBRAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu CAAAAIFJyQHgcD18DwDwA+MDAAABAPEDCAAAADUBAAAHAP+/DwAMBGMDAAAPAALwWwMAAIABCPAI AAAABAAAAANgAAAPAAPwQwMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAAYAAABQAAAA8ABPD7AAAAogwK8AgAAAABYAAAAAoAAJMAC/BOAAAAfwABAO8BgAC4NoUlhwAC AAAAvwAAAAYAvwEAABAA/wEAABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUA IAA3AAAAAAAQ8AgAAABfFY8J3xB/Fg8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQA AAAAAKAPAgAAACoAAAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAAwAAADYDwQAAAAA AAAAAACqDwoAAAACAAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwsgAAABIACvAIAAAA AmAAACACAADzAAvwcgAAAAQAAAAAAH8ABAHvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAA AIcAAQAAAIgAAAAAAL8AAAAGAP8BAQARAAEDBDgAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQA YQBuAGcAbABlACAAMgAAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsA/78P AATwTgEAABIACvAIAAAAA2AAACACAACjAQvwtAAAAAQAAAAAAH8AAQDvAYAA+DxiH4EAMGUBAIIA mLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAIABAAAAAIEB////AIIBAAAB AL8BAAAQAMABAAAAAMEBAAABAMQBAAAAAMsBNSUAAMwBAAAIANYBAQAAAP8BAQAZAAEDBTgAAD8D AAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAsAqwATAP0BQP ABHwEAAAAAAAwwsIAAAAAQAAAAwA/78PAA3wUgAAAAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAA AAAKAAcAAQAAAAAAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA1AHQAvADEAUQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACBSckB4HA9fA8A8APjAwAAAQDx AwgAAAA2AQAABwD/vw8ADARjAwAADwAC8FsDAACgAQjwCAAAAAQAAAADaAAADwAD8EMDAAAPAATw KAAAAAEACfAQAAAAAAAAAAEAAAABAAAAAAAAAAIACvAIAAAAAGgAAAUAAAAPAATw+wAAAKIMCvAI AAAAAWgAAAAKAACTAAvwTgAAAH8AAQDvAYAAWKBuIIcAAgAAAL8AAAAGAL8BAAAQAP8BAAAZAD8D AAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAANwAAAAAAEPAIAAAAXxWPCd8QfxYP ABHwCQAAAAAAIAQBAAAACA8ADfBsAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8cAAAAAgAA AAAAIAgKAAAAAP8CAAcAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAA pg8MAAAA8AAAANQB0ALwAxAFDwAE8LIAAAASAArwCAAAAAJoAAAgAgAA8wAL8HIAAAAEAAAAAAB/ AAQB7wGBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAEAAACIAAAAAAC/AAAABgD/AQEA EQABAwQ4AAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0AGEAbgBnAGwAZQAgADIAAAAAABDwCAAA ALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAAAAAALAP+/DwAE8E4BAAASAArwCAAAAANoAAAgAgAA owEL8LQAAAAEAAAAAAB/AAEA7wGAACifbiCBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACH AAAAAACIAAAAAAC/AAAABgCAAQAAAACBAf///wCCAQAAAQC/AQAAEADAAQAAAADBAQAAAQDEAQAA AADLATUlAADMAQAACADWAQEAAAD/AQEAGQABAwU4AAA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0 AGEAbgBnAGwAZQAgADMAAAAAABDwCAAAALAKsAEwD9AUDwAR8BAAAAAAAMMLCAAAAAEAAAAMAP+/ DwAN8FIAAAAAAJ8PBAAAAAIAAAAAAKEPFAAAAAEAAAAAAAAACgAHAAEAAAAAAAAAAACqDw4AAAAB AAAABwAAAAAACQQAAAAApg8MAAAA8AAAANQB0ALwAxAFEADwByAAAAD///8AAAAAAICAgAAAAAAA u+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAA AIsTEAAAAAAA6y4IAAAAgUnJAeBwPXwPAPAD4wMAAAEA8QMIAAAAOQEAAAcA/78PAAwEYwMAAA8A AvBbAwAAwAEI8AgAAAAEAAAAA3AAAA8AA/BDAwAADwAE8CgAAAABAAnwEAAAABEAAAAAAAAACAAA AAAAAAACAArwCAAAAABwAAAFAAAADwAE8PsAAACiDArwCAAAAAFwAAAACgAAkwAL8E4AAAB/AAEA 7wGAAOg+pyWHAAIAAAC/AAAABgC/AQAAEAD/AQAAGQA/AwAACACAwxgAAAC/AwAAAgBSAGUAYwB0 AGEAbgBnAGwAZQAgADcAAAAAABDwCAAAAF8VjwnfEH8WDwAR8AkAAAAAACAEAQAAAAgPAA3wbAAA AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAACAICgAAAAD/AgAHAAIAAAAAAAIA DAAAANgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPDAAAAPAAAADUAdAC8AMQBQ8ABPCy AAAAEgAK8AgAAAACcAAAIAIAAPMAC/ByAAAABAAAAAAAfwAEAe8BgQAwZQEAggCYsgAAgwAwZQEA hACYsgAAhQAAAAAAhwABAAAAiAAAAAAAvwAAAAYA/wEBABEAAQMEOAAAPwMAAAgAgMMYAAAAvwMA AAIAUgBlAGMAdABhAG4AZwBsAGUAIAAyAAAAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgA AAAAAAAACwD/vw8ABPBOAQAAEgAK8AgAAAADcAAAIAIAAKMBC/C0AAAABAAAAAAAfwABAO8BgAAY l24ggQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAYAgAEAAAAA gQH///8AggEAAAEAvwEAABAAwAEAAAAAwQEAAAEAxAEAAAAAywE1JQAAzAEAAAgA1gEBAAAA/wEB ABkAAQMFOAAAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAAzAAAAAAAQ8AgA AACwCrABMA/QFA8AEfAQAAAAAADDCwgAAAABAAAADAD/vw8ADfBSAAAAAACfDwQAAAACAAAAAACh DxQAAAABAAAAAAAAAAoABwABAAAAAAAAAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAKYPDAAAAPAA AADUAdAC8AMQBRAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAIFJyQHgcD18 DwDwA+MDAAABAPEDCAAAADcBAAAHAP+/DwAMBGMDAAAPAALwWwMAAOABCPAIAAAABAAAAAN4AAAP AAPwQwMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAeAAABQAAAA8A BPD7AAAAogwK8AgAAAABeAAAAAoAAJMAC/BOAAAAfwABAO8BgAAYMYUlhwACAAAAvwAAAAYAvwEA ABAA/wEAABkAPwMAAAgAgMMYAAAAvwMAAAIAUgBlAGMAdABhAG4AZwBsAGUAIAA3AAAAAAAQ8AgA AABfFY8J3xB/Fg8AEfAJAAAAAAAgBAEAAAAIDwAN8GwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxwAAAACAAAAAAAgCAoAAAAA/wIABwACAAAAAAACAAwAAADYDwQAAAAAAAAAAACqDwoAAAAC AAAAAQAAAAAAAACmDwwAAADwAAAA1AHQAvADEAUPAATwsgAAABIACvAIAAAAAngAACACAADzAAvw cgAAAAQAAAAAAH8ABAHvAYEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAQAAAIgAAAAA AL8AAAAGAP8BAQARAAEDBDgAAD8DAAAIAIDDGAAAAL8DAAACAFIAZQBjAHQAYQBuAGcAbABlACAA MgAAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsA/78PAATwTgEAABIACvAI AAAAA3gAACACAACjAQvwtAAAAAQAAAAAAH8AAQDvAYAAKBV+H4EAMGUBAIIAmLIAAIMAMGUBAIQA mLIAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAAGAIABAAAAAIEB////AIIBAAABAL8BAAAQAMABAAAA AMEBAAABAMQBAAAAAMsBNSUAAMwBAAAIANYBAQAAAP8BAQAZAAEDBTgAAD8DAAAIAIDDGAAAAL8D AAACAFIAZQBjAHQAYQBuAGcAbABlACAAMwAAAAAAEPAIAAAAsAqwATAP0BQPABHwEAAAAAAAwwsI AAAAAQAAAAwA/78PAA3wUgAAAAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAAAAAKAAcAAQAAAAAA AAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAACmDwwAAADwAAAA1AHQAvADEAUQAPAHIAAAAP///wAA AAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8A UABQAFQAMQAwAAAAixMQAAAAAADrLggAAACBSckB4HA9fAAAcheAAAAAAQDwAQAAAAA8kAMAzRYA AJRVAABUmgAAod4AAKojAQClaAEAAa8BAM/yAQC7NQIAd3sCALPCAgAUBwMAjUsDAJ3TAwBv2wMA iOoDAOv8AwCYEwQADSkEAJVABADUUwQAE2UEAP5oBADpbAQA1HAEAL90BACqeAQAlXwEAICABAAA APUPHAAAAAAAAAAsPgADAAAAAGuEBAABAAAAHwAAAA8APwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAADCgEAAAAAAAAAAAAA AAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAABQzAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQA AACAAAAABwAAAJwAAAAIAAAAqAAAAAkAAAC8AAAAEgAAAMgAAAAKAAAA8AAAAAwAAAD8AAAADQAA AAgBAAAPAAAAFAEAABEAAAAcAQAAAgAAABAnAAAeAAAACAAAAFNsaWRlIDEAHgAAABQAAABSb2Jl cnRhIE1hZ2xpb25lAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATmFiaWwgQml0YXIAHgAAAAQAAAAz MTgAHgAAACAAAABNaWNyb3NvZnQgTWFjaW50b3NoIFBvd2VyUG9pbnQAAEAAAAC/fPqcWwcAAEAA AAAvsMpyaErJAUAAAACw9KXXko7OAQMAAABBAgAARwAAAPAxAAD+////UElDVDHoAAAAAACHALQA EQL/DAD//gAAAEgAAABIAAAAAAAAAIcAtAAAAAAAHgABAAoAAAAAAIcAtACa/wAAAILQAAAAAACH ALQAAAAEAAAAAABIAAAASAAAABAAIAAEAAgAAAAgAAAAAAAAAAAAAAAAAIcAtAAAAAAAhwC0AAAA DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB /4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/ gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B /4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wFCgf/K/wBP/f8By9D7/wFrjPb/Afel+/8CnP9Y+v8E3zlGWO/6/wPL0JDO+P8CfUV4 +v8B96X2/xTVnU/6Y13rZURItchEU9t/9f//lmL6/wP5XUib+P8B3oD4/wWoSmz2YvX8/wFp9f7/ AZDO7/8AT/3/AcvQ+/8Ba4z2/wH3pfv/Apz/WPr/BN85Rljv+v8Dy9CQzvj/An1FePr/Afel9v8U 1Z1P+mNd62VESLXIRFPbf/X//5Zi+v8D+V1Im/j/Ad6A+P8FqEps9mL1/P8BafX+/wGQzu//AE/9 /wHL0Pv/AWuM9v8B96X7/wKc/1j6/wTfOUZY7/r/A8vQkM74/wJ9RXj6/wH3pfb/FNWdT/pjXetl REi1yERT23/1//+WYvr/A/ldSJv4/wHegPj/BahKbPZi9fz/AWn1/v8BkM7y/wIRgf/K/38i5Ihw wDxc22+633lwEaeRYdDhcZb9iob3/6Me15Fw3v/PEbgjfaL9iob3/9ZL/1i7r2fI4pzjmzxcpth9 gKD+hZKV//8qvJ/Rnu6Ow2umox7ViobzfHaVYtH//2XhIuG1haI95L5VfXi9yK2W/+sheMtkr995 jP/iMsqb/YqG9yqGcHb6ktGZ4XGW/YqG9//yN/il3DqIgPp3Z+qH3IhwwKbYh5d+/oWSlb+/+P9/ IuSIcMA8XNtvut95cBGnkWHQ4XGW/YqG9/+jHteRcN7/zxG4I32i/YqG9//WS/9Yu69nyOKc45s8 XKbYfYCg/oWSlf//Kryf0Z7ujsNrpqMe1YqG83x2lWLR//9l4SLhtYWiPeS+VX14vcitlv/rIXjL ZK/feYz/4jLKm/2KhvcqhnB2+pLRmeFxlv2Khvf/8jf4pdw6iID6d2fqh9yIcMCm2IeXfv6FkpW/ v/j/fyLkiHDAPFzbb7rfeXARp5Fh0OFxlv2Khvf/ox7XkXDe/88RuCN9ov2Khvf/1kv/WLuvZ8ji nOObPFym2H2AoP6FkpX//yq8n9Ge7o7Da6ajHtWKhvN8dpVi0f//ZeEi4bWFoj3kvlV9eL3IrZb/ 6yF4y2Sv33mM/+Iyypv9iob3KoZwdvqS0ZnhcZb9iob3//I3+KXcOoiA+ndn6ofciHDAptiHl37+ hZKVv7/7/wIRgf/K/38i00DGWnOuWIoyyj7rK/iZZHdmxK28R12w/9pKvVbNUv/8Kvob8iu/R12w /9YXIlrqLeU0z1zRW3Oubr8a8CrIX7lR///IWSjjMp2RaWuf2kq9R12rIM07q3j//z3/Iv/UNO09 OhfW734pnNhh//5Q0y3fQbc+7v//rUg9vkddsCoyxnqmOtRYZsStvEddsP/GWf/9/zrZMOaTQ6o7 yEDGWm6/Odguvl+5Uenp+P9/ItNAxlpzrliKMso+6yv4mWR3ZsStvEddsP/aSr1WzVL//Cr6G/Ir v0ddsP/WFyJa6i3lNM9c0Vtzrm6/GvAqyF+5Uf//yFko4zKdkWlrn9pKvUddqyDNO6t4//89/yL/ 1DTtPToX1u9+KZzYYf/+UNMt30G3Pu7//61IPb5HXbAqMsZ6pjrUWGbErbxHXbD/xln//f862TDm k0OqO8hAxlpuvznYLr5fuVHp6fj/fyLTQMZac65YijLKPusr+Jlkd2bErbxHXbD/2kq9Vs1S//wq +hvyK79HXbD/1hciWuot5TTPXNFbc65uvxrwKshfuVH//8hZKOMynZFpa5/aSr1HXasgzTureP// Pf8i/9Q07T06F9bvfimc2GH//lDTLd9Btz7u//+tSD2+R12wKjLGeqY61FhmxK28R12w/8ZZ//3/ Otkw5pNDqjvIQMZabr852C6+X7lR6en7/wIRgf/K/38i01rWVnqcV5ZzyF//LeYyjnFvony4S4vI /+BBwEexXv//KO4t/y2+S4vI/9ZL5yPYKcg52ESkW3qcbr8t/y3NRIpR//Y4wz/IcSPqpqAk30G1 S4vCNdlTuHT//0H/IukineI95GKLdZKPYtpm//9T2TTCOr5f///WSMQhtkuLyCoy+N8Xk9RYb6J8 uEuLyP/7LbdB0jryPKpYZaQ7yFrWVm6/OfM8wESKUd3d+P9/ItNa1lZ6nFeWc8hf/y3mMo5xb6J8 uEuLyP/gQcBHsV7//yjuLf8tvkuLyP/WS+cj2CnIOdhEpFt6nG6/Lf8tzUSKUf/2OMM/yHEj6qag JN9BtUuLwjXZU7h0//9B/yLpIp3iPeRii3WSj2LaZv//U9k0wjq+X///1kjEIbZLi8gqMvjfF5PU WG+ifLhLi8j/+y23QdI68jyqWGWkO8ha1lZuvznzPMBEilHd3fj/fyLTWtZWepxXlnPIX/8t5jKO cW+ifLhLi8j/4EHAR7Fe//8o7i3/Lb5Li8j/1kvnI9gpyDnYRKRbepxuvy3/Lc1EilH/9jjDP8hx I+qmoCTfQbVLi8I12VO4dP//Qf8i6SKd4j3kYot1ko9i2mb//1PZNMI6vl///9ZIxCG2S4vIKjL4 3xeT1Fhvony4S4vI//stt0HSOvI8qlhlpDvIWtZWbr858zzARIpR3d37/wIOgf/K/3WR6a3rq9CH 7Iy75bD/lv+Qma3sjLP+sYv5//yA26yN7P//mMCW/5b+sYv5/+ul/7+6xYPc/o2hrdCHt9+W/5bw kaNb///Kfab/tk3/1IC7/IDasYv2muyp3Lr//3DdkdF/f8ie8vGJ65KC7Kyl//+p7NyByeWw/v8x tHq//rGL+Zn9/5fv6qzsjLP+sYv5///jiLX/nfme6oOaxp3jreurt9+c+Z7pkaNby8v4/3WR6a3r q9CH7Iy75bD/lv+Qma3sjLP+sYv5//yA26yN7P//mMCW/5b+sYv5/+ul/7+6xYPc/o2hrdCHt9+W /5bwkaNb///Kfab/tk3/1IC7/IDasYv2muyp3Lr//3DdkdF/f8ie8vGJ65KC7Kyl//+p7NyByeWw /v8xtHq//rGL+Zn9/5fv6qzsjLP+sYv5///jiLX/nfme6oOaxp3jreurt9+c+Z7pkaNby8v4/3WR 6a3rq9CH7Iy75bD/lv+Qma3sjLP+sYv5//yA26yN7P//mMCW/5b+sYv5/+ul/7+6xYPc/o2hrdCH t9+W/5bwkaNb///Kfab/tk3/1IC7/IDasYv2muyp3Lr//3DdkdF/f8ie8vGJ65KC7Kyl//+p7NyB yeWw/v8xtHq//rGL+Zn9/5fv6qzsjLP+sYv5///jiLX/nfme6oOaxp3jreurt9+c+Z7pkaNby8v7 /wBegf+L/wP5bVjE/P8C7E7M8P8B4av0/wGS+8n/A/ltWMS3/wP5bVjE/P8C7E7M8P8B4av0/wGS +8n/A/ltWMS3/wP5bVjE/P8C7E7M8P8B4av0/wGS+8n/A/ltWMT5/wAMgf+B/4H/gf+B/7H/AG2B /57/A4zD/VH4/wPEVFzh6f8Hksb/3zlGWO/3/wHegO//AcvQnv8DjMP9Ufj/A8RUXOHp/weSxv/f OUZY7/f/Ad6A7/8By9Ce/wOMw/1R+P8DxFRc4en/B5LG/985Rljv9/8B3oDv/wHL0M3/AQmB/57/ U26z/SXzeHT1p3bn//8268DCzGOT83h09ad258Nrpv//zGOT5IhwwNpwS7f/1kv/WLvDbtLea3/T hPqF35mhdcyKhveFiYxps9tvuuSIcMA8XMNrpqH/U26z/SXzeHT1p3bn//8268DCzGOT83h09ad2 58Nrpv//zGOT5IhwwNpwS7f/1kv/WLvDbtLea3/ThPqF35mhdcyKhveFiYxps9tvuuSIcMA8XMNr pqH/U26z/SXzeHT1p3bn//8268DCzGOT83h09ad258Nrpv//zGOT5IhwwNpwS7f/1kv/WLvDbtLe a3/ThPqF35mhdcyKhveFiYxps9tvuuSIcMA8XMNrptD/AQmB/57/U3Cy+yfPNYLbKn59//Up//3/ wpMczzWC2yp+fWlrn///wpMc00DGWmHFUrf/1hciWvoumUxmu1i2NvY3ylhlm7lHXbAr5hbXRViK MtJAxlpzrmlrn6H/U3Cy+yfPNYLbKn59//Up//3/wpMczzWC2yp+fWlrn///wpMc00DGWmHFUrf/ 1hciWvoumUxmu1i2NvY3ylhlm7lHXbAr5hbXRViKMtJAxlpzrmlrn6H/U3Cy+yfPNYLbKn59//Up //3/wpMczzWC2yp+fWlrn///wpMc00DGWmHFUrf/1hciWvoumUxmu1i2NvY3ylhlm7lHXbAr5hbX RViKMtJAxlpzrmlrn9D/AQyB/57/VItrq0Dblk6eK5uo//9FqWSiT6kg25ZOniubqKagJP7/T6kg 01rWVm2lQrf/1kvnI+EuqIZ0o0O2P8wcylhlxb5Li8gt/y3sQVeWc9Ba1lZ6nKagJP6i/1SLa6tA 25ZOniubqP//Ralkok+pINuWTp4rm6imoCT+/0+pINNa1lZtpUK3/9ZL5yPhLqiGdKNDtj/MHMpY ZcW+S4vILf8t7EFXlnPQWtZWepymoCT+ov9Ui2urQNuWTp4rm6j//0WpZKJPqSDblk6eK5uopqAk /v9PqSDTWtZWbaVCt//WS+cj4S6ohnSjQ7Y/zBzKWGXFvkuLyC3/LexBV5Zz0FrWVnqcpqAk/tH/ AQmB/57/U/aNe9r5kJD1yITn///wk5/8x4KT85CQ9ciE59SAu///x4KT463rq+mGntv/66X/v7rc hNLphVK2w4OY5ayy5P6xi/mW/5b2oOyMu+mt66vQh9SAu6H/U/aNe9r5kJD1yITn///wk5/8x4KT 85CQ9ciE59SAu///x4KT463rq+mGntv/66X/v7rchNLphVK2w4OY5ayy5P6xi/mW/5b2oOyMu+mt 66vQh9SAu6H/U/aNe9r5kJD1yITn///wk5/8x4KT85CQ9ciE59SAu///x4KT463rq+mGntv/66X/ v7rchNLphVK2w4OY5ayy5P6xi/mW/5b2oOyMu+mt66vQh9SAu9D/ABmB/4H/6P8Bos2B/8//AaLN gf/P/wGizbT/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/ gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B /4H/sf8AxIH/pP8B+5n8/wvebLT///6W//+u2tz6/wTB7JiK0u//AcHs9v8AlPv/AK7+/wHB7Pn/ Ce99hf+ceN7//7f+/wHa3K//AfuZ/P8L3my0///+lv//rtrc+v8EweyYitLv/wHB7Pb/AJT7/wCu /v8Bwez5/wnvfYX/nHje//+3/v8B2tyv/wH7mfz/C95stP///pb//67a3Pr/BMHsmIrS7/8Bwez2 /wCU+/8Arv7/AcHs+f8J732F/5x43v//t/7/Adrc2P8BNoH/pf9inIl/l5Gyh7WHfEfb//5Og9yt iJCyh7W/g+X/wejE9HiXkaCF4f//oIXhyI/Pv4OY/rG97KOK6bKQ5f//vYnRYpK55YiD/a2glbfB 7JCH1baQoP//kdeN0nPydf/hR63in4eQsP9inIl/l5Gyh7WHfEfb//5Og9ytiJCyh7W/g+X/wejE 9HiXkaCF4f//oIXhyI/Pv4OY/rG97KOK6bKQ5f//vYnRYpK55YiD/a2glbfB7JCH1baQoP//kdeN 0nPydf/hR63in4eQsP9inIl/l5Gyh7WHfEfb//5Og9ytiJCyh7W/g+X/wejE9HiXkaCF4f//oIXh yI/Pv4OY/rG97KOK6bKQ5f//vYnRYpK55YiD/a2glbfB7JCH1baQoP//kdeN0nPydf/hR63in4eQ 2P8BOYH/pv9j44njf2b/uKhfuMF57q7dZvpvebHIuKhfls/Orpnf+m/dZv9lo+GuzmWj4VmlZpbP ssR5mc2A9M9VoXuuzmz/z2f/dNixUuR5YP90md5h93xt/2LOroH2qbWP/3H//3n1SbmxyLH/Y+OJ 439m/7ioX7jBee6u3Wb6b3mxyLioX5bPzq6Z3/pv3Wb/ZaPhrs5lo+FZpWaWz7LEeZnNgPTPVaF7 rs5s/89n/3TYsVLkeWD/dJneYfd8bf9izq6B9qm1j/9x//959Um5scix/2PjieN/Zv+4qF+4wXnu rt1m+m95sci4qF+Wz86umd/6b91m/2Wj4a7OZaPhWaVmls+yxHmZzYD0z1Whe67ObP/PZ/902LFS 5Hlg/3SZ3mH3fG3/Ys6ugfaptY//cf//efVJubHI2P8BOYH/pv9j6n3cf3n/YOBguMF59MroXfCI ebPFYOBgluLfypnecd3+ef+6uYTK37q5hG7pppbi+1mrmdeA67lz47PK33j8rnn/eYXEdt95ef95 md56/3lx71nfyrjHf+l/4Ijw/3niY5KzxbH/Y+p93H95/2DgYLjBefTK6F3wiHmzxWDgYJbi38qZ 3nHd/nn/urmEyt+6uYRu6aaW4vtZq5nXgOu5c+Ozyt94/K55/3mFxHbfeXn/eZneev95ce9Z38q4 x3/pf+CI8P954mOSs8Wx/2Pqfdx/ef9g4GC4wXn0yuhd8Ih5s8Vg4GCW4t/Kmd5x3f55/7q5hMrf urmEbummluL7WauZ14DruXPjs8rfePyuef95hcR233l5/3mZ3nr/eXHvWd/KuMd/6X/giPD/eeJj krPF2P8BNoH/pf9itKrAvP+vm7Hc4LfQ//+hmPC86p6vm7HL8f//zNt/f7C8/7uN5f//u43l2JHT y/H/r/nM78GW88KS5///15LhvP+83ZKl5ry8/7zM773/vMajdf//+qC0/8iR9LP/nqj3suaesP9i tKrAvP+vm7Hc4LfQ//+hmPC86p6vm7HL8f//zNt/f7C8/7uN5f//u43l2JHTy/H/r/nM78GW88KS 5///15LhvP+83ZKl5ry8/7zM773/vMajdf//+qC0/8iR9LP/nqj3suaesP9itKrAvP+vm7Hc4LfQ //+hmPC86p6vm7HL8f//zNt/f7C8/7uN5f//u43l2JHTy/H/r/nM78GW88KS5///15LhvP+83ZKl 5ry8/7zM773/vMajdf//+qC0/8iR9LP/nqj3suae2P8AHIH/gf/W/wKojMOB/9D/AqiMw4H/0P8C qIzDx/8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/ gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B /7H/AGuB/4b/A/2e/7z+/wWok7bd3OX7/wTNu/j/uf3/AMf5/wHq4IH/9P8D/Z7/vP7/BaiTtt3c 5fv/BM27+P+5/f8Ax/n/Aerggf/0/wP9nv+8/v8FqJO23dzl+/8Ezbv4/7n9/wDH+f8B6uC7/wCG gf+G/wP7PMuL/v8fg+qC16CarJDlhuH/nNauz7qrrNaOuMibu7if7ZyW/5yB//T/A/s8y4v+/x+D 6oLXoJqskOWG4f+c1q7Puqus1o64yJu7uJ/tnJb/nIH/9P8D+zzLi/7/H4PqgtegmqyQ5Ybh/5zW rs+6q6zWjrjIm7u4n+2clv+cu/8AhoH/hv8D+5B7hP7/H3ildrmswJ5+t5r/85r/jJDfbXqtzY/9 g/aS26WUlveOgf/0/wP7kHuE/v8feKV2uazAnn63mv/zmv+MkN9teq3Nj/2D9pLbpZSW946B//T/ A/uQe4T+/x94pXa5rMCefrea//Oa/4yQ3216rc2P/YP2ktullJb3jrv/AImB/4b/J/uQ6ErT7P91 lHK5tpFxg62i//92/6WZ+oGOtdaPfYfGjITHoZj2db+B//X/J/uQ6ErT7P91lHK5tpFxg62i//92 /6WZ+oGOtdaPfYfGjITHoZj2db+B//X/J/uQ6ErT7P91lHK5tpFxg62i//92/6WZ+oGOtdaPfYfG jITHoZj2db+8/wBSgf+B//r/Af79/P8BjP79/wD++v8A/f7/At+r04H/6f8B/v38/wGM/v3/AP76 /wD9/v8C36vTgf/p/wH+/fz/AYz+/f8A/vr/AP3+/wLfq9O8/wAlgf+B//P/Afz+8f8A/IH/4P8B /P7x/wD8gf/g/wH8/vH/APy6/wAMgf+B/4H/gf+B/7H/AHmB/47/Affw/f8C9v/29f8F/fT///v7 /f8C8Ovz9/8F9v7+7//3+f8A9Ij/Affw/f8C9v/29f8F/fT///v7/f8C8Ovz9/8F9v7+7//3+f8A 9Ij/Affw/f8C9v/29f8F/fT///v7/f8C8Ovz9/8F9v7+7//3+f8A9Mf/AL6B/4//A7yYm7r+/xSG /4b/8f/27vf5+fX0//+Jgf//xML9/xtrqMn84//27f/v9v//qPB7p53F9+r/8/f/8P+pif8DvJib uv7/FIb/hv/x//bu9/n59fT//4mB///Ewv3/G2uoyfzj//bt/+/2//+o8HunncX36v/z9//w/6mJ /wO8mJu6/v8Uhv+G//H/9u73+fn19P//iYH//8TC/f8ba6jJ/OP/9u3/7/b//6jwe6edxffq//P3 //D/qcf/AMGB/4//A4b/ss/+/xRNk2Kuo51yvYF/tZB6//92i+//xML9/xxkk9iuoKJmiaOWYf/8 l7XR//+PeJrie52Xq6691or/A4b/ss/+/xRNk2Kuo51yvYF/tZB6//92i+//xML9/xxkk9iuoKJm iaOWYf/8l7XR//+PeJrie52Xq6691or/A4b/ss/+/xRNk2Kuo51yvYF/tZB6//92i+//xML9/xxk k9iuoKJmiaOWYf/8l7XR//+PeJrie52Xq6691sj/AMGB/4//A43p4oD+/xSG/4aHrJyP4K6ko9SP /+icf5j/xML9/xyG//+JopCPzILge//1jdal/aSPvHy7qtCP+4i7yIr/A43p4oD+/xSG/4aHrJyP 4K6ko9SP/+icf5j/xML9/xyG//+JopCPzILge//1jdal/aSPvHy7qtCP+4i7yIr/A43p4oD+/xSG /4aHrJyP4K6ko9SP/+icf5j/xML9/xyG//+JopCPzILge//1jdal/aSPvHy7qtCP+4i7yMj/AMSB /4//PPqdkubA///D/8ProtPH/7Gr3erH//+tqrr/4o+Tv///w///vqzGx+bLpHb//3P/uJjlx8ae 9LK515rrfvaK/zz6nZLmwP//w//D66LTx/+xq93qx///raq6/+KPk7///8P//76sxsfmy6R2//9z /7iY5cfGnvSyudea6372iv88+p2S5sD//8P/w+ui08f/savd6sf//62quv/ij5O////D//++rMbH 5sukdv//c/+4mOXHxp70srnXmut+9sj/ADSB/4H/5/8G8qHJ///M/fX/AMmB/+H/BvKhyf//zP31 /wDJgf/h/wbyocn//8z99f8Aycf/AAyB/4H/gf+B/4H/sf8Aa4H/iv8C++vy/f8J9v/z///3///6 /PX/AvTr9PX/BPv7///0gf/+/wL76/L9/wn2//P///f///r89f8C9Ov09f8E+/v///SB//7/Avvr 8v3/Cfb/8///9///+vz1/wL06/T1/wT7+///9MH/AKeB/4r/A8uAopD+/yqGyJj27sX36rrM9fby +/zj//bt///P0V6Yq/bu9/n/7f384//4usfz/tbSgf8F///LgKKQ/v8qhsiY9u7F9+q6zPX28vv8 4//27f//z9FemKv27vf5/+39/OP/+LrH8/7W0oH/Bf//y4CikP7/KobImPbuxffqusz19vL7/OP/ 9u3//8/RXpir9u73+f/t/fzj//i6x/P+1tLC/wCngf+K/wPLboa2/v8qW1z/i6uPeJqvkHmMr4mu oKJmidX/lPdSeLVyvYF/xpOprqCidnulkYn/lIH/Bf//y26Gtv7/Kltc/4urj3iar5B5jK+JrqCi ZonV/5T3Uni1cr2Bf8aTqa6gonZ7pZGJ/5SB/wX//8tuhrb+/ypbXP+Lq494mq+QeYyvia6gomaJ 1f+U91J4tXK9gX/Gk6muoKJ2e6WRif+Uwv8Ap4H/iv8Dy7uytv7/Kn3HoI//j7x8mNSPj/+PiaKQ j8zD/4P3j/1+j+CupJ3c0Imij4a6ipKM/4OB/wX//8u7srb+/yp9x6CP/4+8fJjUj4//j4mikI/M w/+D94/9fo/grqSd3NCJoo+GuoqSjP+Dgf8F///Lu7K2/v8qfcegj/+PvHyY1I+P/4+JopCPzMP/ g/eP/X6P4K6kndzQiaKPhrqKkoz/g8L/AKeB/4r/MeXd/7O////D/7PF/8fGntPqx8f/x76sxsfm 4f+c04uU38f/sav5psy+rMa7p92nwNSfgf8z///l3f+zv///w/+zxf/Hxp7T6sfH/8e+rMbH5uH/ nNOLlN/H/7Gr+abMvqzGu6fdp8DUn4H/M///5d3/s7///8P/s8X/x8ae0+rHx//HvqzGx+bh/5zT i5Tfx/+xq/mmzL6sxrun3afA1J/C/wAogf+B/+7/AfvO7/8BzfuB/+P/AfvO7/8BzfuB/+P/AfvO 7/8BzfvC/wAMgf+B/4H/gf+B/7H/AHmB/5T/AvX/9v7/APfr/wL07+/2/wD3/P8L/uvr8P///vj/ //74+f8A9JP/AvX/9v7/APfr/wL07+/2/wD3/P8L/uvr8P///vj///74+f8A9JP/AvX/9v7/APfr /wL07+/2/wD3/P8L/uvr8P///vj///74+f8A9Mz/AOKB/5T/AkXjjP7/QJD1///x/ff78ez98v/p 9fby+/bu///wuGiid//z/vX/9ZP55P2P7f/4+f/4qFi9/vPrpP7z7qDy//D/9Ov1/LbxlP8CReOM /v9AkPX///H99/vx7P3y/+n19vL79u7///C4aKJ3//P+9f/1k/nk/Y/t//j5//ioWL3+8+uk/vPu oPL/8P/06/X8tvGU/wJF44z+/0CQ9f//8f33+/Hs/fL/6fX28vv27v//8Lhoonf/8/71//WT+eT9 j+3/+Pn/+KhYvf7z66T+8+6g8v/w//Tr9fy28c3/AOKB/5T/Aod5i/7/QJD1/5ijsoyhg6pld9yk bYyviXSto/+g9Ib/mb+RiY//j3Grj7xliNF9fvv//4b/hI7KpISOzWeql6uuZHikjvGilP8Ch3mL /v9AkPX/mKOyjKGDqmV33KRtjK+JdK2j/6D0hv+Zv5GJj/+PcauPvGWI0X1++///hv+EjsqkhI7N Z6qXq65keKSO8aKU/wKHeYv+/0CQ9f+Yo7KMoYOqZXfcpG2Mr4l0raP/oPSG/5m/kYmP/49xq4+8 ZYjRfX77//+G/4SOyqSEjs1nqperrmR4pI7xos3/AOKB/5T/AovSNP7/QJD1/3Ssr5OSj/+Pm7WV aI//j4//kP+U74b/f6uSjI79g5DdoYyPzaxwje7//4b/ZJ29pGSdwGWfj/uIj6vkkO2WlP8Ci9I0 /v9AkPX/dKyvk5KP/4+btZVoj/+Pj/+Q/5Tvhv9/q5KMjv2DkN2hjI/NrHCN7v//hv9knb2kZJ3A ZZ+P+4iPq+SQ7ZaU/wKL0jT+/0CQ9f90rK+Tko//j5u1lWiP/4+P/5D/lO+G/3+rkoyO/YOQ3aGM j82scI3u//+G/2SdvaRkncBln4/7iI+r5JDtls3/AOKB/5T/L8X/rO3S/8iTqdig58S4x//HzeGi p8f/x8f/yP/OpZ6Sy/mnwN6mw8TOn8vH5uGzrv7/E8P/xaHv0sWh8dC81prrx9XxyKLRlP8vxf+s 7dL/yJOp2KDnxLjH/8fN4aKnx//Hx//I/86lnpLL+afA3qbDxM6fy8fm4bOu/v8Tw//Foe/SxaHx 0LzWmuvH1fHIotGU/y/F/6zt0v/Ik6nYoOfEuMf/x83hoqfH/8fH/8j/zqWeksv5p8DepsPEzp/L x+bhs67+/xPD/8Wh79LFofHQvNaa68fV8cii0c3/ACuB/4j/AaL+8v8Aydr/AMmH/wGi/vL/AMna /wDJh/8Bov7y/wDJ2v8Aycz/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wBrgf+D/wPE9fbD /v8DpY3ivv3/AfXJ/v8F3uyvl9vH+f8B6uCB//H/A8T19sP+/wOljeK+/f8B9cn+/wXe7K+X28f5 /wHq4IH/8f8DxPX2w/7/A6WN4r79/wH1yf7/Bd7sr5fbx/n/Aergu/8AfYH/g/8jmdPVl////mvr yXud2qyQ4G+W//+c0K//wr3jodKilPGbk/+cgf/x/yOZ09WX///+a+vJe53arJDgb5b//5zQr//C veOh0qKU8ZuT/5yB//H/I5nT1Zf///5r68l7ndqskOBvlv//nNCv/8K946HSopTxm5P/nLv/AH2B /4P/I5mipJf///nTkaCH+5KefriZlff/jrfN/+WPh6KOgsm9k135joH/8f8jmaKkl///+dORoIf7 kp5+uJmV9/+Ot83/5Y+Hoo6Cyb2TXfmOgf/x/yOZoqSX///505Ggh/uSnn64mZX3/463zf/lj4ei joLJvZNd+Y67/wB9gf+D/yOZ7e+Xv//4dJekj/+PcYOuoZr1/3X1fJikj7airI/MrX1g73WB//H/ I5nt75e///h0l6SP/49xg66hmvX/dfV8mKSPtqKsj8ytfWDvdYH/8f8jme3vl7//+HSXpI//j3GD rqGa9f919XyYpI+2oqyPzK19YO91u/8AWIH/gf/7/wD6/f8A/fv/A6ji//z+/wD9/f8D/P/fq4H/ 6f8A+v3/AP37/wOo4v/8/v8A/f3/A/z/36uB/+n/APr9/wD9+/8DqOL//P7/AP39/wP8/9+ru/8A IoH/gf/u/wD89f8A/IH/2/8A/PX/APyB/9v/APz1/wD8uv8ADIH/gf+B/4H/gf+x/wDWgf+c/wK8 j8n+/wTblbHX5v3/AL77/wC++/8T3PLP/+2Y5f/2wuKx88f//8T19sP9/wPC/f+//f8K/cH//8uW k6v//8f0/wDLo/8CvI/J/v8E25Wx1+b9/wC++/8Avvv/E9zyz//tmOX/9sLisfPH///E9fbD/f8D wv3/v/3/Cv3B///LlpOr///H9P8Ay6P/AryPyf7/BNuVsdfm/f8Avvv/AL77/xPc8s//7Zjl//bC 4rHzx///xPX2w/3/A8L9/7/9/wr9wf//y5aTq///x/T/AMvU/wESgf+c/wJ24sb+/1B//8e2j6rV mr2PvcaOz5q9e5jerJDlhnDEx//Odtz//4yei7nV//+Z09WXrJDvm1ntk2jVmr3ClpT/xdaB8PW+ nr3GmM6ZxbSV7Ju8v6q+08ik/wJ24sb+/1B//8e2j6rVmr2PvcaOz5q9e5jerJDlhnDEx//Odtz/ /4yei7nV//+Z09WXrJDvm1ntk2jVmr3ClpT/xdaB8PW+nr3GmM6ZxbSV7Ju8v6q+08ik/wJ24sb+ /1B//8e2j6rVmr2PvcaOz5q9e5jerJDlhnDEx//Odtz//4yei7nV//+Z09WXrJDvm1ntk2jVmr3C lpT/xdaB8PW+nr3GmM6ZxbSV7Ju8v6q+08jV/wESgf+c/wLanob+/yOF/+y0zY3FoHtxfbnNxaB7 hf6Inn63mpzioP+Xeo///5WWoIv+/ymZoqSXnn6js4mc5oTFoHuG75T/kP1opMSK/I+H+8GCvpyH oeWNi/eN+5Kk/wLanob+/yOF/+y0zY3FoHtxfbnNxaB7hf6Inn63mpzioP+Xeo///5WWoIv+/ymZ oqSXnn6js4mc5oTFoHuG75T/kP1opMSK/I+H+8GCvpyHoeWNi/eN+5Kk/wLanob+/yOF/+y0zY3F oHtxfbnNxaB7hf6Inn63mpzioP+Xeo///5WWoIv+/ymZoqSXnn6js4mc5oTFoHuG75T/kP1opMSK /I+H+8GCvpyHoeWNi/eN+5LV/wESgf+c/1aDmIy///+cmXy31I+TqXOPpJnWk6lzdp69cYOtoqq1 oP+XlVPy/6+d4nD/v/+Z7e+XcYOwel3MiWmTqXORnZX/qMxjk6KP/4+imqScjaGGsZB+j/+Pyayk /1aDmIy///+cmXy31I+TqXOPpJnWk6lzdp69cYOtoqq1oP+XlVPy/6+d4nD/v/+Z7e+XcYOwel3M iWmTqXORnZX/qMxjk6KP/4+imqScjaGGsZB+j/+Pyayk/1aDmIy///+cmXy31I+TqXOPpJnWk6lz dp69cYOtoqq1oP+XlVPy/6+d4nD/v/+Z7e+XcYOwel3MiWmTqXORnZX/qMxjk6KP/4+imqScjaGG sZB+j/+PyazV/wDKgf+b/wD6/P8A/Pz/APz7/wX8///+//39/wD+/v8B/P70/xD9///9///9///8 ///9///zlvr/B/3//P///P/9/f8BlfWj/wD6/P8A/Pz/APz7/wX8///+//39/wD+/v8B/P70/xD9 ///9///9///8///9///zlvr/B/3//P///P/9/f8BlfWj/wD6/P8A/Pz/APz7/wX8///+//39/wD+ /v8B/P70/xD9///9///9///8///9///zlvr/B/3//P///P/9/f8BlfXV/wAigf+B/9v/APvu/wD7 gf/i/wD77v8A+4H/4v8A++7/APvU/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B /4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAMgf+B/4H/ gf+B/7H/AAyB/4H/gf+B/4H/sf8AZYH/gv8Q/fnv6/Dy6+v16+v/+f/59/v9/wL36/z8/wH394H/ 7P8Q/fnv6/Dy6+v16+v/+f/59/v9/wL36/z8/wH394H/7P8Q/fnv6/Dy6+v16+v/+f/59/v9/wL3 6/z8/wH397f/AHSB/4L/EN2paai7xFiolJqotZ+gs3qd/f8MkKBu+fj5+eyOxfby+4H/7/8Q3alp qLvEWKiUmqi1n6Czep39/wyQoG75+Pn57I7F9vL7gf/v/xDdqWmou8RYqJSaqLWfoLN6nf3/DJCg bvn4+fnsjsX28vu6/wB3gf+C/yHdqWOUuv+G/5yHrcFsnv+D///9/f+QjV71fX62g4yPjK+Jgf/v /yHdqWOUuv+G/5yHrcFsnv+D///9/f+QjV71fX62g4yPjK+Jgf/v/yHdqWOUuv+G/5yHrcFsnv+D ///9/f+QjV71fX62g4yPjK+Juv8Ad4H/gv8C3amG/v8Whv+c6v+P/Yrqnv//urL/kPWvtXCNrNX+ jwH/j4H/7/8C3amG/v8Whv+c6v+P/Yrqnv//urL/kPWvtXCNrNX+jwH/j4H/7/8C3amG/v8Whv+c 6v+P/Yrqnv//urL/kPWvtXCNrNX+jwH/j7r/AHGB/4L/D+7Un5Oi/8P/zvX/6KXY4+L8/wfIk6D+ s67c6/7HAf/Hgf/v/w/u1J+Tov/D/871/+il2OPi/P8HyJOg/rOu3Ov+xwH/x4H/7/8P7tSfk6L/ w//O9f/opdjj4vz/B8iToP6zrtzr/scB/8e6/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8A DIH/gf+B/4H/gf+x/wAMgf+B/4H/gf+B/7H/AAyB/4H/gf+B/4H/sf8ADIH/gf+B/4H/gf+x/wAM gf+B/4H/gf+B/7H/AGWB/4H/D//p39Pk0+XT5ub33PL58eb9/wb48OPt9tn+wP8A86n/Dunf0+TT 5dPm5vfc8vnx5v3/Bvjw4+322f7A/wDzqf8O6d/T5NPl0+bm99zy+fHm/f8G+PDj7fbZ/sD/APP2 /wBrgf+B/xr/fmOO117BYLZHvXbP47KBlbKo1fR/LYF5qc/B/wHcnqn/GX5jjtdewWC2R712z+Oy gZWyqNX0fy2BeanPwf8B3J6p/xl+Y47XXsFgtke9ds/jsoGVsqjV9H8tgXmpz8H/Adye9v8AaIH/ gf8a/35rrvt+23fAariO/9mkZpXZcaz/SI1icp99wP8Asan/GX5rrvt+23fAariO/9mkZpXZcaz/ SI1icp99wP8Asan/GX5rrvt+23fAariO/9mkZpXZcaz/SI1icp99wP8Asfb/AGiB/4H/Gv/UwKry 1PPg/rX22f/z0KrE9rrm/8v30uut7sD/AOWp/xnUwKry1PPg/rX22f/z0KrE9rrm/8v30uut7sD/ AOWp/xnUwKry1PPg/rX22f/z0KrE9rrm/8v30uut7sD/AOX2/wAMgf+B/4H/gf+B/7H/AAD/AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5 rkQAAAAF1c3VnC4bEJOXCAArLPmuSAQAAAQEAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACwAAAA BAAAAMQAAAAGAAAAzAAAAAcAAADUAAAACAAAANwAAAAJAAAA5AAAAAoAAADsAAAAFwAAAPQAAAAL AAAA/AAAABAAAAAEAQAAEwAAAAwBAAAWAAAAFAEAAA0AAAAcAQAADAAAAKsDAAACAAAA6f0AAB4A AAAYAAAAT24tc2NyZWVuIFNob3cgKDQ6MykAAAAAHgAAAAwAAABJVCBUZWxlY29tAAADAAAAF4UE AAMAAACEAAAAAwAAAAgAAAADAAAACAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAOAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAABgAAAAGAAAAQXJpYWwAFwAAAO+8re+8syDvvLDj grTjgrfjg4Pjgq8ACgAAAFdpbmdkaW5ncwAIAAAAaWV0Zi02OQAKAAAAMV9pZXRmLTY5AAoAAAAy X2lldGYtNjkACgAAADNfaWV0Zi02OQAKAAAANF9pZXRmLTY5AAoAAAA1X2lldGYtNjkACgAAADZf aWV0Zi02OQAKAAAAN19pZXRmLTY5AAoAAAA4X2lldGYtNjkACgAAADlfaWV0Zi02OQALAAAAMTBf aWV0Zi02OQALAAAAMTFfaWV0Zi02OQALAAAAMTJfaWV0Zi02OQCDAAAASW50ZXJmYWNlIHRvIHRo ZSBSb3V0aW5nIFN5c3RlbSAoSTJSUykgZm9yIFNlcnZpY2UgQ2hhaW5pbmc6IFVzZSBDYXNlcyBh bmQgUmVxdWlyZW1lbnRzICAgZHJhZnQtYml0YXItaTJycy1zZXJ2aWNlLWNoYWluaW5nLTAwLnR4 dAAIAAAAT3V0bGluZQAUAAAAT2JqZWN0aXZlIGFuZCBTY29wZQBHAAAAU2VydmljZSBUb3BvbG9n eSBhbmQgUmVzb3VyY2UgRGlzY292ZXJ5L1JlcHJlc2VudGF0aW9uIGFuZCBNYWludGVuYW5jZQAY AAAAU2VydmljZSBOb2RlIE1vbml0b3JpbmcANAAAAFRyYWZmaWMgQ2xhc3NpZmljYXRpb24gYW5k IFNlcnZpY2UgQ2hhaW5pbmcgQ29udHJvbAA1AAAAU2NhbGFiaWxpdHkgUmVxdWlyZW1lbnRzIGFu ZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwAWAAAAICAgICAgICAgICBOZXh0IFN0ZXBzAAwQAAAG AAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAADAAAAHgAAAAYAAABUaGVtZQADAAAADQAAAB4AAAAN AAAAU2xpZGUgVGl0bGVzAAMAAAAIAAAAAAAAUAAAAAMAAAAAAAAAIAAAAAEAAAA8AAAAAgAAAEQA AAABAAAAAgAAABAAAABfTmV3UmV2aWV3Q3ljbGUAAgAAAOn9AAAeAAAABAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPYPIwAAABQAAABfwJHj84QEAAsA9AMDAAAATmFiaWwgQml0YXIIAAAATgBhAGIAaQBs ACAAQgBpAHQAYQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA== --_002_CE1F9569942B3nabilnbitarverizoncom_-- From hadi@mojatatu.com Thu Aug 1 02:08:15 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D93321F9BF1 for ; Thu, 1 Aug 2013 02:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acgROC6S4sbA for ; Thu, 1 Aug 2013 02:08:11 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8D921F9D28 for ; Thu, 1 Aug 2013 02:08:04 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so1981302veb.2 for ; Thu, 01 Aug 2013 02:08:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jBgVeeeCm1uO5W5d2jKNbv/43Ef5lSRlfuji6o0NSbU=; b=jfqLK2QHD+qQIfPBi1NeDtRx4Km3Rtnq4249/e17LnzeJgKGETktv3mKn8V4uyN/oA hFggt/KI1tKos5PQdhahT7r7S/FgecAxhs7+w7siUmTRk6lBwHDnsWjF3mFkV1+f9dSF 3PA/3cztVBQYg8QKDE1yknhwdjXR4Zvul4zHL/QSseKJ24Bv4vfFvpj8EVA/WtfCvxJ7 4fb8y32ep8bKHkxphX54K82vdIBbakWgNGYu00DjeT5J2hWoFK+tRstcWmKoGznCswg6 CPG5kncci/84lWDNVt3TO9AqlOn3LxS1+El0hVNk0ApRFTD/j5aHUrnIMxGgwrNFhsjk hiYA== X-Received: by 10.52.164.146 with SMTP id yq18mr127984vdb.73.1375348083491; Thu, 01 Aug 2013 02:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Thu, 1 Aug 2013 02:07:43 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Thu, 1 Aug 2013 05:07:43 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJQHx/sWt0roExhzS0NmEUh3O2pLS1UbLz7x+r5XaWEIdegzBHyuX2XA1Vz9cJoF6W56vx Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:08:15 -0000 I have the draft and support its adoption. Some comments: 1) ForCES model can support different levels of granularities. Yes, original intent was to do datapath control-southbound interfaces; but it is very usable in wide range of applications that desire a model. Example, if you attended the ForCES meeting you may have seen a demo where ForCES was used to model VMs doing arbitrary network functions where the ForCES was then used to orchestrate that infrastructure. 2) I think we may end up needing more clarity on the transport. Merely saying you'd use congestion-aware transport and spelling out desire for different levels of reliability is insufficient. An I2RS agent is a proxy; reliability and congestion control need to take into consideration those two requirements above the transport layer. 3) identity/roles It would be useful to specify some sample space of common practise. cheers, jamal On Wed, Jul 24, 2013 at 5:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From lberger@labn.net Thu Aug 1 04:41:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308E21E80CF for ; Thu, 1 Aug 2013 04:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.833 X-Spam-Level: X-Spam-Status: No, score=-101.833 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6FnWUf4UkNf for ; Thu, 1 Aug 2013 04:40:59 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id CB07621E80CA for ; Thu, 1 Aug 2013 04:40:58 -0700 (PDT) Received: (qmail 7804 invoked by uid 0); 1 Aug 2013 11:40:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 1 Aug 2013 11:40:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Fj4n7lGcQ/MNwfZqTLTPDiV+T5heunwZsIIUKZnzbvc=; b=Qu8Z5bue15c+wuabIlhaJMrM6o6VQJffYRqmO6TSeN98YeV45IMIj/FJOHia61pnMl5l/GY1/Z+UwyUn3S4PTtu6lESZw8lP9bKbkg6HrXRb4VBVB8Zdnhk95GPywg0E; Received: from box313.bluehost.com ([69.89.31.113]:60286 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4rFA-0000zc-S6; Thu, 01 Aug 2013 05:40:33 -0600 Message-ID: <51FA492D.3070402@labn.net> Date: Thu, 01 Aug 2013 13:40:29 +0200 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel.Halpern@ericsson.com X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" Subject: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:41:04 -0000 Hi Joel, In today's session, I asked about provisions in the architecture (document) for Client Redundancy/Fault Tolerance. I believe you stated that "it's not needed" and that you'd elaborate on the list. I believe you also answered a latter question by stating that clients are free to coordinate between themselves to provide redundancy. Is this the simple answer? If not, can you elaborate? Thanks, Lou From akatlas@gmail.com Thu Aug 1 04:52:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4D21F9E33 for ; Thu, 1 Aug 2013 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHizPs7MnSt4 for ; Thu, 1 Aug 2013 04:52:14 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0595621F99F3 for ; Thu, 1 Aug 2013 04:51:47 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so4129785oag.15 for ; Thu, 01 Aug 2013 04:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F0aoGGGOiL5MgTlS6+s13kEw4V6HyVr3oae5102E4gI=; b=rbLph3QKlQOLP915CKZ9fUfSH6JypeIQaBAjIhA4vwyD8YgCjv0kFhzPlE28v9lS+Q /OQMP9nFIkA338Mi02em/fB7Fhh+OZSmQdKAXwS6+s4XxFciYfpbERg1QdMBfhzfZ47h w523sAPkBh7RUxGo0I7V96VUCDjKeiejhve/iZqBjmeDfu9t+KmTj8tQwCdUs3YD3ZEP PKWnSorDZ1I6+15UAvrEkiWEupdht4HarH6Rpqc0ndmXcUFZSbRQnb6D/moGJfVrW98j O2wXbvcfznF+EKCdx1LTBKUAJ3zw7Pmt1HUEr4UdR8vD31eqSzBkqG8vXRJX+Tkr5j4X /F+Q== MIME-Version: 1.0 X-Received: by 10.43.65.144 with SMTP id xm16mr104259icb.112.1375357898745; Thu, 01 Aug 2013 04:51:38 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Thu, 1 Aug 2013 04:51:38 -0700 (PDT) In-Reply-To: <51FA492D.3070402@labn.net> References: <51FA492D.3070402@labn.net> Date: Thu, 1 Aug 2013 07:51:38 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=bcaec51b1b6ffe6ef004e2e17650 Cc: "i2rs@ietf.org" , Joel.Halpern@ericsson.com Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:52:14 -0000 --bcaec51b1b6ffe6ef004e2e17650 Content-Type: text/plain; charset=ISO-8859-1 Not to answer for Joel, but my view is that a client is identified by its identity. A different application can take over from the first by using the same identity. Loss of a transport session does not cause existing client state to be removed (in the architecture) - so there is the ability for a new application to take over. Does that help? Alia On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger wrote: > Hi Joel, > In today's session, I asked about provisions in the architecture > (document) for Client Redundancy/Fault Tolerance. I believe you stated > that "it's not needed" and that you'd elaborate on the list. > > I believe you also answered a latter question by stating that clients > are free to coordinate between themselves to provide redundancy. Is this > the simple answer? If not, can you elaborate? > > Thanks, > Lou > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --bcaec51b1b6ffe6ef004e2e17650 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not to answer for Joel, but my view is that a client is id= entified by its identity. =A0A different application can take over from the= first by using the same identity. =A0Loss of a transport session does not = cause existing client state to be removed (in the architecture) - so there = is the ability for a new application to take over.

Does that help?

Alia


On Thu, Aug 1, 2= 013 at 7:40 AM, Lou Berger <lberger@labn.net> wrote:
Hi Joel,
=A0 =A0 =A0 =A0 In today's session, I asked about provisions in the arc= hitecture
(document) for Client Redundancy/Fault Tolerance. I believe you stated
that "it's not needed" and that you'd elaborate on the li= st.

I believe you also answered a latter question by stating that clients
are free to coordinate between themselves to provide redundancy. Is this the simple answer? =A0If not, can you elaborate?

Thanks,
Lou
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--bcaec51b1b6ffe6ef004e2e17650-- From j.schoenwaelder@jacobs-university.de Thu Aug 1 05:03:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2C11E810F for ; Thu, 1 Aug 2013 05:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkPvamADqh8A for ; Thu, 1 Aug 2013 05:02:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B711E812D for ; Thu, 1 Aug 2013 05:02:34 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6568820C06; Thu, 1 Aug 2013 14:02:33 +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 K_L29899iVT4; Thu, 1 Aug 2013 14:02:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0740020BF9; Thu, 1 Aug 2013 14:02:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E787F27A2335; Thu, 1 Aug 2013 14:02:29 +0200 (CEST) Date: Thu, 1 Aug 2013 14:02:29 +0200 From: Juergen Schoenwaelder To: i2rs@ietf.org Message-ID: <20130801120229.GB25597@elstar.local> Mail-Followup-To: i2rs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [i2rs] comments on draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:03:07 -0000 Hi, I have a few comments on draft-atlas-i2rs-architecture-01 I like to share. Overall, I found the document clearly written and well worked out. a) I suggest to remove the last two paragraphs from section 1.1 (the paragraphs that try to make a statement that SNMP, NETCONF, and ForCES do not work for i2rs). Rationale: This is an architectural document and it does not need to explain why certain protocols may not work as i2rs protocols. It is not the job of this document - so simply avoid discussions around this by removing these two paragraphs. b) Is it necessary to describe an example in the middle of the architecture document, given that there is a separate use cases document? My suggestion would be to simply remove section 4.1 (and perhaps consider merging the text left in section 4 into some of the other sections). c) In section 6.9, I suggest to rename 'Perform all' to 'Perform all ignoring errors' or something like that which better highlights the behaviour. Editorial: I think the NETCONF community has settled on spelling NETCONF as NETCONF, not as NetConf. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Thu Aug 1 05:11:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB10421F992E for ; Thu, 1 Aug 2013 05:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOC-EN8mEZa8 for ; Thu, 1 Aug 2013 05:11:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DBE6E21F9CF3 for ; Thu, 1 Aug 2013 05:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 706131BCD8A2; Thu, 1 Aug 2013 05:09:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-427a.meeting.ietf.org (dhcp-427a.meeting.ietf.org [130.129.66.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 83F361BCD8A0; Thu, 1 Aug 2013 05:09:24 -0700 (PDT) Message-ID: <51FA4FF4.2070700@joelhalpern.com> Date: Thu, 01 Aug 2013 08:09:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Lou Berger Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:11:43 -0000 The key point is that client coordination (for standby or any other purpose) is the clients problem. Sharing the identity is one way to do this. I suppose for permission to delete state we might want to have some notion of shared authorization with distinct authentication, but I would prefer not to go there. Yours, Joel On 8/1/13 7:51 AM, Alia Atlas wrote: > Not to answer for Joel, but my view is that a client is identified by > its identity. A different application can take over from the first by > using the same identity. Loss of a transport session does not cause > existing client state to be removed (in the architecture) - so there is > the ability for a new application to take over. > > Does that help? > > Alia > > > On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > wrote: > > Hi Joel, > In today's session, I asked about provisions in the > architecture > (document) for Client Redundancy/Fault Tolerance. I believe you stated > that "it's not needed" and that you'd elaborate on the list. > > I believe you also answered a latter question by stating that clients > are free to coordinate between themselves to provide redundancy. Is this > the simple answer? If not, can you elaborate? > > Thanks, > Lou > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From lberger@labn.net Thu Aug 1 05:12:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0736B21F9DBD for ; Thu, 1 Aug 2013 05:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EDMkbfxZxUq for ; Thu, 1 Aug 2013 05:11:43 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id DDB0921E80D1 for ; Thu, 1 Aug 2013 05:09:46 -0700 (PDT) Received: (qmail 32089 invoked by uid 0); 1 Aug 2013 12:09:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 1 Aug 2013 12:09:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Qw2b7Fqjsbgt+XhHSNTu69ondqtNBo8PYAX2bTQsTmQ=; b=C3syVfAiQeWmoZwNsjtRj7kJW1Edd9CQXkxho5q+NI7/TVP92XDiq5vMGWVubOWZXItHzLdq+krXNAWNMMf7yQboC31xDoNSmKYD6qEmnjXo6TM1wPYWZj/dOoqDFAR5; Received: from box313.bluehost.com ([69.89.31.113]:36845 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4rh3-0002r2-O4; Thu, 01 Aug 2013 06:09:21 -0600 Message-ID: <51FA4FF0.4060902@labn.net> Date: Thu, 01 Aug 2013 08:09:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" , Joel.Halpern@ericsson.com Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:12:03 -0000 Alia, See below. On 08/01/2013 07:51 AM, Alia Atlas wrote: > Not to answer for Joel, but my view is that a client is identified by > its identity. A different application can take over from the first by > using the same identity. Loss of a transport session does not cause > existing client state to be removed (in the architecture) - so there is > the ability for a new application to take over. > > Does that help? > A bit. The discussion of treating multiple writers for the same state as errors got me worried about this case - from a redundancy perspective, and to a lesser degree, accountability standpoint. Given the importance of reliable operation even in the case of client failures, I think the topic should be covered in the architecture document. Of course this topic/comment can be addressed after the document is adopted. Lou > Alia > > > On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > wrote: > > Hi Joel, > In today's session, I asked about provisions in the architecture > (document) for Client Redundancy/Fault Tolerance. I believe you stated > that "it's not needed" and that you'd elaborate on the list. > > I believe you also answered a latter question by stating that clients > are free to coordinate between themselves to provide redundancy. Is this > the simple answer? If not, can you elaborate? > > Thanks, > Lou > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From wesley.george@twcable.com Thu Aug 1 05:18:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1F21E8170 for ; Thu, 1 Aug 2013 05:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxH1h2X305fp for ; Thu, 1 Aug 2013 05:18:02 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id A139621E8220 for ; Thu, 1 Aug 2013 05:17:24 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,793,1367985600"; d="scan'208,217";a="35795690" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Aug 2013 08:16:31 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 1 Aug 2013 08:17:22 -0400 From: "George, Wes" To: "i2rs@ietf.org" Date: Thu, 1 Aug 2013 08:17:24 -0400 Thread-Topic: SDN security and I2RS Thread-Index: Ac5XAaC2GyqmYg7MQsaYk41wAl+X3g3rrfvw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304395E5139@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD592304395E5139PRVPEXVS15cor_" MIME-Version: 1.0 Cc: "draft-hartman-sdnsec-requirements@tools.ietf.org" Subject: [i2rs] FW: SDN security and I2RS X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:18:06 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD592304395E5139PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per the discussion today during the WG meeting, this is the message I sent = to the authors of draft-hartman-sdnsec-requirements. This is the background= info that was to inform the first draft of I2RS security considerations. W= e could use feedback both on the initial discussion summarized in the WG In= terim, and on whether it makes sense to integrate it into this existing sec= urity draft or continue with a standalone draft for I2RS, perhaps with a re= ference to this draft for additional considerations. Thanks, Wes George Authors: I'm not sure if you've been following the I2RS WG much, but we had= an interim meeting not too long ago. The attendees of that group broke up = into smaller groups to discuss different things, and I was heading up the g= roup discussing the security model, because I've been clear in my feedback = that any effort to directly manipulate the routing system will need to have= security as a first-class part of its design from day one, rather than a b= olt-on later. As a result of that discussion, we sketched out the different things we fel= t were important, and were supposed to produce a draft on it. Meantime, I s= aw your draft about SDN security requirements come along, and I think that = perhaps we should do some collaboration, because there's a decent amount of= overlap between what we discussed and what your draft discusses, but it's = not complete, and I'd rather not end up with duplicate drafts. The presentation that resulted from the security discussion is here: http:/= /www.ietf.org/proceedings/interim/2013/04/22/i2rs/slides/slides-interim-201= 3-i2rs-1-12.pdf The meeting minutes from the interim are here, and the record of that prese= ntation's discussion starts at the bottom of page 20. http://www.ietf.org/p= roceedings/interim/2013/04/22/i2rs/minutes/minutes-interim-2013-i2rs-1 I'd be interested in feedback on whether you think this takes the form of a= companion draft, or whether we can incorporate some of these ideas into yo= ur existing framework. I think in a way it would be bolstering the existing= section 3 (and possibly adding some requirements in section 4). I'd be hap= py to contribute some text if I can get some guidance on how best to integr= ate it. Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD592304395E5139PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per the discussion tod= ay during the WG meeting, this is the message I sent to the authors of draf= t-hartman-sdnsec-requirements. This is the background info that was to info= rm the first draft of I2RS security considerations. We could use feedback both on the initial discussion summa= rized in the WG Interim, and on whether it makes sense to integrate it into= this existing security draft or continue with a standalone draft for I2RS,= perhaps with a reference to this draft for additional considerations.

 

Thank= s,

=  

Wes G= eorge

 

 

 

 

Authors: I’m not sure if you’ve been fol= lowing the I2RS WG much, but we had an interim meeting not too long ago. Th= e attendees of that group broke up into smaller groups to discuss different= things, and I was heading up the group discussing the security model, because I’ve been clear in my feedback that any = effort to directly manipulate the routing system will need to have security= as a first-class part of its design from day one, rather than a bolt-on la= ter.

 

As a result of that discussion, we sketched out the = different things we felt were important, and were supposed to produce a dra= ft on it. Meantime, I saw your draft about SDN security requirements come a= long, and I think that perhaps we should do some collaboration, because there’s a decent amount of ove= rlap between what we discussed and what your draft discusses, but it’= s not complete, and I’d rather not end up with duplicate drafts.=

 

The presentation that resulted from the security dis= cussion is here: http://www.ietf.org/proceedings/interim/2013/04/22/i2rs/slides/slides-inter= im-2013-i2rs-1-12.pdf

 

The meeting minutes from the interim are here, and t= he record of that presentation’s discussion starts at the bottom of p= age 20. http://www.ietf.org/proceedings/interim/2013/04/22/i2rs/minutes/minutes-int= erim-2013-i2rs-1

 

 

I’d be interested in feedback on whether you t= hink this takes the form of a companion draft, or whether we can incorporat= e some of these ideas into your existing framework. I think in a way it wou= ld be bolstering the existing section 3 (and possibly adding some requirements in section 4). I’d be happy t= o contribute some text if I can get some guidance on how best to integrate = it.

 

Anyth= ing below this line has been added by my company’s mail server, I hav= e no control over it.

-----= ------------


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD592304395E5139PRVPEXVS15cor_-- From lberger@labn.net Thu Aug 1 05:26:23 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3B21E8191 for ; Thu, 1 Aug 2013 05:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su71INJfqxTi for ; Thu, 1 Aug 2013 05:26:04 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 327D521F9E46 for ; Thu, 1 Aug 2013 05:21:38 -0700 (PDT) Received: (qmail 13786 invoked by uid 0); 1 Aug 2013 12:21:11 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 1 Aug 2013 12:21:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4xLlKmCaxYbtw8e6PjsuJanS5ZtRjvJ9te/pCDy3I1o=; b=artcgwsoNiBZQ1hf56eQofzPQqDDxSpfed4hNhYpK2q+Yr6LS9W9fSL5wQbMJBuP6bylAp+lk27bdbNKJtYWi6c5bmdZyJm5J/C1ae2GXRUpCtnNXeS4SKQUazbH0hJP; Received: from box313.bluehost.com ([69.89.31.113]:38664 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4rsV-00070m-Cf; Thu, 01 Aug 2013 06:21:11 -0600 Message-ID: <51FA52AF.6090104@labn.net> Date: Thu, 01 Aug 2013 08:21:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Joel M. Halpern" References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> In-Reply-To: <51FA4FF4.2070700@joelhalpern.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:26:24 -0000 On 08/01/2013 08:09 AM, Joel M. Halpern wrote: > The key point is that client coordination (for standby or any other > purpose) is the clients problem. Sharing the identity is one way to do > this. > > I suppose for permission to delete state we might want to have some > notion of shared authorization with distinct authentication, but I would > prefer not to go there. Well now you're getting to my AAA comment from the last meeting, i.e., is it okay to lose today's ability for user level traceability on device state changes *on the device*. The current document of course says it is. I'm sure there are some out there who will see this as a pain point, but it also may be acceptable to tell such users to not use I2RS. Lou > > Yours, > Joel > > On 8/1/13 7:51 AM, Alia Atlas wrote: >> Not to answer for Joel, but my view is that a client is identified by >> its identity. A different application can take over from the first by >> using the same identity. Loss of a transport session does not cause >> existing client state to be removed (in the architecture) - so there is >> the ability for a new application to take over. >> >> Does that help? >> >> Alia >> >> >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > > wrote: >> >> Hi Joel, >> In today's session, I asked about provisions in the >> architecture >> (document) for Client Redundancy/Fault Tolerance. I believe you >> stated >> that "it's not needed" and that you'd elaborate on the list. >> >> I believe you also answered a latter question by stating that clients >> are free to coordinate between themselves to provide redundancy. >> Is this >> the simple answer? If not, can you elaborate? >> >> Thanks, >> Lou >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From akatlas@gmail.com Thu Aug 1 05:31:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1B21F9C10 for ; Thu, 1 Aug 2013 05:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xiJAH7J4Kw7 for ; Thu, 1 Aug 2013 05:31:16 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5321E80DE for ; Thu, 1 Aug 2013 05:25:23 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so3754277obc.10 for ; Thu, 01 Aug 2013 05:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n3S2Mv+uxsbHt/G9sKcZ4CXk8u9Q7pIT2Q6N+kUE5Uw=; b=WjKboUbOXU/p1l+dHRhM0AwSN0l4ppTWXw/HtDGXNbB1XGg6rRBQMLy67SwDaPz5SK bzvdYSTwfIExF14TnvDYdSPHCF8dT63n/BdM8gNgZBvdQyrgL1n1VUETxL0am+uOSU/n PX1Ou78LadGq4XB3RW86wR/JeDX2agJ3uY5Xo3sn4sN7bsqrXeUqepiYx34tGmX95I41 d19jwdu/IgoDPUVZGsdHJJNGhpR7h+Boqy6HiYbuIE4H3Lat4S4Z6wviKjAYtSbwJ0wM LoMif7XUwTGN9LlkvGRwxgo+ZsxE0beRTj3GfZSkm2zBNQfGHHO5+58hmuJSmJNqf39g yudQ== MIME-Version: 1.0 X-Received: by 10.43.61.199 with SMTP id wx7mr135011icb.14.1375359903508; Thu, 01 Aug 2013 05:25:03 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Thu, 1 Aug 2013 05:25:03 -0700 (PDT) In-Reply-To: <51FA52AF.6090104@labn.net> References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> <51FA52AF.6090104@labn.net> Date: Thu, 1 Aug 2013 08:25:03 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=bcaec51f96af7cb2e804e2e1eec8 Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:31:38 -0000 --bcaec51f96af7cb2e804e2e1eec8 Content-Type: text/plain; charset=ISO-8859-1 Lou, You think the secondary identity that we put in is insufficient? Alia On Thu, Aug 1, 2013 at 8:21 AM, Lou Berger wrote: > On 08/01/2013 08:09 AM, Joel M. Halpern wrote: > > The key point is that client coordination (for standby or any other > > purpose) is the clients problem. Sharing the identity is one way to do > > this. > > > > I suppose for permission to delete state we might want to have some > > notion of shared authorization with distinct authentication, but I would > > prefer not to go there. > > Well now you're getting to my AAA comment from the last meeting, i.e., > is it okay to lose today's ability for user level traceability on device > state changes *on the device*. The current document of course says it > is. I'm sure there are some out there who will see this as a pain point, > but it also may be acceptable to tell such users to not use I2RS. > > Lou > > > > > Yours, > > Joel > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > >> Not to answer for Joel, but my view is that a client is identified by > >> its identity. A different application can take over from the first by > >> using the same identity. Loss of a transport session does not cause > >> existing client state to be removed (in the architecture) - so there is > >> the ability for a new application to take over. > >> > >> Does that help? > >> > >> Alia > >> > >> > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >> > wrote: > >> > >> Hi Joel, > >> In today's session, I asked about provisions in the > >> architecture > >> (document) for Client Redundancy/Fault Tolerance. I believe you > >> stated > >> that "it's not needed" and that you'd elaborate on the list. > >> > >> I believe you also answered a latter question by stating that > clients > >> are free to coordinate between themselves to provide redundancy. > >> Is this > >> the simple answer? If not, can you elaborate? > >> > >> Thanks, > >> Lou > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > --bcaec51f96af7cb2e804e2e1eec8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Lou,

You think the secondary identity t= hat we put in is insufficient?

Alia


On Thu, Aug 1, 2= 013 at 8:21 AM, Lou Berger <lberger@labn.net> wrote:
On 08/01/2013 08:09 AM, Jo= el M. Halpern wrote:
> The key point is that client coordination (for standby or any other > purpose) is the clients problem. =A0Sharing the identity is one way to= do
> this.
>
> I suppose for permission to delete state we might want to have some > notion of shared authorization with distinct authentication, but I wou= ld
> prefer not to go there.

Well now you're getting to my AAA comment from the last meeting, = i.e.,
is it okay to lose today's ability for user level traceability on devic= e
state changes *on the device*. The current document of course says it
is. I'm sure there are some out there who will see this as a pain point= ,
but it also may be acceptable to tell such users to not use I2RS.

Lou

>
> Yours,
> Joel
>
> On 8/1/13 7:51 AM, Alia Atlas wrote:
>> Not to answer for Joel, but my view is that a client is identified= by
>> its identity. =A0A different application can take over from the fi= rst by
>> using the same identity. =A0Loss of a transport session does not c= ause
>> existing client state to be removed (in the architecture) - so the= re is
>> the ability for a new application to take over.
>>
>> Does that help?
>>
>> Alia
>>
>>
>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
>> <mailto:lberger@labn.net>> wrote:
>>
>> =A0 =A0 Hi Joel,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0In today's session, I asked about p= rovisions in the
>> =A0 =A0 architecture
>> =A0 =A0 (document) for Client Redundancy/Fault Tolerance. I believ= e you
>> stated
>> =A0 =A0 that "it's not needed" and that you'd el= aborate on the list.
>>
>> =A0 =A0 I believe you also answered a latter question by stating t= hat clients
>> =A0 =A0 are free to coordinate between themselves to provide redun= dancy.
>> Is this
>> =A0 =A0 the simple answer? =A0If not, can you elaborate?
>>
>> =A0 =A0 Thanks,
>> =A0 =A0 Lou
>> =A0 =A0 _______________________________________________
>> =A0 =A0 i2rs mailing list
>> =A0 =A0 i2rs@ietf.org <mai= lto:i2rs@ietf.org>
>> =A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>


--bcaec51f96af7cb2e804e2e1eec8-- From cpignata@cisco.com Thu Aug 1 06:02:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7671021F992B for ; Thu, 1 Aug 2013 06:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.669 X-Spam-Level: X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shvPmyslKnTm for ; Thu, 1 Aug 2013 06:02:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D421F9E44 for ; Thu, 1 Aug 2013 06:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33205; q=dns/txt; s=iport; t=1375362071; x=1376571671; h=from:to:subject:date:message-id:mime-version; bh=iCQev8tMOayuBu4Mqdq0iuGBATCAwlSgU1s3ObOACpo=; b=Y6EvAptjswZG/JyWReLIiQt4D0ovM/LrVyIeIQQUbQ6pyJsLLZK6LzQz /8ZQn+y8cS8uCWrobI7tjOVs8wMlk4jrWrJp1YyXYggOOThy84EPZ6HUN ucwGPZXxgy3NndZi/p0awVSK2H4PaXv20bDlxinqNy8vGALKgjDEUjrX0 E=; X-Files: ietf87-i2rs-minutes.html, signature.asc : 31464, 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFACNb+lGtJV2b/2dsb2JhbABbgwY1ULYRiDaBHhZ0giYBBA4MA0gHAgQEFQEaEAIUAT8XEAQbBgYLh3EMmQGgUY4/gRczgx5zA41dgjWBLYdKkCSDFIFxOQ X-IronPort-AV: E=Sophos;i="4.89,794,1367971200"; d="asc'?html'217?scan'217,208,217";a="242056562" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 01 Aug 2013 13:00:40 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r71D0dif003279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 13:00:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 08:00:39 -0500 From: "Carlos Pignataro (cpignata)" To: "i2rs@ietf.org" Thread-Topic: Minutes for IETF87, I2RS WG meeting Thread-Index: AQHOjrces56E6WKKTU+jiHCU53VPwA== Date: Thu, 1 Aug 2013 13:00:39 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D6E09C@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_6CFA0987-AF0E-45A4-BB5C-92B81F640F6E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [i2rs] Minutes for IETF87, I2RS WG meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:02:45 -0000 --Apple-Mail=_6CFA0987-AF0E-45A4-BB5C-92B81F640F6E Content-Type: multipart/mixed; boundary="Apple-Mail=_77FC1D54-7671-417A-80F7-263D6129AD1B" --Apple-Mail=_77FC1D54-7671-417A-80F7-263D6129AD1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I2RS, Please find attached the minutes from today's I2RS meeting. Comments and = corrections are most welcome!! Thanks, -- Carlos. --Apple-Mail=_77FC1D54-7671-417A-80F7-263D6129AD1B Content-Disposition: attachment; filename=ietf87-i2rs-minutes.html Content-Type: text/html; x-unix-mode=0644; name="ietf87-i2rs-minutes.html" Content-Transfer-Encoding: 7bit /ietf87-i2rs Agenda: http://tools.ietf.org/agenda/87/agenda-87-status.html

Scribe: Carlos Pignataro

IETF87 -- Interface to the Routing System (Active WG) 

I2RS WG -- IETF 87, Berlin, Germany           
Thursday, August 1, 2013 from 1pm - 3pm           

Location: Potsdam 3           
WG info: current charter, status page
 Mailing List (archives)

Chairs:
Alia Atlas
Edward Crabbe

Meeting start at 1:05pm local time

Agenda:

Administrivia
(Chairs, 5')
  • Ed: This is the new Note Well, please note it well...
  • ... who is the Jabber scribe? It's Joe Clarke!
  • Alia: thanks for Carlos for volunteering to scribe :-)
  • Ed: Some ground rules:
    • If you go over time, I will cut you off
    • Please state your name before speaking at the mike.
  • ... the big red exclamation point is where we are -- further along that I thought we would
  • ... agenda bashing: there is one more at the end on the agenda online.
  • ... not on the agenda today, there are two drafts, please check them and send comments.



Introduction, Discussion of interim results and current status
(Chairs, 10')
  • Current  status: several new drafts, no expirations, no WG drafts, no WGLCs, no  new RFCs, we are doing really well <laughts in the room>
  • Milestones, it's a copy.
  • Interim  meeting report: Most of the draft authors managed to show up. It was  extremely productive and produced drafts. The notes are online from  Giles, really good notes as usual.
  • and with that...



draft-atlas-i2rs-architecture-01
(J. Halpern, 15')
  • Joel H: I'm Joel Harlpern. This is work a bunch of us did as a design team to propose an architecture for I2RS.
  • We started with two drafts as starting material (Ward and Alia's drafts). 
  • There was a lot here about architecture and a lot that we also took out -- we removed use cases.
  • Keep it simple, clean, and make some choices. We need to make right choices, if wrong, tell us! We can make the change.
  • We wrote proposals on controbersial issues which are our guess and we might be wrong. For example, we removed a bunch of parameters.
  • One of the contentious issues was the issue of Mult-headed control. When discussed, a lot of people mean different things. For us: Can multiple devices write to the single piece of data. Our stance: if that happens, that's "an error".
  • As we define the data model we need to define the atomicity. The core definition is that the same field cannot be written by two guys.
  • Second: If it happens, we need to understand what to do. Would need to understand what to do.
  • Corollary: we do not need to store state for everone elses's value. We do not store alternatives. Increases robustness and simplicity.
  • Should I2RS worry about side effects? You turn off here, and something happens there. We have notifications, but we will not find side effects. Not part of the I2RS client requirement. Other thoughts?
Question:
  • R, from BT: I can see the simplification. But if you have more applications we want to write to the same, we end up with an offbox arbitration who ends up being an NMS.
  • Joel: Part of our thinking is that arbitration is more complex than priority. In I2RS we handle the error gracefully.
  • R: Can you have something intermediate?
  • Joel: I cannot stop you from doing it. But for us it's an error and you won't get a complex system.
  • R: It's the ancient problem of how much rope you give...
  • JOel: we won't have a lot of rope.
  • Ed: In the interim, the issue of backend synchronization came up. These things need to be aware of each other. You can 1. have a broker, or 2. assume these know about each other and they will figure it out, and some subset decomposed in the boxes. The conclusion is that there was not a lot of utility for that case.
Joel continues with slides:
  • Corollaries on persistence, starting and ending, because we want to keep it simple. People can make complicated scenarios. But the I2RS client doing its job covers 90% of the cases. I was exchanging a conversation with a person (forgot their name) talking about time based interactions. But the benefit of simplicitaion outweights the small gain in capability.
  • Corrollary: If I2RS goes away, you go back to the config state.
Question:
  • Wes G: On previous slide, can we clarify if "happens now" is immediately as sent versus schedule during the controller.
  • Joel: I am not sure I follow, let me paraphrase: From the I2RS agent, when it's told to do something, it does it. It does not wait.
  • Wes: We agree, but that's a real important clarification, no complexity during the client.
  • Ed; How many of you read the draft?
  • Joel: Wonderful
  • Ed: I was going to say that's distressfully low.
  • Ed: When we say "client", we mean "controller".
Joel continues with slides:
  • The only addition is notifications for things being deleted and added, requested by Joel Clarke. No problem, we will add it.
  • Transactions: Transaction integrity is *per message*. It's not across larger things. A message could be more than an operation. We have 3 modes of operation or behavious (perform all or none|until error|all). This is the proposal, and I hope we found the right balance.
Question:
  • Someone: Can you clarify the difference between all or none, and all?
  • Joel: all or none is classic SNMP, which is if "all or none" and one fails, then do not do any of them. If it is "all", then if 2 fails, I can still do 1, 3, and 4.
  • The agent does not know, it from the I2RS client what it's requestion, in the message, which behavior.
Joel continues:
  • The architecture draft does not go in "why we do this", use cases, or data models. Brief mentions of RIB, IGP, etc., is to provide context. If you think this is too much, say so on the list. I am one of those guys that prefer short comments.
  • Joel: We had a call for adoption, we received comments, we will take care of them
  • Ed: One chair is co-author, the other will run the IETF process.
Question:
  • Lou B: Redundancy or fault tolerance?
  • Joel: on the list
  • Lou: To be added?
  • Joel: I do not think there is a need to add it, let's discuss on the list.
  • Thomas, from Orange: what about protocol?
  • Joel: Given our charter, the protocol is outside the scope of this architecture. There are use cases which will fall out, won;t address that. If you have a topology abstractor, that's out of scope.
  • Thomas: Interesting!
  • Joel: I agree.
  • Thomas: debatable.
  • Lucy Young, from H: Controller can be redundant controller? 
  • Joel: Writting data is not about authority, it is about practicality. Regarding redundancy I say it is out of scope because charter says I2RS agent talks to many I2RS clients.
  • I am out of time.



draft-nitinb-i2rs-rib-info-model-01
(N. Bahadur, 15')
  • I'd start by apologizing to co-authors, etc.. I have been sick and have not been able to create a collage of the great collaboration.
  • We create a RIB model to program things on the router. It's not just a router or a switch. You can apply this to Hosts. 
  • We said: 1. we should read data, 2. we should write data., 3. we should receive notifications.
  • This is not a data model. That's another I-D, this is an info model.
  • Read:
    • Routes, NHs, info about RIBs. There are some terminology issues in the draft.
    • Writting: NOT to the FIB, only to the RIB manager, who in term decides what goes in the FIB. For routes you can do MPLS routes. The draft tries to use the RIB manager but provide flexibility to the controller.
    • ...What happens when something programmed? You get 2 notifications: is it active? is it installed? Then with this the I2RS client can figure out if this is installed in the FIB without querying the router.
    • Aync notifications are very powerful. Notifications go up to the I2RS client, with "the route you programmed is/is not in the FIB".
  • Nex few slides talk about how we model the RIB. The basic concept is the routing-instance. This is different than the draft published. I think this clears some of the terminology issues. From there we have three elements in the route.
  • The IETF community needs to figure out what to anchor the routing-instance into. A device maybe?
  • A route has 3 things: route-attributes, match, and nexthop-list.
  • A list member can contain a chain. For example you want to chain headers. Or chain header + interface. It's a sequence of operations.
  • And at the lowest level you have a next hop that can be represented by multiple things. NH, logical tunnel (like GRE, or MPLS LSP), or explicit tunnel encap (and you can implement MPLS PP using this model)
  • Devil is in the details. You might argue this feels very complex. If we start with something basic, it would be a lab experiment. This is writting by multiple routing vendors so we understand what's in the field. Instead of later have people say "but we also need this" after the fact.
  • Solving use cases, there are thee examples that can be achieved with this model.
  • We got lots of feedback on the list, really good. Terminology issues are mostly done, and there are other things that need to be fixed. We want to resubmit a draft and re-issue the call for adoption.
Questions:
  • Someone: Terminology differences aside, it is encouraging that this info model is consistent. I want to express my support. I hope we can coordinate our effort.
  • Nitin: We will be coordinating.
  • Jeff Haas: the complexity of this is not bad. It's better than others. Request: as we go through these info models, we need to understand the read vs. right mode of the info model. But also we should keep in mind the read portions are good places to make hooks. Cover the RIB which contains routes. When you want to manage traffic you should say "refer to this information model existing".
  • Thomas Morin: Good doc. But we need to ensure at the WG level that it's happening, not only for your draft but also for others. It would be bad if there;s inconsistencies.
  • Ed: That's acknowledged. As chairs and authors want that.
  • Someone: There was some discussion about PBR in the RIB model. Does that mean it's out of scope?
  • Ed: No, clearly in scope. 
  • Alia: When it becomes a WG draft, make suggestions to the editors.
  • Ed: Address those separately. I cannot comment on the answer because I'm not an author, but it is in scope.
  • Navine Broadcom: Event notifications.
  • Alia: This draft was up for WG adoption. Good discussion on the list. I've not seen a lot of substantive comments on the details of the model. We should have that commentary happening on the actual details of the information model. We have tight timeframe. Other than terminology there seems to be good interest.



draft-atlas-i2rs-problem-statement-01
(T. Nadeau, 10')
  • Tom: Like the architecture, this is one of the early docs.
  • We've only made some minor changes on this doc. Giving a small overview.
  • The problem statement is what you see -- key problem that we think we are solving. It is now fairly aligned to the architecture. 
  • For example, the definition of an Interface to the routing system. As well as data models that describe the interface. And the interface must support a variety of use cases, which is obvious.
  • Data models need to be used to describe the things we will be talking to. We need to describe the RIB (routing system), and Topology.
  • The other key areas are what you do with routing information. And lastly some of the desired elements of an interface.
  • What are we doing now? Alia announced we asked for WG adoption.
  • Alia: I sent out the email, but it was a join desicion.  We co-chairs talk.
  • Ed: Same thing applies here with chair being co-author.
  • Tom: We've god good feedback and a couple of detailed request for edits. One from Ed, one from Carlos, we will be addressing in the next version. Encourage you all to comment on the list for that.
Questions:
  • Alia: we have some wordsmithing comments. WGLC ends on the 12, continue discussion on the mailing list.

I2RS and SDN Security Models
(S. Hartman, 15')
  • Sam: I'm talking about different models and security. The background is that in the Interim you had some discussions, and Wes George had found a draft I had written a while ago of security requirements on the broad SDN context. If you say you are only defining an interface between client and I2RS agent, then there's the question of how if fits in the overall system.
  • You have to be thinking about the security of those impacts for I2RS. Or at least you might want to...
  • Wes asked me to see how much it would take to adapt my draft to I2RS.
  • The question is: do you want security requirements broadly and then see I2RS, or look into the the I2RS specifics only.
  • My co-authors, someone, and Margaret W. who work on security. The draft is pretty old, but I will discuss what's in the draft.
  • On the figure. We are assuming there's a controller, and the controller has multiple applications, and that's interesting from a security standpoint, and is it interesting enough that it affects the interface of I2RS. 
  • Three classes of applications, because they have different security properties.
    • Network sensitive applications. App influences the network environment. Its routing. App talks to routers and switches, possibly mediated by controller doing authorisation, etc.
    • Service for the entire network. Like Firewall. Basically manipulating routers to accomplish that service.
    • Packaged network services. Package up a service and add it to the network as an application. Package a service like a Firwall and drop it in the network. This makes us think.
  • Need for authentication and authorization across multiple organizations. The answer might be that for I2RS there's no impact, but for the broader security architecture there is.
  • Talks about OpenFlow. Maybe take it out and add I2RS stuff. Although if you take this as a starting point, it talks about the broader security applications. And then talk about security that comes in play between I2RS client and server.
  • We have to think about the thread. Yes, error if two people write the same data. But if people are maliscious, there are more interesting questions.
  • Big question is: do you want something this far, with a largest system focus, and include the specifics of I2RS, or have something much more focused only on I2RS
Questions:
  • Wes George: Clarify my involvement. Before I2RS I wanted to get some actual text instead of talking theoretically. That's on my list to do. Unless someone says "no, no", that's where we'd start. If you were not present on the I2RS interim, there are good notes, recording, and a good preso.
  • Alia, with WG Chair hat of: In my view, the scope of I2RS is from the client and interface down. I think the security aspects that we'd do are client down, with understanding that client works on behalf of applications. If you let any applications write any prefixes they want that's not good. Start with the assumption of the same adminsitrative authority controlling router and apps, and then expanding from there.
  • Nancy Can-Widget: You covered some of the points I was going to cover. I am new to I2RS but I cover security. In the presentation that D Mc Grew and I pot together, we have the many-to-many that adds the attack surface.  The group should have security requirements, whichever way you choose.
  • Sam: Whether you assume one trust domain is a big question.
  • Alia -- WG Hat off again: Even if there are different orgs, do they trust each other?
  • Wes: No.
  • Alia: But we need to understand that.
  • Sam: If you assume multiple trust domains security becomes much more interesting. 
  • Ed: Have multiple identities. Notion of redundancy. We need to get down to that level. As much as we have consensus since noone talks about this on the list.
  • Sam: It is a bit more complicated.
  • Nancy: I break it up into two dimensions. Multiple orgs, there is federation of who you are willing to trust, and which applications within the operations. It's a richer policy mechanism.
  • Wes: Maybe the easier way, I will write the background info that I wrote to Sam and send it to the list.
  • Alia: I was going to suggest that there's a few people investigating this topic. Those interested come here after the WG is over so that everyone knows each other.



Thoughts on an I2RS protocol
(E. Crabbe, 10')
  • Ed: I've been talking with vendors and operators.
  • ...As much as much as I can have different opinions with different hats.
  • Alia: it just takes practice.
  • As an operator: I find value of this. I want increased functionality which ties to simplicity. Simple to manage. One of the worst problems in operations is that there is no common APIs and we write screen scraping scripts. We want to avoid that.
  • Speed: We are moving to model-based networking. Models themselves can be fungible but developed quiclky.
  • As well as deployability.
  • One thing that keeps coming up is the number of component protocols involved in the system. I will arbitrarily say 5.
  • With just one protocol we get all these things. We see the IETF issue in as a good example, PCE. We have multiple IGPs doing the same thing.
  • If you have 5 protocols, we retain functionality but through out of the window the simplicity, extensibility, and deployability.
  • So the close we get to this side, the more danger we have of not being practical.
  • I would posit as an IC, that we need one protocol.
  • As a chair: operator feedback is that we want something as simple as possible (and speak up if you disagree or agree).
  • There are significant number of experiments going on in private. Using the term "experiment" loosely. Making things outside the charter because there's demand. That's normal in the IETF, but it's a dychotomy. Alia and I said we would encourage people to present their experiments.
  • I'd encourage people to share your experiments.
  • And that's it.
Questions:
  • Alia: I'd like to echo as co-chair, to share experiments. That's how the WG learns.
  • Ed: Any operator wants to comment? Wes? No yelling? Thanks.

draft-medved-i2rs-topology-im-00
(J. Medved, 15')
  • Jan: Info model for network topologies, in collaboration with many people.
  • Why? Commoon information model for network topology to be used by applications. That's topology at any layer. So we are thinking layer 1, 2, 3, maybe services topologies.
  • We attempt to create a generic topology model, and then extensions, as L3 unicast IGP, and then extensions for the two more common ones, OSPF, and ISIS.
  • The draft uses RBNF. We would like to get a lot of feedback on the mailing list. If the feedback is positive want to ask chairs to issue call of adoption.
Question:
  • Ed: In the Interim meeting we discussed this: topology model is most usable northbound from client or controller. Therefore it might be totally out of charter.
  • Jan: You clearly need an info model, and you need a network topology view to drive those requirements.
  • Ed: We should deliberately start that conversation. That was the main reason why we did not put this one up for adoption.
Jan continues:
  • At a higher level, a topology mode., and added IGP, and TE DB, which exteds the ISIS and OSPF topologies. There's multple levels of refinement, and other topos of L2, services.
  • The basic structure is simpleL topology, nodes, links. Links reference nodes. And either nodes or links as termination points can have underlined elements to create topology layers.
Question:
  • Ed: Do you do layers with multiple termination points or increase the links.
  • Jan: Both. Link in L3 can have multiple L2 links.
  • Ed: so for an underlying link. Direct x-connect running L3 and ethernet. Would I associate the logical termination point with L2 and L3?
  • Jan: No, only the L2
  • Ed: So, there's another termination point for L3?
  • Jan: Yes.
Jan Continues:
  • Links extended with L3 IGP attributes. This allows us to put integrity rules and assure links/nodes/TP are a matching type.
  • This slide shows the further extension of the IGP unicast topo with ISIS and OSPF specific attributes.
  • And that's the end of my preso.
Question:
  • Someone: I've seen a doc with a YANG specification, is the same?
  • Jan: Yes, we have that other corresponding doc that we will present in NETMOD.
  • Someone: Why?
  • Jan: Charter of I2RS is info model, and NETMOD is data model. An info model can be modeled in multiple data model languages, including YANG.
  • Alia: WG Chair on, make sure there is coordination, we need a simple data model.
  • Acee: It would be good to have examples in an appendix and map to RBNF.
  • Someone else: in slide 4, need consistency with 2 termination points.
  • Jan: that's a good point. THis might be an artifact of an early version.
  • Ed: I agree
  • Someone else: this reminds me of someone else I've seen in terms on what the solid diamonds mean and so on.
  • Jan: Yes. that's deliberate.
  • Someone else: yes
  • Ed: You are doing two things: replicating nodes, and replicating termination points. Are you maintaining protocol adjacencies for all of these?
  • Jan: The node can be an abstract node. Can be mapped to an abstract node, then mapped to a physical node.
  • Ed: In slide 5, how are you maintaining adjacencies? And then ext slide, isis links.
  • Jan: It should have the same association but we run out of space.
  • Ed: One of the previous comments made an excellent point, which I also made.
  • Nitin: To respond to Ed's mention earlier. This is a data model that can be used to export topology from the network device, or not bound by an I2RS client. Have a model that applies both from network device and from controller, so as to not duplicate.
  • Jan: If a network element is running a routing protocol is could export all topology.
  • George: There's a draft in ISIS this afternoon, in which I've found useful pointing two unidirectional links to each other and get the whole relationship without confusion.
  • Jan: got it. Thank you.
  • Someone from Ericcson: Why all links are point-to-point?
  • Jan: L3 bias that we have. Links as pseudonodes.
  • Alia: chair hat off. Start is what's in the IGP. It would make made the model useful to amplify the prefixes and termination points as customer terminations, and inactive links. SOmeone that is good enough. This model describes things that what we have is almost good enough.
  • Alia: Another: A link to a link in different layers talk to a path so I am not sure.
  • Jan: Yes, we might need path. But on your other question, we thought about inactive topologies, etc., but decided to focus this draft on IGP topology. We decided to chew off a chunk of work that would absolutely do. If other people contribute models would be great.
  • Ed: Can you start that discussion on the list?
  • Jan: Yes.
  • Ed: Thank you.

draft-bitar-i2rs-service-chaining-00
(N. Bitar, 10')
  • Nabil:
  • This also started in the interim.
  • Let me be clear as to the scope and what this addresses.
  • Objective is to describe service chaining use cases and what can be controlled by I2RS. We want to do service chaining for multi-tenant (tenant being the same as customer in this context).
  • The first use case is representation/discovery of service topology to be used by higher-level orchestration system, and service path.
  • Here we are not liming services to be virtualized. Different ways of realizing services. In VM, router, etc., each of which can have a different way of identifying it. And then it's about the capabilities of the service. And then includes access point, not only the core. In a VPN you want to know which router and which access port is an AC. That could be an extension along the lines of the work Jan just presented.
  • The next use case is monitoring liveliness of a services, to detect node failure or select a different path. service node and hosted system (VM, router), CPU, memory, etc.
  • Then after talking about topology and monitoring, the question is how can we use that? on a given service path (realization of a service in the network). You could mirror, steer, policy route on a given tunnel, etc.
  • The other use case is to do BGP traffic steering.
  • What scalability we need? And also what security considerations are specific to service chaining.
  • We should also align terminology of controller-system to "client-agent". And avoid congestion-triggered DoS.
  • Next steps? We want comments and input. We also need to update the draft with comments from a private exchange with Alia.
  • That's all I have. Any questions?
Questions:
  • Ed: Let's take those to the list. If you get that started it would be great.
  • Alia: The thing that it is nice about this draft is that it talks about feedback that gives guidelines on scalability. Who's read it?
  • Alia: reasonable handful but not too many, I encourage you to read.

draft-keyupate-i2rs-bgp-usecases-00
(all, 15')
  • Ed: There's been some discussion on the list about adopting this document. Although Keyur does not have a presentation, I want to talk about this.
  • Ed: How many people has read the draft?
  • Ed: Not too many.
  • Keyur: Currently the authors have received two pieces of feedback, the first one to merge with draft-white's use cases, and the second to remove the configuration pieces and we are OK.
  • Ed: Yes, that's a short conversation with the number of people who read it.
  • Ed: Please read the draft and send your comments.
  • We have one last preso in the remaining 9 minutes.



draft-camwinget-i2rs-pubsub-sec-00
(N.Cam-Winget / D. McGrew)
  • Nancy: My collegues, David McGrew and Ken we submitted a draft, admitedly close to the deadline so I do not know how many people have read it.
  • The need ot async transport for notification.
  • We want to mane some observations:
  • 1. The need tof the publish-subscribe model to address the requirements. We talk about subscribers looking at it from a topic or contextual based. Organizations might be topic, and operations might be contextual.
  • 2. How the pub-sub fits into the I2RS group. THese requirements highlight the model: async router-to-app notification, many to many relationships, topology. RIB updates, as well as policy management (within your I2RS). But also the ones that drive authorization. Also the need to discover the type of informations, and from security to do that dynamic discovery.
  • From that, I did a very quick overview for the need of pub-sub. Then there's the need to design patterns. This covers the whole breath of security requirements. We need to make sure that there's pee-to-peer, or app-to-client authentication. But beyond that, the communication be autenticated. Also auth against replay attacks, and the ordering issues.
  • For providing those security services we should look at transport models: single vs. multiple message brokers.
  • The draft is only about observations on the design patterns, that highlight requirements.
Questions:
  • Greg Mersky: on pub-sub, who should receive early published state
  • Nancy: I am not sure I understand your questions.
  • Greg: There is the published and subscriber.
  • Nancy: That's why I highlight the difference between topic based vs. context based, and perhaps after the discussions today we might need to have a hybrid. If there is a state change the subscriber needs that update.
  • Greg: The state already exists, it's been published.
  • Ed: He is talking about synchronization of the pb-sub model.
  • Nancy: But I am talking about how to give notification updates.
  • Greg: Ed mention to reuse existing mechanisms. Have you seen routing protocols? They quite well fit pub-sub good enough.
  • Nancy: I am saying architecturally should look at pub-sub, not which 
  • Joel: I am not sure I gollow why you call it pub-sub. From an architectural perspective, it does not matter if it is one transaction or multiple. Then, after that, we get into protocols. I can pretend NETCONF or ForCES is pub-sub. If receiving the notiication is pub-sub it's OK. Otherwise I do not understand the question.
  • Alia: We need protocol requirements drafts, and in that we need to be thinking bout this. I would like to see conversation before next IETF.
  • I would like to see the blue sheets.
  • See you on the list, thank you.

Meeting adjourned, 2:58pm, Berlin time
EOF

--Apple-Mail=_77FC1D54-7671-417A-80F7-263D6129AD1B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_77FC1D54-7671-417A-80F7-263D6129AD1B-- --Apple-Mail=_6CFA0987-AF0E-45A4-BB5C-92B81F640F6E 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 - http://gpgtools.org iEYEARECAAYFAlH6W/AACgkQtfDPGTp3USyROQCdFNgKHDeTNGGuP2SWkX7/Hu6L tjoAniHTkS9hJjbrRBresnrV+/jshPCJ =Z9Qn -----END PGP SIGNATURE----- --Apple-Mail=_6CFA0987-AF0E-45A4-BB5C-92B81F640F6E-- From lberger@labn.net Thu Aug 1 06:46:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC8821E819F for ; Thu, 1 Aug 2013 06:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpU4avtfdRay for ; Thu, 1 Aug 2013 06:46:21 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id AB7A521E81BE for ; Thu, 1 Aug 2013 06:45:25 -0700 (PDT) Received: (qmail 6559 invoked by uid 0); 1 Aug 2013 13:44:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 1 Aug 2013 13:44:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=YnTv4O7IhaGIoERhqndbAp9aaUxf9wIkDqVRP5xqEyA=; b=TAQnNssi4ou8K8AHuSLJTwLbXb4aiFw00BjYzv+fJuWlv9jBJNlDz1bAdh2NCBwmG4vhVTmm1y/tDkQQ1qu4om8Sm0oFwJiKzwvpPNxcdrhjSJj8/5Yj4XqOZKU7B2SW; Received: from box313.bluehost.com ([69.89.31.113]:53565 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4tBX-0004XW-MU; Thu, 01 Aug 2013 07:44:55 -0600 Message-ID: <51FA6656.80003@labn.net> Date: Thu, 01 Aug 2013 09:44:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> <51FA52AF.6090104@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:46:27 -0000 On 08/01/2013 08:25 AM, Alia Atlas wrote: > Lou, > > You think the secondary identity that we put in is insufficient? > > Alia > I wasn't actually suggesting any technical changes (yet), but rather that the document explicitly cover the topic(s), assumptions, and limitations. Preferably for both topics now in this thread. I'm happy to discuss/propose specific text if needed/helpful. Thanks, Lou > > On Thu, Aug 1, 2013 at 8:21 AM, Lou Berger > wrote: > > On 08/01/2013 08:09 AM, Joel M. Halpern wrote: > > The key point is that client coordination (for standby or any other > > purpose) is the clients problem. Sharing the identity is one way > to do > > this. > > > > I suppose for permission to delete state we might want to have some > > notion of shared authorization with distinct authentication, but I > would > > prefer not to go there. > > Well now you're getting to my AAA comment from the last meeting, i.e., > is it okay to lose today's ability for user level traceability on device > state changes *on the device*. The current document of course says it > is. I'm sure there are some out there who will see this as a pain point, > but it also may be acceptable to tell such users to not use I2RS. > > Lou > > > > > Yours, > > Joel > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > >> Not to answer for Joel, but my view is that a client is identified by > >> its identity. A different application can take over from the > first by > >> using the same identity. Loss of a transport session does not cause > >> existing client state to be removed (in the architecture) - so > there is > >> the ability for a new application to take over. > >> > >> Does that help? > >> > >> Alia > >> > >> > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > >> >> wrote: > >> > >> Hi Joel, > >> In today's session, I asked about provisions in the > >> architecture > >> (document) for Client Redundancy/Fault Tolerance. I believe you > >> stated > >> that "it's not needed" and that you'd elaborate on the list. > >> > >> I believe you also answered a latter question by stating that > clients > >> are free to coordinate between themselves to provide redundancy. > >> Is this > >> the simple answer? If not, can you elaborate? > >> > >> Thanks, > >> Lou > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From adrian@olddog.co.uk Thu Aug 1 07:15:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A195221E8209 for ; Thu, 1 Aug 2013 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMq9ZTQFFaOk for ; Thu, 1 Aug 2013 07:15:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E1F9A21E81F6 for ; Thu, 1 Aug 2013 07:15:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r71EF2rH014667; Thu, 1 Aug 2013 15:15:03 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r71EF2Dh014656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 15:15:02 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" , References: <95067C434CE250468B77282634C96ED322D6E09C@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322D6E09C@xmb-aln-x02.cisco.com> Date: Thu, 1 Aug 2013 15:15:00 +0100 Message-ID: <079001ce8ec1$82e7e170$88b7a450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLMIBOBdt8P9QK67QKcLf2rNtNBvJeFQq5w Content-Language: en-gb Subject: Re: [i2rs] Minutes for IETF87, I2RS WG meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:15:14 -0000 Many thanks, Carlos. If the chairs can arrange for these *draft* minutes to be posted ASAP? Cheers, Adrian > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Carlos > Pignataro (cpignata) > Sent: 01 August 2013 14:01 > To: i2rs@ietf.org > Subject: [i2rs] Minutes for IETF87, I2RS WG meeting > > Hi, I2RS, > > Please find attached the minutes from today's I2RS meeting. Comments and > corrections are most welcome!! > > Thanks, > > -- Carlos. From jclarke@cisco.com Thu Aug 1 08:06:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8C21E80FF for ; Thu, 1 Aug 2013 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT5SNjuSm+M8 for ; Thu, 1 Aug 2013 08:06:32 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 897D021E8147 for ; Thu, 1 Aug 2013 08:06:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71F6J95008846; Thu, 1 Aug 2013 17:06:19 +0200 (CEST) Received: from dhcp-10-61-97-173.cisco.com (dhcp-10-61-97-173.cisco.com [10.61.97.173]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71F5JEW016139; Thu, 1 Aug 2013 17:05:29 +0200 (CEST) Message-ID: <51FA792E.3040908@cisco.com> Date: Thu, 01 Aug 2013 11:05:18 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Joel.Halpern@ericsson.com, Lou Berger Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:06:37 -0000 X-List-Received-Date: Thu, 01 Aug 2013 15:06:37 -0000 On 8/1/13 7:51 AM, Alia Atlas wrote: > Not to answer for Joel, but my view is that a client is identified by > its identity. A different application can take over from the first by > using the same identity. Loss of a transport session does not cause > existing client state to be removed (in the architecture) - so there is > the ability for a new application to take over. > > Does that help? That worries me without more discussion about authentication. Additionally, from a troubleshooting standpoint, if I can assume the same identity as another client, how can I be absolutely sure which client does what to the agent? I feel there needs to be more to ensure accountability of what client does what, certainly from a security perspective, but also from a troubleshooting perspective. Joe > > Alia > > > On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > wrote: > > Hi Joel, > In today's session, I asked about provisions in the architecture > (document) for Client Redundancy/Fault Tolerance. I believe you stated > that "it's not needed" and that you'd elaborate on the list. > > I believe you also answered a latter question by stating that clients > are free to coordinate between themselves to provide redundancy. Is this > the simple answer? If not, can you elaborate? > > Thanks, > Lou > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Thu Aug 1 08:12:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E25A11E8105 for ; Thu, 1 Aug 2013 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1bkNcNf2bF4 for ; Thu, 1 Aug 2013 08:12:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A50EF21E8124 for ; Thu, 1 Aug 2013 08:11:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71FBs3F009409; Thu, 1 Aug 2013 17:11:54 +0200 (CEST) Received: from dhcp-10-61-97-173.cisco.com (dhcp-10-61-97-173.cisco.com [10.61.97.173]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71FAw91002053; Thu, 1 Aug 2013 17:11:14 +0200 (CEST) Message-ID: <51FA7A80.3010001@cisco.com> Date: Thu, 01 Aug 2013 11:10:56 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Lou Berger References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> <51FA52AF.6090104@labn.net> In-Reply-To: <51FA52AF.6090104@labn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:12:05 -0000 On 8/1/13 8:21 AM, Lou Berger wrote: > On 08/01/2013 08:09 AM, Joel M. Halpern wrote: >> The key point is that client coordination (for standby or any other >> purpose) is the clients problem. Sharing the identity is one way to do >> this. >> >> I suppose for permission to delete state we might want to have some >> notion of shared authorization with distinct authentication, but I would >> prefer not to go there. > > Well now you're getting to my AAA comment from the last meeting, i.e., > is it okay to lose today's ability for user level traceability on device > state changes *on the device*. The current document of course says it > is. I'm sure there are some out there who will see this as a pain point, > but it also may be acceptable to tell such users to not use I2RS. It is a pain point, especially for troubleshooting and understanding what client did what when. Sure one can not use I2RS, but is that really acceptable to the WG as a stance when it comes to reputability and troubleshooting? Joe > > Lou > >> >> Yours, >> Joel >> >> On 8/1/13 7:51 AM, Alia Atlas wrote: >>> Not to answer for Joel, but my view is that a client is identified by >>> its identity. A different application can take over from the first by >>> using the same identity. Loss of a transport session does not cause >>> existing client state to be removed (in the architecture) - so there is >>> the ability for a new application to take over. >>> >>> Does that help? >>> >>> Alia >>> >>> >>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >> > wrote: >>> >>> Hi Joel, >>> In today's session, I asked about provisions in the >>> architecture >>> (document) for Client Redundancy/Fault Tolerance. I believe you >>> stated >>> that "it's not needed" and that you'd elaborate on the list. >>> >>> I believe you also answered a latter question by stating that clients >>> are free to coordinate between themselves to provide redundancy. >>> Is this >>> the simple answer? If not, can you elaborate? >>> >>> Thanks, >>> Lou >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From akatlas@gmail.com Thu Aug 1 08:16:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C46411E80DF for ; Thu, 1 Aug 2013 08:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuipclHMAk6w for ; Thu, 1 Aug 2013 08:16:18 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3705011E80F0 for ; Thu, 1 Aug 2013 08:16:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so4111876obc.31 for ; Thu, 01 Aug 2013 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ThZqNY77cxpg0+y9GpgAVGmBZW10xFVwo1tOKEMj+9E=; b=JFpsBXRgpUkIaqDcPv7uCx7/a4PA8RpbkZ8sR3dRVfzV2VLa/BEB+o311b3Zp5kIAC MAmrrAgOxSjzcO4t7wr4KBepapV47Rxvtn/87ndwJ0ziAlDHGll1US+mOXcsUycndERG udsGL0JwvvTvOw5kOsWrDXBslA7G+3j1cw7hzRqu6wcpIqSjyPvYG2YD6oqOO1slnkJb alKSJErlGz1OX2RQwY3AQAjrQ4RsqyiQv+aS+nKZCXynkPE7nGCme9L75KbU4MhJf4fV 7UI2zpwucpmkx2Zqc/2KB4c4fe6ZKYvSuLMXdOCZHz59HU+qmoojdFyFIP1f4aF7KW94 FKzA== MIME-Version: 1.0 X-Received: by 10.43.61.199 with SMTP id wx7mr205323icb.14.1375370176603; Thu, 01 Aug 2013 08:16:16 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Thu, 1 Aug 2013 08:16:16 -0700 (PDT) In-Reply-To: <51FA7A80.3010001@cisco.com> References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> <51FA52AF.6090104@labn.net> <51FA7A80.3010001@cisco.com> Date: Thu, 1 Aug 2013 11:16:16 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=bcaec51f96afcfacbd04e2e4522a Cc: "i2rs@ietf.org" , Lou Berger , "Joel M. Halpern" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:16:19 -0000 --bcaec51f96afcfacbd04e2e4522a Content-Type: text/plain; charset=ISO-8859-1 Joe, What we put in the architecture in response to the concern about user-level traceability is that there should be a secondary identity that a client can specify and should be stored for traceability. The authentication and authorization of that secondary identity is the client's problem. The authentication and authorization of the i2rs client is, of course, the i2rs agent's problem. Hopefully, we can reuse existing security techniques and infrastructure. I'd recommend working with Wes George and others who indicated interest and willingness to do work (Sam Hartman, Nancy Cam-Winget, etc) and on the list to help flesh out the requirements and details. Alia On Thu, Aug 1, 2013 at 11:10 AM, Joe Marcus Clarke wrote: > On 8/1/13 8:21 AM, Lou Berger wrote: > > On 08/01/2013 08:09 AM, Joel M. Halpern wrote: > >> The key point is that client coordination (for standby or any other > >> purpose) is the clients problem. Sharing the identity is one way to do > >> this. > >> > >> I suppose for permission to delete state we might want to have some > >> notion of shared authorization with distinct authentication, but I would > >> prefer not to go there. > > > > Well now you're getting to my AAA comment from the last meeting, i.e., > > is it okay to lose today's ability for user level traceability on device > > state changes *on the device*. The current document of course says it > > is. I'm sure there are some out there who will see this as a pain point, > > but it also may be acceptable to tell such users to not use I2RS. > > It is a pain point, especially for troubleshooting and understanding > what client did what when. Sure one can not use I2RS, but is that > really acceptable to the WG as a stance when it comes to reputability > and troubleshooting? > > Joe > > > > > Lou > > > >> > >> Yours, > >> Joel > >> > >> On 8/1/13 7:51 AM, Alia Atlas wrote: > >>> Not to answer for Joel, but my view is that a client is identified by > >>> its identity. A different application can take over from the first by > >>> using the same identity. Loss of a transport session does not cause > >>> existing client state to be removed (in the architecture) - so there is > >>> the ability for a new application to take over. > >>> > >>> Does that help? > >>> > >>> Alia > >>> > >>> > >>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >>> > wrote: > >>> > >>> Hi Joel, > >>> In today's session, I asked about provisions in the > >>> architecture > >>> (document) for Client Redundancy/Fault Tolerance. I believe you > >>> stated > >>> that "it's not needed" and that you'd elaborate on the list. > >>> > >>> I believe you also answered a latter question by stating that > clients > >>> are free to coordinate between themselves to provide redundancy. > >>> Is this > >>> the simple answer? If not, can you elaborate? > >>> > >>> Thanks, > >>> Lou > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>> > >> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --bcaec51f96afcfacbd04e2e4522a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,

What we put in the architecture in= response to the concern about user-level traceability is that there should= be a secondary identity that a client can specify and should be stored for= traceability. =A0The authentication and authorization of that secondary id= entity is the client's problem. =A0The authentication and authorization= of the i2rs client is, of course, the i2rs agent's problem.

Hopefully, we can reuse existing security techniques an= d infrastructure. =A0I'd recommend working with Wes George and others w= ho indicated interest and willingness to do work (Sam Hartman, Nancy Cam-Wi= nget, etc) and on the list to help flesh out the requirements and details.= =A0

Alia=A0


<= div class=3D"gmail_quote">On Thu, Aug 1, 2013 at 11:10 AM, Joe Marcus Clark= e <jclarke@cisco.com> wrote:
On 8/1/13 8:21 AM, Lou Ber= ger wrote:
> On 08/01/2013 08:09 AM, Joel M. Halpern wrote:
>> The key point is that client coordination (for standby or any othe= r
>> purpose) is the clients problem. =A0Sharing the identity is one wa= y to do
>> this.
>>
>> I suppose for permission to delete state we might want to have som= e
>> notion of shared authorization with distinct authentication, but I= would
>> prefer not to go there.
>
> Well now you're getting to my AAA comment from the last meeting, i= .e.,
> is it okay to lose today's ability for user level traceability on = device
> state changes *on the device*. The current document of course says it<= br> > is. I'm sure there are some out there who will see this as a pain = point,
> but it also may be acceptable to tell such users to not use I2RS.

It is a pain point, especially for troubleshooting and understanding<= br> what client did what when. =A0Sure one can not use I2RS, but is that
really acceptable to the WG as a stance when it comes to reputability
and troubleshooting?

Joe

>
> Lou
>
>>
>> Yours,
>> Joel
>>
>> On 8/1/13 7:51 AM, Alia Atlas wrote:
>>> Not to answer for Joel, but my view is that a client is identi= fied by
>>> its identity. =A0A different application can take over from th= e first by
>>> using the same identity. =A0Loss of a transport session does n= ot cause
>>> existing client state to be removed (in the architecture) - so= there is
>>> the ability for a new application to take over.
>>>
>>> Does that help?
>>>
>>> Alia
>>>
>>>
>>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
>>> <mailto:lberger@labn.ne= t>> wrote:
>>>
>>> =A0 =A0 Hi Joel,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0In today's session, I asked abo= ut provisions in the
>>> =A0 =A0 architecture
>>> =A0 =A0 (document) for Client Redundancy/Fault Tolerance. I be= lieve you
>>> stated
>>> =A0 =A0 that "it's not needed" and that you'= d elaborate on the list.
>>>
>>> =A0 =A0 I believe you also answered a latter question by stati= ng that clients
>>> =A0 =A0 are free to coordinate between themselves to provide r= edundancy.
>>> Is this
>>> =A0 =A0 the simple answer? =A0If not, can you elaborate?
>>>
>>> =A0 =A0 Thanks,
>>> =A0 =A0 Lou
>>> =A0 =A0 _______________________________________________
>>> =A0 =A0 i2rs mailing list
>>> =A0 =A0 i2rs@ietf.org <= ;mailto:i2rs@ietf.org>
>>> =A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--bcaec51f96afcfacbd04e2e4522a-- From jclarke@cisco.com Thu Aug 1 08:16:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9946111E8100 for ; Thu, 1 Aug 2013 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrTT9winh6Ki for ; Thu, 1 Aug 2013 08:16:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4321E8093 for ; Thu, 1 Aug 2013 08:16:27 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71FGOEg009858; Thu, 1 Aug 2013 17:16:24 +0200 (CEST) Received: from dhcp-10-61-97-173.cisco.com (dhcp-10-61-97-173.cisco.com [10.61.97.173]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71FFhf0014920; Thu, 1 Aug 2013 17:15:58 +0200 (CEST) Message-ID: <51FA7B9E.8000102@cisco.com> Date: Thu, 01 Aug 2013 11:15:42 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joel Halpern References: <51FA492D.3070402@labn.net> , <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , "lberger@labn.net" , "akatlas@gmail.com" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:16:31 -0000 On 8/1/13 11:11 AM, Joel Halpern wrote: > The client is the entity that is authenticated and authorized. If the > client is acting on behalf of someone else, we assume that the > authentication and authorization of that party is the task of the client > and outside our scope. However we include that identity so that actions > can be easily correlated with originators. Right. I get that. I had thought we were talking about two clients that might be redundant to each other where Client 1 dies and Client 2 assumes its identity to make changes possibly driven by northbound actors. Even in this case, I feel Client 2 still needs to maintain a unique identification to the I2RS agent so that one can trace the operation back to the specific I2RS client (in addition to the northbound actor). Joe > > Yours, > Joel > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > -----Original Message----- > *From:* Joe Marcus Clarke [jclarke@cisco.com] > *Received:* Thursday, 01 Aug 2013, 17:07 > *To:* Alia Atlas [akatlas@gmail.com] > *CC:* Lou Berger [lberger@labn.net]; i2rs@ietf.org [i2rs@ietf.org]; Joel > Halpern [joel.halpern@ericsson.com] > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance > in draft-atlas-i2rs-architecture-01 > > On 8/1/13 7:51 AM, Alia Atlas wrote: >> Not to answer for Joel, but my view is that a client is identified by >> its identity. A different application can take over from the first by >> using the same identity. Loss of a transport session does not cause >> existing client state to be removed (in the architecture) - so there is >> the ability for a new application to take over. >> >> Does that help? > > That worries me without more discussion about authentication. > Additionally, from a troubleshooting standpoint, if I can assume the > same identity as another client, how can I be absolutely sure which > client does what to the agent? I feel there needs to be more to ensure > accountability of what client does what, certainly from a security > perspective, but also from a troubleshooting perspective. > > Joe > >> >> Alia >> >> >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > > wrote: >> >> Hi Joel, >> In today's session, I asked about provisions in the architecture >> (document) for Client Redundancy/Fault Tolerance. I believe you stated >> that "it's not needed" and that you'd elaborate on the list. >> >> I believe you also answered a latter question by stating that clients >> are free to coordinate between themselves to provide redundancy. Is this >> the simple answer? If not, can you elaborate? >> >> Thanks, >> Lou >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From akatlas@gmail.com Thu Aug 1 08:19:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C722F21E8153 for ; Thu, 1 Aug 2013 08:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toDijiK89WAK for ; Thu, 1 Aug 2013 08:19:12 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F075F21E8150 for ; Thu, 1 Aug 2013 08:19:00 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l20so4609943oag.31 for ; Thu, 01 Aug 2013 08:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ItgCG9ZZ5S2u4GnFKFuG7Qlhz2bgCv8KBf3ELc0yCAg=; b=RJP9MKsK5dd3QYHzwqmlY9GBlisjIRwnow6HM7sRDIpT1E97BHP34me79wqPqMnph7 dIRypRsKCgeO42xmtc5Pj59VV7ihug37hrMCrrAScCTTTe0D3gNbOUcg2paW/DaWCE1d n1CpYteYDXZ9BJ8x3eAPwy5BvegEqM1zC2RZEuKDRrJGN6NZE7r1Ymlr47fsIcMD+9Rr t3Ir/3uZ1YaixQgMSq3DRvjBjjtpKSV7y7e3AsslUo9LJPWsAB0b+Fmr71FAjDJAERAf epkVZTXg6PmwJJMtmayP+zwH4ks6f3Fudlj1dOg7IZ+uZey+qqlEeGPNLZ99iGns+ZQi w2bw== MIME-Version: 1.0 X-Received: by 10.50.153.49 with SMTP id vd17mr1306362igb.22.1375370340468; Thu, 01 Aug 2013 08:19:00 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Thu, 1 Aug 2013 08:19:00 -0700 (PDT) In-Reply-To: <51FA7B9E.8000102@cisco.com> References: <51FA492D.3070402@labn.net> <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> Date: Thu, 1 Aug 2013 11:19:00 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=089e014954be941b6504e2e45cd7 Cc: "i2rs@ietf.org" , Joel Halpern , "lberger@labn.net" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:19:13 -0000 --089e014954be941b6504e2e45cd7 Content-Type: text/plain; charset=ISO-8859-1 Joe, Ok - so what I hear from you is needed is the client role client identity sub-client identity? Where the permissions and ownership of state is tied to the client role? Does that match to what you are saying? I believe we're assuming that the ownership of state is tied to the client identity - and you are suggesting that if so, we need a client sub-identity or such? Alia On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke wrote: > On 8/1/13 11:11 AM, Joel Halpern wrote: > > The client is the entity that is authenticated and authorized. If the > > client is acting on behalf of someone else, we assume that the > > authentication and authorization of that party is the task of the client > > and outside our scope. However we include that identity so that actions > > can be easily correlated with originators. > > Right. I get that. I had thought we were talking about two clients > that might be redundant to each other where Client 1 dies and Client 2 > assumes its identity to make changes possibly driven by northbound > actors. Even in this case, I feel Client 2 still needs to maintain a > unique identification to the I2RS agent so that one can trace the > operation back to the specific I2RS client (in addition to the > northbound actor). > > Joe > > > > > Yours, > > Joel > > > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > > > -----Original Message----- > > *From:* Joe Marcus Clarke [jclarke@cisco.com] > > *Received:* Thursday, 01 Aug 2013, 17:07 > > *To:* Alia Atlas [akatlas@gmail.com] > > *CC:* Lou Berger [lberger@labn.net]; i2rs@ietf.org [i2rs@ietf.org]; Joel > > Halpern [joel.halpern@ericsson.com] > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance > > in draft-atlas-i2rs-architecture-01 > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > >> Not to answer for Joel, but my view is that a client is identified by > >> its identity. A different application can take over from the first by > >> using the same identity. Loss of a transport session does not cause > >> existing client state to be removed (in the architecture) - so there is > >> the ability for a new application to take over. > >> > >> Does that help? > > > > That worries me without more discussion about authentication. > > Additionally, from a troubleshooting standpoint, if I can assume the > > same identity as another client, how can I be absolutely sure which > > client does what to the agent? I feel there needs to be more to ensure > > accountability of what client does what, certainly from a security > > perspective, but also from a troubleshooting perspective. > > > > Joe > > > >> > >> Alia > >> > >> > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >> > wrote: > >> > >> Hi Joel, > >> In today's session, I asked about provisions in the > architecture > >> (document) for Client Redundancy/Fault Tolerance. I believe you > stated > >> that "it's not needed" and that you'd elaborate on the list. > >> > >> I believe you also answered a latter question by stating that > clients > >> are free to coordinate between themselves to provide redundancy. Is > this > >> the simple answer? If not, can you elaborate? > >> > >> Thanks, > >> Lou > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --089e014954be941b6504e2e45cd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,

Ok - so what I hear from you= is needed is the
=A0 =A0client role
=A0 =A0client identity
=A0 =A0sub-client identity?

Where the per= missions and ownership of state is tied to the client role? =A0Does that ma= tch to what you are saying? =A0I believe we're assuming that the owners= hip of state is tied to the client identity - and you are suggesting that i= f so, we need a client sub-identity or such?

Alia


On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke <= span dir=3D"ltr"><jclarke@cisco.com> wrote:
On 8/1/13 11:11 AM, Joel H= alpern wrote:
> The client is the entity that is authenticated and authorized. If the<= br> > client is acting on behalf of someone else, we assume that the
> authentication and authorization of that party is the task of the clie= nt
> and outside our scope. However we include that identity so that action= s
> can be easily correlated with originators.

Right. =A0I get that. =A0I had thought we were talking about two clie= nts
that might be redundant to each other where Client 1 dies and Client 2
assumes its identity to make changes possibly driven by northbound
actors. =A0Even in this case, I feel Client 2 still needs to maintain a
unique identification to the I2RS agent so that one can trace the
operation back to the specific I2RS client (in addition to the
northbound actor).

Joe

>
> Yours,
> Joel
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Joe Marcus Clarke [= jclarke@cisco.com]
> *Received:* Thursday, 01 Aug 2013, 17:07
> *To:* Alia Atlas [akatlas@gmail.c= om]
> *CC:* Lou Berger [lberger@labn.net= ]; i2rs@ietf.org [i2rs@ietf.org]; Joel
> Halpern [joel.halpern@eri= csson.com]
> *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance=
> in draft-atlas-i2rs-architectu= re-01
>
> On 8/1/13 7:51 AM, Alia Atlas wrote:
>> Not to answer for Joel, but my view is that a client is identified= by
>> its identity. =A0A different application can take over from the fi= rst by
>> using the same identity. =A0Loss of a transport session does not c= ause
>> existing client state to be removed (in the architecture) - so the= re is
>> the ability for a new application to take over.
>>
>> Does that help?
>
> That worries me without more discussion about authentication.
> Additionally, from a troubleshooting standpoint, if I can assume the > same identity as another client, how can I be absolutely sure which > client does what to the agent? =A0I feel there needs to be more to ens= ure
> accountability of what client does what, certainly from a security
> perspective, but also from a troubleshooting perspective.
>
> Joe
>
>>
>> Alia
>>
>>
>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
>> <mailto:lberger@labn.net>> wrote:
>>
>> =A0 =A0 Hi Joel,
>> =A0 =A0 =A0 =A0 =A0 =A0 In today's session, I asked about prov= isions in the architecture
>> =A0 =A0 (document) for Client Redundancy/Fault Tolerance. I believ= e you stated
>> =A0 =A0 that "it's not needed" and that you'd el= aborate on the list.
>>
>> =A0 =A0 I believe you also answered a latter question by stating t= hat clients
>> =A0 =A0 are free to coordinate between themselves to provide redun= dancy. Is this
>> =A0 =A0 the simple answer? =A0If not, can you elaborate?
>>
>> =A0 =A0 Thanks,
>> =A0 =A0 Lou
>> =A0 =A0 _______________________________________________
>> =A0 =A0 i2rs mailing list
>> =A0 =A0 i2rs@ietf.org <mai= lto:i2rs@ietf.org>
>> =A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
>
> --
> Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|<= br> > SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:..
> Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
> Email: jclarke@cisco.com
>
> ----------------------------------------------------------------------= ------


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--089e014954be941b6504e2e45cd7-- From lberger@labn.net Thu Aug 1 08:40:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3A21F9DC9 for ; Thu, 1 Aug 2013 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.937 X-Spam-Level: X-Spam-Status: No, score=-101.937 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbcrAY0Z8Kt0 for ; Thu, 1 Aug 2013 08:40:11 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 1C15521E81FD for ; Thu, 1 Aug 2013 08:40:01 -0700 (PDT) Received: (qmail 31767 invoked by uid 0); 1 Aug 2013 15:39:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 1 Aug 2013 15:39:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=l0mLoYberRJxaVaYlq+ct5SO8hyq8ulZHTQirqHUfI8=; b=vaXOh4d7+DpTaoKlgqENm/vSwGUGffEeQPIBw/aVrpdzfELOFiv48gVhbfZnpen6bHX9xwXqMGtmMV9S5nppPhSxfJtz8tWSNFiTvlJUIj/AfVx7l8xyzrg5DclnN3iW; Received: from box313.bluehost.com ([69.89.31.113]:47479 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4uyN-00030X-8U; Thu, 01 Aug 2013 09:39:27 -0600 Message-ID: <51FA812E.1030900@labn.net> Date: Thu, 01 Aug 2013 11:39:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Joel M. Halpern" , "i2rs@ietf.org" References: <51FA492D.3070402@labn.net> <51FA4FF4.2070700@joelhalpern.com> <51FA52AF.6090104@labn.net> <51FA6656.80003@labn.net> <51FA6B1E.2060900@joelhalpern.com> In-Reply-To: <51FA6B1E.2060900@joelhalpern.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 (resend) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:40:16 -0000 [resend: dropped WG on my original reply] On 08/01/2013 10:05 AM, Joel M. Halpern wrote: > > PS: I do think for the second aspect you raised (traceability) the > secondary identity is precisely what is needed. And it is basically > there for that purpose. It could be used that way, but I think the application goes beyond "troubleshooting"... Lou From lberger@labn.net Thu Aug 1 08:44:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DD321E81F5 for ; Thu, 1 Aug 2013 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.98 X-Spam-Level: X-Spam-Status: No, score=-100.98 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT-Qj5EMwLlO for ; Thu, 1 Aug 2013 08:44:36 -0700 (PDT) Received: from oproxy5.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0AA4521F9D9C for ; Thu, 1 Aug 2013 08:44:35 -0700 (PDT) Received: (qmail 13920 invoked by uid 0); 1 Aug 2013 15:44:02 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.bluehost.com with SMTP; 1 Aug 2013 15:44:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=I/FmSceP0OVhdud5WmEo+QZk/WzEnsje/f22XY4jVUo=; b=OyxcAKZvD4W0p3LtXZMRE07Q8ojXy/xHeUKoKbYlLuEgnQ8mWG7xOvmstSjdP1YiBvIRemeAKuz27EIFQOl4NdJn+RCserETX1CNwQWcplt34/eqlc/trWDWlOmqoPxP; Received: from box313.bluehost.com ([69.89.31.113]:48268 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4v2o-0004yC-I5; Thu, 01 Aug 2013 09:44:02 -0600 Message-ID: <51FA8241.4040103@labn.net> Date: Thu, 01 Aug 2013 11:44:01 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Marcus Clarke References: <51FA492D.3070402@labn.net> , <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> In-Reply-To: <51FA7B9E.8000102@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" , Joel Halpern , "akatlas@gmail.com" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:44:52 -0000 > Even in this case, I feel Client 2 still needs to maintain a unique identification to the I2RS agent so that one can trace the operation back to the specific I2RS client (in addition to the northbound actor). > I completely agree. Even if there's a simplification to have a single *active* state writer, there should be a provision to allow the active writer to shift. Lou On 08/01/2013 11:15 AM, Joe Marcus Clarke wrote: > On 8/1/13 11:11 AM, Joel Halpern wrote: >> The client is the entity that is authenticated and authorized. If the >> client is acting on behalf of someone else, we assume that the >> authentication and authorization of that party is the task of the client >> and outside our scope. However we include that identity so that actions >> can be easily correlated with originators. > > Right. I get that. I had thought we were talking about two clients > that might be redundant to each other where Client 1 dies and Client 2 > assumes its identity to make changes possibly driven by northbound > actors. Even in this case, I feel Client 2 still needs to maintain a > unique identification to the I2RS agent so that one can trace the > operation back to the specific I2RS client (in addition to the > northbound actor). > > Joe > >> >> Yours, >> Joel >> >> Sent from my Android phone using TouchDown (www.nitrodesk.com) >> >> -----Original Message----- >> *From:* Joe Marcus Clarke [jclarke@cisco.com] >> *Received:* Thursday, 01 Aug 2013, 17:07 >> *To:* Alia Atlas [akatlas@gmail.com] >> *CC:* Lou Berger [lberger@labn.net]; i2rs@ietf.org [i2rs@ietf.org]; Joel >> Halpern [joel.halpern@ericsson.com] >> *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance >> in draft-atlas-i2rs-architecture-01 >> >> On 8/1/13 7:51 AM, Alia Atlas wrote: >>> Not to answer for Joel, but my view is that a client is identified by >>> its identity. A different application can take over from the first by >>> using the same identity. Loss of a transport session does not cause >>> existing client state to be removed (in the architecture) - so there is >>> the ability for a new application to take over. >>> >>> Does that help? >> >> That worries me without more discussion about authentication. >> Additionally, from a troubleshooting standpoint, if I can assume the >> same identity as another client, how can I be absolutely sure which >> client does what to the agent? I feel there needs to be more to ensure >> accountability of what client does what, certainly from a security >> perspective, but also from a troubleshooting perspective. >> >> Joe >> >>> >>> Alia >>> >>> >>> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >> > wrote: >>> >>> Hi Joel, >>> In today's session, I asked about provisions in the architecture >>> (document) for Client Redundancy/Fault Tolerance. I believe you stated >>> that "it's not needed" and that you'd elaborate on the list. >>> >>> I believe you also answered a latter question by stating that clients >>> are free to coordinate between themselves to provide redundancy. Is this >>> the simple answer? If not, can you elaborate? >>> >>> Thanks, >>> Lou >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- > > From jclarke@cisco.com Thu Aug 1 17:30:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82511E8405 for ; Thu, 1 Aug 2013 17:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-SDdpg0Qvat for ; Thu, 1 Aug 2013 17:29:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC121E864A for ; Thu, 1 Aug 2013 16:38:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71NcQXO029138; Fri, 2 Aug 2013 01:38:26 +0200 (CEST) Received: from prosciutto.local (dhcp-10-61-96-187.cisco.com [10.61.96.187]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71NbZF0007754; Fri, 2 Aug 2013 01:37:46 +0200 (CEST) Message-ID: <51FAEF39.9020102@cisco.com> Date: Thu, 01 Aug 2013 19:28:57 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Joel Halpern , "lberger@labn.net" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 00:30:03 -0000 On 8/1/13 11:19 AM, Alia Atlas wrote: > Joe, > > Ok - so what I hear from you is needed is the > client role > client identity > sub-client identity? > > Where the permissions and ownership of state is tied to the client role? > Does that match to what you are saying? I believe we're assuming that > the ownership of state is tied to the client identity - and you are > suggesting that if so, we need a client sub-identity or such? Yes, I think that is in line with what I'm suggesting. If we can allow Client A to assume the identity of Client B using the same credentials, I would want some way to know that this is indeed Client B now acting on behalf of either itself or some northbound controller. Joe > > Alia > > > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke > wrote: > > On 8/1/13 11:11 AM, Joel Halpern wrote: > > The client is the entity that is authenticated and authorized. If the > > client is acting on behalf of someone else, we assume that the > > authentication and authorization of that party is the task of the > client > > and outside our scope. However we include that identity so that > actions > > can be easily correlated with originators. > > Right. I get that. I had thought we were talking about two clients > that might be redundant to each other where Client 1 dies and Client 2 > assumes its identity to make changes possibly driven by northbound > actors. Even in this case, I feel Client 2 still needs to maintain a > unique identification to the I2RS agent so that one can trace the > operation back to the specific I2RS client (in addition to the > northbound actor). > > Joe > > > > > Yours, > > Joel > > > > Sent from my Android phone using TouchDown (www.nitrodesk.com > ) > > > > -----Original Message----- > > *From:* Joe Marcus Clarke [jclarke@cisco.com > ] > > *Received:* Thursday, 01 Aug 2013, 17:07 > > *To:* Alia Atlas [akatlas@gmail.com ] > > *CC:* Lou Berger [lberger@labn.net ]; > i2rs@ietf.org [i2rs@ietf.org > ]; Joel > > Halpern [joel.halpern@ericsson.com ] > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance > > in draft-atlas-i2rs-architecture-01 > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > >> Not to answer for Joel, but my view is that a client is identified by > >> its identity. A different application can take over from the > first by > >> using the same identity. Loss of a transport session does not cause > >> existing client state to be removed (in the architecture) - so > there is > >> the ability for a new application to take over. > >> > >> Does that help? > > > > That worries me without more discussion about authentication. > > Additionally, from a troubleshooting standpoint, if I can assume the > > same identity as another client, how can I be absolutely sure which > > client does what to the agent? I feel there needs to be more to > ensure > > accountability of what client does what, certainly from a security > > perspective, but also from a troubleshooting perspective. > > > > Joe > > > >> > >> Alia > >> > >> > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > >> >> wrote: > >> > >> Hi Joel, > >> In today's session, I asked about provisions in the > architecture > >> (document) for Client Redundancy/Fault Tolerance. I believe > you stated > >> that "it's not needed" and that you'd elaborate on the list. > >> > >> I believe you also answered a latter question by stating that > clients > >> are free to coordinate between themselves to provide > redundancy. Is this > >> the simple answer? If not, can you elaborate? > >> > >> Thanks, > >> Lou > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 > c i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- > > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From ietf@meetecho.com Thu Aug 1 18:46:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2421E8378 for ; Thu, 1 Aug 2013 18:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-8NGYa3bGVv for ; Thu, 1 Aug 2013 18:46:17 -0700 (PDT) Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7449D11E8202 for ; Thu, 1 Aug 2013 17:58:55 -0700 (PDT) Received: from dell-tcastaldi ([130.129.66.20]) by smtpcmd03.ad.aruba.it with bizsmtp id 7cyu1m00H0SDdTW01cyuYz; Fri, 02 Aug 2013 02:58:55 +0200 Date: Fri, 2 Aug 2013 02:58:52 +0200 (CEST) From: Meetecho Team To: i2rs@ietf.org Message-ID: <1759551929.3.1375405132890.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_887106029.1375405132888" Subject: [i2rs] I2RS session recording available X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 01:46:28 -0000 ------=_Part_2_887106029.1375405132888 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the I2RS WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#I2RS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_2_887106029.1375405132888-- From jclarke@cisco.com Thu Aug 1 19:25:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1421E8350 for ; Thu, 1 Aug 2013 19:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3wK7tAlUwOv for ; Thu, 1 Aug 2013 19:25:28 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 41A0F21E83FD for ; Thu, 1 Aug 2013 19:00:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7220TEq013408; Fri, 2 Aug 2013 04:00:33 +0200 (CEST) Received: from dhcp-10-61-96-187.cisco.com (dhcp-10-61-96-187.cisco.com [10.61.96.187]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r72201de000329; Fri, 2 Aug 2013 04:00:17 +0200 (CEST) Message-ID: <51FB129F.8080009@cisco.com> Date: Thu, 01 Aug 2013 21:59:59 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 02:25:38 -0000 On 7/15/13 3:31 PM, Nitin Bahadur wrote: > > A new version of the RIB info model draft has been posted. > > Notable changes include: > - Addition of multicast support > - Text clarifications as per received comments Thanks for the presentation today, Nitin. I have some comments on the draft in addition to what was already said (though there may be some duplicates). See JMC below: Section 4: Route programming in the RIB SHOULD result in a return code that contains the following attributes: JMC: Why would one not want to return a result code? I think this needs to be a MUST and there is evidence in a later section supporting this. Section 4: JMC: How is this result code encapsulated? I realize this is an information model, but I thought there would be some description of this in your RBNF in Section 6. Section 5: Asynchronous notifications are sent by the network device's RIB manager to an external entity when some event occurs on the network device. A RIB data-model MUST support sending asynchronous notifications. A brief list of suggested notifications is as below: o Route change notification, with return code as specified in Section 4 o Nexthop resolution status (resolved/unresolved) notification JMC: While a RIB data-model must support notifications, there are no notifications that must be supported? Are you suggesting that the two examples listed here would be mandatory? Section 6: ::= [] ::= JMC: I agree with Carlos (and I think you missed his point) IPV4_ADDRESS and IPV6_ADDRESS should be IPV4_PREFIX and IPV6_PREFIX as these are not addresses but route prefixes (the next-hop is an address) Section 8.1: JMC: Bulking (as you call it) then must also be supported by a RIB client to request data in bulk. Section 8.2: Bulking (grouping of multiple write operations in a single message) MUST be supported when an external entity wants to write to the RIB. The response from the network device MUST include a return-code for each write operation in the bulk message. JMC: Here, you say the return code per operation is a MUST, which implies that in Section 4, this should be a MUST as well. Section 8.3: There can be cases where a single network event results in multiple events and/or notifications from the network device to an external entity. On the other hand, due to timing of multiple things happening at the same time, a network device might have to send multiple events and/or notifications to an external entity. The network device originated event/notification message MUST support bulking of multiple events and notifications in a single message. JMC: Here is where I think we need to request something akin to pub-sub where the Client can do filtering based on specific events types and parameters within those events. While a bulk blob of events might be nice for the RIB, I would think a client would want to be tactical about the events (and, in fact, within Cisco we offer this kind of granular filtering). Section 9: All interactions between a RIB manager and an external entity MUST be authenticated. JMC: Should you also add authorized in addition to authenticated? This would imply that interactions between Clients and the RIB must have specific permission to red, write in general and in specific parts of the RIB and specific RIBs and routing tables. Joe > > Thanks > > Nitin > > On 7/15/13 12:29 PM, "internet-drafts@ietf.org" > wrote: > >> >> A new version of I-D, draft-nitinb-i2rs-rib-info-model-01.txt >> has been successfully submitted by Nitin Bahadur and posted to the >> IETF repository. >> >> Filename: draft-nitinb-i2rs-rib-info-model >> Revision: 01 >> Title: Routing Information Base Info Model >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 24 >> URL: >> http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-01.tx >> t >> Status: >> http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >> Htmlized: >> http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-nitinb-i2rs-rib-info-model-01 >> >> Abstract: >> Routing and routing functions in enterprise and carrier networks are >> typically performed by network devices (routers and switches) using a >> routing information base (RIB). Protocols and configuration push >> data into the RIB and the RIB manager install state into the >> hardware; for packet forwarding. This draft specifies an information >> model for the RIB to enable defining a standardized data model. Such >> a data model can be used to define an interface to the RIB from an >> entity that may even be external to the network device. This >> interface can be used to support new use-cases being defined by the >> IETF I2RS WG. >> >> >> >> >> >> The IETF Secretariat >> >> >> > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From diego.caviglia@ericsson.com Thu Aug 1 22:46:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7E11E823E for ; Thu, 1 Aug 2013 22:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFg+KaFx33Ws for ; Thu, 1 Aug 2013 22:45:59 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 382EF11E8167 for ; Thu, 1 Aug 2013 22:45:59 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-a2-51fb47955e3e Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5E.0A.11907.5974BF15; Fri, 2 Aug 2013 07:45:57 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.155]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Fri, 2 Aug 2013 07:45:45 +0200 From: Diego Caviglia To: Meetecho Team , "i2rs@ietf.org" Thread-Topic: [i2rs] I2RS session recording available Thread-Index: AQHOjyIiFP7PQW3suEm/LwLl6H8kRpmBaKrw Date: Fri, 2 Aug 2013 05:45:43 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C3DD7F9@ESESSMB103.ericsson.se> References: <1759551929.3.1375405132890.JavaMail.tcastaldi@dell-tcastaldi> In-Reply-To: <1759551929.3.1375405132890.JavaMail.tcastaldi@dell-tcastaldi> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvre5U99+BBi/vaVmsm/GBxeLJjVfM DkweS5b8ZPLoeHifPYApissmJTUnsyy1SN8ugSvjQcNu1oKdbBVzd69namDsZ+1i5OSQEDCR WLZmNzuELSZx4d56ti5GLg4hgaOMEtOn9kA5ixklLs/5DVbFJmAksatjJguILSLgJjFv0Vcm EFsYaNLk/rlsEHFTie9z3jFB2EYSPdcXgPWyCKhIbG+4xAxi8wr4SvxfuATsCiEBL4n/+/6A zeQU8JbY9P8QmM0oICsxYfciRhCbWUBc4taT+UwQlwpILNlznhnCFpV4+fgf1DdKEo1LnrBC 1OtJ3Jg6hQ3C1pZYtvA11F5BiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUjR3FqcVJuupHB JkZgPBzc8ttiB+PlvzaHGKU5WJTEebfonQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwHhX cUPPTk8xlTXnV9cb9x1jupsjIhKw4GOfhMke01+Xbk2XmPHH1VNr+9PrbT65F6cnSIQ3x3Oo fc053HzvHofRMqfja/3O9bapnnl8tn7X7twnE9ht6hzE/rFZ9SQw9ld+m7HF80chV8XWlwsr ozriFS86rZL6sMzu/APeCmkjEUZTe90DwkosxRmJhlrMRcWJAJ8yOJ1VAgAA Subject: Re: [i2rs] I2RS session recording available X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 05:46:04 -0000 Hi Guys Thanks a lot for this really appreciated. Diego > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Meetecho Team > Sent: venerd=EC 2 agosto 2013 02:59 > To: i2rs@ietf.org > Subject: [i2rs] I2RS session recording available >=20 > Dear all, >=20 > the full recording (synchronized video, audio, slides and jabber room) of= the > I2RS WG session at IETF 87 is available at the following URL: > http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#I2RS >=20 > For the chair(s): please feel free to put the link to the recording in th= e > minutes, if you think this might be useful. >=20 > Cheers, > the Meetecho Team >=20 >=20 > This email has been automatically generated by The Meetecho Conferencing > System From kwangkooglee@gmail.com Fri Aug 2 00:19:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078D911E827F for ; Fri, 2 Aug 2013 00:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxbsq9j+RPU4 for ; Fri, 2 Aug 2013 00:19:53 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BC75111E826B for ; Fri, 2 Aug 2013 00:19:53 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so156072qcz.33 for ; Fri, 02 Aug 2013 00:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OprUnkJ1gQgGUvaFys2JGlhCp1KAa2ow871S2xf0mkw=; b=conHeOtRlza93vQ5jhqghfuEGampikhrqLN7FTmY6R6sCe7+z8wrv5npAbANPv7o9x lheN2ryoP86/pvUQHuAzee+I4kEmKG02OYVmFSUnLLyWR282cq5gHfYgFbGBIzOBwk9J ZvkiAVysnBvEHFETHuwLWjOFw9xZ7ujufIo0msY/Nt0pmGlE5iIc25CRkhlBJD1qjq2e Vu2p4kn4I0qgg2IOemS4Nbgkf/96CIpxyuV6hwCuV3hckhp4LGj4DiJZkxzSyTYjew1s lJgQGpWYotqW03wQ24n4Hfj36ZNe+hPGQ7Q5FGhINNQ42UW4jNhBGIwT5DcddSvG3Wg3 YArQ== MIME-Version: 1.0 X-Received: by 10.229.22.67 with SMTP id m3mr1673229qcb.1.1375427993135; Fri, 02 Aug 2013 00:19:53 -0700 (PDT) Received: by 10.49.41.70 with HTTP; Fri, 2 Aug 2013 00:19:53 -0700 (PDT) In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C3DD7F9@ESESSMB103.ericsson.se> References: <1759551929.3.1375405132890.JavaMail.tcastaldi@dell-tcastaldi> <4E9BAD336C18BD49A429157A855607F11C3DD7F9@ESESSMB103.ericsson.se> Date: Fri, 2 Aug 2013 16:19:53 +0900 Message-ID: From: KwangKoog Lee To: Diego Caviglia Content-Type: multipart/alternative; boundary=20cf30684a4ff20fc704e2f1c80c Cc: "i2rs@ietf.org" , Meetecho Team Subject: Re: [i2rs] I2RS session recording available X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:19:55 -0000 --20cf30684a4ff20fc704e2f1c80c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for all. Sincerely, Kwang-koog Lee (KT) On Fri, Aug 2, 2013 at 2:45 PM, Diego Caviglia wrote: > Hi Guys > Thanks a lot for this really appreciated. > > Diego > > > -----Original Message----- > > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > > Meetecho Team > > Sent: venerd=EC 2 agosto 2013 02:59 > > To: i2rs@ietf.org > > Subject: [i2rs] I2RS session recording available > > > > Dear all, > > > > the full recording (synchronized video, audio, slides and jabber room) > of the > > I2RS WG session at IETF 87 is available at the following URL: > > http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#I2RS > > > > For the chair(s): please feel free to put the link to the recording in > the > > minutes, if you think this might be useful. > > > > Cheers, > > the Meetecho Team > > > > > > This email has been automatically generated by The Meetecho Conferencin= g > > System > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf30684a4ff20fc704e2f1c80c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for all.
=A0
Sincerely,=
Kwang-koog Lee (KT)

On Fri, Aug 2, 2013 at 2:45 PM, Diego Caviglia= <diego.caviglia@ericsson.com> wrote:
Hi Guys
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks a lot for this really appreciated.

Diego

> -----Original Message-----
> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of
> Meetecho Team
> Sent: venerd=EC 2 agosto 2013 02:59
> To: i2rs@ietf.org
> Subject: [i2rs] I2RS session recording available
>
> Dear all,
>
> the full recording (synchronized video, audio, slides and jabber room)= of the
> I2RS WG session at IETF 87 is available at the following URL:
> http://ietf87.conf.meetecho.com/index.php/Recorded= _Sessions#I2RS
>
> For the chair(s): please feel free to put the link to the recording in= the
> minutes, if you think this might be useful.
>
> Cheers,
> the Meetecho Team
>
>
> This email has been automatically generated by The Meetecho Conferenci= ng
> System

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--20cf30684a4ff20fc704e2f1c80c-- From akatlas@gmail.com Fri Aug 2 00:53:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEADA11E827F for ; Fri, 2 Aug 2013 00:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT3FX29XsowG for ; Fri, 2 Aug 2013 00:52:59 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8754111E8210 for ; Fri, 2 Aug 2013 00:52:59 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so729854oag.29 for ; Fri, 02 Aug 2013 00:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0S5zt1VIe3wOpDH22olL52WRqlWSdd8Cv3wYj8X3xAc=; b=HClgiApxdp4mp9ixIG8BFl1mhz5szrPC4QuUZxOkBNcFfpnHBJXWg6CHjp56yG7jg4 FTkDhI+k5bdUuzKxUKVBexn8RIYMS8cA6WuYuSo58aAiZC1KdNAW9NuMdRheoeqEXVLB X/5LZMe/xK234sxXCJPuwHfvEiTQAHxsfbG4WizCtmaldkcrrwwXIPZovMZ+tF8EnG4v ecM/GMnkZ2nI1AkxfWcF8KvAJ7/pEuRRlc6fGLVg1QNCbai+LzuSJjF2Xx+zEPGkDohD Cn7SZhFB3aBdiX98hFiRKhCDZ3uo2zgm+Q7qOfkgrYrzaVTQAW8OHG23pkH4Ns+n2r/F 4QOg== MIME-Version: 1.0 X-Received: by 10.42.223.134 with SMTP id ik6mr495800icb.4.1375429976042; Fri, 02 Aug 2013 00:52:56 -0700 (PDT) Received: by 10.64.126.71 with HTTP; Fri, 2 Aug 2013 00:52:55 -0700 (PDT) In-Reply-To: <079001ce8ec1$82e7e170$88b7a450$@olddog.co.uk> References: <95067C434CE250468B77282634C96ED322D6E09C@xmb-aln-x02.cisco.com> <079001ce8ec1$82e7e170$88b7a450$@olddog.co.uk> Date: Fri, 2 Aug 2013 03:52:55 -0400 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11330a1622b96f04e2f23f7e Cc: "Carlos Pignataro \(cpignata\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Minutes for IETF87, I2RS WG meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:53:01 -0000 --001a11330a1622b96f04e2f23f7e Content-Type: text/plain; charset=ISO-8859-1 Done - and many thanks again to Carlos for excellent minutes. Please email any corrections or name expansions privately and we will update. Alia On Thu, Aug 1, 2013 at 10:15 AM, Adrian Farrel wrote: > Many thanks, Carlos. > > If the chairs can arrange for these *draft* minutes to be posted ASAP? > > Cheers, > Adrian > > > -----Original Message----- > > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Carlos > > Pignataro (cpignata) > > Sent: 01 August 2013 14:01 > > To: i2rs@ietf.org > > Subject: [i2rs] Minutes for IETF87, I2RS WG meeting > > > > Hi, I2RS, > > > > Please find attached the minutes from today's I2RS meeting. Comments and > > corrections are most welcome!! > > > > Thanks, > > > > -- Carlos. > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11330a1622b96f04e2f23f7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Done - and many thanks again to Carlos for excellent minut= es. =A0Please email any corrections or name expansions privately and we wil= l update.

Alia

On Thu, Aug 1, 2013 at 10:15 AM, Adrian Farrel <= span dir=3D"ltr"><adrian@olddog.co.uk> wrote:
Many thanks, Carlos.

If the chairs can arrange for these *draft* minutes to be posted ASAP?

Cheers,
Adrian

> -----Original Message-----
> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Carlos
> Pignataro (cpignata)
> Sent: 01 August 2013 14:01
> To: i2rs@ietf.org
> Subject: [i2rs] Minutes for IETF87, I2RS WG meeting
>
> Hi, I2RS,
>
> Please find attached the minutes from today's I2RS meeting. Commen= ts and
> corrections are most welcome!!
>
> Thanks,
>
> -- Carlos.


_______________________= ________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--001a11330a1622b96f04e2f23f7e-- From joel.halpern@ericsson.com Thu Aug 1 08:11:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3A11E8100 for ; Thu, 1 Aug 2013 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHUmsvfOaaAV for ; Thu, 1 Aug 2013 08:11:26 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C221E8093 for ; Thu, 1 Aug 2013 08:11:18 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-7b-51fa7a956bab Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BC.73.13034.59A7AF15; Thu, 1 Aug 2013 17:11:17 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 1 Aug 2013 11:11:17 -0400 From: Joel Halpern To: "akatlas@gmail.com" , "jclarke@cisco.com" Thread-Topic: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 Thread-Index: AQHOjq19Bhf3VDT2uE6E0fyC9uEccZmAtsQA//++nQo= Date: Thu, 1 Aug 2013 15:11:16 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> References: <51FA492D.3070402@labn.net> , <51FA792E.3040908@cisco.com> In-Reply-To: <51FA792E.3040908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB07602F7B029eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXSPn+7Uql+BBusW6lt8eniJ2WLdjA8s Fvuu/mG06Gh+y+LA4jHl90ZWj52z7rJ7LFnyk8njw6ZmtgCWKC6blNSczLLUIn27BK6MpsYF TAVz7Ss6Pt9la2DcYNrFyMkhIWAicfjPDiYIW0ziwr31bF2MXBxCAkcZJZZNuMwE4SxjlPj9 eS0LSBWbgJ7E2vePwTpEBMIkrl/+xNzFyMHBLOAlsWKbFEhYWCBL4vnX92BhEYFsie6ZSRDV VhIt+3Ywg9gsAioSC1b/AZvCK+ArcaphAyvEqm5Gie/TDoAVcQpoSqw+fJ8VxGYEOu77qTVg DcwC4hK3nsyHOlpAYsme88wQtqjEy8f/WCFq8iUmTzrPCrFAUOLkzCcsExhFZiFpn4WkbBaS Moi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvoqRo7Q4tSw33chgEyMwyo5JsOnuYNzz 0vIQozQHi5I47yq9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKvZ7BMcLT6wz9twmINP 4dWvH2evOihmXLv+k83j17MNr5/O9tx8RqPC4qP3q+u3g8+pbPd9dOV8F1/BrpI1N7RcJveu lf06Y5W+x3Yxp31fmsyfiP9xi90QI1bV9X7+gs9/bebZHJLbEfDg8SrF3R76rjxHnh72fP1o wtnUXRel9pUdyrzaZn5aiaU4I9FQi7moOBEACLL5gIACAAA= X-Mailman-Approved-At: Fri, 02 Aug 2013 00:58:07 -0700 Cc: "i2rs@ietf.org" , "lberger@labn.net" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:11:31 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB07602F7B029eusaamb101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The client is the entity that is authenticated and authorized. If the clien= t is acting on behalf of someone else, we assume that the authentication an= d authorization of that party is the task of the client and outside our sco= pe. However we include that identity so that actions can be easily correlat= ed with originators. Yours, Joel Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Joe Marcus Clarke [jclarke@cisco.com] Received: Thursday, 01 Aug 2013, 17:07 To: Alia Atlas [akatlas@gmail.com] CC: Lou Berger [lberger@labn.net]; i2rs@ietf.org [i2rs@ietf.org]; Joel Halp= ern [joel.halpern@ericsson.com] Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in dra= ft-atlas-i2rs-architecture-01 On 8/1/13 7:51 AM, Alia Atlas wrote: > Not to answer for Joel, but my view is that a client is identified by > its identity. A different application can take over from the first by > using the same identity. Loss of a transport session does not cause > existing client state to be removed (in the architecture) - so there is > the ability for a new application to take over. > > Does that help? That worries me without more discussion about authentication. Additionally, from a troubleshooting standpoint, if I can assume the same identity as another client, how can I be absolutely sure which client does what to the agent? I feel there needs to be more to ensure accountability of what client does what, certainly from a security perspective, but also from a troubleshooting perspective. Joe > > Alia > > > On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > wrote: > > Hi Joel, > In today's session, I asked about provisions in the architect= ure > (document) for Client Redundancy/Fault Tolerance. I believe you state= d > that "it's not needed" and that you'd elaborate on the list. > > I believe you also answered a latter question by stating that clients > are free to coordinate between themselves to provide redundancy. Is t= his > the simple answer? If not, can you elaborate? > > Thanks, > Lou > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------= - --_000_6BCE198E4EAEFC4CAB45D75826EFB07602F7B029eusaamb101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The client is the entity that is authenticated and authori= zed. If the client is acting on behalf of someone else, we assume that the = authentication and authorization of that party is the task of the client and outside our scope. However we inc= lude that identity so that actions can be easily correlated with originator= s.

Yours,
Joel

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Joe Marcus Clarke [jclarke@cisco.com]
Received: Thursday, 01 Aug 2013, 17:07
To: Alia Atlas [akatlas@gmail.com]
CC: Lou Berger [lberger@labn.net]; i2rs@ietf.org [i2rs@ietf.org]; Jo= el Halpern [joel.halpern@ericsson.com]
Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance= in draft-atlas-i2rs-architecture-01

On 8/1/13 7:51 AM, Alia Atlas wrote:
> Not to answer for Joel, but my view is that a client is identified by<= br> > its identity.  A different application can take over from the fir= st by
> using the same identity.  Loss of a transport session does not ca= use
> existing client state to be removed (in the architecture) - so there i= s
> the ability for a new application to take over.
>
> Does that help?

That worries me without more discussion about authentication.
Additionally, from a troubleshooting standpoint, if I can assume the
same identity as another client, how can I be absolutely sure which
client does what to the agent?  I feel there needs to be more to ensur= e
accountability of what client does what, certainly from a security
perspective, but also from a troubleshooting perspective.

Joe

>
> Alia
>
>
> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>= ;> wrote:
>
>     Hi Joel,
>            = ; In today's session, I asked about provisions in the architecture
>     (document) for Client Redundancy/Fault Toleran= ce. I believe you stated
>     that "it's not needed" and that you'= d elaborate on the list.
>
>     I believe you also answered a latter question = by stating that clients
>     are free to coordinate between themselves to p= rovide redundancy. Is this
>     the simple answer?  If not, can you elabo= rate?
>
>     Thanks,
>     Lou
>     ______________________________________________= _
>     i2rs mailing list
>     i2rs@ietf.org <mailto:i2rs@ietf.org>
>     https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.iet= f.org/mailman/listinfo/i2rs
>


--
Joe Marcus Clarke, CCIE #5384,       &nb= sp; |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||= ||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867        = ; c i s c o  S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -
 --_000_6BCE198E4EAEFC4CAB45D75826EFB07602F7B029eusaamb101erics_-- From russw@riw.us Fri Aug 2 04:52:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68321E8353 for ; Fri, 2 Aug 2013 04:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJRIBosygGGl for ; Fri, 2 Aug 2013 04:52:45 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3B03621E83AB for ; Fri, 2 Aug 2013 04:52:13 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V5DtL-0004Sw-5M; Fri, 02 Aug 2013 04:51:31 -0700 From: "Russ White" To: "'Lou Berger'" , "'Alia Atlas'" References: <51FA492D.3070402@labn.net> <51FA4FF0.4060902@labn.net> In-Reply-To: <51FA4FF0.4060902@labn.net> Date: Fri, 2 Aug 2013 07:51:31 -0400 Message-ID: <031001ce8f76$a1d07830$e5716890$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLPBvwv9g+y/h2afUIobhWOb72fzQNkulKNAhAeTyyXVTeIcA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, Joel.Halpern@ericsson.com Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:52:50 -0000 > A bit. The discussion of treating multiple writers for the same state as errors > got me worried about this case - from a redundancy perspective, and to a > lesser degree, accountability standpoint. > > Given the importance of reliable operation even in the case of client failures, > I think the topic should be covered in the architecture document. Of course > this topic/comment can be addressed after the document is adopted. Wouldn't much of this problem be alleviated if we went to a RESTful style atomic interface? It seems, to me, that multipart "commit/rollback" procedures always end up adding a lot of complexity, etc. I know there are situations where it's simpler to have the client hold partial state while telling the controller, "this part will succeed, please send me the next part," but then we've also fallen into dealing with latency of operations, locking forwarding plane tables across a remote connection (which routing events are still occurring!), and this entire error management mess in terms of resiliency. Routing protocols produce atomic updates today --we should stick with the pattern set there as much as possible. :-) Russ From cpignata@cisco.com Sat Aug 3 11:56:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FA711E80D5 for ; Sat, 3 Aug 2013 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj1cr-27aCrP for ; Sat, 3 Aug 2013 11:56:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9405321F9EED for ; Sat, 3 Aug 2013 11:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11719; q=dns/txt; s=iport; t=1375556163; x=1376765763; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sRbSVXV6TSQXcMRXpq0SREaYaHJS05xd0AerHHCCIms=; b=efNp3xFLgcoK0JUo8PHAuxSOhwj1FfTi+3luFtXB/LJwqHEJM0gBKCKv Pll/Mb24K4x/70KQq9p6IV0cz6cEMJx5GEB/cyv4SLWPOQyTENl2cT3B6 hlCrrVFj6OyRjsPiEz8oRuLEttzECuuevbADevFO4oG6LSWF/R1+u/2gT o=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGFR/VGtJV2b/2dsb2JhbABQCoMGgQW/FIEdFnSCJAEBAQECAR1cBQsCAQgYCiQyJQIEDgUIBod8BrZHjleBETEHAoMXdAOQE4EtkFGHHoFegTmCKg X-IronPort-AV: E=Sophos;i="4.89,808,1367971200"; d="asc'?scan'208";a="242954239" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2013 18:56:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r73Iu2Qf022140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 18:56:02 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 3 Aug 2013 13:56:02 -0500 From: "Carlos Pignataro (cpignata)" To: Nitin Bahadur Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOjSH8NPZhc7/uTEe7nO8TSnTgBpmD9qYA Date: Sat, 3 Aug 2013 18:56:02 +0000 Message-ID: <95067C434CE250468B77282634C96ED322DAAC34@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.77.108] Content-Type: multipart/signed; boundary="Apple-Mail=_046E1828-A0BF-4BFB-BE80-BD2363A2FD30"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 18:56:09 -0000 --Apple-Mail=_046E1828-A0BF-4BFB-BE80-BD2363A2FD30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Nitin, Many thanks for the follow-up, please see inline. On Jul 30, 2013, at 2:40 PM, Nitin Bahadur wrote: >=20 > Hi Carlos, >=20 >=20 > Thanks for the detailed review. Please see inline below. >=20 > On 7/29/13 12:05 AM, "Carlos Pignataro (cpignata)" = > wrote: >=20 >> Hi, >>=20 >> I have concerns with adopting this document. >>=20 >> As others have mentioned on the list, the concepts of RIB and routing >> instance seem to be inverted. >=20 > Yes, I have removed "RIB" as a top-level container to avoid the > confusion/inversion-issue. >=20 >> But in addition to that, there seem to be two other issues with the >> document in its current shape: >> 1. It's not clear the scope of what's within the Routing Information = Base >> information model. Specifically, elements defined seem to belong in = the >> FIB and not the RIB. >=20 > Besides the routing table, which other elements did you have in mind. >=20 There is a potential gray area between things that are clearly routing = and others that are clearly forwarding. However, I do wonder if things = like RPF (F for forwarding), matching on incoming MAC address, = NO_DECREMENT_TTL, and others are outside the scope of what the RIB is. > Regarding "routing tables" as an element of the FIB, then I think it's = a > terminology mis-understanding. A routing-table (as per this draft) is > something that is local to the control plane and has nothing to do = with > the forwarding plane. A routing-table (as per this draft) is a = database > containing route information. The draft talks about "MPLS Route" and "MAC Route". To me, it would be = useful to further describe the scope of that is a route, a prefix, etc. = LDP does not distribute "routes". > Now if this terminology conflicts/confuses > with how hardware vendors use the same term, I would be happy to = change > the name to something else (maybe call it a RIB). I hope you now > understand why I did not think of it as a FIB construct. I do, thanks. I do think that tighter terminology will certainly help. = "the beginning of wisdom is the definition of terms". And I do believe = that we can derive what should be included into the information model = from scoped definitions. >=20 >> 2. The document structure seems to have gaps and overlaps, and lacks = a >> compiled set of definitions of RIB elements. >=20 > Compiled set of definitions of the elements is on my TODO list. I'll > likely add an Appendix at the end. >=20 Ack -- thanks. >>=20 >> Please find below some additional questions and observations on the >> document, marked with "CMP". >>=20 >> I hope these are clear and useful. >>=20 >> Routing Information Base Info Model >> draft-nitinb-i2rs-rib-info-model-01 >>=20 >> 1. Introduction >>=20 >> The rest of this document is organized as follows. Section 2.1 goes >> into the details of what constitutes and can be programmed in a RIB. >> Section 5 provides a high-level view of the events and notifications >> going from a network device to an external entity, to update the >> external entity on asynchronous events. The RIB grammar is = specified >> in Section 6. Examples of using the RIB grammar are shown in >> Section 7. >>=20 >> CMP: What about other Sections? =46rom 2.1 it jumps to Section 5 >=20 >=20 > Will be cleaned up in next rev. Thanks. >=20 >>=20 >> and not proactive push (from the router) mechanisms. Screen = scraping >> is error prone (since output can change) and vendor dependent. >>=20 >> CMP: A nit -- the output will change. I think "since the output = format >> can change" is what's meant. >=20 > Will fix. >=20 Ack. >=20 >> 2.1. RIB definition >>=20 >> A RIB is a logical construct controlled by an external entity. A = RIB >> contains one or more routing instances. On a network device, a RIB >> is uniquely identified by its name. A routing instance can be in >> only 1 RIB. A routing instance, in the context of the RIB >> information model, is a collection of routing tables, interfaces, = and >> routing parameters. A routing instance creates a logical slice of >> the router and allows different logical slices; across a set of >> routers; to communicate with other each. >>=20 >> CMP: I think these set of definitions could use a visual to describe >> what's a RIB, routing instance, routing tables and their high-level >> elements, in addition to itemized definitions. >=20 > I have a UML diagram representing this, but there is no way to imbed > images in IETF drafts (maybe time to change IETF draft format?). I'll = add > a text form of a diagram for readability. >=20 >=20 Thank you. >> Layer 3 Virtual Private >> Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service >> (VPLS) can be modeled as routing instances. >>=20 >> CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as >> routing instances. Which L3 elements are there in an L2VPN? >=20 > There are no L3 elements in a L2VPN. However, one can (if one really > wants) setup a static PW through the RIB model and then map MAC routes = to > that PW. You can argue that MAC routes shouldn't be a part of this = draft > and I'll be happy to remove it if there is consensus. >=20 Exactly. But this is a consequence of lack of precision in the = definition and scope. To me, it should follow the definition and agreed scope. I would also = like to see which direction the WG wants to go. >=20 >> Note that modeling a >> Layer 2 VPN using a routing instance only models the Layer-3 (RIB) >> aspect and does not model any layer-2 information (like ARP) that >> might be associated with the L2VPN. The question I still have on this is how you are associating "Layer-3" = to "RIB". That is self-contradicting with other parts of the draft (MAC = routes). >>=20 >> CMP: DOes this mean that ARP should be out of the RIB model? >=20 > ARP should be out of the RIB model. ARP is a network-device local = function. >=20 >=20 >> 2.2. Routing tables >>=20 >> A routing table is an entity that contains routes. A routing table >> is identified by its name. The name MUST be unique within a RIB. >> All routes in a given routing table MUST be of the same type (e.g. >> IPv4). Each routing table MUST belong to some routing instance. >>=20 >> CMP: Should you also differentiate, in addition to the AF, by unicast >> versus multicast? >=20 > It would be good if someone kept unicast & mcast in different tables, = but > the model does not enforce > that. >=20 >=20 >> Each route table can be optionally associated with a >> ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding >> (RPF) checks on all IP routes in that table. Reverse path = forwarding >>=20 >> CMP: Is RPF an attribute of the routing table? >=20 > In reality, RPF is an attribute of the route. But it's simpler if it = is > associated with the entire table..so you do an RPF check for all = routes in > that table. It is possible to move this as an attribute of the route = and > if folks prefer that, it's an easy change. >=20 My question was slightly different -- is RPF an attribute of forwarding = or of routing? Is it in the context of multicast, or uRPF (loose or = strict?)? >=20 >> 2.3. Route >>=20 >> A route is essentially a match condition and an action following the >> match. The match condition specifies the kind of route (IPv4, MPLS, >> etc.) and the set of fields to match on. This document specifies = the >> following match types: >>=20 >> CMP: What is an "MPLS Route" in the context of a routing table? >=20 > MPLS route is nothing but a mpls label match. See please below the next comment. >=20 >>=20 >> o IPv4: Match on destination IP in IPv4 header >> o IPv6: Match on destination IP in IPv6 header >> o MPLS: Match on a MPLS tag >> o MAC: Match on ethernet destination addresses >>=20 >> CMP: Is the MAC address a match element within routing? >=20 > MAC address is really not a routing concept. But given that we have = mac > addresses being passed around in E-VPN and that VPLS deals with MAC > addresses, there was sufficient motive to add MAC address match. >=20 >=20 This is a key comment. Scope of what's a "route" or a "RIB" or = "route-table" entry is not clear.=20 >=20 >=20 >> Or what types of address families and identifiers are input to = defining >> the elements included? >=20 > I'm not sure if I understand the above question. AF_IP, AF_IPV6, = AF_MPLS? >=20 Sorry I was not clear -- the real question is about "MAC routes", "MPLS = routes", or frankly the question is to which attributes define a = RIB/route-table: a network-layer protocol address family? plus = uni/multicast? Anything that is distributed by a routing protocol? >=20 >=20 >> 2.4.1. Nexthop types >>=20 >> o Special nexthops - for performing specific well-defined functions >>=20 >> CMP: Are things like the drop/null route fitting here? Are there many >> different kinds of specials, or should they be listed explicitly? >=20 > They should be called out explicitly someplace but not here. This is = more > of an overview of the info model and putting in all the details in = this > section would disturb the overall flow. >=20 >=20 >> 6. RIB grammar >>=20 >> ::=3D | | >> | >>=20 >> CMP: Why these families? >=20 > It doesn't make sense to put IPv4 routes and IPv6 routes together. > Currently, routing vendors have well-defined table names that = implicitly > identify the address family of routes in a given table. Intent here is = to > remove that implicit assumption. >=20 That (being explicit) sounds good -- the question is (again, sorry) = about "IEEE MAC RIB". >=20 >>=20 >> CMP: Do you need to separate IPv4 in unicast versus multicast? Or are = you >> modeling a single table with attributes for the uni/multicast? >=20 > As I said before, it's up to the I2RS server (controller) Do you mean the I2RS server (agent) or the client (controller)? > to create > multiple tables (one for unicast and one for mcast). If the WG feel > strongly, we can enforce that in the model. >=20 >=20 >> ::=3D >>=20 >> CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"? >=20 > I don't know. Last I remember, in rBNF, all terminal stuff should be = all > CAPS. >=20 Sorry for not being clear, my comment is not about the RBNF. An IPv4 route does not have "addresses", it contains "prefixes". I was = wondering if "IPv4_PREFIX" should replace "IPV4_ADDRESS". Thanks, -- Carlos. > Thanks > Nitin >=20 >=20 >=20 --Apple-Mail=_046E1828-A0BF-4BFB-BE80-BD2363A2FD30 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 - http://gpgtools.org iEYEARECAAYFAlH9IlwACgkQtfDPGTp3USw8lwCfe3p0LS5FpT9vUS/DpuxopBpq qWUAninWn/Xn2nuLxGgTtZhD68rv4box =EmUb -----END PGP SIGNATURE----- --Apple-Mail=_046E1828-A0BF-4BFB-BE80-BD2363A2FD30-- From abhijitk@us.ibm.com Mon Aug 5 03:06:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6721F9CE9 for ; Mon, 5 Aug 2013 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldj23eKgJvYs for ; Mon, 5 Aug 2013 03:06:12 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 975BF21F9E80 for ; Mon, 5 Aug 2013 03:03:10 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Aug 2013 04:02:49 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 5 Aug 2013 04:02:46 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 8FBC819D804C for ; Mon, 5 Aug 2013 04:02:33 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r75A2Ooe167770 for ; Mon, 5 Aug 2013 04:02:25 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r75A2NLM001115 for ; Mon, 5 Aug 2013 04:02:23 -0600 Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com [9.63.34.16]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r75A2MeL000882 for ; Mon, 5 Aug 2013 04:02:22 -0600 Auto-Submitted: auto-generated From: Abhijit Kumbhare To: i2rs@ietf.org Message-ID: Date: Mon, 5 Aug 2013 04:01:10 -0600 X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/05/2013 04:02:19 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF12DDFA48CAB8f9e8a93df938690918c08BBF12DDFA48CAB" Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13080510-3620-0000-0000-000003D0588E Subject: [i2rs] AUTO: is out of the office. (returning 08/13/2013) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 10:06:29 -0000 --0__=08BBF12DDFA48CAB8f9e8a93df938690918c08BBF12DDFA48CAB Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 08/13/2013. Travelling on a vacation and may not get a chance to check emails frequently. For any SDN/OpenFlow related issues - please contact Anees Shaikh. For = any general System Networking architecture issues my colleague Keshav Kambl= e . For any other issues - please contact Vijoy Pandey. Note: This is an automated response to your message "i2rs Digest, Vol = 9, Issue 21" sent on 07/28/2013 12:56:10 AM. This is the only notification you will receive while this person is awa= y.= --0__=08BBF12DDFA48CAB8f9e8a93df938690918c08BBF12DDFA48CAB Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 08= /13/2013.

Travelling on a vacation an= d may not get a chance to check emails frequently.

For any SDN/OpenFlow relate= d issues - please contact Anees Shaikh. For any general System Networki= ng architecture issues my colleague Keshav Kamble . For any other issue= s - please contact Vijoy Pandey.


Note: Thi= s is an automated response to your message  "i2rs Digest, Vol 9, Issue 21" sent = on 07/28/2013 12:56:10 A= M.
This is t= he only notification you will receive while this person is away.= = --0__=08BBF12DDFA48CAB8f9e8a93df938690918c08BBF12DDFA48CAB-- From tnadeau@lucidvision.com Mon Aug 12 10:27:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AD221F9CD1 for ; Mon, 12 Aug 2013 10:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9faH+OHMqt+B for ; Mon, 12 Aug 2013 10:27:37 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AF20321F9B92 for ; Mon, 12 Aug 2013 10:24:50 -0700 (PDT) Received: from wgao-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id EBF3A252E7AA for ; Mon, 12 Aug 2013 13:24:49 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD800F9-BDC9-4782-9E8E-7093CA0B10E6@lucidvision.com> Date: Mon, 12 Aug 2013 13:24:49 -0400 To: "i2rs@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [i2rs] NOMS 2014 Call for Papers X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:27:45 -0000 http://noms2014.ieee-noms.org/content/call-experience-session-papers http://www.ieee-noms.org/ NOMS 2014 will be next year's IEEE flagship conference in the area of = management of networked systems and services. The symposium will include = an Experience Session program. Experience Sessions complement the = Technical Sessions with contributions that emphasize practical = experiences and lessons learnt in applying, implementing, and deploying = management technology. They will focus on aspects such as real-world = deployment scenarios, experiences with the management of new services = and technology, industrial applications of management technology, = implementation experiences, and organizational considerations. = Experience sessions are particularly aimed at decision makers and = experts from industry. New this year and for the first time at NOMS, the best Experience Paper = will be recognized with an award. =20 Topics of interest=20 NOMS 2014's theme is "Management in a Software Defined World". NOMS 2014 = will place particular emphasis on Software Defined Networking and = related technologies; submissions in those areas are particularly = encouraged. Specific topics include but are not limited to the ones = listed below. Please refer also to the general Call for Papers. =95 Management case studies and best practices =95 Issues and experiences with practical deployments =95 Software Defined Networks and enabling technologies =95 Open source SDN frameworks, Open Daylight =95 Experiences with OpenFlow deployments =95 Orchestration and SDN controllers =95 Network Function Virtualization implementations =95 Data center automation =95 Management of cloud =95 Cloud service assurance =95 Big Data analytics in management =95 Management of virtualized environments =95 OSS/BSS development =95 Virtualization of operation centers and help desks =95 Organizational aspects of IT service management =95 IT governance =95 Service engineering and operational challenges =95 Management of emerging networks and services =95 Green management and managing energy efficiency =95 Smart buildings, industrial automation and management =95 Experiences with autonomic networking and self-management =95 Application of machine learning and data mining to = management =95 Advances in standardization =95 Management information models =95 Event correlation, diagnostics, fault, performance = management =95 Billing and accounting models and service level management =95 Business alignment of IT service management =95 Experiences with Call Home frameworks =95 Managed service provider issues =95 Service delivery and service assurance =95 Experiences with process engineering and frameworks (ITIL, = eTOM) =95 Other topics in network and service operations and = management From sriganeshkini@gmail.com Mon Aug 12 10:58:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591B21F93BA for ; Mon, 12 Aug 2013 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiWksUV91ATO for ; Mon, 12 Aug 2013 10:58:42 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id AE04121F90FD for ; Mon, 12 Aug 2013 10:58:42 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so3766773pdj.12 for ; Mon, 12 Aug 2013 10:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=V01pkC69TUzS8hMoHfebkYqUZcAB4SUednkTrtf6O80=; b=LfLRKpZ3vXuHJhNgxpeSriaHrPjuUQOeoRSo20+Vl6m9d5TprVIL0tmnUPMNaE+N5b 1QZD95IRc4ya2mfRaVsypJ2VrIj/XFkiwLoeKn+/DIcmn0otnhnyP4lz/+Vt89SZm26e vzE/EMQ7jDXE85uqurFvr0tZFdYZkFzfOa2T5UjmlQuh+qgMOa19qDswQAx5bXLWDNaQ u0vhbLWLSLg7++lWRfZtES7gE0gzHFZOqPIJ8BGbpX/PzyiJmQZ3m+m/n9Zx44ugseky ChJr9bJ+oe6mmwxBZrBkK4HDVrePFWfaXjyKgbJ4TpieYOeLHeyD+aQyxEwGDNKmI+E4 dL0w== X-Received: by 10.66.218.74 with SMTP id pe10mr243997pac.177.1376330322346; Mon, 12 Aug 2013 10:58:42 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Mon, 12 Aug 2013 10:58:12 -0700 (PDT) In-Reply-To: References: From: Sriganesh Kini Date: Mon, 12 Aug 2013 10:58:12 -0700 X-Google-Sender-Auth: j1T91rRBHUhwB3v2dnrnUFB_504 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7b5d9de9f50acc04e3c3df1a Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:58:43 -0000 --047d7b5d9de9f50acc04e3c3df1a Content-Type: text/plain; charset=UTF-8 Support WG adoption. On Wed, Jul 24, 2013 at 2:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --047d7b5d9de9f50acc04e3c3df1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support WG adoption.
<= br>
On Wed, Jul 24, 2013 at 2:52 PM, Alia Atl= as <akatlas@gmail.com> wrote:
Please review draft-atlas-i= 2rs-architecture-01 and comment on whether it should be adopted by I2RS. = =C2=A0Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-arch= itecture-01? Is so, has this IPR been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,Alia

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--047d7b5d9de9f50acc04e3c3df1a-- From edc@google.com Tue Aug 13 09:36:08 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537311E818C for ; Tue, 13 Aug 2013 09:36:04 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoJppLu+4NRC for ; Tue, 13 Aug 2013 09:36:02 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id C531211E8188 for ; Tue, 13 Aug 2013 09:35:58 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id f14so870357wiw.7 for ; Tue, 13 Aug 2013 09:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hH2Wlvv81VCSqGj3qopjCM+hcElIp/yHcqWYDkx4DAc=; b=W75+mjkA1OLX0fd4aYsYRSxbjVTwBwc+DJ/2J2m6IFSSbQBaPS/5jfdzjyKVSiujGI Z11HKVrmyPoC4oaF+vSDDQ7dpQOxxUN/qBUML7njpgIQbsZ0SIl9quG/+mffcDYgi0ez n7B52Jdx9Ot/s9dkMB/KvYASJBnPE03+3qkt2s3ot+gZNK5ERYSXrGtY4yZhPotbYZQk jXOtue1K5KrDDudMqT/fVujIDIY9JHASl73jRuF5DCEChtZEVIn5dyWEgKngNQIaYhEL 2Q8Yvli2aaC+nuhiQyGGjNzO4QEO04UjQzENkIvLD+a18p0sEIuSy5Kyjlp4jEUMM+/2 u5uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hH2Wlvv81VCSqGj3qopjCM+hcElIp/yHcqWYDkx4DAc=; b=GhiAmCP8Rgbt9gNryHsQ603FIzXaPRz8KNBk7JVIGO/3oZ1a1EAP6JQutr0i1u2jzA aj50ofQsX76iMXR4qLF+aA3tiH9cPqamDMvsZrJldCWUI9pbmeXSdlRcJy7dVEsfKrwQ ujPp6qOEd1ndES+9M2KIW8nwsDkVsNkxa5OQSyntrMAWmp62pvkP214RphxkG2PSRLqu KkJuO+5abFTINCQxc639RD1o25WFvQrGvCG5wvdYon5L68jA0zU855V2/WxIjPrYlSAZ QbfjwyFxEyZCInnhy7BeilQBPr2vDpKiJA7jSDd9wxgDbHcd2i9p4btEHU/gqpsdZvav jYzQ== X-Gm-Message-State: ALoCoQki07lcDfi/iA+dqjsGLIRbn2UVA3Mf6B0cB8bcJNHrdFuYOi9NAsJLE+j1vnGjS+F1bWUV9afcnSeMpVaKiuQ4DNoqPFDKwYAV2sifCJvU7HttGmi8pJjQVlUsC/7UkKj/YPJQt/B0QsEDC1Jjf83CsijESr9dv7Ih7Ww6uRqurjTV+UU+sGd01ol/ZbkigTZoM4VV X-Received: by 10.180.183.180 with SMTP id en20mr383262wic.18.1376411756670; Tue, 13 Aug 2013 09:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.99 with HTTP; Tue, 13 Aug 2013 09:35:16 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Tue, 13 Aug 2013 09:35:16 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:36:09 -0000 I2RSers; Yesterday ended the poll for wg adoption of this draft. Although there seems to be sufficient support to warrant adoption, and there do not seem to be any show-stoppers, I haven't seen any responses on the list from Alia yet. Alia should respond to comments and update the draft as warrranted before we finalize the process. I believe she's in the midst of doing just that. cheers, -ed On Mon, Aug 12, 2013 at 10:58 AM, Sriganesh Kini wrote: > Support WG adoption. > > > On Wed, Jul 24, 2013 at 2:52 PM, Alia Atlas wrote: >> >> Please review draft-atlas-i2rs-architecture-01 and comment on whether it >> should be adopted by I2RS. Detailed technical conversation is also most >> welcome. >> >> Authors: Are you aware of any IPR that applies to >> draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more >> details). >> >> This WG call for adoption will complete on August 12. >> >> Thanks, >> Alia >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Tue Aug 13 11:44:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B521F91B7 for ; Tue, 13 Aug 2013 11:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab0Juh5whfKT for ; Tue, 13 Aug 2013 11:44:27 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2AABD21F84B1 for ; Tue, 13 Aug 2013 11:44:27 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so12079996oah.9 for ; Tue, 13 Aug 2013 11:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cZPGlciF2RP75glZgQl7V5UC0QG4QaseQ+lPEZDZLYI=; b=KfEM9SJwMa/oQP9s6o8+ZWc1t7PI1eVS59LyvSZvpoNroRaElXOABJyjUEy/L8Sd3J YYlVbEc9WBrNm3Rf+L5tc298CHiLLL8I52HSZ0WpjNqprnmappATXhgOSeCK5jbG2aLo BZlBOCxy4IsOW8WEIQHqji5aInT+fGqUikX9pFq9lKcLa3DOaKvHe4ooE89P/HpoN+NK k0tqxe/KjWjaTTfsRvFa5H9uIaM5rgledrh2FO3s4J575auoTpqQvzD/csCDKjqEgQtT gwhB+9LyAMBIuRc0hb0DgMLkaNbyxdzNWehX3Pdy25+Fed6Et/7t+Q0yKxw9dQZ1m1KT IFdw== MIME-Version: 1.0 X-Received: by 10.60.40.34 with SMTP id u2mr1459619oek.91.1376419466547; Tue, 13 Aug 2013 11:44:26 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 11:44:26 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322D5EDE4@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322D5EDE4@xmb-aln-x02.cisco.com> Date: Tue, 13 Aug 2013 14:44:26 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=089e0149ce5c5d962f04e3d8a1f1 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 18:44:28 -0000 --089e0149ce5c5d962f04e3d8a1f1 Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Thanks for the review and comments. I apologize for the delay in responding. I took some vacation after IETF. On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > I support I2RS adoption of this document. > > This is a very solid start with a very well written individual draft. > > I also take the chance to share some questions and provide some review > feedback (with "CMP"): > > An Architecture for the Interface to the Routing System > draft-atlas-i2rs-architecture-01 > > 1. Introduction > > The I2RS, and therefore this document, are specifically focused on an > interface for routing and forwarding data. > > CMP: "and forwarding data"? Ultimately the interface will influence > forwarding, but is it focused on it? > [Alia] True - I've removed "and forwarding data" > 1.2. Architectural Overview > > Routing: This block represents that portion of the Routing Element > that implements part of the Internet routing system. It includes > not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, > RSVP-TE, LDP, etc.), but also the RIB Manager layer. > > CMP: Things like LDP and RSVP-TE are counted as "routing". It is not clear > to me that we might want to lump it together here, and frankly what the > scope for these things is. I suspect it might be worth clarifying the reach > and scope of these. > [Alia] I see them as grouped into "routing and signaling" and definitely part of I2RS. The problem-statement draft (not a WG draft yet) clearly states: "In addition to interfaces to the RIB layer, there is a need to configure the various routing and signaling protocols with differing dynamic state based upon application-level policy decisions." and the framework draft that this architecture replaces had a slightly larger section on use-cases and examples. What is your specific concern and how would you want to see the reach and scope confined in the architecture draft? > > I2RS Client: ... It interacts with the I2RS clients to collect > information > from the routing and forwarding system. > > CMP: I also wonder whether these references to interaction with the > "Forwarding system" refer to MPLS dataplane encap or are further reaching, > and how. For example, creating a Tunnel would not be "forwarding". > [Alia] First, the I2RS clients should be I2RS agents. I've fixed that. Second, these are a bit further reaching. For instance, learning about link up/down events, subscribing to counters for when they go over a particular threshold, etc. Basically, to provide the information necessary for a network application's feedback loop, information outside of the routing system may be necessary to read/learn. The exact details will depend on the use-cases and proposed info-models. Do you think that a text change is needed? If so, what would you suggest? > > 2. Terminology > > identity: A client is associated with exactly one specific > identity. State can be attributed to a particular identity. It > is possible for multiple communication channels to use the same > identity; in that case, the assumption is that the associated > client is coordinating such communication. > > CMP: It seems to me that the "client identity" is necessary, but sometimes > not sufficient. I recall seeing an "Application Identity" somewhere in this > document, and wonder if that concept should not be elevated in the > requirement priority. > [Alia] Sure, it's clear that the broker model is of interest. I'll add in secondary identity: An I2RS Client may supply a secondary opaque identity that is not interpreted by the I2RS Agent. An example use is when the I2RS Client is a go-between for multiple applications and it is necessary to track which application has requested a particular operation. > 3.4. Authorization and Authentication > > I2RS clients may be operating on behalf of other applications. While > those applications' identities are not need for authorization, each > application should have a unique opaque identifier that can be > provided by the I2RS client to the I2RS agent for purposes of > tracking attribution of operations. > > CMP: It seems to me that the identity of an application is also critical > for Accounting (and troubleshooting). > [Alia] Yes, tracking the attribution of operations allows aspects like accounting and troubleshooting. I've modified the sentence to end: ...identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to support functionality such as accounting and troubleshooting. 4. Network Applications and I2RS Client > > When an I2RS Client interacts with multiple network applications, > that I2RS Client is behaving as a go-between and may indicate this to > the I2RS Agents by, for example, specifying a secondary opaque > identity to allow improved troubleshooting. > > CMP: Should this be stronger than a "may indicate"? > [Alia] Sure - I'll upgrade it to "should indicate". This is a question of supporting the broker model of an I2RS client for ease of troubleshooting. > > 4.1. Example Network Application: Topology Manager > > One example of such an application is a Topology Manager. Such an > application includes an I2RS client which uses the I2RS protocol to > collect information about the state of the network. The Topology > Manager would collect device and interface state from devices it > interacts with directly. > > CMP: Tunnels are some times key elements in a topology. Are tunnels > considered as "interfaces" or should those be called out explicitly? > [Alia] Tunnels aren't interfaces - but the details of what should be in the topology depends on the topology info-model and isn't specified in the architecture. > 5.4.1. Unicast and Multicast RIB and LFIB > > Network elements concerned with routing IP maintain IP unicast RIBs. > Similarly, there are RIBs for IP Multicast, and a Label Information > Base (LIB) for MPLS. > > and > > 5.4.3. MPLS > > The I2RS Agent will need to interact with the knobs that policy > attributes that control LDP operation as well as RSVP-TE based LSPs. > > CMP: While I think that programmatically interfacing with MPLS information > is useful, the case is not clearly described in the problem statement, nor > it seems to be captured comprehensively here. Section 5.4.3 includes only a > big broad statement, but it's not clear which elements of label > distribution protocols (i.e., BGP also seems missing here) are relevant to > I2RS. > [Alia] BGP is already mentioned as a protocol that will need an info-model. I guess I think of this section as discussing the transport LSPs and associated protocols as compared to the MPLS services. The MPLS services are part of routing and should be included too. I've changed the text in Sec 5.4.3 to read: "The I2RS agent will need to interact with the protocols that create transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, L2VPNs, etc)." > 6.1. Protocol Structure > > protocol. That protocol may use several underlying transports (TCP, > SCTP, DCCP), with suitable authentication and integrity protection > > CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP? > [Alia] There may be cases of data streams that don't require a reliable underlying transport. I'm thinking about providing statistics streams. I am concerned about the issues with timely delivery that can arise with TCP - but I think that what transport protocol is appropriate will depend a bit on what data is being delivered. Thanks again for the detailed review and questions, Alia Thanks, > > -- Carlos. > > > On Jul 24, 2013, at 11:52 PM, Alia Atlas wrote: > > > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > > > > This WG call for adoption will complete on August 12. > > > > Thanks, > > Alia > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --089e0149ce5c5d962f04e3d8a1f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for the review and co= mments. =A0I apologize for the delay in responding. =A0I took some vacation= after IETF.


On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) <cpigna= ta@cisco.com> wrote:
I support I2RS adoption of this document.

This is a very solid start with a very well written individual draft.

I also take the chance to share some questions and provide some review feed= back (with "CMP"):

=A0 =A0 =A0 =A0 An Architecture for the Interface to the Routing System
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-atlas-i2rs-architecture-01
1. =A0Introduction

=A0 =A0The I2RS, and therefore this document, are specifically focused on a= n
=A0 =A0interface for routing and forwarding data.

CMP: "and forwarding data"? Ultimately the interface will influen= ce forwarding, but is it focused on it?
[Alia] True - = I've removed "and forwarding data"=A0
=A0
1.2. =A0Architectural Overview

=A0 =A0Routing: =A0 This block represents that portion of the Routing Eleme= nt
=A0 =A0 =A0 that implements part of the Internet routing system. =A0It incl= udes
=A0 =A0 =A0 not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM,<= br> =A0 =A0 =A0 RSVP-TE, LDP, etc.), but also the RIB Manager layer.

CMP: Things like LDP and RSVP-TE are counted as "routing". It is = not clear to me that we might want to lump it together here, and frankly wh= at the scope for these things is. I suspect it might be worth clarifying th= e reach and scope of these.

[Alia] I see them as grouped into "ro= uting and signaling" and definitely part of I2RS. =A0The problem-state= ment draft (not a WG draft yet) clearly states:=A0
"In addition to interfaces to the RIB= layer, there is a need to=A0configure the various routing and signaling protocols with differin= g=A0dynamic state bas= ed upon application-level policy decisions." and the framework draft t= hat this architecture replaces had a slightly larger section on use-cases a= nd examples.

<= span style=3D"color:rgb(0,0,0);font-size:1em">What is your specific concern= and how would you want to see the reach and scope confined in the architec= ture draft?
=A0

=A0 =A0I2RS Client: =A0 ... =A0It interacts with the I2RS clients to collec= t information
=A0 =A0 =A0 from the routing and forwarding system.

CMP: I also wonder whether these references to interaction with the "F= orwarding system" refer to MPLS dataplane encap or are further reachin= g, and how. For example, creating a Tunnel would not be "forwarding&qu= ot;.

[Alia] =A0First, the I2RS clients should b= e I2RS agents. =A0I've fixed that. =A0Second, these are a bit further r= eaching. =A0For instance, learning about link up/down events, subscribing t= o counters for when they go over a particular threshold, etc. =A0Basically,= to provide the information necessary for a network application's feedb= ack loop, information outside of the routing system may be necessary to rea= d/learn. =A0The exact details will depend on the use-cases and proposed inf= o-models.

Do you think that a text change is needed? =A0If so, wh= at would you suggest?
=A0

2. =A0Terminology

=A0 =A0identity: =A0 A client is associated with exactly one specific
=A0 =A0 =A0 identity. =A0State can be attributed to a particular identity. = =A0It
=A0 =A0 =A0 is possible for multiple communication channels to use the same=
=A0 =A0 =A0 identity; in that case, the assumption is that the associated =A0 =A0 =A0 client is coordinating such communication.

CMP: It seems to me that the "client identity" is necessary, but = sometimes not sufficient. I recall seeing an "Application Identity&quo= t; somewhere in this document, and wonder if that concept should not be ele= vated in the requirement priority.

[Alia] Sure, it's clear that the broke= r model is of interest. =A0I'll add in

=A0 =A0= secondary identity: =A0An I2RS Client may supply a secondary opaque identit= y that is not interpreted by the I2RS Agent. An example use is when the I2R= S Client is a go-between for multiple
applications and it is necessary to track which application has
<= div>requested a particular operation.
=A0
3.4. =A0Authorization and Authentication

=A0 =A0I2RS clients may be operating on behalf of other applications. =A0Wh= ile
=A0 =A0those applications' identities are not need for authorization, e= ach
=A0 =A0application should have a unique opaque identifier that can be
=A0 =A0provided by the I2RS client to the I2RS agent for purposes of
=A0 =A0tracking attribution of operations.

CMP: It seems to me that the identity of an application is also critical fo= r Accounting (and troubleshooting).

[Al= ia] Yes, tracking the attribution of operations allows aspects like account= ing and troubleshooting. =A0I've modified the sentence to end:

...identifier that can be provided by the I2RS cli= ent to the I2RS agent for purposes of tracking
attribution of ope= rations to support functionality such as accounting and troubleshooting.

4. =A0Network Applications and I2RS C= lient

=A0 =A0When an I2RS Client interacts with multiple network applications, =A0 =A0that I2RS Client is behaving as a go-between and may indicate this t= o
=A0 =A0the I2RS Agents by, for example, specifying a secondary opaque
=A0 =A0identity to allow improved troubleshooting.

CMP: Should this be stronger than a "may indicate"?

[Alia] Sure - I'll upgrade it to "should in= dicate". =A0This is a question of supporting the broker model of an I2= RS client for ease of troubleshooting.
=A0

4.1. =A0Example Network Application: Topology Manager

=A0 =A0One example of such an application is a Topology Manager. =A0Such an=
=A0 =A0application includes an I2RS client which uses the I2RS protocol to<= br> =A0 =A0collect information about the state of the network. =A0The Topology<= br> =A0 =A0Manager would collect device and interface state from devices it
=A0 =A0interacts with directly.

CMP: Tunnels are some times key elements in a topology. Are tunnels conside= red as "interfaces" or should those be called out explicitly?
=

[Alia] Tunnels aren't interfaces - but= the details of what should be in the topology depends on the topology info= -model and isn't specified in the architecture.
=A0
5.4.1. =A0Unicast and Multicast RIB and LFIB

=A0 =A0Network elements concerned with routing IP maintain IP unicast RIBs.=
=A0 =A0Similarly, there are RIBs for IP Multicast, and a Label Information<= br> =A0 =A0Base (LIB) for MPLS.

and

5.4.3. =A0MPLS

=A0 =A0The I2RS Agent will need to interact with the knobs that policy
=A0 =A0attributes that control LDP operation as well as RSVP-TE based LSPs.=

CMP: While I think that programmatically interfacing with MPLS information = is useful, the case is not clearly described in the problem statement, nor = it seems to be captured comprehensively here. Section 5.4.3 includes only a= big broad statement, but it's not clear which elements of label distri= bution protocols (i.e., BGP also seems missing here) are relevant to I2RS.<= br>

[Alia] BGP is already mentioned as a proto= col that will need an info-model. =A0I guess I think of this section as dis= cussing the transport LSPs and associated protocols as compared to the MPLS= services. =A0The MPLS services are part of routing and should be included = too. =A0I've changed the text in Sec 5.4.3 to read:

"The I2RS agent will need to interact with the pro= tocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well = as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.= g. pseudowires, L3VPNs,
L2VPNs, etc)."


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> 6.1. =A0Protocol Structure

=A0 =A0protocol. =A0That protocol may use several underlying transports (TC= P,
=A0 =A0SCTP, DCCP), with suitable authentication and integrity protection
CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP?

[Alia] There may be cases of data streams th= at don't require a reliable underlying transport. =A0I'm thinking a= bout providing statistics streams. =A0 I am concerned about the issues with= timely delivery that can arise with TCP - but I think that what transport = protocol is appropriate will depend a bit on what data is being delivered.<= /div>
=A0
Thanks again for the detailed review and questions,

Alia

Thanks,

-- Carlos.


On Jul 24, 2013, at 11:52 PM, Alia Atlas <akatlas@gmail.com> wrote:

> Please review draft-atlas-i2rs-architecture-01 and comment on whether = it should be adopted by I2RS. =A0Detailed technical conversation is also mo= st welcome.
>
> Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-arc= hitecture-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
> ________________________= _______________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


--089e0149ce5c5d962f04e3d8a1f1-- From akatlas@gmail.com Tue Aug 13 13:01:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1B321F9C6F for ; Tue, 13 Aug 2013 13:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z142xuJO+8i for ; Tue, 13 Aug 2013 13:01:51 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B166F21F9C55 for ; Tue, 13 Aug 2013 13:01:50 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so12106644oag.33 for ; Tue, 13 Aug 2013 13:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=stkbYjQJ0MNEp2IJQdzrcrNVqThqOH5X/KDaYR2MhYM=; b=0o/fD7THbBD3HWVt2Hw42RfAM7kC7xgwi3SV2ACR7zXdcedmGsZXmPBi91nU1tIK3A SHSAbowAWJt8hamXngtw1Mlea5tmQdx7TW9oIR29c24k6fwmGTM5ZJBaQCUvJY7RqK60 wt2sXmBjVXl8CoFmtoazEcw2tbmHC8j5D90cti3/gKwYlNG5o9dzQy1bayytnsaisQKS PkD80yJvX3E8kx5FLgYtUmJAfHJymSOGzCTEmXpxirIGoa0XXTolA3yMi9c5z+Jp2QyE IM/rViOZyqvwy+Re0tY/etGrCR+p0/Mtf4iGGquADLtlngF0Y8x1OSmC2xHRPketIRj3 OJHw== MIME-Version: 1.0 X-Received: by 10.60.80.8 with SMTP id n8mr5901714oex.33.1376424100669; Tue, 13 Aug 2013 13:01:40 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:01:40 -0700 (PDT) In-Reply-To: <51F8ED88.5050208@cisco.com> References: <51F8ED88.5050208@cisco.com> Date: Tue, 13 Aug 2013 16:01:40 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=089e0116067894ae7d04e3d9b51d Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:01:53 -0000 --089e0116067894ae7d04e3d9b51d Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Thanks for the detailed review and suggestions. Responses are in-line. Alia On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke wrote: > On 7/24/13 5:52 PM, Alia Atlas wrote: > > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > > should be adopted by I2RS. Detailed technical conversation is also most > > welcome. > > > > Authors: Are you aware of any IPR that applies to > > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > > more details). > > > > This WG call for adoption will complete on August 12. > > I support adoption, but I do have some comments below (see JMC) > > Section 1: > > The I2RS, and therefore this document, are specifically focused on an > interface for routing and forwarding data. > > JMC: Does an interface to the forwarding set the bar too broadly? > Should this instead be an interface to the layer 3 forwarding data? Do > we want to exclude this altogether in light of ForCES? > [Alia] Yes, I've removed the "and forwarding data". I do still think that there is forwarding data that might need to be read, but not written. > Section 1.2: > > As can also be seen in Figure 1, an I2RS Agent may communicate with > multiple clients. Each client may send the agent a variety of write > operations. The handling of this situation has been a source of > discussion in the working group. In order to keep the protocol > simple, the current view is that two clients should not be attempting > to write (modify) the same piece of information. Such collisions may > happen, but are considered error cases that should be resolved by the > network applications and management systems. > > JMC: I think more verbiage is needed around how to detect collisions. > This is key to security considerations. Saying "clients should not" is > not strong enough to keep our potential attackers. If each operation is > tagged with an identifier that is unique to a client, then it will be > possible to determine if the current client is trying to overwrite data > from a previous client. This could fold into authz as well where there > is a permission to allow global override of other application's state. > [Alia] For the I2RS Agent to properly handle a collision, it does need to store the client identifier. I think that is clear in Sec 5.2 "Simply, the I2RS agent stores who did what operation to which entity." and the details in Sec 6.8 are "The current recommendation is to have a simple priority associated with each I2RS clients, and the highest priority change remains in effect. In the case of priority ties, the first client whose attribution is associated with the data will keep control." We already have a reference to Sec 6.8 right there - and that section is where the details are discussed. What specific additional verbiage do you think would be useful? The priority is a knob to allow overwriting of other applications' state - though needing to is considered an error. :-) > Section 2: > > read scope: ... > > write scope: ... > > JMC: Should there be an event or notification scope in addition to read > and write? > [Alia] I think it is folded into the read scope. If we find the need for such a term later on, then we can add it. Section 3.4: > > I2RS clients may be operating on behalf of other applications. While > those applications' identities are not need for authorization, each > application should have a unique opaque identifier that can be > provided by the I2RS client to the I2RS agent for purposes of > tracking attribution of operations. > > JMC: The opaque ID might make it hard to accurately attribute changes. > I2RS should mandate a way to ensure traceability back to a client that > made the change or was granted access. > [Alia] What do you have in mind? The I2RS client will have a security role and its scope. The I2RS client needs to vet the applications that it is a broker for. The opaque ID can be something that is meaningful to that I2RS client. Basically, I2RS is providing the identity and security for between the I2RS client and the I2RS agent. I don't see it as practical or appropriate to try and define how the I2RS client and its applications interact; I know the broker/controller model is popular and so we do need enough to help support traceability to a secondary ID, but I'm not sure what is needed or appropriate beyond that. > Section 4.1: > > JMC: I found the text here a bit confusing and potentially overreaching > for the I2RS scope. I attempted to rewrite it. > > OLD: > > One example of such an application is a Topology Manager. Such an > application includes an I2RS client which uses the I2RS protocol to > collect information about the state of the network. The Topology > Manager would collect device and interface state from devices it > interacts with directly. It also collects routing configuration and > operation data from those devices. Most importantly, it collects > information about the routing system, including the contents of the > IGP (e.g. IS-IS or OSPF) and BGP data sets. This information is > provided to the I2RS client using the I2RS data models and protocols. > > The Topology Manager may be an integral part of an application. It > would build internal data structures, and use the collected data to > drive applications like path computations or anomalous routing > detection. Alternatively, the Topology manager could combine the > I2RS collected data with other information, abstract the result, and > provide a coherent picture of the network state over another > interface. That interface might use the same I2RS protocols, and > could use extensions of the I2RS data models. Developing such > mechanisms is outside the initial scope of the I2RS work. > > NEW: > > One example of such an application is a Topology Manager. A Topology > Manager includes an I2RS client that uses the I2RS data models and > protocol to collect information about the state of the network by > communicating directly with one or more I2RS agents. From these I2RS > agents, the Topology Manager collects routing configuration and > operational data. Most importantly, it collects information about the > routing system, including the contents of the IGP (e.g., IS-IS or OSPF) > and BGP data sets. > > The Topology Manager may be embedded as a component of a larger > application. It would construct internal data structures and use the > collected data to drive functions such as path computations or anomalous > routing detection. Alternatively, the Topology Manager could combine > the I2RS-collected data with other information, abstract a composite > set, and provide a coherent picture of the network state accessible via > another interface. That interface might use the same I2RS protocol and > could use extensions to the I2RS data models. Developing such > mechanisms is outside the initial scope of the I2RS work. > [Alia] Sure - thanks for the rewritten text. I don't find it significantly different in terms of its reach - but if you think it is clearer, I'm happy to update it. > Section 5.2.1: > > An I2RS client applies changes via the I2RS interface based on policy > and other application inputs... > > JMC: I2RS interface is redundant, perhaps I2RS protocol > [Alia] Sure - I2RS protocol is fine. > Section 5.2.2: > > An I2RS Agent may decide that some state should no longer be applied. > An I2RS Client may instruct an Agent to remove state it has applied. > In all such cases, the state will revert to what it would have been > without the I2RS; that state is generally whatever was specified via > the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple > alternative states, nor try to determine which one among such a > plurality it should fall back to. Thus, the model followed is not > like the RIB, where multiple routes are stored at different > preferences. > > JMC: Previously I had commented that one event that should be supported > and perhaps documented here is that if the agent decides to revert the > application can be notified that its state has been reverted. This > might also be useful if another client overrides some portion of another > client's state (this is covered in Section 6.8, but might be useful to > mention here as well). Perhaps add at the end of Section 5.2.2: > > "A client may choose to be notified whenever its state is reverted > either by another client or by the I2RS agent." > [Alia] I'll put in: "An I2RS Client may register for notifications when state that was applied by a particular I2RS Client is modified or removed." That is slightly different since it allows an I2RS Client to learn about the changes to state from itself or from a different I2RS Client. Section 5.4.2: > > (Bulleted list of examples) > > JMC: Consider adding an example for an event such as a new route being > learned or an OSPF neighbor removal. > [Alia] I think that "writing routes or prefixes to be advertised via the protocol" describes a new route being learned. I'd prefer not to put OSPF neighbor removal in as an example. It raises the questions about what is configuration vs. ephemeral data and the I2RS scope. If you have a good use-case that requires it, then I'd be quite interested in seeing it. > Section 5.4.4: > > Many network elements have separate policy and QoS mechanisms, > including knobs which affect local path computation and queue control > capabilities. These capabilities vary widely across implementations, > and I2RS cannot model the full range of information collection or > manipulation of these attributes. A core set does need to be > included in the I2RS data models and in the expected interfaces > between the I2RS Agent and the network element, in order to provide > basic capabilities and the hooks for future extensibility. > > JMC: I think this either needs an editor's note for more discussion or > perhaps QoS in general should be out of scope. > [Alia] I am happy to add in an editor's note for more discussion - but we should start that conversation now on the list - because the WG does have quite tight deadlines for milestones. > > Section 6.1: > > As a result, this architecture views the I2RS interface > as an interface supporting a single control and data exchange > protocol. > > JMC: Another instance of I2RS interface. > [Alia] Removed the interface - thanks. > Section 6.1: > > That protocol may use several underlying transports (TCP, > SCTP, DCCP), with suitable authentication and integrity protection > mechanisms. Whatever transport is used for the data exchange, it > must also support suitable congestion control mechanisms. > > JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP > is ideal for I2RS since we likely do want reliable order of delivery. > [Alia] Yes - DCCP is clearly the wrong choice for a control channel - but it may be good for delivering statistics. I think we'll have different transport options depending on the requirements of a particular data model or section. Since you are the second person to be confused by that section, I've added the following sentence: "These different transports can support different types of communication (e.g. control, reading, notifications, and information collection) and different sets of data." Let me know if that helps or if you have better ideas for wording. > Section 6.4: > > Each I2RS Client will have an identity; it can also have secondary > identities to be used for troubleshooting. > > JMC: Each application will have a _unique_ identity. > [Alia] Hmm, this ties into the discussion about how we want to handle redundancy and recovery for clients. It's also a bit of a tautology - a client is solely identified by its identity. I have changed it to say that "Each I2RS Client will have a unique identity" - but that just helps clarify the intent. > Section 6.5: > > JMC: Perhaps some normative language here to indicate a client may not > maintain a persistent connection, but they may choose to do so as well. > > OLD: > > A client does not need to maintain an active communication channel > with an agent. > > NEW: > > A client may not maintain... > [Alia] Changed to "A client may or may not maintain..." > Section 6.7: > > One of the other important aspects of the I2RS is that it is intended > to simplify collecting information about the state of network > elements. > > JMC: I think this needs to be more specific to routing information > versus any information from the network element (e.g., it does not cover > CPU statistics). > [Alia] The scoping is a question - and that will depend on what the use-cases we consider need and what the related information and data models need to be. If you look at the draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU load. I do think there is a real need to be able to get back thresholded and filtered information. You probably heard Ed's personal thoughts about a single protocol as well... So - I don't think the architecture needs to restrict the data in scope - particular in a section that is talking about communication patterns - but as a WG, we need to keep a tight focus that still provides sufficient information to fully solve the desired use-cases. Thanks again for your review and suggestions, Alia > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --089e0116067894ae7d04e3d9b51d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for the d= etailed review and suggestions. =A0Responses are in-line.

Alia

On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke <jclarke@cisco.com&= gt; wrote:
On 7/24/13 5:52 PM, Alia Atlas wrote:
> Please review draft-atlas-i2rs-architectu= re-01 and comment on whether it
> should be adopted by I2RS. =A0Detailed technical conversation is also = most
> welcome.
>
> Authors: Are you aware of any IPR that applies to
> draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed i= n
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for=
> more details).
>
> This WG call for adoption will complete on August 12.

I support adoption, but I do have some comments below (see JMC)=

Section 1:

The I2RS, and therefore this document, are specifically focused on an
interface for routing and forwarding data.

JMC: Does an interface to the forwarding set the bar too broadly?
Should this instead be an interface to the layer 3 forwarding data? =A0Do we want to exclude this altogether in light of ForCES?

[Alia] Yes, I've removed the "and forwarding data&= quot;. =A0I do still think that there is forwarding data that might need to= be read, but not written.=A0

=A0
Section 1.2:

As can also be seen in Figure 1, an I2RS Agent may communicate with
=A0 =A0multiple clients. =A0Each client may send the agent a variety of wri= te
=A0 =A0operations. =A0The handling of this situation has been a source of =A0 =A0discussion in the working group. =A0In order to keep the protocol =A0 =A0simple, the current view is that two clients should not be attemptin= g
=A0 =A0to write (modify) the same piece of information. =A0Such collisions = may
=A0 =A0happen, but are considered error cases that should be resolved by th= e
=A0 =A0network applications and management systems.

JMC: I think more verbiage is needed around how to detect collisions.
This is key to security considerations. =A0Saying "clients should not&= quot; is
not strong enough to keep our potential attackers. =A0If each operation is<= br> tagged with an identifier that is unique to a client, then it will be
possible to determine if the current client is trying to overwrite data
from a previous client. =A0This could fold into authz as well where there is a permission to allow global override of other application's state.<= br>

[Alia] For the I2RS Agent to properly h= andle a collision, it does need to store the client identifier. =A0I think = that is clear in Sec 5.2 "Simply, the I2RS agent stores who did=A0what operation to which entity." and the details= in Sec 6.8 are "The current recommendation is to=A0have a simple priority associated with each I2RS clients, an= d the=A0highest prior= ity change remains in effect. In the case of priority=A0ties, the first client whose attributio= n is associated with the data=A0will keep control." =A0We already have a reference to Sec 6= .8 right there - and that section is where the details are discussed. =A0Wh= at specific additional verbiage do you think would be useful? =A0 The prior= ity is a knob to allow overwriting of other applications' state - thoug= h needing to is considered an error. :-)
=A0
Section 2:

read scope: ...

write scope: ...

JMC: Should there be an event or notification scope in addition to read
and write?

[Alia] I think it is folded = into the read scope. =A0If we find the need for such a term later on, then = we can add it.

Section 3.4:

I2RS clients may be operating on behalf of other applications. =A0While
=A0 =A0those applications' identities are not need for authorization, e= ach
=A0 =A0application should have a unique opaque identifier that can be
=A0 =A0provided by the I2RS client to the I2RS agent for purposes of
=A0 =A0tracking attribution of operations.

JMC: The opaque ID might make it hard to accurately attribute changes= .
I2RS should mandate a way to ensure traceability back to a client that
made the change or was granted access.

= [Alia] What do you have in mind? =A0The I2RS client will have a security ro= le and its scope. =A0The I2RS client needs to vet the applications that it = is a broker for. =A0The opaque ID can be something that is meaningful to th= at I2RS client. =A0 Basically, I2RS is providing the identity and security = for between the I2RS client and the I2RS agent. =A0I don't see it as pr= actical or appropriate to try and define how the I2RS client and its applic= ations interact; I know the broker/controller model is popular and so we do= need enough to help support traceability to a secondary ID, but I'm no= t sure what is needed or appropriate beyond that.=A0
=A0
Section 4.1:

JMC: I found the text here a bit confusing and potentially overreaching
for the I2RS scope. =A0I attempted to rewrite it.

OLD:

One example of such an application is a Topology Manager. =A0Such an
=A0 =A0application includes an I2RS client which uses the I2RS protocol to<= br> =A0 =A0collect information about the state of the network. =A0The Topology<= br> =A0 =A0Manager would collect device and interface state from devices it
=A0 =A0interacts with directly. =A0It also collects routing configura= tion and
=A0 =A0operation data from those devices. =A0Most importantly, it collects<= br> =A0 =A0information about the routing system, including the contents of the<= br> =A0 =A0IGP (e.g. IS-IS or OSPF) and BGP data sets. =A0This information is =A0 =A0provided to the I2RS client using the I2RS data models and protocols= .

=A0 =A0The Topology Manager may be an integral part of an application. =A0I= t
=A0 =A0would build internal data structures, and use the collected data to<= br> =A0 =A0drive applications like path computations or anomalous routing
=A0 =A0detection. =A0Alternatively, the Topology manager could combine the<= br> =A0 =A0I2RS collected data with other information, abstract the result, and=
=A0 =A0provide a coherent picture of the network state over another
=A0 =A0interface. =A0That interface might use the same I2RS protocols, and<= br> =A0 =A0could use extensions of the I2RS data models. =A0Developing such
=A0 =A0mechanisms is outside the initial scope of the I2RS work.

NEW:

One example of such an application is a Topology Manager. =A0A Topology
Manager includes an I2RS client that uses the I2RS data models and
protocol to collect information about the state of the network by
communicating directly with one or more I2RS agents. =A0From these I2RS
agents, the Topology Manager collects routing configuration and
operational data. =A0Most importantly, it collects information about the routing system, including the contents of the IGP (e.g., IS-IS or OSPF)
and BGP data sets.

The Topology Manager may be embedded as a component of a larger
application. =A0It would construct internal data structures and use the
collected data to drive functions such as path computations or anomalous routing detection. =A0Alternatively, the Topology Manager could combine
the I2RS-collected data with other information, abstract a composite
set, and provide a coherent picture of the network state accessible via
another interface. =A0That interface might use the same I2RS protocol and could use extensions to the I2RS data models. =A0Developing such
mechanisms is outside the initial scope of the I2RS work.
<= div>
[Alia] Sure - thanks for the rewritten text. =A0I don= 9;t find it significantly different in terms of its reach - but if you thin= k it is clearer, I'm happy to update it.=A0

=A0
Section 5.2.1:

An I2RS client applies changes via the I2RS interface based on policy
=A0 =A0and other application inputs...

JMC: I2RS interface is redundant, perhaps I2RS protocol

[Alia] Sure - I2RS protocol is fine. =A0=A0

=
=A0
Section 5.2.2:

An I2RS Agent may decide that some state should no longer be applied.
=A0 =A0An I2RS Client may instruct an Agent to remove state it has applied.=
=A0 =A0In all such cases, the state will revert to what it would have been<= br> =A0 =A0without the I2RS; that state is generally whatever was specified via=
=A0 =A0the CLI, NetConf, SNMP, etc. =A0I2RS Agents will not store multiple<= br> =A0 =A0alternative states, nor try to determine which one among such a
=A0 =A0plurality it should fall back to. =A0Thus, the model followed is not=
=A0 =A0like the RIB, where multiple routes are stored at different
=A0 =A0preferences.

JMC: =A0Previously I had commented that one event that should be supported<= br> and perhaps documented here is that if the agent decides to revert the
application can be notified that its state has been reverted. =A0This
might also be useful if another client overrides some portion of another client's state (this is covered in Section 6.8, but might be useful to<= br> mention here as well). =A0Perhaps add at the end of Section 5.2.2:

=A0 "A client may choose to be notified whenever its state is reverted=
either by another client or by the I2RS agent."
<= br>
[Alia] I'll put in: "An I2RS Client may register for= notifications when state that was
applied by a particular I2RS Client i= s modified or removed." =A0That is slightly different since it allows = an I2RS Client to learn about the changes to state from itself or from a di= fferent I2RS Client. =A0

Section 5.4.2:

(Bulleted list of examples)

JMC: Consider adding an example for an event such as a new route being
learned or an OSPF neighbor removal.

[A= lia] I think that "writ= ing routes or prefixes to be advertised via the protocol" describes a = new route being learned. =A0 I'd prefer not to put OSPF neighbor remova= l in as an example. =A0It raises the questions about what is configuration = vs. ephemeral data and the I2RS scope. =A0If you have a good use-case that = requires it, then I'd be quite interested in seeing it. =A0=A0

=A0
Section 5.4.4:

Many network elements have separate policy and QoS mechanisms,
=A0 =A0including knobs which affect local path computation and queue contro= l
=A0 =A0capabilities. =A0These capabilities vary widely across implementatio= ns,
=A0 =A0and I2RS cannot model the full range of information collection or =A0 =A0manipulation of these attributes. =A0A core set does need to be
=A0 =A0included in the I2RS data models and in the expected interfaces
=A0 =A0between the I2RS Agent and the network element, in order to provide<= br> =A0 =A0basic capabilities and the hooks for future extensibility.

JMC: I think this either needs an editor's note for more discussion or<= br> perhaps QoS in general should be out of scope.

[Alia] I am happy to add in an editor's note for more discussio= n - but we should start that conversation now on the list - because the WG = does have quite tight deadlines for milestones. =A0
=A0

Section 6.1:

As a result, this architecture views the I2RS interface
=A0 =A0as an interface supporting a single control and data exchange
=A0 =A0protocol.

JMC: Another instance of I2RS interface.

[Alia] Removed the interface - thanks.=A0

=A0
Section 6.1:

That protocol may use several underlying transports (TCP,
=A0 =A0SCTP, DCCP), with suitable authentication and integrity protection
=A0 =A0mechanisms. =A0Whatever transport is used for the data exchang= e, it
=A0 =A0must also support suitable congestion control mechanisms.

JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP<= br> is ideal for I2RS since we likely do want reliable order of delivery.
=A0
[Alia] Yes - DCCP is clearly the wrong choice= for a control channel - but it may be
good for delivering statis= tics. =A0 I think we'll have different transport options depending on t= he requirements of a particular data model or section. =A0Since you are the= second person to be confused by that section, I've added the following= sentence:

"These different transports can support different = types of
communication (e.g. control, reading, notifications, and= information
collection) and different sets of data."

=A0Let me know if that helps or if you have better idea= s for wording.


Section 6.4:

Each I2RS Client will have an identity; it can also have secondary
=A0 =A0identities to be used for troubleshooting.

JMC: Each application will have a _unique_ identity.
<= br>
[Alia] Hmm, this ties into the discussion about how we want t= o handle redundancy and recovery for clients. =A0 It's also a bit of a = tautology - a client is solely identified by its identity. =A0 =A0I have ch= anged it to say that "Each I2RS Client will have a unique identity&quo= t; - but =A0that just helps clarify the intent.
=A0
Section 6.5:

JMC: Perhaps some normative language here to indicate a client may not
maintain a persistent connection, but they may choose to do so as well.

OLD:

A client does not need to maintain an active communication channel
=A0 =A0with an agent.

NEW:

A client may not maintain...

[Alia] Cha= nged to "A client may or may not maintain..."=A0

=A0
Section 6.7:

One of the other important aspects of the I2RS is that it is intended
=A0 =A0to simplify collecting information about the state of network
=A0 =A0elements.

JMC: I think this needs to be more specific to routing information
versus any information from the network element (e.g., it does not cover CPU statistics).

[Alia] The scoping is = a question - and that will depend on what the use-cases we consider need an= d what the related information and data models need to be. =A0If you look a= t the draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU= load. =A0I do think there is a real need to be able to get back thresholde= d and filtered information. =A0You probably heard Ed's personal thought= s about a single protocol as well... =A0 So - I don't think the archite= cture needs to restrict the data in scope - particular in a section that is= talking about communication patterns - but as a WG, we need to keep a tigh= t focus that still provides sufficient information to fully solve the desir= ed use-cases.

Thanks again for your review and suggestions,
Alia=A0
=A0
Joe

--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--089e0116067894ae7d04e3d9b51d-- From akatlas@gmail.com Tue Aug 13 13:06:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C9411E81A7 for ; Tue, 13 Aug 2013 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAOJoZgKs3vO for ; Tue, 13 Aug 2013 13:06:39 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 332B311E81B7 for ; Tue, 13 Aug 2013 13:06:27 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so7292296oag.19 for ; Tue, 13 Aug 2013 13:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mOlYRkiYFHM8o3CU5ftnWa0EHg3vwNCE9YAnMDXZJLc=; b=pK+jgkvqGxEitvAsWVmmw5vQJJC1/PR5jaI0L1rNMGffw+TmRf/whNxfOp3nRaMM7g hq2WbIgfEmES+3v7VwfQx5jHTfuosA4quEF3aTBhHVAyGZx0eJJJ+rapzu9OLhqwn4D4 TdlOn6VxVBj/vZkfSQXIHe111b3192HV/AkFeDWiUu9/zWFzlnsFZboI170azulQB60s 7a3HvUmriJnZ5O6jX+lt/VkcfHGfPv2FRBgIAdPfYqkfafM37U31qhcNjrMs8+aq2Op9 kcNL0jMEX9ZuIPAI3kj6ljViayVnRLwsEsVxFfnJ9F8/rmnSnBEUvIP56wnAHLP0ZUHT o7Iw== MIME-Version: 1.0 X-Received: by 10.60.80.8 with SMTP id n8mr5926755oex.33.1376424385112; Tue, 13 Aug 2013 13:06:25 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:06:24 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> References: <51F8ED88.5050208@cisco.com> <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> Date: Tue, 13 Aug 2013 16:06:24 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=089e0116067888f73004e3d9c678 Cc: "i2rs@ietf.org" , "Joe Clarke \(jclarke\)" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:06:41 -0000 --089e0116067888f73004e3d9c678 Content-Type: text/plain; charset=ISO-8859-1 in-line as ever On Wed, Jul 31, 2013 at 7:14 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > > On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke wrote: > > Section 2: > > read scope: ... > > write scope: ... > > JMC: Should there be an event or notification scope in addition to read > and write? > > > +1 to this point. I think that it should also include some words about > pub/sub. > [Alia] I think about the read scope as including the event or notification scope - at least unless and until we have to have the extra complexity of terminology. I don't see where or why read scope and notification scope need to be separate concepts?? > Section 6.6 covers some of this though, so perhaps a forward reference. > [Alia] In the terminology section?? If we needed notification scope, ok - but I don't see an argument for it to be separated... Alia > Thanks, > > -- Carlos. > --089e0116067888f73004e3d9c678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
in-line as ever

On Wed, Jul 31, 2013 at 7:14 AM, Carlos Pignataro (cpignat= a) <cpignata@cisco.com> wrote:
=A0
Section 6.6 covers some of this though, so perhaps a forward ref= erence.

[Alia] In the terminology sect= ion?? =A0If we needed notification scope, ok - but I don't see an argum= ent for it to be separated...
=A0
Alia


Thanks,

-- Carlos.

--089e0116067888f73004e3d9c678-- From akatlas@gmail.com Tue Aug 13 13:11:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACB711E81B7 for ; Tue, 13 Aug 2013 13:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn4TxRNnsRVJ for ; Tue, 13 Aug 2013 13:11:49 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D739A11E81B4 for ; Tue, 13 Aug 2013 13:11:48 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so7447383oag.11 for ; Tue, 13 Aug 2013 13:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yL3GgIHwUu92bpC6iwxC4sR/umC/ykSo1gAP3xZtSV4=; b=eSChpT8dpRzecTeVmkqGdAUtQgwxvmMXQzoGnYkXNhmyyDULKINRSwtoILoOaJMGyX q89d1HJaMS34srRaq1hDr67NLg8Bl+bsfP9T2Wm6DzDCMERVTzPWQaLoUwDQnbXoZVV8 eVR7AedtKFO9QGuL3qC3DpgEw499LgXk27ugOKq9kEeR1lVuS/qNrYPLVCq6v1whv+eG Ze+G+ENzCHJUVCmnIvdF/C38pvYLjxF8ucBh5KPqwhB3L0xljoqK9rhhv4X3HkLtTWk0 UK2F1/tc7t5fW01dIYF/h2r2CueQwd+yOmqplJezgA04WOJyKMlF1U4XzJtoSgATNRNQ zpbA== MIME-Version: 1.0 X-Received: by 10.60.95.99 with SMTP id dj3mr1803963oeb.94.1376424708363; Tue, 13 Aug 2013 13:11:48 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:11:48 -0700 (PDT) In-Reply-To: References: <51F8ED88.5050208@cisco.com> <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> Date: Tue, 13 Aug 2013 16:11:48 -0400 Message-ID: From: Alia Atlas To: KwangKoog Lee Content-Type: multipart/alternative; boundary=089e01228288cd7e8d04e3d9d907 Cc: "Carlos Pignataro \(cpignata\)" , "Joe Clarke \(jclarke\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:11:49 -0000 --089e01228288cd7e8d04e3d9d907 Content-Type: text/plain; charset=ISO-8859-1 Hi KwangKoog Lee, I do hear your concern about the transport and congestion control. Different DSCPs may make sense for the I2RS protocol; the control part with write operations makes sense to have at a high priority. However, getting the RIB updates as an information stream may not want to have the same priority. Congestion control is likely to be needed to handle congested situations that may occur. For instance, consider how I2RS and BGP should interact in terms of QoS. I do have concerns about the head-of-line blocking that happens with TCP given congestion, but I think there are both other transports and that multiple transport channels can be used. Thanks, Alia On Thu, Aug 1, 2013 at 4:24 AM, KwangKoog Lee wrote: > I also support WG adoption and agree with other members' comments. > Also, I have a small comment about the Sec. 6.1. > > "Whatever transport is used for the data exchange, it must also support > suitable congestion control mechanisms." > > Instead of this sentence, I think it needs to mention that I2RS protocol > messages must be treated by the highest proirity even if the control > network is under a congestion situation so that the communication is very > highly reliable between I2RS client and I2RS agent. > I think congestion control is little bit risky to I2RS operation because > those messages have very impotant information and also problem > statement document already mentions that responsiveness and reliability of > i2rs is important. > Thanks. > > Sincerely, > Kwnag-koog Lee (Ph.D) > KT (Korea Telecom) > > > On Wed, Jul 31, 2013 at 8:14 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> >> On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke >> wrote: >> >> Section 2: >> >> read scope: ... >> >> write scope: ... >> >> JMC: Should there be an event or notification scope in addition to read >> and write? >> >> >> +1 to this point. I think that it should also include some words about >> pub/sub. >> >> Section 6.6 covers some of this though, so perhaps a forward reference. >> >> Thanks, >> >> -- Carlos. >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --089e01228288cd7e8d04e3d9d907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi KwangKoog Lee,

I do hear your concer= n about the transport and congestion control. =A0Different DSCPs may make s= ense for the I2RS protocol; the control part with write operations makes se= nse to have at a high priority. =A0 However, getting the RIB updates as an = information stream may not want to have the same priority. =A0
Congestion control is likely to be needed to handle congested situatio= ns that may occur. =A0For instance, consider how I2RS and BGP should intera= ct in terms of QoS.

I do have concerns about the h= ead-of-line blocking that happens with TCP given congestion, but I think th= ere are both other transports and that multiple transport channels can be u= sed.

Thanks,
Alia


On Thu, Aug 1, 2013 at 4:24 AM, Kw= angKoog Lee <kwangkooglee@gmail.com> wrote:
I also support WG adop= tion and agree with other members' comments.
Also, I have a s= mall comment about the Sec. 6.1.
=A0
"Whatever transport is used for t= he data exchange, it must also support suitable congestion control mechanis= ms."
=A0
Instead of this sentence, I think it needs to ment= ion that I2RS protocol messages=A0must be treated by the highest proirity e= ven if the control network is under a congestion situation so that the comm= unication is very highly reliable between I2RS client and I2RS agent.
I think congestion control is little bit risky to I2RS operation becau= se those messages have very impotant information and also problem statement= =A0document already mentions that responsiveness and reliability of i2rs is= important.
Thanks.
=A0
Sincerely,
Kwnag-koog Lee (= Ph.D)
KT (Korea Telecom)

On Wed, Jul 31, 201= 3 at 8:14 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke <jclarke@cisco.com> w= rote:

Section 2:

read sco= pe: ...

write scope: ...

JMC: Shoul= d there be an event or notification scope in addition to read
and write?

+1 to this poi= nt. I think that it should also include some words about pub/sub.=A0
<= div>
Section 6.6 covers some of this though, so perhaps a for= ward reference.

Thanks,

-- Carlos.
=
_________________________________________= ______
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--089e01228288cd7e8d04e3d9d907-- From akatlas@gmail.com Tue Aug 13 13:26:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D41711E81C7 for ; Tue, 13 Aug 2013 13:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF6KRbpd6rFZ for ; Tue, 13 Aug 2013 13:26:42 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 86C5211E81C3 for ; Tue, 13 Aug 2013 13:26:24 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id ta17so10808857obb.4 for ; Tue, 13 Aug 2013 13:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=70ZFD6fyomE2a0CJvZDaZABskIbgpaaSMYq86puCvKA=; b=Ojpqba8IhfA4P73FT16MZzFKVcTjfv3MIf6IIYBC6mXfBmukP2AMhj/1FLRuLoNCaT MT/DQ8KGN5wtjvZP9RBLASqafdHWNX9mpcUKj1O0sd+CAZYGbIwCg6ehrp+CTQ8QwUP4 VOoZ06G75xNGm1YfYkOn4XjviPMGkEobC82vjRzAslZoXfyDqpNHgtDvdj6rzJa5y6IN 2Y7GSOJz69lUCV6+uSpFltQEwobz84/8/kv1FZE5nfNrD/+wZApBjqHltRfVJJ4bK6be U0zG7y/kGcEUC4puz15gkPL9dZ1WCztVdA9rramQ0Ne5Ed0HSDic7sDcFYpQz5uGc28o PSSA== MIME-Version: 1.0 X-Received: by 10.182.214.98 with SMTP id nz2mr5548098obc.37.1376425584001; Tue, 13 Aug 2013 13:26:24 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:26:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 16:26:23 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=e89a8ff1cefefe944e04e3da0d39 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:26:46 -0000 --e89a8ff1cefefe944e04e3da0d39 Content-Type: text/plain; charset=ISO-8859-1 Hi Jamal, Thanks for your comments. Responses in-line. Alia On Thu, Aug 1, 2013 at 5:07 AM, Jamal Hadi Salim wrote: > I have the draft and support its adoption. > > Some comments: > 1) ForCES model can support different levels of granularities. Yes, > original intent > was to do datapath control-southbound interfaces; but it is very usable in > wide > range of applications that desire a model. Example, if you attended the > ForCES > meeting you may have seen a demo where ForCES was used to model VMs > doing arbitrary network functions where the ForCES was then used to > orchestrate > that infrastructure. > [Alia] You have been talking about ForCES as being applicable for quite a while. It would be interesting to read a draft that does the compare/contrast for I2RS as well as the data-model for the RIB info model. There are also concerns about duplicating data models in different technologies and issues around tool-chain availability and automation. > 2) I think we may end up needing more clarity on the transport. Merely > saying > you'd use congestion-aware transport and spelling out desire for different > levels of reliability is insufficient. An I2RS agent is a proxy; > reliability and congestion > control need to take into consideration those two requirements above the > transport layer. > [Alia] Yes, the transport needed depends on the communication pattern being used and that ties to the data-models as well. I think we need a protocol requirements draft that describes some of this in more detail. I have the idea that I2RS would have a default transport - and then some information streams may only be available over a different transport channel - or the client could request data across a different transport channel and so on. > 3) identity/roles > It would be useful to specify some sample space of common practise. > [Alia] Sure - I think this has to come out of the security space. I've heard suggestions about looking at the NetConf Access Control Model (RFC6536). I believe that Wes George was looking at some ideas and there were a number of security-related folks interested at the WG meeting. Regards, Alia > cheers, > jamal > > On Wed, Jul 24, 2013 at 5:52 PM, Alia Atlas wrote: > > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > > should be adopted by I2RS. Detailed technical conversation is also most > > welcome. > > > > Authors: Are you aware of any IPR that applies to > > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more > > details). > > > > This WG call for adoption will complete on August 12. > > > > Thanks, > > Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --e89a8ff1cefefe944e04e3da0d39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jamal,

Thanks for your comments. =A0= Responses in-line.

Alia

On Thu, Aug 1, 2013 at 5:07 AM, Jamal Hadi Salim <hadi@= mojatatu.com> wrote:
I have the draft and support its adoption.
Some comments:
1) ForCES model can support different levels of granularities. Yes,
original intent
was to do datapath control-southbound interfaces; but it is very usable in = wide
range of applications that desire a model. Example, if you attended the For= CES
meeting you may have seen a demo where ForCES was used to model VMs
doing arbitrary network functions where the ForCES was then used to orchest= rate
that infrastructure.

[Alia] You have be= en talking about ForCES as being applicable for quite a while. =A0It would = be interesting to read a draft that does the compare/contrast for I2RS as w= ell as the data-model for the RIB info model. =A0 There are also concerns a= bout duplicating data models in different technologies and issues around to= ol-chain availability and automation.
=A0
2) I think we may end up needing more clarity on the transport. Merely sayi= ng
you'd use congestion-aware transport and spelling out desire for differ= ent
levels of reliability is insufficient. An I2RS agent is a proxy;
reliability and congestion
control need to take into consideration those two requirements above the transport layer.

[Alia] Yes, the transp= ort needed depends on the communication pattern being used and that ties to= the data-models as well. =A0I think we need a protocol requirements draft = that describes some of this in more detail. =A0I have the idea that I2RS wo= uld have a default transport - and then some information streams may only b= e available over a different transport channel - or the client could reques= t data across a different transport channel and so on.=A0
=A0
3) identity/roles
It would be useful to specify some sample space of common practise.

[Alia] Sure - I think this has to come out of = the security space. =A0I've heard suggestions about looking at the NetC= onf Access Control Model (RFC6536). =A0I believe that Wes George was lookin= g at some ideas and there were a number of security-related folks intereste= d at the WG meeting.

Regards,
Alia
=A0
cheers,
jamal

On Wed, Jul 24, 2013 at 5:52 PM, Alia Atlas <akatlas@gmail.com> wrote:
> Please review draft-atlas-i2rs-architecture-01 and comment on whether = it
> should be adopted by I2RS. =A0Detailed technical conversation is also = most
> welcome.
>
> Authors: Are you aware of any IPR that applies to
> draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed i= n
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for= more
> details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

--e89a8ff1cefefe944e04e3da0d39-- From akatlas@gmail.com Tue Aug 13 13:45:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0D821F9F45 for ; Tue, 13 Aug 2013 13:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+xUKDOL4Jai for ; Tue, 13 Aug 2013 13:45:09 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4663521F9F3A for ; Tue, 13 Aug 2013 13:45:09 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so9959726obc.31 for ; Tue, 13 Aug 2013 13:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HsS1ubWmnXLEqBGrx6U11MJAdsah73W3zEefi3nSXyo=; b=LdiFY6zBIK8ccGhv+FiHRA89KaBi+JQBSSyPGNvV0xtW673HQSuZKsZ4j7uPZik9x6 sm5g3q3aVop6scILMEIehBwMgoFvKYiMVJdieahmU7b0so+HNMudyWFC7j++osUVVzQg Hs5joRjzbLOlJEC2/cyUaW+HmlX9iThwE5S4PjVIIRL2tduyA/Dw2fJHDUWT/2NShKOL aHuTIC9aPVFIRBqYBs+HZofWZNzM25V1ZamdSpHcW4GVU9rWt7N6rqOwe25tcXRVRTuk i5m44xxGnMV1uwz57P4ur/BUtBWBUk8tDlyrDkgFG2uhXtNz1B5Xy3kALDmmRoLD4zhR s8PQ== MIME-Version: 1.0 X-Received: by 10.182.76.38 with SMTP id h6mr2382147obw.74.1376426708818; Tue, 13 Aug 2013 13:45:08 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:45:08 -0700 (PDT) In-Reply-To: <20130801120229.GB25597@elstar.local> References: <20130801120229.GB25597@elstar.local> Date: Tue, 13 Aug 2013 16:45:08 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7b4503ca09dfdd04e3da5113 Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:45:10 -0000 --047d7b4503ca09dfdd04e3da5113 Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen, Thanks for the comments and review. Responses are in-line. Alia On Thu, Aug 1, 2013 at 8:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I have a few comments on draft-atlas-i2rs-architecture-01 I like to > share. Overall, I found the document clearly written and well worked > out. > > a) I suggest to remove the last two paragraphs from section 1.1 (the > paragraphs that try to make a statement that SNMP, NETCONF, and > ForCES do not work for i2rs). > > Rationale: This is an architectural document and it does not need > to explain why certain protocols may not work as i2rs protocols. It > is not the job of this document - so simply avoid discussions > around this by removing these two paragraphs. > [Alia] Sure - I'd tried to trim it down a lot and avoid protocol bashing, but am happy to remove it. > b) Is it necessary to describe an example in the middle of the > architecture document, given that there is a separate use cases > document? My suggestion would be to simply remove section 4.1 (and > perhaps consider merging the text left in section 4 into some of > the other sections). > [Alia] I can certainly understand how that section seems a bit odd. However, the topology manager is a key focus point and use-case for I2RS - and it is important architecturally to clarify the initial scope of I2RS in the context of that use-case. Certainly, those are the two reasons that we put the section in there. Similarly, we have bits of what might be info-models to give a sense of what architecturally is in scope. > c) In section 6.9, I suggest to rename 'Perform all' to 'Perform all > ignoring errors' or something like that which better highlights the > behaviour. > [Alia] Sure - renamed to "Perform all storing errors" > Editorial: I think the NETCONF community has settled on spelling > NETCONF as NETCONF, not as NetConf. [Alia] Sure - made the change. Thanks again, Alia > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b4503ca09dfdd04e3da5113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

Thanks for the comments and= review. =A0Responses are in-line.

Alia=

On Thu, Aug 1, 2013 at 8:02 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
Hi,

I have a few comments on draft-atlas-i2rs-architecture-01 I like to
share. Overall, I found the document clearly written and well worked
out.

a) I suggest to remove the last two paragraphs from section 1.1 (the
=A0 =A0paragraphs that try to make a statement that SNMP, NETCONF, and
=A0 =A0ForCES do not work for i2rs).

=A0 =A0Rationale: This is an architectural document and it does not need =A0 =A0to explain why certain protocols may not work as i2rs protocols. It<= br> =A0 =A0is not the job of this document - so simply avoid discussions
=A0 =A0around this by removing these two paragraphs.
<= br>
[Alia] Sure - I'd tried to trim it down a lot and avoid p= rotocol bashing, but am happy to remove it.
=A0
b) Is it necessary to describe an example in the middle of the
=A0 =A0architecture document, given that there is a separate use cases
=A0 =A0document? My suggestion would be to simply remove section 4.1 (and =A0 =A0perhaps consider merging the text left in section 4 into some of
=A0 =A0the other sections).

[Alia] I ca= n certainly understand how that section seems a bit odd. =A0However, the to= pology manager is a key focus point and use-case for I2RS - and it is impor= tant architecturally to clarify the initial scope of I2RS in the context of= that use-case. =A0Certainly, those are the two reasons that we put the sec= tion in there. =A0Similarly, we have bits of what might be info-models to g= ive a sense of what architecturally is in scope.
=A0
c) In section 6.9, I suggest t= o rename 'Perform all' to 'Perform all
=A0 =A0ignoring errors' or something like that which better highlights = the
=A0 =A0behaviour.
[Alia] Sure - renamed to "Perfo= rm all storing errors"
=A0
Editorial: I think the NETCONF community has settled on spelling
=A0 =A0 =A0 =A0 =A0 =A0NETCONF as NETCONF, not as NetConf.

[Alia] Sure - made the change.

Tha= nks again,
Alia=A0

=A0
/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b4503ca09dfdd04e3da5113-- From akatlas@gmail.com Tue Aug 13 13:58:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC71421E8162 for ; Tue, 13 Aug 2013 13:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu3FIQkC+WLw for ; Tue, 13 Aug 2013 13:58:01 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4331E21E8159 for ; Tue, 13 Aug 2013 13:58:01 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so11117759obb.30 for ; Tue, 13 Aug 2013 13:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bGw9sA3RAQNeLdACQSd2AEimdtfxSp5gAqC/eTPhizU=; b=cLwIyq1H3upP1dH/hJGq5wIbh9WT5bcPhc0wTZbrXEe7ndJFxPJzoK4nhwTZGpYIm+ vX2OzyuYhgAlSDPv01hOIeW4QfmfcPaNW9zCeYF5oHpq+C9QGu6whCDtUXqYQMZrrJuc CPY0HySuNBdRFd6kQG5Gj/PfO7BkNc+I+Y0vl+OkKjDORQRL2n1jQvpWS4kPzqfipP4O TY9KG6SJKyrpNLsx9zCB8lfmOPRYLNJDNxiFVdy83MN+k7sYucsB+o+vReUSnBRSV68A feN2zmsqXdbl2TkVbC7igmaCtYaaTkyVB+nNdKrobC8fKUjs/jtAodnZqWMCPjeIdkap Yn4A== MIME-Version: 1.0 X-Received: by 10.60.51.41 with SMTP id h9mr6214882oeo.49.1376427480758; Tue, 13 Aug 2013 13:58:00 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 13:58:00 -0700 (PDT) In-Reply-To: <51FAEF39.9020102@cisco.com> References: <51FA492D.3070402@labn.net> <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> <51FAEF39.9020102@cisco.com> Date: Tue, 13 Aug 2013 16:58:00 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a11c300da0cc32e04e3da7f3f Cc: "i2rs@ietf.org" , Joel Halpern , "lberger@labn.net" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:58:02 -0000 --001a11c300da0cc32e04e3da7f3f Content-Type: text/plain; charset=ISO-8859-1 I am going to publish an updated version of draft-atlas-i2rs-architecture without fully addressing this point. I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 Identity and Security Role that says: "I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such. Since I2RS does not require a continuous transport connection and supports multiple transport sessions, this can provide some basic redundancy. However, it does not address concerns for troubleshooting and accountability about knowing which network application is actually active. At a minimum, basic transport information about each connection and time can be logged with the identity. Further discussion is necessary to determine whether additional client identification information is necessary.[[Editor's note: This requires more discussion in the working group.]]" Alia On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke wrote: > On 8/1/13 11:19 AM, Alia Atlas wrote: > > Joe, > > > > Ok - so what I hear from you is needed is the > > client role > > client identity > > sub-client identity? > > > > Where the permissions and ownership of state is tied to the client role? > > Does that match to what you are saying? I believe we're assuming that > > the ownership of state is tied to the client identity - and you are > > suggesting that if so, we need a client sub-identity or such? > > Yes, I think that is in line with what I'm suggesting. If we can allow > Client A to assume the identity of Client B using the same credentials, > I would want some way to know that this is indeed Client B now acting on > behalf of either itself or some northbound controller. > > Joe > > > > > Alia > > > > > > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke > > wrote: > > > > On 8/1/13 11:11 AM, Joel Halpern wrote: > > > The client is the entity that is authenticated and authorized. If > the > > > client is acting on behalf of someone else, we assume that the > > > authentication and authorization of that party is the task of the > > client > > > and outside our scope. However we include that identity so that > > actions > > > can be easily correlated with originators. > > > > Right. I get that. I had thought we were talking about two clients > > that might be redundant to each other where Client 1 dies and Client > 2 > > assumes its identity to make changes possibly driven by northbound > > actors. Even in this case, I feel Client 2 still needs to maintain a > > unique identification to the I2RS agent so that one can trace the > > operation back to the specific I2RS client (in addition to the > > northbound actor). > > > > Joe > > > > > > > > Yours, > > > Joel > > > > > > Sent from my Android phone using TouchDown (www.nitrodesk.com > > ) > > > > > > -----Original Message----- > > > *From:* Joe Marcus Clarke [jclarke@cisco.com > > ] > > > *Received:* Thursday, 01 Aug 2013, 17:07 > > > *To:* Alia Atlas [akatlas@gmail.com ] > > > *CC:* Lou Berger [lberger@labn.net ]; > > i2rs@ietf.org [i2rs@ietf.org > > ]; Joel > > > Halpern [joel.halpern@ericsson.com joel.halpern@ericsson.com>] > > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault > Tolerance > > > in draft-atlas-i2rs-architecture-01 > > > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > > >> Not to answer for Joel, but my view is that a client is > identified by > > >> its identity. A different application can take over from the > > first by > > >> using the same identity. Loss of a transport session does not > cause > > >> existing client state to be removed (in the architecture) - so > > there is > > >> the ability for a new application to take over. > > >> > > >> Does that help? > > > > > > That worries me without more discussion about authentication. > > > Additionally, from a troubleshooting standpoint, if I can assume > the > > > same identity as another client, how can I be absolutely sure which > > > client does what to the agent? I feel there needs to be more to > > ensure > > > accountability of what client does what, certainly from a security > > > perspective, but also from a troubleshooting perspective. > > > > > > Joe > > > > > >> > > >> Alia > > >> > > >> > > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > > > >> >> wrote: > > >> > > >> Hi Joel, > > >> In today's session, I asked about provisions in the > > architecture > > >> (document) for Client Redundancy/Fault Tolerance. I believe > > you stated > > >> that "it's not needed" and that you'd elaborate on the list. > > >> > > >> I believe you also answered a latter question by stating that > > clients > > >> are free to coordinate between themselves to provide > > redundancy. Is this > > >> the simple answer? If not, can you elaborate? > > >> > > >> Thanks, > > >> Lou > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > > > > > > > > -- > > > Joe Marcus Clarke, CCIE #5384, | | > > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > > Phone: +1 (919) 392-2867 > > c i s c o S y s t e m s > > > Email: jclarke@cisco.com > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --001a11c300da0cc32e04e3da7f3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am going to publish an updated version of draft-atlas-i2= rs-architecture without fully addressing this point.

I d= id add in a new subsection (6.4.1 Client Redundancy) under 6.4 Identity and= Security Role that says:

"I2RS must support client redundancy. =A0At the si= mplest, this can be
handled by having a primary and a backup netw= ork application that both
use the same client identity and can su= ccessfully authenticate as
such. =A0Since I2RS does not require a continuous transport connection=
and supports multiple transport sessions, this can provide some = basic
redundancy. =A0However, it does not address concerns for tr= oubleshooting
and accountability about knowing which network application is actually=
active. =A0At a minimum, basic transport information about each<= /div>
connection and time can be logged with the identity. =A0Further
discussion is necessary to determine whether additional client
identification information is necessary.[[Editor's
note: T= his requires more discussion in the working group.]]"

Alia


On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke <jclarke= @cisco.com> wrote:
On 8/1/13 11:19 AM, Alia A= tlas wrote:
> Joe,
>
> Ok - so what I hear from you is needed is the
> =A0 =A0client role
> =A0 =A0client identity
> =A0 =A0sub-client identity?
>
> Where the permissions and ownership of state is tied to the client rol= e?
> =A0Does that match to what you are saying? =A0I believe we're assu= ming that
> the ownership of state is tied to the client identity - and you are > suggesting that if so, we need a client sub-identity or such?

Yes, I think that is in line with what I'm suggesting. =A0If we c= an allow
Client A to assume the identity of Client B using the same credentials,
I would want some way to know that this is indeed Client B now acting on behalf of either itself or some northbound controller.

Joe

>
> Alia
>
>
> On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke &= lt;jclarke@cisco.com
> <mailto:jclarke@cisco.com>> wrote:
>
> =A0 =A0 On 8/1/13 11:11 AM, Joel Halpern wrote:
> =A0 =A0 > The client is the entity that is authenticated and author= ized. If the
> =A0 =A0 > client is acting on behalf of someone else, we assume tha= t the
> =A0 =A0 > authentication and authorization of that party is the tas= k of the
> =A0 =A0 client
> =A0 =A0 > and outside our scope. However we include that identity s= o that
> =A0 =A0 actions
> =A0 =A0 > can be easily correlated with originators.
>
> =A0 =A0 Right. =A0I get that. =A0I had thought we were talking about t= wo clients
> =A0 =A0 that might be redundant to each other where Client 1 dies and = Client 2
> =A0 =A0 assumes its identity to make changes possibly driven by northb= ound
> =A0 =A0 actors. =A0Even in this case, I feel Client 2 still needs to m= aintain a
> =A0 =A0 unique identification to the I2RS agent so that one can trace = the
> =A0 =A0 operation back to the specific I2RS client (in addition to the=
> =A0 =A0 northbound actor).
>
> =A0 =A0 Joe
>
> =A0 =A0 >
> =A0 =A0 > Yours,
> =A0 =A0 > Joel
> =A0 =A0 >
> =A0 =A0 > Sent from my Android phone using TouchDown (www.nitrodesk.com
> =A0 =A0 <http://www.nitrodesk.com>)
> =A0 =A0 >
> =A0 =A0 > -----Original Message-----
> =A0 =A0 > *From:* Joe Marcus Clarke [jclarke@cisco.com
> =A0 =A0 <mailto:jclarke@= cisco.com>]
> =A0 =A0 > *Received:* Thursday, 01 Aug 2013, 17:0= 7
> =A0 =A0 > *To:* Alia Atlas [akatlas@gmail.com <mailto:a= katlas@gmail.com>]
> =A0 =A0 > *CC:* Lou Berger [lbe= rger@labn.net <mailto:lberger@la= bn.net>];
> =A0 =A0 i2rs@ietf.org <mailto:= i2rs@ietf.org> [i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;]; Joel
> =A0 =A0 > Halpern [joe= l.halpern@ericsson.com <mailto:joel.halpern@ericsson.com>]
> =A0 =A0 > *Subject:* Re: [i2rs] Provisions for Cl= ient Redundancy/Fault Tolerance
> =A0 =A0 > in draft-atlas-i2rs-architecture-01
> =A0 =A0 >
> =A0 =A0 > On 8/1/13 7:51 AM, Alia Atlas wrote:
> =A0 =A0 >> Not to answer for Joel, but my view is that a client = is identified by
> =A0 =A0 >> its identity. =A0A different application can take ove= r from the
> =A0 =A0 first by
> =A0 =A0 >> using the same identity. =A0Loss of a transport sessi= on does not cause
> =A0 =A0 >> existing client state to be removed (in the architect= ure) - so
> =A0 =A0 there is
> =A0 =A0 >> the ability for a new application to take over.
> =A0 =A0 >>
> =A0 =A0 >> Does that help?
> =A0 =A0 >
> =A0 =A0 > That worries me without more discussion about authenticat= ion.
> =A0 =A0 > Additionally, from a troubleshooting standpoint, if I can= assume the
> =A0 =A0 > same identity as another client, how can I be absolutely = sure which
> =A0 =A0 > client does what to the agent? =A0I feel there needs to b= e more to
> =A0 =A0 ensure
> =A0 =A0 > accountability of what client does what, certainly from a= security
> =A0 =A0 > perspective, but also from a troubleshooting perspective.=
> =A0 =A0 >
> =A0 =A0 > Joe
> =A0 =A0 >
> =A0 =A0 >>
> =A0 =A0 >> Alia
> =A0 =A0 >>
> =A0 =A0 >>
> =A0 =A0 >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
> =A0 =A0 <mailto:lberger@labn.ne= t>
> =A0 =A0 >> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote:
> =A0 =A0 >>
> =A0 =A0 >> =A0 =A0 Hi Joel,
> =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 In today's session, I ask= ed about provisions in the
> =A0 =A0 architecture
> =A0 =A0 >> =A0 =A0 (document) for Client Redundancy/Fault Tolera= nce. I believe
> =A0 =A0 you stated
> =A0 =A0 >> =A0 =A0 that "it's not needed" and that= you'd elaborate on the list.
> =A0 =A0 >>
> =A0 =A0 >> =A0 =A0 I believe you also answered a latter question= by stating that
> =A0 =A0 clients
> =A0 =A0 >> =A0 =A0 are free to coordinate between themselves to = provide
> =A0 =A0 redundancy. Is this
> =A0 =A0 >> =A0 =A0 the simple answer? =A0If not, can you elabora= te?
> =A0 =A0 >>
> =A0 =A0 >> =A0 =A0 Thanks,
> =A0 =A0 >> =A0 =A0 Lou
> =A0 =A0 >> =A0 =A0 _____________________________________________= __
> =A0 =A0 >> =A0 =A0 i2rs mailing list
> =A0 =A0 >> =A0 =A0 i2rs@i= etf.org <mailto:i2rs@ietf.org&g= t; <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:= i2rs@ietf.org>>
> =A0 =A0 >> =A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs<= br> > =A0 =A0 >>
> =A0 =A0 >>
> =A0 =A0 >>
> =A0 =A0 >>
> =A0 =A0 >> _______________________________________________
> =A0 =A0 >> i2rs mailing list
> =A0 =A0 >> i2rs@ietf.org<= /a> <mailto:i2rs@ietf.org>
> =A0 =A0 >> https://www.ietf.org/mailman/listinfo= /i2rs
> =A0 =A0 >>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > --
> =A0 =A0 > Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0|
> =A0 =A0 > SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 = =A0 =A0|||||
> =A0 =A0 > Distinguished Services Engineer ..:|||||||||::|||||||||:.= .
> =A0 =A0 > Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392= -2867>
> =A0 =A0 c i s c o =A0S y s t e m s
> =A0 =A0 > Email: jclarke= @cisco.com <mailto:jclarke@cisc= o.com>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 --------------------------------------------------------------= --------------
>
>
> =A0 =A0 --
> =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0|
> =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0= |||||
> =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
> =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867= > =A0 =A0 =A0 =A0 c
> =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 Email: jclarke@cisc= o.com <mailto:jclarke@cisco.com= >
>
> =A0 =A0 --------------------------------------------------------------= --------------
>
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--001a11c300da0cc32e04e3da7f3f-- From akatlas@gmail.com Tue Aug 13 14:00:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC221E812A for ; Tue, 13 Aug 2013 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2g0B2VxuTTg for ; Tue, 13 Aug 2013 14:00:42 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 94CAE21E80C3 for ; Tue, 13 Aug 2013 14:00:39 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so11042673obb.16 for ; Tue, 13 Aug 2013 14:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DZpg0oPgz3KQdhutPi/M9BHenHjPw/g4e6B14BfxXgQ=; b=l6NfouDUQrAIoEWMk0M/69f+5I7gnPS6YzuXBwq2KEU2aBzo9ayISytD3nciX6XTtj Edve2SSdF54Rd1ixN6gp1uKd8Vsafz6ZhEew7yuBb/cuY5IZC7ccmhnkNe2LN7vxyy1b DJEYFUlbmjjrfvdzlqmfimgIcGDGEfcEIX5BcMWU9tO4OnLczPeEacffJxNmT6ysNZHI MT/8UoE7v5ONqNy3Vqq45oM5qcOmhGOV39B8g2CKlZp4LdH9Hw0Wb+kgmPOMuW5/tjvI +BAh3HhzDjUWhLdTwqI1VtybBXWxN5f9DK4Vr5N+8qY6UVa0xrPT52Y+cJckAnp9ZtCE FqzA== MIME-Version: 1.0 X-Received: by 10.182.61.44 with SMTP id m12mr8365520obr.52.1376427638593; Tue, 13 Aug 2013 14:00:38 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 14:00:38 -0700 (PDT) In-Reply-To: <031001ce8f76$a1d07830$e5716890$@riw.us> References: <51FA492D.3070402@labn.net> <51FA4FF0.4060902@labn.net> <031001ce8f76$a1d07830$e5716890$@riw.us> Date: Tue, 13 Aug 2013 17:00:38 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=e89a8fb1f218751f5904e3da8817 Cc: "i2rs@ietf.org" , Joel Halpern , Lou Berger Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:00:50 -0000 --e89a8fb1f218751f5904e3da8817 Content-Type: text/plain; charset=ISO-8859-1 Hi Russ, On Fri, Aug 2, 2013 at 7:51 AM, Russ White wrote: > > > A bit. The discussion of treating multiple writers for the same state as > errors > > got me worried about this case - from a redundancy perspective, and to a > > lesser degree, accountability standpoint. > > > > Given the importance of reliable operation even in the case of client > failures, > > I think the topic should be covered in the architecture document. Of > course > > this topic/comment can be addressed after the document is adopted. > > Wouldn't much of this problem be alleviated if we went to a RESTful style > atomic interface? It seems, to me, that multipart "commit/rollback" > procedures always end up adding a lot of complexity, etc. I know there are > situations where it's simpler to have the client hold partial state while > telling the controller, "this part will succeed, please send me the next > part," but then we've also fallen into dealing with latency of operations, > locking forwarding plane tables across a remote connection (which routing > events are still occurring!), and this entire error management mess in > terms > of resiliency. > [Alia] I don't think that we are suggesting supporting multipart commit/rollback procedures. What operations come in a single message can be handled but so far we are avoiding transaction semantics and certainly locking any tables across messages!! > Routing protocols produce atomic updates today --we should stick with the > pattern set there as much as possible. > [Alia] Yup - my understanding of their concern is the traceability of whether the backup has taken over or not. I'm sure I'm missing nuances that I will be shortly enlightened about. :-) Regards, Alia > > :-) > > Russ > > --e89a8fb1f218751f5904e3da8817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Russ,

On Fri, Aug 2, 2013 at 7:51 AM, Russ White <russw@riw.us>= wrote:

> A bit. =A0The discussion of treating multiple writers for the same sta= te as
errors
> got me worried about this case - from a redundancy perspective, and to= a
> lesser degree, accountability standpoint.
>
> Given the importance of reliable operation even in the case of client<= br> failures,
> I think the topic should be covered in the architecture document. Of course
> this topic/comment can be addressed after the document is adopted.

Wouldn't much of this problem be alleviated if we went to a RESTf= ul style
atomic interface? It seems, to me, that multipart "commit/rollback&quo= t;
procedures always end up adding a lot of complexity, etc. I know there are<= br> situations where it's simpler to have the client hold partial state whi= le
telling the controller, "this part will succeed, please send me the ne= xt
part," but then we've also fallen into dealing with latency of ope= rations,
locking forwarding plane tables across a remote connection (which routing events are still occurring!), and this entire error management mess in term= s
of resiliency.

[Alia] I don't think= that we are suggesting supporting multipart commit/rollback procedures. = =A0What operations come in a single message can be handled but so far we ar= e avoiding transaction semantics and certainly locking any tables across me= ssages!!
=A0
Routing protocols produce atom= ic updates today --we should stick with the
pattern set there as much as possible.

= [Alia] Yup - my understanding of their concern is the traceability of wheth= er the backup has taken over or not. =A0I'm sure I'm missing nuance= s that I will be shortly enlightened about. =A0:-)

Regards,
Alia
=A0

:-)

Russ


--e89a8fb1f218751f5904e3da8817-- From internet-drafts@ietf.org Tue Aug 13 14:17:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B835D21F9EF6; Tue, 13 Aug 2013 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8josTB8gT3a4; Tue, 13 Aug 2013 14:17:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE28821F9E6A; Tue, 13 Aug 2013 14:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813211700.20599.28705.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 14:17:00 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-atlas-i2rs-architecture-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:17:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : An Architecture for the Interface to the Routing System Author(s) : Alia Atlas Joel Halpern Susan Hares Dave Ward Thomas D. Nadeau Filename : draft-atlas-i2rs-architecture-02.txt Pages : 21 Date : 2013-08-13 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet's routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-i2rs-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-i2rs-architecture-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-i2rs-architecture-02 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/ From akatlas@gmail.com Tue Aug 13 14:18:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7821F9EF6 for ; Tue, 13 Aug 2013 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHFpQrhS7c-z for ; Tue, 13 Aug 2013 14:18:43 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2C21F9E6A for ; Tue, 13 Aug 2013 14:18:40 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so11064487obb.16 for ; Tue, 13 Aug 2013 14:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJVNDSwYR71Z3knmwpZv5vos5Lxuq7sm/2WY+aoAlmE=; b=hy7P9QrQRO+jMfV24roy+bTw9Jtg7+9RfyZst8L+InFHvunKlF7fJGk6m3+cvplKmJ lVKPkPzif2UwbjNXP0ahCFB5zjp/2oE2ThrCOGzXevDNgEMZFfYGtP9lrar5ZB8oy0SY E5SIySOmNsO4/oe4pEg2C01s43PMF6Q5rozMFvTd8d0iIWFxlz2QEZ5xH9s/e4Twa9bB zxTj0RicRnXApa+fJ7nD6Lt394YTErkjOnjZgWWzdX0TD9KeTuzt/kpQdkpzAeeczw3Z JdmhZ9cxD7KTv1rUekJrIQPXH7BMcHuG7NySD6tjt7wqUZD+gWD7gfhpd0hYPgYmDgZX fqPA== MIME-Version: 1.0 X-Received: by 10.182.191.36 with SMTP id gv4mr28047obc.103.1376428720272; Tue, 13 Aug 2013 14:18:40 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Tue, 13 Aug 2013 14:18:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 17:18:40 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=089e0158aa9aee3c6f04e3dac837 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:18:43 -0000 --089e0158aa9aee3c6f04e3dac837 Content-Type: text/plain; charset=ISO-8859-1 I believe I have now responded to all the comments on draft-atlas-i2rs-architecture-01. I have updated the draft and submitted it as draft-atlas-i2rs-architecture-02. Please take a look at the differences and see if your suggestions and concerns have been addressed. Thanks, Alia On Tue, Aug 13, 2013 at 12:35 PM, Edward Crabbe wrote: > I2RSers; > > Yesterday ended the poll for wg adoption of this draft. Although there > seems to be sufficient support to warrant adoption, and there do not > seem to be any show-stoppers, I haven't seen any responses on the list > from Alia yet. > > Alia should respond to comments and update the draft > as warrranted before we finalize the process. I believe she's in the > midst of doing just that. > > cheers, > -ed > > On Mon, Aug 12, 2013 at 10:58 AM, Sriganesh Kini > wrote: > > Support WG adoption. > > > > > > On Wed, Jul 24, 2013 at 2:52 PM, Alia Atlas wrote: > >> > >> Please review draft-atlas-i2rs-architecture-01 and comment on whether it > >> should be adopted by I2RS. Detailed technical conversation is also most > >> welcome. > >> > >> Authors: Are you aware of any IPR that applies to > >> draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more > >> details). > >> > >> This WG call for adoption will complete on August 12. > >> > >> Thanks, > >> Alia > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --089e0158aa9aee3c6f04e3dac837 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe I have now responded to all the comments on draf= t-atlas-i2rs-architecture-01. =A0I have updated the draft and submitted it = as draft-atlas-i2rs-architecture-02.

Please take a look = at the differences and see if your suggestions and concerns have been addre= ssed.

Thanks,
Alia


On Tue, Aug 13, 2013 at 12:35 PM, = Edward Crabbe <edc@google.com> wrote:
I2RSers;

Yesterday ended the poll for wg adoption of this draft. =A0Although there seems to be sufficient support to warrant adoption, and there do not
seem to be any show-stoppers, I haven't seen any responses on the list<= br> from Alia yet.

Alia should respond to comments and update the draft
as warrranted before we finalize the process. =A0I believe she's in the=
midst of doing just that.

cheers,
=A0 =A0-ed

On Mon, Aug 12, 2013 at 10:58 AM, Sriganesh Kini
<sriganesh.kini@ericsson.= com> wrote:
> Support WG adoption.
>
>
> On Wed, Jul 24, 2013 at 2:52 PM, Alia Atlas <akatlas@gmail.com> wrote:
>>
>> Please review draft-atlas-i2rs-architecture-01 and comment on whet= her it
>> should be adopted by I2RS. =A0Detailed technical conversation is a= lso most
>> welcome.
>>
>> Authors: Are you aware of any IPR that applies to
>> draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclos= ed in
>> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378= for more
>> details).
>>
>> This WG call for adoption will complete on August 12.
>>
>> Thanks,
>> Alia
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

--089e0158aa9aee3c6f04e3dac837-- From nitinb@juniper.net Tue Aug 13 19:20:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A2D11E80FA for ; Tue, 13 Aug 2013 19:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d72jrhzOE5Mp for ; Tue, 13 Aug 2013 19:19:56 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id A94BA21F9AE7 for ; Tue, 13 Aug 2013 19:19:56 -0700 (PDT) Received: from mail72-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 02:19:55 +0000 Received: from mail72-co9 (localhost [127.0.0.1]) by mail72-co9-R.bigfish.com (Postfix) with ESMTP id CB20E100116; Wed, 14 Aug 2013 02:19:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received-SPF: pass (mail72-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(65816001)(56816003)(77096001)(63696002)(76176001)(53806001)(74366001)(76796001)(76786001)(54356001)(47446002)(16406001)(51856001)(81816001)(76482001)(83322001)(54316002)(74502001)(74662001)(31966008)(83072001)(69226001)(74876001)(46102001)(79102001)(74706001)(81542001)(81342001)(36756003)(80022001)(66066001)(49866001)(47736001)(4396001)(50986001)(56776001)(47976001)(59766001)(77982001)(80976001)(81686001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB052; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.53; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail72-co9 (localhost.localdomain [127.0.0.1]) by mail72-co9 (MessageSwitch) id 1376446792859491_7343; Wed, 14 Aug 2013 02:19:52 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.236]) by mail72-co9.bigfish.com (Postfix) with ESMTP id CD54346024C; Wed, 14 Aug 2013 02:19:52 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 02:19:52 +0000 Received: from BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 14 Aug 2013 02:19:51 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 14 Aug 2013 02:19:50 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.232]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.225]) with mapi id 15.00.0731.000; Wed, 14 Aug 2013 02:19:44 +0000 From: Nitin Bahadur To: Joe Marcus Clarke Thread-Topic: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt Thread-Index: AQHOgZGhebqy3aEUp0GzOI/nVMQ9O5llq0wAgBuZjICAEmwhAA== Date: Wed, 14 Aug 2013 02:19:43 +0000 Message-ID: In-Reply-To: <51FB129F.8080009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [66.129.224.53] x-forefront-prvs: 0938781D02 Content-Type: text/plain; charset="us-ascii" Content-ID: <5193D0EE81B3CA438C5DFD6F0CFF9C03@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 02:20:03 -0000 Hi Joe, Please see inline below for responses. >Section 4: > >Route programming in the RIB SHOULD result in a return code that > contains the following attributes: > >JMC: Why would one not want to return a result code? I think this needs >to be a MUST and there is evidence in a later section supporting this. Agreed. Fixed. >Section 4: > >JMC: How is this result code encapsulated? I realize this is an >information model, but I thought there would be some description of this >in your RBNF in Section 6. See comment below. >Section 5: > >Asynchronous notifications are sent by the network device's RIB >manager to an external entity when some event occurs on the network > device. A RIB data-model MUST support sending asynchronous > notifications. A brief list of suggested notifications is as below: > o Route change notification, with return code as specified in > Section 4 > o Nexthop resolution status (resolved/unresolved) notification > >JMC: While a RIB data-model must support notifications, there are no >notifications that must be supported? Are you suggesting that the two >examples listed here would be mandatory? Notifications section is the least developed so far. Yes, we need to specify what the contents of notifications should be and what notifications must/should be supported. >Section 6: > > ::=3D > [] > ::=3D > >JMC: I agree with Carlos (and I think you missed his point) IPV4_ADDRESS >and IPV6_ADDRESS should be IPV4_PREFIX and IPV6_PREFIX as these are not >addresses but route prefixes (the next-hop is an address) Fair point. Updated draft along the lines of: ::=3D [] ::=3D > >Section 8.1: > >JMC: Bulking (as you call it) then must also be supported by a RIB >client to request data in bulk. Yes. Added text towards that. >Section 8.2: > >Bulking (grouping of multiple write operations in a single message) > MUST be supported when an external entity wants to write to the RIB. > The response from the network device MUST include a return-code for > each write operation in the bulk message. > >JMC: Here, you say the return code per operation is a MUST, which >implies that in Section 4, this should be a MUST as well. Yes updated. >Section 8.3: > >There can be cases where a single network event results in multiple > events and/or notifications from the network device to an external > entity. On the other hand, due to timing of multiple things > happening at the same time, a network device might have to send > multiple events and/or notifications to an external entity. The > network device originated event/notification message MUST support > bulking of multiple events and notifications in a single message. > >JMC: Here is where I think we need to request something akin to pub-sub >where the Client can do filtering based on specific events types and >parameters within those events. While a bulk blob of events might be >nice for the RIB, I would think a client would want to be tactical about >the events (and, in fact, within Cisco we offer this kind of granular >filtering). Yes you could define a decent pub-sub model to limit the amount of data transmitted and for efficiency reasons. >Section 9: > >All interactions between a RIB manager and an external entity MUST be > authenticated. > >JMC: Should you also add authorized in addition to authenticated? Added. Thanks Nitin From ietfc@btconnect.com Wed Aug 14 02:35:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3621F9E33 for ; Wed, 14 Aug 2013 02:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUgvZugsvGqO for ; Wed, 14 Aug 2013 02:35:04 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67F21F9E54 for ; Wed, 14 Aug 2013 02:35:00 -0700 (PDT) Received: from mail4-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE038.bigfish.com (10.243.66.103) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Aug 2013 09:34:58 +0000 Received: from mail4-co1 (localhost [127.0.0.1]) by mail4-co1-R.bigfish.com (Postfix) with ESMTP id B70EAE029B; Wed, 14 Aug 2013 09:34:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zz98dI9371I542I1432I1418I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail4-co1 (localhost.localdomain [127.0.0.1]) by mail4-co1 (MessageSwitch) id 1376472896715429_14594; Wed, 14 Aug 2013 09:34:56 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.248]) by mail4-co1.bigfish.com (Postfix) with ESMTP id 8FAB244004A; Wed, 14 Aug 2013 09:34:56 +0000 (UTC) Received: from DBXPRD0711HT003.eurprd07.prod.outlook.com (157.56.254.181) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 14 Aug 2013 09:34:56 +0000 Received: from DBXPRD0210HT003.eurprd02.prod.outlook.com (157.56.253.181) by pod51017.outlook.com (10.255.178.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 14 Aug 2013 09:34:35 +0000 Message-ID: <02fb01ce98d1$6a6c6ac0$4001a8c0@gateway.2wire.net> From: t.petch To: Alia Atlas , Joe Marcus Clarke References: <51F8ED88.5050208@cisco.com> Date: Wed, 14 Aug 2013 10:24:05 +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: [157.56.253.181] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: i2rs@ietf.org Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:35:10 -0000 ----- Original Message ----- From: "Alia Atlas" To: "Joe Marcus Clarke" Cc: Sent: Tuesday, August 13, 2013 9:01 PM > Hi Joe, > > Thanks for the detailed review and suggestions. Responses are in-line. > > Alia > > On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke wrote: > > > Section 6.4: > > > > Each I2RS Client will have an identity; it can also have secondary > > identities to be used for troubleshooting. > > > > JMC: Each application will have a _unique_ identity. > > > > [Alia] Hmm, this ties into the discussion about how we want to handle > redundancy and recovery for clients. It's also a bit of a tautology - a > client is solely identified by its identity. I have changed it to say > that "Each I2RS Client will have a unique identity" - but that just helps > clarify the intent. I think that this nicely encapsulates a confusion between identity and identifier. Identifiers identify. Objects, in a very generic sense, have identity. Thus if a human being is an instance of an object, they may be identified, based on context, by SSN, passport number, name, name and date of birth, cell phone number etc; all could be valid identifiers: but equally, a cell phone number could be the identifier of a cell phone, which is associated with a function and multiple people, while the cell phone could also be identified by its IMEI so the determination of what is an identity, may take some consideration. This is often critical in security; you have a secure channel but with what? Is the identifier sufficient proof of the identity? Working with routers, you usually have multiple identifiers; the SNMP sysName is not (usually) the OSPF 32 bit router id, while the BGP Identifier (note, identifier) is different again. Identifiers exist within a namespace, with rules about syntax, uniqueness and so on (even if this are not made explicit). The revised I-D contains " A secondary identity is merely a unique, opaque identifier ..." and "An I2RS Client may supply a secondary opaque identity .. " I think that most uses of the word "identity" in this I-D are actually referring to "identifier" but at the same time, given that almost all routers have multiple identifiers (as above), then this issue, of the difference between identity and identifier needs making explicit in this I-D. Tom Petch (p.s. if you have multiple virtual routers in one physical router, how many identities are there? Discuss.) From jmh@joelhalpern.com Wed Aug 14 02:58:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BB11E8142 for ; Wed, 14 Aug 2013 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67dOE6NOBXnI for ; Wed, 14 Aug 2013 02:57:57 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 99DAD11E811E for ; Wed, 14 Aug 2013 02:57:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 82CEF1C0689; Wed, 14 Aug 2013 02:57:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7AEFD1C0685; Wed, 14 Aug 2013 02:57:56 -0700 (PDT) Message-ID: <520B54A2.1080107@joelhalpern.com> Date: Wed, 14 Aug 2013 05:57:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "t.petch" References: <51F8ED88.5050208@cisco.com> <02fb01ce98d1$6a6c6ac0$4001a8c0@gateway.2wire.net> In-Reply-To: <02fb01ce98d1$6a6c6ac0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, Joe Marcus Clarke , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:58:02 -0000 The virtual router question is an interesting one. I believe that the answer is "it depends". On the one hand there is a base device. There may or may not need to be capability for I2RS access to that entity. Then there are the individual virtual routers. My inclination would be to use separate I2RS clients, each with a separate I2RS identity and identifier. But there appears to be enough flexibility in the modeling that we are discussing that one could probably model it as one I2RS agent with various pieces and parts. In which case that one agent has only one identity and one identifier. Yours, Joel On 8/14/13 5:24 AM, t.petch wrote: > ----- Original Message ----- > From: "Alia Atlas" > To: "Joe Marcus Clarke" > Cc: > Sent: Tuesday, August 13, 2013 9:01 PM > > >> Hi Joe, >> >> Thanks for the detailed review and suggestions. Responses are > in-line. >> >> Alia >> >> On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke > wrote: >> > >>> Section 6.4: >>> >>> Each I2RS Client will have an identity; it can also have secondary >>> identities to be used for troubleshooting. >>> >>> JMC: Each application will have a _unique_ identity. >>> >> >> [Alia] Hmm, this ties into the discussion about how we want to handle >> redundancy and recovery for clients. It's also a bit of a > tautology - a >> client is solely identified by its identity. I have changed it to > say >> that "Each I2RS Client will have a unique identity" - but that just > helps >> clarify the intent. > > I think that this nicely encapsulates a confusion between identity and > identifier. Identifiers identify. Objects, in a very generic sense, > have identity. Thus if a human being is an instance of an object, they > may be identified, based on context, by SSN, passport number, name, name > and date of birth, cell phone number etc; all could be valid > identifiers: but equally, a cell phone number could be the identifier of > a cell phone, which is associated with a function and multiple people, > while the cell phone could also be identified by its IMEI so the > determination of what is an identity, may take some consideration. This > is often critical in security; you have a secure channel but with what? > Is the identifier sufficient proof of the identity? > > Working with routers, you usually have multiple identifiers; the SNMP > sysName is not (usually) the OSPF 32 bit router id, while the BGP > Identifier (note, identifier) is different again. > > Identifiers exist within a namespace, with rules about syntax, > uniqueness and so on (even if this are not made explicit). > > The revised I-D contains > " A secondary identity is merely a unique, opaque identifier ..." > and > "An I2RS Client may supply a secondary opaque identity .." > > I think that most uses of the word "identity" in this I-D are actually > referring to "identifier" but at the same time, given that almost all > routers have multiple identifiers (as above), then this issue, of the > difference between identity and identifier needs making explicit in this > I-D. > > Tom Petch > > (p.s. if you have multiple virtual routers in one physical router, how > many identities are there? Discuss.) > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Wed Aug 14 09:11:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB221E809F for ; Wed, 14 Aug 2013 09:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfm40s6JJ59k for ; Wed, 14 Aug 2013 09:11:46 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83821E80CC for ; Wed, 14 Aug 2013 09:11:46 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so11975030obc.6 for ; Wed, 14 Aug 2013 09:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=poJiEFQDKoDXPsrtukELCVmQinSPDdZ4/06ZTwifsrM=; b=ntKKRX5+hAVNDvJHuiWPlwLcaYwwdUuUKu7ff0lNJ/Keo1EFDgwO3ZkN7kgZUu2AHr wgjkXnvdZiFcTa2HhvXO/ILtE5uckvnr77AzPrPJXH8usKXNrAqJBpGD3m6DkZ9tjxzD xzWdSk02hwdsi/IlS8rZBj3v5I8nXHiV3APEF1SraefLbGmtZBQfb0WYksbV4xKQdtjH dh5vCjmGOcbnoL9D1ThBxW8efjiyKoFUUvp05PSUuDSFWk09syxmQs6hNIupa3KT5pVp jSnLPdmiZHsNhYVSI2Ge/0qsM5aLvL2lcFj05Kat+68zphqOTC7+g7k+5LfmesgWclTD iOpg== MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr9792740obc.24.1376496705730; Wed, 14 Aug 2013 09:11:45 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 09:11:45 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> Date: Wed, 14 Aug 2013 12:11:45 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11c336762e107204e3ea9d44 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:11:48 -0000 --001a11c336762e107204e3ea9d44 Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Thanks for the review and comments. Responses in-line now that I'm home and recovered from IETF. Alia On Sun, Jul 28, 2013 at 5:07 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > I support I2RS adoption of this document. > > This is a very nice document. I also wanted to provide a small set of > review feedback comments (marked with "CMP"): > > Interface to the Routing System Problem Statement > draft-atlas-i2rs-problem-statement-01 > > Abstract > > In order to enable applications to have access to and control over > information in the Internet's routing system, we need a publicly > documented interface specification. The interface needs to support > > CMP: Where it says "In order to enable applications", I wonder if we need > to further qualify "network applications", to differentiate a custom > routing app versus a db query. Note this comment applies also to the > Introduction. > [Alia] Sure. > This document expands upon these statements of requirements to > provide a detailed problem statement for an Interface to the Internet > Routing System (I2RS). > > CMP: The acronym does not expand, "Interface to the Internet Routing > System" seems to be "I2IRS" (extra Internet). > [Alia] Ok - I've taken out Internet. Really, the interface applies regardless. > 2. I2RS Model and Problem Area for The IETF > > Figure 1: I2RS model and Problem Area > > CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS > Agent. For model completeness, would it make sense to add another "<-->" > (i.e., within scope) interface from the leftmost I2RS client into a > different I2RS Agent? Even something like "<-----> To another I2RS Agent". > [Alia] Sure 3. Standard Data-Models of Routing State for Installation > > There is a need to be able to precisely control routing and signaling > state based upon policy or external measures. This can range from > > and > > In addition to interfaces to the RIB layer, there is a need to > configure the various routing and signaling protocols with differing > dynamic state based upon application-level policy decisions. The > > CMP: It is not clear to me what "signaling" specifically refers to here. > > 3. Standard Data-Models of Routing State for Installation > > This means that, to usefully model > next-hops, the data model employed needs to handle next-hop > indirection (e.g. a prefix X is routed like prefix Y) as well as > different types of tunneling and encapsulation. > > CMP: a nit: "indirection", or "indirection and recursion"? > [Alia] sure 5. Desired Aspects of a Protocol for I2RS > > Multiple Simultaneous Asynchronous Operations: A single application > should be able to send multiple operations to I2RS without being > required to wait for each to complete before sending the next. > > CMP: "via I2RS" instead of "to I2RS". > [Alia] sure Duplex: Communications can be established by either the I2RS client > (i.e.: that resides within the application or is used by it to > communicate with the I2RS server), or the I2RS server. Similarly, > > CMP: Should "I2RS agent" be used instead of "I2RS Server", for > nomenclature consistency? > [Alia] Yes - good catch > > 5. Desired Aspects of a Protocol for I2RS > > CMP: I think there are some aspects potentially missing. Specifically: > CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting for > the same route) > CMP: 2. Security (and specifically integrity) > CMP: 3. Accounting. > [Alia] I think that (1) belongs in the architecture. I agree that it is important - but I feel that the problem-statement part is covered in the Multi-Headed Control. (2) is mostly covered in "Secure Control". I did add "Such communications must also have its integrity protected." since we hadn't mentioned integrity but just authentication and authorization. For (3), I'm not sure what aspects specifically apply to I2RS... We have authentication and authorization and, in the architecture, tracking of state written. What knobs or functionality are you looking for in accounting? Alia > Thanks! > > -- Carlos. > > > On Jul 24, 2013, at 11:53 PM, Alia Atlas wrote: > > > Please review draft-atlas-i2rs-problem-statement-01 and comment on > whether it should be adopted by I2RS. Detailed technical conversation is > also most welcome. > > > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > > > This WG call for adoption will complete on August 12. > > > > Thanks, > > Alia > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c336762e107204e3ea9d44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for the review and co= mments. =A0Responses in-line now that I'm home and recovered from IETF.=

Alia
<= br>
On Sun, Jul 28, 2013 at 5:07 PM, Carlos Pignataro (cpignata) <cpignata@ci= sco.com> wrote:
I support I2RS adoption of this document.

This is a very nice document. I also wanted to provide a small set of revie= w feedback comments (marked with "CMP"):

=A0 =A0 =A0 =A0 =A0 =A0Interface to the Routing System Problem Statement =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-atlas-i2rs-problem-statement-01
Abstract

=A0 =A0In order to enable applications to have access to and control over =A0 =A0information in the Internet's routing system, we need a publicly=
=A0 =A0documented interface specification. =A0The interface needs to suppor= t

CMP: Where it says "In order to enable applications", I wonder if= we need to further qualify "network applications", to differenti= ate a custom routing app versus a db query. Note this comment applies also = to the Introduction.

[Alia] Sure.
=A0
=A0 =A0This document expands upon these statements of = requirements to
=A0 =A0provide a detailed problem statement for an Interface to the Interne= t
=A0 =A0Routing System (I2RS).

CMP: The acronym does not expand, "Interface to the Internet Routing S= ystem" seems to be "I2IRS" (extra Internet).

[Alia] Ok - I've taken out Internet. =A0Really, th= e interface applies regardless.=A0
=A0
2. =A0I2RS Model and Problem Area for The IETF

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 1: I2RS model and Problem Are= a

CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS Age= nt. For model completeness, would it make sense to add another "<--= >" (i.e., within scope) interface from the leftmost I2RS client int= o a different I2RS Agent? Even something like "<-----> To anothe= r I2RS Agent".

[Alia] Sure=A0

3. =A0Standard Data-Models of Routing State for Ins= tallation

=A0 =A0There is a need to be able to precisely control routing and signalin= g
=A0 =A0state based upon policy or external measures. =A0This can range from=

and

=A0 =A0In addition to interfaces to the RIB layer, there is a need to
=A0 =A0configure the various routing and signaling protocols with differing=
=A0 =A0dynamic state based upon application-level policy decisions. =A0The<= br>
CMP: It is not clear to me what "signaling" specifically refers t= o here.

3. =A0Standard Data-Models of Routing State for Installation

=A0 =A0This means that, to usefully model
=A0 =A0next-hops, the data model employed needs to handle next-hop
=A0 =A0indirection (e.g. a prefix X is routed like prefix Y) as well as
=A0 =A0different types of tunneling and encapsulation.

CMP: a nit: "indirection", or "indirection and recursion&quo= t;?
[Alia] sure=A0

5. =A0Desired Aspects of a Protocol for I2RS

=A0 =A0Multiple Simultaneous Asynchronous Operations: =A0 A single applicat= ion
=A0 =A0 =A0 should be able to send multiple operations to I2RS without bein= g
=A0 =A0 =A0 required to wait for each to complete before sending the next.<= br>
CMP: "via I2RS" instead of "to I2RS".
<= div>
[Alia] sure=A0

=A0 =A0Duplex: =A0 Communications can be established by either the I2RS cli= ent
=A0 =A0 =A0 (i.e.: that resides within the application or is used by it to<= br> =A0 =A0 =A0 communicate with the I2RS server), or the I2RS server. =A0Simil= arly,

CMP: Should "I2RS agent" be used instead of "I2RS Server&quo= t;, for nomenclature consistency?

[Alia= ] Yes - good catch

5. =A0Desired Aspects of a Protocol for I2RS

CMP: I think there are some aspects potentially missing. Specifically:
CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting for t= he same route)
CMP: 2. Security (and specifically integrity)
CMP: 3. Accounting.

[Alia] I think that= (1) belongs in the architecture. =A0I agree that it is important - but I f= eel that the problem-statement part is covered in the Multi-Headed Control.=
(2) is mostly covered in "Secure Control". =A0I did add &quo= t;Such communications must also have its integrity protected." since w= e hadn't mentioned integrity but just authentication and authorization.=
For (3), I'm not sure what aspects specifically apply to I2RS... = =A0We have authentication and authorization and, in the architecture, track= ing of state written. =A0What knobs or functionality are you looking for in= accounting? =A0

Alia
=A0
Thanks!

-- Carlos.


On Jul 24, 2013, at 11:53 PM, Alia Atlas <akatlas@gmail.com> wrote:

> Please review draft-atlas-i2rs-problem-statement-01 and comment on whe= ther it should be adopted by I2RS. =A0Detailed technical conversation is al= so most welcome.
>
> Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-pro= blem-statement-01? Is so, has this IPR been disclosed in compliance with IE= TF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


--001a11c336762e107204e3ea9d44-- From akatlas@gmail.com Wed Aug 14 09:23:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D743311E81ED for ; Wed, 14 Aug 2013 09:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWuyz47xLdVn for ; Wed, 14 Aug 2013 09:23:59 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB111E816E for ; Wed, 14 Aug 2013 09:23:44 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so13406301oag.18 for ; Wed, 14 Aug 2013 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ts0QGC4at1hLB6fMdRYa0zIGojqYvot1FN9IFoTqsPI=; b=JP28P8jByxjQIKesQ5FwcqUI49QB+MYZ4WNE3f6ZuRSQ4+4fuTLA/gmV6d2J1warHA npp04EtW6O6UqWMJdhapSwUK+2eWTMV+gN1AU/YrLOEdEqWDoz4NsTEnbvTatvp9WYfB 9F0LtHZKQUo8qVDlV0Oyx0oHA4oRSOR4WOqpJD+Srv88PkSZEkL+BTtSgrzDM/rPfgOR ioGTCMftkKvxw1sHmPF7JLiaKM+PpkBRo6qfNyLrchd24ZliW5s5AtZKe84ZKckAi0ht LEZ3PQWrXBmivjO/ET3XG6cOeo3npN3sjlv6xJ8e4jqev7soV9sPc5g4pU3is3NX4bfP jrRQ== MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr9835805obc.24.1376497422923; Wed, 14 Aug 2013 09:23:42 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 09:23:42 -0700 (PDT) In-Reply-To: References: <20130729105242.GB7087@puck.nether.net> Date: Wed, 14 Aug 2013 12:23:42 -0400 Message-ID: From: Alia Atlas To: KwangKoog Lee Content-Type: multipart/alternative; boundary=001a11c33676ed7aaa04e3eac7c2 Cc: "i2rs@ietf.org" , Jon Mitchell Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:24:00 -0000 --001a11c33676ed7aaa04e3eac7c2 Content-Type: text/plain; charset=ISO-8859-1 Hi Kwang-koo, Thanks very much for your comments. My responses are in-line. On Mon, Jul 29, 2013 at 7:54 AM, KwangKoog Lee wrote: > Hi. This is Kwang-koog from kt which is one of major network providers in > South Korea. > First, I appreciate a vast of contributions by i2rs members for enabling > intelligent and simple routing operations. > > As Alia mentioned in her draft, many network providers including kt > today have very huge and complex routing networks > according to the growth of the IP-based services but they really need > simple operation and new business model for covering a number of use cases > on that. > With the benefit of the distributed routing manner, modern routing systems > easily plugged into a designated routing network and > forward user packets to desired destinations. But, in the operator > perspective, policy-based routing control and necessary optimizations for > routing are always major issues for them because it is very hard to control > multi-vendor ruters with their own proprietary functions. > > Our company has operated huge routing systems with the size of thousands > of routing systems during tens of years > and made a significant effort to optimize routing systems. > So, current routing systems support preferable service level aggrement and > traffic utilization is optimized by the our own planning rules. > However, to this end, there have been even much trial-and-error and many > times. > So, I expect that the works of i2rs help network providers to easily > control their network and also support many usecases from our customers. > [Alia] I would welcome your thoughts and feedback on the use-cases that I2RS is currently discussing. Additional use-cases would also be quite welcome (given that they fit in the charter) to help scope what information in the models are needed. > > I also think Alia clearly stated such concerns of modern routing > systems so that I also support the WG adoption. > I2RS members pointed out many comments and feedbacks for enhancing that > document which I also agree with. > > In addition, I give a small comment to her draft for "Sec. 5 desired > aspect of a protocol for i2rs" > That is "*interoperability between protocol versions*". > For example, newly defined software define network protocols such as > openflow rapidly changed and a bunch of functions are added. > But, nobody does consider the interoperability of such protocols. > I think providers are very wonderring that different version protocols can > be inter-working or not. > So, I want to comment that i2rs protocol has to have this aspect. > [Alia] A good point. I've added: "Extensibility and Interoperability: Both the I2RS protocol and models must be extensible and interoperate between different versions of protocols and models." Thanks, Alia > Thanks. > > sincerly, > Kwang-koog Lee (Ph.D) > the advanced institue of technology of kt, South Korea > > > On Mon, Jul 29, 2013 at 7:52 PM, Jon Mitchell wrote: > >> On 24/07/13 17:53 -0400, Alia Atlas wrote: >> > Please review draft-atlas-i2rs-problem-statement-01 and comment on >> whether >> > it should be adopted by I2RS. Detailed technical conversation is also >> most >> > welcome. >> > >> >> Support adoption.. some small issues to authors direct. >> >> -Jon >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > --001a11c33676ed7aaa04e3eac7c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kwang-koo,

Thanks very much for your= comments. =A0My responses are in-line.
On Mon, Jul 29, 2013 at 7:54 AM, KwangKoog Lee = <kwangkooglee@gmail.com> wrote:
Hi. This is Kwang-koog from kt which= is one of=A0major network=A0providers=A0in South Korea.
First, I appreciate a vast of contributions by i= 2rs members for enabling intelligent and simple routing operations.
=A0
As Alia ment= ioned in her draft, many network providers including kt today=A0have very h= uge and complex=A0routing networks
according to the growth of the IP-ba= sed services but they really need simple operation and new business model f= or covering a number of use cases on that.
With the benefit of the distributed routin= g manner, modern routing systems easily plugged into=A0a designated routing= =A0network=A0and=A0
forward=A0user=A0packets to desired destinations. Bu= t,=A0in the operator perspective,=A0policy-based routing control=A0and nece= ssary optimizations for routing=A0are=A0always=A0major issues for them beca= use it is very hard to control multi-vendor ruters with their own proprieta= ry functions.
=A0
Our company = has operated=A0huge routing systems with the size of thousands of routing s= ystems=A0during tens of years
and made a si= gnificant effort to optimize routing systems.
So, current=A0routing systems=A0support preferab= le service level aggrement and traffic utilization is optimized by the=A0ou= r own planning rules.
However, to this end,= there have been even=A0much=A0trial-and-error=A0and many times.
So, I expect that the works of i2rs help network= providers to easily control their network and also support many usecases f= rom our customers.

[Alia] I wou= ld welcome your thoughts and feedback on the use-cases that I2RS is current= ly discussing. =A0Additional use-cases would also be quite welcome (given t= hat they fit in the charter)
to help scope what information in the models are needed.
=A0=
=A0
I also think Alia clearly=A0stated such concerns of modern routing systems= =A0so that I also=A0support=A0the WG adoption.
I2RS members pointed out many=A0comments and feedbacks=A0for enhancing = that document which=A0I also agree with.=A0
=A0
In addition,= I=A0give=A0a=A0small comment to her draft for "Sec.=A05 desired aspec= t of a protocol for i2rs"
That is &quo= t;interoperability between protocol versions".
For example, newly defined software define netwo= rk protocols such as openflow=A0rapidly changed and a bunch of functions ar= e added.
But, nobody does consider the inte= roperability of such protocols.
I think providers are=A0very wonderring that dif= ferent version protocols can be inter-working or not.
So, I want to comment that i2rs protocol has to have this aspect= .

[Alia] =A0A good point. =A0I've = added:
=A0 "Extensibility and Interoperability: =A0Both the = I2RS
=A0 =A0 =A0 protocol and models must be extensible and inter= operate between
=A0 =A0 =A0 different versions of protocols and models."

Thanks,
Alia

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Thanks.
=A0
sincerly,
Kwang-koog Lee (Ph.D)
the advanced institue of technology of= kt,=A0South Korea


On Mon, Jul 29, 2013 at 7:52 PM, Jon Mitchell <jrmi= tche@puck.nether.net> wrote:
On 24/07/13 17:53 = -0400, Alia Atlas wrote:
> Please review draft-atlas-i2rs-problem-statement-01 and comment on whe= ther
> it should be adopted by I2RS. =A0Detailed technical conversation is al= so most
> welcome.
>

Support adoption.. some small issues to authors direct.

-Jon

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--001a11c33676ed7aaa04e3eac7c2-- From jclarke@cisco.com Wed Aug 14 09:30:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6111E81DD for ; Wed, 14 Aug 2013 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEBUSkK5FV57 for ; Wed, 14 Aug 2013 09:30:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5380D11E81F6 for ; Wed, 14 Aug 2013 09:30:02 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EGTrZ0002093; Wed, 14 Aug 2013 18:29:54 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EGTrbE000075; Wed, 14 Aug 2013 12:29:53 -0400 (EDT) Message-ID: <520BB081.6010400@cisco.com> Date: Wed, 14 Aug 2013 12:29:53 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Carlos Pignataro \(cpignata\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:30:12 -0000 On 8/14/13 12:11 PM, Alia Atlas wrote: > [Alia] I think that (1) belongs in the architecture. I agree that it is > important - but I feel that the problem-statement part is covered in the > Multi-Headed Control. > (2) is mostly covered in "Secure Control". I did add "Such > communications must also have its integrity protected." since we hadn't > mentioned integrity but just authentication and authorization. > For (3), I'm not sure what aspects specifically apply to I2RS... We > have authentication and authorization and, in the architecture, tracking > of state written. What knobs or functionality are you looking for in > accounting? I'll comment here, and I'm sure Carlos will chime in with anything I miss or if he sees things differently. Coming from a services/support mindset, accountability from a tracing point of view is important. I would like to see a history of actions performed, the client that performed them, when the actions were performed (with very granular timestamps), and the result code. Forgive me for using a vendor reference here (as an example), but in Cisco IOS we have the buffer of CLI commands executed and syslog messages generated. This buffer is very useful when it comes to tracing a crash back to potential triggers. As we look to incorporate our own APIs, we want to provide the same kind of history log to try and tie API calls back to potential problems on the device. With I2RS in particular, while crashes are certainly possible, being able to look back at operations and correlate problems like packet loss, service interruption, performance deviations, etc. will be vital from a troubleshooting standpoint. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From akatlas@gmail.com Wed Aug 14 09:39:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDA11E80AD for ; Wed, 14 Aug 2013 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaKvsnc9GZ17 for ; Wed, 14 Aug 2013 09:39:14 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id EF95311E8159 for ; Wed, 14 Aug 2013 09:39:11 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so13607478oag.12 for ; Wed, 14 Aug 2013 09:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g3jJ+UHsJiaIIfK38C30s6lpMdRvCKrZDBIWmfXIBkk=; b=WvPu5nOoooAoMKdMR9K2QYxJcoFagrcflXQNLowsfzxCaCnBr9zbJ4bzgD9aXg2b7O QNMxwdkOHPHFY99S+fswKE2hZdOclkHSJ8b28w6E73A6SUU/jF08L2ft7KW+4edSHtlL tbTH8sZ/wbsbLti/O7dzv1Xm/U3gvaIHp4O+uj7vVQEBlVE3caVmJGX6176VikF3ajpm 0gXyoGvfdH12fQvSLpOgfexZFsbhNwiYwiP4DmQyLLsDe7iVHLz26hkDSQkUHS8xA7Qo S3kvrhTpa2QjCsoMT2kg/USLzDOruKZPFrui1x4KK6tK9b9YXgPyQ65jkjIdsmoFVLlw upGQ== MIME-Version: 1.0 X-Received: by 10.182.241.71 with SMTP id wg7mr12904677obc.50.1376498351510; Wed, 14 Aug 2013 09:39:11 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 09:39:11 -0700 (PDT) In-Reply-To: <520BB081.6010400@cisco.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> Date: Wed, 14 Aug 2013 12:39:11 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a11c2e0f04699e104e3eaff63 Cc: "Carlos Pignataro \(cpignata\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:39:22 -0000 --001a11c2e0f04699e104e3eaff63 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, I certainly agree that keeping logs of the APIs done and their results or, perhaps, having the ability to mirror the requests and responses to a collector would be useful. With CLI, I agree that this is frequently done with syslog today - which then necessitates vendor-specific code to scrape through. What would be a meaningful accountability framework that would be appropriate and, hopefully, not require vendor-specific screen-scraping? Completely off the top of my head, I can see the following ideas: (a) mirror all (or a meaningful subset) messages in/out to a collector that then stores/sorts/logs the information (b) Define an accountability information model that defines what should be stored and have it stored in the canonical form required by the selected data-model. Perhaps mandate it be stored in a file for acquisition? Have the ability to read it? and I'm sure that there are many others... I do think this is an important area and it could use some good discussion (and even a draft or a section to go into the architecture). Alia On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke wrote: > On 8/14/13 12:11 PM, Alia Atlas wrote: > > [Alia] I think that (1) belongs in the architecture. I agree that it is > > important - but I feel that the problem-statement part is covered in the > > Multi-Headed Control. > > (2) is mostly covered in "Secure Control". I did add "Such > > communications must also have its integrity protected." since we hadn't > > mentioned integrity but just authentication and authorization. > > For (3), I'm not sure what aspects specifically apply to I2RS... We > > have authentication and authorization and, in the architecture, tracking > > of state written. What knobs or functionality are you looking for in > > accounting? > > I'll comment here, and I'm sure Carlos will chime in with anything I > miss or if he sees things differently. > > Coming from a services/support mindset, accountability from a tracing > point of view is important. I would like to see a history of actions > performed, the client that performed them, when the actions were > performed (with very granular timestamps), and the result code. > > Forgive me for using a vendor reference here (as an example), but in > Cisco IOS we have the buffer of CLI commands executed and syslog > messages generated. This buffer is very useful when it comes to tracing > a crash back to potential triggers. As we look to incorporate our own > APIs, we want to provide the same kind of history log to try and tie API > calls back to potential problems on the device. > > With I2RS in particular, while crashes are certainly possible, being > able to look back at operations and correlate problems like packet loss, > service interruption, performance deviations, etc. will be vital from a > troubleshooting standpoint. > > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --001a11c2e0f04699e104e3eaff63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

I certainly agree that keeping = logs of the APIs done and their results or, perhaps, having the ability to = mirror the requests and responses to a collector would be useful.

With CLI, I agree that this is frequently done with syslog t= oday - which then necessitates vendor-specific code to scrape through.

What would be a meaningful accountability framework th= at would be appropriate and, hopefully, not require vendor-specific screen-= scraping?

Completely off the top of my head, I can see the follow= ing ideas:
=A0 =A0(a) mirror all (or a meaningful subset) message= s in/out to a collector that then stores/sorts/logs the information
=A0 =A0(b) Define an accountability information model that defines what sho= uld be stored and have it stored in the canonical form required by the sele= cted data-model. =A0Perhaps mandate it be stored in a file for acquisition?= =A0Have the ability to read it?

and I'm sure that there are many others...

I do think this is an important area and it could use some= good discussion (and even a draft or a section to go into the architecture= ).

Alia


On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke <= span dir=3D"ltr"><jclarke@cisco.com> wrote:
On 8/14/13 12:11 PM, Alia = Atlas wrote:
> [Alia] I think that (1) belongs in the architecture. =A0I agree that i= t is
> important - but I feel that the problem-statement part is covered in t= he
> Multi-Headed Control.
> (2) is mostly covered in "Secure Control". =A0I did add &quo= t;Such
> communications must also have its integrity protected." since we = hadn't
> mentioned integrity but just authentication and authorization.
> For (3), I'm not sure what aspects specifically apply to I2RS... = =A0We
> have authentication and authorization and, in the architecture, tracki= ng
> of state written. =A0What knobs or functionality are you looking for i= n
> accounting?

I'll comment here, and I'm sure Carlos will chime in with any= thing I
miss or if he sees things differently.

Coming from a services/support mindset, accountability from a tracing
point of view is important. =A0I would like to see a history of actions
performed, the client that performed them, when the actions were
performed (with very granular timestamps), and the result code.

Forgive me for using a vendor reference here (as an example), but in
Cisco IOS we have the buffer of CLI commands executed and syslog
messages generated. =A0This buffer is very useful when it comes to tracing<= br> a crash back to potential triggers. =A0As we look to incorporate our own APIs, we want to provide the same kind of history log to try and tie API calls back to potential problems on the device.

With I2RS in particular, while crashes are certainly possible, being
able to look back at operations and correlate problems like packet loss, service interruption, performance deviations, etc. will be vital from a
troubleshooting standpoint.

Joe

--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--001a11c2e0f04699e104e3eaff63-- From internet-drafts@ietf.org Wed Aug 14 09:41:23 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6296421F9E40; Wed, 14 Aug 2013 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEsY3FyxigVT; Wed, 14 Aug 2013 09:41:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B007C21F9E34; Wed, 14 Aug 2013 09:41:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814164118.23861.5795.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 09:41:18 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-atlas-i2rs-problem-statement-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:41:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : Interface to the Routing System Problem Statement Author(s) : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-atlas-i2rs-problem-statement-02.txt Pages : 10 Date : 2013-08-14 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-atlas-i2rs-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-atlas-i2rs-problem-statement-02 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/ From akatlas@gmail.com Wed Aug 14 09:45:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44111E817B for ; Wed, 14 Aug 2013 09:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Fu0af48dOc for ; Wed, 14 Aug 2013 09:45:41 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25911E8156 for ; Wed, 14 Aug 2013 09:45:41 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wc20so6695466obb.14 for ; Wed, 14 Aug 2013 09:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4e6KSyn6C9Noj18JSgnBGNB7s6EXZ1SUD6SVZ7xFX4s=; b=Ehs2cuMiIv/HIC+uAPh48kO92AMb56GDKVNCJb2gXEU5ww8Xyoyr9/vFdR+pfEP2/5 /eFp2PooP37OFKl6qJKlRh7H8mK2+8olB/xA+dUZsS/4pYL/PEhYKXbe++CKvs4yDmTY nWr3wj29rePUKMu+llQgrVhaIPqdya3+jDIZhsSB0G+Elw2DcpMG29ASu2UiQOD+0ZOx ycL3i1snBLoxDIy/+9VG4u3enSF52sceT1FuDOtjjD8DwtIedXODN+/HD4e1FMOM/xHE oyXg2qWvbOi7wqFONKVMQY9SY1xf1zDSpgvlgzzkaFPB1ntmcb/h66ZI0lLfRuYMGkoe rWNA== MIME-Version: 1.0 X-Received: by 10.60.35.40 with SMTP id e8mr10382499oej.34.1376498741207; Wed, 14 Aug 2013 09:45:41 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 09:45:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Aug 2013 12:45:40 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" , Edward Crabbe Content-Type: multipart/alternative; boundary=089e013d0a1880eb6404e3eb165c Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:45:42 -0000 --089e013d0a1880eb6404e3eb165c Content-Type: text/plain; charset=ISO-8859-1 I believe I have addressed all of the comments about draft-atlas-i2rs-problem-statement-01 in the updated and just posted draft-atlas-i2rs-problem-statement-02. Please let me know if I've missed anything or if you have more comments on this draft. Thanks, Alia (wg-chair hat off) On Wed, Jul 24, 2013 at 5:53 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-problem-statement-01 and comment on whether > it should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > --089e013d0a1880eb6404e3eb165c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe I have addressed all of the comments about draft= -atlas-i2rs-problem-statement-01 in the updated and just posted draft-atlas= -i2rs-problem-statement-02. =A0Please let me know if I've missed anythi= ng or if you have more comments on this draft.

Thanks,
Alia (wg-chair hat off)


On Wed, Jul 24, 2013= at 5:53 PM, Alia Atlas <akatlas@gmail.com> wrote:
Please review draft-atlas-i= 2rs-problem-statement-01 and comment on whether it should be adopted by I2R= S. =A0Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-prob= lem-statement-01? Is so, has this IPR been disclosed in compliance with IET= F IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,Alia

--089e013d0a1880eb6404e3eb165c-- From jmh@joelhalpern.com Wed Aug 14 10:28:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8120A21E808C for ; Wed, 14 Aug 2013 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjD7drv3pImL for ; Wed, 14 Aug 2013 10:28:16 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A62DA21F9BA0 for ; Wed, 14 Aug 2013 10:28:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7FD77141B2D; Wed, 14 Aug 2013 10:28:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BF598141B2B; Wed, 14 Aug 2013 10:28:11 -0700 (PDT) Message-ID: <520BBE28.3090902@joelhalpern.com> Date: Wed, 14 Aug 2013 13:28:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Marcus Clarke References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> In-Reply-To: <520BB081.6010400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Carlos Pignataro \(cpignata\)" , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:28:22 -0000 I would expect that kind of kistory creation to be handled by something like a syslog event report, rather than by anything internal to I2RS. We do not normally specify as part of the protocols all the syslog events they should generate, do we? Yours, Joel On 8/14/13 12:29 PM, Joe Marcus Clarke wrote: > On 8/14/13 12:11 PM, Alia Atlas wrote: >> [Alia] I think that (1) belongs in the architecture. I agree that it is >> important - but I feel that the problem-statement part is covered in the >> Multi-Headed Control. >> (2) is mostly covered in "Secure Control". I did add "Such >> communications must also have its integrity protected." since we hadn't >> mentioned integrity but just authentication and authorization. >> For (3), I'm not sure what aspects specifically apply to I2RS... We >> have authentication and authorization and, in the architecture, tracking >> of state written. What knobs or functionality are you looking for in >> accounting? > > I'll comment here, and I'm sure Carlos will chime in with anything I > miss or if he sees things differently. > > Coming from a services/support mindset, accountability from a tracing > point of view is important. I would like to see a history of actions > performed, the client that performed them, when the actions were > performed (with very granular timestamps), and the result code. > > Forgive me for using a vendor reference here (as an example), but in > Cisco IOS we have the buffer of CLI commands executed and syslog > messages generated. This buffer is very useful when it comes to tracing > a crash back to potential triggers. As we look to incorporate our own > APIs, we want to provide the same kind of history log to try and tie API > calls back to potential problems on the device. > > With I2RS in particular, while crashes are certainly possible, being > able to look back at operations and correlate problems like packet loss, > service interruption, performance deviations, etc. will be vital from a > troubleshooting standpoint. > > Joe > From jmh@joelhalpern.com Wed Aug 14 10:29:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9536721F99ED for ; Wed, 14 Aug 2013 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsedhaIbE4NA for ; Wed, 14 Aug 2013 10:29:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0121F9A78 for ; Wed, 14 Aug 2013 10:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D2A431C0689; Wed, 14 Aug 2013 10:29:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7D1C81C004F; Wed, 14 Aug 2013 10:29:36 -0700 (PDT) Message-ID: <520BBE7D.4050604@joelhalpern.com> Date: Wed, 14 Aug 2013 13:29:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alia Atlas References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Carlos Pignataro \(cpignata\)" , Joe Marcus Clarke , "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:29:42 -0000 These look like things outside of the scope of I2RS> I would not want to define message mirroring as part of the transport protocol requirements, for example. yours, Joel On 8/14/13 12:39 PM, Alia Atlas wrote: > Hi Joe, > > I certainly agree that keeping logs of the APIs done and their results > or, perhaps, having the ability to mirror the requests and responses to > a collector would be useful. > > With CLI, I agree that this is frequently done with syslog today - which > then necessitates vendor-specific code to scrape through. > > What would be a meaningful accountability framework that would be > appropriate and, hopefully, not require vendor-specific screen-scraping? > > Completely off the top of my head, I can see the following ideas: > (a) mirror all (or a meaningful subset) messages in/out to a > collector that then stores/sorts/logs the information > (b) Define an accountability information model that defines what > should be stored and have it stored in the canonical form required by > the selected data-model. Perhaps mandate it be stored in a file for > acquisition? Have the ability to read it? > > and I'm sure that there are many others... > > I do think this is an important area and it could use some good > discussion (and even a draft or a section to go into the architecture). > > Alia > > > On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > wrote: > > On 8/14/13 12:11 PM, Alia Atlas wrote: > > [Alia] I think that (1) belongs in the architecture. I agree > that it is > > important - but I feel that the problem-statement part is covered > in the > > Multi-Headed Control. > > (2) is mostly covered in "Secure Control". I did add "Such > > communications must also have its integrity protected." since we > hadn't > > mentioned integrity but just authentication and authorization. > > For (3), I'm not sure what aspects specifically apply to I2RS... We > > have authentication and authorization and, in the architecture, > tracking > > of state written. What knobs or functionality are you looking for in > > accounting? > > I'll comment here, and I'm sure Carlos will chime in with anything I > miss or if he sees things differently. > > Coming from a services/support mindset, accountability from a tracing > point of view is important. I would like to see a history of actions > performed, the client that performed them, when the actions were > performed (with very granular timestamps), and the result code. > > Forgive me for using a vendor reference here (as an example), but in > Cisco IOS we have the buffer of CLI commands executed and syslog > messages generated. This buffer is very useful when it comes to tracing > a crash back to potential triggers. As we look to incorporate our own > APIs, we want to provide the same kind of history log to try and tie API > calls back to potential problems on the device. > > With I2RS in particular, while crashes are certainly possible, being > able to look back at operations and correlate problems like packet loss, > service interruption, performance deviations, etc. will be vital from a > troubleshooting standpoint. > > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Wed Aug 14 10:35:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A8D21E80C7 for ; Wed, 14 Aug 2013 10:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUSmVFthstnf for ; Wed, 14 Aug 2013 10:35:10 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 635BA21E80BA for ; Wed, 14 Aug 2013 10:35:10 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so697955oag.27 for ; Wed, 14 Aug 2013 10:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=261U81+rWrzN7w1d9lBpJra3v4Uh1JP4M3cqqUjr+hM=; b=y6BrxugddSYETqfGeb0r9n5mBKiaCsb0+En44bkzPNGhv6kLCIC3sqk/TB1HeiFOwj iPe8oduQITX3J8/oCC95Iw+h8OuukXV3ceiU97fVSPGk8Yc+NwEwKLeO0EvLqJhJc9UF X67mR5rPvsDBjvJ3HqyFM4gioUb/j8q3xoichvO9JrkgEvHz0Wdc4oYXAibn6EfJoGUy n9yb5WSvjG1QKfSNTiX8ocxBOuQbbh/VP6JulOOes4ZYG6oJGUXlLa/z7kTPyukR2PAB pPFXr4KNdZfLGF42aKsckqxCHznMjDFLJCz4HTMtmzuYkVEuXjNUVWAlOfVKSEcUOPsE D0UQ== MIME-Version: 1.0 X-Received: by 10.60.135.167 with SMTP id pt7mr7749647oeb.59.1376501709855; Wed, 14 Aug 2013 10:35:09 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 10:35:09 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 10:35:09 -0700 (PDT) In-Reply-To: <520BBE7D.4050604@joelhalpern.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> Date: Wed, 14 Aug 2013 13:35:09 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b3a849c72e2a804e3ebc78a Cc: i2rs@ietf.org, Joe Marcus Clarke , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:35:11 -0000 --047d7b3a849c72e2a804e3ebc78a Content-Type: text/plain; charset=ISO-8859-1 Yes, I agree that requiring someyhing like transport mirroring would be unfortunate. I also don't think that we should be defining required syslog messages. But the interesting question is whether something reasonable could be done for vendor-agnostic traceability... Alia On Aug 14, 2013 1:29 PM, "Joel M. Halpern" wrote: > These look like things outside of the scope of I2RS> I would not want to > define message mirroring as part of the transport protocol requirements, > for example. > > yours, > Joel > > On 8/14/13 12:39 PM, Alia Atlas wrote: > >> Hi Joe, >> >> I certainly agree that keeping logs of the APIs done and their results >> or, perhaps, having the ability to mirror the requests and responses to >> a collector would be useful. >> >> With CLI, I agree that this is frequently done with syslog today - which >> then necessitates vendor-specific code to scrape through. >> >> What would be a meaningful accountability framework that would be >> appropriate and, hopefully, not require vendor-specific screen-scraping? >> >> Completely off the top of my head, I can see the following ideas: >> (a) mirror all (or a meaningful subset) messages in/out to a >> collector that then stores/sorts/logs the information >> (b) Define an accountability information model that defines what >> should be stored and have it stored in the canonical form required by >> the selected data-model. Perhaps mandate it be stored in a file for >> acquisition? Have the ability to read it? >> >> and I'm sure that there are many others... >> >> I do think this is an important area and it could use some good >> discussion (and even a draft or a section to go into the architecture). >> >> Alia >> >> >> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > > wrote: >> >> On 8/14/13 12:11 PM, Alia Atlas wrote: >> > [Alia] I think that (1) belongs in the architecture. I agree >> that it is >> > important - but I feel that the problem-statement part is covered >> in the >> > Multi-Headed Control. >> > (2) is mostly covered in "Secure Control". I did add "Such >> > communications must also have its integrity protected." since we >> hadn't >> > mentioned integrity but just authentication and authorization. >> > For (3), I'm not sure what aspects specifically apply to I2RS... >> We >> > have authentication and authorization and, in the architecture, >> tracking >> > of state written. What knobs or functionality are you looking for >> in >> > accounting? >> >> I'll comment here, and I'm sure Carlos will chime in with anything I >> miss or if he sees things differently. >> >> Coming from a services/support mindset, accountability from a tracing >> point of view is important. I would like to see a history of actions >> performed, the client that performed them, when the actions were >> performed (with very granular timestamps), and the result code. >> >> Forgive me for using a vendor reference here (as an example), but in >> Cisco IOS we have the buffer of CLI commands executed and syslog >> messages generated. This buffer is very useful when it comes to >> tracing >> a crash back to potential triggers. As we look to incorporate our own >> APIs, we want to provide the same kind of history log to try and tie >> API >> calls back to potential problems on the device. >> >> With I2RS in particular, while crashes are certainly possible, being >> able to look back at operations and correlate problems like packet >> loss, >> service interruption, performance deviations, etc. will be vital from >> a >> troubleshooting standpoint. >> >> Joe >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 >> c >> i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ------------------------------**------------------------------** >> ---------------- >> >> >> >> >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> --047d7b3a849c72e2a804e3ebc78a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Yes, I agree that requiring someyhing like transport mirrori= ng would be unfortunate.

I also don't think that we should be defining required s= yslog messages.=A0=A0

But the interesting question is whether something reasonable= could be done for vendor-agnostic traceability...

Alia

On Aug 14, 2013 1:29 PM, "Joel M. Halpern&q= uot; <jmh@joelhalpern.com>= wrote:
These look like things outside of the scope of I2RS> =A0I would not want= to define message mirroring as part of the transport protocol requirements= , for example.

yours,
Joel

On 8/14/13 12:39 PM, Alia Atlas wrote:
Hi Joe,

I certainly agree that keeping logs of the APIs done and their results
or, perhaps, having the ability to mirror the requests and responses to
a collector would be useful.

With CLI, I agree that this is frequently done with syslog today - which then necessitates vendor-specific code to scrape through.

What would be a meaningful accountability framework that would be
appropriate and, hopefully, not require vendor-specific screen-scraping?
Completely off the top of my head, I can see the following ideas:
=A0 =A0 (a) mirror all (or a meaningful subset) messages in/out to a
collector that then stores/sorts/logs the information
=A0 =A0 (b) Define an accountability information model that defines what should be stored and have it stored in the canonical form required by
the selected data-model. =A0Perhaps mandate it be stored in a file for
acquisition? =A0Have the ability to read it?

and I'm sure that there are many others...

I do think this is an important area and it could use some good
discussion (and even a draft or a section to go into the architecture).

Alia


On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke <jclarke@cisco.com
<mailto:jclarke@c= isco.com>> wrote:

=A0 =A0 On 8/14/13 12:11 PM, Alia Atlas wrote:
=A0 =A0 =A0> [Alia] I think that (1) belongs in the architecture. =A0I a= gree
=A0 =A0 that it is
=A0 =A0 =A0> important - but I feel that the problem-statement part is c= overed
=A0 =A0 in the
=A0 =A0 =A0> Multi-Headed Control.
=A0 =A0 =A0> (2) is mostly covered in "Secure Control". =A0I d= id add "Such
=A0 =A0 =A0> communications must also have its integrity protected."= ; since we
=A0 =A0 hadn't
=A0 =A0 =A0> mentioned integrity but just authentication and authorizati= on.
=A0 =A0 =A0> For (3), I'm not sure what aspects specifically apply t= o I2RS... =A0We
=A0 =A0 =A0> have authentication and authorization and, in the architect= ure,
=A0 =A0 tracking
=A0 =A0 =A0> of state written. =A0What knobs or functionality are you lo= oking for in
=A0 =A0 =A0> accounting?

=A0 =A0 I'll comment here, and I'm sure Carlos will chime in with a= nything I
=A0 =A0 miss or if he sees things differently.

=A0 =A0 Coming from a services/support mindset, accountability from a traci= ng
=A0 =A0 point of view is important. =A0I would like to see a history of act= ions
=A0 =A0 performed, the client that performed them, when the actions were =A0 =A0 performed (with very granular timestamps), and the result code.

=A0 =A0 Forgive me for using a vendor reference here (as an example), but i= n
=A0 =A0 Cisco IOS we have the buffer of CLI commands executed and syslog =A0 =A0 messages generated. =A0This buffer is very useful when it comes to = tracing
=A0 =A0 a crash back to potential triggers. =A0As we look to incorporate ou= r own
=A0 =A0 APIs, we want to provide the same kind of history log to try and ti= e API
=A0 =A0 calls back to potential problems on the device.

=A0 =A0 With I2RS in particular, while crashes are certainly possible, bein= g
=A0 =A0 able to look back at operations and correlate problems like packet = loss,
=A0 =A0 service interruption, performance deviations, etc. will be vital fr= om a
=A0 =A0 troubleshooting standpoint.

=A0 =A0 Joe

=A0 =A0 --
=A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0|
=A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||=
=A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
=A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%203= 92-2867> =A0 =A0 =A0 =A0 c
=A0 =A0 i s c o =A0S y s t e m s
=A0 =A0 Email: jclar= ke@cisco.com <mailto:jclarke@cisco.com>

=A0 =A0 ------------------------------------------------------------= ----------------




_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b3a849c72e2a804e3ebc78a-- From jclarke@cisco.com Wed Aug 14 10:41:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44BF11E8180 for ; Wed, 14 Aug 2013 10:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o27EJk8hdig for ; Wed, 14 Aug 2013 10:41:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDF511E811F for ; Wed, 14 Aug 2013 10:41:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHfTjE012322; Wed, 14 Aug 2013 19:41:29 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHfS1T016880; Wed, 14 Aug 2013 13:41:28 -0400 (EDT) Message-ID: <520BC148.3030306@cisco.com> Date: Wed, 14 Aug 2013 13:41:28 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51F8ED88.5050208@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:41:40 -0000 On 8/13/13 4:01 PM, Alia Atlas wrote: > Section 1.2: > > As can also be seen in Figure 1, an I2RS Agent may communicate with > multiple clients. Each client may send the agent a variety of write > operations. The handling of this situation has been a source of > discussion in the working group. In order to keep the protocol > simple, the current view is that two clients should not be attempting > to write (modify) the same piece of information. Such collisions may > happen, but are considered error cases that should be resolved by the > network applications and management systems. > > JMC: I think more verbiage is needed around how to detect collisions. > This is key to security considerations. Saying "clients should not" is > not strong enough to keep our potential attackers. If each operation is > tagged with an identifier that is unique to a client, then it will be > possible to determine if the current client is trying to overwrite data > from a previous client. This could fold into authz as well where there > is a permission to allow global override of other application's state. > > > [Alia] For the I2RS Agent to properly handle a collision, it does need > to store the client identifier. I think that is clear in Sec 5.2 > "Simply, the I2RS agent stores who did what operation to which entity." > and the details in Sec 6.8 are "The current recommendation is to have a > simple priority associated with each I2RS clients, and the highest > priority change remains in effect. In the case of priority ties, the > first client whose attribution is associated with the data will keep > control." We already have a reference to Sec 6.8 right there - and that > section is where the details are discussed. What specific additional > verbiage do you think would be useful? The priority is a knob to allow > overwriting of other applications' state - though needing to is > considered an error. :-) When I first read this, I wanted something stronger to prevent clients from writing to the same piece of data. I think the forward references are fine if perhaps a bit late in the text. But my ask was to strengthen the language to say "must not write." > > > Section 2: > > read scope: ... > > write scope: ... > > JMC: Should there be an event or notification scope in addition to read > and write? > > > [Alia] I think it is folded into the read scope. If we find the need > for such a term later on, then we can add it. This section talks about "terminology" used in the draft. However, "read scope" as terminology is not used anywhere. The concept of _reading_ data is, however, quite prevalent. In the same way, the draft talks about "notification" in a number of contexts. As such, I feel there is enough distinction there to warrant calling out what is meant by a notification scope. "notification scope: The set of events and associated information that will be sent northbound by the I2RS Agent to I2RS Clients. Clients have the ability to register for specific events, but must do so given the access restrictions of their associated read scope." > > Section 3.4: > > I2RS clients may be operating on behalf of other applications. While > those applications' identities are not need for authorization, each > application should have a unique opaque identifier that can be > provided by the I2RS client to the I2RS agent for purposes of > tracking attribution of operations. > > JMC: The opaque ID might make it hard to accurately attribute changes. > I2RS should mandate a way to ensure traceability back to a client that > made the change or was granted access. > > > [Alia] What do you have in mind? The I2RS client will have a security > role and its scope. The I2RS client needs to vet the applications that > it is a broker for. The opaque ID can be something that is meaningful > to that I2RS client. Basically, I2RS is providing the identity and > security for between the I2RS client and the I2RS agent. I don't see it > as practical or appropriate to try and define how the I2RS client and > its applications interact; I know the broker/controller model is popular > and so we do need enough to help support traceability to a secondary ID, > but I'm not sure what is needed or appropriate beyond that. After listening to the working group session and based on other threads, this text is now clearer to me. To summarize my feeling, I don't think I2RS should mandate a northbound Client protocol, but we need a unique way to identify the specific Client that obtained access. This means that even in a load-balancing or HA case, there must be a way to uniquely identify the Client that communicate with the Agent. The northbound actor driving the Client should also be identifiable, but that is outside the scope of this document. > Section 5.2.2: > > An I2RS Agent may decide that some state should no longer be applied. > An I2RS Client may instruct an Agent to remove state it has applied. > In all such cases, the state will revert to what it would have been > without the I2RS; that state is generally whatever was specified via > the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple > alternative states, nor try to determine which one among such a > plurality it should fall back to. Thus, the model followed is not > like the RIB, where multiple routes are stored at different > preferences. > > JMC: Previously I had commented that one event that should be supported > and perhaps documented here is that if the agent decides to revert the > application can be notified that its state has been reverted. This > might also be useful if another client overrides some portion of another > client's state (this is covered in Section 6.8, but might be useful to > mention here as well). Perhaps add at the end of Section 5.2.2: > > "A client may choose to be notified whenever its state is reverted > either by another client or by the I2RS agent." > > > [Alia] I'll put in: "An I2RS Client may register for notifications when > state that was > applied by a particular I2RS Client is modified or removed." That is > slightly different since it allows an I2RS Client to learn about the > changes to state from itself or from a different I2RS Client. WFM, thanks. > > Section 5.4.2: > > (Bulleted list of examples) > > JMC: Consider adding an example for an event such as a new route being > learned or an OSPF neighbor removal. > > > [Alia] I think that "writing routes or prefixes to be advertised via the > protocol" describes a new route being learned. I'd prefer not to put > OSPF neighbor removal in as an example. It raises the questions about > what is configuration vs. ephemeral data and the I2RS scope. If you > have a good use-case that requires it, then I'd be quite interested in > seeing it. I was specifically asking about an _event_ use case. Very simply if we learn/lose a route, I'd want my Client to be notified so I can perhaps react to it to install another route or remove a route I have previously installed (e.g., a failover/failback use case). Additionally, if a peer is otherwise reachable, but stops participating in OSPF, BGP, etc., I would like I2RS to notify my Client as I may not know about this any other way (though I could be flooded with route delete events, it's good to correlate that to a peer going away). > > > > Section 5.4.4: > > Many network elements have separate policy and QoS mechanisms, > including knobs which affect local path computation and queue control > capabilities. These capabilities vary widely across implementations, > and I2RS cannot model the full range of information collection or > manipulation of these attributes. A core set does need to be > included in the I2RS data models and in the expected interfaces > between the I2RS Agent and the network element, in order to provide > basic capabilities and the hooks for future extensibility. > > JMC: I think this either needs an editor's note for more discussion or > perhaps QoS in general should be out of scope. > > > [Alia] I am happy to add in an editor's note for more discussion - but > we should start that conversation now on the list - because the WG does > have quite tight deadlines for milestones. Fair enough. > Section 6.1: > > That protocol may use several underlying transports (TCP, > SCTP, DCCP), with suitable authentication and integrity protection > mechanisms. Whatever transport is used for the data exchange, it > must also support suitable congestion control mechanisms. > > JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP > is ideal for I2RS since we likely do want reliable order of delivery. > > > [Alia] Yes - DCCP is clearly the wrong choice for a control channel - > but it may be > good for delivering statistics. I think we'll have different transport > options depending on the requirements of a particular data model or > section. Since you are the second person to be confused by that > section, I've added the following sentence: > > "These different transports can support different types of > communication (e.g. control, reading, notifications, and information > collection) and different sets of data." > > Let me know if that helps or if you have better ideas for wording. That works. > Section 6.7: > > One of the other important aspects of the I2RS is that it is intended > to simplify collecting information about the state of network > elements. > > JMC: I think this needs to be more specific to routing information > versus any information from the network element (e.g., it does not cover > CPU statistics). > > > [Alia] The scoping is a question - and that will depend on what the > use-cases we consider need and what the related information and data > models need to be. If you look at the > draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU > load. I do think there is a real need to be able to get back > thresholded and filtered information. You probably heard Ed's personal > thoughts about a single protocol as well... So - I don't think the > architecture needs to restrict the data in scope - particular in a > section that is talking about communication patterns - but as a WG, we > need to keep a tight focus that still provides sufficient information to > fully solve the desired use-cases. My concerns comes from a desire not to have I2RS become a common API/protocol for things that SNMP or NETCONF or some other potential data collection scheme is used for. So I agree we need a tight focus and potentially a litmus test for what should be adopted as collectable data via I2RS. As it stands now, I think someone could argue for any kind of data and present a use case for it (e.g., latency, interface errors, location). So the statement I made was more around the lines of should I2RS stay pure to routing and routed topology or should we really open the door to other data that is not specifically related to routing? Joe > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Wed Aug 14 10:44:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBB21F99EF for ; Wed, 14 Aug 2013 10:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gvq3exBgAjB for ; Wed, 14 Aug 2013 10:44:32 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8021F9A06 for ; Wed, 14 Aug 2013 10:44:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHiTs8012708; Wed, 14 Aug 2013 19:44:29 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHiSkp020071; Wed, 14 Aug 2013 13:44:28 -0400 (EDT) Message-ID: <520BC1FC.4020109@cisco.com> Date: Wed, 14 Aug 2013 13:44:28 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:44:36 -0000 On 8/14/13 1:35 PM, Alia Atlas wrote: > Yes, I agree that requiring someyhing like transport mirroring would be > unfortunate. > > I also don't think that we should be defining required syslog messages. > > But the interesting question is whether something reasonable could be > done for vendor-agnostic traceability... Yes, that was my point. This would be data that, in my mind, could be queriable via I2RS. Joe > > Alia > > On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > wrote: > > These look like things outside of the scope of I2RS> I would not > want to define message mirroring as part of the transport protocol > requirements, for example. > > yours, > Joel > > On 8/14/13 12:39 PM, Alia Atlas wrote: > > Hi Joe, > > I certainly agree that keeping logs of the APIs done and their > results > or, perhaps, having the ability to mirror the requests and > responses to > a collector would be useful. > > With CLI, I agree that this is frequently done with syslog today > - which > then necessitates vendor-specific code to scrape through. > > What would be a meaningful accountability framework that would be > appropriate and, hopefully, not require vendor-specific > screen-scraping? > > Completely off the top of my head, I can see the following ideas: > (a) mirror all (or a meaningful subset) messages in/out to a > collector that then stores/sorts/logs the information > (b) Define an accountability information model that defines what > should be stored and have it stored in the canonical form > required by > the selected data-model. Perhaps mandate it be stored in a file for > acquisition? Have the ability to read it? > > and I'm sure that there are many others... > > I do think this is an important area and it could use some good > discussion (and even a draft or a section to go into the > architecture). > > Alia > > > On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > > >> wrote: > > On 8/14/13 12:11 PM, Alia Atlas wrote: > > [Alia] I think that (1) belongs in the architecture. I agree > that it is > > important - but I feel that the problem-statement part is > covered > in the > > Multi-Headed Control. > > (2) is mostly covered in "Secure Control". I did add "Such > > communications must also have its integrity protected." > since we > hadn't > > mentioned integrity but just authentication and > authorization. > > For (3), I'm not sure what aspects specifically apply to > I2RS... We > > have authentication and authorization and, in the > architecture, > tracking > > of state written. What knobs or functionality are you > looking for in > > accounting? > > I'll comment here, and I'm sure Carlos will chime in with > anything I > miss or if he sees things differently. > > Coming from a services/support mindset, accountability from > a tracing > point of view is important. I would like to see a history > of actions > performed, the client that performed them, when the actions were > performed (with very granular timestamps), and the result code. > > Forgive me for using a vendor reference here (as an > example), but in > Cisco IOS we have the buffer of CLI commands executed and syslog > messages generated. This buffer is very useful when it > comes to tracing > a crash back to potential triggers. As we look to > incorporate our own > APIs, we want to provide the same kind of history log to try > and tie API > calls back to potential problems on the device. > > With I2RS in particular, while crashes are certainly > possible, being > able to look back at operations and correlate problems like > packet loss, > service interruption, performance deviations, etc. will be > vital from a > troubleshooting standpoint. > > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 > c > i s c o S y s t e m s > Email: jclarke@cisco.com > > > > > ------------------------------__------------------------------__---------------- > > > > > _________________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/__listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jmh@joelhalpern.com Wed Aug 14 10:48:54 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6546221E80C8 for ; Wed, 14 Aug 2013 10:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYaGUH49jE3K for ; Wed, 14 Aug 2013 10:48:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 58CAA21E80C7 for ; Wed, 14 Aug 2013 10:48:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 93242141DFC; Wed, 14 Aug 2013 10:48:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BD194141E05; Wed, 14 Aug 2013 10:48:45 -0700 (PDT) Message-ID: <520BC2F9.9080500@joelhalpern.com> Date: Wed, 14 Aug 2013 13:48:41 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Marcus Clarke References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> In-Reply-To: <520BC148.3030306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:48:54 -0000 Depending upon how one reads RFCs, declaring that having two writers is an error is a MUST NOT write. But we are also trying to recognize that no matter how many MUST NOT statements we produce, things happen. So we are trying to define the handling. I can live with precedence. I can live with "the item does not change". But I do think it is helpful for us to be explicit about the behavior in this far-to-likely error case. Yours, Joel On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: > On 8/13/13 4:01 PM, Alia Atlas wrote: >> Section 1.2: >> >> As can also be seen in Figure 1, an I2RS Agent may communicate with >> multiple clients. Each client may send the agent a variety of write >> operations. The handling of this situation has been a source of >> discussion in the working group. In order to keep the protocol >> simple, the current view is that two clients should not be attempting >> to write (modify) the same piece of information. Such collisions may >> happen, but are considered error cases that should be resolved by the >> network applications and management systems. >> >> JMC: I think more verbiage is needed around how to detect collisions. >> This is key to security considerations. Saying "clients should not" is >> not strong enough to keep our potential attackers. If each operation is >> tagged with an identifier that is unique to a client, then it will be >> possible to determine if the current client is trying to overwrite data >> from a previous client. This could fold into authz as well where there >> is a permission to allow global override of other application's state. >> >> >> [Alia] For the I2RS Agent to properly handle a collision, it does need >> to store the client identifier. I think that is clear in Sec 5.2 >> "Simply, the I2RS agent stores who did what operation to which entity." >> and the details in Sec 6.8 are "The current recommendation is to have a >> simple priority associated with each I2RS clients, and the highest >> priority change remains in effect. In the case of priority ties, the >> first client whose attribution is associated with the data will keep >> control." We already have a reference to Sec 6.8 right there - and that >> section is where the details are discussed. What specific additional >> verbiage do you think would be useful? The priority is a knob to allow >> overwriting of other applications' state - though needing to is >> considered an error. :-) > > When I first read this, I wanted something stronger to prevent clients > from writing to the same piece of data. I think the forward references > are fine if perhaps a bit late in the text. But my ask was to > strengthen the language to say "must not write." > >> >> >> Section 2: >> >> read scope: ... >> >> write scope: ... >> >> JMC: Should there be an event or notification scope in addition to read >> and write? >> >> >> [Alia] I think it is folded into the read scope. If we find the need >> for such a term later on, then we can add it. > > This section talks about "terminology" used in the draft. However, > "read scope" as terminology is not used anywhere. The concept of > _reading_ data is, however, quite prevalent. In the same way, the draft > talks about "notification" in a number of contexts. As such, I feel > there is enough distinction there to warrant calling out what is meant > by a notification scope. > > "notification scope: The set of events and associated information that > will be sent northbound by the I2RS Agent to I2RS Clients. Clients have > the ability to register for specific events, but must do so given the > access restrictions of their associated read scope." > >> >> Section 3.4: >> >> I2RS clients may be operating on behalf of other applications. While >> those applications' identities are not need for authorization, each >> application should have a unique opaque identifier that can be >> provided by the I2RS client to the I2RS agent for purposes of >> tracking attribution of operations. >> >> JMC: The opaque ID might make it hard to accurately attribute changes. >> I2RS should mandate a way to ensure traceability back to a client that >> made the change or was granted access. >> >> >> [Alia] What do you have in mind? The I2RS client will have a security >> role and its scope. The I2RS client needs to vet the applications that >> it is a broker for. The opaque ID can be something that is meaningful >> to that I2RS client. Basically, I2RS is providing the identity and >> security for between the I2RS client and the I2RS agent. I don't see it >> as practical or appropriate to try and define how the I2RS client and >> its applications interact; I know the broker/controller model is popular >> and so we do need enough to help support traceability to a secondary ID, >> but I'm not sure what is needed or appropriate beyond that. > > After listening to the working group session and based on other threads, > this text is now clearer to me. To summarize my feeling, I don't think > I2RS should mandate a northbound Client protocol, but we need a unique > way to identify the specific Client that obtained access. This means > that even in a load-balancing or HA case, there must be a way to > uniquely identify the Client that communicate with the Agent. The > northbound actor driving the Client should also be identifiable, but > that is outside the scope of this document. > >> Section 5.2.2: >> >> An I2RS Agent may decide that some state should no longer be applied. >> An I2RS Client may instruct an Agent to remove state it has applied. >> In all such cases, the state will revert to what it would have been >> without the I2RS; that state is generally whatever was specified via >> the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple >> alternative states, nor try to determine which one among such a >> plurality it should fall back to. Thus, the model followed is not >> like the RIB, where multiple routes are stored at different >> preferences. >> >> JMC: Previously I had commented that one event that should be supported >> and perhaps documented here is that if the agent decides to revert the >> application can be notified that its state has been reverted. This >> might also be useful if another client overrides some portion of another >> client's state (this is covered in Section 6.8, but might be useful to >> mention here as well). Perhaps add at the end of Section 5.2.2: >> >> "A client may choose to be notified whenever its state is reverted >> either by another client or by the I2RS agent." >> >> >> [Alia] I'll put in: "An I2RS Client may register for notifications when >> state that was >> applied by a particular I2RS Client is modified or removed." That is >> slightly different since it allows an I2RS Client to learn about the >> changes to state from itself or from a different I2RS Client. > > WFM, thanks. > >> >> Section 5.4.2: >> >> (Bulleted list of examples) >> >> JMC: Consider adding an example for an event such as a new route being >> learned or an OSPF neighbor removal. >> >> >> [Alia] I think that "writing routes or prefixes to be advertised via the >> protocol" describes a new route being learned. I'd prefer not to put >> OSPF neighbor removal in as an example. It raises the questions about >> what is configuration vs. ephemeral data and the I2RS scope. If you >> have a good use-case that requires it, then I'd be quite interested in >> seeing it. > > I was specifically asking about an _event_ use case. Very simply if we > learn/lose a route, I'd want my Client to be notified so I can perhaps > react to it to install another route or remove a route I have previously > installed (e.g., a failover/failback use case). > > Additionally, if a peer is otherwise reachable, but stops participating > in OSPF, BGP, etc., I would like I2RS to notify my Client as I may not > know about this any other way (though I could be flooded with route > delete events, it's good to correlate that to a peer going away). > >> >> >> >> Section 5.4.4: >> >> Many network elements have separate policy and QoS mechanisms, >> including knobs which affect local path computation and queue control >> capabilities. These capabilities vary widely across implementations, >> and I2RS cannot model the full range of information collection or >> manipulation of these attributes. A core set does need to be >> included in the I2RS data models and in the expected interfaces >> between the I2RS Agent and the network element, in order to provide >> basic capabilities and the hooks for future extensibility. >> >> JMC: I think this either needs an editor's note for more discussion or >> perhaps QoS in general should be out of scope. >> >> >> [Alia] I am happy to add in an editor's note for more discussion - but >> we should start that conversation now on the list - because the WG does >> have quite tight deadlines for milestones. > > Fair enough. > >> Section 6.1: >> >> That protocol may use several underlying transports (TCP, >> SCTP, DCCP), with suitable authentication and integrity protection >> mechanisms. Whatever transport is used for the data exchange, it >> must also support suitable congestion control mechanisms. >> >> JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP >> is ideal for I2RS since we likely do want reliable order of delivery. >> >> >> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - >> but it may be >> good for delivering statistics. I think we'll have different transport >> options depending on the requirements of a particular data model or >> section. Since you are the second person to be confused by that >> section, I've added the following sentence: >> >> "These different transports can support different types of >> communication (e.g. control, reading, notifications, and information >> collection) and different sets of data." >> >> Let me know if that helps or if you have better ideas for wording. > > That works. > >> Section 6.7: >> >> One of the other important aspects of the I2RS is that it is intended >> to simplify collecting information about the state of network >> elements. >> >> JMC: I think this needs to be more specific to routing information >> versus any information from the network element (e.g., it does not cover >> CPU statistics). >> >> >> [Alia] The scoping is a question - and that will depend on what the >> use-cases we consider need and what the related information and data >> models need to be. If you look at the >> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU >> load. I do think there is a real need to be able to get back >> thresholded and filtered information. You probably heard Ed's personal >> thoughts about a single protocol as well... So - I don't think the >> architecture needs to restrict the data in scope - particular in a >> section that is talking about communication patterns - but as a WG, we >> need to keep a tight focus that still provides sufficient information to >> fully solve the desired use-cases. > > My concerns comes from a desire not to have I2RS become a common > API/protocol for things that SNMP or NETCONF or some other potential > data collection scheme is used for. So I agree we need a tight focus > and potentially a litmus test for what should be adopted as collectable > data via I2RS. As it stands now, I think someone could argue for any > kind of data and present a use case for it (e.g., latency, interface > errors, location). So the statement I made was more around the lines of > should I2RS stay pure to routing and routed topology or should we really > open the door to other data that is not specifically related to routing? > > Joe > >> From jclarke@cisco.com Wed Aug 14 10:49:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C94F21E80DD for ; Wed, 14 Aug 2013 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0b1SDSMNgRr for ; Wed, 14 Aug 2013 10:49:17 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35121E80DB for ; Wed, 14 Aug 2013 10:49:17 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHn9JW013344; Wed, 14 Aug 2013 19:49:14 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EHn4MQ024802; Wed, 14 Aug 2013 13:49:04 -0400 (EDT) Message-ID: <520BC310.5030902@cisco.com> Date: Wed, 14 Aug 2013 13:49:04 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51FA492D.3070402@labn.net> <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> <51FAEF39.9020102@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Joel Halpern , "lberger@labn.net" Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:49:21 -0000 On 8/13/13 4:58 PM, Alia Atlas wrote: > I am going to publish an updated version of > draft-atlas-i2rs-architecture without fully addressing this point. > > I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 > Identity and Security Role that says: > > "I2RS must support client redundancy. At the simplest, this can be > handled by having a primary and a backup network application that both > use the same client identity and can successfully authenticate as > such. Since I2RS does not require a continuous transport connection > and supports multiple transport sessions, this can provide some basic > redundancy. However, it does not address concerns for troubleshooting > and accountability about knowing which network application is actually > active. At a minimum, basic transport information about each > connection and time can be logged with the identity. Further > discussion is necessary to determine whether additional client > identification information is necessary.[[Editor's > note: This requires more discussion in the working group.]]" This is fine as a start. I would want to strengthen the language to ensure that an I2RS Agent always stores Client connection information with a timestamp. This information should be queriable via I2RS (with appropriate read scope). Joe > > Alia > > > On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke > wrote: > > On 8/1/13 11:19 AM, Alia Atlas wrote: > > Joe, > > > > Ok - so what I hear from you is needed is the > > client role > > client identity > > sub-client identity? > > > > Where the permissions and ownership of state is tied to the client > role? > > Does that match to what you are saying? I believe we're assuming > that > > the ownership of state is tied to the client identity - and you are > > suggesting that if so, we need a client sub-identity or such? > > Yes, I think that is in line with what I'm suggesting. If we can allow > Client A to assume the identity of Client B using the same credentials, > I would want some way to know that this is indeed Client B now acting on > behalf of either itself or some northbound controller. > > Joe > > > > > Alia > > > > > > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke > > > >> wrote: > > > > On 8/1/13 11:11 AM, Joel Halpern wrote: > > > The client is the entity that is authenticated and > authorized. If the > > > client is acting on behalf of someone else, we assume that the > > > authentication and authorization of that party is the task > of the > > client > > > and outside our scope. However we include that identity so that > > actions > > > can be easily correlated with originators. > > > > Right. I get that. I had thought we were talking about two > clients > > that might be redundant to each other where Client 1 dies and > Client 2 > > assumes its identity to make changes possibly driven by northbound > > actors. Even in this case, I feel Client 2 still needs to > maintain a > > unique identification to the I2RS agent so that one can trace the > > operation back to the specific I2RS client (in addition to the > > northbound actor). > > > > Joe > > > > > > > > Yours, > > > Joel > > > > > > Sent from my Android phone using TouchDown > (www.nitrodesk.com > > ) > > > > > > -----Original Message----- > > > *From:* Joe Marcus Clarke [jclarke@cisco.com > > > >] > > > *Received:* Thursday, 01 Aug 2013, 17:07 > > > *To:* Alia Atlas [akatlas@gmail.com > >] > > > *CC:* Lou Berger [lberger@labn.net > >]; > > i2rs@ietf.org > [i2rs@ietf.org > > >]; Joel > > > Halpern [joel.halpern@ericsson.com > >] > > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault > Tolerance > > > in draft-atlas-i2rs-architecture-01 > > > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > > >> Not to answer for Joel, but my view is that a client is > identified by > > >> its identity. A different application can take over from the > > first by > > >> using the same identity. Loss of a transport session does > not cause > > >> existing client state to be removed (in the architecture) - so > > there is > > >> the ability for a new application to take over. > > >> > > >> Does that help? > > > > > > That worries me without more discussion about authentication. > > > Additionally, from a troubleshooting standpoint, if I can > assume the > > > same identity as another client, how can I be absolutely > sure which > > > client does what to the agent? I feel there needs to be more to > > ensure > > > accountability of what client does what, certainly from a > security > > > perspective, but also from a troubleshooting perspective. > > > > > > Joe > > > > > >> > > >> Alia > > >> > > >> > > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > > > > > > >> > >>> wrote: > > >> > > >> Hi Joel, > > >> In today's session, I asked about provisions in the > > architecture > > >> (document) for Client Redundancy/Fault Tolerance. I believe > > you stated > > >> that "it's not needed" and that you'd elaborate on the > list. > > >> > > >> I believe you also answered a latter question by > stating that > > clients > > >> are free to coordinate between themselves to provide > > redundancy. Is this > > >> the simple answer? If not, can you elaborate? > > >> > > >> Thanks, > > >> Lou > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > > > >> > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> i2rs mailing list > > >> i2rs@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > > > > > > > > -- > > > Joe Marcus Clarke, CCIE #5384, | | > > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > > Phone: +1 (919) 392-2867 > > > c i s c o S y s t e m s > > > Email: jclarke@cisco.com > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 > c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > > > ---------------------------------------------------------------------------- > > > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jmh@joelhalpern.com Wed Aug 14 10:50:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15A21F8CDD for ; Wed, 14 Aug 2013 10:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m75KoC9Welck for ; Wed, 14 Aug 2013 10:50:08 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2F13121F9D09 for ; Wed, 14 Aug 2013 10:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 238EB141E26; Wed, 14 Aug 2013 10:50:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 89B8C141E2C; Wed, 14 Aug 2013 10:50:04 -0700 (PDT) Message-ID: <520BC349.5070206@joelhalpern.com> Date: Wed, 14 Aug 2013 13:50:01 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Marcus Clarke References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> In-Reply-To: <520BC1FC.4020109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, Carlos Pignataro , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:50:13 -0000 Are you asking that the history data itself be readable with I2RS? I really would not want to go there. Asking "who created the current state, CLI or specific named I2RS client, might be reasonable. Yours, Joel On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > On 8/14/13 1:35 PM, Alia Atlas wrote: >> Yes, I agree that requiring someyhing like transport mirroring would be >> unfortunate. >> >> I also don't think that we should be defining required syslog messages. >> >> But the interesting question is whether something reasonable could be >> done for vendor-agnostic traceability... > > Yes, that was my point. This would be data that, in my mind, could be > queriable via I2RS. > > Joe > >> >> Alia >> >> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > > wrote: >> >> These look like things outside of the scope of I2RS> I would not >> want to define message mirroring as part of the transport protocol >> requirements, for example. >> >> yours, >> Joel >> >> On 8/14/13 12:39 PM, Alia Atlas wrote: >> >> Hi Joe, >> >> I certainly agree that keeping logs of the APIs done and their >> results >> or, perhaps, having the ability to mirror the requests and >> responses to >> a collector would be useful. >> >> With CLI, I agree that this is frequently done with syslog today >> - which >> then necessitates vendor-specific code to scrape through. >> >> What would be a meaningful accountability framework that would be >> appropriate and, hopefully, not require vendor-specific >> screen-scraping? >> >> Completely off the top of my head, I can see the following ideas: >> (a) mirror all (or a meaningful subset) messages in/out to a >> collector that then stores/sorts/logs the information >> (b) Define an accountability information model that defines what >> should be stored and have it stored in the canonical form >> required by >> the selected data-model. Perhaps mandate it be stored in a file for >> acquisition? Have the ability to read it? >> >> and I'm sure that there are many others... >> >> I do think this is an important area and it could use some good >> discussion (and even a draft or a section to go into the >> architecture). >> >> Alia >> >> >> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke >> >> >> wrote: >> >> On 8/14/13 12:11 PM, Alia Atlas wrote: >> > [Alia] I think that (1) belongs in the architecture. I agree >> that it is >> > important - but I feel that the problem-statement part is >> covered >> in the >> > Multi-Headed Control. >> > (2) is mostly covered in "Secure Control". I did add "Such >> > communications must also have its integrity protected." >> since we >> hadn't >> > mentioned integrity but just authentication and >> authorization. >> > For (3), I'm not sure what aspects specifically apply to >> I2RS... We >> > have authentication and authorization and, in the >> architecture, >> tracking >> > of state written. What knobs or functionality are you >> looking for in >> > accounting? >> >> I'll comment here, and I'm sure Carlos will chime in with >> anything I >> miss or if he sees things differently. >> >> Coming from a services/support mindset, accountability from >> a tracing >> point of view is important. I would like to see a history >> of actions >> performed, the client that performed them, when the actions were >> performed (with very granular timestamps), and the result code. >> >> Forgive me for using a vendor reference here (as an >> example), but in >> Cisco IOS we have the buffer of CLI commands executed and syslog >> messages generated. This buffer is very useful when it >> comes to tracing >> a crash back to potential triggers. As we look to >> incorporate our own >> APIs, we want to provide the same kind of history log to try >> and tie API >> calls back to potential problems on the device. >> >> With I2RS in particular, while crashes are certainly >> possible, being >> able to look back at operations and correlate problems like >> packet loss, >> service interruption, performance deviations, etc. will be >> vital from a >> troubleshooting standpoint. >> >> Joe >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 >> c >> i s c o S y s t e m s >> Email: jclarke@cisco.com >> > >> >> >> ------------------------------__------------------------------__---------------- >> >> >> >> >> _________________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/__listinfo/i2rs >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > From cpignata@cisco.com Wed Aug 14 11:12:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725FD11E8189 for ; Wed, 14 Aug 2013 11:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfbh0OStqubD for ; Wed, 14 Aug 2013 11:12:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4C11E8187 for ; Wed, 14 Aug 2013 11:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5410; q=dns/txt; s=iport; t=1376503961; x=1377713561; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Np3sDXNzbFXDbwOZqJ9nCARSJ0ULB3aH+m49kXoDY+U=; b=hU2gGbUUt2EQTYq+hCfwVcBu5SQbQYWieL5REm20M5ALEgTrBCnW8viU W8bTqda+DrQsfD8T4q/y8Y2faNcmDLAHTa7PFkqZyEKCbvppTYevLSjcH 27KAYIo4EO+9qmUYY8qi8WehVceSsgmSvwfvDw7E7NUfU/6Ac7kJ4npTm 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAJTHC1KtJXHA/2dsb2JhbABRAQmDBjVQvmSBJBZ0giQBAQEDAQEBARpRCwUHBAIBCBIDAQIKJCEGCxcOAgQOAwIIBodwAwkGDKtNhDgNiFoEjVWBNAGBFTEHgxt3A5AWgS6EN44UhSeBYYE6QIFq X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="asc'?scan'208";a="247312229" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 14 Aug 2013 18:12:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7EICdp1027501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 18:12:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 13:12:38 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: AQHOmNTIGXq8y8N2nUWzTz3+dH/OQ5mVVeEA Date: Wed, 14 Aug 2013 18:12:37 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E05EE8@xmb-aln-x02.cisco.com> References: <51F8ED88.5050208@cisco.com> <02fb01ce98d1$6a6c6ac0$4001a8c0@gateway.2wire.net> <520B54A2.1080107@joelhalpern.com> In-Reply-To: <520B54A2.1080107@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_259C7F46-3592-4C90-875A-BA9D5C0D0FDC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "Joe Clarke \(jclarke\)" , "t.petch" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:12:46 -0000 --Apple-Mail=_259C7F46-3592-4C90-875A-BA9D5C0D0FDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joel, On Aug 14, 2013, at 5:57 AM, Joel M. Halpern = wrote: > The virtual router question is an interesting one. I believe that the = answer is "it depends". > On the one hand there is a base device. There may or may not need to = be capability for I2RS access to that entity. It seems to me that this is dependent on whether the device is part of = the routing system -- not whether it is physical or virtual. Does it = have a RIB, participates in routing, and an interface to routing? If the = answer is yes, then I2RS needs access (whether the base device or an = individual virtual one). > Then there are the individual virtual routers. My inclination would = be to use separate I2RS clients, each with a separate I2RS identity and = identifier. I agree with this (assuming you meant to write "I2RS agent" or "I2RS = server" instead of "I2RS client") -- basically, if it is a node in the = topology, it needs its I2RS identity. > But there appears to be enough flexibility in the modeling that we = are discussing that one could probably model it as one I2RS agent with = various pieces and parts. In which case that one agent has only one = identity and one identifier. >=20 I think there's potentially more than this, namely: proposed I2RS = topology information models support node aggregation / virtual = topologies. Shouldn't each node at a different level of the hierarchy = have its own identity (and identifier)? Thanks, -- Carlos. > Yours, > Joel >=20 > On 8/14/13 5:24 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Alia Atlas" >> To: "Joe Marcus Clarke" >> Cc: >> Sent: Tuesday, August 13, 2013 9:01 PM >>=20 >>=20 >>> Hi Joe, >>>=20 >>> Thanks for the detailed review and suggestions. Responses are >> in-line. >>>=20 >>> Alia >>>=20 >>> On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke >> wrote: >>>=20 >> >>>> Section 6.4: >>>>=20 >>>> Each I2RS Client will have an identity; it can also have secondary >>>> identities to be used for troubleshooting. >>>>=20 >>>> JMC: Each application will have a _unique_ identity. >>>>=20 >>>=20 >>> [Alia] Hmm, this ties into the discussion about how we want to = handle >>> redundancy and recovery for clients. It's also a bit of a >> tautology - a >>> client is solely identified by its identity. I have changed it to >> say >>> that "Each I2RS Client will have a unique identity" - but that just >> helps >>> clarify the intent. >>=20 >> I think that this nicely encapsulates a confusion between identity = and >> identifier. Identifiers identify. Objects, in a very generic sense, >> have identity. Thus if a human being is an instance of an object, = they >> may be identified, based on context, by SSN, passport number, name, = name >> and date of birth, cell phone number etc; all could be valid >> identifiers: but equally, a cell phone number could be the identifier = of >> a cell phone, which is associated with a function and multiple = people, >> while the cell phone could also be identified by its IMEI so the >> determination of what is an identity, may take some consideration. = This >> is often critical in security; you have a secure channel but with = what? >> Is the identifier sufficient proof of the identity? >>=20 >> Working with routers, you usually have multiple identifiers; the SNMP >> sysName is not (usually) the OSPF 32 bit router id, while the BGP >> Identifier (note, identifier) is different again. >>=20 >> Identifiers exist within a namespace, with rules about syntax, >> uniqueness and so on (even if this are not made explicit). >>=20 >> The revised I-D contains >> " A secondary identity is merely a unique, opaque identifier ..." >> and >> "An I2RS Client may supply a secondary opaque identity .." >>=20 >> I think that most uses of the word "identity" in this I-D are = actually >> referring to "identifier" but at the same time, given that almost all >> routers have multiple identifiers (as above), then this issue, of the >> difference between identity and identifier needs making explicit in = this >> I-D. >>=20 >> Tom Petch >>=20 >> (p.s. if you have multiple virtual routers in one physical router, = how >> many identities are there? Discuss.) >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_259C7F46-3592-4C90-875A-BA9D5C0D0FDC 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 - http://gpgtools.org iEYEARECAAYFAlILyJkACgkQtfDPGTp3USyKhgCcDmzkGH7jQ4AWsyeZrIt0nk1c PsoAnjSYZKpw/wPwwlBBsqHG1CTxcx/W =npan -----END PGP SIGNATURE----- --Apple-Mail=_259C7F46-3592-4C90-875A-BA9D5C0D0FDC-- From jakob.heitz@ericsson.com Wed Aug 14 11:14:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B480D21F9298 for ; Wed, 14 Aug 2013 11:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSxVoy8Lr0Zm for ; Wed, 14 Aug 2013 11:14:19 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70711E8159 for ; Wed, 14 Aug 2013 11:14:14 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-f9-520bc8f3dbfc Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 77.E6.09414.3F8CB025; Wed, 14 Aug 2013 20:14:12 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 14 Aug 2013 14:14:02 -0400 From: Jakob Heitz To: "Joel M. Halpern" , Joe Marcus Clarke Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: AQHOjdzg9+OhiQQtoUuo5/IEhGkdipmT5y0AgAFrKQCAAAIEgP//wInQ Date: Wed, 14 Aug 2013 18:14:01 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> <520BC2F9.9080500@joelhalpern.com> In-Reply-To: <520BC2F9.9080500@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPuO6XE9xBBj+u81t8eniJ2WLdjA8s Fvuu/mG0+HjqDZMDi8eU3xtZPXbOusvusWTJTyaPc1O+MwawRHHZpKTmZJalFunbJXBlrO3/ yFJwrqDi/JV77A2MD0K6GDk5JARMJPZ/PsIIYYtJXLi3nq2LkYtDSOAoo8SEd22sEM5yRokZ 056wglSxCehIfLvexQxiiwiESLR032EBsZkFnCX6b3SzdzFycAgLxEq8m2kNURIn0dW4Aarc TWJLz1awZSwCqhJ/Vh4Fi/MK+Eqc2/2GEWLXD0aJrS/3giU4BfQlpnxewgZiMwJd9/3UGiaI XeISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWxlie9zHkHdpiOxYPcnNghbW2LZwtdQiwUlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRgabGIHxdEyCTXcH456XlocYpTlYlMR5 V+mdCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWBybZM94yU2wfsP6Fc4Rt2KjnUP+lgnN ad0U2sLG+SOVe71/psdf94nf+p9qp7vVcd60u5L20kFvf2ej7OVLQUf8fszWDRNPCqu2+F+c HBKU6vSxvn2thlNF7ZZfO9QfLxaukwtyk0mbsKD4+fJrnulTNV8u3eoTUK8aeTaQheOmlGTH lGYlluKMREMt5qLiRACgQdN9dQIAAA== Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:14:24 -0000 Or say: "must write atomically". Here is one way: In the WRITE message, put the value you want to write, as well as the value= that you think that the parameter currently has. You can get the value "you think it has" from a previous READ, then you rep= eat that in your WRITE message. The target of the WRITE will refuse to write your value and return an error= if the value was not what you thought it was. Another way: READ with reservation. When you READ, then set a reservation. When anyone WRITEs the same parameter, it kills all reservations. When you WRITE, the target system checks if you have a reservation and refu= ses to write if you don't and returns an error. Or you can write lock the parameter. -- Jakob Heitz. > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: Wednesday, August 14, 2013 10:49 AM > To: Joe Marcus Clarke > Cc: i2rs@ietf.org; Alia Atlas > Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architectur= e-01 > (ends Aug 12) >=20 > Depending upon how one reads RFCs, declaring that having two writers is a= n > error is a MUST NOT write. > But we are also trying to recognize that no matter how many MUST NOT > statements we produce, things happen. So we are trying to define the > handling. I can live with precedence. I can live with "the item does no= t > change". But I do think it is helpful for us to be explicit about the be= havior in > this far-to-likely error case. >=20 > Yours, > Joel >=20 >=20 > On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: > > On 8/13/13 4:01 PM, Alia Atlas wrote: > >> Section 1.2: > >> > >> As can also be seen in Figure 1, an I2RS Agent may communicate wi= th > >> multiple clients. Each client may send the agent a variety of= write > >> operations. The handling of this situation has been a source = of > >> discussion in the working group. In order to keep the protoco= l > >> simple, the current view is that two clients should not be att= empting > >> to write (modify) the same piece of information. Such collisi= ons may > >> happen, but are considered error cases that should be resolved= by > the > >> network applications and management systems. > >> > >> JMC: I think more verbiage is needed around how to detect collisi= ons. > >> This is key to security considerations. Saying "clients should n= ot" is > >> not strong enough to keep our potential attackers. If each opera= tion is > >> tagged with an identifier that is unique to a client, then it wil= l be > >> possible to determine if the current client is trying to overwrit= e data > >> from a previous client. This could fold into authz as well where= there > >> is a permission to allow global override of other application's s= tate. > >> > >> > >> [Alia] For the I2RS Agent to properly handle a collision, it does > >> need to store the client identifier. I think that is clear in Sec > >> 5.2 "Simply, the I2RS agent stores who did what operation to which > entity." > >> and the details in Sec 6.8 are "The current recommendation is to have > >> a simple priority associated with each I2RS clients, and the highest > >> priority change remains in effect. In the case of priority ties, the > >> first client whose attribution is associated with the data will keep > >> control." We already have a reference to Sec 6.8 right there - and > >> that section is where the details are discussed. What specific additi= onal > >> verbiage do you think would be useful? The priority is a knob to all= ow > >> overwriting of other applications' state - though needing to is > >> considered an error. :-) > > > > When I first read this, I wanted something stronger to prevent clients > > from writing to the same piece of data. I think the forward > > references are fine if perhaps a bit late in the text. But my ask was > > to strengthen the language to say "must not write." > > > >> > >> > >> Section 2: > >> > >> read scope: ... > >> > >> write scope: ... > >> > >> JMC: Should there be an event or notification scope in addition t= o read > >> and write? > >> > >> > >> [Alia] I think it is folded into the read scope. If we find the need > >> for such a term later on, then we can add it. > > > > This section talks about "terminology" used in the draft. However, > > "read scope" as terminology is not used anywhere. The concept of > > _reading_ data is, however, quite prevalent. In the same way, the > > draft talks about "notification" in a number of contexts. As such, I > > feel there is enough distinction there to warrant calling out what is > > meant by a notification scope. > > > > "notification scope: The set of events and associated information that > > will be sent northbound by the I2RS Agent to I2RS Clients. Clients > > have the ability to register for specific events, but must do so given > > the access restrictions of their associated read scope." > > > >> > >> Section 3.4: > >> > >> I2RS clients may be operating on behalf of other applications. W= hile > >> those applications' identities are not need for authorization,= each > >> application should have a unique opaque identifier that can be > >> provided by the I2RS client to the I2RS agent for purposes of > >> tracking attribution of operations. > >> > >> JMC: The opaque ID might make it hard to accurately attribute cha= nges. > >> I2RS should mandate a way to ensure traceability back to a client= that > >> made the change or was granted access. > >> > >> > >> [Alia] What do you have in mind? The I2RS client will have a > >> security role and its scope. The I2RS client needs to vet the > >> applications that it is a broker for. The opaque ID can be something = that is > meaningful > >> to that I2RS client. Basically, I2RS is providing the identity and > >> security for between the I2RS client and the I2RS agent. I don't see > >> it as practical or appropriate to try and define how the I2RS client > >> and its applications interact; I know the broker/controller model is > >> popular and so we do need enough to help support traceability to a > >> secondary ID, but I'm not sure what is needed or appropriate beyond > that. > > > > After listening to the working group session and based on other > > threads, this text is now clearer to me. To summarize my feeling, I > > don't think I2RS should mandate a northbound Client protocol, but we > > need a unique way to identify the specific Client that obtained > > access. This means that even in a load-balancing or HA case, there > > must be a way to uniquely identify the Client that communicate with > > the Agent. The northbound actor driving the Client should also be > > identifiable, but that is outside the scope of this document. > > > >> Section 5.2.2: > >> > >> An I2RS Agent may decide that some state should no longer be appl= ied. > >> An I2RS Client may instruct an Agent to remove state it has ap= plied. > >> In all such cases, the state will revert to what it would have= been > >> without the I2RS; that state is generally whatever was specifi= ed via > >> the CLI, NetConf, SNMP, etc. I2RS Agents will not store multi= ple > >> alternative states, nor try to determine which one among such = a > >> plurality it should fall back to. Thus, the model followed is= not > >> like the RIB, where multiple routes are stored at different > >> preferences. > >> > >> JMC: Previously I had commented that one event that should be > supported > >> and perhaps documented here is that if the agent decides to rever= t the > >> application can be notified that its state has been reverted. Th= is > >> might also be useful if another client overrides some portion of = another > >> client's state (this is covered in Section 6.8, but might be usef= ul to > >> mention here as well). Perhaps add at the end of Section 5.2.2: > >> > >> "A client may choose to be notified whenever its state is rever= ted > >> either by another client or by the I2RS agent." > >> > >> > >> [Alia] I'll put in: "An I2RS Client may register for notifications > >> when state that was applied by a particular I2RS Client is modified > >> or removed." That is slightly different since it allows an I2RS > >> Client to learn about the changes to state from itself or from a > >> different I2RS Client. > > > > WFM, thanks. > > > >> > >> Section 5.4.2: > >> > >> (Bulleted list of examples) > >> > >> JMC: Consider adding an example for an event such as a new route > being > >> learned or an OSPF neighbor removal. > >> > >> > >> [Alia] I think that "writing routes or prefixes to be advertised via t= he > >> protocol" describes a new route being learned. I'd prefer not to put > >> OSPF neighbor removal in as an example. It raises the questions > >> about what is configuration vs. ephemeral data and the I2RS scope. > >> If you have a good use-case that requires it, then I'd be quite > >> interested in seeing it. > > > > I was specifically asking about an _event_ use case. Very simply if > > we learn/lose a route, I'd want my Client to be notified so I can > > perhaps react to it to install another route or remove a route I have > > previously installed (e.g., a failover/failback use case). > > > > Additionally, if a peer is otherwise reachable, but stops > > participating in OSPF, BGP, etc., I would like I2RS to notify my > > Client as I may not know about this any other way (though I could be > > flooded with route delete events, it's good to correlate that to a peer= going > away). > > > >> > >> > >> > >> Section 5.4.4: > >> > >> Many network elements have separate policy and QoS mechanisms, > >> including knobs which affect local path computation and queue > control > >> capabilities. These capabilities vary widely across implement= ations, > >> and I2RS cannot model the full range of information collection= or > >> manipulation of these attributes. A core set does need to be > >> included in the I2RS data models and in the expected interface= s > >> between the I2RS Agent and the network element, in order to > provide > >> basic capabilities and the hooks for future extensibility. > >> > >> JMC: I think this either needs an editor's note for more discussi= on or > >> perhaps QoS in general should be out of scope. > >> > >> > >> [Alia] I am happy to add in an editor's note for more discussion - > >> but we should start that conversation now on the list - because the > >> WG does have quite tight deadlines for milestones. > > > > Fair enough. > > > >> Section 6.1: > >> > >> That protocol may use several underlying transports (TCP, > >> SCTP, DCCP), with suitable authentication and integrity protec= tion > >> mechanisms. Whatever transport is used for the data exchange,= it > >> must also support suitable congestion control mechanisms. > >> > >> JMC: I think Carlos (or someone) mentioned this, but I'm not sure= DCCP > >> is ideal for I2RS since we likely do want reliable order of deliv= ery. > >> > >> > >> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - > >> but it may be > >> good for delivering statistics. I think we'll have different transpo= rt > >> options depending on the requirements of a particular data model or > >> section. Since you are the second person to be confused by that > >> section, I've added the following sentence: > >> > >> "These different transports can support different types of > >> communication (e.g. control, reading, notifications, and information > >> collection) and different sets of data." > >> > >> Let me know if that helps or if you have better ideas for wording. > > > > That works. > > > >> Section 6.7: > >> > >> One of the other important aspects of the I2RS is that it is inte= nded > >> to simplify collecting information about the state of network > >> elements. > >> > >> JMC: I think this needs to be more specific to routing informatio= n > >> versus any information from the network element (e.g., it does no= t > cover > >> CPU statistics). > >> > >> > >> [Alia] The scoping is a question - and that will depend on what the > >> use-cases we consider need and what the related information and data > >> models need to be. If you look at the > >> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU > >> load. I do think there is a real need to be able to get back > >> thresholded and filtered information. You probably heard Ed's persona= l > >> thoughts about a single protocol as well... So - I don't think the > >> architecture needs to restrict the data in scope - particular in a > >> section that is talking about communication patterns - but as a WG, > >> we need to keep a tight focus that still provides sufficient > >> information to fully solve the desired use-cases. > > > > My concerns comes from a desire not to have I2RS become a common > > API/protocol for things that SNMP or NETCONF or some other potential > > data collection scheme is used for. So I agree we need a tight focus > > and potentially a litmus test for what should be adopted as > > collectable data via I2RS. As it stands now, I think someone could > > argue for any kind of data and present a use case for it (e.g., > > latency, interface errors, location). So the statement I made was > > more around the lines of should I2RS stay pure to routing and routed > > topology or should we really open the door to other data that is not > specifically related to routing? > > > > Joe > > > >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From cpignata@cisco.com Wed Aug 14 11:23:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFF011E818C for ; Wed, 14 Aug 2013 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5SB0PNUXkRi for ; Wed, 14 Aug 2013 11:23:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 90B5111E818E for ; Wed, 14 Aug 2013 11:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25569; q=dns/txt; s=iport; t=1376504580; x=1377714180; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6Y9EJMJTa29csGUnlirq2W7GSoPLykalhKHFbz0fG/Q=; b=RNpjvL1fd/smZ+72LbRDvP/X+6buFpWEiDE5qDmhuqB86JvtFgtLOwFr vpFJkg3yXneeTpHLyJgTiKzm6oI3rJ6xguIF3Sn1JsB/kq8RhwBRCnNWq UBwL3Wur1jt5UO4zEzTVvV5lIxTWH+BAoqWb6u5enx43oykbfIFMB970B E=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFjKC1KtJXHB/2dsb2JhbABSCYMGNVC+ZIEkFnSCJAEBAQMBAQEBGlABCwULAgEIDgQGCiQhBgsXDgIEDgUIBodwAwkGDLAKDYhaBI1VgTWBFS0EB4MbdwOQFoEuhDeOFIUngWGBOoIq X-IronPort-AV: E=Sophos;i="4.89,878,1367971200"; d="asc'?scan'208,217";a="247362338" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2013 18:22:59 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7EIMxV5020567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 18:22:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 13:22:59 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: AQHOmFUo5SKjz944LEeZl5/zrw1QapmVWcWA Date: Wed, 14 Aug 2013 18:22:58 +0000 Message-ID: <95067C434CE250468B77282634C96ED322E0602D@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322D5EDE4@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.50] Content-Type: multipart/signed; boundary="Apple-Mail=_47E1AECA-89DE-4F97-A667-7AE9EBFE1F2D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:23:06 -0000 --Apple-Mail=_47E1AECA-89DE-4F97-A667-7AE9EBFE1F2D Content-Type: multipart/alternative; boundary="Apple-Mail=_7BCBECAC-9C27-432C-9C54-8D8C75F4007F" --Apple-Mail=_7BCBECAC-9C27-432C-9C54-8D8C75F4007F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks for all the responses, Alia. Please find some follow-ups inline. On Aug 13, 2013, at 2:44 PM, Alia Atlas wrote: > Hi Carlos, >=20 > Thanks for the review and comments. I apologize for the delay in = responding. I took some vacation after IETF. >=20 >=20 > On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) = wrote: > I support I2RS adoption of this document. >=20 > This is a very solid start with a very well written individual draft. >=20 > I also take the chance to share some questions and provide some review = feedback (with "CMP"): >=20 > An Architecture for the Interface to the Routing System > draft-atlas-i2rs-architecture-01 >=20 > 1. Introduction >=20 > The I2RS, and therefore this document, are specifically focused on = an > interface for routing and forwarding data. >=20 > CMP: "and forwarding data"? Ultimately the interface will influence = forwarding, but is it focused on it? > [Alia] True - I've removed "and forwarding data"=20 > =20 > 1.2. Architectural Overview >=20 > Routing: This block represents that portion of the Routing = Element > that implements part of the Internet routing system. It = includes > not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, > RSVP-TE, LDP, etc.), but also the RIB Manager layer. >=20 > CMP: Things like LDP and RSVP-TE are counted as "routing". It is not = clear to me that we might want to lump it together here, and frankly = what the scope for these things is. I suspect it might be worth = clarifying the reach and scope of these. >=20 > [Alia] I see them as grouped into "routing and signaling" and = definitely part of I2RS. The problem-statement draft (not a WG draft = yet) clearly states:=20 > "In addition to interfaces to the RIB layer, there is a need to = configure the various routing and signaling protocols with differing = dynamic state based upon application-level policy decisions." and the = framework draft that this architecture replaces had a slightly larger = section on use-cases and examples. >=20 > What is your specific concern and how would you want to see the reach = and scope confined in the architecture draft? > =20 Perhaps simply by aligning with the problem statement wording, in terms = of "routing and signaling". Or is the "signaling" piece confined to = label distribution? >=20 > I2RS Client: ... It interacts with the I2RS clients to collect = information > from the routing and forwarding system. >=20 > CMP: I also wonder whether these references to interaction with the = "Forwarding system" refer to MPLS dataplane encap or are further = reaching, and how. For example, creating a Tunnel would not be = "forwarding". >=20 > [Alia] First, the I2RS clients should be I2RS agents. I've fixed = that. Second, these are a bit further reaching. For instance, learning = about link up/down events, subscribing to counters for when they go over = a particular threshold, etc. Basically, to provide the information = necessary for a network application's feedback loop, information outside = of the routing system may be necessary to read/learn. The exact details = will depend on the use-cases and proposed info-models. >=20 > Do you think that a text change is needed? If so, what would you = suggest? Thanks for the clarification -- this works. > =20 >=20 > 2. Terminology >=20 > identity: A client is associated with exactly one specific > identity. State can be attributed to a particular identity. It > is possible for multiple communication channels to use the same > identity; in that case, the assumption is that the associated > client is coordinating such communication. >=20 > CMP: It seems to me that the "client identity" is necessary, but = sometimes not sufficient. I recall seeing an "Application Identity" = somewhere in this document, and wonder if that concept should not be = elevated in the requirement priority. >=20 > [Alia] Sure, it's clear that the broker model is of interest. I'll = add in >=20 > secondary identity: An I2RS Client may supply a secondary opaque = identity that is not interpreted by the I2RS Agent. An example use is = when the I2RS Client is a go-between for multiple > applications and it is necessary to track which application has > requested a particular operation. > =20 > 3.4. Authorization and Authentication >=20 > I2RS clients may be operating on behalf of other applications. = While > those applications' identities are not need for authorization, each > application should have a unique opaque identifier that can be > provided by the I2RS client to the I2RS agent for purposes of > tracking attribution of operations. >=20 > CMP: It seems to me that the identity of an application is also = critical for Accounting (and troubleshooting). >=20 > [Alia] Yes, tracking the attribution of operations allows aspects like = accounting and troubleshooting. I've modified the sentence to end: >=20 > ...identifier that can be provided by the I2RS client to the I2RS = agent for purposes of tracking > attribution of operations to support functionality such as accounting = and troubleshooting. >=20 > 4. Network Applications and I2RS Client >=20 > When an I2RS Client interacts with multiple network applications, > that I2RS Client is behaving as a go-between and may indicate this = to > the I2RS Agents by, for example, specifying a secondary opaque > identity to allow improved troubleshooting. >=20 > CMP: Should this be stronger than a "may indicate"? >=20 > [Alia] Sure - I'll upgrade it to "should indicate". This is a = question of supporting the broker model of an I2RS client for ease of = troubleshooting. > =20 >=20 > 4.1. Example Network Application: Topology Manager >=20 > One example of such an application is a Topology Manager. Such an > application includes an I2RS client which uses the I2RS protocol to > collect information about the state of the network. The Topology > Manager would collect device and interface state from devices it > interacts with directly. >=20 > CMP: Tunnels are some times key elements in a topology. Are tunnels = considered as "interfaces" or should those be called out explicitly? >=20 > [Alia] Tunnels aren't interfaces - but the details of what should be = in the topology depends on the topology info-model and isn't specified = in the architecture. > =20 Fair enough -- I agree it's not within the scope here, but I do thing = that tunnels require some looking into. > 5.4.1. Unicast and Multicast RIB and LFIB >=20 > Network elements concerned with routing IP maintain IP unicast = RIBs. > Similarly, there are RIBs for IP Multicast, and a Label Information > Base (LIB) for MPLS. >=20 > and >=20 > 5.4.3. MPLS >=20 > The I2RS Agent will need to interact with the knobs that policy > attributes that control LDP operation as well as RSVP-TE based = LSPs. >=20 > CMP: While I think that programmatically interfacing with MPLS = information is useful, the case is not clearly described in the problem = statement, nor it seems to be captured comprehensively here. Section = 5.4.3 includes only a big broad statement, but it's not clear which = elements of label distribution protocols (i.e., BGP also seems missing = here) are relevant to I2RS. >=20 > [Alia] BGP is already mentioned as a protocol that will need an = info-model. I guess I think of this section as discussing the transport = LSPs and associated protocols as compared to the MPLS services. The = MPLS services are part of routing and should be included too. I've = changed the text in Sec 5.4.3 to read: >=20 > "The I2RS agent will need to interact with the protocols that create > transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, > LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, > L2VPNs, etc)." >=20 >=20 > =20 > 6.1. Protocol Structure >=20 > protocol. That protocol may use several underlying transports = (TCP, > SCTP, DCCP), with suitable authentication and integrity protection >=20 > CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP? >=20 > [Alia] There may be cases of data streams that don't require a = reliable underlying transport. I'm thinking about providing statistics = streams. I am concerned about the issues with timely delivery that can = arise with TCP - but I think that what transport protocol is appropriate = will depend a bit on what data is being delivered. > =20 > Thanks again for the detailed review and questions, >=20 Blanked Ack for all the edits and fixes. Thanks much! -- Carlos. PS: and thanks for not responding earlier, others were on vacation as = well :-) > Alia >=20 > Thanks, >=20 > -- Carlos. >=20 >=20 > On Jul 24, 2013, at 11:52 PM, Alia Atlas wrote: >=20 > > Please review draft-atlas-i2rs-architecture-01 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. > > > > Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details). > > > > This WG call for adoption will complete on August 12. > > > > Thanks, > > Alia > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_7BCBECAC-9C27-432C-9C54-8D8C75F4007F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Thanks for all the responses, Alia.

Please find some follow-ups inline.

On Aug 13, 2013, at 2:44 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Carlos,

Thanks for the review and comments.  I apologize for the delay in responding.  I took some vacation after IETF.


On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
I support I2RS adoption of this document.

This is a very solid start with a very well written individual draft.

I also take the chance to share some questions and provide some review feedback (with "CMP"):

        An Architecture for the Interface to the Routing System
                    draft-atlas-i2rs-architecture-01

1.  Introduction

   The I2RS, and therefore this document, are specifically focused on an
   interface for routing and forwarding data.

CMP: "and forwarding data"? Ultimately the interface will influence forwarding, but is it focused on it?
[Alia] True - I've removed "and forwarding data" 
 
1.2.  Architectural Overview

   Routing:   This block represents that portion of the Routing Element
      that implements part of the Internet routing system.  It includes
      not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM,
      RSVP-TE, LDP, etc.), but also the RIB Manager layer.

CMP: Things like LDP and RSVP-TE are counted as "routing". It is not clear to me that we might want to lump it together here, and frankly what the scope for these things is. I suspect it might be worth clarifying the reach and scope of these.

[Alia] I see them as grouped into "routing and signaling" and definitely part of I2RS.  The problem-statement draft (not a WG draft yet) clearly states: 
"In addition to interfaces to the RIB layer, there is a need to configure the various routing and signaling protocols with differing dynamic state based upon application-level policy decisions." and the framework draft that this architecture replaces had a slightly larger section on use-cases and examples.

What is your specific concern and how would you want to see the reach and scope confined in the architecture draft?
 

Perhaps simply by aligning with the problem statement wording, in terms of "routing and signaling". Or is the "signaling" piece confined to label distribution?


   I2RS Client:   ...  It interacts with the I2RS clients to collect information
      from the routing and forwarding system.

CMP: I also wonder whether these references to interaction with the "Forwarding system" refer to MPLS dataplane encap or are further reaching, and how. For example, creating a Tunnel would not be "forwarding".

[Alia]  First, the I2RS clients should be I2RS agents.  I've fixed that.  Second, these are a bit further reaching.  For instance, learning about link up/down events, subscribing to counters for when they go over a particular threshold, etc.  Basically, to provide the information necessary for a network application's feedback loop, information outside of the routing system may be necessary to read/learn.  The exact details will depend on the use-cases and proposed info-models.

Do you think that a text change is needed?  If so, what would you suggest?

Thanks for the clarification -- this works.

 

2.  Terminology

   identity:   A client is associated with exactly one specific
      identity.  State can be attributed to a particular identity.  It
      is possible for multiple communication channels to use the same
      identity; in that case, the assumption is that the associated
      client is coordinating such communication.

CMP: It seems to me that the "client identity" is necessary, but sometimes not sufficient. I recall seeing an "Application Identity" somewhere in this document, and wonder if that concept should not be elevated in the requirement priority.

[Alia] Sure, it's clear that the broker model is of interest.  I'll add in

   secondary identity:  An I2RS Client may supply a secondary opaque identity that is not interpreted by the I2RS Agent. An example use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has
requested a particular operation.
 
3.4.  Authorization and Authentication

   I2RS clients may be operating on behalf of other applications.  While
   those applications' identities are not need for authorization, each
   application should have a unique opaque identifier that can be
   provided by the I2RS client to the I2RS agent for purposes of
   tracking attribution of operations.

CMP: It seems to me that the identity of an application is also critical for Accounting (and troubleshooting).

[Alia] Yes, tracking the attribution of operations allows aspects like accounting and troubleshooting.  I've modified the sentence to end:

...identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking
attribution of operations to support functionality such as accounting and troubleshooting.

4.  Network Applications and I2RS Client

   When an I2RS Client interacts with multiple network applications,
   that I2RS Client is behaving as a go-between and may indicate this to
   the I2RS Agents by, for example, specifying a secondary opaque
   identity to allow improved troubleshooting.

CMP: Should this be stronger than a "may indicate"?

[Alia] Sure - I'll upgrade it to "should indicate".  This is a question of supporting the broker model of an I2RS client for ease of troubleshooting.
 

4.1.  Example Network Application: Topology Manager

   One example of such an application is a Topology Manager.  Such an
   application includes an I2RS client which uses the I2RS protocol to
   collect information about the state of the network.  The Topology
   Manager would collect device and interface state from devices it
   interacts with directly.

CMP: Tunnels are some times key elements in a topology. Are tunnels considered as "interfaces" or should those be called out explicitly?

[Alia] Tunnels aren't interfaces - but the details of what should be in the topology depends on the topology info-model and isn't specified in the architecture.
 

Fair enough -- I agree it's not within the scope here, but I do thing that tunnels require some looking into.

5.4.1.  Unicast and Multicast RIB and LFIB

   Network elements concerned with routing IP maintain IP unicast RIBs.
   Similarly, there are RIBs for IP Multicast, and a Label Information
   Base (LIB) for MPLS.

and

5.4.3.  MPLS

   The I2RS Agent will need to interact with the knobs that policy
   attributes that control LDP operation as well as RSVP-TE based LSPs.

CMP: While I think that programmatically interfacing with MPLS information is useful, the case is not clearly described in the problem statement, nor it seems to be captured comprehensively here. Section 5.4.3 includes only a big broad statement, but it's not clear which elements of label distribution protocols (i.e., BGP also seems missing here) are relevant to I2RS.

[Alia] BGP is already mentioned as a protocol that will need an info-model.  I guess I think of this section as discussing the transport LSPs and associated protocols as compared to the MPLS services.  The MPLS services are part of routing and should be included too.  I've changed the text in Sec 5.4.3 to read:

"The I2RS agent will need to interact with the protocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc)."


 
6.1.  Protocol Structure

   protocol.  That protocol may use several underlying transports (TCP,
   SCTP, DCCP), with suitable authentication and integrity protection

CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP?

[Alia] There may be cases of data streams that don't require a reliable underlying transport.  I'm thinking about providing statistics streams.   I am concerned about the issues with timely delivery that can arise with TCP - but I think that what transport protocol is appropriate will depend a bit on what data is being delivered.
 
Thanks again for the detailed review and questions,


Blanked Ack for all the edits and fixes. Thanks much!

-- Carlos.
PS: and thanks for not responding earlier, others were on vacation as well :-)

Alia

Thanks,

-- Carlos.


On Jul 24, 2013, at 11:52 PM, Alia Atlas <akatlas@gmail.com> wrote:

> Please review draft-atlas-i2rs-architecture-01 and comment on whether it should be adopted by I2RS.  Detailed technical conversation is also most welcome.
>
> Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--Apple-Mail=_7BCBECAC-9C27-432C-9C54-8D8C75F4007F-- --Apple-Mail=_47E1AECA-89DE-4F97-A667-7AE9EBFE1F2D 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 - http://gpgtools.org iEYEARECAAYFAlILywYACgkQtfDPGTp3USzUeQCeK2R1gQFiu6hjBa5197IPYsqV 0bMAn0WawNSVz/4mM2jJ7P4Mxfrfk+Zv =T3D9 -----END PGP SIGNATURE----- --Apple-Mail=_47E1AECA-89DE-4F97-A667-7AE9EBFE1F2D-- From jmh@joelhalpern.com Wed Aug 14 11:24:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679621F9A4C for ; Wed, 14 Aug 2013 11:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5fB+xOU61iT for ; Wed, 14 Aug 2013 11:24:25 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB511E8172 for ; Wed, 14 Aug 2013 11:24:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A2AF81422B1; Wed, 14 Aug 2013 11:24:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B005E1422BB; Wed, 14 Aug 2013 11:24:18 -0700 (PDT) Message-ID: <520BCB50.2040703@joelhalpern.com> Date: Wed, 14 Aug 2013 14:24:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jakob Heitz References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> <520BC2F9.9080500@joelhalpern.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Joe Marcus Clarke , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:24:38 -0000 write-locks / atomic writes are an interesting quesiton, but probably should not be thought about as part of the multiple writers case. The multiple writers case is: A writes value X. B decides to write value Y. How clever do we want to be about handling this. The answer we have proposed is "as simpleminded as we can get away with." The specifics we chose are 1) this is an error case 2) there are priorities which determine which value ends up in effect. Atomic writes could come up when there is a race, but more likely would come up when there are system effects which would change this value when it is not pinned by I2RS. Yours, Joel On 8/14/13 2:14 PM, Jakob Heitz wrote: > Or say: "must write atomically". > > Here is one way: > In the WRITE message, put the value you want to write, as well as the value that you think that the parameter currently has. > You can get the value "you think it has" from a previous READ, then you repeat that in your WRITE message. > The target of the WRITE will refuse to write your value and return an error if the value was not what you thought it was. > > Another way: > READ with reservation. When you READ, then set a reservation. > When anyone WRITEs the same parameter, it kills all reservations. > When you WRITE, the target system checks if you have a reservation and refuses to write if you don't and returns an error. > > Or you can write lock the parameter. > > -- > Jakob Heitz. > >> -----Original Message----- >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of >> Joel M. Halpern >> Sent: Wednesday, August 14, 2013 10:49 AM >> To: Joe Marcus Clarke >> Cc: i2rs@ietf.org; Alia Atlas >> Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 >> (ends Aug 12) >> >> Depending upon how one reads RFCs, declaring that having two writers is an >> error is a MUST NOT write. >> But we are also trying to recognize that no matter how many MUST NOT >> statements we produce, things happen. So we are trying to define the >> handling. I can live with precedence. I can live with "the item does not >> change". But I do think it is helpful for us to be explicit about the behavior in >> this far-to-likely error case. >> >> Yours, >> Joel >> >> >> On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: >>> On 8/13/13 4:01 PM, Alia Atlas wrote: >>>> Section 1.2: >>>> >>>> As can also be seen in Figure 1, an I2RS Agent may communicate with >>>> multiple clients. Each client may send the agent a variety of write >>>> operations. The handling of this situation has been a source of >>>> discussion in the working group. In order to keep the protocol >>>> simple, the current view is that two clients should not be attempting >>>> to write (modify) the same piece of information. Such collisions may >>>> happen, but are considered error cases that should be resolved by >> the >>>> network applications and management systems. >>>> >>>> JMC: I think more verbiage is needed around how to detect collisions. >>>> This is key to security considerations. Saying "clients should not" is >>>> not strong enough to keep our potential attackers. If each operation is >>>> tagged with an identifier that is unique to a client, then it will be >>>> possible to determine if the current client is trying to overwrite data >>>> from a previous client. This could fold into authz as well where there >>>> is a permission to allow global override of other application's state. >>>> >>>> >>>> [Alia] For the I2RS Agent to properly handle a collision, it does >>>> need to store the client identifier. I think that is clear in Sec >>>> 5.2 "Simply, the I2RS agent stores who did what operation to which >> entity." >>>> and the details in Sec 6.8 are "The current recommendation is to have >>>> a simple priority associated with each I2RS clients, and the highest >>>> priority change remains in effect. In the case of priority ties, the >>>> first client whose attribution is associated with the data will keep >>>> control." We already have a reference to Sec 6.8 right there - and >>>> that section is where the details are discussed. What specific additional >>>> verbiage do you think would be useful? The priority is a knob to allow >>>> overwriting of other applications' state - though needing to is >>>> considered an error. :-) >>> >>> When I first read this, I wanted something stronger to prevent clients >>> from writing to the same piece of data. I think the forward >>> references are fine if perhaps a bit late in the text. But my ask was >>> to strengthen the language to say "must not write." >>> >>>> >>>> >>>> Section 2: >>>> >>>> read scope: ... >>>> >>>> write scope: ... >>>> >>>> JMC: Should there be an event or notification scope in addition to read >>>> and write? >>>> >>>> >>>> [Alia] I think it is folded into the read scope. If we find the need >>>> for such a term later on, then we can add it. >>> >>> This section talks about "terminology" used in the draft. However, >>> "read scope" as terminology is not used anywhere. The concept of >>> _reading_ data is, however, quite prevalent. In the same way, the >>> draft talks about "notification" in a number of contexts. As such, I >>> feel there is enough distinction there to warrant calling out what is >>> meant by a notification scope. >>> >>> "notification scope: The set of events and associated information that >>> will be sent northbound by the I2RS Agent to I2RS Clients. Clients >>> have the ability to register for specific events, but must do so given >>> the access restrictions of their associated read scope." >>> >>>> >>>> Section 3.4: >>>> >>>> I2RS clients may be operating on behalf of other applications. While >>>> those applications' identities are not need for authorization, each >>>> application should have a unique opaque identifier that can be >>>> provided by the I2RS client to the I2RS agent for purposes of >>>> tracking attribution of operations. >>>> >>>> JMC: The opaque ID might make it hard to accurately attribute changes. >>>> I2RS should mandate a way to ensure traceability back to a client that >>>> made the change or was granted access. >>>> >>>> >>>> [Alia] What do you have in mind? The I2RS client will have a >>>> security role and its scope. The I2RS client needs to vet the >>>> applications that it is a broker for. The opaque ID can be something that is >> meaningful >>>> to that I2RS client. Basically, I2RS is providing the identity and >>>> security for between the I2RS client and the I2RS agent. I don't see >>>> it as practical or appropriate to try and define how the I2RS client >>>> and its applications interact; I know the broker/controller model is >>>> popular and so we do need enough to help support traceability to a >>>> secondary ID, but I'm not sure what is needed or appropriate beyond >> that. >>> >>> After listening to the working group session and based on other >>> threads, this text is now clearer to me. To summarize my feeling, I >>> don't think I2RS should mandate a northbound Client protocol, but we >>> need a unique way to identify the specific Client that obtained >>> access. This means that even in a load-balancing or HA case, there >>> must be a way to uniquely identify the Client that communicate with >>> the Agent. The northbound actor driving the Client should also be >>> identifiable, but that is outside the scope of this document. >>> >>>> Section 5.2.2: >>>> >>>> An I2RS Agent may decide that some state should no longer be applied. >>>> An I2RS Client may instruct an Agent to remove state it has applied. >>>> In all such cases, the state will revert to what it would have been >>>> without the I2RS; that state is generally whatever was specified via >>>> the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple >>>> alternative states, nor try to determine which one among such a >>>> plurality it should fall back to. Thus, the model followed is not >>>> like the RIB, where multiple routes are stored at different >>>> preferences. >>>> >>>> JMC: Previously I had commented that one event that should be >> supported >>>> and perhaps documented here is that if the agent decides to revert the >>>> application can be notified that its state has been reverted. This >>>> might also be useful if another client overrides some portion of another >>>> client's state (this is covered in Section 6.8, but might be useful to >>>> mention here as well). Perhaps add at the end of Section 5.2.2: >>>> >>>> "A client may choose to be notified whenever its state is reverted >>>> either by another client or by the I2RS agent." >>>> >>>> >>>> [Alia] I'll put in: "An I2RS Client may register for notifications >>>> when state that was applied by a particular I2RS Client is modified >>>> or removed." That is slightly different since it allows an I2RS >>>> Client to learn about the changes to state from itself or from a >>>> different I2RS Client. >>> >>> WFM, thanks. >>> >>>> >>>> Section 5.4.2: >>>> >>>> (Bulleted list of examples) >>>> >>>> JMC: Consider adding an example for an event such as a new route >> being >>>> learned or an OSPF neighbor removal. >>>> >>>> >>>> [Alia] I think that "writing routes or prefixes to be advertised via the >>>> protocol" describes a new route being learned. I'd prefer not to put >>>> OSPF neighbor removal in as an example. It raises the questions >>>> about what is configuration vs. ephemeral data and the I2RS scope. >>>> If you have a good use-case that requires it, then I'd be quite >>>> interested in seeing it. >>> >>> I was specifically asking about an _event_ use case. Very simply if >>> we learn/lose a route, I'd want my Client to be notified so I can >>> perhaps react to it to install another route or remove a route I have >>> previously installed (e.g., a failover/failback use case). >>> >>> Additionally, if a peer is otherwise reachable, but stops >>> participating in OSPF, BGP, etc., I would like I2RS to notify my >>> Client as I may not know about this any other way (though I could be >>> flooded with route delete events, it's good to correlate that to a peer going >> away). >>> >>>> >>>> >>>> >>>> Section 5.4.4: >>>> >>>> Many network elements have separate policy and QoS mechanisms, >>>> including knobs which affect local path computation and queue >> control >>>> capabilities. These capabilities vary widely across implementations, >>>> and I2RS cannot model the full range of information collection or >>>> manipulation of these attributes. A core set does need to be >>>> included in the I2RS data models and in the expected interfaces >>>> between the I2RS Agent and the network element, in order to >> provide >>>> basic capabilities and the hooks for future extensibility. >>>> >>>> JMC: I think this either needs an editor's note for more discussion or >>>> perhaps QoS in general should be out of scope. >>>> >>>> >>>> [Alia] I am happy to add in an editor's note for more discussion - >>>> but we should start that conversation now on the list - because the >>>> WG does have quite tight deadlines for milestones. >>> >>> Fair enough. >>> >>>> Section 6.1: >>>> >>>> That protocol may use several underlying transports (TCP, >>>> SCTP, DCCP), with suitable authentication and integrity protection >>>> mechanisms. Whatever transport is used for the data exchange, it >>>> must also support suitable congestion control mechanisms. >>>> >>>> JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP >>>> is ideal for I2RS since we likely do want reliable order of delivery. >>>> >>>> >>>> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - >>>> but it may be >>>> good for delivering statistics. I think we'll have different transport >>>> options depending on the requirements of a particular data model or >>>> section. Since you are the second person to be confused by that >>>> section, I've added the following sentence: >>>> >>>> "These different transports can support different types of >>>> communication (e.g. control, reading, notifications, and information >>>> collection) and different sets of data." >>>> >>>> Let me know if that helps or if you have better ideas for wording. >>> >>> That works. >>> >>>> Section 6.7: >>>> >>>> One of the other important aspects of the I2RS is that it is intended >>>> to simplify collecting information about the state of network >>>> elements. >>>> >>>> JMC: I think this needs to be more specific to routing information >>>> versus any information from the network element (e.g., it does not >> cover >>>> CPU statistics). >>>> >>>> >>>> [Alia] The scoping is a question - and that will depend on what the >>>> use-cases we consider need and what the related information and data >>>> models need to be. If you look at the >>>> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU >>>> load. I do think there is a real need to be able to get back >>>> thresholded and filtered information. You probably heard Ed's personal >>>> thoughts about a single protocol as well... So - I don't think the >>>> architecture needs to restrict the data in scope - particular in a >>>> section that is talking about communication patterns - but as a WG, >>>> we need to keep a tight focus that still provides sufficient >>>> information to fully solve the desired use-cases. >>> >>> My concerns comes from a desire not to have I2RS become a common >>> API/protocol for things that SNMP or NETCONF or some other potential >>> data collection scheme is used for. So I agree we need a tight focus >>> and potentially a litmus test for what should be adopted as >>> collectable data via I2RS. As it stands now, I think someone could >>> argue for any kind of data and present a use case for it (e.g., >>> latency, interface errors, location). So the statement I made was >>> more around the lines of should I2RS stay pure to routing and routed >>> topology or should we really open the door to other data that is not >> specifically related to routing? >>> >>> Joe >>> >>>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Wed Aug 14 11:27:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6105721F9D2E for ; Wed, 14 Aug 2013 11:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StLgnbTu5W1J for ; Wed, 14 Aug 2013 11:27:16 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96321F9A4C for ; Wed, 14 Aug 2013 11:27:04 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so11715297obp.8 for ; Wed, 14 Aug 2013 11:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pKcn0zUnXjPryrVnwtoHOLkQLOtCwqdWLWYZmgvV20c=; b=ZkoO7dV8we0bwHogVAERtFJXg8ULQyraW/ZAkZQAlOh0KRbgA6q3AhOVZ1JYK2rRDo 3x6msuuRQzii7+Ao++PUPkMri+HhBicq4csan5c9O0KKqV3hhuwjdPNHybTnd63PNdXJ HagfJmgdb33teIq04Zo0+8geCRPO1iYQ0gYQUt3LBuigyUQVjsROWKPq3tu0km4HHNTm YE5ADdYgo0d8k+JJbMOhL5WcSHeg/M/RY1XB40Q5bO73NJkIr+b31TQWJD+6kF3pBWnp gOsTI7rBFzOo4Q4RuLpykccVxPyfK4H8HZelkEhOcPq+AKDc/7QQzrbWSRqMSOMvav9d +ihw== MIME-Version: 1.0 X-Received: by 10.182.33.4 with SMTP id n4mr21734888obi.19.1376504820940; Wed, 14 Aug 2013 11:27:00 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 11:27:00 -0700 (PDT) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> <520BC2F9.9080500@joelhalpern.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> Date: Wed, 14 Aug 2013 14:27:00 -0400 Message-ID: From: Alia Atlas To: Jakob Heitz , Ron Bonica Content-Type: multipart/alternative; boundary=089e0158ae38e246ff04e3ec807d Cc: Joe Marcus Clarke , "Joel M. Halpern" , "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 18:27:20 -0000 --089e0158ae38e246ff04e3ec807d Content-Type: text/plain; charset=ISO-8859-1 I'd discussed the problem of depending on read values to write - whether the same value or a different one - with Ron Bonica a while ago. I rather like your WRITE operation idea - where one could generalize to be able to specify other parameters as well. Thus, it could be WRITE X <-p if Y=n and Z=m - or the simple X <- p if X==q. Alia On Wed, Aug 14, 2013 at 2:14 PM, Jakob Heitz wrote: > Or say: "must write atomically". > > Here is one way: > In the WRITE message, put the value you want to write, as well as the > value that you think that the parameter currently has. > You can get the value "you think it has" from a previous READ, then you > repeat that in your WRITE message. > The target of the WRITE will refuse to write your value and return an > error if the value was not what you thought it was. > > Another way: > READ with reservation. When you READ, then set a reservation. > When anyone WRITEs the same parameter, it kills all reservations. > When you WRITE, the target system checks if you have a reservation and > refuses to write if you don't and returns an error. > > Or you can write lock the parameter. > > -- > Jakob Heitz. > > > -----Original Message----- > > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > > Joel M. Halpern > > Sent: Wednesday, August 14, 2013 10:49 AM > > To: Joe Marcus Clarke > > Cc: i2rs@ietf.org; Alia Atlas > > Subject: Re: [i2rs] Call for Adoption by WG: > draft-atlas-i2rs-architecture-01 > > (ends Aug 12) > > > > Depending upon how one reads RFCs, declaring that having two writers is > an > > error is a MUST NOT write. > > But we are also trying to recognize that no matter how many MUST NOT > > statements we produce, things happen. So we are trying to define the > > handling. I can live with precedence. I can live with "the item does > not > > change". But I do think it is helpful for us to be explicit about the > behavior in > > this far-to-likely error case. > > > > Yours, > > Joel > > > > > > On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: > > > On 8/13/13 4:01 PM, Alia Atlas wrote: > > >> Section 1.2: > > >> > > >> As can also be seen in Figure 1, an I2RS Agent may communicate > with > > >> multiple clients. Each client may send the agent a variety > of write > > >> operations. The handling of this situation has been a source > of > > >> discussion in the working group. In order to keep the > protocol > > >> simple, the current view is that two clients should not be > attempting > > >> to write (modify) the same piece of information. Such > collisions may > > >> happen, but are considered error cases that should be > resolved by > > the > > >> network applications and management systems. > > >> > > >> JMC: I think more verbiage is needed around how to detect > collisions. > > >> This is key to security considerations. Saying "clients should > not" is > > >> not strong enough to keep our potential attackers. If each > operation is > > >> tagged with an identifier that is unique to a client, then it > will be > > >> possible to determine if the current client is trying to > overwrite data > > >> from a previous client. This could fold into authz as well > where there > > >> is a permission to allow global override of other application's > state. > > >> > > >> > > >> [Alia] For the I2RS Agent to properly handle a collision, it does > > >> need to store the client identifier. I think that is clear in Sec > > >> 5.2 "Simply, the I2RS agent stores who did what operation to which > > entity." > > >> and the details in Sec 6.8 are "The current recommendation is to have > > >> a simple priority associated with each I2RS clients, and the highest > > >> priority change remains in effect. In the case of priority ties, the > > >> first client whose attribution is associated with the data will keep > > >> control." We already have a reference to Sec 6.8 right there - and > > >> that section is where the details are discussed. What specific > additional > > >> verbiage do you think would be useful? The priority is a knob to > allow > > >> overwriting of other applications' state - though needing to is > > >> considered an error. :-) > > > > > > When I first read this, I wanted something stronger to prevent clients > > > from writing to the same piece of data. I think the forward > > > references are fine if perhaps a bit late in the text. But my ask was > > > to strengthen the language to say "must not write." > > > > > >> > > >> > > >> Section 2: > > >> > > >> read scope: ... > > >> > > >> write scope: ... > > >> > > >> JMC: Should there be an event or notification scope in addition > to read > > >> and write? > > >> > > >> > > >> [Alia] I think it is folded into the read scope. If we find the need > > >> for such a term later on, then we can add it. > > > > > > This section talks about "terminology" used in the draft. However, > > > "read scope" as terminology is not used anywhere. The concept of > > > _reading_ data is, however, quite prevalent. In the same way, the > > > draft talks about "notification" in a number of contexts. As such, I > > > feel there is enough distinction there to warrant calling out what is > > > meant by a notification scope. > > > > > > "notification scope: The set of events and associated information that > > > will be sent northbound by the I2RS Agent to I2RS Clients. Clients > > > have the ability to register for specific events, but must do so given > > > the access restrictions of their associated read scope." > > > > > >> > > >> Section 3.4: > > >> > > >> I2RS clients may be operating on behalf of other applications. > While > > >> those applications' identities are not need for > authorization, each > > >> application should have a unique opaque identifier that can be > > >> provided by the I2RS client to the I2RS agent for purposes of > > >> tracking attribution of operations. > > >> > > >> JMC: The opaque ID might make it hard to accurately attribute > changes. > > >> I2RS should mandate a way to ensure traceability back to a > client that > > >> made the change or was granted access. > > >> > > >> > > >> [Alia] What do you have in mind? The I2RS client will have a > > >> security role and its scope. The I2RS client needs to vet the > > >> applications that it is a broker for. The opaque ID can be something > that is > > meaningful > > >> to that I2RS client. Basically, I2RS is providing the identity and > > >> security for between the I2RS client and the I2RS agent. I don't see > > >> it as practical or appropriate to try and define how the I2RS client > > >> and its applications interact; I know the broker/controller model is > > >> popular and so we do need enough to help support traceability to a > > >> secondary ID, but I'm not sure what is needed or appropriate beyond > > that. > > > > > > After listening to the working group session and based on other > > > threads, this text is now clearer to me. To summarize my feeling, I > > > don't think I2RS should mandate a northbound Client protocol, but we > > > need a unique way to identify the specific Client that obtained > > > access. This means that even in a load-balancing or HA case, there > > > must be a way to uniquely identify the Client that communicate with > > > the Agent. The northbound actor driving the Client should also be > > > identifiable, but that is outside the scope of this document. > > > > > >> Section 5.2.2: > > >> > > >> An I2RS Agent may decide that some state should no longer be > applied. > > >> An I2RS Client may instruct an Agent to remove state it has > applied. > > >> In all such cases, the state will revert to what it would > have been > > >> without the I2RS; that state is generally whatever was > specified via > > >> the CLI, NetConf, SNMP, etc. I2RS Agents will not store > multiple > > >> alternative states, nor try to determine which one among such > a > > >> plurality it should fall back to. Thus, the model followed > is not > > >> like the RIB, where multiple routes are stored at different > > >> preferences. > > >> > > >> JMC: Previously I had commented that one event that should be > > supported > > >> and perhaps documented here is that if the agent decides to > revert the > > >> application can be notified that its state has been reverted. > This > > >> might also be useful if another client overrides some portion of > another > > >> client's state (this is covered in Section 6.8, but might be > useful to > > >> mention here as well). Perhaps add at the end of Section 5.2.2: > > >> > > >> "A client may choose to be notified whenever its state is > reverted > > >> either by another client or by the I2RS agent." > > >> > > >> > > >> [Alia] I'll put in: "An I2RS Client may register for notifications > > >> when state that was applied by a particular I2RS Client is modified > > >> or removed." That is slightly different since it allows an I2RS > > >> Client to learn about the changes to state from itself or from a > > >> different I2RS Client. > > > > > > WFM, thanks. > > > > > >> > > >> Section 5.4.2: > > >> > > >> (Bulleted list of examples) > > >> > > >> JMC: Consider adding an example for an event such as a new route > > being > > >> learned or an OSPF neighbor removal. > > >> > > >> > > >> [Alia] I think that "writing routes or prefixes to be advertised via > the > > >> protocol" describes a new route being learned. I'd prefer not to put > > >> OSPF neighbor removal in as an example. It raises the questions > > >> about what is configuration vs. ephemeral data and the I2RS scope. > > >> If you have a good use-case that requires it, then I'd be quite > > >> interested in seeing it. > > > > > > I was specifically asking about an _event_ use case. Very simply if > > > we learn/lose a route, I'd want my Client to be notified so I can > > > perhaps react to it to install another route or remove a route I have > > > previously installed (e.g., a failover/failback use case). > > > > > > Additionally, if a peer is otherwise reachable, but stops > > > participating in OSPF, BGP, etc., I would like I2RS to notify my > > > Client as I may not know about this any other way (though I could be > > > flooded with route delete events, it's good to correlate that to a > peer going > > away). > > > > > >> > > >> > > >> > > >> Section 5.4.4: > > >> > > >> Many network elements have separate policy and QoS mechanisms, > > >> including knobs which affect local path computation and queue > > control > > >> capabilities. These capabilities vary widely across > implementations, > > >> and I2RS cannot model the full range of information > collection or > > >> manipulation of these attributes. A core set does need to be > > >> included in the I2RS data models and in the expected > interfaces > > >> between the I2RS Agent and the network element, in order to > > provide > > >> basic capabilities and the hooks for future extensibility. > > >> > > >> JMC: I think this either needs an editor's note for more > discussion or > > >> perhaps QoS in general should be out of scope. > > >> > > >> > > >> [Alia] I am happy to add in an editor's note for more discussion - > > >> but we should start that conversation now on the list - because the > > >> WG does have quite tight deadlines for milestones. > > > > > > Fair enough. > > > > > >> Section 6.1: > > >> > > >> That protocol may use several underlying transports (TCP, > > >> SCTP, DCCP), with suitable authentication and integrity > protection > > >> mechanisms. Whatever transport is used for the data > exchange, it > > >> must also support suitable congestion control mechanisms. > > >> > > >> JMC: I think Carlos (or someone) mentioned this, but I'm not > sure DCCP > > >> is ideal for I2RS since we likely do want reliable order of > delivery. > > >> > > >> > > >> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - > > >> but it may be > > >> good for delivering statistics. I think we'll have different > transport > > >> options depending on the requirements of a particular data model or > > >> section. Since you are the second person to be confused by that > > >> section, I've added the following sentence: > > >> > > >> "These different transports can support different types of > > >> communication (e.g. control, reading, notifications, and information > > >> collection) and different sets of data." > > >> > > >> Let me know if that helps or if you have better ideas for wording. > > > > > > That works. > > > > > >> Section 6.7: > > >> > > >> One of the other important aspects of the I2RS is that it is > intended > > >> to simplify collecting information about the state of network > > >> elements. > > >> > > >> JMC: I think this needs to be more specific to routing > information > > >> versus any information from the network element (e.g., it does > not > > cover > > >> CPU statistics). > > >> > > >> > > >> [Alia] The scoping is a question - and that will depend on what the > > >> use-cases we consider need and what the related information and data > > >> models need to be. If you look at the > > >> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU > > >> load. I do think there is a real need to be able to get back > > >> thresholded and filtered information. You probably heard Ed's > personal > > >> thoughts about a single protocol as well... So - I don't think the > > >> architecture needs to restrict the data in scope - particular in a > > >> section that is talking about communication patterns - but as a WG, > > >> we need to keep a tight focus that still provides sufficient > > >> information to fully solve the desired use-cases. > > > > > > My concerns comes from a desire not to have I2RS become a common > > > API/protocol for things that SNMP or NETCONF or some other potential > > > data collection scheme is used for. So I agree we need a tight focus > > > and potentially a litmus test for what should be adopted as > > > collectable data via I2RS. As it stands now, I think someone could > > > argue for any kind of data and present a use case for it (e.g., > > > latency, interface errors, location). So the statement I made was > > > more around the lines of should I2RS stay pure to routing and routed > > > topology or should we really open the door to other data that is not > > specifically related to routing? > > > > > > Joe > > > > > >> > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > --089e0158ae38e246ff04e3ec807d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd discussed the problem of depending on read values = to write - whether the same value or a different one - with Ron Bonica a wh= ile ago. =A0

I rather like your WRITE operation idea - w= here one could generalize to be able to specify other parameters as well. = =A0Thus, it could be WRITE X <-p if Y=3Dn and Z=3Dm - or the simple X &l= t;- p if X=3D=3Dq.

Alia


On Wed, Aug 14, 2013 at 2:14 PM, Jakob Heitz <jako= b.heitz@ericsson.com> wrote:
Or say: "must write atomically".
Here is one way:
In the WRITE message, put the value you want to write, as well as the value= that you think that the parameter currently has.
You can get the value "you think it has" from a previous READ, th= en you repeat that in your WRITE message.
The target of the WRITE will refuse to write your value and return an error= if the value was not what you thought it was.

Another way:
READ with reservation. When you READ, then set a reservation.
When anyone WRITEs the same parameter, it kills all reservations.
When you WRITE, the target system checks if you have a reservation and refu= ses to write if you don't and returns an error.

Or you can write lock the parameter.

--
Jakob Heitz.

> -----Original Message-----
> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of
> Joel M. Halpern
> Sent: Wednesday, August 14, 2013 10:49 AM
> To: Joe Marcus Clarke
> Cc: i2rs@ietf.org; Alia Atlas
> Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architec= ture-01
> (ends Aug 12)
>
> Depending upon how one r= eads RFCs, declaring that having two writers is an
> error is a MUST NOT write.
> But we are also trying to recognize that no matter how many MUST NOT > statements we produce, things happen. =A0So we are trying to define th= e
> handling. =A0I can live with precedence. =A0I can live with "the = item does not
> change". =A0But I do think it is helpful for us to be explicit ab= out the behavior in
> this far-to-likely error case.
>
> Yours,
> Joel
>
>
> On 8/14/13 1:41 PM, Joe Marcus Clarke wrote:
> > On 8/13/13 4:01 PM, Alia Atlas wrote:
> >> =A0 =A0 =A0Section 1.2:
> >>
> >> =A0 =A0 =A0As can also be seen in Figure 1, an I2RS Agent may= communicate with
> >> =A0 =A0 =A0 =A0 multiple clients. =A0Each client may send the= agent a variety of write
> >> =A0 =A0 =A0 =A0 operations. =A0The handling of this situation= has been a source of
> >> =A0 =A0 =A0 =A0 discussion in the working group. =A0In order = to keep the protocol
> >> =A0 =A0 =A0 =A0 simple, the current view is that two clients = should not be attempting
> >> =A0 =A0 =A0 =A0 to write (modify) the same piece of informati= on. =A0Such collisions may
> >> =A0 =A0 =A0 =A0 happen, but are considered error cases that s= hould be resolved by
> the
> >> =A0 =A0 =A0 =A0 network applications and management systems.<= br> > >>
> >> =A0 =A0 =A0JMC: I think more verbiage is needed around how to= detect collisions.
> >> =A0 =A0 =A0This is key to security considerations. =A0Saying = "clients should not" is
> >> =A0 =A0 =A0not strong enough to keep our potential attackers.= =A0If each operation is
> >> =A0 =A0 =A0tagged with an identifier that is unique to a clie= nt, then it will be
> >> =A0 =A0 =A0possible to determine if the current client is try= ing to overwrite data
> >> =A0 =A0 =A0from a previous client. =A0This could fold into au= thz as well where there
> >> =A0 =A0 =A0is a permission to allow global override of other = application's state.
> >>
> >>
> >> [Alia] For the I2RS Agent to properly handle a collision, it = does
> >> need to store the client identifier. =A0I think that is clear= in Sec
> >> 5.2 "Simply, the I2RS agent stores who did what operatio= n to which
> entity."
> >> and the details in Sec 6.8 are "The current recommendati= on is to have
> >> a simple priority associated with each I2RS clients, and the = highest
> >> priority change remains in effect. In the case of priority ti= es, the
> >> first client whose attribution is associated with the data wi= ll keep
> >> control." =A0We already have a reference to Sec 6.8 righ= t there - and
> >> that section is where the details are discussed. =A0What spec= ific additional
> >> verbiage do you think would be useful? =A0 The priority is a = knob to allow
> >> overwriting of other applications' state - though needing= to is
> >> considered an error. :-)
> >
> > When I first read this, I wanted something stronger to prevent cl= ients
> > from writing to the same piece of data. =A0I think the forward > > references are fine if perhaps a bit late in the text. =A0But my = ask was
> > to strengthen the language to say "must not write."
> >
> >>
> >>
> >> =A0 =A0 =A0Section 2:
> >>
> >> =A0 =A0 =A0read scope: ...
> >>
> >> =A0 =A0 =A0write scope: ...
> >>
> >> =A0 =A0 =A0JMC: Should there be an event or notification scop= e in addition to read
> >> =A0 =A0 =A0and write?
> >>
> >>
> >> [Alia] I think it is folded into the read scope. =A0If we fin= d the need
> >> for such a term later on, then we can add it.
> >
> > This section talks about "terminology" used in the draf= t. =A0However,
> > "read scope" as terminology is not used anywhere. =A0Th= e concept of
> > _reading_ data is, however, quite prevalent. =A0In the same way, = the
> > draft talks about "notification" in a number of context= s. =A0As such, I
> > feel there is enough distinction there to warrant calling out wha= t is
> > meant by a notification scope.
> >
> > "notification scope: The set of events and associated inform= ation that
> > will be sent northbound by the I2RS Agent to I2RS Clients. =A0Cli= ents
> > have the ability to register for specific events, but must do so = given
> > the access restrictions of their associated read scope."
> >
> >>
> >> =A0 =A0 =A0Section 3.4:
> >>
> >> =A0 =A0 =A0I2RS clients may be operating on behalf of other a= pplications. =A0While
> >> =A0 =A0 =A0 =A0 those applications' identities are not ne= ed for authorization, each
> >> =A0 =A0 =A0 =A0 application should have a unique opaque ident= ifier that can be
> >> =A0 =A0 =A0 =A0 provided by the I2RS client to the I2RS agent= for purposes of
> >> =A0 =A0 =A0 =A0 tracking attribution of operations.
> >>
> >> =A0 =A0 =A0JMC: The opaque ID might make it hard to accuratel= y attribute changes.
> >> =A0 =A0 =A0I2RS should mandate a way to ensure traceability b= ack to a client that
> >> =A0 =A0 =A0made the change or was granted access.
> >>
> >>
> >> [Alia] What do you have in mind? =A0The I2RS client will have= a
> >> security role and its scope. =A0The I2RS client needs to vet = the
> >> applications that it is a broker for. =A0The opaque ID can be= something that is
> meaningful
> >> to that I2RS client. =A0 Basically, I2RS is providing the ide= ntity and
> >> security for between the I2RS client and the I2RS agent. =A0I= don't see
> >> it as practical or appropriate to try and define how the I2RS= client
> >> and its applications interact; I know the broker/controller m= odel is
> >> popular and so we do need enough to help support traceability= to a
> >> secondary ID, but I'm not sure what is needed or appropri= ate beyond
> that.
> >
> > After listening to the working group session and based on other > > threads, this text is now clearer to me. =A0To summarize my feeli= ng, I
> > don't think I2RS should mandate a northbound Client protocol,= but we
> > need a unique way to identify the specific Client that obtained > > access. =A0This means that even in a load-balancing or HA case, t= here
> > must be a way to uniquely identify the Client that communicate wi= th
> > the Agent. =A0The northbound actor driving the Client should also= be
> > identifiable, but that is outside the scope of this document.
> >
> >> =A0 =A0 =A0Section 5.2.2:
> >>
> >> =A0 =A0 =A0An I2RS Agent may decide that some state should no= longer be applied.
> >> =A0 =A0 =A0 =A0 An I2RS Client may instruct an Agent to remov= e state it has applied.
> >> =A0 =A0 =A0 =A0 In all such cases, the state will revert to w= hat it would have been
> >> =A0 =A0 =A0 =A0 without the I2RS; that state is generally wha= tever was specified via
> >> =A0 =A0 =A0 =A0 the CLI, NetConf, SNMP, etc. =A0I2RS Agents w= ill not store multiple
> >> =A0 =A0 =A0 =A0 alternative states, nor try to determine whic= h one among such a
> >> =A0 =A0 =A0 =A0 plurality it should fall back to. =A0Thus, th= e model followed is not
> >> =A0 =A0 =A0 =A0 like the RIB, where multiple routes are store= d at different
> >> =A0 =A0 =A0 =A0 preferences.
> >>
> >> =A0 =A0 =A0JMC: =A0Previously I had commented that one event = that should be
> supported
> >> =A0 =A0 =A0and perhaps documented here is that if the agent d= ecides to revert the
> >> =A0 =A0 =A0application can be notified that its state has bee= n reverted. =A0This
> >> =A0 =A0 =A0might also be useful if another client overrides s= ome portion of another
> >> =A0 =A0 =A0client's state (this is covered in Section 6.8= , but might be useful to
> >> =A0 =A0 =A0mention here as well). =A0Perhaps add at the end o= f Section 5.2.2:
> >>
> >> =A0 =A0 =A0 =A0"A client may choose to be notified whene= ver its state is reverted
> >> =A0 =A0 =A0either by another client or by the I2RS agent.&quo= t;
> >>
> >>
> >> [Alia] I'll put in: "An I2RS Client may register for= notifications
> >> when state that was applied by a particular I2RS Client is mo= dified
> >> or removed." =A0That is slightly different since it allo= ws an I2RS
> >> Client to learn about the changes to state from itself or fro= m a
> >> different I2RS Client.
> >
> > WFM, thanks.
> >
> >>
> >> =A0 =A0 =A0Section 5.4.2:
> >>
> >> =A0 =A0 =A0(Bulleted list of examples)
> >>
> >> =A0 =A0 =A0JMC: Consider adding an example for an event such = as a new route
> being
> >> =A0 =A0 =A0learned or an OSPF neighbor removal.
> >>
> >>
> >> [Alia] I think that "writing routes or prefixes to be ad= vertised via the
> >> protocol" describes a new route being learned. =A0 I'= ;d prefer not to put
> >> OSPF neighbor removal in as an example. =A0It raises the ques= tions
> >> about what is configuration vs. ephemeral data and the I2RS s= cope.
> >> If you have a good use-case that requires it, then I'd be= quite
> >> interested in seeing it.
> >
> > I was specifically asking about an _event_ use case. =A0Very simp= ly if
> > we learn/lose a route, I'd want my Client to be notified so I= can
> > perhaps react to it to install another route or remove a route I = have
> > previously installed (e.g., a failover/failback use case).
> >
> > Additionally, if a peer is otherwise reachable, but stops
> > participating in OSPF, BGP, etc., I would like I2RS to notify my<= br> > > Client as I may not know about this any other way (though I could= be
> > flooded with route delete events, it's good to correlate that= to a peer going
> away).
> >
> >>
> >>
> >>
> >> =A0 =A0 =A0Section 5.4.4:
> >>
> >> =A0 =A0 =A0Many network elements have separate policy and QoS= mechanisms,
> >> =A0 =A0 =A0 =A0 including knobs which affect local path compu= tation and queue
> control
> >> =A0 =A0 =A0 =A0 capabilities. =A0These capabilities vary wide= ly across implementations,
> >> =A0 =A0 =A0 =A0 and I2RS cannot model the full range of infor= mation collection or
> >> =A0 =A0 =A0 =A0 manipulation of these attributes. =A0A core s= et does need to be
> >> =A0 =A0 =A0 =A0 included in the I2RS data models and in the e= xpected interfaces
> >> =A0 =A0 =A0 =A0 between the I2RS Agent and the network elemen= t, in order to
> provide
> >> =A0 =A0 =A0 =A0 basic capabilities and the hooks for future e= xtensibility.
> >>
> >> =A0 =A0 =A0JMC: I think this either needs an editor's not= e for more discussion or
> >> =A0 =A0 =A0perhaps QoS in general should be out of scope.
> >>
> >>
> >> [Alia] I am happy to add in an editor's note for more dis= cussion -
> >> but we should start that conversation now on the list - becau= se the
> >> WG does have quite tight deadlines for milestones.
> >
> > Fair enough.
> >
> >> =A0 =A0 =A0Section 6.1:
> >>
> >> =A0 =A0 =A0That protocol may use several underlying transport= s (TCP,
> >> =A0 =A0 =A0 =A0 SCTP, DCCP), with suitable authentication and= integrity protection
> >> =A0 =A0 =A0 =A0 mechanisms. =A0Whatever transport is used for= the data exchange, it
> >> =A0 =A0 =A0 =A0 must also support suitable congestion control= mechanisms.
> >>
> >> =A0 =A0 =A0JMC: I think Carlos (or someone) mentioned this, b= ut I'm not sure DCCP
> >> =A0 =A0 =A0is ideal for I2RS since we likely do want reliable= order of delivery.
> >>
> >>
> >> [Alia] Yes - DCCP is clearly the wrong choice for a control c= hannel -
> >> but it may be
> >> good for delivering statistics. =A0 I think we'll have di= fferent transport
> >> options depending on the requirements of a particular data mo= del or
> >> section. =A0Since you are the second person to be confused by= that
> >> section, I've added the following sentence:
> >>
> >> "These different transports can support different types = of
> >> communication (e.g. control, reading, notifications, and info= rmation
> >> collection) and different sets of data."
> >>
> >> =A0 Let me know if that helps or if you have better ideas for= wording.
> >
> > That works.
> >
> >> =A0 =A0 =A0Section 6.7:
> >>
> >> =A0 =A0 =A0One of the other important aspects of the I2RS is = that it is intended
> >> =A0 =A0 =A0 =A0 to simplify collecting information about the = state of network
> >> =A0 =A0 =A0 =A0 elements.
> >>
> >> =A0 =A0 =A0JMC: I think this needs to be more specific to rou= ting information
> >> =A0 =A0 =A0versus any information from the network element (e= .g., it does not
> cover
> >> =A0 =A0 =A0CPU statistics).
> >>
> >>
> >> [Alia] The scoping is a question - and that will depend on wh= at the
> >> use-cases we consider need and what the related information a= nd data
> >> models need to be. =A0If you look at the
> >> draft-bitar-i2rs-service-chaining-00, it does ask for things = like CPU
> >> load. =A0I do think there is a real need to be able to get ba= ck
> >> thresholded and filtered information. =A0You probably heard E= d's personal
> >> thoughts about a single protocol as well... =A0 So - I don= 9;t think the
> >> architecture needs to restrict the data in scope - particular= in a
> >> section that is talking about communication patterns - but as= a WG,
> >> we need to keep a tight focus that still provides sufficient<= br> > >> information to fully solve the desired use-cases.
> >
> > My concerns comes from a desire not to have I2RS become a common<= br> > > API/protocol for things that SNMP or NETCONF or some other potent= ial
> > data collection scheme is used for. =A0So I agree we need a tight= focus
> > and potentially a litmus test for what should be adopted as
> > collectable data via I2RS. =A0As it stands now, I think someone c= ould
> > argue for any kind of data and present a use case for it (e.g., > > latency, interface errors, location). =A0So the statement I made = was
> > more around the lines of should I2RS stay pure to routing and rou= ted
> > topology or should we really open the door to other data that is = not
> specifically related to routing?
> >
> > Joe
> >
> >>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--089e0158ae38e246ff04e3ec807d-- From akatlas@gmail.com Wed Aug 14 12:11:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46A21F9E67 for ; Wed, 14 Aug 2013 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl9yeFApTcRq for ; Wed, 14 Aug 2013 12:11:28 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6679C21F9E51 for ; Wed, 14 Aug 2013 12:11:28 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so12334858obb.2 for ; Wed, 14 Aug 2013 12:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FtrdLnesAUER8YCLTX50tLv3dKu6qc71r01VYZFVGh8=; b=KKWyPbXqf9BJfLBYJOPZduafIr4cHXJwxiIy5q8RIOteXqquy9nOjww6NFNUdY7gqF jRqFRnTk/S8jf+tl/QTN65UsDvX/RhA+dgsz60z7rUNIUTEKspTuz/5cShvhHqZYjc1n y4i+qNe2ZOOW5J/AqLeeKKd/dclq8wuDqBLx/UzAXu3/Mc1MDWLMQ5bCkRV8fgwr9TvI m+wTkFqSXDGZadFaj0wBXraP3FOP4pl72NZR9vicjvzSwrwSjens0tHeGVlgauufFSym cBbnl8rVbjwfhSeZn+ac7ka2Df8RsBTJaf8iL9qKvluKeZjmwAsVOpnT9N14eJOvxtRT bbJA== MIME-Version: 1.0 X-Received: by 10.60.62.4 with SMTP id u4mr9746201oer.35.1376507485134; Wed, 14 Aug 2013 12:11:25 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 12:11:25 -0700 (PDT) In-Reply-To: <520BC148.3030306@cisco.com> References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> Date: Wed, 14 Aug 2013 15:11:25 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=089e012953baaea5dc04e3ed1f88 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:11:30 -0000 --089e012953baaea5dc04e3ed1f88 Content-Type: text/plain; charset=ISO-8859-1 Joe, I'm cutting old stuff out and just responding in-line to the rest.... On Wed, Aug 14, 2013 at 1:41 PM, Joe Marcus Clarke wrote: > On 8/13/13 4:01 PM, Alia Atlas wrote: > > Section 1.2: > > When I first read this, I wanted something stronger to prevent clients > from writing to the same piece of data. I think the forward references > are fine if perhaps a bit late in the text. But my ask was to > strengthen the language to say "must not write." [Alia] I don't really see that saying "must not write" instead of "should not write" makes any meaningful improvement. We've said in the architecture that it should be considered an error. I, personally, think that SHOULD applies more than MUST; the system behavior will be well understood in either event if the I2RS agent detects the collision. If multiple clients do try and write the same value, it will not be catastrophic nor result in I2RS failing. Thus, I think should is more accurate. > > > > > > Section 2: > > > > read scope: ... > > > > write scope: ... > > > > JMC: Should there be an event or notification scope in addition to > read > > and write? > > > > > > [Alia] I think it is folded into the read scope. If we find the need > > for such a term later on, then we can add it. > > This section talks about "terminology" used in the draft. However, > "read scope" as terminology is not used anywhere. The concept of > _reading_ data is, however, quite prevalent. In the same way, the draft > talks about "notification" in a number of contexts. As such, I feel > there is enough distinction there to warrant calling out what is meant > by a notification scope. > > "notification scope: The set of events and associated information that > will be sent northbound by the I2RS Agent to I2RS Clients. Clients have > the ability to register for specific events, but must do so given the > access restrictions of their associated read scope." > [Alia] Sure - if you care about it that much. However, I think that notification scope is "The set of events and associated information that the I2RS Client can request be pushed by the I2RS Agent. I2RS Clients have the ability to register for specific events and information streams, but must do so given the access restrictions of their notification scope." I'll put this in the next version of the draft. > > > Section 3.4: > > > > I2RS clients may be operating on behalf of other applications. While > > those applications' identities are not need for authorization, > each > > application should have a unique opaque identifier that can be > > provided by the I2RS client to the I2RS agent for purposes of > > tracking attribution of operations. > > > > JMC: The opaque ID might make it hard to accurately attribute > changes. > > I2RS should mandate a way to ensure traceability back to a client > that > > made the change or was granted access. > > > > > > [Alia] What do you have in mind? The I2RS client will have a security > > role and its scope. The I2RS client needs to vet the applications that > > it is a broker for. The opaque ID can be something that is meaningful > > to that I2RS client. Basically, I2RS is providing the identity and > > security for between the I2RS client and the I2RS agent. I don't see it > > as practical or appropriate to try and define how the I2RS client and > > its applications interact; I know the broker/controller model is popular > > and so we do need enough to help support traceability to a secondary ID, > > but I'm not sure what is needed or appropriate beyond that. > > After listening to the working group session and based on other threads, > this text is now clearer to me. To summarize my feeling, I don't think > I2RS should mandate a northbound Client protocol, but we need a unique > way to identify the specific Client that obtained access. This means > that even in a load-balancing or HA case, there must be a way to > uniquely identify the Client that communicate with the Agent. The > northbound actor driving the Client should also be identifiable, but > that is outside the scope of this document. > [Alia] I think that there can be a number of ways to uniquely identify a client beyond its I2RS Client Identifier. The question is whether we need "client identity", "sub-client identity" and "secondary identity". Does "secondary identity" also need a "secondary sub-identity" to account for redundancy or load-balancing on the part of the application using the I2RS Client as a broker? Perhaps this is better discussed in the redundancy thread? > > > > Section 5.4.2: > > > > (Bulleted list of examples) > > > > JMC: Consider adding an example for an event such as a new route > being > > learned or an OSPF neighbor removal. > > > > > > [Alia] I think that "writing routes or prefixes to be advertised via the > > protocol" describes a new route being learned. I'd prefer not to put > > OSPF neighbor removal in as an example. It raises the questions about > > what is configuration vs. ephemeral data and the I2RS scope. If you > > have a good use-case that requires it, then I'd be quite interested in > > seeing it. > > I was specifically asking about an _event_ use case. Very simply if we > learn/lose a route, I'd want my Client to be notified so I can perhaps > react to it to install another route or remove a route I have previously > installed (e.g., a failover/failback use case). > > Additionally, if a peer is otherwise reachable, but stops participating > in OSPF, BGP, etc., I would like I2RS to notify my Client as I may not > know about this any other way (though I could be flooded with route > delete events, it's good to correlate that to a peer going away). > [Alia] Oh, yes - I missed that this was for events! Sorry! I'll add: "* subscribing to an information stream of route changes * receiving notifications about peers coming up or going down" > Section 6.7: > > > > One of the other important aspects of the I2RS is that it is intended > > to simplify collecting information about the state of network > > elements. > > > > JMC: I think this needs to be more specific to routing information > > versus any information from the network element (e.g., it does not > cover > > CPU statistics). > > > > > > [Alia] The scoping is a question - and that will depend on what the > > use-cases we consider need and what the related information and data > > models need to be. If you look at the > > draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU > > load. I do think there is a real need to be able to get back > > thresholded and filtered information. You probably heard Ed's personal > > thoughts about a single protocol as well... So - I don't think the > > architecture needs to restrict the data in scope - particular in a > > section that is talking about communication patterns - but as a WG, we > > need to keep a tight focus that still provides sufficient information to > > fully solve the desired use-cases. > > My concerns comes from a desire not to have I2RS become a common > API/protocol for things that SNMP or NETCONF or some other potential > data collection scheme is used for. So I agree we need a tight focus > and potentially a litmus test for what should be adopted as collectable > data via I2RS. As it stands now, I think someone could argue for any > kind of data and present a use case for it (e.g., latency, interface > errors, location). So the statement I made was more around the lines of > should I2RS stay pure to routing and routed topology or should we really > open the door to other data that is not specifically related to routing? > [Alia] Some routing use-cases need data that isn't purely "routing and signaling". Do we force them to use another protocol or do screen-scraping? I don't know the correct answer - and I'm not sure the WG does either. Given that it is I2RS, I think the emphasis on routing can be assumed? Alia --089e012953baaea5dc04e3ed1f88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,

I'm cutting old stuff out and = just responding in-line to the rest....

<= div class=3D"gmail_quote">On Wed, Aug 14, 2013 at 1:41 PM, Joe Marcus Clark= e <jclarke@cisco.com> wrote:
On 8/13/13 4:01 PM, Alia= Atlas wrote:
> =A0 =A0 Section 1.2:

When I first read this, I wanted something stronger to prevent = clients
from writing to the same piece of data. =A0I think the forward references are fine if perhaps a bit late in the text. =A0But my ask was to
strengthen the language to say "must not write."

=A0[Alia] I don't really see that saying "must not= write" instead of "should not write" makes any meaningful i= mprovement. =A0We've said in the architecture that it should be conside= red an error. =A0 I, personally, think that SHOULD applies more than MUST; = the system behavior will be well understood in either event if the I2RS age= nt detects the collision. =A0If multiple clients do try and write the same = value, it will not be catastrophic nor result in I2RS failing. =A0Thus, I t= hink should is more accurate.
=A0
>
>
> =A0 =A0 Section 2:
>
> =A0 =A0 read scope: ...
>
> =A0 =A0 write scope: ...
>
> =A0 =A0 JMC: Should there be an event or notification scope in additio= n to read
> =A0 =A0 and write?
>
>
> [Alia] I think it is folded into the read scope. =A0If we find the nee= d
> for such a term later on, then we can add it.

This section talks about "terminology" used in the draft. = =A0However,
"read scope" as terminology is not used anywhere. =A0The concept = of
_reading_ data is, however, quite prevalent. =A0In the same way, the draft<= br> talks about "notification" in a number of contexts. =A0As such, I= feel
there is enough distinction there to warrant calling out what is meant
by a notification scope.

"notification scope: The set of events and associated information that=
will be sent northbound by the I2RS Agent to I2RS Clients. =A0Clients have<= br> the ability to register for specific events, but must do so given the
access restrictions of their associated read scope."
<= div>
[Alia] Sure - if you care about it that much. =A0 Howeve= r, I think that notification scope is
"The set of events and= associated information that the I2RS Client can request be pushed by the I= 2RS
Agent. =A0I2RS Clients have the ability to register for specific event= s
and information streams, but must do so given the access restri= ctions
of their notification scope."
=A0
I'll put this in the next version of the draft.

>
> =A0 =A0 Section 3.4:
>
> =A0 =A0 I2RS clients may be operating on behalf of other applications.= =A0While
> =A0 =A0 =A0 =A0those applications' identities are not need for aut= horization, each
> =A0 =A0 =A0 =A0application should have a unique opaque identifier that= can be
> =A0 =A0 =A0 =A0provided by the I2RS client to the I2RS agent for purpo= ses of
> =A0 =A0 =A0 =A0tracking attribution of operations.
>
> =A0 =A0 JMC: The opaque ID might make it hard to accurately attribute = changes.
> =A0 =A0 I2RS should mandate a way to ensure traceability back to a cli= ent that
> =A0 =A0 made the change or was granted access.
>
>
> [Alia] What do you have in mind? =A0The I2RS client will have a securi= ty
> role and its scope. =A0The I2RS client needs to vet the applications t= hat
> it is a broker for. =A0The opaque ID can be something that is meaningf= ul
> to that I2RS client. =A0 Basically, I2RS is providing the identity and=
> security for between the I2RS client and the I2RS agent. =A0I don'= t see it
> as practical or appropriate to try and define how the I2RS client and<= br> > its applications interact; I know the broker/controller model is popul= ar
> and so we do need enough to help support traceability to a secondary I= D,
> but I'm not sure what is needed or appropriate beyond that.

After listening to the working group session and based on other threa= ds,
this text is now clearer to me. =A0To summarize my feeling, I don't thi= nk
I2RS should mandate a northbound Client protocol, but we need a unique
way to identify the specific Client that obtained access. =A0This means
that even in a load-balancing or HA case, there must be a way to
uniquely identify the Client that communicate with the Agent. =A0The
northbound actor driving the Client should also be identifiable, but
that is outside the scope of this document.

=
[Alia] I think that there can be a number of ways to uniquely identify= a client beyond its I2RS Client Identifier. =A0The question is whether we = need "client identity", "sub-client identity" and "= ;secondary identity". =A0Does "secondary identity" also need= a "secondary sub-identity" to account for redundancy or load-bal= ancing on the part of the application using the I2RS Client as a broker? = =A0 Perhaps this is better discussed in the redundancy thread?
=A0
>
> =A0 =A0 Section 5.4.2:
>
> =A0 =A0 (Bulleted list of examples)
>
> =A0 =A0 JMC: Consider adding an example for an event such as a new rou= te being
> =A0 =A0 learned or an OSPF neighbor removal.
>
>
> [Alia] I think that "writing routes or prefixes to be advertised = via the
> protocol" describes a new route being learned. =A0 I'd prefer= not to put
> OSPF neighbor removal in as an example. =A0It raises the questions abo= ut
> what is configuration vs. ephemeral data and the I2RS scope. =A0If you=
> have a good use-case that requires it, then I'd be quite intereste= d in
> seeing it.

I was specifically asking about an _event_ use case. =A0Very simply i= f we
learn/lose a route, I'd want my Client to be notified so I can perhaps<= br> react to it to install another route or remove a route I have previously installed (e.g., a failover/failback use case).

Additionally, if a peer is otherwise reachable, but stops participating
in OSPF, BGP, etc., I would like I2RS to notify my Client as I may not
know about this any other way (though I could be flooded with route
delete events, it's good to correlate that to a peer going away).

[Alia] Oh, yes - I missed that this was for = events! =A0 Sorry! =A0I'll add:
"* subscribing to an inf= ormation stream of route changes
=A0*=A0receiving notifications about peers coming up or going down&quo= t;

> =A0 =A0 Section 6.7:
>
> =A0 =A0 One of the other important aspects of the I2RS is that it is i= ntended
> =A0 =A0 =A0 =A0to simplify collecting information about the state of n= etwork
> =A0 =A0 =A0 =A0elements.
>
> =A0 =A0 JMC: I think this needs to be more specific to routing informa= tion
> =A0 =A0 versus any information from the network element (e.g., it does= not cover
> =A0 =A0 CPU statistics).
>
>
> [Alia] The scoping is a question - and that will depend on what the > use-cases we consider need and what the related information and data > models need to be. =A0If you look at the
> draft-bitar-i2rs-service-chaining-00, it does ask for things like CPU<= br> > load. =A0I do think there is a real need to be able to get back
> thresholded and filtered information. =A0You probably heard Ed's p= ersonal
> thoughts about a single protocol as well... =A0 So - I don't think= the
> architecture needs to restrict the data in scope - particular in a
> section that is talking about communication patterns - but as a WG, we=
> need to keep a tight focus that still provides sufficient information = to
> fully solve the desired use-cases.

My concerns comes from a desire not to have I2RS become a common
API/protocol for things that SNMP or NETCONF or some other potential
data collection scheme is used for. =A0So I agree we need a tight focus
and potentially a litmus test for what should be adopted as collectable
data via I2RS. =A0As it stands now, I think someone could argue for any
kind of data and present a use case for it (e.g., latency, interface
errors, location). =A0So the statement I made was more around the lines of<= br> should I2RS stay pure to routing and routed topology or should we really open the door to other data that is not specifically related to routing?

[Alia] Some routing use-cases need data t= hat isn't purely "routing and signaling". =A0Do we force them= to use another protocol or do screen-scraping? =A0I don't know the cor= rect answer - and I'm not sure the WG does either. =A0Given that it is = I2RS, I think the emphasis on routing can be assumed?
=A0
Alia
--089e012953baaea5dc04e3ed1f88-- From akatlas@gmail.com Wed Aug 14 12:18:15 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9611E8187 for ; Wed, 14 Aug 2013 12:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmW3-aDVCLTC for ; Wed, 14 Aug 2013 12:18:14 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BD15521F9C60 for ; Wed, 14 Aug 2013 12:18:14 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so13820626oag.29 for ; Wed, 14 Aug 2013 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iPJ55camSSp29zTU/JtOSZtPVNhYjVa7Ol1uZhGQAPs=; b=YKI2H8hcLjHXNHmucOVdC6A4Pfoc7jxMCw7FyYYeYidEpA3EqQY8Irj3nq4hOUvaVQ oHAQKav7TYSrl2dx3mBkWPcfW0Shj4KdefAsyF9sIJJoL6NBRIkSBYZ3Xib1i+ADZsKL z8jNz5AmC072EIYgmhtYJLEn1lYkq/6Ebk5WKeY41ZvBRP52I7P1DX/6WUiHmWa71zxL RIylsD7DfrJgk/xLXPfN9oy4qwHfh4d1F6ss3r2o5Ow9Jk8LFOs77xYwVXVAadFdCcCx igHNnQdLTZdbpWne+RE3xIyXelOuF47oNBYs4ZmXeCGmh7aZ6WM/u9Q6ebf8/fERJf7V dykw== MIME-Version: 1.0 X-Received: by 10.60.62.38 with SMTP id v6mr10736110oer.45.1376507894264; Wed, 14 Aug 2013 12:18:14 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 12:18:14 -0700 (PDT) In-Reply-To: <95067C434CE250468B77282634C96ED322E0602D@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322D5EDE4@xmb-aln-x02.cisco.com> <95067C434CE250468B77282634C96ED322E0602D@xmb-aln-x02.cisco.com> Date: Wed, 14 Aug 2013 15:18:14 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=089e0153761e117a4604e3ed38fb Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:18:15 -0000 --089e0153761e117a4604e3ed38fb Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Responses in-line with stuff agreed and no longer relevant cut for easier reading. On Wed, Aug 14, 2013 at 2:22 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > On Aug 13, 2013, at 2:44 PM, Alia Atlas wrote: > > On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> >> What is your specific concern and how would you want to see the reach and > scope confined in the architecture draft? > > > > Perhaps simply by aligning with the problem statement wording, in terms of > "routing and signaling". Or is the "signaling" piece confined to label > distribution? > [Alia] Sure - happy to change the "Routing" to "Routing and Signaling" in the description and in the figure. > 4.1. Example Network Application: Topology Manager >> >> One example of such an application is a Topology Manager. Such an >> application includes an I2RS client which uses the I2RS protocol to >> collect information about the state of the network. The Topology >> Manager would collect device and interface state from devices it >> interacts with directly. >> >> CMP: Tunnels are some times key elements in a topology. Are tunnels >> considered as "interfaces" or should those be called out explicitly? >> > > [Alia] Tunnels aren't interfaces - but the details of what should be in > the topology depends on the topology info-model and isn't specified in the > architecture. > > > > Fair enough -- I agree it's not within the scope here, but I do thing that > tunnels require some looking into. > [Alia] Absolutely - I'd suggest talking to Joel Halpern, Jan Medved, Adrian Farrell, Tom Nadeau, and others interested in the topology info-model. > >> > -- Carlos. > PS: and thanks for not responding earlier, others were on vacation as well > :-) > :-) I hope yours was fun too! The Pergamon Museum was amazing. Alia --089e0153761e117a4604e3ed38fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Responses in-line with stuff= agreed and no longer relevant cut for easier reading.

On Wed, Aug 14, 2013 at 2:22 PM, Carlos Pignataro (cpignata= ) <cpignata@cisco.com> wrote:
On Aug 13, 2013, at 2:44 PM,= Alia Atlas <akat= las@gmail.com> wrote:
On Sun, Jul 28, 2013 at 6:06 PM, Carlos Pignataro (cp= ignata) <cpignata@cisco.com> wrote:

What i= s your specific concern and how would you want to see the reach and scope c= onfined in the architecture draft?
=A0

Perh= aps simply by aligning with the problem statement wording, in terms of &quo= t;routing and signaling". Or is the "signaling" piece confin= ed to label distribution?

[Alia] Sure - happy to change = the "Routing" to "Routing and Signaling" in the descrip= tion and in the figure.
4.1. =A0Example Network Application: Topology Manager

=A0 =A0One example of such an application is a Topology Manager. =A0Such an=
=A0 =A0application includes an I2RS client which uses the I2RS protocol to<= br> =A0 =A0collect information about the state of the network. =A0The Topology<= br> =A0 =A0Manager would collect device and interface state from devices it
=A0 =A0interacts with directly.

CMP: Tunnels are some times key elements in a topology. Are tunnels conside= red as "interfaces" or should those be called out explicitly?
=

[Alia] Tunnels aren't interfaces - but= the details of what should be in the topology depends on the topology info= -model and isn't specified in the architecture.
=A0

Fair enough -- I agree it's not within the scope here, but I do= thing that tunnels require some looking into.
=A0
[Alia] Absolutely - I'd suggest talking to Joel Halp= ern, Jan Medved, Adrian Farrell, Tom Nadeau, and others interested in the t= opology info-model.


-- Carlos.
PS: and thanks for not responding earlier, others were on vacation as= well :-)
:-) =A0I hope yours was fun too! =A0 The Perg= amon Museum was amazing.

Alia
--089e0153761e117a4604e3ed38fb-- From akatlas@gmail.com Wed Aug 14 12:20:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA121F9263 for ; Wed, 14 Aug 2013 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5WZ-5gpLNbA for ; Wed, 14 Aug 2013 12:20:03 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B35D221F969F for ; Wed, 14 Aug 2013 12:19:52 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so13805354oag.30 for ; Wed, 14 Aug 2013 12:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J9xPXSEqhO5A4jq9+4N571Zt3KFaBl0kH923ATbJLng=; b=vbDJhZ4Cu2JP9eVDiNbQcYTdeehRtl4cwXqMVJYff1EUJqzA0qgsdqXL2G+reo5+Wj utt8SXCHFf5cATGIU+Q3FG+4MY5Cd07FQTqbcsvVS1XpR9g0DfFy2NzuHwHkVjGxP/Bl Kc4eUsepIU6OD7jEid3o5W/EkkmBkqPh8amwR18pkOHYCpV4zynsCmXfRpoW5bUmihEu 456aZpAmEQJhrYAKopaw2/Pel9tD30+8Y0C+LMC3SK+m+6LCspZyM2u4q13K9q/2xM5W zQM0sH/nEukM72c3I/nQeerDya+KGPpwj+2Dhk63fHkLeDbEEF8YGZnB18DuB/iTgN7H 1IDA== MIME-Version: 1.0 X-Received: by 10.60.52.244 with SMTP id w20mr10788229oeo.30.1376507992189; Wed, 14 Aug 2013 12:19:52 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 12:19:52 -0700 (PDT) In-Reply-To: <520BCB50.2040703@joelhalpern.com> References: <51F8ED88.5050208@cisco.com> <520BC148.3030306@cisco.com> <520BC2F9.9080500@joelhalpern.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02E24B44@eusaamb109.ericsson.se> <520BCB50.2040703@joelhalpern.com> Date: Wed, 14 Aug 2013 15:19:52 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11334600e7b8ab04e3ed3d04 Cc: Jakob Heitz , "i2rs@ietf.org" , Joe Marcus Clarke Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:20:05 -0000 --001a11334600e7b8ab04e3ed3d04 Content-Type: text/plain; charset=ISO-8859-1 Joel, I agree - but I do think the atomic writes is interesting for handling write decisions based upon dynamic state that could be changed. Something to think about for a later version perhaps - and unrelated to the multiple writers of the same data case. Alia On Wed, Aug 14, 2013 at 2:24 PM, Joel M. Halpern wrote: > write-locks / atomic writes are an interesting quesiton, but probably > should not be thought about as part of the multiple writers case. The > multiple writers case is: > A writes value X. > B decides to write value Y. > How clever do we want to be about handling this. > The answer we have proposed is "as simpleminded as we can get away with." > The specifics we chose are > 1) this is an error case > 2) there are priorities which determine which value ends up in effect. > > Atomic writes could come up when there is a race, but more likely would > come up when there are system effects which would change this value when it > is not pinned by I2RS. > > Yours, > Joel > > > On 8/14/13 2:14 PM, Jakob Heitz wrote: > >> Or say: "must write atomically". >> >> Here is one way: >> In the WRITE message, put the value you want to write, as well as the >> value that you think that the parameter currently has. >> You can get the value "you think it has" from a previous READ, then you >> repeat that in your WRITE message. >> The target of the WRITE will refuse to write your value and return an >> error if the value was not what you thought it was. >> >> Another way: >> READ with reservation. When you READ, then set a reservation. >> When anyone WRITEs the same parameter, it kills all reservations. >> When you WRITE, the target system checks if you have a reservation and >> refuses to write if you don't and returns an error. >> >> Or you can write lock the parameter. >> >> -- >> Jakob Heitz. >> >> -----Original Message----- >>> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of >>> Joel M. Halpern >>> Sent: Wednesday, August 14, 2013 10:49 AM >>> To: Joe Marcus Clarke >>> Cc: i2rs@ietf.org; Alia Atlas >>> Subject: Re: [i2rs] Call for Adoption by WG: >>> draft-atlas-i2rs-architecture-**01 >>> (ends Aug 12) >>> >>> Depending upon how one reads RFCs, declaring that having two writers is >>> an >>> error is a MUST NOT write. >>> But we are also trying to recognize that no matter how many MUST NOT >>> statements we produce, things happen. So we are trying to define the >>> handling. I can live with precedence. I can live with "the item does >>> not >>> change". But I do think it is helpful for us to be explicit about the >>> behavior in >>> this far-to-likely error case. >>> >>> Yours, >>> Joel >>> >>> >>> On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: >>> >>>> On 8/13/13 4:01 PM, Alia Atlas wrote: >>>> >>>>> Section 1.2: >>>>> >>>>> As can also be seen in Figure 1, an I2RS Agent may communicate >>>>> with >>>>> multiple clients. Each client may send the agent a variety >>>>> of write >>>>> operations. The handling of this situation has been a source >>>>> of >>>>> discussion in the working group. In order to keep the >>>>> protocol >>>>> simple, the current view is that two clients should not be >>>>> attempting >>>>> to write (modify) the same piece of information. Such >>>>> collisions may >>>>> happen, but are considered error cases that should be >>>>> resolved by >>>>> >>>> the >>> >>>> network applications and management systems. >>>>> >>>>> JMC: I think more verbiage is needed around how to detect >>>>> collisions. >>>>> This is key to security considerations. Saying "clients should >>>>> not" is >>>>> not strong enough to keep our potential attackers. If each >>>>> operation is >>>>> tagged with an identifier that is unique to a client, then it >>>>> will be >>>>> possible to determine if the current client is trying to >>>>> overwrite data >>>>> from a previous client. This could fold into authz as well >>>>> where there >>>>> is a permission to allow global override of other application's >>>>> state. >>>>> >>>>> >>>>> [Alia] For the I2RS Agent to properly handle a collision, it does >>>>> need to store the client identifier. I think that is clear in Sec >>>>> 5.2 "Simply, the I2RS agent stores who did what operation to which >>>>> >>>> entity." >>> >>>> and the details in Sec 6.8 are "The current recommendation is to have >>>>> a simple priority associated with each I2RS clients, and the highest >>>>> priority change remains in effect. In the case of priority ties, the >>>>> first client whose attribution is associated with the data will keep >>>>> control." We already have a reference to Sec 6.8 right there - and >>>>> that section is where the details are discussed. What specific >>>>> additional >>>>> verbiage do you think would be useful? The priority is a knob to >>>>> allow >>>>> overwriting of other applications' state - though needing to is >>>>> considered an error. :-) >>>>> >>>> >>>> When I first read this, I wanted something stronger to prevent clients >>>> from writing to the same piece of data. I think the forward >>>> references are fine if perhaps a bit late in the text. But my ask was >>>> to strengthen the language to say "must not write." >>>> >>>> >>>>> >>>>> Section 2: >>>>> >>>>> read scope: ... >>>>> >>>>> write scope: ... >>>>> >>>>> JMC: Should there be an event or notification scope in addition >>>>> to read >>>>> and write? >>>>> >>>>> >>>>> [Alia] I think it is folded into the read scope. If we find the need >>>>> for such a term later on, then we can add it. >>>>> >>>> >>>> This section talks about "terminology" used in the draft. However, >>>> "read scope" as terminology is not used anywhere. The concept of >>>> _reading_ data is, however, quite prevalent. In the same way, the >>>> draft talks about "notification" in a number of contexts. As such, I >>>> feel there is enough distinction there to warrant calling out what is >>>> meant by a notification scope. >>>> >>>> "notification scope: The set of events and associated information that >>>> will be sent northbound by the I2RS Agent to I2RS Clients. Clients >>>> have the ability to register for specific events, but must do so given >>>> the access restrictions of their associated read scope." >>>> >>>> >>>>> Section 3.4: >>>>> >>>>> I2RS clients may be operating on behalf of other applications. >>>>> While >>>>> those applications' identities are not need for >>>>> authorization, each >>>>> application should have a unique opaque identifier that can be >>>>> provided by the I2RS client to the I2RS agent for purposes of >>>>> tracking attribution of operations. >>>>> >>>>> JMC: The opaque ID might make it hard to accurately attribute >>>>> changes. >>>>> I2RS should mandate a way to ensure traceability back to a >>>>> client that >>>>> made the change or was granted access. >>>>> >>>>> >>>>> [Alia] What do you have in mind? The I2RS client will have a >>>>> security role and its scope. The I2RS client needs to vet the >>>>> applications that it is a broker for. The opaque ID can be something >>>>> that is >>>>> >>>> meaningful >>> >>>> to that I2RS client. Basically, I2RS is providing the identity and >>>>> security for between the I2RS client and the I2RS agent. I don't see >>>>> it as practical or appropriate to try and define how the I2RS client >>>>> and its applications interact; I know the broker/controller model is >>>>> popular and so we do need enough to help support traceability to a >>>>> secondary ID, but I'm not sure what is needed or appropriate beyond >>>>> >>>> that. >>> >>>> >>>> After listening to the working group session and based on other >>>> threads, this text is now clearer to me. To summarize my feeling, I >>>> don't think I2RS should mandate a northbound Client protocol, but we >>>> need a unique way to identify the specific Client that obtained >>>> access. This means that even in a load-balancing or HA case, there >>>> must be a way to uniquely identify the Client that communicate with >>>> the Agent. The northbound actor driving the Client should also be >>>> identifiable, but that is outside the scope of this document. >>>> >>>> Section 5.2.2: >>>>> >>>>> An I2RS Agent may decide that some state should no longer be >>>>> applied. >>>>> An I2RS Client may instruct an Agent to remove state it has >>>>> applied. >>>>> In all such cases, the state will revert to what it would >>>>> have been >>>>> without the I2RS; that state is generally whatever was >>>>> specified via >>>>> the CLI, NetConf, SNMP, etc. I2RS Agents will not store >>>>> multiple >>>>> alternative states, nor try to determine which one among such >>>>> a >>>>> plurality it should fall back to. Thus, the model followed >>>>> is not >>>>> like the RIB, where multiple routes are stored at different >>>>> preferences. >>>>> >>>>> JMC: Previously I had commented that one event that should be >>>>> >>>> supported >>> >>>> and perhaps documented here is that if the agent decides to >>>>> revert the >>>>> application can be notified that its state has been reverted. >>>>> This >>>>> might also be useful if another client overrides some portion of >>>>> another >>>>> client's state (this is covered in Section 6.8, but might be >>>>> useful to >>>>> mention here as well). Perhaps add at the end of Section 5.2.2: >>>>> >>>>> "A client may choose to be notified whenever its state is >>>>> reverted >>>>> either by another client or by the I2RS agent." >>>>> >>>>> >>>>> [Alia] I'll put in: "An I2RS Client may register for notifications >>>>> when state that was applied by a particular I2RS Client is modified >>>>> or removed." That is slightly different since it allows an I2RS >>>>> Client to learn about the changes to state from itself or from a >>>>> different I2RS Client. >>>>> >>>> >>>> WFM, thanks. >>>> >>>> >>>>> Section 5.4.2: >>>>> >>>>> (Bulleted list of examples) >>>>> >>>>> JMC: Consider adding an example for an event such as a new route >>>>> >>>> being >>> >>>> learned or an OSPF neighbor removal. >>>>> >>>>> >>>>> [Alia] I think that "writing routes or prefixes to be advertised via >>>>> the >>>>> protocol" describes a new route being learned. I'd prefer not to put >>>>> OSPF neighbor removal in as an example. It raises the questions >>>>> about what is configuration vs. ephemeral data and the I2RS scope. >>>>> If you have a good use-case that requires it, then I'd be quite >>>>> interested in seeing it. >>>>> >>>> >>>> I was specifically asking about an _event_ use case. Very simply if >>>> we learn/lose a route, I'd want my Client to be notified so I can >>>> perhaps react to it to install another route or remove a route I have >>>> previously installed (e.g., a failover/failback use case). >>>> >>>> Additionally, if a peer is otherwise reachable, but stops >>>> participating in OSPF, BGP, etc., I would like I2RS to notify my >>>> Client as I may not know about this any other way (though I could be >>>> flooded with route delete events, it's good to correlate that to a peer >>>> going >>>> >>> away). >>> >>>> >>>> >>>>> >>>>> >>>>> Section 5.4.4: >>>>> >>>>> Many network elements have separate policy and QoS mechanisms, >>>>> including knobs which affect local path computation and queue >>>>> >>>> control >>> >>>> capabilities. These capabilities vary widely across >>>>> implementations, >>>>> and I2RS cannot model the full range of information >>>>> collection or >>>>> manipulation of these attributes. A core set does need to be >>>>> included in the I2RS data models and in the expected >>>>> interfaces >>>>> between the I2RS Agent and the network element, in order to >>>>> >>>> provide >>> >>>> basic capabilities and the hooks for future extensibility. >>>>> >>>>> JMC: I think this either needs an editor's note for more >>>>> discussion or >>>>> perhaps QoS in general should be out of scope. >>>>> >>>>> >>>>> [Alia] I am happy to add in an editor's note for more discussion - >>>>> but we should start that conversation now on the list - because the >>>>> WG does have quite tight deadlines for milestones. >>>>> >>>> >>>> Fair enough. >>>> >>>> Section 6.1: >>>>> >>>>> That protocol may use several underlying transports (TCP, >>>>> SCTP, DCCP), with suitable authentication and integrity >>>>> protection >>>>> mechanisms. Whatever transport is used for the data >>>>> exchange, it >>>>> must also support suitable congestion control mechanisms. >>>>> >>>>> JMC: I think Carlos (or someone) mentioned this, but I'm not >>>>> sure DCCP >>>>> is ideal for I2RS since we likely do want reliable order of >>>>> delivery. >>>>> >>>>> >>>>> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - >>>>> but it may be >>>>> good for delivering statistics. I think we'll have different >>>>> transport >>>>> options depending on the requirements of a particular data model or >>>>> section. Since you are the second person to be confused by that >>>>> section, I've added the following sentence: >>>>> >>>>> "These different transports can support different types of >>>>> communication (e.g. control, reading, notifications, and information >>>>> collection) and different sets of data." >>>>> >>>>> Let me know if that helps or if you have better ideas for wording. >>>>> >>>> >>>> That works. >>>> >>>> Section 6.7: >>>>> >>>>> One of the other important aspects of the I2RS is that it is >>>>> intended >>>>> to simplify collecting information about the state of network >>>>> elements. >>>>> >>>>> JMC: I think this needs to be more specific to routing >>>>> information >>>>> versus any information from the network element (e.g., it does >>>>> not >>>>> >>>> cover >>> >>>> CPU statistics). >>>>> >>>>> >>>>> [Alia] The scoping is a question - and that will depend on what the >>>>> use-cases we consider need and what the related information and data >>>>> models need to be. If you look at the >>>>> draft-bitar-i2rs-service-**chaining-00, it does ask for things like >>>>> CPU >>>>> load. I do think there is a real need to be able to get back >>>>> thresholded and filtered information. You probably heard Ed's personal >>>>> thoughts about a single protocol as well... So - I don't think the >>>>> architecture needs to restrict the data in scope - particular in a >>>>> section that is talking about communication patterns - but as a WG, >>>>> we need to keep a tight focus that still provides sufficient >>>>> information to fully solve the desired use-cases. >>>>> >>>> >>>> My concerns comes from a desire not to have I2RS become a common >>>> API/protocol for things that SNMP or NETCONF or some other potential >>>> data collection scheme is used for. So I agree we need a tight focus >>>> and potentially a litmus test for what should be adopted as >>>> collectable data via I2RS. As it stands now, I think someone could >>>> argue for any kind of data and present a use case for it (e.g., >>>> latency, interface errors, location). So the statement I made was >>>> more around the lines of should I2RS stay pure to routing and routed >>>> topology or should we really open the door to other data that is not >>>> >>> specifically related to routing? >>> >>>> >>>> Joe >>>> >>>> >>>>> ______________________________**_________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/**listinfo/i2rs >>> >> >> --001a11334600e7b8ab04e3ed3d04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

I agree - but I do think the atom= ic writes is interesting for handling write decisions based upon dynamic st= ate that could be changed. =A0Something to think about for a later version = perhaps - and unrelated to the multiple writers of the same data case.

Alia


On Wed, Aug 14, 2013 at 2:24 PM, Joel M. Halpern <jmh@j= oelhalpern.com> wrote:
write-locks / atomic writes are an interesti= ng quesiton, but probably should not be thought about as part of the multip= le writers case. =A0The multiple writers case is:
A writes value X.
B decides to write value Y.
How clever do we want to be about handling this.
The answer we have proposed is "as simpleminded as we can get away wit= h."
The specifics we chose are
1) this is an error case
2) there are priorities which determine which value ends up in effect.

Atomic writes could come up when there is a race, but more likely would com= e up when there are system effects which would change this value when it is= not pinned by I2RS.

Yours,
Joel


On 8/14/13 2:14 PM, Jakob Heitz wrote:
Or say: "must write atomically".

Here is one way:
In the WRITE message, put the value you want to write, as well as the value= that you think that the parameter currently has.
You can get the value "you think it has" from a previous READ, th= en you repeat that in your WRITE message.
The target of the WRITE will refuse to write your value and return an error= if the value was not what you thought it was.

Another way:
READ with reservation. When you READ, then set a reservation.
When anyone WRITEs the same parameter, it kills all reservations.
When you WRITE, the target system checks if you have a reservation and refu= ses to write if you don't and returns an error.

Or you can write lock the parameter.

--
Jakob Heitz.

-----Original Message-----
From: i2rs-bounc= es@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Wednesday, August 14, 2013 10:49 AM
To: Joe Marcus Clarke
Cc: i2rs@ietf.org; A= lia Atlas
Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-= 01
(ends Aug 12)

Depending upon how one reads RFCs, declaring that having two writers is an<= br> error is a MUST NOT write.
But we are also trying to recognize that no matter how many MUST NOT
statements we produce, things happen. =A0So we are trying to define the
handling. =A0I can live with precedence. =A0I can live with "the item = does not
change". =A0But I do think it is helpful for us to be explicit about t= he behavior in
this far-to-likely error case.

Yours,
Joel


On 8/14/13 1:41 PM, Joe Marcus Clarke wrote:
On 8/13/13 4:01 PM, Alia Atlas wrote:
=A0 =A0 =A0 Section 1.2:

=A0 =A0 =A0 As can also be seen in Figure 1, an I2RS Agent may communicate = with
=A0 =A0 =A0 =A0 =A0multiple clients. =A0Each client may send the agent a va= riety of write
=A0 =A0 =A0 =A0 =A0operations. =A0The handling of this situation has been a= source of
=A0 =A0 =A0 =A0 =A0discussion in the working group. =A0In order to keep the= protocol
=A0 =A0 =A0 =A0 =A0simple, the current view is that two clients should not = be attempting
=A0 =A0 =A0 =A0 =A0to write (modify) the same piece of information. =A0Such= collisions may
=A0 =A0 =A0 =A0 =A0happen, but are considered error cases that should be re= solved by
the
=A0 =A0 =A0 =A0 =A0network applications and management systems.

=A0 =A0 =A0 JMC: I think more verbiage is needed around how to detect colli= sions.
=A0 =A0 =A0 This is key to security considerations. =A0Saying "clients= should not" is
=A0 =A0 =A0 not strong enough to keep our potential attackers. =A0If each o= peration is
=A0 =A0 =A0 tagged with an identifier that is unique to a client, then it w= ill be
=A0 =A0 =A0 possible to determine if the current client is trying to overwr= ite data
=A0 =A0 =A0 from a previous client. =A0This could fold into authz as well w= here there
=A0 =A0 =A0 is a permission to allow global override of other application&#= 39;s state.


[Alia] For the I2RS Agent to properly handle a collision, it does
need to store the client identifier. =A0I think that is clear in Sec
5.2 "Simply, the I2RS agent stores who did what operation to which
entity."
and the details in Sec 6.8 are "The current recommendation is to have<= br> a simple priority associated with each I2RS clients, and the highest
priority change remains in effect. In the case of priority ties, the
first client whose attribution is associated with the data will keep
control." =A0We already have a reference to Sec 6.8 right there - and<= br> that section is where the details are discussed. =A0What specific additiona= l
verbiage do you think would be useful? =A0 The priority is a knob to allow<= br> overwriting of other applications' state - though needing to is
considered an error. :-)

When I first read this, I wanted something stronger to prevent clients
from writing to the same piece of data. =A0I think the forward
references are fine if perhaps a bit late in the text. =A0But my ask was to strengthen the language to say "must not write."



=A0 =A0 =A0 Section 2:

=A0 =A0 =A0 read scope: ...

=A0 =A0 =A0 write scope: ...

=A0 =A0 =A0 JMC: Should there be an event or notification scope in addition= to read
=A0 =A0 =A0 and write?


[Alia] I think it is folded into the read scope. =A0If we find the need
for such a term later on, then we can add it.

This section talks about "terminology" used in the draft. =A0Howe= ver,
"read scope" as terminology is not used anywhere. =A0The concept = of
_reading_ data is, however, quite prevalent. =A0In the same way, the
draft talks about "notification" in a number of contexts. =A0As s= uch, I
feel there is enough distinction there to warrant calling out what is
meant by a notification scope.

"notification scope: The set of events and associated information that=
will be sent northbound by the I2RS Agent to I2RS Clients. =A0Clients
have the ability to register for specific events, but must do so given
the access restrictions of their associated read scope."


=A0 =A0 =A0 Section 3.4:

=A0 =A0 =A0 I2RS clients may be operating on behalf of other applications. = =A0While
=A0 =A0 =A0 =A0 =A0those applications' identities are not need for auth= orization, each
=A0 =A0 =A0 =A0 =A0application should have a unique opaque identifier that = can be
=A0 =A0 =A0 =A0 =A0provided by the I2RS client to the I2RS agent for purpos= es of
=A0 =A0 =A0 =A0 =A0tracking attribution of operations.

=A0 =A0 =A0 JMC: The opaque ID might make it hard to accurately attribute c= hanges.
=A0 =A0 =A0 I2RS should mandate a way to ensure traceability back to a clie= nt that
=A0 =A0 =A0 made the change or was granted access.


[Alia] What do you have in mind? =A0The I2RS client will have a
security role and its scope. =A0The I2RS client needs to vet the
applications that it is a broker for. =A0The opaque ID can be something tha= t is
meaningful
to that I2RS client. =A0 Basically, I2RS is providing the identity and
security for between the I2RS client and the I2RS agent. =A0I don't see=
it as practical or appropriate to try and define how the I2RS client
and its applications interact; I know the broker/controller model is
popular and so we do need enough to help support traceability to a
secondary ID, but I'm not sure what is needed or appropriate beyond
that.

After listening to the working group session and based on other
threads, this text is now clearer to me. =A0To summarize my feeling, I
don't think I2RS should mandate a northbound Client protocol, but we need a unique way to identify the specific Client that obtained
access. =A0This means that even in a load-balancing or HA case, there
must be a way to uniquely identify the Client that communicate with
the Agent. =A0The northbound actor driving the Client should also be
identifiable, but that is outside the scope of this document.

=A0 =A0 =A0 Section 5.2.2:

=A0 =A0 =A0 An I2RS Agent may decide that some state should no longer be ap= plied.
=A0 =A0 =A0 =A0 =A0An I2RS Client may instruct an Agent to remove state it = has applied.
=A0 =A0 =A0 =A0 =A0In all such cases, the state will revert to what it woul= d have been
=A0 =A0 =A0 =A0 =A0without the I2RS; that state is generally whatever was s= pecified via
=A0 =A0 =A0 =A0 =A0the CLI, NetConf, SNMP, etc. =A0I2RS Agents will not sto= re multiple
=A0 =A0 =A0 =A0 =A0alternative states, nor try to determine which one among= such a
=A0 =A0 =A0 =A0 =A0plurality it should fall back to. =A0Thus, the model fol= lowed is not
=A0 =A0 =A0 =A0 =A0like the RIB, where multiple routes are stored at differ= ent
=A0 =A0 =A0 =A0 =A0preferences.

=A0 =A0 =A0 JMC: =A0Previously I had commented that one event that should b= e
supported
=A0 =A0 =A0 and perhaps documented here is that if the agent decides to rev= ert the
=A0 =A0 =A0 application can be notified that its state has been reverted. = =A0This
=A0 =A0 =A0 might also be useful if another client overrides some portion o= f another
=A0 =A0 =A0 client's state (this is covered in Section 6.8, but might b= e useful to
=A0 =A0 =A0 mention here as well). =A0Perhaps add at the end of Section 5.2= .2:

=A0 =A0 =A0 =A0 "A client may choose to be notified whenever its state= is reverted
=A0 =A0 =A0 either by another client or by the I2RS agent."


[Alia] I'll put in: "An I2RS Client may register for notifications=
when state that was applied by a particular I2RS Client is modified
or removed." =A0That is slightly different since it allows an I2RS
Client to learn about the changes to state from itself or from a
different I2RS Client.

WFM, thanks.


=A0 =A0 =A0 Section 5.4.2:

=A0 =A0 =A0 (Bulleted list of examples)

=A0 =A0 =A0 JMC: Consider adding an example for an event such as a new rout= e
being
=A0 =A0 =A0 learned or an OSPF neighbor removal.


[Alia] I think that "writing routes or prefixes to be advertised via t= he
protocol" describes a new route being learned. =A0 I'd prefer not = to put
OSPF neighbor removal in as an example. =A0It raises the questions
about what is configuration vs. ephemeral data and the I2RS scope.
If you have a good use-case that requires it, then I'd be quite
interested in seeing it.

I was specifically asking about an _event_ use case. =A0Very simply if
we learn/lose a route, I'd want my Client to be notified so I can
perhaps react to it to install another route or remove a route I have
previously installed (e.g., a failover/failback use case).

Additionally, if a peer is otherwise reachable, but stops
participating in OSPF, BGP, etc., I would like I2RS to notify my
Client as I may not know about this any other way (though I could be
flooded with route delete events, it's good to correlate that to a peer= going
away).




=A0 =A0 =A0 Section 5.4.4:

=A0 =A0 =A0 Many network elements have separate policy and QoS mechanisms,<= br> =A0 =A0 =A0 =A0 =A0including knobs which affect local path computation and = queue
control
=A0 =A0 =A0 =A0 =A0capabilities. =A0These capabilities vary widely across i= mplementations,
=A0 =A0 =A0 =A0 =A0and I2RS cannot model the full range of information coll= ection or
=A0 =A0 =A0 =A0 =A0manipulation of these attributes. =A0A core set does nee= d to be
=A0 =A0 =A0 =A0 =A0included in the I2RS data models and in the expected int= erfaces
=A0 =A0 =A0 =A0 =A0between the I2RS Agent and the network element, in order= to
provide
=A0 =A0 =A0 =A0 =A0basic capabilities and the hooks for future extensibilit= y.

=A0 =A0 =A0 JMC: I think this either needs an editor's note for more di= scussion or
=A0 =A0 =A0 perhaps QoS in general should be out of scope.


[Alia] I am happy to add in an editor's note for more discussion -
but we should start that conversation now on the list - because the
WG does have quite tight deadlines for milestones.

Fair enough.

=A0 =A0 =A0 Section 6.1:

=A0 =A0 =A0 That protocol may use several underlying transports (TCP,
=A0 =A0 =A0 =A0 =A0SCTP, DCCP), with suitable authentication and integrity = protection
=A0 =A0 =A0 =A0 =A0mechanisms. =A0Whatever transport is used for the data e= xchange, it
=A0 =A0 =A0 =A0 =A0must also support suitable congestion control mechanisms= .

=A0 =A0 =A0 JMC: I think Carlos (or someone) mentioned this, but I'm no= t sure DCCP
=A0 =A0 =A0 is ideal for I2RS since we likely do want reliable order of del= ivery.


[Alia] Yes - DCCP is clearly the wrong choice for a control channel -
but it may be
good for delivering statistics. =A0 I think we'll have different transp= ort
options depending on the requirements of a particular data model or
section. =A0Since you are the second person to be confused by that
section, I've added the following sentence:

"These different transports can support different types of
communication (e.g. control, reading, notifications, and information
collection) and different sets of data."

=A0 =A0Let me know if that helps or if you have better ideas for wording.

That works.

=A0 =A0 =A0 Section 6.7:

=A0 =A0 =A0 One of the other important aspects of the I2RS is that it is in= tended
=A0 =A0 =A0 =A0 =A0to simplify collecting information about the state of ne= twork
=A0 =A0 =A0 =A0 =A0elements.

=A0 =A0 =A0 JMC: I think this needs to be more specific to routing informat= ion
=A0 =A0 =A0 versus any information from the network element (e.g., it does = not
cover
=A0 =A0 =A0 CPU statistics).


[Alia] The scoping is a question - and that will depend on what the
use-cases we consider need and what the related information and data
models need to be. =A0If you look at the
draft-bitar-i2rs-service-chaining-00, it does ask for things like CP= U
load. =A0I do think there is a real need to be able to get back
thresholded and filtered information. =A0You probably heard Ed's person= al
thoughts about a single protocol as well... =A0 So - I don't think the<= br> architecture needs to restrict the data in scope - particular in a
section that is talking about communication patterns - but as a WG,
we need to keep a tight focus that still provides sufficient
information to fully solve the desired use-cases.

My concerns comes from a desire not to have I2RS become a common
API/protocol for things that SNMP or NETCONF or some other potential
data collection scheme is used for. =A0So I agree we need a tight focus
and potentially a litmus test for what should be adopted as
collectable data via I2RS. =A0As it stands now, I think someone could
argue for any kind of data and present a use case for it (e.g.,
latency, interface errors, location). =A0So the statement I made was
more around the lines of should I2RS stay pure to routing and routed
topology or should we really open the door to other data that is not
specifically related to routing?

Joe


_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--001a11334600e7b8ab04e3ed3d04-- From lberger@labn.net Wed Aug 14 12:20:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837FD21E80DB for ; Wed, 14 Aug 2013 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5p1ujvz7tKx for ; Wed, 14 Aug 2013 12:20:04 -0700 (PDT) Received: from oproxy13-pub.mail.unifiedlayer.com (oproxy13-pub.mail.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id C596611E8191 for ; Wed, 14 Aug 2013 12:19:54 -0700 (PDT) Received: (qmail 31801 invoked by uid 0); 14 Aug 2013 19:19:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.mail.unifiedlayer.com with SMTP; 14 Aug 2013 19:19:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QfO+NZSAOdvXCCeFoOpGYokaxRxceorD4emfL+bgKSI=; b=r7qvmRcD9+sv6u5KU0w9V3piN0tfO11FuJeG4hMZHC4AbHeD6P3uCuGTDbuZV+HonGxrb6qZmOTqITdPKF61TR5rt4rhDLW7028PAzqaoPHQVeXPUgNgyJSCYNdtw0q/; Received: from box313.bluehost.com ([69.89.31.113]:48454 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V9gbU-0004NW-Uj; Wed, 14 Aug 2013 13:19:33 -0600 Message-ID: <520BD843.3060007@labn.net> Date: Wed, 14 Aug 2013 15:19:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joe Marcus Clarke , Alia Atlas References: <51FA492D.3070402@labn.net> <51FA792E.3040908@cisco.com> <6BCE198E4EAEFC4CAB45D75826EFB07602F7B029@eusaamb101.ericsson.se> <51FA7B9E.8000102@cisco.com> <51FAEF39.9020102@cisco.com> <520BC310.5030902@cisco.com> In-Reply-To: <520BC310.5030902@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "i2rs@ietf.org" , Joel Halpern Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:20:09 -0000 I agree, a fine start. There's room to add/relocate in the future. Thanks! Lou On 08/14/2013 01:49 PM, Joe Marcus Clarke wrote: > On 8/13/13 4:58 PM, Alia Atlas wrote: >> I am going to publish an updated version of >> draft-atlas-i2rs-architecture without fully addressing this point. >> >> I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 >> Identity and Security Role that says: >> >> "I2RS must support client redundancy. At the simplest, this can be >> handled by having a primary and a backup network application that both >> use the same client identity and can successfully authenticate as >> such. Since I2RS does not require a continuous transport connection >> and supports multiple transport sessions, this can provide some basic >> redundancy. However, it does not address concerns for troubleshooting >> and accountability about knowing which network application is actually >> active. At a minimum, basic transport information about each >> connection and time can be logged with the identity. Further >> discussion is necessary to determine whether additional client >> identification information is necessary.[[Editor's >> note: This requires more discussion in the working group.]]" > > This is fine as a start. I would want to strengthen the language to > ensure that an I2RS Agent always stores Client connection information > with a timestamp. This information should be queriable via I2RS (with > appropriate read scope). > > Joe > >> >> Alia >> >> >> On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke > > wrote: >> >> On 8/1/13 11:19 AM, Alia Atlas wrote: >> > Joe, >> > >> > Ok - so what I hear from you is needed is the >> > client role >> > client identity >> > sub-client identity? >> > >> > Where the permissions and ownership of state is tied to the client >> role? >> > Does that match to what you are saying? I believe we're assuming >> that >> > the ownership of state is tied to the client identity - and you are >> > suggesting that if so, we need a client sub-identity or such? >> >> Yes, I think that is in line with what I'm suggesting. If we can allow >> Client A to assume the identity of Client B using the same credentials, >> I would want some way to know that this is indeed Client B now acting on >> behalf of either itself or some northbound controller. >> >> Joe >> >> > >> > Alia >> > >> > >> > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke >> >> > >> wrote: >> > >> > On 8/1/13 11:11 AM, Joel Halpern wrote: >> > > The client is the entity that is authenticated and >> authorized. If the >> > > client is acting on behalf of someone else, we assume that the >> > > authentication and authorization of that party is the task >> of the >> > client >> > > and outside our scope. However we include that identity so that >> > actions >> > > can be easily correlated with originators. >> > >> > Right. I get that. I had thought we were talking about two >> clients >> > that might be redundant to each other where Client 1 dies and >> Client 2 >> > assumes its identity to make changes possibly driven by northbound >> > actors. Even in this case, I feel Client 2 still needs to >> maintain a >> > unique identification to the I2RS agent so that one can trace the >> > operation back to the specific I2RS client (in addition to the >> > northbound actor). >> > >> > Joe >> > >> > > >> > > Yours, >> > > Joel >> > > >> > > Sent from my Android phone using TouchDown >> (www.nitrodesk.com >> > ) >> > > >> > > -----Original Message----- >> > > *From:* Joe Marcus Clarke [jclarke@cisco.com >> >> > >] >> > > *Received:* Thursday, 01 Aug 2013, 17:07 >> > > *To:* Alia Atlas [akatlas@gmail.com >> > >] >> > > *CC:* Lou Berger [lberger@labn.net >> >]; >> > i2rs@ietf.org > > [i2rs@ietf.org >> > >]; Joel >> > > Halpern [joel.halpern@ericsson.com >> > >] >> > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault >> Tolerance >> > > in draft-atlas-i2rs-architecture-01 >> > > >> > > On 8/1/13 7:51 AM, Alia Atlas wrote: >> > >> Not to answer for Joel, but my view is that a client is >> identified by >> > >> its identity. A different application can take over from the >> > first by >> > >> using the same identity. Loss of a transport session does >> not cause >> > >> existing client state to be removed (in the architecture) - so >> > there is >> > >> the ability for a new application to take over. >> > >> >> > >> Does that help? >> > > >> > > That worries me without more discussion about authentication. >> > > Additionally, from a troubleshooting standpoint, if I can >> assume the >> > > same identity as another client, how can I be absolutely >> sure which >> > > client does what to the agent? I feel there needs to be more to >> > ensure >> > > accountability of what client does what, certainly from a >> security >> > > perspective, but also from a troubleshooting perspective. >> > > >> > > Joe >> > > >> > >> >> > >> Alia >> > >> >> > >> >> > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger >> >> > > >> > >> >> >>> wrote: >> > >> >> > >> Hi Joel, >> > >> In today's session, I asked about provisions in the >> > architecture >> > >> (document) for Client Redundancy/Fault Tolerance. I believe >> > you stated >> > >> that "it's not needed" and that you'd elaborate on the >> list. >> > >> >> > >> I believe you also answered a latter question by >> stating that >> > clients >> > >> are free to coordinate between themselves to provide >> > redundancy. Is this >> > >> the simple answer? If not, can you elaborate? >> > >> >> > >> Thanks, >> > >> Lou >> > >> _______________________________________________ >> > >> i2rs mailing list >> > >> i2rs@ietf.org >> > > >> > >> >> > >> https://www.ietf.org/mailman/listinfo/i2rs >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> i2rs mailing list >> > >> i2rs@ietf.org > > >> > >> https://www.ietf.org/mailman/listinfo/i2rs >> > >> >> > > >> > > >> > > -- >> > > Joe Marcus Clarke, CCIE #5384, | | >> > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> > > Phone: +1 (919) 392-2867 >> >> > c i s c o S y s t e m s >> > > Email: jclarke@cisco.com >> > >> > > >> > > >> > >> ---------------------------------------------------------------------------- >> > >> > >> > -- >> > Joe Marcus Clarke, CCIE #5384, | | >> > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> > Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> > Phone: +1 (919) 392-2867 >> c >> > i s c o S y s t e m s >> > Email: jclarke@cisco.com >> > >> > >> > >> ---------------------------------------------------------------------------- >> > >> > >> >> >> -- >> Joe Marcus Clarke, CCIE #5384, | | >> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >> Phone: +1 (919) 392-2867 c >> i s c o S y s t e m s >> Email: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > From akatlas@gmail.com Wed Aug 14 12:26:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5C811E80FF for ; Wed, 14 Aug 2013 12:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG0dfS8mITFS for ; Wed, 14 Aug 2013 12:26:16 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2835521F99DD for ; Wed, 14 Aug 2013 12:26:16 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so12568363obc.34 for ; Wed, 14 Aug 2013 12:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dLJ13JK0p6uVIiZnK9Raj0ipXOOAK1jex/uGXwPbDOo=; b=LS0O3G6dho1LV86EN7uzkD5L5+h69BmAoEiMExfhJQjISFqbWg8bXCeZJe+w4Ctgk2 TPKs6W9Ogn3/Kwoyn2GO8xUN+Zg6matLHg3Y4k+ccw2yUDNvOUhqyN3C1Q/2I/SiwB78 CPP0CO/bY95BUgXTBtnAxRwFusm3aYv22qC7bZF8nwnxD5cHoZvdDn3aK3P67bgxjpt2 MTHbehipy1ySnU2gsdyBYgv8VlKzkC5JcJD9Uy2E8Y/9n/LASrIFs/GtzqY/wwY6szeF QLnXwsTQLn0IfnordCEMAvOl/9VTtPJ5e7cAe2DG3JBwApTkVzhXYhFK6ew/oA0QOPId j2+Q== MIME-Version: 1.0 X-Received: by 10.182.241.71 with SMTP id wg7mr13496855obc.50.1376508375597; Wed, 14 Aug 2013 12:26:15 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 12:26:15 -0700 (PDT) Date: Wed, 14 Aug 2013 15:26:15 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a11c2e0f0c20a1004e3ed54b7 Cc: "i2rs@ietf.org" , Joel Halpern , "lberger@labn.net" Subject: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 19:26:18 -0000 --001a11c2e0f0c20a1004e3ed54b7 Content-Type: text/plain; charset=ISO-8859-1 I am pulling this into a separate thread because I think that it merits some discussion. There seems to be a strong desire for easy traceability/accountability/troubleshooting that is better than just syslog or screen-scraping - something that is vendor-agnostic. The idea of having the I2RS Agent store all the operations and attribution done is not appealing. Clearly, the most recent writer of data will need to be stored. Perhaps an info-model would be useful - and then an I2RS agent could write the data to a file in a structured format? Perhaps there needs to be some specific interactions with the files - ability to fetch, rotate, clear? I'm not sure what's needed. Should this be the same info-model that describes the connections to the I2RS agent and relevant information and counters? Do we have anyone motivated and interested in this particular area enough to write up a short/quick draft and drive discussion? Thanks, Alia On Wed, Aug 14, 2013 at 1:49 PM, Joe Marcus Clarke wrote: > On 8/13/13 4:58 PM, Alia Atlas wrote: > > I am going to publish an updated version of > > draft-atlas-i2rs-architecture without fully addressing this point. > > > > I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 > > Identity and Security Role that says: > > > > "I2RS must support client redundancy. At the simplest, this can be > > handled by having a primary and a backup network application that both > > use the same client identity and can successfully authenticate as > > such. Since I2RS does not require a continuous transport connection > > and supports multiple transport sessions, this can provide some basic > > redundancy. However, it does not address concerns for troubleshooting > > and accountability about knowing which network application is actually > > active. At a minimum, basic transport information about each > > connection and time can be logged with the identity. Further > > discussion is necessary to determine whether additional client > > identification information is necessary.[[Editor's > > note: This requires more discussion in the working group.]]" > > This is fine as a start. I would want to strengthen the language to > ensure that an I2RS Agent always stores Client connection information > with a timestamp. This information should be queriable via I2RS (with > appropriate read scope). > > Joe > > > > > Alia > > > > > > On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke > > wrote: > > > > On 8/1/13 11:19 AM, Alia Atlas wrote: > > > Joe, > > > > > > Ok - so what I hear from you is needed is the > > > client role > > > client identity > > > sub-client identity? > > > > > > Where the permissions and ownership of state is tied to the client > > role? > > > Does that match to what you are saying? I believe we're assuming > > that > > > the ownership of state is tied to the client identity - and you are > > > suggesting that if so, we need a client sub-identity or such? > > > > Yes, I think that is in line with what I'm suggesting. If we can > allow > > Client A to assume the identity of Client B using the same > credentials, > > I would want some way to know that this is indeed Client B now > acting on > > behalf of either itself or some northbound controller. > > > > Joe > > > > > > > > Alia > > > > > > > > > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke > > > > > >> wrote: > > > > > > On 8/1/13 11:11 AM, Joel Halpern wrote: > > > > The client is the entity that is authenticated and > > authorized. If the > > > > client is acting on behalf of someone else, we assume that > the > > > > authentication and authorization of that party is the task > > of the > > > client > > > > and outside our scope. However we include that identity so > that > > > actions > > > > can be easily correlated with originators. > > > > > > Right. I get that. I had thought we were talking about two > > clients > > > that might be redundant to each other where Client 1 dies and > > Client 2 > > > assumes its identity to make changes possibly driven by > northbound > > > actors. Even in this case, I feel Client 2 still needs to > > maintain a > > > unique identification to the I2RS agent so that one can trace > the > > > operation back to the specific I2RS client (in addition to the > > > northbound actor). > > > > > > Joe > > > > > > > > > > > Yours, > > > > Joel > > > > > > > > Sent from my Android phone using TouchDown > > (www.nitrodesk.com > > > ) > > > > > > > > -----Original Message----- > > > > *From:* Joe Marcus Clarke [jclarke@cisco.com > > > > > >] > > > > *Received:* Thursday, 01 Aug 2013, 17:07 > > > > *To:* Alia Atlas [akatlas@gmail.com > > > >] > > > > *CC:* Lou Berger [lberger@labn.net > > >]; > > > i2rs@ietf.org > > [i2rs@ietf.org > > > >]; Joel > > > > Halpern [joel.halpern@ericsson.com > > > >] > > > > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault > > Tolerance > > > > in draft-atlas-i2rs-architecture-01 > > > > > > > > On 8/1/13 7:51 AM, Alia Atlas wrote: > > > >> Not to answer for Joel, but my view is that a client is > > identified by > > > >> its identity. A different application can take over from > the > > > first by > > > >> using the same identity. Loss of a transport session does > > not cause > > > >> existing client state to be removed (in the architecture) - > so > > > there is > > > >> the ability for a new application to take over. > > > >> > > > >> Does that help? > > > > > > > > That worries me without more discussion about authentication. > > > > Additionally, from a troubleshooting standpoint, if I can > > assume the > > > > same identity as another client, how can I be absolutely > > sure which > > > > client does what to the agent? I feel there needs to be > more to > > > ensure > > > > accountability of what client does what, certainly from a > > security > > > > perspective, but also from a troubleshooting perspective. > > > > > > > > Joe > > > > > > > >> > > > >> Alia > > > >> > > > >> > > > >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger > > > > > > > > > >> > > >>> wrote: > > > >> > > > >> Hi Joel, > > > >> In today's session, I asked about provisions in > the > > > architecture > > > >> (document) for Client Redundancy/Fault Tolerance. I > believe > > > you stated > > > >> that "it's not needed" and that you'd elaborate on the > > list. > > > >> > > > >> I believe you also answered a latter question by > > stating that > > > clients > > > >> are free to coordinate between themselves to provide > > > redundancy. Is this > > > >> the simple answer? If not, can you elaborate? > > > >> > > > >> Thanks, > > > >> Lou > > > >> _______________________________________________ > > > >> i2rs mailing list > > > >> i2rs@ietf.org > > > > > > > >> > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> i2rs mailing list > > > >> i2rs@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/i2rs > > > >> > > > > > > > > > > > > -- > > > > Joe Marcus Clarke, CCIE #5384, | | > > > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > > > Phone: +1 (919) 392-2867 > > > > > c i s c o S y s t e m s > > > > Email: jclarke@cisco.com > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > -- > > > Joe Marcus Clarke, CCIE #5384, | | > > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > > Phone: +1 (919) 392-2867 > > c > > > i s c o S y s t e m s > > > Email: jclarke@cisco.com > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --001a11c2e0f0c20a1004e3ed54b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am pulling this into a separate thread because I think t= hat it merits some discussion.
There seems to be a strong desire for ea= sy traceability/accountability/troubleshooting that is better than just sys= log or screen-scraping - something that is vendor-agnostic.

The idea of having the I2RS Agent store all the operati= ons and attribution done is not appealing. =A0Clearly, the most recent writ= er of data will need to be stored.

Perhaps an info= -model would be useful - and then an I2RS agent could write the data to a f= ile in a structured format? =A0Perhaps there needs to be some specific inte= ractions with the files - ability to fetch, rotate, clear? =A0I'm not s= ure what's needed.

Should= this be the same info-model that describes the connections to the I2RS age= nt and relevant information and counters?=A0

Do we have anyone motivated and interested= in this particular area enough to write up a short/quick draft and drive d= iscussion?

Thanks,
Alia

On Wed, Aug 14, 2013 at 1:49 PM, Joe Marcus Clarke &l= t;jclarke@cisco.com<= /a>> wrote:
On 8/13/13 4:58 PM, Alia A= tlas wrote:
> I am going to publish an updated version of
> draft-atlas-i2rs-architecture without fully addressing this point.
>
> I did add in a new subsection (6.4.1 Client Redundancy) under 6.4
> Identity and Security Role that says:
>
> "I2RS must support client redundancy. =A0At the simplest, this ca= n be
> handled by having a primary and a backup network application that both=
> use the same client identity and can successfully authenticate as
> such. =A0Since I2RS does not require a continuous transport connection=
> and supports multiple transport sessions, this can provide some basic<= br> > redundancy. =A0However, it does not address concerns for troubleshooti= ng
> and accountability about knowing which network application is actually=
> active. =A0At a minimum, basic transport information about each
> connection and time can be logged with the identity. =A0Further
> discussion is necessary to determine whether additional client
> identification information is necessary.[[Editor's
> note: This requires more discussion in the working group.]]"

This is fine as a start. =A0I would want to strengthen the language t= o
ensure that an I2RS Agent always stores Client connection information
with a timestamp. =A0This information should be queriable via I2RS (with appropriate read scope).

Joe

>
> Alia
>
>
> On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke &l= t;jclarke@cisco.com
> <mailto:jclarke@cisco.com>> wrote:
>
> =A0 =A0 On 8/1/13 11:19 AM, Alia Atlas wrote:
> =A0 =A0 > Joe,
> =A0 =A0 >
> =A0 =A0 > Ok - so what I hear from you is needed is the
> =A0 =A0 > =A0 =A0client role
> =A0 =A0 > =A0 =A0client identity
> =A0 =A0 > =A0 =A0sub-client identity?
> =A0 =A0 >
> =A0 =A0 > Where the permissions and ownership of state is tied to t= he client
> =A0 =A0 role?
> =A0 =A0 > =A0Does that match to what you are saying? =A0I believe w= e're assuming
> =A0 =A0 that
> =A0 =A0 > the ownership of state is tied to the client identity - a= nd you are
> =A0 =A0 > suggesting that if so, we need a client sub-identity or s= uch?
>
> =A0 =A0 Yes, I think that is in line with what I'm suggesting. =A0= If we can allow
> =A0 =A0 Client A to assume the identity of Client B using the same cre= dentials,
> =A0 =A0 I would want some way to know that this is indeed Client B now= acting on
> =A0 =A0 behalf of either itself or some northbound controller.
>
> =A0 =A0 Joe
>
> =A0 =A0 >
> =A0 =A0 > Alia
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke
> =A0 =A0 <jclarke@cisco.com= <mailto:jclarke@cisco.com><= br>
> =A0 =A0 > <mailto:jclarke@cisco.com <mailto:jclarke@cisco.com>>> wrote:
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 On 8/1/13 11:11 AM, Joel Halpern wrote:
> =A0 =A0 > =A0 =A0 > The client is the entity that is authenticat= ed and
> =A0 =A0 authorized. If the
> =A0 =A0 > =A0 =A0 > client is acting on behalf of someone else, = we assume that the
> =A0 =A0 > =A0 =A0 > authentication and authorization of that par= ty is the task
> =A0 =A0 of the
> =A0 =A0 > =A0 =A0 client
> =A0 =A0 > =A0 =A0 > and outside our scope. However we include th= at identity so that
> =A0 =A0 > =A0 =A0 actions
> =A0 =A0 > =A0 =A0 > can be easily correlated with originators. > =A0 =A0 >
> =A0 =A0 > =A0 =A0 Right. =A0I get that. =A0I had thought we were ta= lking about two
> =A0 =A0 clients
> =A0 =A0 > =A0 =A0 that might be redundant to each other where Clien= t 1 dies and
> =A0 =A0 Client 2
> =A0 =A0 > =A0 =A0 assumes its identity to make changes possibly dri= ven by northbound
> =A0 =A0 > =A0 =A0 actors. =A0Even in this case, I feel Client 2 sti= ll needs to
> =A0 =A0 maintain a
> =A0 =A0 > =A0 =A0 unique identification to the I2RS agent so that o= ne can trace the
> =A0 =A0 > =A0 =A0 operation back to the specific I2RS client (in ad= dition to the
> =A0 =A0 > =A0 =A0 northbound actor).
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Joe
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Yours,
> =A0 =A0 > =A0 =A0 > Joel
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Sent from my Android phone using TouchDown > =A0 =A0 (www.ni= trodesk.com <= http://www.nitrodesk.com>
> =A0 =A0 > =A0 =A0 <http://www.nitrodesk.com>)
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > -----Original Message-----
> =A0 =A0 > =A0 =A0 > *From:* Joe Marcus Clarke [jclarke@cisco.com
> =A0 =A0 <mailto:jclarke@cisco.= com>
> =A0 =A0 > =A0 =A0 <mailto:jclarke@cisco.com <mailto:jclarke@cisco.com>>]
> =A0 =A0 > =A0 =A0 > *Received:* Thursday, 01 A= ug 2013, 17:07
> =A0 =A0 > =A0 =A0 > *To:* Alia Atlas [akatlas@gmail.com
> =A0 =A0 <mailto:akatlas@= gmail.com> <mailto:akatlas@g= mail.com
> =A0 =A0 <mailto:akatlas@gmail.com>>]
> =A0 =A0 > =A0 =A0 > *CC:* Lou Berger [lberger@labn.net <mailto:lberger@labn.net>
> =A0 =A0 <mailto:lberger@l= abn.net <mailto:lberger@labn.net= >>];
> =A0 =A0 > =A0 =A0 i2rs@ietf.org <mailto:i2rs@ietf.org> <mai= lto:i2rs@ietf.org
> =A0 =A0 <mailto:= i2rs@ietf.org>> [i2rs@ietf.org <mailto:i2rs@ietf.org>
> =A0 =A0 > =A0 =A0 <mailto:i2rs@ietf.org <mailto:i2rs@ietf.or= g>>]; Joel
> =A0 =A0 > =A0 =A0 > Halpern [joel.halpern@ericsson.com
> =A0 =A0 <mailto:joel.h= alpern@ericsson.com> <mailto:joel.halpern@ericsson.com
> =A0 =A0 <mailto:joel.halpern@ericsson.com>>]
> =A0 =A0 > =A0 =A0 > *Subject:* Re: [i2rs] Provisions for Client = Redundancy/Fault
> =A0 =A0 Tolerance
> =A0 =A0 > =A0 =A0 > in draft-atlas-i2rs-architecture-01
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > On 8/1/13 7:51 AM, Alia Atlas wrote:
> =A0 =A0 > =A0 =A0 >> Not to answer for Joel, but my view is t= hat a client is
> =A0 =A0 identified by
> =A0 =A0 > =A0 =A0 >> its identity. =A0A different application= can take over from the
> =A0 =A0 > =A0 =A0 first by
> =A0 =A0 > =A0 =A0 >> using the same identity. =A0Loss of a tr= ansport session does
> =A0 =A0 not cause
> =A0 =A0 > =A0 =A0 >> existing client state to be removed (in = the architecture) - so
> =A0 =A0 > =A0 =A0 there is
> =A0 =A0 > =A0 =A0 >> the ability for a new application to tak= e over.
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> Does that help?
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > That worries me without more discussion abou= t authentication.
> =A0 =A0 > =A0 =A0 > Additionally, from a troubleshooting standpo= int, if I can
> =A0 =A0 assume the
> =A0 =A0 > =A0 =A0 > same identity as another client, how can I b= e absolutely
> =A0 =A0 sure which
> =A0 =A0 > =A0 =A0 > client does what to the agent? =A0I feel the= re needs to be more to
> =A0 =A0 > =A0 =A0 ensure
> =A0 =A0 > =A0 =A0 > accountability of what client does what, cer= tainly from a
> =A0 =A0 security
> =A0 =A0 > =A0 =A0 > perspective, but also from a troubleshooting= perspective.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Joe
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> Alia
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berg= er
> =A0 =A0 <lberger@labn.net &= lt;mailto:lberger@labn.net>
> =A0 =A0 > =A0 =A0 <mailto:lb= erger@labn.net <mailto:lberger@l= abn.net>>
> =A0 =A0 > =A0 =A0 >> <mailto:lberger@labn.net <mailto:= lberger@labn.net>
> =A0 =A0 <mailto:lberger@labn.ne= t <mailto:lberger@labn.net&g= t;>>> wrote:
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> =A0 =A0 Hi Joel,
> =A0 =A0 > =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 In today's s= ession, I asked about provisions in the
> =A0 =A0 > =A0 =A0 architecture
> =A0 =A0 > =A0 =A0 >> =A0 =A0 (document) for Client Redundancy= /Fault Tolerance. I believe
> =A0 =A0 > =A0 =A0 you stated
> =A0 =A0 > =A0 =A0 >> =A0 =A0 that "it's not needed&q= uot; and that you'd elaborate on the
> =A0 =A0 list.
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> =A0 =A0 I believe you also answered a la= tter question by
> =A0 =A0 stating that
> =A0 =A0 > =A0 =A0 clients
> =A0 =A0 > =A0 =A0 >> =A0 =A0 are free to coordinate between t= hemselves to provide
> =A0 =A0 > =A0 =A0 redundancy. Is this
> =A0 =A0 > =A0 =A0 >> =A0 =A0 the simple answer? =A0If not, ca= n you elaborate?
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> =A0 =A0 Thanks,
> =A0 =A0 > =A0 =A0 >> =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 >> =A0 =A0 ________________________________= _______________
> =A0 =A0 > =A0 =A0 >> =A0 =A0 i2rs mailing list
> =A0 =A0 > =A0 =A0 >> =A0 =A0 i2rs@ietf.org <mailto:i2rs@ietf.or= g>
> =A0 =A0 <mailto:i2rs@i= etf.org <mailto:i2rs@ietf.org&g= t;> <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;
> =A0 =A0 > =A0 =A0 <mailto:i2rs@= ietf.org <mailto:i2rs@ietf.org&= gt;>>
> =A0 =A0 > =A0 =A0 >> =A0 =A0 https://www.ietf= .org/mailman/listinfo/i2rs
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> ________________________________________= _______
> =A0 =A0 > =A0 =A0 >> i2rs mailing list
> =A0 =A0 > =A0 =A0 >> i2rs@ie= tf.org <mailto:i2rs@ietf.org>= ; <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;>
> =A0 =A0 > =A0 =A0 >> https://www.ietf.org/mailman/listinfo/i2rs=
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > --
> =A0 =A0 > =A0 =A0 > Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 = =A0 | =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 > =A0 =A0 > SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 = =A0||||| =A0 =A0 =A0|||||
> =A0 =A0 > =A0 =A0 > Distinguished Services Engineer ..:|||||||||= ::|||||||||:..
> =A0 =A0 > =A0 =A0 > Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%2= 9%20392-2867>
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867>
> =A0 =A0 > =A0 =A0 c i s c o =A0S y s t e m s
> =A0 =A0 > =A0 =A0 > Email: = jclarke@cisco.com <mailto:jclar= ke@cisco.com>
> =A0 =A0 <mailto:jclarke@= cisco.com <mailto:jclarke@cisco= .com>>
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 --------------------------------------------------------------= --------------
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 --
> =A0 =A0 > =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | = =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 > =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||= | =A0 =A0 =A0|||||
> =A0 =A0 > =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||= ||||||:..
> =A0 =A0 > =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%203= 92-2867>
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867> =A0 =A0 =A0 =A0 c
> =A0 =A0 > =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 > =A0 =A0 Email: jclar= ke@cisco.com <mailto:jclarke@ci= sco.com>
> =A0 =A0 <mailto:jclarke@= cisco.com <mailto:jclarke@cisco= .com>>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 --------------------------------------------------------------= --------------
> =A0 =A0 >
> =A0 =A0 >
>
>
> =A0 =A0 --
> =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0|
> =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0= |||||
> =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
> =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867> = =A0 =A0 =A0 =A0 c
> =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 Email: jclarke@cisco.com<= /a> <mailto:jclarke@cisco.com&g= t;
>
> =A0 =A0 --------------------------------------------------------------= --------------
>
>
>
>
> _______________________________________= ________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2r= s
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 = =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--001a11c2e0f0c20a1004e3ed54b7-- From jclarke@cisco.com Wed Aug 14 13:18:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D7121E80DF for ; Wed, 14 Aug 2013 13:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+PiQIkWuhq3 for ; Wed, 14 Aug 2013 13:18:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6706721E80D6 for ; Wed, 14 Aug 2013 13:18:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EKIfLU003284; Wed, 14 Aug 2013 22:18:42 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EKIfk6007502; Wed, 14 Aug 2013 16:18:41 -0400 (EDT) Message-ID: <520BE621.2090608@cisco.com> Date: Wed, 14 Aug 2013 16:18:41 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Joel M. Halpern" References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> In-Reply-To: <520BC349.5070206@joelhalpern.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, Carlos Pignataro , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:18:49 -0000 On 8/14/13 1:50 PM, Joel M. Halpern wrote: > Are you asking that the history data itself be readable with I2RS? I > really would not want to go there. Asking "who created the current > state, CLI or specific named I2RS client, might be reasonable. I am suggesting the history (as well as current state) be readable via I2RS itself. In that manner it could be vendor-agnostic by which traceability can be done. Current state could be understand who installed a route and when (Client identifier and timestamp). But there could be conditions where a Client had a route installed then removed it. If you wanted to correlate a period of bad performance, you would like to be able to query I2RS to see what changed in a particular time frame. Joe > > Yours, > Joel > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: >> On 8/14/13 1:35 PM, Alia Atlas wrote: >>> Yes, I agree that requiring someyhing like transport mirroring would be >>> unfortunate. >>> >>> I also don't think that we should be defining required syslog messages. >>> >>> But the interesting question is whether something reasonable could be >>> done for vendor-agnostic traceability... >> >> Yes, that was my point. This would be data that, in my mind, could be >> queriable via I2RS. >> >> Joe >> >>> >>> Alia >>> >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" >> > wrote: >>> >>> These look like things outside of the scope of I2RS> I would not >>> want to define message mirroring as part of the transport protocol >>> requirements, for example. >>> >>> yours, >>> Joel >>> >>> On 8/14/13 12:39 PM, Alia Atlas wrote: >>> >>> Hi Joe, >>> >>> I certainly agree that keeping logs of the APIs done and their >>> results >>> or, perhaps, having the ability to mirror the requests and >>> responses to >>> a collector would be useful. >>> >>> With CLI, I agree that this is frequently done with syslog >>> today >>> - which >>> then necessitates vendor-specific code to scrape through. >>> >>> What would be a meaningful accountability framework that >>> would be >>> appropriate and, hopefully, not require vendor-specific >>> screen-scraping? >>> >>> Completely off the top of my head, I can see the following >>> ideas: >>> (a) mirror all (or a meaningful subset) messages in/out >>> to a >>> collector that then stores/sorts/logs the information >>> (b) Define an accountability information model that >>> defines what >>> should be stored and have it stored in the canonical form >>> required by >>> the selected data-model. Perhaps mandate it be stored in a >>> file for >>> acquisition? Have the ability to read it? >>> >>> and I'm sure that there are many others... >>> >>> I do think this is an important area and it could use some good >>> discussion (and even a draft or a section to go into the >>> architecture). >>> >>> Alia >>> >>> >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke >>> >>> >> wrote: >>> >>> On 8/14/13 12:11 PM, Alia Atlas wrote: >>> > [Alia] I think that (1) belongs in the architecture. >>> I agree >>> that it is >>> > important - but I feel that the problem-statement >>> part is >>> covered >>> in the >>> > Multi-Headed Control. >>> > (2) is mostly covered in "Secure Control". I did add >>> "Such >>> > communications must also have its integrity protected." >>> since we >>> hadn't >>> > mentioned integrity but just authentication and >>> authorization. >>> > For (3), I'm not sure what aspects specifically apply to >>> I2RS... We >>> > have authentication and authorization and, in the >>> architecture, >>> tracking >>> > of state written. What knobs or functionality are you >>> looking for in >>> > accounting? >>> >>> I'll comment here, and I'm sure Carlos will chime in with >>> anything I >>> miss or if he sees things differently. >>> >>> Coming from a services/support mindset, accountability from >>> a tracing >>> point of view is important. I would like to see a history >>> of actions >>> performed, the client that performed them, when the >>> actions were >>> performed (with very granular timestamps), and the >>> result code. >>> >>> Forgive me for using a vendor reference here (as an >>> example), but in >>> Cisco IOS we have the buffer of CLI commands executed >>> and syslog >>> messages generated. This buffer is very useful when it >>> comes to tracing >>> a crash back to potential triggers. As we look to >>> incorporate our own >>> APIs, we want to provide the same kind of history log to >>> try >>> and tie API >>> calls back to potential problems on the device. >>> >>> With I2RS in particular, while crashes are certainly >>> possible, being >>> able to look back at operations and correlate problems like >>> packet loss, >>> service interruption, performance deviations, etc. will be >>> vital from a >>> troubleshooting standpoint. >>> >>> Joe >>> >>> -- >>> Joe Marcus Clarke, CCIE #5384, | | >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| >>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. >>> Phone: +1 (919) 392-2867 >>> c >>> i s c o S y s t e m s >>> Email: jclarke@cisco.com >>> > >>> >>> >>> >>> ------------------------------__------------------------------__---------------- >>> >>> >>> >>> >>> >>> _________________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/__listinfo/i2rs >>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From akatlas@gmail.com Wed Aug 14 14:36:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7321921F962D for ; Wed, 14 Aug 2013 14:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp1+wB+7+N8w for ; Wed, 14 Aug 2013 14:36:01 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5721F8FCE for ; Wed, 14 Aug 2013 14:36:00 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so12735855obc.34 for ; Wed, 14 Aug 2013 14:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FIjEH3vA+uhtgk0BHYOVsKlHPemzI5WJ4JznHp34W+s=; b=bXYu7kDznLIKXxfvHxPeBFo6SHdJCBgjSpYXGud61z22qlrVsvMvmGRBg/gnQdnW9b RbyrpKFp8gfoV9pPhv4eO71hzUQa3W7Fu7HmirwO4QS+w/i4Wyj/If6BsAYcgcUTV76V EVAOMLBZ6rA9LrT+GQwI7+mv5nJhy/VsWfFbX/cSs+qzWxqN83M3qEemtsIqACpMmO1k /NPkKoCBnoHu8Y8IlU4Yz2hFQ0HtWR7XJCUZiKWpsqEM4MSQqIUO2ZFMR6C8DxdMeZTb q0tqi4c5fTJ9Q1dY//As9LLQIZ3Zz63Qd76pmT7uBayrfO+uS+nWpBdr621gfEMrAmh5 fvyw== MIME-Version: 1.0 X-Received: by 10.60.47.230 with SMTP id g6mr7671238oen.62.1376516158368; Wed, 14 Aug 2013 14:35:58 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 14:35:58 -0700 (PDT) In-Reply-To: <520BE621.2090608@cisco.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> Date: Wed, 14 Aug 2013 17:35:58 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a11c2db58a5b63304e3ef249b Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:36:02 -0000 --001a11c2db58a5b63304e3ef249b Content-Type: text/plain; charset=ISO-8859-1 I can see having it in a file for displaying or sending - but actually having the I2RS agent crawl through it to report the data back??? Alia On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke wrote: > On 8/14/13 1:50 PM, Joel M. Halpern wrote: > > Are you asking that the history data itself be readable with I2RS? I > > really would not want to go there. Asking "who created the current > > state, CLI or specific named I2RS client, might be reasonable. > > I am suggesting the history (as well as current state) be readable via > I2RS itself. In that manner it could be vendor-agnostic by which > traceability can be done. Current state could be understand who > installed a route and when (Client identifier and timestamp). But there > could be conditions where a Client had a route installed then removed > it. If you wanted to correlate a period of bad performance, you would > like to be able to query I2RS to see what changed in a particular time > frame. > > Joe > > > > > Yours, > > Joel > > > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > >> On 8/14/13 1:35 PM, Alia Atlas wrote: > >>> Yes, I agree that requiring someyhing like transport mirroring would be > >>> unfortunate. > >>> > >>> I also don't think that we should be defining required syslog messages. > >>> > >>> But the interesting question is whether something reasonable could be > >>> done for vendor-agnostic traceability... > >> > >> Yes, that was my point. This would be data that, in my mind, could be > >> queriable via I2RS. > >> > >> Joe > >> > >>> > >>> Alia > >>> > >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" >>> > wrote: > >>> > >>> These look like things outside of the scope of I2RS> I would not > >>> want to define message mirroring as part of the transport protocol > >>> requirements, for example. > >>> > >>> yours, > >>> Joel > >>> > >>> On 8/14/13 12:39 PM, Alia Atlas wrote: > >>> > >>> Hi Joe, > >>> > >>> I certainly agree that keeping logs of the APIs done and their > >>> results > >>> or, perhaps, having the ability to mirror the requests and > >>> responses to > >>> a collector would be useful. > >>> > >>> With CLI, I agree that this is frequently done with syslog > >>> today > >>> - which > >>> then necessitates vendor-specific code to scrape through. > >>> > >>> What would be a meaningful accountability framework that > >>> would be > >>> appropriate and, hopefully, not require vendor-specific > >>> screen-scraping? > >>> > >>> Completely off the top of my head, I can see the following > >>> ideas: > >>> (a) mirror all (or a meaningful subset) messages in/out > >>> to a > >>> collector that then stores/sorts/logs the information > >>> (b) Define an accountability information model that > >>> defines what > >>> should be stored and have it stored in the canonical form > >>> required by > >>> the selected data-model. Perhaps mandate it be stored in a > >>> file for > >>> acquisition? Have the ability to read it? > >>> > >>> and I'm sure that there are many others... > >>> > >>> I do think this is an important area and it could use some > good > >>> discussion (and even a draft or a section to go into the > >>> architecture). > >>> > >>> Alia > >>> > >>> > >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > >>> > >>> >> wrote: > >>> > >>> On 8/14/13 12:11 PM, Alia Atlas wrote: > >>> > [Alia] I think that (1) belongs in the architecture. > >>> I agree > >>> that it is > >>> > important - but I feel that the problem-statement > >>> part is > >>> covered > >>> in the > >>> > Multi-Headed Control. > >>> > (2) is mostly covered in "Secure Control". I did add > >>> "Such > >>> > communications must also have its integrity protected." > >>> since we > >>> hadn't > >>> > mentioned integrity but just authentication and > >>> authorization. > >>> > For (3), I'm not sure what aspects specifically apply > to > >>> I2RS... We > >>> > have authentication and authorization and, in the > >>> architecture, > >>> tracking > >>> > of state written. What knobs or functionality are you > >>> looking for in > >>> > accounting? > >>> > >>> I'll comment here, and I'm sure Carlos will chime in with > >>> anything I > >>> miss or if he sees things differently. > >>> > >>> Coming from a services/support mindset, accountability > from > >>> a tracing > >>> point of view is important. I would like to see a history > >>> of actions > >>> performed, the client that performed them, when the > >>> actions were > >>> performed (with very granular timestamps), and the > >>> result code. > >>> > >>> Forgive me for using a vendor reference here (as an > >>> example), but in > >>> Cisco IOS we have the buffer of CLI commands executed > >>> and syslog > >>> messages generated. This buffer is very useful when it > >>> comes to tracing > >>> a crash back to potential triggers. As we look to > >>> incorporate our own > >>> APIs, we want to provide the same kind of history log to > >>> try > >>> and tie API > >>> calls back to potential problems on the device. > >>> > >>> With I2RS in particular, while crashes are certainly > >>> possible, being > >>> able to look back at operations and correlate problems > like > >>> packet loss, > >>> service interruption, performance deviations, etc. will be > >>> vital from a > >>> troubleshooting standpoint. > >>> > >>> Joe > >>> > >>> -- > >>> Joe Marcus Clarke, CCIE #5384, | | > >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > >>> Distinguished Services Engineer ..:|||||||||::|||||||||:.. > >>> Phone: +1 (919) 392-2867 > >>> c > >>> i s c o S y s t e m s > >>> Email: jclarke@cisco.com > >>> > > >>> > >>> > >>> > >>> > ------------------------------__------------------------------__---------------- > >>> > >>> > >>> > >>> > >>> > >>> _________________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/__listinfo/i2rs > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>> > >> > >> > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --001a11c2db58a5b63304e3ef249b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can see having it in a file for displaying or sending - = but actually having the I2RS agent crawl through it to report the data back= ???

Alia


<= div class=3D"gmail_quote"> On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke <jclarke@cisco.com&= gt; wrote:
On 8/14/13 1:50 PM, Joel M. Halpern wrote:
> Are you asking that the history data itself be readable with I2RS? =A0= I
> really would not want to go there. =A0Asking "who created the cur= rent
> state, CLI or specific named I2RS client, might be reasonable.

I am suggesting the history (as well as current state) be readable vi= a
I2RS itself. =A0In that manner it could be vendor-agnostic by which
traceability can be done. =A0 Current state could be understand who
installed a route and when (Client identifier and timestamp). =A0But there<= br> could be conditions where a Client had a route installed then removed
it. =A0If you wanted to correlate a period of bad performance, you would like to be able to query I2RS to see what changed in a particular time
frame.

Joe

>
> Yours,
> Joel
>
> On 8/14/13 1:44 PM, Joe Marcus Clarke wrote:
>> On 8/14/13 1:35 PM, Alia Atlas wrote:
>>> Yes, I agree that requiring someyhing like transport mirroring= would be
>>> unfortunate.
>>>
>>> I also don't think that we should be defining required sys= log messages.
>>>
>>> But the interesting question is whether something reasonable c= ould be
>>> done for vendor-agnostic traceability...
>>
>> Yes, that was my point. =A0This would be data that, in my mind, co= uld be
>> queriable via I2RS.
>>
>> Joe
>>
>>>
>>> Alia
>>>
>>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <jmh@joelhalpern.com
>>> <mailto:jmh@joelhalp= ern.com>> wrote:
>>>
>>> =A0 =A0 =A0These look like things outside of the scope of I2RS= > =A0I would not
>>> =A0 =A0 =A0want to define message mirroring as part of the tra= nsport protocol
>>> =A0 =A0 =A0requirements, for example.
>>>
>>> =A0 =A0 =A0yours,
>>> =A0 =A0 =A0Joel
>>>
>>> =A0 =A0 =A0On 8/14/13 12:39 PM, Alia Atlas wrote:
>>>
>>> =A0 =A0 =A0 =A0 =A0Hi Joe,
>>>
>>> =A0 =A0 =A0 =A0 =A0I certainly agree that keeping logs of the = APIs done and their
>>> =A0 =A0 =A0 =A0 =A0results
>>> =A0 =A0 =A0 =A0 =A0or, perhaps, having the ability to mirror t= he requests and
>>> =A0 =A0 =A0 =A0 =A0responses to
>>> =A0 =A0 =A0 =A0 =A0a collector would be useful.
>>>
>>> =A0 =A0 =A0 =A0 =A0With CLI, I agree that this is frequently d= one with syslog
>>> today
>>> =A0 =A0 =A0 =A0 =A0- which
>>> =A0 =A0 =A0 =A0 =A0then necessitates vendor-specific code to s= crape through.
>>>
>>> =A0 =A0 =A0 =A0 =A0What would be a meaningful accountability f= ramework that
>>> would be
>>> =A0 =A0 =A0 =A0 =A0appropriate and, hopefully, not require ven= dor-specific
>>> =A0 =A0 =A0 =A0 =A0screen-scraping?
>>>
>>> =A0 =A0 =A0 =A0 =A0Completely off the top of my head, I can se= e the following
>>> ideas:
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(a) mirror all (or a meaningful sub= set) messages in/out
>>> to a
>>> =A0 =A0 =A0 =A0 =A0collector that then stores/sorts/logs the i= nformation
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(b) Define an accountability inform= ation model that
>>> defines what
>>> =A0 =A0 =A0 =A0 =A0should be stored and have it stored in the = canonical form
>>> =A0 =A0 =A0 =A0 =A0required by
>>> =A0 =A0 =A0 =A0 =A0the selected data-model. =A0Perhaps mandate= it be stored in a
>>> file for
>>> =A0 =A0 =A0 =A0 =A0acquisition? =A0Have the ability to read it= ?
>>>
>>> =A0 =A0 =A0 =A0 =A0and I'm sure that there are many others= ...
>>>
>>> =A0 =A0 =A0 =A0 =A0I do think this is an important area and it= could use some good
>>> =A0 =A0 =A0 =A0 =A0discussion (and even a draft or a section t= o go into the
>>> =A0 =A0 =A0 =A0 =A0architecture).
>>>
>>> =A0 =A0 =A0 =A0 =A0Alia
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcu= s Clarke
>>> =A0 =A0 =A0 =A0 =A0<jc= larke@cisco.com <mailto:jclarke= @cisco.com>
>>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com <mailto:= jclarke@cisco.com>>> wrote:
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0On 8/14/13 12:11 PM, Alia Atlas wro= te:
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > [Alia] I think that (1) belon= gs in the architecture.
>>> I agree
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0that it is
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > important - but I feel that t= he problem-statement
>>> part is
>>> =A0 =A0 =A0 =A0 =A0covered
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0in the
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Multi-Headed Control.
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > (2) is mostly covered in &quo= t;Secure Control". =A0I did add
>>> "Such
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > communications must also have= its integrity protected."
>>> =A0 =A0 =A0 =A0 =A0since we
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0hadn't
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > mentioned integrity but just = authentication and
>>> =A0 =A0 =A0 =A0 =A0authorization.
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > For (3), I'm not sure wha= t aspects specifically apply to
>>> =A0 =A0 =A0 =A0 =A0I2RS... =A0We
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > have authentication and autho= rization and, in the
>>> =A0 =A0 =A0 =A0 =A0architecture,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0tracking
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > of state written. =A0What kno= bs or functionality are you
>>> =A0 =A0 =A0 =A0 =A0looking for in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > accounting?
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0I'll comment here, and I'm = sure Carlos will chime in with
>>> =A0 =A0 =A0 =A0 =A0anything I
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0miss or if he sees things different= ly.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Coming from a services/support mind= set, accountability from
>>> =A0 =A0 =A0 =A0 =A0a tracing
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0point of view is important. =A0I wo= uld like to see a history
>>> =A0 =A0 =A0 =A0 =A0of actions
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed, the client that performe= d them, when the
>>> actions were
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed (with very granular times= tamps), and the
>>> result code.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Forgive me for using a vendor refer= ence here (as an
>>> =A0 =A0 =A0 =A0 =A0example), but in
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cisco IOS we have the buffer of CLI= commands executed
>>> and syslog
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0messages generated. =A0This buffer = is very useful when it
>>> =A0 =A0 =A0 =A0 =A0comes to tracing
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0a crash back to potential triggers.= =A0As we look to
>>> =A0 =A0 =A0 =A0 =A0incorporate our own
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0APIs, we want to provide the same k= ind of history log to
>>> try
>>> =A0 =A0 =A0 =A0 =A0and tie API
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0calls back to potential problems on= the device.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0With I2RS in particular, while cras= hes are certainly
>>> =A0 =A0 =A0 =A0 =A0possible, being
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0able to look back at operations and= correlate problems like
>>> =A0 =A0 =A0 =A0 =A0packet loss,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0service interruption, performance d= eviations, etc. will be
>>> =A0 =A0 =A0 =A0 =A0vital from a
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0troubleshooting standpoint.
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe Marcus Clarke, CCIE #5384, =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0SCJP, SCSA, SCNA, SCSECA, VCP =A0 = =A0 =A0 =A0||||| =A0 =A0 =A0|||||
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Distinguished Services Engineer ..:= |||||||||::|||||||||:..
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Phone: +1 (919) 392-2867 <tel:%2B1%2= 0%28919%29%20392-2867>
>>> =A0 =A0 =A0 =A0 =A0<tel:%2B1%20%28919%29%20392-__2867> = =A0 =A0 =A0 =A0 c
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0i s c o =A0S y s t e m s
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Email: jclarke@cisco.com <mailto:jclarke@cisco.com>
>>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com <mailto:= jclarke@cisco.com>>
>>>
>>>
>>>
>>> ------------------------------__------------------------------= __----------------
>>>
>>>
>>>
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0___________________________________________= ______
>>> =A0 =A0 =A0 =A0 =A0i2rs mailing list
>>> =A0 =A0 =A0 =A0 =A0i2rs@ietf.= org <mailto:i2rs@ietf.org> >>> =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/__listinfo/i2r= s
>>> =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/i2r= s>
>>>
>>>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>
>>
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s=
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--001a11c2db58a5b63304e3ef249b-- From jclarke@cisco.com Wed Aug 14 14:46:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1211E8189 for ; Wed, 14 Aug 2013 14:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unuPmI-P5W04 for ; Wed, 14 Aug 2013 14:46:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37B11E818D for ; Wed, 14 Aug 2013 14:46:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7ELkU14015911; Wed, 14 Aug 2013 23:46:31 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7ELkURq000881; Wed, 14 Aug 2013 17:46:30 -0400 (EDT) Message-ID: <520BFAB6.3040406@cisco.com> Date: Wed, 14 Aug 2013 17:46:30 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:46:39 -0000 On 8/14/13 5:35 PM, Alia Atlas wrote: > I can see having it in a file for displaying or sending - but actually > having the I2RS agent crawl through it to report the data back??? A file/buffer is fine, but will lead to vendor-specific ways of getting at the data. As I read the architecture concerning information collection, I thought this might be very useful information for a Client to collect from the Agent. I know Joel disagrees in favor of syslog. I think syslog is okay, but only if you're receiving messages since the beginning of time (i.e., before a problem is identified). While I very well may be off base here, having the a record of what Clients did what on a particular Agent in a vendor-agnostic way as information to be collected via I2RS seemed reasonable. Joe > > Alia > > > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke > wrote: > > On 8/14/13 1:50 PM, Joel M. Halpern wrote: > > Are you asking that the history data itself be readable with I2RS? I > > really would not want to go there. Asking "who created the current > > state, CLI or specific named I2RS client, might be reasonable. > > I am suggesting the history (as well as current state) be readable via > I2RS itself. In that manner it could be vendor-agnostic by which > traceability can be done. Current state could be understand who > installed a route and when (Client identifier and timestamp). But there > could be conditions where a Client had a route installed then removed > it. If you wanted to correlate a period of bad performance, you would > like to be able to query I2RS to see what changed in a particular time > frame. > > Joe > > > > > Yours, > > Joel > > > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > >> On 8/14/13 1:35 PM, Alia Atlas wrote: > >>> Yes, I agree that requiring someyhing like transport mirroring > would be > >>> unfortunate. > >>> > >>> I also don't think that we should be defining required syslog > messages. > >>> > >>> But the interesting question is whether something reasonable > could be > >>> done for vendor-agnostic traceability... > >> > >> Yes, that was my point. This would be data that, in my mind, > could be > >> queriable via I2RS. > >> > >> Joe > >> > >>> > >>> Alia > >>> > >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > >>> >> wrote: > >>> > >>> These look like things outside of the scope of I2RS> I > would not > >>> want to define message mirroring as part of the transport > protocol > >>> requirements, for example. > >>> > >>> yours, > >>> Joel > >>> > >>> On 8/14/13 12:39 PM, Alia Atlas wrote: > >>> > >>> Hi Joe, > >>> > >>> I certainly agree that keeping logs of the APIs done > and their > >>> results > >>> or, perhaps, having the ability to mirror the requests and > >>> responses to > >>> a collector would be useful. > >>> > >>> With CLI, I agree that this is frequently done with syslog > >>> today > >>> - which > >>> then necessitates vendor-specific code to scrape through. > >>> > >>> What would be a meaningful accountability framework that > >>> would be > >>> appropriate and, hopefully, not require vendor-specific > >>> screen-scraping? > >>> > >>> Completely off the top of my head, I can see the following > >>> ideas: > >>> (a) mirror all (or a meaningful subset) messages in/out > >>> to a > >>> collector that then stores/sorts/logs the information > >>> (b) Define an accountability information model that > >>> defines what > >>> should be stored and have it stored in the canonical form > >>> required by > >>> the selected data-model. Perhaps mandate it be stored in a > >>> file for > >>> acquisition? Have the ability to read it? > >>> > >>> and I'm sure that there are many others... > >>> > >>> I do think this is an important area and it could use > some good > >>> discussion (and even a draft or a section to go into the > >>> architecture). > >>> > >>> Alia > >>> > >>> > >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > >>> > > > >>> > >>> wrote: > >>> > >>> On 8/14/13 12:11 PM, Alia Atlas wrote: > >>> > [Alia] I think that (1) belongs in the architecture. > >>> I agree > >>> that it is > >>> > important - but I feel that the problem-statement > >>> part is > >>> covered > >>> in the > >>> > Multi-Headed Control. > >>> > (2) is mostly covered in "Secure Control". I > did add > >>> "Such > >>> > communications must also have its integrity > protected." > >>> since we > >>> hadn't > >>> > mentioned integrity but just authentication and > >>> authorization. > >>> > For (3), I'm not sure what aspects specifically > apply to > >>> I2RS... We > >>> > have authentication and authorization and, in the > >>> architecture, > >>> tracking > >>> > of state written. What knobs or functionality > are you > >>> looking for in > >>> > accounting? > >>> > >>> I'll comment here, and I'm sure Carlos will chime > in with > >>> anything I > >>> miss or if he sees things differently. > >>> > >>> Coming from a services/support mindset, > accountability from > >>> a tracing > >>> point of view is important. I would like to see a > history > >>> of actions > >>> performed, the client that performed them, when the > >>> actions were > >>> performed (with very granular timestamps), and the > >>> result code. > >>> > >>> Forgive me for using a vendor reference here (as an > >>> example), but in > >>> Cisco IOS we have the buffer of CLI commands executed > >>> and syslog > >>> messages generated. This buffer is very useful when it > >>> comes to tracing > >>> a crash back to potential triggers. As we look to > >>> incorporate our own > >>> APIs, we want to provide the same kind of history > log to > >>> try > >>> and tie API > >>> calls back to potential problems on the device. > >>> > >>> With I2RS in particular, while crashes are certainly > >>> possible, being > >>> able to look back at operations and correlate > problems like > >>> packet loss, > >>> service interruption, performance deviations, etc. > will be > >>> vital from a > >>> troubleshooting standpoint. > >>> > >>> Joe > >>> > >>> -- > >>> Joe Marcus Clarke, CCIE #5384, | | > >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > >>> Distinguished Services Engineer > ..:|||||||||::|||||||||:.. > >>> Phone: +1 (919) 392-2867 > > >>> c > >>> i s c o S y s t e m s > >>> Email: jclarke@cisco.com > > > >>> > >> > >>> > >>> > >>> > >>> > ------------------------------__------------------------------__---------------- > >>> > >>> > >>> > >>> > >>> > >>> _________________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>> > >> > >> > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From akatlas@gmail.com Wed Aug 14 15:28:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B83411E814D for ; Wed, 14 Aug 2013 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC6b-FhAT-CL for ; Wed, 14 Aug 2013 15:28:14 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C978B11E81BF for ; Wed, 14 Aug 2013 15:28:11 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so45641obb.23 for ; Wed, 14 Aug 2013 15:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sBUSh6jffBsfmg22tqYOsnxAT8rAkA68JfcwB9j/IL0=; b=r859Vt3BdD9RAqieztM9/7iyH/ef5VNmNgVOalWNdHGce+0i8uua7J7cVzWf1M5qAl /N6f7znSMS2njEvBiKlEwJ4cXRYxSJgxew/8ZmJrFiEre9wmtYE7vWjx8auVDf6UQn+5 7S3zf6eeR5k+04S5EYJ7AUIpVJJ0/OohkWmRxkViV4+vaf7+8gltt3ZGD1bPFA828Xtr Z/7SYJRB3DwAxGTr9qViu6lQguykKwad4jbAb7MKo9YIHUOchZMRY+PLy+cm4iUejf/i 6+hGc9IFyX9gJZN7LRleP7otJsPe5aAYqwABednZgAb6mT781djSk9nwcUG6TfT/XM0B 0bYA== MIME-Version: 1.0 X-Received: by 10.182.199.74 with SMTP id ji10mr101988obc.69.1376519291311; Wed, 14 Aug 2013 15:28:11 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Wed, 14 Aug 2013 15:28:11 -0700 (PDT) In-Reply-To: <520BFAB6.3040406@cisco.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> Date: Wed, 14 Aug 2013 18:28:11 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=e89a8ff1c024629ebf04e3efdfb3 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 22:28:16 -0000 --e89a8ff1c024629ebf04e3efdfb3 Content-Type: text/plain; charset=ISO-8859-1 Ah - I meant a structured file - so the contents are the written data-model. Thus, a tool could get the file and parse through it to find what was desirable. The structured file would be described in the schema, extensible as always, to provide something better than syslog - without asking the I2RS agent to add in that file parsing and reading and such. Alia On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke wrote: > On 8/14/13 5:35 PM, Alia Atlas wrote: > > I can see having it in a file for displaying or sending - but actually > > having the I2RS agent crawl through it to report the data back??? > > A file/buffer is fine, but will lead to vendor-specific ways of getting > at the data. As I read the architecture concerning information > collection, I thought this might be very useful information for a Client > to collect from the Agent. > > I know Joel disagrees in favor of syslog. I think syslog is okay, but > only if you're receiving messages since the beginning of time (i.e., > before a problem is identified). While I very well may be off base > here, having the a record of what Clients did what on a particular Agent > in a vendor-agnostic way as information to be collected via I2RS seemed > reasonable. > > Joe > > > > > Alia > > > > > > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke > > wrote: > > > > On 8/14/13 1:50 PM, Joel M. Halpern wrote: > > > Are you asking that the history data itself be readable with I2RS? > I > > > really would not want to go there. Asking "who created the current > > > state, CLI or specific named I2RS client, might be reasonable. > > > > I am suggesting the history (as well as current state) be readable > via > > I2RS itself. In that manner it could be vendor-agnostic by which > > traceability can be done. Current state could be understand who > > installed a route and when (Client identifier and timestamp). But > there > > could be conditions where a Client had a route installed then removed > > it. If you wanted to correlate a period of bad performance, you > would > > like to be able to query I2RS to see what changed in a particular > time > > frame. > > > > Joe > > > > > > > > Yours, > > > Joel > > > > > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > > >> On 8/14/13 1:35 PM, Alia Atlas wrote: > > >>> Yes, I agree that requiring someyhing like transport mirroring > > would be > > >>> unfortunate. > > >>> > > >>> I also don't think that we should be defining required syslog > > messages. > > >>> > > >>> But the interesting question is whether something reasonable > > could be > > >>> done for vendor-agnostic traceability... > > >> > > >> Yes, that was my point. This would be data that, in my mind, > > could be > > >> queriable via I2RS. > > >> > > >> Joe > > >> > > >>> > > >>> Alia > > >>> > > >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > > > >>> >> > wrote: > > >>> > > >>> These look like things outside of the scope of I2RS> I > > would not > > >>> want to define message mirroring as part of the transport > > protocol > > >>> requirements, for example. > > >>> > > >>> yours, > > >>> Joel > > >>> > > >>> On 8/14/13 12:39 PM, Alia Atlas wrote: > > >>> > > >>> Hi Joe, > > >>> > > >>> I certainly agree that keeping logs of the APIs done > > and their > > >>> results > > >>> or, perhaps, having the ability to mirror the requests > and > > >>> responses to > > >>> a collector would be useful. > > >>> > > >>> With CLI, I agree that this is frequently done with > syslog > > >>> today > > >>> - which > > >>> then necessitates vendor-specific code to scrape > through. > > >>> > > >>> What would be a meaningful accountability framework that > > >>> would be > > >>> appropriate and, hopefully, not require vendor-specific > > >>> screen-scraping? > > >>> > > >>> Completely off the top of my head, I can see the > following > > >>> ideas: > > >>> (a) mirror all (or a meaningful subset) messages > in/out > > >>> to a > > >>> collector that then stores/sorts/logs the information > > >>> (b) Define an accountability information model that > > >>> defines what > > >>> should be stored and have it stored in the canonical > form > > >>> required by > > >>> the selected data-model. Perhaps mandate it be stored > in a > > >>> file for > > >>> acquisition? Have the ability to read it? > > >>> > > >>> and I'm sure that there are many others... > > >>> > > >>> I do think this is an important area and it could use > > some good > > >>> discussion (and even a draft or a section to go into the > > >>> architecture). > > >>> > > >>> Alia > > >>> > > >>> > > >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > > >>> > > > > > >>> > > >>> wrote: > > >>> > > >>> On 8/14/13 12:11 PM, Alia Atlas wrote: > > >>> > [Alia] I think that (1) belongs in the > architecture. > > >>> I agree > > >>> that it is > > >>> > important - but I feel that the problem-statement > > >>> part is > > >>> covered > > >>> in the > > >>> > Multi-Headed Control. > > >>> > (2) is mostly covered in "Secure Control". I > > did add > > >>> "Such > > >>> > communications must also have its integrity > > protected." > > >>> since we > > >>> hadn't > > >>> > mentioned integrity but just authentication and > > >>> authorization. > > >>> > For (3), I'm not sure what aspects specifically > > apply to > > >>> I2RS... We > > >>> > have authentication and authorization and, in the > > >>> architecture, > > >>> tracking > > >>> > of state written. What knobs or functionality > > are you > > >>> looking for in > > >>> > accounting? > > >>> > > >>> I'll comment here, and I'm sure Carlos will chime > > in with > > >>> anything I > > >>> miss or if he sees things differently. > > >>> > > >>> Coming from a services/support mindset, > > accountability from > > >>> a tracing > > >>> point of view is important. I would like to see a > > history > > >>> of actions > > >>> performed, the client that performed them, when the > > >>> actions were > > >>> performed (with very granular timestamps), and the > > >>> result code. > > >>> > > >>> Forgive me for using a vendor reference here (as an > > >>> example), but in > > >>> Cisco IOS we have the buffer of CLI commands > executed > > >>> and syslog > > >>> messages generated. This buffer is very useful > when it > > >>> comes to tracing > > >>> a crash back to potential triggers. As we look to > > >>> incorporate our own > > >>> APIs, we want to provide the same kind of history > > log to > > >>> try > > >>> and tie API > > >>> calls back to potential problems on the device. > > >>> > > >>> With I2RS in particular, while crashes are certainly > > >>> possible, being > > >>> able to look back at operations and correlate > > problems like > > >>> packet loss, > > >>> service interruption, performance deviations, etc. > > will be > > >>> vital from a > > >>> troubleshooting standpoint. > > >>> > > >>> Joe > > >>> > > >>> -- > > >>> Joe Marcus Clarke, CCIE #5384, | | > > >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| > ||||| > > >>> Distinguished Services Engineer > > ..:|||||||||::|||||||||:.. > > >>> Phone: +1 (919) 392-2867 > > > > >>> c > > >>> i s c o S y s t e m s > > >>> Email: jclarke@cisco.com > > > > > >>> > > >> > > >>> > > >>> > > >>> > > >>> > > > ------------------------------__------------------------------__---------------- > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/i2rs > > >>> > > >> > > >> > > > > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --e89a8ff1c024629ebf04e3efdfb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ah - I meant a structured file - so the contents are the w= ritten data-model. =A0Thus, a tool could get the file and parse through it = to find what was desirable. =A0The structured file would be described in th= e schema, extensible as always, to provide something better than syslog - w= ithout asking the I2RS agent to add in that file parsing and reading and su= ch.

Alia


On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke <jcla= rke@cisco.com> wrote:
On 8/14/13 5:35 PM, Alia A= tlas wrote:
> I can see having it in a file for displaying o= r sending - but actually
> having the I2RS agent crawl through it to report the data back???

A file/buffer is fine, but will lead to vendor-specific ways of getti= ng
at the data. =A0As I read the architecture concerning information
collection, I thought this might be very useful information for a Client to collect from the Agent.

I know Joel disagrees in favor of syslog. =A0I think syslog is okay, but only if you're receiving messages since the beginning of time (i.e., before a problem is identified). =A0While I very well may be off base
here, having the a record of what Clients did what on a particular Agent in a vendor-agnostic way as information to be collected via I2RS seemed
reasonable.

Joe

>
> Alia
>
>
> On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke <jclarke@cisco.com
> <mailto:jclarke@cisco.com>> wrote:
>
> =A0 =A0 On 8/14/13 1:50 PM, Joel M. Halpern wrote:
> =A0 =A0 > Are you asking that the history data itself be readable w= ith I2RS? =A0I
> =A0 =A0 > really would not want to go there. =A0Asking "who cr= eated the current
> =A0 =A0 > state, CLI or specific named I2RS client, might be reason= able.
>
> =A0 =A0 I am suggesting the history (as well as current state) be read= able via
> =A0 =A0 I2RS itself. =A0In that manner it could be vendor-agnostic by = which
> =A0 =A0 traceability can be done. =A0 Current state could be understan= d who
> =A0 =A0 installed a route and when (Client identifier and timestamp). = =A0But there
> =A0 =A0 could be conditions where a Client had a route installed then = removed
> =A0 =A0 it. =A0If you wanted to correlate a period of bad performance,= you would
> =A0 =A0 like to be able to query I2RS to see what changed in a particu= lar time
> =A0 =A0 frame.
>
> =A0 =A0 Joe
>
> =A0 =A0 >
> =A0 =A0 > Yours,
> =A0 =A0 > Joel
> =A0 =A0 >
> =A0 =A0 > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote:
> =A0 =A0 >> On 8/14/13 1:35 PM, Alia Atlas wrote:
> =A0 =A0 >>> Yes, I agree that requiring someyhing like transp= ort mirroring
> =A0 =A0 would be
> =A0 =A0 >>> unfortunate.
> =A0 =A0 >>>
> =A0 =A0 >>> I also don't think that we should be defining= required syslog
> =A0 =A0 messages.
> =A0 =A0 >>>
> =A0 =A0 >>> But the interesting question is whether something= reasonable
> =A0 =A0 could be
> =A0 =A0 >>> done for vendor-agnostic traceability...
> =A0 =A0 >>
> =A0 =A0 >> Yes, that was my point. =A0This would be data that, i= n my mind,
> =A0 =A0 could be
> =A0 =A0 >> queriable via I2RS.
> =A0 =A0 >>
> =A0 =A0 >> Joe
> =A0 =A0 >>
> =A0 =A0 >>>
> =A0 =A0 >>> Alia
> =A0 =A0 >>>
> =A0 =A0 >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern&qu= ot; <jmh@joelhalpern.com
> =A0 =A0 <mailto:jmh@joelhalp= ern.com>
> =A0 =A0 >>> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrot= e:
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0These look like things outside of the = scope of I2RS> =A0I
> =A0 =A0 would not
> =A0 =A0 >>> =A0 =A0 =A0want to define message mirroring as pa= rt of the transport
> =A0 =A0 protocol
> =A0 =A0 >>> =A0 =A0 =A0requirements, for example.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0yours,
> =A0 =A0 >>> =A0 =A0 =A0Joel
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0On 8/14/13 12:39 PM, Alia Atlas wrote:=
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Hi Joe,
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I certainly agree that keeping= logs of the APIs done
> =A0 =A0 and their
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0results
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0or, perhaps, having the abilit= y to mirror the requests and
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0responses to
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0a collector would be useful. > =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0With CLI, I agree that this is= frequently done with syslog
> =A0 =A0 >>> today
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0- which
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0then necessitates vendor-speci= fic code to scrape through.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0What would be a meaningful acc= ountability framework that
> =A0 =A0 >>> would be
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0appropriate and, hopefully, no= t require vendor-specific
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0screen-scraping?
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Completely off the top of my h= ead, I can see the following
> =A0 =A0 >>> ideas:
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(a) mirror all (or a m= eaningful subset) messages in/out
> =A0 =A0 >>> to a
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0collector that then stores/sor= ts/logs the information
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(b) Define an accounta= bility information model that
> =A0 =A0 >>> defines what
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0should be stored and have it s= tored in the canonical form
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0required by
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0the selected data-model. =A0Pe= rhaps mandate it be stored in a
> =A0 =A0 >>> file for
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0acquisition? =A0Have the abili= ty to read it?
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0and I'm sure that there ar= e many others...
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I do think this is an importan= t area and it could use
> =A0 =A0 some good
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0discussion (and even a draft o= r a section to go into the
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0architecture).
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Alia
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0On Wed, Aug 14, 2013 at 12:29 = PM, Joe Marcus Clarke
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<jclarke@cisco.com <mailto:jclarke@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com <mailto:jclarke@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>>> wrote:
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0On 8/14/13 12:11 PM, A= lia Atlas wrote:
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > [Alia] I think t= hat (1) belongs in the architecture.
> =A0 =A0 >>> I agree
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0that it is
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > important - but = I feel that the problem-statement
> =A0 =A0 >>> part is
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0covered
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0in the
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Multi-Headed Con= trol.
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > (2) is mostly co= vered in "Secure Control". =A0I
> =A0 =A0 did add
> =A0 =A0 >>> "Such
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > communications m= ust also have its integrity
> =A0 =A0 protected."
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0since we
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0hadn't
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > mentioned integr= ity but just authentication and
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0authorization.
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > For (3), I'm= not sure what aspects specifically
> =A0 =A0 apply to
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I2RS... =A0We
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > have authenticat= ion and authorization and, in the
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0architecture,
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0tracking
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > of state written= . =A0What knobs or functionality
> =A0 =A0 are you
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0looking for in
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > accounting?
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0I'll comment here,= and I'm sure Carlos will chime
> =A0 =A0 in with
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0anything I
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0miss or if he sees thi= ngs differently.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Coming from a services= /support mindset,
> =A0 =A0 accountability from
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0a tracing
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0point of view is impor= tant. =A0I would like to see a
> =A0 =A0 history
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0of actions
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed, the client = that performed them, when the
> =A0 =A0 >>> actions were
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed (with very g= ranular timestamps), and the
> =A0 =A0 >>> result code.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Forgive me for using a= vendor reference here (as an
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0example), but in
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cisco IOS we have the = buffer of CLI commands executed
> =A0 =A0 >>> and syslog
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0messages generated. = =A0This buffer is very useful when it
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0comes to tracing
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0a crash back to potent= ial triggers. =A0As we look to
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0incorporate our own
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0APIs, we want to provi= de the same kind of history
> =A0 =A0 log to
> =A0 =A0 >>> try
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0and tie API
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0calls back to potentia= l problems on the device.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0With I2RS in particula= r, while crashes are certainly
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0possible, being
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0able to look back at o= perations and correlate
> =A0 =A0 problems like
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0packet loss,
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0service interruption, = performance deviations, etc.
> =A0 =A0 will be
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0vital from a
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0troubleshooting standp= oint.
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe Marcus Clarke, CCI= E #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0SCJP, SCSA, SCNA, SCSE= CA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Distinguished Services= Engineer
> =A0 =A0 ..:|||||||||::|||||||||:..
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Phone: +1 (919) 392-2867
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867> <tel:%2= B1%20%28919%29%20392-2867>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<tel:%2B1= %20%28919%29%20392-__2867> =A0 =A0 =A0 =A0 c
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0i s c o =A0S y s t e m= s
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Email: jclarke@cisco.com <mailto:jclarke@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com <mailto:jclarke@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.com <mailto:j= clarke@cisco.com>>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 ------------------------------__------------------------------= __----------------
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0______________________________= ___________________
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0i2rs mailing list
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0i2rs@ietf.org <mailto:i2rs@ietf.= org>
> =A0 =A0 <mailto:i2rs@ietf.or= g <mailto:i2rs@ietf.org>>=
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0https://www.= ietf.org/mailman/__listinfo/i2rs
> =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman= /listinfo/i2rs>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>>
> =A0 =A0 >>> _______________________________________________ > =A0 =A0 >>> i2rs mailing list
> =A0 =A0 >>> i2rs@ietf.= org <mailto:i2rs@ietf.org>
> =A0 =A0 >>> https://www.ietf.org/mailman/list= info/i2rs
> =A0 =A0 >>>
> =A0 =A0 >>
> =A0 =A0 >>
> =A0 =A0 >
>
>
> =A0 =A0 --
> =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0|
> =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0= |||||
> =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
> =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867= > =A0 =A0 =A0 =A0 c
> =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 Email: jclarke@cisco.com<= /a> <mailto:jclarke@cisco.com&g= t;
>
> =A0 =A0 --------------------------------------------------------= --------------------
>
>
>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--e89a8ff1c024629ebf04e3efdfb3-- From jclarke@cisco.com Wed Aug 14 15:38:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ACC11E81A5 for ; Wed, 14 Aug 2013 15:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnqI0etu9Sje for ; Wed, 14 Aug 2013 15:38:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8511E818C for ; Wed, 14 Aug 2013 15:38:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EMcD2F021973; Thu, 15 Aug 2013 00:38:14 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EMcDXv019871; Wed, 14 Aug 2013 18:38:13 -0400 (EDT) Message-ID: <520C06D5.4090101@cisco.com> Date: Wed, 14 Aug 2013 18:38:13 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 22:38:24 -0000 On 8/14/13 6:28 PM, Alia Atlas wrote: > Ah - I meant a structured file - so the contents are the written > data-model. Thus, a tool could get the file and parse through it to > find what was desirable. The structured file would be described in the > schema, extensible as always, to provide something better than syslog - > without asking the I2RS agent to add in that file parsing and reading > and such. Yep, I understood that. I was going a step further and saying that because the I2RS architecture defines this information collection component, the same file could be collected as information. Thus one would always have a vendor-agnostic way to get to the file as well as parse it. At least to me, this notion seems as applicable to the scope as using information collection to get something orthogonal to routing such as CPU utilization. Joe > > Alia > > > On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke > wrote: > > On 8/14/13 5:35 PM, Alia Atlas wrote: > > I can see having it in a file for displaying or sending - but actually > > having the I2RS agent crawl through it to report the data back??? > > A file/buffer is fine, but will lead to vendor-specific ways of getting > at the data. As I read the architecture concerning information > collection, I thought this might be very useful information for a Client > to collect from the Agent. > > I know Joel disagrees in favor of syslog. I think syslog is okay, but > only if you're receiving messages since the beginning of time (i.e., > before a problem is identified). While I very well may be off base > here, having the a record of what Clients did what on a particular Agent > in a vendor-agnostic way as information to be collected via I2RS seemed > reasonable. > > Joe > > > > > Alia > > > > > > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke > > > >> wrote: > > > > On 8/14/13 1:50 PM, Joel M. Halpern wrote: > > > Are you asking that the history data itself be readable with > I2RS? I > > > really would not want to go there. Asking "who created the > current > > > state, CLI or specific named I2RS client, might be reasonable. > > > > I am suggesting the history (as well as current state) be > readable via > > I2RS itself. In that manner it could be vendor-agnostic by which > > traceability can be done. Current state could be understand who > > installed a route and when (Client identifier and timestamp). > But there > > could be conditions where a Client had a route installed then > removed > > it. If you wanted to correlate a period of bad performance, > you would > > like to be able to query I2RS to see what changed in a > particular time > > frame. > > > > Joe > > > > > > > > Yours, > > > Joel > > > > > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > > >> On 8/14/13 1:35 PM, Alia Atlas wrote: > > >>> Yes, I agree that requiring someyhing like transport mirroring > > would be > > >>> unfortunate. > > >>> > > >>> I also don't think that we should be defining required syslog > > messages. > > >>> > > >>> But the interesting question is whether something reasonable > > could be > > >>> done for vendor-agnostic traceability... > > >> > > >> Yes, that was my point. This would be data that, in my mind, > > could be > > >> queriable via I2RS. > > >> > > >> Joe > > >> > > >>> > > >>> Alia > > >>> > > >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > > > > > > >>> > >>> wrote: > > >>> > > >>> These look like things outside of the scope of I2RS> I > > would not > > >>> want to define message mirroring as part of the transport > > protocol > > >>> requirements, for example. > > >>> > > >>> yours, > > >>> Joel > > >>> > > >>> On 8/14/13 12:39 PM, Alia Atlas wrote: > > >>> > > >>> Hi Joe, > > >>> > > >>> I certainly agree that keeping logs of the APIs done > > and their > > >>> results > > >>> or, perhaps, having the ability to mirror the > requests and > > >>> responses to > > >>> a collector would be useful. > > >>> > > >>> With CLI, I agree that this is frequently done > with syslog > > >>> today > > >>> - which > > >>> then necessitates vendor-specific code to scrape > through. > > >>> > > >>> What would be a meaningful accountability > framework that > > >>> would be > > >>> appropriate and, hopefully, not require > vendor-specific > > >>> screen-scraping? > > >>> > > >>> Completely off the top of my head, I can see the > following > > >>> ideas: > > >>> (a) mirror all (or a meaningful subset) > messages in/out > > >>> to a > > >>> collector that then stores/sorts/logs the information > > >>> (b) Define an accountability information > model that > > >>> defines what > > >>> should be stored and have it stored in the > canonical form > > >>> required by > > >>> the selected data-model. Perhaps mandate it be > stored in a > > >>> file for > > >>> acquisition? Have the ability to read it? > > >>> > > >>> and I'm sure that there are many others... > > >>> > > >>> I do think this is an important area and it could use > > some good > > >>> discussion (and even a draft or a section to go > into the > > >>> architecture). > > >>> > > >>> Alia > > >>> > > >>> > > >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke > > >>> > > > > > >> > > >>> > > > > >>>> wrote: > > >>> > > >>> On 8/14/13 12:11 PM, Alia Atlas wrote: > > >>> > [Alia] I think that (1) belongs in the > architecture. > > >>> I agree > > >>> that it is > > >>> > important - but I feel that the > problem-statement > > >>> part is > > >>> covered > > >>> in the > > >>> > Multi-Headed Control. > > >>> > (2) is mostly covered in "Secure Control". I > > did add > > >>> "Such > > >>> > communications must also have its integrity > > protected." > > >>> since we > > >>> hadn't > > >>> > mentioned integrity but just > authentication and > > >>> authorization. > > >>> > For (3), I'm not sure what aspects > specifically > > apply to > > >>> I2RS... We > > >>> > have authentication and authorization and, > in the > > >>> architecture, > > >>> tracking > > >>> > of state written. What knobs or functionality > > are you > > >>> looking for in > > >>> > accounting? > > >>> > > >>> I'll comment here, and I'm sure Carlos will chime > > in with > > >>> anything I > > >>> miss or if he sees things differently. > > >>> > > >>> Coming from a services/support mindset, > > accountability from > > >>> a tracing > > >>> point of view is important. I would like to > see a > > history > > >>> of actions > > >>> performed, the client that performed them, > when the > > >>> actions were > > >>> performed (with very granular timestamps), > and the > > >>> result code. > > >>> > > >>> Forgive me for using a vendor reference here > (as an > > >>> example), but in > > >>> Cisco IOS we have the buffer of CLI commands > executed > > >>> and syslog > > >>> messages generated. This buffer is very > useful when it > > >>> comes to tracing > > >>> a crash back to potential triggers. As we > look to > > >>> incorporate our own > > >>> APIs, we want to provide the same kind of history > > log to > > >>> try > > >>> and tie API > > >>> calls back to potential problems on the device. > > >>> > > >>> With I2RS in particular, while crashes are > certainly > > >>> possible, being > > >>> able to look back at operations and correlate > > problems like > > >>> packet loss, > > >>> service interruption, performance deviations, > etc. > > will be > > >>> vital from a > > >>> troubleshooting standpoint. > > >>> > > >>> Joe > > >>> > > >>> -- > > >>> Joe Marcus Clarke, CCIE #5384, | > | > > >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| > ||||| > > >>> Distinguished Services Engineer > > ..:|||||||||::|||||||||:.. > > >>> Phone: +1 (919) 392-2867 > > > > > > >>> c > > >>> i s c o S y s t e m s > > >>> Email: jclarke@cisco.com > > > > > >> > > >>> > > > > >>> > > >>> > > >>> > > >>> > > >>> > > > ------------------------------__------------------------------__---------------- > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _________________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > > > >> > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> i2rs mailing list > > >>> i2rs@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/i2rs > > >>> > > >> > > >> > > > > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 > c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- > > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Wed Aug 14 15:47:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269A021E80C3 for ; Wed, 14 Aug 2013 15:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssEny+LtLGd0 for ; Wed, 14 Aug 2013 15:47:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C666621E8051 for ; Wed, 14 Aug 2013 15:47:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EMlCUE022969; Thu, 15 Aug 2013 00:47:13 +0200 (CEST) Received: from dhcp-10-150-54-19.cisco.com (dhcp-10-150-54-19.cisco.com [10.150.54.19]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7EMlCcI026247; Wed, 14 Aug 2013 18:47:12 -0400 (EDT) Message-ID: <520C08F0.1050501@cisco.com> Date: Wed, 14 Aug 2013 18:47:12 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 22:47:20 -0000 On 8/13/13 10:19 PM, Nitin Bahadur wrote: > Hi Joe, > > > Please see inline below for responses. Blanket thanks for the attention and adoption of comments, Nitin. Joe > >> Section 4: >> >> Route programming in the RIB SHOULD result in a return code that >> contains the following attributes: >> >> JMC: Why would one not want to return a result code? I think this needs >> to be a MUST and there is evidence in a later section supporting this. > > Agreed. Fixed. > > >> Section 4: >> >> JMC: How is this result code encapsulated? I realize this is an >> information model, but I thought there would be some description of this >> in your RBNF in Section 6. > > See comment below. > >> Section 5: >> >> Asynchronous notifications are sent by the network device's RIB >> manager to an external entity when some event occurs on the network >> device. A RIB data-model MUST support sending asynchronous >> notifications. A brief list of suggested notifications is as below: >> o Route change notification, with return code as specified in >> Section 4 >> o Nexthop resolution status (resolved/unresolved) notification >> >> JMC: While a RIB data-model must support notifications, there are no >> notifications that must be supported? Are you suggesting that the two >> examples listed here would be mandatory? > > Notifications section is the least developed so far. Yes, we need to > specify what the contents of notifications should be and what > notifications must/should be supported. > > > >> Section 6: >> >> ::= >> [] >> ::= >> >> JMC: I agree with Carlos (and I think you missed his point) IPV4_ADDRESS >> and IPV6_ADDRESS should be IPV4_PREFIX and IPV6_PREFIX as these are not >> addresses but route prefixes (the next-hop is an address) > > Fair point. Updated draft along the lines of: > > ::= [] > ::= > > > >> >> Section 8.1: >> >> JMC: Bulking (as you call it) then must also be supported by a RIB >> client to request data in bulk. > > Yes. Added text towards that. > > >> Section 8.2: >> >> Bulking (grouping of multiple write operations in a single message) >> MUST be supported when an external entity wants to write to the RIB. >> The response from the network device MUST include a return-code for >> each write operation in the bulk message. >> >> JMC: Here, you say the return code per operation is a MUST, which >> implies that in Section 4, this should be a MUST as well. > > Yes updated. > > >> Section 8.3: >> >> There can be cases where a single network event results in multiple >> events and/or notifications from the network device to an external >> entity. On the other hand, due to timing of multiple things >> happening at the same time, a network device might have to send >> multiple events and/or notifications to an external entity. The >> network device originated event/notification message MUST support >> bulking of multiple events and notifications in a single message. >> >> JMC: Here is where I think we need to request something akin to pub-sub >> where the Client can do filtering based on specific events types and >> parameters within those events. While a bulk blob of events might be >> nice for the RIB, I would think a client would want to be tactical about >> the events (and, in fact, within Cisco we offer this kind of granular >> filtering). > > Yes you could define a decent pub-sub model to limit the amount of data > transmitted and for efficiency reasons. > > >> Section 9: >> >> All interactions between a RIB manager and an external entity MUST be >> authenticated. >> >> JMC: Should you also add authorized in addition to authenticated? > > Added. > > Thanks > Nitin > > > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Thu Aug 15 00:07:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7411E80E1 for ; Thu, 15 Aug 2013 00:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f2chxADZVUH for ; Thu, 15 Aug 2013 00:07:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2A21F9F95 for ; Thu, 15 Aug 2013 00:06:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B05020BDA; Thu, 15 Aug 2013 09:06:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cp5Fh_orXI_v; Thu, 15 Aug 2013 09:06:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74DB020BD6; Thu, 15 Aug 2013 09:06:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 58E6C27E0213; Thu, 15 Aug 2013 09:06:48 +0200 (CEST) Date: Thu, 15 Aug 2013 09:06:48 +0200 From: Juergen Schoenwaelder To: Joe Marcus Clarke Message-ID: <20130815070648.GA8153@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Alia Atlas , "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <520BFAB6.3040406@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "i2rs@ietf.org" , Carlos Pignataro , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:07:07 -0000 On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > On 8/14/13 5:35 PM, Alia Atlas wrote: > > I can see having it in a file for displaying or sending - but actually > > having the I2RS agent crawl through it to report the data back??? > > A file/buffer is fine, but will lead to vendor-specific ways of getting > at the data. As I read the architecture concerning information > collection, I thought this might be very useful information for a Client > to collect from the Agent. > > I know Joel disagrees in favor of syslog. I think syslog is okay, but > only if you're receiving messages since the beginning of time (i.e., > before a problem is identified). While I very well may be off base > here, having the a record of what Clients did what on a particular Agent > in a vendor-agnostic way as information to be collected via I2RS seemed > reasonable. Just for your information: RFC 5277 defines a NETCONF extension for notification delivery which supports the playback of event streams. This essentially allows implementations to buffer notifications (which might be syslog messages) for a certain time (or a certain volume) and one can request a replay of the notifications from a given start time until a certain stop time, optionally applying a filter to it. For debugging purposes, such a mechanism (buffering and selected and filtered playback) seems a reasonable solution that is also relatively easy to implement. If, however, complete accountability tracking is the goal, then you need to stream all notifications to an external server and you probably also need something like SYSLOG signatures (RFC 5848) to be able to prove that the notification log is complete etc. Personally, I think i2rs is likely better off with postponing work on event notification logging until the primary goals of i2rs have been met. For early implementors, protocols like SYSLOG likely are good enough. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From akatlas@gmail.com Thu Aug 15 07:06:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE8821F9A57 for ; Thu, 15 Aug 2013 07:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LsUNtT+fbtz for ; Thu, 15 Aug 2013 07:06:01 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 663B521E8143 for ; Thu, 15 Aug 2013 07:05:55 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so807649oag.35 for ; Thu, 15 Aug 2013 07:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ZXh97KvmXJ6GOBlB/FwZ/npA+jydBYk2YFJGY/DAcU=; b=SgWwcBqipdYvH28pBDQ/P48o/YIYDEtz5rMRnsnEcU57y1aBR20cXFdNxmKurlet63 s+LjbWwPsD+pTP9nTzGYMrQptaB4hmG/eCt2tA6K8oBwNe5yHJyQT5Mt29WgfQF6LzO3 /2qEX+lkM64H/+RhmX6j326WNDrC/A8D/RR1E3RHhn/6XkircdF3iYWyNflS/W+ReFp1 +q3gJfYmKpjGRtaGHlDPjxjUApHj4ZQ0wijA6Dlp+v8ydzNfBDQwhYQyNzmr3LihbLk/ LZlT1LJMSkZsguQ1Q4Sr7oDqj6wqYZSdogYqdZw6MUfu7jYiMqRWhcPOVrANGm2jgh/T ichQ== MIME-Version: 1.0 X-Received: by 10.182.104.130 with SMTP id ge2mr26071589obb.6.1376575554058; Thu, 15 Aug 2013 07:05:54 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 07:05:53 -0700 (PDT) In-Reply-To: <520C06D5.4090101@cisco.com> References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <520C06D5.4090101@cisco.com> Date: Thu, 15 Aug 2013 10:05:53 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=089e0112cf10e7ff2f04e3fcf898 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:06:10 -0000 --089e0112cf10e7ff2f04e3fcf898 Content-Type: text/plain; charset=ISO-8859-1 First, I hear and agree with Juergen's point that this is a second order problem. Still, if there are those interested in working on it and documenting what would be desirable, a bit of discussion isn't a bad thing. Second, the minimum necessary seems to be an info model describing what should be saved so that the files can be structured. Third, we have the idea of multiple transports and transport channels in I2RS. I don't think I2RS wants to get into the game of file transfer or of reading it out message by message. Perhaps an operation to request the file transfer via a different channel (scp, ftp?) would address both concerns and allow a bit of experimentation with the multiple transport channel idea? Alia On Wed, Aug 14, 2013 at 6:38 PM, Joe Marcus Clarke wrote: > On 8/14/13 6:28 PM, Alia Atlas wrote: > > Ah - I meant a structured file - so the contents are the written > > data-model. Thus, a tool could get the file and parse through it to > > find what was desirable. The structured file would be described in the > > schema, extensible as always, to provide something better than syslog - > > without asking the I2RS agent to add in that file parsing and reading > > and such. > > Yep, I understood that. I was going a step further and saying that > because the I2RS architecture defines this information collection > component, the same file could be collected as information. Thus one > would always have a vendor-agnostic way to get to the file as well as > parse it. > > At least to me, this notion seems as applicable to the scope as using > information collection to get something orthogonal to routing such as > CPU utilization. > > Joe > > > > > Alia > > > > > > On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke > > wrote: > > > > On 8/14/13 5:35 PM, Alia Atlas wrote: > > > I can see having it in a file for displaying or sending - but > actually > > > having the I2RS agent crawl through it to report the data back??? > > > > A file/buffer is fine, but will lead to vendor-specific ways of > getting > > at the data. As I read the architecture concerning information > > collection, I thought this might be very useful information for a > Client > > to collect from the Agent. > > > > I know Joel disagrees in favor of syslog. I think syslog is okay, > but > > only if you're receiving messages since the beginning of time (i.e., > > before a problem is identified). While I very well may be off base > > here, having the a record of what Clients did what on a particular > Agent > > in a vendor-agnostic way as information to be collected via I2RS > seemed > > reasonable. > > > > Joe > > > > > > > > Alia > > > > > > > > > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke > > > > > >> wrote: > > > > > > On 8/14/13 1:50 PM, Joel M. Halpern wrote: > > > > Are you asking that the history data itself be readable with > > I2RS? I > > > > really would not want to go there. Asking "who created the > > current > > > > state, CLI or specific named I2RS client, might be > reasonable. > > > > > > I am suggesting the history (as well as current state) be > > readable via > > > I2RS itself. In that manner it could be vendor-agnostic by > which > > > traceability can be done. Current state could be understand > who > > > installed a route and when (Client identifier and timestamp). > > But there > > > could be conditions where a Client had a route installed then > > removed > > > it. If you wanted to correlate a period of bad performance, > > you would > > > like to be able to query I2RS to see what changed in a > > particular time > > > frame. > > > > > > Joe > > > > > > > > > > > Yours, > > > > Joel > > > > > > > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: > > > >> On 8/14/13 1:35 PM, Alia Atlas wrote: > > > >>> Yes, I agree that requiring someyhing like transport > mirroring > > > would be > > > >>> unfortunate. > > > >>> > > > >>> I also don't think that we should be defining required > syslog > > > messages. > > > >>> > > > >>> But the interesting question is whether something > reasonable > > > could be > > > >>> done for vendor-agnostic traceability... > > > >> > > > >> Yes, that was my point. This would be data that, in my > mind, > > > could be > > > >> queriable via I2RS. > > > >> > > > >> Joe > > > >> > > > >>> > > > >>> Alia > > > >>> > > > >>> On Aug 14, 2013 1:29 PM, "Joel M. Halpern" > > > > > > > > > >>> > > >>> wrote: > > > >>> > > > >>> These look like things outside of the scope of I2RS> > I > > > would not > > > >>> want to define message mirroring as part of the > transport > > > protocol > > > >>> requirements, for example. > > > >>> > > > >>> yours, > > > >>> Joel > > > >>> > > > >>> On 8/14/13 12:39 PM, Alia Atlas wrote: > > > >>> > > > >>> Hi Joe, > > > >>> > > > >>> I certainly agree that keeping logs of the APIs > done > > > and their > > > >>> results > > > >>> or, perhaps, having the ability to mirror the > > requests and > > > >>> responses to > > > >>> a collector would be useful. > > > >>> > > > >>> With CLI, I agree that this is frequently done > > with syslog > > > >>> today > > > >>> - which > > > >>> then necessitates vendor-specific code to scrape > > through. > > > >>> > > > >>> What would be a meaningful accountability > > framework that > > > >>> would be > > > >>> appropriate and, hopefully, not require > > vendor-specific > > > >>> screen-scraping? > > > >>> > > > >>> Completely off the top of my head, I can see the > > following > > > >>> ideas: > > > >>> (a) mirror all (or a meaningful subset) > > messages in/out > > > >>> to a > > > >>> collector that then stores/sorts/logs the > information > > > >>> (b) Define an accountability information > > model that > > > >>> defines what > > > >>> should be stored and have it stored in the > > canonical form > > > >>> required by > > > >>> the selected data-model. Perhaps mandate it be > > stored in a > > > >>> file for > > > >>> acquisition? Have the ability to read it? > > > >>> > > > >>> and I'm sure that there are many others... > > > >>> > > > >>> I do think this is an important area and it could > use > > > some good > > > >>> discussion (and even a draft or a section to go > > into the > > > >>> architecture). > > > >>> > > > >>> Alia > > > >>> > > > >>> > > > >>> On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus > Clarke > > > >>> > > > > > > > > >> > > > >>> > > > > > > > > >>>> wrote: > > > >>> > > > >>> On 8/14/13 12:11 PM, Alia Atlas wrote: > > > >>> > [Alia] I think that (1) belongs in the > > architecture. > > > >>> I agree > > > >>> that it is > > > >>> > important - but I feel that the > > problem-statement > > > >>> part is > > > >>> covered > > > >>> in the > > > >>> > Multi-Headed Control. > > > >>> > (2) is mostly covered in "Secure Control". > I > > > did add > > > >>> "Such > > > >>> > communications must also have its integrity > > > protected." > > > >>> since we > > > >>> hadn't > > > >>> > mentioned integrity but just > > authentication and > > > >>> authorization. > > > >>> > For (3), I'm not sure what aspects > > specifically > > > apply to > > > >>> I2RS... We > > > >>> > have authentication and authorization and, > > in the > > > >>> architecture, > > > >>> tracking > > > >>> > of state written. What knobs or > functionality > > > are you > > > >>> looking for in > > > >>> > accounting? > > > >>> > > > >>> I'll comment here, and I'm sure Carlos will > chime > > > in with > > > >>> anything I > > > >>> miss or if he sees things differently. > > > >>> > > > >>> Coming from a services/support mindset, > > > accountability from > > > >>> a tracing > > > >>> point of view is important. I would like to > > see a > > > history > > > >>> of actions > > > >>> performed, the client that performed them, > > when the > > > >>> actions were > > > >>> performed (with very granular timestamps), > > and the > > > >>> result code. > > > >>> > > > >>> Forgive me for using a vendor reference here > > (as an > > > >>> example), but in > > > >>> Cisco IOS we have the buffer of CLI commands > > executed > > > >>> and syslog > > > >>> messages generated. This buffer is very > > useful when it > > > >>> comes to tracing > > > >>> a crash back to potential triggers. As we > > look to > > > >>> incorporate our own > > > >>> APIs, we want to provide the same kind of > history > > > log to > > > >>> try > > > >>> and tie API > > > >>> calls back to potential problems on the > device. > > > >>> > > > >>> With I2RS in particular, while crashes are > > certainly > > > >>> possible, being > > > >>> able to look back at operations and correlate > > > problems like > > > >>> packet loss, > > > >>> service interruption, performance deviations, > > etc. > > > will be > > > >>> vital from a > > > >>> troubleshooting standpoint. > > > >>> > > > >>> Joe > > > >>> > > > >>> -- > > > >>> Joe Marcus Clarke, CCIE #5384, | > > | > > > >>> SCJP, SCSA, SCNA, SCSECA, VCP ||||| > > ||||| > > > >>> Distinguished Services Engineer > > > ..:|||||||||::|||||||||:.. > > > >>> Phone: +1 (919) 392-2867 > > > > > > > > > > >>> c > > > >>> i s c o S y s t e m s > > > >>> Email: jclarke@cisco.com > > > > > > > > > >> > > > >>> > > > > > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > ------------------------------__------------------------------__---------------- > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> _________________________________________________ > > > >>> i2rs mailing list > > > >>> i2rs@ietf.org > > > > > > > > >> > > > >>> https://www.ietf.org/mailman/__listinfo/i2rs > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> i2rs mailing list > > > >>> i2rs@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/i2rs > > > >>> > > > >> > > > >> > > > > > > > > > > > > > -- > > > Joe Marcus Clarke, CCIE #5384, | | > > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > > Phone: +1 (919) 392-2867 > > c > > > i s c o S y s t e m s > > > Email: jclarke@cisco.com > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > -- > > Joe Marcus Clarke, CCIE #5384, | | > > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > > Phone: +1 (919) 392-2867 c > > i s c o S y s t e m s > > Email: jclarke@cisco.com > > > > > ---------------------------------------------------------------------------- > > > > > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > > ---------------------------------------------------------------------------- > --089e0112cf10e7ff2f04e3fcf898 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
First, I hear and agree with Juergen's point that this= is a second order problem. =A0Still, if there are those
interested in = working on it and documenting what would be desirable, a bit of discussion = isn't a bad thing.

Second, the minimum necessary seems to be an info model= describing what should be saved so that the
files can be structu= red.

Third, we have the idea of multiple transport= s and transport channels in I2RS. =A0I don't think I2RS wants
to get into the game of file transfer or of reading it out messa= ge by message. =A0Perhaps an operation to
request the file transf= er via a different channel (scp, ftp?) would address both concerns and allo= w a bit
of experimentation with the multiple transport channel idea?

Alia


On Wed, Aug 14, 2013 at 6:38 PM, Joe Marcus Clarke= <jclarke@cisco.com> wrote:
On 8/14/13 6:28 PM, Alia A= tlas wrote:
> Ah - I meant a structured file - so the contents are the written
> data-model. =A0Thus, a tool could get the file and parse through it to=
> find what was desirable. =A0The structured file would be described in = the
> schema, extensible as always, to provide something better than syslog = -
> without asking the I2RS agent to add in that file parsing and reading<= br> > and such.

Yep, I understood that. =A0I was going a step further and saying that=
because the I2RS architecture defines this information collection
component, the same file could be collected as information. =A0Thus one
would always have a vendor-agnostic way to get to the file as well as
parse it.

At least to me, this notion seems as applicable to the scope as using
information collection to get something orthogonal to routing such as
CPU utilization.

Joe

>
> Alia
>
>
> On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke &= lt;jclarke@cisco.com
> <mailto:jclarke@cisco.com>> wrote:
>
> =A0 =A0 On 8/14/13 5:35 PM, Alia Atlas wrote:
> =A0 =A0 > I can see having it in a file for displaying or sending -= but actually
> =A0 =A0 > having the I2RS agent crawl through it to report the data= back???
>
> =A0 =A0 A file/buffer is fine, but will lead to vendor-specific ways o= f getting
> =A0 =A0 at the data. =A0As I read the architecture concerning informat= ion
> =A0 =A0 collection, I thought this might be very useful information fo= r a Client
> =A0 =A0 to collect from the Agent.
>
> =A0 =A0 I know Joel disagrees in favor of syslog. =A0I think syslog is= okay, but
> =A0 =A0 only if you're receiving messages since the beginning of t= ime (i.e.,
> =A0 =A0 before a problem is identified). =A0While I very well may be o= ff base
> =A0 =A0 here, having the a record of what Clients did what on a partic= ular Agent
> =A0 =A0 in a vendor-agnostic way as information to be collected via I2= RS seemed
> =A0 =A0 reasonable.
>
> =A0 =A0 Joe
>
> =A0 =A0 >
> =A0 =A0 > Alia
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke
> =A0 =A0 <jclarke@cisco.com= <mailto:jclarke@cisco.com><= br>
> =A0 =A0 > <mailto:jclarke@cisco.com <mailto:jclarke@cisco.com>>> wrote:
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 On 8/14/13 1:50 PM, = Joel M. Halpern wrote:
> =A0 =A0 > =A0 =A0 > Are you asking that the history data itself = be readable with
> =A0 =A0 I2RS? =A0I
> =A0 =A0 > =A0 =A0 > really would not want to go there. =A0Asking= "who created the
> =A0 =A0 current
> =A0 =A0 > =A0 =A0 > state, CLI or specific named I2RS client, mi= ght be reasonable.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I am suggesting the history (as well as current s= tate) be
> =A0 =A0 readable via
> =A0 =A0 > =A0 =A0 I2RS itself. =A0In that manner it could be vendor= -agnostic by which
> =A0 =A0 > =A0 =A0 traceability can be done. =A0 Current state could= be understand who
> =A0 =A0 > =A0 =A0 installed a route and when (Client identifier and= timestamp).
> =A0 =A0 =A0But there
> =A0 =A0 > =A0 =A0 could be conditions where a Client had a route in= stalled then
> =A0 =A0 removed
> =A0 =A0 > =A0 =A0 it. =A0If you wanted to correlate a period of bad= performance,
> =A0 =A0 you would
> =A0 =A0 > =A0 =A0 like to be able to query I2RS to see what changed= in a
> =A0 =A0 particular time
> =A0 =A0 > =A0 =A0 frame.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Joe
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Yours,
> =A0 =A0 > =A0 =A0 > Joel
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote:=
> =A0 =A0 > =A0 =A0 >> On 8/14/13 1:35 PM, Alia Atlas wrote: > =A0 =A0 > =A0 =A0 >>> Yes, I agree that requiring someyhin= g like transport mirroring
> =A0 =A0 > =A0 =A0 would be
> =A0 =A0 > =A0 =A0 >>> unfortunate.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> I also don't think that we shoul= d be defining required syslog
> =A0 =A0 > =A0 =A0 messages.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> But the interesting question is whet= her something reasonable
> =A0 =A0 > =A0 =A0 could be
> =A0 =A0 > =A0 =A0 >>> done for vendor-agnostic traceabilit= y...
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> Yes, that was my point. =A0This would be= data that, in my mind,
> =A0 =A0 > =A0 =A0 could be
> =A0 =A0 > =A0 =A0 >> queriable via I2RS.
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >> Joe
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> Alia
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> On Aug 14, 2013 1:29 PM, "Joel = M. Halpern"
> =A0 =A0 <jmh@joelhalpern.com= <mailto:jmh@joelhalpern.com<= /a>>
> =A0 =A0 > =A0 =A0 <mailto:jmh@joelhalpern.com <mailto:= jmh@joelhalpern.com>>
> =A0 =A0 > =A0 =A0 >>> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
> =A0 =A0 <mailto:jmh@joelhalp= ern.com <mailto:jmh@joelhalpe= rn.com>>>> wrote:
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0These look like things ou= tside of the scope of I2RS> =A0I
> =A0 =A0 > =A0 =A0 would not
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0want to define message mi= rroring as part of the transport
> =A0 =A0 > =A0 =A0 protocol
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0requirements, for example= .
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0yours,
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0Joel
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0On 8/14/13 12:39 PM, Alia= Atlas wrote:
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Hi Joe,
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I certainly agree= that keeping logs of the APIs done
> =A0 =A0 > =A0 =A0 and their
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0results
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0or, perhaps, havi= ng the ability to mirror the
> =A0 =A0 requests and
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0responses to
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0a collector would= be useful.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0With CLI, I agree= that this is frequently done
> =A0 =A0 with syslog
> =A0 =A0 > =A0 =A0 >>> today
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0- which
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0then necessitates= vendor-specific code to scrape
> =A0 =A0 through.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0What would be a m= eaningful accountability
> =A0 =A0 framework that
> =A0 =A0 > =A0 =A0 >>> would be
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0appropriate and, = hopefully, not require
> =A0 =A0 vendor-specific
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0screen-scraping?<= br> > =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Completely off th= e top of my head, I can see the
> =A0 =A0 following
> =A0 =A0 > =A0 =A0 >>> ideas:
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(a) mirro= r all (or a meaningful subset)
> =A0 =A0 messages in/out
> =A0 =A0 > =A0 =A0 >>> to a
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0collector that th= en stores/sorts/logs the information
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0(b) Defin= e an accountability information
> =A0 =A0 model that
> =A0 =A0 > =A0 =A0 >>> defines what
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0should be stored = and have it stored in the
> =A0 =A0 canonical form
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0required by
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0the selected data= -model. =A0Perhaps mandate it be
> =A0 =A0 stored in a
> =A0 =A0 > =A0 =A0 >>> file for
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0acquisition? =A0H= ave the ability to read it?
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0and I'm sure = that there are many others...
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I do think this i= s an important area and it could use
> =A0 =A0 > =A0 =A0 some good
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0discussion (and e= ven a draft or a section to go
> =A0 =A0 into the
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0architecture). > =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0Alia
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0On Wed, Aug 14, 2= 013 at 12:29 PM, Joe Marcus Clarke
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<jclarke@cisco.com <mailto:jclarke@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>
> =A0 =A0 > =A0 =A0 <mailto:j= clarke@cisco.com <mailto:jclark= e@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com
> =A0 =A0 <mailto:jclarke@cisco.= com> <mailto:jclarke@cisco.c= om
> =A0 =A0 <mailto:jclarke@cisco.= com>>
> =A0 =A0 > =A0 =A0 <mailto:j= clarke@cisco.com <mailto:jclark= e@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>>>> wrote:
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0On 8/14/1= 3 12:11 PM, Alia Atlas wrote:
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > [Al= ia] I think that (1) belongs in the
> =A0 =A0 architecture.
> =A0 =A0 > =A0 =A0 >>> I agree
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0that it i= s
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > imp= ortant - but I feel that the
> =A0 =A0 problem-statement
> =A0 =A0 > =A0 =A0 >>> part is
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0covered
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0in the > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Mul= ti-Headed Control.
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > (2)= is mostly covered in "Secure Control". =A0I
> =A0 =A0 > =A0 =A0 did add
> =A0 =A0 > =A0 =A0 >>> "Such
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > com= munications must also have its integrity
> =A0 =A0 > =A0 =A0 protected."
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0since we
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0hadn'= t
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > men= tioned integrity but just
> =A0 =A0 authentication and
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0authorization. > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > For= (3), I'm not sure what aspects
> =A0 =A0 specifically
> =A0 =A0 > =A0 =A0 apply to
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0I2RS... =A0We
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > hav= e authentication and authorization and,
> =A0 =A0 in the
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0architecture,
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0tracking<= br> > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > of = state written. =A0What knobs or functionality
> =A0 =A0 > =A0 =A0 are you
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0looking for in > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 > acc= ounting?
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0I'll = comment here, and I'm sure Carlos will chime
> =A0 =A0 > =A0 =A0 in with
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0anything I
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0miss or i= f he sees things differently.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Coming fr= om a services/support mindset,
> =A0 =A0 > =A0 =A0 accountability from
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0a tracing
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0point of = view is important. =A0I would like to
> =A0 =A0 see a
> =A0 =A0 > =A0 =A0 history
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0of actions
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed= , the client that performed them,
> =A0 =A0 when the
> =A0 =A0 > =A0 =A0 >>> actions were
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0performed= (with very granular timestamps),
> =A0 =A0 and the
> =A0 =A0 > =A0 =A0 >>> result code.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Forgive m= e for using a vendor reference here
> =A0 =A0 (as an
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0example), but in<= br> > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Cisco IOS= we have the buffer of CLI commands
> =A0 =A0 executed
> =A0 =A0 > =A0 =A0 >>> and syslog
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0messages = generated. =A0This buffer is very
> =A0 =A0 useful when it
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0comes to tracing<= br> > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0a crash b= ack to potential triggers. =A0As we
> =A0 =A0 look to
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0incorporate our o= wn
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0APIs, we = want to provide the same kind of history
> =A0 =A0 > =A0 =A0 log to
> =A0 =A0 > =A0 =A0 >>> try
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0and tie API
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0calls bac= k to potential problems on the device.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0With I2RS= in particular, while crashes are
> =A0 =A0 certainly
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0possible, being > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0able to l= ook back at operations and correlate
> =A0 =A0 > =A0 =A0 problems like
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0packet loss,
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0service i= nterruption, performance deviations,
> =A0 =A0 etc.
> =A0 =A0 > =A0 =A0 will be
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0vital from a
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0troublesh= ooting standpoint.
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0--
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Joe Marcu= s Clarke, CCIE #5384, =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0SCJP, SCS= A, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0|||||
> =A0 =A0 =A0 =A0|||||
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Distingui= shed Services Engineer
> =A0 =A0 > =A0 =A0 ..:|||||||||::|||||||||:..
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Phone: +1 (919) 3= 92-2867
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867>
> =A0 =A0 > =A0 =A0 <tel:%2B1%20%28919%29%20392-2867>
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<tel:%2B1%20%2= 8919%29%20392-__2867> =A0 =A0 =A0 =A0 c
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0i s c o = =A0S y s t e m s
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Email: jclarke@cisco.com
> =A0 =A0 <mailto:jclarke@cisco.= com> <mailto:jclarke@cisco.c= om
> =A0 =A0 <mailto:jclarke@cisco.= com>>
> =A0 =A0 > =A0 =A0 <mailto:j= clarke@cisco.com <mailto:jclark= e@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<mailto:jclarke@cisco.com
> =A0 =A0 <mailto:jclarke@cisco.= com> <mailto:jclarke@cisco.c= om
> =A0 =A0 <mailto:jclarke@cisco.= com>>
> =A0 =A0 > =A0 =A0 <mailto:j= clarke@cisco.com <mailto:jclark= e@cisco.com>
> =A0 =A0 <mailto:jclarke@cisco.= com <mailto:jclarke@cisco.com>>>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 >
> =A0 =A0 ------------------------------__------------------------------= __----------------
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0_________________= ________________________________
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0i2rs mailing list=
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0i2rs@ietf.org <mailto:i2rs@ietf.org>
> =A0 =A0 <mailto:i2rs@ietf.org = <mailto:i2rs@ietf.org>>
> =A0 =A0 > =A0 =A0 <mailto:i2rs@= ietf.org <mailto:i2rs@ietf.org&= gt;
> =A0 =A0 <mailto:i2rs@ietf.org = <mailto:i2rs@ietf.org>>> > =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0https://www.ietf.= org/mailman/__listinfo/i2rs
> =A0 =A0 > =A0 =A0 >>> =A0 =A0 =A0 =A0 =A0<https://www.iet= f.org/mailman/listinfo/i2rs>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>> ____________________________________= ___________
> =A0 =A0 > =A0 =A0 >>> i2rs mailing list
> =A0 =A0 > =A0 =A0 >>> i2r= s@ietf.org <mailto:i2rs@ietf.org> <mailto:i2rs@ietf.org
> =A0 =A0 <mailto:i2rs@ietf.org&= gt;>
> =A0 =A0 > =A0 =A0 >>> https://www.ietf.org/mailman/listinfo/= i2rs
> =A0 =A0 > =A0 =A0 >>>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >>
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 --
> =A0 =A0 > =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | = =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 > =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||= | =A0 =A0 =A0|||||
> =A0 =A0 > =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||= ||||||:..
> =A0 =A0 > =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%203= 92-2867>
> =A0 =A0 <tel:%2B1%20%28919%29%20392-2867> =A0 =A0 =A0 =A0 c
> =A0 =A0 > =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 > =A0 =A0 Email: jclar= ke@cisco.com <mailto:jclarke@ci= sco.com>
> =A0 =A0 <mailto:jc= larke@cisco.com <mailto:jclarke= @cisco.com>>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 --------------------------------------------------------------= --------------
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > _______________________________________________
> =A0 =A0 > i2rs mailing list
> =A0 =A0 > i2rs@ietf.org <ma= ilto:i2rs@ietf.org>
> =A0 =A0 > https://www.ietf.org/mailman/listinfo/i2rs
> =A0 =A0 >
>
>
> =A0 =A0 --
> =A0 =A0 Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0|
> =A0 =A0 SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0= |||||
> =A0 =A0 Distinguished Services Engineer ..:|||||||||::|||||||||:..
> =A0 =A0 Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867> = =A0 =A0 =A0 =A0 c
> =A0 =A0 i s c o =A0S y s t e m s
> =A0 =A0 Email: jclarke@cisco.com<= /a> <mailto:jclarke@cisco.com&g= t;
>
> =A0 =A0 --------------------------------------------------------------= --------------
>
>


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: += 1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t e m s
Email: jclarke@cisco.com

---------------------------------------------------------------------------= -

--089e0112cf10e7ff2f04e3fcf898-- From akatlas@gmail.com Thu Aug 15 07:10:27 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9CE11E8153 for ; Thu, 15 Aug 2013 07:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aiv2qnX-AlPY for ; Thu, 15 Aug 2013 07:10:25 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 68ABC11E80EE for ; Thu, 15 Aug 2013 07:10:25 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so885702obc.34 for ; Thu, 15 Aug 2013 07:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4DARfQYKHnnP7955DDCK14YmRK2Cr5kznrwgIy56+9U=; b=CUvDOKkxoN+FhKOIxatXH+MoxxhLjTgCP5Cdf6Bhv/x08M98TCnhwxNAoAPB8sTpGk 9yMseDqg0fBjo16bsPSnf9PFNEI7XZFVhD4oHwPKo+qJUAQh4Pe56XSRgzHK9XeRxmUk 9OrYZINy0xu+uEshWq+oVs5DRVK7vKaYZgZ6/G/LUsDYlKOYiQCd7lAQVTTF9BwKMfc8 84cGfWmv+/4tps4xeiAe3XYvp+d0vArc87vDwI/SkR7NJyOpiidLvis3STBIiDoYNiIA jZChijrMA0vr4nbiOCXj/D53+/ucs70+7p5yBvrOepk4AxzFVcjqeDko6qL7d3/x5ZPt CnGA== MIME-Version: 1.0 X-Received: by 10.60.93.67 with SMTP id cs3mr14491371oeb.12.1376575823576; Thu, 15 Aug 2013 07:10:23 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 07:10:23 -0700 (PDT) In-Reply-To: <20130815070648.GA8153@elstar.local> References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> Date: Thu, 15 Aug 2013 10:10:23 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Joe Marcus Clarke , Alia Atlas , "i2rs@ietf.org" , "Joel M. Halpern" , Carlos Pignataro Content-Type: multipart/alternative; boundary=047d7b33d176f8829604e3fd0861 Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:10:27 -0000 --047d7b33d176f8829604e3fd0861 Content-Type: text/plain; charset=ISO-8859-1 Juergen, Thanks for the useful information. I agree that a focus on traceability is not an initial primary goal, but Joe's point that syslog isn't vendor-agnostic is a good one too. I'm not sure that I see a network application doing automated troubleshooting and recovery - but perhaps I'm insufficiently optimistic. Alia On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > > On 8/14/13 5:35 PM, Alia Atlas wrote: > > > I can see having it in a file for displaying or sending - but actually > > > having the I2RS agent crawl through it to report the data back??? > > > > A file/buffer is fine, but will lead to vendor-specific ways of getting > > at the data. As I read the architecture concerning information > > collection, I thought this might be very useful information for a Client > > to collect from the Agent. > > > > I know Joel disagrees in favor of syslog. I think syslog is okay, but > > only if you're receiving messages since the beginning of time (i.e., > > before a problem is identified). While I very well may be off base > > here, having the a record of what Clients did what on a particular Agent > > in a vendor-agnostic way as information to be collected via I2RS seemed > > reasonable. > > Just for your information: RFC 5277 defines a NETCONF extension for > notification delivery which supports the playback of event streams. > This essentially allows implementations to buffer notifications (which > might be syslog messages) for a certain time (or a certain volume) and > one can request a replay of the notifications from a given start time > until a certain stop time, optionally applying a filter to it. > > For debugging purposes, such a mechanism (buffering and selected and > filtered playback) seems a reasonable solution that is also relatively > easy to implement. If, however, complete accountability tracking is > the goal, then you need to stream all notifications to an external > server and you probably also need something like SYSLOG signatures > (RFC 5848) to be able to prove that the notification log is complete > etc. > > Personally, I think i2rs is likely better off with postponing work on > event notification logging until the primary goals of i2rs have been > met. For early implementors, protocols like SYSLOG likely are good > enough. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b33d176f8829604e3fd0861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Juergen,

Thanks for the useful informat= ion. =A0I agree that a focus on traceability is not an initial primary goal= , but Joe's point that syslog isn't
vendor-agnostic is a = good one too. =A0I'm not sure that I see a network application doing au= tomated troubleshooting and recovery -
but perhaps I'm insufficiently optimistic.

Alia


On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Aug 14, 2013 at 05= :46:30PM -0400, Joe Marcus Clarke wrote:
> On 8/14/13 5:35 PM, Alia Atlas wrote:
> > I can see having it in a file for displaying or sending - but act= ually
> > having the I2RS agent crawl through it to report the data back???=
>
> A file/buffer is fine, but will lead to vendor-specific ways of gettin= g
> at the data. =A0As I read the architecture concerning information
> collection, I thought this might be very useful information for a Clie= nt
> to collect from the Agent.
>
> I know Joel disagrees in favor of syslog. =A0I think syslog is okay, b= ut
> only if you're receiving messages since the beginning of time (i.e= .,
> before a problem is identified). =A0While I very well may be off base<= br> > here, having the a record of what Clients did what on a particular Age= nt
> in a vendor-agnostic way as information to be collected via I2RS seeme= d
> reasonable.

Just for your information: RFC 5277 defines a NETCONF extension for notification delivery which supports the playback of event streams.
This essentially allows implementations to buffer notifications (which
might be syslog messages) for a certain time (or a certain volume) and
one can request a replay of the notifications from a given start time
until a certain stop time, optionally applying a filter to it.

For debugging purposes, such a mechanism (buffering and selected and
filtered playback) seems a reasonable solution that is also relatively
easy to implement. If, however, complete accountability tracking is
the goal, then you need to stream all notifications to an external
server and you probably also need something like SYSLOG signatures
(RFC 5848) to be able to prove that the notification log is complete
etc.

Personally, I think i2rs is likely better off with postponing work on
event notification logging until the primary goals of i2rs have been
met. For early implementors, protocols like SYSLOG likely are good
enough.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

--047d7b33d176f8829604e3fd0861-- From andy@yumaworks.com Thu Aug 15 07:31:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD76521E8155 for ; Thu, 15 Aug 2013 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YhQFtEnJaIF for ; Thu, 15 Aug 2013 07:31:25 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 362BF11E8152 for ; Thu, 15 Aug 2013 07:31:23 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so779835pbc.18 for ; Thu, 15 Aug 2013 07:31:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jr0pj3qY5/p9oo5gTOdpeLs2giJlSeXxWCWCrHnJHJU=; b=coyfs3jpI3zrB2049GBkdrCG2ovJzqPe2uRmckQf172zv4KG6mS5VvZHRejDvrRb8n xpjuQHBGvIrRzxAR6cadIqDBZsAhDS9IAEbz4O54IQ/sGAgPtizFmXLCfAbRk0Ne0DOz WA28y2x3MLSKYnBGpkHSGwAEIx3+FZf0Tr70ZTFKuORSpGhBPQG9duQOtfCOAG0sugbF OEvTJrRAlxFHjT77ngOmaLCg80I0NofNKuY7wONJgEhUBZAM2+VV3qgjKPIrWbPvTJ0w EkU5MY4idhWRzxeRpUzaeXM1fiDBaPYEESsdNtJRo9SUgX9LDpXYpZh74whQN1zFuxpU NdQg== X-Gm-Message-State: ALoCoQkcUVOfUqiX+ZNnvSlhVGSLUTnjXBS4SULd3HKERQhNP3sCflnyYwjYAZo2SowYip8cU53y MIME-Version: 1.0 X-Received: by 10.66.100.134 with SMTP id ey6mr7406042pab.38.1376577081036; Thu, 15 Aug 2013 07:31:21 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Thu, 15 Aug 2013 07:31:20 -0700 (PDT) In-Reply-To: References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> Date: Thu, 15 Aug 2013 07:31:20 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Carlos Pignataro , Joe Marcus Clarke , Juergen Schoenwaelder , "Joel M. Halpern" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:31:44 -0000 Hi, We are going to run into several long-unsolved NM problems like "standardized log files". (Knowing that adding such a huge task to the charter would be a mistake is the difference between boiling an ocean or just a lake. ;-) Notifications may not be a 2nd order problem because the WG punted on the "I2RS broker" role. Now it is up to each I2RS Client to know that the RIB state it injected got replaced by a higher priority client, or know a higher priority entry was deleted and now maybe it can try again. IMO, the notification mechanism will need to be quite sophisticated to filter just the events relevant to a specific client. More likely all clients will each get all notifications, creating N fire-hoses of 'add' and 'delete' events. At the BoF, the metric "5000 updates a second" was mentioned as the answer to the question "what is fast-path?" How many notifications per second are reasonable for I2RS? Andy On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas wrote: > Juergen, > > Thanks for the useful information. I agree that a focus on traceability is > not an initial primary goal, but Joe's point that syslog isn't > vendor-agnostic is a good one too. I'm not sure that I see a network > application doing automated troubleshooting and recovery - > but perhaps I'm insufficiently optimistic. > > Alia > > > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder > wrote: >> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: >> > On 8/14/13 5:35 PM, Alia Atlas wrote: >> > > I can see having it in a file for displaying or sending - but actually >> > > having the I2RS agent crawl through it to report the data back??? >> > >> > A file/buffer is fine, but will lead to vendor-specific ways of getting >> > at the data. As I read the architecture concerning information >> > collection, I thought this might be very useful information for a Client >> > to collect from the Agent. >> > >> > I know Joel disagrees in favor of syslog. I think syslog is okay, but >> > only if you're receiving messages since the beginning of time (i.e., >> > before a problem is identified). While I very well may be off base >> > here, having the a record of what Clients did what on a particular Agent >> > in a vendor-agnostic way as information to be collected via I2RS seemed >> > reasonable. >> >> Just for your information: RFC 5277 defines a NETCONF extension for >> notification delivery which supports the playback of event streams. >> This essentially allows implementations to buffer notifications (which >> might be syslog messages) for a certain time (or a certain volume) and >> one can request a replay of the notifications from a given start time >> until a certain stop time, optionally applying a filter to it. >> >> For debugging purposes, such a mechanism (buffering and selected and >> filtered playback) seems a reasonable solution that is also relatively >> easy to implement. If, however, complete accountability tracking is >> the goal, then you need to stream all notifications to an external >> server and you probably also need something like SYSLOG signatures >> (RFC 5848) to be able to prove that the notification log is complete >> etc. >> >> Personally, I think i2rs is likely better off with postponing work on >> event notification logging until the primary goals of i2rs have been >> met. For early implementors, protocols like SYSLOG likely are good >> enough. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From akatlas@gmail.com Thu Aug 15 07:39:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365FE21F9FBE for ; Thu, 15 Aug 2013 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOh81Z2TLuFM for ; Thu, 15 Aug 2013 07:39:30 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62B21F9F98 for ; Thu, 15 Aug 2013 07:39:30 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so852527oag.32 for ; Thu, 15 Aug 2013 07:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fDXbPv49hMWqdY5YKC8r+IrCKOUq/YnjG4y0AQjxeEA=; b=Fs2QVEBNebhVdXybmz6GQTZ0lSY0DxRH7lQlTCn3t4BtY32SVtZVjz+afGUGUpruUg TVO1w0Cmzlbdta6uy1wXBhV3Pp89XOhqJJ7TL+rWLynYzEixng/azA7iAx2l2dnaiqAe 4RpJ4lEcabdu1/9lP6wHZ/toqbSuAlaPQPC0kFbZbZHOpDjfkLPho/GSPBwK2OPE+k/b FSvu8LfEbOowvKfQ5IIJ8WSY8sZ+pSJUrGSjCphFh0QCPaB5peBdg0GLKXOpjzZr2b9u MxY3Zit2or9rG+zxlFbigoXBUttRUBGq0GY7o4buaqzp7X/B4M49yXroe6Xm2IF7cp8m v+qw== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr26596983obo.35.1376577563852; Thu, 15 Aug 2013 07:39:23 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 07:39:23 -0700 (PDT) In-Reply-To: References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> Date: Thu, 15 Aug 2013 10:39:23 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b6700c9b3082404e3fd7028 Cc: "i2rs@ietf.org" , Carlos Pignataro , Joe Marcus Clarke , Juergen Schoenwaelder , "Joel M. Halpern" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:39:59 -0000 X-List-Received-Date: Thu, 15 Aug 2013 14:39:59 -0000 --047d7b6700c9b3082404e3fd7028 Content-Type: text/plain; charset=ISO-8859-1 Hi Andy, I meant that the traceability and syslog aspects are a 2nd order problem. I agree very strongly that notifications are a primary concern. That's how clients learn about network changes, changes affecting their state, etc. I believe that we need a sophisticated mechanism to filter and send just the relevant events to the specific client. Sending all notifications to all clients would be bad in terms of scaling and security. I don't have a fixed number for the notifications per second. I'm curious if others have thought about it? Alia On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman wrote: > Hi, > > We are going to run into several long-unsolved NM problems > like "standardized log files". (Knowing that adding such a huge > task to the charter would be a mistake is the difference between > boiling an ocean or just a lake. ;-) > > Notifications may not be a 2nd order problem because the > WG punted on the "I2RS broker" role. Now it is up to > each I2RS Client to know that the RIB state it injected > got replaced by a higher priority client, or know a higher > priority entry was deleted and now maybe it can try again. > > IMO, the notification mechanism will need to be quite > sophisticated to filter just the events relevant to a specific client. > More likely all clients will each get all notifications, creating > N fire-hoses of 'add' and 'delete' events. > > At the BoF, the metric "5000 updates a second" was mentioned > as the answer to the question "what is fast-path?" How many > notifications per second are reasonable for I2RS? > > > Andy > > On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas wrote: > > Juergen, > > > > Thanks for the useful information. I agree that a focus on traceability > is > > not an initial primary goal, but Joe's point that syslog isn't > > vendor-agnostic is a good one too. I'm not sure that I see a network > > application doing automated troubleshooting and recovery - > > but perhaps I'm insufficiently optimistic. > > > > Alia > > > > > > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder > > wrote: > >> > >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > >> > On 8/14/13 5:35 PM, Alia Atlas wrote: > >> > > I can see having it in a file for displaying or sending - but > actually > >> > > having the I2RS agent crawl through it to report the data back??? > >> > > >> > A file/buffer is fine, but will lead to vendor-specific ways of > getting > >> > at the data. As I read the architecture concerning information > >> > collection, I thought this might be very useful information for a > Client > >> > to collect from the Agent. > >> > > >> > I know Joel disagrees in favor of syslog. I think syslog is okay, but > >> > only if you're receiving messages since the beginning of time (i.e., > >> > before a problem is identified). While I very well may be off base > >> > here, having the a record of what Clients did what on a particular > Agent > >> > in a vendor-agnostic way as information to be collected via I2RS > seemed > >> > reasonable. > >> > >> Just for your information: RFC 5277 defines a NETCONF extension for > >> notification delivery which supports the playback of event streams. > >> This essentially allows implementations to buffer notifications (which > >> might be syslog messages) for a certain time (or a certain volume) and > >> one can request a replay of the notifications from a given start time > >> until a certain stop time, optionally applying a filter to it. > >> > >> For debugging purposes, such a mechanism (buffering and selected and > >> filtered playback) seems a reasonable solution that is also relatively > >> easy to implement. If, however, complete accountability tracking is > >> the goal, then you need to stream all notifications to an external > >> server and you probably also need something like SYSLOG signatures > >> (RFC 5848) to be able to prove that the notification log is complete > >> etc. > >> > >> Personally, I think i2rs is likely better off with postponing work on > >> event notification logging until the primary goals of i2rs have been > >> met. For early implementors, protocols like SYSLOG likely are good > >> enough. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >> Fax: +49 421 200 3103 > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --047d7b6700c9b3082404e3fd7028 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andy,

I meant that the traceability = and syslog aspects are a 2nd order problem.

I agre= e very strongly that notifications are a primary concern. =A0That's how= clients learn
about network changes, changes affecting their state, etc. =A0I believ= e that we need a
sophisticated mechanism to filter and send just = the relevant events to the specific client.
Sending all notificat= ions to all clients would be bad in terms of scaling and security.

I don't have a fixed number for the notificat= ions per second. =A0I'm curious if others have thought
about = it?

Alia



On Thu, Aug 15, 2013 at 10:31 AM, Andy B= ierman <andy@yumaworks.com> wrote:
Hi,

We are going to run into several long-unsolved NM problems
like "standardized log files". =A0(Knowing that adding such a hug= e
task to the charter would be a mistake is the difference between
boiling an ocean or just a lake. ;-)

Notifications may not be a 2nd order problem because the
WG punted on the "I2RS broker" role. =A0Now it is up to
each I2RS Client to know that the RIB state it injected
got replaced by a higher priority client, or know a higher
priority entry was deleted and now maybe it can try again.

IMO, the notification mechanism will need to be quite
sophisticated to filter just the events relevant to a specific client.
More likely all clients will each get all notifications, creating
N fire-hoses of 'add' and 'delete' events.

At the BoF, the metric "5000 updates a second" was mentioned
as the answer to the question "what is fast-path?" =A0How many notifications per second are reasonable for I2RS?


Andy

On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas <akatlas@gmail.com> wrote:
> Juergen,
>
> Thanks for the useful information. =A0I agree that a focus on traceabi= lity is
> not an initial primary goal, but Joe's point that syslog isn't=
> vendor-agnostic is a good one too. =A0I'm not sure that I see a ne= twork
> application doing automated troubleshooting and recovery -
> but perhaps I'm insufficiently optimistic.
>
> Alia
>
>
> On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de> wrote:
>>
>> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote:=
>> > On 8/14/13 5:35 PM, Alia Atlas wrote:
>> > > I can see having it in a file for displaying or sending = - but actually
>> > > having the I2RS agent crawl through it to report the dat= a back???
>> >
>> > A file/buffer is fine, but will lead to vendor-specific ways = of getting
>> > at the data. =A0As I read the architecture concerning informa= tion
>> > collection, I thought this might be very useful information f= or a Client
>> > to collect from the Agent.
>> >
>> > I know Joel disagrees in favor of syslog. =A0I think syslog i= s okay, but
>> > only if you're receiving messages since the beginning of = time (i.e.,
>> > before a problem is identified). =A0While I very well may be = off base
>> > here, having the a record of what Clients did what on a parti= cular Agent
>> > in a vendor-agnostic way as information to be collected via I= 2RS seemed
>> > reasonable.
>>
>> Just for your information: RFC 5277 defines a NETCONF extension fo= r
>> notification delivery which supports the playback of event streams= .
>> This essentially allows implementations to buffer notifications (w= hich
>> might be syslog messages) for a certain time (or a certain volume)= and
>> one can request a replay of the notifications from a given start t= ime
>> until a certain stop time, optionally applying a filter to it.
>>
>> For debugging purposes, such a mechanism (buffering and selected a= nd
>> filtered playback) seems a reasonable solution that is also relati= vely
>> easy to implement. If, however, complete accountability tracking i= s
>> the goal, then you need to stream all notifications to an external=
>> server and you probably also need something like SYSLOG signatures=
>> (RFC 5848) to be able to prove that the notification log is comple= te
>> etc.
>>
>> Personally, I think i2rs is likely better off with postponing work= on
>> event notification logging until the primary goals of i2rs have be= en
>> met. For early implementors, protocols like SYSLOG likely are good=
>> enough.
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen= gGmbH
>> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Breme= n, Germany
>> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
>
>
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

--047d7b6700c9b3082404e3fd7028-- From andy@yumaworks.com Thu Aug 15 09:00:30 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2989B11E81DF for ; Thu, 15 Aug 2013 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2WjV5aKJFPx for ; Thu, 15 Aug 2013 09:00:24 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id A78B511E81AB for ; Thu, 15 Aug 2013 09:00:21 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so880741pab.6 for ; Thu, 15 Aug 2013 09:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yl45FEBOPwzL+02O9gbxtArZg0G/JAP441Ia+F/dXUo=; b=bbGJNFHKTWQieiMyj4+mump/GKfa5k1K1fduCT/NahgI1VaM7h85R4NXhIJIv2jgf7 /7CGfbp1jxsEhtZ6zY2I//yAxW83I3iIEUF+QFlelkVuU0Zd89IPt8vrxfWAI0y8NyCH /lKSl+uomILnkcijrd0tpbJXrpuzzlcv+bBSaqZe5udZ1l4zpdsHY2OMGs/fCNpef+uJ Z6AV41qGCaIDYQ1ZFdnp2Rf6nFpPoDpiHUXtj65/DKfxqHoutPqY5K7Ezo5IPcSA398t thmiW0NxUTlNi62eIGLG9F/D2ZDLAkVi06GIiGM+WAYk2LZSGEAc2DPKjsHnxWgXZcwj /zjw== X-Gm-Message-State: ALoCoQlkORxle3uygCIoS16lL5NjGhg+iRBSoU+0pvSvmxKXqSPJpKJZnTjfgcEVWQQuAxF1ZbQD MIME-Version: 1.0 X-Received: by 10.66.253.40 with SMTP id zx8mr7833639pac.71.1376582421195; Thu, 15 Aug 2013 09:00:21 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Thu, 15 Aug 2013 09:00:21 -0700 (PDT) In-Reply-To: References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> Date: Thu, 15 Aug 2013 09:00:21 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Carlos Pignataro , Joe Marcus Clarke , Juergen Schoenwaelder , "Joel M. Halpern" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:00:31 -0000 Hi, Maybe it won't be that hard to automatically setup filters for common use-cases. E.g., if the 'inject' operation had parameters like 'notify-when-ready' and 'notify-if-bounced', then the server can send those notifications (just to that client) if the "inject" fails or gets deleted later, for the specific data entry. Andy On Thu, Aug 15, 2013 at 7:39 AM, Alia Atlas wrote: > Hi Andy, > > I meant that the traceability and syslog aspects are a 2nd order problem. > > I agree very strongly that notifications are a primary concern. That's how > clients learn > about network changes, changes affecting their state, etc. I believe that > we need a > sophisticated mechanism to filter and send just the relevant events to the > specific client. > Sending all notifications to all clients would be bad in terms of scaling > and security. > > I don't have a fixed number for the notifications per second. I'm curious > if others have thought > about it? > > Alia > > > > On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman wrote: >> >> Hi, >> >> We are going to run into several long-unsolved NM problems >> like "standardized log files". (Knowing that adding such a huge >> task to the charter would be a mistake is the difference between >> boiling an ocean or just a lake. ;-) >> >> Notifications may not be a 2nd order problem because the >> WG punted on the "I2RS broker" role. Now it is up to >> each I2RS Client to know that the RIB state it injected >> got replaced by a higher priority client, or know a higher >> priority entry was deleted and now maybe it can try again. >> >> IMO, the notification mechanism will need to be quite >> sophisticated to filter just the events relevant to a specific client. >> More likely all clients will each get all notifications, creating >> N fire-hoses of 'add' and 'delete' events. >> >> At the BoF, the metric "5000 updates a second" was mentioned >> as the answer to the question "what is fast-path?" How many >> notifications per second are reasonable for I2RS? >> >> >> Andy >> >> On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas wrote: >> > Juergen, >> > >> > Thanks for the useful information. I agree that a focus on traceability >> > is >> > not an initial primary goal, but Joe's point that syslog isn't >> > vendor-agnostic is a good one too. I'm not sure that I see a network >> > application doing automated troubleshooting and recovery - >> > but perhaps I'm insufficiently optimistic. >> > >> > Alia >> > >> > >> > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder >> > wrote: >> >> >> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: >> >> > On 8/14/13 5:35 PM, Alia Atlas wrote: >> >> > > I can see having it in a file for displaying or sending - but >> >> > > actually >> >> > > having the I2RS agent crawl through it to report the data back??? >> >> > >> >> > A file/buffer is fine, but will lead to vendor-specific ways of >> >> > getting >> >> > at the data. As I read the architecture concerning information >> >> > collection, I thought this might be very useful information for a >> >> > Client >> >> > to collect from the Agent. >> >> > >> >> > I know Joel disagrees in favor of syslog. I think syslog is okay, >> >> > but >> >> > only if you're receiving messages since the beginning of time (i.e., >> >> > before a problem is identified). While I very well may be off base >> >> > here, having the a record of what Clients did what on a particular >> >> > Agent >> >> > in a vendor-agnostic way as information to be collected via I2RS >> >> > seemed >> >> > reasonable. >> >> >> >> Just for your information: RFC 5277 defines a NETCONF extension for >> >> notification delivery which supports the playback of event streams. >> >> This essentially allows implementations to buffer notifications (which >> >> might be syslog messages) for a certain time (or a certain volume) and >> >> one can request a replay of the notifications from a given start time >> >> until a certain stop time, optionally applying a filter to it. >> >> >> >> For debugging purposes, such a mechanism (buffering and selected and >> >> filtered playback) seems a reasonable solution that is also relatively >> >> easy to implement. If, however, complete accountability tracking is >> >> the goal, then you need to stream all notifications to an external >> >> server and you probably also need something like SYSLOG signatures >> >> (RFC 5848) to be able to prove that the notification log is complete >> >> etc. >> >> >> >> Personally, I think i2rs is likely better off with postponing work on >> >> event notification logging until the primary goals of i2rs have been >> >> met. For early implementors, protocols like SYSLOG likely are good >> >> enough. >> >> >> >> /js >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> >> Fax: +49 421 200 3103 >> > >> > >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> > > > From akatlas@gmail.com Thu Aug 15 09:06:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168011E8165 for ; Thu, 15 Aug 2013 09:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8QF4ZdSovPC for ; Thu, 15 Aug 2013 09:06:40 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4900E21E8084 for ; Thu, 15 Aug 2013 09:06:36 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so1023113obc.40 for ; Thu, 15 Aug 2013 09:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bdd6EhxU6OmPiv+I/x0NfLHFVmtLrg0pznDLDdeMssM=; b=VWOflREtmcF6eknvgOKXZSEfazWrb4zOE5nhhEUDxz+No+/umo4xxdp9B1+Oc5q9L8 WH440j7U5gwylTOIKdzwHQzUfZsJP/6J3RXnZ3wwM9aqDwV9GWKUIQXkjAbnrTSt7o6n FgoTcWGmKeafAiYYkBU3nhKfvXF1Wew5nYRyYAnSDRb+QalFxzGomHi8cIzWh4UsD8n6 KAwsu7aZZBIEY78oiz1mmh0WQ02CSQxxpW/T/A2wP11Q7y6KrhSfWzNz4KLA9fgJVI0o lljdc62QKLAHIBggV6cpmXfpxsUtXkLj6ufytvOnhnjw3o3MQOtV2AkUspTUp82eNVwT cWow== MIME-Version: 1.0 X-Received: by 10.182.60.70 with SMTP id f6mr1317334obr.61.1376582795750; Thu, 15 Aug 2013 09:06:35 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 09:06:35 -0700 (PDT) In-Reply-To: References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> Date: Thu, 15 Aug 2013 12:06:35 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b624a3e8b74da04e3fea8e3 Cc: "i2rs@ietf.org" , Carlos Pignataro , Joe Marcus Clarke , Juergen Schoenwaelder , "Joel M. Halpern" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:06:41 -0000 --047d7b624a3e8b74da04e3fea8e3 Content-Type: text/plain; charset=ISO-8859-1 Exactly - we need to give some real thought to the notifications and how the filtering is set up. There's also a distinction between event notifications and information streams, even though subscription may be similar. For notifications, we have ideas such as: register for a notification when state written by client X is changed register for a notification when a particular state is changed notify when route is installed in FIB notify if interface utilization is over high-water threshold or under low-water threshold For info streams, one could have: subscribe to OSPF peer up/downs subscribe to route changes (perhaps by protocol or within a prefix range) There's the question of describing the desirable notifications and info streams - and then figuring out how to support them in protocol mechanisms (and the practicality for a real implementation). Alia On Thu, Aug 15, 2013 at 12:00 PM, Andy Bierman wrote: > Hi, > > Maybe it won't be that hard to automatically setup filters > for common use-cases. E.g., if the 'inject' operation > had parameters like 'notify-when-ready' and 'notify-if-bounced', > then the server can send those notifications (just to that client) > if the "inject" fails or gets deleted later, for the specific data entry. > > > Andy > > > > > On Thu, Aug 15, 2013 at 7:39 AM, Alia Atlas wrote: > > Hi Andy, > > > > I meant that the traceability and syslog aspects are a 2nd order problem. > > > > I agree very strongly that notifications are a primary concern. That's > how > > clients learn > > about network changes, changes affecting their state, etc. I believe > that > > we need a > > sophisticated mechanism to filter and send just the relevant events to > the > > specific client. > > Sending all notifications to all clients would be bad in terms of scaling > > and security. > > > > I don't have a fixed number for the notifications per second. I'm > curious > > if others have thought > > about it? > > > > Alia > > > > > > > > On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman > wrote: > >> > >> Hi, > >> > >> We are going to run into several long-unsolved NM problems > >> like "standardized log files". (Knowing that adding such a huge > >> task to the charter would be a mistake is the difference between > >> boiling an ocean or just a lake. ;-) > >> > >> Notifications may not be a 2nd order problem because the > >> WG punted on the "I2RS broker" role. Now it is up to > >> each I2RS Client to know that the RIB state it injected > >> got replaced by a higher priority client, or know a higher > >> priority entry was deleted and now maybe it can try again. > >> > >> IMO, the notification mechanism will need to be quite > >> sophisticated to filter just the events relevant to a specific client. > >> More likely all clients will each get all notifications, creating > >> N fire-hoses of 'add' and 'delete' events. > >> > >> At the BoF, the metric "5000 updates a second" was mentioned > >> as the answer to the question "what is fast-path?" How many > >> notifications per second are reasonable for I2RS? > >> > >> > >> Andy > >> > >> On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas wrote: > >> > Juergen, > >> > > >> > Thanks for the useful information. I agree that a focus on > traceability > >> > is > >> > not an initial primary goal, but Joe's point that syslog isn't > >> > vendor-agnostic is a good one too. I'm not sure that I see a network > >> > application doing automated troubleshooting and recovery - > >> > but perhaps I'm insufficiently optimistic. > >> > > >> > Alia > >> > > >> > > >> > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder > >> > wrote: > >> >> > >> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > >> >> > On 8/14/13 5:35 PM, Alia Atlas wrote: > >> >> > > I can see having it in a file for displaying or sending - but > >> >> > > actually > >> >> > > having the I2RS agent crawl through it to report the data back??? > >> >> > > >> >> > A file/buffer is fine, but will lead to vendor-specific ways of > >> >> > getting > >> >> > at the data. As I read the architecture concerning information > >> >> > collection, I thought this might be very useful information for a > >> >> > Client > >> >> > to collect from the Agent. > >> >> > > >> >> > I know Joel disagrees in favor of syslog. I think syslog is okay, > >> >> > but > >> >> > only if you're receiving messages since the beginning of time > (i.e., > >> >> > before a problem is identified). While I very well may be off base > >> >> > here, having the a record of what Clients did what on a particular > >> >> > Agent > >> >> > in a vendor-agnostic way as information to be collected via I2RS > >> >> > seemed > >> >> > reasonable. > >> >> > >> >> Just for your information: RFC 5277 defines a NETCONF extension for > >> >> notification delivery which supports the playback of event streams. > >> >> This essentially allows implementations to buffer notifications > (which > >> >> might be syslog messages) for a certain time (or a certain volume) > and > >> >> one can request a replay of the notifications from a given start time > >> >> until a certain stop time, optionally applying a filter to it. > >> >> > >> >> For debugging purposes, such a mechanism (buffering and selected and > >> >> filtered playback) seems a reasonable solution that is also > relatively > >> >> easy to implement. If, however, complete accountability tracking is > >> >> the goal, then you need to stream all notifications to an external > >> >> server and you probably also need something like SYSLOG signatures > >> >> (RFC 5848) to be able to prove that the notification log is complete > >> >> etc. > >> >> > >> >> Personally, I think i2rs is likely better off with postponing work on > >> >> event notification logging until the primary goals of i2rs have been > >> >> met. For early implementors, protocols like SYSLOG likely are good > >> >> enough. > >> >> > >> >> /js > >> >> > >> >> -- > >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >> >> Fax: +49 421 200 3103 > >> > > >> > > >> > > >> > _______________________________________________ > >> > i2rs mailing list > >> > i2rs@ietf.org > >> > https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > --047d7b624a3e8b74da04e3fea8e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Exactly - we need to give some real thought to the notific= ations and how the filtering is set up. =A0There's also a distinction b= etween event notifications and information streams, even though subscriptio= n may be similar.

For notifications, we have ideas such as:
=A0 =A0 = register for a notification when state written by client X is changed
=
=A0 =A0 register for a notification when a particular state is changed=
=A0 =A0 notify when route is installed in FIB
=A0 =A0 notify= if interface utilization is over high-water threshold or under low-water t= hreshold

For info streams, one could have:
=A0 =A0 subscribe to OSPF peer up/downs
=A0 =A0 subscribe to route changes (perhaps by protocol or within a pr= efix range)
=A0
There's the question of describing = the desirable notifications and info streams - and then figuring out how to= support them in protocol mechanisms (and the practicality for a real imple= mentation).

Alia


On Thu, Aug 15, 2013 at 12:00 PM, Andy Bierman <an= dy@yumaworks.com> wrote:
Hi,

Maybe it won't be that hard to automatically setup filters
for common use-cases. E.g., if the 'inject' operation
had parameters like 'notify-when-ready' and 'notify-if-bounced&= #39;,
then the server can send those notifications (just to that client)
if the "inject" fails or gets deleted later, for the specific dat= a entry.


Andy




On Thu, Aug 15, 2013 at 7:39 AM, Alia Atlas <akatlas@gmail.com> wrote:
> Hi Andy,
>
> I meant that the traceability and syslog aspects are a 2nd order probl= em.
>
> I agree very strongly that notifications are a primary concern. =A0Tha= t's how
> clients learn
> about network changes, changes affecting their state, etc. =A0I believ= e that
> we need a
> sophisticated mechanism to filter and send just the relevant events to= the
> specific client.
> Sending all notifications to all clients would be bad in terms of scal= ing
> and security.
>
> I don't have a fixed number for the notifications per second. =A0I= 'm curious
> if others have thought
> about it?
>
> Alia
>
>
>
> On Thu, Aug 15, 2013 at 10:31 AM, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> Hi,
>>
>> We are going to run into several long-unsolved NM problems
>> like "standardized log files". =A0(Knowing that adding s= uch a huge
>> task to the charter would be a mistake is the difference between >> boiling an ocean or just a lake. ;-)
>>
>> Notifications may not be a 2nd order problem because the
>> WG punted on the "I2RS broker" role. =A0Now it is up to<= br> >> each I2RS Client to know that the RIB state it injected
>> got replaced by a higher priority client, or know a higher
>> priority entry was deleted and now maybe it can try again.
>>
>> IMO, the notification mechanism will need to be quite
>> sophisticated to filter just the events relevant to a specific cli= ent.
>> More likely all clients will each get all notifications, creating<= br> >> N fire-hoses of 'add' and 'delete' events.
>>
>> At the BoF, the metric "5000 updates a second" was menti= oned
>> as the answer to the question "what is fast-path?" =A0Ho= w many
>> notifications per second are reasonable for I2RS?
>>
>>
>> Andy
>>
>> On Thu, Aug 15, 2013 at 7:10 AM, Alia Atlas <akatlas@gmail.com> wrote:
>> > Juergen,
>> >
>> > Thanks for the useful information. =A0I agree that a focus on= traceability
>> > is
>> > not an initial primary goal, but Joe's point that syslog = isn't
>> > vendor-agnostic is a good one too. =A0I'm not sure that I= see a network
>> > application doing automated troubleshooting and recovery - >> > but perhaps I'm insufficiently optimistic.
>> >
>> > Alia
>> >
>> >
>> > On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder
>> > <j= .schoenwaelder@jacobs-university.de> wrote:
>> >>
>> >> On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clar= ke wrote:
>> >> > On 8/14/13 5:35 PM, Alia Atlas wrote:
>> >> > > I can see having it in a file for displaying or= sending - but
>> >> > > actually
>> >> > > having the I2RS agent crawl through it to repor= t the data back???
>> >> >
>> >> > A file/buffer is fine, but will lead to vendor-speci= fic ways of
>> >> > getting
>> >> > at the data. =A0As I read the architecture concernin= g information
>> >> > collection, I thought this might be very useful info= rmation for a
>> >> > Client
>> >> > to collect from the Agent.
>> >> >
>> >> > I know Joel disagrees in favor of syslog. =A0I think= syslog is okay,
>> >> > but
>> >> > only if you're receiving messages since the begi= nning of time (i.e.,
>> >> > before a problem is identified). =A0While I very wel= l may be off base
>> >> > here, having the a record of what Clients did what o= n a particular
>> >> > Agent
>> >> > in a vendor-agnostic way as information to be collec= ted via I2RS
>> >> > seemed
>> >> > reasonable.
>> >>
>> >> Just for your information: RFC 5277 defines a NETCONF ext= ension for
>> >> notification delivery which supports the playback of even= t streams.
>> >> This essentially allows implementations to buffer notific= ations (which
>> >> might be syslog messages) for a certain time (or a certai= n volume) and
>> >> one can request a replay of the notifications from a give= n start time
>> >> until a certain stop time, optionally applying a filter t= o it.
>> >>
>> >> For debugging purposes, such a mechanism (buffering and s= elected and
>> >> filtered playback) seems a reasonable solution that is al= so relatively
>> >> easy to implement. If, however, complete accountability t= racking is
>> >> the goal, then you need to stream all notifications to an= external
>> >> server and you probably also need something like SYSLOG s= ignatures
>> >> (RFC 5848) to be able to prove that the notification log = is complete
>> >> etc.
>> >>
>> >> Personally, I think i2rs is likely better off with postpo= ning work on
>> >> event notification logging until the primary goals of i2r= s have been
>> >> met. For early implementors, protocols like SYSLOG likely= are good
>> >> enough.
>> >>
>> >> /js
>> >>
>> >> --
>> >> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs Universi= ty Bremen gGmbH
>> >> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28= 759 Bremen, Germany
>> >> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-unive= rsity.de/>
>> >
>> >
>> >
>> > _______________________________________________
>> > i2rs mailing list
>> > i2rs@ietf.org
>> > https://www.ietf.org/mailman/listinfo/i2rs
>> >
>
>

--047d7b624a3e8b74da04e3fea8e3-- From akatlas@gmail.com Thu Aug 15 12:20:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E921F9FF9 for ; Thu, 15 Aug 2013 12:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnNia+KbwR8h for ; Thu, 15 Aug 2013 12:20:30 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE7711E80AD for ; Thu, 15 Aug 2013 12:20:27 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so1265638oah.6 for ; Thu, 15 Aug 2013 12:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=295mLwz3e5SAErYnMALNRAqiga3GGO3YtuB9MgAUUT4=; b=pIhTbwRD/vKujkooXgdUbgYMyNJPLa9IHA7jawnDk8g+uNX0Yf8QUh0l4Qr/kN2rN5 +kFTBEvtg1OsZHYupHFUgi9QUwVaVxJIg6rw/lMvk7QllMVcVisseOeqShnS878S/pJN WEAVLwdoRManOZmhVfJEXeZoqa0ZICqG1xprL9w4p3MBsv3YoJ4HyrGmaCdY8y67guFg 3qVdIX8EG6zutR1k0I80JEzAjhIdsTUvtw/fcf/fweGW/26nJaxrcYcEE0BdKbpGJ3Ok 7upKol1Qxoh6dqb8yr1mCWiYSH3sSYkpMj0lpQbIiDDrglV7wfn9pFZnaKoJRXyqrWSd c9uA== MIME-Version: 1.0 X-Received: by 10.60.60.167 with SMTP id i7mr2280127oer.58.1376594424994; Thu, 15 Aug 2013 12:20:24 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 12:20:24 -0700 (PDT) Date: Thu, 15 Aug 2013 15:20:24 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e0158bab4b3a26704e4015d1e Subject: [i2rs] Results of WG Adoption Call: draft-nitinb-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:20:31 -0000 --089e0158bab4b3a26704e4015d1e Content-Type: text/plain; charset=ISO-8859-1 There was a lot of good discussion and comments on this draft. When the next version, addressing that discussion, is published, Ed and I will ask if there is any opposition to adopting that updated draft as a WG draft. Thanks for the good discussions. Alia --089e0158bab4b3a26704e4015d1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There was a lot of good discussion and comments on this dr= aft.=A0
When the next version, addressing that discussion, is published= ,=A0
Ed and I will ask if there is any opposition to adopting tha= t updated
draft as a WG draft.

Thanks for the good disc= ussions.

Alia
--089e0158bab4b3a26704e4015d1e-- From akatlas@gmail.com Thu Aug 15 12:23:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2889D11E816F for ; Thu, 15 Aug 2013 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BS8HQIb6I5J for ; Thu, 15 Aug 2013 12:23:20 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9911E8167 for ; Thu, 15 Aug 2013 12:23:20 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so1304093oag.29 for ; Thu, 15 Aug 2013 12:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gCZj1VgdQ+yWakfwMJXYB/PWRy+PkvivJSqHFLKwVsE=; b=AfukQCZVqC/ackKjhMS0jMckVR/J73nemUSNzl6njpDUHfG1zXObWHsDckSuqMwkHD ca5WY3RWq9bDPnnEPFLC8djl4pAHlXdCpirWB1sSD+OKWC7rvxebgp+0bTMuuOIUa+bm tJipDgHDcA8Q+7cIAJN6Unn+jhYcwYBF/6Cn8YOkFG3qs6CH5TmERevb25+Ds/bcKbBD aMLj2gi+Lxm9+KBZMG3/Q0FJpAxskNwcydReC5/wREW3Ozj5aSumK3rLt8E+rErBUUEj JtQN2VJ3Nltyxa0mbwQO1i+DqesdlH+lRcCcHX4vY5x3YRQdf4OE86mRup9S0G0XNTlU 51oA== MIME-Version: 1.0 X-Received: by 10.182.237.107 with SMTP id vb11mr62198obc.84.1376594599858; Thu, 15 Aug 2013 12:23:19 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Thu, 15 Aug 2013 12:23:19 -0700 (PDT) Date: Thu, 15 Aug 2013 15:23:19 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff1cd6a1fdda604e4016897 Subject: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:23:21 -0000 --e89a8ff1cd6a1fdda604e4016897 Content-Type: text/plain; charset=ISO-8859-1 There was a lot of good discussion about this draft. There were significant concerns about what parts should remain in the draft (e.g. configuration related) and what to do with the BGP-related uses cases in draft-white-i2rs-use-case. Ed and I look forward to seeing the updated draft that resolves that discussion. When that updated draft is published, we will issue another call for WG adoption. Thanks for the reviews and discussion, Alia --e89a8ff1cd6a1fdda604e4016897 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There was a lot of good discussion about this draft. =A0Th= ere were significant concerns about what parts should remain in the draft (= e.g. configuration related) and what to do with the BGP-related uses cases = in draft-white-i2rs-use-case.

Ed and I look forward to seeing the updated draft that resol= ves that discussion. =A0When that updated draft is published, we will issue= another call for WG adoption.

Thanks for the revi= ews and discussion,
Alia
--e89a8ff1cd6a1fdda604e4016897-- From russw@riw.us Thu Aug 15 16:37:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A011E814D for ; Thu, 15 Aug 2013 16:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0c0NG+gLud4 for ; Thu, 15 Aug 2013 16:37:12 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF711E80D7 for ; Thu, 15 Aug 2013 16:37:12 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VA76N-0004Oi-Ax; Thu, 15 Aug 2013 16:37:11 -0700 From: "Russ White" To: "'Alia Atlas'" , References: In-Reply-To: Date: Thu, 15 Aug 2013 19:37:12 -0400 Message-ID: <002c01ce9a10$5f25cc70$1d716550$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLZBMG/tKUNc4DyRDueqD7ovIrl95eCFt7Q Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:37:20 -0000 > There was a lot of good discussion about this draft. There were significant > concerns about what parts should remain in the draft (e.g. > configuration related) and what to do with the BGP-related uses cases in > draft-white-i2rs-use-case. The first question should be --do we want to call it a RIB or general use cases draft, or specifically focus on BGP? I'll see if I can get Keyur to talk to me about merging the relevant parts... :-) Russ From keyupate@cisco.com Thu Aug 15 18:07:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1959F11E8213 for ; Thu, 15 Aug 2013 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq0HbTflRMMQ for ; Thu, 15 Aug 2013 18:07:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F057111E822C for ; Thu, 15 Aug 2013 18:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=787; q=dns/txt; s=iport; t=1376615220; x=1377824820; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=svKvZyNTNSxIyXl8gRD8Tqj91FT/KoD9azASKIcovxU=; b=L+fwa9k5lf+AwLnv9mYlfUgIFsMUCJCLOvtJjAc+Pg1LQ6AjYmBMhn/Y Bjy94JHKNP6x5wvkb+WszBQeLZEJzk15fudLfLYFz8YthtJOPyxfnpIfL YuuX/+mbQqiu7F7DSNQ+fZ31cUnfy4cbiDQpA3wTCiYRjfWri+i7BzWgH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFABd6DVKtJV2a/2dsb2JhbABbgwY1UIJSvEOBJBZ0giQBAQEDAQEBATc0HQEIIhQ3CyUCBAESCIgCBgy6BwSQHziDG3cDqTaDG4Iq X-IronPort-AV: E=Sophos;i="4.89,889,1367971200"; d="scan'208";a="247964318" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 16 Aug 2013 01:06:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7G16rXt001543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 01:06:53 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.187]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 20:06:53 -0500 From: "Keyur Patel (keyupate)" To: Russ White , "'Alia Atlas'" , "i2rs@ietf.org" Thread-Topic: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases Thread-Index: AQHOmhzkpxfh22pVVk2h5lRsIqPr3g== Date: Fri, 16 Aug 2013 01:06:52 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> In-Reply-To: <002c01ce9a10$5f25cc70$1d716550$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.101.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <14D7E6C6CA29144F8F0261A13E32C1A3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:07:05 -0000 Russ: IMHO it would be best to keep BGP specific use cases into a separate draft. Best Regards, Keyur On 8/15/13 4:37 PM, "Russ White" wrote: > >> There was a lot of good discussion about this draft. There were >significant >> concerns about what parts should remain in the draft (e.g. >> configuration related) and what to do with the BGP-related uses cases in >> draft-white-i2rs-use-case. > >The first question should be --do we want to call it a RIB or general use >cases draft, or specifically focus on BGP? I'll see if I can get Keyur to >talk to me about merging the relevant parts... > >:-) > >Russ > > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Thu Aug 15 18:20:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747011E8213 for ; Thu, 15 Aug 2013 18:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldyf-0vwkJ06 for ; Thu, 15 Aug 2013 18:20:27 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF521F9A57 for ; Thu, 15 Aug 2013 18:20:23 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VA8iD-0007cg-L2; Thu, 15 Aug 2013 18:20:22 -0700 From: "Russ White" To: "'Keyur Patel \(keyupate\)'" , "'Alia Atlas'" , References: <002c01ce9a10$5f25cc70$1d716550$@riw.us> <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> Date: Thu, 15 Aug 2013 21:20:21 -0400 Message-ID: <007401ce9a1e$c8aed340$5a0c79c0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKAzhJ12mrO6x8SKcYNuKCIa2z885gyoHgQ Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:20:33 -0000 > IMHO it would be best to keep BGP specific use cases into a separate draft. Okay --so... That leaves us with the next question --the use cases that aren't BGP centric --do we try and continue a draft with just those one or two, or... ?? I don't really understand what the situation is at this point. My understanding of the discussion on list and in person from way back were that the draft I was editing and the BGP use cases draft were going to be merged, not that one was going to subsume the other completely, leaving the remainder out of the picture entirely... In fact, the WG originally decided to only use one use cases draft as it's basis for work until the use cases in that first draft were covered by requirements/etc. It now sounds like we've changed that direction completely, and we're back to boiling the ocean. I'm a bit confused at this point about when those decisions were changed, and how we intend to proceed. :-) Russ From shares@ndzh.com Thu Aug 15 18:23:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A25011E823A for ; Thu, 15 Aug 2013 18:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEnVFfh3+4Ar for ; Thu, 15 Aug 2013 18:23:48 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 02AFA11E8233 for ; Thu, 15 Aug 2013 18:23:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.50; From: "Susan Hares" To: "'Keyur Patel \(keyupate\)'" , "'Russ White'" , "'Alia Atlas'" , References: <002c01ce9a10$5f25cc70$1d716550$@riw.us> <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> In-Reply-To: <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> Date: Thu, 15 Aug 2013 21:23:37 -0400 Message-ID: <013001ce9a1f$3c6c3070$b5449150$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAzhJ12mrO6x8SKcYNuKCIa2z885gyokHw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 01:23:52 -0000 Keyur: Can you give a bit more detail on this point? Sue -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Keyur Patel (keyupate) Sent: Thursday, August 15, 2013 9:07 PM To: Russ White; 'Alia Atlas'; i2rs@ietf.org Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases Russ: IMHO it would be best to keep BGP specific use cases into a separate draft. Best Regards, Keyur On 8/15/13 4:37 PM, "Russ White" wrote: > >> There was a lot of good discussion about this draft. There were >significant >> concerns about what parts should remain in the draft (e.g. >> configuration related) and what to do with the BGP-related uses cases >> in draft-white-i2rs-use-case. > >The first question should be --do we want to call it a RIB or general >use cases draft, or specifically focus on BGP? I'll see if I can get >Keyur to talk to me about merging the relevant parts... > >:-) > >Russ > > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Fri Aug 16 05:29:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A111E81A1 for ; Fri, 16 Aug 2013 05:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh2cYHvwfKf1 for ; Fri, 16 Aug 2013 05:29:08 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66011E8102 for ; Fri, 16 Aug 2013 05:29:08 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAJ9O-0006Hi-Ka; Fri, 16 Aug 2013 05:29:06 -0700 From: "Russ White" To: "'Keyur Patel \(keyupate\)'" , "'Alia Atlas'" , References: <002c01ce9a10$5f25cc70$1d716550$@riw.us> <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> In-Reply-To: Date: Fri, 16 Aug 2013 08:29:08 -0400 Message-ID: <01ef01ce9a7c$35570280$a0050780$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG4ccFKqIbkfseLSde7M0hLhuHKegKAzhJ1AiSKoLiZnuh1YA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:29:13 -0000 > I'm a bit confused at this point about when those decisions were changed, > and how we intend to proceed. I have one possible suggestion, after looking at the structure of the drafts again. What I think we might want to do is to pull the bgp use cases from draft-white to bolster the bgp use cases draft, moving the bgp use cases draft to an editor/contributor format (since it already has a lot of co's). The remaining use cases can be put into a rib uses cases draft, where we can collect all the various "routing protocol agnostic" use cases. Again, we could move this to editor/contributor --I'll be happy to hold the editor baton for this new draft. There may be some question about what fits where (are all the bgp uses really limited to bgp? Do we want a separate overlay use cases, or should these fall into the protocol related draft they work with?), but I think this is a workable model to get all the use cases organized into a reasonable set of drafts that can be added to, etc., until the WG gets to the point of having a 'first set' of use cases on the table. After this initial batch is actually published, then it's going to be better to continue with individual drafts for individual use cases, rather than bis'ing this set, I think. Thoughts? Russ From russw@riw.us Fri Aug 16 05:44:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E619D11E8270 for ; Fri, 16 Aug 2013 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95qYV6CHuxCD for ; Fri, 16 Aug 2013 05:44:45 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F111E8131 for ; Fri, 16 Aug 2013 05:44:44 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAJOT-00073D-Qc; Fri, 16 Aug 2013 05:44:42 -0700 From: "Russ White" To: "'Alia Atlas'" , "'Andy Bierman'" References: <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> In-Reply-To: Date: Fri, 16 Aug 2013 08:44:43 -0400 Message-ID: <01f301ce9a7e$62b94970$282bdc50$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGZxMvokjFoJNdsVeLBwp80l8kQfQH+31MmAdAWZrQA+TXslwJg1u7RAgyd4pgChSWXGgJeTyjrAc0I5L0CfKHg4gHA/FyeAdGBpU0Baif7VQJwCQjTAmO90zgCeIbeqZkMEh8g Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "'Joel M. Halpern'" , i2rs@ietf.org, 'Joe Marcus Clarke' , 'Juergen Schoenwaelder' , 'Carlos Pignataro' Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:44:51 -0000 > register for a notification when state written by client X is changed > register for a notification when a particular state is changed > notify when route is installed in FIB > notify if interface utilization is over high-water threshold or under low- > water threshold The problem, I think, is that we're still not scoped narrowly enough. This could well be a set of requirements for a network management system as much as a set of requirements for an SDN... If we're going to be a new management system, should we move this WG to the management area, and be done with it? I think we need to be a little careful about what problems we take on from day one, so we can really narrow down the work we're actually trying to do, verses what others are already doing --I don't think we should make our goal, "we want to be a faster NETCONF." So, to limit these: 1. So long as the state being written is _routing_ state. 2. So long as the state being changed is _routing_ state. 3. This must include when your route is overwritten by another process. 4. Do we really want to consider everything measurable about an interface a part of the "routing system," from day one? The fourth one is particularly bothersome. I can see where interface state is part of the "routing state," in some broad sense --in reality, though, everything that goes on on a "router" or a "switch" is technically part of the "routing state," including memory fragmentation, memory utilization, local storage read and write speeds, processor temperature, and even the color of the box. These things are "routers" and "switches," so everything they do somehow relates to either "routing" or "switching." Hence, we need to intentionally underclaim in our scope for the moment, focusing on a few small areas. We tried to do this with the use cases, but that's not working so well, so maybe we need to limit our scope in more intentional ways, like saying, "while we understand that interface state other than simple up/down can be construed as part of the routing system, we're simply not going to deal with that right now, because just dealing with up/down, in combination with all the other stuff we're trying to deal with, is enough to chew on for about the next 5 years already." If we don't intentionally scope ourselves, we're going to end up in the drink --a WG that simply churns on lots of big plans, but won't ever be actually implemented in any useful way, because no-one is going to build yet another network management system into their boxes alongside the fourteen or fifteen they already have. At least that's my 2c. :-) Russ From russw@riw.us Fri Aug 16 05:52:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3E511E8131 for ; Fri, 16 Aug 2013 05:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAUva2mdAWVd for ; Fri, 16 Aug 2013 05:52:16 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D89D11E8110 for ; Fri, 16 Aug 2013 05:52:16 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAJVn-0007Sk-Do; Fri, 16 Aug 2013 05:52:15 -0700 From: "Russ White" To: "'Alia Atlas'" , "'Joe Marcus Clarke'" References: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> <520BB081.6010400@cisco.com> <520BBE7D.4050604@joelhalpern.com> <520BC1FC.4020109@cisco.com> <520BC349.5070206@joelhalpern.com> <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <520C06D5.4090101@cisco.com> In-Reply-To: Date: Fri, 16 Aug 2013 08:52:16 -0400 Message-ID: <01fe01ce9a7f$71172770$53457650$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFSbaQ68PEOf8UVEuF6MGwkLKAuKgG122U0AZnEy+gB/t9TJgHQFma0APk17JcCYNbu0QIMneKYAoUllxoCXk8o6wHNCOS9Anyh4OICKRVCVgGmQqfhAPZiX+GZvGENEA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Carlos Pignataro' Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:52:24 -0000 > First, I hear and agree with Juergen's point that this is a second order > problem. Still, if there are those interested in working on it and documenting > what would be desirable, a bit of discussion isn't a bad thing. +1 > Second, the minimum necessary seems to be an info model describing what > should be saved so that the files can be structured. If the I2RS data structures "on the wire," are efficient, atomic, and built in such a way as to invite extension where needed, why not just make the structure, "save off the tlvs as you send and receive, so they can be reparsed according to the same set of rules by some other process later?" In other words, do we need another format for the same data, if there's already one in place for on the wire use? Just a thought... > Third, we have the idea of multiple transports and transport channels in I2RS. +1 --we're already driving enough complexity into this thing... Too much, honestly. Russ From russw@riw.us Fri Aug 16 05:56:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73211E8110 for ; Fri, 16 Aug 2013 05:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCzgKmqZwXMb for ; Fri, 16 Aug 2013 05:56:19 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A011E8119 for ; Fri, 16 Aug 2013 05:56:18 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAJZR-0007eK-Sl; Fri, 16 Aug 2013 05:56:02 -0700 From: "Russ White" To: "'Alia Atlas'" , "'Joe Marcus Clarke'" References: In-Reply-To: Date: Fri, 16 Aug 2013 08:56:03 -0400 Message-ID: <020001ce9a7f$f8125c40$e83714c0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL/dwswimUnrNed5chPEDjTmPsQvJc2EPow Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Joel Halpern' , lberger@labn.net Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:56:25 -0000 > The idea of having the I2RS Agent store all the operations and attribution > done is not appealing. Why not? If the data model on the wire is efficient, then the only thing left to add efficiency to the file sizes would be aggregating the information somehow. It seems, to me, that it's easiest just to store the data in the on-the-wire tlv format, and have locally configurable filters about what to save or not, etc. These might want to be really intelligent filters, like, "only save the last five instances of this specific state change," rather than, "save the last four hundred state changes of any type," but the WG doesn't need to address these filters at all --they would be implementation specific. Russ From jmh@joelhalpern.com Fri Aug 16 06:12:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4D11E8190 for ; Fri, 16 Aug 2013 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGJOAJbq55+x for ; Fri, 16 Aug 2013 06:12:21 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D921F991F for ; Fri, 16 Aug 2013 06:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C489C1BCC349; Fri, 16 Aug 2013 06:12:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 556841BCC3E6; Fri, 16 Aug 2013 06:12:15 -0700 (PDT) Message-ID: <520E252D.5080706@joelhalpern.com> Date: Fri, 16 Aug 2013 09:12:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Russ White References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> In-Reply-To: <020001ce9a7f$f8125c40$e83714c0$@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, 'Joel Halpern' , 'Joe Marcus Clarke' , lberger@labn.net, 'Alia Atlas' Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:12:26 -0000 If an implementation wants to store the data, more power to them. If there is a syslog format or a file dump format defined outside I2RS for reporting the data, great. But I do not want I2RS mandating storage or reporting of the data. That is not our job. Yours, Joel On 8/16/13 8:56 AM, Russ White wrote: > >> The idea of having the I2RS Agent store all the operations and attribution >> done is not appealing. > > Why not? If the data model on the wire is efficient, then the only thing > left to add efficiency to the file sizes would be aggregating the > information somehow. It seems, to me, that it's easiest just to store the > data in the on-the-wire tlv format, and have locally configurable filters > about what to save or not, etc. These might want to be really intelligent > filters, like, "only save the last five instances of this specific state > change," rather than, "save the last four hundred state changes of any > type," but the WG doesn't need to address these filters at all --they would > be implementation specific. > > Russ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From russw@riw.us Fri Aug 16 06:26:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6311E8134 for ; Fri, 16 Aug 2013 06:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj2lYNhcga1b for ; Fri, 16 Aug 2013 06:26:19 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 830A011E80EC for ; Fri, 16 Aug 2013 06:26:19 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAK2j-0000ol-QW; Fri, 16 Aug 2013 06:26:18 -0700 From: "Russ White" To: "'Joel M. Halpern'" References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> In-Reply-To: <520E252D.5080706@joelhalpern.com> Date: Fri, 16 Aug 2013 09:26:19 -0400 Message-ID: <026701ce9a84$32721160$97563420$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL/dwswimUnrNed5chPEDjTmPsQvALzfOS2AlTGytGXC9e6sA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Joel Halpern' , 'Joe Marcus Clarke' , lberger@labn.net, 'Alia Atlas' Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:26:25 -0000 > If an implementation wants to store the data, more power to them. If there > is a syslog format or a file dump format defined outside I2RS for reporting the > data, great. > But I do not want I2RS mandating storage or reporting of the data. That is not > our job. Agreed --but I think the question is --should I2RS create a new format for storing such data? IMHO, the answer is no. If the on-the-wire representation is efficient, then we've already created a way to store the data for anyone who wants to. Russ From akatlas@gmail.com Fri Aug 16 06:39:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB2311E814E for ; Fri, 16 Aug 2013 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z143GyaNT-xZ for ; Fri, 16 Aug 2013 06:39:06 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B3AA611E8140 for ; Fri, 16 Aug 2013 06:39:04 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so2094337obb.1 for ; Fri, 16 Aug 2013 06:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aeOmNGOwnqZbY6WmrhA905Whs7O1jW7X6739lLu5Eio=; b=xytmpCkJzeKeDEcMvnprXXKmNyFv69txKC/D0zBRFM4O6IVNiwCChTFupKupLfe2Li m3NaYccPJUavU+1ipb5U+AtmSMcnO8HkjB9I5ek02oFaq9oAu7RLbEX6R7QszFe+2eZb jqOiZyN55TKXsYkgBCUkagislKfAlQZ79CZNs0sdCPyJXybJHqY0WxH7VE7hlxgwkVtq 6yhQ9lPxYjdU01o7DI2Mu0zej6+R9BFkIWr2sbZuPDK7NxtOUxGJdVcJEA+hadOA8ZIh 82QGq80Dln4TAiSsffvF0Gy5peOrg7pNgUuTPdlFxmyo1+q0IkUa5PO2IFSFkxRCap/U q9YQ== MIME-Version: 1.0 X-Received: by 10.60.117.34 with SMTP id kb2mr1331175oeb.54.1376660344285; Fri, 16 Aug 2013 06:39:04 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 06:39:04 -0700 (PDT) In-Reply-To: <026701ce9a84$32721160$97563420$@riw.us> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> Date: Fri, 16 Aug 2013 09:39:04 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=047d7b417b49cc2e5b04e410b6f7 Cc: Joe Marcus Clarke , Joel Halpern , "Joel M. Halpern" , Lou Berger , "i2rs@ietf.org" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:39:06 -0000 --047d7b417b49cc2e5b04e410b6f7 Content-Type: text/plain; charset=ISO-8859-1 Russ, The on-the-wire representation is insufficient. It doesn't include things like time, client identity, transport connection information, etc. Alia On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > If an implementation wants to store the data, more power to them. If > there > > is a syslog format or a file dump format defined outside I2RS for > reporting the > > data, great. > > But I do not want I2RS mandating storage or reporting of the data. That > is not > > our job. > > Agreed --but I think the question is --should I2RS create a new format for > storing such data? IMHO, the answer is no. If the on-the-wire > representation > is efficient, then we've already created a way to store the data for anyone > who wants to. > > Russ > > > > --047d7b417b49cc2e5b04e410b6f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Russ,

The on-the-wire representation is= insufficient. =A0It doesn't include things like time, client identity,= transport connection information, etc.

Alia
=


On Fri, Aug 1= 6, 2013 at 9:26 AM, Russ White <russw@riw.us> wrote:

> If an implementation wants to store the data, more power to them. =A0I= f
there
> is a syslog format or a file dump format defined outside I2RS for
reporting the
> data, great.
> But I do not want I2RS mandating storage or reporting of the data. =A0= That
is not
> our job.

Agreed --but I think the question is --should I2RS create a new forma= t for
storing such data? IMHO, the answer is no. If the on-the-wire representatio= n
is efficient, then we've already created a way to store the data for an= yone
who wants to.

Russ




--047d7b417b49cc2e5b04e410b6f7-- From russw@riw.us Fri Aug 16 06:55:30 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC0511E814E for ; Fri, 16 Aug 2013 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKXj9QrscBpn for ; Fri, 16 Aug 2013 06:55:23 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33B21F9C4C for ; Fri, 16 Aug 2013 06:55:23 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAKUq-0003NQ-5V; Fri, 16 Aug 2013 06:55:20 -0700 From: "Russ White" To: "'Alia Atlas'" References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> In-Reply-To: Date: Fri, 16 Aug 2013 09:55:21 -0400 Message-ID: <028101ce9a88$40f80970$c2e81c50$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL/dwswimUnrNed5chPEDjTmPsQvALzfOS2AlTGytEBy2PyjwH8uBqIlu2eYDA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Joel Halpern' , 'Joe Marcus Clarke' , 'Lou Berger' , "'Joel M. Halpern'" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 13:55:31 -0000 > The on-the-wire representation is insufficient. It doesn't include things like > time, client identity, transport connection information, etc. Two points to consider: 1. As I've said elsewhere, we need to focus our scope if we're to make progress. 2. It seems, to me, that these are actually problems that are general in nature, and therefore applicable to every possible protocol in the same way (not just I2RS). I think we (the IETF and the community at large) have defined solutions to these very same problems many times --maybe it's time to define a format that includes these in the management area, with a set of open ended tlv spaces and a corresponding registry that could be used for any protocol (OSPF, IS-IS, I2RS, BGP, etc.), so we don't continuously reinvent the wheel in this space. Just a thought. Russ From akatlas@gmail.com Fri Aug 16 07:29:32 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3489511E8270 for ; Fri, 16 Aug 2013 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxEP7ujWHnSn for ; Fri, 16 Aug 2013 07:29:31 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8824A11E80FA for ; Fri, 16 Aug 2013 07:29:31 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so2369949oag.0 for ; Fri, 16 Aug 2013 07:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nS27deohI/DEG2ETbugwH7sOxSrVjAlfINRNcmxMBD0=; b=zCxr7k3dZJeXQJwXr7+QHJjPRa0PA4afd5GuOObwaSig2rw8kGUkYJoNW43smNgJd8 entGfvRxLfeuOeYuHUA7O9f3Hpt/p8cZNjzWwWvEannUWlQv4mMD9mr7aNFteiQ8ApAf u815crkiqSX1Jz3PjF8tPan1CxUj9wdCVFEXJHZ4k8gpPJGUadpqfBBqw2W+TTscKvHP Ab6uoCrT+Jdp3mL+0nrOvWkYhjwDaqFXjiYps3inAhIl1QLpSz5tqli9mqt/FKEI4w0b VmSQwc0WDQThDmPgXW3dYgEcjulgBq4OuMuF7biw3Can2JLjaBNBxnaeAuA4SE7kD+Fs 1r8A== MIME-Version: 1.0 X-Received: by 10.182.50.200 with SMTP id e8mr1568984obo.35.1376663371066; Fri, 16 Aug 2013 07:29:31 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 07:29:30 -0700 (PDT) In-Reply-To: <028101ce9a88$40f80970$c2e81c50$@riw.us> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <028101ce9a88$40f80970$c2e81c50$@riw.us> Date: Fri, 16 Aug 2013 10:29:30 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=047d7b6700c935377304e4116bea Cc: "i2rs@ietf.org" , Joel Halpern , Joe Marcus Clarke , Lou Berger , "Joel M. Halpern" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:29:32 -0000 --047d7b6700c935377304e4116bea Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 16, 2013 at 9:55 AM, Russ White wrote: > > > The on-the-wire representation is insufficient. It doesn't include > things > like > > time, client identity, transport connection information, etc. > > Two points to consider: > > 1. As I've said elsewhere, we need to focus our scope if we're to make > progress. > [Alia] Yes, absolutely. I've said it is a second-order problem - but if there is someone who wants to work on it, that's fine. 2. It seems, to me, that these are actually problems that are general in > nature, and therefore applicable to every possible protocol in the same way > (not just I2RS). I think we (the IETF and the community at large) have > defined solutions to these very same problems many times --maybe it's time > to define a format that includes these in the management area, with a set > of > open ended tlv spaces and a corresponding registry that could be used for > any protocol (OSPF, IS-IS, I2RS, BGP, etc.), so we don't continuously > reinvent the wheel in this space. > [Alia] In the I2RS case, we will have the advantage of structured data and protocol-specific information that can be easily articulated. Maybe NetConf has already solved some of this? I don't personally know yet. If someone wants to take the fairly specific case of having structured storage of actions for I2RS and generalize it for network management, I don't think that would be in the scope of I2RS. Alia > Just a thought. > > Russ > > --047d7b6700c935377304e4116bea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 16, 2013 at 9:55 AM, Russ White <russw@riw.us&= gt; wrote:
=

> The on-the-wire representation is insufficient. =A0It doesn't incl= ude things
like
> time, client identity, transport connection information, etc.

Two points to consider:

1. As I've said elsewhere, we need to focus our scope if we're to m= ake
progress.

[Alia] Yes, absolutely. =A0I&= #39;ve said it is a second-order problem - but if there is someone who
wants to work on it, that's fine.=A0

2. It seems, to me, that these are actually problems that are general in nature, and therefore applicable to every possible protocol in the same way=
(not just I2RS). I think we (the IETF and the community at large) have
defined solutions to these very same problems many times --maybe it's t= ime
to define a format that includes these in the management area, with a set o= f
open ended tlv spaces and a corresponding registry that could be used for any protocol (OSPF, IS-IS, I2RS, BGP, etc.), so we don't continuously reinvent the wheel in this space.

[Alia= ] In the I2RS case, we will have the advantage of structured data and proto= col-specific information that can be easily articulated. =A0Maybe NetConf h= as already solved some of this? =A0I don't personally know yet. =A0If s= omeone wants to take the fairly specific case of having structured storage = of actions for I2RS and generalize it for network management, I don't t= hink that would be in the scope of I2RS.

Alia
=A0
= Just a thought.

Russ


--047d7b6700c935377304e4116bea-- From gsalguei@cisco.com Fri Aug 16 07:32:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4772D11E80FA for ; Fri, 16 Aug 2013 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo3GvF0RHf7F for ; Fri, 16 Aug 2013 07:32:00 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BFFC611E828B for ; Fri, 16 Aug 2013 07:31:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GEVvqQ024751 for ; Fri, 16 Aug 2013 16:31:58 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GEVt3F018630; Fri, 16 Aug 2013 10:31:55 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 16 Aug 2013 10:31:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:32:04 -0000 There is no doubt that it isn't sufficient. But I think the overarching = goal in this case should be agility and expeditiousness, so scope should = be constrained to something manageable that might facilitate that. = There is precedent to doing such work (long) after the core work has = been done. In fact, in RAI we formed a WG specifically for defining a = data model and logging format (RFC 6872 and 6873) for SIP several years = after the fact. Couldn't we lessen our current burden and do something = similar here? Gonzalo On Aug 16, 2013, at 9:39 AM, Alia Atlas wrote: > Russ, >=20 > The on-the-wire representation is insufficient. It doesn't include = things like time, client identity, transport connection information, = etc. >=20 > Alia >=20 >=20 > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: >=20 > > If an implementation wants to store the data, more power to them. = If > there > > is a syslog format or a file dump format defined outside I2RS for > reporting the > > data, great. > > But I do not want I2RS mandating storage or reporting of the data. = That > is not > > our job. >=20 > Agreed --but I think the question is --should I2RS create a new format = for > storing such data? IMHO, the answer is no. If the on-the-wire = representation > is efficient, then we've already created a way to store the data for = anyone > who wants to. >=20 > Russ >=20 >=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Fri Aug 16 07:41:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FE411E8149 for ; Fri, 16 Aug 2013 07:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8I6qHPkiFm4 for ; Fri, 16 Aug 2013 07:41:19 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9434511E8226 for ; Fri, 16 Aug 2013 07:41:18 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so2321328oag.7 for ; Fri, 16 Aug 2013 07:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pr9v09UP9U6X/i6/FfWgkEk0NZ9kwaoKkexmyOpaXwo=; b=SmbZFmlmlj8RvMCGNSokWxrp9pdCq6fdNzWHtmuOVNIpFKiQjYBkcqK8J3gTRQw+nm 3paV5oHU6eP+7aJNlGBgcVjq+vaJbdWNACVtqN1cViWUG/VyzB7/EECuKTqppP7Ghoz8 Z5dWtOVmkHORvPAdMe1u/obd8NHP3Y4AedMjAzJ3XJPU1KbWb0QQrFxegQETzaYBg9Yl K0M+YkWMkCZCdINPX6OS9DTAxzMNLaFaoaIlZek3XhX+V0rBGCGVnN3ELbJSmR6iIR2H ftBN8KqzjQj3weplanaOfzx8IqDh8AEc18dx7eKr/UF/nYONLkbAAHzevE7B0z15zpNQ XgVQ== MIME-Version: 1.0 X-Received: by 10.182.19.229 with SMTP id i5mr1593057obe.46.1376664077096; Fri, 16 Aug 2013 07:41:17 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 07:41:16 -0700 (PDT) In-Reply-To: <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> Date: Fri, 16 Aug 2013 10:41:16 -0400 Message-ID: From: Alia Atlas To: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=001a11c298244a5c9b04e4119573 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:41:20 -0000 --001a11c298244a5c9b04e4119573 Content-Type: text/plain; charset=ISO-8859-1 Hi Gonzalo, If there are people who want to go off and brainstorm up an info-model that would augment any other info-model to put in the information necessary for storing a meaningful operations history, that could be very interesting to read. Whether it is required, in-scope, the highest priority to work on, etc. are different questions. Hearing the lessons learned and why RAI felt the need to do the work for SIP after and what would have been easier had it been done first might be interesting to hear on the list. Alia On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro wrote: > There is no doubt that it isn't sufficient. But I think the overarching > goal in this case should be agility and expeditiousness, so scope should be > constrained to something manageable that might facilitate that. There is > precedent to doing such work (long) after the core work has been done. In > fact, in RAI we formed a WG specifically for defining a data model and > logging format (RFC 6872 and 6873) for SIP several years after the fact. > Couldn't we lessen our current burden and do something similar here? > > Gonzalo > > > On Aug 16, 2013, at 9:39 AM, Alia Atlas > wrote: > > > Russ, > > > > The on-the-wire representation is insufficient. It doesn't include > things like time, client identity, transport connection information, etc. > > > > Alia > > > > > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > > > If an implementation wants to store the data, more power to them. If > > there > > > is a syslog format or a file dump format defined outside I2RS for > > reporting the > > > data, great. > > > But I do not want I2RS mandating storage or reporting of the data. > That > > is not > > > our job. > > > > Agreed --but I think the question is --should I2RS create a new format > for > > storing such data? IMHO, the answer is no. If the on-the-wire > representation > > is efficient, then we've already created a way to store the data for > anyone > > who wants to. > > > > Russ > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c298244a5c9b04e4119573 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Gonzalo,

If there are people who wan= t to go off and brainstorm up an info-model that would augment any other in= fo-model to put in the information necessary for storing a meaningful opera= tions history, that could be very interesting to read.

Whether it is required, in-scope, the highest priority = to work on, etc. are different questions.

Hearing = the lessons learned and why RAI felt the need to do the work for SIP after = and what would have been easier had it been done first might be interesting= to hear on the list.

Alia


On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro <gsa= lguei@cisco.com> wrote:
There is no doubt that it isn't sufficie= nt. But I think the overarching goal in this case should be agility and exp= editiousness, so scope should be constrained to something manageable that m= ight facilitate that. =A0There is precedent to doing such work (long) after= the core work has been done. =A0In fact, in RAI we formed a WG specificall= y for defining a data model and logging format (RFC 6872 and 6873) for SIP = several years after the fact. =A0Couldn't we lessen our current burden = and do something similar here?

Gonzalo


On Aug 16, 2013, at 9:39 AM, Alia Atlas <akatlas@gmail.com>
=A0wrote:

> Russ,
>
> The on-the-wire representation is insufficient. =A0It doesn't incl= ude things like time, client identity, transport connection information, et= c.
>
> Alia
>
>
> On Fri, Aug 16, 2013 at 9:26 AM, Russ White <russw@riw.us> wrote:
>
> > If an implementation wants to store the data, more power to them.= =A0If
> there
> > is a syslog format or a file dump format defined outside I2RS for=
> reporting the
> > data, great.
> > But I do not want I2RS mandating storage or reporting of the data= . =A0That
> is not
> > our job.
>
> Agreed --but I think the question is --should I2RS create a new format= for
> storing such data? IMHO, the answer is no. If the on-the-wire represen= tation
> is efficient, then we've already created a way to store the data f= or anyone
> who wants to.
>
> Russ
>
>
>
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


--001a11c298244a5c9b04e4119573-- From gsalguei@cisco.com Fri Aug 16 07:51:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDEC11E8286 for ; Fri, 16 Aug 2013 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlViKiiojB6z for ; Fri, 16 Aug 2013 07:51:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DE31A11E8149 for ; Fri, 16 Aug 2013 07:51:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GEp1eu027188 for ; Fri, 16 Aug 2013 16:51:02 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GEp0Px006651; Fri, 16 Aug 2013 10:51:01 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 16 Aug 2013 10:51:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <158A6956-2AFB-4CED-AF1E-9DDE76A04454@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:51:32 -0000 Hi Alia -=20 On Aug 16, 2013, at 10:41 AM, Alia Atlas wrote: > Hi Gonzalo, >=20 > If there are people who want to go off and brainstorm up an info-model = that would augment any other info-model to put in the information = necessary for storing a meaningful operations history, that could be = very interesting to read. >=20 > Whether it is required, in-scope, the highest priority to work on, = etc. are different questions. >=20 > Hearing the lessons learned and why RAI felt the need to do the work = for SIP after and what would have been easier had it been done first = might be interesting to hear on the list. It was done after the fact for reasons of scope containment and, as is = typically the case with such troubleshooting efforts (right or wrong), = it was considered lower priority than the core protocol work. It also = time sync'ed nicely with some ongoing discussions of how short-lived WGs = with a very clear and directed purpose with a reasonable number = milestones were the preferred model. Gonzalo >=20 > Alia >=20 >=20 > On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro = wrote: > There is no doubt that it isn't sufficient. But I think the = overarching goal in this case should be agility and expeditiousness, so = scope should be constrained to something manageable that might = facilitate that. There is precedent to doing such work (long) after the = core work has been done. In fact, in RAI we formed a WG specifically = for defining a data model and logging format (RFC 6872 and 6873) for SIP = several years after the fact. Couldn't we lessen our current burden and = do something similar here? >=20 > Gonzalo >=20 >=20 > On Aug 16, 2013, at 9:39 AM, Alia Atlas > wrote: >=20 > > Russ, > > > > The on-the-wire representation is insufficient. It doesn't include = things like time, client identity, transport connection information, = etc. > > > > Alia > > > > > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > > > If an implementation wants to store the data, more power to them. = If > > there > > > is a syslog format or a file dump format defined outside I2RS for > > reporting the > > > data, great. > > > But I do not want I2RS mandating storage or reporting of the data. = That > > is not > > > our job. > > > > Agreed --but I think the question is --should I2RS create a new = format for > > storing such data? IMHO, the answer is no. If the on-the-wire = representation > > is efficient, then we've already created a way to store the data for = anyone > > who wants to. > > > > Russ > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 From akatlas@gmail.com Fri Aug 16 07:59:27 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9811E828E for ; Fri, 16 Aug 2013 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRtpOioa6oT5 for ; Fri, 16 Aug 2013 07:59:26 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 69B1711E8286 for ; Fri, 16 Aug 2013 07:59:26 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so2339532oag.39 for ; Fri, 16 Aug 2013 07:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tmTMMaHCouo1qG9B6QR02flunJsJlzQ9rvtifvRyxVc=; b=JxirjI1AwWswd7JMw2xOWhlbR4GvHF9F399xzZg/26WzXhEgQYysu5AOH85oG5jbqi 7YqTi8ExSlOQ0SFRuKrM4Dio6NJV1AqIM7XxEIkEbhXu8lTPqOep+wkyqeHYvzNGEW7S xv1IE1pROuClGz8vshOuUmTgYNjCTq3hrf3ziScibUt/xX8BBLArjVcfWCZA1SgQrRDK zvoOr8Uxtnsch+VZj8XoHlTUCFK0yYobTeIUopnnKq2ZbdXy7eVtUndxUTFZ4lX1HcGZ j+wcnDQgkSV2yibmz6f7FOHug6AdH8DfHWQDBlpR1KCGqCG9EQ7dyVWeyBk2sC93UhVc x4Iw== MIME-Version: 1.0 X-Received: by 10.60.94.69 with SMTP id da5mr1665875oeb.29.1376665164940; Fri, 16 Aug 2013 07:59:24 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 07:59:24 -0700 (PDT) In-Reply-To: <01ef01ce9a7c$35570280$a0050780$@riw.us> References: <002c01ce9a10$5f25cc70$1d716550$@riw.us> <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> <01ef01ce9a7c$35570280$a0050780$@riw.us> Date: Fri, 16 Aug 2013 10:59:24 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=089e01176ebd218f2504e411d6a0 Cc: "Keyur Patel \(keyupate\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:59:27 -0000 --089e01176ebd218f2504e411d6a0 Content-Type: text/plain; charset=ISO-8859-1 Russ, I think that we realized that documenting all the use-cases in one draft was going to be unwieldy and not provide enough detail on the specific requirements. I think that the use-cases will fall into protocol-specific ones, RIB or "protocol-agnostic" ones, topology-specific ones, and "interacts with multiple protocols" cases. For the latter, I think we just have to document them separately or, possibly if they are developing at similar maturity, in a common draft. More specifically, what we have in charter is: - Tightly scoped key use cases for operational use of I2RS as follows: o Interactions with the Routing Information Base (RIB). Allowing read and write access to the RIB, but no direct access to the Forwarding Information Base (FIB). o Control and analysis of the operation of the Border Gateway Protocol (BGP) including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through rapid modification of the control plane behavior to reroute traffic for one destination while leaving standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as an initial work item. I could see a separate detailed use-case draft for each of these... We need the use-cases flushed out to describe the feedback loop, the frequency, and the information needed for writing and reading and events. Alia On Fri, Aug 16, 2013 at 8:29 AM, Russ White wrote: > > > I'm a bit confused at this point about when those decisions were changed, > > and how we intend to proceed. > > I have one possible suggestion, after looking at the structure of the > drafts > again. What I think we might want to do is to pull the bgp use cases from > draft-white to bolster the bgp use cases draft, moving the bgp use cases > draft to an editor/contributor format (since it already has a lot of co's). > The remaining use cases can be put into a rib uses cases draft, where we > can > collect all the various "routing protocol agnostic" use cases. Again, we > could move this to editor/contributor --I'll be happy to hold the editor > baton for this new draft. > > There may be some question about what fits where (are all the bgp uses > really limited to bgp? Do we want a separate overlay use cases, or should > these fall into the protocol related draft they work with?), but I think > this is a workable model to get all the use cases organized into a > reasonable set of drafts that can be added to, etc., until the WG gets to > the point of having a 'first set' of use cases on the table. After this > initial batch is actually published, then it's going to be better to > continue with individual drafts for individual use cases, rather than > bis'ing this set, I think. > > Thoughts? > > Russ > > --089e01176ebd218f2504e411d6a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Russ,

I think that we realized that doc= umenting all the use-cases in one draft was going to be unwieldy and not pr= ovide enough detail on the specific requirements.

I think that the use-cases will fall into protocol-specific ones, RIB or &q= uot;protocol-agnostic" ones, topology-specific ones, and "interac= ts with multiple protocols" cases. =A0For the latter, I think we just = have to document them separately or, possibly if they are developing at sim= ilar maturity, in a common draft.

More specifically, what we have in charter is:
  - Tightly scoped key use=
 cases for operational use of I2RS as follows:
    o Interactions with the Routing Information Base (RIB). Allowing read
      and write access to the RIB, but no direct access to the Forwarding
      Information Base (FIB).
    o Control and analysis of the operation of the Border Gateway Protocol
      (BGP) including the setting and activation of policies related to
      the protocol.
    o Control, optimization, and choice of traffic exit points from
      networks based on more information than provided by the dynamic
      control plane.
    o Distributed reaction to network-based attacks through rapid
      modification of the control plane behavior to reroute traffic for
      one destination while leaving standard mechanisms (filters, metrics,
      and policy) in place for other routes.
    o Service layer routing to improve on existing hub-and-spoke traffic.
    o The ability to extract information about topology from the network.
      Injection and creation of topology will not be considered as an initi=
al work item.
I could see a separate detailed use-case draft for each of= these... =A0We need the use-cases flushed out to describe the feedback loo= p, the frequency, and the information needed for writing and reading and ev= ents.

Alia



On Fri, Aug 16, 2013 at 8:29 AM, Russ= White <russw@riw.us> wrote:

> I'm a bit confused at this point about when those decisions were c= hanged,
> and how we intend to proceed.

I have one possible suggestion, after looking at the structure of the= drafts
again. What I think we might want to do is to pull the bgp use cases from draft-white to bolster the bgp use cases draft, moving the bgp use cases draft to an editor/contributor format (since it already has a lot of co'= ;s).
The remaining use cases can be put into a rib uses cases draft, where we ca= n
collect all the various "routing protocol agnostic" use cases. Ag= ain, we
could move this to editor/contributor --I'll be happy to hold the edito= r
baton for this new draft.

There may be some question about what fits where (are all the bgp uses
really limited to bgp? Do we want a separate overlay use cases, or should these fall into the protocol related draft they work with?), but I think this is a workable model to get all the use cases organized into a
reasonable set of drafts that can be added to, etc., until the WG gets to the point of having a 'first set' of use cases on the table. After = this
initial batch is actually published, then it's going to be better to continue with individual drafts for individual use cases, rather than
bis'ing this set, I think.

Thoughts?

Russ


--089e01176ebd218f2504e411d6a0-- From akatlas@gmail.com Fri Aug 16 08:00:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5A21F9CF7 for ; Fri, 16 Aug 2013 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6r1wSypouSF for ; Fri, 16 Aug 2013 08:00:40 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id AC9A121F9B5F for ; Fri, 16 Aug 2013 08:00:40 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so2395607oag.10 for ; Fri, 16 Aug 2013 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b5+KTFYdf0sASZ5enH1buyY6rnizn8WmVq91NnTJEd0=; b=qSbCJZr08A3RpsO3mpx9BXWc/eYECI6QgShd5bNo17vWa8l4BKfzYnpDpW8E0FVGz8 pFYwsxCtdXQuIz92NLc/YQcBw5+x1yELdHPyt5rrqhIJTxYXBLOkw1kXbJoYaddfV6Ym cIH00QWfjUYrBKtLDT5RhK35NkJ/kh1iRoos3o+52E48eM0XuRxML/OkAUEjwlBrwvGo thsZjVYpXLtSWVDOFANLaA/EgyV/yLUtWTGj8gz5B4uZ5Jz8egoP7Yj61TOvf8WtXoon Gw66rmmrog7yEVJAmo1X43GEVXUjjRznAUgE90urh6QM31JxzKLqz2Wd/ZGCie2buR6m TnrQ== MIME-Version: 1.0 X-Received: by 10.60.96.131 with SMTP id ds3mr1648941oeb.50.1376665240236; Fri, 16 Aug 2013 08:00:40 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 08:00:40 -0700 (PDT) In-Reply-To: <158A6956-2AFB-4CED-AF1E-9DDE76A04454@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> <158A6956-2AFB-4CED-AF1E-9DDE76A04454@cisco.com> Date: Fri, 16 Aug 2013 11:00:40 -0400 Message-ID: From: Alia Atlas To: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=089e01227b7c9e79ee04e411da63 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:00:41 -0000 --089e01227b7c9e79ee04e411da63 Content-Type: text/plain; charset=ISO-8859-1 Hi Gonzalo, Ok - that doesn't tell me that it was the wrong decision :-) or that I2RS should do something differently. Alia On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro wrote: > Hi Alia - > > On Aug 16, 2013, at 10:41 AM, Alia Atlas wrote: > > > Hi Gonzalo, > > > > If there are people who want to go off and brainstorm up an info-model > that would augment any other info-model to put in the information necessary > for storing a meaningful operations history, that could be very interesting > to read. > > > > Whether it is required, in-scope, the highest priority to work on, etc. > are different questions. > > > > Hearing the lessons learned and why RAI felt the need to do the work for > SIP after and what would have been easier had it been done first might be > interesting to hear on the list. > > It was done after the fact for reasons of scope containment and, as is > typically the case with such troubleshooting efforts (right or wrong), it > was considered lower priority than the core protocol work. It also time > sync'ed nicely with some ongoing discussions of how short-lived WGs with a > very clear and directed purpose with a reasonable number milestones were > the preferred model. > > Gonzalo > > > > > Alia > > > > > > On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro > wrote: > > There is no doubt that it isn't sufficient. But I think the overarching > goal in this case should be agility and expeditiousness, so scope should be > constrained to something manageable that might facilitate that. There is > precedent to doing such work (long) after the core work has been done. In > fact, in RAI we formed a WG specifically for defining a data model and > logging format (RFC 6872 and 6873) for SIP several years after the fact. > Couldn't we lessen our current burden and do something similar here? > > > > Gonzalo > > > > > > On Aug 16, 2013, at 9:39 AM, Alia Atlas > > wrote: > > > > > Russ, > > > > > > The on-the-wire representation is insufficient. It doesn't include > things like time, client identity, transport connection information, etc. > > > > > > Alia > > > > > > > > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > > > > > If an implementation wants to store the data, more power to them. If > > > there > > > > is a syslog format or a file dump format defined outside I2RS for > > > reporting the > > > > data, great. > > > > But I do not want I2RS mandating storage or reporting of the data. > That > > > is not > > > > our job. > > > > > > Agreed --but I think the question is --should I2RS create a new format > for > > > storing such data? IMHO, the answer is no. If the on-the-wire > representation > > > is efficient, then we've already created a way to store the data for > anyone > > > who wants to. > > > > > > Russ > > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > --089e01227b7c9e79ee04e411da63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Gonzalo,

Ok - that doesn't tell = me that it was the wrong decision :-) or that I2RS should do something diff= erently.

Alia


On Fri, Aug 16, 2013 at 10:51 AM, Gonzal= o Salgueiro <gsalguei@cisco.com> wrote:
Hi Alia -

On Aug 16, 2013, at 10:41 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi Gonzalo,
>
> If there are people who want to go off and brainstorm up an info-model= that would augment any other info-model to put in the information necessar= y for storing a meaningful operations history, that could be very interesti= ng to read.
>
> Whether it is required, in-scope, the highest priority to work on, etc= . are different questions.
>
> Hearing the lessons learned and why RAI felt the need to do the work f= or SIP after and what would have been easier had it been done first might b= e interesting to hear on the list.

It was done after the fact for reasons of scope containment and, as i= s typically the case with such troubleshooting efforts (right or wrong), it= was considered lower priority than the core protocol work. =A0It also time= sync'ed nicely with some ongoing discussions of how short-lived WGs wi= th a very clear and directed purpose with a reasonable number milestones we= re the preferred model.

Gonzalo

>
> Alia
>
>
> On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
> There is no doubt that it isn't sufficient. But I think the overar= ching goal in this case should be agility and expeditiousness, so scope sho= uld be constrained to something manageable that might facilitate that. =A0T= here is precedent to doing such work (long) after the core work has been do= ne. =A0In fact, in RAI we formed a WG specifically for defining a data mode= l and logging format (RFC 6872 and 6873) for SIP several years after the fa= ct. =A0Couldn't we lessen our current burden and do something similar h= ere?
>
> Gonzalo
>
>
> On Aug 16, 2013, at 9:39 AM, Alia Atlas <akatlas@gmail.com>
> =A0wrote:
>
> > Russ,
> >
> > The on-the-wire representation is insufficient. =A0It doesn't= include things like time, client identity, transport connection informatio= n, etc.
> >
> > Alia
> >
> >
> > On Fri, Aug 16, 2013 at 9:26 AM, Russ White <russw@riw.us> wrote:
> >
> > > If an implementation wants to store the data, more power to = them. =A0If
> > there
> > > is a syslog format or a file dump format defined outside I2R= S for
> > reporting the
> > > data, great.
> > > But I do not want I2RS mandating storage or reporting of the= data. =A0That
> > is not
> > > our job.
> >
> > Agreed --but I think the question is --should I2RS create a new f= ormat for
> > storing such data? IMHO, the answer is no. If the on-the-wire rep= resentation
> > is efficient, then we've already created a way to store the d= ata for anyone
> > who wants to.
> >
> > Russ
> >
> >
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > i2rs@ietf.org
> > https://www.ietf.org/mailman/listinfo/i2rs
>
>


--089e01227b7c9e79ee04e411da63-- From gsalguei@cisco.com Fri Aug 16 08:17:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252311E8290 for ; Fri, 16 Aug 2013 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oANyE+rk6I5B for ; Fri, 16 Aug 2013 08:17:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6029611E815B for ; Fri, 16 Aug 2013 08:17:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GFHMTj000533 for ; Fri, 16 Aug 2013 17:17:22 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GFHLdZ003954; Fri, 16 Aug 2013 11:17:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Fri, 16 Aug 2013 11:17:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4323369A-A183-4BC6-A638-3E6EE235E102@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> <158A6956-2AFB-4CED-AF1E-9DDE76A04454@cisco.com> To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:17:38 -0000 Hi Alia -=20 On Aug 16, 2013, at 11:00 AM, Alia Atlas wrote: > Hi Gonzalo, >=20 > Ok - that doesn't tell me that it was the wrong decision :-) or that = I2RS should do something differently. No, nor am I ;-) I was merely offering up the historical precedent for doing this work = after the fact considering the effects of scope creep and delay. I don't = argue that an investigation into an information model and log format of = such structured data would be an interesting read. In fact, I agree = that it certainly would. I just worry that each such effort, even if = ad-hoc and done outside WG purview, could reduce cycles best applied to = the core work. Gonzalo >=20 > Alia >=20 >=20 > On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro = wrote: > Hi Alia - >=20 > On Aug 16, 2013, at 10:41 AM, Alia Atlas wrote: >=20 > > Hi Gonzalo, > > > > If there are people who want to go off and brainstorm up an = info-model that would augment any other info-model to put in the = information necessary for storing a meaningful operations history, that = could be very interesting to read. > > > > Whether it is required, in-scope, the highest priority to work on, = etc. are different questions. > > > > Hearing the lessons learned and why RAI felt the need to do the work = for SIP after and what would have been easier had it been done first = might be interesting to hear on the list. >=20 > It was done after the fact for reasons of scope containment and, as is = typically the case with such troubleshooting efforts (right or wrong), = it was considered lower priority than the core protocol work. It also = time sync'ed nicely with some ongoing discussions of how short-lived WGs = with a very clear and directed purpose with a reasonable number = milestones were the preferred model. >=20 > Gonzalo >=20 > > > > Alia > > > > > > On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro = wrote: > > There is no doubt that it isn't sufficient. But I think the = overarching goal in this case should be agility and expeditiousness, so = scope should be constrained to something manageable that might = facilitate that. There is precedent to doing such work (long) after the = core work has been done. In fact, in RAI we formed a WG specifically = for defining a data model and logging format (RFC 6872 and 6873) for SIP = several years after the fact. Couldn't we lessen our current burden and = do something similar here? > > > > Gonzalo > > > > > > On Aug 16, 2013, at 9:39 AM, Alia Atlas > > wrote: > > > > > Russ, > > > > > > The on-the-wire representation is insufficient. It doesn't = include things like time, client identity, transport connection = information, etc. > > > > > > Alia > > > > > > > > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > > > > > If an implementation wants to store the data, more power to = them. If > > > there > > > > is a syslog format or a file dump format defined outside I2RS = for > > > reporting the > > > > data, great. > > > > But I do not want I2RS mandating storage or reporting of the = data. That > > > is not > > > > our job. > > > > > > Agreed --but I think the question is --should I2RS create a new = format for > > > storing such data? IMHO, the answer is no. If the on-the-wire = representation > > > is efficient, then we've already created a way to store the data = for anyone > > > who wants to. > > > > > > Russ > > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > >=20 >=20 From akatlas@gmail.com Fri Aug 16 09:22:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7B11E8197 for ; Fri, 16 Aug 2013 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE9JHd1xw2QD for ; Fri, 16 Aug 2013 09:22:05 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E786821F9CBF for ; Fri, 16 Aug 2013 09:22:04 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so2265921obc.3 for ; Fri, 16 Aug 2013 09:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pNzrFp3qHOQHyXDX1E6qjCxLrX0AVn3U+AOMdA526Iw=; b=sJZcmAKQNNJQIkWYnrUUbrjYvmZsonxZcmek2zfPejcoWxH20QCmZZau7KAcjp6sjQ z+4boseVv+p/KbIYdT3aclaCQp2rzmaktN4AHE1/rT33vlVf6pzDHdzQzwtIdlmUo+dG 6g8ffV0qfLToiEB/2S6h2C1eCUpPL5qnWOpMI69yWZklfKvpdBysrzqbKWtQLZlxRO7M wdvk4JXGrxKYSVkedBamb7TmfRmQrxQGGiuRbchq37fABkeSoCQoJGQQ8MehWO6LGNB4 aqK+01ilL3xAD6O3AMR7psZdKOdKRl4/H6Wn9QIupwx1uiO7QYc+vWzffyCSt6hPbbFw 3JDg== MIME-Version: 1.0 X-Received: by 10.182.89.131 with SMTP id bo3mr1890902obb.48.1376670124414; Fri, 16 Aug 2013 09:22:04 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 09:22:04 -0700 (PDT) In-Reply-To: <4323369A-A183-4BC6-A638-3E6EE235E102@cisco.com> References: <020001ce9a7f$f8125c40$e83714c0$@riw.us> <520E252D.5080706@joelhalpern.com> <026701ce9a84$32721160$97563420$@riw.us> <7EA917B0-6410-466F-9799-386C865BAFF9@cisco.com> <158A6956-2AFB-4CED-AF1E-9DDE76A04454@cisco.com> <4323369A-A183-4BC6-A638-3E6EE235E102@cisco.com> Date: Fri, 16 Aug 2013 12:22:04 -0400 Message-ID: From: Alia Atlas To: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=089e01494992bd1af604e412fdb1 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] info-model for traceability and accountability?? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:22:06 -0000 --089e01494992bd1af604e412fdb1 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Gonzalo. That was what I was trying to understand. I would also prefer focus on the core work. In particular, augmenting and nailing down our use-cases, starting on the other protocol-related info models, and starting to define the protocol requirements and data-modeling requirements would be very helpful. We'll need to be discussing the protocol and data-modeling requirements and, hopefully, which protocols and data-modeling languages can support them and what extensions might be required. I'd really like to see I2RS ready to do that in sophisticated detail by November. As a reminder, our milestones are: Jul 2013 - Request publication of an Informational document defining the problem statement Jul 2013 - Request publication of an Informational document defining the high-level architecture Aug 2013 - Request publication of Informational documents describing use cases Sep 2013 - Request publication of an Informational document defining the protocol requirements Sep 2013 - Request publication of an Informational document defining encoding language requirements Feb 2014 - Request publication of Standards Track documents specifying information models Feb 2014 - Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Feb 2014 - Consider re-chartering Alia On Fri, Aug 16, 2013 at 11:17 AM, Gonzalo Salgueiro wrote: > Hi Alia - > > On Aug 16, 2013, at 11:00 AM, Alia Atlas wrote: > > > Hi Gonzalo, > > > > Ok - that doesn't tell me that it was the wrong decision :-) or that > I2RS should do something differently. > > No, nor am I ;-) > > I was merely offering up the historical precedent for doing this work > after the fact considering the effects of scope creep and delay. I don't > argue that an investigation into an information model and log format of > such structured data would be an interesting read. In fact, I agree that > it certainly would. I just worry that each such effort, even if ad-hoc and > done outside WG purview, could reduce cycles best applied to the core work. > > Gonzalo > > > > > > Alia > > > > > > On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro > wrote: > > Hi Alia - > > > > On Aug 16, 2013, at 10:41 AM, Alia Atlas wrote: > > > > > Hi Gonzalo, > > > > > > If there are people who want to go off and brainstorm up an info-model > that would augment any other info-model to put in the information necessary > for storing a meaningful operations history, that could be very interesting > to read. > > > > > > Whether it is required, in-scope, the highest priority to work on, > etc. are different questions. > > > > > > Hearing the lessons learned and why RAI felt the need to do the work > for SIP after and what would have been easier had it been done first might > be interesting to hear on the list. > > > > It was done after the fact for reasons of scope containment and, as is > typically the case with such troubleshooting efforts (right or wrong), it > was considered lower priority than the core protocol work. It also time > sync'ed nicely with some ongoing discussions of how short-lived WGs with a > very clear and directed purpose with a reasonable number milestones were > the preferred model. > > > > Gonzalo > > > > > > > > Alia > > > > > > > > > On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro < > gsalguei@cisco.com> wrote: > > > There is no doubt that it isn't sufficient. But I think the > overarching goal in this case should be agility and expeditiousness, so > scope should be constrained to something manageable that might facilitate > that. There is precedent to doing such work (long) after the core work has > been done. In fact, in RAI we formed a WG specifically for defining a data > model and logging format (RFC 6872 and 6873) for SIP several years after > the fact. Couldn't we lessen our current burden and do something similar > here? > > > > > > Gonzalo > > > > > > > > > On Aug 16, 2013, at 9:39 AM, Alia Atlas > > > wrote: > > > > > > > Russ, > > > > > > > > The on-the-wire representation is insufficient. It doesn't include > things like time, client identity, transport connection information, etc. > > > > > > > > Alia > > > > > > > > > > > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White wrote: > > > > > > > > > If an implementation wants to store the data, more power to them. > If > > > > there > > > > > is a syslog format or a file dump format defined outside I2RS for > > > > reporting the > > > > > data, great. > > > > > But I do not want I2RS mandating storage or reporting of the data. > That > > > > is not > > > > > our job. > > > > > > > > Agreed --but I think the question is --should I2RS create a new > format for > > > > storing such data? IMHO, the answer is no. If the on-the-wire > representation > > > > is efficient, then we've already created a way to store the data for > anyone > > > > who wants to. > > > > > > > > Russ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > i2rs mailing list > > > > i2rs@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > --089e01494992bd1af604e412fdb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Gonzalo. =A0That was what I was trying to understa= nd.

I would also prefer focus on the core work. =A0In pa= rticular, augmenting and nailing down our use-cases, starting on the other = protocol-related info models, and starting to define the protocol requireme= nts and data-modeling requirements would be very helpful.

We'll need to be discussing the protocol and data-m= odeling requirements and, hopefully, which protocols and data-modeling lang= uages can support them and what extensions might be required. =A0I'd re= ally like to see I2RS ready to do that in sophisticated detail by November.=

As a reminder, our milestones are:
  Jul 2013 - Request publication of an=
 Informational document defining the problem statement
  Jul 2013 - Request publication of an Informational document defining the =
high-level architecture
  Aug 2013 - Request publication of Informational documents describing use =
cases
  Sep 2013 - Request publication of an Informational document defining the =
protocol requirements
  Sep 2013 - Request publication of an Informational document defining enco=
ding language requirements
  Feb 2014 - Request publication of Standards Track documents specifying in=
formation models
  Feb 2014 - Request publication of an Informational document providing an =
analysis of existing IETF and other protocols and encoding languages agains=
t the requirements
  Feb 2014 - Consider re-chartering


Alia


On Fri, Aug 16, 2013 at= 11:17 AM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
Hi Alia -

On Aug 16, 2013, at 11:00 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi Gonzalo,
>
> Ok - that doesn't tell me that it was the = wrong decision :-) or that I2RS should do something differently.

No, nor am I ;-)

I was merely offering up the historical precedent for doing this work after= the fact considering the effects of scope creep and delay. I don't arg= ue that an investigation into an information model and log format of such s= tructured data would be an interesting read. =A0In fact, I agree that it ce= rtainly would. =A0I just worry that each such effort, even if ad-hoc and do= ne outside WG purview, could reduce cycles best applied to the core work.

Gonzalo


>
> Alia
>
>
> On Fri, Aug 16, 2013 at 10:51 AM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
> Hi Alia -
>
> On Aug 16, 2013, at 10:41 AM, Alia Atlas <akatlas@gmail.com> wrote:
>
> > Hi Gonzalo,
> >
> > If there are people who want to go off and brainstorm up an info-= model that would augment any other info-model to put in the information nec= essary for storing a meaningful operations history, that could be very inte= resting to read.
> >
> > Whether it is required, in-scope, the highest priority to work on= , etc. are different questions.
> >
> > Hearing the lessons learned and why RAI felt the need to do the w= ork for SIP after and what would have been easier had it been done first mi= ght be interesting to hear on the list.
>
> It was done after the fact for reasons of scope containment and, as is= typically the case with such troubleshooting efforts (right or wrong), it = was considered lower priority than the core protocol work. =A0It also time = sync'ed nicely with some ongoing discussions of how short-lived WGs wit= h a very clear and directed purpose with a reasonable number milestones wer= e the preferred model.
>
> Gonzalo
>
> >
> > Alia
> >
> >
> > On Fri, Aug 16, 2013 at 10:31 AM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
> > There is no doubt that it isn't sufficient. But I think the o= verarching goal in this case should be agility and expeditiousness, so scop= e should be constrained to something manageable that might facilitate that.= =A0There is precedent to doing such work (long) after the core work has be= en done. =A0In fact, in RAI we formed a WG specifically for defining a data= model and logging format (RFC 6872 and 6873) for SIP several years after t= he fact. =A0Couldn't we lessen our current burden and do something simi= lar here?
> >
> > Gonzalo
> >
> >
> > On Aug 16, 2013, at 9:39 AM, Alia Atlas <akatlas@gmail.com>
> > =A0wrote:
> >
> > > Russ,
> > >
> > > The on-the-wire representation is insufficient. =A0It doesn&= #39;t include things like time, client identity, transport connection infor= mation, etc.
> > >
> > > Alia
> > >
> > >
> > > On Fri, Aug 16, 2013 at 9:26 AM, Russ White <russw@riw.us> wrote:
> > >
> > > > If an implementation wants to store the data, more powe= r to them. =A0If
> > > there
> > > > is a syslog format or a file dump format defined outsid= e I2RS for
> > > reporting the
> > > > data, great.
> > > > But I do not want I2RS mandating storage or reporting o= f the data. =A0That
> > > is not
> > > > our job.
> > >
> > > Agreed --but I think the question is --should I2RS create a = new format for
> > > storing such data? IMHO, the answer is no. If the on-the-wir= e representation
> > > is efficient, then we've already created a way to store = the data for anyone
> > > who wants to.
> > >
> > > Russ
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > i2rs mailing list
> > > i2rs@ietf.org
> > > https://www.ietf.org/mailman/listinfo/i2rs
> >
> >
>
>


--089e01494992bd1af604e412fdb1-- From keyupate@cisco.com Fri Aug 16 10:16:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF98311E8197 for ; Fri, 16 Aug 2013 10:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-9KkVgxLAl6 for ; Fri, 16 Aug 2013 10:16:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EF74511E8153 for ; Fri, 16 Aug 2013 10:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1376673403; x=1377883003; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=e5pk9ZQhpUr2VTUWWEVLw5iUwv+gRwj9j963SFRpj8Y=; b=g9eZNi6dzPgEraFTupMaJXuA9/movOHxm+WLzo197mbiHomWIFHPensg D6Fi3nmh80ATc9lS2ofkNvBKm/Et71s8hM+aghjWDDa2XD+MOwAjDk9Q8 AWnReEataRRnimefeMzN50HhXP9Ii4xmt4QXFjESow6KNsYlNlV9Y3p0C E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADJdDlKtJXG9/2dsb2JhbABbgwaBBr8fgSsWdIIkAQEBAwE6UQEIIhRCJQIEARIIiAIGuhmQHziDG3cDqTmDHIIq X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="248194716" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 16 Aug 2013 17:16:40 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7GHGexa030743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 17:16:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.187]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 12:16:39 -0500 From: "Keyur Patel (keyupate)" To: Russ White , "'Alia Atlas'" , "i2rs@ietf.org" Thread-Topic: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases Thread-Index: AQHOmhzkpxfh22pVVk2h5lRsIqPr3pmXXSSAgACWfQA= Date: Fri, 16 Aug 2013 17:16:39 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E088BA55B@xmb-aln-x09.cisco.com> In-Reply-To: <007401ce9a1e$c8aed340$5a0c79c0$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.33.12.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <241C16945D85D34AA7FB59BEEE3E2842@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] Results of WG Adoption Call: draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:16:55 -0000 Russ, I am ok with merging of the draft. But do u think merging non-bgp centric use cases into bgp usecases draft makes sense? Regards, Keyur On 8/15/13 6:20 PM, "Russ White" wrote: > >> IMHO it would be best to keep BGP specific use cases into a separate >draft. > >Okay --so... That leaves us with the next question --the use cases that >aren't BGP centric --do we try and continue a draft with just those one or >two, or... ??=20 > >I don't really understand what the situation is at this point. My >understanding of the discussion on list and in person from way back were >that the draft I was editing and the BGP use cases draft were going to be >merged, not that one was going to subsume the other completely, leaving >the >remainder out of the picture entirely... In fact, the WG originally >decided >to only use one use cases draft as it's basis for work until the use cases >in that first draft were covered by requirements/etc. It now sounds like >we've changed that direction completely, and we're back to boiling the >ocean. > >I'm a bit confused at this point about when those decisions were changed, >and how we intend to proceed. > >:-) > >Russ=20 > > From ietfc@btconnect.com Fri Aug 16 10:37:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5511E8164 for ; Fri, 16 Aug 2013 10:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=1.766, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAmjUVX+yxln for ; Fri, 16 Aug 2013 10:37:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id B4BAF11E8163 for ; Fri, 16 Aug 2013 10:37:35 -0700 (PDT) Received: from mail4-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.22; Fri, 16 Aug 2013 17:37:34 +0000 Received: from mail4-am1 (localhost [127.0.0.1]) by mail4-am1-R.bigfish.com (Postfix) with ESMTP id 7F07C160262; Fri, 16 Aug 2013 17:37:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail4-am1 (localhost.localdomain [127.0.0.1]) by mail4-am1 (MessageSwitch) id 1376674599448578_17589; Fri, 16 Aug 2013 17:36:39 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.228]) by mail4-am1.bigfish.com (Postfix) with ESMTP id 60943220048; Fri, 16 Aug 2013 17:36:39 +0000 (UTC) Received: from AMSPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.181) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 16 Aug 2013 17:36:39 +0000 Received: from pc6 (86.135.129.242) by pod51017.outlook.com (10.242.14.165) with Microsoft SMTP Server (TLS) id 14.16.347.3; Fri, 16 Aug 2013 17:36:38 +0000 Message-ID: <01c101ce9aa7$15855a80$4001a8c0@gateway.2wire.net> From: t.petch To: Russ White , "'Keyur Patel (keyupate)'" , 'Alia Atlas' , References: <002c01ce9a10$5f25cc70$1d716550$@riw.us><4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> <01ef01ce9a7c$35570280$a0050780$@riw.us> Date: Fri, 16 Aug 2013 18:31:18 +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: [86.135.129.242] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [i2rs] Results of WG Adoption Call:draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 17:37:43 -0000 ----- Original Message ----- From: "Russ White" To: "'Keyur Patel (keyupate)'" ; "'Alia Atlas'" ; Sent: Friday, August 16, 2013 1:29 PM > > > I'm a bit confused at this point about when those decisions were changed, > > and how we intend to proceed. > > I have one possible suggestion, after looking at the structure of the drafts > again. What I think we might want to do is to pull the bgp use cases from > draft-white to bolster the bgp use cases draft, moving the bgp use cases > draft to an editor/contributor format (since it already has a lot of co's). > The remaining use cases can be put into a rib uses cases draft, where we can > collect all the various "routing protocol agnostic" use cases. Again, we > could move this to editor/contributor --I'll be happy to hold the editor > baton for this new draft. > > There may be some question about what fits where (are all the bgp uses > really limited to bgp? Do we want a separate overlay use cases, or should > these fall into the protocol related draft they work with?), but I think > this is a workable model to get all the use cases organized into a > reasonable set of drafts that can be added to, etc., until the WG gets to > the point of having a 'first set' of use cases on the table. After this > initial batch is actually published, then it's going to be better to > continue with individual drafts for individual use cases, rather than > bis'ing this set, I think. > > Thoughts? Russ The recurring thought I have is that we are pressing on with design - architecture, info-model etc - and have not, AFAIK, agreed requirements, which the use cases should do, or at least bring out into the open. So I would oppose the adoption of any design document until the requirements have greater clarity. Your comment about boiling oceans I see rather as boiling separate lakes, each lake being firmly founded on a different view of use cases, and I think that that has emerged in the discussion of the info-model. So, for me, use cases comes first, one document preferred, more than one ok; the rest should wait. Tom Petch > > Russ From edc@google.com Fri Aug 16 11:06:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9611E81E3 for ; Fri, 16 Aug 2013 11:06:38 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tU8IdLJt1Ee for ; Fri, 16 Aug 2013 11:06:38 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FD11E81CF for ; Fri, 16 Aug 2013 11:06:37 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so1758766wgh.21 for ; Fri, 16 Aug 2013 11:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Dp5kRuZZQHWmjv09TzUqoEFNwLsmpwjyxx16yXlyo1g=; b=Le6QOHCq8NL0F7wg6fQ1q+CHH7VQ+Wkrl51+X0v6iUegL5D4Ci7wJZXhJx0LO85IbY kEb4WsA8ADFIfyUapqfZG0mstpuvBp61yGvZYtOUfpi0mIUmLaJNB5KNMy+Bx9LrTw+p rxM2gAXO+aM7rMTkQYYt01GUICYpWBXTTgMYWKJ5Vh/UgcxKF8GlUda8dQUJH1MzKbBe y1oeMpgjbu3SYes6HhmyXY90/A0w7NQoZd7ANftugXcyMU01r2SNOCYf/aP6Y7foTqvr K8yR8S8YL/e2xKprBlPOdJgUa1/k7r9BDiJiI4wpGCkwsvqQA9U15r+b4mk7x7RYy0Td VQaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Dp5kRuZZQHWmjv09TzUqoEFNwLsmpwjyxx16yXlyo1g=; b=Gvhe7qVMJMWf0MaULCXmZ0QpROx6+R/J2DGMBLG8E/nEdr9M6WsHUXGshQLMSxWjf7 fMFYQjbiT81inX+loiUH0ZfOvRP0G/OLStTQSIKx7D+m9R3+t06xqDBNzmH9kiKUiNk1 MjQm3hQJVr7Od3ye2n8tjIRYG4UYuC8wr5Zb1D9f9zK/bKEzu72genCv4Jx8ZXkOKhUS OkkSUyNyk9OOsSqz1Vjalk9eYp8hF3ck0UstntM1TZRQRQ9FZhAaTUMGTe4QHTUxGXJE lYkTx4IxWpf5nIzxNHGm8/iQj2fsoPrSdDhrp+72yGVy5UvADJthwukqMB7hmzMXQ+Rx QbPQ== X-Gm-Message-State: ALoCoQnORGh8KUO/q467PsEMqQMXxHKlat2Ov+EnM45ST9bOXquJqnJNpAzQ5bNrvPjktfOZbucAepxFnchJnaI2uK+X6pnbCnRFkCgs1LM0vo8hW9CvKNPJ8WU0i493V9zXQH+uHxRI5iAsQCxKB9fkN2KknLbK5Kk4dbkDrovpEu8w1zmC3a6LP2GwyuF+ioMGan0jDqQW X-Received: by 10.180.13.174 with SMTP id i14mr79097wic.49.1376676392853; Fri, 16 Aug 2013 11:06:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.99 with HTTP; Fri, 16 Aug 2013 11:05:52 -0700 (PDT) From: Edward Crabbe Date: Fri, 16 Aug 2013 11:05:52 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Results of WG Adoption Call: draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 18:06:40 -0000 We had a lots of great discussion about this draft on both the list and at the last two IETFs. At this point, I believe Alia has addressed all of the concerns raised regarding the draft either on the list, in the draft-atlas-i2rs-architecture-02 draft text or both. There is also sufficiently strong support to warrant adoption as a working group document. We have our first official I2RS WG draft. :) cheers all, -ed From akatlas@gmail.com Fri Aug 16 11:36:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FE821F9AE7 for ; Fri, 16 Aug 2013 11:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q4HJ-oDX-KB for ; Fri, 16 Aug 2013 11:36:47 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7E11E811F for ; Fri, 16 Aug 2013 11:36:42 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uz19so2397824obc.21 for ; Fri, 16 Aug 2013 11:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QucD31VdT5yjaRxAzOlgyiPQUZy2aivqR4IPfhONpLg=; b=PyVgxG9Y9AG7/NRx5oENnAneCv5kvfS02V2Y4DyRmr1sJ/rxIsu+6euAmsaQRnF172 wSHjBq1SDgIAV6OPLVypMlIzM8PhKea7a7L7Ia/FYvF7SqWYYLSOe59QNauc99CX4cjM /SPJ1Ph22432bFZLUzPOri+gqzCe050FFKUEJvLMuK88xtavJUVCmbJ9tBRl6C22m2Vd mg3P5geW0b66tgznsWFYwfICFOjUeGuyplGtolkIJlWY7vN4riJrAnfvijEWcTq7izxs 5HOkHiX33c+1AahZEAixuk/2PLqpLo5U1wuHx8t+sFAASjkApBaID8p6wrZOT+QohazF p0Dg== MIME-Version: 1.0 X-Received: by 10.60.60.167 with SMTP id i7mr1840237oer.58.1376678202070; Fri, 16 Aug 2013 11:36:42 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 11:36:41 -0700 (PDT) In-Reply-To: <01c101ce9aa7$15855a80$4001a8c0@gateway.2wire.net> References: <002c01ce9a10$5f25cc70$1d716550$@riw.us> <4931A85EED76CA48BD52F2D94E7FAB0E088B8EEB@xmb-aln-x09.cisco.com> <01ef01ce9a7c$35570280$a0050780$@riw.us> <01c101ce9aa7$15855a80$4001a8c0@gateway.2wire.net> Date: Fri, 16 Aug 2013 14:36:41 -0400 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=089e0158bab4345b7904e414df9c Cc: Russ White , "Keyur Patel \(keyupate\)" , "i2rs@ietf.org" Subject: Re: [i2rs] Results of WG Adoption Call:draft-keyupate-i2rs-bgp-usecases X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 18:36:47 -0000 --089e0158bab4345b7904e414df9c Content-Type: text/plain; charset=ISO-8859-1 Tom, I definitely want to keep a focus on getting the use-cases better articulated. I've been beating that drum for over 6 months now - heck, about a year. We do have some reasonable individual drafts that describe fairly well various use-cases. As usual, different are interesting to different people. The WG has a very tight schedule in terms of milestones - and we need to make progress on those even while we continue to refine the use-cases. The problem-statement, architecture, RIB info model, and topology info models are all basic constructs that help feed multiple use-cases and help define what I2RS is. Do you have particular concerns on any of those documents? Could you start a separate thread (so it is seen) and we can work on those concerns? Do you have thoughts on the use-cases? Is a particular one interesting to you? Can you help with defining it better or raising the concerns and issues? That is exactly the kind of conversations we should be having on the I2RS mailing list! Regards, Alia On Fri, Aug 16, 2013 at 1:31 PM, t.petch wrote: > ----- Original Message ----- > From: "Russ White" > To: "'Keyur Patel (keyupate)'" ; "'Alia Atlas'" > ; > Sent: Friday, August 16, 2013 1:29 PM > > > > > I'm a bit confused at this point about when those decisions were > changed, > > > and how we intend to proceed. > > > > I have one possible suggestion, after looking at the structure of the > drafts > > again. What I think we might want to do is to pull the bgp use cases > from > > draft-white to bolster the bgp use cases draft, moving the bgp use > cases > > draft to an editor/contributor format (since it already has a lot of > co's). > > The remaining use cases can be put into a rib uses cases draft, where > we can > > collect all the various "routing protocol agnostic" use cases. Again, > we > > could move this to editor/contributor --I'll be happy to hold the > editor > > baton for this new draft. > > > > There may be some question about what fits where (are all the bgp uses > > really limited to bgp? Do we want a separate overlay use cases, or > should > > these fall into the protocol related draft they work with?), but I > think > > this is a workable model to get all the use cases organized into a > > reasonable set of drafts that can be added to, etc., until the WG gets > to > > the point of having a 'first set' of use cases on the table. After > this > > initial batch is actually published, then it's going to be better to > > continue with individual drafts for individual use cases, rather than > > bis'ing this set, I think. > > > > Thoughts? > > Russ > > The recurring thought I have is that we are pressing on with design - > architecture, info-model etc - and have not, AFAIK, agreed requirements, > which the use cases should do, or at least bring out into the open. So > I would oppose the adoption of any design document until the > requirements have greater clarity. > > Your comment about boiling oceans I see rather as boiling separate > lakes, each lake being firmly founded on a different view of use cases, > and I think that that has emerged in the discussion of the info-model. > > So, for me, use cases comes first, one document preferred, more than one > ok; the rest should wait. > > Tom Petch > > > > > Russ > > > --089e0158bab4345b7904e414df9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tom,

I definitely want to keep a focus = on getting the use-cases better articulated. =A0I've been beating that = drum for over 6 months now - heck, about a year. =A0We do have some reasona= ble individual drafts that describe fairly well various use-cases. =A0As us= ual, different are interesting to different people.

The WG has a very tight schedule in terms of milestones= - and we need to make progress on those even while we continue to refine t= he use-cases. =A0

The problem-statement, architect= ure, RIB info model, and topology info models are all basic constructs that= help feed multiple use-cases and help define what I2RS is. =A0 Do you have= particular concerns on any of those documents? =A0Could you start a separa= te thread (so it is seen) and we can work on those concerns?

Do you have thoughts on the use-cases? =A0Is a particul= ar one interesting to you? =A0Can you help with defining it better or raisi= ng the concerns and issues? =A0That is exactly the kind of conversations we= should be having on the I2RS mailing list!

Regards,
Alia


On Fri, Aug 16, 2013 at 1:31 PM, = t.petch <ietfc@btconnect.com> wrote:
----= - Original Message -----
From: "Russ White" <russw@riw.= us>
To: "'Keyur Patel (keyupate)'" <keyupate@cisco.com>; "'Alia Atlas'"= ;
<akatlas@gmail.com>; <i2rs@ietf.org>
Sent: Friday, August 16, 2013 1:29 PM
>
> > I'm a bit confused at this point about when those decisions w= ere
changed,
> > and how we intend to proceed.
>
> I have one possible suggestion, after looking at the structure of the<= br> drafts
> again. What I think we might want to do is to pull the bgp use cases from
> draft-white to bolster the bgp use cases draft, moving the bgp use
cases
> draft to an editor/contributor format (since it already has a lot of co's).
> The remaining use cases can be put into a rib uses cases draft, where<= br> we can
> collect all the various "routing protocol agnostic" use case= s. Again,
we
> could move this to editor/contributor --I'll be happy to hold the<= br> editor
> baton for this new draft.
>
> There may be some question about what fits where (are all the bgp uses=
> really limited to bgp? Do we want a separate overlay use cases, or
should
> these fall into the protocol related draft they work with?), but I
think
> this is a workable model to get all the use cases organized into a
> reasonable set of drafts that can be added to, etc., until the WG gets=
to
> the point of having a 'first set' of use cases on the table. A= fter
this
> initial batch is actually published, then it's going to be better = to
> continue with individual drafts for individual use cases, rather than<= br> > bis'ing this set, I think.
>
> Thoughts?

Russ

The recurring thought I have is that we are pressing on with de= sign -
architecture, info-model etc - and have not, AFAIK, agreed requirements, which the use cases should do, or at least bring out into the open. =A0So I would oppose the adoption of any design document until the
requirements have greater clarity.

Your comment about boiling oceans I see rather as boiling separate
lakes, each lake being firmly founded on a different view of use cases,
and I think that that has emerged in the discussion of the info-model.

So, for me, use cases comes first, one document preferred, more than one ok; the rest should wait.

Tom Petch

>
> Russ



--089e0158bab4345b7904e414df9c-- From internet-drafts@ietf.org Fri Aug 16 12:08:35 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98AB11E8186; Fri, 16 Aug 2013 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AvlX5668vjH; Fri, 16 Aug 2013 12:08:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C32AA11E8172; Fri, 16 Aug 2013 12:08:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130816190814.9679.20501.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 12:08:14 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-architecture-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 19:08:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : An Architecture for the Interface to the Routing System Author(s) : Alia Atlas Joel Halpern Susan Hares Dave Ward Thomas D. Nadeau Filename : draft-ietf-i2rs-architecture-00.txt Pages : 21 Date : 2013-08-16 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet's routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-architecture-00 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/ From edc@google.com Fri Aug 16 12:08:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2211E8217 for ; Fri, 16 Aug 2013 12:08:51 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTmzQbgusgTf for ; Fri, 16 Aug 2013 12:08:51 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD011E8172 for ; Fri, 16 Aug 2013 12:08:35 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so1208328wiw.3 for ; Fri, 16 Aug 2013 12:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=blwIx32MgKNckI2Tm61p65kKbbfbVZ7rf9esz/nQKvU=; b=IGPNqymi8pEvVsHFUQpZamdnwcrrN1e7ev828QIsCcTYVCJZRvis6RnXO/gAUil++0 JcdIIJZiciGiudw8He2FETBrLePyaPbdAmGPR0ZDfhKkmBpohBaYgUiHUYb8GQpp++ax szABGIe8bGBhFmErBElTE3HRcWJJC9eL8yH8lF90X8kw3yf11cEfLtokfQ9gUK3ZQs/k BKFDRg06Bb+GuMvo7wzGH+4X3G4KopZ6033w5V8X0zmpQGIiNxZJUBx+qbGsF2Owk45U uA/hBpgh3AXwq3Ob42dRs/gAV15ZSp7a8QimlfpYkdOuPXrb8s+0xcasCNLbhq4gWU4y C2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=blwIx32MgKNckI2Tm61p65kKbbfbVZ7rf9esz/nQKvU=; b=U3BWwlq89Vab1yIM2wfgEaEzTnCtOdTNfhTMJVJK694wUvoZBbkbj2SzRqMdckr4qU +oRX+sw1iDIdEjykW22ENFlgj6WwkJTMKvfB+U/bnVN/S0TnEKOUCU/87H6R+g70xzra 27VDcXTaaLaXO8FZ30is+5pfLxBXLnNev4FfGISzafNtTQX8mqEwUBRFaEBrafTG+crv QbX4AyjVnzkrCZOqm7MkSyo73ziNpMeGhnD9r3G3lnn/j6QzFE5qpPqmSsQlLWRtPgic kWMpvJnTUFvTaqrAnzqab1fQlVVFCPdkQsqXs25YPs8yVa5z69yu+RSdUugCdRMQr6JG 71Qg== X-Gm-Message-State: ALoCoQnyrYPjwMJkAuG1ZAEHh9W2/F9xY3+I1AL+Y1Pre4c4DKGra5WTX3r7ql/b1f3wZ37t2Xm5UpMtwhUo5oUpnqiFMwtBh4Jzag0eYPBNxskLEl/f3hEehZlnATTC8oTIZgVv2N2CYGNrE1fVK7X7URJg92k8Yxsm6cdb2QacXEsPI/LOCu8xHDxqapqB9a4p2RQpJUDO X-Received: by 10.194.240.129 with SMTP id wa1mr2215816wjc.31.1376680112066; Fri, 16 Aug 2013 12:08:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.99 with HTTP; Fri, 16 Aug 2013 12:07:51 -0700 (PDT) From: Edward Crabbe Date: Fri, 16 Aug 2013 12:07:51 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Results of WG Adoption Call: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 19:08:53 -0000 The poll has demonstrated substantial support for adoption of this document. I believe all substantive, draft-specifics comments raised on the list have been reflected in draft-atlas-i2rs-problem-statement-02. This draft has now been accepted as an I2RS working group document. From internet-drafts@ietf.org Fri Aug 16 12:19:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3286911E82A8; Fri, 16 Aug 2013 12:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgGnLbruyQp2; Fri, 16 Aug 2013 12:19:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C5411E8118; Fri, 16 Aug 2013 12:19:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130816191919.17553.40621.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2013 12:19:19 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 19:19:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : Interface to the Routing System Problem Statement Author(s) : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-00.txt Pages : 10 Date : 2013-08-16 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-00 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/ From akatlas@gmail.com Fri Aug 16 12:47:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F811E82C5 for ; Fri, 16 Aug 2013 12:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7FtkcPt1J50 for ; Fri, 16 Aug 2013 12:47:34 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id F322311E82B3 for ; Fri, 16 Aug 2013 12:47:33 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so2474864obp.22 for ; Fri, 16 Aug 2013 12:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v49VRnKCa/zmBd1E8mwZpedGPDLnhzofWpbBtYmsvK4=; b=FxEPqQ4BV6HxvQlXDg5zIgBFlvMVB+cYN+xDnJ8mfuC4kNEQpP/c3C/Stx5J9FN3T2 Dk5+0q2pfbNUcsHSL4LdoU8mBcZ2DxWVIi5wxwVxime4A4KFXUeeiDi+0t0T6eIReAkN DfD0QorCxMpoWNqEMLcJ8PAup87OPB63VAo45n5ZLjBLdAvS86tXSO3cThV7n4kw6EVr tjfBTP/40j64kGVjvtjV6vIU/xBvtaxYpJFwFvML8Jciv0tiCfcm5Vz2k/A/J2sBqWm0 hnlT8UbfLD6TMBg3Y7mPgwl1EgAlUXvlmUjJR61XPVK7a/qYgyFTAGPUpOlHK+ckjgEx sPWw== MIME-Version: 1.0 X-Received: by 10.60.121.103 with SMTP id lj7mr2667808oeb.25.1376682452542; Fri, 16 Aug 2013 12:47:32 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 12:47:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Aug 2013 15:47:32 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=047d7b414e9e8d6aea04e415dc39 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Results of WG Adoption Call: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 19:47:34 -0000 --047d7b414e9e8d6aea04e415dc39 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Ed. I've submitted this as draft-ietf-i2rs-problem-statement-00. The only difference is fixing a typo in Sec 2. Alia On Fri, Aug 16, 2013 at 3:07 PM, Edward Crabbe wrote: > The poll has demonstrated substantial support for adoption of this > document. I believe all substantive, draft-specifics comments raised > on the list have been reflected in > draft-atlas-i2rs-problem-statement-02. > > This draft has now been accepted as an I2RS working group document. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b414e9e8d6aea04e415dc39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Ed. =A0I've submitted this as draft-ietf-i2rs-= problem-statement-00. =A0The only difference is fixing a typo in Sec 2.
Alia


On Fri, Aug 16, 2013 at 3:07 PM, Edward Crabbe <edc@google.com>= wrote:
The poll has demonstrated =A0substantial support for adoption of this
document. =A0I believe all substantive, draft-specifics comments raised
on the list have been reflected in
draft-atlas-i2rs-problem-statement-02.

This draft has now been accepted as an I2RS working group document.
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b414e9e8d6aea04e415dc39-- From akatlas@gmail.com Fri Aug 16 12:52:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA211E8203 for ; Fri, 16 Aug 2013 12:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4LrSN1u7iB6 for ; Fri, 16 Aug 2013 12:52:51 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8311E8129 for ; Fri, 16 Aug 2013 12:52:47 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so2432655obc.26 for ; Fri, 16 Aug 2013 12:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/VhdnSxdXJRxx2lX0YmtTRp60W019Lmg+ih08paDqGI=; b=ui4eqEdU4MVI5spv8Kc2zg7v+ANZ5NH82c964iQ7g+/NlBm2bNEaU8JAu0O6/Kd1E9 a2m4ImveDfpgpkYahPrXghxz/D2Fauj4FIIWre6lQpx5b3WjKI4jMFpnyDyj1ptvi0EW x+dr+TFfDjD+AEr0lJN8OzdCMEdW1OiMJo8S3bixOlQ2mCkqrp1ETeBAsE5fk0LGLBtF pEKWqLmDglZM8JGqDsRIphoJqJE6Xcw0ceD/tJJFmSNiI+1Z+WF34tQlzjkdYFGwBjIB MsPCc/7ttS+RG/MAaKvbhUs5Z28k8kTzYCyW9Kh5T/Csi4k6TmndoKJJ0gZVk4pkpRVG sV5Q== MIME-Version: 1.0 X-Received: by 10.182.19.229 with SMTP id i5mr2687533obe.46.1376682767273; Fri, 16 Aug 2013 12:52:47 -0700 (PDT) Received: by 10.182.221.98 with HTTP; Fri, 16 Aug 2013 12:52:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Aug 2013 15:52:47 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=001a11c298244fd37304e415ef19 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Results of WG Adoption Call: draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 19:52:52 -0000 --001a11c298244fd37304e415ef19 Content-Type: text/plain; charset=ISO-8859-1 Thanks. I've submitted this as draft-ietf-i2rs-architecture-00. The changes (based on discussion on the list) are: * updated "Routing" to "Routing and Signaling" in Figure 1 and associated text. * defined "notification scope" in the terminology * Added event examples in Sec 5.4.2 o subscribing to an information stream of route changes o receiving notifications about peers coming up or going down The truly curious can look at: http://tools.ietf.org//rfcdiff?url1=draft-atlas-i2rs-architecture-02&url2=draft-ietf-i2rs-architecture-00 Alia On Fri, Aug 16, 2013 at 2:05 PM, Edward Crabbe wrote: > We had a lots of great discussion about this draft on both the list > and at the last two IETFs. At this point, I believe Alia has > addressed all of the concerns raised regarding the draft either on the > list, in the draft-atlas-i2rs-architecture-02 draft text or both. > There is also sufficiently strong support to warrant adoption as a > working group document. > > We have our first official I2RS WG draft. :) > > cheers all, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c298244fd37304e415ef19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks. =A0I've submitted this as draft-ietf-i2rs-arch= itecture-00. =A0
The changes (based on discussion on the list) are:

* =A0updated "Routing" to "Routing and= Signaling" in Figure 1 and associated text.
* defined "notification scope" in the terminology
= * Added event examples in Sec 5.4.2=A0
=A0 =A0 o =A0subscribing t= o an information stream of route changes
=A0 =A0o =A0receiving no= tifications about peers coming up or going down

The truly curious can look at:

Alia
On = Fri, Aug 16, 2013 at 2:05 PM, Edward Crabbe <edc@google.com> = wrote:
We had a lots of great discussion about this= draft on both the list
and at the last two IETFs. =A0At this point, I believe Alia has
addressed all of the concerns raised regarding the draft either on the
list, in the draft-atlas-i2rs-architecture-02 draft text or both.
There is also sufficiently strong support to warrant adoption as a
working group document.

We have our first official I2RS WG draft. =A0:)

cheers all,
=A0 =A0-ed
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--001a11c298244fd37304e415ef19-- From jclarke@cisco.com Fri Aug 16 13:04:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4DA11E8203 for ; Fri, 16 Aug 2013 13:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpMmqMsFYq1e for ; Fri, 16 Aug 2013 13:03:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C66B411E82B3 for ; Fri, 16 Aug 2013 13:03:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GK3qng009136; Fri, 16 Aug 2013 22:03:53 +0200 (CEST) Received: from dhcp-10-150-54-67.cisco.com (dhcp-10-150-54-67.cisco.com [10.150.54.67]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7GK3qRV014241; Fri, 16 Aug 2013 16:03:52 -0400 (EDT) Message-ID: <520E85A8.1080608@cisco.com> Date: Fri, 16 Aug 2013 16:03:52 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] Results of WG Adoption Call: draft-atlas-i2rs-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 20:04:02 -0000 On 8/16/13 3:52 PM, Alia Atlas wrote: > Thanks. I've submitted this as draft-ietf-i2rs-architecture-00. > The changes (based on discussion on the list) are: > > * updated "Routing" to "Routing and Signaling" in Figure 1 and > associated text. > * defined "notification scope" in the terminology > * Added event examples in Sec 5.4.2 > o subscribing to an information stream of route changes > o receiving notifications about peers coming up or going down > > The truly curious can look at: > http://tools.ietf.org//rfcdiff?url1=draft-atlas-i2rs-architecture-02&url2=draft-ietf-i2rs-architecture-00 Thanks, Alia! Joe > > Alia > On Fri, Aug 16, 2013 at 2:05 PM, Edward Crabbe > wrote: > > We had a lots of great discussion about this draft on both the list > and at the last two IETFs. At this point, I believe Alia has > addressed all of the concerns raised regarding the draft either on the > list, in the draft-atlas-i2rs-architecture-02 draft text or both. > There is also sufficiently strong support to warrant adoption as a > working group document. > > We have our first official I2RS WG draft. :) > > cheers all, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From internet-drafts@ietf.org Wed Aug 21 10:35:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DA711E83C2; Wed, 21 Aug 2013 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AK0rDUE2Hny; Wed, 21 Aug 2013 10:35:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B7211E80FA; Wed, 21 Aug 2013 10:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821173517.14062.96486.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 10:35:17 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-nitinb-i2rs-rib-info-model-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:35:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : Routing Information Base Info Model Author(s) : Nitin Bahadur Ron Folkes Sriganesh Kini Jan Medved Filename : draft-nitinb-i2rs-rib-info-model-02.txt Pages : 26 Date : 2013-08-21 Abstract: Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager install state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-nitinb-i2rs-rib-info-model-02 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/ From nitinb@juniper.net Wed Aug 21 13:46:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8537721F9FC6 for ; Wed, 21 Aug 2013 13:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxQTMykQcSb3 for ; Wed, 21 Aug 2013 13:46:42 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3442C21F9E96 for ; Wed, 21 Aug 2013 13:46:42 -0700 (PDT) Received: from mail196-db8-R.bigfish.com (10.174.8.233) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.22; Wed, 21 Aug 2013 20:46:41 +0000 Received: from mail196-db8 (localhost [127.0.0.1]) by mail196-db8-R.bigfish.com (Postfix) with ESMTP id 57FA3AC01F7 for ; Wed, 21 Aug 2013 20:46:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received-SPF: pass (mail196-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(24454002)(377424004)(377454003)(479174003)(51704005)(189002)(69226001)(74876001)(4396001)(47736001)(79102001)(81542001)(81342001)(31966008)(47446002)(74662001)(74502001)(76482001)(53806001)(54316002)(80976001)(54356001)(77096001)(56776001)(56816003)(74706001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(76176001)(36756003)(63696002)(46102001)(47976001)(66066001)(49866001)(50986001)(83072001)(19580405001)(19580395003)(76796001)(81816001)(81686001)(76786001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB051; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.54; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail196-db8 (localhost.localdomain [127.0.0.1]) by mail196-db8 (MessageSwitch) id 1377117998973974_23323; Wed, 21 Aug 2013 20:46:38 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.226]) by mail196-db8.bigfish.com (Postfix) with ESMTP id EA81E1401D9 for ; Wed, 21 Aug 2013 20:46:38 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 21 Aug 2013 20:46:38 +0000 Received: from BL2PR05MB051.namprd05.prod.outlook.com (10.255.228.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Wed, 21 Aug 2013 20:46:36 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB051.namprd05.prod.outlook.com (10.255.228.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 21 Aug 2013 20:46:29 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.39]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.39]) with mapi id 15.00.0745.000; Wed, 21 Aug 2013 20:46:29 +0000 From: Nitin Bahadur To: "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-nitinb-i2rs-rib-info-model-02.txt Thread-Index: AQHOnpTb6HRChWmEc0mU7Ra1hgdT8ZmfrIWA Date: Wed, 21 Aug 2013 20:46:28 +0000 Message-ID: In-Reply-To: <20130821173517.14062.96486.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [66.129.224.54] x-forefront-prvs: 0945B0CC72 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [i2rs] I-D Action: draft-nitinb-i2rs-rib-info-model-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 20:46:53 -0000 We've posted a new version of the draft. This version is in line with the IETF presentation and addresses comments on the list. Major changes include: - Resolution of terminology and grammar - Added diagrams representing the key objects (similar to IETF slides) - Text clarifications in multiple places (based on list review) Thanks Nitin Bahadur On 8/21/13 10:35 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Interface to the Routing System Working >Group of the IETF. > > Title : Routing Information Base Info Model > Author(s) : Nitin Bahadur > Ron Folkes > Sriganesh Kini > Jan Medved > Filename : draft-nitinb-i2rs-rib-info-model-02.txt > Pages : 26 > Date : 2013-08-21 > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager install state into the > hardware; for packet forwarding. This draft specifies an information > model for the RIB to enable defining a standardized data model. Such > a data model can be used to define an interface to the RIB from an > entity that may even be external to the network device. This > interface can be used to support new use-cases being defined by the > IETF I2RS WG. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-nitinb-i2rs-rib-info-model-02 > > >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/ > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs > > From edc@google.com Mon Aug 26 19:49:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA8421F9D7A for ; Mon, 26 Aug 2013 19:49:49 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN4PoXaUbnRx for ; Mon, 26 Aug 2013 19:49:49 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E81CA21F98D8 for ; Mon, 26 Aug 2013 19:49:48 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t58so3319557wes.24 for ; Mon, 26 Aug 2013 19:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=OFpWHA2YBDqORpFz3oJXrkMHWcyrYsao7axe5Uyc7fw=; b=J56DIgb0e0Tu+Men4rtwWG3IbiDQgFtsP4nf0cM198A4USzh5EU89gnln+kCHv26VW ohI4Mv2hdffXeRaTwHLbGN7D9DZueosIMx8BpW/7PDqPQi1t5l6KmSXw4mfLFFeNcAbL IWx6vT3d6cOXn0Ir3uWYqj6BGcMk5540lTRawywqBMfpgZ9j9xkWYlfrA6LL7ll7Scbw ea20E1BbFZ1q9EOIk4VKhfeMgn2fG1jkxZb9UwPN8tfK3e+45gz0zXGExtGLt4DKEN+/ EeD8mdJ6AFYSHUghi7dJw+yojzhKWS2Cm0gMtL94gLKBMS3iY5v6YZEZzWaxZyEFFuA4 lxWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=OFpWHA2YBDqORpFz3oJXrkMHWcyrYsao7axe5Uyc7fw=; b=IYEHe8hE26j3FL3LsGvkBE978p95mu6UCzB+Cse9mQccsi/S75J5Lp2XvGLp7L5jJF g11wBtSWyUMLrB+RHDygWCSXvqxGwKLV2lGK+94TpmEWSSUlh2SZHBFguU+Y3/GCgAoC i4OiK+HJEybS/gdtIOlLcdKGEdht32NWYh3E5Au04dDcyXwnb1hirtU039oKeMIr3HwX mlul5xcDgjxbB8nM8p104ejP5DC2cMAfBeoNv4ixqGAqRUPCMhGRzn8JPFa5A5/G61zX idsRSpvc703jSA1BYD7h/mb8RWK6ondKf1lGdBvlGc4RCNBJA/PMZfxi26y11D7QNFuO uVMw== X-Gm-Message-State: ALoCoQkm4h6lTC6TKykXjN57YX3AD0IDFIZX4cABaA+ptK05ZvPQlu23CZB51rx9BdioFkQH++X6pHXbdjT99nDiHQmPAgs7x3Vr63HbkOTgyOBG/EFaDATqN+HzbEpiYVyeCLaBsU5+h8mLR2Rq8toBw+7iWn3Ab30+aJbBkI/xe+5zH6jRsLIJ5TRilirptPl1Dh1WI8Gj X-Received: by 10.180.183.180 with SMTP id en20mr9567378wic.18.1377571780618; Mon, 26 Aug 2013 19:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Mon, 26 Aug 2013 19:49:00 -0700 (PDT) From: Edward Crabbe Date: Mon, 26 Aug 2013 19:49:00 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 02:49:50 -0000 Hey all; Nitin published an updated version of his RIB info model draft, available at: http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 Please review this draft and comment on whether it should be adopted as an I2RS document. This WG call for adoption will finish on September 9th. best, -ed From jclarke@cisco.com Mon Aug 26 20:46:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264CB11E8139 for ; Mon, 26 Aug 2013 20:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeTtamOTyHZE for ; Mon, 26 Aug 2013 20:46:22 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A932A21E804D for ; Mon, 26 Aug 2013 20:46:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7R3kGdW014644; Tue, 27 Aug 2013 05:46:16 +0200 (CEST) Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com [10.117.46.167]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7R3kFUZ012620; Mon, 26 Aug 2013 23:46:15 -0400 (EDT) Message-ID: <521C2107.9040704@cisco.com> Date: Mon, 26 Aug 2013 23:46:15 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Edward Crabbe References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 03:46:26 -0000 On 8/26/13 10:49 PM, Edward Crabbe wrote: > Hey all; > > Nitin published an updated version of his RIB info model draft, available at: > > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 > > Please review this draft and comment on whether it should be adopted > as an I2RS document. > > This WG call for adoption will finish on September 9th. With the changes, I support adoption. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From tnadeau@lucidvision.com Tue Aug 27 04:28:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEEF11E8290 for ; Tue, 27 Aug 2013 04:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hTwL+jMmSAf for ; Tue, 27 Aug 2013 04:28:37 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1315611E8179 for ; Tue, 27 Aug 2013 04:28:36 -0700 (PDT) Received: from [192.168.1.100] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 94CAE2548D14; Tue, 27 Aug 2013 07:28:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Tue, 27 Aug 2013 07:28:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <018FF5AD-F0AC-4F15-9AE9-BA3BDCC1CCE1@lucidvision.com> References: To: Edward Crabbe X-Mailer: Apple Mail (2.1508) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 11:28:41 -0000 Support. It is a good place to start this work. --Tom =20 On Aug 26, 2013:10:49 PM, at 10:49 PM, Edward Crabbe = wrote: > Hey all; >=20 > Nitin published an updated version of his RIB info model draft, = available at: >=20 > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 >=20 > Please review this draft and comment on whether it should be adopted > as an I2RS document. >=20 > This WG call for adoption will finish on September 9th. >=20 > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From tnadeau@lucidvision.com Tue Aug 27 04:48:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FF711E82BC for ; Tue, 27 Aug 2013 04:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMRXCfjCIq1R for ; Tue, 27 Aug 2013 04:48:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E32C011E82BB for ; Tue, 27 Aug 2013 04:48:20 -0700 (PDT) Received: from [172.28.130.28] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 00AA22548E51 for ; Tue, 27 Aug 2013 07:48:19 -0400 (EDT) From: Thomas Nadeau Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 27 Aug 2013 07:48:18 -0400 To: "i2rs@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [i2rs] NOMS2014 call for papers X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 11:48:26 -0000 http://noms2014.ieee-noms.org/call-for-submissions From tokatsu@cisco.com Tue Aug 27 07:38:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B99D11E8356 for ; Tue, 27 Aug 2013 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQNKdkOZjBzn for ; Tue, 27 Aug 2013 07:38:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A208B11E8364 for ; Tue, 27 Aug 2013 07:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2653; q=dns/txt; s=iport; t=1377614319; x=1378823919; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+M8kiRSx1aMQFRXFmf+suJhlx61WtdLtpAo/sBAEKyA=; b=NX7U5P+xQ8eeH8vN3XlEQpGy7vVuHJMg2GcZSpJL/C8470JVvTEgCuSB +lWxtM81+EMWhyfja4EHnZqYDSYcU3DERALx9yGgg0HZ0v6cRVS6ZovAO Ka7ol5o5FU2JDBwrAX4aIxA1r4TamvlIYMmSMtbUjxPngLMv3BzirJroh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJu5HFKtJV2c/2dsb2JhbABZgwc1UcAjgSMWdIIkAQEBBAEBARodNAsMBAIBCA4DBAEBCxQJBycLFAkIAgQOBQiHeQy4TI8zBisHBoMWfQOZHIkOhyWDIIIq X-IronPort-AV: E=Sophos;i="4.89,968,1367971200"; d="scan'208";a="252193991" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 27 Aug 2013 14:38:39 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7REcdam022105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 14:38:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 09:38:38 -0500 From: "Toru Okatsu (tokatsu)" To: Edward Crabbe Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAdcmdi5mdIDUGwd5fuGYvUzJmpFiEQ Date: Tue, 27 Aug 2013 14:38:38 +0000 Message-ID: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 14:38:46 -0000 I support the adoption of this info model document. I also have two feedback of this. In the section 6 which is about RIB grammar, it is better to change the def= inition of and to accommodate not only multicast = routing but also source address base routing. Original: ::=3D [] ::=3D ::=3D ::=3D [] ::=3D ::=3D My comment: ::=3D [] ::=3D ::=3D ::=3D ::=3D [] ::=3D ::=3D ::=3D Another comment is a minor correction. In the section 7.2.3, = should be . Original: ::=3D ( ) [( ) ... ] ::=3D ( ) [( )... ] My comment ::=3D ( ) [( ) ... ] ::=3D ( ) [( )... ] Thanks, Toru > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Edward Crabbe > Sent: Tuesday, August 27, 2013 11:49 AM > To: i2rs@ietf.org > Subject: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 >=20 > Hey all; >=20 > Nitin published an updated version of his RIB info model draft, available > at: >=20 > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 >=20 > Please review this draft and comment on whether it should be adopted as > an I2RS document. >=20 > This WG call for adoption will finish on September 9th. >=20 > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From edc@google.com Thu Aug 29 09:16:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393EC21E8082 for ; Thu, 29 Aug 2013 09:16:24 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oag0tL3jYhxe for ; Thu, 29 Aug 2013 09:16:23 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 138F611E8123 for ; Thu, 29 Aug 2013 09:16:21 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so743965wgh.25 for ; Thu, 29 Aug 2013 09:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=detoSlCCT58Gxy11Zso6Z9HNJbBP777FkXHfJwumzn4=; b=Cxm0nNsXIM55amKTXs7IOnPpAloYn0CyUwpKvPeF7amnTiorCpAdeeJNJYV2rXkH3o bIVw4nIjZtKX/liJG1Pb9fRqtXFOuFzaFgJTWz0cvh7ZvuIB9uJ6lN8h4xSZOaBVVUly +EWiN70Y096LZMRgmjIOAE3jz4mjU3fZ5ChmUyWDVueFZx3tut/7CRP6aXpFRm++bRCf Wkh/7zeQ8Gr1+zeEUR/gFNSrGfXdi5NjjHbo9kGpeEruH5VH226OBU82AsH03oypAksL hdja6fvhABr6g6eUcSu4ik7v6Q80j3Z4aA9OFVLI7pVzne5wlUDhHKu335U5BAAYEwnE HIgA== 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:from:date :message-id:subject:to:content-type; bh=detoSlCCT58Gxy11Zso6Z9HNJbBP777FkXHfJwumzn4=; b=AQUdtxpHZVDEn2flRDoh0Ximz6bzYt+XbvY6jNXOR3bACMFJyV061mDCfxvOcQdlBb GKg4UuJ8jAs5rZTF28zryckWiV/Ma7fwklW4BMfI3vqo1YJYUsh6gwql8DC+CFGYFEB7 KTKdYDwjVJgOlCFHfZWda+FJD+thNXcA2A6u1g4klJx8YtaxcBauYRwy+kpmk/JF9Lus tYsZ+qdUO4WI8rJ4nHRegiVEINPQGcUm9U3MAXeKTa3TZINXWJOsRALFYoNUh4NLfSCy zXHyO4p896Wabc+KF5E28rSx3zHng58qNnhjX8kXgbjXzK3F2VnMVRHvIyALEanXVd0T 9E1g== X-Gm-Message-State: ALoCoQn86oQufl+QxbDBC8gAUJuHo0zh3SqiruJr0oycWSPz4VNBWe0ZLVSYOe65962Y3zAlrDVRZ75gwdIqoFUwebENc3Dj+18QA6z+pqKYx3+MdFwMDOtknxT/smod2U3TBl4bmYqK/T+vHXyCPoeAgQnIWThRfUCD+hmJXHKn4J9Mc5o+u7P5ZRDh5Z7iqsy+5pt/IP9u X-Received: by 10.180.78.229 with SMTP id e5mr15284656wix.58.1377792980620; Thu, 29 Aug 2013 09:16:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Thu, 29 Aug 2013 09:15:39 -0700 (PDT) In-Reply-To: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> References: <521F5498.803@qti.qualcomm.com> <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> From: Edward Crabbe Date: Thu, 29 Aug 2013 09:15:39 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Fwd: FW: Mail lost yesterday X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:16:24 -0000 FYI ---------- Forwarded message ---------- From: Adrian Farrel Date: Thu, Aug 29, 2013 at 7:46 AM Subject: FW: Mail lost yesterday For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups. From nvsrinivas@gmail.com Thu Aug 29 23:44:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A272B21F9FBE for ; Thu, 29 Aug 2013 23:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IWbt3ClriJh for ; Thu, 29 Aug 2013 23:44:16 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id ED72111E80E9 for ; Thu, 29 Aug 2013 23:44:13 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1947055pab.27 for ; Thu, 29 Aug 2013 23:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=AqNQYNCyioTrMXEjOL+TsLcPyWnhJiPeZeRDgdibbMI=; b=faBnPA8SKXbJcZxyJba0G+gimmveufazldwqOc76iU630+SNjrFUCIGhDAOVP3v3K2 g95/yoXQlfxSlkpmU80c0CU36UFWychiislnzkvIcMKBlN4BucwMiOC3cdCg+XeVE7/I PVL9TrohbbSJ+vxy9HpbRuwZpQGr8CICajz/IqVODLD6tgCnGaEfYBNwGBuU+uTKd2Oa u5oztVmygLNjfEYa3fSoq1MsT599Oo9sugD28tGNvBG9i4FqXOr06wBPSnA3QWEXrS1K JmoKwKk/iZ13rGiD5AyTfsz6Tk17TF7wKJa92zjBJVHSbq+5PnCgIvSMV5JxsSAuE0vd ROBA== X-Received: by 10.68.196.37 with SMTP id ij5mr8025037pbc.175.1377845053697; Thu, 29 Aug 2013 23:44:13 -0700 (PDT) Received: from [192.168.0.101] (c-98-207-211-136.hsd1.ca.comcast.net. [98.207.211.136]) by mx.google.com with ESMTPSA id xe9sm42384451pbc.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 23:44:12 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <70022A1B-BB62-47F6-88AC-2563723E5FD4@gmail.com> X-Mailer: iPad Mail (10B329) From: nvsrinivas@gmail.com Date: Thu, 29 Aug 2013 23:44:11 -0700 To: Edward Crabbe Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 06:44:16 -0000 draft-02 is good but the RIB grammar still needs refinement as commented on d= raft-00 to the original authors. Nexthop grammar as proposed is not kosher enough and would lead to incorrect= modeling. - Next hop grammar should unwrap itself to a route or an interface to not ha= ve dangling terms for example cannot end with a tunnel encap. - Interface has to be defined in the grammar. - (minor) next hop term is overused loosing its true meaning. (Need to have a= better term for next hop chain) Thanks --Srinivas On Aug 26, 2013, at 7:49 PM, Edward Crabbe wrote: > Hey all; >=20 > Nitin published an updated version of his RIB info model draft, available a= t: >=20 > http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-02 >=20 > Please review this draft and comment on whether it should be adopted > as an I2RS document. >=20 > This WG call for adoption will finish on September 9th. >=20 > best, > -ed > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From swhyte@google.com Fri Aug 30 13:46:54 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12D211E8113 for ; Fri, 30 Aug 2013 13:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ7WPZ1mRL05 for ; Fri, 30 Aug 2013 13:46:53 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08A11E80FA for ; Fri, 30 Aug 2013 13:46:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so2322998pbc.3 for ; Fri, 30 Aug 2013 13:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QIBCiFNVMJOfKaZYniNmpHzPOWffB4w83MrZZ8QmUYw=; b=IFS1HXvwSVwni6K39IKRe9cXgBQRf882+9Bg+qISjEPGlOChqCSpvBzeRYSH8xFqxP zBsmhqdevOJXIPTqnMWTlaDF4+1VNN62pFHd5YDG3tSVO3THs13VNuekz0dKIvIpoQvc HlGY6X1gwL6TCtIavXKiWl8xnNN+f+xEOJudbPPppzjgPzdZCO85U3wwwjlap8OY4VIx /TUnECvd1kz+jlxn6hyUstS1jMNO2sqoEWgBXLaRothV60xkz6foZA92/CGsDKCMTlVl M5LGfeoaZEJ8xW2P9nwq7d9fFrOJSDt19aJT0/fTwsi7N3a2bYr7LCuHZUwNw4kJHa3o V5Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=QIBCiFNVMJOfKaZYniNmpHzPOWffB4w83MrZZ8QmUYw=; b=bfuDH2GP1cIrbCBfy001ypZ/dYPCGFwBHlErWwP/rFFMeUvaSUv8mafXDo0LtOfdaH lAnFZibetQWr+UtcV+HqJfZ7QQuynGXjanrL60ekIyf8uJ/5w+zX8tP5m0qLPZVL+dv1 9yaG9mqfS2KzZDsjwUuFTzN6rlk/TJcMyzQg4Nutb1WeU3QJPg0HN3NEdxNMgK5KVMEh PJEQ0VTaHsv2nyfVKiZwVqX7pQmku1xQJ7IXmYKLUYf7dGNPa4DnOc6NNO3tPLj1EmFd vzKPZbxbVMtxN6xLfvrcfhxzUPxlwcExS53uci6iR8dhkKfhbgXNLmDIRwDSHJirO7FB OZeQ== X-Gm-Message-State: ALoCoQmkQwf7iMlNxVdDKqqwPgRaAE5FHX7bGM2lYjYI9gtMkFuVflEZavRhKlUV+ExcqEizdivjTZx06TkIYuoFHk/PKjYBUFdm3h2qxuQfwmFjPEFg8gIw1J02LGhjNA3wxR662HJJLAqirvXflXLT1DlJuO7myhSG9rCILRP89S2CoIxmsn4sXCNgAA+93NHudrGi5Cqm X-Received: by 10.67.30.225 with SMTP id kh1mr12808493pad.148.1377895612680; Fri, 30 Aug 2013 13:46:52 -0700 (PDT) Received: from localhost ([2620:0:1000:3202:baac:6fff:fe7c:df72]) by mx.google.com with ESMTPSA id yo2sm45651pab.8.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 13:46:51 -0700 (PDT) Date: Fri, 30 Aug 2013 13:46:50 -0700 From: Scott Whyte To: Russ White Message-ID: <20130830204650.GA12707@google.com> References: <520BE621.2090608@cisco.com> <520BFAB6.3040406@cisco.com> <20130815070648.GA8153@elstar.local> <01f301ce9a7e$62b94970$282bdc50$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f301ce9a7e$62b94970$282bdc50$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: i2rs@ietf.org, 'Carlos Pignataro' , 'Joe Marcus Clarke' , 'Juergen Schoenwaelder' , 'Andy Bierman' , 'Alia Atlas' , "'Joel M. Halpern'" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:46:55 -0000 On Fri, Aug 16, 2013 at 08:44:43AM -0400, Russ White wrote: > > > register for a notification when state written by client X is changed > > register for a notification when a particular state is changed > > notify when route is installed in FIB > > notify if interface utilization is over high-water threshold or under > low- > > water threshold > > The problem, I think, is that we're still not scoped narrowly enough. This > could well be a set of requirements for a network management system as much > as a set of requirements for an SDN... If we're going to be a new management > system, should we move this WG to the management area, and be done with it? > I think we need to be a little careful about what problems we take on from > day one, so we can really narrow down the work we're actually trying to do, > verses what others are already doing --I don't think we should make our > goal, "we want to be a faster NETCONF." > > So, to limit these: > > 1. So long as the state being written is _routing_ state. > 2. So long as the state being changed is _routing_ state. > 3. This must include when your route is overwritten by another process. > 4. Do we really want to consider everything measurable about an interface a > part of the "routing system," from day one? > > The fourth one is particularly bothersome. I can see where interface state > is part of the "routing state," in some broad sense --in reality, though, > everything that goes on on a "router" or a "switch" is technically part of > the "routing state," including memory fragmentation, memory utilization, > local storage read and write speeds, processor temperature, and even the > color of the box. These things are "routers" and "switches," so everything > they do somehow relates to either "routing" or "switching." Russ, I do not see same the problem you do. Getting high-resolution, bulk statistics off of network nodes with minimal impact to the nodes is required for SDN, and I2RS is a subset of SDN. We do not have a method for doing that today. > > Hence, we need to intentionally underclaim in our scope for the moment, > focusing on a few small areas. We tried to do this with the use cases, but > that's not working so well, so maybe we need to limit our scope in more > intentional ways, like saying, "while we understand that interface state > other than simple up/down can be construed as part of the routing system, > we're simply not going to deal with that right now, because just dealing > with up/down, in combination with all the other stuff we're trying to deal > with, is enough to chew on for about the next 5 years already." > I am willing to propose a use case and draft a framework for generic bulk data collection. I do agree with taking bite-sized chunks; comparing the complexity of reading data off of network nodes and writing data to them, reading is substantially easier and it would be good to get that experience under our belt. It may help inform a decision if the two directions even need separate protocols. Rather than try and specify each and every thing we think is appropriate or necessary for I2RS to advertise, I would instead go with an approach like: - a standardized way for network nodes to publish what they have available - a standardized way for subscribers to select from that list - a method to negotiate both formatting and transport > If we don't intentionally scope ourselves, we're going to end up in the > drink --a WG that simply churns on lots of big plans, but won't ever be > actually implemented in any useful way, because no-one is going to build yet > another network management system into their boxes alongside the fourteen or > fifteen they already have. I am, it's in progress. And rather than make blanket statements one way or the other maybe we should get some operator input. Perhaps they have fifteen NMSes because the IETF has failed to give them a decent solution, and SDN is only going to exacerbate that. -Scott > > At least that's my 2c. > > :-) > > Russ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nitinb@juniper.net Fri Aug 30 14:25:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0521F9F2D for ; Fri, 30 Aug 2013 14:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gulxy0YWhkMh for ; Fri, 30 Aug 2013 14:25:01 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 575C621F9F23 for ; Fri, 30 Aug 2013 14:25:01 -0700 (PDT) Received: from mail120-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Fri, 30 Aug 2013 21:25:00 +0000 Received: from mail120-ch1 (localhost [127.0.0.1]) by mail120-ch1-R.bigfish.com (Postfix) with ESMTP id 9C4AF2401D8; Fri, 30 Aug 2013 21:25:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail120-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(199002)(76176001)(74502001)(47446002)(74662001)(76786001)(36756003)(76796001)(79102001)(53806001)(56776001)(54356001)(59766001)(77982001)(81686001)(65816001)(74876001)(80022001)(66066001)(74706001)(77096001)(56816003)(31966008)(69226001)(74366001)(4396001)(81542001)(50986001)(47976001)(51856001)(83072001)(83506001)(46102001)(63696002)(81816001)(80976001)(76482001)(54316002)(49866001)(47736001)(81342001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB050; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail120-ch1 (localhost.localdomain [127.0.0.1]) by mail120-ch1 (MessageSwitch) id 1377897898747332_27892; Fri, 30 Aug 2013 21:24:58 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail120-ch1.bigfish.com (Postfix) with ESMTP id AC3A034004D; Fri, 30 Aug 2013 21:24:58 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 30 Aug 2013 21:24:58 +0000 Received: from BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 30 Aug 2013 21:24:57 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 30 Aug 2013 21:24:57 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.15]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.47]) with mapi id 15.00.0745.000; Fri, 30 Aug 2013 21:24:56 +0000 From: Nitin Bahadur To: "Toru Okatsu (tokatsu)" Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 Thread-Index: AQHOotAh8RvKRWKS5kiUGkwhgrfht5mpIJsAgASzJYA= Date: Fri, 30 Aug 2013 21:24:56 +0000 Message-ID: In-Reply-To: <2C754117643E1841B7DAA35BAC690E3408614668@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0954EE4910 Content-Type: text/plain; charset="us-ascii" Content-ID: <8A154FEB5F8900429A8C2401FDC3C670@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 21:25:07 -0000 Hi Toru-san, Thanks for your feedback. Some comments as below. >In the section 6 which is about RIB grammar, it is better to change the >definition of and to accommodate not only >multicast routing but also source address base routing. > >Original: > ::=3D [] > ::=3D > ::=3D > > ::=3D [] > ::=3D > ::=3D > >My comment: > ::=3D [] > ::=3D > ::=3D > ::=3D > > ::=3D [] > ::=3D > ::=3D > ::=3D If you are doing source-based routing, then you may or may not need the destination-address. So ::=3D [] is incorrect. The below might be more correct: ::=3D ( []) | ( []) >Another comment is a minor correction. In the section 7.2.3, > should be . > >Original: > ::=3D ( ) > [( ) ... ] > ::=3D ( ) > [( )... ] > >My comment > ::=3D ( ) > [( ) ... ] > ::=3D ( ) > [( )... ] This will be fixed in the next revision. Thanks Nitin