From nobody Tue Apr 1 09:45:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC351A0996 for ; Tue, 1 Apr 2014 09:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeClkdnXH9sE for ; Tue, 1 Apr 2014 09:45:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 802351A088B for ; Tue, 1 Apr 2014 09:45:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F2208C23D; Tue, 1 Apr 2014 12:45:31 -0400 (EDT) Date: Tue, 1 Apr 2014 12:45:31 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140401164531.GI28363@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TUhJjS6B5VLzLc5AhaenIruBfoE Subject: [i2rs] Minutes and additional meetings notes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 01 Apr 2014 16:45:36 -0000 I've updated the IETF 89 meeting minutes with the minor changes noted on the list. I've also uploaded Susan Hares' very detailed notes to the I2RS wiki: http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/Ietf89 Note that I'm just getting started on the wiki and the top level page will be a mess for a few days. :-) -- Jeff From nobody Wed Apr 2 07:03:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7A1A010D for ; Tue, 1 Apr 2014 23:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFAPVa8YGHdl for ; Tue, 1 Apr 2014 23:59:07 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id 785581A00BE for ; Tue, 1 Apr 2014 23:59:07 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id i50so1911766qgf.22 for ; Tue, 01 Apr 2014 23:59:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4P6SS9MO+BlUoGNByQSgRvovMS/YdIOgyYsU+Dacbaw=; b=G9lkbbSAqjukYbL/qvivXB8M6bwN6oMRRyTR/qMZeHnEeW87wPs8CJ4Q0OxUv0Nof3 SUxrjwr7UUguDehJf+aHoGy/mUbLLvGvGC+imqfRpeEcMJJijZdFjzzaCoOV8Q7oSgN/ CPVSCPdSwiH5RO0WIPsgKHbFDj+WU5Um8jB1wwAJMAsLaCzrJFMZxPVh9W9qRFrzlXoK 7UqQCUwgSRMJGwDFYXTR3fHuweVswKwROaVXwrZicESHc7y8P9ghWZrxycWXJx9wis9+ qi0zYMPHpM2th8yvF84yMI+JSR6e+HjRo2PpJ4TaCpWAF9mLMoFlRFcI5ZkBtJzWWL0j ppDQ== X-Gm-Message-State: ALoCoQmm/uSLu3vuhfGY08clWrNDcC4P8SvstpmHo04h4KwIc3+3mO6f93IkfdFnOWbJa8xqkGF8 MIME-Version: 1.0 X-Received: by 10.224.80.201 with SMTP id u9mr24349914qak.0.1396421943477; Tue, 01 Apr 2014 23:59:03 -0700 (PDT) Received: by 10.140.96.203 with HTTP; Tue, 1 Apr 2014 23:59:03 -0700 (PDT) Date: Wed, 2 Apr 2014 11:59:03 +0500 Message-ID: From: Shahryar Ali Khan To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=001a11c3e1ece5f01204f609d180 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ihuqKCEF7Kt8Yai6QttaIfntrpI X-Mailman-Approved-At: Wed, 02 Apr 2014 07:02:59 -0700 Subject: [i2rs] Is I2RS an alternative to OpenFlow and can they work together? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 06:59:12 -0000 --001a11c3e1ece5f01204f609d180 Content-Type: text/plain; charset=ISO-8859-1 Is I2RS about programming the RIBs only as compared to OpenFlow which we can call per-flow forwarding. And i am not sure how I2RS will separate the control plane from the forwarding plane like OpenFlow. And can I2RS and OpenFlow work together to achieve an optimized software defined network? regards, Shahryar Ali Product Engineer - Wireless Networks --001a11c3e1ece5f01204f609d180 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is I2RS about programming the RIBs only as compared to Ope= nFlow which we can call per-flow forwarding. And i am not sure how I2RS wil= l separate the control plane from the forwarding plane like OpenFlow. And c= an I2RS and OpenFlow work together to achieve an optimized software defined= network?


regards,
Shahryar Ali
Product Engineer - Wireless Networks
--001a11c3e1ece5f01204f609d180-- From nobody Wed Apr 2 08:53:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F81A02E6 for ; Wed, 2 Apr 2014 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89P_KPSEcjCT for ; Wed, 2 Apr 2014 08:53:09 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 64EBB1A02D5 for ; Wed, 2 Apr 2014 08:53:09 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so470596oag.7 for ; Wed, 02 Apr 2014 08:53:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QPAYD/ZpPrlxs4vU0vx3pytje61rqvnwG2GsHhleUNU=; b=cF0T0AIkFfiudTZCFdcqWLwIOM76KqAsaGlqD4kTO1PDmCTdp+18MbAo6nssQ4M89a Rg17zOwGtp6rfG0Y8smpNU709QWRE1Ukd5NH+3E1g/Be0f6xsB+1OxjrGBQ7j45IhTFz 9FSuPvboY3Em2ROb11U25nqWosKFbRRufr/QvR+6nwtohWjvvrHQkLqXipkuHf64yLbu i57AfAIYqbaC9cL4G6m91mjy/K6d3Ss2J/C3EqsR2JJgX4LO1i0QcPKFZSA3NWDEsvqO g1I/enwk7FyjKvqK7UrVWZ/Mbm/YvbrdBjMb4YRPsaRep+ecIA5zmDfDaeH40qNm/wq4 sbmg== X-Gm-Message-State: ALoCoQl+A5WyxMzCTxRYxsgm3/5pSJdCdDeeJV8FmfVzH+Vg8C2kPsnrALt+aXsXHmEXNDavNkg0 MIME-Version: 1.0 X-Received: by 10.182.79.9 with SMTP id f9mr732529obx.64.1396453985392; Wed, 02 Apr 2014 08:53:05 -0700 (PDT) Received: by 10.76.83.225 with HTTP; Wed, 2 Apr 2014 08:53:05 -0700 (PDT) X-Originating-IP: [199.172.169.79] In-Reply-To: References: Date: Wed, 2 Apr 2014 11:53:05 -0400 Message-ID: From: Truman Boyes To: Shahryar Ali Khan Content-Type: multipart/alternative; boundary=047d7b2e4016beefcf04f6114776 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/smQAKNIW1HHC8gRN1qgVfWOEpnI Cc: i2rs@ietf.org Subject: Re: [i2rs] Is I2RS an alternative to OpenFlow and can they work together? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2014 15:53:14 -0000 --047d7b2e4016beefcf04f6114776 Content-Type: text/plain; charset=ISO-8859-1 Influencing/Programming RIBs can allow for a richer set of programming than the actions defined in OFP today. I2RS is much closer to natural routing behaviour with individual nodes running protocols. I believe there is a future where both methods can live together, especially with OpenFlow implementations supporting fall-through to normal forwarding modes or multiple tables, etc. Truman On Wed, Apr 2, 2014 at 2:59 AM, Shahryar Ali Khan wrote: > Is I2RS about programming the RIBs only as compared to OpenFlow which we > can call per-flow forwarding. And i am not sure how I2RS will separate the > control plane from the forwarding plane like OpenFlow. And can I2RS and > OpenFlow work together to achieve an optimized software defined network? > > > regards, > Shahryar Ali > Product Engineer - Wireless Networks > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --047d7b2e4016beefcf04f6114776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Influencing/Programming RIBs can allow for a richer set of= programming than the actions defined in OFP today. I2RS is much closer to = natural routing behaviour with individual nodes running protocols.=A0
I believe there is a future where both methods can live together, especiall= y with OpenFlow implementations supporting fall-through to normal forwardin= g modes or multiple tables, etc.=A0

Truman


On Wed, Apr 2= , 2014 at 2:59 AM, Shahryar Ali Khan <mr.shahryarali.k@ieee.org> wrote:
Is I2RS about programming t= he RIBs only as compared to OpenFlow which we can call per-flow forwarding.= And i am not sure how I2RS will separate the control plane from the forwar= ding plane like OpenFlow. And can I2RS and OpenFlow work together to achiev= e an optimized software defined network?


regards,
Shahryar Ali
Pro= duct Engineer - Wireless Networks

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


--047d7b2e4016beefcf04f6114776-- From nobody Fri Apr 4 14:26:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3A1A011E for ; Fri, 4 Apr 2014 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvZoJRsIiqOC for ; Fri, 4 Apr 2014 14:26:05 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CC6C41A011B for ; Fri, 4 Apr 2014 14:26:05 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id ar20so3995551iec.2 for ; Fri, 04 Apr 2014 14:26:01 -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:date:message-id:subject :from:to:cc:content-type; bh=1Q4O+Qj4j6ysNSpOh3cQ8lFG9lYtMqm35sT43RNblHw=; b=LFUAknwibAUx2bF4SZXfkoCyDZIFgOzBRDyBrn3s+UYNte1LJtm2K1ncLfW81ui7iQ qDsM/sH6rbfmZ4OUKiWjDpBfYb8C3GHX0+HWafoWyuZaT41oOs3qcu1uto3vN/so1Glw EyZJftOp6ajjOBTgo2pgT1LI+ZHfiMaHRYdzGNzqIPQ5hYcREsjP/q6qOJXy17a9mg3b pbniMI556IWdJrOvjybVQziZvWfmVZ19Ruebg2bGioRV/VWvpMygHes4gOEROzFy9p7v JkhuP9b9Udv0AN4yW4lpgMfqN0Z3h52FynZpdFdIqZD/u6+v237SdAzsnHcKWZo7m1Yh GjFw== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr5836123igb.9.1396646761069; Fri, 04 Apr 2014 14:26:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 4 Apr 2014 14:26:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 23:26:01 +0200 X-Google-Sender-Auth: bDmr2cx88jDzAghfCnezzaZTV-4 Message-ID: From: Robert Raszuk To: Shahryar Ali Khan Content-Type: multipart/alternative; boundary=089e013a1d8e1202c904f63e2adf Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/e6J0bXS2_p9QWMmrTgRRF_Cofio Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Is I2RS an alternative to OpenFlow and can they work together? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 04 Apr 2014 21:26:10 -0000 --089e013a1d8e1202c904f63e2adf Content-Type: text/plain; charset=ISO-8859-1 Hi Shahryar, I think right analogy between I2RS and OF could be build to the choice of your programming language ... Do you want to focus on real problems to be solved and use higher level compiler languages which do offer wide portability of your applications or You see need to do everything in assembler language highly custom to your hardware underneath with zero practical portability across platforms ? (Leave alone the issue that even real OF hardware is far from ready for production use and each platform which claims to be OF 1.x ready differs from one another I can assure you that real SDN value has no dependency on the latter and can be much faster accelerated with the former. Best, R. On Wed, Apr 2, 2014 at 8:59 AM, Shahryar Ali Khan wrote: > Is I2RS about programming the RIBs only as compared to OpenFlow which we > can call per-flow forwarding. And i am not sure how I2RS will separate the > control plane from the forwarding plane like OpenFlow. And can I2RS and > OpenFlow work together to achieve an optimized software defined network? > > > regards, > Shahryar Ali > Product Engineer - Wireless Networks > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --089e013a1d8e1202c904f63e2adf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahryar,

I think right analogy between I2RS and OF could be build to the choice of y= our programming language ...=A0

Do you want to focus on real problems to be solved and use higher level com= piler languages which do offer wide portability of your applications =A0

or=A0

You see need to do everything in assembler language highly custom to your h= ardware underneath with zero practical portability across platforms ? (Leav= e alone the issue that even real OF hardware is far from ready for producti= on use and each platform which claims to be OF 1.x ready differs from one a= nother=A0

I can assure you that real SDN value = has no dependency on the latter and can be much faster accelerated with the= former.=A0

Best,
R.



On Wed, Apr 2, 2014 at 8:59 AM, Shahryar Ali Khan <= mr.shahryara= li.k@ieee.org> wrote:
Is I2RS about programming t= he RIBs only as compared to OpenFlow which we can call per-flow forwarding.= And i am not sure how I2RS will separate the control plane from the forwar= ding plane like OpenFlow. And can I2RS and OpenFlow work together to achiev= e an optimized software defined network?


regards,
Shahryar Ali
Pro= duct Engineer - Wireless Networks

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


--089e013a1d8e1202c904f63e2adf-- From nobody Thu Apr 10 08:39:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99951A027C for ; Thu, 10 Apr 2014 08:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKmPp6Y2A_3w for ; Thu, 10 Apr 2014 08:39:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1816C1A0277 for ; Thu, 10 Apr 2014 08:39:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM46148; Thu, 10 Apr 2014 15:39:39 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 16:38:33 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 16:39:38 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 08:39:25 -0700 From: Linda Dunbar To: Scott Whyte , "hines@google.com" , "warren@kumari.net" Thread-Topic: Questions to draft-swhyte-i2rs-data-collection-system-00 Thread-Index: Ac9U0wzX+7CSu1UNTzSEtYC9ilSiBA== Date: Thu, 10 Apr 2014 15:39:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF2B5C@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.172] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CF2B5Cdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/S_Xiq4ZoE_YzJpiYKQFNKoCXZ0s Cc: "i2rs@ietf.org" Subject: [i2rs] Questions to draft-swhyte-i2rs-data-collection-system-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 10 Apr 2014 15:39:44 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645CF2B5Cdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, et al, Your draft listed comprehensive requirement on what data you need to pull o= ut of a router. The Section 3 (Use Cases) , I was hoping to see some use cases on how those= collected data are used. But Section 3 only listed bunch of data that you = need. So Section 3 is really the "Requirement" (instead of use cases). Do you have any examples showing how those data are used? Concrete examples= can greatly help router vendors to prioritize the information to be pulled= when there is resource contention. Even though the primary objective is "= Collecting large data sets with high frequency with minimal impact to devic= e's CPU", very often "large set & high frequency" do need CPU cycles. Both Syslog and IPFIX were intended to export data from devices. What are t= he limitation of those schemes? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645CF2B5Cdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott, et al,

 

Your draft listed comprehensive requirement on what = data you need to pull out of a router.

 

The Section 3 (Use Cases) , I was hoping to see some= use cases on how those collected data are used. But Section 3 only listed = bunch of data that you need. So Section 3 is really the “Requirement&= #8221; (instead of use cases).

 

Do you have any examples showing how those data are = used? Concrete examples can greatly help router vendors to prioritize the i= nformation to be pulled when there is resource contention. Even though the = primary objective is  “Collecting large data sets with high frequency with minimal impact to device’s = CPU”,  very often “large set & high frequency” d= o need CPU cycles.  

 

Both Syslog and IPFIX were intended to export data f= rom devices. What are the limitation of those schemes?  

 

Thanks, Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645CF2B5Cdfweml701chmchi_-- From nobody Fri Apr 11 02:07:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12511A0458 for ; Fri, 11 Apr 2014 02:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjHI0Y_sq_l0 for ; Fri, 11 Apr 2014 02:07:49 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 80E411A019B for ; Fri, 11 Apr 2014 02:07:47 -0700 (PDT) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Fri, 11 Apr 2014 09:07:44 +0000 Message-ID: <008801cf5565$411fe1a0$4001a8c0@gateway.2wire.net> From: t.petch To: Linda Dunbar , Scott Whyte , , References: <4A95BA014132FF49AE685FAB4B9F17F645CF2B5C@dfweml701-chm.china.huawei.com> Date: Fri, 11 Apr 2014 10:04:00 +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.69] X-ClientProxiedBy: DB3PR07CA001.eurprd07.prod.outlook.com (10.242.134.41) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 0178184651 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(13464003)(164054003)(19580405001)(80976001)(74662001)(31966008)(81816999)(19580395003)(50226001)(83322001)(76176999)(81686999)(50986999)(74502001)(2201001)(92566001)(33646001)(79102001)(44716002)(89996001)(62236002)(50466002)(88136002)(85852003)(83072002)(23756003)(62966002)(61296002)(77982001)(66066001)(87286001)(4396001)(81342001)(20776003)(47776003)(87976001)(81542001)(99396002)(76482001)(44736004)(77156001)(84392001)(93916002)(46102001)(42186004)(80022001)(86362001)(15975445006)(92726001)(14496001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB064; H:DB3PRD0210HT003.eurprd02.prod.outlook.com; FPR:B498F5EC.20B15699.78579D4F.58F8D5AD.20285; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2fd7b4N7zEkg8uInGk7GnMCJ2YY Cc: i2rs@ietf.org Subject: Re: [i2rs] Questions to draft-swhyte-i2rs-data-collection-system-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 09:07:54 -0000 ----- Original Message ----- From: "Linda Dunbar" To: "Scott Whyte" ; ; Cc: Sent: Thursday, April 10, 2014 4:39 PM Scott, et al, Your draft listed comprehensive requirement on what data you need to pull out of a router. The Section 3 (Use Cases) , I was hoping to see some use cases on how those collected data are used. But Section 3 only listed bunch of data that you need. So Section 3 is really the "Requirement" (instead of use cases). Do you have any examples showing how those data are used? Concrete examples can greatly help router vendors to prioritize the information to be pulled when there is resource contention. Even though the primary objective is "Collecting large data sets with high frequency with minimal impact to device's CPU", very often "large set & high frequency" do need CPU cycles. Both Syslog and IPFIX were intended to export data from devices. What are the limitation of those schemes? When anyone says 'use cases', I find myself going back to our charter, which calls for us to work on tightly scoped key use cases, listing six. I look at those six to see where this fits. Um, I struggle to see the fit with the charter. Tom Petch Thanks, Linda Dunbar ------------------------------------------------------------------------ -------- > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Apr 11 04:59:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE271A0659 for ; Fri, 11 Apr 2014 04:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqLLe7fvmCq4 for ; Fri, 11 Apr 2014 04:59:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA701A01DA for ; Fri, 11 Apr 2014 04:59:12 -0700 (PDT) Received: from DB3PRD0210HT004.eurprd02.prod.outlook.com (157.56.253.69) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.918.8; Fri, 11 Apr 2014 11:59:10 +0000 Message-ID: <068001cf557d$33e5b9c0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , References: <20140401164531.GI28363@pfrc> Date: Fri, 11 Apr 2014 12:57:12 +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.69] X-ClientProxiedBy: AMXPR07CA006.eurprd07.prod.outlook.com (10.242.64.46) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Forefront-PRVS: 0178184651 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51704005)(13464003)(377454003)(66066001)(44736004)(80022001)(15975445006)(76482001)(81542001)(50466002)(80976001)(92566001)(61296002)(92726001)(19580395003)(99396002)(85852003)(83072002)(79102001)(46102001)(47776003)(19580405001)(83322001)(15202345003)(77156001)(77982001)(20776003)(81342001)(33646001)(31966008)(74502001)(74662001)(42186004)(62236002)(44716002)(84392001)(23756003)(89996001)(50226001)(62966002)(4396001)(87286001)(81816999)(81686999)(86362001)(93916002)(76176999)(87976001)(50986999)(88136002)(14496001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB053; H:DB3PRD0210HT004.eurprd02.prod.outlook.com; FPR:7AABF138.2D3B64E3.B0F3B5F7.D6E19ACA.2020B; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kyF7hSAr2tqmHpnNoVxtDfbH7SU Subject: Re: [i2rs] Minutes and additional meetings notes X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 11:59:17 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: Sent: Tuesday, April 01, 2014 5:45 PM > I've updated the IETF 89 meeting minutes with the minor changes noted on the > list. I've also uploaded Susan Hares' very detailed notes to the I2RS wiki: > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/Ietf89 I had a peek at this, saw that it was a 725KB PDF, thought, ah well, I 'll view it anyway and only to get HTML preview not available, since the file size exceeds 262144 bytes Yes, it is very detailed and I could down load it but it would be nice if it was a little friendlier. I think of Word as excessively verbose but the original Word document was only 114KB which turns into 54KB of text, so quite what Adobe has done, I cannot imagine. Tom Petch I had a peek at Tom Petch Tom Petch > > Note that I'm just getting started on the wiki and the top level page will > be a mess for a few days. :-) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 11 10:51:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF31A072E for ; Fri, 11 Apr 2014 10:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-0FHnWVFLGn for ; Fri, 11 Apr 2014 10:51:41 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1131D1A074B for ; Fri, 11 Apr 2014 10:51:40 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so5754679wes.0 for ; Fri, 11 Apr 2014 10:51:39 -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=ziMy6waKpZmTW+4AtSlh2q0oM+N8P8lKyHxgYgE5ocI=; b=bu7Dm6R1Ep6Ulk40kd7ybst+3To8SlOaaUA3lr/S7yUQtdYZ0/MIMs1qq23uJ7LaZG nBEN0jfJBeLsc4RXEcWM73+NOA18dpPsTrJ4X4t0S2GeenCaQA7aguJq2dvaKHoBg4Hc jMurH055FS7F6uqkGWEm/llAtYcUwxvB4g7+SMKe8BUmGK6R2nsmp7tEfp+TFuGOnBjO Y8DZqEfgXOpSJnvlV8tock2YzSx18q6nGEvTB8NKaIRP3x812OOoHkYUBpBcesD5EJJa Hx8vlIPergIWF1Epcp9J4Zpxyyvgr19tcxQ027zYkpW6CR1pzlJfEKA2sq2de/32xnIc hvxw== 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=ziMy6waKpZmTW+4AtSlh2q0oM+N8P8lKyHxgYgE5ocI=; b=hmFW7qp10VF40oF7kFV5AumJGjaazXcxjlTu6KIF37zXLXdNT1b2I7+MkHIukwMvEQ 4CT/Y0hglH3enn4pLhQ4HQEG2tZVIYfI8BYKR779hA0nIVeRZATXwO5CaGF+vtLmjTsz Jt3P1NsQ/k5JYR2gyNPRfm2TcrJzlKc7rhI9zsIC20x43vZ+KP7Lyjf7BeyjHJxCeyVm hs39x6pMvIUHKgGbS9u3bvGsKEBuZAwlQ/iUbefaDvYtiOtJ7QLiY4dPo9JE0uwKlwen htdACsR4c0gpsJ7X7UBoyx/dJaTWFFVEPPF+aTICJPwu4z0seNRoA6Gse+S+c6EESDlK vAAQ== X-Gm-Message-State: ALoCoQm86BZ5mUKlfGFNOD5+AwN746dOzAlShNFuJvphE7nokTq1QcNkHVPEACQHA3pSaQIsL+jcBqYiwQG2buyaQcc+8n1Pemzlu8pOdJt3VciTYqQNsztvszMPeTfqhA51EpAVlCGxC/kLAiIULru/DVPvFPWHWwEmapnLMoFNbqlwd+oTGLFKHnutH7MW9oUjLNY/pPf3 X-Received: by 10.194.203.170 with SMTP id kr10mr22149978wjc.19.1397238698794; Fri, 11 Apr 2014 10:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.66 with HTTP; Fri, 11 Apr 2014 10:50:58 -0700 (PDT) From: Edward Crabbe Date: Fri, 11 Apr 2014 10:50:58 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6d87de4f006a04f6c7fccf Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-vc3bZ66aMLonCnirsriAsnRChM Subject: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 17:51:42 -0000 --047d7b6d87de4f006a04f6c7fccf Content-Type: text/plain; charset=ISO-8859-1 Dear I2RSers, At the last I2RS WG meeting there was a great deal of conversation regarding selection of both modeling language and underlying transport protocol. Consensus at the time was to make use of Yang and (NetConf or RestConf) (unclear). Before coming to a final consensus, we'd like to give people adequate time to review source material, marshall arguments and discuss on the mailing list. To this end, we're asking that interested parties do just this over the course of the next ~two weeks. Following that period, on 4/28, we'll be initiating a consensus call that will last an additional two weeks, with the aim of converging modeling language / protocol by Friday, 5/9. The consensus call should also generate proposals for any material changes required to the underlying protocols. These proposals in turn will form the basis for a later draft including gap analysis and said changes. Those strongly in favor of one protocol over another should be prepared to contribute to this analysis. best, -ed --047d7b6d87de4f006a04f6c7fccf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear I2RSers,


  At the last I2RS WG meetin= g there was a great deal of conversation regarding selection of both modeli= ng language and underlying transport protocol.  Consensus at the time = was to make use of Yang and (NetConf or RestConf) (unclear).  

  Before coming to a final consensus, we’d like to give peop= le adequate time to review source material, marshall arguments and discuss = on the mailing list.  To this end, we’re asking that interested = parties do just this over the course of the next ~two weeks. Following that= period, on 4/28, we’ll be initiating a consensus call that will last= an additional two weeks, with the aim of converging modeling language / pr= otocol by Friday, 5/9.  

The consensus call should also generate proposals for a= ny material changes required to the underlying protocols.  These propo= sals in turn will form the basis for a later draft including gap analysis a= nd said changes.  Those strongly in favor of one protocol over another= should be prepared to contribute to this analysis. 


best,

  -ed
--047d7b6d87de4f006a04f6c7fccf-- From nobody Sat Apr 12 11:38:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038FF1A0217 for ; Sat, 12 Apr 2014 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACN_3IWjJ0Tg for ; Sat, 12 Apr 2014 11:38:51 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id EDE101A0215 for ; Sat, 12 Apr 2014 11:38:50 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so6011050veb.14 for ; Sat, 12 Apr 2014 11:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OdD32tNrxVpXZenkcs+bcImjfyxT88tTPrfNdWqu1I4=; b=XOyiP6O0Mml8VnMa0+qv/ATtUIbxw8YLQIJTg3G8XEIXyqPUuBhVZIFpzeVFA2K2iI rP0zwg5/cp/seMP9ZFt2aLYxwzE2kEw0ACUF2WuVy6NVREhwNClXQSMj5KmWPuUhNMz+ zAWdiDuuvHKAOKrIJQg5zPP3GorjVOfqgFw7tlErUbTw+UEiXFxy3JVUoeG4H2CEvz8I YuXLvEw2RBbaNh1HQJDbmipJ5swjDVWHk9BbAVOSsjyKGgBZ7OR/1ysZD4mffG+sn0z6 igSvDxGmwfSIi0EBoHUHV+e4RjaFQdD0HT7/wrk6I5fgXu/sEEeJlI8XFG9HkqansCQ5 1qvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OdD32tNrxVpXZenkcs+bcImjfyxT88tTPrfNdWqu1I4=; b=SmI+TI3kzYZ23gGPV+fqFKtlqHwZf+jWNsX82X8sqGG5XiPBh7mHkyLzN7xKXwwB7i OhgNJoagi0J7kUnfw3FOoGvtyQM7lx2vf8N0bqkwMDdbz7wF49pz+BZd2JTCB7Wv5YMT lEKFmN+4jk+XN8eWTTjWPaUV1WZpbXYVA8XayG/w1S6r2dNLYH0S7bqt9YuWr4WDjD68 k4YRsQqlUOdBUGN/9WiwzJ5qufC3AnQ4Ozi7I4G3cj1eYiHQj+8idl8VEG48R/w027n3 aUBFBIqo2XQ0gyuzLJ5u0BYfk8idnNHHN+8vO9LWGfEd5rZJmt1Ye+la5mNQCZNEVlDN PwdA== X-Gm-Message-State: ALoCoQl534uPXDwkVIQsCwxdgWtzW7x+1Az9SX+zgC6vhHdYiR2SFELzgG4Mq99uyvmHARVYkd680aGwVJqCbQE4MHjQYUtQqsy5UP11vb1a8u5EFU6M+GP1BhwjdzzA3mK9PoFvmdAhyz4ugmiJyxFCo5G9vwoBJYCddpZY582BU47MsDlHoK/GGxPqd9y+WiOCgq0YeRDz MIME-Version: 1.0 X-Received: by 10.58.181.170 with SMTP id dx10mr39622vec.25.1397327928916; Sat, 12 Apr 2014 11:38:48 -0700 (PDT) Received: by 10.52.126.169 with HTTP; Sat, 12 Apr 2014 11:38:48 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF2B5C@dfweml701-chm.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645CF2B5C@dfweml701-chm.china.huawei.com> Date: Sat, 12 Apr 2014 11:38:48 -0700 Message-ID: From: Scott Whyte To: Linda Dunbar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/6yNDEMtheFQLA6O2oaZoofjbPvk Cc: "i2rs@ietf.org" , "warren@kumari.net" , "hines@google.com" Subject: Re: [i2rs] Questions to draft-swhyte-i2rs-data-collection-system-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 12 Apr 2014 18:38:52 -0000 On Thu, Apr 10, 2014 at 8:39 AM, Linda Dunbar wro= te: > Scott, et al, > > > > Your draft listed comprehensive requirement on what data you need to pull > out of a router. > > > > The Section 3 (Use Cases) , I was hoping to see some use cases on how tho= se > collected data are used. But Section 3 only listed bunch of data that you > need. So Section 3 is really the =E2=80=9CRequirement=E2=80=9D (instead o= f use cases). > > > > Do you have any examples showing how those data are used? Concrete exampl= es > can greatly help router vendors to prioritize the information to be pulle= d > when there is resource contention. Even though the primary objective is > =E2=80=9CCollecting large data sets with high frequency with minimal impa= ct to > device=E2=80=99s CPU=E2=80=9D, very often =E2=80=9Clarge set & high freq= uency=E2=80=9D do need CPU cycles. Hi Linda, Thanks for the comments. The draft as such needs to be re-organized along the lines you suggest, which I hope to start this quarter. > > > > Both Syslog and IPFIX were intended to export data from devices. What are > the limitation of those schemes? I think many of the limitations of the original syslog RFC3164 are addressed in RFC5424, but I'm also not aware of strong support for 5424 in the industry. If that is not the case I'd be happy to learn otherwise. IPFIX was mentioned in the draft as an example of how the operations of existing data export models that work very well with their specific datasets could be improved by adding a framework that supports pub/sub subscriptions in front of them. Particularly if a vendor already supports a specific format like IPFIX. Again I'm sure this concept could benefit from a re-write, which we will look into. Thanks, Scott > > > > Thanks, Linda Dunbar > > From nobody Sat Apr 12 12:08:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85341A021C for ; Sat, 12 Apr 2014 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWKtpfssI5QS for ; Sat, 12 Apr 2014 12:08:37 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 32B031A0219 for ; Sat, 12 Apr 2014 12:08:37 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so5862814veb.19 for ; Sat, 12 Apr 2014 12:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bm2ejxkrXLPFPOAFimXA5dMiHTc5K2Qw19S3bjrTUk8=; b=esSpft7jD0JUJyS9RojQJL2tUweZwvpGmlH2zwdpgwOojPIHNYaiHX0sIWtUmaDHjJ dJfrmWtG/lyn44f7xOIdnLDu6ohrA6oENGHO4hj7tiH58HU7AjRUy0YLJ7wurPCy7zgz wghSMkhoxBPrw3TfB5LQRLGO84qrle7ftYHj3J2sIbrENOd3uT1xPCZ2QVoG2lONz94f 1N3/QInz909kzDxP1YxLiuHzyXgys2hzC7OmuOk0HeGUq25/2pJ+oAyXt/5DOhMJH/Cq 2uNxD0ODAIx0nL3j8B4sIVk0QW7+4w2pnsZXzWoGO4YLbHf45c8Klw1fGk0g6I0XkFvp 2lsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bm2ejxkrXLPFPOAFimXA5dMiHTc5K2Qw19S3bjrTUk8=; b=RPVz2mdptcvAvebhOnJMgv+gpK+1XK/HgtAOFXqmMGiA3MBix/rKVu2RzIlzYJBpgD xl0+UmCLtYXD2+eV1sXgCCsFNcN0aV/Kt40a+ltIgo/UPOfCTOqT0lccbsZ70NYBlcpA wzGvrb1HvD2gpDw4qrqaPMkSwisNPYssouD+I2HlqWBtk8KKHhud/9tvnOamR3mp2nvv yaog6kz4EuSHRZtHGQjM4LQISf0xm89oFXbqpZqm5o3ZgBO4YB511VD/yYf7F0+eRb7z eOBpRG1ikRf2Q612ft9CJPdXSp0b3bKQ+DWiRR8gcOVL4fOP9UoPliObNJwG4tHo/kpf CFLA== X-Gm-Message-State: ALoCoQmcHb0pCerRvmRfdW1ECO0GAOeOtLkGcLPjZa2kZHMgQUs2vJzH+QoKSnFqyxmjl+d2lqwQ+tWMmCoUPCtjDCj5FNEUxn0Ev5AE2BtsUX05NAYE+fdWOpgL9y8WU+dTLWa34NCyNudjPhE/ec0rMrJBI7rvkFQJxm3HvyfK2iTE5izFwGwSzlGfkibSK5Yxw9EHgVZ2 MIME-Version: 1.0 X-Received: by 10.52.108.164 with SMTP id hl4mr1580800vdb.25.1397329715158; Sat, 12 Apr 2014 12:08:35 -0700 (PDT) Received: by 10.52.126.169 with HTTP; Sat, 12 Apr 2014 12:08:35 -0700 (PDT) In-Reply-To: <008801cf5565$411fe1a0$4001a8c0@gateway.2wire.net> References: <4A95BA014132FF49AE685FAB4B9F17F645CF2B5C@dfweml701-chm.china.huawei.com> <008801cf5565$411fe1a0$4001a8c0@gateway.2wire.net> Date: Sat, 12 Apr 2014 12:08:35 -0700 Message-ID: From: Scott Whyte To: "t.petch" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zV5XPEonYb8Vm5_2qU27eFTbxEE Cc: i2rs@ietf.org, Marcus Hines , warren@kumari.net, Linda Dunbar Subject: Re: [i2rs] Questions to draft-swhyte-i2rs-data-collection-system-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 12 Apr 2014 19:08:39 -0000 On Fri, Apr 11, 2014 at 2:04 AM, t.petch wrote: > ----- Original Message ----- > From: "Linda Dunbar" > To: "Scott Whyte" ; ; > > Cc: > Sent: Thursday, April 10, 2014 4:39 PM > > Scott, et al, > > Your draft listed comprehensive requirement on what data you need to > pull out of a router. > > The Section 3 (Use Cases) , I was hoping to see some use cases on how > those collected data are used. But Section 3 only listed bunch of data > that you need. So Section 3 is really the "Requirement" (instead of use > cases). > > Do you have any examples showing how those data are used? Concrete > examples can greatly help router vendors to prioritize the information > to be pulled when there is resource contention. Even though the primary > objective is "Collecting large data sets with high frequency with > minimal impact to device's CPU", very often "large set & high > frequency" do need CPU cycles. > > Both Syslog and IPFIX were intended to export data from devices. What > are the limitation of those schemes? > > > When anyone says 'use cases', I find myself going back to our charter, > which calls for us to work on tightly scoped key use cases, listing six. > I look at those six to see where this fits. Um, I struggle to see the > fit with the charter. Tom, I wouldn't argue that the draft as is, is all over the place. However, let me pose a use-case and ask the WG for guidance: Tight coupling of interface state and control plane is broadly supported in the industry, and greatly improves BGP convergence times by allowing near-instantaneous reaction to a port going down instead of having to wait for hold-down to expire. Using I2RS and its various services I can implement BGP as an application. Doing so breaks this tight coupling by necessity, as the interface affected in the data plane and the BGP application implementing the routing system are no longer co-located. Given the impact to control plane convergence and the wide-spread reliance on such signalling today, it seems well placed within the tightly scoped key use cases. On the other hand, given that it is an optimization based on the colocation of data and control planes in a routing element and not purely part of the routing system, is doesn't seem to fit in the I2RS protocol proper. Where does this type of signalling best fit? In I2RS but not the I2RS protcol, or a different WG (please suggest where), or in the I2RS protocol, or something entirely different? -Scott > > Tom Petch > > Thanks, Linda Dunbar > > > > > ------------------------------------------------------------------------ > -------- > > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Mon Apr 14 17:02:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E171A0696 for ; Mon, 14 Apr 2014 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNU0caksbQW6 for ; Mon, 14 Apr 2014 17:01:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 159F01A0692 for ; Mon, 14 Apr 2014 17:01:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 50CB9C3A6; Mon, 14 Apr 2014 20:01:47 -0400 (EDT) Date: Mon, 14 Apr 2014 20:01:47 -0400 From: Jeffrey Haas To: draft-clarke-i2rs-traceability@tools.ietf.org, i2rs@ietf.org Message-ID: <20140415000147.GA15705@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/am9QUN452xfVTjv2ZXrBPGGJRTI Subject: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 00:01:58 -0000 Authors, While reviewing draft-clarke-i2rs-traceability, one big thing jumped out at me that will require a bit more consideration: ABNF is only ASCII-friendly. Since one of the data modeling languages we're considering is Yang, we need to have support for unicode (UTF-8, e.g.). I don't have a specific suggested fix at this time. I suspect this is a bigger issue than just ours as it impacts other consumers of ABNF. -- Jeff From nobody Tue Apr 15 06:44:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D81A0768 for ; Tue, 15 Apr 2014 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX7gNnX4QIe9 for ; Tue, 15 Apr 2014 06:44:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E01A063A for ; Tue, 15 Apr 2014 06:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1397569455; x=1398779055; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=82osxHzkThYWWbS5D0+zTOeQw9Rxj6u93Qo1XFgdU54=; b=Q7do+dj8VOUlXfUQPBKBqltp34dFDSrHyetw35qGUNgJ0W8wgqrBVlOH z4IekM8L5ocq9pbKy7/bZu/t6mrBhHf9HRaM3L0LvXQ/YRUcdmHSys8FE gQ+y0wPwoIeV0ALEBBxQVo2ppKUa5UqTWGzwlCcDkcJ3Vllb+lA2NgpHa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAK82TVOtJV2a/2dsb2JhbABZgwbEOoEiFnSCJQEBAQQ4QBELDgQGCRYPCQMCAQIBNw4GAQwIAQGHeMwsF45qhDgBA5hihlSLcYNNIQ X-IronPort-AV: E=Sophos;i="4.97,864,1389744000"; d="scan'208";a="35977709" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 15 Apr 2014 13:44:14 +0000 Received: from [10.150.54.111] (dhcp-10-150-54-111.cisco.com [10.150.54.111]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FDiEVS008354; Tue, 15 Apr 2014 13:44:14 GMT Message-ID: <534D37AF.1050901@cisco.com> Date: Tue, 15 Apr 2014 09:44:15 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jeffrey Haas , draft-clarke-i2rs-traceability@tools.ietf.org, i2rs@ietf.org References: <20140415000147.GA15705@pfrc> In-Reply-To: <20140415000147.GA15705@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uNPZhuhqEcO1GQLcfQTbQi8gBKI Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 13:44:24 -0000 On 4/14/14, 8:01 PM, Jeffrey Haas wrote: > Authors, > > While reviewing draft-clarke-i2rs-traceability, one big thing jumped out at > me that will require a bit more consideration: ABNF is only ASCII-friendly. > Since one of the data modeling languages we're considering is Yang, we need > to have support for unicode (UTF-8, e.g.). > > I don't have a specific suggested fix at this time. I suspect this is a > bigger issue than just ours as it impacts other consumers of ABNF. Thanks for the feedback, Jeff! We've been waiting for some :-). Yes, ABNF is ASCII-friendly. When we originally wrote this, we were going off of what was in the architecture. I have some updates planned for this, and I will work on updating the model to reflect current WG status. Any other comments or suggestions are very much welcome. Joe From nobody Tue Apr 15 11:10:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDE61A03D7 for ; Tue, 15 Apr 2014 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JOSwjK9X-Td for ; Tue, 15 Apr 2014 11:10:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id E14D51A0368 for ; Tue, 15 Apr 2014 11:10:03 -0700 (PDT) Received: from mail33-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Apr 2014 18:09:22 +0000 Received: from mail33-ch1 (localhost [127.0.0.1]) by mail33-ch1-R.bigfish.com (Postfix) with ESMTP id EA61740294; Tue, 15 Apr 2014 18:09:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I1447Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail33-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(189002)(199002)(479174003)(377454003)(24454002)(51914003)(86362001)(93916002)(74502001)(36756003)(74662001)(31966008)(82746002)(2656002)(83716003)(33656001)(80976001)(99396002)(15975445006)(89996001)(99286001)(77156001)(92566001)(19580405001)(88136002)(87286001)(92726001)(83322001)(83072002)(19580395003)(76176999)(85852003)(50986999)(87936001)(76482001)(20776003)(66066001)(80022001)(79102001)(77982001)(50226001)(4396001)(81542001)(46102001)(62966002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:A868F5F9.9FD39FE3.32C59CF3.EEDDD849.20306; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail33-ch1 (localhost.localdomain [127.0.0.1]) by mail33-ch1 (MessageSwitch) id 1397585359150461_29599; Tue, 15 Apr 2014 18:09:19 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail33-ch1.bigfish.com (Postfix) with ESMTP id 47DCA2A0051; Tue, 15 Apr 2014 18:09:17 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Apr 2014 18:09:16 +0000 Received: from BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Tue, 15 Apr 2014 18:09:54 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 15 Apr 2014 18:09:53 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.224]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.224]) with mapi id 15.00.0918.000; Tue, 15 Apr 2014 18:09:52 +0000 From: Dean Bogdanovic To: Joe Marcus Clarke Thread-Topic: [i2rs] Comments on draft-clarke-i2rs-traceability Thread-Index: AQHPWD36NQ7+JPAwAEmzr1Y3+kBTm5sSsRiAgABKNoA= Date: Tue, 15 Apr 2014 18:09:52 +0000 Message-ID: <4F0DB516-2994-46A0-9BF7-1059C79BD8AE@juniper.net> References: <20140415000147.GA15705@pfrc> <534D37AF.1050901@cisco.com> In-Reply-To: <534D37AF.1050901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-forefront-prvs: 0182DBBB05 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% Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FTVsA_fiKZzJ4tUFFkFXS9nT38E Cc: Jeffrey Haas , "" , "" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 18:10:06 -0000 Joe, Besides having the same comment as Jeff, here is one more and think some ad= ditional clarification is needed Actor Identifier: This is an opaque identifier that may be known to the Client from a northbound controlling application. This is used to trace the northbound actor driving the actions of the Client. The Client may not provide this identifier to the Agent if there is no external actor driving the Client. However, this field MUST be logged. If the Client does not provide an actor ID, then the Agent MUST log an empty field. I can see that Actor ID can be useful to report back to Client operator abo= ut rouge Actor. WRT logging Actor ID, when the Actor ID is not provided by = Client, instead of logging an empty field, I would suggest to log UNKNOWN o= r NOT FOUND or NOT PROVIDED, as it is easier to search for a keyword then j= ust empty field. Dean On Apr 15, 2014, at 9:44 AM, Joe Marcus Clarke wrote: > On 4/14/14, 8:01 PM, Jeffrey Haas wrote: >> Authors, >>=20 >> While reviewing draft-clarke-i2rs-traceability, one big thing jumped out= at >> me that will require a bit more consideration: ABNF is only ASCII-friend= ly. >> Since one of the data modeling languages we're considering is Yang, we n= eed >> to have support for unicode (UTF-8, e.g.). >>=20 >> I don't have a specific suggested fix at this time. I suspect this is a >> bigger issue than just ours as it impacts other consumers of ABNF. >=20 > Thanks for the feedback, Jeff! We've been waiting for some :-). Yes, AB= NF is ASCII-friendly. When we originally wrote this, we were going off of = what was in the architecture. I have some updates planned for this, and I = will work on updating the model to reflect current WG status. >=20 > Any other comments or suggestions are very much welcome. >=20 > Joe >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 From nobody Tue Apr 15 11:51:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4FE1A0330 for ; Tue, 15 Apr 2014 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEU50CiZeoeT for ; Tue, 15 Apr 2014 11:51:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 733F51A0262 for ; Tue, 15 Apr 2014 11:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2442; q=dns/txt; s=iport; t=1397587861; x=1398797461; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aVzkeTOjAVBMTMrGPvSPk+a/b0WLq2OvPTzybnnjr9k=; b=Q9P79K7IDGw4ZdYHwhQGioerfhfNtxXYZ7Fk++m/IqFi7mwF1RqkCADy to6DTOYSHODNGOeBEnCH+vg7FPIXHOEOMBr7lOat7r6QNQo5rmJ1rSBXp 5L2EswVBtuFqyjqiqHNuCBCkFc661dMIkbvA/XR18i1z3/aL7rKVipa3O c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOl+TVOtJV2Y/2dsb2JhbABYgwY7vE+HNoEoFnSCJQEBAQMBAQEBNTYKARALEgYJFg8JAwIBAgEVIg4GDQEFAgEBh3AIDcxGEwSOYweEOAEDmGKGVItxg00h X-IronPort-AV: E=Sophos;i="4.97,865,1389744000"; d="scan'208";a="36048852" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 15 Apr 2014 18:50:59 +0000 Received: from [10.150.54.111] (dhcp-10-150-54-111.cisco.com [10.150.54.111]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3FIoxuu003929; Tue, 15 Apr 2014 18:50:59 GMT Message-ID: <534D7F93.2090708@cisco.com> Date: Tue, 15 Apr 2014 14:50:59 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dean Bogdanovic References: <20140415000147.GA15705@pfrc> <534D37AF.1050901@cisco.com> <4F0DB516-2994-46A0-9BF7-1059C79BD8AE@juniper.net> In-Reply-To: <4F0DB516-2994-46A0-9BF7-1059C79BD8AE@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/22wywdbDwDq1epLpRNrPF4d2oEw Cc: Jeffrey Haas , "" , "" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 18:51:09 -0000 On 4/15/14, 2:09 PM, Dean Bogdanovic wrote: > Joe, > > Besides having the same comment as Jeff, here is one more and think some additional clarification is needed > > Actor Identifier: This is an opaque identifier that may be known to > the Client from a northbound controlling application. This is > used to trace the northbound actor driving the actions of the > Client. The Client may not provide this identifier to the Agent > if there is no external actor driving the Client. However, this > field MUST be logged. If the Client does not provide an actor ID, > then the Agent MUST log an empty field. > I can see that Actor ID can be useful to report back to Client operator about rouge Actor. WRT logging Actor ID, when the Actor ID is not provided by Client, instead of logging an empty field, I would suggest to log UNKNOWN or NOT FOUND or NOT PROVIDED, as it is easier to search for a keyword then just empty field. Thanks, Dean. The searchability is a good point. Of the three you propose, I think "NOT PROVIDED" is the only correct option. What do others think? Admittedly, this might evolve into some kind of enumeration where we might need values like "NOT PROVIDED" and "UNKNOWN" to accommodate different states. Joe > > Dean > > On Apr 15, 2014, at 9:44 AM, Joe Marcus Clarke wrote: > >> On 4/14/14, 8:01 PM, Jeffrey Haas wrote: >>> Authors, >>> >>> While reviewing draft-clarke-i2rs-traceability, one big thing jumped out at >>> me that will require a bit more consideration: ABNF is only ASCII-friendly. >>> Since one of the data modeling languages we're considering is Yang, we need >>> to have support for unicode (UTF-8, e.g.). >>> >>> I don't have a specific suggested fix at this time. I suspect this is a >>> bigger issue than just ours as it impacts other consumers of ABNF. >> >> Thanks for the feedback, Jeff! We've been waiting for some :-). Yes, ABNF is ASCII-friendly. When we originally wrote this, we were going off of what was in the architecture. I have some updates planned for this, and I will work on updating the model to reflect current WG status. >> >> Any other comments or suggestions are very much welcome. >> >> Joe >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > From nobody Tue Apr 15 12:03:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8D41A0394 for ; Tue, 15 Apr 2014 12:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTNMVxcuKoXl for ; Tue, 15 Apr 2014 12:02:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C9D481A0322 for ; Tue, 15 Apr 2014 12:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1077; q=dns/txt; s=iport; t=1397588575; x=1398798175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zuHiOCtwRHJQHZNrNwO1Ri052RZ+4UeL2P6lIYjT0io=; b=OoSI+XXUxZ6utr3sBURRMLRO8AmLUANlCPKkuD4ffLutv7DIsvqsyi+J C43gL0DCN+w/G3XNkuAqNRuM6eSpaBFK1pKX1A/XbekV9DBDANKCecaB/ eWhcbpdff0yhE21BwGzeW4gzOf4veYFxxphEha3Tdv6MKtk8tJknlQoQ3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAH+BTVOtJA2I/2dsb2JhbABYgwY7V7t4hzaBKRZ0giUBAQEDAQEBASQTNAsFCwIBCA4oECcLJQIEDgWHdAgNzEgTBI4wMweDJIEUAQOYYpJFgzGCKw X-IronPort-AV: E=Sophos;i="4.97,865,1389744000"; d="scan'208";a="36066695" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 15 Apr 2014 19:02:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3FJ2sr2006334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Apr 2014 19:02:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 15 Apr 2014 14:02:54 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Jeffrey Haas Thread-Topic: [i2rs] Comments on draft-clarke-i2rs-traceability Thread-Index: AQHPWD3zNoq+7NjE9kGzFbVfPkzTR5sTXfIA Date: Tue, 15 Apr 2014 19:02:54 +0000 Message-ID: <4DEACA63-F472-467F-833C-38726E3C0F1D@cisco.com> References: <20140415000147.GA15705@pfrc> In-Reply-To: <20140415000147.GA15705@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.98] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F20787B51B22549B65D73E79658EE9D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YlkerR8DqqVT-jVeS90BI8G1Tj4 Cc: "i2rs@ietf.org" , "draft-clarke-i2rs-traceability@tools.ietf.org" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 19:03:02 -0000 As Joe mentioned, we're certainly open to expanding to UTF-8. To your (val= id) point regarding YANG, would the group prefer to see the trace log synta= x expressed in YANG instead of ABNF? We stuck with BNF-based out of sheer h= abit. If we did this, for the sake of consistency, would we also want the s= yntax updated (RBNF->YANG) in Nitin's RIB IM draft as well? Gonzalo On Apr 14, 2014, at 8:01 PM, Jeffrey Haas wrote: > Authors, >=20 > While reviewing draft-clarke-i2rs-traceability, one big thing jumped out = at > me that will require a bit more consideration: ABNF is only ASCII-friendl= y. > Since one of the data modeling languages we're considering is Yang, we ne= ed > to have support for unicode (UTF-8, e.g.). >=20 > I don't have a specific suggested fix at this time. I suspect this is a > bigger issue than just ours as it impacts other consumers of ABNF. >=20 > -- Jeff >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Apr 15 12:12:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC6B1A016B for ; Tue, 15 Apr 2014 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znAncdOWSenl for ; Tue, 15 Apr 2014 12:12:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id F077C1A0489 for ; Tue, 15 Apr 2014 12:12:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6363024047A; Tue, 15 Apr 2014 12:12:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-122.clppva.east.verizon.net [70.106.135.122]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 88191240ACF; Tue, 15 Apr 2014 12:12:00 -0700 (PDT) Message-ID: <534D847E.7080802@joelhalpern.com> Date: Tue, 15 Apr 2014 15:11:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , Jeffrey Haas References: <20140415000147.GA15705@pfrc> <4DEACA63-F472-467F-833C-38726E3C0F1D@cisco.com> In-Reply-To: <4DEACA63-F472-467F-833C-38726E3C0F1D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/D2UkJ-_7tavdGthvu7QCuag9mGM Cc: "i2rs@ietf.org" , "draft-clarke-i2rs-traceability@tools.ietf.org" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 19:12:08 -0000 The question about languages mixes three very different spaces. 1) Is the format of a (potentially binary) packet on the wire, in this case the trace log syntax. 2) Is the data model for the command exchanges. 3) Is the language used for information modeling. Taking them in reverse order, ABNF (or RBNF) is absolutely the wrong thing to use for item 3. I would prefer to use UML. If we decide (as seems likely) to use YANG for the data modeling, then I can live with skipping the UML step and going directly to YANG. Item (2) is the domain of the protocol discussion the chairs are trying to wrap up. I expect the mailing list to endorse the conclusion that we should use YANG for this. Item 1 could be seen as similar to item 2. But only if you constrain the format to match what YANG can talk about. In describing a general format (with details of the final binding to the wire deferred or specified as we choose) ABNF / RBNF are very well suited to this problem. And produce very clear descriptions of packets. Yours, Joel On 4/15/14, 3:02 PM, Gonzalo Salgueiro (gsalguei) wrote: > As Joe mentioned, we're certainly open to expanding to UTF-8. To your (valid) point regarding YANG, would the group prefer to see the trace log syntax expressed in YANG instead of ABNF? We stuck with BNF-based out of sheer habit. If we did this, for the sake of consistency, would we also want the syntax updated (RBNF->YANG) in Nitin's RIB IM draft as well? > > Gonzalo > > > On Apr 14, 2014, at 8:01 PM, Jeffrey Haas wrote: > >> Authors, >> >> While reviewing draft-clarke-i2rs-traceability, one big thing jumped out at >> me that will require a bit more consideration: ABNF is only ASCII-friendly. >> Since one of the data modeling languages we're considering is Yang, we need >> to have support for unicode (UTF-8, e.g.). >> >> I don't have a specific suggested fix at this time. I suspect this is a >> bigger issue than just ours as it impacts other consumers of ABNF. >> >> -- Jeff >> >> _______________________________________________ >> 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 nobody Wed Apr 16 06:35:23 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253111A0193 for ; Wed, 16 Apr 2014 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4vDMGuUKo-5 for ; Wed, 16 Apr 2014 06:35:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9E1A0191 for ; Wed, 16 Apr 2014 06:35:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C1C29C2A4; Wed, 16 Apr 2014 09:35:17 -0400 (EDT) Date: Wed, 16 Apr 2014 09:35:17 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140416133517.GA21499@pfrc> References: <20140415000147.GA15705@pfrc> <4DEACA63-F472-467F-833C-38726E3C0F1D@cisco.com> <534D847E.7080802@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534D847E.7080802@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/RDxnvUU4I8SEtTe4Kh86L35rJqE Cc: Jeffrey Haas , "i2rs@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" , "draft-clarke-i2rs-traceability@tools.ietf.org" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 13:35:22 -0000 [Speaking with my chair hat off...] On Tue, Apr 15, 2014 at 03:11:58PM -0400, Joel M. Halpern wrote: > The question about languages mixes three very different spaces. > > 1) Is the format of a (potentially binary) packet on the wire, in > this case the trace log syntax. > 2) Is the data model for the command exchanges. > 3) Is the language used for information modeling. [...] > Item (2) is the domain of the protocol discussion the chairs are > trying to wrap up. I expect the mailing list to endorse the > conclusion that we should use YANG for this. It isn't fully clear to me that for our traceability mechanism that we must use the same data modeling language as the language we use for the rest of I2RS. Yes, there are potentially significant benefits to doing that, but I wouldn't preclude other considerations. The single biggest benefit addressing my original point is that if we chose Yang, the traceability could similarly use Yang (or even simply an XML document fragment). This would address the unicode consideration. There are two potential impacts that would have that may not beneficial: 1. Input and output would have to be modeled after CDATA anyway. The trace mechanism MUST be able to deal with malformed input and output. This means the useful structured bits of the trace in XML format are largely wrappers, not the data. Basically, trying to interpret the inputs to the trace using the same code is hazardous and needs to be called out as specifically discouraged. 2. There are some nice benefits to log formats that are effectively "single line". And yes, I'll immediately contrast this to formats that effectively split the outputs across multiple line and require some sophisticated cleanup in log parsers. Basically, the question begged is how syslog friendly are we concerned about in the base trace mechanism or are there considerations for a separate syslog format? -- Jeff From nobody Thu Apr 17 16:22:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239FB1A01CC for ; Thu, 17 Apr 2014 16:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NueL-lk6n440 for ; Thu, 17 Apr 2014 16:22:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E81401A0196 for ; Thu, 17 Apr 2014 16:22:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFU54040; Thu, 17 Apr 2014 23:22:37 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 00:21:10 +0100 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 00:22:36 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml705-chm.china.huawei.com ([169.254.7.19]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 16:22:24 -0700 From: Linda Dunbar To: "nitin_bahadur@yahoo.com" , "ronf@juniper.net" , "sriganesh.kini@ericsson.com" , "jmedved@cisco.com" Thread-Topic: questions to draft-ietf-rib-info-model-02 Thread-Index: Ac9ak+OHyF+bZSP8Rkam+5RoM1oqcw== Date: Thu, 17 Apr 2014 23:22:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF8CED@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.181] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JMwXmxtNTqhnRCWPvZ0lVrrg2Lo Cc: "i2rs@ietf.org" Subject: [i2rs] questions to draft-ietf-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 23:22:49 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_" --_000_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nitin, et al, Your draft is written very well and clear. Here are some questions to the draft: - Figure 3 (Page 8): Is the "nexthop-list" counted as the "Actio= n" when the "match" condition is met? - What is the relationship between "nexthop-list" and "route-attri= bute"? - Why the Route-attribute ranges 0-N, whereas the "nexthop-list" s= tarts from 1? - What kind of scenario will cause "Lists of lists", i.e. the "Cha= in" in the "nexthop-list-member"? You have a statement in the draft: [cid:image001.png@01CF5A69.FAAE3320] Isn't one node supposed to deal with only the outer header? Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin, et al,

 

Your draft is written very well and clear.

Here are some questions to the draft:

 

-       = ;   Figure 3 (Page 8): Is the  "nexthop-list"  counted as the "Action&quo= t; when the "match" condition is met?

 

-       = ;   What is the relationship bet= ween "nexthop-list" and "route-attribute"?

 

 

-     &= nbsp;    Why the Route-attribute ranges 0-N, whereas the = 220;nexthop-list” starts from 1?

 

-     &= nbsp;    What kind of scenario will cause “Lists of li= sts”, i.e. the “Chain” in the “nexthop-list-member&= #8221;?

 

You have a statement in t= he draft:

<= o:p>

 

Isn’t one node supp= osed to deal with only the outer header?

 

Thanks, Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_-- --_004_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=18851; creation-date="Thu, 17 Apr 2014 23:22:24 GMT"; modification-date="Thu, 17 Apr 2014 23:22:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAgcAAAA7CAYAAADvhinEAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAEkjSURBVHja 7d0FkC1XtTfwQxWv6j0+qCBfPSB5BIIkwMXdCe7u7u7uENzd3d0hQQIx3N0lAQJEkADBrb/8+nz/ mTU7Z+b0mXvn3pm8XlVdM+ec7t17L/kv2bt3T7qu2/eEY7/hx5EnHD8dj/EYj/EYj/EYj5PoMfn/ Tn8gPfGEYzIe4zEe4zEe4zEeJ+FjgeDgqyccp9hlHf3GNybdxz8+6f70p83DPH362Mcm3W9/u/42 jj120r31rZPur3896SrZD34wld3xx2/N/v/qV5PuAx+Yyvo3v/nfCxY//emke8c7Vv/9F7+Y8umj H510Rx65a/v6ox8ty4yNLXo9e3z726djHnrNH/846Q44YHp85zs7biyHHz7pDjxw0v361xvLsy9+ cdr3L31pdIyb/fjXvybdZz876T7xiUn3z3/u8uDg7v0F73znpLvvfSfdoYdOG3jlK6efH/3oKThs T2cM8pnPnA68/e1d75p0e+01NZLNIqD3vnfSnfOck+5tb1t/G0cfPemue91Jd9xxJ11FPuSQSXe2 s026979/a/afjB784El37nNPuje/edg1L3jBpPvZz05acvzWtybdjW406f797xP/9s1vTrp73WvS Pfzhk+4xj5l0Bx20a/sKJ+5+90l3vvNNule8YuVvEoxnPWt+Gze72aT79KcXCyLvc59Jd73rTbpr XGPS/eMfO2Ysn/nMpDvveSfdC1+4sTwTDN385pPukpecLePx2DwHX/mc50y6s5510n3/++tr46Uv nXQ//vF2Bwd/OuE4x1K2vPfek+5CF5oq/5e/POkufelJd+97L2eGFOtTn5oqW735V74y6d7znuXA QnTNYfisrY98ZOpsdVqGIiColYJ73GPSvfvdk+7b357+dswxKwcjg//wh6fXHnXU9Ls//GHSve99 0347X5/0bVFGfv7z02vd+6tfnXR///v0+/vffxocyFT07ec/XxndGb++fuhDy9fkOPjgadXA9TX6 +8lPplkPp3TEEdN2WwXAL3xz3te/Pum+973FxuNa4/nud6fX/+1v0+/JEBj5rWY/Aj/BkIzwl7+c 9sl1Q++HT294w7SfkWEbCYuC3deYh7Spr8Yv44ms6VOb+dBR7frr+Mtfln/zv6rG/vvPrgrghXHL Ph/1qEn32tcOqyid//zTgJkuVn2sAccHPzjVjUUDw9gWe/ra16a6EJ2h4xy1dmdlvdFjcm9/+93v ptfJ/MkpOkc27EpghBezMk5O5drXnvKfjf/5z1M9cb5xBhvc12cB41pjpAOyWNmRzFnfjI+MIxe/ x6Y48fo5B5m9+MUr9Yw8znWuSfea10z/18fov4Ne+/6Nb5x0v//9ShuAJWxcNQyv/J1VKRMgVD3L gS/aoG+LVAuf/vRJ94xnTGXqvvCmPQevjIUutHZCRqthH13UJzwkH0FRDWx851rBYa2SkDVZGgf8 gt/sK+fwA2xLf/GUXSySGQcPqj3rY+7rHFjsfzoX3dAXeOu7Wq00Dn1JH+mVtoZUfo1F5eaTn5zq Rotfqx3w0j3oTu7fyo5ORD7GMysQgNf0m11W2xWsu8bY6ZTkveIyu8ELwXL1pdrhwx/xiGVfy17X ERx8/oRjt6WL7nCHqQIxLp8f9rBJ9/rXT/8HsE94wqR76EOnx53uNO1wovmrX33Snec8089PfvLU SFUfGLXIWCR0t7tNsxDtVuP0/fWvPzUUwYg+BHS/8IVJ98AHTu8piBDBAxDX68OZzzwFa+e4FlOG TlE89anTLER/HvKQaVtxJD7LElQ8OED3TsZISO4l69SH/fZbCULPf/70+4tcZGps+Z7i+e7CF562 Kxsz7hiJMT372dOxGtONbzzprnnNYWMBWK69610n3YMeNOWDYC+O5GUvm/Jen29zm+UMEOCRnQwG P1x361sPz6xUl4zHdfp9v/tNwTcZF974Hj/veMcpWM1rk1O97W0n3dWutvxZn/Uz57zpTVO5uC/Z n/70y2NluL7HB+Ml3xg93dAn8vO98+gqA57XL8Z49rNPHSY9NNYf/nBlUPiAB0zveZe7TP/n5IcA 5stfPpUPPnF85zjHFGwAxgUusByUPPKRk+6Wt1yutAHJpz1tep3x3PnOyzYbsNAPNvb4x0+rWYAn 4MRWyfuKVzxxVglcLn/5SXeJS0zHRI4AT78kDnQmwC3wZ+PVYc862PMee0z5ox/6TLZk5f76vuee y8nHq189tcs2sGQ7L3nJSqB90pOmlax73nPKS5UO/c05nA2ZwSkON9+7l3FKYLSLz3gcfKu8vMEN ThwccMLuRSfw2j3aBGe1g81e7nLTAIEMr3OdZUdCV8mWnuM/PadjSSKcn+/pZOzOcdhhUx7jK33S bzJL9ZbDZwNkCjNe97plW4Pz27ZN8UB1hoxcz65SBTZO7d7kJlNMGzp9RX9dG/ukfzDS/S94wel9 3IPusQFj0Cd69pSnTPvsOrgtCEgFkw5f5jJTmeHZrW416Z74xPl9EhCyGWMhN3JPkrvWATfxU9XR WFzv2opvMIou4jEdF9TkNwEJeyTbxz1u6vOuetXl32G/YND02alPPfUnsXnBHJnjg4PuZboPL+g3 O9e2o50KGxgcfKzLegOGCZBFqG7MURk04/Q7o6+gw3kTUIxYEMCoAmC1QwTLCa6WSQlKGGUibozC FEqjT4KBnMtwKLPfAC+ACgDrAwG15cZZByECkDhv0ZV2E21SFIqYQMNYVQMSXQcUHRx46wQEGbKM NmsFAre73XLka9yUPkEHBclcqs/OH2J4nAu+J8PCa30OqNZ+iCbxvF4LXCIfpVkKN+S+nA5Ay3j0 nf7IZF/1qpXleoYoyBoy3wu8GXjNLOpngYKIOxE6AxOMGD9wkI3mXFkBHgMdMnRugjlGtc8+y7Kd d9AvY2u/B1QAoGZhDBU41ABx1kGXAE2CRP0EbAE//1/pSsuODnjRE59VbTjmGli5p35wBPhdeaF6 QOfq/QU4N7zh7Gm/5z1vCuCzpiKAXvQNPiiHDgmEAJ/qBXuDL3Tnylde1j+/J5jDC5/bChqHVYOD YBLnMi9zZ38CvfqdytFFL7psJ8YnYKhrLGDarOCAblXg5+jwbWiCAu+CJ5x9+MjZv+hFK50rJ5TE qVYzE+TDcRhGB2o1gU3IKHMufAvWubfApmbNnI7zg2vONW78oKuZaha8CsrmjVMw89jHTjEh1VTt uTbJqIAg00L0Q59yPT7EFzlk7YKYakOmp7UXLBoSoMGBOm2uD7e//fDyvcBZFp8K+r77LssHzxJw kwU9zmf2ImmOzfFxgqb8Do/xgu1rt1aLYHP1iXx21RPYrjqzndMKB59w/J+l4ICSUhAMEghwNoko L3vZKTCKsmSADJtjBry5KQf7H/+xEqzCJA5EhD2rs9qq89YcjlKKkgzQas/nJAAkh6HPrZOk+EMy 3qpsDqAS4QgMajbJ2N7ylmVnxOmJ5gAk3rQOg4IYc1vaAiQqJPVzggPGQmlE4xwNEHOfWaDdHpSp XbeRsmCMmDGRH+WpBgCMapQtM2DIQwyEAbeOFTBq71rXmkb00RlyNVcsexyynqEGAzKh+pnDI3vt Gw9wJzvgLtM2PvJxX/9f4QpTfgiYWsOhL0OmFcLnWYbHZtyr/V6AWEuyqx2yDPZlPOQuq0iQqNLx 3OeuPF9mAOT9pS+RK1syfrrA3uIw2ipT/czmOb1ZekYXKgi3fBNsAEd9HrKwjgxUDGAFByRI1x+2 Qnb6oC8JBnJ+O/02KzjguPCjViVnHRIOmXML9Bxv/c59axY5Kzjg9GT+dDH6JhFyjyH6xPbxOJ85 NwGD/03ncCixH1n0pS61rE/+CvTc1yGAjCNqdRE/6WISI1US9ph2VaYqfpDNrCQLnlh3o18wim2l mrHWAQfpaZsgcnzaSQJDp8jPPWrlhlz1P7xgh3Qmus3Bw5uatA096DAc0zZ/M8uOZx1wjp3W78g+ VSmJmaCMbATpNQBn66YJV7NLCaeKTGv3rlHpJLPIXVvuW/3jWtN7C1cO0mHzRxhO6XQwDpFRiPAA I6B2c9FLXY9gIErq/tYyINAAUlUxKmBxvDU4wEgC42AZaHWwMvmb3nQKjO4vUqsKIcsxnTFPsCKt /fY7cTk7zlQ5pgYHgonMy/pN0CQ40U8ZRls50GcCa7MYlYAaHPg/0bLMUVDEKQBsRo7vQ9ZSGIuo vM1Ik3VTpshMdadWDkSwNTggvyHZQIIDQWT9TmRLb+iTILPqDMOZl0k7XAOAaqZwi1ssl6YBknaU uAVmMk9AQx9NBwGWet/M19GP6HQO0xdDphViB7UkXef8jbfKW+ZCf+ctYKR3ggMOE4irjgk645QF akCgVmDci1MWTNBlQXrGSl/wAX/83i5Oap2nykHldT3oQoLXWWNOaVhQPoR/+AMkjVWmJMjTT8Bv PMCTI0gWS4dVSVoecuStvivDkn2VwayAh+634GnarQIs/nFAqd4E7Fs+uZcpGddHBgKKOt201iEw qMGBwCCVA7KDp2mXzuM5jEqFN0kSR36VqyzLUxCcjNahyiZATiArkMiqeLzQRtUL+K8q1faXHUo0 YLqAzToj9jPPKXN8gpHPfW7l9xKLGpTRefc1tqq3dIKjpdvR8zpHrz9DqkazpnXot3Zho3ELEoZc SzYCnmrHfJMKJt6wWWsztAvjM52X4LZd51PlpV2yVj2qQZKKFl9qrRA+RN9qpR42uG/1tXWtycDg 4LsnHP936abKSCIhgnbTyWQZNCmXaQbzduarlf05JE4aIzh0GXQELsK1IE+WrXQjAKD0BsVBxvkw uItffOqwnKt0drGLLZd+ORelNkqoL0CTIcZJnO5009/1j7Ao4JDokfMW3euLa2XsnD4DEYVyNgxM n3wGAByh4ER0K1CioDJOc6SyGCVWfRaBq0qYj/I3C6rcEwgCHf9TJkoPBPSZIpzlLNMSZRbtyASH rFoFniJGjoKMjMe1+qutKKq+GTeeAz7jBZZAVZ8oqN8FhvMeFZOpaWf33af3E9hwFJwZMNAPgUN0 xr2jM/PGIzCUjQnCyB6w4Q3HiKfuyclrk/HQv5SAM3WA7+4rUwI6nBD9UhUiP/2lh//5n9Pgb8gj mdoxJnosCOXg8DAZFT0mv6yJaAOR1fhoXl2gyNC1DRxTkRG4WVPBAeuzzCbTNXSQTQBtY3Ww4WSX eEe/nO8ctpJg1HjxSAZknpK94mcCZIkCoJGhkaF71zl8jheQmusd+jge+2BLAJNO4j/dl7lmASoe whp9A6InP/m0//rFIZCnPhmX4CL6pB1BMF3EQ23XaTl2QDYyMjrq2ug4Oz7taafBkGvhlXYAK5vA O05cP/EJPoZPghT64zo2Rk5DgiU8gwd4HDxQLWDH7slhka3xkqtEhF5n8aJpUfczDusPlNVdo8/6 xNG5lh6pbpzqVFPMNGbYpo/BBO2SN5xyL/bmHA6sVr70zRoj/NAfNqCPdc3VagfdJh+24Z4CGhhV p4wEeNautFNUxutcOsj38Av01lj5ELhnnQQM1beh+si2YBJ5wlsJiPENCe5Um/gfdm+aiu9JtUWy qKqiQqW/9IM/yHoSyQpeGAfbou9J0NiBCqs+0AP6SpdVDciH/4MV9I2syJeeJxDGF0E7+dBrNl+n oAYGB/864Th/fwHGAFhHBgBE6gpJkQxwpJScoc+UgrEALM5T5ykrh+O8zL/IFLLow2ASFRogJaRg zqGsPlP2DIhRy0b1rZYDMYYDcQ3AZ7xDFwJlfhwY6CeHw+gomwg9ix/1wf3z2TlZBMagKDbBZJEl B0TZgItxuI7ggSpe+i5zwo58FvkBOYqGP8aD/+0K5bUO/NMv4wEOjCYKI/vgrGQNjF2/8F7g4V76 QaGBbz7PmluvB6V3HiVkFAyAM68LQmUn+KFPlBo4DQGSlHEpOSCPTDgM/ccn99Su6L99/h4QcTJ+ 51iMK7wQSLkGP7L6WdtDghZjY3x4RGfwrGanQI8utHO+89o0Ho7ceF1fpy4AAx44x3jIrV7PXmU/ fnOOLLDKgBzJRtv4lwyFvrC7qqsAKvLBN9/5TdvG3AaM+Oiei2RrnC6dAeTuJ5AUZAH+VDYyVucZ WxYXxnHXftUsiX0ak+BK0FgrmJKHjNVfPIljokv6QKbGSRZVX5wbfHStcdcslb653r1dO+RxV3pc 8QD453Nw11/VBOPkjFwT+XAqwS4VNDhTZYF3ZA4TOBx9y1QMHmvP9fhC38hBkCL4TT8cmVqOkxYQ BGc4nyGVwFqlgpd4TA/alfQCLpXMWftJ0GO2gc98TnwIHKqygdNDbDnTQoIk/RFURAZDHs/WT36K 7ri+XWytkkkP8S9YX6sx+o+PxgOXU1nHX36SPNiqoEMQnoQAj9ixe9NL+lYrXK4jF30ibxhVn5ob GBygJy88R7NZDgZprnOr9n88xmPIIbha1AHvjIMj5iBqNWGrHgLXoYtwx2M8EmwOnX7dTMcCwcEx Jxx7bbkBmtdRtlGOFZHNe756PMZjKx6yDwt/rYqWJWyGDZhU12TzSs+mAOvK6a14yDLx15SBbKs+ cTIe4zHrUIn0dIupeJWKRfej2SLBAXp/N51e2LZljuOP39Yddti27tBDt3UHHLCtO+KIrdP38RiP oceRR27rDj54W3fQQdu6/fff1h133Obo1yGHbOsOPHDar8MP39o8PuaYKY8dsOToo0e9G4+1j6OO mup+dObYY7dO3xcMDkYaaaSRRhpppJM6jcHBSCONNNJII420gsbgYKSRRhpppJFGWkELBwdf+9rX uo997GPdn//85+268Te/+c3ufe97X3fIIYd0xx577CiJQj/+8Y+7j370o92vfvWrXXL/v//9793b 3va27sgjj9zhbZP1+9///u7DH/5w9/3vf39LyCN9PvDAA7vf/OY3C1379a9/vfvABz7QfepTn+r+ /e9//6/V6c997nPdhz70oR3WHl5+5jOf6eUCQ+jsSZm+8Y1vLOngH/7whx3evra/8pWv7JSxfOtb 3+rHcfzxx29KXv/ud7/rDjjggN5uv/e97/2vtdmFg4N3vOMd3VnOcpbtUqSPfOQj3f3ud7/uMY95 TPekJz2pB9CRlumzn/1sd77zna97/vOfv67rP/GJT3RvectbtqsPt7zlLbtPf/rTO3RcxxxzTPeg Bz2oe/jDH9497nGP697znvdsCXno98Me9rBu27Zt3Zve9KaFrhXk3elOd+qv/f3vf7/hfWWX7Oo+ 97lPD3CbhV73utd197///XdYe4KDF77whd2d73zn7hznOEd3+OGHn6QxAe7e4x736Pbee+8eP3c0 3fe+9+1e//rX79A2n/70p3d/+9vfTvT9Bz/4we7sZz97nxyuh+CG4GIj6Le//W3vmx796Ed3j3jE I7p3vetd3b/+9a81r/nkJz/Zy+Y1r3nN0ndw4p73vOdScnCve92ru/e9790f7FOSjV760pcu/fb4 xz9+ZvIhOaHr+vOKV7xiYQxaL61rWuHWt751nwkddNBB3Vvf+tbu17/+9YrfMTMO6oc//OEKgxah XvGKV+zudre7de9973v7KkRlvmyZ8N/+9revMHgRnGyW40RHHHFEf16tOgDf/fffv7/HIln3n/70 p15YxiKjHUJ/+ctfeiX/4he/2EfynEDLi3/+85/9+I3FubMMRRTN8GUGgF1f0FOf+tTuiU984pLy OYeSVZKN4bEqTIhyAcwrXelK/W/69KUvfWkwL7761a/2173yla88kVzTPjngk3ZVOYaQcx/wgAd0 l7zkJbt3v/vdvdFVGdGBww47rL/3F77whaXvRfHGDkj+8Y9/9HzHh+985zu9007mGCILvzv/r3/9 a3/9xz/+8b7d1oG4zzvf+c6l4NRnsvrjH/+4wvD19eijj+4e9ahHda997WuXflNZwQs612au+KRv 7u28m970pn1/N5KMGyABD/fmjJ/ylKf0fWFrdAzPnYfXLR133HH9eDgfursI0UE8Zp+f//znl7Jb /Mc/wQFbqST4ZP+wwvna8Dl2YQx0kJ6T0yz+0Zsb3ehG3Xe/+90T/ebe68ED9LOf/azXU30LPtEn uoiX7BqesWs686Mf/WgJyOkju/v2t7+9gj9sxlj8TpcFb+k3ZwdPZdPuuxpe3PWud+3H05K+4Cde w8ahxH7JjWObVSnUh9gPG2Yj+DqPyHGfffbpnve85/W8cNSKB92kp+yYzv3iF79YIdOf/vSnfaXJ db/85S+XfnPeta51re5mN7vZEr5pYxHCc9fhPzmEVDIf8pCHdBe+8IV7PpKDfswjvulUpzpVd4Ur XKFvT1X94he/eHemM52pO+qoo/r+nfe85+2dP5/15je/ufehbIWOXP/61+9ucIMbzKzIwx3BiiAC pgkiLn/5y88NWHZZcHDzm9+8u+ENb9hngQ996EO7O97xjkuREGPeb7/9+kxLhug3xhMFpiwYdb3r Xa974AMf2D3nOc9ZAiLMMXgCEiX5n+Igwcgd7nCHnunaE5Xe7na366MwRACuczz4wQ/uM6ehFQlO WOTs2lvc4hbdc5/73BVKs1pAYez/9V//1fdDpMlw73KXuyxVVfDEGJzn+8c+9rErDF6kTvD45Le9 9tpriY9AXT8QI7va1a7W8y73Nn7t4pO2RZRRppvc5CbdhS50of53918kQwdKeHHuc5+7B/lKjEeb 5PaEJzyhO+c5z9nzbAiR7TWucY3ughe8YC8fgcJPfvKT/jcGiAfa5YDpFUMClEAdb/GArrz4xS/u +3D729++d3B77LFH/xlfATQAutzlLtcHIa5/1rOe1fNY2+RUK16AnlECG2BBBgyVIyL/ZOB47NCH 6DKgNwZ6rn18jvP68pe/3MvEOIwHEKgcbGQZ9ec//3l/zxoAARDj5iAFDac//en7MarWcagCwOok 8NFYjIuMhvYXaLnukY98ZD/e0572tEsBKX2EB1e/+tX7PlQimzOf+cz9tfjuvGte85q9XFzvt4te 9KJ9lYl+3OpWt1oROMZhu7Yt/wLdYMGieMBRO59stfGMZzyjtznATS933333PpNDqhYclftxYvCO 3nB+qm+CiwRu+K9NcvKXbGAGvX3JS17S7bbbbv01sWnjbqcQVKHaJEEwCy/ILfbJoQ8h/HQNu3zD G95womARBukr2RoX2Q6pKL785S/vzna2s/XjgyfuUbNi/CFrOKbf9DGOGM9ue9vb9roqicSLTEH+ 4Ac/6J3wZS5zmb5Ncjr44IMH24kgCH8c2naP2C0fw6+d5zzn6XWG/Q4JPARLN77xjfukTBuCDnJi 9/Ej/q+6C0fwBakQk98sIms6EYKHT3va03bKFOW6ggOAymjSQZEscATQlLwqGXC4+93vvhRZI2AA gCsBNYokcw2JgAFKvpM1KkdVoxGpqxgQdr3WfCSnP2RthOguAQpDu+pVr9qD7Twytj333HNFJC+r EMS4r6MCLGOI8+d4GUUqH86lLDImBJCUqhglEK/K8MY3vrF70YtetPTZPZSmOCUkSwOm20O3uc1t ukMPPXTFd9oVeKQvFHyR6QtGwyArxQm/+tWvXpIBwGcs1XkxNhFzQALQuJYRAxMZmWqJawFaSm8V kAQXLV9E7wIh+pjsn7GL7jmrBHMyFsGQQIuB0v+a0agoaF8bQKXOr5MXvd3I4EAQTV9awge6wr7w L3qt0gWQE0TQs1qBEYjWMulaJFmosnryk5+8omKI8INdVGKv9IkNXPayl+1lJVsT+CFOgR4GYAVw +lyrGuymDQ6CB7G1RfAAn+hUtX+BQA2wtYXX9LaOm67Aksp7eouUqwWhxihYk4Qg+Bb8uNjFLtbb QUj7L3vZy1b0T/DRBgeSDEFzSNVDkFb1cx65V5KPkCBAUhLnye5VNIc4zARtq1XLjBv+wfTgDdkj 2F6rloIAgWSIHBOcLUICevhTMUFSlQotUr2JzIYSPODAYYBgx0EvjCnjI+9aOcPHYNEzn/nMPuic Rao5/CJevepVrzpR9W0jaeHggIIokSq3hjCA45MJmjIQ4YuigIGBmT+v54v22nkTxjdrThKjM/dO CO7TzssAhkSpBMuA3HvfffcdVE5UZiIc13Kyl7jEJVYY+WokigVWtcRDsQUXlJuBBCA4EwCYbJwj oRSVgEvaevazn93z7cpXvvKS0YSATCJV4wSiF7nIRZYADKAwqO0hytyWnhk6JZUpAXBBXrL/ISTD JJtKQBMP/a0kw68RM6OWUbYEaAUpdEQVQQDCGSYYxW9G6HqOqOWLEnq9TwXhZH0h4wXMqisyWkGv 88jXGPzPubTt0cHrXOc6G7rAVJCWTKQS8BPk0HF2GWKPcVCcqcxRtpbxqPIIcoYQPmlbdkQfyaKd ZsGzFnQFdHjFYV/3utftcYQ86TOScFTdZ1MqENX+ZwUH/heMrQcP8FFZmfMPL7Tf8kJ2L4sO+Ifo n36zTdfpA5JIGCNMMCbnoEwTGAe7rs5UgBpeVL1sgwOYGDzwu2sufelLLzSdKJh4wQtesOI7wSyM kk2Trcob3Jo13dGSJIvOC1RmER8g2Kufk1TihYDHePAHbtb1VyqJ61mPxfbbMeofncp0riA2welQ olMq4XwGWeBVfEP0w+9+o4d+F7wmAGqDA/qtupfpTe3CNDro2lk4uCmCAyQ4qBEz4CFIIENJZZii TiUWwCE7q1mTICDl2ZCICIDX+d6URQFLHC8mtxkYQVzlKlfpgT735dhkDkMWkwB5WROwkvkzrNZZ zSKOAJDUeXfZO5CmFIRJ4bWrrC5zSzbDUbaOCv8CqioHsmcKxODNgYVEpIxDBhMe+18ZEJFNG2gN MehKlLBOK+iXDJgMZCR4Lttk1EOJ4QUsQ/iE/22pEkgDrJCgbdZcq1Ix2WuXE6Sb+o4ScOKNkp77 APVKSpKzMgXZL3CuJOhTcnZwatqtei5QAu7uU0HRvWWFrSMBSJzFjiAZhmyszpHSfU6ITqpI1eCA TdIjRG8udalL9TZpTGzCMWS+VTmdXOiX8ZMHEGwXQ7LNtmqkD/qED+waL7SV6QeYokpYMQJwt+sh akk6eCDjXQ8eqCAJfl3jWnzwf23fGOmmLL9WSZV72S17d7B/uhCAN0ZVEOAu0EQcuX4aOyfoupBq QFs5oOeqPq2tcnrBA2PFq0WeKMPn9l6qP/gBg2CcNjl8GDmP4AQZCIpCVW6SjBoc4EcW/7FZfIU/ bEdwUisjpgJqJWEovgmUTZFUMv0i6EnffF60csBXkC09VsGDcyqNfGHwXCDu/nSe/lS7b6cVBBuq oOySTGoVRWVDu5syOAAy5k/Pf/7z9+BJoDKOLOTDGJka5wdEKTJhphRFeTlfoEXxnEMhCIeCy7CB uuiYwoqogCpHbMpCaZdRum+ibNcqibmvQMI9KbDr5zl5zE40LmsRsZkq4JzmLcqiAKc+9al7wesP hWbsWcQkSFAKonBKtNoVAVJkhstRARO8suBEVKmcqc/Xvva1+74goGadBv4AKSCATzIQY9U+xxhg 4QwABv46x7lDHiPL42HAS2asf65X9sWL//mf/+nlhk/4BSCHlp6Bi2vJXpscUZQev4CebIEeMQiO BDjhk76r5gAUY6rlYv1SNWHgIm76kaAr83oCM23IhjmuLLxSnTDGLEByTjIIU1oCH4EWh6X0aH0J 4GK8ZGNe1TX4z/DpZ4ISfcVHfQAcJzvZyfpz45wEuKpsStg7ivRTdUS1ih3oq35mmkZ1QCBP/6wZ MW52Se6mYvCNU2eTdWpmLXI+G8AnsiMfzj3TY4Ik/MBL88R+z9yrvxwiXutbHm+2ZoTN0wlPRtEx 1wnI2CviZAX0MIhtsCM2D1DphP6TLV1lI9odggeSE7whS/LCCzarZIxvHNoFLnCBpeSITqkyGC8e wysBp/PIgh0Jmug6fhsz25Eo0AHYo1/GaxycL35pnzwy7ZjFs3jIkTonAagAJnigv+QAc4c8hgcr tCXwFXhpI+tW8Po0pznNkmzZSJ3mXYvIRz8FTGTAmesTgmFwgI2wN/ZojRDHTT50BR66P0xwroAt FSM6ByvpO2esnXYtymoBC51QlTVONivpyLXGrQ/wxO/4XYObtXyiyrVx1iCTn+Qj2JwqMF7AolpV EyiYphfgkgPMgCuSCXZrjR1+ZBE3OUu+N2VwQBgUhJM3WIDfll9FmAwM4wnZZ4YFhBgPY/KbdrRR F/+JerMwikHHQQMC5zvy6EddDYzhlMVvDlku4xiy6lqGoF0RHAVR5uFs50XenJeolhIrdZm3qwve KLppEW3JZhgI5YtT1D4A5sA4fu1xHgwWj5K5Myb94zDz+A8gxTtj1W9jiGNDnDweAR68GzLf7d4M JnwOrzPPb56P/FVzOLWhi54Q5TamtOmoi+f8jz/6TGcyreMvg4jOONqqk88JfgQWFbwACV0CmvTU 9dFXAWD00F+6meoLEqgpo3KysrtktZwZMCc7/SVTv9VqAfsQrGqTPAUX5JUMh86bd9zeR05bojN0 Ub9ScQOqQFHf6U/9XCtSxug617t2yNMVbIwjFhjjoTHV9UXG7vsq+2Tb+gEn2LH+uL9rnccpyrzp HKdLhnQ6BDiBfNVV52StADzI6m73JKuheMCJcO6u1S+6w5bpBl1Q0QDi8IwtyDTzGCD9cx29Y6P6 lcQJDghmjM33Ama/0R/9hiV4wNnRm8r/8LfaZdYYtXjAftjAkGya7UQ+sS+6i8iC/sNS35PDInuT CKKNOVMI0Qu44X7ky2bYY/0Mx1yHDxIea5+MuSYF+KZP8JVeDK3AJbsnI5XPWvV1n4oHjiGBUPpf 14sILvMoI2wIf9u1Sioilfe5dwIpbdIZ19G9RTB3pwcHIy0TZc+irpFGGmnHkpL8ep+F32rEkVqT cFLfzGmkrUNjcLBOUn4UfXqWVTluPatnRxpppNkkW1eqNfcqg6wVnZMaCQhk5RbUevKjfaRwpJF2 BY3BwTpJGcviEiU4c5pDyk8jjTTSMFKVM5du/l6g0C7mPCmRqQ5Tr7DEWOumZiONtKtoDA5GGmmk kUYaaaQVNAYHI4000kgjjTTSChqDg11EVs0uuvfAjiQrsj1BsTO24VQ2db9F9+vfleRJkp1dysYf a1l2xr7pO5s8EjZk34SRTkymMHeGLsIkdjpv6/gdTXYk9TTVkPvCK310zLITNmS/mF1lR/pnLEPu 7/fNbO8nqeDAM6UemTNPSeHMW/rrUROPCHmO1O91C0qKZM2A3/3msEK6PjazEWQBkmd7dxVgeuTS zmA7EgjMlc5ae+ExLc9v1014Njt5fMjGQPXZ5UXI462zXly1FuGTFeuztkHe6uRR3WwItFmJY/Eo NdnVR+NgAXzwOKPHLvNYK6zwfx55zr76Do/a1Q3dQvDItR69ZS/tNtOzyDoEulgfO90IsleM/VXs z7AzyGPK9uGwCNPjoHnp1lqUvSHsV+K69hFGjxnDGRswte/y2BlkcanHDu1s61HJtcgiW/s3tLtg bhZad3AgQvL4Td3KVAQEEDncvLmLQfm/bj7CIckkWuPBLOclkvL70P3obTphYwzPiNqch2LYQtVz rJ6l9rIUQvCEgb+e3c0YbOLkJS9+80wupbMRy/bsXifS1/f64hSKgxf4Y5ycc97EuJojcV67cQsw 0u/sawDU2m1h8RCPZ70mmMyAnGfs262fc37uMZRUQfLyJM9ne5Y78sVnAZjNPnL/WXJ1f30eWs2g R/iWMbi27vUQMiZ9Wq1dMnEt+eCl88gPCNnEyn30zZjavS+028rH2MiW8/C7Y4guGQenYtOk8GmW g9E3bc76DcUG9XuRrMT52q0643r9yCN2/h/yVr7aJr5xuvUFOXiMb6meabM+kVBtx3jr21cr4SvZ 1XHOGod+z6tcGaNdIyeTydJW5GzgjGc8Y78BGGdGPp5QsjWy/Uk8ew5rbHRk7wMb6NjQCea0Ns3m 7FXiGo7DhkbZpXJevzyxYaMn41xNl+m+/s76jd66bpZ9ZJz2GLDIWoBQk4bgdX3MMphTdaHKcx6R jT1YPOnlbaH2bGjxhg64b7U5YzMO53sBU7sXR/pq/4bVdhKMfszSt8qfVFIqVkUXZyVVeOLeklRP nLRbxc8iAVHsPXtphNi372rVlb7j3dDEg760fnpDgwMbYdikgxMF+DZqIECDIGw7geVtiYzB57xk QhTOMERM9Q1jhG5DC7th2VTF5hGuAbLz3gLmXNFi3aDDvuJeqENQGB7HlP7XrNnGEjY2CdmQx/4F 2/OiHM7Qbn224Y3iABA7X8mikR3f8JGRUBDZVZTAvW2kgZ+CHrvERXFlJgxYO9lcyRbC2WLUd9lK 2M6BdaMdygJoZKiAqQKJnbfs/ia4smkPHsgmhjg2u4DZzcuYZR7GU7dHJSO7sNEVmbF7p4KjT4I7 gZ0+2wRryO5uDNzulEDCxlWuFejlPR7ky7kzUmOhk9VI8NOmT3SULtv8x453cUQCHVkeXRJo4lm2 rgWkqj+uo3vuE/BUdRCM6he9s7nN0DcC4qPH9+xKx+nodzZtwie79ZEf4GNDdf98ek5n6JUNZehH u2HUagSgXUN2eJosjk2TF9l6XFfw7L5DN2Ox+x39JXubFlWHx77ttJrNwfAqb2FVvbNjoM224IJ+ 2RimgrfMm4PWH+dlF1Z2hgd2J7QplCCNvsGbeTbNVthotnpmd9qp24Rrq74rht0KBhD5sL1ZhI91 C3AbMw19f4XNiOiZe9E5/akBU968adyy8WzIBU9skhad8XutitqQh637Hi9jA8EhyRXZ4LFNprKb IIdjB0u8oQsqKDBU34YkFcYBn+0cSN/YbRxjdqIkA78Jptr3STgXBq62UZdgdNY7UwQV8C32k/cU wGE7GhoHTGRrqju+y061NpPDA32ii9XfsB8VA+Pn3/S93S58Fqlu2/0VluAnvIclghDBtOqyNsMb m5PBaFW4eUmUscAwvOXv4NIileKFg4O8JYoyil4YIsOwKxeisAYY8NAhiizCjKJlZ0NtUcjs9IUh tikFxBQa47IX9VoEdGa9ljg7fVEggIuxAg2GRhnCXEykKAzKLmPKd7bE3J65oLzdkQNkUDVYsj0m IjC8EYy4N2fif/2y0xoHAQwdHD8HmqwWD72WmfC1r5xmbIzdrm7ViAFnzdrIws5jQKBG+v7n1G29 TFb4BpSHvAlMvwRCAF9k22bZZOhVqAIQegP8OQ3X+d/OesnAZWcChCEZKsdpi1c85ciMS2VIuZYh 2PUsAIIv2ZPdfekYudBh8nIusMsOZoCbXjNWOiYrECjpJ3DIVr7uq53oYN5IZxzGWqth84iD82po 4CiQkYEAhwQHtgjOzpL6C+QyH62P+pyKG9tq98tfjQRj2X5bHwRCCaTIbu+99+710XfGrU9DKjz6 rC+cLJCqJBP3ymMBKH2hZ7aUBoSuo3sCK8EuPnIG2QmTvQDhYAm8Id/MRdMdMlABhFVk6tpZlbRK eaUvBwIX6GV27gy17x0RgKUCwOlxsLMou6hyzpIWvFytItKSAMnUAqzEH/fLFs5sgD5qk0zwAo7R A06eXmb6UtAniHaeAA0PBX364RwOlUNEeK6/0QuYkspg5tYFBColsMn9Bc9DthyGDfqMJ6mmRp+M C2bRSdiHXwKr2FswvX1RVSXntsFB3gEkcGCTMII/gj/wXoIFA92f3bFjGC4IyC6ecBaRf14rT455 gZaxsB8OfFZw0hJbPsUpTtEHIHSUXmuXH0Qq3HU6zhST4GTIu3/4vwSx+siW6rs7dnhwAITbaFdH K5gAsGwKxGHk7X4UXOAgYDB4kTPAqHMzBJUXlAyl+m4HwCCzBuiMAoBSPI6JsJT9ML+2z7hsuCJA OMMZzrDD9q7GK8IALvaIF+wAwkScwK9mfu5vzp7Cm7OShdiW1cHYZZHJThmiYAJwVpKZZ399PKZc ApB2Xktf8LktA8pOKvDNejvjapSXRc0iwFLLfHldL3lRWsahr9ELmeoQRab8KcuF6GfevgZcZB14 mPe4IwBWI/KQbDTOloMAfLKuSkCAvusvXQEkQK7ulolvCU4XIdNM+FH7g2/RV/Ln5PBJlUDQmyCM U1AlwUu6wwaHzGnXAE67gJ7+RbcAY5UdkMXzRRaz5h33lThyDjxAx5kJAPLuC5lwfckPB5FqFL4L rqMz/tKZun25qtmim5PlFb4SCbKnA+3LeNgpPeJEVDlhWmQt4KwvDONgXJ/t49mx6wUYHGDeQTGP 4KhrQ+xM4IL0TTDNbvAFP/Am2OLeAiTf4wfZRtdamXDEkgbE0XsHBP2OXXoXRrA2tpbEZ1EyBpjR 6gScrq/MDkZXJ7me4ADu80GVBCBwiO6pPkoUVNzYoP/xmNzwV4DId8XmYQCs5LOy3XHI70Ne4KTi YP1EnfKC7XAYDrFteh+9llzWIGkewV39VZHjL4as61h3cMB4ArAhQQFBJQr2F0gZEKcUB4S5QIai A1MHha/OiEOvUfoQYqB1X2uOQMDBIfuewgW4AXurIDIEkThHRdCMmWFs72I9AEOwMriUyzmatMs5 1ReGAA1gIWtXUlWRoXTAxv8puSIAqgzbAjQDYNwMLzz2v5JYGxwA5pYoZZ3G4eRUb4YQQ0oJriVA ZXxVad0LL5RxRfCmV4zVmIHskL39BX+MtJJ26BHDz/iBEH7nrYza1p+1SqDkhe8CurxUCcnGgabx Akb3MO76JkL6NpRvLVgAq8iVw84CMU7Z/dzLQccZfKoSMhb3BOQCUmVOfJ03104GeYeB8bJPGXey JMFBDXwELItuG443deoOybryqts4hvpZcFBfT1vfBaFKYgoSfuA/nREQ1rnYvPFwEeLwtQeY8UDF je1UoGcTAg96hs81IBGUVWepP5wxXlZ9EDQIdIZklwhmVdwiozhW2S3MNJ0R+yFPWSz9ic64hj4k OFCFaGUiOIDlSP9UJ903VQ98T/AWG1nvjo5rBQf1HkiCUsv0eTndahk0XMjbWUN5v0mlBLqCbr+Z NiBrfOHn+BYEv/k09oHHeW20xFPlqL49ND5oyEJDNluncZDqgb5nCowN6IeqAR4M8Uv4SFbkzifQ U1XRRRKWhYMDEZ0OysYALEdGKdv3a3PKSoR1b3RGpuzsGsYnWjPgdFiUpHyuEgC0CX5IdkKROBpC UprRDscgytVHmXoWrxACoYmks6BLpgTsZJEOGSsDqosJKRFjWeRxPGU6Cx1F15yhYCVrLwjeitpE gT4zchEy3sTBMXCf3d/cqfsDFoAka8RLwVgCMAYvI3E+PsictZlpniwaBVTGqI8BVO0ylJTH3VcU 3c73rUaiakalPQouYs2UEWM1vig8XZDd6CNQV2Uhc30gJzJps4fVgo7//u//7p032akkMOq87tR8 JR7IAjhZDiYyNGWQl68wcjwBWHhO74yFzPFM8Gh82pJRk2kWk+IT+dbgwLXGry19NL4ha1joA77k XJE+8ABe2rAug17iDcCQ3SbAYQP0Bk/1X384snn79Se4F5hqG++tBchOfcaWV8gi9lE/r0V4Qx/g AdCnq7ErDnPfffddqm4osfoscAWA+p63fhqDYC5VPc7CZ7btHuxevxNYwA6JiIqCe662EK8lU45Z 5S6DCz4kQHMvwajqTft4oT7jvwTAmOkxOwxvLUAU4NM1PId1Q9YckKVAj0MKHrpHslXOWdZr7Fmg KYjSB/fg8GAdnOSMVU+DK7BblVVf8V3GDKfon0AVDwUYzqVn9a2NxsGR0kO/LbJGS39goWAFLyrW 0xV8IVttsjNle74iAZe+wXTO1fUJkOmJvqg4kVNdMKw9dingcw4fASsT3JDzbrvt1suIrZ/udKdb smmYyMnCNTx2T9/hBd2TAKqo+F5V1NRMu7BzFsHHk5/85H3gxqYz9U5vQ1koqzI2tIrLdt1f//Ba sivhJL8NCw4QYxZBMU7ZJ4NtDSXlqRhrCAOBN6UT7VLqlL9EqAxIJikr9vtQhcsiPNGdtjFYvwAY Q7LwJYsDZUICB9EUYQMtc0RZPMZpE0YNBJTm/b7oOgSBiH5QfAFIsnLOjLAoK4VSkclnhguYGLII UtQqqqW8WSgDcAC4v6k41ChbRO9+jEo7qRxo11y/UpbrKRAwpIDKhjIF/GOAPnM+gHHIPCJZAQo8 FECmTEcG+GB8HLbP+uUzh2e8xm/s7iVDwZ8hlQNvZONQRMj6TU6ZhzYGfeBkACAemrdNNsmJko2+ 4DG9ZDyMHxDRwzzKSIfoiHPJEmDJIPBYWVnbNTgAPM41HiBonPOeVacH9C6vBM7css/67zOdNU48 4gBUMFLG5izcE7Aaj3PaaafVCGCyHcGU6hqe+p/9+ktWZEtWeOxz1m+sRQJ/dqOfMhd4wWEBTc5O O/pNd/IZCMuW6J5glY3SeZ9dn4oGGdFd/MADWXsCU4GS8wXArskc7lokwGZvFoHFAbIL1T924b4c B7uBEe6RviCZmmvpGBvQd8G1oFiAQpZkourgWucPWXUuaOUYYBZc5XzopsoG50KvODj9pG/4yM7o EweuwoVHAhcYop1kumwsNuJ6fRI8BCsFgoKLYKrgiRPLPLvF5nQFj1XYhpJkEp8sxmND9DVBLp7n 1d+wjf5lIXCeLuNbgl/0MYEqHNQWnkd/6EYCD/wjA/JxXhIuBOO0J4gQfNDbBBbpk3uFF/QtazkE KfieCjE80r9a+WpJn+kBHcVvumdseT14Jb/X6cZ5pL8CJGOAxbACBtPbIUnXuoODCmbreSFKsol2 wRlFdgAKv2t70U16tEmBKhBrM4+l1O+y4Uc2zXDPLCCr2RbDliktspgjxJlnDDXYMEZ9cu9sfpPP NQDBA32qEaix5TE3f+ujZhXowsNK7pXHI3N9+Oyzo/apfh5KeZSu8iAyyKYf+VyDP9/VRzSHkGAr pVGyb5+sMC79Sf/JvH0c0XfuW3noHH2L7KI/2sp3eZQSD2fpqb5od+jjXXUDl8on/1fddc/ot7bD 6+hNxrPoplOxv4ALfsY+IqvVZLeWw42tx66NJ5vZhK/arZ+r7ukDeeRzlVOwpOqM82MfsZ/VHvts dSW8zj3qpja+iw5r1z2qXRpjNugJljgn+hb5JFNeBC/zmDF+0qt8rvqun6vZT9WZPA5XSX8iz6pT 0YWWh3QrjyQbt98XqRyET5VXrb66X6qJ7X1b/KqVg+BeML0dqzZ8X22q/jbr/1AeF5011lRl09/o 8Fq+oeKz/2ctmDUmCciQheGzApDqZ30eOl0+7pA4gJRolJ939s5hI61NQFdE7ZEomdPQLHmkkUYa aSuQqpGqjif4NnpjvpbG4GAA7YwthkdanETpyvlKfOZkh87HjTTSSCNtBTIdaUrTQur17ta6XhqD g5FGGmmkkUYaaQWNwcFII4000kgjjbSCxuBgpJFGGmmkkTaYrFnbSm+m3a7gICupK1nNaaFYXi5U V3VaxZkVnFkxX1eEr0UeOfFIS/YM3wiyKtSjPOZ46nOmG0l4YTGde3rkaMiiOo+iOB8/6vsLEF56 xMzjRzb9GLJKe0dT9iD3COW8Z+w9CmQcNozaSkRv6W903YrgrJgGAn73m3Pmbdkb8iiVtRN5tn+j yL4F9MfRbjazmQiWZLW/leVZoV7fF7DIS6B2BlnJPlTem4HoarZdXpTYdjCcrPxfn6LJE1h5edAQ 0o+8P2SRJzoWJTjrHvY5aB+33yiCyxtt2zuS1hUcMEjPoXteF7B7jjuPk1lA4dlXz256ftWRzSuA kuedPQvsWVG/eVa33bVqFtmIQ7v1xSUbQR5XBNCL7gC3XhIQWGzi2XuHfQHmkcdRPG/tOvsVtIbt mXBK6DnfvIxmZxJj86wuec17phaweA6XLm0lsieHZ7s9/+7ZYc8oZy8Iz8h7vtj46blnmTmz9hHK loCpgC472G0U0R92pH9DX6C0s8mmWZ7l99y45+7xBC89G0/32amNZmzcs5nIM/R5/8NWIPY55O2B s4gM6DkMtw8D+WTDNLve2v/APgZ5mZfNjYa8xM1GYLa7t4HURpEgRkJCtxbdRXO9JAnc6Ndu70ha ODgQaXp8zK52doaSeYi+bNSCAByHZbMjIGTHJ5s35H0CHBrnKyMQTdoQZegWojagEJTIlu0Ul40x qrLa8MLqdeASopB2mlMVsNGHAKbuJZCtTO1yZbMZjrVuK+pRRps+2ZSDQqU0ZDMo7YlAs5OXDWhs rDNvsyR85GC8eAa/8LC+lyCbHeGV+856M6VHW/ISlVkkwLGZR0s2DiIHPLQTWKJ6m0hx1DWg8JY6 m2dkP3VBmvOMU//qvUXjNlexmRADt0NZNglZi7RtgxgyIjsBE71BHIH7yybwxOEcO7PN23dC34yV wyWn+nIumxTZq53B0iPjoVtDX9NNzwUDNqFS1bIXRvTCfekA2dBz1S7t4/U8AojZehkvHfXlPDIy O4EKytlg3SgKz1S86IzxZofDELnSY/yzk6SApu7T7p50zaZE9a2Y2SjKbqf4A+TdfyMdM7nADRgC H/LSJzLLNsL4S3fsdMkGW12nHx5BbvFgHsn8bQCGh67POPPK5fDMhjs+Z4MxDvFc5zpXv3MfPrq+ 3UKb/eCdPtnMKMRp4LFxy8iDR/RBYEkmAg/O146nKnN14zNYAD/cU99rxU72DtPgp82RbGSUPSts OOV11O6Nt9oYWm3Mq8P1TdvkE/vRtk2BjFUFgG6SUd2GfC2y1TmstTmaNiqv4BWdhF/ZGbLapc1/ YBAetTrhCSd2g7fwhg3UYM6mXbBRwpu3oSKJLd7CaTZo07DYxLyqCznpq3vO2qtA/1VZ6Qz+8K+z cHvTBwcYZpAtw7OjVow2b4MCjDU4cB6gj1OQuQzd0pFDsBmRXacYk/9jIHanExjIiCgVISaKBa4A k3MQJeo/A4mTzp7kHhUB4Bx2XjQDVCg1JaBM/qeweR+9+8nQOTCGB7i1Na+Mxngoop2+0lf3ytvS BDLAwH31iaK3b54EfqsFB9oX1VcH4TwgYedJu33hBaXEG0btfrI1wMFggCIj8FIqzgLQMRry8jvg zPSL34G4YAIf9QtQDtlZEV9PecpT9m2TnX3JGROdEYDZ5SzbTiM7PMpE5pUDgZfgE/+M1UYiidzz KuI99tij54nqFkAaCl4hVYFZjgePjCFEvu4/JDjwTLMd1vLKVbJPYMAxKk/qL96TQcqvxikQwk/g qW/ZmljgKgDzPfkAQDzPuz2ytbnf6AZ9zi6BgMr5Kg3uT8cFcLPehLqjCH5kV8PoKwL8+ki/bTNt Bz02QmfwNzsOOid4gPcVD9YiVVH2wCG7VrJAjpw6neFMsuWxIILO2xEvIK+aBF/cnw7UaVA7wWpb f7UtAckbZ8mdLeYVwWRpR0pBgnO9FVOgnF0WBUt5bS9d0Ee/448AkHyy+VbeAwBr6Qx8Y6+udb7s 3rVsgx7MmwpsiT7mldWVVIRrVdi92jdzziJBtqBbkOwawY7Koikbzp9cYTC78xcfYgP0nY7CJ2Ni 06nGkq1gLryg07Zez/b95JIADM/ZXpIiSTBZ2MGTnbgvnRNozEso+B+2nN1fKwmuBD/6ivf6cKYz nWnwq9Y3VXBAYesbqJSlGIBBZq6NY1VqAupKVjUCIxjbqHL09q5Ohjg0OGCsIcbFCN2XIonK9MMB XER2dQcqyuU3hpe90gmEcGqmL3AAApSU4lE01xEyI5YR17la4wQQ65m30347345f7l+N1Lwgh1hf FLRocCCzJ4/2ZUMMGzAYk0BJpqF8Kyq3PazsFS8AoawpPBbNk4n2OKmq0II2OjBkTpshyrbqeBlJ tgU2TvzVBwaON0MqEiE6kG1i6xsWAWV14AA3jngokcmst6RxDPiFf4BYZlVfDrYayQBNU2QKgvPI FBdA4yiBnfEIvMiutus635MJR5XqGudYK21kzCkEGPWVk6Hj2gb41c7JwBbkQ98iuCOJjdSXjqG8 90NlKMQuBbTkjWec8Vp4MIu8sKgF8GzTjPA6wQBShayBK/1ZrXQMryQ26ZPgh16EyFVA3b4chw4I 9BDnBo84fuMla7Jr5UJPkhELpgW9Kh+cJ73PWo1UdreHBDXti4fyPQfLBtxbn4a88RYOwNS6bwks I1vJB/kIxMJHAVfeworgIT0WKML5bGvOd1TZ4qHXNPMBqh50Bq/Tru/xO4me802VDLHjWdS+lAsJ wAVCMBCPyMP/i+DbpgkOZFmcaYhg7EdtjijgQyCyF4Ksyh+FoawEz7HIaExPDCGCqq9wZeyCAwze a6+9egPKWgZOU5QqcKBIghrRJ0PS37yxy3hagVEmgEQpZHGuSbsyFeOrc+nt+90XIYDRVk5EysbW EiWq5SZZn3GuRgyqggaAnDW/yGiUFxEjp/zWhgBE1RBZG1C1E6H7VR6LzAUueFRLqIxLVWTIAlIZ aH0dKwLsAUSkL3RFX/NmxXkkm3A+Xsq48K9eS/b1xTd5j/wiZNyqKy2xBbqDR3QGOA8JHgVcNeDz OVUsGZE5UnzJeh66mBfHsDnjcT+2Zaov01G+a6cB8lppmY+MSFuRLd2przvmINntriAVnjaT0mdO LWMSFAmGBKO+O+tZz7oqHqxFsI3DrwSwTf0h9lCDAZ+rTulrG8ikv9ZacXr4HPmp9IQ4JvbUkvcn xM5VdMiZbrte4Klv7Xs79ClvFIQB7Dr4x9ay216Sne1ZRS/ollS0ROdhhjHRP9M/Q3aZFRwYW6Y3 OWWyFgjBAYmENsNDcs+UHX6YGjFO/sKbO7PmzVRODSJiFyoQ+OCFU7C86gydzzQLngtIh7wPYxaR RxtEGav+CZzcy7j0YZFXrW8ULRwciGiAbd62h4AjZxIywAgW2NbMCsDlDY6yW1nzkDeTIUpdS4OE D4QZPCDgLCmfdmVOsmb/a59g8j1FzjoH0ZoyYCI1Rkw4+Z2xUx7G53oRJiOui8s4nvW8njdjahdZ yvD1oc79UyCBRJ0P5CzXWq9ByauSiaaNpzozBid7zrypSJ9BK5kJmmQyAh8GqmwLmCg0XjAWPPaZ 0dXXNSvBcWRDVhxrk2Fmnlt7DLxG6IJJBku38mKlecS5AXt91w/6UoHdGGsW6H5DA48QOc1aD0Kv s25lkZd14WcN+ASDedW1oJV8sr6BrtIVn8kZcMk+/aYdwJi+eSkOp5egQ5XNlAon4TuBHB1zLX5p rwYTbHit4MA1ZDRkQe2iRD9rUoD0ueq3ftMPwQEbJRdjbPFg3nsuJBtsRBuRHd2O8xMM+D1jFoRV Bw9rMm2qTxxz3sGgf+zC/3Q8VaUQva6vNQ8JlGPn7gePtMkpaodO1OBJQC4QEFg6j0OtT3VwUKYa cq7pmWTH+KTPi1RB6dasaQUV2FSfFq2qCqAq/iUhU3mAM3mfAhvg2FOhJPe8TIluyPSDbXwFDMgT dPRBUExPOHw+BM9cq212hRepaMJ8wV1dA7QItRiJ2JhqU+7h3vxr+5bjLREcIKU8CqlqAEwBbLJv Weaee+7ZKzFHRkCUmPLIXAUR5uhzPeENee81cFIdYDyEo/TOoXAWBMvBaIcz0K4gRFla+TRlQX31 vXPM6yTQADwExLCNRanpDGc4Q+9EOUbfiTr9VfnQDqeax/CMl+GL/hKlziNKwHj22Wef/tXW7m89 RhxJ1jfoU94tnikCPBXQUFQ8AZ6icgR4KCAjAP5ARX9TnTGe8F7gpp1a6gOO+IrHIn8OPnNqHA0e 53q8wBeVGbLWFj4bi76bz+Pk1wJk/eLU8FCgpG3joS/ty004u0XK/oxee6Y8zBHihacLBLbu6+10 3pyW6pX2ZdtDqkB4Rt76LavBh0zXaIuDVznA4xpIr0UAmtzoJoDLkxw+542cHLx70QvVHmOjx4JX PMM7jkwwbNpABUC/yBNQkwvZqehpF08EThwO2eGX8+h6HpP111vujMd1fm8fIWQL5D2rvLxeAsbG Ys2LqRbz19FFgR39ziu5lcp33333vv/O4QjoasZLV+HBkBfFpaJEn7WBr5Gt4Md3AgT9se5JRSAy liT4ndwFoviVqVNOnny0TW6OVCkEk3DSK96dg/+xWQEiOxdMsBGOP5U8eoL37uUa1+qbaTmkqmeN AT64X7AsWAKHTCFp12/sK8HNPJIk4RG7MeVkXJkK4Ni9YZc91fsNIVUAiyTZF1xRifHZvTLlBdPw GGaSb6YOXEsHUgFl3/EZiMzgKX7wWfiqosQGtNH6kLwxFEYEUwUg+lIXSa5F1hvgq+l0a7pcmyck BIenOc1p+nvqE17R+fq2zy0VHCDKSaGBVo3wADIHY/B5OxiD8Z0Iz19gJtJ1cMxZ+LQWieBcS4Du jak+O2LwIkv90S6DqtEq5fQ9x8ogtEPgNYJzLQMGLubrInzA4LPrXZMoj8K5JouPzCcOfXQQ0AsA 8BAPtK2d2mfggFfarmDsvu6lHO8a/2cBqHbx3nfGaP5TZaJezwn5zT3bfRUYY/jCENu5TPd2X9cC xFqOFJhYwGM87iGAS6VhNRLY5b3ogMz/xtJm26pDpoMWffkI4MSDvDoaP4G1+2axmnuTcT4PKenp Ix5H9sacqo5sLbqJT0MNnb1wamSDt5yjz9qpq5zptnbxuq4fEYRxCr7Hc+PSr8jedwJe52QFud9T ahfk0Wf3r2tF2G8WAhoznW0fy6QHgqoduQ+J8ZCH+7p/xoWsgdBP6zAERqqGPtO3BKPGoL+z8GAe wRfX4n97Hbv0mzbZA72pa6dgiXsKpttyP74bi2sq7sEaehQeV7nhte/Zo/vAIvYhI87r7t3HZ9dW m8Yv/aSD7EA7bTWP7PDNtYs4JXjrmtiNMefxQ3rgu3y/iF7Qo8jS2Om+z2SRaQnnaFcy1q6hohvu y57gMUypQaHfXSvBg2/VBuBFdKZin+9jG/jo/6GvPtYH7eGTo/oJmEE+ZOYcY1zk7ZabMjgYaaSd RQxb1iOzGmmkkUYaaeNpDA5G2tQkU1CaVZ403VOffBlppJFGGmljaAwORtr0pDyojKpEuugz2CON NNJIIy1OY3Aw0kgjjTTSSCOtoP8HTPHI+XZ4xuEAAAAASUVORK5CYII= --_004_4A95BA014132FF49AE685FAB4B9F17F645CF8CEDdfweml701chmchi_-- From nobody Fri Apr 18 04:28:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17FA1A00ED for ; Fri, 18 Apr 2014 04:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gohV-k-HROKI for ; Fri, 18 Apr 2014 04:28:14 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8F1A010D for ; Fri, 18 Apr 2014 04:28:14 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so2554936veb.25 for ; Fri, 18 Apr 2014 04:28:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SWj8ynnwBe2XRxYTdLDS3AmOFkhY49jgYS/qIJtXp7E=; b=eLCLOmCvr+WnWWUcUpIR/fNGkWJAa7sxq9Gp7fOZJGzcXfJJmoVVWSA5Jx8JFRjSIr NeTH8y+D3ZLMzLfaytd01z30O9+4vsFA+8CfYGgG2/SzpiZEXCLfbV7TIdvvtTgcni3n d1btGTYfVZ6XPt9uuO0LZCcPmfaXw54O6oq1puNWKFQkHfQ1ynRLMFmJY21BPYRuLXUb Zg3x7Oz0K84sMFlyqQdJU5iJJHejlehBSsfhKkXCEybtp6eYfGfXFWBF/oguuEcAuScr qOVqEA4UVrroEyj0yzT1RMaSbs8GR1Lnxr6r+8xoZfu0qoYdI72jYspfPY7UmRfL31aX EmFA== X-Gm-Message-State: ALoCoQmxGj9YPF/pMdUd8lpM0bS/tl/8+Mz5O0+iftDAIMdC3Hp/eVDE4lvOwvb1dwVUpm9tOF+Z X-Received: by 10.52.108.164 with SMTP id hl4mr10905797vdb.25.1397820490158; Fri, 18 Apr 2014 04:28:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 04:27:50 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 07:27:50 -0400 Message-ID: To: Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/J64OkaaERs8CSgWyckgw-696uV0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 11:28:19 -0000 Ok, since nobody is saying anything i'll bite. How would you like for this discussion to proceed? On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: > Dear I2RSers, > > At the last I2RS WG meeting there was a great deal of conversation > regarding selection of both modeling language and underlying transport > protocol. Consensus at the time was to make use of Yang and (NetConf or > RestConf) (unclear). > And i believe the view, as correctly presented by you, is for folks to go back and make educated decisions by actually getting knowledgeable about the different views presented. "Consensus" that you described above to me looked like a pageant popularity contest not based on anything technical ("who likes contestant in the blue shirt? please cheer for them"). In my opinion i dont think the requirements are clear. Will that get the crickets stop chirping? cheers, jamal > Before coming to a final consensus, we'd like to give people adequate time > to review source material, marshall arguments and discuss on the mailing > list. To this end, we're asking that interested parties do just this over > the course of the next ~two weeks. Following that period, on 4/28, we'll be > initiating a consensus call that will last an additional two weeks, with the > aim of converging modeling language / protocol by Friday, 5/9. > > The consensus call should also generate proposals for any material changes > required to the underlying protocols. These proposals in turn will form the > basis for a later draft including gap analysis and said changes. Those > strongly in favor of one protocol over another should be prepared to > contribute to this analysis. > > > best, > > -ed > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Apr 18 06:17:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE981A0158 for ; Fri, 18 Apr 2014 06:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRr0Uu4OO4hz for ; Fri, 18 Apr 2014 06:17:43 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF931A0118 for ; Fri, 18 Apr 2014 06:17:43 -0700 (PDT) Received: from mail43-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE017.bigfish.com (10.3.207.139) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Apr 2014 13:16:52 +0000 Received: from mail43-am1 (localhost [127.0.0.1]) by mail43-am1-R.bigfish.com (Postfix) with ESMTP id 53C7DE03BA; Fri, 18 Apr 2014 13:16:52 +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: -23 X-BigFish: VPS-23(zz98dI9371I1432Idb82hzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h1155h) Received-SPF: pass (mail43-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(24454002)(199002)(189002)(93916002)(46102001)(81342001)(86362001)(36756003)(15975445006)(99396002)(77156001)(81542001)(82746002)(62966002)(92726001)(83322001)(19580405001)(80976001)(19580395003)(77982001)(4396001)(74662001)(31966008)(561944002)(50226001)(74502001)(85852003)(87286001)(2656002)(88136002)(87936001)(83072002)(76176999)(50986999)(89996001)(33656001)(83716003)(57306001)(66066001)(99286001)(20776003)(80022001)(76482001)(92566001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:ACF4F1F9.9FE2D559.F1F1914B.5EE4FD49.2044A; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail43-am1 (localhost.localdomain [127.0.0.1]) by mail43-am1 (MessageSwitch) id 1397827009798721_16176; Fri, 18 Apr 2014 13:16:49 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.240]) by mail43-am1.bigfish.com (Postfix) with ESMTP id BABF024025C; Fri, 18 Apr 2014 13:16:49 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Apr 2014 13:16:49 +0000 Received: from BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 18 Apr 2014 13:17:34 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.921.12; Fri, 18 Apr 2014 13:17:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Fri, 18 Apr 2014 13:17:32 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepAA= Date: Fri, 18 Apr 2014 13:17:32 +0000 Message-ID: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 018577E36E Content-Type: text/plain; charset="us-ascii" Content-ID: <123060FE573A074587C7B658AA13B754@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% Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fHRGgivZCGk9Fr01d9g9iPeEHZc Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 13:17:48 -0000 Jamal, Here are two criteria to be considered: 1. technical 2. commercial/business We can discuss pros and cons for both, but have to state that from business= perspective for Juniper going with RESTCONF/YANG make more sense. We alrea= dy built the Junos model in YANG and=20 have or are in process of building needed tools. Same goes for RESTCONF. We= have NETCONF implemented in Junos and are working on RESTCONF implementati= on. Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCO= NF as well, so this looks like a low hanging fruit from business perspectiv= e. Looking at technical aspect, unless there is a very compelling reason (and = there might be, but I'm not aware of it), don't see reason to switch from R= ESTCONF and YANG. We can find out down the line that RESTCONF/YANG was the wrong way to go, b= ut that can be always changed. From my perspective it looks right today. Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. Dean On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > Ok, since nobody is saying anything i'll bite. > How would you like for this discussion to proceed? >=20 > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> Dear I2RSers, >>=20 >> At the last I2RS WG meeting there was a great deal of conversation >> regarding selection of both modeling language and underlying transport >> protocol. Consensus at the time was to make use of Yang and (NetConf or >> RestConf) (unclear). >>=20 >=20 > And i believe the view, as correctly presented by you, is for folks to go= back > and make educated decisions by actually getting knowledgeable about > the different views presented. "Consensus" that you described above > to me looked like a pageant popularity contest not based on anything > technical ("who likes contestant in the blue shirt? please cheer for them= "). >=20 > In my opinion i dont think the requirements are clear. >=20 > Will that get the crickets stop chirping? >=20 > cheers, > jamal >=20 >> Before coming to a final consensus, we'd like to give people adequate t= ime >> to review source material, marshall arguments and discuss on the mailing >> list. To this end, we're asking that interested parties do just this ov= er >> the course of the next ~two weeks. Following that period, on 4/28, we'll= be >> initiating a consensus call that will last an additional two weeks, with= the >> aim of converging modeling language / protocol by Friday, 5/9. >>=20 >> The consensus call should also generate proposals for any material chang= es >> required to the underlying protocols. These proposals in turn will form= the >> basis for a later draft including gap analysis and said changes. Those >> strongly in favor of one protocol over another should be prepared to >> contribute to this analysis. >>=20 >>=20 >> best, >>=20 >> -ed >>=20 >> _______________________________________________ >> 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 >=20 >=20 From nobody Fri Apr 18 07:20:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4A41A0336 for ; Fri, 18 Apr 2014 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLywxdxbDNSd for ; Fri, 18 Apr 2014 07:20:24 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6AABF1A0308 for ; Fri, 18 Apr 2014 07:20:24 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so2902831veb.26 for ; Fri, 18 Apr 2014 07:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ULOGHt0aPVhkLkW9gLWWGIoS/CyoZMCP5Gg6uLWwKKo=; b=LeqcfK3/0wvaxYLHU2O43LM+b3ukyVmVmfkbHfUeFPHwQ5Mh61bgwWVsh23cdtui38 E44ank/39SA6jrylgdOCx6nrahyCGvKbxYR3zMfSMJlxnPgjoqznt1uGjS8S6bCF6xvE q2ssFDAd3yRJ+kcO3KtuMPcdb9gbx7enVf7Yn4aYh4X+MaMgC0ky1xcUrSZY3QaJp0qh dJudwaZtA0ojNycNfaznTp1ccuHxMhsiHLfuO0xvkxmSKMaHDulPYghaMoNsOphYlnzy 0VtzAmgKkZ7pD3M8k5ntzs3Lr14O7IWq7oTBpVeZmnazWxSle9YjUlsfLiwaEBBg/2WY PRNw== X-Gm-Message-State: ALoCoQm9FqdgjwJHzMtq3n57jUOmtxfKKS3m06y+Bnx38Fv+O3/TqEw3wbIlt+xBNp3oP87Hz6RM X-Received: by 10.52.166.102 with SMTP id zf6mr12306671vdb.2.1397830820276; Fri, 18 Apr 2014 07:20:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 07:20:00 -0700 (PDT) In-Reply-To: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 10:20:00 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5sYR7Tr9ODdvdcLNIjga0AcZC2c Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 14:20:30 -0000 On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic wrote: > Jamal, > > Here are two criteria to be considered: > 1. technical > 2. commercial/business > > We can discuss pros and cons for both, but have to state that from business perspective for >Juniper going with RESTCONF/YANG make more sense. We already built the Junos model > in YANG and have or are in process of building needed tools. > Same goes for RESTCONF. We have NETCONF implemented in Junos and are working > on RESTCONF implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so >this looks like a low hanging fruit from business perspective. > Thanks for being sincere Dean. First, I will say I empathize with your view above (I understand such a view is motivation for many unfortunately often disguised as technical opinion). While i empathize, I would like to point that we need to have these discussions which are technical otherwise there is no point in having a standard. In any case I get where you are coming from. > Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm >not aware of it), don't see reason to switch from RESTCONF and YANG. Maybe we'll bring up the topics sequentially as the thread proceeds - I'll start with 1 or 2 of what i think are requirements against protocol/model so we dont have to respond to long emails. If you have issues with ForCES please bring them up as well and we can discuss (I brought up a few in my presentation). One of the issues was throughput and latency. You stated in London that you want to be able to do a large amount of updates/sec. Other than you - I cant get anyone else to say this is a requirement. I do believe it is. It will be useful for example to come up with some hand waving numbers against some agreed-to info model (eg the rib) and see how this requirement is met by the different protocols. As for the model, I'd like to quote from the minutes what Tom Petch (who i consider to be a sage in this space): "If I was writing an info model I'd use YANG every time. But if I was writing a data model I'd go for ForCES." And this is rooted in the nature of Yang being intended for Config. There is also the issue of i2rs ability to describe instances which is lacking in Yang; but maybe leave that out to a different email.. cheers, jamal > We can find out down the line that RESTCONF/YANG was the wrong way to go, but that >can be always changed. From my perspective it looks right today. > > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > From nobody Fri Apr 18 08:26:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A61A03EF for ; Fri, 18 Apr 2014 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m13huiSBsBW for ; Fri, 18 Apr 2014 08:26:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 472171A03E8 for ; Fri, 18 Apr 2014 08:26:43 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 38C83276E74D; Fri, 18 Apr 2014 11:26:39 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FF957FC2-1FA5-4A41-938C-2AC61028EFED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 11:26:38 -0400 Message-Id: <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5DcGjbZDQbCZSMsGn4bWPq2NDfc Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 15:26:48 -0000 --Apple-Mail=_FF957FC2-1FA5-4A41-938C-2AC61028EFED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for the top post, but I wanted to inject that for the = record, Brocade is in favor of using RestConf/Yang (or variations of = those) for I2RS. We have no interest in using FORCES as the basis for = this. --Tom On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim = wrote: > On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic = wrote: >> Jamal, >>=20 >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >>=20 >> We can discuss pros and cons for both, but have to state that from = business perspective for >> Juniper going with RESTCONF/YANG make more sense. We already built = the Junos model >> in YANG and have or are in process of building needed tools. >> Same goes for RESTCONF. We have NETCONF implemented in Junos and are = working >> on RESTCONF implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into = RESTCONF as well, so >this looks like a low hanging fruit from business = perspective. >>=20 >=20 > Thanks for being sincere Dean. > First, I will say I empathize with your view above (I understand such > a view is motivation > for many unfortunately often disguised as technical opinion). While i > empathize, I would like > to point that we need to have these discussions which are technical > otherwise there is > no point in having a standard. > In any case I get where you are coming from. >=20 >> Looking at technical aspect, unless there is a very compelling reason = (and there might be, but I'm >> not aware of it), don't see reason to switch from RESTCONF and YANG. >=20 > Maybe we'll bring up the topics sequentially as the thread proceeds - > I'll start with > 1 or 2 of what i think are requirements against protocol/model so we > dont have to > respond to long emails. If you have issues with ForCES please bring > them up as well > and we can discuss (I brought up a few in my presentation). >=20 > One of the issues was throughput and latency. > You stated in London that you want to be able to do a large amount of > updates/sec. > Other than you - I cant get anyone else to say this is a requirement. > I do believe it is. > It will be useful for example to come up with some hand waving numbers = against > some agreed-to info model (eg the rib) and see how this requirement is > met by the > different protocols. >=20 > As for the model, I'd like to quote from the minutes what Tom Petch > (who i consider to > be a sage in this space): > "If I was writing an info model I'd use YANG every time. But if I was > writing a data > model I'd go for ForCES." > And this is rooted in the nature of Yang being intended for Config. >=20 > There is also the issue of i2rs ability to describe instances which is > lacking in Yang; > but maybe leave that out to a different email.. >=20 > cheers, > jamal >=20 >> We can find out down the line that RESTCONF/YANG was the wrong way to = go, but that >> can be always changed. =46rom my perspective it looks right today. >>=20 >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_FF957FC2-1FA5-4A41-938C-2AC61028EFED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUUQuAAoJEPcO+I7eiUJZVaYQAKzV4NAuKQZGSN/OBnqdNLd0 XOoAklBVvVkvbFAQxqYInQ7ntoXiv85LxdFQ56tTVSAl3hF9kzgJvGBnwguMcDZK gs94ifJ8MAiuBrcvNQkfsSB0Qm/l8E71tmonLvwnoH+qUngpi1fBkQgCC97SmPZa v4zlSiJg3GCgAhj6cB1j7fJX93sJymWsr1axq3ecLZknJMaUfe4XILUbnf7VuGFG idLgYyoHPD0cwigDdydjNMI6xOJDn+ENri1vRaQFniuYG52g5Yv5jC9oARI3wXQk ybXuxyfBaGt7QQoiJ96kaZoexUNVfYw40rS9qV0+MHWKn2f+3kk4D7NmQjwacxo+ Bf2EixF+QST5fBx1GAh+E+eMS36Jv+e64W3SUEExJecFZZKzCUWkqIbbJN/GE1m9 nESWDCeW3cu5mU9weugtCacw80dZFe7C5YsuCARzhcQEDY7gJ/6yLHsrF3aemQGt bGtMseyS9P0c/ja+18bJVaWkD+32zudiR3lALdMXwqTRwTGVDjMLIpMBTK4DpqPN fRZCOxmoJOF1jbTgqpc1WwgoPfg2LFuinhib+YGkjcZbEqLT+nXLGGOHfXrUHAZM Q3tLDAejoQhIDzV65fhnpPDOcYEsD/BbIArnPSVS2r2sBw/1WcY1El7y8uYan/GV 1CXo9lfdYU3VHlkyGqmt =1GUJ -----END PGP SIGNATURE----- --Apple-Mail=_FF957FC2-1FA5-4A41-938C-2AC61028EFED-- From nobody Fri Apr 18 08:32:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEBB1A0407 for ; Fri, 18 Apr 2014 08:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1U6507C2-pq for ; Fri, 18 Apr 2014 08:31:49 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAA1A03FA for ; Fri, 18 Apr 2014 08:31:35 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so1445630lbi.36 for ; Fri, 18 Apr 2014 08:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KxPMS7DIg2x+Y0JdoLg5LNUOquSwaj7XwpzjHMol3GE=; b=a0AGNo7Ea0tGzfJYWGEsz6VPQASXCMdGpW3Xyco6z9pFnMHT0NmTiYOX4iYRuvPxX4 tKwqhOtGQBu1C/1A4U9UJQMKajJDANP2X59iUzoAC6e2kXTRAQ96C6DBXaV3I8xdR5E8 D2IxTMwaCwC8AKrkaqxJ2CluEaMMhr9PR/CySgibsTHvQ/+ISXIy4oBuk3KHyqosHZQl DzwPszyqqd8lICKIf3I8J0+GAV1cYno8cp0bEABla9OrsAdqp1X5+Y5pWB4/TftQahbU ZXW58Jr8jNIJQQDHGESQXlbFjy4PVBLiyvQoxrz65vbur5+PjH9yNoAbo0H1gRvWPYNb GyHA== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr14566945lac.0.1397835091246; Fri, 18 Apr 2014 08:31:31 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 18 Apr 2014 08:31:31 -0700 (PDT) In-Reply-To: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> Date: Fri, 18 Apr 2014 10:31:31 -0500 Message-ID: From: Behcet Sarikaya To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a113484bc11840904f752d8d1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IsgluWAnuPRGsE-UwiWErEpo4RU Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:31:54 -0000 --001a113484bc11840904f752d8d1 Content-Type: text/plain; charset=UTF-8 Hi Dean, I attended i2rs session in London on this issue. My question is why ONF Management and Configuration protocol (OF-Config 1.2) was not on the table. Regards, Behcet On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic wrote: > Jamal, > > Here are two criteria to be considered: > 1. technical > 2. commercial/business > > We can discuss pros and cons for both, but have to state that from > business perspective for Juniper going with RESTCONF/YANG make more sense. > We already built the Junos model in YANG and > have or are in process of building needed tools. Same goes for RESTCONF. > We have NETCONF implemented in Junos and are working on RESTCONF > implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so this looks like a low hanging fruit from business > perspective. > > Looking at technical aspect, unless there is a very compelling reason (and > there might be, but I'm not aware of it), don't see reason to switch from > RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to go, > but that can be always changed. From my perspective it looks right today. > > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > > Dean > > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > > > Ok, since nobody is saying anything i'll bite. > > How would you like for this discussion to proceed? > > > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: > >> Dear I2RSers, > >> > >> At the last I2RS WG meeting there was a great deal of conversation > >> regarding selection of both modeling language and underlying transport > >> protocol. Consensus at the time was to make use of Yang and (NetConf or > >> RestConf) (unclear). > >> > > > > And i believe the view, as correctly presented by you, is for folks to > go back > > and make educated decisions by actually getting knowledgeable about > > the different views presented. "Consensus" that you described above > > to me looked like a pageant popularity contest not based on anything > > technical ("who likes contestant in the blue shirt? please cheer for > them"). > > > > In my opinion i dont think the requirements are clear. > > > > Will that get the crickets stop chirping? > > > > cheers, > > jamal > > > >> Before coming to a final consensus, we'd like to give people adequate > time > >> to review source material, marshall arguments and discuss on the mailing > >> list. To this end, we're asking that interested parties do just this > over > >> the course of the next ~two weeks. Following that period, on 4/28, > we'll be > >> initiating a consensus call that will last an additional two weeks, > with the > >> aim of converging modeling language / protocol by Friday, 5/9. > >> > >> The consensus call should also generate proposals for any material > changes > >> required to the underlying protocols. These proposals in turn will > form the > >> basis for a later draft including gap analysis and said changes. Those > >> strongly in favor of one protocol over another should be prepared to > >> contribute to this analysis. > >> > >> > >> best, > >> > >> -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 > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113484bc11840904f752d8d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dean,

I attended i2rs = session in London on this issue.

My question is why ONF Manage= ment and Configuration protocol (OF-Config 1.2) was not on the table.
Regards,

Behcet


On Fri, Apr 18, 2014 at= 8:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
Jamal,

Here are two criteria to be considered:
1. technical
2. commercial/business

We can discuss pros and cons for both, but have to state that from business= perspective for Juniper going with RESTCONF/YANG make more sense. We alrea= dy built the Junos model in YANG and
have or are in process of building needed tools. Same goes for RESTCONF. We= have NETCONF implemented in Junos and are working on RESTCONF implementati= on.
Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCO= NF as well, so this looks like a low hanging fruit from business perspectiv= e.

Looking at technical aspect, unless there is a very compelling reason (and = there might be, but I'm not aware of it), don't see reason to switc= h from RESTCONF and YANG.
We can find out down the line that RESTCONF/YANG was the wrong way to go, b= ut that can be always changed. From my perspective it looks right today.
Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean

On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> Ok, since nobody is saying anything i'll bite.
> How would you like for this discussion to proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <edc@google.com> wrote:
>> Dear I2RSers,
>>
>> =C2=A0At the last I2RS WG meeting there was a great deal of conver= sation
>> regarding selection of both modeling language and underlying trans= port
>> protocol. =C2=A0Consensus at the time was to make use of Yang and = (NetConf or
>> RestConf) (unclear).
>>
>
> And i believe the view, as correctly presented by you, is for folks to= go back
> and make educated decisions by actually getting knowledgeable about > the different views presented. "Consensus" that you describe= d above
> to me looked like =C2=A0a pageant popularity contest not based on anyt= hing
> technical ("who likes contestant in the blue shirt? please cheer = for them").
>
> In my opinion i dont think the requirements are clear.
>
> Will that get the crickets stop chirping?
>
> cheers,
> jamal
>
>> =C2=A0Before coming to a final consensus, we'd like to give pe= ople adequate time
>> to review source material, marshall arguments and discuss on the m= ailing
>> list. =C2=A0To this end, we're asking that interested parties = do just this over
>> the course of the next ~two weeks. Following that period, on 4/28,= we'll be
>> initiating a consensus call that will last an additional two weeks= , with the
>> aim of converging modeling language / protocol by Friday, 5/9.
>>
>> The consensus call should also generate proposals for any material= changes
>> required to the underlying protocols. =C2=A0These proposals in tur= n will form the
>> basis for a later draft including gap analysis and said changes. = =C2=A0Those
>> strongly in favor of one protocol over another should be prepared = to
>> contribute to this analysis.
>>
>>
>> best,
>>
>> =C2=A0-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
>
>


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

--001a113484bc11840904f752d8d1-- From nobody Fri Apr 18 08:42:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A404E1A041E for ; Fri, 18 Apr 2014 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI3zLivBb-iP for ; Fri, 18 Apr 2014 08:42:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA421A0421 for ; Fri, 18 Apr 2014 08:42:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "'Dean Bogdanovic'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Date: Fri, 18 Apr 2014 11:42:08 -0400 Message-ID: <007c01cf5b1c$c2399800$46acc800$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01CF5AFB.3B2BEFA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuZe80hag Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qlEubtrX3izPbIwM7fajkQtTqrw Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 15:42:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007D_01CF5AFB.3B2BEFA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Behcet:=20 =20 Can you tell me how the ONF Management and configuration protocol will = interface with the routing system with all the requirements set forth by = the architecture document? Please refer to version 2.0 architecture =20 Or review to the presentation at IETF. If you can present these = features in email or any substantial way, we will listen. In my = observations, the ONF management protocol was designed for the ONF flows = and not the information models required or the use case required. =20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, April 18, 2014 11:32 AM To: Dean Bogdanovic Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model =20 Hi Dean, I attended i2rs session in London on this issue. My question is why ONF Management and Configuration protocol (OF-Config = 1.2) was not on the table. Regards, Behcet=20 =20 On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic = wrote: Jamal, Here are two criteria to be considered: 1. technical 2. commercial/business We can discuss pros and cons for both, but have to state that from = business perspective for Juniper going with RESTCONF/YANG make more = sense. We already built the Junos model in YANG and have or are in process of building needed tools. Same goes for RESTCONF. = We have NETCONF implemented in Junos and are working on RESTCONF = implementation. Many carriers adopted or are adopting NETCONF/YANG, are looking into = RESTCONF as well, so this looks like a low hanging fruit from business = perspective. Looking at technical aspect, unless there is a very compelling reason = (and there might be, but I'm not aware of it), don't see reason to = switch from RESTCONF and YANG. We can find out down the line that RESTCONF/YANG was the wrong way to = go, but that can be always changed. From my perspective it looks right = today. Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. Dean On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > Ok, since nobody is saying anything i'll bite. > How would you like for this discussion to proceed? > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> Dear I2RSers, >> >> At the last I2RS WG meeting there was a great deal of conversation >> regarding selection of both modeling language and underlying = transport >> protocol. Consensus at the time was to make use of Yang and (NetConf = or >> RestConf) (unclear). >> > > And i believe the view, as correctly presented by you, is for folks to = go back > and make educated decisions by actually getting knowledgeable about > the different views presented. "Consensus" that you described above > to me looked like a pageant popularity contest not based on anything > technical ("who likes contestant in the blue shirt? please cheer for = them"). > > In my opinion i dont think the requirements are clear. > > Will that get the crickets stop chirping? > > cheers, > jamal > >> Before coming to a final consensus, we'd like to give people = adequate time >> to review source material, marshall arguments and discuss on the = mailing >> list. To this end, we're asking that interested parties do just this = over >> the course of the next ~two weeks. Following that period, on 4/28, = we'll be >> initiating a consensus call that will last an additional two weeks, = with the >> aim of converging modeling language / protocol by Friday, 5/9. >> >> The consensus call should also generate proposals for any material = changes >> required to the underlying protocols. These proposals in turn will = form the >> basis for a later draft including gap analysis and said changes. = Those >> strongly in favor of one protocol over another should be prepared to >> contribute to this analysis. >> >> >> best, >> >> -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 > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_007D_01CF5AFB.3B2BEFA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Behcet:

 

Can you tell me how the ONF Management and configuration protocol = will interface with the routing system with all the requirements set = forth by the architecture document? =C2=A0=C2=A0Please refer to version = 2.0 architecture

 

Or review to the presentation at IETF.=C2=A0=C2=A0 If you can present = these features in email or any substantial way, we will listen.=C2=A0 In = my observations, the ONF management protocol was designed for the ONF = flows and not the information models required or the use case = required.=C2=A0=C2=A0

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: = Dean Bogdanovic
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi = Salim
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 

Hi = Dean,

I attended i2rs session = in London on this issue.


My question is why ONF Management and = Configuration protocol (OF-Config 1.2) was not on the = table.

Regards,

Behcet

 

On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic = <deanb@juniper.net> wrote:

Jamal,

Here are two criteria to be = considered:
1. technical
2. commercial/business

We can = discuss pros and cons for both, but have to state that from business = perspective for Juniper going with RESTCONF/YANG make more sense. We = already built the Junos model in YANG and
have or are in process of = building needed tools. Same goes for RESTCONF. We have NETCONF = implemented in Junos and are working on RESTCONF implementation.
Many = carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF = as well, so this looks like a low hanging fruit from business = perspective.

Looking at technical aspect, unless there is a very = compelling reason (and there might be, but I'm not aware of it), don't = see reason to switch from RESTCONF and YANG.
We can find out down the = line that RESTCONF/YANG was the wrong way to go, but that can be always = changed. From my perspective it looks right today.

Just to be = clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean


On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim = <hadi@mojatatu.com> = wrote:

> Ok, since nobody is saying anything i'll = bite.
> How would you like for this discussion to = proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe = <edc@google.com> = wrote:
>> Dear I2RSers,
>>
>>  At the = last I2RS WG meeting there was a great deal of conversation
>> = regarding selection of both modeling language and underlying = transport
>> protocol.  Consensus at the time was to make = use of Yang and (NetConf or
>> RestConf) = (unclear).
>>
>
> And i believe the view, as = correctly presented by you, is for folks to go back
> and make = educated decisions by actually getting knowledgeable about
> the = different views presented. "Consensus" that you described = above
> to me looked like  a pageant popularity contest not = based on anything
> technical ("who likes contestant in the = blue shirt? please cheer for them").
>
> In my opinion = i dont think the requirements are clear.
>
> Will that get = the crickets stop chirping?
>
> cheers,
> = jamal
>
>>  Before coming to a final consensus, we'd = like to give people adequate time
>> to review source material, = marshall arguments and discuss on the mailing
>> list.  To = this end, we're asking that interested parties do just this = over
>> the course of the next ~two weeks. Following that = period, on 4/28, we'll be
>> initiating a consensus call that = will last an additional two weeks, with the
>> aim of = converging modeling language / protocol by Friday, = 5/9.
>>
>> The consensus call should also generate = proposals for any material changes
>> required to the = underlying protocols.  These proposals in turn will form = the
>> basis for a later draft including gap analysis and said = changes.  Those
>> strongly in favor of one protocol over = another should be prepared to
>> contribute to this = analysis.
>>
>>
>> = best,
>>
>>  -ed
>>
>> = _______________________________________________
>> i2rs mailing = list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> = https://www.ietf.org/mailman/listinfo/i2rs
><= br>>


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

 

------=_NextPart_000_007D_01CF5AFB.3B2BEFA0-- From nobody Fri Apr 18 08:47:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC05F1A03CC for ; Fri, 18 Apr 2014 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuPLODiIOm9U for ; Fri, 18 Apr 2014 08:47:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 705161A038D for ; Fri, 18 Apr 2014 08:47:18 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4F3E3276E864; Fri, 18 Apr 2014 11:47:14 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3FA32B08-95B3-4791-B5EC-86F1D18F8452"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 11:47:12 -0400 Message-Id: <11BE70B4-52F1-4165-B474-66C6021123C1@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GB2H2W8iOGFxkOmZ2z4mhpE2LFM Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 15:47:24 -0000 --Apple-Mail=_3FA32B08-95B3-4791-B5EC-86F1D18F8452 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C20E4BB-0000-4500-8D73-136B5566A9E8" --Apple-Mail=_7C20E4BB-0000-4500-8D73-136B5566A9E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe its because OF-Config does not meet the requirements = we set forth.=20 --Tom On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya = wrote: > Hi Dean, >=20 > I attended i2rs session in London on this issue. >=20 > My question is why ONF Management and Configuration protocol = (OF-Config 1.2) was not on the table. >=20 > Regards, >=20 > Behcet=20 >=20 >=20 > On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic = wrote: > Jamal, >=20 > Here are two criteria to be considered: > 1. technical > 2. commercial/business >=20 > We can discuss pros and cons for both, but have to state that from = business perspective for Juniper going with RESTCONF/YANG make more = sense. We already built the Junos model in YANG and > have or are in process of building needed tools. Same goes for = RESTCONF. We have NETCONF implemented in Junos and are working on = RESTCONF implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into = RESTCONF as well, so this looks like a low hanging fruit from business = perspective. >=20 > Looking at technical aspect, unless there is a very compelling reason = (and there might be, but I'm not aware of it), don't see reason to = switch from RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to = go, but that can be always changed. =46rom my perspective it looks right = today. >=20 > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >=20 > Dean >=20 > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim = wrote: >=20 > > Ok, since nobody is saying anything i'll bite. > > How would you like for this discussion to proceed? > > > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe = wrote: > >> Dear I2RSers, > >> > >> At the last I2RS WG meeting there was a great deal of conversation > >> regarding selection of both modeling language and underlying = transport > >> protocol. Consensus at the time was to make use of Yang and = (NetConf or > >> RestConf) (unclear). > >> > > > > And i believe the view, as correctly presented by you, is for folks = to go back > > and make educated decisions by actually getting knowledgeable about > > the different views presented. "Consensus" that you described above > > to me looked like a pageant popularity contest not based on = anything > > technical ("who likes contestant in the blue shirt? please cheer for = them"). > > > > In my opinion i dont think the requirements are clear. > > > > Will that get the crickets stop chirping? > > > > cheers, > > jamal > > > >> Before coming to a final consensus, we'd like to give people = adequate time > >> to review source material, marshall arguments and discuss on the = mailing > >> list. To this end, we're asking that interested parties do just = this over > >> the course of the next ~two weeks. Following that period, on 4/28, = we'll be > >> initiating a consensus call that will last an additional two weeks, = with the > >> aim of converging modeling language / protocol by Friday, 5/9. > >> > >> The consensus call should also generate proposals for any material = changes > >> required to the underlying protocols. These proposals in turn will = form the > >> basis for a later draft including gap analysis and said changes. = Those > >> strongly in favor of one protocol over another should be prepared = to > >> contribute to this analysis. > >> > >> > >> best, > >> > >> -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 > > > > >=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=_7C20E4BB-0000-4500-8D73-136B5566A9E8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I believe its because OF-Config does not meet the requirements we set forth. 

--Tom

On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

Hi Dean,

I attended i2rs session in London on this issue.

My question is why ONF Management and Configuration protocol (OF-Config 1.2) was not on the table.

Regards,

Behcet


On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
Jamal,

Here are two criteria to be considered:
1. technical
2. commercial/business

We can discuss pros and cons for both, but have to state that from business perspective for Juniper going with RESTCONF/YANG make more sense. We already built the Junos model in YANG and
have or are in process of building needed tools. Same goes for RESTCONF. We have NETCONF implemented in Junos and are working on RESTCONF implementation.
Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so this looks like a low hanging fruit from business perspective.

Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm not aware of it), don't see reason to switch from RESTCONF and YANG.
We can find out down the line that RESTCONF/YANG was the wrong way to go, but that can be always changed. From my perspective it looks right today.

Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean

On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> Ok, since nobody is saying anything i'll bite.
> How would you like for this discussion to proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <edc@google.com> wrote:
>> Dear I2RSers,
>>
>>  At the last I2RS WG meeting there was a great deal of conversation
>> regarding selection of both modeling language and underlying transport
>> protocol.  Consensus at the time was to make use of Yang and (NetConf or
>> RestConf) (unclear).
>>
>
> And i believe the view, as correctly presented by you, is for folks to go back
> and make educated decisions by actually getting knowledgeable about
> the different views presented. "Consensus" that you described above
> to me looked like  a pageant popularity contest not based on anything
> technical ("who likes contestant in the blue shirt? please cheer for them").
>
> In my opinion i dont think the requirements are clear.
>
> Will that get the crickets stop chirping?
>
> cheers,
> jamal
>
>>  Before coming to a final consensus, we'd like to give people adequate time
>> to review source material, marshall arguments and discuss on the mailing
>> list.  To this end, we're asking that interested parties do just this over
>> the course of the next ~two weeks. Following that period, on 4/28, we'll be
>> initiating a consensus call that will last an additional two weeks, with the
>> aim of converging modeling language / protocol by Friday, 5/9.
>>
>> The consensus call should also generate proposals for any material changes
>> required to the underlying protocols.  These proposals in turn will form the
>> basis for a later draft including gap analysis and said changes.  Those
>> strongly in favor of one protocol over another should be prepared to
>> contribute to this analysis.
>>
>>
>> best,
>>
>>  -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
>
>


_______________________________________________
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=_7C20E4BB-0000-4500-8D73-136B5566A9E8-- --Apple-Mail=_3FA32B08-95B3-4791-B5EC-86F1D18F8452 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUUkBAAoJEPcO+I7eiUJZBbEP/0zUAeskxVCA2pVG/jDcJ2I8 ppsEHP9f8N23AsY7VEywmWoNBRVp14uleuc3A0NgNlmBuo9tIWTnCQ8TkPZA3CR8 bR01bDIOulrlngaLtmFipoc4t2oLUXSSiUFj+Swjm5awkdyNjFJIKtS3kWo1bKOb j4y8sMBZ7tsMTxWKoaqzwLdovnJ4NOT6C1giCDZVC2v1g+nCS+SPDwSI182ag/Pb B3a7T1JWfQjKHkNmebCn1xXI4Wh5oOf9sttQSZFNCyj+rukVgHbP5GSdgpnI4LeB FKLnzqGPHNRiplrG+rh1z6zWJm3c6xFvftVnZYFsI9lnxY5ouV7xTq4g6OdQNdLZ 5nxDlErIetLWTDNQifKoaM+WM33jYe1NM2jQxDErR1AyyXMmoWDzFPfvp7AO8gY1 MLGJ5IL39+JKVoArAW+c14jN2LN3sCseV26/CFo60X2/nC0C/ieDka7vlOnUWmCl mtoJlGFj6YQfOzB6WWYDINXNWtmF5ZMFVcNV08V7ra4c7JvlQaknj9RxLzetzIiO qvLBwDvcJuwHlFGV0lmLvc8ExtGPeylOEmVZ97yP/gZaqyy1mRbEZAFU72Alg99q c+7J/V1rO8FZmXazg7aX3DQstC7f2IUz+5tnoSyl+WPtbsCBwW58+RRfznAItN2/ KvrQna7yu5AIJhQTooD4 =9ZVG -----END PGP SIGNATURE----- --Apple-Mail=_3FA32B08-95B3-4791-B5EC-86F1D18F8452-- From nobody Fri Apr 18 08:57:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787AC1A0448 for ; Fri, 18 Apr 2014 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7-eV4TysUDO for ; Fri, 18 Apr 2014 08:57:20 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A4D5A1A0441 for ; Fri, 18 Apr 2014 08:57:19 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id p9so1496327lbv.32 for ; Fri, 18 Apr 2014 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=feeTduS60ajrvNIIxUUrKP6B0vC1ShqhIWkv6LWBTrs=; b=jVRbDUNDkmow9V6irwwNE4U9B4SJPXxfZUNN7ky8eV76PqVgBPnvNdgjO+S5JLIZMC VXRfN/D7kxtTJK5+KIP5QSJWOojhxD7TEyWhkZXTFN8OXBxdJ4+K1WmqzhFcA9Qr/sLM Ovg0SsXsenVQSiuAIPd8r84xmjoEc4uM+/4iIPWrTrhDmxevYe5MoMSahGcYKgN4tG7S e45BZOQD86+OZd5j5DYe9MZIGvhHne4PElEBwA7aDgv67A4Mf/xM88fGIzGMcoOnDjjC D6VbEYmee6N+mzi66wm+MBZEJ7q9Eix2m+WrkUQzmD1ZWcIxGo9dTWNP2FdbXhlaORg2 pdLw== MIME-Version: 1.0 X-Received: by 10.112.32.67 with SMTP id g3mr1719507lbi.46.1397836635067; Fri, 18 Apr 2014 08:57:15 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Fri, 18 Apr 2014 08:57:15 -0700 (PDT) In-Reply-To: <007c01cf5b1c$c2399800$46acc800$@ndzh.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> Date: Fri, 18 Apr 2014 10:57:15 -0500 Message-ID: From: Behcet Sarikaya To: Susan Hares Content-Type: multipart/alternative; boundary=001a11360a1c165b3704f75334e3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2vkPt_zDlHTUweT0Mvh2_UMWBNg Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:57:24 -0000 --001a11360a1c165b3704f75334e3 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares wrote: > Behcet: > > > > Can you tell me how the ONF Management and configuration protocol will > interface with the routing system with all the requirements set forth by > the architecture document? Please refer to version 2.0 architecture > > > Don't get me wrong. I am not speaking in favor of OF-Config. But the point is that a more realistic choice should be between these two choices. If the study showed that OF-Config did not meet the requirements, that is fine but I heard no one said that. I wonder if the forces protocol meets these requirements? Behcet > Or review to the presentation at IETF. If you can present these features > in email or any substantial way, we will listen. In my observations, the > ONF management protocol was designed for the ONF flows and not the > information models required or the use case required. > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Behcet Sarikaya > *Sent:* Friday, April 18, 2014 11:32 AM > *To:* Dean Bogdanovic > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > Hi Dean, > > I attended i2rs session in London on this issue. > > > My question is why ONF Management and Configuration protocol (OF-Config > 1.2) was not on the table. > > Regards, > > Behcet > > > > On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic > wrote: > > Jamal, > > Here are two criteria to be considered: > 1. technical > 2. commercial/business > > We can discuss pros and cons for both, but have to state that from > business perspective for Juniper going with RESTCONF/YANG make more sense. > We already built the Junos model in YANG and > have or are in process of building needed tools. Same goes for RESTCONF. > We have NETCONF implemented in Junos and are working on RESTCONF > implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so this looks like a low hanging fruit from business > perspective. > > Looking at technical aspect, unless there is a very compelling reason (and > there might be, but I'm not aware of it), don't see reason to switch from > RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to go, > but that can be always changed. From my perspective it looks right today. > > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > > Dean > > > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > > > Ok, since nobody is saying anything i'll bite. > > How would you like for this discussion to proceed? > > > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: > >> Dear I2RSers, > >> > >> At the last I2RS WG meeting there was a great deal of conversation > >> regarding selection of both modeling language and underlying transport > >> protocol. Consensus at the time was to make use of Yang and (NetConf or > >> RestConf) (unclear). > >> > > > > And i believe the view, as correctly presented by you, is for folks to > go back > > and make educated decisions by actually getting knowledgeable about > > the different views presented. "Consensus" that you described above > > to me looked like a pageant popularity contest not based on anything > > technical ("who likes contestant in the blue shirt? please cheer for > them"). > > > > In my opinion i dont think the requirements are clear. > > > > Will that get the crickets stop chirping? > > > > cheers, > > jamal > > > >> Before coming to a final consensus, we'd like to give people adequate > time > >> to review source material, marshall arguments and discuss on the mailing > >> list. To this end, we're asking that interested parties do just this > over > >> the course of the next ~two weeks. Following that period, on 4/28, > we'll be > >> initiating a consensus call that will last an additional two weeks, > with the > >> aim of converging modeling language / protocol by Friday, 5/9. > >> > >> The consensus call should also generate proposals for any material > changes > >> required to the underlying protocols. These proposals in turn will > form the > >> basis for a later draft including gap analysis and said changes. Those > >> strongly in favor of one protocol over another should be prepared to > >> contribute to this analysis. > >> > >> > >> best, > >> > >> -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 > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a11360a1c165b3704f75334e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <= ;shares@ndzh.com&g= t; wrote:

Behcet:

=C2=A0

Can you tell me how= the ONF Management and configuration protocol will interface with the rout= ing system with all the requirements set forth by the architecture document= ? =C2=A0=C2=A0Please refer to version 2.0 architecture=

=C2=A0

<= /div>

Don't get me wrong.

=
I am not speaking in favor of OF-Config.

But the poi= nt is that a more realistic choice should be between these two choices.
=
If the study showed that OF-Config did not meet the requirem= ents, that is fine but I heard no one said that.
I wonder if the forces protocol meets these requirements?


Behcet

Or review to the presentation at IETF.=C2=A0=C2=A0 = If you can present these features in email or any substantial way, we will = listen.=C2=A0 In my observations, the ONF management protocol was designed = for the ONF flows and not the information models required or the use case r= equired.=C2=A0=C2=A0

=C2=A0

Sue Hares

=C2=A0

From: i2= rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: Dean Bogdanovic<= br>Cc: i2rs@ietf.= org; Edward Crabbe; Jamal Hadi Salim
Subject: Re: [i2rs] cons= ensus on I2RS protocol and model

=C2=A0

=

H= i Dean,

I attended i2rs sessi= on in London on this issue.


My question= is why ONF Management and Configuration protocol (OF-Config 1.2) was not o= n the table.

Regards,

Behcet

=C2=A0

On Fri, A= pr 18, 2014 at 8:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:

Jamal,

Here are two criteria to be considered= :
1. technical
2. commercial/business

We can discuss pros and = cons for both, but have to state that from business perspective for Juniper= going with RESTCONF/YANG make more sense. We already built the Junos model= in YANG and
have or are in process of building needed tools. Same goes for RESTCONF. We= have NETCONF implemented in Junos and are working on RESTCONF implementati= on.
Many carriers adopted or are adopting NETCONF/YANG, are looking into= RESTCONF as well, so this looks like a low hanging fruit from business per= spective.

Looking at technical aspect, unless there is a very compelling reason (= and there might be, but I'm not aware of it), don't see reason to s= witch from RESTCONF and YANG.
We can find out down the line that RESTCON= F/YANG was the wrong way to go, but that can be always changed. From my per= spective it looks right today.

Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean

=


On Apr 18, 2014, at 7:27 AM, Jamal Hadi Sal= im <hadi@mojatatu= .com> wrote:

> Ok, since nobody is saying anything i'll bite.
> How wou= ld you like for this discussion to proceed?
>
> On Fri, Apr 11,= 2014 at 1:50 PM, Edward Crabbe <edc@google.com> wrote:
>> Dear I2RSers,
>>
>> =C2=A0At the last I2RS WG me= eting there was a great deal of conversation
>> regarding selectio= n of both modeling language and underlying transport
>> protocol. = =C2=A0Consensus at the time was to make use of Yang and (NetConf or
>> RestConf) (unclear).
>>
>
> And i believe the= view, as correctly presented by you, is for folks to go back
> and m= ake educated decisions by actually getting knowledgeable about
> the = different views presented. "Consensus" that you described above > to me looked like =C2=A0a pageant popularity contest not based on anyt= hing
> technical ("who likes contestant in the blue shirt? pleas= e cheer for them").
>
> In my opinion i dont think the req= uirements are clear.
>
> Will that get the crickets stop chirping?
>
> chee= rs,
> jamal
>
>> =C2=A0Before coming to a final consen= sus, we'd like to give people adequate time
>> to review sourc= e material, marshall arguments and discuss on the mailing
>> list. =C2=A0To this end, we're asking that interested parties = do just this over
>> the course of the next ~two weeks. Following = that period, on 4/28, we'll be
>> initiating a consensus call = that will last an additional two weeks, with the
>> aim of converging modeling language / protocol by Friday, 5/9.
= >>
>> The consensus call should also generate proposals for = any material changes
>> required to the underlying protocols. =C2= =A0These proposals in turn will form the
>> basis for a later draft including gap analysis and said changes. = =C2=A0Those
>> strongly in favor of one protocol over another shou= ld be prepared to
>> contribute to this analysis.
>>
&= gt;>
>> best,
>>
>> =C2=A0-ed
>>
>> __= _____________________________________________
>> i2rs mailing list=
>> i2rs@ietf.o= rg
>> 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

=C2=A0

=
--001a11360a1c165b3704f75334e3-- From nobody Fri Apr 18 09:03:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6056B1A044C for ; Fri, 18 Apr 2014 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyjSs59LopnN for ; Fri, 18 Apr 2014 09:03:18 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 688DB1A0448 for ; Fri, 18 Apr 2014 09:03:14 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so3195537veb.35 for ; Fri, 18 Apr 2014 09:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VZZCqoU1UJ7O1y7lnWqX1gz2Em4Jf/VEXF7kVgEQbQY=; b=BncUXx78Q0b9swvvWgP8L4BXYPdsq3p0bt71NtbA9/mJofp85qfyMTDitesl+4+UEK f8tknVVVEpT+5blCMKcwAmZnWvcFGly93jBmsKBC8tnUjV519xH/DePmxkSDwsEA/Mp1 LOH8Z03X8wNG2+7DV/mepcpiGLdLrdcaRcd6s/6z3uEy7QMqXwIysOVZtuXs9TBYDWnW rIl0qx1s1/jyw0Xx/06ucdLTn05B/u0lKzP3ggAZDUV8iX0/Z4noTSz5F5mVOBXnzXBb UvuFQGlHLKIAnNzKuzcDgVXExjpoz3UDSFIP2MSNR05za5ceuEZVKpAoNcF73Nbi9R7t OQSg== X-Gm-Message-State: ALoCoQkslMTb8QUaetLz9PechF+dXc6mUg3Z9Eks/IV8x9HRISAEOIvl18JdF27Xc+yl69hlUJOb X-Received: by 10.58.243.39 with SMTP id wv7mr804667vec.51.1397836990148; Fri, 18 Apr 2014 09:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 09:02:50 -0700 (PDT) In-Reply-To: <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 12:02:50 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dQGQHROMeDDpAd5HkUifWBPqMvU Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 16:03:24 -0000 I dont think a post like this is useful. State your reasons please - just cheering on is not helpful. cheers, jamal On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau wrote: > > Sorry for the top post, but I wanted to inject that for the record, Brocade is in favor of using RestConf/Yang (or variations of those) for I2RS. We have no interest in using FORCES as the basis for this. > > --Tom > > > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim wrote: > >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic wrote: >>> Jamal, >>> >>> Here are two criteria to be considered: >>> 1. technical >>> 2. commercial/business >>> >>> We can discuss pros and cons for both, but have to state that from business perspective for >>> Juniper going with RESTCONF/YANG make more sense. We already built the Junos model >>> in YANG and have or are in process of building needed tools. >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are working >>> on RESTCONF implementation. >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so >this looks like a low hanging fruit from business perspective. >>> >> >> Thanks for being sincere Dean. >> First, I will say I empathize with your view above (I understand such >> a view is motivation >> for many unfortunately often disguised as technical opinion). While i >> empathize, I would like >> to point that we need to have these discussions which are technical >> otherwise there is >> no point in having a standard. >> In any case I get where you are coming from. >> >>> Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm >>> not aware of it), don't see reason to switch from RESTCONF and YANG. >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - >> I'll start with >> 1 or 2 of what i think are requirements against protocol/model so we >> dont have to >> respond to long emails. If you have issues with ForCES please bring >> them up as well >> and we can discuss (I brought up a few in my presentation). >> >> One of the issues was throughput and latency. >> You stated in London that you want to be able to do a large amount of >> updates/sec. >> Other than you - I cant get anyone else to say this is a requirement. >> I do believe it is. >> It will be useful for example to come up with some hand waving numbers against >> some agreed-to info model (eg the rib) and see how this requirement is >> met by the >> different protocols. >> >> As for the model, I'd like to quote from the minutes what Tom Petch >> (who i consider to >> be a sage in this space): >> "If I was writing an info model I'd use YANG every time. But if I was >> writing a data >> model I'd go for ForCES." >> And this is rooted in the nature of Yang being intended for Config. >> >> There is also the issue of i2rs ability to describe instances which is >> lacking in Yang; >> but maybe leave that out to a different email.. >> >> cheers, >> jamal >> >>> We can find out down the line that RESTCONF/YANG was the wrong way to go, but that >>> can be always changed. From my perspective it looks right today. >>> >>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Fri Apr 18 09:04:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E169A1A015D for ; Fri, 18 Apr 2014 09:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKiTNoBludaV for ; Fri, 18 Apr 2014 09:04:06 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 292221A0448 for ; Fri, 18 Apr 2014 09:04:06 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so3194487veb.18 for ; Fri, 18 Apr 2014 09:04:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qa3LZQTK1pVlb1V51j1n/c/Q4mJMjtbk7jSGaHXr7fY=; b=JsUPu25l/sGK6+h2U2VP+0iF24H9PVa2RW/DRN9n+tAvUeLksKzmUPs1KmYTIY6E6F 5c5cejyH+EwKWDQWD4CgcdtJWQzxzaWoQ0zIvDatFxxKotXfAeIzsyG8I58gmJP/NLoi m2Uy57lL3H+iwyGo2VaWDSoIexj1kBQgzdrqyr+J1brl+cITwc35TsgtmU6OdUrURm7R sI3SOlVU8j6q2n/EbnjIf3H8YSwMckmeq5B1wUAal3EzpZNoZfMxuezcWdmZQZSaGwsP UWhr9qOYt4jx+IoLRk8TaKvajj+NSXmaCutBm/wv4CkFg7kxK1k/r5jrw5nBTjXnCM+E jHjw== X-Gm-Message-State: ALoCoQkZgYN98pwObltEOyhliIq+tQuBlrVFMkUBgg0ZAJ+MCmNM0mY4TVYkCQ9XPFSO5JB91RI3 X-Received: by 10.58.77.238 with SMTP id v14mr3550391vew.27.1397837042010; Fri, 18 Apr 2014 09:04:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 09:03:41 -0700 (PDT) In-Reply-To: <11BE70B4-52F1-4165-B474-66C6021123C1@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <11BE70B4-52F1-4165-B474-66C6021123C1@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 12:03:41 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/RKzyPSrPtcZhwaRkTgQAHUpgTo4 Cc: "i2rs@ietf.org" , sarikaya@ieee.org, Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 16:04:11 -0000 And what are those mysterious requirements it doesnt meet Thomas? cheers, jamal On Fri, Apr 18, 2014 at 11:47 AM, Thomas Nadeau wrote: > > I believe its because OF-Config does not meet the requirements we set forth. > > --Tom > > On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya > wrote: > > Hi Dean, > > I attended i2rs session in London on this issue. > > My question is why ONF Management and Configuration protocol (OF-Config 1.2) > was not on the table. > > Regards, > > Behcet > > > On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic wrote: >> >> Jamal, >> >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >> >> We can discuss pros and cons for both, but have to state that from >> business perspective for Juniper going with RESTCONF/YANG make more sense. >> We already built the Junos model in YANG and >> have or are in process of building needed tools. Same goes for RESTCONF. >> We have NETCONF implemented in Junos and are working on RESTCONF >> implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> RESTCONF as well, so this looks like a low hanging fruit from business >> perspective. >> >> Looking at technical aspect, unless there is a very compelling reason (and >> there might be, but I'm not aware of it), don't see reason to switch from >> RESTCONF and YANG. >> We can find out down the line that RESTCONF/YANG was the wrong way to go, >> but that can be always changed. From my perspective it looks right today. >> >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >> Dean >> >> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >> >> > Ok, since nobody is saying anything i'll bite. >> > How would you like for this discussion to proceed? >> > >> > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> >> Dear I2RSers, >> >> >> >> At the last I2RS WG meeting there was a great deal of conversation >> >> regarding selection of both modeling language and underlying transport >> >> protocol. Consensus at the time was to make use of Yang and (NetConf >> >> or >> >> RestConf) (unclear). >> >> >> > >> > And i believe the view, as correctly presented by you, is for folks to >> > go back >> > and make educated decisions by actually getting knowledgeable about >> > the different views presented. "Consensus" that you described above >> > to me looked like a pageant popularity contest not based on anything >> > technical ("who likes contestant in the blue shirt? please cheer for >> > them"). >> > >> > In my opinion i dont think the requirements are clear. >> > >> > Will that get the crickets stop chirping? >> > >> > cheers, >> > jamal >> > >> >> Before coming to a final consensus, we'd like to give people adequate >> >> time >> >> to review source material, marshall arguments and discuss on the >> >> mailing >> >> list. To this end, we're asking that interested parties do just this >> >> over >> >> the course of the next ~two weeks. Following that period, on 4/28, >> >> we'll be >> >> initiating a consensus call that will last an additional two weeks, >> >> with the >> >> aim of converging modeling language / protocol by Friday, 5/9. >> >> >> >> The consensus call should also generate proposals for any material >> >> changes >> >> required to the underlying protocols. These proposals in turn will >> >> form the >> >> basis for a later draft including gap analysis and said changes. Those >> >> strongly in favor of one protocol over another should be prepared to >> >> contribute to this analysis. >> >> >> >> >> >> best, >> >> >> >> -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 >> > >> > >> >> >> _______________________________________________ >> 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 nobody Fri Apr 18 09:41:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6161A042F for ; Fri, 18 Apr 2014 09:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfPeErCutAwa for ; Fri, 18 Apr 2014 09:41:32 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 23A931A0438 for ; Fri, 18 Apr 2014 09:41:31 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so3214576veb.4 for ; Fri, 18 Apr 2014 09:41:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bksX3G3u0Ar4THoWgZVgIJ7Y2yjbiHbcs9nOlD3zi9Q=; b=OadUJp4ue85oG4Oa9P3JQggTG0fKtld2tFiuYrK16HLsWl1nZlVlQQHxkRYvJo/Han ED48JvsQyThpgxIlb29KWPGEQ7PKKByW4b145mqEbEHnGmk1VAZkbbb2NpbKVzCPHgd+ gwNONYzJMga2OUwmZKb7/lBH0pcKlCMNU1i+wS5TkCXpFXwLNwkNqnvOUiTHpOxm6vAu laEOmhXqkEywQNQFFcV/fAXGWcpnuLlD6nuqV+neS3dM756YWDREmsIQkoGIokjddlaJ ixShAvfyY2dlysOl+//PUkW7+ntQ0KakMwTlEksG+7x4cREm8ZZJcT1xr9KuDZ36E1uR glbA== X-Gm-Message-State: ALoCoQmtvIMqaWSQpfofBRA7Qb68NV/Rbg5T2XwZHP4L7+GBkf5nQI2MhUKjnKcTbfDDAp/BSYGr X-Received: by 10.52.104.33 with SMTP id gb1mr3072139vdb.45.1397839287844; Fri, 18 Apr 2014 09:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 09:41:07 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 12:41:07 -0400 Message-ID: To: sarikaya Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/I99QuCMs4pF07zltYrCd0YdFmIs Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 16:41:37 -0000 On Fri, Apr 18, 2014 at 11:57 AM, Behcet Sarikaya wrote: > > > > On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares wrote: >> >> Behcet: >> >> >> >> Can you tell me how the ONF Management and configuration protocol will >> interface with the routing system with all the requirements set forth by the >> architecture document? Please refer to version 2.0 architecture >> >> > > > Don't get me wrong. > > I am not speaking in favor of OF-Config. > > But the point is that a more realistic choice should be between these two > choices. > Why? > If the study showed that OF-Config did not meet the requirements, that is > fine but I heard no one said that. > I wonder if the forces protocol meets these requirements? > > Only set of requirements i could find was what appears to be an abandoned draft here: http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00 Not sure i agree with some of the parts but it is what i used to present. I havent seen anything on the model. Overall requirements need to be considered. You know what would be really useful is to show up at the next meeting with implementations of I2RS - perhaps a few demos and discuss what the lessons learnt are. cheers, jamal > > Behcet >> >> Or review to the presentation at IETF. If you can present these features >> in email or any substantial way, we will listen. In my observations, the >> ONF management protocol was designed for the ONF flows and not the >> information models required or the use case required. >> >> >> >> Sue Hares >> >> >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet Sarikaya >> Sent: Friday, April 18, 2014 11:32 AM >> To: Dean Bogdanovic >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> >> >> Hi Dean, >> >> I attended i2rs session in London on this issue. >> >> >> My question is why ONF Management and Configuration protocol (OF-Config >> 1.2) was not on the table. >> >> Regards, >> >> Behcet >> >> >> >> On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic >> wrote: >> >> Jamal, >> >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >> >> We can discuss pros and cons for both, but have to state that from >> business perspective for Juniper going with RESTCONF/YANG make more sense. >> We already built the Junos model in YANG and >> have or are in process of building needed tools. Same goes for RESTCONF. >> We have NETCONF implemented in Junos and are working on RESTCONF >> implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> RESTCONF as well, so this looks like a low hanging fruit from business >> perspective. >> >> Looking at technical aspect, unless there is a very compelling reason (and >> there might be, but I'm not aware of it), don't see reason to switch from >> RESTCONF and YANG. >> We can find out down the line that RESTCONF/YANG was the wrong way to go, >> but that can be always changed. From my perspective it looks right today. >> >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >> Dean >> >> >> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >> >> > Ok, since nobody is saying anything i'll bite. >> > How would you like for this discussion to proceed? >> > >> > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> >> Dear I2RSers, >> >> >> >> At the last I2RS WG meeting there was a great deal of conversation >> >> regarding selection of both modeling language and underlying transport >> >> protocol. Consensus at the time was to make use of Yang and (NetConf >> >> or >> >> RestConf) (unclear). >> >> >> > >> > And i believe the view, as correctly presented by you, is for folks to >> > go back >> > and make educated decisions by actually getting knowledgeable about >> > the different views presented. "Consensus" that you described above >> > to me looked like a pageant popularity contest not based on anything >> > technical ("who likes contestant in the blue shirt? please cheer for >> > them"). >> > >> > In my opinion i dont think the requirements are clear. >> > >> > Will that get the crickets stop chirping? >> > >> > cheers, >> > jamal >> > >> >> Before coming to a final consensus, we'd like to give people adequate >> >> time >> >> to review source material, marshall arguments and discuss on the >> >> mailing >> >> list. To this end, we're asking that interested parties do just this >> >> over >> >> the course of the next ~two weeks. Following that period, on 4/28, >> >> we'll be >> >> initiating a consensus call that will last an additional two weeks, >> >> with the >> >> aim of converging modeling language / protocol by Friday, 5/9. >> >> >> >> The consensus call should also generate proposals for any material >> >> changes >> >> required to the underlying protocols. These proposals in turn will >> >> form the >> >> basis for a later draft including gap analysis and said changes. Those >> >> strongly in favor of one protocol over another should be prepared to >> >> contribute to this analysis. >> >> >> >> >> >> best, >> >> >> >> -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 >> > >> > >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > From nobody Fri Apr 18 09:47:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7D1A0444 for ; Fri, 18 Apr 2014 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGDwEfZ3AIJh for ; Fri, 18 Apr 2014 09:47:05 -0700 (PDT) Received: from nm8-vm1.bullet.mail.gq1.yahoo.com (nm8-vm1.bullet.mail.gq1.yahoo.com [98.136.218.224]) by ietfa.amsl.com (Postfix) with ESMTP id 006361A044F for ; Fri, 18 Apr 2014 09:47:04 -0700 (PDT) Received: from [98.137.12.57] by nm8.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 16:47:01 -0000 Received: from [208.71.42.213] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 16:47:01 -0000 Received: from [127.0.0.1] by smtp224.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 16:47:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397839621; bh=+S45lwg5adG/M5fxQO3BgzVCWfIyXASPAo5wbqsk2jw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=ZqYQrJyyXP7t9sNYDRjFn2Gv1k4PMOaYE1tP5P2Qten6lKIZsqHU4xe7oFtrdZQp+cDdtsfuxcCtUsaX2t49hXfbIMsPvmZtimVm8mOYfBNBQRaubB+ZCbmh7CWK/+d2VjEuB410GYLfCdkcT8M1HpVrWkPonH244Hzp+uBs5iI= X-Yahoo-Newman-Id: 154148.6900.bm@smtp224.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8GwYudcVM1l0RHdi3nWBxeKg7Rj5ba7zB2mgSt6DJ1wYapK xDHF6XWneX4cWop23VmaKw9NCHK4w5gkuCRMRqSS_er8XC3IXyrGWyXA7WcM nU_il.CP8T9lRIMuBUDZAlrsURERDrxVhIXTVhgMhM.8L406EHyrAtJbOw00 2DqL5X9K_WJ_VIldx4SofWodg0sunTJN7WNidHMAwhYfjlgrETT.TE6HmYBM A0_IjRLZsLwydSjEmwL3xyrNF_9pc3mxD31OVqMsAwdCuaOli1VY.vDYiq4m x7RSI_JPJApUz0H.0FrCvtybSGmd.fXN7078cdBswr1CgGXyhHuygOD4TFBJ caP_suMLnRoyXb4t7.Q5z5zN3fLonIAvcyJ3EJu1mrjcWl8CUqkgJirBrE50 rdfq_P._5fdXtv0JXBxLSG1p6sXKxJbI1RYYe95UMSF0AhNysjig8NsWgHiX N4pKnc2.kVobvDros.CtnL5HNrg_B1tL.brLXPtgcrHJsFINLKiXrcDHA9gs H6y2KWM1zPeGwtcChodwyN0WFUl6YcBdoYcoEhfCxWlaknZhQ_IfMKmmiZGU ZMZiOgJ23U4UvOuC73DhT3KoFTRzbNjE8q99Xa39gSx7PPY1Xu2U4e80W7mx Dg7RDHFQd5RVUc7nxdb_q X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [98.139.211.125]) by smtp224.mail.gq1.yahoo.com with SMTP; 18 Apr 2014 16:47:01 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Fri, 18 Apr 2014 09:46:50 -0700 From: Nitin Bahadur To: , Susan Hares Message-ID: Thread-Topic: [i2rs] consensus on I2RS protocol and model In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3480659220_5289264" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1e_BPpS8r4xFHERDasgamjZmO0Y Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 16:47:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3480659220_5289264 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > > If the study showed that OF-Config did not meet the requirements, that is fine > but I heard no one said that. > On Feb 5th, Alia Atlas said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html > Gap Analysis for different Protocols: I2RS needs to select a protocol to use. I believe that we have volunteers for discussing RESTCONF. > We'd welcome hearing from others who can provide at least a presentation for review before IETF and preferably a quick draft as well. On Feb 27th, Ed Crabbe said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html > The I2RS agenda has been posted. Those who think OF-Config should have been a candidate, should have presented at the IETF; or at least started a discussion on the mailing list. My 2 cents Nitin --B_3480659220_5289264 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


If the study sho= wed that OF-Config did not meet the requirements, that is fine but I heard n= o one said that.


On Feb 5th, Alia Atlas said:&nbs= p;http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html

> Gap Analysis for different Prot= ocols:  I2RS needs to select a protocol to use.  I believe that we have volunteers for discussing RESTCONF.&nb= sp;
> We'd welcome hearing from others who can provide at least= a presentation for review before IETF and preferably a quick draft as well.

> The I= 2RS agenda has been posted.  

Those who think = OF-Config should have been a candidate, should have presented at the IETF; o= r at least started a discussion on the mailing list.

My 2 cents
Nitin
--B_3480659220_5289264-- From nobody Fri Apr 18 10:37:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F481A04A3 for ; Fri, 18 Apr 2014 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5PnNS7SEmTx for ; Fri, 18 Apr 2014 10:37:00 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id ACE401A0496 for ; Fri, 18 Apr 2014 10:36:56 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so1896336qcx.41 for ; Fri, 18 Apr 2014 10:36:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z5CddVniAiNNV60fch7xeF/t7Umy+j8wITQHFwO5K+o=; b=MJg8yiGnV+SXvMlc7QXKEkrGlffydpU3O0SiQ9jJ3oUxgzKuv+yCNEgfKoci5gJYOd 8TKHShMxgKGXjQNCI8V8FiBKn2uS8sRYHe6oLIrjuNciNCsLtpLLbhGp912U2yCe7xe9 imSZOk7JIUa0/IYEAp0DDIHBt4uMKOUA1fe6fOsuH7UquJf03xqAnZyox3kQ4qqJWFP6 TDQR+pNzvYLLaQkfqiEL0tqke4oNoGMY4lmhirZAMPrJUTnKHwj2LmwZHyyrlciye8QL rT805t6J64G7eLoXaYhcgJsDKxDFQihyMX2LI3+qKljZhftKs6c3yGEPAzucfJqyjGGp 1/nA== X-Gm-Message-State: ALoCoQkwpkEfq5sRgKELFgEjCyvnNCxNDm/BwNiGI9IT6FgtqamO9t3GNZ1KQ8pJdO31M4G5kthM MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr21163758qca.7.1397842612471; Fri, 18 Apr 2014 10:36:52 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 18 Apr 2014 10:36:52 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> Date: Fri, 18 Apr 2014 10:36:52 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a1133c9385e626e04f7549880 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Nk0oSl1I9rOvXE2fck1rBVV2zgk Cc: Thomas Nadeau , Crabbe Edward , Dean Bogdanovic , "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 17:37:06 -0000 --001a1133c9385e626e04f7549880 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim wrote: > I dont think a post like this is useful. > State your reasons please - just cheering on is not helpful. > > It is as useful as +1, which IMO is useful. Availability of tools is important to developers who intend to implement I2RS. I think there are also some technical reasons to use YANG: - YANG is protocol and encoding independent. It can be mapped to a protocol fairly easily. It supports XML now. A standards effort to support JSON encoding has been started in the NETMOD WG. A proposal to support EXI exists, and support for CBOR is possible. - YANG supports definition of protocol operations, data nodes, and notification events. Data nodes are either configuration or non-configuration. XPath is used to define validation rules such as 'must' and 'when'. There rules apply differently to each context (operation, config data, non-config data, notification). - The local config is related to operational state, especially since operational values may include configured values. YANG is already being used for configuration. Using consistent data naming is important. A YANG instance-identifier is an absolute-path (restricted XPath) expression. - YANG supports external and conditional augmentation of any data model. Each YANG module defines its own namespace. A module namespace can be sub-divided with sub-modules. All nodes are identified with QNames, using the YANG module or namespace as the extended name. This supports non-centralized naming authority (i.e., vendor A and vendor B can both augment the same standard data node without any possibility of naming collisions.) - YANG "features" allow optional functionality to be defined in a data-model specific manner. Conformance advertisement information is standardized so clients know what options are supported by each server implementation. - YANG "extensions" allow new language statements to be added to the language, These external statements must be parsed by every YANG compiler, even if the compiler does not understand the extension. This allows YANG to be easily adapted for new applications, without the need to revise the language. jamal > Andy > > On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau > wrote: > > > > Sorry for the top post, but I wanted to inject that for the > record, Brocade is in favor of using RestConf/Yang (or variations of those) > for I2RS. We have no interest in using FORCES as the basis for this. > > > > --Tom > > > > > > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim < > hadi@mojatatu.com> wrote: > > > >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic > wrote: > >>> Jamal, > >>> > >>> Here are two criteria to be considered: > >>> 1. technical > >>> 2. commercial/business > >>> > >>> We can discuss pros and cons for both, but have to state that from > business perspective for > >>> Juniper going with RESTCONF/YANG make more sense. We already built the > Junos model > >>> in YANG and have or are in process of building needed tools. > >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are > working > >>> on RESTCONF implementation. > >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so >this looks like a low hanging fruit from business > perspective. > >>> > >> > >> Thanks for being sincere Dean. > >> First, I will say I empathize with your view above (I understand such > >> a view is motivation > >> for many unfortunately often disguised as technical opinion). While i > >> empathize, I would like > >> to point that we need to have these discussions which are technical > >> otherwise there is > >> no point in having a standard. > >> In any case I get where you are coming from. > >> > >>> Looking at technical aspect, unless there is a very compelling reason > (and there might be, but I'm > >>> not aware of it), don't see reason to switch from RESTCONF and YANG. > >> > >> Maybe we'll bring up the topics sequentially as the thread proceeds - > >> I'll start with > >> 1 or 2 of what i think are requirements against protocol/model so we > >> dont have to > >> respond to long emails. If you have issues with ForCES please bring > >> them up as well > >> and we can discuss (I brought up a few in my presentation). > >> > >> One of the issues was throughput and latency. > >> You stated in London that you want to be able to do a large amount of > >> updates/sec. > >> Other than you - I cant get anyone else to say this is a requirement. > >> I do believe it is. > >> It will be useful for example to come up with some hand waving numbers > against > >> some agreed-to info model (eg the rib) and see how this requirement is > >> met by the > >> different protocols. > >> > >> As for the model, I'd like to quote from the minutes what Tom Petch > >> (who i consider to > >> be a sage in this space): > >> "If I was writing an info model I'd use YANG every time. But if I was > >> writing a data > >> model I'd go for ForCES." > >> And this is rooted in the nature of Yang being intended for Config. > >> > >> There is also the issue of i2rs ability to describe instances which is > >> lacking in Yang; > >> but maybe leave that out to a different email.. > >> > >> cheers, > >> jamal > >> > >>> We can find out down the line that RESTCONF/YANG was the wrong way to > go, but that > >>> can be always changed. From my perspective it looks right today. > >>> > >>> Just to be clear, I vote for RESTCONF/YANG adoption for 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 > --001a1133c9385e626e04f7549880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
I dont think a post like this is useful.
State your reasons please - just cheering on is not helpful.


It is as useful as +1, which IMO is us= eful.

Availability of tools is important to develo= pers who intend to implement I2RS.

I think there a= re also some technical reasons to use YANG:

=A0 - YANG is protocol and encoding independent. It can= be mapped to a protocol
=A0 =A0 fairly easily. =A0It supports XM= L now. A standards effort to support JSON encoding
=A0 =A0 has be= en started in the NETMOD WG. =A0A proposal to support EXI exists, and
=A0 =A0 support for CBOR is possible.

= =A0- YANG supports definition of protocol operations, data nodes, and notif= ication events.
=A0 =A0Data nodes are either configuration or non= -configuration. XPath is used to define
=A0 =A0validation rules such as 'must' and 'when'. The= re rules apply differently to
=A0 =A0each context (operation, con= fig data, non-config data, notification).

= =A0- The local config is related to operational state, especially since ope= rational values may
=A0 =A0include configured values. =A0YANG is already being used for co= nfiguration.
=A0 =A0Using consistent data naming is important. A = YANG instance-identifier is an
=A0 =A0absolute-path (restricted X= Path) expression.

=A0- YANG supports external and conditional augmentatio= n of any data model.
=A0 =A0Each YANG module defines its own name= space. =A0A module namespace can
=A0 =A0be sub-divided with sub-m= odules. =A0All nodes are identified with QNames,
=A0 =A0using the YANG module or namespace as the extended name. This s= upports
=A0 =A0non-centralized naming authority (i.e., vendor A a= nd vendor B can both augment
=A0 =A0the same standard data node w= ithout any possibility of naming collisions.)

=A0- YANG "features" allow optional functiona= lity to be defined in a data-model specific manner.
=A0 =A0Confor= mance advertisement information is standardized so clients know what option= s
=A0 =A0are supported by each server implementation.

=A0- YANG "extensions" allow new language statements to be= added to the language,
=A0 =A0These external statements must be = parsed by every YANG compiler, even if
=A0 =A0the compiler does not understand the extension. =A0This allows = YANG to be easily
=A0 =A0adapted for new applications, without th= e need to revise the language.


jamal

Andy
=A0

On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:
>
> =A0 =A0 =A0 =A0 Sorry for the top post, but I wanted to inject that fo= r the record, Brocade is in favor of using RestConf/Yang (or variations of = those) for I2RS. We have no interest in using FORCES as the basis for this.=
>
> =A0 =A0 =A0 =A0 --Tom
>
>
> On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>
>> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
>>> Jamal,
>>>
>>> Here are two criteria to be considered:
>>> 1. technical
>>> 2. commercial/business
>>>
>>> We can discuss pros and cons for both, but have to state that = from business perspective for
>>> Juniper going with RESTCONF/YANG make more sense. We already b= uilt the Junos model
>>> in YANG and have or are in process of building needed tools. >>> Same goes for RESTCONF. We have NETCONF implemented in Junos a= nd are working
>>> on RESTCONF implementation.
>>> Many carriers adopted or are adopting NETCONF/YANG, are lookin= g into RESTCONF as well, so >this looks like a low hanging fruit from bu= siness perspective.
>>>
>>
>> Thanks for being sincere Dean.
>> First, I will say I empathize with your view above (I understand s= uch
>> a view is motivation
>> for many unfortunately often disguised as technical opinion). Whil= e i
>> empathize, I would like
>> to point that we need to have these discussions which are technica= l
>> otherwise there is
>> no point in having a standard.
>> In any case I get where you are coming from.
>>
>>> Looking at technical aspect, unless there is a very compelling= reason (and there might be, but I'm
>>> not aware of it), don't see reason to switch from RESTCONF= and YANG.
>>
>> Maybe we'll bring up the topics sequentially as the thread pro= ceeds -
>> I'll start with
>> 1 or 2 of what i think are requirements against protocol/model so = we
>> dont have to
>> respond to long emails. If you have issues with ForCES please brin= g
>> them up as well
>> and we can discuss (I brought up a few in my presentation).
>>
>> One of the issues was throughput and latency.
>> You stated in London that you want to be able to do a large amount= of
>> updates/sec.
>> Other than you - I cant get anyone else to say this is a requireme= nt.
>> I do believe it is.
>> It will be useful for example to come up with some hand waving num= bers against
>> some agreed-to info model (eg the rib) and see how this requiremen= t is
>> met by the
>> different protocols.
>>
>> As for the model, I'd like to quote from the minutes what Tom = Petch
>> (who i =A0consider to
>> be a sage in this space):
>> "If I was writing an info model I'd use YANG every time. = =A0But if I was
>> writing a data
>> model I'd go for ForCES."
>> And this is rooted in the nature of Yang being intended for Config= .
>>
>> There is also the issue of i2rs ability to describe instances whic= h is
>> lacking in Yang;
>> but maybe leave that out to a different email..
>>
>> cheers,
>> jamal
>>
>>> We can find out down the line that RESTCONF/YANG was the wrong= way to go, but that
>>> can be always changed. From my perspective it looks right toda= y.
>>>
>>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.<= br> >>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>

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

--001a1133c9385e626e04f7549880-- From nobody Fri Apr 18 10:40:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C11A03CF for ; Fri, 18 Apr 2014 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9Sr1zv5PrSC for ; Fri, 18 Apr 2014 10:40:01 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD591A02FB for ; Fri, 18 Apr 2014 10:40:01 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4269D276EB4D; Fri, 18 Apr 2014 13:39:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9E33A2F9-0231-436B-99FC-11A76EE6179B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 13:39:56 -0400 Message-Id: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YchmTz-QlGjNX3Pbc2z1oll1uWE Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 17:40:06 -0000 --Apple-Mail=_9E33A2F9-0231-436B-99FC-11A76EE6179B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why is that not useful? Because I didn't say I was in favor of = forces? *) It IS useful to say that my company's products implement = Yang/Netconf and will support RestConf, and therefore a derivative of = those technologies used for i2rs is preferred. We have no plans to = support any of the other discussed options in i2rs such as Forces at = this time. The reasons are simple: our customers asked for Netconf/Yang = models and as far as I can tell, have no interest in Forces. =20 =46rom my perspective, continuing to debate which protocol is = derived to become i2rs is a waste of everyone's time. Its clear what = people want from the meeting, and if you poll interested implementations = you'll likely get the same answer: yang/netconf/restconf. Lets please = stop delaying i2rs and get some work done here. --Tom On Apr 18, 2014:12:02 PM, at 12:02 PM, Jamal Hadi Salim = wrote: > I dont think a post like this is useful. > State your reasons please - just cheering on is not helpful. >=20 > cheers, > jamal >=20 > On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau = wrote: >>=20 >> Sorry for the top post, but I wanted to inject that for the = record, Brocade is in favor of using RestConf/Yang (or variations of = those) for I2RS. We have no interest in using FORCES as the basis for = this. >>=20 >> --Tom >>=20 >>=20 >> On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim = wrote: >>=20 >>> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic = wrote: >>>> Jamal, >>>>=20 >>>> Here are two criteria to be considered: >>>> 1. technical >>>> 2. commercial/business >>>>=20 >>>> We can discuss pros and cons for both, but have to state that from = business perspective for >>>> Juniper going with RESTCONF/YANG make more sense. We already built = the Junos model >>>> in YANG and have or are in process of building needed tools. >>>> Same goes for RESTCONF. We have NETCONF implemented in Junos and = are working >>>> on RESTCONF implementation. >>>> Many carriers adopted or are adopting NETCONF/YANG, are looking = into RESTCONF as well, so >this looks like a low hanging fruit from = business perspective. >>>>=20 >>>=20 >>> Thanks for being sincere Dean. >>> First, I will say I empathize with your view above (I understand = such >>> a view is motivation >>> for many unfortunately often disguised as technical opinion). While = i >>> empathize, I would like >>> to point that we need to have these discussions which are technical >>> otherwise there is >>> no point in having a standard. >>> In any case I get where you are coming from. >>>=20 >>>> Looking at technical aspect, unless there is a very compelling = reason (and there might be, but I'm >>>> not aware of it), don't see reason to switch from RESTCONF and = YANG. >>>=20 >>> Maybe we'll bring up the topics sequentially as the thread proceeds = - >>> I'll start with >>> 1 or 2 of what i think are requirements against protocol/model so we >>> dont have to >>> respond to long emails. If you have issues with ForCES please bring >>> them up as well >>> and we can discuss (I brought up a few in my presentation). >>>=20 >>> One of the issues was throughput and latency. >>> You stated in London that you want to be able to do a large amount = of >>> updates/sec. >>> Other than you - I cant get anyone else to say this is a = requirement. >>> I do believe it is. >>> It will be useful for example to come up with some hand waving = numbers against >>> some agreed-to info model (eg the rib) and see how this requirement = is >>> met by the >>> different protocols. >>>=20 >>> As for the model, I'd like to quote from the minutes what Tom Petch >>> (who i consider to >>> be a sage in this space): >>> "If I was writing an info model I'd use YANG every time. But if I = was >>> writing a data >>> model I'd go for ForCES." >>> And this is rooted in the nature of Yang being intended for Config. >>>=20 >>> There is also the issue of i2rs ability to describe instances which = is >>> lacking in Yang; >>> but maybe leave that out to a different email.. >>>=20 >>> cheers, >>> jamal >>>=20 >>>> We can find out down the line that RESTCONF/YANG was the wrong way = to go, but that >>>> can be always changed. =46rom my perspective it looks right today. >>>>=20 >>>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_9E33A2F9-0231-436B-99FC-11A76EE6179B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUWNsAAoJEPcO+I7eiUJZs6AP/2Djops3R4K7eiy5YRBde0CX XJXLe4neGZKLLgZAp/JIlEYOd+1Wn02fNY4l+bVYLF8In/umJWVBi3yTEmRkFU5o abgnUfSwcRLdAFxghA46NVCXNcFk5Ya7Yf2JpFZizxJyloORR3Y33SIBss6W//XC MxqDYEhO/dxsYoiJhgdszfIAn8wRVLhMlzNdMhu4mEUUUYCuHDU7mM0FHNAw46tC Ymi1E2DNbEXX5OBCR17ZfPLJShkRHgeahho2MP79rjSRXIjmLlH5EP1ilo7ZtOWm xXBUq7GArrbjXOsIYI0DNax8W/GKy4smhRRPGKiqeMK1Q47cDHV1Ke5n0zL4jSRC b+tAe7uUDdBv/Sdo5s4qaxoo++YwPxD17tipfOO+m6Rsuyw1A+thbOT1zW8kLL7p MyxKQhJS7I4EzK5jHHW1GzDTZwDTMRPJUPdvR2lcRIXlHZU2rXODl3rbVecrgFIp NWareYZVSegPLSolZW7JyTI6XxVQhDbO+Tv9hIot72J64Iyeu8I57aAf3AwR6DGr HTc5MrTIVuMzaXM3yXzBPMq4Q5tki3dxIn3bl66o7gVKWFkgL0UvvVyViUVutvgN Tjl2ngI6Pa9FLeiDI0+oEtAWdoX34tZidOB0P4rTnkVrC4+D/Lxgs2IVzC7ihon3 CoRvAmIIxM4OD68aIJOl =Df6n -----END PGP SIGNATURE----- --Apple-Mail=_9E33A2F9-0231-436B-99FC-11A76EE6179B-- From nobody Fri Apr 18 10:42:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843C1A03CF for ; Fri, 18 Apr 2014 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjsFbjLlXXh3 for ; Fri, 18 Apr 2014 10:42:31 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4941A01FE for ; Fri, 18 Apr 2014 10:42:31 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 1FE22276EBD7; Fri, 18 Apr 2014 13:42:27 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_209770E6-49B7-44E2-A8BA-263CBEE1756E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 13:42:26 -0400 Message-Id: References: To: b nitin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rADc2vvE8St9oSkwqWGykIUlm2o Cc: "i2rs@ietf.org" , Crabbe Edward , Jamal Hadi Salim , Dean Bogdanovic , sarikaya@ieee.org, Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 17:42:33 -0000 --Apple-Mail=_209770E6-49B7-44E2-A8BA-263CBEE1756E Content-Type: multipart/alternative; boundary="Apple-Mail=_0E330BE0-2F8D-4768-8915-1E687801BAE8" --Apple-Mail=_0E330BE0-2F8D-4768-8915-1E687801BAE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur = wrote: >=20 >>=20 >> If the study showed that OF-Config did not meet the requirements, = that is fine but I heard no one said that. >>=20 >=20 >=20 > On Feb 5th, Alia Atlas said: = http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html >=20 > > Gap Analysis for different Protocols: I2RS needs to select a = protocol to use. I believe that we have volunteers for discussing = RESTCONF.=20 > > We'd welcome hearing from others who can provide at least a = presentation for review before IETF and preferably a quick draft as = well. >=20 > On Feb 27th, Ed Crabbe said: = http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html > > The I2RS agenda has been posted. =20 >=20 > Those who think OF-Config should have been a candidate, should have = presented at the IETF; or at least started a discussion on the mailing = list. >=20 > My 2 cents > Nitin I agree %100 with your 2 cents. --Tom > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_0E330BE0-2F8D-4768-8915-1E687801BAE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 18, 2014:12:46 PM, at 12:46 PM, = Nitin Bahadur <nitin_bahadur@yahoo.com> = wrote:



If the study showed that = OF-Config did not meet the requirements, that is fine but I heard no one = said = that.

<= br>
On Feb 5th, Alia Atlas = said: h= ttp://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html

> Gap Analysis for different = Protocols:  I2RS needs to select a protocol to use.  I believe that we have volunteers for discussing = RESTCONF. 
> We'd welcome hearing from others who can = provide at least a presentation for review before IETF and preferably a quick draft as well.

> The I2RS agenda has been posted. =  

Those who think OF-Config should have = been a candidate, should have presented at the IETF; or at least started = a discussion on the mailing list.

My 2 = cents
Nitin

I agree = %100 with your 2 cents.

= --Tom


_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_0E330BE0-2F8D-4768-8915-1E687801BAE8-- --Apple-Mail=_209770E6-49B7-44E2-A8BA-263CBEE1756E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUWQCAAoJEPcO+I7eiUJZNPcP/jggKYvEBfbdIjLCBI+YQL0h egstpQyfzRmS3MZr0DMHwLa86GFoPIfMBCcmnQgBCxBGx3cRPEJjjGtUNMkTgwjd ulruWuuvNUbzcL1BBqlo20WlR12zguaMHRWZH48Romfu/7wlGYjiQ406HoPzx86I h/IXAd+7O/HxE/0mgLZfT/Iegz/TKwO/JYLoV7vQHoQgl0vEhbPzBtOUZa2mh/+O 8JWeXeTG25a5i3vYeboHP1NROj2Y+DSwe9r67uWOotBpMwLfBgkcU6sExXUpoluB SIf0Cj2jaj4jz1v2UKi0TsLHxqY8Zlhv7q9EOcOtDnSqyRFSXvZsOIUtqqzDU3Xd aKYI5yEqmseliejbFZCP1nWBvPzuXaegnMuxyoLRp1TUwv796JpTKKwcj4IVq0N4 ioYE8t2ehxNrfYJsyEp8jN0xgD2yUeh5aOwEjbA/78AP3iEO3rCZsmFfANVfSTtI j8ng1+uCrheddZRPGGdJAYJPGzb2S9By+MEmmmzbiQIyI3ydKOVQh9/dnhmXLkf1 N2eLihw9QAVJ7h8JqX7onLvLtIBdyjyGUl52KYZONkaKP7UQv9NiT1xsjwn3HnRU x6hHIvynnTtmb9oGsvqnyp9VC1SsSinmCM8bdJ74rWMe9mU/8E5xtPSew+3FLqvZ JRhWDbidoHFZfxeX0a3o =O7V7 -----END PGP SIGNATURE----- --Apple-Mail=_209770E6-49B7-44E2-A8BA-263CBEE1756E-- From nobody Fri Apr 18 11:06:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB81A0451 for ; Fri, 18 Apr 2014 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynhfISU5E8Sy for ; Fri, 18 Apr 2014 11:06:31 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id A0B3B1A0445 for ; Fri, 18 Apr 2014 11:06:31 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so3345250veb.24 for ; Fri, 18 Apr 2014 11:06:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fcYE544B0rN7vwvI7zYtCPXlnAmdCc0HrgsyeeKmIbo=; b=WYIE3KsH3N4kR9x09pgg+8z6FFoIpgeeWmDfJWoe+bHRpui3iwuGZktQUG6ihcrePq PVLS5046EXTk7ut7eP/Ry7JO5zQnwsBDcsna4ta8EABNAwZKypPysY2NX337gmoph/+j 5wy8ExVgwic/teYpCM6kEn8+eztymNlO9JUIIVhB46hds5e2yiZYrGTCAbuWSUMq80SV bxVakiRpO22wbF7kTTjYVwBy1lCrmmM1Wvx8wD93zvDPwhw0lx+1IHh50f5LRjvivpcd kh9c5fu0I2tQe7ENteV4tfFtsRlKNmVeI3u6gsn4qUq2uSSr2otjAa2xNQk8Aq/gKyD9 uBYQ== X-Gm-Message-State: ALoCoQm08QSkswsPJ2etxGosafrhk8+RmlIV1qJwHi7fxgUxSlTYoauMxPywJ0tEY6jj26rTxAXh X-Received: by 10.58.55.170 with SMTP id t10mr3869182vep.29.1397844387255; Fri, 18 Apr 2014 11:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 11:06:07 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 14:06:07 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zQ8Lr4AqHxvwIUFlmDC-8oZnXKs Cc: Thomas Nadeau , Crabbe Edward , Dean Bogdanovic , "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:06:37 -0000 On Fri, Apr 18, 2014 at 1:36 PM, Andy Bierman wrote: > > > > On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim wrote: >> >> I dont think a post like this is useful. >> State your reasons please - just cheering on is not helpful. >> > > It is as useful as +1, which IMO is useful. > +1 is useful if it points to a technical point - not to "I like the guy with the blue shirt" without saying why. Andy, hate to go over your list and respond to it because that puts you on the defensive and the other thing is i am not sure what part of this is "requirements" for I2RS and what is "excellent things Yang has". Let me try but i worry i will be peppering over probably some of what you may feel are strong statements that need to be emphasized. > Availability of tools is important to developers who intend to implement > I2RS. > > I think there are also some technical reasons to use YANG: > > - YANG is protocol and encoding independent. It can be mapped to a > protocol > fairly easily. It supports XML now. A standards effort to support JSON > encoding > has been started in the NETMOD WG. A proposal to support EXI exists, > and support for CBOR is possible. > As a modelling language so is ForCES. The language is based on XML. The ForCES protocol is tied to the model but the model is not tied to the protocol. > - YANG supports definition of protocol operations, data nodes, and > notification events. > Data nodes are either configuration or non-configuration. XPath is used > to define > validation rules such as 'must' and 'when'. There rules apply differently > to > each context (operation, config data, non-config data, notification). > ForCES model does not support making protocol definitions. There are some basic protocol definitions assumed (GET/SET/DEL etc). Validation of constructs exists by virtue of the data model existing. > - The local config is related to operational state, especially since > operational values may > include configured values. YANG is already being used for configuration. > Using consistent data naming is important. A YANG instance-identifier is > an > absolute-path (restricted XPath) expression. > I think this is the point Tom Petch brought up as being problematic. When you have config and operational info - very likely end up with two subtrees. > - YANG supports external and conditional augmentation of any data model. > Each YANG module defines its own namespace. A module namespace can > be sub-divided with sub-modules. All nodes are identified with QNames, > using the YANG module or namespace as the extended name. This supports > non-centralized naming authority (i.e., vendor A and vendor B can both > augment > the same standard data node without any possibility of naming > collisions.) > ForCES is OO. The main building blocks are Classes known as LFBs. Each class has a name and an ID. While Classes define templates, Class instances are used when refering to components. Classes can be inherited to define new classes. > - YANG "features" allow optional functionality to be defined in a > data-model specific manner. > Conformance advertisement information is standardized so clients know > what options > are supported by each server implementation. > ForCES LFB class has a capability section which is used to advertise features. > - YANG "extensions" allow new language statements to be added to the > language, > These external statements must be parsed by every YANG compiler, even if > the compiler does not understand the extension. This allows YANG to be > easily > adapted for new applications, without the need to revise the language. > ForCES modeling does not have this feature. So while i attempted to address the different points - I am not sure which are requirements and which are not. cheers, jamal > >> jamal > > > Andy > >> >> >> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau >> wrote: >> > >> > Sorry for the top post, but I wanted to inject that for the >> > record, Brocade is in favor of using RestConf/Yang (or variations of those) >> > for I2RS. We have no interest in using FORCES as the basis for this. >> > >> > --Tom >> > >> > >> > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim >> > wrote: >> > >> >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic >> >> wrote: >> >>> Jamal, >> >>> >> >>> Here are two criteria to be considered: >> >>> 1. technical >> >>> 2. commercial/business >> >>> >> >>> We can discuss pros and cons for both, but have to state that from >> >>> business perspective for >> >>> Juniper going with RESTCONF/YANG make more sense. We already built the >> >>> Junos model >> >>> in YANG and have or are in process of building needed tools. >> >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are >> >>> working >> >>> on RESTCONF implementation. >> >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> >>> RESTCONF as well, so >this looks like a low hanging fruit from business >> >>> perspective. >> >>> >> >> >> >> Thanks for being sincere Dean. >> >> First, I will say I empathize with your view above (I understand such >> >> a view is motivation >> >> for many unfortunately often disguised as technical opinion). While i >> >> empathize, I would like >> >> to point that we need to have these discussions which are technical >> >> otherwise there is >> >> no point in having a standard. >> >> In any case I get where you are coming from. >> >> >> >>> Looking at technical aspect, unless there is a very compelling reason >> >>> (and there might be, but I'm >> >>> not aware of it), don't see reason to switch from RESTCONF and YANG. >> >> >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - >> >> I'll start with >> >> 1 or 2 of what i think are requirements against protocol/model so we >> >> dont have to >> >> respond to long emails. If you have issues with ForCES please bring >> >> them up as well >> >> and we can discuss (I brought up a few in my presentation). >> >> >> >> One of the issues was throughput and latency. >> >> You stated in London that you want to be able to do a large amount of >> >> updates/sec. >> >> Other than you - I cant get anyone else to say this is a requirement. >> >> I do believe it is. >> >> It will be useful for example to come up with some hand waving numbers >> >> against >> >> some agreed-to info model (eg the rib) and see how this requirement is >> >> met by the >> >> different protocols. >> >> >> >> As for the model, I'd like to quote from the minutes what Tom Petch >> >> (who i consider to >> >> be a sage in this space): >> >> "If I was writing an info model I'd use YANG every time. But if I was >> >> writing a data >> >> model I'd go for ForCES." >> >> And this is rooted in the nature of Yang being intended for Config. >> >> >> >> There is also the issue of i2rs ability to describe instances which is >> >> lacking in Yang; >> >> but maybe leave that out to a different email.. >> >> >> >> cheers, >> >> jamal >> >> >> >>> We can find out down the line that RESTCONF/YANG was the wrong way to >> >>> go, but that >> >>> can be always changed. From my perspective it looks right today. >> >>> >> >>> Just to be clear, I vote for RESTCONF/YANG adoption for 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 nobody Fri Apr 18 11:18:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DBB1A044C for ; Fri, 18 Apr 2014 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDgLFZ2akh_R for ; Fri, 18 Apr 2014 11:18:49 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85F281A02EB for ; Fri, 18 Apr 2014 11:18:49 -0700 (PDT) X-AuditID: c618062d-f79f66d000001393-3c-53511e13044c Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 64.82.05011.31E11535; Fri, 18 Apr 2014 14:44:03 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 14:18:44 -0400 From: Jeff Tantsura To: Thomas Nadeau , b nitin Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Kz7DmdZ4nBEu9xmRI1UtXUZsXiiYAgAAepgCAACVwgIAAAvcAgAAEOYCAAA3bAIAAD4kA//+UxgA= Date: Fri, 18 Apr 2014 18:18:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_CF76BA895A269jefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyuXRPiK6wXGCwweMfYhaP2+cwWzxcvJHd 4vbWPWwW62Z8YLF4cbaN1WJ272kWiz9vXrFYPJx8id2Bw2PBplKPpxMOMnksWfKTyeN601V2 j61PlrB7bLu1ltVj9uvrrB6zZh1mCuCI4rJJSc3JLEst0rdL4Mq4/OEYW8EWy4qdT7YxNzBu M+pi5OCQEDCReDXBoouRE8gUk7hwbz1bFyMXh5DAUUaJD/MmQTnLGSXu/t3MCFLFJmAg8f/b cRYQW0TAT+Lj/XesIEXMAncYJdbOuc0EkhAWsJBY2bmDHaLIUuLysl9MEHaSxL6vL8CaWQRU JSZcO8sGYvMKmEtMf38KrEZIIEeirW0SWC+ngLPEmVVLwGoYgc77fmoNWA2zgLjErSfzmSDO FpBYsuc8M4QtKvHy8T9WEFtUQE/i3qO5LBBxJYk5r68xQ/TGSMzdfY4ZYq+gxMmZT1gmMIrN QjJ2FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwGKrXWqJ1y19WZDULGDlWMXKUFqeW5aYb GWxiBEb/MQk23R2Me15aHmIU4GBU4uGdct03WIg1say4MvcQozQHi5I475e3zkFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGFVE9y2Plf0bml/hfGxR1qcp++Wy+yds2cvwoaL6x0wOy9dv u6xOHSlVPP/x3d3ejSXhR8RK/lv4undVlfQ1J2688v/42xltSQ7djG+5LLo//CrwuHf4r+mS G9t2e1vMXV+46/vMd+3NuQ4eYiYb5L673/tyatONbbkftxy3u2c94TPvwziZ7jVKLMUZiYZa zEXFiQAkg7GX3wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4LjOR9wLvAjpl88iFq0aQ6y4sUw Cc: "i2rs@ietf.org" , Crabbe Edward , Jamal Hadi Salim , Dean Bogdanovic , "sarikaya@ieee.org" , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:18:54 -0000 --_000_CF76BA895A269jefftantsuraericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here Cheers, Jeff From: Thomas Nadeau > Date: Friday, April 18, 2014 10:42 AM To: b nitin > Cc: "i2rs@ietf.org" >, Crabbe Edward >, Jamal Hadi Sal= im >, Dean Bogdanovic >, "sarikaya@ieee.org" >, Susan Hares > Subject: Re: [i2rs] consensus on I2RS protocol and model On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur > wrote: If the study showed that OF-Config did not meet the requirements, that is f= ine but I heard no one said that. On Feb 5th, Alia Atlas said: http://www.ietf.org/mail-archive/web/i2rs/curr= ent/msg01243.html > Gap Analysis for different Protocols: I2RS needs to select a protocol to= use. I believe that we have volunteers for discussing RESTCONF. > We'd welcome hearing from others who can provide at least a presentation = for review before IETF and preferably a quick draft as well. On Feb 27th, Ed Crabbe said: http://www.ietf.org/mail-archive/web/i2rs/curr= ent/msg01291.html > The I2RS agenda has been posted. Those who think OF-Config should have been a candidate, should have present= ed at the IETF; or at least started a discussion on the mailing list. My 2 cents Nitin I agree %100 with your 2 cents. --Tom _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_CF76BA895A269jefftantsuraericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F43F58FC1A86B41A4DD2E8CB62ED432@ericsson.com> Content-Transfer-Encoding: quoted-printable
Same here

Cheers,
Jeff

From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Friday, April 18, 2014 10:42 = AM
To: b nitin <nitin_bahadur@yahoo.com>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>, Crabbe Edward <edc@go= ogle.com>, Jamal Hadi Salim <hadi@mojatatu.com>, Dean Bogdanovic <deanb@juniper.net= >, "sarikaya@ieee.org&= quot; <sarikaya@ieee.org>, S= usan Hares <shares@ndzh.com> Subject: Re: [i2rs] consensus on I2= RS protocol and model


On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur <nitin_bahadur@yahoo.com> wrote:



If the study showed that OF-Config did not meet the requirements, that= is fine but I heard no one said that.


> Gap Analysis for different Protocols:  I2RS needs to select = a protocol to use.  I believe that we have volunteers for discussing R= ESTCONF. 
> We'd welcome hearing from others who can provide at least a prese= ntation for review before IETF and preferably a quick draft as well.

> The I2RS agenda has been posted.  

Those who think OF-Config should have been a candidate, should have pr= esented at the IETF; or at least started a discussion on the mailing list.<= /div>

My 2 cents
Nitin

I agre= e %100 with your 2 cents.

--Tom<= /div>


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

 --_000_CF76BA895A269jefftantsuraericssoncom_-- From nobody Fri Apr 18 11:22:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DDF1A043F for ; Fri, 18 Apr 2014 11:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNpK2jDUuqbe for ; Fri, 18 Apr 2014 11:22:15 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id A787F1A041A for ; Fri, 18 Apr 2014 11:22:15 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so3454274veb.18 for ; Fri, 18 Apr 2014 11:22:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=0NiHuwhrSelZQ30kUpE6MRe6kUcL1ZT/YyUMWZ507Tk=; b=A3BiifIczMSxhaBzu9sLAZ5GawuErm8unsZpR3lgu5bG+MrTmEqmHkwLKm8ptPrtjD TWfZFaPeGun5PFS7pfg7L/4KhNXYImeAl4LwZg/GBMcI589Vokepxt3zFCeMYisvkQsW POyZ+tFhp4Tkui+yVD5sX1/JnBEAGeFONha/bg77wJIV2Vg+125+HCeW+uc6rXMUbjGb I6IBcoshcTIcIiMcEo1H9uEcnH7SfSaXluHiTpFZ7Mk9dIL3tYYD0abaVbkJTMDtrmvS GO6h28usRmpUd3Q7XoU7xY1BCeFUVU+IuIcFqMKOfo8kDaNpPtHI1yN8On52PIC1HCqW iS6A== X-Gm-Message-State: ALoCoQn1/jz7hx6J2aDXBtVYPBwKVO8sniE9rWZ+Ed7vfufyjr+L0AuxRrZhnSBC9gsBPyAShBX9 X-Received: by 10.52.78.231 with SMTP id e7mr12391721vdx.28.1397845331514; Fri, 18 Apr 2014 11:22:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 11:21:51 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 14:21:51 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QbFmFTaBKa7LjpVoYifPOKd2GCo Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:22:17 -0000 On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau wr= ote: > > Why is that not useful? Because I didn't say I was in favor of fo= rces? *) Not at all. Your statement was more like a high five. It is ok to raise your hand at the meeting - but i was hoping the list would have more useful technical discussion. >It IS useful to say that my company's products implement Yang/Netconf and = will support RestConf, >and therefore a derivative of those technologies us= ed for i2rs is preferred. We have no plans to >support any of the other dis= cussed options in i2rs such as Forces at this time. The reasons are >simpl= e: our customers asked for Netconf/Yang models and as far as I can tell, ha= ve no interest in >Forces. > So again it boils down to "bussiness" reasons - am i wrong? "we have an implementation of Yang/netconf"; "we are going to make it work for I2RS". If thats the case - then lets just end the discussion. I am hoping to get the answer to: What are the technical requirements/arguements? Why do i have to struggle so much in a technical environment like IETF for someone to come out and say what the requirements are? I can assure you that i have no religious conviction that say it has to be ForCES. Lets actually start with you showing me how netconf/yang meets the requirem= ents. Otherwise - please stop with the high fives. > From my perspective, continuing to debate which protocol is deriv= ed to become i2rs is a waste >of everyone's time. Whats the point to having a circus show in pretending we are trying to get any consensus? >Its clear what people want from the meeting, and if you poll interested im= plementations you'll likely >get the same answer: yang/netconf/restconf. L= ets please stop delaying i2rs and get some work >done here. > When you go and ask people to raise their hands they will. You need to ask them why they are raising their hands. I am hoping this is not a staked popularity contest. cheers, jamal From nobody Fri Apr 18 11:30:30 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870531A02D4 for ; Fri, 18 Apr 2014 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsAjzQ4cMdC4 for ; Fri, 18 Apr 2014 11:30:24 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 252721A0220 for ; Fri, 18 Apr 2014 11:30:24 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id F3B15276EED8; Fri, 18 Apr 2014 14:30:19 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6C2AB188-C395-45D4-B33B-F0F8729AC2F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 14:30:19 -0400 Message-Id: <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E6bQ7jIZa0lYHYq1GG8ZjPwGDIw Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:30:28 -0000 --Apple-Mail=_6C2AB188-C395-45D4-B33B-F0F8729AC2F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim = wrote: > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau = wrote: >>=20 >> Why is that not useful? Because I didn't say I was in favor of = forces? *) >=20 > Not at all. Your statement was more like a high five. It is ok to > raise your hand at > the meeting - but i was hoping the list would have more useful > technical discussion. >=20 >> It IS useful to say that my company's products implement Yang/Netconf = and will support RestConf, >and therefore a derivative of those = technologies used for i2rs is preferred. We have no plans to >support = any of the other discussed options in i2rs such as Forces at this time. = The reasons are >simple: our customers asked for Netconf/Yang models and = as far as I can tell, have no interest in >Forces. >>=20 >=20 > So again it boils down to "bussiness" reasons - am i wrong? Yes, but not in the way you imply. My company has implemented = Yang/Netconf because our customers have asked us to and because when we = did, they bought our equipment - not as you imply, because we think its = cool. There are a number of other major hardware vendors on this list = that have done the same. I think if you poll most of those vendors, you = will find that they generally don't engineering resources to things = that people don't buy. Also, Open Daylight has gone with = Netconf/Yang/RestConf as one of its primary interfaces - there are = dozens of vendors working on that project too. As far as I can tell, no = one has done any programmable interface based on Forces there. That = seems to be an overwhelming number of implementations that have gone = with yang/netconf/restconf.=20 > "we have an implementation of Yang/netconf"; > "we are going to make it work for I2RS". > If thats the case - then lets just end the discussion. > I am hoping to get the answer to: > What are the technical requirements/arguements? > Why do i have to struggle so much in a technical environment like IETF = for > someone to come out and say what the requirements are? >=20 > I can assure you that i have no religious conviction that say it has > to be ForCES. > Lets actually start with you showing me how netconf/yang meets the = requirements. > Otherwise - please stop with the high fives. >=20 >> =46rom my perspective, continuing to debate which protocol is = derived to become i2rs is a waste >of everyone's time. >=20 > Whats the point to having a circus show in pretending we are trying to > get any consensus? I am not WG chair, so I will let Ed/Jeff comment on the circus. = *) > Its clear what people want from the meeting, and if you poll = interested implementations you'll likely >get the same answer: = yang/netconf/restconf. Lets please stop delaying i2rs and get some work = >done here. >>=20 >=20 > When you go and ask people to raise their hands they will. You need to > ask them why > they are raising their hands. I am hoping this is not a staked > popularity contest. Well, at some point it does come down to running code and real, = deployed implementations, right? As I said above, there are many real = and significant implementations of yang/netconf in the marketplace = *today*. Asking those things to be modified slightly isn't that big of a = deal in order to address the requirements. Implementing a completely new = protocol is. I am not totally against new protocols - its just that if = we can achieve the goals we have by hacking an existing implementation, = that makes better engineering and business sense.=20 --Tom >=20 >=20 > cheers, > jamal >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_6C2AB188-C395-45D4-B33B-F0F8729AC2F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUW87AAoJEPcO+I7eiUJZLLEP/ReSuHlyl4uPQ+k//yjs67R4 hqHvr6OqC5gaVQPYw3Wn8PU38F/x2AJBpVnZBahDhGactUcgOmzczpcU3JhSeSSQ rfyMYHSAkiaNmJjsLbdME4J7p4ZEmEeq/WedIYUY2CA+97IuKychn4YD82T3rZKp KPW2vlUnYk2wjMPJoW4cl204nl/Q+04eEcSqP8dXX8qUTVz/HNJSo0FnPtAfIQqc JrlJXmNt49ehGOI7u6892/7qWuS6yzmbstOz4TkQa6twQis535szu8kd8ZQJcZ4F 25MLxpExJWrl4GNlH05i/XvffyX3abx+mk7x8USxVpMBbIdRpEAspOswf3amEFzF mnCw4VY/f6h6jrZc8F+9AGqbCw0kIcqWvogiizRIjgGiuWyabtJ5TaCKrY8X1Jz7 XwJbxx7w8MYfYbgSqvfNnFGwmQzORfFJAluxI5cCJRDcdAbepCht68c5YvsXAdfu oXo3A1icJTPYBA2l18qO8thzws/9Y8fWjYY+CoDKLRV9eGeop7ZA6Dqmv02TSn5/ eYQmRNBPboDy1kJQPQsVM60rZgRzXV+bttZzdpqdaerE2Z4gQ2eUqkiZXswp8GSM Tv8HNlbveK+3E8VDZpYpNnP3zY8MCyvZDrbcVIMMpxF5PhR9XFqUyGj7TU7+Xf6C glJNKzF3kvAZE71LHj0P =OZYM -----END PGP SIGNATURE----- --Apple-Mail=_6C2AB188-C395-45D4-B33B-F0F8729AC2F0-- From nobody Fri Apr 18 11:32:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320A1A0468 for ; Fri, 18 Apr 2014 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LwtN-axy63g for ; Fri, 18 Apr 2014 11:32:26 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id 913201A0454 for ; Fri, 18 Apr 2014 11:32:26 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so1199745qga.22 for ; Fri, 18 Apr 2014 11:32:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qxbFMv6BOT6CMjagd9g3nbfD6UHRsTV2ayubCKiWCUs=; b=cvNWa64NR/RIeoMRqL6BCAgFoC833tMh7IP4+uZDRIAwOBT5PM3K/gUdp4zb2vFATD lajnAW/7jP624MKdYC2/4/A5iiT1YfnN1De6BRXLnNdjL/eJFIxxjnea1fGDiJER0kyl NL8drAEQUHouBcKb2kS3vwO5AJ46RRV08whP6vhqc0mCeujgGaZrL95xhchyOHGup5W1 j/YfYrEWGvuCvfzsvL9HB4ZxZVA7JHmg/NZDWyQ+LDfZ0itdrdrnPjhNbS/HlEzMmvTT Ga4mLKa4pN4q3QGeoOOQWSxCaZ9N34Q+MUMUlWtah5kjtnuCR/2dNFV1yZO2MYCopBhy eq1A== X-Gm-Message-State: ALoCoQnIYxIjXnVPV3796IOSq3w9fT/g+p28sIkcBHuAYbYNC/KID3xflIfjc456M30NjILuWPSt MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr8498625qge.34.1397845942286; Fri, 18 Apr 2014 11:32:22 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 18 Apr 2014 11:32:22 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> Date: Fri, 18 Apr 2014 11:32:22 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a113abfd8d7a89204f7555e1b Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E05OTIEJbmd73La5N9E4e_uirj4 Cc: Thomas Nadeau , Crabbe Edward , Dean Bogdanovic , "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:32:31 -0000 --001a113abfd8d7a89204f7555e1b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 18, 2014 at 11:06 AM, Jamal Hadi Salim wrote: > On Fri, Apr 18, 2014 at 1:36 PM, Andy Bierman wrote: > > > > > > > > On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim > wrote: > >> > >> I dont think a post like this is useful. > >> State your reasons please - just cheering on is not helpful. > >> > > > > It is as useful as +1, which IMO is useful. > > > > +1 is useful if it points to a technical point - not to "I like the > guy with the blue > shirt" without saying why. > I guess I knew that Brocade already uses YANG, and inferred that what was Tom meant. > > Andy, hate to go over your list and respond to it because that puts you > on the defensive and the other thing is i am not sure what part of this > is "requirements" for I2RS and what is "excellent things Yang has". > Let me try but i worry i will be peppering over probably some of what > you may feel are strong statements that need to be emphasized. > > You stated that YANG only does config, which is incorrect. It may be useful for people have not bothered to read either YANG or ForCES RFCs to understand more about both. But at a certain point it gets to be like debating programming languages. Much of it is subjective, based on the preferences, tools, training, etc., of the people who will be writing the code. Andy > Availability of tools is important to developers who intend to implement > > I2RS. > > > > I think there are also some technical reasons to use YANG: > > > > - YANG is protocol and encoding independent. It can be mapped to a > > protocol > > fairly easily. It supports XML now. A standards effort to support > JSON > > encoding > > has been started in the NETMOD WG. A proposal to support EXI exists, > > and support for CBOR is possible. > > > > As a modelling language so is ForCES. The language is based on XML. > The ForCES protocol is tied to the model but the model is not tied to the > protocol. > > > - YANG supports definition of protocol operations, data nodes, and > > notification events. > > Data nodes are either configuration or non-configuration. XPath is > used > > to define > > validation rules such as 'must' and 'when'. There rules apply > differently > > to > > each context (operation, config data, non-config data, notification). > > > > ForCES model does not support making protocol definitions. There are some > basic > protocol definitions assumed (GET/SET/DEL etc). > Validation of constructs exists by virtue of the data model existing. > > > > - The local config is related to operational state, especially since > > operational values may > > include configured values. YANG is already being used for > configuration. > > Using consistent data naming is important. A YANG instance-identifier > is > > an > > absolute-path (restricted XPath) expression. > > > > I think this is the point Tom Petch brought up as being problematic. > When you have > config and operational info - very likely end up with two subtrees. > > > - YANG supports external and conditional augmentation of any data model. > > Each YANG module defines its own namespace. A module namespace can > > be sub-divided with sub-modules. All nodes are identified with > QNames, > > using the YANG module or namespace as the extended name. This supports > > non-centralized naming authority (i.e., vendor A and vendor B can both > > augment > > the same standard data node without any possibility of naming > > collisions.) > > > > ForCES is OO. The main building blocks are Classes known as LFBs. > Each class has a name and an ID. > While Classes define templates, Class instances are used when refering > to components. > Classes can be inherited to define new classes. > > > - YANG "features" allow optional functionality to be defined in a > > data-model specific manner. > > Conformance advertisement information is standardized so clients know > > what options > > are supported by each server implementation. > > > > ForCES LFB class has a capability section which is used to advertise > features. > > > - YANG "extensions" allow new language statements to be added to the > > language, > > These external statements must be parsed by every YANG compiler, even > if > > the compiler does not understand the extension. This allows YANG to > be > > easily > > adapted for new applications, without the need to revise the language. > > > > ForCES modeling does not have this feature. > > So while i attempted to address the different points - I am not sure which > are requirements and which are not. > > cheers, > jamal > > > >> jamal > > > > > > Andy > > > >> > >> > >> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau < > tnadeau@lucidvision.com> > >> wrote: > >> > > >> > Sorry for the top post, but I wanted to inject that for the > >> > record, Brocade is in favor of using RestConf/Yang (or variations of > those) > >> > for I2RS. We have no interest in using FORCES as the basis for this. > >> > > >> > --Tom > >> > > >> > > >> > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim > >> > wrote: > >> > > >> >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic > >> >> wrote: > >> >>> Jamal, > >> >>> > >> >>> Here are two criteria to be considered: > >> >>> 1. technical > >> >>> 2. commercial/business > >> >>> > >> >>> We can discuss pros and cons for both, but have to state that from > >> >>> business perspective for > >> >>> Juniper going with RESTCONF/YANG make more sense. We already built > the > >> >>> Junos model > >> >>> in YANG and have or are in process of building needed tools. > >> >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are > >> >>> working > >> >>> on RESTCONF implementation. > >> >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into > >> >>> RESTCONF as well, so >this looks like a low hanging fruit from > business > >> >>> perspective. > >> >>> > >> >> > >> >> Thanks for being sincere Dean. > >> >> First, I will say I empathize with your view above (I understand such > >> >> a view is motivation > >> >> for many unfortunately often disguised as technical opinion). While i > >> >> empathize, I would like > >> >> to point that we need to have these discussions which are technical > >> >> otherwise there is > >> >> no point in having a standard. > >> >> In any case I get where you are coming from. > >> >> > >> >>> Looking at technical aspect, unless there is a very compelling > reason > >> >>> (and there might be, but I'm > >> >>> not aware of it), don't see reason to switch from RESTCONF and YANG. > >> >> > >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - > >> >> I'll start with > >> >> 1 or 2 of what i think are requirements against protocol/model so we > >> >> dont have to > >> >> respond to long emails. If you have issues with ForCES please bring > >> >> them up as well > >> >> and we can discuss (I brought up a few in my presentation). > >> >> > >> >> One of the issues was throughput and latency. > >> >> You stated in London that you want to be able to do a large amount of > >> >> updates/sec. > >> >> Other than you - I cant get anyone else to say this is a requirement. > >> >> I do believe it is. > >> >> It will be useful for example to come up with some hand waving > numbers > >> >> against > >> >> some agreed-to info model (eg the rib) and see how this requirement > is > >> >> met by the > >> >> different protocols. > >> >> > >> >> As for the model, I'd like to quote from the minutes what Tom Petch > >> >> (who i consider to > >> >> be a sage in this space): > >> >> "If I was writing an info model I'd use YANG every time. But if I > was > >> >> writing a data > >> >> model I'd go for ForCES." > >> >> And this is rooted in the nature of Yang being intended for Config. > >> >> > >> >> There is also the issue of i2rs ability to describe instances which > is > >> >> lacking in Yang; > >> >> but maybe leave that out to a different email.. > >> >> > >> >> cheers, > >> >> jamal > >> >> > >> >>> We can find out down the line that RESTCONF/YANG was the wrong way > to > >> >>> go, but that > >> >>> can be always changed. From my perspective it looks right today. > >> >>> > >> >>> Just to be clear, I vote for RESTCONF/YANG adoption for 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 > > > > > --001a113abfd8d7a89204f7555e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 18, 2014 at 11:06 AM, Jamal Hadi Salim <hadi@mojatatu.= com> wrote:
On Fri, Apr 18, 2014 at 1:36 PM, Andy Bierma= n <andy@yumaworks.com> wrot= e:
>
>
>
> On Fri, Apr 18, 2014 at 9:02 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>>
>> I dont think a post like this is useful.
>> State your reasons please - just cheering on is not helpful.
>>
>
> It is as useful as +1, which IMO is useful.
>

+1 is useful if it points to a technical point - not to "I like the guy with the blue
shirt" without saying why.

I guess= I knew that Brocade already uses YANG, and inferred that
what wa= s Tom meant.
=A0

Andy, hate to go over your list and respond to it because that puts you
on the defensive and the other thing is i am not sure what part of this
is "requirements" for I2RS and what is "excellent things Yan= g has".
Let me try but i worry i will be peppering over probably some of what
you may feel are strong statements that need to be emphasized.


You stated that YANG only does config,= which is incorrect.
It may be useful for people have not bothere= d to read either
YANG or ForCES RFCs to understand more about bot= h.

But at a certain point it gets to be like debating prog= ramming languages.
Much of it is subjective, based on the prefere= nces, tools, training, etc.,
of the people who will be writing th= e code.



Andy

=

> Availability of tools is important to developers who intend to impleme= nt
> I2RS.
>
> I think there are also some technical reasons to use YANG:
>
> =A0 - YANG is protocol and encoding independent. It can be mapped to a=
> protocol
> =A0 =A0 fairly easily. =A0It supports XML now. A standards effort to s= upport JSON
> encoding
> =A0 =A0 has been started in the NETMOD WG. =A0A proposal to support EX= I exists,
> and support for CBOR is possible.
>

As a modelling language so is ForCES. The language is based on XML.
The ForCES protocol is tied to the model but the model is not tied to the protocol.

> =A0- YANG supports definition of protocol operations, data nodes, and<= br> > notification events.
> =A0 =A0Data nodes are either configuration or non-configuration. XPath= is used
> to define
> =A0 =A0validation rules such as 'must' and 'when'. The= re rules apply differently
> to
> =A0 =A0each context (operation, config data, non-config data, notifica= tion).
>

ForCES model does not support making protocol definitions. There are some b= asic
protocol definitions assumed (GET/SET/DEL etc).
Validation of constructs exists by virtue of the data model existing.


> =A0- The local config is related to operational state, especially sinc= e
> operational values may
> =A0 =A0include configured values. =A0YANG is already being used for co= nfiguration.
> =A0 =A0Using consistent data naming is important. A YANG instance-iden= tifier is
> an
> =A0 =A0absolute-path (restricted XPath) expression.
>

I think this is the point Tom Petch brought up as being problematic.
When you have
config and operational info - very likely end up with two subtrees.

> =A0- YANG supports external and conditional augmentation of any data m= odel.
> =A0 =A0Each YANG module defines its own namespace. =A0A module namespa= ce can
> =A0 =A0be sub-divided with sub-modules. =A0All nodes are identified wi= th QNames,
> =A0 =A0using the YANG module or namespace as the extended name. This s= upports
> =A0 =A0non-centralized naming authority (i.e., vendor A and vendor B c= an both
> augment
> =A0 =A0the same standard data node without any possibility of naming > collisions.)
>

ForCES is OO. The main building blocks are Classes known as LFBs.
Each class has a name and an ID.
While Classes define templates, Class instances are used when refering
to components.
Classes can be inherited to define new classes.

> =A0- YANG "features" allow optional functionality to be defi= ned in a
> data-model specific manner.
> =A0 =A0Conformance advertisement information is standardized so client= s know
> what options
> =A0 =A0are supported by each server implementation.
>

ForCES LFB class has a capability section which is used to advertise featur= es.

> =A0- YANG "extensions" allow new language statements to be a= dded to the
> language,
> =A0 =A0These external statements must be parsed by every YANG compiler= , even if
> =A0 =A0the compiler does not understand the extension. =A0This allows = YANG to be
> easily
> =A0 =A0adapted for new applications, without the need to revise the la= nguage.
>

ForCES modeling does not have this feature.

So while i attempted to address the different points - I am not sure which<= br> are requirements and which are not.

cheers,
jamal
>
>> jamal
>
>
> Andy
>
>>
>>
>> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <tnadeau@lucidvision.com>
>> wrote:
>> >
>> > =A0 =A0 =A0 =A0 Sorry for the top post, but I wanted to injec= t that for the
>> > record, Brocade is in favor of using RestConf/Yang (or variat= ions of those)
>> > for I2RS. We have no interest in using FORCES as the basis fo= r this.
>> >
>> > =A0 =A0 =A0 =A0 --Tom
>> >
>> >
>> > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim
>> > <hadi@mojatatu.com> wrote:
>> >
>> >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic <deanb@juniper.net>
>> >> wrote:
>> >>> Jamal,
>> >>>
>> >>> Here are two criteria to be considered:
>> >>> 1. technical
>> >>> 2. commercial/business
>> >>>
>> >>> We can discuss pros and cons for both, but have to st= ate that from
>> >>> business perspective for
>> >>> Juniper going with RESTCONF/YANG make more sense. We = already built the
>> >>> Junos model
>> >>> in YANG and have or are in process of building needed= tools.
>> >>> Same goes for RESTCONF. We have NETCONF implemented i= n Junos and are
>> >>> working
>> >>> on RESTCONF implementation.
>> >>> Many carriers adopted or are adopting NETCONF/YANG, a= re looking into
>> >>> RESTCONF as well, so >this looks like a low hangin= g fruit from business
>> >>> perspective.
>> >>>
>> >>
>> >> Thanks for being sincere Dean.
>> >> First, I will say I empathize with your view above (I und= erstand such
>> >> a view is motivation
>> >> for many unfortunately often disguised as technical opini= on). While i
>> >> empathize, I would like
>> >> to point that we need to have these discussions which are= technical
>> >> otherwise there is
>> >> no point in having a standard.
>> >> In any case I get where you are coming from.
>> >>
>> >>> Looking at technical aspect, unless there is a very c= ompelling reason
>> >>> (and there might be, but I'm
>> >>> not aware of it), don't see reason to switch from= RESTCONF and YANG.
>> >>
>> >> Maybe we'll bring up the topics sequentially as the t= hread proceeds -
>> >> I'll start with
>> >> 1 or 2 of what i think are requirements against protocol/= model so we
>> >> dont have to
>> >> respond to long emails. If you have issues with ForCES pl= ease bring
>> >> them up as well
>> >> and we can discuss (I brought up a few in my presentation= ).
>> >>
>> >> One of the issues was throughput and latency.
>> >> You stated in London that you want to be able to do a lar= ge amount of
>> >> updates/sec.
>> >> Other than you - I cant get anyone else to say this is a = requirement.
>> >> I do believe it is.
>> >> It will be useful for example to come up with some hand w= aving numbers
>> >> against
>> >> some agreed-to info model (eg the rib) and see how this r= equirement is
>> >> met by the
>> >> different protocols.
>> >>
>> >> As for the model, I'd like to quote from the minutes = what Tom Petch
>> >> (who i =A0consider to
>> >> be a sage in this space):
>> >> "If I was writing an info model I'd use YANG eve= ry time. =A0But if I was
>> >> writing a data
>> >> model I'd go for ForCES."
>> >> And this is rooted in the nature of Yang being intended f= or Config.
>> >>
>> >> There is also the issue of i2rs ability to describe insta= nces which is
>> >> lacking in Yang;
>> >> but maybe leave that out to a different email..
>> >>
>> >> cheers,
>> >> jamal
>> >>
>> >>> We can find out down the line that RESTCONF/YANG was = the wrong way to
>> >>> go, but that
>> >>> can be always changed. From my perspective it looks r= ight today.
>> >>>
>> >>> Just to be clear, I vote for RESTCONF/YANG adoption f= or 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
>
>

--001a113abfd8d7a89204f7555e1b-- From nobody Fri Apr 18 11:37:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67C01A0220 for ; Fri, 18 Apr 2014 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv34r9ji5a_h for ; Fri, 18 Apr 2014 11:37:17 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 39ACD1A02D4 for ; Fri, 18 Apr 2014 11:37:17 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so1943423qcx.24 for ; Fri, 18 Apr 2014 11:37:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4tsF+866JOSNf818Sgf1sHIWUUQWU8+jxcddW0MJXSI=; b=Mlp/8ISspHPZRDumKWdN7pwMiNO306P9BFk7AyVlheh02zQxftbd/W4O+ZqUSWyU73 zwyA1xG1VYoRytqDxke+dXN0RNIY7AkCqCH1Ia4VCDDHgp5Czgf2K+in43alKwlSbZCr kUpu20T+an/IwSd9R1UuJ8iwyVeymEPoeH4VjUwXFIpl/IveMqdK3rNYbPl9us4bgKS9 Bu1Lzqso7Tf2y+KgJ4DqHOIcPzBh1noaTwmaxK0JH46wq6wFlbzON2LZhhZ1sjpJdHav 1CuJwdAJmUIyPu0KQvAx8dcHKNanvxQxKuNiTFXaDN/7bMwDUfmdGN2R25TVu6gR2VxA raWw== X-Gm-Message-State: ALoCoQke2KANZ8rspQRY13Wpz9meQJIwy7QyrnF8RsVhptwnOVg/aiIThusxJI2J0UUGiJ6Gjb82 MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr8524130qge.34.1397846232920; Fri, 18 Apr 2014 11:37:12 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Fri, 18 Apr 2014 11:37:12 -0700 (PDT) In-Reply-To: <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> Date: Fri, 18 Apr 2014 11:37:12 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: multipart/alternative; boundary=001a113abfd829f7af04f755707e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lBbpPCZye0s5k8ormGE_7B8roaA Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:37:21 -0000 --001a113abfd829f7af04f755707e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau wrote: > > On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim > wrote: > > > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau > wrote: > >> > >> Why is that not useful? Because I didn't say I was in favor of > forces? *) > > > > Not at all. Your statement was more like a high five. It is ok to > > raise your hand at > > the meeting - but i was hoping the list would have more useful > > technical discussion. > > > >> It IS useful to say that my company's products implement Yang/Netconf > and will support RestConf, >and therefore a derivative of those > technologies used for i2rs is preferred. We have no plans to >support any > of the other discussed options in i2rs such as Forces at this time. The > reasons are >simple: our customers asked for Netconf/Yang models and as far > as I can tell, have no interest in >Forces. > >> > > > > So again it boils down to "bussiness" reasons - am i wrong? > > Yes, but not in the way you imply. My company has implemented > Yang/Netconf because our customers have asked us to and because when we > did, they bought our equipment - not as you imply, because we think its > cool. There are a number of other major hardware vendors on this list that > have done the same. I think if you poll most of those vendors, you will > find that they generally don't engineering resources to things that people > don't buy. Also, Open Daylight has gone with Netconf/Yang/RestConf as one > of its primary interfaces - there are dozens of vendors working on that > project too. As far as I can tell, no one has done any programmable > interface based on Forces there. That seems to be an overwhelming number > of implementations that have gone with yang/netconf/restconf. > > It would be just as valid for people to chime in "We already use ForCES" or "we use already OF-Config", as a reason to use it for I2RS. Andy > "we have an implementation of Yang/netconf"; > > "we are going to make it work for I2RS". > > If thats the case - then lets just end the discussion. > > I am hoping to get the answer to: > > What are the technical requirements/arguements? > > Why do i have to struggle so much in a technical environment like IETF > for > > someone to come out and say what the requirements are? > > > > I can assure you that i have no religious conviction that say it has > > to be ForCES. > > Lets actually start with you showing me how netconf/yang meets the > requirements. > > Otherwise - please stop with the high fives. > > > >> From my perspective, continuing to debate which protocol is > derived to become i2rs is a waste >of everyone's time. > > > > Whats the point to having a circus show in pretending we are trying to > > get any consensus? > > I am not WG chair, so I will let Ed/Jeff comment on the circus. *) > > > Its clear what people want from the meeting, and if you poll interested > implementations you'll likely >get the same answer: yang/netconf/restconf. > Lets please stop delaying i2rs and get some work >done here. > >> > > > > When you go and ask people to raise their hands they will. You need to > > ask them why > > they are raising their hands. I am hoping this is not a staked > > popularity contest. > > Well, at some point it does come down to running code and real, > deployed implementations, right? As I said above, there are many real and > significant implementations of yang/netconf in the marketplace *today*. > Asking those things to be modified slightly isn't that big of a deal in > order to address the requirements. Implementing a completely new protocol > is. I am not totally against new protocols - its just that if we can > achieve the goals we have by hacking an existing implementation, that makes > better engineering and business sense. > > --Tom > > > > > > > > > cheers, > > jamal > > > > _______________________________________________ > > 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 > > --001a113abfd829f7af04f755707e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau &= lt;tnadeau@luc= idvision.com> wrote:

On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:
>>
>> =A0 =A0 =A0 =A0Why is that not useful? Because I didn't say I = was in favor of forces? *)
>
> Not at all. Your statement was more like a high five. It is ok to
> raise your hand at
> the meeting - but i was hoping the list would have more useful
> technical discussion.
>
>> It IS useful to say that my company's products implement Yang/= Netconf and will support RestConf, >and therefore a derivative of those = technologies used for i2rs is preferred. We have no plans to >support an= y of the other discussed options in i2rs such as Forces at this time. =A0Th= e reasons are >simple: our customers asked for Netconf/Yang models and a= s far as I can tell, have no interest in >Forces.
>>
>
> So again it boils down to "bussiness" reasons - am i wrong?<= br>
=A0 =A0 =A0 =A0 Yes, but not in the way you imply. My company has implement= ed Yang/Netconf because our customers have asked us to and because when we = did, they bought our equipment - not as you imply, because we think its coo= l. There are a number of other major hardware vendors on this list that hav= e done the same. I think if you poll most of those vendors, you will find t= hat they generally don't =A0engineering resources to things that people= don't buy. =A0Also, Open Daylight has gone with Netconf/Yang/RestConf = as one of its primary interfaces - there are dozens of vendors working on t= hat project too. =A0As far as I can tell, no one has done any programmable = interface based on Forces there. =A0That seems to be an overwhelming number= of implementations that have gone with yang/netconf/restconf.


It would be just as valid for people t= o chime in "We already use ForCES"
or "we use alre= ady OF-Config", as a reason to use it for I2RS.


Andy

> "we have an implementation of Yang/netconf";
> "we are going to make it work for I2RS".
> If thats the case - then lets just end the discussion.
> I am hoping to get the answer to:
> What are the technical requirements/arguements?
> Why do i have to struggle so much in a technical environment like IETF= for
> someone to come out and say what the requirements are?
>
> I can assure you that i have no religious conviction that say it has > to be =A0ForCES.
> Lets actually start with you showing me how netconf/yang meets the req= uirements.
> Otherwise - please stop with the high fives.
>
>> =A0 =A0 =A0 =A0From my perspective, continuing to debate which pro= tocol is derived to become i2rs is a waste >of everyone's time.
>
> Whats the point to having a circus show in pretending we are trying to=
> get any consensus?

=A0 =A0 =A0 =A0 I am not WG chair, so I will let Ed/Jeff comment on the cir= cus. *)

> Its clear what people want from the meeting, and if you poll intereste= d implementations you'll likely >get the same answer: yang/netconf/r= estconf. =A0Lets please stop delaying i2rs and get some work >done here.=
>>
>
> When you go and ask people to raise their hands they will. You need to=
> ask them why
> they are raising their hands. I am hoping this is not a staked
> popularity contest.

=A0 =A0 =A0 =A0 Well, at some point it does come down to running code and r= eal, deployed implementations, right? =A0As I said above, there are many re= al and significant implementations of yang/netconf in the marketplace *toda= y*. Asking those things to be modified slightly isn't that big of a dea= l in order to address the requirements. Implementing a completely new proto= col is. I am not totally against new protocols - its just that if we can ac= hieve the goals we have by hacking an existing implementation, that makes b= etter engineering and business sense.

=A0 =A0 =A0 =A0 --Tom



>
>
> cheers,
> jamal
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>


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


--001a113abfd829f7af04f755707e-- From nobody Fri Apr 18 11:43:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70501A043F for ; Fri, 18 Apr 2014 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-A7TkZiRTV6 for ; Fri, 18 Apr 2014 11:43:33 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E58E71A0401 for ; Fri, 18 Apr 2014 11:43:32 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C1ACE276EF73; Fri, 18 Apr 2014 14:43:28 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D444EB86-C44A-4129-9A5C-D2F6DAFFC322"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 18 Apr 2014 14:43:27 -0400 Message-Id: <3B9BF234-1E42-4DBA-BE5D-C2478B7AA881@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LoerwZWCEAR96Nqx1nAnN3zgA5g Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 18:43:38 -0000 --Apple-Mail=_D444EB86-C44A-4129-9A5C-D2F6DAFFC322 Content-Type: multipart/alternative; boundary="Apple-Mail=_54129193-70BA-4526-B160-19669E3E636F" --Apple-Mail=_54129193-70BA-4526-B160-19669E3E636F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau = wrote: >=20 > On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim = wrote: >=20 > > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau = wrote: > >> > >> Why is that not useful? Because I didn't say I was in favor = of forces? *) > > > > Not at all. Your statement was more like a high five. It is ok to > > raise your hand at > > the meeting - but i was hoping the list would have more useful > > technical discussion. > > > >> It IS useful to say that my company's products implement = Yang/Netconf and will support RestConf, >and therefore a derivative of = those technologies used for i2rs is preferred. We have no plans to = >support any of the other discussed options in i2rs such as Forces at = this time. The reasons are >simple: our customers asked for = Netconf/Yang models and as far as I can tell, have no interest in = >Forces. > >> > > > > So again it boils down to "bussiness" reasons - am i wrong? >=20 > Yes, but not in the way you imply. My company has implemented = Yang/Netconf because our customers have asked us to and because when we = did, they bought our equipment - not as you imply, because we think its = cool. There are a number of other major hardware vendors on this list = that have done the same. I think if you poll most of those vendors, you = will find that they generally don't engineering resources to things = that people don't buy. Also, Open Daylight has gone with = Netconf/Yang/RestConf as one of its primary interfaces - there are = dozens of vendors working on that project too. As far as I can tell, no = one has done any programmable interface based on Forces there. That = seems to be an overwhelming number of implementations that have gone = with yang/netconf/restconf. >=20 >=20 > It would be just as valid for people to chime in "We already use = ForCES" > or "we use already OF-Config", as a reason to use it for I2RS. It would, and I think that is what the chairs are trying to = assess so chime on in!=20 --Tom >=20 >=20 > Andy >=20 > > "we have an implementation of Yang/netconf"; > > "we are going to make it work for I2RS". > > If thats the case - then lets just end the discussion. > > I am hoping to get the answer to: > > What are the technical requirements/arguements? > > Why do i have to struggle so much in a technical environment like = IETF for > > someone to come out and say what the requirements are? > > > > I can assure you that i have no religious conviction that say it has > > to be ForCES. > > Lets actually start with you showing me how netconf/yang meets the = requirements. > > Otherwise - please stop with the high fives. > > > >> =46rom my perspective, continuing to debate which protocol = is derived to become i2rs is a waste >of everyone's time. > > > > Whats the point to having a circus show in pretending we are trying = to > > get any consensus? >=20 > I am not WG chair, so I will let Ed/Jeff comment on the = circus. *) >=20 > > Its clear what people want from the meeting, and if you poll = interested implementations you'll likely >get the same answer: = yang/netconf/restconf. Lets please stop delaying i2rs and get some work = >done here. > >> > > > > When you go and ask people to raise their hands they will. You need = to > > ask them why > > they are raising their hands. I am hoping this is not a staked > > popularity contest. >=20 > Well, at some point it does come down to running code and = real, deployed implementations, right? As I said above, there are many = real and significant implementations of yang/netconf in the marketplace = *today*. Asking those things to be modified slightly isn't that big of a = deal in order to address the requirements. Implementing a completely new = protocol is. I am not totally against new protocols - its just that if = we can achieve the goals we have by hacking an existing implementation, = that makes better engineering and business sense. >=20 > --Tom >=20 >=20 >=20 > > > > > > cheers, > > jamal > > > > _______________________________________________ > > 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 >=20 >=20 --Apple-Mail=_54129193-70BA-4526-B160-19669E3E636F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:
>>
>>        Why is that not useful? Because I didn't say I was in favor of forces? *)
>
> Not at all. Your statement was more like a high five. It is ok to
> raise your hand at
> the meeting - but i was hoping the list would have more useful
> technical discussion.
>
>> It IS useful to say that my company's products implement Yang/Netconf and will support RestConf, >and therefore a derivative of those technologies used for i2rs is preferred. We have no plans to >support any of the other discussed options in i2rs such as Forces at this time.  The reasons are >simple: our customers asked for Netconf/Yang models and as far as I can tell, have no interest in >Forces.
>>
>
> So again it boils down to "bussiness" reasons - am i wrong?

        Yes, but not in the way you imply. My company has implemented Yang/Netconf because our customers have asked us to and because when we did, they bought our equipment - not as you imply, because we think its cool. There are a number of other major hardware vendors on this list that have done the same. I think if you poll most of those vendors, you will find that they generally don't  engineering resources to things that people don't buy.  Also, Open Daylight has gone with Netconf/Yang/RestConf as one of its primary interfaces - there are dozens of vendors working on that project too.  As far as I can tell, no one has done any programmable interface based on Forces there.  That seems to be an overwhelming number of implementations that have gone with yang/netconf/restconf.


It would be just as valid for people to chime in "We already use ForCES"
or "we use already OF-Config", as a reason to use it for I2RS.

It would, and I think that is what the chairs are trying to assess so chime on in! 

--Tom



Andy

> "we have an implementation of Yang/netconf";
> "we are going to make it work for I2RS".
> If thats the case - then lets just end the discussion.
> I am hoping to get the answer to:
> What are the technical requirements/arguements?
> Why do i have to struggle so much in a technical environment like IETF for
> someone to come out and say what the requirements are?
>
> I can assure you that i have no religious conviction that say it has
> to be  ForCES.
> Lets actually start with you showing me how netconf/yang meets the requirements.
> Otherwise - please stop with the high fives.
>
>>        From my perspective, continuing to debate which protocol is derived to become i2rs is a waste >of everyone's time.
>
> Whats the point to having a circus show in pretending we are trying to
> get any consensus?

        I am not WG chair, so I will let Ed/Jeff comment on the circus. *)

> Its clear what people want from the meeting, and if you poll interested implementations you'll likely >get the same answer: yang/netconf/restconf.  Lets please stop delaying i2rs and get some work >done here.
>>
>
> When you go and ask people to raise their hands they will. You need to
> ask them why
> they are raising their hands. I am hoping this is not a staked
> popularity contest.

        Well, at some point it does come down to running code and real, deployed implementations, right?  As I said above, there are many real and significant implementations of yang/netconf in the marketplace *today*. Asking those things to be modified slightly isn't that big of a deal in order to address the requirements. Implementing a completely new protocol is. I am not totally against new protocols - its just that if we can achieve the goals we have by hacking an existing implementation, that makes better engineering and business sense.

        --Tom



>
>
> cheers,
> jamal
>
> _______________________________________________
> 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=_54129193-70BA-4526-B160-19669E3E636F-- --Apple-Mail=_D444EB86-C44A-4129-9A5C-D2F6DAFFC322 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTUXJPAAoJEPcO+I7eiUJZrNAQALZySIQEocuhQEvhq4wXtENh CKoGTwGXXDO0mlJNHG/R/SsEh/FMcYywAecfogO7uLppp8NaZJhhSMT34FpVXZ/v 6idHokJ2tvv6cfaf8Twe9Ayy5DWMYqgLW0YBG9Y1bnM+wlVE0FYKsORXvGvER/nC T1oFg+JcHxHs0bzmI40HJfOsq9gH+cBp2zlXvf/yhNa/AhF6cfwZIJIyEv90eETj /GaWXDFSrcssd8VgPE2CHtY/M84gWauYChpsjHqlvT6SZvMxKFYfb+DYxd7bmDSg QAKlGRwVRACj2c5hFxLZvCoxI8VidaRCwulRGNgD+YsOVDURKITisyCoc1N4vjo1 Wa5F+r04D4/LLkNL362EKBUaKdOpl9uKrNwb6xXRW+mzIlSFsQ3tx35/o7SJ+nbB OZl+Hs/4/rmQHqO99lG1lXcaBLU2G8nCogJLCpMOB6cvtH6x4b5BJl4GoF2tcSBr t+q3mSXLYuPQgB1Y+V57GMB7c6oCqPsBWj77tuyZ3NQ9HA/ynoZ96QNU/ZAaGvBI 4jFGKVziEVnKFEKCRPONJP0zAf6d3XROCC2Gg578DZhQWc2cavkCTnnwgP7AvOxl O4igo91/mh1gUxKDKRr5t1oHRAYq/HSI/jhn222BwW71xM0i0X07f9XUk5qInyZJ LYBdH9/k1+VOOMkmw1jE =RZ75 -----END PGP SIGNATURE----- --Apple-Mail=_D444EB86-C44A-4129-9A5C-D2F6DAFFC322-- From nobody Fri Apr 18 12:01:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE35F1A0461 for ; Fri, 18 Apr 2014 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsbkpICKL8jL for ; Fri, 18 Apr 2014 12:01:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA021A0454 for ; Fri, 18 Apr 2014 12:01:41 -0700 (PDT) Received: from [192.168.1.2] (unknown [75.103.8.100]) by mail.tail-f.com (Postfix) with ESMTPSA id 841A339412C; Fri, 18 Apr 2014 21:01:33 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carl Moberg In-Reply-To: <3B9BF234-1E42-4DBA-BE5D-C2478B7AA881@lucidvision.com> Date: Fri, 18 Apr 2014 12:01:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33C63443-3640-4F87-95C6-4F58D48EDDB5@tail-f.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> <3B9BF234-1E42-4DBA-BE5D-C2478B7AA881@lucidvision.com> To: "i2rs@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qb--jriAsfIeJEpH6LABT9pj5M4 Cc: Thomas Nadeau , Jamal Hadi Salim , Crabbe Edward , Andy Bierman , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 19:01:47 -0000 On Apr 18, 2014, at 11:43 AM, Thomas Nadeau = wrote: >=20 > On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau = wrote: >>=20 >> On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim = wrote: >>=20 >> > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau = wrote: >> >> >> >> Why is that not useful? Because I didn't say I was in favor = of forces? *) >> > >> > Not at all. Your statement was more like a high five. It is ok to >> > raise your hand at >> > the meeting - but i was hoping the list would have more useful >> > technical discussion. >> > >> >> It IS useful to say that my company's products implement = Yang/Netconf and will support RestConf, >and therefore a derivative of = those technologies used for i2rs is preferred. We have no plans to = >support any of the other discussed options in i2rs such as Forces at = this time. The reasons are >simple: our customers asked for = Netconf/Yang models and as far as I can tell, have no interest in = >Forces. >> >> >> > >> > So again it boils down to "bussiness" reasons - am i wrong? >>=20 >> Yes, but not in the way you imply. My company has implemented = Yang/Netconf because our customers have asked us to and because when we = did, they bought our equipment - not as you imply, because we think its = cool. There are a number of other major hardware vendors on this list = that have done the same. I think if you poll most of those vendors, you = will find that they generally don't engineering resources to things = that people don't buy. Also, Open Daylight has gone with = Netconf/Yang/RestConf as one of its primary interfaces - there are = dozens of vendors working on that project too. As far as I can tell, no = one has done any programmable interface based on Forces there. That = seems to be an overwhelming number of implementations that have gone = with yang/netconf/restconf. >>=20 >>=20 >> It would be just as valid for people to chime in "We already use = ForCES" >> or "we use already OF-Config", as a reason to use it for I2RS. >=20 > It would, and I think that is what the chairs are trying to = assess so chime on in!=20 While we (the ONF contributors) have explicitly tried to keep the = OF-CONFIG specification language and protocol agnostic, but the only = currently available implementation-ready language and transport mapping = available is YANG and NETCONF. So in reality, OF-CONFIG is currently = NETCONF with a YANG module maintained by the ONF. > --Tom >=20 >>=20 >>=20 >> Andy >>=20 >> > "we have an implementation of Yang/netconf"; >> > "we are going to make it work for I2RS". >> > If thats the case - then lets just end the discussion. >> > I am hoping to get the answer to: >> > What are the technical requirements/arguements? >> > Why do i have to struggle so much in a technical environment like = IETF for >> > someone to come out and say what the requirements are? >> > >> > I can assure you that i have no religious conviction that say it = has >> > to be ForCES. >> > Lets actually start with you showing me how netconf/yang meets the = requirements. >> > Otherwise - please stop with the high fives. >> > >> >> =46rom my perspective, continuing to debate which protocol = is derived to become i2rs is a waste >of everyone's time. >> > >> > Whats the point to having a circus show in pretending we are trying = to >> > get any consensus? >>=20 >> I am not WG chair, so I will let Ed/Jeff comment on the = circus. *) >>=20 >> > Its clear what people want from the meeting, and if you poll = interested implementations you'll likely >get the same answer: = yang/netconf/restconf. Lets please stop delaying i2rs and get some work = >done here. >> >> >> > >> > When you go and ask people to raise their hands they will. You need = to >> > ask them why >> > they are raising their hands. I am hoping this is not a staked >> > popularity contest. >>=20 >> Well, at some point it does come down to running code and = real, deployed implementations, right? As I said above, there are many = real and significant implementations of yang/netconf in the marketplace = *today*. Asking those things to be modified slightly isn't that big of a = deal in order to address the requirements. Implementing a completely new = protocol is. I am not totally against new protocols - its just that if = we can achieve the goals we have by hacking an existing implementation, = that makes better engineering and business sense. >>=20 >> --Tom >>=20 >>=20 >>=20 >> > >> > >> > cheers, >> > jamal >> > >> > _______________________________________________ >> > 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 >>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Carl Moberg VP Technology twitter: @cmoberg http://www.tail-f.com/ From nobody Fri Apr 18 12:40:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B181A01D9 for ; Fri, 18 Apr 2014 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsPsw67-YEqs for ; Fri, 18 Apr 2014 12:40:07 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 802601A01B1 for ; Fri, 18 Apr 2014 12:40:07 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so3634525veb.13 for ; Fri, 18 Apr 2014 12:40:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dn+p4d3RSoxuZ8+KnqwP2tp/uP0AouIkE8J3hcaEzR0=; b=ceNHOgEdoFrIUB8dSqGQCjNf5UR32g4JeaMZ5I1MobgsC+RX0uYtZ2c4NwcJpqXEWr Dg3steP9dSjsJiTp5ZFeGL/95qH0hBq2+7Z0JU3q64IBFDsdP/+ec9ll41W3CJ1qlBMW nnU96rGcQUcR0wVSnY9gojdOPMNKxsrn5f8HfyhbsUgPx86snpddv9pBBAnzWFaMdq40 PhZEo33K9+a3LtFXikxJp20QsMMd1gaJ1Pn1h4LeY3KKCwlXMrrACTaJTF+mZFjyR4TY Xm10bgHiAPZTng7vmvrCgHJXDu2zml0vTqB/ZmYRvaJfzNOXwTHhSVlxBsu9WSbJgyVD d7Ag== X-Gm-Message-State: ALoCoQnnHvhdrgVLQBCyAT0w4bw8O+4NU991XoEyOU4RDCebx2/7ogzBXnY5yNZLEF5ZToKNSVEp X-Received: by 10.52.108.228 with SMTP id hn4mr8879vdb.43.1397850003308; Fri, 18 Apr 2014 12:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 12:39:43 -0700 (PDT) In-Reply-To: <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 15:39:43 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NYvWe0pv4RSqULCTRVycdgX_l5Q Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 19:40:09 -0000 On Fri, Apr 18, 2014 at 2:30 PM, Thomas Nadeau wrote: > >> So again it boils down to "bussiness" reasons - am i wrong? > > Yes, but not in the way you imply. >My company has implemented Yang/Netconf because our customers have asked us to and because >when we did, they bought our equipment - not as you imply, because we think its cool. So your customer came to you and said they need you to implement I2RS using Yang/Netconf? It sounds to me like you had Yang/Netconf - customer may have asked for I2RS and in you suggested netconf/Yang. >There are a number of other major hardware vendors on this list that have done the same. I think if >you poll most of those vendors, you will find that they generally don't engineering resources to >things that people don't buy. >Also, Open Daylight has gone with Netconf/Yang/RestConf as one of >its primary interfaces - there are dozens of vendors working on that project too. I think you are missing the point. What are the requirements? I will use netconf/yang when it makes sense. But using it because you can, or some project decided they want to use it is not an assertion that it meets the requirements. > As far as I can tell, no one has done any programmable interface based on Forces there. Seriously? I know you decided to leave ForCES out of your book but you are not entitled to you facts. ForCES has been deployed and vetted. If you are interested and not being a troll we can talk. >That > seems to be an overwhelming number of implementations that have gone with > yang/netconf/restconf. So please explain how it meets the requirements for i2rs. > Well, at some point it does come down to running code and real, deployed implementations, > right? Sure - so you want to show up at the next IETF meeting with your implementation of I2RS and i will show up with me and we can discuss around running code? For sure you havent deployed I2RS. So lets not talk about deployment. >As I said above, there are many real and significant implementations of yang/netconf in the > marketplace *today*. Asking those things to be modified slightly isn't that big of a deal in order to > address the requirements. Implementing a completely new protocol is. I am not totally against new > protocols - its just that if we can achieve the goals we have by hacking an existing implementation, > that makes better engineering and business sense. > I dont think we have much disagreements there. I am just not convinced that netconf/yang will require just a small surgery to deploy I2RS. Lets start with requirements, shall we? I may actually end up agreeing with you, who knows. cheers, jamal From nobody Fri Apr 18 12:49:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1691A02D6 for ; Fri, 18 Apr 2014 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJlybHjUDb-8 for ; Fri, 18 Apr 2014 12:49:10 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id D038F1A01F6 for ; Fri, 18 Apr 2014 12:49:09 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so3595470veb.37 for ; Fri, 18 Apr 2014 12:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TikQJbshlOPzYQyBC8UvTy/8flGZY0N2p25uWZNOQco=; b=cbZ7aFxAATc8wJrBhXqoTnsAq+TMcHD1eGj7OJI3Tz62TQP7LRbklY1PtbbCmJCpvA j92GttEO3ASsNIXScG0i2WUcdPIuhp/lVVFWlvdEYUPh9jHjikl7SgyA77HZy0xDdXKu tahcD1UyTHKVEQpENSUza0HuOGLdw2LT7DMEONuZblykJ/7j9dAHwcae/d1lcxkMwxok 4wCNLSkQyEDNh5fZaTeL/ft2RmcFk8OXM9eBIZuFJtD7Pgz5A/VcH0x0+FqGZudCyhjz 0QK8eG9cO/OJwTqB1XJGDTsF5/F5kby4+IOIptYYSD2Ioi24oT7IEx57SuDHknzRdxjd WUsw== X-Gm-Message-State: ALoCoQnBQqQb7lcp4u2k+tPTscOvKZIST06HLg1d1Ow8D3XjvOhwhvoL3JzBuv0riDHti3fZd4vJ X-Received: by 10.220.103.141 with SMTP id k13mr4440737vco.25.1397850545655; Fri, 18 Apr 2014 12:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 12:48:45 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 15:48:45 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5T5da9Bo0jMfQ57QBCMtjsIEZnQ Cc: Thomas Nadeau , Crabbe Edward , Dean Bogdanovic , "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 19:49:14 -0000 On Fri, Apr 18, 2014 at 2:32 PM, Andy Bierman wrote: > > > I guess I knew that Brocade already uses YANG, and inferred that > what was Tom meant. > > You stated that YANG only does config, which is incorrect. > It may be useful for people have not bothered to read either > YANG or ForCES RFCs to understand more about both. > Ok, let me take that back. NETCONF/YANG is about config. > But at a certain point it gets to be like debating programming languages. > Much of it is subjective, based on the preferences, tools, training, etc., > of the people who will be writing the code. > Or we could have requirements well stated and things vetted against requirements. I think then there is a threshold where which approach requires a bigger surgery. If both ForCES and Yang/netconf/restconf require equivalent surgeries then by all means Yang/netconf/restconf is the better candidate. cheers, jamal > > From nobody Fri Apr 18 12:58:21 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C051A01CE for ; Fri, 18 Apr 2014 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PU407Kwdwt1 for ; Fri, 18 Apr 2014 12:58:07 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8196E1A01E3 for ; Fri, 18 Apr 2014 12:58:07 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3557114veb.39 for ; Fri, 18 Apr 2014 12:58:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=I2Xry2kuxb51a1xS6tuHyo+wvX2S+9BlH5vGmaKQy0A=; b=k0weyTynJQHKXsZT7JatFCIHodOSq60YQmwnDc+5gSTowMBWDiOqdy7lOl0SYGgRJT zKr1Pz0tmOAQwPtpnu00pXZq5S3zkfkVvFPXtobrGmYJNx8uQlxfRbe8VULb3WpMFuxi eGp+ZuqKAkccC1Uh3W5bsPbfCZm9qMeQl1yWX3IhovapFfCVwi+IfM22RL5wWfHv//nd rggaOb+xWXl6WQaUiZkPMnjms78r/JmX5ZtUhGePTRIuhC9PwUw0NSmwXHQah8+T0jkY AbgYY8YDUOcCxtO+gf2uC3d/V4/SsGB+HaxG+Gnzq7j2b+YyRNrIFUj7Ejux7oaOXAhu FwDQ== X-Gm-Message-State: ALoCoQmA5kjSefCR0c9z4y0TKQYcQbyUwzt9oNdsQYxpq8mNBTPzLhs0bPQHq+jtJU9q6EgGPxm6 X-Received: by 10.52.37.196 with SMTP id a4mr3734405vdk.33.1397851083415; Fri, 18 Apr 2014 12:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 12:57:43 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <083849EA-A48D-458B-A842-46064595E649@lucidvision.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 15:57:43 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HI-I3NRcQuVrD-E6ijBrpsQxzQI Cc: Thomas Nadeau , Crabbe Edward , Dean Bogdanovic , "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 19:58:12 -0000 On Fri, Apr 18, 2014 at 2:37 PM, Andy Bierman wrote: > It would be just as valid for people to chime in "We already use ForCES" > or "we use already OF-Config", as a reason to use it for I2RS. I will drop the idea of ForCES being the better candidate if there is actually an analysis of requirements vs what is out there and ForCES turns only to be slightly better. I hear what you said earlier on subjectivity as being a factor. This is true. And i do have my biases for ForCES - but I do hope this turns out to be a reasonable technical discussion. cheers, jamal From nobody Fri Apr 18 13:59:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C2F1A01D3 for ; Fri, 18 Apr 2014 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLlZqZ49kmk8 for ; Fri, 18 Apr 2014 13:59:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 234041A007B for ; Fri, 18 Apr 2014 13:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4669; q=dns/txt; s=iport; t=1397854774; x=1399064374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V9WEEu6fxBLdKceUWAA53EfBr6TkM/tIeLq3dxKeySo=; b=XU+CI1ikFF3HCDakh+a11hh46gFjt9qc4llt4Np+ogvrCXgAp5fKvo74 f33hAV1feii7dgwrEW1VK9agMRR6bb22mnRaDRk5Yz9ewUzsIWWrSTHDy Y/nSVwMka0D7piWcpZIFUlv89sidtZMLeXbzvqEtd1xTHM2pXf6XBdF0+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAK+RUVOtJA2H/2dsb2JhbABagwZPV7w+hzyBHRZ0giUBAQEEAQEBZAcLEAIBCBguJwslAgQBDQWIQQ3NFhMEiT2EcjMHhDgEiSqPRJJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="36989078" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 18 Apr 2014 20:59:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3IKxX3Z021257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 20:59:33 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 15:59:33 -0500 From: "Jan Medved (jmedved)" To: Dean Bogdanovic , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AA== Date: Fri, 18 Apr 2014 20:59:32 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.168] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <769D0CEFFED01A4D8E6FAE597C216D32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JVlT-K8Edi3yiKAW7M2k7nn07iM Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 20:59:44 -0000 Cisco is also implementing Netconf - it=B9s available on XR today, and it will be available on other platforms as well. For OpenDaylight, we chose Yang as the IDL to describe internal and external APIs in the controller and so far it has served its purpose really well.=20 Also, as Tom pointed out, Netconf and Restconf have also been implemented in ODL. I=B9d like to stress that we not only have multiple Netconf/Restcon= f implementations from multiple vendors (Brocade, Juniper, Cisco, just to mention those on this thread), but have multiple open source implementations as well. In addition to ODL, there is libnetconfd and a few others. ODL / libnetconfd interop testing is done in the ODL regression test suite. Now, since there are multiple independent open source implementations, we=B9ve got a good ecosystem for implementation of new Netconf/Restconf/Yang features that may be required to meet i2rs=B9s needs (if the need to evolve the protocols/language arises). In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as the modeling language. Thanks, Jan On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >Jamal, > >Here are two criteria to be considered: >1. technical >2. commercial/business > >We can discuss pros and cons for both, but have to state that from >business perspective for Juniper going with RESTCONF/YANG make more >sense. We already built the Junos model in YANG and >have or are in process of building needed tools. Same goes for RESTCONF. >We have NETCONF implemented in Junos and are working on RESTCONF >implementation. >Many carriers adopted or are adopting NETCONF/YANG, are looking into >RESTCONF as well, so this looks like a low hanging fruit from business >perspective. > >Looking at technical aspect, unless there is a very compelling reason >(and there might be, but I'm not aware of it), don't see reason to switch >from RESTCONF and YANG. >We can find out down the line that RESTCONF/YANG was the wrong way to go, >but that can be always changed. From my perspective it looks right today. > >Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > >Dean > >On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > >> Ok, since nobody is saying anything i'll bite. >> How would you like for this discussion to proceed? >>=20 >> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>> Dear I2RSers, >>>=20 >>> At the last I2RS WG meeting there was a great deal of conversation >>> regarding selection of both modeling language and underlying transport >>> protocol. Consensus at the time was to make use of Yang and (NetConf >>>or >>> RestConf) (unclear). >>>=20 >>=20 >> And i believe the view, as correctly presented by you, is for folks to >>go back >> and make educated decisions by actually getting knowledgeable about >> the different views presented. "Consensus" that you described above >> to me looked like a pageant popularity contest not based on anything >> technical ("who likes contestant in the blue shirt? please cheer for >>them"). >>=20 >> In my opinion i dont think the requirements are clear. >>=20 >> Will that get the crickets stop chirping? >>=20 >> cheers, >> jamal >>=20 >>> Before coming to a final consensus, we'd like to give people adequate >>>time >>> to review source material, marshall arguments and discuss on the >>>mailing >>> list. To this end, we're asking that interested parties do just this >>>over >>> the course of the next ~two weeks. Following that period, on 4/28, >>>we'll be >>> initiating a consensus call that will last an additional two weeks, >>>with the >>> aim of converging modeling language / protocol by Friday, 5/9. >>>=20 >>> The consensus call should also generate proposals for any material >>>changes >>> required to the underlying protocols. These proposals in turn will >>>form the >>> basis for a later draft including gap analysis and said changes. Those >>> strongly in favor of one protocol over another should be prepared to >>> contribute to this analysis. >>>=20 >>>=20 >>> best, >>>=20 >>> -ed >>>=20 >>> _______________________________________________ >>> 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 >>=20 >>=20 > > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 18 14:12:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5B41A04A3 for ; Fri, 18 Apr 2014 14:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zekawoLN86pf for ; Fri, 18 Apr 2014 14:12:36 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id CED3C1A01F0 for ; Fri, 18 Apr 2014 14:12:35 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so3676716veb.4 for ; Fri, 18 Apr 2014 14:12:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=YrMgU7pAgnOoxHl+g090+4zQKxFU2lCFtpE2skquSBM=; b=T1NdLfB4HcCeWvyJf+yddcGhoTi7MPpJu5DIxz9e1L5mfj9ewbXjVndV4Yg7KwfY3T PbR2j+jHZl/4zo6TvbIC+KBwdKFKma0Pqa/fqtUUwl5XOz/3sh7V2uefKf3b4WX02Jf+ rUZp/FZ7ui8D6QAkC/vbq2aXSxxuRBJEjtAHObsyDocOoMeT+2yvLkDufo+6iChKu3QP 9SXbEnh3PSUsO3qSGS+N2qpC8G2EUz4iwEnfGddUpYuCM4KSXwPDN9Ug8xyXrBxDOAac 06GWFt9nw8dboz8COZleoQwV3CiFuA1YGVMlsssXcHCiZLFH63329DFXHrB4QUsqUNBb qppQ== X-Gm-Message-State: ALoCoQlydlVyoWj4YfyWiAQRQx/c83jGHm03dbKOp81dssRMzfU7FBv23m49SJIUkb9jagTygDIX X-Received: by 10.52.183.228 with SMTP id ep4mr3882508vdc.30.1397855551601; Fri, 18 Apr 2014 14:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 14:12:11 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 17:12:11 -0400 Message-ID: To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/u0fWAb6mKb-qS1NU0aGVOjbwFto Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 21:12:41 -0000 On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) w= rote: > Cisco is also implementing Netconf - it=B9s available on XR today, and it > will be available on other platforms as well. > > For OpenDaylight, we chose Yang as the IDL to describe internal and > external APIs in the controller and so far it has served its purpose > really well. > This has nothing to do with meeting requirements for I2RS. > Also, as Tom pointed out, Netconf and Restconf have also been implemented > in ODL. I=B9d like to stress that we not only have multiple Netconf/Restc= onf > implementations from multiple vendors (Brocade, Juniper, Cisco, just to > mention those on this thread), but have multiple open source > implementations as well. In addition to ODL, there is libnetconfd and a > few others. ODL / libnetconfd interop testing is done in the ODL > regression test suite. Again - I am not hearing requirements against I2RS. Have you implemented I2RS with netconf/restconf/yang? > Now, since there are multiple independent open > source implementations, we=B9ve got a good ecosystem for implementation o= f > new Netconf/Restconf/Yang features that may be required to meet i2rs=B9s > needs (if the need to evolve the protocols/language arises). > I dont think this sounds rational at all. HTTP has a bigger ecosystem than = you. Why not build around that and then refactor as needed? Why is it so hard to get requirements around here? What is the point to a standard again? cheers, jamal > In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as > the modeling language. > > > > Thanks, > Jan > > > On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: > >>Jamal, >> >>Here are two criteria to be considered: >>1. technical >>2. commercial/business >> >>We can discuss pros and cons for both, but have to state that from >>business perspective for Juniper going with RESTCONF/YANG make more >>sense. We already built the Junos model in YANG and >>have or are in process of building needed tools. Same goes for RESTCONF. >>We have NETCONF implemented in Junos and are working on RESTCONF >>implementation. >>Many carriers adopted or are adopting NETCONF/YANG, are looking into >>RESTCONF as well, so this looks like a low hanging fruit from business >>perspective. >> >>Looking at technical aspect, unless there is a very compelling reason >>(and there might be, but I'm not aware of it), don't see reason to switch >>from RESTCONF and YANG. >>We can find out down the line that RESTCONF/YANG was the wrong way to go, >>but that can be always changed. From my perspective it looks right today. >> >>Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >>Dean >> >>On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >> >>> Ok, since nobody is saying anything i'll bite. >>> How would you like for this discussion to proceed? >>> >>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>>> Dear I2RSers, >>>> >>>> At the last I2RS WG meeting there was a great deal of conversation >>>> regarding selection of both modeling language and underlying transport >>>> protocol. Consensus at the time was to make use of Yang and (NetConf >>>>or >>>> RestConf) (unclear). >>>> >>> >>> And i believe the view, as correctly presented by you, is for folks to >>>go back >>> and make educated decisions by actually getting knowledgeable about >>> the different views presented. "Consensus" that you described above >>> to me looked like a pageant popularity contest not based on anything >>> technical ("who likes contestant in the blue shirt? please cheer for >>>them"). >>> >>> In my opinion i dont think the requirements are clear. >>> >>> Will that get the crickets stop chirping? >>> >>> cheers, >>> jamal >>> >>>> Before coming to a final consensus, we'd like to give people adequate >>>>time >>>> to review source material, marshall arguments and discuss on the >>>>mailing >>>> list. To this end, we're asking that interested parties do just this >>>>over >>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>we'll be >>>> initiating a consensus call that will last an additional two weeks, >>>>with the >>>> aim of converging modeling language / protocol by Friday, 5/9. >>>> >>>> The consensus call should also generate proposals for any material >>>>changes >>>> required to the underlying protocols. These proposals in turn will >>>>form the >>>> basis for a later draft including gap analysis and said changes. Thos= e >>>> strongly in favor of one protocol over another should be prepared to >>>> contribute to this analysis. >>>> >>>> >>>> best, >>>> >>>> -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 >>> >>> >> >> >>_______________________________________________ >>i2rs mailing list >>i2rs@ietf.org >>https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Apr 18 15:05:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED841A02D8 for ; Fri, 18 Apr 2014 15:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNAstC290kXt for ; Fri, 18 Apr 2014 15:05:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id E5F671A01F0 for ; Fri, 18 Apr 2014 15:05:00 -0700 (PDT) X-AuditID: c6180641-f79a26d000001830-2e-535150ab7fc2 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8E.63.06192.BA051535; Fri, 18 Apr 2014 18:19:56 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 18:04:55 -0400 From: Jeff Tantsura To: "Jan Medved (jmedved)" , Dean Bogdanovic , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Kz7DmdZ4nBEu9xmRI1UtXUZsXiiYAgAAepgCAAIEVAP//nOgA Date: Fri, 18 Apr 2014 22:04:54 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyuXRPrO6agMBgg9utghaP2+cwWzxcvJHd 4vbWPWwW62Z8YLHo+X2F2YHVY8rvjaweCzaVeixZ8pPJ43rTVXaPbbfWsgawRnHZpKTmZJal FunbJXBlfJ7bw17wx6Li5OQ/jA2MB8y7GDk5JARMJDavPMgGYYtJXLi3Hsjm4hASOMoo8fjQ PmYIZzmjxKO+nawgVWwCBhL/vx1nAbFFBKolOj9/YAexmQWcJd68/ssEYgsLWEis7NzBDlFj KXF52S8mCNtNYuqC92BxFgFVicaFX8A28wqYS5xdfRisRkjgI6PErcuaXYwcHJwC+hLT5nCB hBmBjvt+ag0TxCpxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/YGeKCuhJ3Hs0lwUiriQx5/U1Zohe LYkvP/axgYxnFrCWaNmtAhFWlJjS/ZAd4hpBiZMzn7BMYJSYhWTbLCTdsxC6ZyHpnoWkewEj 6ypGjtLi1LLcdCPDTYzAGD0mwea4g3HBJ8tDjAIcjEo8vFpXfYOFWBPLiitzDzFKc7AoifN+ eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR64IPx8wbl93P37KbbZs4/WRr173aQ0aR d01ky3ut0m7XL8+9aKK0vH+X+h2l6rVeH3axpJqkbild9frPg7OSckHh+6WerJnteuHdxmW1 xvlimoF+e2bPjfMxm5vktz/h4Tv7p98vHNee87Ru8eaFcmI5KnuZ5WWDDwull/Bs7fE73fvu /Np/SizFGYmGWsxFxYkAeO1xVrICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bOozCRK3XfNb18u2j4LletnvRYw Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 22:05:07 -0000 KzEgZm9yIE5ldGNvbmYvWUFORyBmb3IgdGhlIGkycnMgcHJvdG9jb2wgYW5kIGZvciBZQU5HIGFz DQp0aGUgbW9kZWxpbmcgbGFuZ3VhZ2UuDQoNCg0KQ2hlZXJzLA0KSmVmZg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiSmFuIE1lZHZlZCAgIChqbWVkdmVkKSIgPGptZWR2 ZWRAY2lzY28uY29tPg0KRGF0ZTogRnJpZGF5LCBBcHJpbCAxOCwgMjAxNCAxOjU5IFBNDQpUbzog RGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5pcGVyLm5ldD4sIEphbWFsIEhhZGkgU2FsaW0NCjxo YWRpQG1vamF0YXR1LmNvbT4NCkNjOiAiaTJyc0BpZXRmLm9yZyIgPGkycnNAaWV0Zi5vcmc+LCBF ZHdhcmQgQ3JhYmJlIDxlZGNAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbaTJyc10gY29uc2Vu c3VzIG9uIEkyUlMgcHJvdG9jb2wgYW5kIG1vZGVsDQoNCj5DaXNjbyBpcyBhbHNvIGltcGxlbWVu dGluZyBOZXRjb25mIC0gaXSp9nMgYXZhaWxhYmxlIG9uIFhSIHRvZGF5LCBhbmQgaXQNCj53aWxs IGJlIGF2YWlsYWJsZSBvbiBvdGhlciBwbGF0Zm9ybXMgYXMgd2VsbC4NCj4NCj5Gb3IgT3BlbkRh eWxpZ2h0LCB3ZSBjaG9zZSBZYW5nIGFzIHRoZSBJREwgdG8gZGVzY3JpYmUgaW50ZXJuYWwgYW5k DQo+ZXh0ZXJuYWwgQVBJcyBpbiB0aGUgY29udHJvbGxlciBhbmQgc28gZmFyIGl0IGhhcyBzZXJ2 ZWQgaXRzIHB1cnBvc2UNCj5yZWFsbHkgd2VsbC4gDQo+DQo+QWxzbywgYXMgVG9tIHBvaW50ZWQg b3V0LCBOZXRjb25mIGFuZCBSZXN0Y29uZiBoYXZlIGFsc28gYmVlbiBpbXBsZW1lbnRlZA0KPmlu IE9ETC4gSan2ZCBsaWtlIHRvIHN0cmVzcyB0aGF0IHdlIG5vdCBvbmx5IGhhdmUgbXVsdGlwbGUg TmV0Y29uZi9SZXN0Y29uZg0KPmltcGxlbWVudGF0aW9ucyBmcm9tIG11bHRpcGxlIHZlbmRvcnMg KEJyb2NhZGUsIEp1bmlwZXIsIENpc2NvLCBqdXN0IHRvDQo+bWVudGlvbiB0aG9zZSBvbiB0aGlz IHRocmVhZCksIGJ1dCBoYXZlIG11bHRpcGxlIG9wZW4gc291cmNlDQo+aW1wbGVtZW50YXRpb25z IGFzIHdlbGwuIEluIGFkZGl0aW9uIHRvIE9ETCwgdGhlcmUgaXMgbGlibmV0Y29uZmQgYW5kIGEN Cj5mZXcgb3RoZXJzLiAgT0RMIC8gbGlibmV0Y29uZmQgaW50ZXJvcCB0ZXN0aW5nIGlzIGRvbmUg aW4gdGhlIE9ETA0KPnJlZ3Jlc3Npb24gdGVzdCBzdWl0ZS4gIE5vdywgc2luY2UgdGhlcmUgYXJl IG11bHRpcGxlIGluZGVwZW5kZW50IG9wZW4NCj5zb3VyY2UgaW1wbGVtZW50YXRpb25zLCB3Zan2 dmUgZ290IGEgZ29vZCBlY29zeXN0ZW0gZm9yIGltcGxlbWVudGF0aW9uIG9mDQo+bmV3IE5ldGNv bmYvUmVzdGNvbmYvWWFuZyBmZWF0dXJlcyB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBtZWV0IGky cnOp9nMNCj5uZWVkcyAoaWYgdGhlIG5lZWQgdG8gZXZvbHZlIHRoZSBwcm90b2NvbHMvbGFuZ3Vh Z2UgYXJpc2VzKS4NCj4NCj5JbiBzaG9ydCwgKzEgZm9yIE5ldGNvbmYvUmVzdGNvbmYgZm9yIHRo ZSBpMnJzIHByb3RvY29sIGFuZCBmb3IgWWFuZyBhcw0KPnRoZSBtb2RlbGluZyBsYW5ndWFnZS4N Cj4NCj4NCj4NCj5UaGFua3MsDQo+SmFuDQo+DQo+DQo+T24gNC8xOC8xNCwgNjoxNyBBTSwgIkRl YW4gQm9nZGFub3ZpYyIgPGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4NCj4+SmFtYWwsDQo+ Pg0KPj5IZXJlIGFyZSB0d28gY3JpdGVyaWEgdG8gYmUgY29uc2lkZXJlZDoNCj4+MS4gdGVjaG5p Y2FsDQo+PjIuIGNvbW1lcmNpYWwvYnVzaW5lc3MNCj4+DQo+PldlIGNhbiBkaXNjdXNzIHByb3Mg YW5kIGNvbnMgZm9yIGJvdGgsIGJ1dCBoYXZlIHRvIHN0YXRlIHRoYXQgZnJvbQ0KPj5idXNpbmVz cyBwZXJzcGVjdGl2ZSBmb3IgSnVuaXBlciBnb2luZyB3aXRoIFJFU1RDT05GL1lBTkcgbWFrZSBt b3JlDQo+PnNlbnNlLiBXZSBhbHJlYWR5IGJ1aWx0IHRoZSBKdW5vcyBtb2RlbCBpbiBZQU5HIGFu ZA0KPj5oYXZlIG9yIGFyZSBpbiBwcm9jZXNzIG9mIGJ1aWxkaW5nIG5lZWRlZCB0b29scy4gU2Ft ZSBnb2VzIGZvciBSRVNUQ09ORi4NCj4+V2UgaGF2ZSBORVRDT05GIGltcGxlbWVudGVkIGluIEp1 bm9zIGFuZCBhcmUgd29ya2luZyBvbiBSRVNUQ09ORg0KPj5pbXBsZW1lbnRhdGlvbi4NCj4+TWFu eSBjYXJyaWVycyBhZG9wdGVkIG9yIGFyZSBhZG9wdGluZyBORVRDT05GL1lBTkcsIGFyZSBsb29r aW5nIGludG8NCj4+UkVTVENPTkYgYXMgd2VsbCwgc28gdGhpcyBsb29rcyBsaWtlIGEgbG93IGhh bmdpbmcgZnJ1aXQgZnJvbSBidXNpbmVzcw0KPj5wZXJzcGVjdGl2ZS4NCj4+DQo+Pkxvb2tpbmcg YXQgdGVjaG5pY2FsIGFzcGVjdCwgdW5sZXNzIHRoZXJlIGlzIGEgdmVyeSBjb21wZWxsaW5nIHJl YXNvbg0KPj4oYW5kIHRoZXJlIG1pZ2h0IGJlLCBidXQgSSdtIG5vdCBhd2FyZSBvZiBpdCksIGRv bid0IHNlZSByZWFzb24gdG8gc3dpdGNoDQo+PmZyb20gUkVTVENPTkYgYW5kIFlBTkcuDQo+Pldl IGNhbiBmaW5kIG91dCBkb3duIHRoZSBsaW5lIHRoYXQgUkVTVENPTkYvWUFORyB3YXMgdGhlIHdy b25nIHdheSB0byBnbywNCj4+YnV0IHRoYXQgY2FuIGJlIGFsd2F5cyBjaGFuZ2VkLiBGcm9tIG15 IHBlcnNwZWN0aXZlIGl0IGxvb2tzIHJpZ2h0IHRvZGF5Lg0KPj4NCj4+SnVzdCB0byBiZSBjbGVh ciwgSSB2b3RlIGZvciBSRVNUQ09ORi9ZQU5HIGFkb3B0aW9uIGZvciBpMnJzLg0KPj4NCj4+RGVh bg0KPj4NCj4+T24gQXByIDE4LCAyMDE0LCBhdCA3OjI3IEFNLCBKYW1hbCBIYWRpIFNhbGltIDxo YWRpQG1vamF0YXR1LmNvbT4gd3JvdGU6DQo+Pg0KPj4+IE9rLCBzaW5jZSBub2JvZHkgaXMgc2F5 aW5nIGFueXRoaW5nIGknbGwgYml0ZS4NCj4+PiBIb3cgd291bGQgeW91IGxpa2UgZm9yIHRoaXMg ZGlzY3Vzc2lvbiB0byBwcm9jZWVkPw0KPj4+IA0KPj4+IE9uIEZyaSwgQXByIDExLCAyMDE0IGF0 IDE6NTAgUE0sIEVkd2FyZCBDcmFiYmUgPGVkY0Bnb29nbGUuY29tPiB3cm90ZToNCj4+Pj4gRGVh ciBJMlJTZXJzLA0KPj4+PiANCj4+Pj4gIEF0IHRoZSBsYXN0IEkyUlMgV0cgbWVldGluZyB0aGVy ZSB3YXMgYSBncmVhdCBkZWFsIG9mIGNvbnZlcnNhdGlvbg0KPj4+PiByZWdhcmRpbmcgc2VsZWN0 aW9uIG9mIGJvdGggbW9kZWxpbmcgbGFuZ3VhZ2UgYW5kIHVuZGVybHlpbmcgdHJhbnNwb3J0DQo+ Pj4+IHByb3RvY29sLiAgQ29uc2Vuc3VzIGF0IHRoZSB0aW1lIHdhcyB0byBtYWtlIHVzZSBvZiBZ YW5nIGFuZCAoTmV0Q29uZg0KPj4+Pm9yDQo+Pj4+IFJlc3RDb25mKSAodW5jbGVhcikuDQo+Pj4+ IA0KPj4+IA0KPj4+IEFuZCBpIGJlbGlldmUgdGhlIHZpZXcsIGFzIGNvcnJlY3RseSBwcmVzZW50 ZWQgYnkgeW91LCBpcyBmb3IgZm9sa3MgdG8NCj4+PmdvIGJhY2sNCj4+PiBhbmQgbWFrZSBlZHVj YXRlZCBkZWNpc2lvbnMgYnkgYWN0dWFsbHkgZ2V0dGluZyBrbm93bGVkZ2VhYmxlIGFib3V0DQo+ Pj4gdGhlIGRpZmZlcmVudCB2aWV3cyBwcmVzZW50ZWQuICJDb25zZW5zdXMiIHRoYXQgeW91IGRl c2NyaWJlZCBhYm92ZQ0KPj4+IHRvIG1lIGxvb2tlZCBsaWtlICBhIHBhZ2VhbnQgcG9wdWxhcml0 eSBjb250ZXN0IG5vdCBiYXNlZCBvbiBhbnl0aGluZw0KPj4+IHRlY2huaWNhbCAoIndobyBsaWtl cyBjb250ZXN0YW50IGluIHRoZSBibHVlIHNoaXJ0PyBwbGVhc2UgY2hlZXIgZm9yDQo+Pj50aGVt IikuDQo+Pj4gDQo+Pj4gSW4gbXkgb3BpbmlvbiBpIGRvbnQgdGhpbmsgdGhlIHJlcXVpcmVtZW50 cyBhcmUgY2xlYXIuDQo+Pj4gDQo+Pj4gV2lsbCB0aGF0IGdldCB0aGUgY3JpY2tldHMgc3RvcCBj aGlycGluZz8NCj4+PiANCj4+PiBjaGVlcnMsDQo+Pj4gamFtYWwNCj4+PiANCj4+Pj4gIEJlZm9y ZSBjb21pbmcgdG8gYSBmaW5hbCBjb25zZW5zdXMsIHdlJ2QgbGlrZSB0byBnaXZlIHBlb3BsZSBh ZGVxdWF0ZQ0KPj4+PnRpbWUNCj4+Pj4gdG8gcmV2aWV3IHNvdXJjZSBtYXRlcmlhbCwgbWFyc2hh bGwgYXJndW1lbnRzIGFuZCBkaXNjdXNzIG9uIHRoZQ0KPj4+Pm1haWxpbmcNCj4+Pj4gbGlzdC4g IFRvIHRoaXMgZW5kLCB3ZSdyZSBhc2tpbmcgdGhhdCBpbnRlcmVzdGVkIHBhcnRpZXMgZG8ganVz dCB0aGlzDQo+Pj4+b3Zlcg0KPj4+PiB0aGUgY291cnNlIG9mIHRoZSBuZXh0IH50d28gd2Vla3Mu IEZvbGxvd2luZyB0aGF0IHBlcmlvZCwgb24gNC8yOCwNCj4+Pj53ZSdsbCBiZQ0KPj4+PiBpbml0 aWF0aW5nIGEgY29uc2Vuc3VzIGNhbGwgdGhhdCB3aWxsIGxhc3QgYW4gYWRkaXRpb25hbCB0d28g d2Vla3MsDQo+Pj4+d2l0aCB0aGUNCj4+Pj4gYWltIG9mIGNvbnZlcmdpbmcgbW9kZWxpbmcgbGFu Z3VhZ2UgLyBwcm90b2NvbCBieSBGcmlkYXksIDUvOS4NCj4+Pj4gDQo+Pj4+IFRoZSBjb25zZW5z dXMgY2FsbCBzaG91bGQgYWxzbyBnZW5lcmF0ZSBwcm9wb3NhbHMgZm9yIGFueSBtYXRlcmlhbA0K Pj4+PmNoYW5nZXMNCj4+Pj4gcmVxdWlyZWQgdG8gdGhlIHVuZGVybHlpbmcgcHJvdG9jb2xzLiAg VGhlc2UgcHJvcG9zYWxzIGluIHR1cm4gd2lsbA0KPj4+PmZvcm0gdGhlDQo+Pj4+IGJhc2lzIGZv ciBhIGxhdGVyIGRyYWZ0IGluY2x1ZGluZyBnYXAgYW5hbHlzaXMgYW5kIHNhaWQgY2hhbmdlcy4N Cj4+Pj5UaG9zZQ0KPj4+PiBzdHJvbmdseSBpbiBmYXZvciBvZiBvbmUgcHJvdG9jb2wgb3ZlciBh bm90aGVyIHNob3VsZCBiZSBwcmVwYXJlZCB0bw0KPj4+PiBjb250cmlidXRlIHRvIHRoaXMgYW5h bHlzaXMuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gYmVzdCwNCj4+Pj4gDQo+Pj4+ICAtZWQNCj4+Pj4g DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IGkycnMgbWFpbGluZyBsaXN0DQo+Pj4+IGkycnNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+IA0KPj4+IA0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gaTJycyBtYWls aW5nIGxpc3QNCj4+PiBpMnJzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMnJzDQo+Pj4gDQo+Pj4gDQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+aTJycyBtYWlsaW5nIGxpc3QNCj4+ aTJyc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ky cnMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PmkycnMgbWFpbGluZyBsaXN0DQo+aTJyc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= From nobody Fri Apr 18 15:11:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076B11A02D8 for ; Fri, 18 Apr 2014 15:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBXF_mHv36Jk for ; Fri, 18 Apr 2014 15:11:16 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 006CC1A01F0 for ; Fri, 18 Apr 2014 15:11:15 -0700 (PDT) Received: from mail128-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Apr 2014 22:10:24 +0000 Received: from mail128-co9 (localhost [127.0.0.1]) by mail128-co9-R.bigfish.com (Postfix) with ESMTP id 3BBB73001DC; Fri, 18 Apr 2014 22:10:24 +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: -26 X-BigFish: VPS-26(zzbb2dI98dI9371Ic89bh542I1432I4015Idb82hzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzc2hz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h1155h) Received-SPF: pass (mail128-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=gmattson@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(199002)(189002)(24454002)(377454003)(479174003)(164054003)(13464003)(51704005)(15975445006)(81342001)(99396002)(76482001)(4396001)(66066001)(92566001)(80022001)(20776003)(81542001)(79102001)(54356999)(74662001)(76176999)(1941001)(99286001)(77096999)(36756003)(83506001)(92726001)(80976001)(50986999)(74502001)(83072002)(2656002)(31966008)(46102001)(87936001)(83322001)(85852003)(77982001)(561944002)(19580405001)(19580395003)(86362001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB417; H:BLUPR05MB756.namprd05.prod.outlook.com; FPR:ACB7F1D9.9FE2D453.F9F1514B.5EE4DD49.2057B; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail128-co9 (localhost.localdomain [127.0.0.1]) by mail128-co9 (MessageSwitch) id 1397859022424192_29858; Fri, 18 Apr 2014 22:10:22 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.241]) by mail128-co9.bigfish.com (Postfix) with ESMTP id 6297120004F; Fri, 18 Apr 2014 22:10:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Apr 2014 22:10:22 +0000 Received: from BLUPR05MB417.namprd05.prod.outlook.com (10.141.27.15) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 18 Apr 2014 22:11:04 +0000 Received: from BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) by BLUPR05MB417.namprd05.prod.outlook.com (10.141.27.15) with Microsoft SMTP Server (TLS) id 15.0.921.12; Fri, 18 Apr 2014 22:11:03 +0000 Received: from BLUPR05MB756.namprd05.prod.outlook.com ([10.141.208.151]) by BLUPR05MB756.namprd05.prod.outlook.com ([10.141.208.151]) with mapi id 15.00.0918.000; Fri, 18 Apr 2014 22:11:02 +0000 From: Geoffrey Mattson To: Jeff Tantsura , "Jan Medved (jmedved)" , Dean Bogdanovic , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Je9XaL+FIKUeJb8+m5HQcAZsXRxgAgAAepgCAAIEVAIAAEkMA//+MRYA= Date: Fri, 18 Apr 2014 22:11:01 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.14] x-forefront-prvs: 018577E36E Content-Type: text/plain; charset="euc-kr" Content-ID: <814B714A869FAA459B87DDB1B269CDC8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/k9ZW6uT3p617l6Puv1Tkn9em9Tk Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 22:11:23 -0000 KzEgZm9yIE5ldGNvbmYgZm9yIHRoZSBJMlJTIHByb3RvY29sIGFuZCBZQU5HIGZvciB0aGUgbW9k ZWxpbmcgbGFuZ3VhZ2UuDQoNCk9uIDQvMTgvMTQgMzowNCBQTSwgIkplZmYgVGFudHN1cmEiIDxq ZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj4rMSBmb3IgTmV0Y29uZi9ZQU5H IGZvciB0aGUgaTJycyBwcm90b2NvbCBhbmQgZm9yIFlBTkcgYXMNCj50aGUgbW9kZWxpbmcgbGFu Z3VhZ2UuDQo+DQo+DQo+Q2hlZXJzLA0KPkplZmYNCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206ICJKYW4gTWVkdmVkICAgKGptZWR2ZWQpIiA8am1lZHZlZEBjaXNjby5j b20+DQo+RGF0ZTogRnJpZGF5LCBBcHJpbCAxOCwgMjAxNCAxOjU5IFBNDQo+VG86IERlYW4gQm9n ZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+LCBKYW1hbCBIYWRpIFNhbGltDQo+PGhhZGlAbW9q YXRhdHUuY29tPg0KPkNjOiAiaTJyc0BpZXRmLm9yZyIgPGkycnNAaWV0Zi5vcmc+LCBFZHdhcmQg Q3JhYmJlIDxlZGNAZ29vZ2xlLmNvbT4NCj5TdWJqZWN0OiBSZTogW2kycnNdIGNvbnNlbnN1cyBv biBJMlJTIHByb3RvY29sIGFuZCBtb2RlbA0KPg0KPj5DaXNjbyBpcyBhbHNvIGltcGxlbWVudGlu ZyBOZXRjb25mIC0gaXSp9nMgYXZhaWxhYmxlIG9uIFhSIHRvZGF5LCBhbmQgaXQNCj4+d2lsbCBi ZSBhdmFpbGFibGUgb24gb3RoZXIgcGxhdGZvcm1zIGFzIHdlbGwuDQo+Pg0KPj5Gb3IgT3BlbkRh eWxpZ2h0LCB3ZSBjaG9zZSBZYW5nIGFzIHRoZSBJREwgdG8gZGVzY3JpYmUgaW50ZXJuYWwgYW5k DQo+PmV4dGVybmFsIEFQSXMgaW4gdGhlIGNvbnRyb2xsZXIgYW5kIHNvIGZhciBpdCBoYXMgc2Vy dmVkIGl0cyBwdXJwb3NlDQo+PnJlYWxseSB3ZWxsLiANCj4+DQo+PkFsc28sIGFzIFRvbSBwb2lu dGVkIG91dCwgTmV0Y29uZiBhbmQgUmVzdGNvbmYgaGF2ZSBhbHNvIGJlZW4gaW1wbGVtZW50ZWQN Cj4+aW4gT0RMLiBJqfZkIGxpa2UgdG8gc3RyZXNzIHRoYXQgd2Ugbm90IG9ubHkgaGF2ZSBtdWx0 aXBsZQ0KPj5OZXRjb25mL1Jlc3Rjb25mDQo+PmltcGxlbWVudGF0aW9ucyBmcm9tIG11bHRpcGxl IHZlbmRvcnMgKEJyb2NhZGUsIEp1bmlwZXIsIENpc2NvLCBqdXN0IHRvDQo+Pm1lbnRpb24gdGhv c2Ugb24gdGhpcyB0aHJlYWQpLCBidXQgaGF2ZSBtdWx0aXBsZSBvcGVuIHNvdXJjZQ0KPj5pbXBs ZW1lbnRhdGlvbnMgYXMgd2VsbC4gSW4gYWRkaXRpb24gdG8gT0RMLCB0aGVyZSBpcyBsaWJuZXRj b25mZCBhbmQgYQ0KPj5mZXcgb3RoZXJzLiAgT0RMIC8gbGlibmV0Y29uZmQgaW50ZXJvcCB0ZXN0 aW5nIGlzIGRvbmUgaW4gdGhlIE9ETA0KPj5yZWdyZXNzaW9uIHRlc3Qgc3VpdGUuICBOb3csIHNp bmNlIHRoZXJlIGFyZSBtdWx0aXBsZSBpbmRlcGVuZGVudCBvcGVuDQo+PnNvdXJjZSBpbXBsZW1l bnRhdGlvbnMsIHdlqfZ2ZSBnb3QgYSBnb29kIGVjb3N5c3RlbSBmb3IgaW1wbGVtZW50YXRpb24g b2YNCj4+bmV3IE5ldGNvbmYvUmVzdGNvbmYvWWFuZyBmZWF0dXJlcyB0aGF0IG1heSBiZSByZXF1 aXJlZCB0byBtZWV0IGkycnOp9nMNCj4+bmVlZHMgKGlmIHRoZSBuZWVkIHRvIGV2b2x2ZSB0aGUg cHJvdG9jb2xzL2xhbmd1YWdlIGFyaXNlcykuDQo+Pg0KPj5JbiBzaG9ydCwgKzEgZm9yIE5ldGNv bmYvUmVzdGNvbmYgZm9yIHRoZSBpMnJzIHByb3RvY29sIGFuZCBmb3IgWWFuZyBhcw0KPj50aGUg bW9kZWxpbmcgbGFuZ3VhZ2UuDQo+Pg0KPj4NCj4+DQo+PlRoYW5rcywNCj4+SmFuDQo+Pg0KPj4N Cj4+T24gNC8xOC8xNCwgNjoxNyBBTSwgIkRlYW4gQm9nZGFub3ZpYyIgPGRlYW5iQGp1bmlwZXIu bmV0PiB3cm90ZToNCj4+DQo+Pj5KYW1hbCwNCj4+Pg0KPj4+SGVyZSBhcmUgdHdvIGNyaXRlcmlh IHRvIGJlIGNvbnNpZGVyZWQ6DQo+Pj4xLiB0ZWNobmljYWwNCj4+PjIuIGNvbW1lcmNpYWwvYnVz aW5lc3MNCj4+Pg0KPj4+V2UgY2FuIGRpc2N1c3MgcHJvcyBhbmQgY29ucyBmb3IgYm90aCwgYnV0 IGhhdmUgdG8gc3RhdGUgdGhhdCBmcm9tDQo+Pj5idXNpbmVzcyBwZXJzcGVjdGl2ZSBmb3IgSnVu aXBlciBnb2luZyB3aXRoIFJFU1RDT05GL1lBTkcgbWFrZSBtb3JlDQo+Pj5zZW5zZS4gV2UgYWxy ZWFkeSBidWlsdCB0aGUgSnVub3MgbW9kZWwgaW4gWUFORyBhbmQNCj4+PmhhdmUgb3IgYXJlIGlu IHByb2Nlc3Mgb2YgYnVpbGRpbmcgbmVlZGVkIHRvb2xzLiBTYW1lIGdvZXMgZm9yIFJFU1RDT05G Lg0KPj4+V2UgaGF2ZSBORVRDT05GIGltcGxlbWVudGVkIGluIEp1bm9zIGFuZCBhcmUgd29ya2lu ZyBvbiBSRVNUQ09ORg0KPj4+aW1wbGVtZW50YXRpb24uDQo+Pj5NYW55IGNhcnJpZXJzIGFkb3B0 ZWQgb3IgYXJlIGFkb3B0aW5nIE5FVENPTkYvWUFORywgYXJlIGxvb2tpbmcgaW50bw0KPj4+UkVT VENPTkYgYXMgd2VsbCwgc28gdGhpcyBsb29rcyBsaWtlIGEgbG93IGhhbmdpbmcgZnJ1aXQgZnJv bSBidXNpbmVzcw0KPj4+cGVyc3BlY3RpdmUuDQo+Pj4NCj4+Pkxvb2tpbmcgYXQgdGVjaG5pY2Fs IGFzcGVjdCwgdW5sZXNzIHRoZXJlIGlzIGEgdmVyeSBjb21wZWxsaW5nIHJlYXNvbg0KPj4+KGFu ZCB0aGVyZSBtaWdodCBiZSwgYnV0IEknbSBub3QgYXdhcmUgb2YgaXQpLCBkb24ndCBzZWUgcmVh c29uIHRvDQo+Pj5zd2l0Y2gNCj4+PmZyb20gUkVTVENPTkYgYW5kIFlBTkcuDQo+Pj5XZSBjYW4g ZmluZCBvdXQgZG93biB0aGUgbGluZSB0aGF0IFJFU1RDT05GL1lBTkcgd2FzIHRoZSB3cm9uZyB3 YXkgdG8NCj4+PmdvLA0KPj4+YnV0IHRoYXQgY2FuIGJlIGFsd2F5cyBjaGFuZ2VkLiBGcm9tIG15 IHBlcnNwZWN0aXZlIGl0IGxvb2tzIHJpZ2h0DQo+Pj50b2RheS4NCj4+Pg0KPj4+SnVzdCB0byBi ZSBjbGVhciwgSSB2b3RlIGZvciBSRVNUQ09ORi9ZQU5HIGFkb3B0aW9uIGZvciBpMnJzLg0KPj4+ DQo+Pj5EZWFuDQo+Pj4NCj4+Pk9uIEFwciAxOCwgMjAxNCwgYXQgNzoyNyBBTSwgSmFtYWwgSGFk aSBTYWxpbSA8aGFkaUBtb2phdGF0dS5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+IE9rLCBzaW5jZSBu b2JvZHkgaXMgc2F5aW5nIGFueXRoaW5nIGknbGwgYml0ZS4NCj4+Pj4gSG93IHdvdWxkIHlvdSBs aWtlIGZvciB0aGlzIGRpc2N1c3Npb24gdG8gcHJvY2VlZD8NCj4+Pj4gDQo+Pj4+IE9uIEZyaSwg QXByIDExLCAyMDE0IGF0IDE6NTAgUE0sIEVkd2FyZCBDcmFiYmUgPGVkY0Bnb29nbGUuY29tPiB3 cm90ZToNCj4+Pj4+IERlYXIgSTJSU2VycywNCj4+Pj4+IA0KPj4+Pj4gIEF0IHRoZSBsYXN0IEky UlMgV0cgbWVldGluZyB0aGVyZSB3YXMgYSBncmVhdCBkZWFsIG9mIGNvbnZlcnNhdGlvbg0KPj4+ Pj4gcmVnYXJkaW5nIHNlbGVjdGlvbiBvZiBib3RoIG1vZGVsaW5nIGxhbmd1YWdlIGFuZCB1bmRl cmx5aW5nDQo+Pj4+PnRyYW5zcG9ydA0KPj4+Pj4gcHJvdG9jb2wuICBDb25zZW5zdXMgYXQgdGhl IHRpbWUgd2FzIHRvIG1ha2UgdXNlIG9mIFlhbmcgYW5kIChOZXRDb25mDQo+Pj4+Pm9yDQo+Pj4+ PiBSZXN0Q29uZikgKHVuY2xlYXIpLg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBBbmQgaSBiZWxpZXZl IHRoZSB2aWV3LCBhcyBjb3JyZWN0bHkgcHJlc2VudGVkIGJ5IHlvdSwgaXMgZm9yIGZvbGtzIHRv DQo+Pj4+Z28gYmFjaw0KPj4+PiBhbmQgbWFrZSBlZHVjYXRlZCBkZWNpc2lvbnMgYnkgYWN0dWFs bHkgZ2V0dGluZyBrbm93bGVkZ2VhYmxlIGFib3V0DQo+Pj4+IHRoZSBkaWZmZXJlbnQgdmlld3Mg cHJlc2VudGVkLiAiQ29uc2Vuc3VzIiB0aGF0IHlvdSBkZXNjcmliZWQgYWJvdmUNCj4+Pj4gdG8g bWUgbG9va2VkIGxpa2UgIGEgcGFnZWFudCBwb3B1bGFyaXR5IGNvbnRlc3Qgbm90IGJhc2VkIG9u IGFueXRoaW5nDQo+Pj4+IHRlY2huaWNhbCAoIndobyBsaWtlcyBjb250ZXN0YW50IGluIHRoZSBi bHVlIHNoaXJ0PyBwbGVhc2UgY2hlZXIgZm9yDQo+Pj4+dGhlbSIpLg0KPj4+PiANCj4+Pj4gSW4g bXkgb3BpbmlvbiBpIGRvbnQgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBhcmUgY2xlYXIuDQo+Pj4+ IA0KPj4+PiBXaWxsIHRoYXQgZ2V0IHRoZSBjcmlja2V0cyBzdG9wIGNoaXJwaW5nPw0KPj4+PiAN Cj4+Pj4gY2hlZXJzLA0KPj4+PiBqYW1hbA0KPj4+PiANCj4+Pj4+ICBCZWZvcmUgY29taW5nIHRv IGEgZmluYWwgY29uc2Vuc3VzLCB3ZSdkIGxpa2UgdG8gZ2l2ZSBwZW9wbGUNCj4+Pj4+YWRlcXVh dGUNCj4+Pj4+dGltZQ0KPj4+Pj4gdG8gcmV2aWV3IHNvdXJjZSBtYXRlcmlhbCwgbWFyc2hhbGwg YXJndW1lbnRzIGFuZCBkaXNjdXNzIG9uIHRoZQ0KPj4+Pj5tYWlsaW5nDQo+Pj4+PiBsaXN0LiAg VG8gdGhpcyBlbmQsIHdlJ3JlIGFza2luZyB0aGF0IGludGVyZXN0ZWQgcGFydGllcyBkbyBqdXN0 IHRoaXMNCj4+Pj4+b3Zlcg0KPj4+Pj4gdGhlIGNvdXJzZSBvZiB0aGUgbmV4dCB+dHdvIHdlZWtz LiBGb2xsb3dpbmcgdGhhdCBwZXJpb2QsIG9uIDQvMjgsDQo+Pj4+PndlJ2xsIGJlDQo+Pj4+PiBp bml0aWF0aW5nIGEgY29uc2Vuc3VzIGNhbGwgdGhhdCB3aWxsIGxhc3QgYW4gYWRkaXRpb25hbCB0 d28gd2Vla3MsDQo+Pj4+PndpdGggdGhlDQo+Pj4+PiBhaW0gb2YgY29udmVyZ2luZyBtb2RlbGlu ZyBsYW5ndWFnZSAvIHByb3RvY29sIGJ5IEZyaWRheSwgNS85Lg0KPj4+Pj4gDQo+Pj4+PiBUaGUg Y29uc2Vuc3VzIGNhbGwgc2hvdWxkIGFsc28gZ2VuZXJhdGUgcHJvcG9zYWxzIGZvciBhbnkgbWF0 ZXJpYWwNCj4+Pj4+Y2hhbmdlcw0KPj4+Pj4gcmVxdWlyZWQgdG8gdGhlIHVuZGVybHlpbmcgcHJv dG9jb2xzLiAgVGhlc2UgcHJvcG9zYWxzIGluIHR1cm4gd2lsbA0KPj4+Pj5mb3JtIHRoZQ0KPj4+ Pj4gYmFzaXMgZm9yIGEgbGF0ZXIgZHJhZnQgaW5jbHVkaW5nIGdhcCBhbmFseXNpcyBhbmQgc2Fp ZCBjaGFuZ2VzLg0KPj4+Pj5UaG9zZQ0KPj4+Pj4gc3Ryb25nbHkgaW4gZmF2b3Igb2Ygb25lIHBy b3RvY29sIG92ZXIgYW5vdGhlciBzaG91bGQgYmUgcHJlcGFyZWQgdG8NCj4+Pj4+IGNvbnRyaWJ1 dGUgdG8gdGhpcyBhbmFseXNpcy4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBiZXN0LA0KPj4+Pj4g DQo+Pj4+PiAgLWVkDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+Pj4gaTJyc0Bp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz DQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IGkycnMgbWFpbGluZyBsaXN0DQo+Pj4+IGkycnNAaWV0Zi5vcmcN Cj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+IA0K Pj4+PiANCj4+Pg0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+aTJycyBtYWlsaW5nIGxpc3QNCj4+PmkycnNAaWV0Zi5vcmcNCj4+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPj4NCj4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+aTJycyBtYWlsaW5nIGxp c3QNCj4+aTJyc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kycnMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPmkycnMgbWFpbGluZyBsaXN0DQo+aTJyc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= From nobody Fri Apr 18 15:14:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B171A01F0 for ; Fri, 18 Apr 2014 15:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg8_PeD_rgY9 for ; Fri, 18 Apr 2014 15:14:08 -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 CE9D11A01D8 for ; Fri, 18 Apr 2014 15:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8576; q=dns/txt; s=iport; t=1397859244; x=1399068844; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PSVKilaR+pMS54v8RcOOFDRiP7O0kkkdKudevS7MpZM=; b=IQvTpCRRtBSb8JbicjngiZcaxWXSqxO0ynu7xwQLTHrBP6KlMEJpWHJF 3FQeSwGFlO4CUdyq6p/yl6BQY37bD25LKIzLKzhY0C9/TQ716bNXJzSzH 7FX5sOGS3mimQw4j/7o1kaOs0wKVypf1GkQKj8xZUo2xOd9pzJbKJdvKH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAE2iUVOtJV2b/2dsb2JhbABagwZPV4MSuSyHPBmBBBZ0giUBAQEEAQEBMTMHCwwGAQgOAwMBAgEEKAQlCx0IAgQBDQWIQAENjVicEwajGRMEgSOIGoRyMwcGgmOBTwSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="318768264" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 18 Apr 2014 22:14:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3IME3DK006602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 22:14:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 17:14:02 -0500 From: "Palani Chinnakannan (pals)" To: Geoffrey Mattson , Jeff Tantsura , "Jan Medved (jmedved)" , Dean Bogdanovic , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7K+1TI1cr5GESMSJyaLQYZpJsXmuoAgAAepgCAAIEVAIAAEkMAgAABtoD//4wFgA== Date: Fri, 18 Apr 2014 22:14:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [171.70.242.208] Content-Type: text/plain; charset="euc-kr" Content-ID: <2F8CD7F3622DDD4AA4A0A755ADF62017@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5YlGh2VzLqqORgyXH-Xy9n4MeM4 Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 22:14:12 -0000 KzENCldlIGhhdmUgYmVlbiBzYXlpbmcgdGhpcyBmb3IgYSBxdWl0ZSBzb21ldGltZSA6LSkNCg0K cGFscw0KDQpPbiA0LzE4LzE0IDM6MTEgUE0sICJHZW9mZnJleSBNYXR0c29uIiA8Z21hdHRzb25A anVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+KzEgZm9yIE5ldGNvbmYgZm9yIHRoZSBJMlJTIHByb3Rv Y29sIGFuZCBZQU5HIGZvciB0aGUgbW9kZWxpbmcgbGFuZ3VhZ2UuDQo+DQo+T24gNC8xOC8xNCAz OjA0IFBNLCAiSmVmZiBUYW50c3VyYSIgPGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPiB3cm90 ZToNCj4NCj4+KzEgZm9yIE5ldGNvbmYvWUFORyBmb3IgdGhlIGkycnMgcHJvdG9jb2wgYW5kIGZv ciBZQU5HIGFzDQo+PnRoZSBtb2RlbGluZyBsYW5ndWFnZS4NCj4+DQo+Pg0KPj5DaGVlcnMsDQo+ PkplZmYNCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiAiSmFu IE1lZHZlZCAgIChqbWVkdmVkKSIgPGptZWR2ZWRAY2lzY28uY29tPg0KPj5EYXRlOiBGcmlkYXks IEFwcmlsIDE4LCAyMDE0IDE6NTkgUE0NCj4+VG86IERlYW4gQm9nZGFub3ZpYyA8ZGVhbmJAanVu aXBlci5uZXQ+LCBKYW1hbCBIYWRpIFNhbGltDQo+PjxoYWRpQG1vamF0YXR1LmNvbT4NCj4+Q2M6 ICJpMnJzQGlldGYub3JnIiA8aTJyc0BpZXRmLm9yZz4sIEVkd2FyZCBDcmFiYmUgPGVkY0Bnb29n bGUuY29tPg0KPj5TdWJqZWN0OiBSZTogW2kycnNdIGNvbnNlbnN1cyBvbiBJMlJTIHByb3RvY29s IGFuZCBtb2RlbA0KPj4NCj4+PkNpc2NvIGlzIGFsc28gaW1wbGVtZW50aW5nIE5ldGNvbmYgLSBp dKn2cyBhdmFpbGFibGUgb24gWFIgdG9kYXksIGFuZCBpdA0KPj4+d2lsbCBiZSBhdmFpbGFibGUg b24gb3RoZXIgcGxhdGZvcm1zIGFzIHdlbGwuDQo+Pj4NCj4+PkZvciBPcGVuRGF5bGlnaHQsIHdl IGNob3NlIFlhbmcgYXMgdGhlIElETCB0byBkZXNjcmliZSBpbnRlcm5hbCBhbmQNCj4+PmV4dGVy bmFsIEFQSXMgaW4gdGhlIGNvbnRyb2xsZXIgYW5kIHNvIGZhciBpdCBoYXMgc2VydmVkIGl0cyBw dXJwb3NlDQo+Pj5yZWFsbHkgd2VsbC4gDQo+Pj4NCj4+PkFsc28sIGFzIFRvbSBwb2ludGVkIG91 dCwgTmV0Y29uZiBhbmQgUmVzdGNvbmYgaGF2ZSBhbHNvIGJlZW4NCj4+PmltcGxlbWVudGVkDQo+ Pj5pbiBPREwuIEmp9mQgbGlrZSB0byBzdHJlc3MgdGhhdCB3ZSBub3Qgb25seSBoYXZlIG11bHRp cGxlDQo+Pj5OZXRjb25mL1Jlc3Rjb25mDQo+Pj5pbXBsZW1lbnRhdGlvbnMgZnJvbSBtdWx0aXBs ZSB2ZW5kb3JzIChCcm9jYWRlLCBKdW5pcGVyLCBDaXNjbywganVzdCB0bw0KPj4+bWVudGlvbiB0 aG9zZSBvbiB0aGlzIHRocmVhZCksIGJ1dCBoYXZlIG11bHRpcGxlIG9wZW4gc291cmNlDQo+Pj5p bXBsZW1lbnRhdGlvbnMgYXMgd2VsbC4gSW4gYWRkaXRpb24gdG8gT0RMLCB0aGVyZSBpcyBsaWJu ZXRjb25mZCBhbmQgYQ0KPj4+ZmV3IG90aGVycy4gIE9ETCAvIGxpYm5ldGNvbmZkIGludGVyb3Ag dGVzdGluZyBpcyBkb25lIGluIHRoZSBPREwNCj4+PnJlZ3Jlc3Npb24gdGVzdCBzdWl0ZS4gIE5v dywgc2luY2UgdGhlcmUgYXJlIG11bHRpcGxlIGluZGVwZW5kZW50IG9wZW4NCj4+PnNvdXJjZSBp bXBsZW1lbnRhdGlvbnMsIHdlqfZ2ZSBnb3QgYSBnb29kIGVjb3N5c3RlbSBmb3IgaW1wbGVtZW50 YXRpb24gb2YNCj4+Pm5ldyBOZXRjb25mL1Jlc3Rjb25mL1lhbmcgZmVhdHVyZXMgdGhhdCBtYXkg YmUgcmVxdWlyZWQgdG8gbWVldCBpMnJzqfZzDQo+Pj5uZWVkcyAoaWYgdGhlIG5lZWQgdG8gZXZv bHZlIHRoZSBwcm90b2NvbHMvbGFuZ3VhZ2UgYXJpc2VzKS4NCj4+Pg0KPj4+SW4gc2hvcnQsICsx IGZvciBOZXRjb25mL1Jlc3Rjb25mIGZvciB0aGUgaTJycyBwcm90b2NvbCBhbmQgZm9yIFlhbmcg YXMNCj4+PnRoZSBtb2RlbGluZyBsYW5ndWFnZS4NCj4+Pg0KPj4+DQo+Pj4NCj4+PlRoYW5rcywN Cj4+Pkphbg0KPj4+DQo+Pj4NCj4+Pk9uIDQvMTgvMTQsIDY6MTcgQU0sICJEZWFuIEJvZ2Rhbm92 aWMiIDxkZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4NCj4+Pj5KYW1hbCwNCj4+Pj4NCj4+ Pj5IZXJlIGFyZSB0d28gY3JpdGVyaWEgdG8gYmUgY29uc2lkZXJlZDoNCj4+Pj4xLiB0ZWNobmlj YWwNCj4+Pj4yLiBjb21tZXJjaWFsL2J1c2luZXNzDQo+Pj4+DQo+Pj4+V2UgY2FuIGRpc2N1c3Mg cHJvcyBhbmQgY29ucyBmb3IgYm90aCwgYnV0IGhhdmUgdG8gc3RhdGUgdGhhdCBmcm9tDQo+Pj4+ YnVzaW5lc3MgcGVyc3BlY3RpdmUgZm9yIEp1bmlwZXIgZ29pbmcgd2l0aCBSRVNUQ09ORi9ZQU5H IG1ha2UgbW9yZQ0KPj4+PnNlbnNlLiBXZSBhbHJlYWR5IGJ1aWx0IHRoZSBKdW5vcyBtb2RlbCBp biBZQU5HIGFuZA0KPj4+PmhhdmUgb3IgYXJlIGluIHByb2Nlc3Mgb2YgYnVpbGRpbmcgbmVlZGVk IHRvb2xzLiBTYW1lIGdvZXMgZm9yDQo+Pj4+UkVTVENPTkYuDQo+Pj4+V2UgaGF2ZSBORVRDT05G IGltcGxlbWVudGVkIGluIEp1bm9zIGFuZCBhcmUgd29ya2luZyBvbiBSRVNUQ09ORg0KPj4+Pmlt cGxlbWVudGF0aW9uLg0KPj4+Pk1hbnkgY2FycmllcnMgYWRvcHRlZCBvciBhcmUgYWRvcHRpbmcg TkVUQ09ORi9ZQU5HLCBhcmUgbG9va2luZyBpbnRvDQo+Pj4+UkVTVENPTkYgYXMgd2VsbCwgc28g dGhpcyBsb29rcyBsaWtlIGEgbG93IGhhbmdpbmcgZnJ1aXQgZnJvbSBidXNpbmVzcw0KPj4+PnBl cnNwZWN0aXZlLg0KPj4+Pg0KPj4+Pkxvb2tpbmcgYXQgdGVjaG5pY2FsIGFzcGVjdCwgdW5sZXNz IHRoZXJlIGlzIGEgdmVyeSBjb21wZWxsaW5nIHJlYXNvbg0KPj4+PihhbmQgdGhlcmUgbWlnaHQg YmUsIGJ1dCBJJ20gbm90IGF3YXJlIG9mIGl0KSwgZG9uJ3Qgc2VlIHJlYXNvbiB0bw0KPj4+PnN3 aXRjaA0KPj4+PmZyb20gUkVTVENPTkYgYW5kIFlBTkcuDQo+Pj4+V2UgY2FuIGZpbmQgb3V0IGRv d24gdGhlIGxpbmUgdGhhdCBSRVNUQ09ORi9ZQU5HIHdhcyB0aGUgd3Jvbmcgd2F5IHRvDQo+Pj4+ Z28sDQo+Pj4+YnV0IHRoYXQgY2FuIGJlIGFsd2F5cyBjaGFuZ2VkLiBGcm9tIG15IHBlcnNwZWN0 aXZlIGl0IGxvb2tzIHJpZ2h0DQo+Pj4+dG9kYXkuDQo+Pj4+DQo+Pj4+SnVzdCB0byBiZSBjbGVh ciwgSSB2b3RlIGZvciBSRVNUQ09ORi9ZQU5HIGFkb3B0aW9uIGZvciBpMnJzLg0KPj4+Pg0KPj4+ PkRlYW4NCj4+Pj4NCj4+Pj5PbiBBcHIgMTgsIDIwMTQsIGF0IDc6MjcgQU0sIEphbWFsIEhhZGkg U2FsaW0gPGhhZGlAbW9qYXRhdHUuY29tPg0KPj4+Pndyb3RlOg0KPj4+Pg0KPj4+Pj4gT2ssIHNp bmNlIG5vYm9keSBpcyBzYXlpbmcgYW55dGhpbmcgaSdsbCBiaXRlLg0KPj4+Pj4gSG93IHdvdWxk IHlvdSBsaWtlIGZvciB0aGlzIGRpc2N1c3Npb24gdG8gcHJvY2VlZD8NCj4+Pj4+IA0KPj4+Pj4g T24gRnJpLCBBcHIgMTEsIDIwMTQgYXQgMTo1MCBQTSwgRWR3YXJkIENyYWJiZSA8ZWRjQGdvb2ds ZS5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4+IERlYXIgSTJSU2VycywNCj4+Pj4+PiANCj4+Pj4+ PiAgQXQgdGhlIGxhc3QgSTJSUyBXRyBtZWV0aW5nIHRoZXJlIHdhcyBhIGdyZWF0IGRlYWwgb2Yg Y29udmVyc2F0aW9uDQo+Pj4+Pj4gcmVnYXJkaW5nIHNlbGVjdGlvbiBvZiBib3RoIG1vZGVsaW5n IGxhbmd1YWdlIGFuZCB1bmRlcmx5aW5nDQo+Pj4+Pj50cmFuc3BvcnQNCj4+Pj4+PiBwcm90b2Nv bC4gIENvbnNlbnN1cyBhdCB0aGUgdGltZSB3YXMgdG8gbWFrZSB1c2Ugb2YgWWFuZyBhbmQNCj4+ Pj4+PihOZXRDb25mDQo+Pj4+Pj5vcg0KPj4+Pj4+IFJlc3RDb25mKSAodW5jbGVhcikuDQo+Pj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IEFuZCBpIGJlbGlldmUgdGhlIHZpZXcsIGFzIGNvcnJlY3RseSBw cmVzZW50ZWQgYnkgeW91LCBpcyBmb3IgZm9sa3MNCj4+Pj4+dG8NCj4+Pj4+Z28gYmFjaw0KPj4+ Pj4gYW5kIG1ha2UgZWR1Y2F0ZWQgZGVjaXNpb25zIGJ5IGFjdHVhbGx5IGdldHRpbmcga25vd2xl ZGdlYWJsZSBhYm91dA0KPj4+Pj4gdGhlIGRpZmZlcmVudCB2aWV3cyBwcmVzZW50ZWQuICJDb25z ZW5zdXMiIHRoYXQgeW91IGRlc2NyaWJlZCBhYm92ZQ0KPj4+Pj4gdG8gbWUgbG9va2VkIGxpa2Ug IGEgcGFnZWFudCBwb3B1bGFyaXR5IGNvbnRlc3Qgbm90IGJhc2VkIG9uIGFueXRoaW5nDQo+Pj4+ PiB0ZWNobmljYWwgKCJ3aG8gbGlrZXMgY29udGVzdGFudCBpbiB0aGUgYmx1ZSBzaGlydD8gcGxl YXNlIGNoZWVyIGZvcg0KPj4+Pj50aGVtIikuDQo+Pj4+PiANCj4+Pj4+IEluIG15IG9waW5pb24g aSBkb250IHRoaW5rIHRoZSByZXF1aXJlbWVudHMgYXJlIGNsZWFyLg0KPj4+Pj4gDQo+Pj4+PiBX aWxsIHRoYXQgZ2V0IHRoZSBjcmlja2V0cyBzdG9wIGNoaXJwaW5nPw0KPj4+Pj4gDQo+Pj4+PiBj aGVlcnMsDQo+Pj4+PiBqYW1hbA0KPj4+Pj4gDQo+Pj4+Pj4gIEJlZm9yZSBjb21pbmcgdG8gYSBm aW5hbCBjb25zZW5zdXMsIHdlJ2QgbGlrZSB0byBnaXZlIHBlb3BsZQ0KPj4+Pj4+YWRlcXVhdGUN Cj4+Pj4+PnRpbWUNCj4+Pj4+PiB0byByZXZpZXcgc291cmNlIG1hdGVyaWFsLCBtYXJzaGFsbCBh cmd1bWVudHMgYW5kIGRpc2N1c3Mgb24gdGhlDQo+Pj4+Pj5tYWlsaW5nDQo+Pj4+Pj4gbGlzdC4g IFRvIHRoaXMgZW5kLCB3ZSdyZSBhc2tpbmcgdGhhdCBpbnRlcmVzdGVkIHBhcnRpZXMgZG8ganVz dA0KPj4+Pj4+dGhpcw0KPj4+Pj4+b3Zlcg0KPj4+Pj4+IHRoZSBjb3Vyc2Ugb2YgdGhlIG5leHQg fnR3byB3ZWVrcy4gRm9sbG93aW5nIHRoYXQgcGVyaW9kLCBvbiA0LzI4LA0KPj4+Pj4+d2UnbGwg YmUNCj4+Pj4+PiBpbml0aWF0aW5nIGEgY29uc2Vuc3VzIGNhbGwgdGhhdCB3aWxsIGxhc3QgYW4g YWRkaXRpb25hbCB0d28gd2Vla3MsDQo+Pj4+Pj53aXRoIHRoZQ0KPj4+Pj4+IGFpbSBvZiBjb252 ZXJnaW5nIG1vZGVsaW5nIGxhbmd1YWdlIC8gcHJvdG9jb2wgYnkgRnJpZGF5LCA1LzkuDQo+Pj4+ Pj4gDQo+Pj4+Pj4gVGhlIGNvbnNlbnN1cyBjYWxsIHNob3VsZCBhbHNvIGdlbmVyYXRlIHByb3Bv c2FscyBmb3IgYW55IG1hdGVyaWFsDQo+Pj4+Pj5jaGFuZ2VzDQo+Pj4+Pj4gcmVxdWlyZWQgdG8g dGhlIHVuZGVybHlpbmcgcHJvdG9jb2xzLiAgVGhlc2UgcHJvcG9zYWxzIGluIHR1cm4gd2lsbA0K Pj4+Pj4+Zm9ybSB0aGUNCj4+Pj4+PiBiYXNpcyBmb3IgYSBsYXRlciBkcmFmdCBpbmNsdWRpbmcg Z2FwIGFuYWx5c2lzIGFuZCBzYWlkIGNoYW5nZXMuDQo+Pj4+Pj5UaG9zZQ0KPj4+Pj4+IHN0cm9u Z2x5IGluIGZhdm9yIG9mIG9uZSBwcm90b2NvbCBvdmVyIGFub3RoZXIgc2hvdWxkIGJlIHByZXBh cmVkIHRvDQo+Pj4+Pj4gY29udHJpYnV0ZSB0byB0aGlzIGFuYWx5c2lzLg0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IGJlc3QsDQo+Pj4+Pj4gDQo+Pj4+Pj4gIC1lZA0KPj4+Pj4+IA0KPj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4g aTJycyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBpMnJzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBp MnJzIG1haWxpbmcgbGlzdA0KPj4+Pj4gaTJyc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pg0KPj4+ Pg0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+aTJycyBtYWlsaW5nIGxpc3QNCj4+Pj5pMnJzQGlldGYub3JnDQo+Pj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5pMnJzIG1haWxpbmcgbGlzdA0KPj4+ aTJyc0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p MnJzDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj5pMnJzIG1haWxpbmcgbGlzdA0KPj5pMnJzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+aTJycyBtYWlsaW5nIGxpc3QNCj5pMnJzQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCg== From nobody Fri Apr 18 15:15:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AFD1A024F for ; Fri, 18 Apr 2014 15:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj1oFzNVgUwA for ; Fri, 18 Apr 2014 15:15:31 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2BE1A01D8 for ; Fri, 18 Apr 2014 15:15:31 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so2148145qcx.18 for ; Fri, 18 Apr 2014 15:15:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MeGGWZlZJQHwWtKCmNV2BALmOdF2UKUxZojXNeqqTos=; b=b/Y7V3Et2bmDf7nQn80rOj0v8OEa7yg8EbbLAy/MWgzsA5q7PDlOxco6he3P0h001v Oxhi2yjdBL9X8yqVTJX20h9ujPq0Smkp7Ov8z1pDM/5/8Z5MFny0xTfBj0Kq+weh6GLS FTGTNrClsd8DlcbfWjG2ApUjkIkfU7UonTPwweXkyJR8vJZ4rrK+bxiRssaYAcAkVbZV 4g+rCnGPwOlBRhrwxm4jrdcpryx2QWYek6GQnFzFwK6Yi2aKR9caBQS9jYQHfhopPlq8 2L8oIHKsher/hHcCGM6/kh7LOyi9mToeH6Va51Oo5Gm5Dxq7NIFV4cWurjmbr4Ik7Fce h7/w== X-Gm-Message-State: ALoCoQkBrtqyS47fDNNSVeeDuriLuUu7eumGUsAY7q6+yvFoChU/o61fU3hph6NG3tUR6VhFpst3 MIME-Version: 1.0 X-Received: by 10.224.169.5 with SMTP id w5mr5794280qay.96.1397859326861; Fri, 18 Apr 2014 15:15:26 -0700 (PDT) Received: by 10.140.105.35 with HTTP; Fri, 18 Apr 2014 15:15:26 -0700 (PDT) X-Originating-IP: [128.223.223.251] In-Reply-To: References: Date: Fri, 18 Apr 2014 15:15:26 -0700 Message-ID: From: David Meyer To: "Palani Chinnakannan (pals)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LHAZqXuvoPYlBfmiPa2WKqyM114 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Jeff Tantsura , "Jan Medved \(jmedved\)" , Geoffrey Mattson Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 22:15:35 -0000 Likewise: +1 for Netconf/YANG for the i2rs protocol and for YANG as the modeling language. --dmm On Fri, Apr 18, 2014 at 3:14 PM, Palani Chinnakannan (pals) wrote: > +1 > We have been saying this for a quite sometime :-) > > pals > > On 4/18/14 3:11 PM, "Geoffrey Mattson" wrote: > >>+1 for Netconf for the I2RS protocol and YANG for the modeling language. >> >>On 4/18/14 3:04 PM, "Jeff Tantsura" wrote: >> >>>+1 for Netconf/YANG for the i2rs protocol and for YANG as >>>the modeling language. >>> >>> >>>Cheers, >>>Jeff >>> >>> >>>-----Original Message----- >>>From: "Jan Medved (jmedved)" >>>Date: Friday, April 18, 2014 1:59 PM >>>To: Dean Bogdanovic , Jamal Hadi Salim >>> >>>Cc: "i2rs@ietf.org" , Edward Crabbe >>>Subject: Re: [i2rs] consensus on I2RS protocol and model >>> >>>>Cisco is also implementing Netconf - it=C2=B9s available on XR today, a= nd it >>>>will be available on other platforms as well. >>>> >>>>For OpenDaylight, we chose Yang as the IDL to describe internal and >>>>external APIs in the controller and so far it has served its purpose >>>>really well. >>>> >>>>Also, as Tom pointed out, Netconf and Restconf have also been >>>>implemented >>>>in ODL. I=C2=B9d like to stress that we not only have multiple >>>>Netconf/Restconf >>>>implementations from multiple vendors (Brocade, Juniper, Cisco, just to >>>>mention those on this thread), but have multiple open source >>>>implementations as well. In addition to ODL, there is libnetconfd and a >>>>few others. ODL / libnetconfd interop testing is done in the ODL >>>>regression test suite. Now, since there are multiple independent open >>>>source implementations, we=C2=B9ve got a good ecosystem for implementat= ion of >>>>new Netconf/Restconf/Yang features that may be required to meet i2rs=C2= =B9s >>>>needs (if the need to evolve the protocols/language arises). >>>> >>>>In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as >>>>the modeling language. >>>> >>>> >>>> >>>>Thanks, >>>>Jan >>>> >>>> >>>>On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >>>> >>>>>Jamal, >>>>> >>>>>Here are two criteria to be considered: >>>>>1. technical >>>>>2. commercial/business >>>>> >>>>>We can discuss pros and cons for both, but have to state that from >>>>>business perspective for Juniper going with RESTCONF/YANG make more >>>>>sense. We already built the Junos model in YANG and >>>>>have or are in process of building needed tools. Same goes for >>>>>RESTCONF. >>>>>We have NETCONF implemented in Junos and are working on RESTCONF >>>>>implementation. >>>>>Many carriers adopted or are adopting NETCONF/YANG, are looking into >>>>>RESTCONF as well, so this looks like a low hanging fruit from business >>>>>perspective. >>>>> >>>>>Looking at technical aspect, unless there is a very compelling reason >>>>>(and there might be, but I'm not aware of it), don't see reason to >>>>>switch >>>>>from RESTCONF and YANG. >>>>>We can find out down the line that RESTCONF/YANG was the wrong way to >>>>>go, >>>>>but that can be always changed. From my perspective it looks right >>>>>today. >>>>> >>>>>Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>>> >>>>>Dean >>>>> >>>>>On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim >>>>>wrote: >>>>> >>>>>> Ok, since nobody is saying anything i'll bite. >>>>>> How would you like for this discussion to proceed? >>>>>> >>>>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe >>>>>>wrote: >>>>>>> Dear I2RSers, >>>>>>> >>>>>>> At the last I2RS WG meeting there was a great deal of conversation >>>>>>> regarding selection of both modeling language and underlying >>>>>>>transport >>>>>>> protocol. Consensus at the time was to make use of Yang and >>>>>>>(NetConf >>>>>>>or >>>>>>> RestConf) (unclear). >>>>>>> >>>>>> >>>>>> And i believe the view, as correctly presented by you, is for folks >>>>>>to >>>>>>go back >>>>>> and make educated decisions by actually getting knowledgeable about >>>>>> the different views presented. "Consensus" that you described above >>>>>> to me looked like a pageant popularity contest not based on anythin= g >>>>>> technical ("who likes contestant in the blue shirt? please cheer for >>>>>>them"). >>>>>> >>>>>> In my opinion i dont think the requirements are clear. >>>>>> >>>>>> Will that get the crickets stop chirping? >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>>> Before coming to a final consensus, we'd like to give people >>>>>>>adequate >>>>>>>time >>>>>>> to review source material, marshall arguments and discuss on the >>>>>>>mailing >>>>>>> list. To this end, we're asking that interested parties do just >>>>>>>this >>>>>>>over >>>>>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>>>>we'll be >>>>>>> initiating a consensus call that will last an additional two weeks, >>>>>>>with the >>>>>>> aim of converging modeling language / protocol by Friday, 5/9. >>>>>>> >>>>>>> The consensus call should also generate proposals for any material >>>>>>>changes >>>>>>> required to the underlying protocols. These proposals in turn will >>>>>>>form the >>>>>>> basis for a later draft including gap analysis and said changes. >>>>>>>Those >>>>>>> strongly in favor of one protocol over another should be prepared t= o >>>>>>> contribute to this analysis. >>>>>>> >>>>>>> >>>>>>> best, >>>>>>> >>>>>>> -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 >>>>>> >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>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 >> >>_______________________________________________ >>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 nobody Fri Apr 18 16:10:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80D11A0484 for ; Fri, 18 Apr 2014 16:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLv_ncDYWNVm for ; Fri, 18 Apr 2014 16:10:23 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5626F1A04AC for ; Fri, 18 Apr 2014 16:10:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Edward Crabbe'" , References: In-Reply-To: Date: Fri, 18 Apr 2014 19:10:16 -0400 Message-ID: <008201cf5b5b$5ca25dd0$15e71970$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CF5B39.D591F650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+pfnf2dQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xDaFU2XpeyTFb1rAmOIiVt7xQ0w Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:10:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CF5B39.D591F650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mr. Ed, our wonderful and delightful co-chair: This thread is address to the basic assumptions I've of the Yang/Netconf decision is based on, and not a yes or no on the draft. However, your insights will help me cast my vote as an engineer without emotional sway. My sources: I have been working under an assumption of I2rs informational models and I2RS data models that I would like to confirm in this discussion. My assumption comes from discussion with Benoit Claise (OPS/NM area AD) whose wisdom on NM guides the yang/netmod/netconf/ipfix world. I have been equally listening to Andy Beirman. and Jamal Salim. I recommend buying liquid libations to these fonts of wisdom. The assumption: I am assuming that the information models are not a waste of time. Jeff Haas' comment was isn't having information models and data models a duplication of effort. First of all, RBNF and ABNF seem to be causing redundant issues in the draft-ietf-i2rs-rib-info-model-02 draft. The ABNF the delightful work in draft-clarke-i2rs-traceability-01 really difficult to follow. My assumption had been the following train would occur: UML graphic (readable) || VV (someday via tool) UML text (readable) || (via tools - I've already found some) || VV Yang/Forces Data Model (Yang readable/Forces:Readable) || || (tools to create) XML syntax (yang/forces) / binary syntax (forces) | | | | (tools to create) V V Code inserted For validation of the code in the router Code || (tools creates) XML || (tool creates) Yang/Forces Data model || (tool creates) UML syntax || (tool creates) UML diagrams Why is this chain of events important to me? Validation of Code and structures. Is this any different that the tool chains for Yang/netmod/netconf or Forces/binary/binary? Nope. That's why I hope we can automate it. The goal behind picking a data model is to provide readability as we create these tool chains or to debug it. So.. font of wisdom from on high, can you let me know if I have misunderstood the point for information models and data models. Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Edward Crabbe Sent: Friday, April 11, 2014 1:51 PM To: i2rs@ietf.org Subject: [i2rs] consensus on I2RS protocol and model Dear I2RSers, At the last I2RS WG meeting there was a great deal of conversation regarding selection of both modeling language and underlying transport protocol. Consensus at the time was to make use of Yang and (NetConf or RestConf) (unclear). Before coming to a final consensus, we'd like to give people adequate time to review source material, marshall arguments and discuss on the mailing list. To this end, we're asking that interested parties do just this over the course of the next ~two weeks. Following that period, on 4/28, we'll be initiating a consensus call that will last an additional two weeks, with the aim of converging modeling language / protocol by Friday, 5/9. The consensus call should also generate proposals for any material changes required to the underlying protocols. These proposals in turn will form the basis for a later draft including gap analysis and said changes. Those strongly in favor of one protocol over another should be prepared to contribute to this analysis. best, -ed ------=_NextPart_000_0083_01CF5B39.D591F650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mr. Ed, our wonderful and delightful co-chair: =  

 

This thread is address to the basic assumptions I’ve  of = the Yang/Netconf decision is based on, and not a yes or no on the = draft.  However, your insights will help me cast my vote as an = engineer without emotional sway.  

 

My sources:

I have been working under an assumption of I2rs informational models = and I2RS data models that I would like to confirm in this discussion. =  My assumption comes from discussion with Benoit Claise (OPS/NM = area AD) whose wisdom on NM guides the yang/netmod/netconf/ipfix world. =   I have been equally listening to Andy Beirman.  and = Jamal Salim. I recommend buying liquid libations to these fonts of = wisdom.

 

The assumption:

I am assuming that the information models are not a waste of time. = Jeff Haas’ comment was isn’t having information models and = data models a duplication of effort.

 

First of all, RBNF and ABNF seem to be causing redundant issues in = the draft-ietf-i2rs-rib-info-model-02 draft.

The ABNF the delightful work in = draft-clarke-i2rs-traceability-01= really difficult to follow. 

 

My assumption had been the following train would = occur:

 

UML graphic (readable)

  ||

  VV  (someday via tool) =

UML = text  (readable)

  ||   (via tools – = I’ve already found some)

  ||

  VV

Yang/Forces Data Model (Yang = readable/Forces:Readable)   

    ||

    || (tools to create) =

 XML  syntax (yang/forces) / binary syntax = (forces)

  |  |

  |  | (tools to = create)

  V V

Code inserted

 

For validation of the code in the = router

=  Code

  || (tools creates) =

  XML

  ||  (tool creates) =

 Yang/Forces Data model =

  ||  (tool creates) =

UML = syntax

  ||  (tool creates) =

UML = diagrams

 

Why is this chain of events important to me?  Validation of Code = and structures.   Is this any different that the tool chains = for Yang/netmod/netconf or  Forces/binary/binary?  Nope.  = That’s why I hope we can automate it.  The goal behind = picking a data model is to provide readability as we create these tool = chains or to debug it.

 

So.. font of wisdom from on high, can you let me know if I have = misunderstood the point for information models and data models. =

 

Sue Hares

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Edward = Crabbe
Sent: Friday, April 11, 2014 1:51 PM
To: = i2rs@ietf.org
Subject: [i2rs] consensus on I2RS protocol and = model

 

Dear = I2RSers,


  At the last I2RS WG meeting there was a great = deal of conversation regarding selection of both modeling language and = underlying transport protocol.  Consensus at the time was to make = use of Yang and (NetConf or RestConf) (unclear). =  


  Before coming = to a final consensus, we’d like to give people adequate time to = review source material, marshall arguments and discuss on the mailing = list.  To this end, we’re asking that interested parties do = just this over the course of the next ~two weeks. Following that period, = on 4/28, we’ll be initiating a consensus call that will last an = additional two weeks, with the aim of converging modeling language / = protocol by Friday, 5/9.  

 

The consensus call should also generate proposals for = any material changes required to the underlying protocols.  These = proposals in turn will form the basis for a later draft including gap = analysis and said changes.  Those strongly in favor of one protocol = over another should be prepared to contribute to this = analysis. 


best,

  = -ed

------=_NextPart_000_0083_01CF5B39.D591F650-- From nobody Fri Apr 18 16:28:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2551A04B6 for ; Fri, 18 Apr 2014 16:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L6s1ovAcVL3 for ; Fri, 18 Apr 2014 16:28:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E5E681A0484 for ; Fri, 18 Apr 2014 16:28:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Dean Bogdanovic'" , "'Jamal Hadi Salim'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> Date: Fri, 18 Apr 2014 19:27:56 -0400 Message-ID: <009501cf5b5d$d49403f0$7dbc0bd0$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqmXy5DNoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Vi5YYcJ4ceIrGjBxE9zv340hjJk Cc: i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:28:07 -0000 Dean: Could you let me know what tool chains you consider necessary for RESTCONF/Yang? Do you start with informational models in the Yang/RESTCONF world? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Friday, April 18, 2014 9:18 AM To: Jamal Hadi Salim Cc: i2rs@ietf.org; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model Jamal, Here are two criteria to be considered: 1. technical 2. commercial/business We can discuss pros and cons for both, but have to state that from business perspective for Juniper going with RESTCONF/YANG make more sense. We already built the Junos model in YANG and have or are in process of building needed tools. Same goes for RESTCONF. We have NETCONF implemented in Junos and are working on RESTCONF implementation. Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so this looks like a low hanging fruit from business perspective. Looking at technical aspect, unless there is a very compelling reason (and there might be, but I'm not aware of it), don't see reason to switch from RESTCONF and YANG. We can find out down the line that RESTCONF/YANG was the wrong way to go, but that can be always changed. From my perspective it looks right today. Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. Dean On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > Ok, since nobody is saying anything i'll bite. > How would you like for this discussion to proceed? > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> Dear I2RSers, >> >> At the last I2RS WG meeting there was a great deal of conversation >> regarding selection of both modeling language and underlying >> transport protocol. Consensus at the time was to make use of Yang >> and (NetConf or >> RestConf) (unclear). >> > > And i believe the view, as correctly presented by you, is for folks to > go back and make educated decisions by actually getting knowledgeable > about the different views presented. "Consensus" that you described > above to me looked like a pageant popularity contest not based on > anything technical ("who likes contestant in the blue shirt? please cheer for them"). > > In my opinion i dont think the requirements are clear. > > Will that get the crickets stop chirping? > > cheers, > jamal > >> Before coming to a final consensus, we'd like to give people >> adequate time to review source material, marshall arguments and >> discuss on the mailing list. To this end, we're asking that >> interested parties do just this over the course of the next ~two >> weeks. Following that period, on 4/28, we'll be initiating a >> consensus call that will last an additional two weeks, with the aim of converging modeling language / protocol by Friday, 5/9. >> >> The consensus call should also generate proposals for any material >> changes required to the underlying protocols. These proposals in >> turn will form the basis for a later draft including gap analysis and >> said changes. Those strongly in favor of one protocol over another >> should be prepared to contribute to this analysis. >> >> >> best, >> >> -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 > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 18 16:41:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4861A0503 for ; Fri, 18 Apr 2014 16:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F_Xzqv60eWQ for ; Fri, 18 Apr 2014 16:41:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D5E971A0505 for ; Fri, 18 Apr 2014 16:41:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> In-Reply-To: Date: Fri, 18 Apr 2014 19:41:07 -0400 Message-ID: <00cd01cf5b5f$abd02780$03707680$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01CF5B3E.24C05C40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuQMuvjsDAniBsB+XkB1VcA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_5KMyb5UoWo3j7-PxihY8VUE_AI Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:41:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CF5B3E.24C05C40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Behcet: =20 The choice between two was because only two protocols groups (IETF = protocols at that!) suggested they met the requirements. The call has = been made at last 3+ meetings. Any new protocol that comes in must = prepare as much as Andy Bierman did and Jamal Salim did for IETF 89. =20 One other caveat=E2=80=A6 the protocol will need to make change so the = protocol must be under the change control of the IETF for I2rs use = Since, ONF has its own change control I suspect that also creates a = barrier.=20 =20 Sue=20 =20 From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Friday, April 18, 2014 11:57 AM To: Susan Hares Cc: Dean Bogdanovic; i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model =20 =20 =20 On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares wrote: Behcet:=20 =20 Can you tell me how the ONF Management and configuration protocol will = interface with the routing system with all the requirements set forth by = the architecture document? Please refer to version 2.0 architecture =20 =20 Don't get me wrong. I am not speaking in favor of OF-Config. But the point is that a more realistic choice should be between these = two choices. If the study showed that OF-Config did not meet the requirements, that = is fine but I heard no one said that. I wonder if the forces protocol meets these requirements? =20 Behcet=20 Or review to the presentation at IETF. If you can present these = features in email or any substantial way, we will listen. In my = observations, the ONF management protocol was designed for the ONF flows = and not the information models required or the use case required. =20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, April 18, 2014 11:32 AM To: Dean Bogdanovic Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model =20 Hi Dean, I attended i2rs session in London on this issue. My question is why ONF Management and Configuration protocol (OF-Config = 1.2) was not on the table. Regards, Behcet=20 =20 On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic = wrote: Jamal, Here are two criteria to be considered: 1. technical 2. commercial/business We can discuss pros and cons for both, but have to state that from = business perspective for Juniper going with RESTCONF/YANG make more = sense. We already built the Junos model in YANG and have or are in process of building needed tools. Same goes for RESTCONF. = We have NETCONF implemented in Junos and are working on RESTCONF = implementation. Many carriers adopted or are adopting NETCONF/YANG, are looking into = RESTCONF as well, so this looks like a low hanging fruit from business = perspective. Looking at technical aspect, unless there is a very compelling reason = (and there might be, but I'm not aware of it), don't see reason to = switch from RESTCONF and YANG. We can find out down the line that RESTCONF/YANG was the wrong way to = go, but that can be always changed. From my perspective it looks right = today. Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. Dean On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > Ok, since nobody is saying anything i'll bite. > How would you like for this discussion to proceed? > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> Dear I2RSers, >> >> At the last I2RS WG meeting there was a great deal of conversation >> regarding selection of both modeling language and underlying = transport >> protocol. Consensus at the time was to make use of Yang and (NetConf = or >> RestConf) (unclear). >> > > And i believe the view, as correctly presented by you, is for folks to = go back > and make educated decisions by actually getting knowledgeable about > the different views presented. "Consensus" that you described above > to me looked like a pageant popularity contest not based on anything > technical ("who likes contestant in the blue shirt? please cheer for = them"). > > In my opinion i dont think the requirements are clear. > > Will that get the crickets stop chirping? > > cheers, > jamal > >> Before coming to a final consensus, we'd like to give people = adequate time >> to review source material, marshall arguments and discuss on the = mailing >> list. To this end, we're asking that interested parties do just this = over >> the course of the next ~two weeks. Following that period, on 4/28, = we'll be >> initiating a consensus call that will last an additional two weeks, = with the >> aim of converging modeling language / protocol by Friday, 5/9. >> >> The consensus call should also generate proposals for any material = changes >> required to the underlying protocols. These proposals in turn will = form the >> basis for a later draft including gap analysis and said changes. = Those >> strongly in favor of one protocol over another should be prepared to >> contribute to this analysis. >> >> >> best, >> >> -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 > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_00CE_01CF5B3E.24C05C40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Behcet:

 

The choice between two was because only two protocols groups (IETF = protocols at that!) suggested they met the requirements. =C2=A0The call = has been made at last 3+ meetings. Any new protocol that comes in must = prepare as much as Andy Bierman did and Jamal Salim did for IETF = 89.

 

One other caveat=E2=80=A6 the protocol will need to make change so = the protocol must be under the change control of the IETF for I2rs use = =C2=A0Since, ONF has its own change control I suspect that also creates = a barrier.

 

Sue

 

From:= = Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: Friday, = April 18, 2014 11:57 AM
To: Susan Hares
Cc: Dean = Bogdanovic; i2rs@ietf.org; Edward Crabbe; Jamal Hadi = Salim
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 

 

 

On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <shares@ndzh.com> = wrote:

Behcet:

 

Can you tell me how the ONF Management and configuration protocol = will interface with the routing system with all the requirements set = forth by the architecture document?   Please refer to version = 2.0 architecture

 

 

Don't get me = wrong.

I am not speaking in favor of = OF-Config.

But the point is that a more realistic = choice should be between these two choices.

If the study showed that OF-Config did not meet the = requirements, that is fine but I heard no one said = that.

I wonder if the forces protocol meets = these requirements?

 

Behcet

Or review to the presentation at IETF.   If you can present = these features in email or any substantial way, we will listen.  In = my observations, the ONF management protocol was designed for the ONF = flows and not the information models required or the use case = required.  

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: = Dean Bogdanovic
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi = Salim
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi = Dean,

I attended = i2rs session in London on this issue.


My question = is why ONF Management and Configuration protocol (OF-Config 1.2) was not = on the table.

Regards,

Behcet =

 <= /p>

On Fri, Apr = 18, 2014 at 8:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:

Jamal,
Here are two criteria to be considered:
1. technical
2. = commercial/business

We can discuss pros and cons for both, but = have to state that from business perspective for Juniper going with = RESTCONF/YANG make more sense. We already built the Junos model in YANG = and
have or are in process of building needed tools. Same goes for = RESTCONF. We have NETCONF implemented in Junos and are working on = RESTCONF implementation.
Many carriers adopted or are adopting = NETCONF/YANG, are looking into RESTCONF as well, so this looks like a = low hanging fruit from business perspective.

Looking at technical = aspect, unless there is a very compelling reason (and there might be, = but I'm not aware of it), don't see reason to switch from RESTCONF and = YANG.
We can find out down the line that RESTCONF/YANG was the wrong = way to go, but that can be always changed. From my perspective it looks = right today.

Just to be clear, I vote for RESTCONF/YANG adoption = for i2rs.

Dean


On Apr = 18, 2014, at 7:27 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> Ok, since = nobody is saying anything i'll bite.
> How would you like for this = discussion to proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, = Edward Crabbe <edc@google.com> wrote:
>> Dear = I2RSers,
>>
>>  At the last I2RS WG meeting there = was a great deal of conversation
>> regarding selection of both = modeling language and underlying transport
>> protocol. =  Consensus at the time was to make use of Yang and (NetConf = or
>> RestConf) (unclear).
>>
>
> And i = believe the view, as correctly presented by you, is for folks to go = back
> and make educated decisions by actually getting = knowledgeable about
> the different views presented. = "Consensus" that you described above
> to me looked like =  a pageant popularity contest not based on anything
> = technical ("who likes contestant in the blue shirt? please cheer = for them").
>
> In my opinion i dont think the = requirements are clear.
>
> Will that get the crickets stop = chirping?
>
> cheers,
> jamal
>
>> =  Before coming to a final consensus, we'd like to give people = adequate time
>> to review source material, marshall arguments = and discuss on the mailing
>> list.  To this end, we're = asking that interested parties do just this over
>> the course = of the next ~two weeks. Following that period, on 4/28, we'll = be
>> initiating a consensus call that will last an additional = two weeks, with the
>> aim of converging modeling language / = protocol by Friday, 5/9.
>>
>> The consensus call = should also generate proposals for any material changes
>> = required to the underlying protocols.  These proposals in turn will = form the
>> basis for a later draft including gap analysis and = said changes.  Those
>> strongly in favor of one protocol = over another should be prepared to
>> contribute to this = analysis.
>>
>>
>> = best,
>>
>>  -ed
>>
>> = _______________________________________________
>> i2rs mailing = list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
><= br>>


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

 <= /o:p>

 

------=_NextPart_000_00CE_01CF5B3E.24C05C40-- From nobody Fri Apr 18 16:42:36 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F241A0505 for ; Fri, 18 Apr 2014 16:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8HneR51WvMO for ; Fri, 18 Apr 2014 16:42:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC5131A0503 for ; Fri, 18 Apr 2014 16:42:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> In-Reply-To: Date: Fri, 18 Apr 2014 19:42:18 -0400 Message-ID: <00da01cf5b5f$d63fcd40$82bf67c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01CF5B3E.4F2FDAF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuQMuvjsDAniBsB+XkB7FUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eiyXmY5YfvQTLgNLmdGhPboD_aI Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:42:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DB_01CF5B3E.4F2FDAF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Behcet: =20 The burden of proof was on the group that proposed the forces/forces or = yang/netconf models.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, April 18, 2014 11:57 AM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Dean Bogdanovic; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model =20 =20 =20 On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares wrote: Behcet:=20 =20 Can you tell me how the ONF Management and configuration protocol will = interface with the routing system with all the requirements set forth by = the architecture document? Please refer to version 2.0 architecture =20 =20 Don't get me wrong. I am not speaking in favor of OF-Config. But the point is that a more realistic choice should be between these = two choices. If the study showed that OF-Config did not meet the requirements, that = is fine but I heard no one said that. I wonder if the forces protocol meets these requirements? =20 Behcet=20 Or review to the presentation at IETF. If you can present these = features in email or any substantial way, we will listen. In my = observations, the ONF management protocol was designed for the ONF flows = and not the information models required or the use case required. =20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Friday, April 18, 2014 11:32 AM To: Dean Bogdanovic Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model =20 Hi Dean, I attended i2rs session in London on this issue. My question is why ONF Management and Configuration protocol (OF-Config = 1.2) was not on the table. Regards, Behcet=20 =20 On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic = wrote: Jamal, Here are two criteria to be considered: 1. technical 2. commercial/business We can discuss pros and cons for both, but have to state that from = business perspective for Juniper going with RESTCONF/YANG make more = sense. We already built the Junos model in YANG and have or are in process of building needed tools. Same goes for RESTCONF. = We have NETCONF implemented in Junos and are working on RESTCONF = implementation. Many carriers adopted or are adopting NETCONF/YANG, are looking into = RESTCONF as well, so this looks like a low hanging fruit from business = perspective. Looking at technical aspect, unless there is a very compelling reason = (and there might be, but I'm not aware of it), don't see reason to = switch from RESTCONF and YANG. We can find out down the line that RESTCONF/YANG was the wrong way to = go, but that can be always changed. From my perspective it looks right = today. Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. Dean On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > Ok, since nobody is saying anything i'll bite. > How would you like for this discussion to proceed? > > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> Dear I2RSers, >> >> At the last I2RS WG meeting there was a great deal of conversation >> regarding selection of both modeling language and underlying = transport >> protocol. Consensus at the time was to make use of Yang and (NetConf = or >> RestConf) (unclear). >> > > And i believe the view, as correctly presented by you, is for folks to = go back > and make educated decisions by actually getting knowledgeable about > the different views presented. "Consensus" that you described above > to me looked like a pageant popularity contest not based on anything > technical ("who likes contestant in the blue shirt? please cheer for = them"). > > In my opinion i dont think the requirements are clear. > > Will that get the crickets stop chirping? > > cheers, > jamal > >> Before coming to a final consensus, we'd like to give people = adequate time >> to review source material, marshall arguments and discuss on the = mailing >> list. To this end, we're asking that interested parties do just this = over >> the course of the next ~two weeks. Following that period, on 4/28, = we'll be >> initiating a consensus call that will last an additional two weeks, = with the >> aim of converging modeling language / protocol by Friday, 5/9. >> >> The consensus call should also generate proposals for any material = changes >> required to the underlying protocols. These proposals in turn will = form the >> basis for a later draft including gap analysis and said changes. = Those >> strongly in favor of one protocol over another should be prepared to >> contribute to this analysis. >> >> >> best, >> >> -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 > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_00DB_01CF5B3E.4F2FDAF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Behcet:

 

The burden of proof was on the group that proposed the forces/forces = or yang/netconf models.

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: Friday, April 18, 2014 11:57 AM
To: = Susan Hares
Cc: i2rs@ietf.org; Edward Crabbe; Dean Bogdanovic; = Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS = protocol and model

 

 

 

On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <shares@ndzh.com> = wrote:

Behcet:

 

Can you tell me how the ONF Management and configuration protocol = will interface with the routing system with all the requirements set = forth by the architecture document?   Please refer to version = 2.0 architecture

 

 

Don't get me = wrong.

I am not speaking in favor of = OF-Config.

But the point is that a more realistic = choice should be between these two choices.

If the study showed that OF-Config did not meet the = requirements, that is fine but I heard no one said = that.

I wonder if the forces protocol meets = these requirements?

 

Behcet

Or review to the presentation at IETF.   If you can present = these features in email or any substantial way, we will listen.  In = my observations, the ONF management protocol was designed for the ONF = flows and not the information models required or the use case = required.  

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: = Dean Bogdanovic
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi = Salim
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi = Dean,

I attended = i2rs session in London on this issue.


My question = is why ONF Management and Configuration protocol (OF-Config 1.2) was not = on the table.

Regards,

Behcet =

 <= /p>

On Fri, Apr = 18, 2014 at 8:17 AM, Dean Bogdanovic <deanb@juniper.net> wrote:

Jamal,
Here are two criteria to be considered:
1. technical
2. = commercial/business

We can discuss pros and cons for both, but = have to state that from business perspective for Juniper going with = RESTCONF/YANG make more sense. We already built the Junos model in YANG = and
have or are in process of building needed tools. Same goes for = RESTCONF. We have NETCONF implemented in Junos and are working on = RESTCONF implementation.
Many carriers adopted or are adopting = NETCONF/YANG, are looking into RESTCONF as well, so this looks like a = low hanging fruit from business perspective.

Looking at technical = aspect, unless there is a very compelling reason (and there might be, = but I'm not aware of it), don't see reason to switch from RESTCONF and = YANG.
We can find out down the line that RESTCONF/YANG was the wrong = way to go, but that can be always changed. From my perspective it looks = right today.

Just to be clear, I vote for RESTCONF/YANG adoption = for i2rs.

Dean


On Apr = 18, 2014, at 7:27 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

> Ok, since = nobody is saying anything i'll bite.
> How would you like for this = discussion to proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, = Edward Crabbe <edc@google.com> wrote:
>> Dear = I2RSers,
>>
>>  At the last I2RS WG meeting there = was a great deal of conversation
>> regarding selection of both = modeling language and underlying transport
>> protocol. =  Consensus at the time was to make use of Yang and (NetConf = or
>> RestConf) (unclear).
>>
>
> And i = believe the view, as correctly presented by you, is for folks to go = back
> and make educated decisions by actually getting = knowledgeable about
> the different views presented. = "Consensus" that you described above
> to me looked like =  a pageant popularity contest not based on anything
> = technical ("who likes contestant in the blue shirt? please cheer = for them").
>
> In my opinion i dont think the = requirements are clear.
>
> Will that get the crickets stop = chirping?
>
> cheers,
> jamal
>
>> =  Before coming to a final consensus, we'd like to give people = adequate time
>> to review source material, marshall arguments = and discuss on the mailing
>> list.  To this end, we're = asking that interested parties do just this over
>> the course = of the next ~two weeks. Following that period, on 4/28, we'll = be
>> initiating a consensus call that will last an additional = two weeks, with the
>> aim of converging modeling language / = protocol by Friday, 5/9.
>>
>> The consensus call = should also generate proposals for any material changes
>> = required to the underlying protocols.  These proposals in turn will = form the
>> basis for a later draft including gap analysis and = said changes.  Those
>> strongly in favor of one protocol = over another should be prepared to
>> contribute to this = analysis.
>>
>>
>> = best,
>>
>>  -ed
>>
>> = _______________________________________________
>> i2rs mailing = list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;
>
> = _______________________________________________
> i2rs mailing = list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
><= br>>


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

 <= /o:p>

 

------=_NextPart_000_00DB_01CF5B3E.4F2FDAF0-- From nobody Fri Apr 18 16:52:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E861A053B for ; Fri, 18 Apr 2014 16:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyDAlat0cday for ; Fri, 18 Apr 2014 16:51:58 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AF4881A0535 for ; Fri, 18 Apr 2014 16:51:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jamal Hadi Salim'" , "'Thomas Nadeau'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> In-Reply-To: Date: Fri, 18 Apr 2014 19:51:10 -0400 Message-ID: <00e701cf5b61$1341d2f0$39c578d0$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkC4OP6iAINsCOdAnFEb3KXkJaIwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CGxIC6mJ9VlsB8xWFAY_q_XCAjU Cc: i2rs@ietf.org, 'Crabbe Edward' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:52:02 -0000 Jamal and Tom: Dean Bogdanovic and Ron Bonica clearly indicated there were two reasons: business and technical. My understanding is that Ed Crabbe's context for this discussion was to judge technical merit. Did I misunderstand the context of this discussion to be engineering? If this is an engineering discussion - Tom it would be helpful to discuss the engineering reasons for Brocade's choice for restconf/yang. Some good engineering reasons might be that the Vyatta acquisition provided them with a tool chain that was ready for the restconf/yang. You could further comment on if the Vyatta deployments with restconf/yang were able to pull massive amount of routes or status? Did early deployments of Vyatta's took chain in data centers or WAN networks encounter any problems? Did you easily integrate new features? The web buzz on this sounds like a bee-hive buzzing, so ... the engineering details would be great. And since Vyatta is open source ... Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Friday, April 18, 2014 12:03 PM To: Thomas Nadeau Cc: i2rs@ietf.org; Crabbe Edward; Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model I dont think a post like this is useful. State your reasons please - just cheering on is not helpful. cheers, jamal On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau wrote: > > Sorry for the top post, but I wanted to inject that for the record, Brocade is in favor of using RestConf/Yang (or variations of those) for I2RS. We have no interest in using FORCES as the basis for this. > > --Tom > > > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim wrote: > >> On Fri, Apr 18, 2014 at 9:17 AM, Dean Bogdanovic wrote: >>> Jamal, >>> >>> Here are two criteria to be considered: >>> 1. technical >>> 2. commercial/business >>> >>> We can discuss pros and cons for both, but have to state that from >>> business perspective for Juniper going with RESTCONF/YANG make more >>> sense. We already built the Junos model in YANG and have or are in process of building needed tools. >>> Same goes for RESTCONF. We have NETCONF implemented in Junos and are >>> working on RESTCONF implementation. >>> Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF as well, so >this looks like a low hanging fruit from business perspective. >>> >> >> Thanks for being sincere Dean. >> First, I will say I empathize with your view above (I understand such >> a view is motivation for many unfortunately often disguised as >> technical opinion). While i empathize, I would like to point that we >> need to have these discussions which are technical otherwise there is >> no point in having a standard. >> In any case I get where you are coming from. >> >>> Looking at technical aspect, unless there is a very compelling >>> reason (and there might be, but I'm not aware of it), don't see reason to switch from RESTCONF and YANG. >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - >> I'll start with >> 1 or 2 of what i think are requirements against protocol/model so we >> dont have to respond to long emails. If you have issues with ForCES >> please bring them up as well and we can discuss (I brought up a few >> in my presentation). >> >> One of the issues was throughput and latency. >> You stated in London that you want to be able to do a large amount of >> updates/sec. >> Other than you - I cant get anyone else to say this is a requirement. >> I do believe it is. >> It will be useful for example to come up with some hand waving >> numbers against some agreed-to info model (eg the rib) and see how >> this requirement is met by the different protocols. >> >> As for the model, I'd like to quote from the minutes what Tom Petch >> (who i consider to be a sage in this space): >> "If I was writing an info model I'd use YANG every time. But if I >> was writing a data model I'd go for ForCES." >> And this is rooted in the nature of Yang being intended for Config. >> >> There is also the issue of i2rs ability to describe instances which >> is lacking in Yang; but maybe leave that out to a different email.. >> >> cheers, >> jamal >> >>> We can find out down the line that RESTCONF/YANG was the wrong way >>> to go, but that can be always changed. From my perspective it looks right today. >>> >>> Just to be clear, I vote for RESTCONF/YANG adoption for 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 nobody Fri Apr 18 16:55:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC031A053B for ; Fri, 18 Apr 2014 16:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1SHa-Gddmy3 for ; Fri, 18 Apr 2014 16:55:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 672E21A0527 for ; Fri, 18 Apr 2014 16:55:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jamal Hadi Salim'" , "'Thomas Nadeau'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <11BE70B4-52F1-4165-B474-66C6021123C1@lucidvision.com> In-Reply-To: Date: Fri, 18 Apr 2014 19:55:03 -0400 Message-ID: <00eb01cf5b61$9e332120$da996360$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuQMB6Dr5AbZyq9WXl5j2cA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TCpzzQGRTye4LNMqeqQQqvyOYgY Cc: i2rs@ietf.org, sarikaya@ieee.org, 'Crabbe Edward' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:55:16 -0000 Jamal: Were you looking for details on OF-Config? I've enjoyed our discussions of the OF-Config protocol - so this would be fun. However, my understanding is that any proposal for i2rs data model language/protocol needs to at least have one person who is willing to stand up and support it. Without someone to propose it, I suspect we are just delaying Mr. Ed's I2rs deadlines. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Friday, April 18, 2014 12:04 PM To: Thomas Nadeau Cc: i2rs@ietf.org; sarikaya@ieee.org; Crabbe Edward; Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model And what are those mysterious requirements it doesnt meet Thomas? cheers, jamal On Fri, Apr 18, 2014 at 11:47 AM, Thomas Nadeau wrote: > > I believe its because OF-Config does not meet the requirements we set forth. > > --Tom > > On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya > wrote: > > Hi Dean, > > I attended i2rs session in London on this issue. > > My question is why ONF Management and Configuration protocol > (OF-Config 1.2) was not on the table. > > Regards, > > Behcet > > > On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic wrote: >> >> Jamal, >> >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >> >> We can discuss pros and cons for both, but have to state that from >> business perspective for Juniper going with RESTCONF/YANG make more sense. >> We already built the Junos model in YANG and have or are in process >> of building needed tools. Same goes for RESTCONF. >> We have NETCONF implemented in Junos and are working on RESTCONF >> implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> RESTCONF as well, so this looks like a low hanging fruit from >> business perspective. >> >> Looking at technical aspect, unless there is a very compelling reason >> (and there might be, but I'm not aware of it), don't see reason to >> switch from RESTCONF and YANG. >> We can find out down the line that RESTCONF/YANG was the wrong way to >> go, but that can be always changed. From my perspective it looks right today. >> >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >> Dean >> >> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >> >> > Ok, since nobody is saying anything i'll bite. >> > How would you like for this discussion to proceed? >> > >> > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> >> Dear I2RSers, >> >> >> >> At the last I2RS WG meeting there was a great deal of >> >> conversation regarding selection of both modeling language and >> >> underlying transport protocol. Consensus at the time was to make >> >> use of Yang and (NetConf or >> >> RestConf) (unclear). >> >> >> > >> > And i believe the view, as correctly presented by you, is for folks >> > to go back and make educated decisions by actually getting >> > knowledgeable about the different views presented. "Consensus" that >> > you described above to me looked like a pageant popularity contest >> > not based on anything technical ("who likes contestant in the blue >> > shirt? please cheer for them"). >> > >> > In my opinion i dont think the requirements are clear. >> > >> > Will that get the crickets stop chirping? >> > >> > cheers, >> > jamal >> > >> >> Before coming to a final consensus, we'd like to give people >> >> adequate time to review source material, marshall arguments and >> >> discuss on the mailing list. To this end, we're asking that >> >> interested parties do just this over the course of the next ~two >> >> weeks. Following that period, on 4/28, we'll be initiating a >> >> consensus call that will last an additional two weeks, with the >> >> aim of converging modeling language / protocol by Friday, 5/9. >> >> >> >> The consensus call should also generate proposals for any material >> >> changes required to the underlying protocols. These proposals in >> >> turn will form the basis for a later draft including gap analysis >> >> and said changes. Those strongly in favor of one protocol over >> >> another should be prepared to contribute to this analysis. >> >> >> >> >> >> best, >> >> >> >> -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 >> > >> > >> >> >> _______________________________________________ >> 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 nobody Fri Apr 18 16:55:58 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F771A0535 for ; Fri, 18 Apr 2014 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caOrZbBlkt61 for ; Fri, 18 Apr 2014 16:55:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EDEC01A0552 for ; Fri, 18 Apr 2014 16:55:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jamal Hadi Salim'" , "'sarikaya'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> In-Reply-To: Date: Fri, 18 Apr 2014 19:55:45 -0400 Message-ID: <00ed01cf5b61$b72ba580$2582f080$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuQMuvjsDAniBsB8A7rWt0JeIrPpw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5ll6LaZddAJolJMqRj0xq9kIIvg Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:55:57 -0000 Jamal and Behcet: I will try to dig through the Use cases and get a list of requirement based on use cases. It will be a few days. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jamal Hadi Salim Sent: Friday, April 18, 2014 12:41 PM To: sarikaya Cc: i2rs@ietf.org; Edward Crabbe; Dean Bogdanovic; Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model On Fri, Apr 18, 2014 at 11:57 AM, Behcet Sarikaya wrote: > > > > On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares wrote: >> >> Behcet: >> >> >> >> Can you tell me how the ONF Management and configuration protocol >> will interface with the routing system with all the requirements set forth by the >> architecture document? Please refer to version 2.0 architecture >> >> > > > Don't get me wrong. > > I am not speaking in favor of OF-Config. > > But the point is that a more realistic choice should be between these > two choices. > Why? > If the study showed that OF-Config did not meet the requirements, that > is fine but I heard no one said that. > I wonder if the forces protocol meets these requirements? > > Only set of requirements i could find was what appears to be an abandoned draft here: http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00 Not sure i agree with some of the parts but it is what i used to present. I havent seen anything on the model. Overall requirements need to be considered. You know what would be really useful is to show up at the next meeting with implementations of I2RS - perhaps a few demos and discuss what the lessons learnt are. cheers, jamal > > Behcet >> >> Or review to the presentation at IETF. If you can present these features >> in email or any substantial way, we will listen. In my observations, >> the ONF management protocol was designed for the ONF flows and not >> the information models required or the use case required. >> >> >> >> Sue Hares >> >> >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Behcet >> Sarikaya >> Sent: Friday, April 18, 2014 11:32 AM >> To: Dean Bogdanovic >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> >> >> Hi Dean, >> >> I attended i2rs session in London on this issue. >> >> >> My question is why ONF Management and Configuration protocol >> (OF-Config >> 1.2) was not on the table. >> >> Regards, >> >> Behcet >> >> >> >> On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic >> wrote: >> >> Jamal, >> >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >> >> We can discuss pros and cons for both, but have to state that from >> business perspective for Juniper going with RESTCONF/YANG make more sense. >> We already built the Junos model in YANG and have or are in process >> of building needed tools. Same goes for RESTCONF. >> We have NETCONF implemented in Junos and are working on RESTCONF >> implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into >> RESTCONF as well, so this looks like a low hanging fruit from >> business perspective. >> >> Looking at technical aspect, unless there is a very compelling reason >> (and there might be, but I'm not aware of it), don't see reason to >> switch from RESTCONF and YANG. >> We can find out down the line that RESTCONF/YANG was the wrong way to >> go, but that can be always changed. From my perspective it looks right today. >> >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >> >> Dean >> >> >> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >> >> > Ok, since nobody is saying anything i'll bite. >> > How would you like for this discussion to proceed? >> > >> > On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >> >> Dear I2RSers, >> >> >> >> At the last I2RS WG meeting there was a great deal of >> >> conversation regarding selection of both modeling language and >> >> underlying transport protocol. Consensus at the time was to make >> >> use of Yang and (NetConf or >> >> RestConf) (unclear). >> >> >> > >> > And i believe the view, as correctly presented by you, is for folks >> > to go back and make educated decisions by actually getting >> > knowledgeable about the different views presented. "Consensus" that >> > you described above to me looked like a pageant popularity contest >> > not based on anything technical ("who likes contestant in the blue >> > shirt? please cheer for them"). >> > >> > In my opinion i dont think the requirements are clear. >> > >> > Will that get the crickets stop chirping? >> > >> > cheers, >> > jamal >> > >> >> Before coming to a final consensus, we'd like to give people >> >> adequate time to review source material, marshall arguments and >> >> discuss on the mailing list. To this end, we're asking that >> >> interested parties do just this over the course of the next ~two >> >> weeks. Following that period, on 4/28, we'll be initiating a >> >> consensus call that will last an additional two weeks, with the >> >> aim of converging modeling language / protocol by Friday, 5/9. >> >> >> >> The consensus call should also generate proposals for any material >> >> changes required to the underlying protocols. These proposals in >> >> turn will form the basis for a later draft including gap analysis >> >> and said changes. Those strongly in favor of one protocol over >> >> another should be prepared to contribute to this analysis. >> >> >> >> >> >> best, >> >> >> >> -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 >> > >> > >> >> >> _______________________________________________ >> 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 nobody Fri Apr 18 16:56:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC531A053B for ; Fri, 18 Apr 2014 16:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HekasB91d71O for ; Fri, 18 Apr 2014 16:56:52 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C34931A0535 for ; Fri, 18 Apr 2014 16:56:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , References: In-Reply-To: Date: Fri, 18 Apr 2014 19:56:42 -0400 Message-ID: <00ef01cf5b61$d91b6400$8b522c00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CF5B40.520A8750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1ARromV+20xeTIgCZUuGN6fm/q5rMwUcQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PwXj6hpocngPR3sPyIgi2UXyt4g Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:56:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F0_01CF5B40.520A8750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin: If it was to be a candidate, did you know someone who wanted to be the chief supporter in the IETF? Sue From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] Sent: Friday, April 18, 2014 12:47 PM To: sarikaya@ieee.org; Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Dean Bogdanovic; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model If the study showed that OF-Config did not meet the requirements, that is fine but I heard no one said that. On Feb 5th, Alia Atlas said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html > Gap Analysis for different Protocols: I2RS needs to select a protocol to use. I believe that we have volunteers for discussing RESTCONF. > We'd welcome hearing from others who can provide at least a presentation for review before IETF and preferably a quick draft as well. On Feb 27th, Ed Crabbe said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html > The I2RS agenda has been posted. Those who think OF-Config should have been a candidate, should have presented at the IETF; or at least started a discussion on the mailing list. My 2 cents Nitin ------=_NextPart_000_00F0_01CF5B40.520A8750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin:

 

If it was to be a candidate, did you know someone who wanted to be = the chief supporter in the IETF?

 

Sue

 

From:= = Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]
Sent: Friday, = April 18, 2014 12:47 PM
To: sarikaya@ieee.org; Susan = Hares
Cc: i2rs@ietf.org; Edward Crabbe; Dean Bogdanovic; Jamal = Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 

 

 

If the study showed that OF-Config did not meet the requirements, that = is fine but I heard no one said that.

 

 

 

> Gap Analysis for different Protocols:  I2RS needs to select a = protocol to use.  I believe that we have volunteers for discussing = RESTCONF. 

> We'd welcome hearing from others who can provide at least a = presentation for review before IETF and preferably a quick draft as = well.

 

> The I2RS agenda has been posted. =  

 

Those who think OF-Config should have been a candidate, should have = presented at the IETF; or at least started a discussion on the mailing = list.

 

My 2 cents

Nitin

------=_NextPart_000_00F0_01CF5B40.520A8750-- From nobody Fri Apr 18 17:00:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24601A0535 for ; Fri, 18 Apr 2014 16:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cRGSrOVtuZC for ; Fri, 18 Apr 2014 16:59:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 34DCB1A0527 for ; Fri, 18 Apr 2014 16:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9644; q=dns/txt; s=iport; t=1397865591; x=1399075191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=plWwZGapejWUTYZDZgh0d4X41VBR5LRKNqr5xrCEwps=; b=XzhDu9xHxFPBtRJ+iSwghr9R4jGEwAZMppE+Bb+At/XQ7sNcT8tFcjfD QBBEMnqCjcl0KrrDdGx5isOzeIBeipsZSmic3KVVvBG8nNd2MPdKwB/Jj tH7ceGvfqDqm8ghw7xHmJ7MFQlrcL3I0LsZplwepdUtGExRN0XwCHUd3B 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAOG7UVOtJV2c/2dsb2JhbABagwZPV4MPuSyHPBmBARZ0giUBAQEDAQEBATEzBwsQAgEIGAQoAgIlCyUCBA4FFIglCA2NVZwTBqNMEwSBI4gahSUHgmmBTwSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="37038545" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 18 Apr 2014 23:59:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3INxogA004425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 23:59:50 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 18:59:50 -0500 From: "Jan Medved (jmedved)" To: Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwA= Date: Fri, 18 Apr 2014 23:59:49 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.168] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1OzaLlpmZEMa0bs_97QkcLG71gY Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 00:00:00 -0000 DQoNCk9uIDQvMTgvMTQsIDI6MTIgUE0sICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUBtb2phdGF0 dS5jb20+IHdyb3RlOg0KDQo+T24gRnJpLCBBcHIgMTgsIDIwMTQgYXQgNDo1OSBQTSwgSmFuIE1l ZHZlZCAoam1lZHZlZCkgPGptZWR2ZWRAY2lzY28uY29tPg0KPndyb3RlOg0KPj4gQ2lzY28gaXMg YWxzbyBpbXBsZW1lbnRpbmcgTmV0Y29uZiAtIGl0qfZzIGF2YWlsYWJsZSBvbiBYUiB0b2RheSwg YW5kIGl0DQo+PiB3aWxsIGJlIGF2YWlsYWJsZSBvbiBvdGhlciBwbGF0Zm9ybXMgYXMgd2VsbC4N Cj4+DQo+PiBGb3IgT3BlbkRheWxpZ2h0LCB3ZSBjaG9zZSBZYW5nIGFzIHRoZSBJREwgdG8gZGVz Y3JpYmUgaW50ZXJuYWwgYW5kDQo+PiBleHRlcm5hbCBBUElzIGluIHRoZSBjb250cm9sbGVyIGFu ZCBzbyBmYXIgaXQgaGFzIHNlcnZlZCBpdHMgcHVycG9zZQ0KPj4gcmVhbGx5IHdlbGwuDQo+Pg0K Pg0KPlRoaXMgaGFzIG5vdGhpbmcgIHRvIGRvIHdpdGggbWVldGluZyByZXF1aXJlbWVudHMgZm9y IEkyUlMuDQoNClN1cmUgaXQgZG9lcy4gSTJSUyBpcyB1bHRpbWF0ZWx5IGFib3V0IGEgc2V0IG9m IHByb2dyYW1tYXRpYyBBUElzIHRvIHRoZQ0Kcm91dGluZyBzeXN0ZW0uIFRoZSBjb250cm9sbGVy IHByb2dyYW1tYXRpYyBBUEkgaXMgYSBzdXBlcnNldCBvZiBhIGRldmljZQ0KcHJvZ3JhbW1hdGlj IEFQSSwgc2luY2UgdGhlIGNvbnRyb2xsZXIgbXVzdCBiZSBhYmxlIHRvIHByb3h5IHRoZSBkZXZp Y2UNCmFuZCBwcm92aWRlIHByb2dyYW1tYXRpYyBBUElzIHRvIGl0cyBvd24gc2VydmljZXMuIE5v dywgaWYgYW4gSURMIGhhcw0KcHJvdmVuIHRvIGJlIHVzZWZ1bCBhbmQvb3IgbWVldCB0aGUgcmVx dWlyZW1lbnRzIGluIGEgZW52aXJvbm1lbnQgd2hpY2ggaXMNCmEgc3VwZXJzZXQgb2YgdGhlIHRh cmdldCBlbnZpcm9ubWVudCwgdGhlbiBieSBkZWZpbml0aW9uIGl0IHdpbGwgYmUgdXNlZnVsDQph bmQvb3IgbWVldCB0aGUgcmVxdWlyZW1lbnRzIGluIHRoZSB0YXJnZXQgZW52aXJvbm1lbnQuDQoN Cj4NCj4+IEFsc28sIGFzIFRvbSBwb2ludGVkIG91dCwgTmV0Y29uZiBhbmQgUmVzdGNvbmYgaGF2 ZSBhbHNvIGJlZW4NCj4+aW1wbGVtZW50ZWQNCj4+IGluIE9ETC4gSan2ZCBsaWtlIHRvIHN0cmVz cyB0aGF0IHdlIG5vdCBvbmx5IGhhdmUgbXVsdGlwbGUNCj4+TmV0Y29uZi9SZXN0Y29uZg0KPj4g aW1wbGVtZW50YXRpb25zIGZyb20gbXVsdGlwbGUgdmVuZG9ycyAoQnJvY2FkZSwgSnVuaXBlciwg Q2lzY28sIGp1c3QgdG8NCj4+IG1lbnRpb24gdGhvc2Ugb24gdGhpcyB0aHJlYWQpLCBidXQgaGF2 ZSBtdWx0aXBsZSBvcGVuIHNvdXJjZQ0KPj4gaW1wbGVtZW50YXRpb25zIGFzIHdlbGwuIEluIGFk ZGl0aW9uIHRvIE9ETCwgdGhlcmUgaXMgbGlibmV0Y29uZmQgYW5kIGENCj4+IGZldyBvdGhlcnMu ICBPREwgLyBsaWJuZXRjb25mZCBpbnRlcm9wIHRlc3RpbmcgaXMgZG9uZSBpbiB0aGUgT0RMDQo+ PiByZWdyZXNzaW9uIHRlc3Qgc3VpdGUuDQo+DQo+QWdhaW4gLSBJIGFtIG5vdCBoZWFyaW5nIHJl cXVpcmVtZW50cyBhZ2FpbnN0IEkyUlMuDQo+SGF2ZSB5b3UgaW1wbGVtZW50ZWQgSTJSUyB3aXRo IG5ldGNvbmYvcmVzdGNvbmYveWFuZz8NCg0KTm9ib2R5IGhhcyBpbXBsZW1lbnRlZCBJMlJTLCBi ZWNhdXNlIHRoZSBwcm90b2NvbCBoYXMgbm90IGJlZW4gZGVmaW5lZA0KeWV0LiBCdXQgSSB3YXMg ZGVlcGx5IGludm9sdmVkIHdpdGggTmV0Y29uZi9SZXN0Y29uZi9ZYW5nIGltcGxlbWVudGF0aW9u cw0Kb24gYm90aCBJT1MtWFIgYW5kIG9uIE9wZW5EYXlsaWdodC4gSW4gYW55IGNhc2UsIE5ldGNv bmYvUmVzdGNvbmYvWWFuZw0KZ2l2ZXMgdXMgdG9kYXkgbWF5YmUgODAtOTAlIG9mIHdoYXQgd2Ug bmVlZCBmcm9tIEkyUlMgZm9yIG91ciB1c2UgY2FzZXMuDQoNCj4NCj4+IE5vdywgc2luY2UgdGhl cmUgYXJlIG11bHRpcGxlIGluZGVwZW5kZW50IG9wZW4NCj4+IHNvdXJjZSBpbXBsZW1lbnRhdGlv bnMsIHdlqfZ2ZSBnb3QgYSBnb29kIGVjb3N5c3RlbSBmb3IgaW1wbGVtZW50YXRpb24gb2YNCj4+ IG5ldyBOZXRjb25mL1Jlc3Rjb25mL1lhbmcgZmVhdHVyZXMgdGhhdCBtYXkgYmUgcmVxdWlyZWQg dG8gbWVldCBpMnJzqfZzDQo+PiBuZWVkcyAoaWYgdGhlIG5lZWQgdG8gZXZvbHZlIHRoZSBwcm90 b2NvbHMvbGFuZ3VhZ2UgYXJpc2VzKS4NCj4+DQo+DQo+SSBkb250IHRoaW5rIHRoaXMgc291bmRz IHJhdGlvbmFsIGF0IGFsbC4gSFRUUCBoYXMgYSBiaWdnZXIgZWNvc3lzdGVtDQo+dGhhbiB5b3Uu DQo+V2h5IG5vdCBidWlsZCBhcm91bmQgdGhhdCBhbmQgdGhlbiByZWZhY3RvciBhcyBuZWVkZWQ/ DQoNCkJpbmdvISBIb3cgYWJvdXQgUmVzdGNvbmYgd2l0aCBKU09OIGVuY29kaW5nPyA7LSkNCg0K PldoeSBpcyBpdCBzbyBoYXJkIHRvIGdldCByZXF1aXJlbWVudHMgYXJvdW5kIGhlcmU/ICBXaGF0 IGlzIHRoZSBwb2ludA0KPnRvIGEgc3RhbmRhcmQgYWdhaW4/DQoNClRoZSBJMlJTIHJlcXVpcmVt ZW50cyBoYXZlIGJlZW4gZ2F0aGVyZWQsIGFuZCBOZXRjb25mIGFuZCBZYW5nIGhhdmUgYmVlbg0K YW5hbHl6ZWQgYWdhaW5zdCB0aGUgcmVxdWlyZW1lbnRzIGJ5IEFuZHkgYW5kIERlYW4gYXQgdGhl IGxhc3QgSUVURi4gSQ0KZmluZCBubyBmYXVsdCBpbiB0aGVpciBhbmFseXNpcywgc28gSU1ITyBO ZXRjb25mIC8gWWFuZyAod2l0aCBwb3NzaWJseQ0Kc21hbGwgbW9kaWZpY2F0aW9ucykgd2lsbCBt ZWV0IHRoZSB0ZWNobmljYWwgcmVxdWlyZW1lbnRzIG9mIEkyUlMuDQoNCldoYXQgSSBhbmQgb3Ro ZXJzIGhhdmUgYmVlbiB0cnlpbmcgdG8gc2F5IGlzIHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHdvcmxk IGlzDQptb3ZpbmcgdG93YXJkcyBOZXRjb25mL1Jlc3Rjb25mL1lhbmcuIFRoZXJlZm9yZSwgKGJl c2lkZXMgaXQgYmVpbmcgYQ0KZ29vZC1lbm91Z2ggdGVjaG5pY2FsIGNob2ljZSksIGl0IGlzIHRo ZSBwcmFnbWF0aWMgY2hvaWNlLiBJZiBJMlJTIHdhbnRzDQp0byBiZSByZWxldmFudCB0byBvcGVy YXRvcnMsIHZlbmRvcnMsIGFuZCB0aGUgb3BlbiBzb3VyY2UgY29tbXVuaXR5LCBpdA0KbmVlZHMg dG8gZ28gd2hlcmUgYWxsIHRoZXNlIGVudGl0aWVzIHdhbnQgdG8gYmUuDQoNCj4NCj5jaGVlcnMs DQo+SmFtYWwNCg0KDQpUaGFua3MsDQpKYW4NCg0KPg0KPj4gSW4gc2hvcnQsICsxIGZvciBOZXRj b25mL1Jlc3Rjb25mIGZvciB0aGUgaTJycyBwcm90b2NvbCBhbmQgZm9yIFlhbmcgYXMNCj4+IHRo ZSBtb2RlbGluZyBsYW5ndWFnZS4NCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcywNCj4+IEphbg0KPj4N Cj4+DQo+PiBPbiA0LzE4LzE0LCA2OjE3IEFNLCAiRGVhbiBCb2dkYW5vdmljIiA8ZGVhbmJAanVu aXBlci5uZXQ+IHdyb3RlOg0KPj4NCj4+PkphbWFsLA0KPj4+DQo+Pj5IZXJlIGFyZSB0d28gY3Jp dGVyaWEgdG8gYmUgY29uc2lkZXJlZDoNCj4+PjEuIHRlY2huaWNhbA0KPj4+Mi4gY29tbWVyY2lh bC9idXNpbmVzcw0KPj4+DQo+Pj5XZSBjYW4gZGlzY3VzcyBwcm9zIGFuZCBjb25zIGZvciBib3Ro LCBidXQgaGF2ZSB0byBzdGF0ZSB0aGF0IGZyb20NCj4+PmJ1c2luZXNzIHBlcnNwZWN0aXZlIGZv ciBKdW5pcGVyIGdvaW5nIHdpdGggUkVTVENPTkYvWUFORyBtYWtlIG1vcmUNCj4+PnNlbnNlLiBX ZSBhbHJlYWR5IGJ1aWx0IHRoZSBKdW5vcyBtb2RlbCBpbiBZQU5HIGFuZA0KPj4+aGF2ZSBvciBh cmUgaW4gcHJvY2VzcyBvZiBidWlsZGluZyBuZWVkZWQgdG9vbHMuIFNhbWUgZ29lcyBmb3IgUkVT VENPTkYuDQo+Pj5XZSBoYXZlIE5FVENPTkYgaW1wbGVtZW50ZWQgaW4gSnVub3MgYW5kIGFyZSB3 b3JraW5nIG9uIFJFU1RDT05GDQo+Pj5pbXBsZW1lbnRhdGlvbi4NCj4+Pk1hbnkgY2FycmllcnMg YWRvcHRlZCBvciBhcmUgYWRvcHRpbmcgTkVUQ09ORi9ZQU5HLCBhcmUgbG9va2luZyBpbnRvDQo+ Pj5SRVNUQ09ORiBhcyB3ZWxsLCBzbyB0aGlzIGxvb2tzIGxpa2UgYSBsb3cgaGFuZ2luZyBmcnVp dCBmcm9tIGJ1c2luZXNzDQo+Pj5wZXJzcGVjdGl2ZS4NCj4+Pg0KPj4+TG9va2luZyBhdCB0ZWNo bmljYWwgYXNwZWN0LCB1bmxlc3MgdGhlcmUgaXMgYSB2ZXJ5IGNvbXBlbGxpbmcgcmVhc29uDQo+ Pj4oYW5kIHRoZXJlIG1pZ2h0IGJlLCBidXQgSSdtIG5vdCBhd2FyZSBvZiBpdCksIGRvbid0IHNl ZSByZWFzb24gdG8NCj4+PnN3aXRjaA0KPj4+ZnJvbSBSRVNUQ09ORiBhbmQgWUFORy4NCj4+Pldl IGNhbiBmaW5kIG91dCBkb3duIHRoZSBsaW5lIHRoYXQgUkVTVENPTkYvWUFORyB3YXMgdGhlIHdy b25nIHdheSB0bw0KPj4+Z28sDQo+Pj5idXQgdGhhdCBjYW4gYmUgYWx3YXlzIGNoYW5nZWQuIEZy b20gbXkgcGVyc3BlY3RpdmUgaXQgbG9va3MgcmlnaHQNCj4+PnRvZGF5Lg0KPj4+DQo+Pj5KdXN0 IHRvIGJlIGNsZWFyLCBJIHZvdGUgZm9yIFJFU1RDT05GL1lBTkcgYWRvcHRpb24gZm9yIGkycnMu DQo+Pj4NCj4+PkRlYW4NCj4+Pg0KPj4+T24gQXByIDE4LCAyMDE0LCBhdCA3OjI3IEFNLCBKYW1h bCBIYWRpIFNhbGltIDxoYWRpQG1vamF0YXR1LmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gT2ssIHNp bmNlIG5vYm9keSBpcyBzYXlpbmcgYW55dGhpbmcgaSdsbCBiaXRlLg0KPj4+PiBIb3cgd291bGQg eW91IGxpa2UgZm9yIHRoaXMgZGlzY3Vzc2lvbiB0byBwcm9jZWVkPw0KPj4+Pg0KPj4+PiBPbiBG cmksIEFwciAxMSwgMjAxNCBhdCAxOjUwIFBNLCBFZHdhcmQgQ3JhYmJlIDxlZGNAZ29vZ2xlLmNv bT4gd3JvdGU6DQo+Pj4+PiBEZWFyIEkyUlNlcnMsDQo+Pj4+Pg0KPj4+Pj4gIEF0IHRoZSBsYXN0 IEkyUlMgV0cgbWVldGluZyB0aGVyZSB3YXMgYSBncmVhdCBkZWFsIG9mIGNvbnZlcnNhdGlvbg0K Pj4+Pj4gcmVnYXJkaW5nIHNlbGVjdGlvbiBvZiBib3RoIG1vZGVsaW5nIGxhbmd1YWdlIGFuZCB1 bmRlcmx5aW5nDQo+Pj4+PnRyYW5zcG9ydA0KPj4+Pj4gcHJvdG9jb2wuICBDb25zZW5zdXMgYXQg dGhlIHRpbWUgd2FzIHRvIG1ha2UgdXNlIG9mIFlhbmcgYW5kIChOZXRDb25mDQo+Pj4+Pm9yDQo+ Pj4+PiBSZXN0Q29uZikgKHVuY2xlYXIpLg0KPj4+Pj4NCj4+Pj4NCj4+Pj4gQW5kIGkgYmVsaWV2 ZSB0aGUgdmlldywgYXMgY29ycmVjdGx5IHByZXNlbnRlZCBieSB5b3UsIGlzIGZvciBmb2xrcyB0 bw0KPj4+PmdvIGJhY2sNCj4+Pj4gYW5kIG1ha2UgZWR1Y2F0ZWQgZGVjaXNpb25zIGJ5IGFjdHVh bGx5IGdldHRpbmcga25vd2xlZGdlYWJsZSBhYm91dA0KPj4+PiB0aGUgZGlmZmVyZW50IHZpZXdz IHByZXNlbnRlZC4gIkNvbnNlbnN1cyIgdGhhdCB5b3UgZGVzY3JpYmVkIGFib3ZlDQo+Pj4+IHRv IG1lIGxvb2tlZCBsaWtlICBhIHBhZ2VhbnQgcG9wdWxhcml0eSBjb250ZXN0IG5vdCBiYXNlZCBv biBhbnl0aGluZw0KPj4+PiB0ZWNobmljYWwgKCJ3aG8gbGlrZXMgY29udGVzdGFudCBpbiB0aGUg Ymx1ZSBzaGlydD8gcGxlYXNlIGNoZWVyIGZvcg0KPj4+PnRoZW0iKS4NCj4+Pj4NCj4+Pj4gSW4g bXkgb3BpbmlvbiBpIGRvbnQgdGhpbmsgdGhlIHJlcXVpcmVtZW50cyBhcmUgY2xlYXIuDQo+Pj4+ DQo+Pj4+IFdpbGwgdGhhdCBnZXQgdGhlIGNyaWNrZXRzIHN0b3AgY2hpcnBpbmc/DQo+Pj4+DQo+ Pj4+IGNoZWVycywNCj4+Pj4gamFtYWwNCj4+Pj4NCj4+Pj4+ICBCZWZvcmUgY29taW5nIHRvIGEg ZmluYWwgY29uc2Vuc3VzLCB3ZSdkIGxpa2UgdG8gZ2l2ZSBwZW9wbGUNCj4+Pj4+YWRlcXVhdGUN Cj4+Pj4+dGltZQ0KPj4+Pj4gdG8gcmV2aWV3IHNvdXJjZSBtYXRlcmlhbCwgbWFyc2hhbGwgYXJn dW1lbnRzIGFuZCBkaXNjdXNzIG9uIHRoZQ0KPj4+Pj5tYWlsaW5nDQo+Pj4+PiBsaXN0LiAgVG8g dGhpcyBlbmQsIHdlJ3JlIGFza2luZyB0aGF0IGludGVyZXN0ZWQgcGFydGllcyBkbyBqdXN0IHRo aXMNCj4+Pj4+b3Zlcg0KPj4+Pj4gdGhlIGNvdXJzZSBvZiB0aGUgbmV4dCB+dHdvIHdlZWtzLiBG b2xsb3dpbmcgdGhhdCBwZXJpb2QsIG9uIDQvMjgsDQo+Pj4+PndlJ2xsIGJlDQo+Pj4+PiBpbml0 aWF0aW5nIGEgY29uc2Vuc3VzIGNhbGwgdGhhdCB3aWxsIGxhc3QgYW4gYWRkaXRpb25hbCB0d28g d2Vla3MsDQo+Pj4+PndpdGggdGhlDQo+Pj4+PiBhaW0gb2YgY29udmVyZ2luZyBtb2RlbGluZyBs YW5ndWFnZSAvIHByb3RvY29sIGJ5IEZyaWRheSwgNS85Lg0KPj4+Pj4NCj4+Pj4+IFRoZSBjb25z ZW5zdXMgY2FsbCBzaG91bGQgYWxzbyBnZW5lcmF0ZSBwcm9wb3NhbHMgZm9yIGFueSBtYXRlcmlh bA0KPj4+Pj5jaGFuZ2VzDQo+Pj4+PiByZXF1aXJlZCB0byB0aGUgdW5kZXJseWluZyBwcm90b2Nv bHMuICBUaGVzZSBwcm9wb3NhbHMgaW4gdHVybiB3aWxsDQo+Pj4+PmZvcm0gdGhlDQo+Pj4+PiBi YXNpcyBmb3IgYSBsYXRlciBkcmFmdCBpbmNsdWRpbmcgZ2FwIGFuYWx5c2lzIGFuZCBzYWlkIGNo YW5nZXMuDQo+Pj4+PlRob3NlDQo+Pj4+PiBzdHJvbmdseSBpbiBmYXZvciBvZiBvbmUgcHJvdG9j b2wgb3ZlciBhbm90aGVyIHNob3VsZCBiZSBwcmVwYXJlZCB0bw0KPj4+Pj4gY29udHJpYnV0ZSB0 byB0aGlzIGFuYWx5c2lzLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBiZXN0LA0KPj4+Pj4NCj4+Pj4+ ICAtZWQNCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4gaTJycyBtYWlsaW5nIGxpc3QNCj4+Pj4+IGkycnNAaWV0Zi5vcmcN Cj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPj4+Pj4N Cj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gaTJycyBtYWlsaW5nIGxpc3QNCj4+Pj4gaTJyc0BpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCj4+Pj4NCj4+Pj4NCj4+Pg0K Pj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+aTJycyBtYWlsaW5nIGxpc3QNCj4+PmkycnNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPj4NCg0K From nobody Fri Apr 18 17:03:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E7E1A0527 for ; Fri, 18 Apr 2014 17:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb_HbO0p2DjW for ; Fri, 18 Apr 2014 17:03:43 -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 3B14F1A0214 for ; Fri, 18 Apr 2014 17:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=578; q=dns/txt; s=iport; t=1397865819; x=1399075419; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+QyCulhYmeX1UvRLbcNDgg7qB2cPCuomAFXirV830pM=; b=W6Hw0Ug2OOYHxJfPYtjXyW06ERmHBNUayLbIGEc/TcswRiD8ASOpvZUW TBUgc8BgFSWVUMgn081ArvaO6RTc+lw+3lHAvBHbVandob4G4vCSOiYYC WzVun+TtnQJkwx2isTAirk7gm9czFQy4rEbr6WbTcRF/u+RauYhdJqfSB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAW9UVOtJA2B/2dsb2JhbABagwaBJsN3gRoWdIImAQEEbgsQAgEIDjgyJQIEAQ0FiEHNRxeOABEBUAeEOAEDiSqPRJJPgzGBcjk X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="318850014" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 19 Apr 2014 00:03:35 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3J03YUk006934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Apr 2014 00:03:34 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 19:03:34 -0500 From: "Jan Medved (jmedved)" To: Susan Hares , "'Jamal Hadi Salim'" , "'Thomas Nadeau'" Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAABF0AIAAEp4AgAAKHQCAAILaAP//jh2A Date: Sat, 19 Apr 2014 00:03:33 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <00e701cf5b61$1341d2f0$39c578d0$@ndzh.com> In-Reply-To: <00e701cf5b61$1341d2f0$39c578d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.168] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4_QtEOz_vZaxESCBjNjSpWI8E2o Cc: "i2rs@ietf.org" , 'Crabbe Edward' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 00:03:47 -0000 Sue, On 4/18/14, 4:51 PM, "Susan Hares" wrote: >Jamal and Tom: > >Dean Bogdanovic and Ron Bonica clearly indicated there were two reasons: >business and technical. My understanding is that Ed Crabbe's context for >this discussion was to judge technical merit. Did I misunderstand the >context of this discussion to be engineering? > I re-read Ed=B9s email: it calls for marshaling of arguments and discussion on the mailing list. It does not seem to say that the discussion and arguments ought to be purely engineering. Thanks, Jan From nobody Fri Apr 18 17:20:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1141A058E for ; Fri, 18 Apr 2014 17:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nM8lmpE5y1 for ; Fri, 18 Apr 2014 17:20:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id E57EE1A0574 for ; Fri, 18 Apr 2014 17:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ED60B1C023A; Fri, 18 Apr 2014 17:20:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E9BA21C0130; Fri, 18 Apr 2014 17:19:55 -0700 (PDT) Message-ID: <5351C11F.1070109@joelhalpern.com> Date: Fri, 18 Apr 2014 20:19:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jan Medved (jmedved)" , Jamal Hadi Salim References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FM4jZRb6xe3EZ81V1pg8JJC3f5w Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 00:20:13 -0000 Actually Jan, you made a leap there I did not follow. You assert that "the controller programmatic API iis a superset of a device programmatic API." This does not seem to follow. On the one hand, I would hope that a controller is exposing abstractions, which are unrelated to the device API. And on the other hand, there may well be many things the device API can do that the controller does not need. The I2RS charter makes it clear that I2RS is not intended to replace other configuration mechanisms. And the basic premise of I2RS is that there are requirements for the work that were not addressed properly by the existing configuration protocols. Otherwise the WG would not even need to discuss protocol modifications. So the fact that NetConf / YANG works for device configuration does not seem to be evidence that it works for what I2RS wants to do. I would actually guess that it is reasonably close, and I will live with whatever conclusion the WG reaches about protocol and modeling. But I would not claim tha thte existing deployment is relevant evidence for this problem space. Yours, Joel On 4/18/14, 7:59 PM, Jan Medved (jmedved) wrote: > > > On 4/18/14, 2:12 PM, "Jamal Hadi Salim" wrote: > >> On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) >> wrote: >>> Cisco is also implementing Netconf - it©ös available on XR today, and it >>> will be available on other platforms as well. >>> >>> For OpenDaylight, we chose Yang as the IDL to describe internal and >>> external APIs in the controller and so far it has served its purpose >>> really well. >>> >> >> This has nothing to do with meeting requirements for I2RS. > > Sure it does. I2RS is ultimately about a set of programmatic APIs to the > routing system. The controller programmatic API is a superset of a device > programmatic API, since the controller must be able to proxy the device > and provide programmatic APIs to its own services. Now, if an IDL has > proven to be useful and/or meet the requirements in a environment which is > a superset of the target environment, then by definition it will be useful > and/or meet the requirements in the target environment. > >> >>> Also, as Tom pointed out, Netconf and Restconf have also been >>> implemented >>> in ODL. I©öd like to stress that we not only have multiple >>> Netconf/Restconf >>> implementations from multiple vendors (Brocade, Juniper, Cisco, just to >>> mention those on this thread), but have multiple open source >>> implementations as well. In addition to ODL, there is libnetconfd and a >>> few others. ODL / libnetconfd interop testing is done in the ODL >>> regression test suite. >> >> Again - I am not hearing requirements against I2RS. >> Have you implemented I2RS with netconf/restconf/yang? > > Nobody has implemented I2RS, because the protocol has not been defined > yet. But I was deeply involved with Netconf/Restconf/Yang implementations > on both IOS-XR and on OpenDaylight. In any case, Netconf/Restconf/Yang > gives us today maybe 80-90% of what we need from I2RS for our use cases. > >> >>> Now, since there are multiple independent open >>> source implementations, we©öve got a good ecosystem for implementation of >>> new Netconf/Restconf/Yang features that may be required to meet i2rs©ös >>> needs (if the need to evolve the protocols/language arises). >>> >> >> I dont think this sounds rational at all. HTTP has a bigger ecosystem >> than you. >> Why not build around that and then refactor as needed? > > Bingo! How about Restconf with JSON encoding? ;-) > >> Why is it so hard to get requirements around here? What is the point >> to a standard again? > > The I2RS requirements have been gathered, and Netconf and Yang have been > analyzed against the requirements by Andy and Dean at the last IETF. I > find no fault in their analysis, so IMHO Netconf / Yang (with possibly > small modifications) will meet the technical requirements of I2RS. > > What I and others have been trying to say is that the rest of the world is > moving towards Netconf/Restconf/Yang. Therefore, (besides it being a > good-enough technical choice), it is the pragmatic choice. If I2RS wants > to be relevant to operators, vendors, and the open source community, it > needs to go where all these entities want to be. > >> >> cheers, >> Jamal > > > Thanks, > Jan > >> >>> In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as >>> the modeling language. >>> >>> >>> >>> Thanks, >>> Jan >>> >>> >>> On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >>> >>>> Jamal, >>>> >>>> Here are two criteria to be considered: >>>> 1. technical >>>> 2. commercial/business >>>> >>>> We can discuss pros and cons for both, but have to state that from >>>> business perspective for Juniper going with RESTCONF/YANG make more >>>> sense. We already built the Junos model in YANG and >>>> have or are in process of building needed tools. Same goes for RESTCONF. >>>> We have NETCONF implemented in Junos and are working on RESTCONF >>>> implementation. >>>> Many carriers adopted or are adopting NETCONF/YANG, are looking into >>>> RESTCONF as well, so this looks like a low hanging fruit from business >>>> perspective. >>>> >>>> Looking at technical aspect, unless there is a very compelling reason >>>> (and there might be, but I'm not aware of it), don't see reason to >>>> switch >>> >from RESTCONF and YANG. >>>> We can find out down the line that RESTCONF/YANG was the wrong way to >>>> go, >>>> but that can be always changed. From my perspective it looks right >>>> today. >>>> >>>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>> >>>> Dean >>>> >>>> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >>>> >>>>> Ok, since nobody is saying anything i'll bite. >>>>> How would you like for this discussion to proceed? >>>>> >>>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>>>>> Dear I2RSers, >>>>>> >>>>>> At the last I2RS WG meeting there was a great deal of conversation >>>>>> regarding selection of both modeling language and underlying >>>>>> transport >>>>>> protocol. Consensus at the time was to make use of Yang and (NetConf >>>>>> or >>>>>> RestConf) (unclear). >>>>>> >>>>> >>>>> And i believe the view, as correctly presented by you, is for folks to >>>>> go back >>>>> and make educated decisions by actually getting knowledgeable about >>>>> the different views presented. "Consensus" that you described above >>>>> to me looked like a pageant popularity contest not based on anything >>>>> technical ("who likes contestant in the blue shirt? please cheer for >>>>> them"). >>>>> >>>>> In my opinion i dont think the requirements are clear. >>>>> >>>>> Will that get the crickets stop chirping? >>>>> >>>>> cheers, >>>>> jamal >>>>> >>>>>> Before coming to a final consensus, we'd like to give people >>>>>> adequate >>>>>> time >>>>>> to review source material, marshall arguments and discuss on the >>>>>> mailing >>>>>> list. To this end, we're asking that interested parties do just this >>>>>> over >>>>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>>> we'll be >>>>>> initiating a consensus call that will last an additional two weeks, >>>>>> with the >>>>>> aim of converging modeling language / protocol by Friday, 5/9. >>>>>> >>>>>> The consensus call should also generate proposals for any material >>>>>> changes >>>>>> required to the underlying protocols. These proposals in turn will >>>>>> form the >>>>>> basis for a later draft including gap analysis and said changes. >>>>>> Those >>>>>> strongly in favor of one protocol over another should be prepared to >>>>>> contribute to this analysis. >>>>>> >>>>>> >>>>>> best, >>>>>> >>>>>> -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 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 nobody Fri Apr 18 17:21:27 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6208C1A0574 for ; Fri, 18 Apr 2014 17:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS-oD59PWNrs for ; Fri, 18 Apr 2014 17:21:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C01A0549 for ; Fri, 18 Apr 2014 17:21:19 -0700 (PDT) Received: from [10.67.132.67] (mobile-166-147-103-172.mycingular.net [166.147.103.172]) by lucidvision.com (Postfix) with ESMTP id 6B6C7276F916; Fri, 18 Apr 2014 20:21:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Fri, 18 Apr 2014 19:21:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> To: "Jan Medved (jmedved)" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/U_oFd6sEH7L-idnO2yJmWJBP3U0 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 00:21:25 -0000 > On Apr 18, 2014, at 6:59 PM, "Jan Medved (jmedved)" wr= ote: >=20 >=20 >=20 >> On 4/18/14, 2:12 PM, "Jamal Hadi Salim" wrote: >>=20 >> On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) = >> wrote: >>> Cisco is also implementing Netconf - it=C2=B9s available on XR today, an= d it >>> will be available on other platforms as well. >>>=20 >>> For OpenDaylight, we chose Yang as the IDL to describe internal and >>> external APIs in the controller and so far it has served its purpose >>> really well. >>=20 >> This has nothing to do with meeting requirements for I2RS. >=20 > Sure it does. I2RS is ultimately about a set of programmatic APIs to the > routing system. The controller programmatic API is a superset of a device > programmatic API, since the controller must be able to proxy the device > and provide programmatic APIs to its own services. Now, if an IDL has > proven to be useful and/or meet the requirements in a environment which is= > a superset of the target environment, then by definition it will be useful= > and/or meet the requirements in the target environment. Spot on. Tom=20 >=20 >>=20 >>> Also, as Tom pointed out, Netconf and Restconf have also been >>> implemented >>> in ODL. I=C2=B9d like to stress that we not only have multiple >>> Netconf/Restconf >>> implementations from multiple vendors (Brocade, Juniper, Cisco, just to >>> mention those on this thread), but have multiple open source >>> implementations as well. In addition to ODL, there is libnetconfd and a >>> few others. ODL / libnetconfd interop testing is done in the ODL >>> regression test suite. >>=20 >> Again - I am not hearing requirements against I2RS. >> Have you implemented I2RS with netconf/restconf/yang? >=20 > Nobody has implemented I2RS, because the protocol has not been defined > yet. But I was deeply involved with Netconf/Restconf/Yang implementations > on both IOS-XR and on OpenDaylight. In any case, Netconf/Restconf/Yang > gives us today maybe 80-90% of what we need from I2RS for our use cases. >=20 >>=20 >>> Now, since there are multiple independent open >>> source implementations, we=C2=B9ve got a good ecosystem for implementati= on of >>> new Netconf/Restconf/Yang features that may be required to meet i2rs=C2=B9= s >>> needs (if the need to evolve the protocols/language arises). >>=20 >> I dont think this sounds rational at all. HTTP has a bigger ecosystem >> than you. >> Why not build around that and then refactor as needed? >=20 > Bingo! How about Restconf with JSON encoding? ;-) >=20 >> Why is it so hard to get requirements around here? What is the point >> to a standard again? >=20 > The I2RS requirements have been gathered, and Netconf and Yang have been > analyzed against the requirements by Andy and Dean at the last IETF. I > find no fault in their analysis, so IMHO Netconf / Yang (with possibly > small modifications) will meet the technical requirements of I2RS. >=20 > What I and others have been trying to say is that the rest of the world is= > moving towards Netconf/Restconf/Yang. Therefore, (besides it being a > good-enough technical choice), it is the pragmatic choice. If I2RS wants > to be relevant to operators, vendors, and the open source community, it > needs to go where all these entities want to be. >=20 >>=20 >> cheers, >> Jamal >=20 >=20 > Thanks, > Jan >=20 >>=20 >>> In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as >>> the modeling language. >>>=20 >>>=20 >>>=20 >>> Thanks, >>> Jan >>>=20 >>>=20 >>>> On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >>>>=20 >>>> Jamal, >>>>=20 >>>> Here are two criteria to be considered: >>>> 1. technical >>>> 2. commercial/business >>>>=20 >>>> We can discuss pros and cons for both, but have to state that from >>>> business perspective for Juniper going with RESTCONF/YANG make more >>>> sense. We already built the Junos model in YANG and >>>> have or are in process of building needed tools. Same goes for RESTCONF.= >>>> We have NETCONF implemented in Junos and are working on RESTCONF >>>> implementation. >>>> Many carriers adopted or are adopting NETCONF/YANG, are looking into >>>> RESTCONF as well, so this looks like a low hanging fruit from business >>>> perspective. >>>>=20 >>>> Looking at technical aspect, unless there is a very compelling reason >>>> (and there might be, but I'm not aware of it), don't see reason to >>>> switch >>>> from RESTCONF and YANG. >>>> We can find out down the line that RESTCONF/YANG was the wrong way to >>>> go, >>>> but that can be always changed. =46rom my perspective it looks right >>>> today. >>>>=20 >>>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>>=20 >>>> Dean >>>>=20 >>>>> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrot= e: >>>>>=20 >>>>> Ok, since nobody is saying anything i'll bite. >>>>> How would you like for this discussion to proceed? >>>>>=20 >>>>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote= : >>>>>> Dear I2RSers, >>>>>>=20 >>>>>> At the last I2RS WG meeting there was a great deal of conversation >>>>>> regarding selection of both modeling language and underlying >>>>>> transport >>>>>> protocol. Consensus at the time was to make use of Yang and (NetConf= >>>>>> or >>>>>> RestConf) (unclear). >>>>>=20 >>>>> And i believe the view, as correctly presented by you, is for folks to= >>>>> go back >>>>> and make educated decisions by actually getting knowledgeable about >>>>> the different views presented. "Consensus" that you described above >>>>> to me looked like a pageant popularity contest not based on anything >>>>> technical ("who likes contestant in the blue shirt? please cheer for >>>>> them"). >>>>>=20 >>>>> In my opinion i dont think the requirements are clear. >>>>>=20 >>>>> Will that get the crickets stop chirping? >>>>>=20 >>>>> cheers, >>>>> jamal >>>>>=20 >>>>>> Before coming to a final consensus, we'd like to give people >>>>>> adequate >>>>>> time >>>>>> to review source material, marshall arguments and discuss on the >>>>>> mailing >>>>>> list. To this end, we're asking that interested parties do just this= >>>>>> over >>>>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>>> we'll be >>>>>> initiating a consensus call that will last an additional two weeks, >>>>>> with the >>>>>> aim of converging modeling language / protocol by Friday, 5/9. >>>>>>=20 >>>>>> The consensus call should also generate proposals for any material >>>>>> changes >>>>>> required to the underlying protocols. These proposals in turn will >>>>>> form the >>>>>> basis for a later draft including gap analysis and said changes. >>>>>> Those >>>>>> strongly in favor of one protocol over another should be prepared to >>>>>> contribute to this analysis. >>>>>>=20 >>>>>>=20 >>>>>> best, >>>>>>=20 >>>>>> -ed >>>>>>=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 >>>>=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 From nobody Fri Apr 18 18:13:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ADB1A0126 for ; Fri, 18 Apr 2014 18:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYg0REiVsQwK for ; Fri, 18 Apr 2014 18:13:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C47911A00FF for ; Fri, 18 Apr 2014 18:13:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jan Medved \(jmedved\)'" , "'Jamal Hadi Salim'" , "'Thomas Nadeau'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <4E16F253-8988-468C-B21B-7FED6C4799D6@lucidvision.com> <00e701cf5b61$1341d2f0$39c578d0$@ndzh.com> In-Reply-To: Date: Fri, 18 Apr 2014 21:13:07 -0400 Message-ID: <011101cf5b6c$864e0790$92ea16b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkC4OP6iAINsCOdAnFEb3ICcFKwpwKDisOvl2kPhCA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0GdLFZUHj9UN3MPvfYFtGdRbNl8 Cc: i2rs@ietf.org, 'Crabbe Edward' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 01:13:23 -0000 Jan and Tom:=20 Thanks for letting me know. Thanks for the clarification. Talk on.=20 Ed's comments at IETF 89 inquired about a technical discussion regarding FORCES and YANG rather than an "emotional" or simply business. Both aspects are important to a corporate decision, but it is the WG chairs = that set the constraints for our discussion. =20 I am still interested in the technical side of the Brocade decision. =20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jan Medved = (jmedved) Sent: Friday, April 18, 2014 8:04 PM To: Susan Hares; 'Jamal Hadi Salim'; 'Thomas Nadeau' Cc: i2rs@ietf.org; 'Crabbe Edward'; 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model Sue, On 4/18/14, 4:51 PM, "Susan Hares" wrote: >Jamal and Tom: > >Dean Bogdanovic and Ron Bonica clearly indicated there were two = reasons: >business and technical. My understanding is that Ed Crabbe's context = for >this discussion was to judge technical merit. Did I misunderstand the=20 >context of this discussion to be engineering? > I re-read Ed=B9s email: it calls for marshaling of arguments and = discussion on the mailing list. It does not seem to say that the discussion and = arguments ought to be purely engineering. Thanks, Jan _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Apr 18 18:25:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568B1A021B for ; Fri, 18 Apr 2014 18:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUmLeiCdaVC4 for ; Fri, 18 Apr 2014 18:25:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CFC171A01EA for ; Fri, 18 Apr 2014 18:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14628; q=dns/txt; s=iport; t=1397870747; x=1399080347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=74UCj3Pip2TXzjyGk757rI9MnUEDLM50q4NkDciapIM=; b=MJLXbmP0KB4Xp2PcfcaLyQVvYqkw8Ofq9s+S/EQVZLY/eM2wU/MZ78M0 DFj9rNX616NU6h8MjMkwilDHxA4KPQagYAk4LBY9ruu43yiztAyxwN3Og kLjDADy889wDKXMKf43AQ/1z350d0cHvpF546KhFXm/gyRP0m0WOXVTMP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALfPUVOtJA2M/2dsb2JhbABagwZPV4MPuS+HPBmBARZ0giUBAQEEAQEBMTMHCxACAQgYBCgCAiULJQIEAQ0FFIgtDY1NnBMGo0oTBIEjiBqEcjMHgmmBTwSYbpJPgzGCKw X-IronPort-AV: E=Sophos;i="4.97,886,1389744000"; d="scan'208";a="318858958" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 19 Apr 2014 01:25:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3J1Pil7001540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Apr 2014 01:25:44 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 20:25:43 -0500 From: "Jan Medved (jmedved)" To: "Joel M. Halpern" , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwCAAHrngP//nRqA Date: Sat, 19 Apr 2014 01:25:42 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> In-Reply-To: <5351C11F.1070109@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.168] Content-Type: text/plain; charset="euc-kr" Content-ID: <557C39481E43D54A8B420A6E7C3C0836@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/H9uWihjbE4HWbT9jK_txLw4QcHE Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 01:25:56 -0000 Sm9lbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIDQvMTgvMTQsIDU6MTkgUE0sICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCg0KPkFjdHVhbGx5IEph biwgeW91IG1hZGUgYSBsZWFwIHRoZXJlIEkgZGlkIG5vdCBmb2xsb3cuDQo+WW91IGFzc2VydCB0 aGF0ICJ0aGUgY29udHJvbGxlciBwcm9ncmFtbWF0aWMgQVBJIGlpcyBhIHN1cGVyc2V0IG9mIGEN Cj5kZXZpY2UgcHJvZ3JhbW1hdGljIEFQSS6hsQ0KPlRoaXMgZG9lcyBub3Qgc2VlbSB0byBmb2xs b3cuICBPbiB0aGUgb25lIGhhbmQsIEkgd291bGQgaG9wZSB0aGF0IGENCj5jb250cm9sbGVyIGlz IGV4cG9zaW5nIGFic3RyYWN0aW9ucywgd2hpY2ggYXJlIHVucmVsYXRlZCB0byB0aGUgZGV2aWNl DQo+QVBJLiAgDQoNClllcy4gSSBtYXkgaGF2ZSBzdGF0ZWQgc2xpZ2h0bHkgZGlmZmVyZW50bHkg LSBJIGNhbGxlZCB0aGVzZSBhYnN0cmFjdGlvbnMNCqGwY29udHJvbGxlcqGvcyBvd24gc2Vydmlj ZXOhsS4NCg0KPkFuZCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUgbWF5IHdlbGwgYmUgbWFueSB0 aGluZ3MgdGhlIGRldmljZSBBUEkgY2FuDQo+ZG8gdGhhdCB0aGUgY29udHJvbGxlciBkb2VzIG5v dA0KPm5lZWQuICANCg0KQWdhaW4sIHdlIGFyZSBpbiBhZ3JlZW1lbnQsIHdpdGggb25lIHBvc3Np YmxlIHR3aXN0OiBhbiBhcHBsaWNhdGlvbiBtYXkNCndhbnQgdG8gdGFsayB0byB0aGUgZGV2aWNl IG5vdCBkaXJlY3RseSwgYnV0IHRocm91Z2ggdGhlIGNvbnRyb2xsZXIgKEkNCnRoaW5rIGEgd2hp bGUgYmFjayB3ZSBhbGwgYWdyZWVkIHRoYXQgdGhpcyB3YXMgYSB2YWxpZCB1c2UgY2FzZSkuIEkg Y2FsbGVkDQppdCChsGNvbnRyb2xsZXIgcHJveHlpbmcgdGhlIGRldmljZaGxLg0KDQpUaGUgcG9p bnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2UgdGhhdCBZYW5nLCBhcyB0aGUgSURMIGluIHRoZSBjb250 cm9sbGVyLCBpcw0Kc3VpdGFibGUgYm90aCBmb3IgZGVmaW5pbmcgY29udHJvbGxlcqGvcyBvd24g c2VydmljZSBBUElzIGFuZCBmb3IgcHJveHlpbmcNCm9mIGRldmljZSBBUElzLiBJIHNwb2tlIGZy b20gZXhwZXJpZW5jZTogd2UgZGVmaW5lZCBhIGJ1bmNoIG9mIGNvbnRyb2xsZXINCnNlcnZpY2Vz IGFuZCBwcm94aWVkIGEgYnVuY2ggb2YgZGV2aWNlIEFQSXMgKG5ldGNvbmYgaXRzZWxmLCBQQ0VQ LA0KT3BlbkZsb3cpIHdpdGggeWFuZyBtb2RlbHMuIEl0IHdvcmtlZCByZWFsbHkgd2VsbCBmb3Ig YWxsIEFQSXMgdGhhdCB3ZQ0KbWFuYWdlZCB0byB0aHJvdyBhdCBpdCA6LSkuDQoNClRvIGNvbmNs dWRlOiBpZiB5YW5nIHdvcmtzIHdlbGwgaW4gdGhlIGNvbnRyb2xsZXIgZW52aXJvbm1lbnQsIHdo aWNoIGlzIGENCm1vcmUgY29tcGxleCBBUEkgZW52aXJvbm1lbnQgdGhhbiBhIGRldmljZSwgaXQg d2lsbCBzdXJlbHkgd29yayB3ZWxsIGF0DQp0aGUgZGV2aWNlIGxldmVsLiBUaGF0oa9zIGFsbCB0 aGF0IEkgd2FudGVkIHRvIHNheS4NCg0KPlRoZSBJMlJTIGNoYXJ0ZXIgbWFrZXMgaXQgY2xlYXIg dGhhdCBJMlJTIGlzIG5vdCBpbnRlbmRlZCB0byByZXBsYWNlDQo+b3RoZXIgY29uZmlndXJhdGlv biBtZWNoYW5pc21zLg0KPg0KPkFuZCB0aGUgYmFzaWMgcHJlbWlzZSBvZiBJMlJTIGlzIHRoYXQg dGhlcmUgYXJlIHJlcXVpcmVtZW50cyBmb3IgdGhlDQo+d29yayB0aGF0IHdlcmUgbm90IGFkZHJl c3NlZCBwcm9wZXJseSBieSB0aGUgZXhpc3RpbmcgY29uZmlndXJhdGlvbg0KPnByb3RvY29scy4g IE90aGVyd2lzZSB0aGUgV0cgd291bGQgbm90IGV2ZW4gbmVlZCB0byBkaXNjdXNzIHByb3RvY29s DQo+bW9kaWZpY2F0aW9ucy4gIFNvIHRoZSBmYWN0IHRoYXQgTmV0Q29uZiAvIFlBTkcgd29ya3Mg Zm9yIGRldmljZQ0KPmNvbmZpZ3VyYXRpb24gZG9lcyBub3Qgc2VlbSB0byBiZSBldmlkZW5jZSB0 aGF0IGl0IHdvcmtzIGZvciB3aGF0IEkyUlMNCj53YW50cyB0byBkby4NCj4NCj5JIHdvdWxkIGFj dHVhbGx5IGd1ZXNzIHRoYXQgaXQgaXMgcmVhc29uYWJseSBjbG9zZSwNCg0KQWdhaW4sIHdlIHNl ZW0gdG8gYmUgaW4gYWdyZWVtZW50IC0gSSBhbHNvIHNhaWQgdGhhdCB0aGUgbWFqb3JpdHkgb2Yg dXNlDQpjYXNlcyB0aGF0IEkgY2FuIHRoaW5rIG9mIGNhbiBiZSBjb3ZlcmVkIHdpdGggTmV0Y29u Zi9SZXN0Y29uZi9ZYW5nIHRvZGF5Lg0KSSBkaWQgbm90IHNheSB3ZSBjYW4gY292ZXIgZXZlcnl0 aGluZy4gQnV0LCB0aHJvdWdoIHRoZSBPcGVuRGF5bGlnaHQNCmV4cGVyaWVuY2UgSSBmb3VuZCB0 aGF0IE5ldGNvbmYvWWFuZyBjb3VsZCBjb3ZlciBhIGxvdCBtb3JlIHRoYW4gd2hhdCBJDQpvcmln aW5hbGx5IGFudGljaXBhdGVkICh3aGljaCB3YXMgYWN0dWFsbHkgcXVpdGUgc3VycHJpc2luZyB0 byBtZSkuDQoNCg0KPmFuZCBJIHdpbGwgbGl2ZSB3aXRoIHdoYXRldmVyIGNvbmNsdXNpb24gdGhl IFdHIHJlYWNoZXMgYWJvdXQgcHJvdG9jb2wNCj5hbmQgbW9kZWxpbmcuICBCdXQgSSB3b3VsZCBu b3QgY2xhaW0gdGhhdCB0aGUgZXhpc3RpbmcgZGVwbG95bWVudCBpcw0KPnJlbGV2YW50IGV2aWRl bmNlIGZvciB0aGlzIHByb2JsZW0gc3BhY2UuDQoNCkkgYWN0dWFsbHkgdGhpbmsgaXQgaXMgLSB3 aGF0oa9zIHdyb25nIHdpdGggd29ya2luZyBjb2RlPyA7LSkNCg0KPg0KPllvdXJzLA0KPkpvZWwN Cg0KDQpUaGFua3MsDQpKYW4NCg0KPg0KPk9uIDQvMTgvMTQsIDc6NTkgUE0sIEphbiBNZWR2ZWQg KGptZWR2ZWQpIHdyb3RlOg0KPj4gDQo+PiANCj4+IE9uIDQvMTgvMTQsIDI6MTIgUE0sICJKYW1h bCBIYWRpIFNhbGltIiA8aGFkaUBtb2phdGF0dS5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gT24gRnJp LCBBcHIgMTgsIDIwMTQgYXQgNDo1OSBQTSwgSmFuIE1lZHZlZCAoam1lZHZlZCkNCj4+PjxqbWVk dmVkQGNpc2NvLmNvbT4NCj4+PiB3cm90ZToNCj4+Pj4gQ2lzY28gaXMgYWxzbyBpbXBsZW1lbnRp bmcgTmV0Y29uZiAtIGl0qfZzIGF2YWlsYWJsZSBvbiBYUiB0b2RheSwgYW5kDQo+Pj4+aXQNCj4+ Pj4gd2lsbCBiZSBhdmFpbGFibGUgb24gb3RoZXIgcGxhdGZvcm1zIGFzIHdlbGwuDQo+Pj4+DQo+ Pj4+IEZvciBPcGVuRGF5bGlnaHQsIHdlIGNob3NlIFlhbmcgYXMgdGhlIElETCB0byBkZXNjcmli ZSBpbnRlcm5hbCBhbmQNCj4+Pj4gZXh0ZXJuYWwgQVBJcyBpbiB0aGUgY29udHJvbGxlciBhbmQg c28gZmFyIGl0IGhhcyBzZXJ2ZWQgaXRzIHB1cnBvc2UNCj4+Pj4gcmVhbGx5IHdlbGwuDQo+Pj4+ DQo+Pj4NCj4+PiBUaGlzIGhhcyBub3RoaW5nICB0byBkbyB3aXRoIG1lZXRpbmcgcmVxdWlyZW1l bnRzIGZvciBJMlJTLg0KPj4gDQo+PiBTdXJlIGl0IGRvZXMuIEkyUlMgaXMgdWx0aW1hdGVseSBh Ym91dCBhIHNldCBvZiBwcm9ncmFtbWF0aWMgQVBJcyB0byB0aGUNCj4+IHJvdXRpbmcgc3lzdGVt LiBUaGUgY29udHJvbGxlciBwcm9ncmFtbWF0aWMgQVBJIGlzIGEgc3VwZXJzZXQgb2YgYQ0KPj5k ZXZpY2UNCj4+IHByb2dyYW1tYXRpYyBBUEksIHNpbmNlIHRoZSBjb250cm9sbGVyIG11c3QgYmUg YWJsZSB0byBwcm94eSB0aGUgZGV2aWNlDQo+PiBhbmQgcHJvdmlkZSBwcm9ncmFtbWF0aWMgQVBJ cyB0byBpdHMgb3duIHNlcnZpY2VzLiBOb3csIGlmIGFuIElETCBoYXMNCj4+IHByb3ZlbiB0byBi ZSB1c2VmdWwgYW5kL29yIG1lZXQgdGhlIHJlcXVpcmVtZW50cyBpbiBhIGVudmlyb25tZW50IHdo aWNoDQo+PmlzDQo+PiBhIHN1cGVyc2V0IG9mIHRoZSB0YXJnZXQgZW52aXJvbm1lbnQsIHRoZW4g YnkgZGVmaW5pdGlvbiBpdCB3aWxsIGJlDQo+PnVzZWZ1bA0KPj4gYW5kL29yIG1lZXQgdGhlIHJl cXVpcmVtZW50cyBpbiB0aGUgdGFyZ2V0IGVudmlyb25tZW50Lg0KPj4gDQo+Pj4NCj4+Pj4gQWxz bywgYXMgVG9tIHBvaW50ZWQgb3V0LCBOZXRjb25mIGFuZCBSZXN0Y29uZiBoYXZlIGFsc28gYmVl bg0KPj4+PiBpbXBsZW1lbnRlZA0KPj4+PiBpbiBPREwuIEmp9mQgbGlrZSB0byBzdHJlc3MgdGhh dCB3ZSBub3Qgb25seSBoYXZlIG11bHRpcGxlDQo+Pj4+IE5ldGNvbmYvUmVzdGNvbmYNCj4+Pj4g aW1wbGVtZW50YXRpb25zIGZyb20gbXVsdGlwbGUgdmVuZG9ycyAoQnJvY2FkZSwgSnVuaXBlciwg Q2lzY28sIGp1c3QNCj4+Pj50bw0KPj4+PiBtZW50aW9uIHRob3NlIG9uIHRoaXMgdGhyZWFkKSwg YnV0IGhhdmUgbXVsdGlwbGUgb3BlbiBzb3VyY2UNCj4+Pj4gaW1wbGVtZW50YXRpb25zIGFzIHdl bGwuIEluIGFkZGl0aW9uIHRvIE9ETCwgdGhlcmUgaXMgbGlibmV0Y29uZmQgYW5kDQo+Pj4+YQ0K Pj4+PiBmZXcgb3RoZXJzLiAgT0RMIC8gbGlibmV0Y29uZmQgaW50ZXJvcCB0ZXN0aW5nIGlzIGRv bmUgaW4gdGhlIE9ETA0KPj4+PiByZWdyZXNzaW9uIHRlc3Qgc3VpdGUuDQo+Pj4NCj4+PiBBZ2Fp biAtIEkgYW0gbm90IGhlYXJpbmcgcmVxdWlyZW1lbnRzIGFnYWluc3QgSTJSUy4NCj4+PiBIYXZl IHlvdSBpbXBsZW1lbnRlZCBJMlJTIHdpdGggbmV0Y29uZi9yZXN0Y29uZi95YW5nPw0KPj4gDQo+ PiBOb2JvZHkgaGFzIGltcGxlbWVudGVkIEkyUlMsIGJlY2F1c2UgdGhlIHByb3RvY29sIGhhcyBu b3QgYmVlbiBkZWZpbmVkDQo+PiB5ZXQuIEJ1dCBJIHdhcyBkZWVwbHkgaW52b2x2ZWQgd2l0aCBO ZXRjb25mL1Jlc3Rjb25mL1lhbmcNCj4+aW1wbGVtZW50YXRpb25zDQo+PiBvbiBib3RoIElPUy1Y UiBhbmQgb24gT3BlbkRheWxpZ2h0LiBJbiBhbnkgY2FzZSwgTmV0Y29uZi9SZXN0Y29uZi9ZYW5n DQo+PiBnaXZlcyB1cyB0b2RheSBtYXliZSA4MC05MCUgb2Ygd2hhdCB3ZSBuZWVkIGZyb20gSTJS UyBmb3Igb3VyIHVzZSBjYXNlcy4NCj4+IA0KPj4+DQo+Pj4+IE5vdywgc2luY2UgdGhlcmUgYXJl IG11bHRpcGxlIGluZGVwZW5kZW50IG9wZW4NCj4+Pj4gc291cmNlIGltcGxlbWVudGF0aW9ucywg d2Wp9nZlIGdvdCBhIGdvb2QgZWNvc3lzdGVtIGZvciBpbXBsZW1lbnRhdGlvbg0KPj4+Pm9mDQo+ Pj4+IG5ldyBOZXRjb25mL1Jlc3Rjb25mL1lhbmcgZmVhdHVyZXMgdGhhdCBtYXkgYmUgcmVxdWly ZWQgdG8gbWVldCBpMnJzqfZzDQo+Pj4+IG5lZWRzIChpZiB0aGUgbmVlZCB0byBldm9sdmUgdGhl IHByb3RvY29scy9sYW5ndWFnZSBhcmlzZXMpLg0KPj4+Pg0KPj4+DQo+Pj4gSSBkb250IHRoaW5r IHRoaXMgc291bmRzIHJhdGlvbmFsIGF0IGFsbC4gSFRUUCBoYXMgYSBiaWdnZXIgZWNvc3lzdGVt DQo+Pj4gdGhhbiB5b3UuDQo+Pj4gV2h5IG5vdCBidWlsZCBhcm91bmQgdGhhdCBhbmQgdGhlbiBy ZWZhY3RvciBhcyBuZWVkZWQ/DQo+PiANCj4+IEJpbmdvISBIb3cgYWJvdXQgUmVzdGNvbmYgd2l0 aCBKU09OIGVuY29kaW5nPyA7LSkNCj4+IA0KPj4+IFdoeSBpcyBpdCBzbyBoYXJkIHRvIGdldCBy ZXF1aXJlbWVudHMgYXJvdW5kIGhlcmU/ICBXaGF0IGlzIHRoZSBwb2ludA0KPj4+IHRvIGEgc3Rh bmRhcmQgYWdhaW4/DQo+PiANCj4+IFRoZSBJMlJTIHJlcXVpcmVtZW50cyBoYXZlIGJlZW4gZ2F0 aGVyZWQsIGFuZCBOZXRjb25mIGFuZCBZYW5nIGhhdmUgYmVlbg0KPj4gYW5hbHl6ZWQgYWdhaW5z dCB0aGUgcmVxdWlyZW1lbnRzIGJ5IEFuZHkgYW5kIERlYW4gYXQgdGhlIGxhc3QgSUVURi4gSQ0K Pj4gZmluZCBubyBmYXVsdCBpbiB0aGVpciBhbmFseXNpcywgc28gSU1ITyBOZXRjb25mIC8gWWFu ZyAod2l0aCBwb3NzaWJseQ0KPj4gc21hbGwgbW9kaWZpY2F0aW9ucykgd2lsbCBtZWV0IHRoZSB0 ZWNobmljYWwgcmVxdWlyZW1lbnRzIG9mIEkyUlMuDQo+PiANCj4+IFdoYXQgSSBhbmQgb3RoZXJz IGhhdmUgYmVlbiB0cnlpbmcgdG8gc2F5IGlzIHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHdvcmxkDQo+ PmlzDQo+PiBtb3ZpbmcgdG93YXJkcyBOZXRjb25mL1Jlc3Rjb25mL1lhbmcuIFRoZXJlZm9yZSwg KGJlc2lkZXMgaXQgYmVpbmcgYQ0KPj4gZ29vZC1lbm91Z2ggdGVjaG5pY2FsIGNob2ljZSksIGl0 IGlzIHRoZSBwcmFnbWF0aWMgY2hvaWNlLiBJZiBJMlJTIHdhbnRzDQo+PiB0byBiZSByZWxldmFu dCB0byBvcGVyYXRvcnMsIHZlbmRvcnMsIGFuZCB0aGUgb3BlbiBzb3VyY2UgY29tbXVuaXR5LCBp dA0KPj4gbmVlZHMgdG8gZ28gd2hlcmUgYWxsIHRoZXNlIGVudGl0aWVzIHdhbnQgdG8gYmUuDQo+ PiANCj4+Pg0KPj4+IGNoZWVycywNCj4+PiBKYW1hbA0KPj4gDQo+PiANCj4+IFRoYW5rcywNCj4+ IEphbg0KPj4gDQo+Pj4NCj4+Pj4gSW4gc2hvcnQsICsxIGZvciBOZXRjb25mL1Jlc3Rjb25mIGZv ciB0aGUgaTJycyBwcm90b2NvbCBhbmQgZm9yIFlhbmcNCj4+Pj5hcw0KPj4+PiB0aGUgbW9kZWxp bmcgbGFuZ3VhZ2UuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gSmFuDQo+ Pj4+DQo+Pj4+DQo+Pj4+IE9uIDQvMTgvMTQsIDY6MTcgQU0sICJEZWFuIEJvZ2Rhbm92aWMiIDxk ZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBKYW1hbCwNCj4+Pj4+DQo+Pj4+ PiBIZXJlIGFyZSB0d28gY3JpdGVyaWEgdG8gYmUgY29uc2lkZXJlZDoNCj4+Pj4+IDEuIHRlY2hu aWNhbA0KPj4+Pj4gMi4gY29tbWVyY2lhbC9idXNpbmVzcw0KPj4+Pj4NCj4+Pj4+IFdlIGNhbiBk aXNjdXNzIHByb3MgYW5kIGNvbnMgZm9yIGJvdGgsIGJ1dCBoYXZlIHRvIHN0YXRlIHRoYXQgZnJv bQ0KPj4+Pj4gYnVzaW5lc3MgcGVyc3BlY3RpdmUgZm9yIEp1bmlwZXIgZ29pbmcgd2l0aCBSRVNU Q09ORi9ZQU5HIG1ha2UgbW9yZQ0KPj4+Pj4gc2Vuc2UuIFdlIGFscmVhZHkgYnVpbHQgdGhlIEp1 bm9zIG1vZGVsIGluIFlBTkcgYW5kDQo+Pj4+PiBoYXZlIG9yIGFyZSBpbiBwcm9jZXNzIG9mIGJ1 aWxkaW5nIG5lZWRlZCB0b29scy4gU2FtZSBnb2VzIGZvcg0KPj4+Pj5SRVNUQ09ORi4NCj4+Pj4+ IFdlIGhhdmUgTkVUQ09ORiBpbXBsZW1lbnRlZCBpbiBKdW5vcyBhbmQgYXJlIHdvcmtpbmcgb24g UkVTVENPTkYNCj4+Pj4+IGltcGxlbWVudGF0aW9uLg0KPj4+Pj4gTWFueSBjYXJyaWVycyBhZG9w dGVkIG9yIGFyZSBhZG9wdGluZyBORVRDT05GL1lBTkcsIGFyZSBsb29raW5nIGludG8NCj4+Pj4+ IFJFU1RDT05GIGFzIHdlbGwsIHNvIHRoaXMgbG9va3MgbGlrZSBhIGxvdyBoYW5naW5nIGZydWl0 IGZyb20NCj4+Pj4+YnVzaW5lc3MNCj4+Pj4+IHBlcnNwZWN0aXZlLg0KPj4+Pj4NCj4+Pj4+IExv b2tpbmcgYXQgdGVjaG5pY2FsIGFzcGVjdCwgdW5sZXNzIHRoZXJlIGlzIGEgdmVyeSBjb21wZWxs aW5nIHJlYXNvbg0KPj4+Pj4gKGFuZCB0aGVyZSBtaWdodCBiZSwgYnV0IEknbSBub3QgYXdhcmUg b2YgaXQpLCBkb24ndCBzZWUgcmVhc29uIHRvDQo+Pj4+PiBzd2l0Y2gNCj4+Pj4gPmZyb20gUkVT VENPTkYgYW5kIFlBTkcuDQo+Pj4+PiBXZSBjYW4gZmluZCBvdXQgZG93biB0aGUgbGluZSB0aGF0 IFJFU1RDT05GL1lBTkcgd2FzIHRoZSB3cm9uZyB3YXkgdG8NCj4+Pj4+IGdvLA0KPj4+Pj4gYnV0 IHRoYXQgY2FuIGJlIGFsd2F5cyBjaGFuZ2VkLiBGcm9tIG15IHBlcnNwZWN0aXZlIGl0IGxvb2tz IHJpZ2h0DQo+Pj4+PiB0b2RheS4NCj4+Pj4+DQo+Pj4+PiBKdXN0IHRvIGJlIGNsZWFyLCBJIHZv dGUgZm9yIFJFU1RDT05GL1lBTkcgYWRvcHRpb24gZm9yIGkycnMuDQo+Pj4+Pg0KPj4+Pj4gRGVh bg0KPj4+Pj4NCj4+Pj4+IE9uIEFwciAxOCwgMjAxNCwgYXQgNzoyNyBBTSwgSmFtYWwgSGFkaSBT YWxpbSA8aGFkaUBtb2phdGF0dS5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBPaywg c2luY2Ugbm9ib2R5IGlzIHNheWluZyBhbnl0aGluZyBpJ2xsIGJpdGUuDQo+Pj4+Pj4gSG93IHdv dWxkIHlvdSBsaWtlIGZvciB0aGlzIGRpc2N1c3Npb24gdG8gcHJvY2VlZD8NCj4+Pj4+Pg0KPj4+ Pj4+IE9uIEZyaSwgQXByIDExLCAyMDE0IGF0IDE6NTAgUE0sIEVkd2FyZCBDcmFiYmUgPGVkY0Bn b29nbGUuY29tPg0KPj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+IERlYXIgSTJSU2VycywNCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICBBdCB0aGUgbGFzdCBJMlJTIFdHIG1lZXRpbmcgdGhlcmUgd2FzIGEgZ3JlYXQg ZGVhbCBvZg0KPj4+Pj4+PmNvbnZlcnNhdGlvbg0KPj4+Pj4+PiByZWdhcmRpbmcgc2VsZWN0aW9u IG9mIGJvdGggbW9kZWxpbmcgbGFuZ3VhZ2UgYW5kIHVuZGVybHlpbmcNCj4+Pj4+Pj4gdHJhbnNw b3J0DQo+Pj4+Pj4+IHByb3RvY29sLiAgQ29uc2Vuc3VzIGF0IHRoZSB0aW1lIHdhcyB0byBtYWtl IHVzZSBvZiBZYW5nIGFuZA0KPj4+Pj4+PihOZXRDb25mDQo+Pj4+Pj4+IG9yDQo+Pj4+Pj4+IFJl c3RDb25mKSAodW5jbGVhcikuDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBBbmQgaSBiZWxpZXZl IHRoZSB2aWV3LCBhcyBjb3JyZWN0bHkgcHJlc2VudGVkIGJ5IHlvdSwgaXMgZm9yIGZvbGtzDQo+ Pj4+Pj50bw0KPj4+Pj4+IGdvIGJhY2sNCj4+Pj4+PiBhbmQgbWFrZSBlZHVjYXRlZCBkZWNpc2lv bnMgYnkgYWN0dWFsbHkgZ2V0dGluZyBrbm93bGVkZ2VhYmxlIGFib3V0DQo+Pj4+Pj4gdGhlIGRp ZmZlcmVudCB2aWV3cyBwcmVzZW50ZWQuICJDb25zZW5zdXMiIHRoYXQgeW91IGRlc2NyaWJlZCBh Ym92ZQ0KPj4+Pj4+IHRvIG1lIGxvb2tlZCBsaWtlICBhIHBhZ2VhbnQgcG9wdWxhcml0eSBjb250 ZXN0IG5vdCBiYXNlZCBvbg0KPj4+Pj4+YW55dGhpbmcNCj4+Pj4+PiB0ZWNobmljYWwgKCJ3aG8g bGlrZXMgY29udGVzdGFudCBpbiB0aGUgYmx1ZSBzaGlydD8gcGxlYXNlIGNoZWVyIGZvcg0KPj4+ Pj4+IHRoZW0iKS4NCj4+Pj4+Pg0KPj4+Pj4+IEluIG15IG9waW5pb24gaSBkb250IHRoaW5rIHRo ZSByZXF1aXJlbWVudHMgYXJlIGNsZWFyLg0KPj4+Pj4+DQo+Pj4+Pj4gV2lsbCB0aGF0IGdldCB0 aGUgY3JpY2tldHMgc3RvcCBjaGlycGluZz8NCj4+Pj4+Pg0KPj4+Pj4+IGNoZWVycywNCj4+Pj4+ PiBqYW1hbA0KPj4+Pj4+DQo+Pj4+Pj4+ICAgQmVmb3JlIGNvbWluZyB0byBhIGZpbmFsIGNvbnNl bnN1cywgd2UnZCBsaWtlIHRvIGdpdmUgcGVvcGxlDQo+Pj4+Pj4+IGFkZXF1YXRlDQo+Pj4+Pj4+ IHRpbWUNCj4+Pj4+Pj4gdG8gcmV2aWV3IHNvdXJjZSBtYXRlcmlhbCwgbWFyc2hhbGwgYXJndW1l bnRzIGFuZCBkaXNjdXNzIG9uIHRoZQ0KPj4+Pj4+PiBtYWlsaW5nDQo+Pj4+Pj4+IGxpc3QuICBU byB0aGlzIGVuZCwgd2UncmUgYXNraW5nIHRoYXQgaW50ZXJlc3RlZCBwYXJ0aWVzIGRvIGp1c3QN Cj4+Pj4+Pj50aGlzDQo+Pj4+Pj4+IG92ZXINCj4+Pj4+Pj4gdGhlIGNvdXJzZSBvZiB0aGUgbmV4 dCB+dHdvIHdlZWtzLiBGb2xsb3dpbmcgdGhhdCBwZXJpb2QsIG9uIDQvMjgsDQo+Pj4+Pj4+IHdl J2xsIGJlDQo+Pj4+Pj4+IGluaXRpYXRpbmcgYSBjb25zZW5zdXMgY2FsbCB0aGF0IHdpbGwgbGFz dCBhbiBhZGRpdGlvbmFsIHR3byB3ZWVrcywNCj4+Pj4+Pj4gd2l0aCB0aGUNCj4+Pj4+Pj4gYWlt IG9mIGNvbnZlcmdpbmcgbW9kZWxpbmcgbGFuZ3VhZ2UgLyBwcm90b2NvbCBieSBGcmlkYXksIDUv OS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlIGNvbnNlbnN1cyBjYWxsIHNob3VsZCBhbHNvIGdlbmVy YXRlIHByb3Bvc2FscyBmb3IgYW55IG1hdGVyaWFsDQo+Pj4+Pj4+IGNoYW5nZXMNCj4+Pj4+Pj4g cmVxdWlyZWQgdG8gdGhlIHVuZGVybHlpbmcgcHJvdG9jb2xzLiAgVGhlc2UgcHJvcG9zYWxzIGlu IHR1cm4gd2lsbA0KPj4+Pj4+PiBmb3JtIHRoZQ0KPj4+Pj4+PiBiYXNpcyBmb3IgYSBsYXRlciBk cmFmdCBpbmNsdWRpbmcgZ2FwIGFuYWx5c2lzIGFuZCBzYWlkIGNoYW5nZXMuDQo+Pj4+Pj4+IFRo b3NlDQo+Pj4+Pj4+IHN0cm9uZ2x5IGluIGZhdm9yIG9mIG9uZSBwcm90b2NvbCBvdmVyIGFub3Ro ZXIgc2hvdWxkIGJlIHByZXBhcmVkDQo+Pj4+Pj4+dG8NCj4+Pj4+Pj4gY29udHJpYnV0ZSB0byB0 aGlzIGFuYWx5c2lzLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBiZXN0LA0KPj4+Pj4+Pg0K Pj4+Pj4+PiAgIC1lZA0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+Pj4+ PiBpMnJzQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaTJycw0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+ Pj4+IGkycnNAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnMNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBpMnJzIG1haWxp bmcgbGlzdA0KPj4+Pj4gaTJyc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4gaTJy c0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz DQo+PiANCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPmkycnMgbWFpbGluZyBsaXN0DQo+aTJyc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQo= From nobody Fri Apr 18 18:34:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFBF1A020F for ; Fri, 18 Apr 2014 18:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uy9_eKARcRG for ; Fri, 18 Apr 2014 18:34:04 -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 7F43E1A01DD for ; Fri, 18 Apr 2014 18:34:04 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so4001880veb.2 for ; Fri, 18 Apr 2014 18:34:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PmXrcrY+sWeN7FdKKahzlmfncX9NmdFYINq0w9LDMVw=; b=QaqZG2G26B1uH23NFYs/XlTXcdH3NJ8pNbhxrSPwOIiwjgXzuoWNpK23+ld6zDp3Wd qc06ljTqx2M8H9RPm3JIkyCWqQXNfZO7vJRW8msUiVkTk0LhU3fFW3KFPz5C1ZxWWWuG dodTNyCRMOH9ztdo+29XpM7fHogUhJW1EZEPm4hqnR1yToQvbtZcKSgZUXXR+Je2WqI3 ZG4rC7s2wNPK4gyyjr6wVTXNnZmK4L1jE9+gSd/1+IW+fdVCLtrTuoylCpk4OTkblB0R UPwoQYhoHnrb88zbQZI0m9wq+49OH61dKzrehmkDUftziMjDbDYe+Si0141U7pGP61Bw /Vpw== X-Gm-Message-State: ALoCoQk1D3M7jwBWyZXRdjTnWzP7JcRtaHAKCUBHqi1Rzovu8dcStkeccrDBosnPs44cxSZQz74O X-Received: by 10.221.4.66 with SMTP id ob2mr130171vcb.28.1397871240204; Fri, 18 Apr 2014 18:34:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Fri, 18 Apr 2014 18:33:40 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> From: Jamal Hadi Salim Date: Fri, 18 Apr 2014 21:33:40 -0400 Message-ID: To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VxeH3l2du4x-OAuKXc1pBA8Ytro Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 01:34:05 -0000 On Fri, Apr 18, 2014 at 9:25 PM, Jan Medved (jmedved) wrote: [..] > I actually think it is - what's wrong with working code? ;-) Unless you have _working_ I2RS code - this is a meaningless statement to make. How about we strive to show up with some working I2RS code at the next meeting? cheers, jamal From nobody Fri Apr 18 19:51:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537D1A0224 for ; Fri, 18 Apr 2014 19:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OLUyRlOrG7o for ; Fri, 18 Apr 2014 19:50:56 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9DF1A0016 for ; Fri, 18 Apr 2014 19:50:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49FF41C023A; Fri, 18 Apr 2014 19:50:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 837F21C0130; Fri, 18 Apr 2014 19:50:44 -0700 (PDT) Message-ID: <5351E471.4010902@joelhalpern.com> Date: Fri, 18 Apr 2014 22:50:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Jan Medved (jmedved)" , Jamal Hadi Salim References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OhIIUghytd56GnG_akxfBax-VYI Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 02:51:03 -0000 Thank you. I had misread your note as talking about the (reasonably wide) use of YANG for configuring routers. I will agree that the use of YANG by ODL is evidence of the versatility of the tool. Yours, Joel On 4/18/14, 9:25 PM, Jan Medved (jmedved) wrote: > Joel, > > Please see inline. > > On 4/18/14, 5:19 PM, "Joel M. Halpern" wrote: > >> Actually Jan, you made a leap there I did not follow. >> You assert that "the controller programmatic API iis a superset of a >> device programmatic API.¡± >> This does not seem to follow. On the one hand, I would hope that a >> controller is exposing abstractions, which are unrelated to the device >> API. > > Yes. I may have stated slightly differently - I called these abstractions > ¡°controller¡¯s own services¡±. > >> And on the other hand, there may well be many things the device API can >> do that the controller does not >> need. > > Again, we are in agreement, with one possible twist: an application may > want to talk to the device not directly, but through the controller (I > think a while back we all agreed that this was a valid use case). I called > it ¡°controller proxying the device¡±. > > The point I was trying to make that Yang, as the IDL in the controller, is > suitable both for defining controller¡¯s own service APIs and for proxying > of device APIs. I spoke from experience: we defined a bunch of controller > services and proxied a bunch of device APIs (netconf itself, PCEP, > OpenFlow) with yang models. It worked really well for all APIs that we > managed to throw at it :-). > > To conclude: if yang works well in the controller environment, which is a > more complex API environment than a device, it will surely work well at > the device level. That¡¯s all that I wanted to say. > >> The I2RS charter makes it clear that I2RS is not intended to replace >> other configuration mechanisms. >> >> And the basic premise of I2RS is that there are requirements for the >> work that were not addressed properly by the existing configuration >> protocols. Otherwise the WG would not even need to discuss protocol >> modifications. So the fact that NetConf / YANG works for device >> configuration does not seem to be evidence that it works for what I2RS >> wants to do. >> >> I would actually guess that it is reasonably close, > > Again, we seem to be in agreement - I also said that the majority of use > cases that I can think of can be covered with Netconf/Restconf/Yang today. > I did not say we can cover everything. But, through the OpenDaylight > experience I found that Netconf/Yang could cover a lot more than what I > originally anticipated (which was actually quite surprising to me). > > >> and I will live with whatever conclusion the WG reaches about protocol >> and modeling. But I would not claim that the existing deployment is >> relevant evidence for this problem space. > > I actually think it is - what¡¯s wrong with working code? ;-) > >> >> Yours, >> Joel > > > Thanks, > Jan > >> >> On 4/18/14, 7:59 PM, Jan Medved (jmedved) wrote: >>> >>> >>> On 4/18/14, 2:12 PM, "Jamal Hadi Salim" wrote: >>> >>>> On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) >>>> >>>> wrote: >>>>> Cisco is also implementing Netconf - it©ös available on XR today, and >>>>> it >>>>> will be available on other platforms as well. >>>>> >>>>> For OpenDaylight, we chose Yang as the IDL to describe internal and >>>>> external APIs in the controller and so far it has served its purpose >>>>> really well. >>>>> >>>> >>>> This has nothing to do with meeting requirements for I2RS. >>> >>> Sure it does. I2RS is ultimately about a set of programmatic APIs to the >>> routing system. The controller programmatic API is a superset of a >>> device >>> programmatic API, since the controller must be able to proxy the device >>> and provide programmatic APIs to its own services. Now, if an IDL has >>> proven to be useful and/or meet the requirements in a environment which >>> is >>> a superset of the target environment, then by definition it will be >>> useful >>> and/or meet the requirements in the target environment. >>> >>>> >>>>> Also, as Tom pointed out, Netconf and Restconf have also been >>>>> implemented >>>>> in ODL. I©öd like to stress that we not only have multiple >>>>> Netconf/Restconf >>>>> implementations from multiple vendors (Brocade, Juniper, Cisco, just >>>>> to >>>>> mention those on this thread), but have multiple open source >>>>> implementations as well. In addition to ODL, there is libnetconfd and >>>>> a >>>>> few others. ODL / libnetconfd interop testing is done in the ODL >>>>> regression test suite. >>>> >>>> Again - I am not hearing requirements against I2RS. >>>> Have you implemented I2RS with netconf/restconf/yang? >>> >>> Nobody has implemented I2RS, because the protocol has not been defined >>> yet. But I was deeply involved with Netconf/Restconf/Yang >>> implementations >>> on both IOS-XR and on OpenDaylight. In any case, Netconf/Restconf/Yang >>> gives us today maybe 80-90% of what we need from I2RS for our use cases. >>> >>>> >>>>> Now, since there are multiple independent open >>>>> source implementations, we©öve got a good ecosystem for implementation >>>>> of >>>>> new Netconf/Restconf/Yang features that may be required to meet i2rs©ös >>>>> needs (if the need to evolve the protocols/language arises). >>>>> >>>> >>>> I dont think this sounds rational at all. HTTP has a bigger ecosystem >>>> than you. >>>> Why not build around that and then refactor as needed? >>> >>> Bingo! How about Restconf with JSON encoding? ;-) >>> >>>> Why is it so hard to get requirements around here? What is the point >>>> to a standard again? >>> >>> The I2RS requirements have been gathered, and Netconf and Yang have been >>> analyzed against the requirements by Andy and Dean at the last IETF. I >>> find no fault in their analysis, so IMHO Netconf / Yang (with possibly >>> small modifications) will meet the technical requirements of I2RS. >>> >>> What I and others have been trying to say is that the rest of the world >>> is >>> moving towards Netconf/Restconf/Yang. Therefore, (besides it being a >>> good-enough technical choice), it is the pragmatic choice. If I2RS wants >>> to be relevant to operators, vendors, and the open source community, it >>> needs to go where all these entities want to be. >>> >>>> >>>> cheers, >>>> Jamal >>> >>> >>> Thanks, >>> Jan >>> >>>> >>>>> In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang >>>>> as >>>>> the modeling language. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> >>>>> On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >>>>> >>>>>> Jamal, >>>>>> >>>>>> Here are two criteria to be considered: >>>>>> 1. technical >>>>>> 2. commercial/business >>>>>> >>>>>> We can discuss pros and cons for both, but have to state that from >>>>>> business perspective for Juniper going with RESTCONF/YANG make more >>>>>> sense. We already built the Junos model in YANG and >>>>>> have or are in process of building needed tools. Same goes for >>>>>> RESTCONF. >>>>>> We have NETCONF implemented in Junos and are working on RESTCONF >>>>>> implementation. >>>>>> Many carriers adopted or are adopting NETCONF/YANG, are looking into >>>>>> RESTCONF as well, so this looks like a low hanging fruit from >>>>>> business >>>>>> perspective. >>>>>> >>>>>> Looking at technical aspect, unless there is a very compelling reason >>>>>> (and there might be, but I'm not aware of it), don't see reason to >>>>>> switch >>>>> >from RESTCONF and YANG. >>>>>> We can find out down the line that RESTCONF/YANG was the wrong way to >>>>>> go, >>>>>> but that can be always changed. From my perspective it looks right >>>>>> today. >>>>>> >>>>>> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>>>> >>>>>> Dean >>>>>> >>>>>> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim >>>>>> wrote: >>>>>> >>>>>>> Ok, since nobody is saying anything i'll bite. >>>>>>> How would you like for this discussion to proceed? >>>>>>> >>>>>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe >>>>>>> wrote: >>>>>>>> Dear I2RSers, >>>>>>>> >>>>>>>> At the last I2RS WG meeting there was a great deal of >>>>>>>> conversation >>>>>>>> regarding selection of both modeling language and underlying >>>>>>>> transport >>>>>>>> protocol. Consensus at the time was to make use of Yang and >>>>>>>> (NetConf >>>>>>>> or >>>>>>>> RestConf) (unclear). >>>>>>>> >>>>>>> >>>>>>> And i believe the view, as correctly presented by you, is for folks >>>>>>> to >>>>>>> go back >>>>>>> and make educated decisions by actually getting knowledgeable about >>>>>>> the different views presented. "Consensus" that you described above >>>>>>> to me looked like a pageant popularity contest not based on >>>>>>> anything >>>>>>> technical ("who likes contestant in the blue shirt? please cheer for >>>>>>> them"). >>>>>>> >>>>>>> In my opinion i dont think the requirements are clear. >>>>>>> >>>>>>> Will that get the crickets stop chirping? >>>>>>> >>>>>>> cheers, >>>>>>> jamal >>>>>>> >>>>>>>> Before coming to a final consensus, we'd like to give people >>>>>>>> adequate >>>>>>>> time >>>>>>>> to review source material, marshall arguments and discuss on the >>>>>>>> mailing >>>>>>>> list. To this end, we're asking that interested parties do just >>>>>>>> this >>>>>>>> over >>>>>>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>>>>> we'll be >>>>>>>> initiating a consensus call that will last an additional two weeks, >>>>>>>> with the >>>>>>>> aim of converging modeling language / protocol by Friday, 5/9. >>>>>>>> >>>>>>>> The consensus call should also generate proposals for any material >>>>>>>> changes >>>>>>>> required to the underlying protocols. These proposals in turn will >>>>>>>> form the >>>>>>>> basis for a later draft including gap analysis and said changes. >>>>>>>> Those >>>>>>>> strongly in favor of one protocol over another should be prepared >>>>>>>> to >>>>>>>> contribute to this analysis. >>>>>>>> >>>>>>>> >>>>>>>> best, >>>>>>>> >>>>>>>> -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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Sat Apr 19 02:55:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30BF1A00D8 for ; Sat, 19 Apr 2014 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCd_krxBNqh1 for ; Sat, 19 Apr 2014 02:55:09 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC91A00CD for ; Sat, 19 Apr 2014 02:55:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas Nadeau'" , "'b nitin'" References: In-Reply-To: Date: Sat, 19 Apr 2014 05:54:50 -0400 Message-ID: <000d01cf5bb5$6920d000$3b627000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CF5B93.E2104170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1ARromV+20xeTIgCZUuGN6fm/qwFYYO9gmsKlahA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/nQCOzyhrywGvknjZf54po8s88s4 Cc: i2rs@ietf.org, sarikaya@ieee.org, 'Crabbe Edward' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 09:55:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01CF5B93.E2104170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom: On this 100% agreement with you - that those who wished to support OF-Config should have presented at IETF 89. Sue From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Friday, April 18, 2014 1:42 PM To: b nitin Cc: sarikaya@ieee.org; Susan Hares; i2rs@ietf.org; Crabbe Edward; Dean Bogdanovic; Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model On Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur wrote: If the study showed that OF-Config did not meet the requirements, that is fine but I heard no one said that. On Feb 5th, Alia Atlas said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01243.html > Gap Analysis for different Protocols: I2RS needs to select a protocol to use. I believe that we have volunteers for discussing RESTCONF. > We'd welcome hearing from others who can provide at least a presentation for review before IETF and preferably a quick draft as well. On Feb 27th, Ed Crabbe said: http://www.ietf.org/mail-archive/web/i2rs/current/msg01291.html > The I2RS agenda has been posted. Those who think OF-Config should have been a candidate, should have presented at the IETF; or at least started a discussion on the mailing list. My 2 cents Nitin I agree %100 with your 2 cents. --Tom _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_000E_01CF5B93.E2104170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom:

 

On this 100% agreement with you – that those who wished to = support OF-Config should have presented at IETF 89. =

 

Sue

 

From:= = Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Friday, = April 18, 2014 1:42 PM
To: b nitin
Cc: = sarikaya@ieee.org; Susan Hares; i2rs@ietf.org; Crabbe Edward; Dean = Bogdanovic; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on = I2RS protocol and model

 

 

On = Apr 18, 2014:12:46 PM, at 12:46 PM, Nitin Bahadur <nitin_bahadur@yahoo.com> = wrote:



 =

 =

If the = study showed that OF-Config did not meet the requirements, that is fine = but I heard no one said that.

 =

 =

 =

> Gap = Analysis for different Protocols:  I2RS needs to select a protocol = to use.  I believe that we have volunteers for discussing = RESTCONF. 

> We'd = welcome hearing from others who can provide at least a presentation for = review before IETF and preferably a quick draft as = well.

 =

> The = I2RS agenda has been posted.  

 =

Those who = think OF-Config should have been a candidate, should have presented at = the IETF; or at least started a discussion on the mailing = list.

 =

My 2 = cents

Nitin<= /o:p>

 

        &n= bsp;   I agree %100 with your 2 = cents.

 

        &n= bsp;   --Tom

 



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

 

------=_NextPart_000_000E_01CF5B93.E2104170-- From nobody Sat Apr 19 03:44:01 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E701A0133 for ; Sat, 19 Apr 2014 03:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVGnLOCuEa3Z for ; Sat, 19 Apr 2014 03:43:58 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFF21A0132 for ; Sat, 19 Apr 2014 03:43:57 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so4746883veb.1 for ; Sat, 19 Apr 2014 03:43:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=hw2BXnetf/l0HAupXMTxpxuqbU1qUvdxoTyBe6l0QVE=; b=C0Dogul/KyhtytMWPlP2cQCA2mjjzfaL+DG0Ct2pC4gTUlKv1AzhiBG44YPm1SlHCZ mTZrZoJjgToI4gQB18ncLwqVR7WYWOeeCf8jOnQrlReGzEesD6adkZ+adI5w1n4cI+h/ UR6Ca/I/fYmWGW+w6OtO9zLhC6V8kqGeqJcs0Sna2Qsf1lPuZFoMj+rpt/dx8Ey+whWq M6/XbAcfYqm4lUf6HL3GWhOA4dmJ4ctR5SruDOD5wGaFb3qvZzNWKR3Bhk7xL6hV2aB9 zjrV5NSVkmqrzRxAXtRrG4iUy1y5mCrzJMXuUTkGXNM/C/GPF/R5FDNKWjudvE8JWfi9 uC1Q== X-Gm-Message-State: ALoCoQn/xXuu2VXvmReVLQfQUAgE9Hdktt4iN0VB2kwPWxQFl+qFemnDjk3arNm9k9mpM/f92dOm X-Received: by 10.58.55.170 with SMTP id t10mr44019vep.29.1397904233499; Sat, 19 Apr 2014 03:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 03:43:33 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 06:43:33 -0400 Message-ID: To: Edward Crabbe , "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/yJjang8ekJrAMD2v4QqN5nmQ6HM Subject: [i2rs] consensus on I2RS protocol and model Requirements WAS(Re: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 10:44:00 -0000 So 54 emails later.... I still dont see the requirements. Of course even before London i was asking for what the requirements are and got nothing. I ended putting a draft handwaving what the requirements are. Nobody agreed or disagreed. Yes, there is a protocols requirement draft that just died. There is nothing for the model. Folks, to solve engineering problems (The "E" in IETF) dont we need requirements first? There are use cases in place. Nothing so far has been extracted out of that to define what the requirements for a protocol/model are. If Yang/Netconf/Restconf is the answer - what is the question? ;-> Jan is the only person who has actually addressed this issue. To quote: > > The I2RS requirements have been gathered, and Netconf and Yang have been > analyzed against the requirements by Andy and Dean at the last IETF. I > find no fault in their analysis, so IMHO Netconf / Yang (with possibly > small modifications) will meet the technical requirements of I2RS. > Andy, Dean and myself included presented based on our view of what the requirements are. There are no requirements spelt out anywhere. Why is this such a hard question to ask around an engineering forum? cheers, jamal On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: > Dear I2RSers, > > > At the last I2RS WG meeting there was a great deal of conversation > regarding selection of both modeling language and underlying transport > protocol. Consensus at the time was to make use of Yang and (NetConf or > RestConf) (unclear). > > Before coming to a final consensus, we'd like to give people adequate time > to review source material, marshall arguments and discuss on the mailing > list. To this end, we're asking that interested parties do just this over > the course of the next ~two weeks. Following that period, on 4/28, we'll be > initiating a consensus call that will last an additional two weeks, with the > aim of converging modeling language / protocol by Friday, 5/9. > > The consensus call should also generate proposals for any material changes > required to the underlying protocols. These proposals in turn will form the > basis for a later draft including gap analysis and said changes. Those > strongly in favor of one protocol over another should be prepared to > contribute to this analysis. > > > best, > > -ed > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Sat Apr 19 03:51:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFE1A015A for ; Sat, 19 Apr 2014 03:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97f1aYALZT1Q for ; Sat, 19 Apr 2014 03:51:53 -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 43F111A012A for ; Sat, 19 Apr 2014 03:51:53 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so4622406veb.16 for ; Sat, 19 Apr 2014 03:51:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=4Jvw2kxysvjEWKGUmtxl7iPM8xZRKlJu8hCE/6O8QWs=; b=dFDLQnz8u7PqUsolYFQPrQRABW6BG+Zcx3N9DtsMzS84Hxpl2FaonzUZkRqi5L8jlm 9G2ZwKJNSMmfTcbTZXGAPO8ukO2RXoKN6wlM193SbiBkntyxFdf8/+FQm+CrFRTeo5T9 IEJgKkT3cCjzRD4+UdwX9HRR8wSNdyY1Lht9Lj6ivC63W6/UmGwgU/F3+8+vFFSMEZHT biLKgjffIH0KIjNK3vXDoCEIQzW1Tcb3nw5G6bNT4wZXcPGYOWqxCtpWGbhp5WAiVaq9 FK8sB/3y7++aY03Da/c2r8h/JkLX9VWa01dkOkxMvws703HQPYNBvsKcH/9Bq0kOA0z6 npCg== X-Gm-Message-State: ALoCoQkvqcMO20lrTfsm74jdkf1tm5jKrGLPDOqJbt5Plm8xwDn4pDzq6UFhqTwCxrgjo4DYLfe+ X-Received: by 10.58.220.161 with SMTP id px1mr23224971vec.13.1397904708687; Sat, 19 Apr 2014 03:51:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 03:51:28 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 06:51:28 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1NHZ68d_z2ZgCaQ9NoXs0wDj9jg Subject: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 10:51:55 -0000 Folks, No offense intended, but can we please have something a little more profound than a +1 when agreeing or disagreeing? All i can see in my head when someone says +1 is: https://www.youtube.com/watch?v=_j9QeUoPOi4 I think a +1 should complete with "because ...." cheers, jamal From nobody Sat Apr 19 05:21:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859361A017A for ; Sat, 19 Apr 2014 05:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.844 X-Spam-Level: ** X-Spam-Status: No, score=2.844 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR6cN4e7qE5C for ; Sat, 19 Apr 2014 05:21:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 596731A0133 for ; Sat, 19 Apr 2014 05:21:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Mach Chen'" , References: In-Reply-To: Date: Sat, 19 Apr 2014 08:17:22 -0400 Message-ID: <000001cf5bc9$51f0bf80$f5d23e80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIqEPuwDn5/mNVisorRCPuW5Z0M0ppjXq7g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mpsKwcerLUWMOvNi0p7F_XRe0LM Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 12:21:17 -0000 Nitin: I've been digging into the RBNF forms in Section 6 draft-ietf-i2rs-rib-info-model-02 based on what you indicated to mach. = I would like to confirm I understand your intent of the RBNF. =20 1) match will augment its sequence with a type=20 ::=3D | | | = | =20 Will be redefined as:=20 ::=3D [ | | = | mac-route> | ] This sequence occurs wit: 1 route-type, 1 following definition. =20 Route-type::=3D | | | | =20 (these are the values) Do I understand your values? =20 2) Let's take one example of your IPv4=20 ::=3D [ | = | =20 ::=3D=20 ::=3D =20 Are you intending to allow: destination-ipv4-address or = source-ipv4-address or the combination of ? = If so, do you want a tag to identify the type of form it is?=20 ::=3D [ | | = ]=20 ::=3D| | | < 3) Let's take the use case of matching a destination-ipv4-address:=20 ::=3D I doubt you really wanted the redundant tag. This will occur for IPv6 = as well. If you use a tag form that has ip-form ::=20 4) Would a corrections to the above be useful: Given the above you could simplify your match RBNF: :: =3D [ipv4-route | ipv6-route | = mpls-route | mac-route] ipv4-route ::=3D [ipv4-prefix] | [ipv4-prefix][ipv4-prefix]=20 ipv6-route ::=3D [ipv6-prefix] | [ipv6-prefix][ipv6-prefix] mpls-route::=3D [mpls-label] | [mpls-label][mpls-label] mac-route::=3D [MAC_ADDRESS] | [MAC_ADDRESS][MAC_ADDRESS] These basic variables are defined in YANG Data Models and FORCES data models. You do not need to go further with the simple definitions.=20 5) Why did you specify differently?=20 multicast-source-ipv4-address ::=3D multicast-source-ipv6-address ::=3D Where you trying to express some checking that the node should have on = these address? I've got similar questions on , = and . I will start a different mail thread for = these.=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Friday, February 14, 2014 4:55 PM To: Mach Chen; i2rs@ietf.org Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 Hi Mach, Thanks for your comments. Please see inline below.. >General comments: >According to the recent discussion about "Multi-Headed Control", seems=20 >there needs to define the unit of the "data" that will be changed by=20 >the I2RS clients in this rib im document. > > >Specific Comments: >1. Section 6 > ::=3D > ::=3D ( ) > >1.1 Seems the brackets of " ( )" are redundant. Yes. We will remove them in next rev. > >1.2 What's the and stands for here? The route type? Yes..route type. >=20 >If so, why not apply this to the and as=20 >well ,hence ::=3D =20 >would be ::=3D = ,=20 >and ::=3D would be=20 > ::=3D I think I know what you mean. What might be more appropriate would be: ::=3D ( | = | ( )) Or the other way to model this would be: ::=3D ( | | | | ) = ::=3D | | | | > > >2. Section 6 > ::=3D | | > | , > >and > > ::=3D | | | > | There are four rib=20 >families defined, but there are five types route, so which rib family=20 >does the interface-route belong to? Seems there needs a=20 >. An interface is part of a routing-instance ::=3D [] [] The purpose of a RIB family is essentially to identify what protocol treatment to give to a packet. For example, for an IPv4 packet, you = would do a TTL check. For an interface-route, there is no such behavior. An IPv4 route can be associated with any interface in the = above. Interface-route is more of a container (match) for all packets coming in = on an interface. The network-device can choose to do DPI on the packet and = run checks before it processes interface-route matching packets, or it can = just choose to do what the interface-route says (match all packet coming in interface-A and send them out via interface-B). So in summary, I don=B9t see a real need for INTERFACE_RIB_FAMILY. >=20 >3. Section 6 > ::=3D > [] > [] > >When a route was installed in the RIB, there should be an indication to = >identify from which protocols (e.g., ISIS, OSPF, BGP, I2RS, CLI etc.)=20 >the route is. So there may need a attribute. >Maybe similar like this: > ::=3D | | | | | |=20 > >| > >How do you think? Yes, there =B3could=B2 be such an optional attribute. What we need to = think more towards is, is just the protocol-type sufficient or do you need other = things as well, like protocol peer address (just thinking aloud). > >4. Section 6 > ::=3D | | | | > >Should the be more specific to and ? What does the=20 > really intend for? UDP, TCP? And there may be other tunnel, e.g., l2tp. Makes sense to have IPv4 and IPv6 called out separately. The IPv4/v6 is basically for IP-in-IP tunnels. And yes, there could be other tunnels = like L2TP, etc. I guess we don=B9t want to create an exhaustive list of = tunnels in the info model, but rather leave it to the data model and data-model extensions. We=B9ll split the v4/v6 stuff in next rev. > >5. Section 7.1 > >AS-data information and AS length comparison are BGP related stuff,=20 >this should be transparent to RIB manager. I am not sure whether this=20 >belongs to Rib info model. This has been removed in the latest version. Thanks Nitin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sat Apr 19 05:55:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7501A01FB for ; Sat, 19 Apr 2014 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfQTEzbH7rzY for ; Sat, 19 Apr 2014 05:55:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 101631A0194 for ; Sat, 19 Apr 2014 05:55:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Sat, 19 Apr 2014 08:55:07 -0400 Message-ID: <000f01cf5bce$97da7220$c78f5660$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CF5BAD.10C94750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9bzWl/c2iH4l1zQhqqdH1Q3+lFcQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E16S_Gg8No49gfuCCIJrpbJz4Ec Cc: Qin Wu Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 draft - rib-family variable X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 12:55:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CF5BAD.10C94750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin, Ron: Kini, Jan: This question RIB Grammar section 6: ::= [ . ][ENABLE_IP_RPF_CHECK] ::== | | | In your grammar, my understanding of the "." is limited. I assumed this means that this is a sequence of routes. You do not provide a grammar for RIB_NAME. Are you looking for this to be an ASCII String or what? You do not provide a grammar for ENABLE_IP_RPF_CHECK - what is your grammar type for this? My initial reading had been that , , and [ENABLE_IP_RPF_CHECK] only occur once even if you have 10K routes. Sue Hares ------=_NextPart_000_0010_01CF5BAD.10C94750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin, = Ron: Kini, Jan:

 

This = question RIB Grammar section 6:

 

<rib>::=3D<RIB_NAME> <rib-family> = [<route> … ][ENABLE_IP_RPF_CHECK]

<rib-family>::=3D=3D<IPV4_RIB_FAMILY> | = <IPV6_RIB_FAMILY> | <MPLS_RIB_FAMILY> | = <IEEE_MAC_RIB_FAMILY>

 

In your = grammar, my understanding of the “…” is limited.  = I assumed this means that this is a sequence of routes.

 

You do not = provide a grammar for RIB_NAME.  Are you looking for this to be an = ASCII String or what?

You do not = provide a grammar for ENABLE_IP_RPF_CHECK – what is your grammar = type for this?

 

My initial = reading had been that <RIB_NAME>, <rib-family>, and = [ENABLE_IP_RPF_CHECK] only occur once even if you have 10K routes. =

 

Sue Hares

------=_NextPart_000_0010_01CF5BAD.10C94750-- From nobody Sat Apr 19 07:12:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C071A023D for ; Sat, 19 Apr 2014 07:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg2Swsvsl5rT for ; Sat, 19 Apr 2014 07:12:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id A6A831A01D4 for ; Sat, 19 Apr 2014 07:12:26 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.918.8; Sat, 19 Apr 2014 14:12:20 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Sat, 19 Apr 2014 14:12:19 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepACAAKqNAIAA9xaA Date: Sat, 19 Apr 2014 14:12:18 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <009501cf5b5d$d49403f0$7dbc0bd0$@ndzh.com> In-Reply-To: <009501cf5b5d$d49403f0$7dbc0bd0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(13464003)(51704005)(24454002)(57306001)(76482001)(99286001)(99396002)(81342001)(33656001)(79102001)(80022001)(66066001)(19580405001)(50226001)(81542001)(4396001)(80976001)(83322001)(19580395003)(62966002)(31966008)(74662001)(20776003)(74502001)(83716003)(87286001)(89996001)(88136002)(46102001)(36756003)(82746002)(83072002)(2656002)(87936001)(50986999)(76176999)(93916002)(92726001)(92566001)(86362001)(561944002)(85852003)(77982001)(77156001)(15975445006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:AC74F1F9.97E2D453.71F3B14B.5EE4FD4D.20522; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <9C60CBB3867FA5489701CAE401B60C32@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5dTvBc7b0qTxi34AmaobfCpfUNY Cc: "" , Edward Crabbe , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 14:12:31 -0000 Susan, For YANG following is necessary: publish current model in YANG and YANG compiler We are looking at creating some additional tools to make easier for develop= ers to work with YANG and Junos, but the above two are main conditions. I usually start with informational model and try to see how will it work wi= th data model. And then tweak certain things here and there. For very few t= hings I went directly to data models, but the info model was already very w= ell defined in my head :-) Dean On Apr 18, 2014, at 7:27 PM, Susan Hares wrote: > Dean: >=20 > Could you let me know what tool chains you consider necessary for > RESTCONF/Yang?=20 >=20 > Do you start with informational models in the Yang/RESTCONF world? >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic > Sent: Friday, April 18, 2014 9:18 AM > To: Jamal Hadi Salim > Cc: i2rs@ietf.org; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model >=20 > Jamal, >=20 > Here are two criteria to be considered: > 1. technical > 2. commercial/business >=20 > We can discuss pros and cons for both, but have to state that from busine= ss > perspective for Juniper going with RESTCONF/YANG make more sense. We alre= ady > built the Junos model in YANG and have or are in process of building need= ed > tools. Same goes for RESTCONF. We have NETCONF implemented in Junos and a= re > working on RESTCONF implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so this looks like a low hanging fruit from business > perspective. >=20 > Looking at technical aspect, unless there is a very compelling reason (an= d > there might be, but I'm not aware of it), don't see reason to switch from > RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to go, > but that can be always changed. From my perspective it looks right today. >=20 > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >=20 > Dean >=20 > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >=20 >> Ok, since nobody is saying anything i'll bite. >> How would you like for this discussion to proceed? >>=20 >> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>> Dear I2RSers, >>>=20 >>> At the last I2RS WG meeting there was a great deal of conversation=20 >>> regarding selection of both modeling language and underlying=20 >>> transport protocol. Consensus at the time was to make use of Yang=20 >>> and (NetConf or >>> RestConf) (unclear). >>>=20 >>=20 >> And i believe the view, as correctly presented by you, is for folks to=20 >> go back and make educated decisions by actually getting knowledgeable=20 >> about the different views presented. "Consensus" that you described=20 >> above to me looked like a pageant popularity contest not based on=20 >> anything technical ("who likes contestant in the blue shirt? please chee= r > for them"). >>=20 >> In my opinion i dont think the requirements are clear. >>=20 >> Will that get the crickets stop chirping? >>=20 >> cheers, >> jamal >>=20 >>> Before coming to a final consensus, we'd like to give people=20 >>> adequate time to review source material, marshall arguments and=20 >>> discuss on the mailing list. To this end, we're asking that=20 >>> interested parties do just this over the course of the next ~two=20 >>> weeks. Following that period, on 4/28, we'll be initiating a=20 >>> consensus call that will last an additional two weeks, with the aim of > converging modeling language / protocol by Friday, 5/9. >>>=20 >>> The consensus call should also generate proposals for any material=20 >>> changes required to the underlying protocols. These proposals in=20 >>> turn will form the basis for a later draft including gap analysis and=20 >>> said changes. Those strongly in favor of one protocol over another=20 >>> should be prepared to contribute to this analysis. >>>=20 >>>=20 >>> best, >>>=20 >>> -ed >>>=20 >>> _______________________________________________ >>> 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 >>=20 >>=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 >=20 From nobody Sat Apr 19 07:22:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84A1A0241 for ; Sat, 19 Apr 2014 07:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0rioW06Lgqw for ; Sat, 19 Apr 2014 07:22:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3F1A01D4 for ; Sat, 19 Apr 2014 07:22:35 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.921.12; Sat, 19 Apr 2014 14:22:29 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Sat, 19 Apr 2014 14:22:29 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepACAAIEXAIAAA4mAgAAu1oCAAAWPgIAAEnAAgAACOgCAANbMAA== Date: Sat, 19 Apr 2014 14:22:29 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(24454002)(51704005)(85852003)(87936001)(57306001)(76482001)(83072002)(36756003)(46102001)(74502001)(99286001)(20776003)(4396001)(66066001)(89996001)(76176999)(50986999)(77982001)(81542001)(50226001)(62966002)(92726001)(99396002)(80022001)(19580405001)(88136002)(83322001)(92566001)(33656001)(19580395003)(79102001)(81342001)(87286001)(83716003)(31966008)(74662001)(80976001)(77156001)(93916002)(86362001)(82746002)(2656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:28864A2E.2A269F2F.B1D92D0C.D4E1C9D9.2020C; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B667BC980144B428365ABCD41BBE8FF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_vaYn94xKjdAbiDCCZgc6zpSycE Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 14:22:40 -0000 On Apr 18, 2014, at 9:33 PM, Jamal Hadi Salim wrote: > On Fri, Apr 18, 2014 at 9:25 PM, Jan Medved (jmedved) = wrote: >=20 > [..] >=20 >> I actually think it is - what's wrong with working code? ;-) >=20 > Unless you have _working_ I2RS code - this is a meaningless statement to > make. > How about we strive to show up with some working I2RS code at the next > meeting? >=20 Jamal,=20 What is working i2rs code? From Juniper perspective, I can claim having PoC= i2rs code, as I can dynamically create REST APIs (will not call them RESTc= onf, as it has only partial compliance with current RESTconf draft) based o= n the service described on the device. The PoC functionally is very close i= 2rs architecture document and with that can see what services can be create= d and abstracted for i2rs. So for i2rs, as long I can create a data model for a service, where the ser= vice is simple as add or delete route and can programmatically consume that= service, it is i2rs. Many vendors today can do that with NETCONF/RESTCONF/= YANG and we are voicing our preference for that. Dean From nobody Sat Apr 19 07:22:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4351A0250 for ; Sat, 19 Apr 2014 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j4rxxQyyE3W for ; Sat, 19 Apr 2014 07:22:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA11A0218 for ; Sat, 19 Apr 2014 07:22:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <009501cf5b5d$d49403f0$7dbc0bd0$@ndzh.com> In-Reply-To: Date: Sat, 19 Apr 2014 10:22:31 -0400 Message-ID: <000601cf5bda$cd989200$68c9b600$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkCAObk2QHzXla2l6zoDLA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0Ib1P16I7cz2FuviDBbkKDV94f4 Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 14:22:43 -0000 Dean: Thank you for the prompt input. This really helps me! I'm going through the informational models this weekend to try to create a common platform. If you have time to comment over the next few days on the RIB-info models, it would help. I think the RBNF is causing rather than helping with issues. I've switched over to the UML focus because it helps me find the issues with the relationships to simplify the models. Sue -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Saturday, April 19, 2014 10:12 AM To: Susan Hares Cc: Jamal Hadi Salim; ; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model Susan, For YANG following is necessary: publish current model in YANG and YANG compiler We are looking at creating some additional tools to make easier for developers to work with YANG and Junos, but the above two are main conditions. I usually start with informational model and try to see how will it work with data model. And then tweak certain things here and there. For very few things I went directly to data models, but the info model was already very well defined in my head :-) Dean On Apr 18, 2014, at 7:27 PM, Susan Hares wrote: > Dean: > > Could you let me know what tool chains you consider necessary for > RESTCONF/Yang? > > Do you start with informational models in the Yang/RESTCONF world? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic > Sent: Friday, April 18, 2014 9:18 AM > To: Jamal Hadi Salim > Cc: i2rs@ietf.org; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model > > Jamal, > > Here are two criteria to be considered: > 1. technical > 2. commercial/business > > We can discuss pros and cons for both, but have to state that from > business perspective for Juniper going with RESTCONF/YANG make more > sense. We already built the Junos model in YANG and have or are in > process of building needed tools. Same goes for RESTCONF. We have > NETCONF implemented in Junos and are working on RESTCONF implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so this looks like a low hanging fruit from business > perspective. > > Looking at technical aspect, unless there is a very compelling reason > (and there might be, but I'm not aware of it), don't see reason to > switch from RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to > go, but that can be always changed. From my perspective it looks right today. > > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > > Dean > > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: > >> Ok, since nobody is saying anything i'll bite. >> How would you like for this discussion to proceed? >> >> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>> Dear I2RSers, >>> >>> At the last I2RS WG meeting there was a great deal of conversation >>> regarding selection of both modeling language and underlying >>> transport protocol. Consensus at the time was to make use of Yang >>> and (NetConf or >>> RestConf) (unclear). >>> >> >> And i believe the view, as correctly presented by you, is for folks >> to go back and make educated decisions by actually getting >> knowledgeable about the different views presented. "Consensus" that >> you described above to me looked like a pageant popularity contest >> not based on anything technical ("who likes contestant in the blue >> shirt? please cheer > for them"). >> >> In my opinion i dont think the requirements are clear. >> >> Will that get the crickets stop chirping? >> >> cheers, >> jamal >> >>> Before coming to a final consensus, we'd like to give people >>> adequate time to review source material, marshall arguments and >>> discuss on the mailing list. To this end, we're asking that >>> interested parties do just this over the course of the next ~two >>> weeks. Following that period, on 4/28, we'll be initiating a >>> consensus call that will last an additional two weeks, with the aim >>> of > converging modeling language / protocol by Friday, 5/9. >>> >>> The consensus call should also generate proposals for any material >>> changes required to the underlying protocols. These proposals in >>> turn will form the basis for a later draft including gap analysis >>> and said changes. Those strongly in favor of one protocol over >>> another should be prepared to contribute to this analysis. >>> >>> >>> best, >>> >>> -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 >> >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > From nobody Sat Apr 19 07:47:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEA1A0007 for ; Sat, 19 Apr 2014 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqW2rpB-iweJ for ; Sat, 19 Apr 2014 07:47:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8A1A0002 for ; Sat, 19 Apr 2014 07:47:38 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.918.8; Sat, 19 Apr 2014 14:47:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Sat, 19 Apr 2014 14:47:32 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepACAAKqNAIAA9xaAgAAC3ICAAAb7AA== Date: Sat, 19 Apr 2014 14:47:31 +0000 Message-ID: <52E275BD-B0B8-4B0B-A87F-80388223A7D3@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <009501cf5b5d$d49403f0$7dbc0bd0$@ndzh.com> <000601cf5bda$cd989200$68c9b600$@ndzh.com> In-Reply-To: <000601cf5bda$cd989200$68c9b600$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(24454002)(13464003)(46034005)(51704005)(189002)(377454003)(199002)(76176999)(86362001)(33656001)(36756003)(50986999)(93916002)(15975445006)(92566001)(19580405001)(46102001)(83716003)(92726001)(81542001)(81342001)(80976001)(83322001)(82746002)(20776003)(62966002)(79102001)(19580395003)(561944002)(89996001)(57306001)(74662001)(77982001)(77156001)(66066001)(50226001)(31966008)(99286001)(2656002)(83072002)(87936001)(80022001)(76482001)(85852003)(74502001)(88136002)(4396001)(87286001)(99396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:EC74F129.97E2D747.F1F3B147.5EE4F54D.205B7; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <204E455E8FF0AE4895E298528FA6DA82@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ib2m-3pOCm6-ERBlC6OMdkK3HoQ Cc: "" , Edward Crabbe , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 14:47:46 -0000 Susan, I'm currently busy with few other things, but wanted to see how some of my = work aligns with rib-info models, so planned to read the rib-info models by= mid week anyway.=20 Dean On Apr 19, 2014, at 10:22 AM, Susan Hares wrote: > Dean: >=20 > Thank you for the prompt input. This really helps me! I'm going through = the > informational models this weekend to try to create a common platform. =20 >=20 > If you have time to comment over the next few days on the RIB-info models= , > it would help. I think the RBNF is causing rather than helping with issu= es. > I've switched over to the UML focus because it helps me find the issues w= ith > the relationships to simplify the models.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net]=20 > Sent: Saturday, April 19, 2014 10:12 AM > To: Susan Hares > Cc: Jamal Hadi Salim; ; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model >=20 > Susan, >=20 > For YANG following is necessary: >=20 > publish current model in YANG > and > YANG compiler >=20 > We are looking at creating some additional tools to make easier for > developers to work with YANG and Junos, but the above two are main > conditions. >=20 > I usually start with informational model and try to see how will it work > with data model. And then tweak certain things here and there. For very f= ew > things I went directly to data models, but the info model was already ver= y > well defined in my head :-) >=20 > Dean >=20 > On Apr 18, 2014, at 7:27 PM, Susan Hares wrote: >=20 >> Dean: >>=20 >> Could you let me know what tool chains you consider necessary for=20 >> RESTCONF/Yang? >>=20 >> Do you start with informational models in the Yang/RESTCONF world? >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic >> Sent: Friday, April 18, 2014 9:18 AM >> To: Jamal Hadi Salim >> Cc: i2rs@ietf.org; Edward Crabbe >> Subject: Re: [i2rs] consensus on I2RS protocol and model >>=20 >> Jamal, >>=20 >> Here are two criteria to be considered: >> 1. technical >> 2. commercial/business >>=20 >> We can discuss pros and cons for both, but have to state that from=20 >> business perspective for Juniper going with RESTCONF/YANG make more=20 >> sense. We already built the Junos model in YANG and have or are in=20 >> process of building needed tools. Same goes for RESTCONF. We have=20 >> NETCONF implemented in Junos and are working on RESTCONF implementation. >> Many carriers adopted or are adopting NETCONF/YANG, are looking into=20 >> RESTCONF as well, so this looks like a low hanging fruit from business=20 >> perspective. >>=20 >> Looking at technical aspect, unless there is a very compelling reason=20 >> (and there might be, but I'm not aware of it), don't see reason to=20 >> switch from RESTCONF and YANG. >> We can find out down the line that RESTCONF/YANG was the wrong way to=20 >> go, but that can be always changed. From my perspective it looks right > today. >>=20 >> Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>=20 >> Dean >>=20 >> On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >>=20 >>> Ok, since nobody is saying anything i'll bite. >>> How would you like for this discussion to proceed? >>>=20 >>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>>> Dear I2RSers, >>>>=20 >>>> At the last I2RS WG meeting there was a great deal of conversation=20 >>>> regarding selection of both modeling language and underlying=20 >>>> transport protocol. Consensus at the time was to make use of Yang=20 >>>> and (NetConf or >>>> RestConf) (unclear). >>>>=20 >>>=20 >>> And i believe the view, as correctly presented by you, is for folks=20 >>> to go back and make educated decisions by actually getting=20 >>> knowledgeable about the different views presented. "Consensus" that=20 >>> you described above to me looked like a pageant popularity contest=20 >>> not based on anything technical ("who likes contestant in the blue=20 >>> shirt? please cheer >> for them"). >>>=20 >>> In my opinion i dont think the requirements are clear. >>>=20 >>> Will that get the crickets stop chirping? >>>=20 >>> cheers, >>> jamal >>>=20 >>>> Before coming to a final consensus, we'd like to give people=20 >>>> adequate time to review source material, marshall arguments and=20 >>>> discuss on the mailing list. To this end, we're asking that=20 >>>> interested parties do just this over the course of the next ~two=20 >>>> weeks. Following that period, on 4/28, we'll be initiating a=20 >>>> consensus call that will last an additional two weeks, with the aim=20 >>>> of >> converging modeling language / protocol by Friday, 5/9. >>>>=20 >>>> The consensus call should also generate proposals for any material=20 >>>> changes required to the underlying protocols. These proposals in=20 >>>> turn will form the basis for a later draft including gap analysis=20 >>>> and said changes. Those strongly in favor of one protocol over=20 >>>> another should be prepared to contribute to this analysis. >>>>=20 >>>>=20 >>>> best, >>>>=20 >>>> -ed >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>=20 >>=20 >=20 >=20 From nobody Sat Apr 19 08:23:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83BD1A0019 for ; Sat, 19 Apr 2014 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Fbo4yA1ETJ for ; Sat, 19 Apr 2014 08:22:59 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 488911A001D for ; Sat, 19 Apr 2014 08:22:59 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93]:56722 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WbX6U-000557-4N; Sat, 19 Apr 2014 15:22:54 +0000 From: "Russ White" To: "'Joel M. Halpern'" , "'Jan Medved \(jmedved\)'" , "'Jamal Hadi Salim'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> In-Reply-To: <5351C11F.1070109@joelhalpern.com> Date: Sat, 19 Apr 2014 11:22:39 -0400 Message-ID: <001a01cf5be3$345abf60$9d103e20$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBT5eIBUQg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/H3DWMwSv5LNUc5NSaD8d8SO4W_k Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 15:23:03 -0000 > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. :-) Russ From nobody Sat Apr 19 08:24:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F20F1A0013 for ; Sat, 19 Apr 2014 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ZMxE_rtb9I for ; Sat, 19 Apr 2014 08:24:36 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 475AA1A0008 for ; Sat, 19 Apr 2014 08:24:36 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93]:56737 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WbX7y-00055p-40; Sat, 19 Apr 2014 15:24:26 +0000 From: "Russ White" To: , "'Susan Hares'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <007c01cf5b1c$c2399800$46acc800$@ndzh.com> In-Reply-To: Date: Sat, 19 Apr 2014 11:24:11 -0400 Message-ID: <003401cf5be3$6b3b35a0$41b1a0e0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBx4SeuQMuvjsDAniBsB+XkSYW4A== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hROGT_8wVK0JtUJsBukbOOW8EPo Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 15:24:37 -0000 > But the point is that a more realistic choice should be between these two > choices. Why? :-) Russ From nobody Sat Apr 19 10:23:21 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238051A004C for ; Sat, 19 Apr 2014 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 037MKj_e8Dxk for ; Sat, 19 Apr 2014 10:23:15 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id ED8931A0041 for ; Sat, 19 Apr 2014 10:23:14 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j5so2562194qaq.14 for ; Sat, 19 Apr 2014 10:23:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nzvK0MoD5C97RDF4UnM95UcXWmUORIXnw8uZfVFX/yo=; b=ZdbDQoR+i/1McpzCfIVPkMT6uNJupD+1PiX7v5ukYbwnCj5WSIfsyQIRx6VqgafhX/ 4wWb80SLt8exZmktUZeLrdxy3/4+dTem7m4Bos/hADwJpQQ0oiK6v2wEZlLcsuhktn+1 1HbB8FLawXLLsj2BAgcoHyPfeQDa9fZ/Aoav1QB1WJzoVM+jwrma9Rs3WOgkyaF6BePF Tyo5cObZffUBkQ2jj8PRuEacqNpjG/uKTrS17lJ6onO9u5gFTTk6cm8LT1hynB8H4Z9s 5IH0vdo113Uh2EXvEINsDZm+FUVk9F0TheAszMwW2Eoay5mPu9XAs58Rj7ipReiUKi4M Ca9w== X-Gm-Message-State: ALoCoQn9ntG1GsyIjNGjAaKDS5oWTgZQXynUF0V/O28g7r5fz/Xuanq0EhQGB7NdRFHcC+ohZ7Df MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr25435923qge.91.1397928190412; Sat, 19 Apr 2014 10:23:10 -0700 (PDT) Received: by 10.140.105.35 with HTTP; Sat, 19 Apr 2014 10:23:10 -0700 (PDT) X-Originating-IP: [24.21.216.213] In-Reply-To: References: Date: Sat, 19 Apr 2014 10:23:10 -0700 Message-ID: From: David Meyer To: Jamal Hadi Salim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xE5Qxp-vCoxxk8Kpx2nRZvnrulc Cc: "i2rs@ietf.org" Subject: Re: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 17:23:19 -0000 On Sat, Apr 19, 2014 at 3:51 AM, Jamal Hadi Salim wrote: > Folks, > > No offense intended, but can we please have something a little more > profound than a +1 when > agreeing or disagreeing? > All i can see in my head when someone says +1 is: > https://www.youtube.com/watch?v=_j9QeUoPOi4 > > I think a +1 should complete with "because ...." Thank you for your opinion but I trust my that my colleagues are capable of expressing their support (or lack there of) in the way that want to. In addition, given the breadth and depth of this thread (and associated history) I don't see the need to recapitulate the arguments made here in order to agree (or disagree) with the stated direction. --dmm > > cheers, > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Sat Apr 19 10:40:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436D81A0061 for ; Sat, 19 Apr 2014 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUbOlVf7hnOG for ; Sat, 19 Apr 2014 10:39:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA5E81A0052 for ; Sat, 19 Apr 2014 10:39:59 -0700 (PDT) Received: from [10.38.231.191] (unknown [166.147.97.124]) by lucidvision.com (Postfix) with ESMTP id B252B2770629; Sat, 19 Apr 2014 13:39:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Sat, 19 Apr 2014 12:39:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Meyer Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_ZwPbZ4jpwjwjdz9wEMZaattWAM Cc: "i2rs@ietf.org" , Jamal Hadi Salim Subject: Re: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 17:40:04 -0000 That was most definitely the purpose of my last +1. My intend wasn't "me too= ", but a shorthand for not rewriting exactly what Jan had said. I'd advise we keep the process management in the hands of the chairs. Tom=20 > On Apr 19, 2014, at 12:23 PM, David Meyer wrote: >=20 >> On Sat, Apr 19, 2014 at 3:51 AM, Jamal Hadi Salim wro= te: >> Folks, >>=20 >> No offense intended, but can we please have something a little more >> profound than a +1 when >> agreeing or disagreeing? >> All i can see in my head when someone says +1 is: >> https://www.youtube.com/watch?v=3D_j9QeUoPOi4 >>=20 >> I think a +1 should complete with "because ...." >=20 > Thank you for your opinion but I trust my that my colleagues are > capable of expressing their support (or lack there of) in the way that > want to. In addition, given the breadth and depth of this thread (and > associated history) I don't see the need to recapitulate the arguments > made here in order to agree (or disagree) with the stated direction. >=20 > --dmm >=20 >>=20 >> cheers, >> jamal >>=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 >=20 From nobody Sat Apr 19 10:46:12 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318361A0065 for ; Sat, 19 Apr 2014 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNB1W9BHIqXL for ; Sat, 19 Apr 2014 10:46:05 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 734AB1A0064 for ; Sat, 19 Apr 2014 10:46:05 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so2588847qab.9 for ; Sat, 19 Apr 2014 10:46:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WnoNxiPzFi7GleHScA8HBmwdml3IXhIl8hTCt5SiY1U=; b=cIJTJgcAOlh9NGrmMAibXapdGfpb6m3kvZiHWtR7NWMNEW2hPxDveiNvgJ9u6EKcLI JjZwHHBEm2TS/o1DYfpAS512YDQh9pnPyQ5RLvOkbAuCX+EZd7FVB26C0ZLLmPG5cUG4 bOfIe/NsSLJpoIXdQgA5kdPqG2otw2tom70+jpUKkUlgED071OEkwPA2tsNWpxhq+Own KYOXs+a+jskqDPRJaCmyM50KOVK6WCanzlenH0ePTXfx87S2O8LUytPOzmTl9UqQd/Q/ A2DRu1jWyDZcZstD4fK9VlNO3AXDHqpWl9Dk7PN03DN5MGtBrYbw/WVtQqWS1WNl9e59 MzGg== X-Gm-Message-State: ALoCoQlU6ZK8qPzhVPN1rGc+uWxH2W8d6RylPLyrm+07DvOjh5PeSQzkeYLZpqUxAMoI5h83W+ee MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr27294214qcn.20.1397929560970; Sat, 19 Apr 2014 10:46:00 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 19 Apr 2014 10:46:00 -0700 (PDT) In-Reply-To: <001a01cf5be3$345abf60$9d103e20$@riw.us> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> Date: Sat, 19 Apr 2014 10:46:00 -0700 Message-ID: From: Andy Bierman To: Russ White Content-Type: multipart/alternative; boundary=001a1133886ee72f1304f768d6b3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/om9TcQnvFUT0kbXqBX9y84SlRuE Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 17:46:10 -0000 --001a1133886ee72f1304f768d6b3 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > > > And the basic premise of I2RS is that there are requirements for the work > > that were not addressed properly by the existing configuration protocols. > > Otherwise the WG would not even need to discuss protocol modifications. > > So the fact that NetConf / YANG works for device configuration does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the problem, and said, > "let's use YANG." But I think we're starting to confuse the problem set > because we started by trying to boil the ocean. Once you actually get to > town, it's hard to keep in focus that you're just there for a new pitchfork > handle -- that game of checkers over there on the porch of the hotel looks > so interesting, and the hardware store has so much other stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB interface, and not > protocol, configuration, device, etc., etc., what specific points have the > use cases brought out that either NETCONF/YANG or FORCES not fulfill? One > of > the primary points was timing -- are these other systems fast enough? > > >From my perspective, these two systems don't fulfill the I2RS mandate on > the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit heavy weigh for > what > we want here. The flexibility is there, but so is the cost of that > flexibility. > Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? > > - I'm not convinced YANG has handled the atomicity issues in a way that > makes sense for the application environment we have in mind. RESTCONF seems > to go that direction, but I'm not certain it's a complete solution (?). > > YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? > So, IMHO, I think we need to either consider FORCES, or "something new." > But > we're going to have a hard time determining if this is true if we can't > make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing routes in > the RIB > - An immediate feedback system within the RESTful mold that tells the > installing process what happened, and why, with the route it just tried to > install in the RIB > > So, it seems to me that we need to return to the use cases -- there are two > in the charter. If we want to discuss adding others, that's fine, but we > need to gain some focus, and stop trying to boil the ocean, if we want to > make any progress. > > It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) > > Russ > Andy --001a1133886ee72f1304f768d6b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Sat, Apr 19, 2014 at 8:22 AM, Russ White &l= t;russw@riw.us> wrote:

> And the basic premise of I2RS is that there are requirements for the w= ork
> that were not addressed properly by the existing configuration protoco= ls.
> Otherwise the WG would not even need to discuss protocol modifications= .
> So the fact that NetConf / YANG works for device configuration does no= t
> seem to be evidence that it works for what I2RS wants to do.

Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse t= he problem set
because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new p= itchfork
handle -- that game of checkers over there on the porch of the hotel looks<= br> so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all.

So, given we are _supposed_ to be focused on the RIB interface, and not
protocol, configuration, device, etc., etc., what specific points have the<= br> use cases brought out that either NETCONF/YANG or FORCES not fulfill? One o= f
the primary points was timing -- are these other systems fast enough?

>From my perspective, these two systems don't fulfill the I2RS manda= te on the
RIB side for various reasons:

- I'm not convinced on the speed side. YANG feels a bit heavy weigh for= what
we want here. The flexibility is there, but so is the cost of that
flexibility.


Can you exp= lain how an off-line representation of the data model can be fast or slow?<= /div>
You mean the YANG compiler takes too long to process a YANG file?=
You mean the unspecified I2RS protocol will be too slow on the wire if=
it uses XML or JSON encoding of YANG data structures?
=
=A0

- I'm not convinced YANG has handled the atomicity issues in a way that=
makes sense for the application environment we have in mind. RESTCONF seems=
to go that direction, but I'm not certain it's a complete solution = (?).


YANG is a data modeling language.
RESTCONF is a protocol.
Atomicity is a property of the prot= ocol.
Which YANG statements prevent this from being accomplished = in the TBD I2RS protocol?

=A0
So, IMHO, I think we need to either consider FORCES, or "something new= ." But
we're going to have a hard time determining if this is true if we can&#= 39;t make
a solid requirements list. For me, these are:

- Atomic operations at the RIB level
- Speed that's comparable to a local routing process installing routes = in
the RIB
- An immediate feedback system within the RESTful mold that tells the
installing process what happened, and why, with the route it just tried to<= br> install in the RIB

So, it seems to me that we need to return to the use cases -- there are two=
in the charter. If we want to discuss adding others, that's fine, but w= e
need to gain some focus, and stop trying to boil the ocean, if we want to make any progress.


It seems to me this WG needs to start = asking the right questions about the
data modeling language requi= rements. =A0E.g.:

=A0 - What are the data types ne= eded? =A0Is this a static set of will it ever change?
=A0 - What are the high level data modeling constructs needed?
=A0 - Are user defined types needed?
=A0 - Are re-usable data = definitions needed?
=A0 - Does the data model need to be modular?= =A0How does it grow over time?
=A0 - Can vendors add data definitions that extend the standard defini= tions?
=A0 - How are new definitions added in a way that does not= break existing clients?
=A0 - How is mandatory to implement vs. = optional to implement functionality handled?
=A0 - How is mandatory to use vs. optional to use functionality handle= d?

You are asking about protocol requirements, not= data modeling.
IMO it would be near-sighted and extremely imprac= tical to choose
a language that only supported description on RIB info. =A0I fail to s= ee what
is so special about RIB info that would warrant its own D= ML.


:-)

Russ

Andy

--001a1133886ee72f1304f768d6b3-- From nobody Sat Apr 19 11:07:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8569F1A0066 for ; Sat, 19 Apr 2014 11:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyDTEt9RhVTO for ; Sat, 19 Apr 2014 11:07:21 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id B32531A006F for ; Sat, 19 Apr 2014 11:07:21 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93]:60783 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WbZfA-0006KW-R7; Sat, 19 Apr 2014 18:06:53 +0000 From: "Russ White" To: "'Andy Bierman'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> In-Reply-To: Date: Sat, 19 Apr 2014 14:06:37 -0400 Message-ID: <02a101cf5bfa$1c705830$55510890$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHSXXZxtYA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rmJBUP4U0srTOoYhe9W7Kl9tsmE Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' , 'Dean Bogdanovic' , "'Jan Medved \(jmedved\)'" , "'Joel M. Halpern'" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 18:07:23 -0000 > Can you explain how an off-line representation of the data model can be fast > or slow? Marshalling can still be fast or slow. I'm not convinced that YANG, being focused on management, rather than protocol level interaction, doesn't have a lot of stuff that's not needed, and does have all the stuff that's needed -- nor do I understand what the overhead of carrying the stuff that's not needed is going to be. > You mean the YANG compiler takes too long to process a YANG file? > You mean the unspecified I2RS protocol will be too slow on the wire if it uses > XML or JSON encoding of YANG data structures? If I2RS on the wire uses all YANG structures and NETCONF, then it won't be I2RS -- it'll be YANG. That's okay if we look at the requirements and determine that YANG resolves all of them. In that case, fold the WG and be done -- it's a lot of extra work for no net gain. Again, however, I'm not convinced that YANG fulfills all the requirements at hand. > YANG is a data modeling language. > RESTCONF is a protocol. > Atomicity is a property of the protocol. Kindof. You can build a model that assumes atomic processing, and hence includes everything in the model to make certain atomic processing will work correctly. Or you can assume the data model will be used for just reading and writing discrete pieces of data, and then say, "we leave how to actually use the data up to someone else." YANG seems to do the latter, not the former. To put it a different way -- you can look at the problem of interacting with the RIB in two ways: - I want to be able to read stuff out of and push stuff into the RIB from time to time. - I want to interact with the RIB in parallel with other routing processes in near real time. I'm not convinced these are the same question. Can you prove they are? > It seems to me this WG needs to start asking the right questions about the > data modeling language requirements. E.g.: Data modeling is only half the problem -- part of the issue here is we've jumped right from a really large number of use cases to, "let's build data models," then to, "hey, these look a lot like YANG, so let's just use YANG." The interaction between the RIB and off box processes are important, too -- but we've apparently just left those behind in the rush to models. > You are asking about protocol requirements, not data modeling. Right! So let's go back to the protocol work, and once we have protocol and application level requirements, based on use cases, then we can ask, "hey does YANG have all the bits we need to make this work?" Right now, we don't know what the bits we need to make this work really are, so choosing a data model, or having some sort of competition between data models, doesn't make a lot of sense, to me. > IMO it would be near-sighted and extremely impractical to choose a language > that only supported description on RIB info. I fail to see what is so special > about RIB info that would warrant its own DML. So you'd argue that all the requirements in all the different use cases can be fulfilled with YANG? There is _nothing_ unique in _any_ of those use cases the YANG model doesn't support? Do the analysis and prove it. :-) Russ From nobody Sat Apr 19 11:26:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751C1A0089 for ; Sat, 19 Apr 2014 11:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6PzQi44ldLm for ; Sat, 19 Apr 2014 11:26:34 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCB1A0088 for ; Sat, 19 Apr 2014 11:26:33 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so2702555qcx.41 for ; Sat, 19 Apr 2014 11:26:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dYt948DcoFNPdAWDRJHO4alcI+qLNaSn3a2iF1+XtAY=; b=SS8HiAqYl/aFNcYGG0QWAK8QJAwri2PxUCLDn3grXErRFjRfoXolCX60ylbmQAzMbF FsuRTYi9m8ajXftT6kLAScWiaXWL5JLsujE6qfFxaiRODLvtH+zTgbl8xNxw2A9tbA0R hR0x5mofwn4WETdEwmFYuV+UsUt4kdb+K1mToXrGL4TZpgluMwwOf79L4/I94MpWe2Lg HwT05T9DCpbAGdtF+jBRjPDpX4iJ0YDDzbXEVar8nEyV4dU0CMhz9NDe6RmoAo1qVFgB jLXvQCDl3LQ8laXA9YqOt4nCYNeFIF82TBVxnYCVGpCXeuEFQNiEmbYy8sbiHH4DPRKO GkJg== X-Gm-Message-State: ALoCoQk4qqvHPSmO0tgZsqcDHAYR2FBKgN3hHTIZNS1nvETrFHM66+FjSoKvtt0QFuhZ1ZsFoX+r MIME-Version: 1.0 X-Received: by 10.140.98.116 with SMTP id n107mr25347495qge.94.1397931989238; Sat, 19 Apr 2014 11:26:29 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 19 Apr 2014 11:26:29 -0700 (PDT) In-Reply-To: <02a101cf5bfa$1c705830$55510890$@riw.us> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> Date: Sat, 19 Apr 2014 11:26:29 -0700 Message-ID: From: Andy Bierman To: Russ White Content-Type: multipart/alternative; boundary=001a113a9238a39a4b04f7696705 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vRLI49lDNjroGeqSyQXWmwfxZ-Q Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 18:26:37 -0000 --001a113a9238a39a4b04f7696705 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 19, 2014 at 11:06 AM, Russ White wrote: > > > Can you explain how an off-line representation of the data model can be > fast > > or slow? > > Marshalling can still be fast or slow. I'm not convinced that YANG, being > focused on management, rather than protocol level interaction, doesn't have > a lot of stuff that's not needed, and does have all the stuff that's needed > -- nor do I understand what the overhead of carrying the stuff that's not > needed is going to be. > > > You mean the YANG compiler takes too long to process a YANG file? > > You mean the unspecified I2RS protocol will be too slow on the wire if it > uses > > XML or JSON encoding of YANG data structures? > > If I2RS on the wire uses all YANG structures and NETCONF, then it won't be > I2RS -- it'll be YANG. That's okay if we look at the requirements and > determine that YANG resolves all of them. In that case, fold the WG and be > done -- it's a lot of extra work for no net gain. Again, however, I'm not > convinced that YANG fulfills all the requirements at hand. > > > YANG is a data modeling language. > > RESTCONF is a protocol. > > Atomicity is a property of the protocol. > > Kindof. You can build a model that assumes atomic processing, and hence > includes everything in the model to make certain atomic processing will > work > correctly. Or you can assume the data model will be used for just reading > and writing discrete pieces of data, and then say, "we leave how to > actually > use the data up to someone else." YANG seems to do the latter, not the > former. > > To put it a different way -- you can look at the problem of interacting > with > the RIB in two ways: > > - I want to be able to read stuff out of and push stuff into the RIB from > time to time. > - I want to interact with the RIB in parallel with other routing processes > in near real time. > > I'm not convinced these are the same question. Can you prove they are? > > > It seems to me this WG needs to start asking the right questions about > the > > data modeling language requirements. E.g.: > > Data modeling is only half the problem -- part of the issue here is we've > jumped right from a really large number of use cases to, "let's build data > models," then to, "hey, these look a lot like YANG, so let's just use > YANG." > The interaction between the RIB and off box processes are important, too -- > but we've apparently just left those behind in the rush to models. > > > You are asking about protocol requirements, not data modeling. > > Right! So let's go back to the protocol work, and once we have protocol and > application level requirements, based on use cases, then we can ask, "hey > does YANG have all the bits we need to make this work?" Right now, we don't > know what the bits we need to make this work really are, so choosing a data > model, or having some sort of competition between data models, doesn't make > a lot of sense, to me. > > > IMO it would be near-sighted and extremely impractical to choose a > language > > that only supported description on RIB info. I fail to see what is so > special > > about RIB info that would warrant its own DML. > > So you'd argue that all the requirements in all the different use cases can > be fulfilled with YANG? There is _nothing_ unique in _any_ of those use > cases the YANG model doesn't support? Do the analysis and prove it. > > Perhaps we agree on 1 thing -- this is all speculation without a protocol definition. You are confusing the protocol properties and data model properties with the data modeling language properties. If you don't like the sentence, you don't blame the alphabet. YANG is just the schema for describing valid instances of conceptual data. The protocol operations and server implementation performance depend on how YANG is used. I am still unclear on this "E is for Engineering, so we don't mention tools" thing. That sounds like computer science , not engineering. Engineers need to worry about the practical implementation of the design. The ability to leverage existing technology is extremely relevant to software engineering. > :-) > > Russ > > Andy --001a113a9238a39a4b04f7696705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Apr 19, 2014 at 11:06 AM, Russ White <= russw@riw.us> wrote:

> Can you explain how an off-line representation of the data model can b= e
fast
> or slow?

Marshalling can still be fast or slow. I'm not convinced that YANG, bei= ng
focused on management, rather than protocol level interaction, doesn't = have
a lot of stuff that's not needed, and does have all the stuff that'= s needed
-- nor do I understand what the overhead of carrying the stuff that's n= ot
needed is going to be.

> You mean the YANG compiler takes too long to process a YANG file?
> You mean the unspecified I2RS protocol will be too slow on the wire if= it
uses
> XML or JSON encoding of YANG data structures?

If I2RS on the wire uses all YANG structures and NETCONF, then it won't= be
I2RS -- it'll be YANG. That's okay if we look at the requirements a= nd
determine that YANG resolves all of them. In that case, fold the WG and be<= br> done -- it's a lot of extra work for no net gain. Again, however, I'= ;m not
convinced that YANG fulfills all the requirements at hand.

> YANG is a data modeling language.
> RESTCONF is a protocol.
> Atomicity is a property of the protocol.

Kindof. You can build a model that assumes atomic processing, and hence
includes everything in the model to make certain atomic processing will wor= k
correctly. Or you can assume the data model will be used for just reading and writing discrete pieces of data, and then say, "we leave how to ac= tually
use the data up to someone else." YANG seems to do the latter, not the=
former.

To put it a different way -- you can look at the problem of interacting wit= h
the RIB in two ways:

- I want to be able to read stuff out of and push stuff into the RIB from time to time.
- I want to interact with the RIB in parallel with other routing processes<= br> in near real time.

I'm not convinced these are the same question. Can you prove they are?<= br>
> It seems to me this WG needs to start asking the right questions about= the
> data modeling language requirements. =A0E.g.:

Data modeling is only half the problem -- part of the issue here is we'= ve
jumped right from a really large number of use cases to, "let's bu= ild data
models," then to, "hey, these look a lot like YANG, so let's = just use YANG."
The interaction between the RIB and off box processes are important, too --=
but we've apparently just left those behind in the rush to models.

> You are asking about protocol requirements, not data modeling.

Right! So let's go back to the protocol work, and once we have protocol= and
application level requirements, based on use cases, then we can ask, "= hey
does YANG have all the bits we need to make this work?" Right now, we = don't
know what the bits we need to make this work really are, so choosing a data=
model, or having some sort of competition between data models, doesn't = make
a lot of sense, to me.

> IMO it would be near-sighted and extremely impractical to choose a
language
> that only supported description on RIB info. =A0I fail to see what is = so
special
> about RIB info that would warrant its own DML.

So you'd argue that all the requirements in all the different use cases= can
be fulfilled with YANG? There is _nothing_ unique in _any_ of those use
cases the YANG model doesn't support? Do the analysis and prove it.



Perhaps we agree on 1 t= hing -- this is all speculation without a protocol
definition. = =A0You are confusing the protocol properties and data model
prope= rties with the data modeling language properties. =A0If you don't like<= /div>
the sentence, you don't blame the alphabet. =A0YANG is just the sc= hema
for describing valid instances of conceptual data. =A0The pr= otocol operations
and server implementation performance depend on= how YANG is used.

I am still unclear on this "E is for Engineering, = so we don't mention tools"
thing. =A0That sounds like co= mputer science , not engineering. =A0Engineers
need to worry abou= t the practical implementation of the design.
The ability to leverage existing technology is extremely relevant
to software engineering.



=
=A0
:-)

Russ



<= /div>
Andy

--001a113a9238a39a4b04f7696705-- From nobody Sat Apr 19 11:36:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335431A00BD for ; Sat, 19 Apr 2014 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSOQvLIR-pqY for ; Sat, 19 Apr 2014 11:36:14 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 111ED1A0096 for ; Sat, 19 Apr 2014 11:36:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E1AF01C071C; Sat, 19 Apr 2014 11:36:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BC3BE1C05A8; Sat, 19 Apr 2014 11:35:57 -0700 (PDT) Message-ID: <5352C203.7030205@joelhalpern.com> Date: Sat, 19 Apr 2014 14:35:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman , Russ White References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DRhtYMkR2p-Sfd__PRKniNpiMXs Cc: "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 18:36:15 -0000 There are a number of modeling and protocol expectations (I think they can be reasonable called requirements, and I think they have been agreed by the working group) in the architecture draft. Some of them are a stretch for YANG. Some of them are a stretch for ForCES. Yours, Joel On 4/19/14, 1:46 PM, Andy Bierman wrote: > Hi, > > > On Sat, Apr 19, 2014 at 8:22 AM, Russ White > wrote: > > > > And the basic premise of I2RS is that there are requirements for > the work > > that were not addressed properly by the existing configuration > protocols. > > Otherwise the WG would not even need to discuss protocol > modifications. > > So the fact that NetConf / YANG works for device configuration > does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the problem, and > said, > "let's use YANG." But I think we're starting to confuse the problem set > because we started by trying to boil the ocean. Once you actually get to > town, it's hard to keep in focus that you're just there for a new > pitchfork > handle -- that game of checkers over there on the porch of the hotel > looks > so interesting, and the hardware store has so much other stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB interface, and not > protocol, configuration, device, etc., etc., what specific points > have the > use cases brought out that either NETCONF/YANG or FORCES not > fulfill? One of > the primary points was timing -- are these other systems fast enough? > > >From my perspective, these two systems don't fulfill the I2RS > mandate on the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit heavy weigh > for what > we want here. The flexibility is there, but so is the cost of that > flexibility. > > > > Can you explain how an off-line representation of the data model can be > fast or slow? > You mean the YANG compiler takes too long to process a YANG file? > You mean the unspecified I2RS protocol will be too slow on the wire if > it uses XML or JSON encoding of YANG data structures? > > > - I'm not convinced YANG has handled the atomicity issues in a way that > makes sense for the application environment we have in mind. > RESTCONF seems > to go that direction, but I'm not certain it's a complete solution (?). > > > YANG is a data modeling language. > RESTCONF is a protocol. > Atomicity is a property of the protocol. > Which YANG statements prevent this from being accomplished in the TBD > I2RS protocol? > > So, IMHO, I think we need to either consider FORCES, or "something > new." But > we're going to have a hard time determining if this is true if we > can't make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing > routes in > the RIB > - An immediate feedback system within the RESTful mold that tells the > installing process what happened, and why, with the route it just > tried to > install in the RIB > > So, it seems to me that we need to return to the use cases -- there > are two > in the charter. If we want to discuss adding others, that's fine, but we > need to gain some focus, and stop trying to boil the ocean, if we > want to > make any progress. > > > It seems to me this WG needs to start asking the right questions about the > data modeling language requirements. E.g.: > > - What are the data types needed? Is this a static set of will it > ever change? > - What are the high level data modeling constructs needed? > - Are user defined types needed? > - Are re-usable data definitions needed? > - Does the data model need to be modular? How does it grow over time? > - Can vendors add data definitions that extend the standard definitions? > - How are new definitions added in a way that does not break existing > clients? > - How is mandatory to implement vs. optional to implement > functionality handled? > - How is mandatory to use vs. optional to use functionality handled? > > You are asking about protocol requirements, not data modeling. > IMO it would be near-sighted and extremely impractical to choose > a language that only supported description on RIB info. I fail to see what > is so special about RIB info that would warrant its own DML. > > > :-) > > Russ > > > Andy > From nobody Sat Apr 19 12:02:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDCD1A0063 for ; Sat, 19 Apr 2014 12:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ugjy4epZ1bw for ; Sat, 19 Apr 2014 12:02:32 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 80B151A0077 for ; Sat, 19 Apr 2014 12:02:32 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so2762567qcx.18 for ; Sat, 19 Apr 2014 12:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mizpzp2VsE0LDgRHvlUBzipPzaPPeW+0S0GfmEPr86Q=; b=fu+fjSESoTOPWmob/IabvStpQY75aL5hCrhxZvwZ7ldtp/SWHYJt3NNjPo/QIIM8gH IgQnaN+DbUR6NsRT7tMaOA6MSxkLIVKI/j53HqT0P4hlUjDQkpOPSjzmHe7SMVZV+1T2 M016/iYKG+97qUCeaEJa+UnoVICbZQC2WOlq+WwmLpr8V/NdDvlK1jzp2QCB1e868LaL 4k6v+PWAdn4v8iibLCBqrBGtiORsbImYlU/s9StQtM8v/mSMvTYZSUJFH5huwsBPFemR wxgJOlc19dbddIdkLQSYJTppy1E3rrNl3yUguS7yTo9WD0AUYwLxv6rbCIrOTbRRpsd+ rFgw== X-Gm-Message-State: ALoCoQnW88FvgbBkY2gVT9/mdv/a3R8ZksDocddy70PjPlWz+j0XKGvkaZXf71CqlDOrcT8KTq6L MIME-Version: 1.0 X-Received: by 10.224.136.74 with SMTP id q10mr22782683qat.78.1397934147995; Sat, 19 Apr 2014 12:02:27 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 19 Apr 2014 12:02:27 -0700 (PDT) In-Reply-To: <5352C203.7030205@joelhalpern.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <5352C203.7030205@joelhalpern.com> Date: Sat, 19 Apr 2014 12:02:27 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c2b61e4f9d0004f769e812 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YECtAKuOdaaNKVdOFcMBFAQvhBI Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 19:02:38 -0000 --001a11c2b61e4f9d0004f769e812 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern wrote: > There are a number of modeling and protocol expectations (I think they can > be reasonable called requirements, and I think they have been agreed by the > working group) in the architecture draft. Some of them are a stretch for > YANG. Some of them are a stretch for ForCES. > > I assume you mean sec. 6.4.5? I did not find anything in there that YANG does not already support or could not support with a YANG extension statement. Since I2RS can define its own YANG extensions, YANG is ready today to meet all the requirements. Can you be more specific about the stretch items? Yours, > Joel > > Andy > On 4/19/14, 1:46 PM, Andy Bierman wrote: > >> Hi, >> >> >> On Sat, Apr 19, 2014 at 8:22 AM, Russ White > > wrote: >> >> >> > And the basic premise of I2RS is that there are requirements for >> the work >> > that were not addressed properly by the existing configuration >> protocols. >> > Otherwise the WG would not even need to discuss protocol >> modifications. >> > So the fact that NetConf / YANG works for device configuration >> does not >> > seem to be evidence that it works for what I2RS wants to do. >> >> Precisely. Otherwise, we could have just looked at the problem, and >> said, >> "let's use YANG." But I think we're starting to confuse the problem >> set >> because we started by trying to boil the ocean. Once you actually get >> to >> town, it's hard to keep in focus that you're just there for a new >> pitchfork >> handle -- that game of checkers over there on the porch of the hotel >> looks >> so interesting, and the hardware store has so much other stuff than >> just >> pitchfork handles, after all. >> >> So, given we are _supposed_ to be focused on the RIB interface, and >> not >> protocol, configuration, device, etc., etc., what specific points >> have the >> use cases brought out that either NETCONF/YANG or FORCES not >> fulfill? One of >> the primary points was timing -- are these other systems fast enough? >> >> >From my perspective, these two systems don't fulfill the I2RS >> mandate on the >> RIB side for various reasons: >> >> - I'm not convinced on the speed side. YANG feels a bit heavy weigh >> for what >> we want here. The flexibility is there, but so is the cost of that >> flexibility. >> >> >> >> Can you explain how an off-line representation of the data model can be >> fast or slow? >> You mean the YANG compiler takes too long to process a YANG file? >> You mean the unspecified I2RS protocol will be too slow on the wire if >> it uses XML or JSON encoding of YANG data structures? >> >> >> - I'm not convinced YANG has handled the atomicity issues in a way >> that >> makes sense for the application environment we have in mind. >> RESTCONF seems >> to go that direction, but I'm not certain it's a complete solution >> (?). >> >> >> YANG is a data modeling language. >> RESTCONF is a protocol. >> Atomicity is a property of the protocol. >> Which YANG statements prevent this from being accomplished in the TBD >> I2RS protocol? >> >> So, IMHO, I think we need to either consider FORCES, or "something >> new." But >> we're going to have a hard time determining if this is true if we >> can't make >> a solid requirements list. For me, these are: >> >> - Atomic operations at the RIB level >> - Speed that's comparable to a local routing process installing >> routes in >> the RIB >> - An immediate feedback system within the RESTful mold that tells the >> installing process what happened, and why, with the route it just >> tried to >> install in the RIB >> >> So, it seems to me that we need to return to the use cases -- there >> are two >> in the charter. If we want to discuss adding others, that's fine, but >> we >> need to gain some focus, and stop trying to boil the ocean, if we >> want to >> make any progress. >> >> >> It seems to me this WG needs to start asking the right questions about the >> data modeling language requirements. E.g.: >> >> - What are the data types needed? Is this a static set of will it >> ever change? >> - What are the high level data modeling constructs needed? >> - Are user defined types needed? >> - Are re-usable data definitions needed? >> - Does the data model need to be modular? How does it grow over time? >> - Can vendors add data definitions that extend the standard >> definitions? >> - How are new definitions added in a way that does not break existing >> clients? >> - How is mandatory to implement vs. optional to implement >> functionality handled? >> - How is mandatory to use vs. optional to use functionality handled? >> >> You are asking about protocol requirements, not data modeling. >> IMO it would be near-sighted and extremely impractical to choose >> a language that only supported description on RIB info. I fail to see >> what >> is so special about RIB info that would warrant its own DML. >> >> >> :-) >> >> Russ >> >> >> Andy >> >> --001a11c2b61e4f9d0004f769e812 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <jmh@joelhalpe= rn.com> wrote:
There are a number of modeling and protocol = expectations (I think they can be reasonable called requirements, and I thi= nk they have been agreed by the working group) in the architecture draft. = =A0Some of them are a stretch for YANG. =A0Some of them are a stretch for F= orCES.


I assume you mean sec. 6.4.5?
I did not find anything in there that YANG does not already support or co= uld not
support with a YANG extension statement. =A0Since I2RS ca= n define its own
YANG extensions, YANG is ready today to meet all the requirements.
Can you be more specific about the stretch items?



Yours,
Joel


Andy
=A0
On 4/19/14, 1:46 PM, Andy Bierman wrote:
Hi,


On Sat, Apr 19, 2014 at 8:22 AM, Russ White <russw@riw.us
<mailto:russw@riw.us>> wrote:


=A0 =A0 =A0> And the basic premise of I2RS is that there are requirement= s for
=A0 =A0 the work
=A0 =A0 =A0> that were not addressed properly by the existing configurat= ion
=A0 =A0 protocols.
=A0 =A0 =A0> Otherwise the WG would not even need to discuss protocol =A0 =A0 modifications.
=A0 =A0 =A0> So the fact that NetConf / YANG works for device configurat= ion
=A0 =A0 does not
=A0 =A0 =A0> seem to be evidence that it works for what I2RS wants to do= .

=A0 =A0 Precisely. Otherwise, we could have just looked at the problem, and=
=A0 =A0 said,
=A0 =A0 "let's use YANG." But I think we're starting to c= onfuse the problem set
=A0 =A0 because we started by trying to boil the ocean. Once you actually g= et to
=A0 =A0 town, it's hard to keep in focus that you're just there for= a new
=A0 =A0 pitchfork
=A0 =A0 handle -- that game of checkers over there on the porch of the hote= l
=A0 =A0 looks
=A0 =A0 so interesting, and the hardware store has so much other stuff than= just
=A0 =A0 pitchfork handles, after all.

=A0 =A0 So, given we are _supposed_ to be focused on the RIB interface, and= not
=A0 =A0 protocol, configuration, device, etc., etc., what specific points =A0 =A0 have the
=A0 =A0 use cases brought out that either NETCONF/YANG or FORCES not
=A0 =A0 fulfill? One of
=A0 =A0 the primary points was timing -- are these other systems fast enoug= h?

=A0 =A0 =A0>From my perspective, these two systems don't fulfill the= I2RS
=A0 =A0 mandate on the
=A0 =A0 RIB side for various reasons:

=A0 =A0 - I'm not convinced on the speed side. YANG feels a bit heavy w= eigh
=A0 =A0 for what
=A0 =A0 we want here. The flexibility is there, but so is the cost of that<= br> =A0 =A0 flexibility.



Can you explain how an off-line representation of the data model can be
fast or slow?
You mean the YANG compiler takes too long to process a YANG file?
You mean the unspecified I2RS protocol will be too slow on the wire if
it uses XML or JSON encoding of YANG data structures?


=A0 =A0 - I'm not convinced YANG has handled the atomicity issues in a = way that
=A0 =A0 makes sense for the application environment we have in mind.
=A0 =A0 RESTCONF seems
=A0 =A0 to go that direction, but I'm not certain it's a complete s= olution (?).


YANG is a data modeling language.
RESTCONF is a protocol.
Atomicity is a property of the protocol.
Which YANG statements prevent this from being accomplished in the TBD
I2RS protocol?

=A0 =A0 So, IMHO, I think we need to either consider FORCES, or "somet= hing
=A0 =A0 new." But
=A0 =A0 we're going to have a hard time determining if this is true if = we
=A0 =A0 can't make
=A0 =A0 a solid requirements list. For me, these are:

=A0 =A0 - Atomic operations at the RIB level
=A0 =A0 - Speed that's comparable to a local routing process installing=
=A0 =A0 routes in
=A0 =A0 the RIB
=A0 =A0 - An immediate feedback system within the RESTful mold that tells t= he
=A0 =A0 installing process what happened, and why, with the route it just =A0 =A0 tried to
=A0 =A0 install in the RIB

=A0 =A0 So, it seems to me that we need to return to the use cases -- there=
=A0 =A0 are two
=A0 =A0 in the charter. If we want to discuss adding others, that's fin= e, but we
=A0 =A0 need to gain some focus, and stop trying to boil the ocean, if we =A0 =A0 want to
=A0 =A0 make any progress.


It seems to me this WG needs to start asking the right questions about the<= br> data modeling language requirements. =A0E.g.:

=A0 =A0- What are the data types needed? =A0Is this a static set of will it=
ever change?
=A0 =A0- What are the high level data modeling constructs needed?
=A0 =A0- Are user defined types needed?
=A0 =A0- Are re-usable data definitions needed?
=A0 =A0- Does the data model need to be modular? =A0How does it grow over t= ime?
=A0 =A0- Can vendors add data definitions that extend the standard definiti= ons?
=A0 =A0- How are new definitions added in a way that does not break existin= g
clients?
=A0 =A0- How is mandatory to implement vs. optional to implement
functionality handled?
=A0 =A0- How is mandatory to use vs. optional to use functionality handled?=

You are asking about protocol requirements, not data modeling.
IMO it would be near-sighted and extremely impractical to choose
a language that only supported description on RIB info. =A0I fail to see wh= at
is so special about RIB info that would warrant its own DML.


=A0 =A0 :-)

=A0 =A0 Russ


Andy


--001a11c2b61e4f9d0004f769e812-- From nobody Sat Apr 19 12:08:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE901A006F for ; Sat, 19 Apr 2014 12:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y7fn95Z2Nc2 for ; Sat, 19 Apr 2014 12:08:52 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5CB1A0063 for ; Sat, 19 Apr 2014 12:08:52 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so5196322veb.14 for ; Sat, 19 Apr 2014 12:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=0ApdVNJys9urLYN6MJ9dAZx21p6PE+QxvZokj2cA5Fw=; b=L+XdB6+gMhUt3FM/+f7DnQRzGABwz+AgpoI1xwp+P5ZYblTCRI7Zp7GISxNqTZ59+9 asUlxAzgZZTf2IHmaZ4oHtXwJxWPfwRL2Sj20glarhrXnU1pC8cwYNrc/J4vsnFVXvm0 iutq2ViNv8NHdiS6T5MYpKfxqtnYXzPiQ/2K3wwZ2XHkXLfDqEhc2aeg6Qop/iiWgWBj /Jl0D4wdpXP/G4131HkpjvEPvOvSUmZTuwGW6sfaR37FLca8+bPOzNL1xmrINf6E2dY+ HiqDL68SjUBbCibt6BWuIcQ+i6vEdw8If3nk3i+1IwQVVSNWQfgf9eyf/NWUupJrmQPk XB0w== X-Gm-Message-State: ALoCoQlr8PNP0qDMuCE2DGzAO0gXZAhJmWCGxpMcObnq59R5MZ0ML3CWI9Ac06F8989x1lIHmoGT X-Received: by 10.220.133.197 with SMTP id g5mr852546vct.20.1397934528016; Sat, 19 Apr 2014 12:08:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 12:08:27 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 15:08:27 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5eD_RYPHm6FM3NSIKjGfEq_z7zY Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 19:08:57 -0000 On Sat, Apr 19, 2014 at 10:22 AM, Dean Bogdanovic wrote= : > > What is working i2rs code? Code that implements, using your choice of model and protocol, the I2RS semantics. To examplify using your slides at the meeting, iirc, such semantics would be between the agent one side and what iirc you called client (in our case we call them Apps). i.e take something like the RIB info model and cast it into your model cho= ice and make APIs available to message things between a basic agent and the routing daemon. >From Juniper perspective, I can claim having PoC i2rs code, as I can dynam= ically create >REST APIs (will not call them RESTconf, as it has only partial compliance = with >current RESTconf draft) based on the service described on the device. The = PoC functionally >is very close i2rs architecture document and with that can see what servic= es can be created >and abstracted for i2rs. > > So for i2rs, as long I can create a data model for a service, where the s= ervice is simple as add or >delete route and can programmatically consume t= hat service, it is i2rs. Many vendors today can do >that with NETCONF/RESTC= ONF/YANG and we are voicing our preference for that. > Sorry, I dont think that is sufficient. The programmatic APIs part is obvio= us. There are bigger issue which shape how a protocol is to be wired and what model would be sensible; in my response ealier, one you and I discussed was speed. How do you do a 1000 route update or add with JSON? If it is a requirement then the agent needs to be able to handle clients of different latencies etc and deal with congestion issues that are common in proxies wh= en you have multiple users being considered and probably a single entry to the routing interface. If it is not a requirement - should that not be stated somewhere? Unfortunately - we are not having that kind of useful discussion and i feel like a broken record asking for requirements. cheers, jamal From nobody Sat Apr 19 12:09:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB41A00A5 for ; Sat, 19 Apr 2014 12:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSDTvzglygbU for ; Sat, 19 Apr 2014 12:08:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 65DF11A006E for ; Sat, 19 Apr 2014 12:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 344911C0A77; Sat, 19 Apr 2014 12:08:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 52F1B1C071C; Sat, 19 Apr 2014 12:08:39 -0700 (PDT) Message-ID: <5352C9A4.4010204@joelhalpern.com> Date: Sat, 19 Apr 2014 15:08:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <5352C203.7030205@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AgjA6DjirqonRCe1Db_ZiprO7BU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 19:09:00 -0000 I actually expect that YANG can be extended to do what is needed. I also expect that ForCES protocol can be extended to do what is needed on the protocol side. But that is not the same as saying that either item "as is" meets the needs as stated. It would seem appropriate to at least describe what extensions will be needed to YANG before we decide to say "yes, we will use YANG and we will extend it to address the needs." On the ForCES side, I believe Jamal did include that information in his presentation. Is there a similar list for YANG that I have misplaced? Yours, Joel On 4/19/14, 3:02 PM, Andy Bierman wrote: > > > > On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern > wrote: > > There are a number of modeling and protocol expectations (I think > they can be reasonable called requirements, and I think they have > been agreed by the working group) in the architecture draft. Some > of them are a stretch for YANG. Some of them are a stretch for ForCES. > > > I assume you mean sec. 6.4.5? > I did not find anything in there that YANG does not already support or > could not > support with a YANG extension statement. Since I2RS can define its own > YANG extensions, YANG is ready today to meet all the requirements. > Can you be more specific about the stretch items? > > > > Yours, > Joel > > > Andy > > On 4/19/14, 1:46 PM, Andy Bierman wrote: > > Hi, > > > On Sat, Apr 19, 2014 at 8:22 AM, Russ White > >> wrote: > > > > And the basic premise of I2RS is that there are > requirements for > the work > > that were not addressed properly by the existing > configuration > protocols. > > Otherwise the WG would not even need to discuss protocol > modifications. > > So the fact that NetConf / YANG works for device > configuration > does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the > problem, and > said, > "let's use YANG." But I think we're starting to confuse the > problem set > because we started by trying to boil the ocean. Once you > actually get to > town, it's hard to keep in focus that you're just there for > a new > pitchfork > handle -- that game of checkers over there on the porch of > the hotel > looks > so interesting, and the hardware store has so much other > stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB > interface, and not > protocol, configuration, device, etc., etc., what specific > points > have the > use cases brought out that either NETCONF/YANG or FORCES not > fulfill? One of > the primary points was timing -- are these other systems > fast enough? > > >From my perspective, these two systems don't fulfill the I2RS > mandate on the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit > heavy weigh > for what > we want here. The flexibility is there, but so is the cost > of that > flexibility. > > > > Can you explain how an off-line representation of the data model > can be > fast or slow? > You mean the YANG compiler takes too long to process a YANG file? > You mean the unspecified I2RS protocol will be too slow on the > wire if > it uses XML or JSON encoding of YANG data structures? > > > - I'm not convinced YANG has handled the atomicity issues > in a way that > makes sense for the application environment we have in mind. > RESTCONF seems > to go that direction, but I'm not certain it's a complete > solution (?). > > > YANG is a data modeling language. > RESTCONF is a protocol. > Atomicity is a property of the protocol. > Which YANG statements prevent this from being accomplished in > the TBD > I2RS protocol? > > So, IMHO, I think we need to either consider FORCES, or > "something > new." But > we're going to have a hard time determining if this is true > if we > can't make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing > routes in > the RIB > - An immediate feedback system within the RESTful mold that > tells the > installing process what happened, and why, with the route > it just > tried to > install in the RIB > > So, it seems to me that we need to return to the use cases > -- there > are two > in the charter. If we want to discuss adding others, that's > fine, but we > need to gain some focus, and stop trying to boil the ocean, > if we > want to > make any progress. > > > It seems to me this WG needs to start asking the right questions > about the > data modeling language requirements. E.g.: > > - What are the data types needed? Is this a static set of > will it > ever change? > - What are the high level data modeling constructs needed? > - Are user defined types needed? > - Are re-usable data definitions needed? > - Does the data model need to be modular? How does it grow > over time? > - Can vendors add data definitions that extend the standard > definitions? > - How are new definitions added in a way that does not break > existing > clients? > - How is mandatory to implement vs. optional to implement > functionality handled? > - How is mandatory to use vs. optional to use functionality > handled? > > You are asking about protocol requirements, not data modeling. > IMO it would be near-sighted and extremely impractical to choose > a language that only supported description on RIB info. I fail > to see what > is so special about RIB info that would warrant its own DML. > > > :-) > > Russ > > > Andy > > From nobody Sat Apr 19 12:16:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C61F1A0024 for ; Sat, 19 Apr 2014 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSXY1EL0xyq4 for ; Sat, 19 Apr 2014 12:16:17 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 18FD51A0063 for ; Sat, 19 Apr 2014 12:16:16 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so2557623qab.23 for ; Sat, 19 Apr 2014 12:16:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SRpdqwT+KcmCMd3X92baUsX0U/k0X8+Q34TMxrU5Fz4=; b=fghxs/+9KtPQxDLZh9a4XlLGQwyqmJNMa7QhBG1vYTm90AC+3XQoEJzucwlpVSx1b+ RO3JluoabtXHM3UMXJeoHzcsZMU4+pXdEUcJZW857SzTduLckI2XWVRMQDpM0K8zOUE5 uVudvzTe4qTK5EccQe+HYLjDh7yl4NNjd5fG/0kg9ja2DI1jylpNNUkNT4CdbMOe3TJJ c+94QY/NwhTb8GtSedsYIr0N/PWb69/MAYfFOxvswbSIkotkLZAnwVB3AIsFMXLvYv9w edmU/PyOyM8JKTUKVLdBfMMZPG9Kv5n/NM5YcJyvEKUj0pbsR7CWAEW1eUjjgRD328dL ZDOw== X-Gm-Message-State: ALoCoQncdm0KUHs6CLnDG7sJhtkDV6MippqRRVcCVgz2lYKcXcu67jayeKbVqniYmAWbg479FGNN MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr26438374qad.88.1397934972494; Sat, 19 Apr 2014 12:16:12 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Sat, 19 Apr 2014 12:16:12 -0700 (PDT) In-Reply-To: <5352C9A4.4010204@joelhalpern.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <5352C203.7030205@joelhalpern.com> <5352C9A4.4010204@joelhalpern.com> Date: Sat, 19 Apr 2014 12:16:12 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e0158a9e4747c7c04f76a1983 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/68J5FsUDDmywqDlfIrjeKs3rF-k Cc: "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 19:16:23 -0000 --089e0158a9e4747c7c04f76a1983 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Apr 19, 2014 at 12:08 PM, Joel M. Halpern wrote: > I actually expect that YANG can be extended to do what is needed. I also > expect that ForCES protocol can be extended to do what is needed on the > protocol side. > > But that is not the same as saying that either item "as is" meets the > needs as stated. > > It would seem appropriate to at least describe what extensions will be > needed to YANG before we decide to say "yes, we will use YANG and we will > extend it to address the needs." > > I did that already. See the I2RS slides from IETF #89. On the ForCES side, I believe Jamal did include that information in his > presentation. Is there a similar list for YANG that I have misplaced? > > Yours, > Joel > > On 4/19/14, 3:02 PM, Andy Bierman wrote: > >> >> >> >> On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern > > wrote: >> >> There are a number of modeling and protocol expectations (I think >> they can be reasonable called requirements, and I think they have >> been agreed by the working group) in the architecture draft. Some >> of them are a stretch for YANG. Some of them are a stretch for >> ForCES. >> >> >> I assume you mean sec. 6.4.5? >> I did not find anything in there that YANG does not already support or >> could not >> support with a YANG extension statement. Since I2RS can define its own >> YANG extensions, YANG is ready today to meet all the requirements. >> Can you be more specific about the stretch items? >> >> >> >> Yours, >> Joel >> >> >> Andy >> >> On 4/19/14, 1:46 PM, Andy Bierman wrote: >> >> Hi, >> >> >> On Sat, Apr 19, 2014 at 8:22 AM, Russ White > >> >> wrote: >> >> >> > And the basic premise of I2RS is that there are >> requirements for >> the work >> > that were not addressed properly by the existing >> configuration >> protocols. >> > Otherwise the WG would not even need to discuss protocol >> modifications. >> > So the fact that NetConf / YANG works for device >> configuration >> does not >> > seem to be evidence that it works for what I2RS wants to >> do. >> >> Precisely. Otherwise, we could have just looked at the >> problem, and >> said, >> "let's use YANG." But I think we're starting to confuse the >> problem set >> because we started by trying to boil the ocean. Once you >> actually get to >> town, it's hard to keep in focus that you're just there for >> a new >> pitchfork >> handle -- that game of checkers over there on the porch of >> the hotel >> looks >> so interesting, and the hardware store has so much other >> stuff than just >> pitchfork handles, after all. >> >> So, given we are _supposed_ to be focused on the RIB >> interface, and not >> protocol, configuration, device, etc., etc., what specific >> points >> have the >> use cases brought out that either NETCONF/YANG or FORCES not >> fulfill? One of >> the primary points was timing -- are these other systems >> fast enough? >> >> >From my perspective, these two systems don't fulfill the >> I2RS >> mandate on the >> RIB side for various reasons: >> >> - I'm not convinced on the speed side. YANG feels a bit >> heavy weigh >> for what >> we want here. The flexibility is there, but so is the cost >> of that >> flexibility. >> >> >> >> Can you explain how an off-line representation of the data model >> can be >> fast or slow? >> You mean the YANG compiler takes too long to process a YANG file? >> You mean the unspecified I2RS protocol will be too slow on the >> wire if >> it uses XML or JSON encoding of YANG data structures? >> >> >> - I'm not convinced YANG has handled the atomicity issues >> in a way that >> makes sense for the application environment we have in mind. >> RESTCONF seems >> to go that direction, but I'm not certain it's a complete >> solution (?). >> >> >> YANG is a data modeling language. >> RESTCONF is a protocol. >> Atomicity is a property of the protocol. >> Which YANG statements prevent this from being accomplished in >> the TBD >> I2RS protocol? >> >> So, IMHO, I think we need to either consider FORCES, or >> "something >> new." But >> we're going to have a hard time determining if this is true >> if we >> can't make >> a solid requirements list. For me, these are: >> >> - Atomic operations at the RIB level >> - Speed that's comparable to a local routing process >> installing >> routes in >> the RIB >> - An immediate feedback system within the RESTful mold that >> tells the >> installing process what happened, and why, with the route >> it just >> tried to >> install in the RIB >> >> So, it seems to me that we need to return to the use cases >> -- there >> are two >> in the charter. If we want to discuss adding others, that's >> fine, but we >> need to gain some focus, and stop trying to boil the ocean, >> if we >> want to >> make any progress. >> >> >> It seems to me this WG needs to start asking the right questions >> about the >> data modeling language requirements. E.g.: >> >> - What are the data types needed? Is this a static set of >> will it >> ever change? >> - What are the high level data modeling constructs needed? >> - Are user defined types needed? >> - Are re-usable data definitions needed? >> - Does the data model need to be modular? How does it grow >> over time? >> - Can vendors add data definitions that extend the standard >> definitions? >> - How are new definitions added in a way that does not break >> existing >> clients? >> - How is mandatory to implement vs. optional to implement >> functionality handled? >> - How is mandatory to use vs. optional to use functionality >> handled? >> >> You are asking about protocol requirements, not data modeling. >> IMO it would be near-sighted and extremely impractical to choose >> a language that only supported description on RIB info. I fail >> to see what >> is so special about RIB info that would warrant its own DML. >> >> >> :-) >> >> Russ >> >> >> Andy >> >> >> --089e0158a9e4747c7c04f76a1983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Sat, Apr 19, 2014 at 12:08 PM, Joel M. Halpern <jmh@joelha= lpern.com> wrote:
I actually expect that YANG can be extended = to do what is needed. =A0I also expect that ForCES protocol can be extended= to do what is needed on the protocol side.

But that is not the same as saying that either item "as is" meets= the needs as stated.

It would seem appropriate to at least describe what extensions will be need= ed to YANG before we decide to say "yes, we will use YANG and we will = extend it to address the needs."


I did that already. =A0See the I2RS sl= ides from IETF #89.


On the ForCES side, I believe Jamal did include that information in his pre= sentation. =A0Is there a similar list for YANG that I have misplaced?

Yours,
Joel

On 4/19/14, 3:02 PM, Andy Bierman wrote:



On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

=A0 =A0 There are a number of modeling and protocol expectations (I think =A0 =A0 they can be reasonable called requirements, and I think they have =A0 =A0 been agreed by the working group) in the architecture draft. =A0Som= e
=A0 =A0 of them are a stretch for YANG. =A0Some of them are a stretch for F= orCES.


I assume you mean sec. 6.4.5?
I did not find anything in there that YANG does not already support or
could not
support with a YANG extension statement. =A0Since I2RS can define its own YANG extensions, YANG is ready today to meet all the requirements.
Can you be more specific about the stretch items?



=A0 =A0 Yours,
=A0 =A0 Joel


Andy

=A0 =A0 On 4/19/14, 1:46 PM, Andy Bierman wrote:

=A0 =A0 =A0 =A0 Hi,


=A0 =A0 =A0 =A0 On Sat, Apr 19, 2014 at 8:22 AM, Russ White <russw@riw.us
=A0 =A0 =A0 =A0 <mailto:russw@riw.us>
=A0 =A0 =A0 =A0 <mailto:russw@riw.us <mailto:russw@riw.us>>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 > And the basic premise of I2RS is that ther= e are
=A0 =A0 =A0 =A0 requirements for
=A0 =A0 =A0 =A0 =A0 =A0 =A0the work
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > that were not addressed properly by the ex= isting
=A0 =A0 =A0 =A0 configuration
=A0 =A0 =A0 =A0 =A0 =A0 =A0protocols.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > Otherwise the WG would not even need to di= scuss protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0modifications.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > So the fact that NetConf / YANG works for = device
=A0 =A0 =A0 =A0 configuration
=A0 =A0 =A0 =A0 =A0 =A0 =A0does not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > seem to be evidence that it works for what= I2RS wants to do.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Precisely. Otherwise, we could have just looked = at the
=A0 =A0 =A0 =A0 problem, and
=A0 =A0 =A0 =A0 =A0 =A0 =A0said,
=A0 =A0 =A0 =A0 =A0 =A0 =A0"let's use YANG." But I think we&#= 39;re starting to confuse the
=A0 =A0 =A0 =A0 problem set
=A0 =A0 =A0 =A0 =A0 =A0 =A0because we started by trying to boil the ocean. = Once you
=A0 =A0 =A0 =A0 actually get to
=A0 =A0 =A0 =A0 =A0 =A0 =A0town, it's hard to keep in focus that you= 9;re just there for
=A0 =A0 =A0 =A0 a new
=A0 =A0 =A0 =A0 =A0 =A0 =A0pitchfork
=A0 =A0 =A0 =A0 =A0 =A0 =A0handle -- that game of checkers over there on th= e porch of
=A0 =A0 =A0 =A0 the hotel
=A0 =A0 =A0 =A0 =A0 =A0 =A0looks
=A0 =A0 =A0 =A0 =A0 =A0 =A0so interesting, and the hardware store has so mu= ch other
=A0 =A0 =A0 =A0 stuff than just
=A0 =A0 =A0 =A0 =A0 =A0 =A0pitchfork handles, after all.

=A0 =A0 =A0 =A0 =A0 =A0 =A0So, given we are _supposed_ to be focused on the= RIB
=A0 =A0 =A0 =A0 interface, and not
=A0 =A0 =A0 =A0 =A0 =A0 =A0protocol, configuration, device, etc., etc., wha= t specific
=A0 =A0 =A0 =A0 points
=A0 =A0 =A0 =A0 =A0 =A0 =A0have the
=A0 =A0 =A0 =A0 =A0 =A0 =A0use cases brought out that either NETCONF/YANG o= r FORCES not
=A0 =A0 =A0 =A0 =A0 =A0 =A0fulfill? One of
=A0 =A0 =A0 =A0 =A0 =A0 =A0the primary points was timing -- are these other= systems
=A0 =A0 =A0 =A0 fast enough?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 >From my perspective, these two systems don&= #39;t fulfill the I2RS
=A0 =A0 =A0 =A0 =A0 =A0 =A0mandate on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0RIB side for various reasons:

=A0 =A0 =A0 =A0 =A0 =A0 =A0- I'm not convinced on the speed side. YANG = feels a bit
=A0 =A0 =A0 =A0 heavy weigh
=A0 =A0 =A0 =A0 =A0 =A0 =A0for what
=A0 =A0 =A0 =A0 =A0 =A0 =A0we want here. The flexibility is there, but so i= s the cost
=A0 =A0 =A0 =A0 of that
=A0 =A0 =A0 =A0 =A0 =A0 =A0flexibility.



=A0 =A0 =A0 =A0 Can you explain how an off-line representation of the data = model
=A0 =A0 =A0 =A0 can be
=A0 =A0 =A0 =A0 fast or slow?
=A0 =A0 =A0 =A0 You mean the YANG compiler takes too long to process a YANG= file?
=A0 =A0 =A0 =A0 You mean the unspecified I2RS protocol will be too slow on = the
=A0 =A0 =A0 =A0 wire if
=A0 =A0 =A0 =A0 it uses XML or JSON encoding of YANG data structures?


=A0 =A0 =A0 =A0 =A0 =A0 =A0- I'm not convinced YANG has handled the ato= micity issues
=A0 =A0 =A0 =A0 in a way that
=A0 =A0 =A0 =A0 =A0 =A0 =A0makes sense for the application environment we h= ave in mind.
=A0 =A0 =A0 =A0 =A0 =A0 =A0RESTCONF seems
=A0 =A0 =A0 =A0 =A0 =A0 =A0to go that direction, but I'm not certain it= 's a complete
=A0 =A0 =A0 =A0 solution (?).


=A0 =A0 =A0 =A0 YANG is a data modeling language.
=A0 =A0 =A0 =A0 RESTCONF is a protocol.
=A0 =A0 =A0 =A0 Atomicity is a property of the protocol.
=A0 =A0 =A0 =A0 Which YANG statements prevent this from being accomplished = in
=A0 =A0 =A0 =A0 the TBD
=A0 =A0 =A0 =A0 I2RS protocol?

=A0 =A0 =A0 =A0 =A0 =A0 =A0So, IMHO, I think we need to either consider FOR= CES, or
=A0 =A0 =A0 =A0 "something
=A0 =A0 =A0 =A0 =A0 =A0 =A0new." But
=A0 =A0 =A0 =A0 =A0 =A0 =A0we're going to have a hard time determining = if this is true
=A0 =A0 =A0 =A0 if we
=A0 =A0 =A0 =A0 =A0 =A0 =A0can't make
=A0 =A0 =A0 =A0 =A0 =A0 =A0a solid requirements list. For me, these are:
=A0 =A0 =A0 =A0 =A0 =A0 =A0- Atomic operations at the RIB level
=A0 =A0 =A0 =A0 =A0 =A0 =A0- Speed that's comparable to a local routing= process installing
=A0 =A0 =A0 =A0 =A0 =A0 =A0routes in
=A0 =A0 =A0 =A0 =A0 =A0 =A0the RIB
=A0 =A0 =A0 =A0 =A0 =A0 =A0- An immediate feedback system within the RESTfu= l mold that
=A0 =A0 =A0 =A0 tells the
=A0 =A0 =A0 =A0 =A0 =A0 =A0installing process what happened, and why, with = the route
=A0 =A0 =A0 =A0 it just
=A0 =A0 =A0 =A0 =A0 =A0 =A0tried to
=A0 =A0 =A0 =A0 =A0 =A0 =A0install in the RIB

=A0 =A0 =A0 =A0 =A0 =A0 =A0So, it seems to me that we need to return to the= use cases
=A0 =A0 =A0 =A0 -- there
=A0 =A0 =A0 =A0 =A0 =A0 =A0are two
=A0 =A0 =A0 =A0 =A0 =A0 =A0in the charter. If we want to discuss adding oth= ers, that's
=A0 =A0 =A0 =A0 fine, but we
=A0 =A0 =A0 =A0 =A0 =A0 =A0need to gain some focus, and stop trying to boil= the ocean,
=A0 =A0 =A0 =A0 if we
=A0 =A0 =A0 =A0 =A0 =A0 =A0want to
=A0 =A0 =A0 =A0 =A0 =A0 =A0make any progress.


=A0 =A0 =A0 =A0 It seems to me this WG needs to start asking the right ques= tions
=A0 =A0 =A0 =A0 about the
=A0 =A0 =A0 =A0 data modeling language requirements. =A0E.g.:

=A0 =A0 =A0 =A0 =A0 =A0 - What are the data types needed? =A0Is this a stat= ic set of
=A0 =A0 =A0 =A0 will it
=A0 =A0 =A0 =A0 ever change?
=A0 =A0 =A0 =A0 =A0 =A0 - What are the high level data modeling constructs = needed?
=A0 =A0 =A0 =A0 =A0 =A0 - Are user defined types needed?
=A0 =A0 =A0 =A0 =A0 =A0 - Are re-usable data definitions needed?
=A0 =A0 =A0 =A0 =A0 =A0 - Does the data model need to be modular? =A0How do= es it grow
=A0 =A0 =A0 =A0 over time?
=A0 =A0 =A0 =A0 =A0 =A0 - Can vendors add data definitions that extend the = standard
=A0 =A0 =A0 =A0 definitions?
=A0 =A0 =A0 =A0 =A0 =A0 - How are new definitions added in a way that does = not break
=A0 =A0 =A0 =A0 existing
=A0 =A0 =A0 =A0 clients?
=A0 =A0 =A0 =A0 =A0 =A0 - How is mandatory to implement vs. optional to imp= lement
=A0 =A0 =A0 =A0 functionality handled?
=A0 =A0 =A0 =A0 =A0 =A0 - How is mandatory to use vs. optional to use funct= ionality
=A0 =A0 =A0 =A0 handled?

=A0 =A0 =A0 =A0 You are asking about protocol requirements, not data modeli= ng.
=A0 =A0 =A0 =A0 IMO it would be near-sighted and extremely impractical to c= hoose
=A0 =A0 =A0 =A0 a language that only supported description on RIB info. =A0= I fail
=A0 =A0 =A0 =A0 to see what
=A0 =A0 =A0 =A0 is so special about RIB info that would warrant its own DML= .


=A0 =A0 =A0 =A0 =A0 =A0 =A0:-)

=A0 =A0 =A0 =A0 =A0 =A0 =A0Russ


=A0 =A0 =A0 =A0 Andy



--089e0158a9e4747c7c04f76a1983-- From nobody Sat Apr 19 12:36:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDFC1A0096 for ; Sat, 19 Apr 2014 12:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGAPBfnYf0Mu for ; Sat, 19 Apr 2014 12:36:31 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0A1A0078 for ; Sat, 19 Apr 2014 12:36:30 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so5161988veb.19 for ; Sat, 19 Apr 2014 12:36:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ytd/vni+T8wV1IhMuIyqkQpCuXeZF0kWd59xd/m0/2I=; b=dDOZNyLLIygkGQr31bAhLZDIzUMdLhcr1rqSKMceNYZFYgjvF8Vqb/Cs08+EF3Wn2A fX0x7NipPHQoSyJ7NIHo620zW09j1sg2/6UCy8AsYYenkpXuOt/shsODH0i56+1gIU9j h7S7oH2s5BZVHgMbKOTCWVvdX3PONv1g75abFLZalFMy2tkgG/HZVrvGXxvWJLJm/SmH WzvnV0K/gkajuWH7rvwwQ948viISw/CbGGnEl0pB8iUzyTL+/QGj+K6My/+wEKUFinAY wGE0XJYUhdRGY2SJRPVpCsb7qWPEeIe9Ttx1FxOnUsIAwguhc2HK4SMm5zdBFcdNtpaH 4+0w== X-Gm-Message-State: ALoCoQlpTOGX68m10H7E/Vmd3BpzLH+/YyfKOT8xmlmqofXxDzZ02DafJS1/AKCv3m0y8jAhNsJ6 X-Received: by 10.52.189.193 with SMTP id gk1mr657149vdc.12.1397936186248; Sat, 19 Apr 2014 12:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 12:36:05 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <5352C203.7030205@joelhalpern.com> <5352C9A4.4010204@joelhalpern.com> From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 15:36:05 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Gbl1eU1LHCuW-j0FxNE0X1EaFE8 Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 19:36:35 -0000 I think this progress. I would be more than happy to go over the requirements listed there and whatever more for an "stretch" analysis needed for both protocol and model. In other words, some process. A joint draft perhaps. cheers, jamal On Sat, Apr 19, 2014 at 3:16 PM, Andy Bierman wrote: > Hi, > > > On Sat, Apr 19, 2014 at 12:08 PM, Joel M. Halpern > wrote: >> >> I actually expect that YANG can be extended to do what is needed. I also >> expect that ForCES protocol can be extended to do what is needed on the >> protocol side. >> >> But that is not the same as saying that either item "as is" meets the >> needs as stated. >> >> It would seem appropriate to at least describe what extensions will be >> needed to YANG before we decide to say "yes, we will use YANG and we will >> extend it to address the needs." >> > > I did that already. See the I2RS slides from IETF #89. > > >> On the ForCES side, I believe Jamal did include that information in his >> presentation. Is there a similar list for YANG that I have misplaced? >> >> Yours, >> Joel >> >> On 4/19/14, 3:02 PM, Andy Bierman wrote: >>> >>> >>> >>> >>> On Sat, Apr 19, 2014 at 11:35 AM, Joel M. Halpern >> > wrote: >>> >>> There are a number of modeling and protocol expectations (I think >>> they can be reasonable called requirements, and I think they have >>> been agreed by the working group) in the architecture draft. Some >>> of them are a stretch for YANG. Some of them are a stretch for >>> ForCES. >>> >>> >>> I assume you mean sec. 6.4.5? >>> I did not find anything in there that YANG does not already support or >>> could not >>> support with a YANG extension statement. Since I2RS can define its own >>> YANG extensions, YANG is ready today to meet all the requirements. >>> Can you be more specific about the stretch items? >>> >>> >>> >>> Yours, >>> Joel >>> >>> >>> Andy >>> >>> On 4/19/14, 1:46 PM, Andy Bierman wrote: >>> >>> Hi, >>> >>> >>> On Sat, Apr 19, 2014 at 8:22 AM, Russ White >> >>> >> wrote: >>> >>> >>> > And the basic premise of I2RS is that there are >>> requirements for >>> the work >>> > that were not addressed properly by the existing >>> configuration >>> protocols. >>> > Otherwise the WG would not even need to discuss protocol >>> modifications. >>> > So the fact that NetConf / YANG works for device >>> configuration >>> does not >>> > seem to be evidence that it works for what I2RS wants to >>> do. >>> >>> Precisely. Otherwise, we could have just looked at the >>> problem, and >>> said, >>> "let's use YANG." But I think we're starting to confuse the >>> problem set >>> because we started by trying to boil the ocean. Once you >>> actually get to >>> town, it's hard to keep in focus that you're just there for >>> a new >>> pitchfork >>> handle -- that game of checkers over there on the porch of >>> the hotel >>> looks >>> so interesting, and the hardware store has so much other >>> stuff than just >>> pitchfork handles, after all. >>> >>> So, given we are _supposed_ to be focused on the RIB >>> interface, and not >>> protocol, configuration, device, etc., etc., what specific >>> points >>> have the >>> use cases brought out that either NETCONF/YANG or FORCES not >>> fulfill? One of >>> the primary points was timing -- are these other systems >>> fast enough? >>> >>> >From my perspective, these two systems don't fulfill the >>> I2RS >>> mandate on the >>> RIB side for various reasons: >>> >>> - I'm not convinced on the speed side. YANG feels a bit >>> heavy weigh >>> for what >>> we want here. The flexibility is there, but so is the cost >>> of that >>> flexibility. >>> >>> >>> >>> Can you explain how an off-line representation of the data model >>> can be >>> fast or slow? >>> You mean the YANG compiler takes too long to process a YANG file? >>> You mean the unspecified I2RS protocol will be too slow on the >>> wire if >>> it uses XML or JSON encoding of YANG data structures? >>> >>> >>> - I'm not convinced YANG has handled the atomicity issues >>> in a way that >>> makes sense for the application environment we have in mind. >>> RESTCONF seems >>> to go that direction, but I'm not certain it's a complete >>> solution (?). >>> >>> >>> YANG is a data modeling language. >>> RESTCONF is a protocol. >>> Atomicity is a property of the protocol. >>> Which YANG statements prevent this from being accomplished in >>> the TBD >>> I2RS protocol? >>> >>> So, IMHO, I think we need to either consider FORCES, or >>> "something >>> new." But >>> we're going to have a hard time determining if this is true >>> if we >>> can't make >>> a solid requirements list. For me, these are: >>> >>> - Atomic operations at the RIB level >>> - Speed that's comparable to a local routing process >>> installing >>> routes in >>> the RIB >>> - An immediate feedback system within the RESTful mold that >>> tells the >>> installing process what happened, and why, with the route >>> it just >>> tried to >>> install in the RIB >>> >>> So, it seems to me that we need to return to the use cases >>> -- there >>> are two >>> in the charter. If we want to discuss adding others, that's >>> fine, but we >>> need to gain some focus, and stop trying to boil the ocean, >>> if we >>> want to >>> make any progress. >>> >>> >>> It seems to me this WG needs to start asking the right questions >>> about the >>> data modeling language requirements. E.g.: >>> >>> - What are the data types needed? Is this a static set of >>> will it >>> ever change? >>> - What are the high level data modeling constructs needed? >>> - Are user defined types needed? >>> - Are re-usable data definitions needed? >>> - Does the data model need to be modular? How does it grow >>> over time? >>> - Can vendors add data definitions that extend the standard >>> definitions? >>> - How are new definitions added in a way that does not break >>> existing >>> clients? >>> - How is mandatory to implement vs. optional to implement >>> functionality handled? >>> - How is mandatory to use vs. optional to use functionality >>> handled? >>> >>> You are asking about protocol requirements, not data modeling. >>> IMO it would be near-sighted and extremely impractical to choose >>> a language that only supported description on RIB info. I fail >>> to see what >>> is so special about RIB info that would warrant its own DML. >>> >>> >>> :-) >>> >>> Russ >>> >>> >>> Andy >>> >>> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Sat Apr 19 13:12:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3EB1A00DD for ; Sat, 19 Apr 2014 13:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iheSxSO3huug for ; Sat, 19 Apr 2014 13:11:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id C98611A0055 for ; Sat, 19 Apr 2014 13:11:54 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.921.12; Sat, 19 Apr 2014 20:11:48 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Sat, 19 Apr 2014 20:11:48 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepACAAIEXAIAAA4mAgAAu1oCAAAWPgIAAEnAAgAACOgCAANbMAIAAT+iAgAARsAA= Date: Sat, 19 Apr 2014 20:11:47 +0000 Message-ID: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(24454002)(199002)(189002)(81342001)(93916002)(46102001)(86362001)(36756003)(99396002)(77156001)(81542001)(82746002)(551934002)(62966002)(92726001)(80976001)(19580395003)(19580405001)(83322001)(77982001)(4396001)(31966008)(74662001)(50226001)(74502001)(85852003)(87286001)(2656002)(88136002)(87936001)(83072002)(76176999)(50986999)(89996001)(33656001)(83716003)(66066001)(79102001)(99286001)(20776003)(80022001)(76482001)(92566001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:EEF7F02C.AFF69503.B0FA3D4F.4AEAE981.2047E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69ED70B610EE424090E2DC4652A91EC8@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hUxCcQegTfzUAkfbkD1NSupS5mk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 20:11:59 -0000 On Apr 19, 2014, at 3:08 PM, Jamal Hadi Salim wrote: > On Sat, Apr 19, 2014 at 10:22 AM, Dean Bogdanovic wro= te: >=20 >>=20 >> What is working i2rs code? >=20 > Code that implements, using your choice of model and protocol, the I2RS > semantics. To examplify using your slides at the meeting, iirc, > such semantics would be between the agent one side and what iirc > you called client (in our case we call them Apps). > i.e take something like the RIB info model and cast it into your model c= hoice > and make APIs available to message things between a basic agent and > the routing daemon. >=20 >> From Juniper perspective, I can claim having PoC i2rs code, as I can dyn= amically create >> REST APIs (will not call them RESTconf, as it has only partial complianc= e with >> current RESTconf draft) based on the service described on the device. Th= e PoC functionally >> is very close i2rs architecture document and with that can see what serv= ices can be created >> and abstracted for i2rs. >>=20 >> So for i2rs, as long I can create a data model for a service, where the = service is simple as add or >delete route and can programmatically consume = that service, it is i2rs. Many vendors today can do >that with NETCONF/REST= CONF/YANG and we are voicing our preference for that. >>=20 >=20 > Sorry, I dont think that is sufficient. The programmatic APIs part is obv= ious. > There are bigger issue which shape how a protocol is to be wired and > what model would be > sensible; in my response ealier, one you and I discussed was speed. > How do you do > a 1000 route update or add with JSON? It comes down how many transactions are required? Will you updated 1000 rou= tes in single transaction or in 1000 transactions. >From my perspective there are two important metrics for i2rs throughput and latency IMO, I2RS agent has to provide as high as possible throughput and add minim= al latency to the process. What is the throughput required? Don't know at t= he moment. I saw some request in high single digit thousands per second, bu= t not sure about use cases. On the latency side, you want it as close to 0 = as possible, but that will be highly platform dependent. I have to start doing some PoCs to see what can and can not do with existin= g tools. If those tools work, then good. If those tools don't work, then ba= ck to the drawing board. Until things work, keep on moving with what works = and try to find break points. > If it is a requirement then the agent needs to be able to handle > clients of different > latencies etc and deal with congestion issues that are common in proxies = when > you have multiple users being considered and probably a single entry > to the routing interface. > If it is not a requirement - should that not be stated somewhere? You can add your comments to the existing drafts. >=20 > Unfortunately - we are not having that kind of useful discussion and i > feel like a broken > record asking for requirements. I believe we have a set of requirements. It is in draft-rfernando-i2rs-prot= ocol-requirements. You can always comment that draft and argue pro and con = each requirement. >=20 > cheers, > jamal From nobody Sat Apr 19 16:04:34 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E91A0102 for ; Sat, 19 Apr 2014 16:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od_AtCM3sEzb for ; Sat, 19 Apr 2014 16:04:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C7D171A00D3 for ; Sat, 19 Apr 2014 16:04:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas Nadeau'" , "'David Meyer'" References: In-Reply-To: Date: Sat, 19 Apr 2014 19:04:16 -0400 Message-ID: <002d01cf5c23$b0756c90$116045b0$@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: AQHvgyR3RJcJ8Z28dH8XpYzls9ffUAFkD5pgAmcPTxGauuePAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7tJGQzgKtAL4C76fMwcLazeT2Uo Cc: i2rs@ietf.org, 'Jamal Hadi Salim' Subject: Re: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 19 Apr 2014 23:04:32 -0000 Tom: 100% agree on the process management in the hands of the chair. Thanks for the email clarification since the verbal pointed toward "tech-only". I hope Ed or Jeff will comment. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Saturday, April 19, 2014 1:40 PM To: David Meyer Cc: i2rs@ietf.org; Jamal Hadi Salim Subject: Re: [i2rs] On +1 That was most definitely the purpose of my last +1. My intend wasn't "me too", but a shorthand for not rewriting exactly what Jan had said. I'd advise we keep the process management in the hands of the chairs. Tom > On Apr 19, 2014, at 12:23 PM, David Meyer wrote: > >> On Sat, Apr 19, 2014 at 3:51 AM, Jamal Hadi Salim wrote: >> Folks, >> >> No offense intended, but can we please have something a little more >> profound than a +1 when agreeing or disagreeing? >> All i can see in my head when someone says +1 is: >> https://www.youtube.com/watch?v=_j9QeUoPOi4 >> >> I think a +1 should complete with "because ...." > > Thank you for your opinion but I trust my that my colleagues are > capable of expressing their support (or lack there of) in the way that > want to. In addition, given the breadth and depth of this thread (and > associated history) I don't see the need to recapitulate the arguments > made here in order to agree (or disagree) with the stated direction. > > --dmm > >> >> cheers, >> jamal >> >> _______________________________________________ >> 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 nobody Sat Apr 19 17:27:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36A1A00D3 for ; Sat, 19 Apr 2014 17:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqGd-4CwzTBR for ; Sat, 19 Apr 2014 17:27:19 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 50A361A00A3 for ; Sat, 19 Apr 2014 17:27:19 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so2546567yha.30 for ; Sat, 19 Apr 2014 17:27: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=Dpj5Y6lRohkXeuI6OFSoWRmmRbLrVxor86uE4dzWfxU=; b=Ojxh7H1GK7xdgDGoyIXqfqgWs42+1fOX2m0O+BM7kpoL3Lyqoj/oryaGzP8cEi80CM JUYBImSSTtQJE3VYnez/yR0Vuy/zMqoewD8aI79aac6+Jo8DDhq+whpWoOUkJXupHV7Q o0X09CZXYi1/VV8RHwP0HwCGl2E9SkGp1UshN8f5IzCfZYZfBLxGqGMJrFVtjEUWgZ6F t7adJ5bCC4dEzQV41HOFpC9zm0W8tn88YsXCNIrEMRMGOyJDDtG2D1FziAZdyS+avrOb kQ3poxlgARQHH3vQ8hjarO4ddMUDJkUjSYK/MmEQWPHk9A2Q9GcV23tDSIV8iE7P9xLK JtnA== MIME-Version: 1.0 X-Received: by 10.236.114.2 with SMTP id b2mr5408821yhh.92.1397953634693; Sat, 19 Apr 2014 17:27:14 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Sat, 19 Apr 2014 17:27:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Apr 2014 02:27:14 +0200 Message-ID: From: Abdussalam Baryun To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=20cf3011db3dcef59404f76e719b Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/28CvqcNoHLedx28b9dTbr1HNnIA Cc: "i2rs@ietf.org" Subject: Re: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 00:27:21 -0000 --20cf3011db3dcef59404f76e719b Content-Type: text/plain; charset=UTF-8 I disagree mostly and may agree if no there were no WG discussion. IMO any participant can input even with humming in meeting so on lists +1 is like humming yes, -1 humming no (without reasons). On the other hand, we need to have discussions with reasons on all issues, so I prefer if we point to the issue that had no discussion with reason before the hummings, or open subject discussion within WG for clarification. AB On Saturday, April 19, 2014, Jamal Hadi Salim wrote: > Folks, > > No offense intended, but can we please have something a little more > profound than a +1 when > agreeing or disagreeing? Was there discussion before that? The reasons may be related to discussions in past. What is your point? When was there voting before discussions? > All i can see in my head when someone says +1 is: > very nice, high five For me is means humming YES (remotely). > > I think a +1 should complete with "because ...." No always. > > cheers, > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf3011db3dcef59404f76e719b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree mostly=C2=A0and may agree if no there were no WG=C2=A0discussion= .=C2=A0=C2=A0IMO any participant can input even with humming in meeting so = on lists +1 is like humming yes, -1 humming no (without reasons). On=C2=A0t= he other hand,=C2=A0we need to=C2=A0have=C2=A0discussions with reasons on a= ll issues, so I prefer if we=C2=A0point to the issue that had no discussion= with reason before the hummings, or open subject discussion within WG for = clarification.=C2=A0

AB

On Saturday, April 19, 2014, Jamal Hadi Salim wro= te:
Folks,

No offense intended, =C2=A0but can we please have something a little more profound than a +1 when
agreeing or disagreeing?

Was there discussi= on before that? The reasons may be related to discussions in past. What is = your point? When was there voting before=C2=A0discussions?
=C2=A0=
All i can see in my head when someone says +1 is:
very nice, high five

For me is means h= umming YES (remotely).=C2=A0
=C2=A0

I think a +1 should complete with "because ...."

No always.=C2=A0
=C2=A0

cheers,
jamal

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
--20cf3011db3dcef59404f76e719b-- From nobody Sat Apr 19 17:50:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69EF1A0096 for ; Sat, 19 Apr 2014 17:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQoGIX4BSwbk for ; Sat, 19 Apr 2014 17:50:00 -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 3FFCB1A008D for ; Sat, 19 Apr 2014 17:50:00 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so5630693veb.30 for ; Sat, 19 Apr 2014 17:49:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zkphclkIcHEFc7f3z5RTp6YO8MSyu6ajbYn3OadYavE=; b=E4qBgxU85GAT6btv3TCRrghjpzchQwoHKoP9facthVNXhGMPoVt/2hwYW/tsruXRCl kfWrcV6xWFJ6gE4/lpO5xVxAUayUsm1VPosg0pSXgubiA7rNLil3IoauMniOCX6hFv6S AYU/jXtgJ3N5T3k7K/HMhHZn9J75PEtRdNWGWRxvuVHmcBbPdidyjTf9iRuo/KNdbOtp A6uiThuAxf1ICJmHAefOb/4Mc+mlPYh2umQ6Wmm8lHctMeK86/2PAv1mMOQ7bGPB5C/z aX23UqgIOvBRc0H07uNr2t2v6QwzSVb+vrZHN7joP66R2gtSLx6wDVIo7eOHbovH0XNv Ij/g== X-Gm-Message-State: ALoCoQmQXzlx7h9Nf3dx4WsZhOK7ojpid90fPFeUkpWmeBVQNawvAZrZi0jjvqVD0mCYrcX0DRPT X-Received: by 10.52.69.146 with SMTP id e18mr19027651vdu.15.1397954995232; Sat, 19 Apr 2014 17:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 17:49:34 -0700 (PDT) In-Reply-To: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 20:49:34 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/d-qRiDwo6am7ah_7nz7nNHEippk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 00:50:02 -0000 On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic wrote: > It comes down how many transactions are required? Will you updated 1000 > routes in single transaction or in 1000 transactions. > Take your pick. The point is it boils down to how that is modelled and carr= ied over the wire (and influences those decisions). > From my perspective there are two important metrics for i2rs > throughput > and > latency > Now we are talking. > > IMO, I2RS agent has to provide as high as possible throughput and add min= imal latency to the >process. What is the throughput required? Don't know a= t the moment. I saw some request in high >single digit thousands per second= , but not sure about use cases. On the latency side, you want it as >close = to 0 as possible, but that will be highly platform dependent. > Agreed. > I have to start doing some PoCs to see what can and can not do with exist= ing tools. If those tools >work, then good. If those tools don't work, then= back to the drawing board. Until things work, keep on >moving with what wo= rks and try to find break points. > But i do believe there are limitations which are not obvious without contrasting against requirements. > You can add your comments to the existing drafts. > I would gladly do - but i worry whether the discussion is about crowning so= me solution instead of meeting such objectives; if the WG decides to move in = that direction i would be happy to contribute. There's material floating, the old protocol draft; Joel pointed to the architecture draft covering model requirements. Andy mentioned possible "stretch" requirements. I think what would be appropriate is one draft for the model and one for the protocol with gap analysis. >> >> Unfortunately - we are not having that kind of useful discussion and i >> feel like a broken >> record asking for requirements. > > I believe we have a set of requirements. It is in draft-rfernando-i2rs-pr= otocol-requirements. >You can always comment that draft and argue pro and con each requirement. Glad we are bringing that draft into play;-> How does restconf fair against= it? Note: The draft is a good starting point but is missing as an example the issue of latency and throughput. cheers, jamal From nobody Sat Apr 19 17:56:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00011A0112 for ; Sat, 19 Apr 2014 17:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0q1laiHnQ_S for ; Sat, 19 Apr 2014 17:56:49 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id E4CA31A0096 for ; Sat, 19 Apr 2014 17:56:48 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so5592465veb.32 for ; Sat, 19 Apr 2014 17:56:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sY8s3B3u+Wvl8E6orAvN9jUts6LAUOoUfetP8hZDH+k=; b=OTVvZKHoDD+McZujhYBR2mPCYeCQzYMIwZo6qDoucX3llTUYOHY0YwtauJZA8+ThjF 8fQso9RiH5Tbf1agm6qr4CiJAR4JVoHcX0A/eIntiOJeYiHXS3cHC/AaalTW4S5Qi/hw GyUHEfylFWFOGdhyQuh5E0XUdxqkwBB6Q+XJxTx1f5AAkTBK7FITU2MMELsf/64viEs6 8ZrrpbqR070LWvstlqtNJsKAfwUbB/vliNlifQsCJ3cb1AbqiCu0pa+4CNkmSENFqGo/ tG/UNZb5UacxYZ1UVB5PU6gcTq28odxqDyXyva0irxzbCbLwXvZx2aHlqmLbqA563vnU SY2w== X-Gm-Message-State: ALoCoQl3hRhVQOiCpF51fUzHSNKeNLYs2ORd5J2c07FiuilEVnl9FQ/NIQOo2X7KI5GaoQGI6zoq X-Received: by 10.52.175.166 with SMTP id cb6mr18911551vdc.1.1397955404307; Sat, 19 Apr 2014 17:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sat, 19 Apr 2014 17:56:24 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Sat, 19 Apr 2014 20:56:24 -0400 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wRr8Uzl08x6Ufno1gv2XBKDwUmY Cc: "i2rs@ietf.org" Subject: Re: [i2rs] On +1 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 00:56:51 -0000 The posting from the chair was to have a discussion towards a consensus and an eventual draft. In the meeting people could hum to "do you like the blue shirt"; they could raise their hands to agree with somebody's presentation. But if the chair asks for discussion's raising your hand or humming is not as useful. Another analogy: If i someone said "should we go for dinner?" - then a +1 is appropriate. If someone said "what should we have for dinner?" - then an abundance of +1 is not useful. The former is a vote and the later is a discussion. I believe we are supposed to have a discussion. In any case - I am sorry i started this discussion; it is distracting. cheers, jamal On Sat, Apr 19, 2014 at 8:27 PM, Abdussalam Baryun wrote: > I disagree mostly and may agree if no there were no WG discussion. IMO any > participant can input even with humming in meeting so on lists +1 is like > humming yes, -1 humming no (without reasons). On the other hand, we need to > have discussions with reasons on all issues, so I prefer if we point to the > issue that had no discussion with reason before the hummings, or open > subject discussion within WG for clarification. > > AB > > > On Saturday, April 19, 2014, Jamal Hadi Salim wrote: >> >> Folks, >> >> No offense intended, but can we please have something a little more >> profound than a +1 when >> agreeing or disagreeing? > > > Was there discussion before that? The reasons may be related to discussions > in past. What is your point? When was there voting before discussions? > >> >> All i can see in my head when someone says +1 is: >> very nice, high five > > > For me is means humming YES (remotely). > >> >> >> I think a +1 should complete with "because ...." > > > No always. > >> >> >> cheers, >> jamal >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Apr 20 12:54:01 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D01A000C for ; Sun, 20 Apr 2014 12:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C6T7_G--Epj for ; Sun, 20 Apr 2014 12:53:55 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8021A0007 for ; Sun, 20 Apr 2014 12:53:55 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3KJm6rq012893; Sun, 20 Apr 2014 12:53:41 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1kcfjk832u-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 20 Apr 2014 12:53:41 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 20 Apr 2014 12:53:40 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Sun, 20 Apr 2014 12:53:40 -0700 From: ramki Krishnan To: Geoffrey Mattson , Jeff Tantsura , "Jan Medved (jmedved)" , Dean Bogdanovic , Jamal Hadi Salim Date: Sun, 20 Apr 2014 12:53:41 -0700 Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Je9XaL+FIKUeJb8+m5HQcAZsXRxgAgAAepgCAAIEVAIAAEkMA//+MRYCAA3OPYA== Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-20_02:2014-04-18,2014-04-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404200340 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/WYKbJ5dp8_lwQQs5r4rX0QfTYMw Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 19:53:59 -0000 +1 for Netconf for the I2RS protocol and YANG for the modeling language. Thanks, Ramki (Brocade Communications Systems, Inc.) -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Geoffrey Mattson Sent: Friday, April 18, 2014 3:11 PM To: Jeff Tantsura; Jan Medved (jmedved); Dean Bogdanovic; Jamal Hadi Salim Cc: i2rs@ietf.org; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model +1 for Netconf for the I2RS protocol and YANG for the modeling language. On 4/18/14 3:04 PM, "Jeff Tantsura" wrote: >+1 for Netconf/YANG for the i2rs protocol and for YANG as >the modeling language. > > >Cheers, >Jeff > > >-----Original Message----- >From: "Jan Medved (jmedved)" >Date: Friday, April 18, 2014 1:59 PM >To: Dean Bogdanovic , Jamal Hadi Salim=20 > >Cc: "i2rs@ietf.org" , Edward Crabbe >Subject: Re: [i2rs] consensus on I2RS protocol and model > >>Cisco is also implementing Netconf - it=B9s available on XR today, and=20 >>it will be available on other platforms as well. >> >>For OpenDaylight, we chose Yang as the IDL to describe internal and=20 >>external APIs in the controller and so far it has served its purpose=20 >>really well. >> >>Also, as Tom pointed out, Netconf and Restconf have also been=20 >>implemented in ODL. I=B9d like to stress that we not only have multiple=20 >>Netconf/Restconf implementations from multiple vendors (Brocade,=20 >>Juniper, Cisco, just to mention those on this thread), but have=20 >>multiple open source implementations as well. In addition to ODL,=20 >>there is libnetconfd and a few others. ODL / libnetconfd interop=20 >>testing is done in the ODL regression test suite. Now, since there=20 >>are multiple independent open source implementations, we=B9ve got a good= =20 >>ecosystem for implementation of new Netconf/Restconf/Yang features=20 >>that may be required to meet i2rs=B9s needs (if the need to evolve the=20 >>protocols/language arises). >> >>In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang=20 >>as the modeling language. >> >> >> >>Thanks, >>Jan >> >> >>On 4/18/14, 6:17 AM, "Dean Bogdanovic" wrote: >> >>>Jamal, >>> >>>Here are two criteria to be considered: >>>1. technical >>>2. commercial/business >>> >>>We can discuss pros and cons for both, but have to state that from=20 >>>business perspective for Juniper going with RESTCONF/YANG make more=20 >>>sense. We already built the Junos model in YANG and have or are in=20 >>>process of building needed tools. Same goes for RESTCONF. >>>We have NETCONF implemented in Junos and are working on RESTCONF=20 >>>implementation. >>>Many carriers adopted or are adopting NETCONF/YANG, are looking into=20 >>>RESTCONF as well, so this looks like a low hanging fruit from=20 >>>business perspective. >>> >>>Looking at technical aspect, unless there is a very compelling reason=20 >>>(and there might be, but I'm not aware of it), don't see reason to=20 >>>switch from RESTCONF and YANG. >>>We can find out down the line that RESTCONF/YANG was the wrong way to=20 >>>go, but that can be always changed. From my perspective it looks=20 >>>right today. >>> >>>Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>> >>>Dean >>> >>>On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim wrote: >>> >>>> Ok, since nobody is saying anything i'll bite. >>>> How would you like for this discussion to proceed? >>>>=20 >>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe wrote: >>>>> Dear I2RSers, >>>>>=20 >>>>> At the last I2RS WG meeting there was a great deal of=20 >>>>>conversation regarding selection of both modeling language and=20 >>>>>underlying transport protocol. Consensus at the time was to make=20 >>>>>use of Yang and (NetConf or >>>>> RestConf) (unclear). >>>>>=20 >>>>=20 >>>> And i believe the view, as correctly presented by you, is for folks=20 >>>>to go back and make educated decisions by actually getting=20 >>>>knowledgeable about the different views presented. "Consensus" that=20 >>>>you described above to me looked like a pageant popularity contest=20 >>>>not based on anything technical ("who likes contestant in the blue=20 >>>>shirt? please cheer for them"). >>>>=20 >>>> In my opinion i dont think the requirements are clear. >>>>=20 >>>> Will that get the crickets stop chirping? >>>>=20 >>>> cheers, >>>> jamal >>>>=20 >>>>> Before coming to a final consensus, we'd like to give people=20 >>>>>adequate time to review source material, marshall arguments and=20 >>>>>discuss on the mailing list. To this end, we're asking that=20 >>>>>interested parties do just this over the course of the next ~two=20 >>>>>weeks. Following that period, on 4/28, we'll be initiating a=20 >>>>>consensus call that will last an additional two weeks, with the =20 >>>>>aim of converging modeling language / protocol by Friday, 5/9. >>>>>=20 >>>>> The consensus call should also generate proposals for any material=20 >>>>>changes required to the underlying protocols. These proposals in=20 >>>>>turn will form the basis for a later draft including gap analysis=20 >>>>>and said changes. >>>>>Those >>>>> strongly in favor of one protocol over another should be prepared=20 >>>>>to contribute to this analysis. >>>>>=20 >>>>>=20 >>>>> best, >>>>>=20 >>>>> -ed >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >>>>=20 >>>>=20 >>> >>> >>>_______________________________________________ >>>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 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Apr 20 14:31:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340951A0057 for ; Sun, 20 Apr 2014 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqobj7C79DvQ for ; Sun, 20 Apr 2014 14:31:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF3B1A004B for ; Sun, 20 Apr 2014 14:31:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Sun, 20 Apr 2014 17:31:09 -0400 Message-ID: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CF5CBE.52022E50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9c19foXt9o+CdzTr2gUy/X6uSZrw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/l8tSm0xH6RbBaLUjBpxpEa_T6TM Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, Alia Atlas Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 21:31:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01CF5CBE.52022E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin, Ron, Kini, Jan: 1) Is Section 7 of your document normative or informative? 2) Your grammar seems wordy/inconsistent in the repetition of the next hop below Your RIB grammar on page 17 states: ::= | ((nexthop-list-member>) | ( . | )) ::= ( | ) [] ::= ( .) Questions: Why do you have nexthop-list-member listed twice? Why list twice? Is this readability or technical matter? Why not: ::= (( | (nexthop-list-member) . ) . Why not: ::= ((( | ( . ))[ Multicast-source-ipv6-address ::= Did I miss someplace where they attached to the normative section 6. You indicated the PIM paths can be chains (section 7.3), but you do not give the normative section. Sue Hares ------=_NextPart_000_002E_01CF5CBE.52022E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin, = Ron, Kini, Jan:

 

1)      = Is Section 7 of your document normative or = informative?

 

2)      = Your grammar seems wordy/inconsistent in the = repetition of the next hop below

 

Your = RIB grammar on page 17 states:

 

<nexthop-list> ::=3D <special-nexthop> | =

         &= nbsp;           &n= bsp;          ((nexthop= -list-member>) |

         &= nbsp;           &n= bsp;           (&l= t;nexthop-list-member> … | = <nexthop-list>))

 

<nexthop-list-member> ::=3D = (<nexthop-chain> |

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     <nexthop-chain-identifier>)

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    = [<nexthop-list-member-attributes>]

 

<nexthop-chain>::=3D (<nexthop> …) =

 

Questions: Why do you have nexthop-list-member listed = twice?  Why list <nexthop-list> twice? Is this readability or = technical matter?

 

Why not: =

<nexthop-list>::=3D = ((<special-nexthop> | (nexthop-list-member) … ) … =

 

Why not:

<nexthop-list-member> ::=3D = (((<nexthop-chain-identifier> | (<nexthops> … = ))[<nexthop-list-member-attributes]) )…

 

Were you = trying to name the chains?

 

3)      = Two variables seem orphaned:

 

Multicast-source-ipv4-address ::=3D = <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D = <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH>

 

=          Did I miss = someplace where they attached to the normative section 6. =

         &= nbsp; You indicated the PIM paths can be chains (section 7.3), but = you do not give the normative section.

 

Sue Hares =

 

------=_NextPart_000_002E_01CF5CBE.52022E50-- From nobody Sun Apr 20 15:00:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E411A0054 for ; Sun, 20 Apr 2014 15:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ot4A18cNgWO for ; Sun, 20 Apr 2014 15:00:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 338BC1A0051 for ; Sun, 20 Apr 2014 15:00:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> In-Reply-To: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> Date: Sun, 20 Apr 2014 18:00:09 -0400 Message-ID: <005001cf5ce3$e692ddb0$b3b89910$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CF5CC2.5F827630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJDVTTSWiap2uJXVyijfSPE/irizZozHMug Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4ZdoX0kqbMQK6lWyQw6uc0_23m8 Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 22:00:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0051_01CF5CC2.5F827630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin, Ron, Kini and Jan: I forgot to ask question on the grammar: :: = | | ( [COS_VALUE] []) Rater limited is not defined. Is there a reason why this would be in a standard document without a definition? Did I miss something on the list? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, April 20, 2014 5:31 PM To: i2rs@ietf.org Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia Atlas Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 Nitin, Ron, Kini, Jan: 1) Is Section 7 of your document normative or informative? 2) Your grammar seems wordy/inconsistent in the repetition of the next hop below Your RIB grammar on page 17 states: ::= | ((nexthop-list-member>) | ( . | )) ::= ( | ) [] ::= ( .) Questions: Why do you have nexthop-list-member listed twice? Why list twice? Is this readability or technical matter? Why not: ::= (( | (nexthop-list-member) . ) . Why not: ::= ((( | ( . ))[ Multicast-source-ipv6-address ::= Did I miss someplace where they attached to the normative section 6. You indicated the PIM paths can be chains (section 7.3), but you do not give the normative section. Sue Hares ------=_NextPart_000_0051_01CF5CC2.5F827630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin, Ron, Kini and = Jan:

 

I forgot to ask question = on the grammar:

 

<special-nexthop> = :: =3D <DISCARD> | <DISCARD_WITH_ERROR> | (<RECEIVE> = [COS_VALUE] [<rate-limiter>])

 

Rater limited is not = defined.  Is there a reason why this would be in a standard = document without a definition?  Did I miss something on the list? =

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Sunday, April 20, 2014 5:31 PM
To: = i2rs@ietf.org
Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia = Atlas
Subject: [i2rs] = draft-ietf-i2rs-rib-info-model-02

 

Nitin, Ron, = Kini, Jan:

 

1)      = Is Section 7 of your document normative or = informative?

 

2)      = Your grammar seems wordy/inconsistent in the = repetition of the next hop below

 

Your = RIB grammar on page 17 states:

 

<nexthop-list> ::=3D <special-nexthop> | =

         &= nbsp;           &n= bsp;          ((nexthop= -list-member>) |

         &= nbsp;           &n= bsp;           (&l= t;nexthop-list-member> … | = <nexthop-list>))

 

<nexthop-list-member> ::=3D = (<nexthop-chain> |

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     <nexthop-chain-identifier>)

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    = [<nexthop-list-member-attributes>]

 

<nexthop-chain>::=3D (<nexthop> …) =

 

Questions: Why do you have nexthop-list-member listed = twice?  Why list <nexthop-list> twice? Is this readability or = technical matter?

 

Why not: =

<nexthop-list>::=3D = ((<special-nexthop> | (nexthop-list-member) … ) … =

 

Why not:

<nexthop-list-member> ::=3D = (((<nexthop-chain-identifier> | (<nexthops> … = ))[<nexthop-list-member-attributes]) )…

 

Were you = trying to name the chains?

 

3)      = Two variables seem orphaned:

 

Multicast-source-ipv4-address ::=3D = <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D = <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH>

 

         D= id I miss someplace where they attached to the normative section 6. =

         &= nbsp; You indicated the PIM paths can be chains (section 7.3), but = you do not give the normative section.

 

Sue Hares =

 

------=_NextPart_000_0051_01CF5CC2.5F827630-- From nobody Sun Apr 20 15:12:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132011A0063 for ; Sun, 20 Apr 2014 15:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka1C-CIBjAC2 for ; Sun, 20 Apr 2014 15:12: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 02BE41A0059 for ; Sun, 20 Apr 2014 15:12:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> <005001cf5ce3$e692ddb0$b3b89910$@ndzh.com> In-Reply-To: <005001cf5ce3$e692ddb0$b3b89910$@ndzh.com> Date: Sun, 20 Apr 2014 18:12:39 -0400 Message-ID: <006301cf5ce5$a4e23cb0$eea6b610$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CF5CC4.1DD24A60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJDVTTSWiap2uJXVyijfSPE/irizQIDiWqrmiMEUJA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/j-tiBId9vSXjpLL4-vR2JqhC-Ww Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Apr 2014 22:12:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01CF5CC4.1DD24A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin, Ron, Kini and Jan: Did you replace the nexthop-address and not remove this text? ::= ( ) | ( ) | ( ) The paper only his this definition once? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, April 20, 2014 6:00 PM To: i2rs@ietf.org Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 Nitin, Ron, Kini and Jan: I forgot to ask question on the grammar: :: = | | ( [COS_VALUE] []) Rater limited is not defined. Is there a reason why this would be in a standard document without a definition? Did I miss something on the list? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, April 20, 2014 5:31 PM To: i2rs@ietf.org Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia Atlas Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 Nitin, Ron, Kini, Jan: 1) Is Section 7 of your document normative or informative? 2) Your grammar seems wordy/inconsistent in the repetition of the next hop below Your RIB grammar on page 17 states: ::= | ((nexthop-list-member>) | ( . | )) ::= ( | ) [] ::= ( .) Questions: Why do you have nexthop-list-member listed twice? Why list twice? Is this readability or technical matter? Why not: ::= (( | (nexthop-list-member) . ) . Why not: ::= ((( | ( . ))[ Multicast-source-ipv6-address ::= Did I miss someplace where they attached to the normative section 6. You indicated the PIM paths can be chains (section 7.3), but you do not give the normative section. Sue Hares ------=_NextPart_000_0064_01CF5CC4.1DD24A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin, Ron, Kini and = Jan:

 

Did you replace the = nexthop-address and not remove this text?

 

 

   <nexthop-address> ::=3D = (<IPv4> <ipv4-address>) |

         &= nbsp;           &n= bsp;   (<IPV6> <ipv6-address>) = |

         &= nbsp;           &n= bsp;   (<IEEE_MAC> = <IEEE_MAC_ADDRESS>)

 

The paper only his this = definition once?

 

Sue =

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Sunday, April 20, 2014 6:00 PM
To: = i2rs@ietf.org
Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; 'Alia = Atlas'
Subject: Re: [i2rs] = draft-ietf-i2rs-rib-info-model-02

 

Nitin, Ron, Kini and = Jan:

 

I forgot to ask question = on the grammar:

 

<special-nexthop> = :: =3D <DISCARD> | <DISCARD_WITH_ERROR> | (<RECEIVE> = [COS_VALUE] [<rate-limiter>])

 

Rater limited is not = defined.  Is there a reason why this would be in a standard = document without a definition?  Did I miss something on the list? =

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Sunday, April 20, 2014 = 5:31 PM
To: i2rs@ietf.org
Cc: 'Jeffrey = Haas'; adrian@olddog.co.uk; = Alia Atlas
Subject: [i2rs] = draft-ietf-i2rs-rib-info-model-02

 

Nitin, Ron, = Kini, Jan:

 

1)      = Is Section 7 of your document normative or = informative?

 

2)      = Your grammar seems wordy/inconsistent in the = repetition of the next hop below

 

Your = RIB grammar on page 17 states:

 

<nexthop-list> ::=3D <special-nexthop> | =

         &= nbsp;           &n= bsp;          ((nexthop= -list-member>) |

         &= nbsp;           &n= bsp;           (&l= t;nexthop-list-member> … | = <nexthop-list>))

 

<nexthop-list-member> ::=3D = (<nexthop-chain> |

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     <nexthop-chain-identifier>)

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;    = [<nexthop-list-member-attributes>]

 

<nexthop-chain>::=3D (<nexthop> …) =

 

Questions: Why do you have nexthop-list-member listed = twice?  Why list <nexthop-list> twice? Is this readability or = technical matter?

 

Why not: =

<nexthop-list>::=3D = ((<special-nexthop> | (nexthop-list-member) … ) … =

 

Why not:

<nexthop-list-member> ::=3D = (((<nexthop-chain-identifier> | (<nexthops> … = ))[<nexthop-list-member-attributes]) )…

 

Were you = trying to name the chains?

 

3)      = Two variables seem orphaned:

 

Multicast-source-ipv4-address ::=3D = <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D = <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH>

 

         D= id I miss someplace where they attached to the normative section 6. =

         &= nbsp; You indicated the PIM paths can be chains (section 7.3), but = you do not give the normative section.

 

Sue Hares =

 

------=_NextPart_000_0064_01CF5CC4.1DD24A60-- From nobody Sun Apr 20 20:22:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD931A017F for ; Sun, 20 Apr 2014 20:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.43 X-Spam-Level: X-Spam-Status: No, score=0.43 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eI9i4FC4g-l for ; Sun, 20 Apr 2014 20:21:55 -0700 (PDT) Received: from nm10-vm3.bullet.mail.gq1.yahoo.com (nm10-vm3.bullet.mail.gq1.yahoo.com [98.136.218.94]) by ietfa.amsl.com (Postfix) with ESMTP id C2E541A0176 for ; Sun, 20 Apr 2014 20:21:55 -0700 (PDT) Received: from [98.137.12.190] by nm10.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 03:21:51 -0000 Received: from [98.136.164.69] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 03:21:51 -0000 Received: from [127.0.0.1] by smtp231.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 03:21:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398050510; bh=hzRYtXGhDGhrnBbqsdw36IT5zyCYpJuKGgOa02FqbUE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=e3FhQvRiHk+XFBcoUjJOSsi1vWMreDC8CBokut0ULjuQ9CRmh7iSpEc/TI2xIQHHwZdXmwjEKzUCq/7EdqijD0/HY0U1xYWOOuAKVVDZuhn7fWQztRKc0TFKlVPZZahor2ZOzly7lkXvGGNl4ENmg67AXojMYVO7rDd2SewGONg= X-Yahoo-Newman-Id: 982775.12949.bm@smtp231.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GCSdOqMVM1mx4RapxcAuGc0iw6JMEqkubk.l3Lr6fy9wZJG BUuQOUFuvVSAVUMhLvIny7eTNxlv3CZ.SE7EP2uoLAJ3TURYYFj1y45vgb8o Raq60Z1DHFIg.C1bgQ2P75QeNYgueVr2SZDEOSFBjYxjnNRT52h8K_z.8WyR AEGOfUcYz3xzZQJ46wWr67lDmQeT_b.gKwxMlcsD6DYV178_W9rTw2fp56I4 PZzOFZ7N4K8cL6z_13BQWUYUMesbh5qRnpg8s8JgQBEbHHp_c9MwbIeNoIpI b3QGl65X6cisyU_iw3hUt99Qm53ayzPIV1it2CuYTMc9ZQlkcFn5bV5ydUD4 xA18jIiQPzb__sWQ1GpMWKXnGEufxyzakj3xvqb_Yaddrw8qQyPh2DzYYLt1 tO_SSd.uCytfmpLmPoRu9NAGcVQ.3S_aw_FhBPNEyEb5TUAJmS98CBGzhKBp kgJwVXWsljZi4n4I0dhvv9te0j2Xl5m.6BgLXMr1M6bSOl_grlCfmulZYKLo EyWNZAEKxnuAdcvQxs0d79CoPq.mYM7WnqIQ- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.22] (nitin_bahadur@24.4.100.156 with plain [98.138.105.21]) by smtp231.mail.gq1.yahoo.com with SMTP; 21 Apr 2014 03:21:50 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Sun, 20 Apr 2014 20:21:55 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] draft-ietf-i2rs-rib-info-model-02 In-Reply-To: <005001cf5ce3$e692ddb0$b3b89910$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3480870121_6109227" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/jCgRZ4zIlLb-3NXlGJjjdK9J7_I Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 03:22:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3480870121_6109227 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sue, We should remove it from the base document. The intent was that anything that goes to the control plane should be rate-limited to prevent a DOS attack. We had talked internally that the specification of a rate-limiter was out of scope of this document, but keeping this in the doc would ensure that implementors assigned a (fixed value initially?) rate-limiter of some sorts. We can remove that from the grammar and just add/keep relevant text to make the intentions more clear. Thanks nitin From: Susan Hares Date: Sunday, April 20, 2014 at 3:00 PM To: Cc: 'Jeffrey Haas' , , 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 > Nitin, Ron, Kini and Jan: > =20 > I forgot to ask question on the grammar: > =20 > :: =3D | | ( > [COS_VALUE] []) > =20 > Rater limited is not defined. Is there a reason why this would be in a > standard document without a definition? Did I miss something on the list= ? > =20 > Sue=20 > =20 >=20 > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Sunday, April 20, 2014 5:31 PM > To: i2rs@ietf.org > Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia Atlas > Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 > =20 > Nitin, Ron, Kini, Jan: > =20 > 1) Is Section 7 of your document normative or informative? >=20 > =20 >=20 > 2) Your grammar seems wordy/inconsistent in the repetition of the ne= xt > hop below=20 >=20 > =20 > Your RIB grammar on page 17 states: >=20 > =20 > ::=3D | > ((nexthop-list-member>) | > ( =8A | )) > =20 > ::=3D ( | > ) > =20 > [] > =20 > ::=3D ( =8A) > =20 > Questions: Why do you have nexthop-list-member listed twice? Why list > twice? Is this readability or technical matter? > =20 > Why not:=20 > ::=3D (( | (nexthop-list-member) =8A ) =8A > =20 > Why not:=20 > ::=3D ((( | ( =8A > ))[ =20 > Were you trying to name the chains? > =20 > 3) Two variables seem orphaned: >=20 > =20 >=20 > Multicast-source-ipv4-address ::=3D >=20 > Multicast-source-ipv6-address ::=3D >=20 > =20 > Did I miss someplace where they attached to the normative sectio= n 6. > You indicated the PIM paths can be chains (section 7.3), but y= ou do > not give the normative section. > =20 > Sue Hares=20 > =20 > _______________________________________________ i2rs mailing list > i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --B_3480870121_6109227 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Sue,

<= div>We should remove it from the base document. The intent was that anything= that goes to the control plane should be rate-limited to prevent a DOS atta= ck. We had talked internally that the specification of a rate-limiter was ou= t of scope of this document, but keeping this in the doc would ensure that i= mplementors assigned a (fixed value initially?) rate-limiter of some sorts.<= /div>

We can remove that from the grammar and just add/ke= ep relevant text to make the intentions more clear.

Thanks
nitin

=
From= : Susan Hares <shares@ndzh.com>
Date: Sunday, April 20, 201= 4 at 3:00 PM
To: <i2rs@ietf.org>
Cc= : 'Jeffrey Haas' <jhaas@pfrc.org<= /a>>, <adrian@olddog.co.uk>= ;, 'Alia Atlas' <akatlas@juniper.net= >
Subject: Re: [i2rs] draft= -ietf-i2rs-rib-info-model-02

Nitin, Ron, Kini and Jan:

 

I forgot to ask question on the grammar: =

 

<special-nex= thop> :: =3D <DISCARD> | <DISCARD_WITH_ERROR> | (<RECEIVE>= ; [COS_VALUE] [<rate-limiter>])

 

Rater limited is not defined.  Is the= re a reason why this would be in a standard document without a definition? &= nbsp;Did I miss something on the list?

 

Sue

 

From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of Susan Hares
Sent: Sunday, Apr= il 20, 2014 5:31 PM
To: i2rs@ietf.o= rg
Cc: 'Jeffrey Haas'; ad= rian@olddog.co.uk; Alia Atlas
Subject: [i2rs] draft-ietf-i2rs-= rib-info-model-02

 

Nitin, Ron, Kini, Jan:

=

 

1)      Is Section 7 of your document normative or informative?

 

<= span style=3D"mso-list:Ignore">2)      Your grammar seems wordy/inconsistent in the repetition of the next = hop below

 

Your RIB grammar on page 17 states:

 

<nexthop-list>= ; ::=3D <special-nexthop> |

 &n= bsp;            =             &nbs= p;     ((nexthop-list-member>) |

=

         &= nbsp;            = ;           (<next= hop-list-member> … | <nexthop-list>))

 

<nexthop-list-membe= r> ::=3D (<nexthop-chain> |

 = ;            &nb= sp;            &= nbsp;            = ;            <= ;nexthop-chain-identifier>)

 &nbs= p;            &n= bsp;            =             &nbs= p;          [<nexthop-list-m= ember-attributes>]

 

<nexthop-chain>::=3D (<nexthop> …)

 

= Questions: Why do you have nexthop-list-member listed twice?  Why list = <nexthop-list> twice? Is this readability or technical matter?

 

Why n= ot:

<nexthop-list>::=3D ((<specia= l-nexthop> | (nexthop-list-member) … ) …

 

Why not:

<nexthop-list-member> ::=3D (((<nexthop-ch= ain-identifier> | (<nexthops> … ))[<nexthop-list-member-at= tributes]) )…

 

Were you trying to name the chains?

 

3)      = Two variables seem orphaned:

 

Multicast-source-ipv4-address := :=3D <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D <IPv6_ADDRESS> <= IPv6_PREFIX_LENGTH>

 <= /p>

        &nbs= p;Did I miss someplace where they attached to the normative section 6. =

       &nb= sp;   You indicated the PIM paths can be chains (section 7.3)= , but you do not give the normative section.

 

Sue Hares

 

____________________= ___________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/m= ailman/listinfo/i2rs
--B_3480870121_6109227-- From nobody Sun Apr 20 22:46:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9C41A0005 for ; Sun, 20 Apr 2014 22:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be8xHKiqaMwx for ; Sun, 20 Apr 2014 22:46:31 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABAB1A004D for ; Sun, 20 Apr 2014 22:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4402; q=dns/txt; s=iport; t=1398059184; x=1399268784; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eB0FbGkU02FFQDSUds9V9/XeWp0zEdsq8YU3+aakwgk=; b=ToNJP9FB8FvMRhvWJwCuvwTXBqoGjUFJFgJ9EH9CzBMRunNstMorsebC 9ERVgT+fmTPD8VMxXKouATFE2laCeI4/Q2v8OOp27+xlOieb6TpJn5bow QBmKMbDmq4uku7rxHaf/nUm5iU4We+JyTPT3ZDU0TPBjdu9xKLtCK9BUc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAOevVFOtJA2F/2dsb2JhbABZgwaBJsQGgSIWdIIlAQEBAwEnQBIQAgEIEjQyFw4CBAENBRuIHgjMcBeNf2MHhDgBA4krj0OST4Mxgis X-IronPort-AV: E=Sophos;i="4.97,895,1389744000"; d="scan'208";a="37367886" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 21 Apr 2014 05:46:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3L5kNiD008985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 05:46:23 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 00:46:23 -0500 From: "Jan Medved (jmedved)" To: Jamal Hadi Salim , Dean Bogdanovic Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwCAAHrngP//nRqAgAB3jwCAANbOgIAAT+aAgAARsoCAAE2dAIABb+yA Date: Mon, 21 Apr 2014 05:46:22 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.95.74] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4Lok3Cabe7iUIx2X0jWW9mzccuM Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 05:46:35 -0000 On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: >On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic >wrote: > > >> It comes down how many transactions are required? Will you updated 1000 >> routes in single transaction or in 1000 transactions. >> > >Take your pick. The point is it boils down to how that is modelled and >carried >over the wire (and influences those decisions). > >> From my perspective there are two important metrics for i2rs >> throughput >> and >> latency >> > >Now we are talking. > >> >> IMO, I2RS agent has to provide as high as possible throughput and add >>minimal latency to the >process. What is the throughput required? Don't >>know at the moment. I saw some request in high >single digit thousands >>per second, but not sure about use cases. On the latency side, you want >>it as >close to 0 as possible, but that will be highly platform >>dependent. >> > >Agreed. Both throughput and latency are meaningless from the standardization point of view - they both largely depend on the underlying system. Speaking for NC/Y implementations that I=B9ve been involved with, the throughput of the Netconf Agent itself is much larger than the rest of the system, and its latency is negligible compared to the rest of the system. This happens to be true both for an embedded agent (XR), where ultimately both throughput and latency are determined by how fast you can program hardware, and for the controller, where both throughput and latency depend on how fast you can shove things into a data store. Rather than focusing on devising a super fast binary encoding for the protocol (which will speed up maybe 2-5% of the overall CPU cycles), we need to have a self-describing schema-based message encoding which allows for creation of tools that generate most of the agent and client code. NC/RC/Y gives us exactly that. The raw speed of the agent (optimized protocol processing, message encoding, etc.) must be weighed against the ease and speed with which new APIs can be added to system - we have Moore=B9s law for CPUs, but not for human brains ;-) We need to compensate for that with tooling/automation. > >> I have to start doing some PoCs to see what can and can not do with >>existing tools. If those tools >work, then good. If those tools don't >>work, then back to the drawing board. Until things work, keep on >moving >>with what works and try to find break points. >> > >But i do believe there are limitations which are not obvious without >contrasting against requirements. > >> You can add your comments to the existing drafts. >> > >I would gladly do - but i worry whether the discussion is about crowning >some >solution instead of meeting such objectives; if the WG decides to move >in that >direction i would be happy to contribute. >There's material floating, the old protocol draft; Joel pointed to the >architecture >draft covering model requirements. Andy mentioned possible "stretch" >requirements. I think what would be appropriate is one draft for the model >and one for the protocol with gap analysis. > >>> >>> Unfortunately - we are not having that kind of useful discussion and i >>> feel like a broken >>> record asking for requirements. >> >> I believe we have a set of requirements. It is in >>draft-rfernando-i2rs-protocol-requirements. >>You can always comment that draft and argue pro and con each requirement. > >Glad we are bringing that draft into play;-> How does restconf fair >against it? Reasonably well. When we evaluated restconf against these requirements (I am a co-author), the major deficiency found was lack of notifications in restconf, which was addressed in a subsequent restconf revision. There are still things that would have to be added (for example, client identities), but this can be addressed either in the protocol or in models. There is nothing *structural* in restconf that would prevent it from satisfying the requirements set.=20 And as I said earlier in this thread, about 80-90% of what I can think that we can do with I2RS (and it=B9s much, much more than just RIB programming ;-) ) can be addressed with NC/RC/Y today. >Note: The draft is a good starting point but is missing as an example >the issue of >latency and throughput. > >cheers, >jamal From nobody Sun Apr 20 23:15:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCD51A0061 for ; Sun, 20 Apr 2014 23:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDsRwxGSc4lL for ; Sun, 20 Apr 2014 23:15:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC771A0049 for ; Sun, 20 Apr 2014 23:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1398060917; x=1399270517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6KMEQU+toz0jYUXnHr6mOa1T39Z3gMLOG/UwFBNFUbM=; b=fNvbpK0AUDL1Gy5SsjJhJMQb2lOVP20bJoNMgYhn9dOaDXTgkL7daZbs 2aScSoHcDNsOQLOjYdYFRqiPH4toR1ls3YackIvKh+BqfAHW+8hxkKSvY qJ82yR+QoBSW8hKeIYVhXM+C6ZkCyt+uWfIP5pGcM8SL+9V2QwGg7isKy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsFAPi2VFOtJV2b/2dsb2JhbABZgwaBJsQFgSIWdIImAQEEeRACAQhGMiUCBAENBYhBzHoXjmIHhDgBA5hukk+DMYIr X-IronPort-AV: E=Sophos;i="4.97,895,1389744000"; d="scan'208";a="37371705" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 21 Apr 2014 06:15:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3L6FHX9020684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 06:15:17 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 01:15:16 -0500 From: "Jan Medved (jmedved)" To: Russ White , "'Andy Bierman'" Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwCAAHrngIAA/EeAgAAoDQCAAAXDgIAB6JUA Date: Mon, 21 Apr 2014 06:15:16 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> In-Reply-To: <02a101cf5bfa$1c705830$55510890$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.95.74] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ALgf15Eu-C2lITnpJF891UEtsRo Cc: "i2rs@ietf.org" , "'Joel M. Halpern'" , 'Edward Crabbe' , 'Dean Bogdanovic' , 'Jamal Hadi Salim' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 06:15:27 -0000 Russ, On 4/19/14, 11:06 AM, "Russ White" wrote: >>IMO it would be near-sighted and extremely impractical to choose a >>language that only supported description on RIB info. I fail to see >>what is so special about RIB info that would warrant its own DML. > >So you'd argue that all the requirements in all the different use cases >can >be fulfilled with YANG? There is _nothing_ unique in _any_ of those use >cases the YANG model doesn't support? Do the analysis and prove it. > What you are asking for would be a lot of work for no practical purpose. Yang has been proven to work in practice for everything that we managed to throw at it. I have two data points: - In XR, we generated yang models from internal CLI schemas - we generated models=20 for the entire CLI, for all features supported by XR, some 200 models overall.=20 The entire system can be managed by NC/Y. - In OpenDaylight, we define APIs as yang models. We created yang models for OpenFlow, ACLs, BGP protocol and BGP RIB, PCEP Protocol and tunnel programming=20 service, network wide services such as topology and inventory, etc. Overall,=20 about 110 models in production code (overall, over 300 models have been defined, but a lot of them are for testing) In addition, we have started to create models for new service definitions both on device and off-device, such as policies, analytics, subscribers, security, new protocol definitions, =8A We have not really run into any limitations. Also, as Andy pointed out, if yang does not cover something you need, you can define your own extension. So far, we only had to define a couple. Thanks, Jan From nobody Mon Apr 21 04:37:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5501A01F7 for ; Mon, 21 Apr 2014 04:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJt0uEFDfBtk for ; Mon, 21 Apr 2014 04:37:11 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 99E501A01F4 for ; Mon, 21 Apr 2014 04:37:11 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so7935560veb.12 for ; Mon, 21 Apr 2014 04:37:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Wt9/ZA0SUfbBZhcjabjReT0On4gi/5xCRRR1YhuIuss=; b=kyuYVDZlByBy8XEZEOCML1z6iJ3Z4BrzHHp0uclazeDeTC2fw9Hl2YfB7C+L7ZngeI qTjNCbqWDEhBu81rnyRx3+HDAos6RNPZuu7KhqwSKbsuzBs6l33P5wVlI/mzzspNZPzi 8at738kp9OJHznDGIYlZ9arr/cHvHqKJRhGZLTd8oXKrTbzpXnIDFuG9zDGEiXiINC42 V5mNrvWNTHhEmypeF5hGUnSLceFX/RodrCq8VZ08AQGYq6E3U6+NLBGBUUe6wvmQMCRs KYteqROuaAVZ0o2VZokSJed4WWST6DhzfTqFJHgFSvFFiOFRMjR5HVJUD4hFIfNwUHKe oaow== X-Gm-Message-State: ALoCoQmH87GLkbSyHKA1xvsemsybjZtpeXFqTEZgPLC+jVajNQMUIp1APelrMLtYeUxrVVqC7Z/g X-Received: by 10.52.166.102 with SMTP id zf6mr26053801vdb.2.1398080225377; Mon, 21 Apr 2014 04:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Mon, 21 Apr 2014 04:36:44 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> From: Jamal Hadi Salim Date: Mon, 21 Apr 2014 07:36:44 -0400 Message-ID: To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/I28NpyyLYRIGe5lWxod4ZBn7LFc Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 11:37:16 -0000 On Mon, Apr 21, 2014 at 1:46 AM, Jan Medved (jmedved) w= rote: > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: > > Both throughput and latency are meaningless from the standardization poin= t > of view - they both largely depend on the underlying system. > I am sorry, I disagree. Understanding latency and throughput needs is fundamental. We are talking about a part of the system that is optimized for speed typic= ally (at least I hope your RIB manager is) that you will now need to interact wi= th. We are not talking about you banging at some 8 bit PIO bus on a micro-controller. > Speaking for NC/Y implementations that I=B9ve been involved with, the > throughput of the Netconf Agent itself is much larger than the rest of th= e > system, and its latency is negligible compared to the rest of the system. > This happens to be true both for an embedded agent (XR), where ultimately > both throughput and latency are determined by how fast you can program > hardware, and for the controller, where both throughput and latency depen= d > on how fast you can shove things into a data store. > You have a single user in that case. Factor in the many users. Your focus in that case is provisioning. I2RS is not a CLI replacement. It is not a provisioning system. If i am mistaken and it falls under the auspicies of either CLI replacement or provisioning - then by all means Netconf/Yang = is a clear selection and lets end the discussion. Even if say a few tens/transactions per second is what the requirement says then I would go with your approach. > Rather than focusing on devising a super fast binary encoding for the > protocol (which will speed up maybe 2-5% of the overall CPU cycles), I'd like to argue your 2-5% (as i am sure papers which have been written on= how to speed up string processing will), but lets just ignore that for a sec: Lets say your approach takes 1000 cycles. You can say only 2-5% of those cy= cles are used for encoding/decoding ascii. That would be a correct statement to = make. What it is ignoring is: you are spending 1000 cycles instead of 50 for the overall computation. > >we > need to have a self-describing schema-based message encoding which allows > for creation of tools that generate most of the agent and client code. > NC/RC/Y gives us exactly that. > So does ForCES. BTW, Ive heard you repeat this statement above a few times (as well as from Thomas); Programmatic APIs are a given. We've had them in ForCES implementations for a few years. We were told IETF is not about APIs - just protocols; so nobody both= ered. I will make that clear again: We have programmatic APIs. >The raw speed of the agent (optimized > protocol processing, message encoding, etc.) must be weighed against the > ease and speed with which new APIs can be added to system - we have > Moore=B9s law for CPUs, but not for human brains ;-) Agreed - but within reason. There is a cross-over where it is abuse of huma= n intelligence i.e there is a threshold where it is not sensible to optimize for efficiency at the expense of usability - but if i can get both; what is the problem? I dont think we are that different from a usability perspective. We have different perspectives. You have been doing provisioning systems where latency and throughput require to be better than humans; I have been working on systems where i need to failover or have a board with a few hundred thousand table rows boot up very fast. My view is I2RS is closer to my perspective. >We need to compensate for that with tooling/automation. > Jan, how about this: You show up with your tools and i will show up with mine. The starting poin= t would be an information model that none of us have seen before. Lets convert that to a data model, output code and start using it via an ap= p. If I beat you by <5 minutes - you win. Lets do this live at the next meetin= g;-> >>Glad we are bringing that draft into play;-> How does restconf fair >>against it? > > Reasonably well. When we evaluated restconf against these requirements (I > am a co-author), the major deficiency found was lack of notifications in > restconf, which was addressed in a subsequent restconf revision. There ar= e > still things that would have to be added (for example, client identities)= , > but this can be addressed either in the protocol or in models. There is > nothing *structural* in restconf that would prevent it from satisfying th= e > requirements set. > As i said earlier, the draft is a good starting point but not sufficient (It also delves into areas that are not protocol specifics). To be honest, I dont recall seeing it when i published my gap analysis here= : http://datatracker.ietf.org/doc/draft-hadi-i2rs-forces-gap-analysis/ I was going to update my draft (in which case I will reference it); but i a= m not sure if it will be worth it. > And as I said earlier in this thread, about 80-90% of what I can think > that we can do with I2RS (and it=B9s much, much more than just RIB > programming ;-) ) can be addressed with NC/RC/Y today. > Lets take that hammer and use it to fix everything we see on our way. Note: I am not even arguing ForCES is the way to go - this may be a totally different protocol. cheers, jamal From nobody Mon Apr 21 04:51:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85B11A01F7 for ; Mon, 21 Apr 2014 04:51: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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp7vaJOCe8zG for ; Mon, 21 Apr 2014 04:51:34 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0AF1A01F4 for ; Mon, 21 Apr 2014 04:51:34 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so7916978veb.11 for ; Mon, 21 Apr 2014 04:51:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gnoV0CQKZrCMNNpMbop6oOv5Yu7buqBDp5FVeZEJ44k=; b=TIoU0KKNsCn7UwSbbU0sXZbjpZvWQIEQ1dEL5BvPO2gsLXM64+++xIRC21JV7K821J zKDOGyclKETf4I3Q69lNTFT1L5EcnZsqC5LOFV9ly5kk6d8rmj5bjBof4AWqv4EODxJl D7UO7IyxaUyumCTDmsxKaJzeClcCTU1GGCws953jW26f0Crn81xI2zFCssSlihx+z/PY q27xE1rmXMMDiKZfzPSbLjEJJMLjx88VYFwjZSHFEIiF+tmAmSVp0ltAKGCSauyqjIXX jsGjHp6bsAYCKhrRU0ty7zsDw/44Uyljv81Tk8CIJ0NpC4ywrHEY34jcE5SRIS4DWh/F 7SgQ== X-Gm-Message-State: ALoCoQl5TKLI1T0N7Zk9T6sLh8HzRmwpQQkcVG3FYMjLl92P/LdTwjmsaqQ/1LrGbAQ6AF7WLh1C X-Received: by 10.58.55.170 with SMTP id t10mr180422vep.29.1398081089414; Mon, 21 Apr 2014 04:51:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Mon, 21 Apr 2014 04:51:08 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> From: Jamal Hadi Salim Date: Mon, 21 Apr 2014 07:51:08 -0400 Message-ID: To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-oi8P4AXa8CUnkG-Yc9hTQqqWt0 Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Russ White , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 11:51:39 -0000 On Mon, Apr 21, 2014 at 2:15 AM, Jan Medved (jmedved) wrote: > Russ, > > On 4/19/14, 11:06 AM, "Russ White" wrote: > > What you are asking for would be a lot of work for no practical purpose. Sigh. I thought there was some process that we needed to follow. Here's a proposition: How about we settle to just an information model to begin with? This is what approaches like openstack do. You can use Yang. We'll use ours. You can use netconf/restconf and we'll use whatever modification we need on ForCES. We both publish our results after real code exists. cheers, jamal From nobody Mon Apr 21 05:56:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B41A0214 for ; Mon, 21 Apr 2014 05:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF73DDt62j9G for ; Mon, 21 Apr 2014 05:56:36 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB761A0181 for ; Mon, 21 Apr 2014 05:56:36 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so3929624qcx.20 for ; Mon, 21 Apr 2014 05:56:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FNnlHOIl7dS4+t1Jfy1/kMxNzJVZwDj8zzapfIv2alI=; b=jvuwu3Hqunt3IAIG78MNEbVyxfzphiQrKf/8ZUb3wfw/UKZ7a6GWGWwOMR/z07EB5e yIbA58DSXhh7s8iK88WWzLxI0rz34U2b/k8pOkZvvGDyDBs0dgangwFZCV6/oahDfQQG gcC7tXYmchi3lziFOf4XZEE/4IFyi5am4179aE7qC7xtU+Osi6qukzkmMYLX3qRO0K/a 04Its6DX+Rbfg+bQfHNTAQGFZiS/misOxBmxLuYF7OEfe/KYR1DGXP4YfuPND6u8Dw1w Ps8Ysbk8YI+5y1uSh+v92R2PMm2ZH7LWlwIKo2tPLx1t/SP+mrx0SRqOxslH0WB+Bxqq JnXg== X-Gm-Message-State: ALoCoQmZ9Tviny+FcpGn6kDkD/NBv1nRuo/A7W+A2xkmkb67M8TAHs1FyOHYzSF3f2URkx+nGlfr MIME-Version: 1.0 X-Received: by 10.140.27.212 with SMTP id 78mr43469369qgx.18.1398084991061; Mon, 21 Apr 2014 05:56:31 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 05:56:30 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> Date: Mon, 21 Apr 2014 05:56:30 -0700 Message-ID: From: Andy Bierman To: "Jan Medved (jmedved)" Content-Type: multipart/alternative; boundary=001a11c14d664224b904f78d070c Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QI8YQEYYem1Avah0nS9a-JLyzqc Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 12:56:41 -0000 --001a11c14d664224b904f78d070c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 20, 2014 at 10:46 PM, Jan Medved (jmedved) w= rote: > > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: > > >On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic > >wrote: > > > > > >> It comes down how many transactions are required? Will you updated 100= 0 > >> routes in single transaction or in 1000 transactions. > >> > > > >Take your pick. The point is it boils down to how that is modelled and > >carried > >over the wire (and influences those decisions). > > > >> From my perspective there are two important metrics for i2rs > >> throughput > >> and > >> latency > >> > > > >Now we are talking. > > > >> > >> IMO, I2RS agent has to provide as high as possible throughput and add > >>minimal latency to the >process. What is the throughput required? Don't > >>know at the moment. I saw some request in high >single digit thousands > >>per second, but not sure about use cases. On the latency side, you want > >>it as >close to 0 as possible, but that will be highly platform > >>dependent. > >> > > > >Agreed. > > Both throughput and latency are meaningless from the standardization poin= t > of view - they both largely depend on the underlying system. > > Speaking for NC/Y implementations that I=B9ve been involved with, the > throughput of the Netconf Agent itself is much larger than the rest of th= e > system, and its latency is negligible compared to the rest of the system. > This happens to be true both for an embedded agent (XR), where ultimately > both throughput and latency are determined by how fast you can program > hardware, and for the controller, where both throughput and latency depen= d > on how fast you can shove things into a data store. > > Rather than focusing on devising a super fast binary encoding for the > protocol (which will speed up maybe 2-5% of the overall CPU cycles), we > need to have a self-describing schema-based message encoding which allows > for creation of tools that generate most of the agent and client code. > NC/RC/Y gives us exactly that. The raw speed of the agent (optimized > protocol processing, message encoding, etc.) must be weighed against the > ease and speed with which new APIs can be added to system - we have > Moore=B9s law for CPUs, but not for human brains ;-) We need to compensa= te > for that with tooling/automation. > > > Great points. There are some specific areas where the data modeling language can impact protocol performance. The most significant is the handling of default leafs. A well-designed data model will pick reasonable default values for most leafs. Since defaults are mandatory-to-implement in YANG, a client can omit defaults when creating a new data structure. This can have a much bigger impact on throughput than binary encoding. A protocol can be fast by being clever, not always just by brute strength compression. For example, clever use of PATCH to update the absolute minimum set of objects is smaller and faster than replacing entire subtrees with PUT. The biggest impact a data modeling language can have on the protocol is wrt/ human usability and tool automation. Andy > > >> I have to start doing some PoCs to see what can and can not do with > >>existing tools. If those tools >work, then good. If those tools don't > >>work, then back to the drawing board. Until things work, keep on >movin= g > >>with what works and try to find break points. > >> > > > >But i do believe there are limitations which are not obvious without > >contrasting against requirements. > > > >> You can add your comments to the existing drafts. > >> > > > >I would gladly do - but i worry whether the discussion is about crowning > >some > >solution instead of meeting such objectives; if the WG decides to move > >in that > >direction i would be happy to contribute. > >There's material floating, the old protocol draft; Joel pointed to the > >architecture > >draft covering model requirements. Andy mentioned possible "stretch" > >requirements. I think what would be appropriate is one draft for the mod= el > >and one for the protocol with gap analysis. > > > >>> > >>> Unfortunately - we are not having that kind of useful discussion and = i > >>> feel like a broken > >>> record asking for requirements. > >> > >> I believe we have a set of requirements. It is in > >>draft-rfernando-i2rs-protocol-requirements. > >>You can always comment that draft and argue pro and con each requiremen= t. > > > >Glad we are bringing that draft into play;-> How does restconf fair > >against it? > > Reasonably well. When we evaluated restconf against these requirements (I > am a co-author), the major deficiency found was lack of notifications in > restconf, which was addressed in a subsequent restconf revision. There ar= e > still things that would have to be added (for example, client identities)= , > but this can be addressed either in the protocol or in models. There is > nothing *structural* in restconf that would prevent it from satisfying th= e > requirements set. > > And as I said earlier in this thread, about 80-90% of what I can think > that we can do with I2RS (and it=B9s much, much more than just RIB > programming ;-) ) can be addressed with NC/RC/Y today. > > > > >Note: The draft is a good starting point but is missing as an example > >the issue of > >latency and throughput. > > > >cheers, > >jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c14d664224b904f78d070c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Apr 20, 2014 at 10:46 PM, Jan Medved (jmedved) <jmedved@ci= sco.com> wrote:


On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <hadi@mojatatu.com> wrote:

>On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <deanb@juniper.net>
>wrote:
>
>
>> It comes down how many transactions are required? Will you updated= 1000
>> routes in single transaction or in 1000 transactions.
>>
>
>Take your pick. The point is it boils down to how that is modelled and<= br> >carried
>over the wire (and influences those decisions).
>
>> From my perspective there are two important metrics for i2rs
>> throughput
>> and
>> latency
>>
>
>Now we are talking.
>
>>
>> IMO, I2RS agent has to provide as high as possible throughput and = add
>>minimal latency to the >process. What is the throughput required= ? Don't
>>know at the moment. I saw some request in high >single digit tho= usands
>>per second, but not sure about use cases. On the latency side, you = want
>>it as >close to 0 as possible, but that will be highly platform<= br> >>dependent.
>>
>
>Agreed.

Both throughput and latency are meaningless from the standardization point<= br> of view - they both largely depend on the underlying system.

Speaking for NC/Y implementations that I=B9ve been involved with, the
throughput of the Netconf Agent itself is much larger than the rest of the<= br> system, and its latency is negligible compared to the rest of the system. This happens to be true both for an embedded agent (XR), where ultimately both throughput and latency are determined by how fast you can program
hardware, and for the controller, where both throughput and latency depend<= br> on how fast you can shove things into a data store.

Rather than focusing on devising a super fast binary encoding for the
protocol (which will speed up maybe 2-5% of the overall CPU cycles), we
need to have a self-describing schema-based message encoding which allows for creation of tools that generate most of the agent and client code.
NC/RC/Y gives us exactly that. The raw speed of the agent (optimized
protocol processing, message encoding, etc.) must be weighed against the ease and speed with which new APIs can be added to system - we have
Moore=B9s law for CPUs, but not for human brains ;-) =A0We need to compensa= te
for that with tooling/automation.




Great points.

There are some specific areas where the data modeling langu= age can
impact protocol performance. =A0The most significant is t= he handling
of default leafs. =A0A well-designed data model will pick reasonable
default values for most leafs. =A0Since defaults are mandatory-to-= implement
in YANG, a client can omit defaults when creating a new= data structure.
This can have a much bigger impact on throughput than binary encoding.=

A protocol can be fast by being clever, not alway= s just by brute strength
compression. =A0For example, clever use = of PATCH to update the absolute
minimum set of =A0objects is smaller and faster than replacing entire<= /div>
subtrees with PUT.

The biggest impact a = data modeling language can have on the protocol
is wrt/ human usa= bility and tool automation.


Andy

>
>> I have to start doing some PoCs to see what can and can not do wit= h
>>existing tools. If those tools >work, then good. If those tools = don't
>>work, then back to the drawing board. Until things work, keep on &g= t;moving
>>with what works and try to find break points.
>>
>
>But i do believe there are limitations which are not obvious without >contrasting against requirements.
>
>> You can add your comments to the existing drafts.
>>
>
>I would gladly do - but i worry whether the discussion is about crownin= g
>some
>solution instead of meeting such objectives; =A0if the WG decides to mo= ve
>in that
>direction i would be happy to contribute.
>There's material floating, the old protocol draft; Joel pointed to = the
>architecture
>draft covering model requirements. Andy mentioned =A0possible "str= etch"
>requirements. I think what would be appropriate is one draft for the mo= del
>and one for the protocol with gap analysis.
>
>>>
>>> Unfortunately - we are not having that kind of useful discussi= on and i
>>> feel =A0like a broken
>>> record asking for requirements.
>>
>> I believe we have a set of requirements. It is in
>>draft-rfernando-i2rs-protocol-requirements.
>>You can always comment that draft and argue pro and con each requir= ement.
>
>Glad we are bringing that draft into play;-> How does restconf fair<= br> >against it?

Reasonably well. When we evaluated restconf against these requirements (I am a co-author), the major deficiency found was lack of notifications in restconf, which was addressed in a subsequent restconf revision. There are<= br> still things that would have to be added (for example, client identities),<= br> but this can be addressed either in the protocol or in models. There is
nothing *structural* in restconf that would prevent it from satisfying the<= br> requirements set.

And as I said earlier in this thread, about 80-90% of what I can think
that we can do with I2RS (and it=B9s much, much more than just RIB
programming ;-) ) can be addressed with NC/RC/Y today.



>Note: The draft is a good starting point but is missing as an example >the issue of
>latency and throughput.
>
>cheers,
>jamal

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

--001a11c14d664224b904f78d070c-- From nobody Mon Apr 21 06:02:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD711A0212 for ; Mon, 21 Apr 2014 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1FQvm-ONiuu for ; Mon, 21 Apr 2014 06:01:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB741A0181 for ; Mon, 21 Apr 2014 06:01:56 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 21 Apr 2014 13:01:50 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) with mapi id 15.00.0921.000; Mon, 21 Apr 2014 13:01:50 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsXRxgAgAAepACAAIEXAIAAA4mAgAAu1oCAAAWPgIAA/EeAgAAoDQCAAAXDgIACXeoAgABd1wCAABO+AA== Date: Mon, 21 Apr 2014 13:01:49 +0000 Message-ID: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(479174003)(377454003)(51704005)(31966008)(74662001)(74502001)(50226001)(83322001)(19580405001)(80976001)(19580395003)(4396001)(77982001)(50986999)(79102001)(57306001)(66066001)(83716003)(80022001)(20776003)(76482001)(92566001)(99286001)(88136002)(2656002)(87936001)(83072002)(87286001)(89996001)(33656001)(76176999)(85852003)(92726001)(99396002)(36756003)(77156001)(81342001)(93916002)(46102001)(86362001)(81542001)(82746002)(62966002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:FC74C094.8CF65111.F1C79648.4AE0A1CC.202B6; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/j7nIxsgywDGGPfv9HHZ0IDyLbYw Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 13:02:02 -0000 Jamal, Majority of the people are using today NC/RC/YA (because it is available) a= nd it provides necessary functionality. Many people, including myself, didn= 't find any issues so far with it and we believe it is the right choice. If you remember, at the beginning I mentioned two criteria, technical and b= usiness. NC/RC/YA are satisfying both of them for lot of people in this gro= up. You are trying to explain why ForCES is better then NC/RC/YA and I apprecia= te it, but it is not better for my case and why should I go ahead and imple= ment ForCES on the company platform, when there is no request from the mark= et and the existing tools are working satisfactory. People do not have to explain their vote, they can just cast it, as it is t= heir opinion. Dean On Apr 21, 2014, at 7:51 AM, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 2:15 AM, Jan Medved (jmedved) = wrote: >> Russ, >>=20 >> On 4/19/14, 11:06 AM, "Russ White" wrote: >>=20 >=20 >> What you are asking for would be a lot of work for no practical purpose. >=20 > Sigh. I thought there was some process that we needed to follow. >=20 > Here's a proposition: > How about we settle to just an information model to begin with? > This is what approaches like openstack do. > You can use Yang. We'll use ours. You can use netconf/restconf and > we'll use whatever modification we need on ForCES. We both publish > our results after real code exists. >=20 > cheers, > jamal From nobody Mon Apr 21 06:08:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8B91A0181 for ; Mon, 21 Apr 2014 06:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ7VJfWnsym4 for ; Mon, 21 Apr 2014 06:08:09 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6BD1A020A for ; Mon, 21 Apr 2014 06:08:09 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s3LD7vop016702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 09:07:57 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Apr 2014 09:07:57 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Apr 2014 09:07:57 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.0847.030; Mon, 21 Apr 2014 09:07:57 -0400 From: Igor Bryskin To: "Jan Medved (jmedved)" , Jamal Hadi Salim , Dean Bogdanovic Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7GKQuFjKSvXU2c1OImmTGZdpsXiiYAgAAepgCAAIEVAIAAA4mAgAAu1oCAAAWPgIAAEnAAgAACOgCAANbOgIAAT+aAgAARsoCAAE2cAIAB5UIAgAAsEcY= Date: Mon, 21 Apr 2014 13:07:57 +0000 Message-ID: <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.98.165.184] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-21_01:2014-04-21,2014-04-20,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CFWOyWQuSNaCud5inQ7qvmfAr3s Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 13:08:11 -0000 Hi Jan,=0A= =0A= You said:=0A= =0A= " Both throughput and latency are meaningless from the standardization poin= t=0A= of view - they both largely depend on the underlying system.=0A= =0A= Speaking for NC/Y implementations that I=B9ve been involved with, the=0A= throughput of the Netconf Agent itself is much larger than the rest of the= =0A= system, and its latency is negligible compared to the rest of the system.= =0A= This happens to be true both for an embedded agent (XR), where ultimately= =0A= both throughput and latency are determined by how fast you can program=0A= hardware, and for the controller, where both throughput and latency depend= =0A= on how fast you can shove things into a data store.=0A= =0A= Rather than focusing on devising a super fast binary encoding for the=0A= protocol (which will speed up maybe 2-5% of the overall CPU cycles), we=0A= need to have a self-describing schema-based message encoding which allows= =0A= for creation of tools that generate most of the agent and client code.=0A= NC/RC/Y gives us exactly that. The raw speed of the agent (optimized=0A= protocol processing, message encoding, etc.) must be weighed against the=0A= ease and speed with which new APIs can be added to system - we have=0A= Moore=B9s law for CPUs, but not for human brains ;-) We need to compensate= =0A= for that with tooling/automation."=0A= =0A= I have a couple of questions:=0A= 1. AFAIK we don't have yet a routing protocol whose speakers exchange XML e= ncoded messages, why is that?=0A= 2. Do you think we could replace BGP transport with Netconf RPCs? (I am pes= simistic about what Yakov would say about this idea :=3D))=0A= 3. If I am to develop an i2rs client that can learn or generate route updat= es at the speed and volume of a regular BGP speaker, can it, using Netconf= , instal these updates in the i2rs agent's RIB in a timely manner? What if = i2rs client is twice as fast as the BGP speaker? What if there are two or m= ore such i2rs clients talking to the same i2rs agent? Are these are reasona= ble use cases at all ?=0A= 4. Could we replace BGP transport with ForCES? =0A= 5. Is it not possible that for some things i2rs will end up using Netconf, = while for others ForCES and/or something else? =0A= =0A= IMHO we can not give convincing answers for 3. and 5. until we see the requ= irements agreed upon by all interesting parties. In this I totally agree wi= th Jamal.=0A= My personal answer to 4. is why not? It is binary and hence as fast. I happ= en to like the granularity at which ForCES protocol allows for incremental = updates and how the messages could be limited both in size and CPU processi= ng to just the very things that have changed.=0A= =0A= Regards,=0A= Igor=0A= =0A= From nobody Mon Apr 21 06:22:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725511A0214 for ; Mon, 21 Apr 2014 06:22: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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgphZKQPaGh0 for ; Mon, 21 Apr 2014 06:22:00 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id CECB01A01DE for ; Mon, 21 Apr 2014 06:21:59 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so933855vcb.25 for ; Mon, 21 Apr 2014 06:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=21y4rge9vGcgAbjK3phL9AunIkVVZDg3MC/Xhh/K708=; b=URGlM86JM8et+z+dWgLa3mex9luKEfDJqAhPRofrNF9yo2OVjQiffHZiA9FOYAlpib Y7cW8LGxFwXEPhoDgQJCNdsxtXO1soqR9uUN+/mJ6mBcSnJaLU/ZfXuH2y074JW7x7OC fUzNMMZx1quNtBrX+0LyvsGPPmHVLMa/2fWPjciJrveih9VbzM64T7FgDRDdEIypVHCk 783O7DwDY+gUOuNaSL1glZK/J3FrQyqHyKDoCFfo1YF2pHBD0Bw65+mffGwjMTQVAIc0 7dNqfD+LWwnI7a6Zq1Mbr/Gr45dY5Sm/y1Jkb66Pz03HnrMdnBR/b0F5E0s4f4DnP5ht ye0g== X-Gm-Message-State: ALoCoQmTD9Mda9LBgLZnBvMdh6fg0HHY6ej4fSbwdhTRsoJmqGez7F38/ayKM+fiAEksU8DRbKRl X-Received: by 10.58.96.36 with SMTP id dp4mr3358922veb.21.1398086514675; Mon, 21 Apr 2014 06:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Mon, 21 Apr 2014 06:21:33 -0700 (PDT) In-Reply-To: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> From: Jamal Hadi Salim Date: Mon, 21 Apr 2014 09:21:33 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ezsPK0JI2ad5UTyzS_vOMn-f2yE Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 13:22:04 -0000 Dean, On Mon, Apr 21, 2014 at 9:01 AM, Dean Bogdanovic wrote: > Jamal, > > Majority of the people are using today NC/RC/YA (because it is available)= and it provides necessary >functionality. Many people, including myself, d= idn't find any issues so far with it and we believe it is >the right choice= . You have NOT implemented the spec to justify that technical arguement. As an example, In your last posting you said latency and throughput was important. Jan claims they are irrelevant. Is it a requirement? My answer and your is = yes. > If you remember, at the beginning I mentioned two criteria, technical and= business. I know "business" reasoning is a BIG driver; unfortunately often made to appear like the reasoning is technical (Ive said before i appreciate your sincerity). Dean, I think you should look at this with "bussiness" outside the picture. If you were to be given a chance to get this right from a technical pov - what would you do? There is an "E" in IETF (no "B"); yes i am trying my best to be pragmatic and not ignoring the "B" - but only when all is equal that becomes a clear decider. To be noted again: I am not even pushing for ForCES, but it definetely aint netconf or restconf - sorry. > NC/RC/YA are satisfying both of them for lot of people in this group. > You are trying to explain why ForCES is better then NC/RC/YA and I apprec= iate it, but it is not better >for my case and why should I go ahead and im= plement ForCES on the company platform, when >there is no request from the = market and the existing tools are working satisfactory. > sure - so what is wrong then with letting you go and do restconf and me do ForCES. Lets just have the "market" decide? All i am asking for is the process be followed or have the tyranny of the majority take over. > People do not have to explain their vote, they can just cast it, as it is= their opinion. > There is a difference between a vote and a discussion. I believe we are in discussion mode right now. In discussion mode people voice opinions not cast a ballot. cheers, jamal From nobody Mon Apr 21 06:33:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7DB1A0219 for ; Mon, 21 Apr 2014 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwl4ChNOW_tg for ; Mon, 21 Apr 2014 06:33:05 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7F1A0214 for ; Mon, 21 Apr 2014 06:33:04 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id 63so588570qgz.9 for ; Mon, 21 Apr 2014 06:33:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MerB8UXASgjRrr77+xbMp1AcKTVz18mb3Znp5ee1NzY=; b=DlntJZC17EVKkcbikjMLy4zA6lXVpQgNvJlKX0DGVr4FIROXtpdM8IpWoyjOhs+kpl TiyGa/PYPBgXbkccpIjEbX2Dfp6/xakl8RoWe8QbC3Ls7vMWRUZc2JstQy+8kJQA0+ux o9TSqO3VYX1+h7kl4k8FZAOBZoBq23lvsCNUOKVjkbDd7e0vz608AqHczRGZw4tzCBGI nA5zz+BwvreUaq7uMhBrTQvEuYU590U/gK/7ouNoG7grFiwnCGK1qojrcM5q2Xl4TWvd yejJ6A7+rnVWVbNyWysEor2kJXA+o/cwyckaVSul83I6WU5mZEC5zLWaKGBzUfH5XLsl 4Qaw== X-Gm-Message-State: ALoCoQm798CdSyK9Vic6oQ3pawZ08sIk6Mn4h8bHy+T7vXrqLTzTqYqPCDR5nMytPFFAixQJ0sEm MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr3936626qad.88.1398087179911; Mon, 21 Apr 2014 06:32:59 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 06:32:59 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> Date: Mon, 21 Apr 2014 06:32:59 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0158a9e4b957ca04f78d899c Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OQnYStQCCUxSOirRdn1uHtHKaK4 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 13:33:09 -0000 --089e0158a9e4b957ca04f78d899c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 6:21 AM, Jamal Hadi Salim wrote: > Dean, > > On Mon, Apr 21, 2014 at 9:01 AM, Dean Bogdanovic > wrote: > > Jamal, > > > > Majority of the people are using today NC/RC/YA (because it is > available) and it provides necessary >functionality. Many people, including > myself, didn't find any issues so far with it and we believe it is >the > right choice. > > You have NOT implemented the spec to justify that technical arguement. > As an example, In your last posting you said latency and throughput > was important. > Jan claims they are irrelevant. Is it a requirement? My answer and your is > yes. > > > If you remember, at the beginning I mentioned two criteria, technical > and business. > > I know "business" reasoning is a BIG driver; unfortunately often made > to appear like the > reasoning is technical (Ive said before i appreciate your sincerity). > Dean, I think you should look at this with "bussiness" outside the picture. > If you were to be given a chance to get this right from a technical > pov - what would > you do? There is an "E" in IETF (no "B"); yes i am trying my best to > be pragmatic > and not ignoring the "B" - but only when all is equal that becomes a > clear decider. > To be noted again: I am not even pushing for ForCES, but it definetely > aint netconf > or restconf - sorry. > > > NC/RC/YA are satisfying both of them for lot of people in this group. > > You are trying to explain why ForCES is better then NC/RC/YA and I > appreciate it, but it is not better >for my case and why should I go ahead > and implement ForCES on the company platform, when >there is no request > from the market and the existing tools are working satisfactory. > > > > sure - so what is wrong then with letting you go and do restconf and > me do ForCES. > Lets just have the "market" decide? All i am asking for is the process > be followed or > have the tyranny of the majority take over. > > It looks to me like the market already has decided. NETCONF started in 2002 and was first published as an RFC in 2004. Now, 12 years later, it is finally being significantly deployed. (Delay is mostly because converting legacy systems from ad-hoc hand-made CLI is hard.) Will it take 10 more years for vendors to deploy ForCES? Are any vendors shipping it now? If not, how soon? Ignoring the tool-chains and the history and claiming that both NETCONF/YANG and ForCES are at the same level of maturity is not really fair. Andy > People do not have to explain their vote, they can just cast it, as it is > their opinion. > > > > There is a difference between a vote and a discussion. I believe we > are in discussion > mode right now. In discussion mode people voice opinions not cast a ballot. > > cheers, > jamal > --089e0158a9e4b957ca04f78d899c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Apr 21, 2014 at 6:21 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Dean,

On Mon, Apr 21, 2014 at 9:01 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
> Jamal,
>
> Majority of the people are using today NC/RC/YA (because it is availab= le) and it provides necessary >functionality. Many people, including mys= elf, didn't find any issues so far with it and we believe it is >the= right choice.

You have NOT implemented the spec to justify that technical arguement.
As an example, In your last posting you said latency and throughput
was important.
Jan claims they are irrelevant. Is it a requirement? My answer and your is = yes.

> If you remember, at the beginning I mentioned two criteria, technical = and business.

I know "business" reasoning is a BIG driver; unfortunately often = made
to appear like the
reasoning is technical (Ive said before i appreciate your sincerity).
Dean, I think you should look at this with "bussiness" outside th= e picture.
If you were to be given a chance to get this right from a technical
pov - what would
you do? There is an "E" in IETF (no "B"); yes i am tryi= ng my best to
be pragmatic
and not ignoring the "B" - but only when all is equal that become= s a
clear decider.
To be noted again: I am not even pushing for ForCES, but it definetely
aint netconf
or restconf - sorry.

> NC/RC/YA are satisfying both of them for lot of people in this group.<= br> > You are trying to explain why ForCES is better then NC/RC/YA and I app= reciate it, but it is not better >for my case and why should I go ahead = and implement ForCES on the company platform, when >there is no request = from the market and the existing tools are working satisfactory.
>

sure - so what is wrong then with letting you go and do restconf and
me do ForCES.
Lets just have the "market" decide? All i am asking for is the pr= ocess
be followed or
have the tyranny of the majority take over.



It looks to me like the= market already has decided.
NETCONF started in 2002 and was firs= t published as an RFC in 2004.
Now, 12 years later, it is finally= being significantly deployed.
(Delay is mostly because converting legacy systems from ad-hoc hand-ma= de CLI is hard.)

Will it take 10 more years for ve= ndors to deploy ForCES?
Are any vendors shipping it now? If not, = how soon?

Ignoring the tool-chains and the history and claiming t= hat both NETCONF/YANG and ForCES
are at the same level of maturit= y is not really fair.


Andy


> People do not have to explain their vote, they can just cast it, as it= is their opinion.
>

There is a difference between a vote and a discussion. I believe we
are in discussion
mode right now. In discussion mode people voice opinions not cast a ballot.=

cheers,
jamal

--089e0158a9e4b957ca04f78d899c-- From nobody Mon Apr 21 06:55:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59561A01FA for ; Mon, 21 Apr 2014 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id numxzcXefLtx for ; Mon, 21 Apr 2014 06:55:18 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF71A01C2 for ; Mon, 21 Apr 2014 06:55:18 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id im17so1000673vcb.37 for ; Mon, 21 Apr 2014 06:55:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VVJA+AC2mt0pHdHFMFD2KbLlxx93R75ZEUtb1v8qk9c=; b=i/A9OgqfrmOkTtMkUgjWmbN92Wcah9x2oy/O6tkfxrk2v28aCID6amqE0n3YQnEOrZ HtsG2nX4NLtWG7EMh4DS103xplVnTVW3oBM6iib0+HI/QE/xT2hjof59jkF927wJeJgh SRcRmWEp8xnTnzQ2qSznQaS7jPybgtE268p9cyYx3cvzvR5rCIJdqdOaK+r9cre8Shr2 2S2HR0kUMO/QKphVNf6Gp2lEDadLDU696EQsTWKPrFsv3F33QQqHxJDZlByxp97LQpn9 +LMj8j8p04jIBULlj2z6Tvg9MS7tWkkZIDvozkbaYFG/hlrWNHm+5VQbS8O6hIyJ9bSw 9dAA== X-Gm-Message-State: ALoCoQl7JGCeRd/FuFqkkh8txmZGuJ5Hy31nvdtQ9u7QbXvrX3YThCZcr4nDeKYXbnYJ0dq9/LYq X-Received: by 10.58.181.170 with SMTP id dx10mr2114752vec.25.1398088512966; Mon, 21 Apr 2014 06:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Mon, 21 Apr 2014 06:54:52 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> From: Jamal Hadi Salim Date: Mon, 21 Apr 2014 09:54:52 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/stv-b8351-DhYBS6YfJecN0Sf_Y Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 13:55:23 -0000 Sigh - ok, I guess we need to address this elephant in the room. Feel free to change the subject line. On Mon, Apr 21, 2014 at 9:32 AM, Andy Bierman wrote: > > > It looks to me like the market already has decided. > NETCONF started in 2002 and was first published as an RFC in 2004. > Now, 12 years later, it is finally being significantly deployed. > (Delay is mostly because converting legacy systems from ad-hoc hand-made CLI > is hard.) > The _big box vendors have decided_ as is evident in this thread. The market used to be driven by vendors deciding. New rules. If the "market" had decided all along then OF wouldnt be making the dent it did. We wouldnt even have an I2RS working group or this discussion today. If OF (regardless of its deficiencies) had come to the IETF it would have been dead on arrival because the "market" would decide differently. > Will it take 10 more years for vendors to deploy ForCES? Traditional vendors have refused to deploy ForCES. That is their choice and i can empathize with their point of view. Look - the old rules of "vendor needs to deploy" equalling success is what held back ForCES by deciding to do this at the IETF. OTOH, I know without coming to the IETF we would be not as complete as i believe we are. Tapping into the great system of expertise at the IETF has been extremely invaluable. Death by +1 - not so much. > Are any vendors shipping it now? If not, how soon? > Your definition of "vendor" may vary. Andy, Yuma is a vendor; we are a vendor. The rules have changed. We dont need the vertical supply chains to define a protocol. Hacking the system using old rules will make the IETF irrelevant. > Ignoring the tool-chains and the history and claiming that both NETCONF/YANG > and ForCES > are at the same level of maturity is not really fair. > respectfully disagree. Jan keeps talking about all these great APIs they have. We've been doing that for a decade. cheers, jamal From nobody Mon Apr 21 07:54:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D21A0223 for ; Mon, 21 Apr 2014 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86w3A7H5u_Wz for ; Mon, 21 Apr 2014 07:54:17 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 157221A021B for ; Mon, 21 Apr 2014 07:54:16 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id w8so3796541qac.41 for ; Mon, 21 Apr 2014 07:54:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SLte1FYnV94baOanOeBGBFUKmHDVvXrVFmDpgoxPqis=; b=beP0ceWeageX9ye44+Z+Uw5cGE5hI7w8s97jmnMijAyxI+r1bpD/NffHJ6jRiKAFaO 1VnhLSuhIwhGd6pCDuSvGygDuOl19ySZk2glP8OQFd8gfwsbpvn4ybXm8DU4cb0Ooygq tdvscJLHi5vFZRn/TiTrkEv2Jm9um6kVvomoHHmXgHGdbl4+SZ5eRxApGnKj4WgiZgJT eMtq9vCUbzajp78iE4DlMP+FVPIwCJtDvmopAvFbv1SWJlobu9wWUDdIMTONf5mkCbVT 4fAeA7nMLSaPUjsafgTm5ZOGQ8xi1oksYoM1IHczwP7bdZyPi2P/71XWs5DAorxx1qyV a4Rg== X-Gm-Message-State: ALoCoQkGIYnulS89henUq1XMXbGiOZCT4f1ABISzgrPOws1UfgrsoufDDrKrB/3EDmbgx/igm553 MIME-Version: 1.0 X-Received: by 10.140.36.86 with SMTP id o80mr41012163qgo.25.1398092050864; Mon, 21 Apr 2014 07:54:10 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 07:54:10 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> Date: Mon, 21 Apr 2014 07:54:10 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a11c16c1e0e31bf04f78eac83 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/KPCJQZkrZgYikeK1NtRbL3vLDzc Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 14:54:22 -0000 --001a11c16c1e0e31bf04f78eac83 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 21, 2014 at 6:54 AM, Jamal Hadi Salim wrote: > Sigh - ok, I guess we need to address this elephant in the room. > Feel free to change the subject line. > > On Mon, Apr 21, 2014 at 9:32 AM, Andy Bierman wrote: > > > > > > It looks to me like the market already has decided. > > NETCONF started in 2002 and was first published as an RFC in 2004. > > Now, 12 years later, it is finally being significantly deployed. > > (Delay is mostly because converting legacy systems from ad-hoc hand-made > CLI > > is hard.) > > > > The _big box vendors have decided_ as is evident in this thread. > The market used to be driven by vendors deciding. New rules. > If the "market" had decided all along then OF wouldnt be making the dent > it did. We wouldnt even have an I2RS working group or this discussion > today. > If OF (regardless of its deficiencies) had come to the IETF it would have > been > dead on arrival because the "market" would decide differently. > > I think Jan and others have explained why they think they can leverage the NC/RC/YANG technology to implement I2RS. There are tool and data model management requirements in addition to the protocol in order to have a workable solution. Unless the RIB data is one monolithic blob implemented without variation on every router, then issues such as modularity, conformance model, data lifecycle, distributed naming authority, data augmentation, and language extensibility are going to matter. Andy > Will it take 10 more years for vendors to deploy ForCES? > > Traditional vendors have refused to deploy ForCES. That is their choice > and i can empathize with their point of view. Look - the old rules of "vendor needs to deploy" equalling success is > what held back ForCES by deciding to do this at the IETF. > OTOH, I know without coming to the IETF we would be not as complete as > i believe we are. Tapping into the great system of expertise at the > IETF has been > extremely invaluable. Death by +1 - not so much. > > > Are any vendors shipping it now? If not, how soon? > > > > Your definition of "vendor" may vary. Andy, Yuma is a vendor; we are > a vendor. The rules have changed. We dont need the vertical supply chains > to define a protocol. > Hacking the system using old rules will make the IETF irrelevant. > > > Ignoring the tool-chains and the history and claiming that both > NETCONF/YANG > > and ForCES > > are at the same level of maturity is not really fair. > > > > respectfully disagree. > Jan keeps talking about all these great APIs they have. We've been > doing that for a decade. > > cheers, > jamal > --001a11c16c1e0e31bf04f78eac83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Apr 21, 2014 at 6:54 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Sigh - ok, I guess we need to address this e= lephant in the room.
Feel free to change the subject line.

On Mon, Apr 21, 2014 at 9:32 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
> It looks to me like the market already has decided.
> NETCONF started in 2002 and was first published as an RFC in 2004.
> Now, 12 years later, it is finally being significantly deployed.
> (Delay is mostly because converting legacy systems from ad-hoc hand-ma= de CLI
> is hard.)
>

The _big box vendors have decided_ as is evident in this thread.
The market used to be driven by vendors deciding. New rules.
If the "market" had decided all along then OF wouldnt be making t= he dent
it did. We wouldnt even have an I2RS working group or this discussion today= .
If OF (regardless of its deficiencies) had come to the IETF it would have b= een
dead on arrival because the "market" would decide differently.


I think Jan and others = have explained why they think they can leverage
the NC/RC/YANG te= chnology to implement I2RS. There are tool
and data model managem= ent requirements in addition to the protocol
in order to have a workable solution.

Unless = the RIB data is one monolithic blob implemented without
variation= on every router, then issues such as modularity, conformance model,
data lifecycle, distributed naming authority, data augmentation,
=
and language extensibility are going to matter.



Andy


> Will it take 10 more years for vendors to deploy ForCES?

Traditional vendors have refused to deploy ForCES. That is their choice
and i can empathize with their point of view.=A0
Look - the old rules of "vendor needs to deploy" equalling succes= s is
what held back ForCES by deciding to do this at the IETF.
OTOH, I know without coming to the IETF we would be not as complete as
i believe we are. Tapping into the great system of expertise at the
IETF has been
extremely invaluable. Death by +1 - not so much.

> Are any vendors shipping it now? If not, how soon?
>

Your definition of =A0"vendor" may vary. Andy, Yuma is a vendor; = we are
a vendor. The rules have changed. We dont need the vertical supply chains to define a protocol.
Hacking the system using old rules will make the IETF irrelevant.

> Ignoring the tool-chains and the history and claiming that both NETCON= F/YANG
> and ForCES
> are at the same level of maturity is not really fair.
>

respectfully disagree.
Jan keeps talking about all these great APIs they have. We've been
doing that for a decade.

cheers,
jamal

--001a11c16c1e0e31bf04f78eac83-- From nobody Mon Apr 21 08:10:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EE1A01FF for ; Mon, 21 Apr 2014 08:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSBiFE_7Q2uE for ; Mon, 21 Apr 2014 08:10:40 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 081001A01FA for ; Mon, 21 Apr 2014 08:10:39 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so1116169vcb.16 for ; Mon, 21 Apr 2014 08:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=q+1uIIm28rcmYgGD4Fm58RgfxsCuyuE7LOagcVW1D94=; b=Yjg8BhvinRfJjyLj4vMSGO+EIHgd2CjDvOYOuX0ga+qdEHwiwSOORDm4MT9Cz7rSFc zewWuIM6+M41xP996JsQq6GzuQkRjT7wKe4qFCyFjYSS3aoK7q67aVr8rXAfoebDi3YI vxfSLyYRxJXx4BcIgdMqdyDWhkEoe/M2dpWQR8pO0yRle9pG0av/JwR68TLvnaO2HLZo oZglkdFRUo/M380cN0dkE1CdgJTdZke1OJFl3nE/i3UyuvYyIw3x1Vk7hYUPBxSYVmvz DalCkJyAc+FpHZxzCm1oaG05XesbmadOR5Mx8UKY4DeyoDCK8UnMIBN1Q4IbK2D0yss6 n+jw== X-Gm-Message-State: ALoCoQno1cy1zMJcpyte1RMOoNdJouB2CwfB34/TXnHwpUXVHzuL8lI+qGrP/YCm+EqCEzBNrQgX X-Received: by 10.58.49.65 with SMTP id s1mr15282ven.48.1398093034813; Mon, 21 Apr 2014 08:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Mon, 21 Apr 2014 08:10:14 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> From: Jamal Hadi Salim Date: Mon, 21 Apr 2014 11:10:14 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/V4ISVYM1HAuqEft5Fh2Vmc0Yo6w Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 15:10:41 -0000 On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman wrote: > > I think Jan and others have explained why they think they can leverage > the NC/RC/YANG technology to implement I2RS. There are tool > and data model management requirements in addition to the protocol > in order to have a workable solution. > > Unless the RIB data is one monolithic blob implemented without > variation on every router, then issues such as modularity, conformance > model, data lifecycle, distributed naming authority, data augmentation, > and language extensibility are going to matter. > So lets put all that in a requirement list somewhere and work around a gap analysis. cheers, jamal From nobody Mon Apr 21 09:56:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E511A0235 for ; Mon, 21 Apr 2014 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlGcyFJaZCKd for ; Mon, 21 Apr 2014 09:55:55 -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 59CCD1A0015 for ; Mon, 21 Apr 2014 09:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6598; q=dns/txt; s=iport; t=1398099350; x=1399308950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7wE6/pPKv3LXj3EqPhxGjPbhekJk8/YnvGu7hZVnKLs=; b=eMFX1dA+ucXpNtNKYl0jqeqP8lPVQeYAXYpd9G4RFgx9UsuxqbbNqB/o /8noyNS7wPRPBN1aQm7L2wHU3+Fk5xpLZ+TuQTXz+6eLba5r683VqSuZg N682rp02J5+r/DKFAogEn0vhulrsGg/Q5sYUTuZu3s9FjjxF58RyBgFjG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAD1NVVOtJV2Z/2dsb2JhbABZgwaBJoMPwH8ZgQcWdIImAQEENEUQAgEIDg4oAgIwJQIEAQ0FFIgtjlGcEwaCDKETF4EjjF0KBwElKwcEgmWBTwSYbpJPgzGBaQkXIg X-IronPort-AV: E=Sophos;i="4.97,897,1389744000"; d="scan'208";a="319039865" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 21 Apr 2014 16:55:50 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3LGtndj024817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 16:55:49 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 11:55:49 -0500 From: "Jan Medved (jmedved)" To: Igor Bryskin , Jamal Hadi Salim , Dean Bogdanovic Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwCAAHrngP//nRqAgAB3jwCAANbOgIAAT+aAgAARsoCAAE2dAIABb+yAgADwtoD//8pTAA== Date: Mon, 21 Apr 2014 16:55:48 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.169] Content-Type: text/plain; charset="euc-kr" Content-ID: <4F182B613FDB5E4DB9E66FAC2B48A36E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/G-t3ctD1cith9OHnFyg5v4EkMSs Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 16:55:59 -0000 SGkgSWdvciwNCg0KT24gNC8yMS8xNCwgNjowNyBBTSwgIklnb3IgQnJ5c2tpbiIgPElCcnlza2lu QGFkdmFvcHRpY2FsLmNvbT4gd3JvdGU6DQoNCj5IaSBKYW4sDQo+DQo+WW91IHNhaWQ6DQo+DQo+ IiBCb3RoIHRocm91Z2hwdXQgYW5kIGxhdGVuY3kgYXJlIG1lYW5pbmdsZXNzIGZyb20gdGhlIHN0 YW5kYXJkaXphdGlvbg0KPnBvaW50DQo+b2YgdmlldyAtIHRoZXkgYm90aCBsYXJnZWx5IGRlcGVu ZCBvbiB0aGUgdW5kZXJseWluZyBzeXN0ZW0uDQo+DQo+U3BlYWtpbmcgZm9yIE5DL1kgaW1wbGVt ZW50YXRpb25zIHRoYXQgSan2dmUgYmVlbiBpbnZvbHZlZCB3aXRoLCB0aGUNCj50aHJvdWdocHV0 IG9mIHRoZSBOZXRjb25mIEFnZW50IGl0c2VsZiBpcyBtdWNoIGxhcmdlciB0aGFuIHRoZSByZXN0 IG9mIHRoZQ0KPnN5c3RlbSwgYW5kIGl0cyBsYXRlbmN5IGlzIG5lZ2xpZ2libGUgY29tcGFyZWQg dG8gdGhlIHJlc3Qgb2YgdGhlIHN5c3RlbS4NCj5UaGlzIGhhcHBlbnMgdG8gYmUgdHJ1ZSBib3Ro IGZvciBhbiBlbWJlZGRlZCBhZ2VudCAoWFIpLCB3aGVyZSB1bHRpbWF0ZWx5DQo+Ym90aCB0aHJv dWdocHV0IGFuZCBsYXRlbmN5IGFyZSBkZXRlcm1pbmVkIGJ5IGhvdyBmYXN0IHlvdSBjYW4gcHJv Z3JhbQ0KPmhhcmR3YXJlLCBhbmQgZm9yIHRoZSBjb250cm9sbGVyLCB3aGVyZSBib3RoIHRocm91 Z2hwdXQgYW5kIGxhdGVuY3kgZGVwZW5kDQo+b24gaG93IGZhc3QgeW91IGNhbiBzaG92ZSB0aGlu Z3MgaW50byBhIGRhdGEgc3RvcmUuDQo+DQo+UmF0aGVyIHRoYW4gZm9jdXNpbmcgb24gZGV2aXNp bmcgYSBzdXBlciBmYXN0IGJpbmFyeSBlbmNvZGluZyBmb3IgdGhlDQo+cHJvdG9jb2wgKHdoaWNo IHdpbGwgc3BlZWQgdXAgbWF5YmUgMi01JSBvZiB0aGUgb3ZlcmFsbCBDUFUgY3ljbGVzKSwgd2UN Cj5uZWVkIHRvIGhhdmUgYSBzZWxmLWRlc2NyaWJpbmcgc2NoZW1hLWJhc2VkIG1lc3NhZ2UgZW5j b2Rpbmcgd2hpY2ggYWxsb3dzDQo+Zm9yIGNyZWF0aW9uIG9mIHRvb2xzIHRoYXQgZ2VuZXJhdGUg bW9zdCBvZiB0aGUgYWdlbnQgYW5kIGNsaWVudCBjb2RlLg0KPk5DL1JDL1kgZ2l2ZXMgdXMgZXhh Y3RseSB0aGF0LiBUaGUgcmF3IHNwZWVkIG9mIHRoZSBhZ2VudCAob3B0aW1pemVkDQo+cHJvdG9j b2wgcHJvY2Vzc2luZywgbWVzc2FnZSBlbmNvZGluZywgZXRjLikgbXVzdCBiZSB3ZWlnaGVkIGFn YWluc3QgdGhlDQo+ZWFzZSBhbmQgc3BlZWQgd2l0aCB3aGljaCBuZXcgQVBJcyBjYW4gYmUgYWRk ZWQgdG8gc3lzdGVtIC0gd2UgaGF2ZQ0KPk1vb3JlqfZzIGxhdyBmb3IgQ1BVcywgYnV0IG5vdCBm b3IgaHVtYW4gYnJhaW5zIDstKSAgV2UgbmVlZCB0byBjb21wZW5zYXRlDQo+Zm9yIHRoYXQgd2l0 aCB0b29saW5nL2F1dG9tYXRpb24uIg0KPg0KPkkgaGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbnM6 DQo+MS4gQUZBSUsgd2UgZG9uJ3QgaGF2ZSB5ZXQgYSByb3V0aW5nIHByb3RvY29sIHdob3NlIHNw ZWFrZXJzIGV4Y2hhbmdlIFhNTA0KPmVuY29kZWQgbWVzc2FnZXMsIHdoeSBpcyB0aGF0Pw0KDQpJ IGFtIG5vdCB0YWxraW5nIGFib3V0IHJvdXRpbmcgcHJvdG9jb2xzLCBidXQgcHJvdG9jb2xzIHRo YXQgY29uc3RpdHV0ZQ0KobBBUElzobEgaW50byB0aGUgc3lzdGVtLiBTdWNoIHByb3RvY29scyBh cmUgTkMvUkMvWSwgRm9yY2VzLCBPRiwgUENFUCwgLi4uDQoNCj4yLiBEbyB5b3UgdGhpbmsgd2Ug Y291bGQgcmVwbGFjZSBCR1AgdHJhbnNwb3J0IHdpdGggTmV0Y29uZiBSUENzPyAoSSBhbQ0KPnBl c3NpbWlzdGljIGFib3V0IHdoYXQgWWFrb3Ygd291bGQgc2F5IGFib3V0IHRoaXMgaWRlYSA6PSkp DQoNCkkgYW0gbm90IHN1Z2dlc3RpbmcgdGhhdCwgYWx0aG91Z2ggaXShr3MgZG9hYmxlLiBJbiBP REwgd2UgaW50ZXJuYWxseQ0Kbm9ybWFsaXplIHByb3RvY29sIG1lc3NhZ2VzIG9uIHlhbmctZW5j b2RlZCBOQyBSUENzIGFuZCBOb3RpZmljYXRpb25zDQpiZWZvcmUgcHV0dGluZyB0aGVtIG9uIGFu IGludGVybmFsIG1lc3NhZ2UgYnVzLiBXZSBkZWZpbmVkIHlhbmcgbW9kZWxzIGZvcg0KT0YsIFBD RVAgYW5kIEJHUCBtZXNzYWdlcy4gQkdQLCBQQ0VQLCBPRiwgZXRjIGlzIHVzZWQgZXh0ZXJuYWxs eSwgdGhvdWdoLg0KDQpXaGVuIHJ1bm5pbmcgYmVuY2htYXJrcyAmIHByb2ZpbGluZywgdGhlIG5v cm1hbGl6YXRpb24gaXMgYmFyZWx5IGEgYmxpcCBvbg0KdGhlIHJhZGFyoaYgVGhlIGFkdmFudGFn ZSBpcyB0aGF0IHdlIHByZXNlbnQgYSB1bmlmb3JtIHZpZXcgb2YgcHJvdG9jb2xzIHRvDQphcHBz IHJ1bm5pbmcgaW4gdGhlIGNvbnRyb2xsZXIgYW5kIGhhdmUgIGJ1bmNoIG9mIHRvb2xzIHRoYXQg Z2VuZXJhdGUgYQ0KbG90IG9mIHRoZSBhcHAgY29kZSB0aGF0IG5lZWRzIHRvIGludGVyYWN0IHdp dGggdGhlIHJlc3BlY3RpdmUgcHJvdG9jb2wuDQpJdCBhbHNvIGFsbG93ZWQgdXMgdG8gcmUtdXNl IG5vdCBvbmx5IGNvZGUsIGJ1dCBkZXNpZ24gcGF0dGVybnMgYXMgd2VsbC4NCg0KPjMuIElmIEkg YW0gdG8gZGV2ZWxvcCBhbiBpMnJzIGNsaWVudCB0aGF0IGNhbiBsZWFybiBvciBnZW5lcmF0ZSBy b3V0ZQ0KPnVwZGF0ZXMgYXQgdGhlIHNwZWVkIGFuZCB2b2x1bWUgIG9mIGEgcmVndWxhciBCR1Ag c3BlYWtlciwgY2FuIGl0LCB1c2luZw0KPk5ldGNvbmYsIGluc3RhbCB0aGVzZSB1cGRhdGVzIGlu IHRoZSBpMnJzIGFnZW50J3MgUklCIGluIGEgdGltZWx5IG1hbm5lcj8NCg0KQXMgSSBzYWlkIGJl Zm9yZSwgdGhlIHByb3RvY29sIGJ5IHdoaWNoIHlvdSBsZWFybiB0aGUgcm91dGUgdXBkYXRlcyBp cyBhDQpzbWFsbCBmcmFjdGlvbiBvZiB0aGUgb3ZlcmFsbCBDUFUgY3ljbGVzLiBGb3IgYSBsYXJn ZSBzY2FsZSBkZXBsb3ltZW50DQppdKGvcyBtb3JlIGFib3V0IHRoZSByaWdodCBvcmdhbml6YXRp b24gb2YgZGF0YSBpbiB0aGUgUklCIGZvciBmYXN0IHVwZGF0ZXMNCmFuZCBzY2FsZTsgYWZ0ZXIg dGhhdCBpdKGvcyBhYm91dCB0aGUgc3BlZWQgYXQgd2hpY2ggeW91IGNhbiBpbnN0YWxsIHRoZQ0K cm91dGVzIGluIGhhcmR3YXJlLg0KDQo+V2hhdCBpZiBpMnJzIGNsaWVudCBpcyB0d2ljZSBhcyBm YXN0IGFzIHRoZSBCR1Agc3BlYWtlcj8NCg0KSSBkb26hr3QgdW5kZXJzdGFuZCB0aGUgcXVlc3Rp b24gLSBob3cgY2FuIGFuIGkycnMgY2xpZW50IGludGVyYWN0IHdpdGggYQ0KQkdQIFNwZWtlcj8N Cg0KDQoNCj5XaGF0IGlmIHRoZXJlIGFyZSB0d28gb3IgbW9yZSBzdWNoIGkycnMgY2xpZW50cyB0 YWxraW5nIHRvIHRoZSBzYW1lIGkycnMNCj5hZ2VudD8gQXJlIHRoZXNlIGFyZSByZWFzb25hYmxl IHVzZSBjYXNlcyBhdCBhbGwgPw0KPjQuIENvdWxkIHdlIHJlcGxhY2UgQkdQIHRyYW5zcG9ydCB3 aXRoIEZvckNFUz8NCj4gDQo+NS4gSXMgaXQgbm90IHBvc3NpYmxlIHRoYXQgZm9yIHNvbWUgdGhp bmdzIGkycnMgd2lsbCBlbmQgdXAgdXNpbmcNCj5OZXRjb25mLCB3aGlsZSBmb3Igb3RoZXJzIEZv ckNFUyBhbmQvb3Igc29tZXRoaW5nIGVsc2U/DQoNCiJUaGF0J3MgZm9vbGlzaC4gWW91IHBpY2sg dGhlIG9uZSByaWdodCB0b29sLqGxIChBbnRvbiBDaGlndXJoIGluIE5vDQpDb3VudHJ5IGZvciBP bGQgTWVuKQ0KDQpXaHkgd291bGQgd2UgZG8gdGhhdD8gVHdvIHNldHMgb2YgZW5naW5lZXJpbmcg cnVsZXMsIGNvbmZpZ3VyYXRpb25zLCB0b29sDQpjaGFpbnMsIGJ1Z3OhpiAoTXkgJDAuMDIpDQoN Cj4gDQo+DQo+SU1ITyB3ZSBjYW4gbm90IGdpdmUgY29udmluY2luZyBhbnN3ZXJzIGZvciAzLiBh bmQgNS4gdW50aWwgd2Ugc2VlIHRoZQ0KPnJlcXVpcmVtZW50cyBhZ3JlZWQgdXBvbiBieSBhbGwg aW50ZXJlc3RpbmcgcGFydGllcy4gSW4gdGhpcyBJIHRvdGFsbHkNCj5hZ3JlZSB3aXRoIEphbWFs Lg0KDQpXZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBJMlJTIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1l bnRzIGZvciB0aGUgcGFzdCB5ZWFyDQpvciBzby4gSXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0 IGF0IHRoZSBsYXN0IElFVEYgdGhlcmUgd2VyZSB0d28NCnByb3Bvc2FscyB0aGF0IGNhbiBtZWV0 IHRoZSByZXF1aXJlbWVudHM6IEZvcmNlcyBhbmQgTkMvUkMvWS4gVGhlcmUgaGF2ZQ0KYmVlbiBj YXNlcyBtYWRlIGZvciBlYWNoIG9uZSBvZiB0aGVtIC0gQW5keSBhbmQgRGVhbiBtYWRlIHRoZSBj YXNlIGZvcg0KTkMvUkMvWSwgYW5kIEphbWFsIG1hZGUgdGhlIGNhc2UgZm9yIEZvcmNlcy4gRWQg aGFzIGFza2VkIHRoZSBjb21tdW5pdHkgdG8NCmEgdm90ZSBmb3Igb25lIG9mIHRoZSB0d28uDQoN CklzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdCBvciBub3Q/IElmIG15IHVuZGVyc3RhbmRpbmcg aXMgY29ycmVjdCwgd2h5DQphcmUgd2UgZ29pbmcgYmFjayB0byBzcXVhcmUgb25lPw0KDQoNCj5N eSBwZXJzb25hbCBhbnN3ZXIgdG8gNC4gaXMgd2h5IG5vdD8NCg0KIkkgYW0gcGVzc2ltaXN0aWMg YWJvdXQgd2hhdCBZYWtvdiB3b3VsZCBzYXkgYWJvdXQgdGhpcyBpZGVhIDo9KSmhsSAoLi4uDQpl YXJsaWVyIGluIHRoaXMgZW1haWwgdGhyZWFkKQ0KDQoNCj5JdCBpcyBiaW5hcnkgYW5kIGhlbmNl IGFzIGZhc3QuIEkgaGFwcGVuIHRvIGxpa2UgdGhlIGdyYW51bGFyaXR5IGF0IHdoaWNoDQo+Rm9y Q0VTIHByb3RvY29sIGFsbG93cyBmb3IgaW5jcmVtZW50YWwgdXBkYXRlcyBhbmQgaG93IHRoZSBt ZXNzYWdlcyBjb3VsZA0KPmJlIGxpbWl0ZWQgYm90aCBpbiBzaXplIGFuZCBDUFUgcHJvY2Vzc2lu ZyB0byBqdXN0IHRoZSB2ZXJ5IHRoaW5ncyB0aGF0DQo+aGF2ZSBjaGFuZ2VkLg0KPg0KPlJlZ2Fy ZHMsDQo+SWdvcg0KPg0KDQpUaGFua3MsDQpKYW4NCg0K From nobody Mon Apr 21 09:58:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD91A0224 for ; Mon, 21 Apr 2014 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAsHelQ2HEU8 for ; Mon, 21 Apr 2014 09:58:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id B84BA1A0209 for ; Mon, 21 Apr 2014 09:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1339; q=dns/txt; s=iport; t=1398099513; x=1399309113; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IqZapRQJy9g/a+wGIGru+RnFq33L43v/lxr1auk92Dg=; b=iiqohCY3chsRmCDn99U7zWLEtDQoZjIsjkDGmosHgBGyvZNPAC4ZllaD Ekl983chCKeGK1jkwRUUPCI5SEnngGxaEHlwXkMl6Y6/krn6gjDwqZSOj movAPJ2uUqN8mwYjvWWvODFZeilS5LjwVpqMZBUiZPI6wOG+iw4FKJ6qf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFALFNVVOtJV2d/2dsb2JhbABZgwaBJsQOgSAWdIIlAQEBBDo/EAIBCBgeEDIlAgQBDQUUB4gmzgoXjmIHhDgBA5UAg26ST4Mxgis X-IronPort-AV: E=Sophos;i="4.97,897,1389744000"; d="scan'208";a="37498385" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 21 Apr 2014 16:58:32 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3LGwWHf017368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 16:58:32 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.11]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 11:58:31 -0500 From: "Jan Medved (jmedved)" To: Jamal Hadi Salim , Andy Bierman Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7Vxr+wwZfonk+Dg+mnlGSYCZsXmukAgAAepwCAAAu8AIAAeOGA//+5fwCAAHrngIAA/EeAgAAoDQCAAAXDgIAB6JUAgADTLACAABO/gIAABYSAgAADMYCAAAYeAIAAEJEAgAAEfQD//6jrgA== Date: Mon, 21 Apr 2014 16:58:30 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.27.7.169] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eu4nHqFX3VfnWT_a28qrzC-68D4 Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 16:58:42 -0000 Jamal, On 4/21/14, 8:10 AM, "Jamal Hadi Salim" wrote: >On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman wrote: >> >> I think Jan and others have explained why they think they can leverage >> the NC/RC/YANG technology to implement I2RS. There are tool >> and data model management requirements in addition to the protocol >> in order to have a workable solution. >> >> Unless the RIB data is one monolithic blob implemented without >> variation on every router, then issues such as modularity, conformance >> model, data lifecycle, distributed naming authority, data augmentation, >> and language extensibility are going to matter. >> > >So lets put all that in a requirement list somewhere and work around a gap >analysis. We have been discussing I2RS use cases and requirements for the past year or so. It is my understanding that at the last IETF there were two proposals presented that can meet the requirements: Forces and NC/RC/Y. The case has been made for each one of them - you made the case for Forces, and Andy and Dean made the case for NC/RC/Y. Now, Ed has asked the community to a vote for one of the two. Is my understanding correct or not? If my understanding is correct, why are we going back to square one? > >cheers, >Jamal Thanks, Jan From nobody Mon Apr 21 10:31:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519FA1A0224 for ; Mon, 21 Apr 2014 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xjuszg2LFJn for ; Mon, 21 Apr 2014 10:31:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 83E531A01FA for ; Mon, 21 Apr 2014 10:30:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 809A9C220; Mon, 21 Apr 2014 13:30:51 -0400 (EDT) Date: Mon, 21 Apr 2014 13:30:51 -0400 From: Jeffrey Haas To: Joe Marcus Clarke Message-ID: <20140421173051.GA2046@pfrc> References: <20140415000147.GA15705@pfrc> <534D37AF.1050901@cisco.com> <4F0DB516-2994-46A0-9BF7-1059C79BD8AE@juniper.net> <534D7F93.2090708@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534D7F93.2090708@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cUvkURmvP7bu6T3YWhi5ECtoLTM Cc: Jeffrey Haas , "" , Dean Bogdanovic , "" Subject: Re: [i2rs] Comments on draft-clarke-i2rs-traceability X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 17:31:09 -0000 On Tue, Apr 15, 2014 at 02:50:59PM -0400, Joe Marcus Clarke wrote: > On 4/15/14, 2:09 PM, Dean Bogdanovic wrote: > >Besides having the same comment as Jeff, here is one more and think some additional clarification is needed > > > >Actor Identifier: This is an opaque identifier that may be known to > > the Client from a northbound controlling application. This is > > used to trace the northbound actor driving the actions of the > > Client. The Client may not provide this identifier to the Agent > > if there is no external actor driving the Client. However, this > > field MUST be logged. If the Client does not provide an actor ID, > > then the Agent MUST log an empty field. > >I can see that Actor ID can be useful to report back to Client operator about rouge Actor. WRT logging Actor ID, when the Actor ID is not provided by Client, instead of logging an empty field, I would suggest to log UNKNOWN or NOT FOUND or NOT PROVIDED, as it is easier to search for a keyword then just empty field. > > Thanks, Dean. The searchability is a good point. Of the three you > propose, I think "NOT PROVIDED" is the only correct option. What do > others think? Admittedly, this might evolve into some kind of > enumeration where we might need values like "NOT PROVIDED" and > "UNKNOWN" to accommodate different states. Reserved values may be the appropriate answer, although they should be scarcely used since they suggest that the reserved name is unavailable in other portions of other systems. As we resolve the discussion about data model for this component, we might find that the data modeling language provides some help here. For example, a "string" component may permit arbitrary Actor Identifiers, while a type of "enueration" in the same field could have reserved components. This would of course depend on whether typed fields are even an option. -- Jeff From nobody Mon Apr 21 10:57:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867BB1A024E for ; Mon, 21 Apr 2014 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ars1kWtlewX for ; Mon, 21 Apr 2014 10:57:40 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC01A0242 for ; Mon, 21 Apr 2014 10:57:39 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s3LHvUkX011624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 13:57:30 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Apr 2014 13:57:30 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 21 Apr 2014 13:57:24 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.0847.030; Mon, 21 Apr 2014 13:57:24 -0400 From: Igor Bryskin To: "Jan Medved (jmedved)" , Jamal Hadi Salim , Dean Bogdanovic Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7GKQuFjKSvXU2c1OImmTGZdpsXiiYAgAAepgCAAIEVAIAAA4mAgAAu1oCAAAWPgIAAEnAAgAACOgCAANbOgIAAT+aAgAARsoCAAE2cAIAB5UIAgAAsEcaAAI75AP//v93o Date: Mon, 21 Apr 2014 17:57:23 +0000 Message-ID: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.98.165.184] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-21_03:2014-04-21,2014-04-21,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vrb65-tv6EYRgBHgN-_U0mtnrRI Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 17:57:45 -0000 Hi Jan,=0A= Please, see in line.=0A= Igor=0A= ________________________________________=0A= From: Jan Medved (jmedved) =0A= Sent: Monday, April 21, 2014 12:55 PM=0A= To: Igor Bryskin; Jamal Hadi Salim; Dean Bogdanovic=0A= Cc: i2rs@ietf.org; Joel M. Halpern; Edward Crabbe=0A= Subject: Re: [i2rs] consensus on I2RS protocol and model=0A= =0A= >Hi Jan,=0A= >=0A= >You said:=0A= >=0A= >" Both throughput and latency are meaningless from the standardization=0A= >point=0A= >of view - they both largely depend on the underlying system.=0A= >=0A= >Speaking for NC/Y implementations that I=B9ve been involved with, the=0A= >throughput of the Netconf Agent itself is much larger than the rest of the= =0A= >system, and its latency is negligible compared to the rest of the system.= =0A= >This happens to be true both for an embedded agent (XR), where ultimately= =0A= >both throughput and latency are determined by how fast you can program=0A= >hardware, and for the controller, where both throughput and latency depend= =0A= >on how fast you can shove things into a data store.=0A= >=0A= >Rather than focusing on devising a super fast binary encoding for the=0A= >protocol (which will speed up maybe 2-5% of the overall CPU cycles), we=0A= >need to have a self-describing schema-based message encoding which allows= =0A= >for creation of tools that generate most of the agent and client code.=0A= >NC/RC/Y gives us exactly that. The raw speed of the agent (optimized=0A= >protocol processing, message encoding, etc.) must be weighed against the= =0A= >ease and speed with which new APIs can be added to system - we have=0A= >Moore=B9s law for CPUs, but not for human brains ;-) We need to compensat= e=0A= >for that with tooling/automation."=0A= >=0A= >I have a couple of questions:=0A= >1. AFAIK we don't have yet a routing protocol whose speakers exchange XML= =0A= >encoded messages, why is that?=0A= =0A= I am not talking about routing protocols, but protocols that constitute=0A= =93APIs=94 into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, .= ..=0A= =0A= IB>> Were do you see routing or signaling protocols different? Why can't yo= u use for example Netconf/YANG for provisioning of TE paths?=0A= =0A= >2. Do you think we could replace BGP transport with Netconf RPCs? (I am=0A= >pessimistic about what Yakov would say about this idea :=3D))=0A= =0A= I am not suggesting that, although it=92s doable. In ODL we internally=0A= normalize protocol messages on yang-encoded NC RPCs and Notifications=0A= before putting them on an internal message bus. We defined yang models for= =0A= OF, PCEP and BGP messages. BGP, PCEP, OF, etc is used externally, though.= =0A= =0A= When running benchmarks & profiling, the normalization is barely a blip on= =0A= the radar=85 The advantage is that we present a uniform view of protocols t= o=0A= apps running in the controller and have bunch of tools that generate a=0A= lot of the app code that needs to interact with the respective protocol.=0A= It also allowed us to re-use not only code, but design patterns as well.=0A= =0A= IB>> Same question: why don't we replace signaling and routing protocols wi= th Netconf/YANG and have a universal tool for all network control needs? = =0A= =0A= >3. If I am to develop an i2rs client that can learn or generate route=0A= >updates at the speed and volume of a regular BGP speaker, can it, using= =0A= >Netconf, instal these updates in the i2rs agent's RIB in a timely manner?= =0A= =0A= As I said before, the protocol by which you learn the route updates is a=0A= small fraction of the overall CPU cycles. For a large scale deployment=0A= it=92s more about the right organization of data in the RIB for fast update= s=0A= and scale; after that it=92s about the speed at which you can install the= =0A= routes in hardware.=0A= =0A= IB>> But the WG like i2rs can only influence on the speed of the protocols,= not internal NE architecture and infrastructure as you keep referring to a= s well as the facts we have to take your word for.=0A= =0A= >What if i2rs client is twice as fast as the BGP speaker?=0A= =0A= I don=92t understand the question - how can an i2rs client interact with a= =0A= BGP Speker?=0A= =0A= IB>> I meant to say what if i2rs client can produce calls to RIB manager tw= ice as many as local BGP speaker.=0A= =0A= >What if there are two or more such i2rs clients talking to the same i2rs= =0A= >agent? Are these are reasonable use cases at all ?=0A= >4. Could we replace BGP transport with ForCES?=0A= >=0A= >5. Is it not possible that for some things i2rs will end up using=0A= >Netconf, while for others ForCES and/or something else?=0A= =0A= "That's foolish. You pick the one right tool.=94 (Anton Chigurh in No=0A= Country for Old Men)=0A= =0A= Why would we do that? Two sets of engineering rules, configurations, tool= =0A= chains, bugs=85 (My $0.02)=0A= =0A= IB>> Well, in the past we had a choice which IGP to use: OSPF or ISIS. The = decision was to let market to decide, and it turned out that both are well = deployed. Another example, we had to choose which signalling protocol to us= e for setting up TE paths. In this case we decided to choose one and ended = up with the RSVP-TE, arguably the worst possible choice we could make (at l= east in case of transport networks), discarding all other options in a very= early stage. =0A= =0A= >=0A= >=0A= >IMHO we can not give convincing answers for 3. and 5. until we see the=0A= >requirements agreed upon by all interesting parties. In this I totally=0A= >agree with Jamal.=0A= =0A= We have been discussing I2RS use cases and requirements for the past year= =0A= or so. It is my understanding that at the last IETF there were two=0A= proposals that can meet the requirements: Forces and NC/RC/Y. There have=0A= been cases made for each one of them - Andy and Dean made the case for=0A= NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community to= =0A= a vote for one of the two.=0A= =0A= Is my understanding correct or not? If my understanding is correct, why=0A= are we going back to square one?=0A= =0A= IB>> I don't think we have a satisfactorily protocol/model requirement docu= ment yet, which is a tightly defined an unambiguous enumeration of qualitat= ive and qualitative parameters of the protocol and model that are required,= desired, etc. for i2rs architecture to be successful (Take a look for a go= od example at MPLS-TP requirements RFC). We have to go to square one and w= rite such a document, I think=0A= =0A= Cheers,=0A= Igor=0A= From nobody Mon Apr 21 12:02:31 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427671A026F for ; Mon, 21 Apr 2014 12:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBhLTohsPDHT for ; Mon, 21 Apr 2014 12:02:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E197E1A026C for ; Mon, 21 Apr 2014 12:02:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A06E0C220; Mon, 21 Apr 2014 15:02:18 -0400 (EDT) Date: Mon, 21 Apr 2014 15:02:18 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140421190218.GB2046@pfrc> References: <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/69C9gSuvQJDgs5Xe4ZMUi6otfuc Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 19:02:28 -0000 On Mon, Apr 21, 2014 at 07:36:44AM -0400, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 1:46 AM, Jan Medved (jmedved) wrote: > > On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: > > > > Both throughput and latency are meaningless from the standardization point > > of view - they both largely depend on the underlying system. > > I am sorry, I disagree. Understanding latency and throughput needs is > fundamental. I agree - the understanding is required to help us decide whether the properties of a given data modeling language/protocol pairing satisfy our requirements. It may not be the primary deciding criterion but it will certainly be a big one given the high-throughput desires we have for I2RS. To use this as a jump-off point, what we need is a listing of such requirements and properties of a given data modeling language/protocol that realizes that perhaps better than another example. I'm still familiarizing myself with the IETF wiki and am unclear what sort of security permissions are present in it, but I'm happy to provide wiki space for these things to be enumerated. For the above item, there are various properties from the different mechanism that may be of benefit. (I'm still not through my protocol reading, so mistakes in characterization of a given protocol are all mine.) The binary encoding of FORCES may help with speed. It was asserted elsewhere (copied below) that this may only be 3-5% of a speed improvement. (I had thought I recalled a discussion in netmod(?) at one point of a BER format for YANG, but my google-fu is failing me.) A somewhat negative property of XML is that a document is only considered valid once you have the whole document. Thus, document size may matter. > Your focus in that case is provisioning. I2RS is not a CLI replacement. > It is not a provisioning system. If i am mistaken and it falls under > the auspicies > of either CLI replacement or provisioning - then by all means Netconf/Yang is > a clear selection and lets end the discussion. I've been working through the various I-Ds in detail. Using the BGP use case as an example, one of the desires may be to dynamically provision BGP peering sessions. Given that the I2RS cases are not strictly to provide the configuration of BGP but are likely a subset of this piece of configuration in an ephemeral context, this seems to suggest that the I2RS pieces of the system should ideally have good alignment with configuration systems. Thus, if YANG were used for provisioning BGP, there's a strong desire for there to be symmetry in the I2RS model - and thus potentially to share a portion of the YANG. The same observation would hold for a FORCES implementation of I2RS. Another example is the RIB. We want to leverage existing data models in a configuration context while also providing I2RS extensions for configuration, monitoring, etc. > Even if say a few tens/transactions per second is what the requirement says > then I would go with your approach. > > > Rather than focusing on devising a super fast binary encoding for the > > protocol (which will speed up maybe 2-5% of the overall CPU cycles), > > I'd like to argue your 2-5% (as i am sure papers which have been written on how > to speed up string processing will), but lets just ignore that for a sec: > Lets say your approach takes 1000 cycles. You can say only 2-5% of those cycles > are used for encoding/decoding ascii. That would be a correct statement to make. > What it is ignoring is: you are spending 1000 cycles instead of 50 for > the overall > computation. The other half of such a discussion tends to be around letting other consumers of the encoded information Do Something Useful with it. This does to some extent argue and influence what your programming model/API is. If your access to everything is always via strict API, binary encoding a great. But an (IMO) advantage of text-based systems is that it's pretty trivial to do a lot of things. I suspect I'm not the only one that uses text-based expansions of binary objects for various work. (And I'll also note that I leave things in binary format with API access when it makes sense.) What I'm really saying is that the ecosystem is likely to expand binary encoding to text just as much as it's going to move to a binary encoding. > >we > > need to have a self-describing schema-based message encoding which allows > > for creation of tools that generate most of the agent and client code. > > NC/RC/Y gives us exactly that. > > > > So does ForCES. BTW, Ive heard you repeat this statement above a few times > (as well as from Thomas); Would you say section 4.5.3 of RFC 5812 provides a good example of that? (Just to pick one from my reading.) > > And as I said earlier in this thread, about 80-90% of what I can think > > that we can do with I2RS (and it?s much, much more than just RIB > > programming ;-) ) can be addressed with NC/RC/Y today. > > > > Lets take that hammer and use it to fix everything we see on our way. Jamal, while the point is being made perhaps a bit less than pleasantly, there is certainly something there to discuss: The work Jan cites has a depth of models that cover many pieces of functionality similar to those that I2RS looks to address. They've done enough work against Yang/Netconf to have an idea of the remaining gaps. While I agree that within the limited scope of the FORCES documents that I've read that the modeling language and to a large extent the protocol can similarly address the problems, I haven't the depth to determine whether similar coverage of I2RS cases can be done within FORCES and what would need to change. It is also unclear aside from the binary encoding / more atomic transaction model (note, I haven't read restconf yet for proper comparison) that FORCES would bring vs. Yang/Netconf. That comparison is what the WG needs in somewhat greater depth than the existing gap analysis. -- Jeff From nobody Mon Apr 21 12:14:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DFD1A0257 for ; Mon, 21 Apr 2014 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9rIMwqGvOfe for ; Mon, 21 Apr 2014 12:14:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C94AD1A0251 for ; Mon, 21 Apr 2014 12:14:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CF375C220; Mon, 21 Apr 2014 15:13:59 -0400 (EDT) Date: Mon, 21 Apr 2014 15:13:59 -0400 From: Jeffrey Haas To: Igor Bryskin Message-ID: <20140421191359.GC2046@pfrc> References: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/stV3ZtOrKfsVm3ca9TUD8xzvt-0 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 19:14:06 -0000 On Mon, Apr 21, 2014 at 05:57:23PM +0000, Igor Bryskin wrote: > >I have a couple of questions: > >1. AFAIK we don't have yet a routing protocol whose speakers exchange XML > >encoded messages, why is that? > > I am not talking about routing protocols, but protocols that constitute > ?APIs? into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ... FWIW, L3VPN has draft-ietf-l3vpn-end-system using XMPP as a component. :-) > As I said before, the protocol by which you learn the route updates is a > small fraction of the overall CPU cycles. For a large scale deployment > it?s more about the right organization of data in the RIB for fast updates > and scale; after that it?s about the speed at which you can install the > routes in hardware. I tend to agree here. I've spent a fair amount of time analyzing the marshalling code in 3 different BGP implementations and while there is room to Do the Wrong Thing, most of the CPU is not spent in these paths. Where bigger mistakes tend to be is taking the information to be presented and deviating too greatly from the internal representation of that information. > >IMHO we can not give convincing answers for 3. and 5. until we see the > >requirements agreed upon by all interesting parties. In this I totally > >agree with Jamal. > > We have been discussing I2RS use cases and requirements for the past year > or so. It is my understanding that at the last IETF there were two > proposals that can meet the requirements: Forces and NC/RC/Y. There have > been cases made for each one of them - Andy and Dean made the case for > NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community to > a vote for one of the two. > > Is my understanding correct or not? If my understanding is correct, why > are we going back to square one? The request was really for two things: 1. Please look at the proposed mechanisms in DETAIL. We already know there are gaps and have been presented many of them by the experts in those mechanisms. Before the WG goes off and chooses something by popularity contest, we owe it to ourselves as engineers to understand the systems well enough to know what we're getting into. 2. By becoming familiar with the other system, we can see if there are properties we really like that would need to be added into the competing system. To give an arbitrary example, if binary encoding is really that helpful in the FORCES protocol, do we want something similar in Netconf/Restconf if we chose that one? If human-readable XML output is what we really want, are there gaps in the properties we get in Yang that FORCES would need? > IB>> I don't think we have a satisfactorily protocol/model requirement document yet, which is a tightly defined an unambiguous enumeration of qualitative and qualitative parameters of the protocol and model that are required, desired, etc. for i2rs architecture to be successful (Take a look for a good example at MPLS-TP requirements RFC). We have to go to square one and write such a document, I think Much of the motivation for this discussion was to help decide what should go in such a thing. We're not inventing something completely from scratch in I2RS, we have existing things we can pick from. If we know that something that exists doesn't satisfy all of the needs via either comparison or other means, the selected mechanism will need to evolve. And while inventing our own might be neat, I think the majority of people interested in I2RS related work would really just rather start writing code. -- Jeff From nobody Mon Apr 21 12:16:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59A51A0277 for ; Mon, 21 Apr 2014 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HQ3GMrOmRhb for ; Mon, 21 Apr 2014 12:16:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6E1A0272 for ; Mon, 21 Apr 2014 12:16:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B0385C220; Mon, 21 Apr 2014 15:16:14 -0400 (EDT) Date: Mon, 21 Apr 2014 15:16:14 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140421191614.GD2046@pfrc> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/WBxurQZdGsQGxZvpyCcvO-v3fNg Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 19:16:20 -0000 On Mon, Apr 21, 2014 at 07:51:08AM -0400, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 2:15 AM, Jan Medved (jmedved) wrote: > > Russ, > > > > On 4/19/14, 11:06 AM, "Russ White" wrote: > > > > > What you are asking for would be a lot of work for no practical purpose. > > Sigh. I thought there was some process that we needed to follow. > > Here's a proposition: > How about we settle to just an information model to begin with? > This is what approaches like openstack do. > You can use Yang. We'll use ours. You can use netconf/restconf and > we'll use whatever modification we need on ForCES. We both publish > our results after real code exists. Sue will have some document updates utilizing UML soon. ABNF/RBNF has proven to be insufficient for our purposes. My suggestion is to wait on her updates and provide feedback on whether the new format sufficiently addresses the concerns. -- Jeff From nobody Mon Apr 21 12:57:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9671A0276 for ; Mon, 21 Apr 2014 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0TuccRcqTrb for ; Mon, 21 Apr 2014 12:57:03 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id B40BF1A028E for ; Mon, 21 Apr 2014 12:57:02 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so2244900wiv.12 for ; Mon, 21 Apr 2014 12:56: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=yVE9FuY+c1IUimrUw4xR3sLYS8JsQQ4W2pwGsu5c+vg=; b=CVzI3oTDCq/otlYGALL2QLwOez8nl9sumD4y2bXsLhJHfxXoKZUf/063W/pzuz7afA j6nBcxSIlr5GC0AASq5j9cnBCC7Ua8SN7EJl8ZthB/tioHYzK6v5He5F+sWS0LJkHZTr TYnnLDGGyFYOGXCUXV/s8zjKco24s6ApUfO+u2OJ1Rgf5TXJMNBVahy9iEdtfr8gvu+r onVqAMxKLmplst87IhudEoFsfPgL4mFlXxELAENHn7YMCK2Agowauevd2ov878mOQspT KL+zEIe5aDLOkOaB+rQ4SMeUbfBruAvXr14iH+28c4KfspG8hQK5hXZIqIJXjMU+XFrN o53w== 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:cc:content-type; bh=yVE9FuY+c1IUimrUw4xR3sLYS8JsQQ4W2pwGsu5c+vg=; b=GfLPYdA1D5fZzz6nDDQDJivNkt8ccHKtRd6shhfWwDSS/qpB+TU5lsep5/Fa5bQYUl VJNSQ/hpwsdBWJJn7qz4ewO4R8K0IKaB0aWlfe+u/cMfs9Vei573blDH4BxkclHdbxGa YknlIcFHUsVidvaijWoKlvMHAALCXxYSPN+dGYwTn/dCE1z471lCFNw93l5XP/2LZOx5 ayegAeVafelhSZW4BlPbhN4YJ7CcOuXL0w9zsoWwN+r3CM2jfFssRZMw42wFfPtV+agq /BpOza5RHpf6VMewsvp3ZZy1tHW60qWNvHmmomUEVHFNoh1aGE3m/glSskpOHVkSUMdy onUw== X-Gm-Message-State: ALoCoQkWRIPOUT7e9+dd0Ai7bbr248YpRvy+taJp+h0gyOfmAWktC2jovNwAOcRyXc8z8GO4CZsCDynhz/uWHga9M4DykIABe+MEQ150sRLQMYvRgpDATOIFzQSEX2WZfuUzvt6fuyTJ5xCV4kSz/paGSAKVzQewGR4kT8W3Sn+WLykvr2LuIAUtsMOqmb6KCw1/AkNeDXe4 X-Received: by 10.194.24.194 with SMTP id w2mr30208214wjf.25.1398110217131; Mon, 21 Apr 2014 12:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.66 with HTTP; Mon, 21 Apr 2014 12:56:17 -0700 (PDT) In-Reply-To: <20140421191359.GC2046@pfrc> References: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <4d977c6004ac474294428716b426f80d@ATL-SRV-MBX1.advaoptical.com> <20140421191359.GC2046@pfrc> From: Edward Crabbe Date: Mon, 21 Apr 2014 12:56:17 -0700 Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7b450c56d982fc04f792e64d Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uT43atjDWkBLnv-IVRVBcFS7bzk Cc: "i2rs@ietf.org" , Jamal Hadi Salim , Igor Bryskin , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 19:57:08 -0000 --047d7b450c56d982fc04f792e64d Content-Type: text/plain; charset=ISO-8859-1 Jeff; +1 ^_^ This was originally the reason Jeff and I asked for a two week period during which people could familiarize themselves more thoroughly with both protocols. From both my reading and advice/explanation from protocol experts, both NetCONF/YANG and ForCES are entirely capable (with some minor modifications) of performing the duties required by I2RS (from both modeling and communications perspectives). Supporting via +1 is fine (preferably with someone is echoing a previously espoused argument set). There is obviously a component of ease of use and expedience in the protocol selection process here, especially given the fact that both protocols seem to meet our specific needs without too many contortions, but the point of this discussion is to pinpoint any deficiencies in the (other-guy's ?) protocol that we may have missed in review thus far, aka the /gap analyses/ that Jeff and I have referred to. Looking forward to hearing some more substantive debate here, and glad to see it's started in the last 10 messages or so. cheers, -ed On Mon, Apr 21, 2014 at 12:13 PM, Jeffrey Haas wrote: > On Mon, Apr 21, 2014 at 05:57:23PM +0000, Igor Bryskin wrote: > > >I have a couple of questions: > > >1. AFAIK we don't have yet a routing protocol whose speakers exchange > XML > > >encoded messages, why is that? > > > > I am not talking about routing protocols, but protocols that constitute > > ?APIs? into the system. Such protocols are NC/RC/Y, Forces, OF, PCEP, ... > > FWIW, L3VPN has draft-ietf-l3vpn-end-system using XMPP as a component. :-) > > > As I said before, the protocol by which you learn the route updates is a > > small fraction of the overall CPU cycles. For a large scale deployment > > it?s more about the right organization of data in the RIB for fast > updates > > and scale; after that it?s about the speed at which you can install the > > routes in hardware. > > I tend to agree here. I've spent a fair amount of time analyzing the > marshalling code in 3 different BGP implementations and while there is room > to Do the Wrong Thing, most of the CPU is not spent in these paths. > > Where bigger mistakes tend to be is taking the information to be presented > and deviating too greatly from the internal representation of that > information. > > > >IMHO we can not give convincing answers for 3. and 5. until we see the > > >requirements agreed upon by all interesting parties. In this I totally > > >agree with Jamal. > > > > We have been discussing I2RS use cases and requirements for the past year > > or so. It is my understanding that at the last IETF there were two > > proposals that can meet the requirements: Forces and NC/RC/Y. There have > > been cases made for each one of them - Andy and Dean made the case for > > NC/RC/Y, and Jamal made the case for Forces. Ed has asked the community > to > > a vote for one of the two. > > > > Is my understanding correct or not? If my understanding is correct, why > > are we going back to square one? > > The request was really for two things: > 1. Please look at the proposed mechanisms in DETAIL. We already know there > are gaps and have been presented many of them by the experts in those > mechanisms. Before the WG goes off and chooses something by popularity > contest, we owe it to ourselves as engineers to understand the systems well > enough to know what we're getting into. > > 2. By becoming familiar with the other system, we can see if there are > properties we really like that would need to be added into the competing > system. To give an arbitrary example, if binary encoding is really that > helpful in the FORCES protocol, do we want something similar in > Netconf/Restconf if we chose that one? If human-readable XML output is > what > we really want, are there gaps in the properties we get in Yang that FORCES > would need? > > > IB>> I don't think we have a satisfactorily protocol/model requirement > document yet, which is a tightly defined an unambiguous enumeration of > qualitative and qualitative parameters of the protocol and model that are > required, desired, etc. for i2rs architecture to be successful (Take a look > for a good example at MPLS-TP requirements RFC). We have to go to square > one and write such a document, I think > > Much of the motivation for this discussion was to help decide what should > go > in such a thing. We're not inventing something completely from scratch in > I2RS, we have existing things we can pick from. If we know that something > that exists doesn't satisfy all of the needs via either comparison or other > means, the selected mechanism will need to evolve. > > And while inventing our own might be neat, I think the majority of people > interested in I2RS related work would really just rather start writing > code. > > -- Jeff > --047d7b450c56d982fc04f792e64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jeff;

+1 =A0 =A0^_^=A0

This was originally the reason Jeff and I asked for a two week per= iod during which people could familiarize themselves more thoroughly with b= oth protocols. =A0From both my reading and advice/explanation from protocol= experts, both NetCONF/YANG and ForCES are entirely capable (with some mino= r modifications) of performing the duties required by I2RS (from both model= ing and communications perspectives). =A0

Supporting via +1 is fine (preferably with someone is e= choing a previously espoused argument set). =A0There is obviously a compone= nt of ease of use and expedience in the protocol selection process here, es= pecially given the fact that both protocols seem to meet our specific needs= without too many contortions, =A0but the point of this discussion is to pi= npoint any deficiencies in the (other-guy's ?) protocol that we may hav= e missed in review thus far, aka the /gap analyses/ =A0that Jeff and I have= referred to. =A0

Looking forward to hearing some more substantive debate= here, and glad to see it's started in the last 10 messages or so.=A0

cheers,
=A0 =A0-ed =A0

=A0=A0 =A0=A0




On Mon, Apr 21, 2014 at 12:13 PM,= Jeffrey Haas <jhaas@pfrc.org> wrote:
On Mon, Apr 21, 2014 at 05:5= 7:23PM +0000, Igor Bryskin wrote:
> >I have a couple of questions:
> >1. AFAIK we don't have yet a routing protocol whose speakers e= xchange XML
> >encoded messages, why is that?
>
> I am not talking about routing protocols, but protocols that constitut= e
> ?APIs? into the system. Such protocols are NC/RC/Y, Forces, OF, = PCEP, ...

FWIW, L3VPN has draft-ietf-l3vpn-end-system using XMPP as a component. :-)<= br>

> As I said before, the protocol by which you learn the route updates is= a
> small fraction of the overall CPU cycles. For a large scale deployment=
> it?s more about the right organization of data in the RIB for fa= st updates
> and scale; after that it?s about the speed at which you can install th= e
> routes in hardware.

I tend to agree here. =A0I've spent a fair amount of time analyzing the=
marshalling code in 3 different BGP implementations and while there is room=
to Do the Wrong Thing, most of the CPU is not spent in these paths.

Where bigger mistakes tend to be is taking the information to be presented<= br> and deviating too greatly from the internal representation of that
information.

> >IMHO we can not give convincing answers for 3. and 5. until we see= the
> >requirements agreed upon by all interesting parties. In this I tot= ally
> >agree with Jamal.
>
> We have been discussing I2RS use cases and requirements for the past y= ear
> or so. It is my understanding that at the last IETF there were two
> proposals that can meet the requirements: Forces and NC/RC/Y. There ha= ve
> been cases made for each one of them - Andy and Dean made the case for=
> NC/RC/Y, and Jamal made the case for Forces. Ed has asked the communit= y to
> a vote for one of the two.
>
> Is my understanding correct or not? If my understanding is correct, wh= y
> are we going back to square one?

The request was really for two things:
1. Please look at the proposed mechanisms in DETAIL. =A0We already know the= re
are gaps and have been presented many of them by the experts in those
mechanisms. =A0Before the WG goes off and chooses something by popularity contest, we owe it to ourselves as engineers to understand the systems well=
enough to know what we're getting into.

2. By becoming familiar with the other system, we can see if there are
properties we really like that would need to be added into the competing system. =A0To give an arbitrary example, if binary encoding is really that<= br> helpful in the FORCES protocol, do we want something similar in
Netconf/Restconf if we chose that one? =A0If human-readable XML output is w= hat
we really want, are there gaps in the properties we get in Yang that FORCES=
would need?

> IB>> I don't think we have a satisfactorily protocol/model r= equirement document yet, which is a tightly defined an unambiguous enumerat= ion of qualitative and qualitative parameters of the protocol and model tha= t are required, desired, etc. for i2rs architecture to be successful (Take = a look for a good =A0example at MPLS-TP requirements RFC). We have to go to= square one and write such a document, I think

Much of the motivation for this discussion was to help decide what sh= ould go
in such a thing. =A0We're not inventing something completely from scrat= ch in
I2RS, we have existing things we can pick from. =A0If we know that somethin= g
that exists doesn't satisfy all of the needs via either comparison or o= ther
means, the selected mechanism will need to evolve.

And while inventing our own might be neat, I think the majority of people interested in I2RS related work would really just rather start writing code= .

-- Jeff

--047d7b450c56d982fc04f792e64d-- From nobody Mon Apr 21 13:02:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1225E1A028D for ; Mon, 21 Apr 2014 13:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQz5vhsVCqZ2 for ; Mon, 21 Apr 2014 13:02:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6942A1A0277 for ; Mon, 21 Apr 2014 13:02:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 58A6FC220; Mon, 21 Apr 2014 16:02:02 -0400 (EDT) Date: Mon, 21 Apr 2014 16:02:02 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140421200202.GE2046@pfrc> References: <008201cf5b5b$5ca25dd0$15e71970$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008201cf5b5b$5ca25dd0$15e71970$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/avvyNW03ugVuJBzO1HBN_S1-dH0 Cc: i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 20:02:09 -0000 On Fri, Apr 18, 2014 at 07:10:16PM -0400, Susan Hares wrote: > The assumption: > > I am assuming that the information models are not a waste of time. Jeff > Haas' comment was isn't having information models and data models a > duplication of effort. > > First of all, RBNF and ABNF seem to be causing redundant issues in the > draft-ietf-i2rs-rib-info-model-02 draft. > > The ABNF the delightful work in > > draft-clarke-i2rs-traceability-01 really difficult to follow. > > My assumption had been the following train would occur: > > UML graphic (readable) > || > VV (someday via tool) > UML text (readable) > || (via tools - I've already found some) > || > VV > > Yang/Forces Data Model (Yang readable/Forces:Readable) FWIW, UML can do much of this but even some of the best authors on it note that it can be a bit more art than science in some cases. Since our models to this point have been relatively simple I suspect that this train may actually work. > For validation of the code in the router > > Code > > || (tools creates) > > XML > > || (tool creates) > > Yang/Forces Data model > > || (tool creates) I suspect this is effectively where the tool chain would traditionally stop. You've de-marshalled the intermediate form into something that recognizes the structured data and can dump it directly into your code. You might have: > UML syntax UML in the middle to absorb it, but my suspicion is that a lot of existing tools would prefer to either work on XML documents due to the related tools like XPath. > So.. font of wisdom from on high, can you let me know if I have > misunderstood the point for information models and data models. Just to clarify my own point for the list, my concern was mostly that a sufficiently useful data modeling language obviates much of what the info model gives us: Structure of the information and general typing. What something like UML gives us that isn't necessarily a property of those data modeling languages is the inter-relationship of objects. UML is pretty good at that. My only concern about graphical UML, having done a few pretty pictures for similar info systems is that they get *big*, and splitting those across the IETF-publishable formats may be messy. -- Jeff From nobody Mon Apr 21 13:04:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F621A0279 for ; Mon, 21 Apr 2014 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lfaMjiOi5GH for ; Mon, 21 Apr 2014 13:04:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id BC19C1A0277 for ; Mon, 21 Apr 2014 13:04:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5D98A81; Mon, 21 Apr 2014 22:04:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fdflNwidDXwE; Mon, 21 Apr 2014 22:04:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Apr 2014 22:04:07 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 155B620017; Mon, 21 Apr 2014 22:04:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U8pTBmeWyb5v; Mon, 21 Apr 2014 22:04:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3D1E20013; Mon, 21 Apr 2014 22:04:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9FA6D2C92055; Mon, 21 Apr 2014 22:04:04 +0200 (CEST) Date: Mon, 21 Apr 2014 22:04:04 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140421200404.GA9609@elstar.local> Mail-Followup-To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved (jmedved)" , Dean Bogdanovic , Edward Crabbe References: <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <20140421190218.GB2046@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140421190218.GB2046@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GiRyJTUzocZcjxERL6zwfROTUzI Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 21 Apr 2014 20:04:18 -0000 On Mon, Apr 21, 2014 at 03:02:18PM -0400, Jeffrey Haas wrote: > > The binary encoding of FORCES may help with speed. > It was asserted elsewhere (copied below) that this may only be 3-5% of a > speed improvement. (I had thought I recalled a discussion in netmod(?) at > one point of a BER format for YANG, but my google-fu is failing me.) > As long as you do crypto in software, the outcome of the binary vs. textual data encoding discussion likely does not matter much. Note that for NC all standards-track transports do authentication and encryption above the transport layer (via SSH or optionally TLS). For RC it is likely going to be TLS. For ForCES, it seems RFC 5811 (ForCES over SCTP) requires IPsec in transport mode plus IKE. Perhaps all boxes that are targets for I2RS can be assumed to have hardware crypto and hence this is a non-issue. But I think it is important to keep the bigger picture in mind when we talk about performance (and I assume I2RS will not pass through the IESG with a plaintext transport mode). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Apr 21 13:12:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752821A02B6 for ; Mon, 21 Apr 2014 13:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beBSuXFcMf2n for ; Mon, 21 Apr 2014 13:12:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 229631A02A6 for ; Mon, 21 Apr 2014 13:11:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 23264C220; Mon, 21 Apr 2014 16:11:33 -0400 (EDT) Date: Mon, 21 Apr 2014 16:11:33 -0400 From: Jeffrey Haas To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved (jmedved)" , Dean Bogdanovic , Edward Crabbe Message-ID: <20140421201133.GC8955@pfrc> References: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <20140421190218.GB2046@pfrc> <20140421200404.GA9609@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140421200404.GA9609@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/12dSe6GdtU0Rj3zVqdWyjY278XM Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 20:12:27 -0000 Juergen, On Mon, Apr 21, 2014 at 10:04:04PM +0200, Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2014 at 03:02:18PM -0400, Jeffrey Haas wrote: > > The binary encoding of FORCES may help with speed. > > It was asserted elsewhere (copied below) that this may only be 3-5% of a > > speed improvement. (I had thought I recalled a discussion in netmod(?) at > > one point of a BER format for YANG, but my google-fu is failing me.) > [...] > Perhaps all boxes that are targets for I2RS can be assumed to have > hardware crypto and hence this is a non-issue. But I think it is > important to keep the bigger picture in mind when we talk about > performance (and I assume I2RS will not pass through the IESG with a > plaintext transport mode). Not speaking for the chairs, I'd hope the WG would consider this blatantly against what we're hoping to do. The goal of the WG is to help make routing system information more available. Requiring new hardware to implement our proposals goes counter to that idea, IMO. :-) -- Jeff From nobody Mon Apr 21 14:44:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0B61A02A9 for ; Mon, 21 Apr 2014 14:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24MaQI1boyQ for ; Mon, 21 Apr 2014 14:44:34 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by ietfa.amsl.com (Postfix) with ESMTP id E57FE1A028A for ; Mon, 21 Apr 2014 14:44:33 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id f51so2651362qge.10 for ; Mon, 21 Apr 2014 14:44:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W6dG30rTJmUTM61ou4Mr5+67Wadza+4RP8w8BZHMGZE=; b=gCzuqo59xwY2adffbdTVwuD2zh3zq7vuUlHJ1FP8wugqr+4coNTTp0+E5r4+E1YYmy Doo51A+YqprhkE7LG/bAxSGRZw92DmXbGvEF+acQXoPSl8hc28wKlBHHt7tYwpPsx1Rg t+C94n5mPZCsCiL9uvwRypRo7Bo2EMEPCktUjCkohpwNXfs0yRYUteI/uaHsTgpkg9CR 7N2n30cKfWOFnOO4tA24ZJiCJKCqMLcimqhd0I7SM6i+bVx+F+5qeqH3/2jnKqrCcbDg pCrguKIZwsp2A17mdD6O7STsdA9mN00Ta0BzM7P9CsKupU1l0NCzcDgqNgG6lmfDgC1L CBLg== X-Gm-Message-State: ALoCoQkteCGtQEZvvcxY1v+q63zn7lLtBDYT/os3udiCeY/KSA6ZTmtD2fmpE3F1D6om9mUwE72t MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr7480220qad.88.1398116668641; Mon, 21 Apr 2014 14:44:28 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 14:44:28 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> Date: Mon, 21 Apr 2014 14:44:28 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0158a9e463aee604f79467e8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NvqAZ1b9Me6anbemCtQuc6H05EU Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 21:44:38 -0000 --089e0158a9e463aee604f79467e8 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman wrote: > > > > I think Jan and others have explained why they think they can leverage > > the NC/RC/YANG technology to implement I2RS. There are tool > > and data model management requirements in addition to the protocol > > in order to have a workable solution. > > > > Unless the RIB data is one monolithic blob implemented without > > variation on every router, then issues such as modularity, conformance > > model, data lifecycle, distributed naming authority, data augmentation, > > and language extensibility are going to matter. > > > > So lets put all that in a requirement list somewhere and work around a gap > analysis. > > So how does ForCES support these things? Where is the language specification in RFC 5812? Section 4 describes LFB classes, which appear to represent the only supported data for the protocol. Is the entire normative language specification contained in the XSD in sec. 4.9? What happens if multiple elements pull in definitions with the same local name? The examples do not show any use of prefixes and the element has no prefix mapping. There does not appear to be any conformance information like what is mandatory or conditional on a user-defined feature. How are logical groups of conditional objects defined and advertised in the protocol? (e.g., YANG features) Are there examples of the augmentation described in sec. 4.5.7? There does not appear to be any way for 1 module to add elements to another without controlling the naming for all modules. How does a vendor implement the unique naming requirements in ForCES without controlling the names of all possible ForCES files? Are they supposed to rewrite modules when a naming collision occurs because modules X and Y are being loaded into module Z, which causes a new naming collision that did not occur before? YANG supports groupings that can be refined in each use/expansion. How are complex statements reused and refined? Where are examples of that in the RFC? How would I2RS use ? ipv4 IPv4 packet This frame type refers to an IPv4 packet. ipv6 IPv6 packet This frame type refers to an IPv6 packet. ... Is this like a YANG identity statement, except this causes naming collisions, so it is more like a specialized distributed enumeration type? To compare readability, here are the same type definitions in ForCES and YANG: ForCES: (RFC 5812, pg. 80) accessPermissionValues The possible values of component access permission uchar None Access is prohibited Read-Only Access to the component is read only Write-Only The component MAY be written, but not read Read-Write The component MAY be read or written YANG: typedef accessPermissionValues { description "The possible values of component access permission"; type enumeration { enum None { value 0; description "Access is prohibited"; } enum Read-Only { value 1; description "Access to the component is read only"; } enum Write-Only { value 2; description "The component MAY be written, but not read"; } enum Read-Write { value 3; description "The component MAY be read or written"; } } } How are new protocol operations defined? Are they part of the language. How are language extensions done? This does not appear to be supported. How are existence constraints between objects expressed? (e.g., must/when/unique) How does a vendor add arbitrary data to notification events? Can event definitions be augmented? If so, how is this done so nodes can be conditional? (e.g., if-feature, when) The element is one of many that seems very ForCES specific. How are new events added? I don't see an event definition for the "Goof1changed" example: Goof1changed An example event for a complex structure goo f1 goo f1 I am still confused about the general applicability. E.g., how are , used in I2RS? > cheers, > jamal > Andy --089e0158a9e463aee604f79467e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <hadi@mojatat= u.com> wrote:
On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> I think Jan and others have explained why they think they can leverage=
> the NC/RC/YANG technology to implement I2RS. There are tool
> and data model management requirements in addition to the protocol
> in order to have a workable solution.
>
> Unless the RIB data is one monolithic blob implemented without
> variation on every router, then issues such as modularity, conformance=
> model, data lifecycle, distributed naming authority, data augmentation= ,
> and language extensibility are going to matter.
>

So lets put all that in a requirement list somewhere and work around a gap<= br> analysis.


So how does ForCES support these thing= s?
Where is the language specification in RFC 5812?
Section 4 describes LFB classes, which appear to represent the only suppo= rted data
for the protocol. Is the entire normative language specification conta= ined in the XSD in sec. 4.9?

What happe= ns if multiple <load> elements pull in definitions with the
same local name? =A0The examples do not show any use of prefixes
=
and the <load> element has no prefix mapping.

   <load library=3D"a_library"/>
   <load library=3D"another_library" location=3D"another_=
lib.xml"/>
   <load library=3D"yetanother_library"
    location=3D"http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/><=
/pre>

There does not appear to be any confor= mance information like what is
mandatory or conditional on a user-defined feature. How are logical gr= oups
of conditional objects defined and advertised in the protoco= l? (e.g., YANG features)

Are there examples of the= augmentation described in sec. 4.5.7?
There does not appear to be any way for 1 module to add elements to an= other
<dataTypeDef> without controlling the naming for all = modules.

How does a vendor implement the unique na= ming requirements in ForCES
without controlling the names of all possible ForCES files? =A0Are the= y supposed to
rewrite modules when a naming collision occurs beca= use modules X and Y are being loaded
into module Z, which causes = a new naming collision that did not occur before?

YANG supports groupings that can be refined in each use= /expansion.
How are complex <dataTypeDef> statements reused= and refined?
Where are examples of that in the RFC?



How would I2RS use <frameDe= fs>?

    <frameDefs>
     <frameDef>
      <name>ipv4</name>
      <synopsis>IPv4 packet</synopsis>
      <description>
       This frame type refers to an IPv4 packet.
     </description>
    </frameDef>
     <frameDef>
     <name>ipv6</name>
     <synopsis>IPv6 packet</synopsis>
     <description>
       This frame type refers to an IPv6 packet.
     </description>
    </frameDef>
     ...
   </frameDefs>

Is this like a YANG identity statement, except th= is causes naming collisions,
so it is more like a specialized dis= tributed enumeration type?


To compare readability, here are the same type definit= ions in ForCES and YANG:

ForCES: (RFC 5812, pg. 80= )

              <dataTypeDef>
                  <name>accessPermissionValues</name>
                  <synopsis>
                    The possible values of component access permission
                  </synopsis>
                  <atomic>
                    <baseType>uchar</baseType>
                    <specialValues>
                      <specialValue value=3D"0">
                        <name>None</name>
                        <synopsis>Access is prohibited</synopsis&g=
t;
                      </specialValue>
                       <specialValue value=3D"1">
                        <name> Read-Only </name>
                        <synopsis>
                          Access to the component is read only
                        </synopsis>
                      </specialValue>
                      <specialValue value=3D"2">
                        <name>Write-Only</name>
                        <synopsis>
                          The component MAY be written, but not read
                        </synopsis>
                      </specialValue>
                      <specialValue value=3D"3">
                        <name>Read-Write</name>
                        <synopsis>
                          The component MAY be read or written
                        </synopsis>
                      </specialValue>
                    </specialValues>
                  </atomic>
                </dataTypeDef>

YANG:

    typedef accessPermis=
sionValues {
      description=A0
        "The possible values of component=
 access permission";
           t=
ype enumeration {
             enum None {
  =
              value 0;
            =
    description "Access is prohibited";
            =
 }
             enum Read-Only {=

                value 1;
                des=
cription "Acces=
s to the component is read only";


             }
             enum Write-Only {<=
/span>


                value 2;
                description=
 "The component=
 MAY be written, but not read";


             }
             enum Read-Write =
{
                value 3;
                des=
cription "The c=
omponent MAY be read or written";


             }
           }


        }

=


How are new protocol operations defined? Are they part of the language.


How are language extensions done? Thi= s does not appear to be supported.

How are existence constraints between objects expressed= ? (e.g., must/when/unique)

How does a vendor add a= rbitrary data to notification events?
Can event definitions be au= gmented?
If so, how is this done so nodes can be conditional? (e.g., if-feature= , when)

The <eventCondition> element is one = of many that seems very ForCES specific.
How are new events added= ?

I don't see an event definition for the "Goof1= changed" example:


    </xsd:complexType>
      <!-- the substitution group for the event conditions -->
      <xsd:element name=3D"eventCondition" abstract=3D"tr=
ue"/>
      <xsd:element name=3D"eventCreated"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventDeleted"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventChanged"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventGreaterThan"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventLessThan"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:complexType name=3D"eventPathType">
        <xsd:sequence>
          <xsd:element ref=3D"eventPathPart" maxOccurs=3D"=
;unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
      <!-- the substitution group for the event path parts -->
      <xsd:element name=3D"eventPathPart" type=3D"xsd:str=
ing"
                   abstract=3D"true"/>
      <xsd:element name=3D"eventField" type=3D"xsd:string=
"
                   substitutionGroup=3D"eventPathPart"/>
      <xsd:element name=3D"eventSubscript" type=3D"xsd:st=
ring"
                   substitutionGroup=3D"eventPathPart"/>
      <xsd:complexType name=3D"eventReportsType">
        <xsd:sequence>
          <xsd:element name=3D"eventReport" type=3D"event=
PathType"
                       maxOccurs=3D"unbounded"/>
        </xsd:sequence>
      </xsd:complexType>

<event eventID=3D"8"> <name>Goof1changed</name> <synopsis> An example event for a complex structure </synopsis> <eventTarget> <!-- target is goo.f1 --> <eventField>goo</eventField> <eventField>f1</eventField> </eventTarget> <eventChanged/> <eventReports> <!-- report the new state of goo.f1 --> <eventReport> <eventField>goo</eventField> <eventField>f1</eventField> </eventReport> </eventReports> </event>

I am still confused about the <metadataD= efs> general applicability.
E.g., how are <inputPorts>, = <outputPorts> used in I2RS?

=A0
cheers,
jamal


Andy

--089e0158a9e463aee604f79467e8-- From nobody Mon Apr 21 15:20:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AB31A02D3 for ; Mon, 21 Apr 2014 15:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z1Awk9_cvgu for ; Mon, 21 Apr 2014 15:20:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7B91A02B8 for ; Mon, 21 Apr 2014 15:20:05 -0700 (PDT) Received: from [172.20.10.3] (232.sub-174-229-75.myvzw.com [174.229.75.232]) by lucidvision.com (Postfix) with ESMTP id 5A27A2772E17; Mon, 21 Apr 2014 18:19:54 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Mon, 21 Apr 2014 17:18:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> To: "Jan Medved (jmedved)" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3867BclyBaTE5yr7PWQT5KrZ7Zk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Edward Crabbe , Dean Bogdanovic , Jamal Hadi Salim Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 22:20:13 -0000 > On Apr 21, 2014, at 12:46 AM, "Jan Medved (jmedved)" w= rote: >=20 >=20 >=20 >> On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: >>=20 >> On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic >> wrote: >>=20 >>=20 >>> It comes down how many transactions are required? Will you updated 1000 >>> routes in single transaction or in 1000 transactions. >>=20 >> Take your pick. The point is it boils down to how that is modelled and >> carried >> over the wire (and influences those decisions). >>=20 >>> =46rom my perspective there are two important metrics for i2rs >>> throughput >>> and >>> latency >>=20 >> Now we are talking. >>=20 >>>=20 >>> IMO, I2RS agent has to provide as high as possible throughput and add >>> minimal latency to the >process. What is the throughput required? Don't >>> know at the moment. I saw some request in high >single digit thousands >>> per second, but not sure about use cases. On the latency side, you want >>> it as >close to 0 as possible, but that will be highly platform >>> dependent. >>=20 >> Agreed. >=20 > Both throughput and latency are meaningless from the standardization point= > of view - they both largely depend on the underlying system. >=20 > Speaking for NC/Y implementations that I=C2=B9ve been involved with, the > throughput of the Netconf Agent itself is much larger than the rest of the= > system, and its latency is negligible compared to the rest of the system. > This happens to be true both for an embedded agent (XR), where ultimately > both throughput and latency are determined by how fast you can program > hardware, and for the controller, where both throughput and latency depend= > on how fast you can shove things into a data store. >=20 > Rather than focusing on devising a super fast binary encoding for the > protocol (which will speed up maybe 2-5% of the overall CPU cycles), we > need to have a self-describing schema-based message encoding which allows > for creation of tools that generate most of the agent and client code. > NC/RC/Y gives us exactly that. The raw speed of the agent (optimized > protocol processing, message encoding, etc.) must be weighed against the > ease and speed with which new APIs can be added to system - we have > Moore=C2=B9s law for CPUs, but not for human brains ;-) We need to compen= sate > for that with tooling/automation. This is the right approach. The speed up vs pita factor for binary encoding i= sn't worth it. And as you say, the CPU performance is so fast even today tha= t it's not an issue. >=20 >=20 >>=20 >>> I have to start doing some PoCs to see what can and can not do with >>> existing tools. If those tools >work, then good. If those tools don't >>> work, then back to the drawing board. Until things work, keep on >moving= >>> with what works and try to find break points. >>=20 >> But i do believe there are limitations which are not obvious without >> contrasting against requirements. >>=20 >>> You can add your comments to the existing drafts. >>=20 >> I would gladly do - but i worry whether the discussion is about crowning >> some >> solution instead of meeting such objectives; if the WG decides to move >> in that >> direction i would be happy to contribute. >> There's material floating, the old protocol draft; Joel pointed to the >> architecture >> draft covering model requirements. Andy mentioned possible "stretch" >> requirements. I think what would be appropriate is one draft for the mode= l >> and one for the protocol with gap analysis. >>=20 >>>>=20 >>>> Unfortunately - we are not having that kind of useful discussion and i >>>> feel like a broken >>>> record asking for requirements. >>>=20 >>> I believe we have a set of requirements. It is in >>> draft-rfernando-i2rs-protocol-requirements. >>> You can always comment that draft and argue pro and con each requirement= . >>=20 >> Glad we are bringing that draft into play;-> How does restconf fair >> against it? >=20 > Reasonably well. When we evaluated restconf against these requirements (I > am a co-author), the major deficiency found was lack of notifications in > restconf, which was addressed in a subsequent restconf revision. There are= > still things that would have to be added (for example, client identities),= > but this can be addressed either in the protocol or in models. There is > nothing *structural* in restconf that would prevent it from satisfying the= > requirements set.=20 >=20 > And as I said earlier in this thread, about 80-90% of what I can think > that we can do with I2RS (and it=C2=B9s much, much more than just RIB > programming ;-) ) can be addressed with NC/RC/Y today. I agree. I've always viewed what needs to be done as more or less a subset o= f what's in netconf today. Tom >=20 >=20 >=20 >> Note: The draft is a good starting point but is missing as an example >> the issue of >> latency and throughput. >>=20 >> cheers, >> jamal >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Mon Apr 21 15:22:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC591A02D3 for ; Mon, 21 Apr 2014 15:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDkFyq4VrLdS for ; Mon, 21 Apr 2014 15:22:00 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id A52451A02B8 for ; Mon, 21 Apr 2014 15:22:00 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id ih12so291444qab.11 for ; Mon, 21 Apr 2014 15:21:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fk/OleeL/yL5dnZhu/XhiHBFWXfKI6Fv+Vix2g5WaZw=; b=AyEadf/PzisuX2s1eDbgdFQxow0UhF5Q0H4qZtOQlcNIPguPlpvPIEp1Cbp6Xabn8Y Iq35Tb90xZbcG5h0hnnlhYWFAeZ8En/uzhMh3rT/Df2LmntKGajER1jcplV5yZTnW8w6 iW2CBA5bOiwk2M7qH5N6lRVY8um4Zv9SH6bVojYbEpLLr0HcvRFrxrhjHoJwEg3kUlrV gdiiN2iK7+/cVzlaB9/+w48F3t6iAS5DrJiQtSyRlMqR0baIloNVvUOL7lyZGDc4P8ru 7l5/1VzpaY6qMwgj2h2kNNiJ2Xe8CHLtKxS3Nvh5W0RqWXl9KSUMKwMwFe5VLA6sS6GD r0GQ== X-Gm-Message-State: ALoCoQm5t6s1g/sjsRLyNtbUHFrEEiVuoK8bGyqCMa07iJRxbIDRWeFp5Ng2WDLbqBQNIIezTxEF MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr7689883qad.88.1398118915312; Mon, 21 Apr 2014 15:21:55 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 15:21:55 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> Date: Mon, 21 Apr 2014 15:21:55 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0158a9e44d1c5f04f794ed16 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mvshy7L3K8rEf1CjyrXRYPnWyL0 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 22:22:05 -0000 --089e0158a9e44d1c5f04f794ed16 Content-Type: text/plain; charset=ISO-8859-1 Hi, Forgot life-cycle issues.... There does not appear to be any notion of a module revision in ForCES. There does not seem to be any way to identify a particular definition as either current, deprecated, or obsolete. Is a library used with the element ever allowed to change? If so, how are new revisions identified? Is there any text explaining how these modules are allowed to change over time? Was this considered by the WG? Andy On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman wrote: > Hi, > > > On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim wrote: > >> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman >> wrote: >> > >> > I think Jan and others have explained why they think they can leverage >> > the NC/RC/YANG technology to implement I2RS. There are tool >> > and data model management requirements in addition to the protocol >> > in order to have a workable solution. >> > >> > Unless the RIB data is one monolithic blob implemented without >> > variation on every router, then issues such as modularity, conformance >> > model, data lifecycle, distributed naming authority, data augmentation, >> > and language extensibility are going to matter. >> > >> >> So lets put all that in a requirement list somewhere and work around a gap >> analysis. >> >> > So how does ForCES support these things? > Where is the language specification in RFC 5812? > Section 4 describes LFB classes, which appear to represent the only > supported data > for the protocol. Is the entire normative language specification contained > in the XSD in sec. 4.9? > > What happens if multiple elements pull in definitions with the > same local name? The examples do not show any use of prefixes > and the element has no prefix mapping. > > > > location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> > > > There does not appear to be any conformance information like what is > mandatory or conditional on a user-defined feature. How are logical groups > of conditional objects defined and advertised in the protocol? (e.g., YANG > features) > > Are there examples of the augmentation described in sec. 4.5.7? > There does not appear to be any way for 1 module to add elements to another > without controlling the naming for all modules. > > How does a vendor implement the unique naming requirements in ForCES > without controlling the names of all possible ForCES files? Are they > supposed to > rewrite modules when a naming collision occurs because modules X and Y are > being loaded > into module Z, which causes a new naming collision that did not occur > before? > > YANG supports groupings that can be refined in each use/expansion. > How are complex statements reused and refined? > Where are examples of that in the RFC? > > > > How would I2RS use ? > > > > ipv4 > IPv4 packet > > This frame type refers to an IPv4 packet. > > > > ipv6 > IPv6 packet > > This frame type refers to an IPv6 packet. > > > ... > > > > Is this like a YANG identity statement, except this causes naming > collisions, > so it is more like a specialized distributed enumeration type? > > > To compare readability, here are the same type definitions in ForCES and > YANG: > > ForCES: (RFC 5812, pg. 80) > > > accessPermissionValues > > The possible values of component access permission > > > uchar > > > None > Access is prohibited > > > Read-Only > > Access to the component is read only > > > > Write-Only > > The component MAY be written, but not read > > > > Read-Write > > The component MAY be read or written > > > > > > > > YANG: > > > typedef accessPermissionValues { > > description > > "The possible values of component access permission"; > > type enumeration { > > enum None { > > value 0; > > description "Access is prohibited"; > > } > > enum Read-Only { > > value 1; > > description "Access to the component is read only"; > > } > > enum Write-Only { > > value 2; > > description "The component MAY be written, but not read"; > > } > > enum Read-Write { > > value 3; > > description "The component MAY be read or written"; > > } > > } > > } > > > > > How are new protocol operations defined? Are they part of the language. > > > How are language extensions done? This does not appear to be supported. > > How are existence constraints between objects expressed? (e.g., > must/when/unique) > > How does a vendor add arbitrary data to notification events? > Can event definitions be augmented? > If so, how is this done so nodes can be conditional? (e.g., if-feature, > when) > > The element is one of many that seems very ForCES > specific. > How are new events added? > > I don't see an event definition for the "Goof1changed" example: > > > > > > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > > > > > > > abstract="true"/> > substitutionGroup="eventPathPart"/> > substitutionGroup="eventPathPart"/> > > > maxOccurs="unbounded"/> > > > > > > Goof1changed > > An example event for a complex structure > > > > goo > f1 > > > > > > goo > f1 > > > > > > I am still confused about the general applicability. > E.g., how are , used in I2RS? > > > >> cheers, >> jamal >> > > > Andy > > --089e0158a9e44d1c5f04f794ed16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Forgot life-cycle issues....
<= div>There does not appear to be any notion of a module revision in ForCES.<= /div>
There does not seem to be any way to identify a particular defini= tion
as either current, deprecated, or obsolete.

I= s a library used with the <load> element ever allowed to change?
If so, how are new revisions identified?=A0

Is there any text explaining how these modules are allowed to change over t= ime?
Was this considered by the WG?

Andy=








On Mon, Apr 21, 2014 at 2:44 PM, Andy Bier= man <andy@yumaworks.com> wrote:
Hi,


On Mon, Apr 21, 2014 at 8:10 AM, = Jamal Hadi Salim <hadi@mojatatu.com> wrote:
On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman <andy@yumaworks.com>= wrote:
>
> I think Jan and others have explained why they think they can leverage=
> the NC/RC/YANG technology to implement I2RS. There are tool
> and data model management requirements in addition to the protocol
> in order to have a workable solution.
>
> Unless the RIB data is one monolithic blob implemented without
> variation on every router, then issues such as modularity, conformance=
> model, data lifecycle, distributed naming authority, data augmentation= ,
> and language extensibility are going to matter.
>

So lets put all that in a requirement list somewhere and work around a gap<= br> analysis.


So how does ForCES support these thing= s?
Where is the language specification in RFC 5812?
Section 4 describes LFB classes, which appear to represent the only suppo= rted data
for the protocol. Is the entire normative language specification conta= ined in the XSD in sec. 4.9?

What happe= ns if multiple <load> elements pull in definitions with the
same local name? =A0The examples do not show any use of prefixes
=
and the <load> element has no prefix mapping.

   <=
;load library=3D"a_library"/>
   <load library=3D"another_library" location=3D"another_=
lib.xml"/>
   <load library=3D"yetanother_library"
    location=3D"http://www.example.com/forces/1.0/lfbmodel/lpm.x=
ml"/>

There does not appea= r to be any conformance information like what is
mandatory or conditional on a user-defined feature. How are logical gr= oups
of conditional objects defined and advertised in the protoco= l? (e.g., YANG features)

Are there examples of the= augmentation described in sec. 4.5.7?
There does not appear to be any way for 1 module to add elements to an= other
<dataTypeDef> without controlling the naming for all = modules.

How does a vendor implement the unique na= ming requirements in ForCES
without controlling the names of all possible ForCES files? =A0Are the= y supposed to
rewrite modules when a naming collision occurs beca= use modules X and Y are being loaded
into module Z, which causes = a new naming collision that did not occur before?

YANG supports groupings that can be refined in each use= /expansion.
How are complex <dataTypeDef> statements reused= and refined?
Where are examples of that in the RFC?



How would I2RS use <frameDe= fs>?

    <frameDefs>
     <frameDef>
      <name>ipv4</name>
      <synopsis>IPv4 packet</synopsis>
      <description>
       This frame type refers to an IPv4 packet.
     </description>
    </frameDef>
     <frameDef>
     <name>ipv6</name>
     <synopsis>IPv6 packet</synopsis>
     <description>
       This frame type refers to an IPv6 packet.
     </description>
    </frameDef>
     ...
   </frameDefs>

Is this like a YANG identity statement, except th= is causes naming collisions,
so it is more like a specialized dis= tributed enumeration type?


To compare readability, here are the same type definit= ions in ForCES and YANG:

ForCES: (RFC 5812, pg. 80= )

              <dataTypeDef>
                  <name>accessPermissionValues</name>
                  <synopsis>
                    The possible values of component access permission
                  </synopsis>
                  <atomic>
                    <baseType>uchar</baseType>
                    <specialValues>
                      <specialValue value=3D"0">
                        <name>None</name>
                        <synopsis>Access is prohibited</synopsis&g=
t;
                      </specialValue>
                       <specialValue value=3D"1">
                        <name> Read-Only </name>
                        <synopsis>
                          Access to the component is read only
                        </synopsis>
                      </specialValue>
                      <specialValue value=3D"2">
                        <name>Write-Only</name>
                        <synopsis>
                          The component MAY be written, but not read
                        </synopsis>
                      </specialValue>
                      <specialValue value=3D"3">
                        <name>Read-Write</name>
                        <synopsis>
                          The component MAY be read or written
                        </synopsis>
                      </specialValue>
                    </specialValues>
                  </atomic>
                </dataTypeDef>

YANG:

   =
 typedef accessPermissionValues {
      descrip=
tion=A0
=
        "The possible =
values of component access permission";
           type enumeration {
             enum None {

                value 0;


                description "Access is prohibited&quo=
t;;



             }
             enum Read-Only=
 {
                value 1;<=
/span>


                description "Access to the component =
is read only";<=
/span>



             }
<=
pre style=3D"font-size:1em;margin-bottom:0px;margin-top:0px">
             enum Write-Only {<=
/pre>

                value 2;
<=
pre style=3D"font-size:1em;margin-top:0px;margin-bottom:0px">                description "=
The component MAY be writte=
n, but not read"=
;;



             }
             enum Read-Writ=
e {
                value 3;=



                description "The component MAY be rea=
d or written";<=
/span>



             }
           }



        }
How are new protocol operations defined? Are they p= art of the language.


How are langua= ge extensions done? This does not appear to be supported.

How are existence constraints between objects expressed= ? (e.g., must/when/unique)

How does a vendor add a= rbitrary data to notification events?
Can event definitions be au= gmented?
If so, how is this done so nodes can be conditional? (e.g., if-feature= , when)

The <eventCondition> element is one = of many that seems very ForCES specific.
How are new events added= ?

I don't see an event definition for the "Goof1= changed" example:


    </xsd:complexTyp=
e>
      <!-- the substitution group for the event conditions -->
      <xsd:element name=3D"eventCondition" abstract=3D"tr=
ue"/>
      <xsd:element name=3D"eventCreated"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventDeleted"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventChanged"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventGreaterThan"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:element name=3D"eventLessThan"
                  substitutionGroup=3D"eventCondition"/>
      <xsd:complexType name=3D"eventPathType">
        <xsd:sequence>
          <xsd:element ref=3D"eventPathPart" maxOccurs=3D"=
;unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
      <!-- the substitution group for the event path parts -->
      <xsd:element name=3D"eventPathPart" type=3D"xsd:str=
ing"
                   abstract=3D"true"/>
      <xsd:element name=3D"eventField" type=3D"xsd:string=
"
                   substitutionGroup=3D"eventPathPart"/>
      <xsd:element name=3D"eventSubscript" type=3D"xsd:st=
ring"
                   substitutionGroup=3D"eventPathPart"/>
      <xsd:complexType name=3D"eventReportsType">
        <xsd:sequence>
          <xsd:element name=3D"eventReport" type=3D"event=
PathType"
                       maxOccurs=3D"unbounded"/>
        </xsd:sequence>
      </xsd:complexType>

  <event eventID=3D"8">
      <name>Goof1changed</name>
      <synopsis>
          An example event for a complex structure
      </synopsis>
      <eventTarget>
        <!-- target is goo.f1 -->
        <eventField>goo</eventField>
        <eventField>f1</eventField>
      </eventTarget>
      <eventChanged/>
      <eventReports>
        <!-- report the new state of goo.f1 -->
        <eventReport>
        <eventField>goo</eventField>
        <eventField>f1</eventField>
        </eventReport>
      </eventReports>
    </event>

I am still confused about the <metadataD= efs> general applicability.
E.g., how are <inputPorts>, = <outputPorts> used in I2RS?

=A0
cheers,
jamal


Andy
=


--089e0158a9e44d1c5f04f794ed16-- From nobody Mon Apr 21 15:42:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9931A02DC for ; Mon, 21 Apr 2014 15:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGWqQTze5U9o for ; Mon, 21 Apr 2014 15:42:36 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3391A02F4 for ; Mon, 21 Apr 2014 15:42:34 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id k15so4379844qaq.15 for ; Mon, 21 Apr 2014 15:42:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PDzJ5+hxVQej8fuvdXbn4uRysl8vCrEZmTVQlTqvaLA=; b=HPDuJ0Q9TDHC4Qy960RANJvJZf1mceg1Dkqap3xNtFKwCFpigLmsGhHXOWbTGFrOaW EYEsg6leCHy5fI2Ogh5fmqGL0MkcT/cKpyk537obdCGSHSrubMeNa8rGbvjSWiksL5tB w0rUz0z74K4rWTExnw3vcwRwbc8J5pIpXtLPj9BdvxR/mTKXnneWF36bSjPo36t9WuJw hNHa4lk2Lo59HZKGPYrchG/rHLXL1xwEWQrRQ30QN7tZxIv271toulPouIA/TSiMgnbs rywZgkTLPmppQK8HfOJF/kFDALxTJ5nUea0vLZgHcme715BqKeaI5ZlwClwlJ36ce6e9 sJKw== X-Gm-Message-State: ALoCoQmGdlr3XXX11n50PH5Fhrxulw96xHaEsBDT9kAnvgWJPBZggEpx+/100VMRtOKrgwJr7lSi MIME-Version: 1.0 X-Received: by 10.140.18.173 with SMTP id 42mr3207860qgf.94.1398120149146; Mon, 21 Apr 2014 15:42:29 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Mon, 21 Apr 2014 15:42:28 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> Date: Mon, 21 Apr 2014 15:42:28 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: multipart/alternative; boundary=001a11351cb2d7f5ef04f79536e7 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E7xH0m088yHeAAeUfYwBj0Kuzy8 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 21 Apr 2014 22:42:41 -0000 --001a11351cb2d7f5ef04f79536e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 21, 2014 at 3:18 PM, Thomas Nadeau wro= te: > > > > On Apr 21, 2014, at 12:46 AM, "Jan Medved (jmedved)" > wrote: > > > > > > > >> On 4/19/14, 5:49 PM, "Jamal Hadi Salim" wrote: > >> > >> On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic > >> wrote: > >> > >> > >>> It comes down how many transactions are required? Will you updated 10= 00 > >>> routes in single transaction or in 1000 transactions. > >> > >> Take your pick. The point is it boils down to how that is modelled and > >> carried > >> over the wire (and influences those decisions). > >> > >>> From my perspective there are two important metrics for i2rs > >>> throughput > >>> and > >>> latency > >> > >> Now we are talking. > >> > >>> > >>> IMO, I2RS agent has to provide as high as possible throughput and add > >>> minimal latency to the >process. What is the throughput required? Don= 't > >>> know at the moment. I saw some request in high >single digit thousand= s > >>> per second, but not sure about use cases. On the latency side, you wa= nt > >>> it as >close to 0 as possible, but that will be highly platform > >>> dependent. > >> > >> Agreed. > > > > Both throughput and latency are meaningless from the standardization > point > > of view - they both largely depend on the underlying system. > > > > Speaking for NC/Y implementations that I=B9ve been involved with, the > > throughput of the Netconf Agent itself is much larger than the rest of > the > > system, and its latency is negligible compared to the rest of the syste= m. > > This happens to be true both for an embedded agent (XR), where ultimate= ly > > both throughput and latency are determined by how fast you can program > > hardware, and for the controller, where both throughput and latency > depend > > on how fast you can shove things into a data store. > > > > Rather than focusing on devising a super fast binary encoding for the > > protocol (which will speed up maybe 2-5% of the overall CPU cycles), we > > need to have a self-describing schema-based message encoding which allo= ws > > for creation of tools that generate most of the agent and client code. > > NC/RC/Y gives us exactly that. The raw speed of the agent (optimized > > protocol processing, message encoding, etc.) must be weighed against th= e > > ease and speed with which new APIs can be added to system - we have > > Moore=B9s law for CPUs, but not for human brains ;-) We need to compen= sate > > for that with tooling/automation. > > This is the right approach. The speed up vs pita factor for binary > encoding isn't worth it. And as you say, the CPU performance is so fast > even today that it's not an issue. > > > > > > >> > >>> I have to start doing some PoCs to see what can and can not do with > >>> existing tools. If those tools >work, then good. If those tools don't > >>> work, then back to the drawing board. Until things work, keep on > >moving > >>> with what works and try to find break points. > >> > >> But i do believe there are limitations which are not obvious without > >> contrasting against requirements. > >> > >>> You can add your comments to the existing drafts. > >> > >> I would gladly do - but i worry whether the discussion is about crowni= ng > >> some > >> solution instead of meeting such objectives; if the WG decides to mov= e > >> in that > >> direction i would be happy to contribute. > >> There's material floating, the old protocol draft; Joel pointed to the > >> architecture > >> draft covering model requirements. Andy mentioned possible "stretch" > >> requirements. I think what would be appropriate is one draft for the > model > >> and one for the protocol with gap analysis. > >> > >>>> > >>>> Unfortunately - we are not having that kind of useful discussion and= i > >>>> feel like a broken > >>>> record asking for requirements. > >>> > >>> I believe we have a set of requirements. It is in > >>> draft-rfernando-i2rs-protocol-requirements. > >>> You can always comment that draft and argue pro and con each > requirement. > >> > >> Glad we are bringing that draft into play;-> How does restconf fair > >> against it? > > > > Reasonably well. When we evaluated restconf against these requirements = (I > > am a co-author), the major deficiency found was lack of notifications i= n > > restconf, which was addressed in a subsequent restconf revision. There > are > > still things that would have to be added (for example, client > identities), > > but this can be addressed either in the protocol or in models. There is > > nothing *structural* in restconf that would prevent it from satisfying > the > > requirements set. > > > > And as I said earlier in this thread, about 80-90% of what I can think > > that we can do with I2RS (and it=B9s much, much more than just RIB > > programming ;-) ) can be addressed with NC/RC/Y today. > > I agree. I've always viewed what needs to be done as more or less a subse= t > of what's in netconf today. > > I will try to be more specific here. IMO: I2RS =3D (NC | RC) + YANG - datastore_validation - NV_storage + owner_priority_ACM My early implementation feedback (hope to be done before Toronto): The message encoding has virtually no impact and it is not the bottleneck. The new protocol stack screams, because distributed YANG validation and NV-storage can be really expensive. The system's ability to activate change= s in the underlying firmware is the bottleneck in NC/RC, and that depends on the implementation. > Tom > > Andy > > > > > > > > >> Note: The draft is a good starting point but is missing as an example > >> the issue of > >> latency and throughput. > >> > >> cheers, > >> jamal > > > > _______________________________________________ > > 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 > --001a11351cb2d7f5ef04f79536e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Apr 21, 2014 at 3:18 PM, Thomas Nadeau &l= t;tnadeau@luci= dvision.com> wrote:


> On Apr 21, 2014, at 12:46 AM, "Jan Medved (jmedved)" <jmedved@cisco.com> wrote:
>
>
>
>> On 4/19/14, 5:49 PM, "Jamal Hadi Salim" <hadi@mojatatu.com> wrote:
>>
>> On Sat, Apr 19, 2014 at 4:11 PM, Dean Bogdanovic <deanb@juniper.net>
>> wrote:
>>
>>
>>> It comes down how many transactions are required? Will you upd= ated 1000
>>> routes in single transaction or in 1000 transactions.
>>
>> Take your pick. The point is it boils down to how that is modelled= and
>> carried
>> over the wire (and influences those decisions).
>>
>>> From my perspective there are two important metrics for i2rs >>> throughput
>>> and
>>> latency
>>
>> Now we are talking.
>>
>>>
>>> IMO, I2RS agent has to provide as high as possible throughput = and add
>>> minimal latency to the >process. What is the throughput req= uired? Don't
>>> know at the moment. I saw some request in high >single digi= t thousands
>>> per second, but not sure about use cases. On the latency side,= you want
>>> it as >close to 0 as possible, but that will be highly plat= form
>>> dependent.
>>
>> Agreed.
>
> Both throughput and latency are meaningless from the standardization p= oint
> of view - they both largely depend on the underlying system.
>
> Speaking for NC/Y implementations that I=B9ve been involved with, the<= br> > throughput of the Netconf Agent itself is much larger than the rest of= the
> system, and its latency is negligible compared to the rest of the syst= em.
> This happens to be true both for an embedded agent (XR), where ultimat= ely
> both throughput and latency are determined by how fast you can program=
> hardware, and for the controller, where both throughput and latency de= pend
> on how fast you can shove things into a data store.
>
> Rather than focusing on devising a super fast binary encoding for the<= br> > protocol (which will speed up maybe 2-5% of the overall CPU cycles), w= e
> need to have a self-describing schema-based message encoding which all= ows
> for creation of tools that generate most of the agent and client code.=
> NC/RC/Y gives us exactly that. The raw speed of the agent (optimized > protocol processing, message encoding, etc.) must be weighed against t= he
> ease and speed with which new APIs can be added to system - we have > Moore=B9s law for CPUs, but not for human brains ;-) =A0We need to com= pensate
> for that with tooling/automation.

This is the right approach. The speed up vs pita factor for binary encoding= isn't worth it. And as you say, the CPU performance is so fast even to= day that it's not an issue.

>
>
>>
>>> I have to start doing some PoCs to see what can and can not do= with
>>> existing tools. If those tools >work, then good. If those t= ools don't
>>> work, then back to the drawing board. Until things work, keep = on >moving
>>> with what works and try to find break points.
>>
>> But i do believe there are limitations which are not obvious witho= ut
>> contrasting against requirements.
>>
>>> You can add your comments to the existing drafts.
>>
>> I would gladly do - but i worry whether the discussion is about cr= owning
>> some
>> solution instead of meeting such objectives; =A0if the WG decides = to move
>> in that
>> direction i would be happy to contribute.
>> There's material floating, the old protocol draft; Joel pointe= d to the
>> architecture
>> draft covering model requirements. Andy mentioned =A0possible &quo= t;stretch"
>> requirements. I think what would be appropriate is one draft for t= he model
>> and one for the protocol with gap analysis.
>>
>>>>
>>>> Unfortunately - we are not having that kind of useful disc= ussion and i
>>>> feel =A0like a broken
>>>> record asking for requirements.
>>>
>>> I believe we have a set of requirements. It is in
>>> draft-rfernando-i2rs-protocol-requirements.
>>> You can always comment that draft and argue pro and con each r= equirement.
>>
>> Glad we are bringing that draft into play;-> How does restconf = fair
>> against it?
>
> Reasonably well. When we evaluated restconf against these requirements= (I
> am a co-author), the major deficiency found was lack of notifications = in
> restconf, which was addressed in a subsequent restconf revision. There= are
> still things that would have to be added (for example, client identiti= es),
> but this can be addressed either in the protocol or in models. There i= s
> nothing *structural* in restconf that would prevent it from satisfying= the
> requirements set.
>
> And as I said earlier in this thread, about 80-90% of what I can think=
> that we can do with I2RS (and it=B9s much, much more than just RIB
> programming ;-) ) can be addressed with NC/RC/Y today.

I agree. I've always viewed what needs to be done as more or less a sub= set of what's in netconf today.


I will try to be more specific here.

IMO:

=A0 I2RS =3D (NC | RC= ) + YANG - datastore_validation - NV_storage + owner_priority_ACM

My early implementation feedback (hope to be done before Tor= onto):
The message encoding has virtually no impact and it is not= the bottleneck.
The new protocol stack screams, because distribu= ted YANG validation and
NV-storage can be really expensive. The system's ability to activa= te changes
in the underlying firmware is the bottleneck in NC/RC,= and that depends
on the implementation.

=A0
Tom


Andy

=A0

>
>
>
>> Note: The draft is a good starting point but is missing as an exam= ple
>> the issue of
>> latency and throughput.
>>
>> cheers,
>> jamal
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

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

--001a11351cb2d7f5ef04f79536e7-- From nobody Mon Apr 21 20:48:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F541A002F for ; Mon, 21 Apr 2014 20:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVUo8QkILYfF for ; Mon, 21 Apr 2014 20:48:18 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D60551A0048 for ; Mon, 21 Apr 2014 20:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F209A6058F; Mon, 21 Apr 2014 20:48:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 85AAF6058C; Mon, 21 Apr 2014 20:48:12 -0700 (PDT) Message-ID: <5355E678.8030309@joelhalpern.com> Date: Mon, 21 Apr 2014 23:48:08 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman , Jamal Hadi Salim References: <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MCHZV8579K4RLdA1_oR8zMil0p8 Cc: Russ White , "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 03:48:23 -0000 As a minor point, I consider the embedding of file management and business logic into the core of NetConf was probably a mistake. ForCES does have version numbers on classes, so if you change an LFB class definition, you increase the revision. It also has inheritance, which provides an effective way to define a coherent extension of a class. And it explicitly includes indications of which items are required. As well as providing mechanisms for a controller to determine on a fine grained basis what an FE actually supports. So we do not have to guess what the right groupings are for unknown users down the road. Yours, Joel On 4/21/14, 6:21 PM, Andy Bierman wrote: > Hi, > > Forgot life-cycle issues.... > There does not appear to be any notion of a module revision in ForCES. > There does not seem to be any way to identify a particular definition > as either current, deprecated, or obsolete. > > Is a library used with the element ever allowed to change? > If so, how are new revisions identified? > > Is there any text explaining how these modules are allowed to change > over time? > Was this considered by the WG? > > Andy > > > > > > > > > > On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman > wrote: > > Hi, > > > On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim > wrote: > > On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman > > wrote: > > > > I think Jan and others have explained why they think they can > leverage > > the NC/RC/YANG technology to implement I2RS. There are tool > > and data model management requirements in addition to the > protocol > > in order to have a workable solution. > > > > Unless the RIB data is one monolithic blob implemented without > > variation on every router, then issues such as modularity, > conformance > > model, data lifecycle, distributed naming authority, data > augmentation, > > and language extensibility are going to matter. > > > > So lets put all that in a requirement list somewhere and work > around a gap > analysis. > > > So how does ForCES support these things? > Where is the language specification in RFC 5812? > Section 4 describes LFB classes, which appear to represent the only > supported data > for the protocol. Is the entire normative language specification > contained in the XSD in sec. 4.9? > > What happens if multiple elements pull in definitions with the > same local name? The examples do not show any use of prefixes > and the element has no prefix mapping. > > > > location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> > > > There does not appear to be any conformance information like what is > mandatory or conditional on a user-defined feature. How are logical > groups > of conditional objects defined and advertised in the protocol? > (e.g., YANG features) > > Are there examples of the augmentation described in sec. 4.5.7? > There does not appear to be any way for 1 module to add elements to > another > without controlling the naming for all modules. > > How does a vendor implement the unique naming requirements in ForCES > without controlling the names of all possible ForCES files? Are > they supposed to > rewrite modules when a naming collision occurs because modules X and > Y are being loaded > into module Z, which causes a new naming collision that did not > occur before? > > YANG supports groupings that can be refined in each use/expansion. > How are complex statements reused and refined? > Where are examples of that in the RFC? > > > > How would I2RS use ? > > > > ipv4 > IPv4 packet > > This frame type refers to an IPv4 packet. > > > > ipv6 > IPv6 packet > > This frame type refers to an IPv6 packet. > > > ... > > > > Is this like a YANG identity statement, except this causes naming > collisions, > so it is more like a specialized distributed enumeration type? > > > To compare readability, here are the same type definitions in ForCES > and YANG: > > ForCES: (RFC 5812, pg. 80) > > > accessPermissionValues > > The possible values of component access permission > > > uchar > > > None > Access is prohibited > > > Read-Only > > Access to the component is read only > > > > Write-Only > > The component MAY be written, but not read > > > > Read-Write > > The component MAY be read or written > > > > > > > > YANG: > > > typedef accessPermissionValues { > > description > > "The possible values of component access permission"; > > type enumeration { > > enum None { > > value 0; > > description "Access is prohibited"; > > } > > enum Read-Only { > > value 1; > > > description "Access to the component is read only"; > > > } > > enum Write-Only { > > > value 2; > > description "The component MAY be written, but not read"; > > > } > > enum Read-Write { > > value 3; > > > description "The component MAY be read or written"; > > > } > > } > > > > } > > > > > > > How are new protocol operations defined? Are they part of the language. > > > How are language extensions done? This does not appear to be supported. > > How are existence constraints between objects expressed? (e.g., > must/when/unique) > > How does a vendor add arbitrary data to notification events? > Can event definitions be augmented? > If so, how is this done so nodes can be conditional? (e.g., > if-feature, when) > > The element is one of many that seems very ForCES > specific. > How are new events added? > > I don't see an event definition for the "Goof1changed" example: > > > > > > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > substitutionGroup="eventCondition"/> > > > > > > > abstract="true"/> > substitutionGroup="eventPathPart"/> > substitutionGroup="eventPathPart"/> > > > maxOccurs="unbounded"/> > > > > > > Goof1changed > > An example event for a complex structure > > > > goo > f1 > > > > > > goo > f1 > > > > > > I am still confused about the general applicability. > E.g., how are , used in I2RS? > > cheers, > jamal > > > > Andy > > From nobody Mon Apr 21 22:27:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED061A0087 for ; Mon, 21 Apr 2014 22:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVU36HKtKyzT for ; Mon, 21 Apr 2014 22:27:11 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF31A0077 for ; Mon, 21 Apr 2014 22:27:11 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3M5Ev3I024512; Mon, 21 Apr 2014 22:27:00 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1kd0wcgdn8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Apr 2014 22:27:00 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Apr 2014 22:26:59 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Mon, 21 Apr 2014 22:26:59 -0700 From: ramki Krishnan To: "Joel M. Halpern" , Andy Bierman , Jamal Hadi Salim Date: Mon, 21 Apr 2014 22:26:58 -0700 Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: Ac9d3kexm9NS2WzSRZGipJc+FnqZ2AAC6DZA Message-ID: References: <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> In-Reply-To: <5355E678.8030309@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-22_02:2014-04-21,2014-04-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404220076 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NKur5Sp0GYZlLsfcXjAXq25lmqc Cc: Russ White , "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 05:27:16 -0000 It would be good to have an empirical performance analysis of Netconf vs FO= RCES; this would substantiate performance advantages, if any, of either pro= tocol. The following reference provides a reasonable empirical performance = analysis of Netconf vs SNMP - http://morse.colorado.edu/~tlen5710/11s/11NET= CONFvsSNMP.pdf. Thanks, Ramki -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, April 21, 2014 8:48 PM To: Andy Bierman; Jamal Hadi Salim Cc: Russ White; i2rs@ietf.org; Jan Medved (jmedved); Dean Bogdanovic; Edwar= d Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model As a minor point, I consider the embedding of file management and business = logic into the core of NetConf was probably a mistake. ForCES does have version numbers on classes, so if you change an LFB class = definition, you increase the revision. It also has inheritance, which provides an effective way to define a cohere= nt extension of a class. And it explicitly includes indications of which items are required. As wel= l as providing mechanisms for a controller to determine on a fine grained b= asis what an FE actually supports. So we do not have to guess what the rig= ht groupings are for unknown users down the road. Yours, Joel On 4/21/14, 6:21 PM, Andy Bierman wrote: > Hi, > > Forgot life-cycle issues.... > There does not appear to be any notion of a module revision in ForCES. > There does not seem to be any way to identify a particular definition=20 > as either current, deprecated, or obsolete. > > Is a library used with the element ever allowed to change? > If so, how are new revisions identified? > > Is there any text explaining how these modules are allowed to change=20 > over time? > Was this considered by the WG? > > Andy > > > > > > > > > > On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman > wrote: > > Hi, > > > On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim > wrote: > > On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman > > wrote: > > > > I think Jan and others have explained why they think they can > leverage > > the NC/RC/YANG technology to implement I2RS. There are tool > > and data model management requirements in addition to the > protocol > > in order to have a workable solution. > > > > Unless the RIB data is one monolithic blob implemented without > > variation on every router, then issues such as modularity, > conformance > > model, data lifecycle, distributed naming authority, data > augmentation, > > and language extensibility are going to matter. > > > > So lets put all that in a requirement list somewhere and work > around a gap > analysis. > > > So how does ForCES support these things? > Where is the language specification in RFC 5812? > Section 4 describes LFB classes, which appear to represent the only > supported data > for the protocol. Is the entire normative language specification > contained in the XSD in sec. 4.9? > > What happens if multiple elements pull in definitions with the > same local name? The examples do not show any use of prefixes > and the element has no prefix mapping. > > > > =20 > location=3D"http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> > > > There does not appear to be any conformance information like what is > mandatory or conditional on a user-defined feature. How are logical > groups > of conditional objects defined and advertised in the protocol? > (e.g., YANG features) > > Are there examples of the augmentation described in sec. 4.5.7? > There does not appear to be any way for 1 module to add elements to > another > without controlling the naming for all modules. > > How does a vendor implement the unique naming requirements in ForCES > without controlling the names of all possible ForCES files? Are > they supposed to > rewrite modules when a naming collision occurs because modules X and > Y are being loaded > into module Z, which causes a new naming collision that did not > occur before? > > YANG supports groupings that can be refined in each use/expansion. > How are complex statements reused and refined? > Where are examples of that in the RFC? > > > > How would I2RS use ? > > > > ipv4 > IPv4 packet > > This frame type refers to an IPv4 packet. > > > > ipv6 > IPv6 packet > > This frame type refers to an IPv6 packet. > > > ... > > > > Is this like a YANG identity statement, except this causes naming > collisions, > so it is more like a specialized distributed enumeration type? > > > To compare readability, here are the same type definitions in ForCES > and YANG: > > ForCES: (RFC 5812, pg. 80) > > > accessPermissionValues > > The possible values of component access permissi= on > > > uchar > > > None > Access is prohibited > > > Read-Only > > Access to the component is read only > > > > Write-Only > > The component MAY be written, but not read > > > > Read-Write > > The component MAY be read or written > > > > > > > > YANG: > > > typedef accessPermissionValues { > > description > > "The possible values of component access permission"; > > type enumeration { > > enum None { > > value 0; > > description "Access is prohibited"; > > } > > enum Read-Only { > > value 1; > > > description "Access to the component is read=20 > only"; > > > } > > enum Write-Only { > > > value 2; > > description "The component MAY be written, but=20 > not read"; > > > } > > enum Read-Write { > > value 3; > > > description "The component MAY be read or=20 > written"; > > > } > > } > > > > } > > > > > > > How are new protocol operations defined? Are they part of the languag= e. > > > How are language extensions done? This does not appear to be supporte= d. > > How are existence constraints between objects expressed? (e.g., > must/when/unique) > > How does a vendor add arbitrary data to notification events? > Can event definitions be augmented? > If so, how is this done so nodes can be conditional? (e.g., > if-feature, when) > > The element is one of many that seems very ForCES > specific. > How are new events added? > > I don't see an event definition for the "Goof1changed" example: > > > > > > substitutionGroup=3D"eventCondition"/> > substitutionGroup=3D"eventCondition"/> > substitutionGroup=3D"eventCondition"/> > substitutionGroup=3D"eventCondition"/> > substitutionGroup=3D"eventCondition"/> > > > > > > > abstract=3D"true"/> > substitutionGroup=3D"eventPathPart"/> > substitutionGroup=3D"eventPathPart"/> > > > maxOccurs=3D"unbounded"/> > > > > > > Goof1changed > > An example event for a complex structure > > > > goo > f1 > > > > > > goo > f1 > > > > > > I am still confused about the general applicability. > E.g., how are , used in I2RS? > > cheers, > jamal > > > > Andy > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Apr 22 00:06:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744AC1A00DD for ; Tue, 22 Apr 2014 00:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNZov5cYEvcG for ; Tue, 22 Apr 2014 00:06:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id EF2E61A00CF for ; Tue, 22 Apr 2014 00:06:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 55B083941E0; Tue, 22 Apr 2014 09:06:09 +0200 (CEST) Date: Tue, 22 Apr 2014 09:06:09 +0200 (CEST) Message-Id: <20140422.090609.829653947336212190.mbj@tail-f.com> To: jhaas@pfrc.org From: Martin Bjorklund In-Reply-To: <20140421200202.GE2046@pfrc> References: <008201cf5b5b$5ca25dd0$15e71970$@ndzh.com> <20140421200202.GE2046@pfrc> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/W9_LITqVqU7UEev12AHnd-N-rMU Cc: i2rs@ietf.org, edc@google.com, shares@ndzh.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 07:06:19 -0000 Jeffrey Haas wrote: > On Fri, Apr 18, 2014 at 07:10:16PM -0400, Susan Hares wrote: > > The assumption: > > > > I am assuming that the information models are not a waste of time. Jeff > > Haas' comment was isn't having information models and data models a > > duplication of effort. > > > > First of all, RBNF and ABNF seem to be causing redundant issues in the > > draft-ietf-i2rs-rib-info-model-02 draft. > > > > The ABNF the delightful work in > > > > draft-clarke-i2rs-traceability-01 really difficult to follow. > > > > My assumption had been the following train would occur: > > > > UML graphic (readable) > > || > > VV (someday via tool) > > UML text (readable) > > || (via tools - I've already found some) > > || > > VV > > > > Yang/Forces Data Model (Yang readable/Forces:Readable) > > FWIW, UML can do much of this but even some of the best authors on it note > that it can be a bit more art than science in some cases. Also note that UML is more abstract, and doesn't necessarily have the ability to express details that are actually needed in the data model. So in general it is not possible to generate the data model from UML. (of course, you might be able to generate a stub data model which you manually tweak). I agree that UML is a better choice for the information model than ABNF. /martin From nobody Tue Apr 22 00:20:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47FA1A00E6 for ; Tue, 22 Apr 2014 00:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siechEomTUEz for ; Tue, 22 Apr 2014 00:20:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDD1A00E7 for ; Tue, 22 Apr 2014 00:20:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D6FFDFD0; Tue, 22 Apr 2014 09:20:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N7EBHaBcvtbE; Tue, 22 Apr 2014 09:19:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Apr 2014 09:19:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BF1520017; Tue, 22 Apr 2014 09:19:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4pah6lvbroW1; Tue, 22 Apr 2014 09:19:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF04C20013; Tue, 22 Apr 2014 09:19:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9B2762C92AB7; Tue, 22 Apr 2014 09:19:56 +0200 (CEST) Date: Tue, 22 Apr 2014 09:19:56 +0200 From: Juergen Schoenwaelder To: ramki Krishnan Message-ID: <20140422071954.GA10717@elstar.local> Mail-Followup-To: ramki Krishnan , "Joel M. Halpern" , Andy Bierman , Jamal Hadi Salim , Russ White , "i2rs@ietf.org" , "Jan Medved (jmedved)" , Dean Bogdanovic , Edward Crabbe References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BdZkmsmH7kzEQpqRLJ6nSukStLQ Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Andy Bierman , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Apr 2014 07:20:16 -0000 On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: > It would be good to have an empirical performance analysis of > Netconf vs FORCES; this would substantiate performance advantages, > if any, of either protocol. The following reference provides a > reasonable empirical performance analysis of Netconf vs SNMP - > http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. I believe this comparison is flawed. ncclient uses a pure Python implementation of SSH while the authors used a Python wrapper around NET-SNMP (a C implementation) to measure SNMP performance. And the authors state that they used SNMPv2c (no security) and SSH as the NETCONF transport. (It is also unclear whether all NETCONF transactions were executed over a single session or multiple sessions.) The design of such experiments is not as easy as it may look at first glance and it is in particular important to use comparable security algorithms (ideally the same crypto library). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Apr 22 04:43:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068831A03B4 for ; Tue, 22 Apr 2014 04:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umy1_4YWnaEM for ; Tue, 22 Apr 2014 04:43:42 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A55241A03A3 for ; Tue, 22 Apr 2014 04:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7252; q=dns/txt; s=iport; t=1398167016; x=1399376616; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=aMpo6KVIEVQX8LGenUa0BlOUtSApBZQfbWFlvvvVqW0=; b=HMHk6fV/itNgOoRsCqWhTO1eONh4oMtNd/oFPhHmxwdDPfiYQaBtxJUV hWZ1A5Xv5m2FbgYg/9lg5wioRCckUZeSq320X/XClErSp0GktbpDGCBGt o5OC8wUCwJYpgCIQBSqLZpR/biU/Z7QPyrBlB6JlDqiVxvJiGOyiLZKfP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAGJVVlOQ/khL/2dsb2JhbABZgwaKErsqgRcWdIImAQEEeBELDgQPFg8JAwIBAgE3DgYBDAgBARUCiCbMQReNdBEBV4Q4AQOYcIZZi3mDMzuBNQ X-IronPort-AV: E=Sophos; i="4.97,903,1389744000"; d="scan'208,217"; a="23212835" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 22 Apr 2014 11:43:35 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3MBhZMr003433; Tue, 22 Apr 2014 11:43:35 GMT Message-ID: <535655E7.9090405@cisco.com> Date: Tue, 22 Apr 2014 13:43:35 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Edward Crabbe , "i2rs@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000304040504000605040907" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_pqunSC4heFr_iL2HI1kFQ1kcqQ Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 11:43:47 -0000 This is a multi-part message in MIME format. --------------000304040504000605040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I've been spending the last 2 hours reading that full email thread, up to this time. Not sure to which email I should reply, so here am I, top posting. + 1 on YANG for the data model language. What counts at the end of the day is a consistent data model language for configuration, because implementing a proxy for different data model languages is a pain, time consuming, and error-prone. Ideally, we should have a consistent information model language, but the industry/standards are not there yet. Not even sure they will even arrive there one day. Looking at the life cycling of specifying a new language, implementing it, deploying it, and developing tools around it (I have SMI and YANG in mind), having a new data model language for I2RS only is not practical. And the more we wait, the more obvious the solution is. I know, it's not about a technical argument any longer (those have been made on the lits already). Let's look at the WG deliverables: 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 The least we can say is that the WG is late. I observe that after 1 year and 3 months after the WG creation, we still don't have the problem statement/architecture/requirements: that explains, whether we like it or not, why the business reasons are getting more and more important compared to the technical arguments. Didn't we see a few comments lately about the IETF not being relevant because we're too slow? Maybe the IESG should be stricter: "no problem statement with a year, WG closed", but I guess I'm diverging :-) Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logical step, even if I believe that in practice, we'll see different devices speaking different languages. Regards, Benoit (as a contributor) --------------000304040504000605040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I've been spending the last 2 hours reading that full email thread, up to this time.
Not sure to which email I should reply, so here am I, top posting.

+ 1 on YANG for the data model language.
What counts at the end of the day is a consistent data model language for configuration, because implementing a proxy for different data model languages is a pain, time consuming, and error-prone.
Ideally, we should have a consistent information model language, but the industry/standards are not there yet. Not even sure they will even arrive there one day.

Looking at the life cycling of specifying a new language, implementing it, deploying it, and developing tools around it (I have SMI and YANG in mind), having a new data model language for I2RS only is not practical. And the more we wait, the more obvious the solution is.
I know, it's not about a technical argument any longer (those have been made on the lits already).
Let's look at the WG deliverables:
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

The least we can say is that the WG is late.
I observe that after 1 year and 3 months after the WG creation, we still don't have the problem statement/architecture/requirements: that  explains, whether we like it or not, why the  business reasons are getting more and more important compared to the technical arguments.
Didn't we see a few comments lately about the IETF not being relevant because we're too slow?
Maybe the IESG should be stricter: "no problem statement with a year, WG closed", but I guess I'm diverging :-)

Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logical step, even if I believe that in practice, we'll see different devices speaking different languages.

Regards,  Benoit (as a contributor)

--------------000304040504000605040907-- From nobody Tue Apr 22 06:21:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364051A046C for ; Tue, 22 Apr 2014 06:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s80m3xQtWe1 for ; Tue, 22 Apr 2014 06:21:40 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6822A1A046A for ; Tue, 22 Apr 2014 06:21:40 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so1276941vcb.29 for ; Tue, 22 Apr 2014 06:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DbFBZabbOTbZa6JCDIw9QPSH5nlIlSAJ5LnmAKD97no=; b=HRUoZVE51ngNIuwWxW97DyljzNrB/IKyntZiafQcnDlyKuUuNdGkir+YN+ygIZF72+ JweAcllBfRcg4j+Cf0u70DGe5eGtNSjEQZ3iDNw9Bhp9N5P8ndNZeZh5NfvAVuql//jY hOnFdAZiEnffuiksMliLZAYK7pml+bOF7JfguVCAUVRGW4JVSvCtsg1j4PO6VsuwNckB IFMdZjx85OM+EPowHul+ROF64FRbYNZIBmWW1r1V5/csC/2naMFJhaeD8GUyNZxoe4+h qWaY21Ch9D/MSswzXIFpCEaAnXZofmKcQICy7Oj5Jq86XNxYMYgdQ5gM6CUeq33Fqp/L +hYA== X-Gm-Message-State: ALoCoQm9sMr4inoNua25oU5Ix5tcanKkCC6tHEg+s1gIkD1LgjldQS6rDh43zKdxLTFN+XzE1Hg6 X-Received: by 10.220.105.130 with SMTP id t2mr157631vco.18.1398172894810; Tue, 22 Apr 2014 06:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 22 Apr 2014 06:21:14 -0700 (PDT) In-Reply-To: <20140422071954.GA10717@elstar.local> References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> From: Jamal Hadi Salim Date: Tue, 22 Apr 2014 09:21:14 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hYz7KIIl0B2TVJ-0x_Yb7fHgBZs Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 13:21:45 -0000 On Mon, Apr 21, 2014 at 3:02 PM, Jeffrey Haas wrote: > On Mon, Apr 21, 2014 at 07:36:44AM -0400, Jamal Hadi Salim wrote: > > It may not be the primary deciding criterion but it will > certainly be a big one given the high-throughput desires we have for I2RS. > Do you see a whole BGP table (or larger) being injected/dumped via I2RS? > but I'm happy to provide wiki space for these things to be enumerated. > That would be nice. > The binary encoding of FORCES may help with speed. > It was asserted elsewhere (copied below) that this may only be 3-5% of a > speed improvement. (I had thought I recalled a discussion in netmod(?) at > one point of a BER format for YANG, but my google-fu is failing me.) > A somewhat negative property of XML is that a document is only considered > valid once you have the whole document. Thus, document size may matter. > I think the parsing technique used for XML may help (DOM vs SAX); XML gurus can comment. I have very strong doubts about the 3-5% number stated - but hopefully we can settle that with real numbers. Let me try to handwave (not sure if this is wiki material): On compute: I would expect json to perform better than XML when sending to a browser. In particular given that json is a native format to javascript (but also heard of some decent C/python parsers). If you extended that thought to binary data it will likely perform better than json to an I2RS agent because it is closer to the native format of the I2RS agent ( a lot less translation needed). String processing may be alleviated with newer instruction sets that processor vendors are putting out (glibc uses some of the SSE instructions on x864 when available to do things like strcmp) - but that still will not give you the 3-5% difference claimed. There's also a bunch of vendors who would sell you xml or string processing offload. But i wouldnt call that commodity or depend on that when defining wire format. On extensibility: One could argue that the XML definition would be more extensible than json i.e if you want to be close to native format you pay in reduced extensibility. So if I2RS cared more about extensibility json would not be a good choice. In ForCES we chose to define things in XML to allow for the extensibility; so from that perspective we are closer to XML. The ForCES XML schema/language allows defining things as close as possible to native format. On the wire we take the xml definition and convert it to binary and from that perspective we are closer to json. On wire performance: Should be noted that it is not just about compute resources, but also network resources. If i send 1000 RIB components in ascii (doesnt matter whether it is json or xml) vs the same amount in binary; i would expect the wire resources to be several magnitudes better with binary. It will also be a lot closer to native format the RIB manager uses. Same with sending XML vs json to a browser - json is a native format to javascript and a lot more compact, therefore will perform better. Wire performance can be improved by the classical technique of using compression on the wire. That adds cost to the cost of compute. > I've been working through the various I-Ds in detail. Using the BGP use case > as an example, one of the desires may be to dynamically provision BGP > peering sessions. Given that the I2RS cases are not strictly to provide the > configuration of BGP but are likely a subset of this piece of configuration > in an ephemeral context, this seems to suggest that the I2RS pieces of the > system should ideally have good alignment with configuration systems. Thus, > if YANG were used for provisioning BGP, there's a strong desire for there to > be symmetry in the I2RS model - and thus potentially to share a portion of > the YANG. The same observation would hold for a FORCES implementation of > I2RS. > > Another example is the RIB. > > We want to leverage existing data models in a configuration context while > also providing I2RS extensions for configuration, monitoring, etc. > Lets pick a few use cases that makes sense to I2RS and go with that from an analysis pov. Tom Petch was probably right in saying we needed to start with use cases. I dont want to sell ForCES features that have no meaning for I2RS. > The other half of such a discussion tends to be around letting other > consumers of the encoded information Do Something Useful with it. This does > to some extent argue and influence what your programming model/API is. If > your access to everything is always via strict API, binary encoding a great. This is the modus operandi for what we do today. It allows us to hide whats underneath. The user really has no business knowing we are running ForCES underneath. > But an (IMO) advantage of text-based systems is that it's pretty trivial to > do a lot of things. This is true. The cost may be extensibility as i said above. Note: most of the time the arguement ive heard for ascii is it is useful for the operator for debugging - which clearly not true considering the wire format is always encrypted. This may have been true for smtp or early days of http - but clearly not true for the domain we are talking about. >I suspect I'm not the only one that uses text-based > expansions of binary objects for various work. (And I'll also note that I > leave things in binary format with API access when it makes sense.) > > What I'm really saying is that the ecosystem is likely to expand binary > encoding to text just as much as it's going to move to a binary encoding. > I am juggling that in my head and not seeing going ascii from binary. (I guess given my reading of your context above i am seeing base64 encoding of binary data ;->). You probably mean something else > > Would you say section 4.5.3 of RFC 5812 provides a good example of that? > (Just to pick one from my reading.) > If you are talking about the API, it is closer to what http does (restful, few verbs and many nouns which would be close to URIs). Think of a restful binary setup. Something restful like http would be sufficient to describe it. Section 4.5 defines the schema i.e how one would define/model the resources (eg RIB). The API is what the protocol provides the few verbs to act on resources/nouns. So an API call is of the form: Verb [optional data] Bringing the comparison to http again: a ForCES SET would be equivalent to http POST/PUT/PATCH etc. There are some CRUD semantics like append/exclusivity etc that were discussed but missing from the protocol. I gave a high level view at the SDNRG WG in ietf86. Also my gap analysis summarizes some things. Evangelos is planning to give webinars/tutorial that people wanting to get familiar with ForCES could attend. > Jamal, while the point is being made perhaps a bit less than pleasantly, > there is certainly something there to discuss: The work Jan cites has a > depth of models that cover many pieces of functionality similar to those > that I2RS looks to address. They've done enough work against Yang/Netconf > to have an idea of the remaining gaps. > > While I agree that within the limited scope of the FORCES documents that > I've read that the modeling language and to a large extent the protocol can > similarly address the problems, I haven't the depth to determine whether > similar coverage of I2RS cases can be done within FORCES and what would need > to change. It is also unclear aside from the binary encoding / more atomic > transaction model (note, I haven't read restconf yet for proper comparison) > that FORCES would bring vs. Yang/Netconf. That comparison is what the WG > needs in somewhat greater depth than the existing gap analysis. > So my take on this is: Lets have the informational description of what I2RS needs - perhaps by going over use cases. It is easy to provide the ForCES view of those model. cheers, jamal From nobody Tue Apr 22 06:59:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BABA1A0481 for ; Tue, 22 Apr 2014 06:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm2ROGlPCvqh for ; Tue, 22 Apr 2014 06:59:35 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFD21A03EF for ; Tue, 22 Apr 2014 06:59:35 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so9426635veb.6 for ; Tue, 22 Apr 2014 06:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JFSZNwy0FcRDsHTmML0rXCLgokXUxbSfvbDfgEbFir0=; b=jt46qp+CQt9H9stTE8NvuhIly6OyExAl+Xwb+DWcw1CY6fYI95PBG/gnhyG1/GE/yr lBWhApQYCg8ElmAljnPLFwxMJPlT5WPk0sOFeGQ3zq14N9px6eNBhiQ+tjtKpYJzz6kt SSl6BiEWXkc96xRfMcHIm4Gm4E6adOEYtH+LvqIKgBzMXxGiU/8KHpxlNfce4jXFbYCV Gj+x4pJukeQGZfbLtLg1t2aSsty+PPhempC7KwaqGABJzQY7d/3sK2+gOnRyV+bwqvSm s1TsGFOR9s31Zg+7RRpVkJITPue2LQujIjc9EFgcWSk4HlWXYrkJt7dsQoE4ApxChLAQ sRsw== X-Gm-Message-State: ALoCoQlIpZ+HAIrTYN4/kqN92WQXAViJ4qTCtXJuKmbsu+Cqt3Fj4cniXV99jSTQlVDLvHUQeQ3t X-Received: by 10.58.110.74 with SMTP id hy10mr181913veb.52.1398175169455; Tue, 22 Apr 2014 06:59:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 22 Apr 2014 06:59:09 -0700 (PDT) In-Reply-To: <5355E678.8030309@joelhalpern.com> References: <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> From: Jamal Hadi Salim Date: Tue, 22 Apr 2014 09:59:09 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BHu9e83ciljnMd6qElfMkPeSFVo Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 13:59:40 -0000 Sorry Andy - trying to catchup with the threads (and busy elsewhere at the moment) so fast forwarding to this email. I will try to come back later and answer each of your questions probably in a separate email To provide an example to what Joel said: You can augment/extend in two ways. a) Take an existing LFB - keep the name change the class version. Take an existing data structure within that class and extend it. Example (straight out of our regression tests, simplified for clarity): struct foobartype { id 1, foo, uint32; id 2, bar, uint32; } class MyUpgrade id 667 { version 1.0 components { id 1, cbogtabl, array of foobartype; } events { id 1, CBogChanged ... reports cbogtable changes with row } } And later you decide you want to add some new field to foobartype. struct foobartype { id 1, foo, uint32; id 2, bar, uint32; id 3, goo, uint32; } class MyUpgrade id 667 { version 1.1 components { id 1, cbogtable, array of foobartype; } events { id 1, CBogChanged ... reports table changes with new foobartype } } In field upgrades, typically i see that the control piece is first upgraded. The data path follows next incrementally on different nodes. The datapath ignores and logs what it doesnt understand. i.e in such a case, an app sends cbogtable row with goo to version 1 datapath. On inheritance, here's an example of what a linux port would look like: struct portinfo { id 1, name, string[16] id 2, ifindex, uint32 .. .. id 23, ethinfo, struct ethparams } class Port, id 6113 { version 1.0 components { id 1, ports, array of portinfo; } events { ... link, port creation etc .. } capabilities { ......... } } So if i wanted to define a tunnel device, then i take that portinfo struct and derive from it then i create a new class. As an example for tuntap port on Linux: struct tunport { PortInfo id 24,tunflags, uint32, optional id 25, userid, uint32, optional id 26, groupid, uint32, optiona } class tuntap, id 6119 { version 1.0 Port components { id 1, ports, array of tunport; } events { ... link, port creation etc .. } capabilities { ......... } } The XML is reduced greatly. Not sure if i answered the specific question I will respond to your other questions later.. cheers, jamal On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern wrote: > As a minor point, I consider the embedding of file management and business > logic into the core of NetConf was probably a mistake. > ForCES does have version numbers on classes, so if you change an LFB class > definition, you increase the revision. > It also has inheritance, which provides an effective way to define a > coherent extension of a class. > And it explicitly includes indications of which items are required. As well > as providing mechanisms for a controller to determine on a fine grained > basis what an FE actually supports. So we do not have to guess what the > right groupings are for unknown users down the road. > > Yours, > Joel > > On 4/21/14, 6:21 PM, Andy Bierman wrote: >> >> Hi, >> >> Forgot life-cycle issues.... >> There does not appear to be any notion of a module revision in ForCES. >> There does not seem to be any way to identify a particular definition >> as either current, deprecated, or obsolete. >> >> Is a library used with the element ever allowed to change? >> If so, how are new revisions identified? >> >> Is there any text explaining how these modules are allowed to change >> over time? >> Was this considered by the WG? >> >> Andy >> >> >> >> >> >> >> >> >> >> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman > > wrote: >> >> Hi, >> >> >> On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim > > wrote: >> >> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman >> > wrote: >> > >> > I think Jan and others have explained why they think they can >> leverage >> > the NC/RC/YANG technology to implement I2RS. There are tool >> > and data model management requirements in addition to the >> protocol >> > in order to have a workable solution. >> > >> > Unless the RIB data is one monolithic blob implemented without >> > variation on every router, then issues such as modularity, >> conformance >> > model, data lifecycle, distributed naming authority, data >> augmentation, >> > and language extensibility are going to matter. >> > >> >> So lets put all that in a requirement list somewhere and work >> around a gap >> analysis. >> >> >> So how does ForCES support these things? >> Where is the language specification in RFC 5812? >> Section 4 describes LFB classes, which appear to represent the only >> supported data >> for the protocol. Is the entire normative language specification >> contained in the XSD in sec. 4.9? >> >> What happens if multiple elements pull in definitions with the >> same local name? The examples do not show any use of prefixes >> and the element has no prefix mapping. >> >> >> >> > location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> >> >> >> There does not appear to be any conformance information like what is >> mandatory or conditional on a user-defined feature. How are logical >> groups >> of conditional objects defined and advertised in the protocol? >> (e.g., YANG features) >> >> Are there examples of the augmentation described in sec. 4.5.7? >> There does not appear to be any way for 1 module to add elements to >> another >> without controlling the naming for all modules. >> >> How does a vendor implement the unique naming requirements in ForCES >> without controlling the names of all possible ForCES files? Are >> they supposed to >> rewrite modules when a naming collision occurs because modules X and >> Y are being loaded >> into module Z, which causes a new naming collision that did not >> occur before? >> >> YANG supports groupings that can be refined in each use/expansion. >> How are complex statements reused and refined? >> Where are examples of that in the RFC? >> >> >> >> How would I2RS use ? >> >> >> >> ipv4 >> IPv4 packet >> >> This frame type refers to an IPv4 packet. >> >> >> >> ipv6 >> IPv6 packet >> >> This frame type refers to an IPv6 packet. >> >> >> ... >> >> >> >> Is this like a YANG identity statement, except this causes naming >> collisions, >> so it is more like a specialized distributed enumeration type? >> >> >> To compare readability, here are the same type definitions in ForCES >> and YANG: >> >> ForCES: (RFC 5812, pg. 80) >> >> >> accessPermissionValues >> >> The possible values of component access >> permission >> >> >> uchar >> >> >> None >> Access is prohibited >> >> >> Read-Only >> >> Access to the component is read only >> >> >> >> Write-Only >> >> The component MAY be written, but not read >> >> >> >> Read-Write >> >> The component MAY be read or written >> >> >> >> >> >> >> >> YANG: >> >> >> typedef accessPermissionValues { >> >> description >> >> "The possible values of component access permission"; >> >> type enumeration { >> >> enum None { >> >> value 0; >> >> description "Access is prohibited"; >> >> } >> >> enum Read-Only { >> >> value 1; >> >> >> description "Access to the component is read only"; >> >> >> } >> >> enum Write-Only { >> >> >> value 2; >> >> description "The component MAY be written, but not >> read"; >> >> >> } >> >> enum Read-Write { >> >> value 3; >> >> >> description "The component MAY be read or written"; >> >> >> } >> >> } >> >> >> >> } >> >> >> >> >> >> >> How are new protocol operations defined? Are they part of the >> language. >> >> >> How are language extensions done? This does not appear to be >> supported. >> >> How are existence constraints between objects expressed? (e.g., >> must/when/unique) >> >> How does a vendor add arbitrary data to notification events? >> Can event definitions be augmented? >> If so, how is this done so nodes can be conditional? (e.g., >> if-feature, when) >> >> The element is one of many that seems very ForCES >> specific. >> How are new events added? >> >> I don't see an event definition for the "Goof1changed" example: >> >> >> >> >> >> > substitutionGroup="eventCondition"/> >> > substitutionGroup="eventCondition"/> >> > substitutionGroup="eventCondition"/> >> > substitutionGroup="eventCondition"/> >> > substitutionGroup="eventCondition"/> >> >> >> >> >> >> >> > abstract="true"/> >> > substitutionGroup="eventPathPart"/> >> > substitutionGroup="eventPathPart"/> >> >> >> > maxOccurs="unbounded"/> >> >> >> >> >> >> Goof1changed >> >> An example event for a complex structure >> >> >> >> goo >> f1 >> >> >> >> >> >> goo >> f1 >> >> >> >> >> >> I am still confused about the general applicability. >> E.g., how are , used in I2RS? >> >> cheers, >> jamal >> >> >> >> Andy >> >> > From nobody Tue Apr 22 07:19:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948D1A0484 for ; Tue, 22 Apr 2014 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-wB6G8-TVHE for ; Tue, 22 Apr 2014 07:19:38 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 253B71A043B for ; Tue, 22 Apr 2014 07:19:38 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so2585087vcb.26 for ; Tue, 22 Apr 2014 07:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=68BqQt7QWGgZlU55Ura0QffKNwwMrCElwh2Qh816ygY=; b=Cu4F8hL1fZHxG7Xj/B1Mnv8nkwCUShpZfRR9wT/UmXgt516WKQGGRwZEl5BSQ+biNl SwHyDKxTaTf+9WsCf+b1NtwTS/idi0IAJeYKpdygMgIpeIiAtvfNgEB2Tm0NLEu0CvGU 5ZNJU9XNHF3dH/Dnb/FjRo09kw58w7NZpCYg3Csl+417w9904Zx9IA678QQPEQ15KwHJ JRw82/kxOPPRk6ZwweRNJgbU/CxC6uUdcin4ZlAZVK5slJBvR73v6zyozefd16esbrK/ y9FeLyflwgcCG4a1ZaZeWs9PjOHAGH9PtiI+8hVwFdUuchFooAHF5yoH+y6MR8VUIYe/ QZJw== X-Gm-Message-State: ALoCoQlDRYCIGwac2/DW9C+NGPqeXulRMIiBnCAUbnVn7ZIvikZt60gEDo6L77rLt+1zazK9xAHB X-Received: by 10.52.128.84 with SMTP id nm20mr46070vdb.63.1398176372528; Tue, 22 Apr 2014 07:19:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 22 Apr 2014 07:19:12 -0700 (PDT) In-Reply-To: <535655E7.9090405@cisco.com> References: <535655E7.9090405@cisco.com> From: Jamal Hadi Salim Date: Tue, 22 Apr 2014 10:19:12 -0400 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=bcaec51ddbcd04b33a04f7a24ef5 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PixA_9JCTTB0hTrPLVrzJUb208E Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:19:44 -0000 --bcaec51ddbcd04b33a04f7a24ef5 Content-Type: text/plain; charset=ISO-8859-1 So I understand the practical implication of a WG being behind schedule and by no means do i want to contribute to that. One approach that Tom Petch had suggested is to focus on use cases. The idea of what model/protocol is used can be going on in parallel. Input from the use cases is useful to help define what protocol model used. cheers, jamal On Tue, Apr 22, 2014 at 7:43 AM, Benoit Claise wrote: > Dear all, > > I've been spending the last 2 hours reading that full email thread, up to > this time. > Not sure to which email I should reply, so here am I, top posting. > > + 1 on YANG for the data model language. > What counts at the end of the day is a consistent data model language for > configuration, because implementing a proxy for different data model > languages is a pain, time consuming, and error-prone. > Ideally, we should have a consistent information model language, but the > industry/standards are not there yet. Not even sure they will even arrive > there one day. > > Looking at the life cycling of specifying a new language, implementing it, > deploying it, and developing tools around it (I have SMI and YANG in mind), > having a new data model language for I2RS only is not practical. And the > more we wait, the more obvious the solution is. > I know, it's not about a technical argument any longer (those have been > made on the lits already). > Let's look at the WG deliverables: > 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 > > The least we can say is that the WG is late. > I observe that after 1 year and 3 months after the WG creation, we still > don't have the problem statement/architecture/requirements: that explains, > whether we like it or not, why the business reasons are getting more and > more important compared to the technical arguments. > Didn't we see a few comments lately about the IETF not being relevant > because we're too slow? > Maybe the IESG should be stricter: "no problem statement with a year, WG > closed", but I guess I'm diverging :-) > > Once YANG is selected, NETCONF/RESTCONF for the protocol is the next > logical step, even if I believe that in practice, we'll see different > devices speaking different languages. > > Regards, Benoit (as a contributor) > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --bcaec51ddbcd04b33a04f7a24ef5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

So I understand the practical implication o= f a WG being behind schedule
and by no means do i want to contribute to= that.
One approach that Tom Petch had suggested is to focus on u= se cases.
The idea of what model/protocol is used can be going on in parallel. I= nput
from the use cases is useful to help define what protocol mo= del used.

cheers,
jamal




On Tue, Apr 22, 2014 at 7:43 AM, Benoit Claise <bclaise@cisc= o.com> wrote:
=20 =20 =20
Dear all,

I've been spending the last 2 hours reading that full email thread, up to this time.
Not sure to which email I should reply, so here am I, top posting.
+ 1 on YANG for the data model language.
What counts at the end of the day is a consistent data model language for configuration, because implementing a proxy for different data model languages is a pain, time consuming, and error-prone.
Ideally, we should have a consistent information model language, but the industry/standards are not there yet. Not even sure they will even arrive there one day.

Looking at the life cycling of specifying a new language, implementing it, deploying it, and developing tools around it (I have SMI and YANG in mind), having a new data model language for I2RS only is not practical. And the more we wait, the more obvious the solution is.
I know, it's not about a technical argument any longer (those hav= e been made on the lits already).
Let's look at the WG deliverables:
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

The least we can say is that the WG is late.
I observe that after 1 year and 3 months after the WG creation, we still don't have the problem statement/architecture/requirements: that=A0 explains, whether we like it or not, why the=A0 business reasons are getting more and more important compared to the technical arguments.
Didn't we see a few comments lately about the IETF not being relevant because we're too slow?
Maybe the IESG should be stricter: "no problem statement with a year, WG closed", but I guess I'm diverging :-)

Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logical step, even if I believe that in practice, we'll see different devices speaking different languages.

Regards,=A0 Benoit (as a contributor)


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


--bcaec51ddbcd04b33a04f7a24ef5-- From nobody Tue Apr 22 07:24:27 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE921A04AA for ; Tue, 22 Apr 2014 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rd961wC1-n6 for ; Tue, 22 Apr 2014 07:24:21 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC91A049C for ; Tue, 22 Apr 2014 07:24:04 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so384252qga.25 for ; Tue, 22 Apr 2014 07:23:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ItPM6kr76aVg2hH+cWlzpBNvfDKQYvyUH7x2FFmOU+E=; b=Ft4iZeiyU50TuRM2mH8ZughjwaTVqeren1CxA21Q1qK/gR8KR6JG14w3SRzQR9ugHw wGQ6F6ip4wkeIIFZ7ZvnCoOYtYDmlstihueaBjq3WFYTemBcPlW1l3DK13p+1xKGG5RE d1xpFmUy3n4RSr1V+XzF0BMWCNKjO/DBnbIEY+J2O9A5IZnNGGI6mQDXeQV/w3V0rODX Gk8LgowicxhOJF6vwSA8QhYWj/WEQsRe7Dl+LLtxYWY5a2mIXB3P/Qc7wqPglFrkHxor iZsu75CDife7fGPppukSI5yBKvdgI7R1rHSvILh9kuC7mEcjmCRhfzYNz1CAX/V0ujYj b7cQ== X-Gm-Message-State: ALoCoQl8qhgmsBgj42VGq8OJ1yEHHQ+QSuPLKcunGl++0W3A5jP1q3Ti4EjF63MPsYLMHgFRbnVK MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr12051994qge.91.1398176638496; Tue, 22 Apr 2014 07:23:58 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 07:23:58 -0700 (PDT) In-Reply-To: References: <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> Date: Tue, 22 Apr 2014 07:23:58 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a1134f2bedf0ee804f7a25d02 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qD0m_bM7bR8MC8z8FNPvGg_PLf0 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:24:26 -0000 --001a1134f2bedf0ee804f7a25d02 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 22, 2014 at 6:59 AM, Jamal Hadi Salim wrote: > Sorry Andy - trying to catchup with the threads (and busy elsewhere at > the moment) > so fast forwarding to this email. I will try to come back later and answer > each > of your questions probably in a separate email > To provide an example to what Joel said: > You can augment/extend in two ways. > a) Take an existing LFB - keep the name change the class version. > Take an existing data structure within that class and extend it. > Example (straight out of our regression tests, simplified for clarity): > > I will try to relate this back to the RFC. The real syntax is XML and does not look anything like your examples. (If XML was that readable, perhaps you would use the real syntax). I do not understand the conformance model. Does the server claim conformance to a set of { class, version } tuples? How does the client know what versions to expect? ForCES is not really extensible if multiple vendors are defining data because there is 1 giant flat namespace so all data naming has to globally coordinated, or naming collisions can occur: mod1: container foo { } mod2: augment /mod1:foo { leaf X { type string } } mod3: augment /mod1:foo { leaf X { type string } } This is not an error in YANG. It can't be because mod2 and mod3 are from 2 different vendors and they both want to augment the standard module (mod1). Clients that use /mod1:foo/mod2:X do not collide with clients that are using /mod1:foo/mod3:X. Without namespaces, even vendor modules would need to go through a central naming authority like IANA. Andy struct foobartype { > id 1, foo, uint32; > id 2, bar, uint32; > } > > class MyUpgrade id 667 > { > version 1.0 > components { > id 1, cbogtabl, array of foobartype; > } > > events { > id 1, CBogChanged ... reports cbogtable changes with row > } > } > > And later you decide you want to add some new field to foobartype. > > struct foobartype { > id 1, foo, uint32; > id 2, bar, uint32; > id 3, goo, uint32; > } > > class MyUpgrade id 667 > { > version 1.1 > components { > id 1, cbogtable, array of foobartype; > } > events { > id 1, CBogChanged ... reports table changes with new foobartype > } > } > > In field upgrades, typically i see that the control piece is first > upgraded. > The data path follows next incrementally on different nodes. > The datapath ignores and logs what it doesnt understand. i.e in such a > case, > an app sends cbogtable row with goo to version 1 datapath. > > On inheritance, here's an example of what a linux port would look like: > > struct portinfo { > id 1, name, string[16] > id 2, ifindex, uint32 > .. > .. > id 23, ethinfo, struct ethparams > } > > class Port, id 6113 > { > version 1.0 > components { > id 1, ports, array of portinfo; > } > events { > ... link, port creation etc .. > } > capabilities { > ......... > } > } > > So if i wanted to define a tunnel device, then i take that > portinfo struct and derive from it then i create a new class. > As an example for tuntap port on Linux: > > struct tunport { > PortInfo > id 24,tunflags, uint32, optional > id 25, userid, uint32, optional > id 26, groupid, uint32, optiona > } > > class tuntap, id 6119 > { > version 1.0 > Port > components { > id 1, ports, array of tunport; > } > events { > ... link, port creation etc .. > } > capabilities { > ......... > } > } > > > The XML is reduced greatly. > > Not sure if i answered the specific question > > I will respond to your other questions later.. > > cheers, > jamal > > > On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern > wrote: > > As a minor point, I consider the embedding of file management and > business > > logic into the core of NetConf was probably a mistake. > > ForCES does have version numbers on classes, so if you change an LFB > class > > definition, you increase the revision. > > It also has inheritance, which provides an effective way to define a > > coherent extension of a class. > > And it explicitly includes indications of which items are required. As > well > > as providing mechanisms for a controller to determine on a fine grained > > basis what an FE actually supports. So we do not have to guess what the > > right groupings are for unknown users down the road. > > > > Yours, > > Joel > > > > On 4/21/14, 6:21 PM, Andy Bierman wrote: > >> > >> Hi, > >> > >> Forgot life-cycle issues.... > >> There does not appear to be any notion of a module revision in ForCES. > >> There does not seem to be any way to identify a particular definition > >> as either current, deprecated, or obsolete. > >> > >> Is a library used with the element ever allowed to change? > >> If so, how are new revisions identified? > >> > >> Is there any text explaining how these modules are allowed to change > >> over time? > >> Was this considered by the WG? > >> > >> Andy > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman >> > wrote: > >> > >> Hi, > >> > >> > >> On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim < > hadi@mojatatu.com > >> > wrote: > >> > >> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman > >> > wrote: > >> > > >> > I think Jan and others have explained why they think they can > >> leverage > >> > the NC/RC/YANG technology to implement I2RS. There are tool > >> > and data model management requirements in addition to the > >> protocol > >> > in order to have a workable solution. > >> > > >> > Unless the RIB data is one monolithic blob implemented > without > >> > variation on every router, then issues such as modularity, > >> conformance > >> > model, data lifecycle, distributed naming authority, data > >> augmentation, > >> > and language extensibility are going to matter. > >> > > >> > >> So lets put all that in a requirement list somewhere and work > >> around a gap > >> analysis. > >> > >> > >> So how does ForCES support these things? > >> Where is the language specification in RFC 5812? > >> Section 4 describes LFB classes, which appear to represent the only > >> supported data > >> for the protocol. Is the entire normative language specification > >> contained in the XSD in sec. 4.9? > >> > >> What happens if multiple elements pull in definitions with > the > >> same local name? The examples do not show any use of prefixes > >> and the element has no prefix mapping. > >> > >> > >> > >> >> location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml > "/> > >> > >> > >> There does not appear to be any conformance information like what is > >> mandatory or conditional on a user-defined feature. How are logical > >> groups > >> of conditional objects defined and advertised in the protocol? > >> (e.g., YANG features) > >> > >> Are there examples of the augmentation described in sec. 4.5.7? > >> There does not appear to be any way for 1 module to add elements to > >> another > >> without controlling the naming for all modules. > >> > >> How does a vendor implement the unique naming requirements in ForCES > >> without controlling the names of all possible ForCES files? Are > >> they supposed to > >> rewrite modules when a naming collision occurs because modules X and > >> Y are being loaded > >> into module Z, which causes a new naming collision that did not > >> occur before? > >> > >> YANG supports groupings that can be refined in each use/expansion. > >> How are complex statements reused and refined? > >> Where are examples of that in the RFC? > >> > >> > >> > >> How would I2RS use ? > >> > >> > >> > >> ipv4 > >> IPv4 packet > >> > >> This frame type refers to an IPv4 packet. > >> > >> > >> > >> ipv6 > >> IPv6 packet > >> > >> This frame type refers to an IPv6 packet. > >> > >> > >> ... > >> > >> > >> > >> Is this like a YANG identity statement, except this causes naming > >> collisions, > >> so it is more like a specialized distributed enumeration type? > >> > >> > >> To compare readability, here are the same type definitions in ForCES > >> and YANG: > >> > >> ForCES: (RFC 5812, pg. 80) > >> > >> > >> accessPermissionValues > >> > >> The possible values of component access > >> permission > >> > >> > >> uchar > >> > >> > >> None > >> Access is prohibited > >> > >> > >> Read-Only > >> > >> Access to the component is read only > >> > >> > >> > >> Write-Only > >> > >> The component MAY be written, but not > read > >> > >> > >> > >> Read-Write > >> > >> The component MAY be read or written > >> > >> > >> > >> > >> > >> > >> > >> YANG: > >> > >> > >> typedef accessPermissionValues { > >> > >> description > >> > >> "The possible values of component access permission"; > >> > >> type enumeration { > >> > >> enum None { > >> > >> value 0; > >> > >> description "Access is prohibited"; > >> > >> } > >> > >> enum Read-Only { > >> > >> value 1; > >> > >> > >> description "Access to the component is read only"; > >> > >> > >> } > >> > >> enum Write-Only { > >> > >> > >> value 2; > >> > >> description "The component MAY be written, but not > >> read"; > >> > >> > >> } > >> > >> enum Read-Write { > >> > >> value 3; > >> > >> > >> description "The component MAY be read or written"; > >> > >> > >> } > >> > >> } > >> > >> > >> > >> } > >> > >> > >> > >> > >> > >> > >> How are new protocol operations defined? Are they part of the > >> language. > >> > >> > >> How are language extensions done? This does not appear to be > >> supported. > >> > >> How are existence constraints between objects expressed? (e.g., > >> must/when/unique) > >> > >> How does a vendor add arbitrary data to notification events? > >> Can event definitions be augmented? > >> If so, how is this done so nodes can be conditional? (e.g., > >> if-feature, when) > >> > >> The element is one of many that seems very ForCES > >> specific. > >> How are new events added? > >> > >> I don't see an event definition for the "Goof1changed" example: > >> > >> > >> > >> > >> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> > >> > >> > >> > >> > >> > >> >> abstract="true"/> > >> >> substitutionGroup="eventPathPart"/> > >> >> substitutionGroup="eventPathPart"/> > >> > >> > >> >> maxOccurs="unbounded"/> > >> > >> > >> > >> > >> > >> Goof1changed > >> > >> An example event for a complex structure > >> > >> > >> > >> goo > >> f1 > >> > >> > >> > >> > >> > >> goo > >> f1 > >> > >> > >> > >> > >> > >> I am still confused about the general applicability. > >> E.g., how are , used in I2RS? > >> > >> cheers, > >> jamal > >> > >> > >> > >> Andy > >> > >> > > > --001a1134f2bedf0ee804f7a25d02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 22, 2014 at 6:59 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Sorry Andy - trying to catchup with the threads (and busy = elsewhere at
the moment)
so fast forwarding to this email. I will try to come back later and answer = each
of your questions probably in a separate email
To provide an example to what Joel said:
You can augment/extend in two ways.
a) Take an existing LFB - keep the name change the class version.
Take an existing data structure within that class and extend it.
Example (straight out of our regression tests, simplified for clarity):


I will try to relate this back to the = RFC.
The real syntax is XML and does not look anything like your = examples.
(If XML was that readable, perhaps you would use the re= al syntax).

I do not understand the conformance model. =A0Does the = server claim
conformance to a set of { class, version } tuples? H= ow does the
client know what versions to expect?

ForCES is not really extensible if multiple vendors are defining= data because
there is 1 giant flat namespace so all data naming = has to globally
coordinated, or naming collisions can occur:

mod1:

=A0 =A0container foo { }=

mod2:

=A0 =A0augment /mo= d1:foo {
=A0 =A0 =A0 leaf X { type string }
=A0 =A0}

mod3:

=A0 =A0augment /mod1:foo {
=A0 =A0 =A0 leaf X { type string }
=A0 =A0}

This is not an error in YANG.
It can&= #39;t be because mod2 and mod3 are from 2 different vendors
and they both want to augment the standard module (mod1).
Cl= ients that use /mod1:foo/mod2:X do not collide with clients
that = are using /mod1:foo/mod3:X.

Without namespaces, ev= en vendor modules would need to go
through a central naming authority like IANA. =A0

=


Andy


=
struct foobartype {
=A0 id 1, foo, uint32;
=A0 id 2, bar, uint32;
}

class MyUpgrade id 667
{
=A0 version 1.0
=A0 components {
=A0 =A0 id 1, cbogtabl, array of foobartype;
=A0 }

=A0 events {
=A0 =A0 id 1, CBogChanged ... reports =A0cbogtable changes with row
=A0}
}

And later you decide you want to add some new field to foobartype.

struct foobartype {
=A0 id 1, foo, uint32;
=A0 id 2, bar, uint32;
=A0 id 3, goo, uint32;
}

class MyUpgrade id 667
{
=A0 version 1.1
=A0 components {
=A0 =A0 id 1, cbogtable, array of foobartype;
=A0 }
=A0 events {
=A0 =A0 id 1, CBogChanged ... reports table changes with new foobartype
=A0}
}

In field upgrades, typically i see that the =A0control piece is first upgra= ded.
The data path follows next incrementally on different nodes.
The datapath ignores and logs what it doesnt understand. i.e in such a case= ,
an app sends cbogtable row with goo to version 1 datapath.

On inheritance, here's an example of what a linux port would look like:=

struct portinfo {
=A0 id 1, name, string[16]
=A0 id 2, ifindex, uint32
=A0 ..
=A0 ..
=A0 id 23, ethinfo, struct ethparams
}

class Port, id 6113
{
=A0version 1.0
=A0components {
=A0 =A0 id 1, ports, array of portinfo;
=A0 }
=A0 events {
=A0 =A0... link, port creation etc ..
=A0 }
=A0capabilities {
=A0 =A0.........
=A0}
}

So if i wanted to define a tunnel device, then i take that
portinfo struct and derive from it then i create a new class.
As an example for tuntap port on Linux:

struct tunport {
=A0 <derivedFrom>PortInfo</derivedFrom>
=A0 id 24,tunflags, uint32, optional
=A0 id 25, userid, uint32, optional
=A0 id 26, groupid, uint32, optiona
=A0}

class tuntap, id 6119
{
=A0version 1.0
=A0<derivedFrom>Port</derivedFrom>
=A0components {
=A0 =A0 id 1, ports, array of tunport;
=A0 }
=A0 events {
=A0 =A0... link, port creation etc ..
=A0 }
=A0capabilities {
=A0 =A0.........
=A0}
}


The XML is reduced greatly.

Not sure if i answered the specific question

I will respond to your other questions later..

cheers,
jamal


On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> As a minor point, I consider the embedding of file management and busi= ness
> logic into the core of NetConf was probably a mistake.
> ForCES does have version numbers on classes, so if you change an LFB c= lass
> definition, you increase the revision.
> It also has inheritance, which provides an effective way to define a > coherent extension of a class.
> And it explicitly includes indications of which items are required. = =A0As well
> as providing mechanisms for a controller to determine on a fine graine= d
> basis what an FE actually supports. =A0So we do not have to guess what= the
> right groupings are for unknown users down the road.
>
> Yours,
> Joel
>
> On 4/21/14, 6:21 PM, Andy Bierman wrote:
>>
>> Hi,
>>
>> Forgot life-cycle issues....
>> There does not appear to be any notion of a module revision in For= CES.
>> There does not seem to be any way to identify a particular definit= ion
>> as either current, deprecated, or obsolete.
>>
>> Is a library used with the <load> element ever allowed to ch= ange?
>> If so, how are new revisions identified?
>>
>> Is there any text explaining how these modules are allowed to chan= ge
>> over time?
>> Was this considered by the WG?
>>
>> Andy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman <andy@yumaworks.com
>> <mailto:andy@yumaworks.co= m>> wrote:
>>
>> =A0 =A0 Hi,
>>
>>
>> =A0 =A0 On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim <hadi@mojatatu.com
>> =A0 =A0 <mailto:hadi@mojat= atu.com>> wrote:
>>
>> =A0 =A0 =A0 =A0 On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman
>> =A0 =A0 =A0 =A0 <andy@yum= aworks.com <mailto:andy@yumawo= rks.com>> wrote:
>> =A0 =A0 =A0 =A0 =A0>
>> =A0 =A0 =A0 =A0 =A0> I think Jan and others have explained why = they think they can
>> =A0 =A0 =A0 =A0 leverage
>> =A0 =A0 =A0 =A0 =A0> the NC/RC/YANG technology to implement I2R= S. There are tool
>> =A0 =A0 =A0 =A0 =A0> and data model management requirements in = addition to the
>> =A0 =A0 =A0 =A0 protocol
>> =A0 =A0 =A0 =A0 =A0> in order to have a workable solution.
>> =A0 =A0 =A0 =A0 =A0>
>> =A0 =A0 =A0 =A0 =A0> Unless the RIB data is one monolithic blob= implemented without
>> =A0 =A0 =A0 =A0 =A0> variation on every router, then issues suc= h as modularity,
>> =A0 =A0 =A0 =A0 conformance
>> =A0 =A0 =A0 =A0 =A0> model, data lifecycle, distributed naming = authority, data
>> =A0 =A0 =A0 =A0 augmentation,
>> =A0 =A0 =A0 =A0 =A0> and language extensibility are going to ma= tter.
>> =A0 =A0 =A0 =A0 =A0>
>>
>> =A0 =A0 =A0 =A0 So lets put all that in a requirement list somewhe= re and work
>> =A0 =A0 =A0 =A0 around a gap
>> =A0 =A0 =A0 =A0 analysis.
>>
>>
>> =A0 =A0 So how does ForCES support these things?
>> =A0 =A0 Where is the language specification in RFC 5812?
>> =A0 =A0 Section 4 describes LFB classes, which appear to represent= the only
>> =A0 =A0 supported data
>> =A0 =A0 for the protocol. Is the entire normative language specifi= cation
>> =A0 =A0 contained in the XSD in sec. 4.9?
>>
>> =A0 =A0 What happens if multiple <load> elements pull in def= initions with the
>> =A0 =A0 same local name? =A0The examples do not show any use of pr= efixes
>> =A0 =A0 and the <load> element has no prefix mapping.
>>
>> =A0 =A0 =A0 =A0 <load library=3D"a_library"/>
>> =A0 =A0 =A0 =A0 <load library=3D"another_library" loc= ation=3D"another_lib.xml"/>
>> =A0 =A0 =A0 =A0 <load library=3D"yetanother_library"<= br> >> =A0 =A0 =A0 =A0 =A0location=3D"http://www.example.com/f= orces/1.0/lfbmodel/lpm.xml"/>
>>
>>
>> =A0 =A0 There does not appear to be any conformance information li= ke what is
>> =A0 =A0 mandatory or conditional on a user-defined feature. How ar= e logical
>> =A0 =A0 groups
>> =A0 =A0 of conditional objects defined and advertised in the proto= col?
>> =A0 =A0 (e.g., YANG features)
>>
>> =A0 =A0 Are there examples of the augmentation described in sec. 4= .5.7?
>> =A0 =A0 There does not appear to be any way for 1 module to add el= ements to
>> =A0 =A0 another
>> =A0 =A0 <dataTypeDef> without controlling the naming for all= modules.
>>
>> =A0 =A0 How does a vendor implement the unique naming requirements= in ForCES
>> =A0 =A0 without controlling the names of all possible ForCES files= ? =A0Are
>> =A0 =A0 they supposed to
>> =A0 =A0 rewrite modules when a naming collision occurs because mod= ules X and
>> =A0 =A0 Y are being loaded
>> =A0 =A0 into module Z, which causes a new naming collision that di= d not
>> =A0 =A0 occur before?
>>
>> =A0 =A0 YANG supports groupings that can be refined in each use/ex= pansion.
>> =A0 =A0 How are complex <dataTypeDef> statements reused and = refined?
>> =A0 =A0 Where are examples of that in the RFC?
>>
>>
>>
>> =A0 =A0 How would I2RS use <frameDefs>?
>>
>> =A0 =A0 =A0 =A0 =A0<frameDefs>
>> =A0 =A0 =A0 =A0 =A0 <frameDef>
>> =A0 =A0 =A0 =A0 =A0 =A0<name>ipv4</name>
>> =A0 =A0 =A0 =A0 =A0 =A0<synopsis>IPv4 packet</synopsis>= ;
>> =A0 =A0 =A0 =A0 =A0 =A0<description>
>> =A0 =A0 =A0 =A0 =A0 =A0 This frame type refers to an IPv4 packet.<= br> >> =A0 =A0 =A0 =A0 =A0 </description>
>> =A0 =A0 =A0 =A0 =A0</frameDef>
>> =A0 =A0 =A0 =A0 =A0 <frameDef>
>> =A0 =A0 =A0 =A0 =A0 <name>ipv6</name>
>> =A0 =A0 =A0 =A0 =A0 <synopsis>IPv6 packet</synopsis> >> =A0 =A0 =A0 =A0 =A0 <description>
>> =A0 =A0 =A0 =A0 =A0 =A0 This frame type refers to an IPv6 packet.<= br> >> =A0 =A0 =A0 =A0 =A0 </description>
>> =A0 =A0 =A0 =A0 =A0</frameDef>
>> =A0 =A0 =A0 =A0 =A0 ...
>> =A0 =A0 =A0 =A0 </frameDefs>
>>
>>
>> =A0 =A0 Is this like a YANG identity statement, except this causes= naming
>> =A0 =A0 collisions,
>> =A0 =A0 so it is more like a specialized distributed enumeration t= ype?
>>
>>
>> =A0 =A0 To compare readability, here are the same type definitions= in ForCES
>> =A0 =A0 and YANG:
>>
>> =A0 =A0 ForCES: (RFC 5812, pg. 80)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<dataTypeDef>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<name>accessP= ermissionValues</name>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<synopsis> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The possible va= lues of component access
>> permission
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</synopsis> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<atomic>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<baseType>= ;uchar</baseType>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<specialValu= es>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<special= Value value=3D"0">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<nam= e>None</name>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<syn= opsis>Access is prohibited</synopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</specia= lValue>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <specia= lValue value=3D"1">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<nam= e> Read-Only </name>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<syn= opsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Acc= ess to the component is read only
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</sy= nopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</specia= lValue>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<special= Value value=3D"2">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<nam= e>Write-Only</name>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<syn= opsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The= component MAY be written, but not read
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</sy= nopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</specia= lValue>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<special= Value value=3D"3">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<nam= e>Read-Write</name>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<syn= opsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The= component MAY be read or written
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</sy= nopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</specia= lValue>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</specialVal= ues>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</atomic>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</dataTypeDef> >>
>>
>> =A0 =A0 YANG:
>>
>>
>> =A0 =A0 =A0 =A0 =A0typedef accessPermissionValues {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0description
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0"The possible values of component = access permission";
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type enumeration {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enum None {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value 0;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0description "Acces= s is prohibited";
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enum Read-Only {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value 1;
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0description "Acces= s to the component is read only";
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enum Write-Only {
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value 2;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0description "The c= omponent MAY be written, but not
>> read";
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enum Read-Write {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value 3;
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0description "The c= omponent MAY be read or written";
>>
>>
>> =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 How are new protocol operations defined? Are they part of = the
>> language.
>>
>>
>> =A0 =A0 How are language extensions done? This does not appear to = be
>> supported.
>>
>> =A0 =A0 How are existence constraints between objects expressed? (= e.g.,
>> =A0 =A0 must/when/unique)
>>
>> =A0 =A0 How does a vendor add arbitrary data to notification event= s?
>> =A0 =A0 Can event definitions be augmented?
>> =A0 =A0 If so, how is this done so nodes can be conditional? (e.g.= ,
>> =A0 =A0 if-feature, when)
>>
>> =A0 =A0 The <eventCondition> element is one of many that see= ms very ForCES
>> =A0 =A0 specific.
>> =A0 =A0 How are new events added?
>>
>> =A0 =A0 I don't see an event definition for the "Goof1cha= nged" example:
>>
>>
>> =A0 =A0 =A0 =A0 =A0</xsd:complexType>
>> =A0 =A0 =A0 =A0 =A0 =A0<!-- the substitution group for the even= t conditions -->
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventCondition= " abstract=3D"true"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventCreated&q= uot;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substitutionGroup= =3D"eventCondition"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventDeleted&q= uot;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substitutionGroup= =3D"eventCondition"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventChanged&q= uot;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substitutionGroup= =3D"eventCondition"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventGreaterTh= an"
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substitutionGroup= =3D"eventCondition"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventLessThan&= quot;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substitutionGroup= =3D"eventCondition"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:complexType name=3D"eventPathT= ype">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<xsd:sequence>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xsd:element ref=3D"eventPa= thPart" maxOccurs=3D"unbounded"/>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</xsd:sequence>
>> =A0 =A0 =A0 =A0 =A0 =A0</xsd:complexType>
>> =A0 =A0 =A0 =A0 =A0 =A0<!-- the substitution group for the even= t path parts -->
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventPathPart&= quot; type=3D"xsd:string"
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 abstract=3D"t= rue"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventField&quo= t; type=3D"xsd:string"
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 substitutionGroup= =3D"eventPathPart"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventSubscript= " type=3D"xsd:string"
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 substitutionGroup= =3D"eventPathPart"/>
>> =A0 =A0 =A0 =A0 =A0 =A0<xsd:complexType name=3D"eventRepor= tsType">
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<xsd:sequence>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<xsd:element name=3D"eventR= eport" type=3D"eventPathType"
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maxOccurs= =3D"unbounded"/>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</xsd:sequence>
>> =A0 =A0 =A0 =A0 =A0 =A0</xsd:complexType>
>>
>>
>> =A0 =A0 =A0 =A0<event eventID=3D"8">
>> =A0 =A0 =A0 =A0 =A0 =A0<name>Goof1changed</name>
>> =A0 =A0 =A0 =A0 =A0 =A0<synopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0An example event for a complex stru= cture
>> =A0 =A0 =A0 =A0 =A0 =A0</synopsis>
>> =A0 =A0 =A0 =A0 =A0 =A0<eventTarget>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<!-- target is goo.f1 -->
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<eventField>goo</eventField>= ;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<eventField>f1</eventField>=
>> =A0 =A0 =A0 =A0 =A0 =A0</eventTarget>
>> =A0 =A0 =A0 =A0 =A0 =A0<eventChanged/>
>> =A0 =A0 =A0 =A0 =A0 =A0<eventReports>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<!-- report the new state of goo.f1 = -->
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<eventReport>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<eventField>goo</eventField>= ;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<eventField>f1</eventField>=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</eventReport>
>> =A0 =A0 =A0 =A0 =A0 =A0</eventReports>
>> =A0 =A0 =A0 =A0 =A0</event>
>>
>>
>> =A0 =A0 I am still confused about the <metadataDefs> general= applicability.
>> =A0 =A0 E.g., how are <inputPorts>, <outputPorts> used= in I2RS?
>>
>> =A0 =A0 =A0 =A0 cheers,
>> =A0 =A0 =A0 =A0 jamal
>>
>>
>>
>> =A0 =A0 Andy
>>
>>
>

--001a1134f2bedf0ee804f7a25d02-- From nobody Tue Apr 22 07:28:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5661A04C2 for ; Tue, 22 Apr 2014 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwgzIJMhEkES for ; Tue, 22 Apr 2014 07:28:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2391A04BA for ; Tue, 22 Apr 2014 07:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F174F1C04AE; Tue, 22 Apr 2014 07:28:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 91B871C04A8; Tue, 22 Apr 2014 07:28:18 -0700 (PDT) Message-ID: <53567C7D.6040809@joelhalpern.com> Date: Tue, 22 Apr 2014 10:28:13 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman , Jamal Hadi Salim References: <02a101cf5bfa$1c705830$55510890$@riw.us> <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uLzOf6APnYfJ69hlPG9RYuqniao Cc: Russ White , "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:28:32 -0000 Since ForCES name space is per-lfb-class. So that the collision problem is mostly in the naming of the lfb classes. (Some care is needed in the naming of data types and such, but it is pretty easy to do that in a colission avoiding fashion. The harder problem, which applies equally to NetConf and ForCES, is to know when you can reuse an existing definition and when you need your own.) Note that the protocol on the wire does not use the names at all, but only the assigned identifiers. Which are registered precisely to avoid collision. Yours, Joel On 4/22/14, 10:23 AM, Andy Bierman wrote: > > > > On Tue, Apr 22, 2014 at 6:59 AM, Jamal Hadi Salim > wrote: > > Sorry Andy - trying to catchup with the threads (and busy elsewhere at > the moment) > so fast forwarding to this email. I will try to come back later and > answer each > of your questions probably in a separate email > To provide an example to what Joel said: > You can augment/extend in two ways. > a) Take an existing LFB - keep the name change the class version. > Take an existing data structure within that class and extend it. > Example (straight out of our regression tests, simplified for clarity): > > > I will try to relate this back to the RFC. > The real syntax is XML and does not look anything like your examples. > (If XML was that readable, perhaps you would use the real syntax). > > I do not understand the conformance model. Does the server claim > conformance to a set of { class, version } tuples? How does the > client know what versions to expect? > > ForCES is not really extensible if multiple vendors are defining data > because > there is 1 giant flat namespace so all data naming has to globally > coordinated, or naming collisions can occur: > > mod1: > > container foo { } > > mod2: > > augment /mod1:foo { > leaf X { type string } > } > > mod3: > > augment /mod1:foo { > leaf X { type string } > } > > > This is not an error in YANG. > It can't be because mod2 and mod3 are from 2 different vendors > and they both want to augment the standard module (mod1). > Clients that use /mod1:foo/mod2:X do not collide with clients > that are using /mod1:foo/mod3:X. > > Without namespaces, even vendor modules would need to go > through a central naming authority like IANA. > > > > Andy > > > struct foobartype { > id 1, foo, uint32; > id 2, bar, uint32; > } > > class MyUpgrade id 667 > { > version 1.0 > components { > id 1, cbogtabl, array of foobartype; > } > > events { > id 1, CBogChanged ... reports cbogtable changes with row > } > } > > And later you decide you want to add some new field to foobartype. > > struct foobartype { > id 1, foo, uint32; > id 2, bar, uint32; > id 3, goo, uint32; > } > > class MyUpgrade id 667 > { > version 1.1 > components { > id 1, cbogtable, array of foobartype; > } > events { > id 1, CBogChanged ... reports table changes with new foobartype > } > } > > In field upgrades, typically i see that the control piece is first > upgraded. > The data path follows next incrementally on different nodes. > The datapath ignores and logs what it doesnt understand. i.e in such > a case, > an app sends cbogtable row with goo to version 1 datapath. > > On inheritance, here's an example of what a linux port would look like: > > struct portinfo { > id 1, name, string[16] > id 2, ifindex, uint32 > .. > .. > id 23, ethinfo, struct ethparams > } > > class Port, id 6113 > { > version 1.0 > components { > id 1, ports, array of portinfo; > } > events { > ... link, port creation etc .. > } > capabilities { > ......... > } > } > > So if i wanted to define a tunnel device, then i take that > portinfo struct and derive from it then i create a new class. > As an example for tuntap port on Linux: > > struct tunport { > PortInfo > id 24,tunflags, uint32, optional > id 25, userid, uint32, optional > id 26, groupid, uint32, optiona > } > > class tuntap, id 6119 > { > version 1.0 > Port > components { > id 1, ports, array of tunport; > } > events { > ... link, port creation etc .. > } > capabilities { > ......... > } > } > > > The XML is reduced greatly. > > Not sure if i answered the specific question > > I will respond to your other questions later.. > > cheers, > jamal > > > On Mon, Apr 21, 2014 at 11:48 PM, Joel M. Halpern > > wrote: > > As a minor point, I consider the embedding of file management and > business > > logic into the core of NetConf was probably a mistake. > > ForCES does have version numbers on classes, so if you change an > LFB class > > definition, you increase the revision. > > It also has inheritance, which provides an effective way to define a > > coherent extension of a class. > > And it explicitly includes indications of which items are > required. As well > > as providing mechanisms for a controller to determine on a fine > grained > > basis what an FE actually supports. So we do not have to guess > what the > > right groupings are for unknown users down the road. > > > > Yours, > > Joel > > > > On 4/21/14, 6:21 PM, Andy Bierman wrote: > >> > >> Hi, > >> > >> Forgot life-cycle issues.... > >> There does not appear to be any notion of a module revision in > ForCES. > >> There does not seem to be any way to identify a particular > definition > >> as either current, deprecated, or obsolete. > >> > >> Is a library used with the element ever allowed to change? > >> If so, how are new revisions identified? > >> > >> Is there any text explaining how these modules are allowed to change > >> over time? > >> Was this considered by the WG? > >> > >> Andy > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Apr 21, 2014 at 2:44 PM, Andy Bierman > > >> >> wrote: > >> > >> Hi, > >> > >> > >> On Mon, Apr 21, 2014 at 8:10 AM, Jamal Hadi Salim > > >> >> wrote: > >> > >> On Mon, Apr 21, 2014 at 10:54 AM, Andy Bierman > >> > >> wrote: > >> > > >> > I think Jan and others have explained why they think > they can > >> leverage > >> > the NC/RC/YANG technology to implement I2RS. There > are tool > >> > and data model management requirements in addition to the > >> protocol > >> > in order to have a workable solution. > >> > > >> > Unless the RIB data is one monolithic blob > implemented without > >> > variation on every router, then issues such as > modularity, > >> conformance > >> > model, data lifecycle, distributed naming authority, data > >> augmentation, > >> > and language extensibility are going to matter. > >> > > >> > >> So lets put all that in a requirement list somewhere and > work > >> around a gap > >> analysis. > >> > >> > >> So how does ForCES support these things? > >> Where is the language specification in RFC 5812? > >> Section 4 describes LFB classes, which appear to represent > the only > >> supported data > >> for the protocol. Is the entire normative language specification > >> contained in the XSD in sec. 4.9? > >> > >> What happens if multiple elements pull in definitions > with the > >> same local name? The examples do not show any use of prefixes > >> and the element has no prefix mapping. > >> > >> > >> > >> >> > location="http://www.example.com/forces/1.0/lfbmodel/lpm.xml"/> > >> > >> > >> There does not appear to be any conformance information like > what is > >> mandatory or conditional on a user-defined feature. How are > logical > >> groups > >> of conditional objects defined and advertised in the protocol? > >> (e.g., YANG features) > >> > >> Are there examples of the augmentation described in sec. 4.5.7? > >> There does not appear to be any way for 1 module to add > elements to > >> another > >> without controlling the naming for all modules. > >> > >> How does a vendor implement the unique naming requirements > in ForCES > >> without controlling the names of all possible ForCES files? Are > >> they supposed to > >> rewrite modules when a naming collision occurs because > modules X and > >> Y are being loaded > >> into module Z, which causes a new naming collision that did not > >> occur before? > >> > >> YANG supports groupings that can be refined in each > use/expansion. > >> How are complex statements reused and refined? > >> Where are examples of that in the RFC? > >> > >> > >> > >> How would I2RS use ? > >> > >> > >> > >> ipv4 > >> IPv4 packet > >> > >> This frame type refers to an IPv4 packet. > >> > >> > >> > >> ipv6 > >> IPv6 packet > >> > >> This frame type refers to an IPv6 packet. > >> > >> > >> ... > >> > >> > >> > >> Is this like a YANG identity statement, except this causes > naming > >> collisions, > >> so it is more like a specialized distributed enumeration type? > >> > >> > >> To compare readability, here are the same type definitions > in ForCES > >> and YANG: > >> > >> ForCES: (RFC 5812, pg. 80) > >> > >> > >> accessPermissionValues > >> > >> The possible values of component access > >> permission > >> > >> > >> uchar > >> > >> > >> None > >> Access is > prohibited > >> > >> > >> Read-Only > >> > >> Access to the component is read only > >> > >> > >> > >> Write-Only > >> > >> The component MAY be written, but > not read > >> > >> > >> > >> Read-Write > >> > >> The component MAY be read or written > >> > >> > >> > >> > >> > >> > >> > >> YANG: > >> > >> > >> typedef accessPermissionValues { > >> > >> description > >> > >> "The possible values of component access permission"; > >> > >> type enumeration { > >> > >> enum None { > >> > >> value 0; > >> > >> description "Access is prohibited"; > >> > >> } > >> > >> enum Read-Only { > >> > >> value 1; > >> > >> > >> description "Access to the component is > read only"; > >> > >> > >> } > >> > >> enum Write-Only { > >> > >> > >> value 2; > >> > >> description "The component MAY be written, > but not > >> read"; > >> > >> > >> } > >> > >> enum Read-Write { > >> > >> value 3; > >> > >> > >> description "The component MAY be read or > written"; > >> > >> > >> } > >> > >> } > >> > >> > >> > >> } > >> > >> > >> > >> > >> > >> > >> How are new protocol operations defined? Are they part of the > >> language. > >> > >> > >> How are language extensions done? This does not appear to be > >> supported. > >> > >> How are existence constraints between objects expressed? (e.g., > >> must/when/unique) > >> > >> How does a vendor add arbitrary data to notification events? > >> Can event definitions be augmented? > >> If so, how is this done so nodes can be conditional? (e.g., > >> if-feature, when) > >> > >> The element is one of many that seems very > ForCES > >> specific. > >> How are new events added? > >> > >> I don't see an event definition for the "Goof1changed" example: > >> > >> > >> > >> > >> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> >> substitutionGroup="eventCondition"/> > >> > >> > >> maxOccurs="unbounded"/> > >> > >> > >> > >> >> abstract="true"/> > >> >> substitutionGroup="eventPathPart"/> > >> >> substitutionGroup="eventPathPart"/> > >> > >> > >> >> maxOccurs="unbounded"/> > >> > >> > >> > >> > >> > >> Goof1changed > >> > >> An example event for a complex structure > >> > >> > >> > >> goo > >> f1 > >> > >> > >> > >> > >> > >> goo > >> f1 > >> > >> > >> > >> > >> > >> I am still confused about the general > applicability. > >> E.g., how are , used in I2RS? > >> > >> cheers, > >> jamal > >> > >> > >> > >> Andy > >> > >> > > > > From nobody Tue Apr 22 07:31:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D411A023E for ; Tue, 22 Apr 2014 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uNU_uZxGOeb for ; Tue, 22 Apr 2014 07:30:53 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) by ietfa.amsl.com (Postfix) with ESMTP id 257BC1A0267 for ; Tue, 22 Apr 2014 07:30:53 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s3MDuxKD008614; Tue, 22 Apr 2014 07:30:44 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1kdmyur64x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Apr 2014 07:30:44 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 22 Apr 2014 07:30:43 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Tue, 22 Apr 2014 07:30:43 -0700 From: ramki Krishnan To: Jamal Hadi Salim , Juergen Schoenwaelder , "Joel M. Halpern" , Andy Bierman , Russ White , "i2rs@ietf.org" , "Jan Medved (jmedved)" , Dean Bogdanovic , Edward Crabbe Date: Tue, 22 Apr 2014 07:30:42 -0700 Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: Ac9eNVSE9A+lToEORP29QH4UlQASzAAAAxhQ Message-ID: References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-22_05:2014-04-22,2014-04-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404220191 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fkzAZEE4IjREMnnSMdpBmWLg9vc Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:30:58 -0000 My point is that it is good to have an empirical performance comparison (wh= ich would mean everything is apple-to-apple including setup, use case etc.)= between Netconf and FORCES given that both the protocols have been in exis= tence for a while.=20 I agree that there may be some flaws in this particular comparison between = SNMP and Netconf. I couldn't find anything else which is easily publicly av= ailable; if you have any better publicly available reference, please sugges= t. Thanks, Ramki -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@mojatatu.com]=20 Sent: Tuesday, April 22, 2014 7:15 AM To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman; J= amal Hadi Salim; Russ White; i2rs@ietf.org; Jan Medved (jmedved); Dean Bogd= anovic; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model I see a different flaw just from the first few pages and looking at the con= clusion. Sorry - didnt have time to look at the whole thing. The paper picks a model entity of about 90% strings (theres one "int" iirc)= . I am not sure what that was supposed to emulate. From that perspective the = question answered to me seems to be "how bad does SNMP do when you have mos= tly strings?". It seemed to do fairly well at the end. I liked the fact the= y tried to batch things with SNMP. If i was emulating what I2RS is doing by building on say the RIB model, it = will not be 90% ascii on the wire for SNMP. Agree with Juergen on apple-apple comparison needed. cheers, jamal On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: > >> It would be good to have an empirical performance analysis of Netconf=20 >> vs FORCES; this would substantiate performance advantages, if any, of=20 >> either protocol. The following reference provides a reasonable=20 >> empirical performance analysis of Netconf vs SNMP -=20 >> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. > > I believe this comparison is flawed. ncclient uses a pure Python=20 > implementation of SSH while the authors used a Python wrapper around=20 > NET-SNMP (a C implementation) to measure SNMP performance. And the=20 > authors state that they used SNMPv2c (no security) and SSH as the=20 > NETCONF transport. (It is also unclear whether all NETCONF=20 > transactions were executed over a single session or multiple > sessions.) > > The design of such experiments is not as easy as it may look at first=20 > glance and it is in particular important to use comparable security=20 > algorithms (ideally the same crypto library). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Tue Apr 22 07:44:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF891A04FA for ; Tue, 22 Apr 2014 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2qeX-nE_Anv for ; Tue, 22 Apr 2014 07:44:50 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id E4F761A04E9 for ; Tue, 22 Apr 2014 07:44:49 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so5467312qcx.18 for ; Tue, 22 Apr 2014 07:44:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/aMetRDsqnBIV5kCcHpVXzFd6aKSXZJMlYK4iWIdDE4=; b=OFvfRK69iUbPeqOWNwRw8wlpIKJ+EV3+yjaJlDvWZqL3eSBe8VKNInFW7GPBWWzOYe BySUe3EFyPC2fb7W3oCsip3Kc6sajfQtTeoieWAMZX5raDN9XTyRw11+5hvG5itB6Sj9 jcXi1Fki6Uv/bdM317pznySb5QjWNIqsnG6OBTc1F44KIpx8vQuAIU9ARcQjNgqvmzL+ ZdGAyzsb6GUCMoW0ScVvlsl1bOI/GSj4qvELGiSaYm7afRQrGCbammk5kaSqMQJ3Pa08 fzwZj9JN72Nnw3xv1QJpO3k2cgyMDUNmUZPGOqJssqg+Bf7ykxONRQ7gbptYQj60GNM0 c7eg== X-Gm-Message-State: ALoCoQld8ijiU953hP5bHjiKWs1Y3HLj/xUGQeAFMG48Box3KEUzOK/XY7C4OeZ8PRO7w7v3yHEP MIME-Version: 1.0 X-Received: by 10.229.230.68 with SMTP id jl4mr49027878qcb.2.1398177884173; Tue, 22 Apr 2014 07:44:44 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 07:44:44 -0700 (PDT) In-Reply-To: References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> Date: Tue, 22 Apr 2014 07:44:44 -0700 Message-ID: From: Andy Bierman To: ramki Krishnan Content-Type: multipart/alternative; boundary=001a11347e9c1e8e0204f7a2a87d Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GQpqhKWx9437fyyqHHb7Kal91xM Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Juergen Schoenwaelder , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:44:55 -0000 --001a11347e9c1e8e0204f7a2a87d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 22, 2014 at 7:30 AM, ramki Krishnan wrote: > My point is that it is good to have an empirical performance comparison > (which would mean everything is apple-to-apple including setup, use case > etc.) between Netconf and FORCES given that both the protocols have been in > existence for a while. > > It would be good to have a pointer to implementations, open-source tools, tutorials, etc. The NETCONF WG maintains a wiki to help provide this information: http://trac.tools.ietf.org/wg/netconf/trac/wiki Benoit asked at the London meeting, "where is this list for ForCES?" We still have not heard an answer. I agree that there may be some flaws in this particular comparison between > SNMP and Netconf. I couldn't find anything else which is easily publicly > available; if you have any better publicly available reference, please > suggest. > > Thanks, > Ramki > > Andy > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Tuesday, April 22, 2014 7:15 AM > To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman; > Jamal Hadi Salim; Russ White; i2rs@ietf.org; Jan Medved (jmedved); Dean > Bogdanovic; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model > > I see a different flaw just from the first few pages and looking at the > conclusion. > Sorry - didnt have time to look at the whole thing. > The paper picks a model entity of about 90% strings (theres one "int" > iirc). > I am not sure what that was supposed to emulate. From that perspective the > question answered to me seems to be "how bad does SNMP do when you have > mostly strings?". It seemed to do fairly well at the end. I liked the fact > they tried to batch things with SNMP. > If i was emulating what I2RS is doing by building on say the RIB model, it > will not be 90% ascii on the wire for SNMP. > > Agree with Juergen on apple-apple comparison needed. > > cheers, > jamal > > > On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: > > > >> It would be good to have an empirical performance analysis of Netconf > >> vs FORCES; this would substantiate performance advantages, if any, of > >> either protocol. The following reference provides a reasonable > >> empirical performance analysis of Netconf vs SNMP - > >> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. > > > > I believe this comparison is flawed. ncclient uses a pure Python > > implementation of SSH while the authors used a Python wrapper around > > NET-SNMP (a C implementation) to measure SNMP performance. And the > > authors state that they used SNMPv2c (no security) and SSH as the > > NETCONF transport. (It is also unclear whether all NETCONF > > transactions were executed over a single session or multiple > > sessions.) > > > > The design of such experiments is not as easy as it may look at first > > glance and it is in particular important to use comparable security > > algorithms (ideally the same crypto library). > > > > /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 > --001a11347e9c1e8e0204f7a2a87d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 22, 2014 at 7:30 AM, ramki Krishnan &= lt;ramk@brocade.com> wrote:
My point is that it is good to have an empirical performan= ce comparison (which would mean everything is apple-to-apple including setu= p, use case etc.) between Netconf and FORCES given that both the protocols = have been in existence for a while.


It would be good to have a pointer to = implementations, open-source tools, tutorials, etc.

The NETCONF WG maintains a wiki to help provide this information:

Benoit a= sked at the London meeting, "where is this list for ForCES?"
We still have not heard an answer.


=
I agree that there may be some flaws in this particular comparison between = SNMP and Netconf. I couldn't find anything else which is easily publicl= y available; if you have any better publicly available reference, please su= ggest.

Thanks,
Ramki



Andy
=A0
-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@mo= jatatu.com]
Sent: Tuesday, April 22, 2014 7:15 AM
To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman; J= amal Hadi Salim; Russ White; i2rs@ietf.org= ; Jan Medved (jmedved); Dean Bogdanovic; Edward Crabbe
Subject: Re: [i2rs] consensus on I2RS protocol and model

I see a different flaw just from the first few pages and looking at the con= clusion.
Sorry - didnt have time to look at the whole thing.
The paper picks a model entity of about 90% strings (theres one "int&q= uot; iirc).
I am not sure what that was supposed to emulate. From that perspective the = question answered to me seems to be "how bad does SNMP do when you hav= e mostly strings?". It seemed to do fairly well at the end. I liked th= e fact they tried to batch things with SNMP.
If i was emulating what I2RS is doing by building on say the RIB model, it = will not be 90% ascii on the wire for SNMP.

Agree with Juergen on apple-apple comparison needed.

cheers,
jamal


On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.d= e> wrote:
> On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote:
>
>> It would be good to have an empirical performance analysis of Netc= onf
>> vs FORCES; this would substantiate performance advantages, if any,= of
>> either protocol. The following reference provides a reasonable
>> empirical performance analysis of Netconf vs SNMP -
>> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvs= SNMP.pdf.
>
> I believe this comparison is flawed. ncclient uses a pure Python
> implementation of SSH while the authors used a Python wrapper around > NET-SNMP (a C implementation) to measure SNMP performance. And the
> authors state that they used SNMPv2c (no security) and SSH as the
> NETCONF transport. (It is also unclear whether all NETCONF
> transactions were executed over a single session or multiple
> sessions.)
>
> The design of such experiments is not as easy as it may look at first<= br> > glance and it is in particular important to use comparable security > algorithms (ideally the same crypto library).
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> 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

--001a11347e9c1e8e0204f7a2a87d-- From nobody Tue Apr 22 08:08:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8A1A064D for ; Tue, 22 Apr 2014 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrB4lCpyUGD1 for ; Tue, 22 Apr 2014 08:08:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DB0411A064B for ; Tue, 22 Apr 2014 08:08:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 89A7FC29E; Tue, 22 Apr 2014 11:08:29 -0400 (EDT) Date: Tue, 22 Apr 2014 11:08:29 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140422150829.GN8955@pfrc> References: <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HlWgy5z5qRuoyM8CeiMpve--oQc Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , "Jan Medved \(jmedved\)" , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:08:40 -0000 Jamal, On Tue, Apr 22, 2014 at 09:21:14AM -0400, Jamal Hadi Salim wrote: > On Mon, Apr 21, 2014 at 3:02 PM, Jeffrey Haas wrote: > > It may not be the primary deciding criterion but it will > > certainly be a big one given the high-throughput desires we have for I2RS. > > > > Do you see a whole BGP table (or larger) being injected/dumped via I2RS? I can definitely see such a case, although the more likely paradigm is injecting a large number of RIB entries that may have some BGP properties, such as communities or inputs to various BGP-like policy mechanisms. > > but I'm happy to provide wiki space for these things to be enumerated. > > > > That would be nice. I have created stubs in the wiki for such comparisons. Would you mind starting the work for FORCES? http://wiki.tools.ietf.org/wg/i2rs/trac/wiki You will require a datatracker login. If you run into issues with editing, please unicast me. This is the first time I'll have done more than editing it myself. If someone is willing to start stubbing in similar items for Netconf/Yang, that would be helpful. > On compute: > I would expect json to perform better than XML when sending to a browser. While I think that detail is true, I suspect a browser is not the first order consumer of the information. > In particular given that json is a native format to javascript (but > also heard of > some decent C/python parsers). If you extended that thought to binary data > it will likely perform better than json to an I2RS agent because > it is closer to the native format of the I2RS agent ( a lot less > translation needed). My general experience with such things is that JSON does fine when you want to pass around JavaScript native data, but that you lose some of the semantic layering in turning things into JavaScript. My personal preference would be that if we provide JSON layers that they effectively be at the far end of the pipe (UI facing) rather than the native object in-protocol. Obviously such details are discussion points and the above is simply my opinion and experience. > String processing may be alleviated with newer instruction sets that > processor vendors are putting out (glibc uses some of the SSE > instructions on x864 when > available to do things like strcmp) - but that still will not give you > the 3-5% difference > claimed. There's also a bunch of vendors who would sell you xml or > string processing > offload. But i wouldnt call that commodity or depend on that when > defining wire format. While certainly not a constraint on the working group, I tend to remember that we want I2RS to be as pervasive as possible. This means that anything we can make work well on older platforms means it's more likely to be supported across a wide range of devices. This has impact, for example, on crypto load. [Several other good points that should be in the wiki entry elided.] > Should be noted that it is not just about compute resources, but also > network resources. > If i send 1000 RIB components in ascii (doesnt matter whether it is > json or xml) vs > the same amount in binary; i would expect the wire resources to be > several magnitudes > better with binary. It will also be a lot closer to native format the > RIB manager > uses. Same with sending XML vs json to a browser - json is a native > format to javascript > and a lot more compact, therefore will perform better. > Wire performance can be improved by the classical technique of using compression > on the wire. That adds cost to the cost of compute. I think I made this observation at the last IETF session: Even for simple compression, XML tends to compress *very* nicely with small dictionaries. Since HTTP compression is well deployed, I suspect this isn't quite as big a deal as it could be. Of course, that presumes we're layering on top of something HTTP-like. > > But an (IMO) advantage of text-based systems is that it's pretty trivial to > > do a lot of things. > > This is true. The cost may be extensibility as i said above. > Note: most of the time the arguement ive heard for ascii is it is > useful for the operator > for debugging - which clearly not true considering the wire format is always > encrypted. This may have been true for smtp or early days of http - but clearly > not true for the domain we are talking about. It's pretty common to either tap before or after the transport APIs for debugging. I think the distintion is that in something text-like you can tap and do thinks potentially simpler than if you have to look at binary PDUs. That requires tapping one level back before the binary marshalling layer. Obviously that is doable as well, but simply moves the point of complexity one layer up/down. > >I suspect I'm not the only one that uses text-based > > expansions of binary objects for various work. (And I'll also note that I > > leave things in binary format with API access when it makes sense.) > > > > What I'm really saying is that the ecosystem is likely to expand binary > > encoding to text just as much as it's going to move to a binary encoding. > > > > I am juggling that in my head and not seeing going ascii from binary. To offer a somewhat BGP network operations example, those who use the MRT file format (RFC 6396) typically have programs that convert from/to that format in human-readable form. Some users may use binary API to interact with the files but the majority of operators I've interacted with that use it tend to simply transform it to ASCII and Do Something Clever using their favorite scripting language. > So my take on this is: > Lets have the informational description of what I2RS needs - perhaps > by going over > use cases. It is easy to provide the ForCES view of those model. I've left a stub in the wiki for helping to derive or map requirements. -- Jeff From nobody Tue Apr 22 08:19:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552EA1A04E8 for ; Tue, 22 Apr 2014 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ1M7SY1_4-3 for ; Tue, 22 Apr 2014 08:19:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A14691A04C8 for ; Tue, 22 Apr 2014 08:19:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 69A78C1ED; Tue, 22 Apr 2014 11:19:10 -0400 (EDT) Date: Tue, 22 Apr 2014 11:19:10 -0400 From: Jeffrey Haas To: Joel Halpern Direct Message-ID: <20140422151910.GP8955@pfrc> References: <5355E678.8030309@joelhalpern.com> <53567C7D.6040809@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53567C7D.6040809@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JUgr0LHZqR9XH5zzVfGMVflge0g Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:19:17 -0000 Joel, On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote: > Since ForCES name space is per-lfb-class. So that the collision > problem is mostly in the naming of the lfb classes. (Some care is > needed in the naming of data types and such, but it is pretty easy > to do that in a colission avoiding fashion. The harder problem, > which applies equally to NetConf and ForCES, is to know when you can > reuse an existing definition and when you need your own.) I'm still working my way through my FORCES reading. It would be very helpful to see an example of this. To offer an example from netconf that I commented upon at various WG sessions, a RIB entry will tend to consist of things that are common across implementations (prefix, nexthop[s], source protocol) and may be augmented by either protocol-specific components (AS_PATH, communities for BGP; metric for IGP) or vendor-specific ones (weight, administrative distance, etc.) In YANG, this is mostly a matter of just decorating with additional XML elements around the core objects. (I'm over-generalizing.) How does one do this in FORCES? > Note that the protocol on the wire does not use the names at all, > but only the assigned identifiers. Which are registered precisely > to avoid collision. One of my lesser concerns here is that code point registries provide another pivot for coordinating development work, in or out of IETF. Arguably, XML token names have the same sort of issue to some extent, but tend not to be "last code point +1". -- Jeff From nobody Tue Apr 22 08:23:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E04A1A065C for ; Tue, 22 Apr 2014 08:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 547pr-Zm7BjJ for ; Tue, 22 Apr 2014 08:23:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5652A1A0640 for ; Tue, 22 Apr 2014 08:23:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 21684C1ED; Tue, 22 Apr 2014 11:23:09 -0400 (EDT) Date: Tue, 22 Apr 2014 11:23:09 -0400 From: Jeffrey Haas To: Benoit Claise Message-ID: <20140422152309.GQ8955@pfrc> References: <535655E7.9090405@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535655E7.9090405@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Tg0Scxwpl7JluFr_-9eZnAM5jGY Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:23:17 -0000 Benoit, On Tue, Apr 22, 2014 at 01:43:35PM +0200, Benoit Claise wrote: > The least we can say is that the WG is late. Indeed. :-) > I observe that after 1 year and 3 months after the WG creation, we > still don't have the problem statement/architecture/requirements: I've been told that we should see an update to the architecture and problem statement soon. The intention is to push for final review in WGLC to get that work completed. The requirements are, in many cases, covered in the various use case documents. Sue has volunteered to try to excerpt the common requirements from the documents she's shepherding to derive a common requirements set. A space has been set aside on the WG wiki for this. Please feel free to help populate it: http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/UseCaseRequirementsEnumeration -- Jeff From nobody Tue Apr 22 08:42:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3061A059F for ; Tue, 22 Apr 2014 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzfPBA99ja36 for ; Tue, 22 Apr 2014 08:42:18 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 797E71A03F0 for ; Tue, 22 Apr 2014 08:42:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 69D031C0AA4; Tue, 22 Apr 2014 08:42:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E7C8C1C0768; Tue, 22 Apr 2014 08:42:11 -0700 (PDT) Message-ID: <53568DCD.1070004@joelhalpern.com> Date: Tue, 22 Apr 2014 11:42:05 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jeffrey Haas References: <5355E678.8030309@joelhalpern.com> <53567C7D.6040809@joelhalpern.com> <20140422151910.GP8955@pfrc> In-Reply-To: <20140422151910.GP8955@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/baU8DMukOM_24FRv_TZdNPmm3Zo Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Andy Bierman , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:42:23 -0000 As with most modeling work, there are several ways to extend the base models. Figuring out which one is right, and designing for extensibility is important no matter what the language is. So, for the RIB, clearly it starts with a base RIB entry definition with the common stuff. The challenge with extensions is whether there are a number of orthogonal things we want, or a set of components that we want to be able to use. To pick the hardest case, lets suppose that we use a RIB table LFB which uses a RIB datatype. If we can coordinate, the easiest thing is to assign an ID in the RIB structure for each substructure as you add it. One way or another, in order to have binary names for these, we have to achieve that. The subclassing mechanism supports this easily. For alternatives, we do have unions. But I think that is a more narrow case and not as useful. One can also define various components as freestanding LFB classes, and include aliases to reference them. That is even more flexible, and requires less coordination. But it is more opaque as a model. To do this, would would define in the base RIB entry a table of "extension points" which are aliases to an LFB class which inherits from a base LFB extension LFB. You can then reference any instances of any subclass of that. Arbitrarily flexible, but quite confusing. Yours, Joel On 4/22/14, 11:19 AM, Jeffrey Haas wrote: > Joel, > > On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote: >> Since ForCES name space is per-lfb-class. So that the collision >> problem is mostly in the naming of the lfb classes. (Some care is >> needed in the naming of data types and such, but it is pretty easy >> to do that in a colission avoiding fashion. The harder problem, >> which applies equally to NetConf and ForCES, is to know when you can >> reuse an existing definition and when you need your own.) > > I'm still working my way through my FORCES reading. It would be very > helpful to see an example of this. > > To offer an example from netconf that I commented upon at various WG > sessions, a RIB entry will tend to consist of things that are common across > implementations (prefix, nexthop[s], source protocol) and may be augmented > by either protocol-specific components (AS_PATH, communities for BGP; metric > for IGP) or vendor-specific ones (weight, administrative distance, etc.) > > In YANG, this is mostly a matter of just decorating with additional XML > elements around the core objects. (I'm over-generalizing.) > > How does one do this in FORCES? > >> Note that the protocol on the wire does not use the names at all, >> but only the assigned identifiers. Which are registered precisely >> to avoid collision. > > One of my lesser concerns here is that code point registries provide another > pivot for coordinating development work, in or out of IETF. Arguably, XML > token names have the same sort of issue to some extent, but tend not to be > "last code point +1". > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Apr 22 08:46:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D121A04D2 for ; Tue, 22 Apr 2014 08:46: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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTOZ7gTr0JMV for ; Tue, 22 Apr 2014 08:46:46 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7836A1A0496 for ; Tue, 22 Apr 2014 08:46:46 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so5529210qcx.7 for ; Tue, 22 Apr 2014 08:46:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xogJUsChqFMutwZLF71SBgRg9LdDlSjDxcXZ90gbYQQ=; b=R9JrlDVP0Sz3mTwXLzLqncs+WOH8oKnCxobMxp4B1OhKdu5BtKC7RXunFyGKDpD6RE +32rk8ctCG6o5AKl4MUkF76J52JBlC7/Jb68rOXTM+DHEhkwThvll3s2GoO0MdFkB9lF vYofqKzJKSibYuaKZQr3m9ogp59OvKUsffCjGbaVRmShc3HbAu+A98NyXJ/1Zn8Bl/l3 kTQQBO0d0ttFFfGHsbisXdXFRJsofgpyP1b7am5KcxjkKND3S3Ag5GM/VPKO6a/QWlid 7z1pv0YTKC3ARBvHJdUk5BrmCR8ZvFcA+daHkSIt/+raCKCU8fdEKr5fFVqOeG8hSgid 80mg== X-Gm-Message-State: ALoCoQkQDwme7DcXrOzZONhf4lpUk4C+/QxeTPImGT/Q6bCMVuIZSMCOT1vOTRO9nCu6dzsmyB4C MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr50075830qaa.7.1398181600806; Tue, 22 Apr 2014 08:46:40 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 08:46:40 -0700 (PDT) In-Reply-To: <20140422151910.GP8955@pfrc> References: <5355E678.8030309@joelhalpern.com> <53567C7D.6040809@joelhalpern.com> <20140422151910.GP8955@pfrc> Date: Tue, 22 Apr 2014 08:46:40 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7bea3986a5dcd004f7a38546 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PtksVh2D51P6FeUyoRGo-bbHkBU Cc: Joel Halpern Direct , Edward Crabbe , "i2rs@ietf.org" , Jamal Hadi Salim , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:46:52 -0000 --047d7bea3986a5dcd004f7a38546 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 22, 2014 at 8:19 AM, Jeffrey Haas wrote: > Joel, > > On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote: > > Since ForCES name space is per-lfb-class. So that the collision > > problem is mostly in the naming of the lfb classes. (Some care is > > needed in the naming of data types and such, but it is pretty easy > > to do that in a colission avoiding fashion. The harder problem, > > which applies equally to NetConf and ForCES, is to know when you can > > reuse an existing definition and when you need your own.) > > I'm still working my way through my FORCES reading. It would be very > helpful to see an example of this. > > Isn't "knowing when you can reuse an existing definition" just a tooling issue (e.g., searchable library of existing definitions)? YANG is designed to be as readable by humans as possible because usually humans need to understand the data model. > To offer an example from netconf that I commented upon at various WG > sessions, a RIB entry will tend to consist of things that are common across > implementations (prefix, nexthop[s], source protocol) and may be augmented > by either protocol-specific components (AS_PATH, communities for BGP; > metric > for IGP) or vendor-specific ones (weight, administrative distance, etc.) > > In YANG, this is mostly a matter of just decorating with additional XML > elements around the core objects. (I'm over-generalizing.) > > How does one do this in FORCES? > > > Note that the protocol on the wire does not use the names at all, > > but only the assigned identifiers. Which are registered precisely > > to avoid collision. > > One of my lesser concerns here is that code point registries provide > another > pivot for coordinating development work, in or out of IETF. Arguably, XML > token names have the same sort of issue to some extent, but tend not to be > "last code point +1". > Who assigns code points? IANA? IMO it is really useful to have distributed naming authority, so vendors do not need to register every data node as a new code point with IANA. The experience in NETCONF has been that human friendly identifiers like "/interfaces/interface/name" are far easier to work with than OIDs like 1.3.6.1.2.1.31.1.1.1.1 I think EXI encoding would be almost as efficient as a native binary encoding for NETCONF and HTTP compression should be about the same for RESTCONF. > -- Jeff > Andy --047d7bea3986a5dcd004f7a38546 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 22, 2014 at 8:19 AM, Jeffrey Haas <= ;jhaas@pfrc.org>= wrote:
Joel,

On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote:
> Since ForCES name space is per-lfb-class. =A0So that the collision
> problem is mostly in the naming of the lfb classes. =A0(Some care is > needed in the naming of data types and such, but it is pretty easy
> to do that in a colission avoiding fashion. =A0The harder problem,
> which applies equally to NetConf and ForCES, is to know when you can > reuse an existing definition and when you need your own.)

I'm still working my way through my FORCES reading. =A0It would be very=
helpful to see an example of this.



Isn't "knowing= when you can reuse an existing definition"
just a tooling i= ssue (e.g., searchable library of existing definitions)?
YANG is = designed to be as readable by humans as possible because
usually humans need to understand the data model.

=

=A0
To offer an example from netconf that I commented upon at various WG
sessions, a RIB entry will tend to consist of things that are common across=
implementations (prefix, nexthop[s], source protocol) and may be augmented<= br> by either protocol-specific components (AS_PATH, communities for BGP; metri= c
for IGP) or vendor-specific ones (weight, administrative distance, etc.)
In YANG, this is mostly a matter of just decorating with additional XML
elements around the core objects. =A0(I'm over-generalizing.)

How does one do this in FORCES?

> Note that the protocol on the wire does not use the names at all,
> but only the assigned identifiers. =A0Which are registered precisely > to avoid collision.

One of my lesser concerns here is that code point registries provide anothe= r
pivot for coordinating development work, in or out of IETF. =A0Arguably, XM= L
token names have the same sort of issue to some extent, but tend not to be<= br> "last code point +1".


Who assigns code points? IANA?
IMO it is really useful to= have distributed naming authority, so
vendors do not need to reg= ister every data node as a new code point
with IANA.

The experience in NETCONF has been= that human friendly identifiers like
"/interfaces/interface= /name" are far easier to work with than=A0OIDs lik= e 1.3.6.1.2.1.31.1.1.1.1
I think EXI encoding would be almost as efficient = as a native binary encoding for NETCONF

-- Jeff

Andy

--047d7bea3986a5dcd004f7a38546-- From nobody Tue Apr 22 08:52:27 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81EC1A0372 for ; Tue, 22 Apr 2014 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsmgGv_A2k1l for ; Tue, 22 Apr 2014 08:52:23 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 963D21A0004 for ; Tue, 22 Apr 2014 08:52:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5E4D81C0B5B; Tue, 22 Apr 2014 08:52:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DE6491C0873; Tue, 22 Apr 2014 08:52:16 -0700 (PDT) Message-ID: <5356902B.5010901@joelhalpern.com> Date: Tue, 22 Apr 2014 11:52:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman , Jeffrey Haas References: <5355E678.8030309@joelhalpern.com> <53567C7D.6040809@joelhalpern.com> <20140422151910.GP8955@pfrc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/R3ceLsFARcrKaM3WxwH3m54fIr8 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] component reuse X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 15:52:25 -0000 I wish that knowing when you can reuse definitions was just a matter of searchable libraries. Unfortunately, until human readable documentation is consistently better, it is still a challenge when looking at these things to tell what they really are for and whether they cover what you want. Yes, tooling, documentation, and search support all help. And maybe it will be easier than I expect. In any case, i don't think this is a difference between the choices. Yours, Joel On 4/22/14, 11:46 AM, Andy Bierman wrote: ... > > Isn't "knowing when you can reuse an existing definition" > just a tooling issue (e.g., searchable library of existing definitions)? > YANG is designed to be as readable by humans as possible because > usually humans need to understand the data model. ... From nite@hq.sk Tue Apr 22 09:18:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DC11A0219 for ; Tue, 22 Apr 2014 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMpCbnnx0XDK for ; Tue, 22 Apr 2014 09:18:29 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9BA1A021F for ; Tue, 22 Apr 2014 09:18:29 -0700 (PDT) Received: from [172.16.4.121] (fw.pantheon.sk [81.89.59.166]) by mail.hq.sk (Postfix) with ESMTPSA id A407E16B; Tue, 22 Apr 2014 18:18:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1398183502; bh=kOlYm9lzav3j0/NpyUiW725qYraBnCA0J+Mhl6oSOMA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=O6BENvswyLyVQA79dTwI/p2P54AGGGKVKguwh2+kFHgauDWCKj2k0DXEjRImuycDH vf7Wk6eC/GDCn6E6sA6Q1Nqi02yBguK2TYbezx4+sXKASdp0fdMRVEDoZK612j2kjs ePxGVg1NBdjuOScy9mmjSoFw0kvHzhZE2ewV713k= Message-ID: <5356964F.9060608@hq.sk> Date: Tue, 22 Apr 2014 18:18:23 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jeffrey Haas , Jamal Hadi Salim References: <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <20140421190218.GB2046@pfrc> In-Reply-To: <20140421190218.GB2046@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MzrOgEhTVocvG1ZfSAC8zDjg9LA Cc: i2rs@ietf.org, "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 18:09:14 -0000 On 04/21/2014 09:02 PM, Jeffrey Haas wrote: > The binary encoding of FORCES may help with speed. > It was asserted elsewhere (copied below) that this may only be 3-5% of a > speed improvement. (I had thought I recalled a discussion in netmod(?) at > one point of a BER format for YANG, but my google-fu is failing me.) > A somewhat negative property of XML is that a document is only considered > valid once you have the whole document. Thus, document size may matter. There is a draft for using EXI encoding in NETCONF. There is a (partial) implementation in OpenDaylight, so benchmarking should be possible. Sorry, don't have the cycles to actually design/run a reasonable test suite. Bye, Robert From nobody Tue Apr 22 11:57:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F801A010B for ; Tue, 22 Apr 2014 11:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57zo-0vobgyC for ; Tue, 22 Apr 2014 11:57: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 9863D1A003D for ; Tue, 22 Apr 2014 11:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1022; q=dns/txt; s=iport; t=1398193056; x=1399402656; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/FdP3HEVKUc/3qu6T+eCs1KuyMOPMxijcwgbRSduE9M=; b=QvgwaE1jLmmCXyGIQ3JtFUHxBUzAmb/lURvCDebBqZTfEbJ7OQnbxU25 PTwc5lDit2znwvwJqKfTBtPyUI809ix+4Wi8j/Q9u9lm37tOJbZKYBDYf Q5/2+t1QyHC4S5skqVAMEh9nx5QVBQUAa44IXq2+EHZcWS7QzvbSMQUAi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAF+6VlOtJA2B/2dsb2JhbABZgwZPV7xkhzqBFhZ0giUBAQEEAQEBNzQLEgEIDgoeNwslAgQBDQWIQAENzHYTBI5WB4Q4AQOYcJJSgzGCKw X-IronPort-AV: E=Sophos;i="4.97,905,1389744000"; d="scan'208";a="319558796" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 22 Apr 2014 18:57:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3MIvaDq026157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 18:57:36 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 13:57:35 -0500 From: "Palani Chinnakannan (pals)" To: Robert Varga , Jeffrey Haas , Jamal Hadi Salim Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7K+1TI1cr5GESMSJyaLQYZpJsXmuoAgAAepgCAAIEVAIAAA4mAgAAu1oCAAAWPgIAAEm8AgAACOgCAANbOgIAAT+aAgAARsoCAAE2dAIAB5UEAgABh5QCAAHx9AIABZImA//+3uoA= Date: Tue, 22 Apr 2014 18:57:35 +0000 Message-ID: In-Reply-To: <5356964F.9060608@hq.sk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [171.70.242.208] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F2E00AABB37664886785C4BA23CAD95@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/riqcINrC9ZpyQaNtAdZUFunlmqk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 18:57:46 -0000 Just an FYI. Rex an I have a protocol buffer mapping to Yang RFC proposal.=20 pals On 4/22/14 9:18 AM, "Robert Varga" wrote: >On 04/21/2014 09:02 PM, Jeffrey Haas wrote: >> The binary encoding of FORCES may help with speed. >> It was asserted elsewhere (copied below) that this may only be 3-5% of a >> speed improvement. (I had thought I recalled a discussion in netmod(?) >>at >> one point of a BER format for YANG, but my google-fu is failing me.) >> A somewhat negative property of XML is that a document is only >>considered >> valid once you have the whole document. Thus, document size may matter. > >There is a draft for using EXI encoding in NETCONF. There is a (partial) >implementation in OpenDaylight, so benchmarking should be possible. >Sorry, don't have the cycles to actually design/run a reasonable test >suite. > >Bye, >Robert > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Apr 22 17:32:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97FD1A02B4 for ; Tue, 22 Apr 2014 17:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2AyP9kye8Xr for ; Tue, 22 Apr 2014 17:32:22 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CE0111A02AE for ; Tue, 22 Apr 2014 17:32:21 -0700 (PDT) Received: from [192.168.40.127] (unknown [67.142.101.142]) by lucidvision.com (Postfix) with ESMTP id 021C42774DEA; Tue, 22 Apr 2014 20:32:14 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C9A58F67-42A2-46DB-9811-C7D41FA1748F Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D167) In-Reply-To: <535655E7.9090405@cisco.com> Date: Tue, 22 Apr 2014 19:32:08 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4684264F-04D8-4AE9-9460-C17FAD9E9251@lucidvision.com> References: <535655E7.9090405@cisco.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hlhbB9zVjmlSQVDqf_ugHJZOco0 Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 00:32:27 -0000 --Apple-Mail-C9A58F67-42A2-46DB-9811-C7D41FA1748F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Apr 22, 2014, at 6:43 AM, Benoit Claise wrote: >=20 > Dear all, >=20 > I've been spending the last 2 hours reading that full email thread, up to t= his time. > Not sure to which email I should reply, so here am I, top posting. >=20 > + 1 on YANG for the data model language.=20 > What counts at the end of the day is a consistent data model language for c= onfiguration, because implementing a proxy for different data model language= s is a pain, time consuming, and error-prone. > Ideally, we should have a consistent information model language, but the i= ndustry/standards are not there yet. Not even sure they will even arrive the= re one day. >=20 > Looking at the life cycling of specifying a new language, implementing it,= deploying it, and developing tools around it (I have SMI and YANG in mind),= having a new data model language for I2RS only is not practical. And the mo= re we wait, the more obvious the solution is. > I know, it's not about a technical argument any longer (those have been ma= de on the lits already). > Let's look at the WG deliverables: > Jul 2013=09 > Request publication of an Informational document defining the problem stat= ement > Jul 2013=09 > Request publication of an Informational document defining the high-level a= rchitecture > Aug 2013=09 > Request publication of Informational documents describing use cases > Sep 2013=09 > Request publication of an Informational document defining the protocol req= uirements > Sep 2013=09 > Request publication of an Informational document defining encoding languag= e requirements > Feb 2014=09 > Request publication of Standards Track documents specifying information mo= dels > Feb 2014=09 > Request publication of an Informational document providing an analysis of e= xisting IETF and other protocols and encoding languages against the requirem= ents > Feb 2014=09 > Consider re-chartering >=20 > The least we can say is that the WG is late. > I observe that after 1 year and 3 months after the WG creation, we still d= on't have the problem statement/architecture/requirements: that explains, w= hether we like it or not, why the business reasons are getting more and mor= e important compared to the technical arguments. > Didn't we see a few comments lately about the IETF not being relevant beca= use we're too slow? > Maybe the IESG should be stricter: "no problem statement with a year, WG c= losed", but I guess I'm diverging :-) >=20 > Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logic= al step, even if I believe that in practice, we'll see different devices spe= aking different languages. >=20 > Regards, Benoit (as a contributor) I am with you in the "move forward or shut this train down" sentiment. Reall= y how long does it take to decide in a modeling language - esp when the ietf= has one that is perfectly suitable? Tom=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-C9A58F67-42A2-46DB-9811-C7D41FA1748F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On Apr 22, 2014, at 6:43 AM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

I've been spending the last 2 hours reading that full email thread, up to this time.
Not sure to which email I should reply, so here am I, top posting.

+ 1 on YANG for the data model language.
What counts at the end of the day is a consistent data model language for configuration, because implementing a proxy for different data model languages is a pain, time consuming, and error-prone.
Ideally, we should have a consistent information model language, but the industry/standards are not there yet. Not even sure they will even arrive there one day.

Looking at the life cycling of specifying a new language, implementing it, deploying it, and developing tools around it (I have SMI and YANG in mind), having a new data model language for I2RS only is not practical. And the more we wait, the more obvious the solution is.
I know, it's not about a technical argument any longer (those have been made on the lits already).
Let's look at the WG deliverables:
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

The least we can say is that the WG is late.
I observe that after 1 year and 3 months after the WG creation, we still don't have the problem statement/architecture/requirements: that  explains, whether we like it or not, why the  business reasons are getting more and more important compared to the technical arguments.
Didn't we see a few comments lately about the IETF not being relevant because we're too slow?
Maybe the IESG should be stricter: "no problem statement with a year, WG closed", but I guess I'm diverging :-)

Once YANG is selected, NETCONF/RESTCONF for the protocol is the next logical step, even if I believe that in practice, we'll see different devices speaking different languages.

Regards,  Benoit (as a contributor)

I am with you in the "move forward or shut this train down" sentiment. Really how long does it take to decide in a modeling language - esp when the ietf has one that is perfectly suitable?

Tom 




_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
--Apple-Mail-C9A58F67-42A2-46DB-9811-C7D41FA1748F-- From nobody Tue Apr 22 17:36:41 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4C1A02C5 for ; Tue, 22 Apr 2014 17:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ENeGn1yqrNB for ; Tue, 22 Apr 2014 17:36:33 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 405E71A02C3 for ; Tue, 22 Apr 2014 17:36:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" , "'Russ White'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> In-Reply-To: Date: Tue, 22 Apr 2014 20:36:01 -0400 Message-ID: <006f01cf5e8c$015231b0$03f69510$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01CF5E6A.7A46FA50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHSXYrvNsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/jUJUg8sBkJalzxCPUHIikIDZK1o Cc: i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' , 'Dean Bogdanovic' , "'Jan Medved \(jmedved\)'" , "'Joel M. Halpern'" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 00:36:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0070_01CF5E6A.7A46FA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: Catching up. A few questions: 1) Why do you think that only the RIB matters in the long run (Short run = RIB + BGP) 2) Your modeling questions are important .. so let me ask a meta-question and then go a level deeper. Why does netmod never really publish an informational model? Here's a bunch of answers/question to you great modeling questino - What are the data types needed? Is this a static set of will it ever change? a) Yes. Right now no Data types in This static set is likely to continually expand if it is used for I2RS, and have vendor specific - What are the high level data modeling constructs needed? [Sue] Yes. But we will talk a lot about what is high-level data model constructs? Do you consider next-hop as defined in the RIB a high-level? - Are user defined types needed? [Sue" If you mean, will vendors or specific end users need it? I do not see how we can go without it. - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? -Can vendors add data definitions that extend the standard definition? - How are new definitions added in a way that does not break existing clients? [Sue]: Answer yes to all. Re-usable, modular, growing, vendor extensible, user-defined. Do not plan to break if add new, - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? [Sue]: Need the profiling variables that Yang is using [Note: Forces has an equivalent to all of this] Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Saturday, April 19, 2014 1:46 PM To: Russ White Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan Medved (jmedved); Joel M. Halpern Subject: Re: [i2rs] consensus on I2RS protocol and model Hi, On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) Russ Andy ------=_NextPart_000_0070_01CF5E6A.7A46FA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

Catching up.  A few questions:

 

1)      = Why do you think that only the RIB matters in the long run (Short run = =3D RIB + BGP)

2)      = Your modeling questions are important .. so let me ask a = meta-question and then go a level deeper…

 

Why does netmod never really publish an informational model? =

  

Here’s a bunch of answers/question to you great modeling = questino

 

  - What are = the data types needed?  Is this a static set of will it ever = change?

a)      = Yes.  Right now no Data types in =  

This static set is = likely to continually expand if it is used for I2RS, and have vendor = specific

 

  - What are the high level data modeling = constructs needed?

[Sue] Yes.  But we will talk a lot = about what is high-level data model constructs?  

       &n= bsp;  Do you consider next-hop as defined in the RIB a = high-level?

 

  - Are user defined types = needed?

[Sue” If you mean, will vendors or = specific end users need it?  I do not see how we can go without it. =

 

  - Are re-usable data definitions = needed?

  - Does the data model = need to be modular?  How does it grow over time?

 -Can vendors add data definitions that extend = the standard definition?

  - = How are new definitions added in a way that does not break existing = clients?

 

   [Sue]:  Answer yes to all.  = Re-usable, modular, growing, vendor extensible, user-defined. =

   Do not plan to = break if add new,

       

  - How is mandatory to implement vs. = optional to implement functionality handled?

  - How is mandatory to use vs. optional to use = functionality handled?

    [Sue]: Need the profiling variables = that Yang is using

         &= nbsp;    [Note: Forces has an equivalent to all of = this]

 

Sue

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: = Russ White
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 

Hi,

 

On Sat, Apr 19, 2014 at 8:22 AM, Russ White <russw@riw.us> = wrote:


> And the basic premise = of I2RS is that there are requirements for the work
> that were = not addressed properly by the existing configuration protocols.
> = Otherwise the WG would not even need to discuss protocol = modifications.
> So the fact that NetConf / YANG works for device = configuration does not
> seem to be evidence that it works for = what I2RS wants to do.

Precisely. Otherwise, we could have just = looked at the problem, and said,
"let's use YANG." But I = think we're starting to confuse the problem set
because we started by = trying to boil the ocean. Once you actually get to
town, it's hard to = keep in focus that you're just there for a new pitchfork
handle -- = that game of checkers over there on the porch of the hotel looks
so = interesting, and the hardware store has so much other stuff than = just
pitchfork handles, after all.

So, given we are _supposed_ = to be focused on the RIB interface, and not
protocol, configuration, = device, etc., etc., what specific points have the
use cases brought = out that either NETCONF/YANG or FORCES not fulfill? One of
the = primary points was timing -- are these other systems fast = enough?

>From my perspective, these two systems don't fulfill = the I2RS mandate on the
RIB side for various reasons:

- I'm = not convinced on the speed side. YANG feels a bit heavy weigh for = what
we want here. The flexibility is there, but so is the cost of = that
flexibility.

 

 

Can you explain how an off-line representation of the = data model can be fast or slow?

You mean the YANG compiler takes too long to process a = YANG file?

You mean the = unspecified I2RS protocol will be too slow on the wire = if

it uses XML or JSON = encoding of YANG data structures?

 

 


- I'm not convinced YANG has handled = the atomicity issues in a way that
makes sense for the application = environment we have in mind. RESTCONF seems
to go that direction, but = I'm not certain it's a complete solution = (?).

 

YANG is a data modeling = language.

RESTCONF is a = protocol.

Atomicity is a = property of the protocol.

Which YANG statements prevent this from being = accomplished in the TBD I2RS protocol?

 

 

So, IMHO, I think we need to either = consider FORCES, or "something new." But
we're going to = have a hard time determining if this is true if we can't make
a solid = requirements list. For me, these are:

- Atomic operations at the = RIB level
- Speed that's comparable to a local routing process = installing routes in
the RIB
- An immediate feedback system within = the RESTful mold that tells the
installing process what happened, and = why, with the route it just tried to
install in the RIB

So, it = seems to me that we need to return to the use cases -- there are = two
in the charter. If we want to discuss adding others, that's fine, = but we
need to gain some focus, and stop trying to boil the ocean, if = we want to
make any progress.

 

It seems to me this WG needs to start asking the right = questions about the

data = modeling language requirements.  E.g.:

 

  - What are the data types needed?  Is this = a static set of will it ever change?

  - What are the high level data modeling = constructs needed?

  = - Are user defined types needed?

  - Are re-usable data definitions = needed?

  - Does the = data model need to be modular?  How does it grow over = time?

  - Can vendors = add data definitions that extend the standard = definitions?

  - How = are new definitions added in a way that does not break existing = clients?

  - How is = mandatory to implement vs. optional to implement functionality = handled?

  - How is = mandatory to use vs. optional to use functionality = handled?

 

You are asking about protocol requirements, not data = modeling.

IMO it would be = near-sighted and extremely impractical to = choose

a language that = only supported description on RIB info.  I fail to see = what

is so special about = RIB info that would warrant its own DML.

 

 

:-)

Russ

 

Andy

 

------=_NextPart_000_0070_01CF5E6A.7A46FA50-- From nobody Tue Apr 22 17:45:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44321A02C5 for ; Tue, 22 Apr 2014 17:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEnfUzOeN6-N for ; Tue, 22 Apr 2014 17:45:43 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 158321A02B4 for ; Tue, 22 Apr 2014 17:45:43 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id e89so255581qgf.34 for ; Tue, 22 Apr 2014 17:45:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mRiSqxTr3O+UVTWp4zgPDCwz7r4nZh2MZwM8S8pj9i4=; b=KiyVqwj1e1q5L5ztJM6xcNXe7p3bVPwN1eBsOeNsJaVj/Im3BF06C2Uzle4V2o8gMV Y3e2U9PM+oNvNmiqb+OLRSpkVIOe2y3B6XlNikI+CU1p6YdaUpbsth0tU+z8AMD0wIWv KkciwngeCzWsmzQEFuX2p975KTVnY/SDuMwNJLqhsGin0Qy7lQWOul3KX/mIkaLbBYsW K7E4cOeYk60YOCetPspMaiWx6V9qE3bSsFxj/Ms9AO7cPyXrTi1U/OXxglS5CFmDZlt/ XpzqjVXvqt+L56NvbN3MC1XV/+cTHx+XYs+AZrcFupxeq/ieZHlRmMaAa8SmMi/0gMon pNPA== X-Gm-Message-State: ALoCoQmQ/GXL/Vx+u3pC3TDavfO8O3HjKcaHddr3oYhY+o/YIDpD7mhfjCne5zjXf8tmQfy0SAHV MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr17399952qad.88.1398213937351; Tue, 22 Apr 2014 17:45:37 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Tue, 22 Apr 2014 17:45:37 -0700 (PDT) In-Reply-To: <006f01cf5e8c$015231b0$03f69510$@ndzh.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> Date: Tue, 22 Apr 2014 17:45:37 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=089e0158a9e40e675504f7ab0d71 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JxzpSTQVvnIvtN60QtwiNcX7a58 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 00:45:48 -0000 --089e0158a9e40e675504f7ab0d71 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 22, 2014 at 5:36 PM, Susan Hares wrote: > Andy: > > > > Catching up. A few questions: > > > > 1) Why do you think that only the RIB matters in the long run (Short > run = RIB + BGP) > Why do you think I said that? I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. > 2) Your modeling questions are important .. so let me ask a > meta-question and then go a level deeper... > > > > Why does netmod never really publish an informational model? > > > NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. Andy > Here's a bunch of answers/question to you great modeling questino > > > > - What are the data types needed? Is this a static set of will it ever > change? > > a) Yes. Right now no Data types in > > This static set is likely to continually expand if it is used for I2RS, > and have vendor specific > > > > - What are the high level data modeling constructs needed? > > [Sue] Yes. But we will talk a lot about what is high-level data model > constructs? > > Do you consider next-hop as defined in the RIB a high-level? > > > > - Are user defined types needed? > > [Sue" If you mean, will vendors or specific end users need it? I do not > see how we can go without it. > > > > - Are re-usable data definitions needed? > > - Does the data model need to be modular? How does it grow over time? > > -Can vendors add data definitions that extend the standard definition? > > - How are new definitions added in a way that does not break existing > clients? > > > > [Sue]: Answer yes to all. Re-usable, modular, growing, vendor > extensible, user-defined. > > Do not plan to break if add new, > > > > - How is mandatory to implement vs. optional to implement functionality > handled? > > - How is mandatory to use vs. optional to use functionality handled? > > [Sue]: Need the profiling variables that Yang is using > > [Note: Forces has an equivalent to all of this] > > > Sue > > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Saturday, April 19, 2014 1:46 PM > *To:* Russ White > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > Hi, > > > > On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > > > > And the basic premise of I2RS is that there are requirements for the work > > that were not addressed properly by the existing configuration protocols. > > Otherwise the WG would not even need to discuss protocol modifications. > > So the fact that NetConf / YANG works for device configuration does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the problem, and said, > "let's use YANG." But I think we're starting to confuse the problem set > because we started by trying to boil the ocean. Once you actually get to > town, it's hard to keep in focus that you're just there for a new pitchfork > handle -- that game of checkers over there on the porch of the hotel looks > so interesting, and the hardware store has so much other stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB interface, and not > protocol, configuration, device, etc., etc., what specific points have the > use cases brought out that either NETCONF/YANG or FORCES not fulfill? One > of > the primary points was timing -- are these other systems fast enough? > > >From my perspective, these two systems don't fulfill the I2RS mandate on > the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit heavy weigh for > what > we want here. The flexibility is there, but so is the cost of that > flexibility. > > > > > > Can you explain how an off-line representation of the data model can be > fast or slow? > > You mean the YANG compiler takes too long to process a YANG file? > > You mean the unspecified I2RS protocol will be too slow on the wire if > > it uses XML or JSON encoding of YANG data structures? > > > > > > > - I'm not convinced YANG has handled the atomicity issues in a way that > makes sense for the application environment we have in mind. RESTCONF seems > to go that direction, but I'm not certain it's a complete solution (?). > > > > YANG is a data modeling language. > > RESTCONF is a protocol. > > Atomicity is a property of the protocol. > > Which YANG statements prevent this from being accomplished in the TBD I2RS > protocol? > > > > > > So, IMHO, I think we need to either consider FORCES, or "something new." > But > we're going to have a hard time determining if this is true if we can't > make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing routes in > the RIB > - An immediate feedback system within the RESTful mold that tells the > installing process what happened, and why, with the route it just tried to > install in the RIB > > So, it seems to me that we need to return to the use cases -- there are two > in the charter. If we want to discuss adding others, that's fine, but we > need to gain some focus, and stop trying to boil the ocean, if we want to > make any progress. > > > > It seems to me this WG needs to start asking the right questions about the > > data modeling language requirements. E.g.: > > > > - What are the data types needed? Is this a static set of will it ever > change? > > - What are the high level data modeling constructs needed? > > - Are user defined types needed? > > - Are re-usable data definitions needed? > > - Does the data model need to be modular? How does it grow over time? > > - Can vendors add data definitions that extend the standard definitions? > > - How are new definitions added in a way that does not break existing > clients? > > - How is mandatory to implement vs. optional to implement functionality > handled? > > - How is mandatory to use vs. optional to use functionality handled? > > > > You are asking about protocol requirements, not data modeling. > > IMO it would be near-sighted and extremely impractical to choose > > a language that only supported description on RIB info. I fail to see what > > is so special about RIB info that would warrant its own DML. > > > > > > :-) > > Russ > > > > Andy > > > --089e0158a9e40e675504f7ab0d71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 22, 2014 at 5:36 PM, Susan Hares <= shares@ndzh.com>= ; wrote:

Andy:<= u>

 

Catching up.  = A few questions:

 

1)      Why do you think that only the RI= B matters in the long run (Short run =3D RIB + BGP)


Why do you think I said that?<= /div>
I don't see anything special about I2RS at all.
Edi= ting operational state would probably work the same for other data.

 

<= u>

2)      Your modeling questions are important .= . so let me ask a meta-question and then go a level deeper… <= u>

 

Why does netmod nev= er really publish an informational model?

  


NETMOD publishes YANG modules.
I suppose it is perceived an unnecessary.


Andy


=
 

Here’s a bunch= of answers/question to you great modeling questino

 

  - What are the data types needed?  = ;Is this a static set of will it ever change?

a)&n= bsp;     Yes.  Right now no D= ata types in  

This static set is likely to contin= ually expand if it is used for I2RS, and have vendor specific

 

 = ; - What are the high level data modeling constructs needed?<= /p>

[Sue] Yes.  But we will talk a lot = about what is high-level data model constructs?  

       &= nbsp;  Do you consider next-hop as defined in the RIB a high-leve= l?

=  

  - Are user defined types= needed?

[Sue” If you mean, will vendors or sp= ecific end users need it?  I do not see how we can go without it. <= /u>

&nb= sp;

  - Are re-usable data definitions needed?

  - Does the data model need to be modular?  How d= oes it grow over time?

 -Can = vendors add data definitions that extend the standard definition?

  - How are new definitions added in a way that= does not break existing clients?

<= u> 

   [Sue]:  Ans= wer yes to all.  Re-usable, modular, growing, vendor extensible, user-= defined.

   Do not plan to break if add new, <= u>

      = ; 

  - How is mandatory t= o implement vs. optional to implement functionality handled?<= /p>

  - How is mandatory to use vs. optional to use= functionality handled?

  = ;  [Sue]: Need the profiling variables that Yang is using

            &nb= sp; [Note: Forces has an equivalent to all of this] 

 

Sue

 

 

From: i2= rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: Russ White
<= b>Cc: i2rs@ietf.org<= /a>; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan Medved (jmedved)= ; Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

Hi,

 

On Sat, Apr 19, 2014 at= 8:22 AM, Russ White <= russw@riw.us> wrote:


>= ; And the basic premise of I2RS is that there are requirements for the work=
> that were not addressed properly by the existing configuration protoco= ls.
> Otherwise the WG would not even need to discuss protocol modifi= cations.
> So the fact that NetConf / YANG works for device configura= tion does not
> seem to be evidence that it works for what I2RS wants to do.

Pr= ecisely. Otherwise, we could have just looked at the problem, and said,
= "let's use YANG." But I think we're starting to confuse t= he problem set
because we started by trying to boil the ocean. Once you actually get totown, it's hard to keep in focus that you're just there for a new = pitchfork
handle -- that game of checkers over there on the porch of the= hotel looks
so interesting, and the hardware store has so much other stuff than justpitchfork handles, after all.

So, given we are _supposed_ to be foc= used on the RIB interface, and not
protocol, configuration, device, etc.= , etc., what specific points have the
use cases brought out that either NETCONF/YANG or FORCES not fulfill? One o= f
the primary points was timing -- are these other systems fast enough?<= br>
>From my perspective, these two systems don't fulfill the I2R= S mandate on the
RIB side for various reasons:

- I'm not convinced on the speed s= ide. YANG feels a bit heavy weigh for what
we want here. The flexibility= is there, but so is the cost of that
flexibility.

 

 

Can yo= u explain how an off-line representation of the data model can be fast or s= low?

You mean the YANG compiler takes too long= to process a YANG file?

You mean the unspecified I2RS protocol will be too slow on the wire if<= /u>

it uses XML or JSON encoding of YANG data= structures?

&nbs= p;

 


- I'm not con= vinced YANG has handled the atomicity issues in a way that
makes sense f= or the application environment we have in mind. RESTCONF seems
to go tha= t direction, but I'm not certain it's a complete solution (?).

 

YANG is a data modeling language.

=

RESTCONF is a protocol.

=

Atomicity is a property of the protocol.

Which YANG statements prevent this = from being accomplished in the TBD I2RS protocol?

 

 

So, IMHO, I think we = need to either consider FORCES, or "something new." But
we'= ;re going to have a hard time determining if this is true if we can't m= ake
a solid requirements list. For me, these are:

- Atomic operations at= the RIB level
- Speed that's comparable to a local routing process = installing routes in
the RIB
- An immediate feedback system within th= e RESTful mold that tells the
installing process what happened, and why, with the route it just tried to<= br>install in the RIB

So, it seems to me that we need to return to t= he use cases -- there are two
in the charter. If we want to discuss addi= ng others, that's fine, but we
need to gain some focus, and stop trying to boil the ocean, if we want tomake any progress.

 

It seems to m= e this WG needs to start asking the right questions about the=

data modeling language requirements. &nbs= p;E.g.:

 =

  - What are the data types = needed?  Is this a static set of will it ever change?

  - What are the high level data mod= eling constructs needed?

  - Are user defined types needed?

  - Are re-usable data definitions needed?

  - Does the data model need to be modular? &n= bsp;How does it grow over time?

  - Can vendors add data definitions that extend the standard = definitions?

  - How are new definitions added in= a way that does not break existing clients?

  - How is mandatory to implement vs. optional to= implement functionality handled?

  - How is mandatory to use vs. opti= onal to use functionality handled?

 

You ar= e asking about protocol requirements, not data modeling.

IMO it would be near-sighted and extremel= y impractical to choose

= a language that only supported description on RIB info.  I fail to see= what

is so special about RIB info that would w= arrant its own DML.

<= /u> 

 <= /p>

:-)

Russ

<= p class=3D"MsoNormal"> 

Andy

 <= u>


--089e0158a9e40e675504f7ab0d71-- From nobody Wed Apr 23 07:51:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198EF1A03CD for ; Wed, 23 Apr 2014 07:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.846 X-Spam-Level: **** X-Spam-Status: No, score=4.846 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw3LGnyZWSMf for ; Wed, 23 Apr 2014 07:50:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DE3501A03C9 for ; Wed, 23 Apr 2014 07:50:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> In-Reply-To: Date: Wed, 23 Apr 2014 10:50:43 -0400 Message-ID: <007801cf5f03$671a4830$354ed890$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01CF5EE1.E0109770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHQB8lGI9QG/kFEwAfy5kPeXNjySAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ltXE6l1y7MPK1kFvZghuHM631lU Cc: i2rs@ietf.org Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 14:50:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0079_01CF5EE1.E0109770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The list server choked - so I'm Pull off all copies except Andy and I2rs. By the way, I agree with Jeff Haas and Adrian,RBNF == BAD for I2RS. I hope we can pull it soon. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, April 23, 2014 10:42 AM To: 'Andy Bierman' Cc: 'i2rs@ietf.org'; 'Edward Crabbe'; 'Jamal Hadi Salim'; 'Dean Bogdanovic'; 'Russ White'; 'Jan Medved (jmedved)'; 'Joel M. Halpern'; 'adrian@olddog.co.uk'; Alia Atlas (akatlas@juniper.net); Nitin Bahadur (nitin_bahadur@yahoo.com); 'Jeffrey Haas' Subject: RE: [i2rs] consensus on I2RS protocol and model Andy: I started using UML to do the information models because Adrian Farrel and Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf models are still mining the existing SNMP/Configuration structures. For new development, I suspect UML may help us root out redundancy. Why? Because I think I've found lots of redundancy in the RIB_INFO model. I've attached slides that may convince you, and an alternate drafts. I've assumed in the information model that yang models as defined below +--------+---------------------------+-----------+ | Prefix | YANG module | Reference | +--------+---------------------------+-----------+ | if | ietf-interfaces | [YANG-IF ] | | | | | | ip | ietf-ip | [YANG-IP ] | | | | | | rt | ietf-routing | [routing] | | | | | | v4ur | ietf-ipv4-unicast-routing | [routing] | | | | | | v6ur | ietf-ipv6-unicast-routing | [routing | | | | | | yang | ietf-yang-types | [RFC6991 ] | | | | | | inet | ietf-inet-types | [RFC6991 ] | +--------+---------------------------+-----------+ I've attached a revision of the RIB-info-model draft that provides: 1) Revised RIB Grammar in RBNF (section 6.1) 2) (section 6.2) Spot for the pdf graphic attached as draf-thares-i2rs-info-rib-only-v7.pdf 3) (section 6.3) Yang tree structure (per yang documents) 4) Revised Usage - using simplified grammar Basically the complex RBNF grammar boils down to very few simply statement. The Yang Tree does not provide an easy way to design/debug redundancy. I think that the use of the UML tools that create the Yang modules/Yang Tree structures could speed time to market on the designs. For example, all the I2RS RIB is simply 5 power-point slides, that then can be generated into Yang module. This seems the normal progression of the process you started with the Yang-modules. CAVEATS: 1) For all mistakes on the UML and diagrams blame me - this first pass at UMLs, and it will need revising 2) Some of the redundancies could have been fixed in other ways 3) I did Yang modules to demonstrate proof of concept 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES Data model can do the same Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, April 22, 2014 8:46 PM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern Subject: Re: [i2rs] consensus on I2RS protocol and model <..snip> 1) Why do you think that only the RIB matters in the long run (Short run = RIB + BGP) - [Andy] Why do you think I said that I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. [Sue]: Agree! 2) Your modeling questions are important .. so let me ask a meta-question and then go a level deeper. Why does netmod never really publish an informational model? NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. [Sue]: Other designers on lists stated they suggested they considered IM in their design of YANG. I think the graphical finds redundancies wrote: > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) Russ Andy ------=_NextPart_000_0079_01CF5EE1.E0109770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The list server choked – so I’m Pull off all copies = except Andy and I2rs.    By the way, I agree with Jeff = Haas and Adrian,RBNF =3D=3D BAD for I2RS.  I hope we can pull it = soon.

 

Sue

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, April = 23, 2014 10:42 AM
To: 'Andy Bierman'
Cc: = 'i2rs@ietf.org'; 'Edward Crabbe'; 'Jamal Hadi Salim'; 'Dean Bogdanovic'; = 'Russ White'; 'Jan Medved (jmedved)'; 'Joel M. Halpern'; = 'adrian@olddog.co.uk'; Alia Atlas (akatlas@juniper.net); Nitin Bahadur = (nitin_bahadur@yahoo.com); 'Jeffrey Haas'
Subject: RE: [i2rs] = consensus on I2RS protocol and model

 

Andy:

 

I started using UML to do the information models because Adrian = Farrel and Alia Atlas encouraged it to replace RBNF.   I think = that the yang/netconf models are still mining the existing = SNMP/Configuration structures. For new development, I suspect UML may = help us root out redundancy. Why?  Because I think I’ve found = lots of redundancy in the RIB_INFO model.  I’ve attached = slides that may convince you, and an alternate = drafts.

 

I’ve assumed in the information model that yang models as = defined below

 

  +--------+---------------------------+-----= ------+

  = | Prefix | YANG = module           &= nbsp;   | Reference |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal style=3D'page-break-before:always'>  = | if     | = ietf-interfaces         &nbs= p; | [YANG-IF] |

  = |        = |            =             &= nbsp;  = |           = |

  = | ip     | = ietf-ip           =         | [YANG-IP] |

  = |        = |            =             &= nbsp;  = |           = |

  = | rt     | = ietf-routing          &= nbsp;   | = [routing] |

 |        = |            =             &= nbsp;  = |           = |

 | = v4ur   | ietf-ipv4-unicast-routing | = [routing] |

  = |        = |            =             &= nbsp;  = |           = |

  = | v6ur   | ietf-ipv6-unicast-routing | = [routing  |

  = |        = |            =             &= nbsp;  = |           = |

  = | yang   | = ietf-yang-types         &nbs= p; | [RFC6991] = |

  = |        = |            =             &= nbsp;  = |           = |

  = | inet   | = ietf-inet-types         &nbs= p; | [RFC6991] = |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal> 

I’ve attached a revision of the RIB-info-model draft that = provides:

1)      = Revised RIB Grammar in RBNF (section 6.1)

2)      = (section 6.2) Spot for the pdf graphic attached as = draf-thares-i2rs-info-rib-only-v7.pdf

3)      = (section 6.3) Yang tree structure (per yang = documents)

4)      = Revised Usage – using simplified = grammar

 

Basically the complex RBNF grammar boils down to very few simply = statement.  The Yang Tree does not provide an easy way to = design/debug redundancy. I think that the use of the UML tools that = create the Yang modules/Yang Tree structures could speed time to market = on the designs.  For example, all the I2RS RIB is simply 5 = power-point slides, that then can be generated into Yang module.  = This seems the normal progression of the process you started with the = Yang-modules.

 

CAVEATS:

1)      = For all mistakes on the UML and diagrams blame me – this first = pass at UMLs, and it will need revising

2)      = Some of the redundancies could have been fixed in other ways =

3)      = I did Yang modules to demonstrate proof of = concept

4)      = I suspect with Jamal and Joel Halpern’s help (FoRCES gurus).. = FoRCES Data model can do the same

 

Sue Hares  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Andy Bierman
Sent: Tuesday, April 22, 2014 = 8:46 PM
To: Susan Hares
Cc: i2rs@ietf.org; Edward Crabbe; Jamal = Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

<..snip>  

1)      = Why do you think that only the RIB matters in the long run (Short run = =3D RIB + BGP) -

[Andy] Why do you = think I said that I don't see = anything special about I2RS at all. = Editing operational state would probably work the same for other = data.

[Sue]: Agree!

 

2)      = Your modeling questions are important .. so let me ask a = meta-question and then go a level deeper…

 Why does netmod never really publish an informational model? =

 NETMOD publishes YANG modules. I suppose it is perceived an = unnecessary.

[Sue]: Other designers on lists stated they suggested they considered = IM in their design of YANG.  I think the graphical finds = redundancies

<snip)  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: = Russ White
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi,

 <= /p>

On Sat, Apr = 19, 2014 at 8:22 AM, Russ White <russw@riw.us> wrote:


> = And the basic premise of I2RS is that there are requirements for the = work
> that were not addressed properly by the existing = configuration protocols.
> Otherwise the WG would not even need to = discuss protocol modifications.
> So the fact that NetConf / YANG = works for device configuration does not
> seem to be evidence that = it works for what I2RS wants to do.

Precisely. Otherwise, we = could have just looked at the problem, and said,
"let's use = YANG." But I think we're starting to confuse the problem = set
because we started by trying to boil the ocean. Once you actually = get to
town, it's hard to keep in focus that you're just there for a = new pitchfork
handle -- that game of checkers over there on the porch = of the hotel looks
so interesting, and the hardware store has so much = other stuff than just
pitchfork handles, after all.

So, given = we are _supposed_ to be focused on the RIB interface, and = not
protocol, configuration, device, etc., etc., what specific points = have the
use cases brought out that either NETCONF/YANG or FORCES not = fulfill? One of
the primary points was timing -- are these other = systems fast enough?

>From my perspective, these two systems = don't fulfill the I2RS mandate on the
RIB side for various = reasons:

- I'm not convinced on the speed side. YANG feels a bit = heavy weigh for what
we want here. The flexibility is there, but so = is the cost of that
flexibility.

 <= /o:p>

 <= /o:p>

Can you = explain how an off-line representation of the data model can be fast or = slow?

You mean = the YANG compiler takes too long to process a YANG = file?

You mean = the unspecified I2RS protocol will be too slow on the wire = if

it uses XML = or JSON encoding of YANG data structures?

 <= /o:p>

 <= /o:p>


- I'm not = convinced YANG has handled the atomicity issues in a way that
makes = sense for the application environment we have in mind. RESTCONF = seems
to go that direction, but I'm not certain it's a complete = solution (?).

 <= /o:p>

YANG is a = data modeling language.

RESTCONF is = a protocol.

Atomicity = is a property of the protocol.

Which YANG = statements prevent this from being accomplished in the TBD I2RS = protocol?

 <= /o:p>

 <= /o:p>

So, IMHO, I think = we need to either consider FORCES, or "something new." = But
we're going to have a hard time determining if this is true if we = can't make
a solid requirements list. For me, these are:

- = Atomic operations at the RIB level
- Speed that's comparable to a = local routing process installing routes in
the RIB
- An immediate = feedback system within the RESTful mold that tells the
installing = process what happened, and why, with the route it just tried = to
install in the RIB

So, it seems to me that we need to = return to the use cases -- there are two
in the charter. If we want = to discuss adding others, that's fine, but we
need to gain some = focus, and stop trying to boil the ocean, if we want to
make any = progress.

 <= /o:p>

It seems to = me this WG needs to start asking the right questions about = the

data = modeling language requirements.  E.g.:

 <= /o:p>

  - = What are the data types needed?  Is this a static set of will it = ever change?

  - = What are the high level data modeling constructs = needed?

  - = Are user defined types needed?

  - = Are re-usable data definitions needed?

  - = Does the data model need to be modular?  How does it grow over = time?

  - = Can vendors add data definitions that extend the standard = definitions?

  - = How are new definitions added in a way that does not break existing = clients?

  - = How is mandatory to implement vs. optional to implement functionality = handled?

  - = How is mandatory to use vs. optional to use functionality = handled?

 <= /o:p>

You are = asking about protocol requirements, not data = modeling.

IMO it = would be near-sighted and extremely impractical to = choose

a language = that only supported description on RIB info.  I fail to see = what

is so = special about RIB info that would warrant its own = DML.

 <= /o:p>

 <= /o:p>

:-)

R= uss

 <= /o:p>

Andy

 <= /o:p>

 

------=_NextPart_000_0079_01CF5EE1.E0109770-- From nobody Wed Apr 23 09:10:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63C71A0381 for ; Wed, 23 Apr 2014 09:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4GxP3oEgtDX for ; Wed, 23 Apr 2014 09:10:33 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id B226D1A03AA for ; Wed, 23 Apr 2014 09:10:26 -0700 (PDT) Received: from DBXPRD0210HT003.eurprd02.prod.outlook.com (157.56.253.181) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 23 Apr 2014 16:10:19 +0000 Message-ID: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> From: t.petch To: Edward Crabbe , References: Date: Wed, 23 Apr 2014 17:07:51 +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-ClientProxiedBy: AMSPR07CA007.eurprd07.prod.outlook.com (10.242.77.175) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) X-Forefront-PRVS: 01901B3451 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(13464003)(51704005)(377454003)(20776003)(92726001)(47776003)(92566001)(80022001)(66066001)(14496001)(23756003)(561944002)(88136002)(81342001)(33646001)(89996001)(62966002)(61296002)(74502001)(74662001)(81542001)(31966008)(99396002)(50466002)(85852003)(83072002)(77982001)(4396001)(81816999)(46102001)(76176999)(80976001)(81686999)(19580395003)(19580405001)(83322001)(44736004)(93916002)(84392001)(44716002)(86362001)(42186004)(15975445006)(62236002)(79102001)(87976001)(50226001)(76482001)(77156001)(50986999)(87286001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB055; H:DBXPRD0210HT003.eurprd02.prod.outlook.com; FPR:ECFBF1F4.D3F2D712.B3F1B07B.98A6DD41.20454; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/T7SIx2LMvF8MTjxE56tYBzuCOtk Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 16:10:48 -0000 YANG (with NETCONF) is designed for writing configuration and reading everything else, and does an excellent job at it. Trouble is, for me, that configuration doesn't mean what I think of it as; it means, in the YANG context, what you might put in through the CLI and it excludes everything else, such as data learnt via a protocol. Take routing. A static route is configuration; anything learnt, via BGP, IS-IS, RIP etc, is not configuration (and is read only). An interface configured automatically on a hot-plugged card is not configuration; adding 'ospf passive' is. And so on, for DHCP, NTP, ..... In practice, this means that the YANG model comes in twin sets, one of read-write configuration and one of read-only not-configuration (as can be seen in the current I-Ds that the netmod WG is producing) with no formal way in YANG of relating the one to the other. So if you want e.g. the routing table, the host software has to know where to look and how to combine the pieces to produce a coherent picture (and then you cannot edit most of it). So if I2RS never wants to write anything to a router, YANG is fine; if I2RS is only producing a Information Model (and ignoring whether or not data is read-only or read-write), and not moving on to an implementation, then YANG is fine. Rather, as Andy Bierman said at IETF89, likely I2RS would need an extension to YANG, a new sub-statement for all data objects, semantics not too clear but designed to separate out the not-configuration, learnt via a protocol, 'editable-state' (and in doing so, making it read-write - but still 'config false'). Yes, YANG allows for such extensions but it seems to me that I2RS would then be getting YANG++ (and NETCONF++), once the necessary work has been done. Tom Petch ----- Original Message ----- From: "Edward Crabbe" To: Sent: Friday, April 11, 2014 6:50 PM Subject: [i2rs] consensus on I2RS protocol and model > Dear I2RSers, > > > At the last I2RS WG meeting there was a great deal of conversation > regarding selection of both modeling language and underlying transport > protocol. Consensus at the time was to make use of Yang and (NetConf or > RestConf) (unclear). > > Before coming to a final consensus, we'd like to give people adequate > time to review source material, marshall arguments and discuss on the > mailing list. To this end, we're asking that interested parties do just > this over the course of the next ~two weeks. Following that period, on > 4/28, we'll be initiating a consensus call that will last an additional two > weeks, with the aim of converging modeling language / protocol by Friday, > 5/9. > > The consensus call should also generate proposals for any material changes > required to the underlying protocols. These proposals in turn will form > the basis for a later draft including gap analysis and said changes. Those > strongly in favor of one protocol over another should be prepared to > contribute to this analysis. > > > best, > > -ed > ------------------------------------------------------------------------ -------- > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Apr 23 09:22:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827921A0381 for ; Wed, 23 Apr 2014 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8jFBDsSoe59 for ; Wed, 23 Apr 2014 09:22:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 413731A0389 for ; Wed, 23 Apr 2014 09:22:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'t.petch'" , "'Edward Crabbe'" , References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> In-Reply-To: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> Date: Wed, 23 Apr 2014 12:21:54 -0400 Message-ID: <010a01cf5f10$2498c1a0$6dca44e0$@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: AQNnmQphth37jSxo2JyFHVfe58SH+gG4HiDPl+Eqx+A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/w-Lv0zGm3DIR1gbg523jPAmQqCg Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 16:22:08 -0000 Tom: 100% agree with your comments. I2RS cares whether it is read-only or read-write. My work toward the revision found: - RBNF RBNF did not even allow you a place to r/w or r-only or permissions (needed for security, but that's my next draft). - The yang tree I wrote was r-w for config, but did not express the ro-only tree. I wanted some feedback to figure out why I had 2 write 2 trees. (your telling me it is a yang short-coming). - UML seems to be able to handle read/write variants, and I'm looking to see if graphical tools will help the developer. Not shown in the reduction: ... And I started working on BGP, ISIS, RIP.. only to find some of these issues you mention. DCHP and NTP. Any suggestions or help would be gratefully accepted. I will continue to try to get more details on Yang++ and ForCES to see how many wheels fall off. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch Sent: Wednesday, April 23, 2014 12:08 PM To: Edward Crabbe; i2rs@ietf.org Subject: Re: [i2rs] consensus on I2RS protocol and model YANG (with NETCONF) is designed for writing configuration and reading everything else, and does an excellent job at it. Trouble is, for me, that configuration doesn't mean what I think of it as; it means, in the YANG context, what you might put in through the CLI and it excludes everything else, such as data learnt via a protocol. Take routing. A static route is configuration; anything learnt, via BGP, IS-IS, RIP etc, is not configuration (and is read only). An interface configured automatically on a hot-plugged card is not configuration; adding 'ospf passive' is. And so on, for DHCP, NTP, ..... In practice, this means that the YANG model comes in twin sets, one of read-write configuration and one of read-only not-configuration (as can be seen in the current I-Ds that the netmod WG is producing) with no formal way in YANG of relating the one to the other. So if you want e.g. the routing table, the host software has to know where to look and how to combine the pieces to produce a coherent picture (and then you cannot edit most of it). So if I2RS never wants to write anything to a router, YANG is fine; if I2RS is only producing a Information Model (and ignoring whether or not data is read-only or read-write), and not moving on to an implementation, then YANG is fine. Rather, as Andy Bierman said at IETF89, likely I2RS would need an extension to YANG, a new sub-statement for all data objects, semantics not too clear but designed to separate out the not-configuration, learnt via a protocol, 'editable-state' (and in doing so, making it read-write - but still 'config false'). Yes, YANG allows for such extensions but it seems to me that I2RS would then be getting YANG++ (and NETCONF++), once the necessary work has been done. Tom Petch ----- Original Message ----- From: "Edward Crabbe" To: Sent: Friday, April 11, 2014 6:50 PM Subject: [i2rs] consensus on I2RS protocol and model > Dear I2RSers, > > > At the last I2RS WG meeting there was a great deal of conversation > regarding selection of both modeling language and underlying transport > protocol. Consensus at the time was to make use of Yang and (NetConf or > RestConf) (unclear). > > Before coming to a final consensus, we'd like to give people adequate > time to review source material, marshall arguments and discuss on the > mailing list. To this end, we're asking that interested parties do just > this over the course of the next ~two weeks. Following that period, on > 4/28, we'll be initiating a consensus call that will last an additional two > weeks, with the aim of converging modeling language / protocol by Friday, > 5/9. > > The consensus call should also generate proposals for any material changes > required to the underlying protocols. These proposals in turn will form > the basis for a later draft including gap analysis and said changes. Those > strongly in favor of one protocol over another should be prepared to > contribute to this analysis. > > > best, > > -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 From nobody Wed Apr 23 10:00:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FED1A03B6 for ; Wed, 23 Apr 2014 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92oWBmbKEj2B for ; Wed, 23 Apr 2014 10:00:13 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40F1A03CC for ; Wed, 23 Apr 2014 10:00:12 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so1119442qab.9 for ; Wed, 23 Apr 2014 10:00:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UKYtezJm1a5x0rfYEC2eftpV52nSD/fGW5zhtxYyWL8=; b=k6pMIh7SfbbrnnmqEg497WwLEBF3vDeyigiIW8UcPg8/9G5STvqq83KTzWx5olunEq x4qGd4ya1p7TrFnpcvfc2K0isaOdI1ulT3Yrs9aRn+2Vr3UbzSKmTeImcqUmTDiq5vf9 FhWuEayXFwH1GyIxx6q4qlDs0FczJtaLX3Z9TIMHi+TM8IeHAC0sJiYyiStPe/wvI304 +cqWWLDiNXU75F7AA1DKEeVu+yazG9+ZWKwok7pF/bumbBMmWre1wAFpHIyXSXD7lafm VoX5OLKp4UYAhD3f9qctMyhSHqktvM5PuNuIxX23Meyus1UfUXhPpa68qsRdE4diVTJi vT1Q== X-Gm-Message-State: ALoCoQlzczq2X1Q7BAaXjhYSCu+kExVm0RkcLsrrhD0vdmtR1gNy4GFqKB26GXbe6xUxW9AOumqm MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr23354714qad.88.1398272395478; Wed, 23 Apr 2014 09:59:55 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 09:59:55 -0700 (PDT) In-Reply-To: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> Date: Wed, 23 Apr 2014 09:59:55 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=089e0158a9e46ea55004f7b8a9c7 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oyRwjL2HdQMS6m4jW6CubH0lhEI Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 17:00:16 -0000 --089e0158a9e46ea55004f7b8a9c7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 9:07 AM, t.petch wrote: > YANG (with NETCONF) is designed for writing configuration and reading > everything else, and does an excellent job at it. Trouble is, for me, > that configuration doesn't mean what I think of it as; it means, in the > YANG context, what you might put in through the CLI and it excludes > everything else, such as data learnt via a protocol. > > Take routing. A static route is configuration; anything learnt, via > BGP, IS-IS, RIP etc, is not configuration (and is read only). > > An interface configured automatically on a hot-plugged card is not > configuration; adding 'ospf passive' is. > > And so on, for DHCP, NTP, ..... > > In practice, this means that the YANG model comes in twin sets, one of > read-write configuration and one of read-only not-configuration (as can > be seen in the current I-Ds that the netmod WG is producing) with no > formal way in YANG of relating the one to the other. So if you want > e.g. the routing table, the host software has to know where to look and > how to combine the pieces to produce a coherent picture (and then you > cannot edit most of it). > > So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS is only producing a Information Model (and ignoring whether or not > data is read-only or read-write), and not moving on to an > implementation, then YANG is fine. > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension to YANG, a new sub-statement for all data objects, semantics > not too clear but designed to separate out the not-configuration, learnt > via a protocol, 'editable-state' (and in doing so, making it > read-write - but still 'config false'). > > Yes, YANG allows for such extensions but it seems to me that I2RS would > then be getting YANG++ (and NETCONF++), once the necessary work has been > done. > So far, 2 extensions have been identified that are needed by I2RS. 1) identification of editable operational state. The config=false property in YANG will cause NETCONF and RESTCONF to (correctly) treat operational state as read-only. I2RS servers must implement the extension: The I2RS protocol will use its own access control model on this data. NACM is not required. e.g. (not real data, just example!) extension edit-data { description "If this statement is present, and the parent statement represents a non-configuration data node, then instances of this data node can be modified by a client."; } container rib { config false; i2rs:edit-data; .... } 2) identification of objects associated with event notifications This could also be done with a YANG extension, and there is a proposal to change YANG 1.1 to support this feature: extension event-object { description "If this statement is present, and the parent statement is a notification statement, then the 'path' argument represents the resource associated with the notification."; argument path; } notification some-interface-event { i2rs:event-object /if:interfaces/if:interface; leaf name { type leafref { path /if:interfaces/if:interface/if:name; } } leaf some-data { type string; } .... } Nobody said YANG or ForCES could be used without any modifications to support I2RS. YANG allows instant modifications that require no changes to the language specification. > Tom Petch > Andy > > > ----- Original Message ----- > From: "Edward Crabbe" > To: > Sent: Friday, April 11, 2014 6:50 PM > Subject: [i2rs] consensus on I2RS protocol and model > > > > Dear I2RSers, > > > > > > At the last I2RS WG meeting there was a great deal of conversation > > regarding selection of both modeling language and underlying transport > > protocol. Consensus at the time was to make use of Yang and (NetConf > or > > RestConf) (unclear). > > > > Before coming to a final consensus, we'd like to give people > adequate > > time to review source material, marshall arguments and discuss on the > > mailing list. To this end, we're asking that interested parties do > just > > this over the course of the next ~two weeks. Following that period, on > > 4/28, we'll be initiating a consensus call that will last an > additional two > > weeks, with the aim of converging modeling language / protocol by > Friday, > > 5/9. > > > > The consensus call should also generate proposals for any material > changes > > required to the underlying protocols. These proposals in turn will > form > > the basis for a later draft including gap analysis and said changes. > Those > > strongly in favor of one protocol over another should be prepared to > > contribute to this analysis. > > > > > > best, > > > > -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 > --089e0158a9e46ea55004f7b8a9c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 23, 2014 at 9:07 AM, t.petch <ietfc@btconnect.com> wrote:
YANG (with NETCONF) is designed for writing configuration = and reading
everything else, and does an excellent job at it. =A0Trouble is, for me, that configuration doesn't mean what I think of it as; it means, in the=
YANG context, what you might put in through the CLI and it excludes
everything else, such as data learnt via a protocol.

Take routing. =A0A static route is configuration; anything learnt, via
BGP, IS-IS, RIP etc, is not configuration (and is read only).

An interface configured automatically on a hot-plugged card is not
configuration; adding 'ospf passive' is.

And so on, for DHCP, NTP, .....

In practice, this means that the YANG model comes in twin sets, one of
read-write configuration and one of read-only not-configuration (as can
be seen in the current I-Ds that the netmod WG is producing) with no
formal way in YANG of relating the one to the other. =A0So if you want
e.g. the routing table, the host software has to know where to look and
how to combine the pieces to produce a coherent picture (and then you
cannot edit most of it).

So if I2RS never wants to write anything to a router, YANG is fine; if
I2RS is only producing a Information Model (and ignoring whether or not
data is read-only or read-write), and not moving on to an
implementation, then YANG is fine.

Rather, as Andy Bierman said at IETF89, likely I2RS would need an
extension to YANG, a new sub-statement for all data objects, semantics
not too clear but designed to separate out the not-configuration, learnt via a protocol, 'editable-state' (and in doing so, making it
read-write - but still 'config false').

Yes, YANG allows for such extensions but it seems to me that I2RS would
then be getting YANG++ (and NETCONF++), once the necessary work has been done.


So far, 2 extensio= ns have been identified that are needed by I2RS.

1= ) identification of editable operational state.
=A0 =A0 The confi= g=3Dfalse property in YANG will cause NETCONF and RESTCONF
=A0 =A0 to (correctly) treat operational state as read-only. I2RS serv= ers must
=A0 =A0 implement the extension: The I2RS protocol will = use its own access control
=A0 =A0 model on this data. NACM is no= t required.

=A0 =A0e.g. (not real data, just example!)
=A0 =A0extension edit-data {
=A0 =A0 =A0 =A0descript= ion
=A0 =A0 =A0 =A0 =A0 "If this statement is present, and t= he parent statement represents
=A0 =A0 =A0 =A0 =A0 =A0a non-configuration data node, then instances o= f this data node
=A0 =A0 =A0 =A0 =A0 =A0can be modified by a clie= nt.";
=A0 =A0}
=A0 =A0 =A0=A0
=A0 = =A0container rib {
=A0 =A0 =A0 config false;
=A0 =A0 =A0 i2rs:edit-data;
=A0 =A0 =A0 ....
=A0 = =A0}

2) identification of objects associated with = event notifications

This could also be done with a= YANG extension, and there is a proposal
to change YANG 1.1 to support this feature:
=A0 =A0
=A0 =A0extension event-object {
=A0 =A0 =A0 =A0 =A0 "If this statement is present, and the parent st= atement is
=A0 =A0}

=A0 =A0notification some-interface-event {
=A0 =A0 =A0 i2rs:= event-object /if:interfaces/if:interface;

=A0 =A0 = =A0 leaf name {
=A0 =A0 =A0 =A0 =A0type leafref { path /if:interf= aces/if:interface/if:name; }
=A0 =A0 =A0 }
=A0 =A0 =A0 leaf some-data { type string; }
=A0 =A0 =A0 ....
=A0 =A0}

Nobody= said YANG or ForCES could be used without any modifications
to s= upport I2RS. =A0YANG allows instant modifications that require no
changes to the language specification.




Tom Petch

Andy

=A0


----- Original Message -----
From: "Edward Crabbe" <edc@g= oogle.com>
To: <i2rs@ietf.org>
Sent: Friday, April 11, 2014 6:50 PM
Subject: [i2rs] consensus on I2RS protocol and model


> Dear I2RSers,
>
>
> =A0 At the last I2RS WG meeting there was a great deal of conversation=
> regarding selection of both modeling language and underlying transport=
> protocol. =A0Consensus at the time was to make use of Yang and (NetCon= f
or
> RestConf) (unclear).
>
> =A0 Before coming to a final consensus, we'd like to give people adequate
> time to review source material, marshall arguments and discuss on the<= br> > mailing list. =A0To this end, we're asking that interested parties= do
just
> this over the course of the next ~two weeks. Following that period, on=
> 4/28, we'll be initiating a consensus call that will last an
additional two
> weeks, with the aim of converging modeling language / protocol by
Friday,
> 5/9.
>
> The consensus call should also generate proposals for any material
changes
> required to the underlying protocols. =A0These proposals in turn will<= br> form
> the basis for a later draft including gap analysis and said changes. Those
> strongly in favor of one protocol over another should be prepared to > contribute to this analysis.
>
>
> best,
>
> =A0 -ed
>


------------------------------------------------------------------------ --------


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

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

--089e0158a9e46ea55004f7b8a9c7-- From nobody Wed Apr 23 10:09:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6C1A03B6 for ; Wed, 23 Apr 2014 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up4avVwpfwtT for ; Wed, 23 Apr 2014 10:08:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D92471A0221 for ; Wed, 23 Apr 2014 10:08:58 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id CE067384005; Wed, 23 Apr 2014 19:08:51 +0200 (CEST) Date: Wed, 23 Apr 2014 19:08:51 +0200 (CEST) Message-Id: <20140423.190851.213360502.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/foHilRQfWfbZuWmR94DOmSdZkpQ Cc: i2rs@ietf.org, edc@google.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 17:09:00 -0000 t.petch wrote: > YANG (with NETCONF) is designed for writing configuration and reading > everything else, and does an excellent job at it. Trouble is, for me, > that configuration doesn't mean what I think of it as; it means, in the > YANG context, what you might put in through the CLI and it excludes > everything else, such as data learnt via a protocol. This is true, but more for NETCONF than for YANG. I think it has been clear from the start that I2RS probably needs some (hopefully minor) extensions to NETCONF and/or YANG, should we choose to use these technologies. Also, I think it has been pretty clear that what is missing is a way to identify writable data that is not configuration (in the NETCONF/YANG sense). > In practice, this means that the YANG model comes in twin sets, one of > read-write configuration and one of read-only not-configuration (as can > be seen in the current I-Ds that the netmod WG is producing) Correct. This reflects how it usually works on devices; most routers and similar equipment has a "config mode CLI" and "show commands"; a linux box has config files and various ways of reading and writing operational state (/proc, direct apis...) These are different structures with different syntax and semantics. (SNMP tried to combine the two into one, but this turned out to be problematic.) > with no > formal way in YANG of relating the one to the other. So if you want > e.g. the routing table, the host software has to know where to look and > how to combine the pieces to produce a coherent picture (and then you > cannot edit most of it). > > So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS is only producing a Information Model (and ignoring whether or not > data is read-only or read-write), and not moving on to an > implementation, then YANG is fine. > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension to YANG, a new sub-statement for all data objects, semantics > not too clear but designed to separate out the not-configuration, learnt > via a protocol, 'editable-state' (and in doing so, making it > read-write - but still 'config false'). > > Yes, YANG allows for such extensions but it seems to me that I2RS would > then be getting YANG++ (and NETCONF++), once the necessary work has been > done. You can call it YANG++ and NETCONF++, but the fact is that these things can be done today, without having to revise the YANG or NETCONF specs, by using the current extensibility mechanisms. /martin From nobody Wed Apr 23 11:20:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1F1A0429 for ; Wed, 23 Apr 2014 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN71uzFTUBcr for ; Wed, 23 Apr 2014 11:20:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id AC7711A0424 for ; Wed, 23 Apr 2014 11:20:35 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 23 Apr 2014 18:20:28 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) with mapi id 15.00.0921.000; Wed, 23 Apr 2014 18:20:28 +0000 From: Dean Bogdanovic To: Martin Bjorklund Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsfclangAAPsYCAABP/gA== Date: Wed, 23 Apr 2014 18:20:27 +0000 Message-ID: <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> In-Reply-To: <20140423.190851.213360502.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(377454003)(51704005)(199002)(189002)(81542001)(66066001)(88136002)(50226001)(4396001)(46102001)(33656001)(83072002)(77156001)(99396002)(62966002)(85852003)(81342001)(99286001)(19580395003)(19580405001)(83322001)(74662001)(20776003)(74502001)(551934002)(76176999)(93916002)(80976001)(50986999)(15975445006)(86362001)(57306001)(36756003)(76482001)(79102001)(89996001)(31966008)(2656002)(83716003)(80022001)(92566001)(82746002)(87286001)(87936001)(77982001)(92726001)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:E637F1D5.A3F2F710.B1CC1D7B.90A6D143.2054F; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xawcJYBZcMuHYHf7aa7VUr4wngw Cc: "" , "" , "" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 18:20:38 -0000 Martin et alii, The suggested protocol for i2rs is RESTCONF. Let me put quickly pros and co= ns for RESTCONF with few use cases. Although there are many similarities between those two protocols, there are= differences. Biggest negative for both, RESTCONF and NETCONF is lack of po= ssibility to modify operational state of the device.=20 Cons: No network locking model Can=92t modify operational state of network device Using JSON only simple meta-data is supported Pros: Unified data store Provides atomicity of transaction Simplified defaults handling Allows multiple edits (with PATCH) within single message Providing abstracted simplified config model Supports XML and JSON Streaming via Server-Sent-Events Edit collision detection I2RS clearly needs capability to modify operational state of the device. Wi= th unified data store that should be easier to achieve for RESTCONF then NE= TCONF, where multiple data stores are supported. I envision that only transient changes are configured via RESTCONF. Any per= sistent changes IMO, should go via NETCONF.=20 Does the WG see a need for i2rs to provide mechanism for persistent changes= ? Following 3, I view very connected, simplified defaults handling, atomicity= of transaction and abstracted simplified config model. With simplified con= figuration models, we can create=20 With RESTCONF we want to ensure that a single transaction is making a meani= ngful request that can be fulfilled. This means that request can be either = fulfilled or the transaction will fail. The simplified defaults handling ma= kes the process easier. In case of writing, if not all the parameters are p= rovided and there are no default arguments for the missing parameter, trans= action will fail. For the performance reasons, support for PATCH is very good, as it allows m= ultiple updates in single transaction. It is not the same to send 1000 tran= sactions to update 1000 routes or 1000 routes are updated in single transac= tion. With this capability clients can execute much faster changes to the s= ystem. Lacking support for network locking model is an issue if there is a service= activated across multiple devices via i2rs and in case of an error on one = device, client has to be able to clean up on the other devices. Is this a v= iable use case that would prevent use of RESTCONF for i2rs? Dean On Apr 23, 2014, at 1:08 PM, Martin Bjorklund wrote: > t.petch wrote: >> YANG (with NETCONF) is designed for writing configuration and reading >> everything else, and does an excellent job at it. Trouble is, for me, >> that configuration doesn't mean what I think of it as; it means, in the >> YANG context, what you might put in through the CLI and it excludes >> everything else, such as data learnt via a protocol. >=20 > This is true, but more for NETCONF than for YANG. I think it has been > clear from the start that I2RS probably needs some (hopefully minor) > extensions to NETCONF and/or YANG, should we choose to use these > technologies. >=20 > Also, I think it has been pretty clear that what is missing is a way > to identify writable data that is not configuration (in the > NETCONF/YANG sense). >=20 >> In practice, this means that the YANG model comes in twin sets, one of >> read-write configuration and one of read-only not-configuration (as can >> be seen in the current I-Ds that the netmod WG is producing) >=20 > Correct. This reflects how it usually works on devices; most routers > and similar equipment has a "config mode CLI" and "show commands"; a > linux box has config files and various ways of reading and writing > operational state (/proc, direct apis...) These are different > structures with different syntax and semantics. >=20 > (SNMP tried to combine the two into one, but this turned out to be > problematic.) >=20 >> with no >> formal way in YANG of relating the one to the other. So if you want >> e.g. the routing table, the host software has to know where to look and >> how to combine the pieces to produce a coherent picture (and then you >> cannot edit most of it). >>=20 >> So if I2RS never wants to write anything to a router, YANG is fine; if >> I2RS is only producing a Information Model (and ignoring whether or not >> data is read-only or read-write), and not moving on to an >> implementation, then YANG is fine. >>=20 >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >> extension to YANG, a new sub-statement for all data objects, semantics >> not too clear but designed to separate out the not-configuration, learnt >> via a protocol, 'editable-state' (and in doing so, making it >> read-write - but still 'config false'). >>=20 >> Yes, YANG allows for such extensions but it seems to me that I2RS would >> then be getting YANG++ (and NETCONF++), once the necessary work has been >> done. >=20 > You can call it YANG++ and NETCONF++, but the fact is that these > things can be done today, without having to revise the YANG or NETCONF > specs, by using the current extensibility mechanisms. >=20 >=20 > /martin >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Apr 23 12:54:58 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282AD1A049A for ; Wed, 23 Apr 2014 12:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G02OW2U5jgnj for ; Wed, 23 Apr 2014 12:54:52 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC51A0502 for ; Wed, 23 Apr 2014 12:54:50 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id x13so646338qcv.35 for ; Wed, 23 Apr 2014 12:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=92h5o91rnmwyHp1JsHPtEXEMeRqEzPQQfC2ciEGR7sc=; b=QdWMNaAS+tywDURCfJyjUmdoL0J1EaIezCemMDr15RnEHhMTrFM07dSn2oIYXboUp2 1NRRlQm6f33vQdpkOzC9re9O3I7+J68NIEMDYE2FgRT4I0ofPp6nSAEQJCslmcgtfuW3 sqwIetx7NABq2K75iap+Um0vJS55/1l05aMqc2qklyzQH9FWWTXGXXKmSvuWRs4naMkV qBBtSnzKBpm5LVEwBhzsxWocJiZJy65Ruw+vYSMkNpkYEripEaKqNjqpf5cTVE3nsFDp i+08YqHxT00niocAJDa0MnBQvjyn6e0qpFBlG5cf/D8XB6/QXtb7cdy1+s+kEtc5vmPN YtAA== X-Gm-Message-State: ALoCoQmLYVuvH3jJWfrqPnFQtVbVbSyxVcF+cmwwvWfeDPoSBHoE23YSPry1D8VT8sUrYKP08vmy MIME-Version: 1.0 X-Received: by 10.224.136.74 with SMTP id q10mr54640126qat.78.1398282884178; Wed, 23 Apr 2014 12:54:44 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 12:54:44 -0700 (PDT) In-Reply-To: <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> Date: Wed, 23 Apr 2014 12:54:44 -0700 Message-ID: From: Andy Bierman To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a11c2b61e9ba5a904f7bb1af9 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Bpnwb9heIoGmlvwLgKfZ7OFq8e0 Cc: "" , Martin Bjorklund , "" , "" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 19:54:56 -0000 --001a11c2b61e9ba5a904f7bb1af9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 11:20 AM, Dean Bogdanovic wrote: > Martin et alii, > > The suggested protocol for i2rs is RESTCONF. Let me put quickly pros and > cons for RESTCONF with few use cases. > > Although there are many similarities between those two protocols, there > are differences. Biggest negative for both, RESTCONF and NETCONF is lack of > possibility to modify operational state of the device. > > Cons: > No network locking model > Can't modify operational state of network device > Using JSON only simple meta-data is supported > > Pros: > Unified data store > Provides atomicity of transaction > Simplified defaults handling > Allows multiple edits (with PATCH) within single message > Providing abstracted simplified config model > Supports XML and JSON > Streaming via Server-Sent-Events > Edit collision detection > > I2RS clearly needs capability to modify operational state of the device. > With unified data store that should be easier to achieve for RESTCONF then > NETCONF, where multiple data stores are supported. > I envision that only transient changes are configured via RESTCONF. Any > persistent changes IMO, should go via NETCONF. > Does the WG see a need for i2rs to provide mechanism for persistent > changes? > > Following 3, I view very connected, simplified defaults handling, > atomicity of transaction and abstracted simplified config model. With > simplified configuration models, we can create > With RESTCONF we want to ensure that a single transaction is making a > meaningful request that can be fulfilled. This means that request can be > either fulfilled or the transaction will fail. The simplified defaults > handling makes the process easier. In case of writing, if not all the > parameters are provided and there are no default arguments for the missing > parameter, transaction will fail. > > For the performance reasons, support for PATCH is very good, as it allows > multiple updates in single transaction. It is not the same to send 1000 > transactions to update 1000 routes or 1000 routes are updated in single > transaction. With this capability clients can execute much faster changes > to the system. > > I agree the RESTCONF session-less approach is better is the client does not need to change things very often, or changes can be done in bulk. That may not be the case, for example, if the client is really a broker coordinating lots of I2RS applications, so it is sending very frequently. Then the session-based NETCONF approach might work better. If the cost of authentication is high, RESTCONF would probably be slower than NETCONF. Lacking support for network locking model is an issue if there is a service > activated across multiple devices via i2rs and in case of an error on one > device, client has to be able to clean up on the other devices. Is this a > viable use case that would prevent use of RESTCONF for i2rs? > I thought I2RS is starting out focusing on 1 client and 1 agent. Network locking across devices is out of scope. > > Dean > > > Andy > On Apr 23, 2014, at 1:08 PM, Martin Bjorklund wrote: > > > t.petch wrote: > >> YANG (with NETCONF) is designed for writing configuration and reading > >> everything else, and does an excellent job at it. Trouble is, for me, > >> that configuration doesn't mean what I think of it as; it means, in the > >> YANG context, what you might put in through the CLI and it excludes > >> everything else, such as data learnt via a protocol. > > > > This is true, but more for NETCONF than for YANG. I think it has been > > clear from the start that I2RS probably needs some (hopefully minor) > > extensions to NETCONF and/or YANG, should we choose to use these > > technologies. > > > > Also, I think it has been pretty clear that what is missing is a way > > to identify writable data that is not configuration (in the > > NETCONF/YANG sense). > > > >> In practice, this means that the YANG model comes in twin sets, one of > >> read-write configuration and one of read-only not-configuration (as can > >> be seen in the current I-Ds that the netmod WG is producing) > > > > Correct. This reflects how it usually works on devices; most routers > > and similar equipment has a "config mode CLI" and "show commands"; a > > linux box has config files and various ways of reading and writing > > operational state (/proc, direct apis...) These are different > > structures with different syntax and semantics. > > > > (SNMP tried to combine the two into one, but this turned out to be > > problematic.) > > > >> with no > >> formal way in YANG of relating the one to the other. So if you want > >> e.g. the routing table, the host software has to know where to look and > >> how to combine the pieces to produce a coherent picture (and then you > >> cannot edit most of it). > >> > >> So if I2RS never wants to write anything to a router, YANG is fine; if > >> I2RS is only producing a Information Model (and ignoring whether or not > >> data is read-only or read-write), and not moving on to an > >> implementation, then YANG is fine. > >> > >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an > >> extension to YANG, a new sub-statement for all data objects, semantics > >> not too clear but designed to separate out the not-configuration, learnt > >> via a protocol, 'editable-state' (and in doing so, making it > >> read-write - but still 'config false'). > >> > >> Yes, YANG allows for such extensions but it seems to me that I2RS would > >> then be getting YANG++ (and NETCONF++), once the necessary work has been > >> done. > > > > You can call it YANG++ and NETCONF++, but the fact is that these > > things can be done today, without having to revise the YANG or NETCONF > > specs, by using the current extensibility mechanisms. > > > > > > /martin > > > > _______________________________________________ > > 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 > --001a11c2b61e9ba5a904f7bb1af9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 23, 2014 at 11:20 AM, Dean Bogdanovic <deanb@juniper.n= et> wrote:
Martin et alii,

The suggested protocol for i2rs is RESTCONF. Let me put quickly pros and co= ns for RESTCONF with few use cases.

Although there are many similarities between those two protocols, there are= differences. Biggest negative for both, RESTCONF and NETCONF is lack of po= ssibility to modify operational state of the device.

Cons:
No network locking model
Can’t modify operational state of network device
Using JSON only simple meta-data is supported

Pros:
Unified data store
Provides atomicity of transaction
Simplified defaults handling
Allows multiple edits (with PATCH) within single message
Providing abstracted simplified config model
Supports XML and JSON
Streaming via Server-Sent-Events
Edit collision detection

I2RS clearly needs capability to modify operational state of the device. Wi= th unified data store that should be easier to achieve for RESTCONF then NE= TCONF, where multiple data stores are supported.
I envision that only transient changes are configured via RESTCONF. Any per= sistent changes IMO, should go via NETCONF.
Does the WG see a need for i2rs to provide mechanism for persistent changes= ?

Following 3, I view very connected, simplified defaults handling, atomicity= of transaction and abstracted simplified config model. With simplified con= figuration models, we can create
With RESTCONF we want to ensure that a single transaction is making a meani= ngful request that can be fulfilled. This means that request can be either = fulfilled or the transaction will fail. The simplified defaults handling ma= kes the process easier. In case of writing, if not all the parameters are p= rovided and there are no default arguments for the missing parameter, trans= action will fail.

For the performance reasons, support for PATCH is very good, as it allows m= ultiple updates in single transaction. It is not the same to send 1000 tran= sactions to update 1000 routes or 1000 routes are updated in single transac= tion. With this capability clients can execute much faster changes to the s= ystem.



I agree the RESTCONF se= ssion-less approach is better is the client does not need
to chan= ge things very often, or changes can be done in bulk.

That may not be the case, for example, if the client is really a broke= r
coordinating lots of I2RS applications, so it is sending very f= requently.
Then the session-based NETCONF approach might work bet= ter.
If the cost of authentication is high, RESTCONF would probably be slow= er than NETCONF.


Lacking support for network locking model is an issue if there is a service= activated across multiple devices via i2rs and in case of an error on one = device, client has to be able to clean up on the other devices. Is this a v= iable use case that would prevent use of RESTCONF for i2rs?


I thought I2RS is starting = out focusing on 1 client and 1 agent.
Network locking across devi= ces is out of scope.

 

Dean




Andy
 
On Apr 23, 2014, at 1:08 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> t.petch <ietfc@btconnect.com= > wrote:
>> YANG (with NETCONF) is designed for writing configuration and read= ing
>> everything else, and does an excellent job at it.  Trouble is= , for me,
>> that configuration doesn't mean what I think of it as; it mean= s, in the
>> YANG context, what you might put in through the CLI and it exclude= s
>> everything else, such as data learnt via a protocol.
>
> This is true, but more for NETCONF than for YANG.  I think it has= been
> clear from the start that I2RS probably needs some (hopefully minor) > extensions to NETCONF and/or YANG, should we choose to use these
> technologies.
>
> Also, I think it has been pretty clear that what is missing is a way > to identify writable data that is not configuration (in the
> NETCONF/YANG sense).
>
>> In practice, this means that the YANG model comes in twin sets, on= e of
>> read-write configuration and one of read-only not-configuration (a= s can
>> be seen in the current I-Ds that the netmod WG is producing)
>
> Correct.  This reflects how it usually works on devices; most rou= ters
> and similar equipment has a "config mode CLI" and "show= commands"; a
> linux box has config files and various ways of reading and writing
> operational state (/proc, direct apis...)  These are different > structures with different syntax and semantics.
>
> (SNMP tried to combine the two into one, but this turned out to be
> problematic.)
>
>> with no
>> formal way in YANG of relating the one to the other.  So if y= ou want
>> e.g. the routing table, the host software has to know where to loo= k and
>> how to combine the pieces to produce a coherent picture (and then = you
>> cannot edit most of it).
>>
>> So if I2RS never wants to write anything to a router, YANG is fine= ; if
>> I2RS is only producing a Information Model (and ignoring whether o= r not
>> data is read-only or read-write), and not moving on to an
>> implementation, then YANG is fine.
>>
>> Rather, as Andy Bierman said at IETF89, likely I2RS would need an<= br> >> extension to YANG, a new sub-statement for all data objects, seman= tics
>> not too clear but designed to separate out the not-configuration, = learnt
>> via a protocol, 'editable-state' (and in doing so, making = it
>> read-write - but still 'config false').
>>
>> Yes, YANG allows for such extensions but it seems to me that I2RS = would
>> then be getting YANG++ (and NETCONF++), once the necessary work ha= s been
>> done.
>
> You can call it YANG++ and NETCONF++, but the fact is that these
> things can be done today, without having to revise the YANG or NETCONF=
> specs, by using the current extensibility mechanisms.
>
>
> /martin
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--001a11c2b61e9ba5a904f7bb1af9-- From nobody Wed Apr 23 13:19:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701621A04B4 for ; Wed, 23 Apr 2014 13:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvPG6hhh7u9Q for ; Wed, 23 Apr 2014 13:19:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) by ietfa.amsl.com (Postfix) with ESMTP id 37A5D1A0584 for ; Wed, 23 Apr 2014 13:19:47 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 23 Apr 2014 20:19:39 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.91]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) with mapi id 15.00.0921.000; Wed, 23 Apr 2014 20:19:39 +0000 From: Dean Bogdanovic To: Andy Bierman Thread-Topic: [i2rs] consensus on I2RS protocol and model Thread-Index: AQHPVa7JW2PqjJWao0awJm624ETikpsfclangAAPsYCAABP/gIAAGloAgAAG9IA= Date: Wed, 23 Apr 2014 20:19:38 +0000 Message-ID: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(51694002)(199002)(189002)(24454002)(377454003)(93916002)(76176999)(36756003)(76482001)(50986999)(80976001)(86362001)(57306001)(74502001)(20776003)(87936001)(87286001)(92726001)(77982001)(89996001)(31966008)(79102001)(83716003)(80022001)(82746002)(92566001)(2656002)(33656001)(77156001)(99396002)(83072002)(88136002)(50226001)(4396001)(81542001)(66066001)(46102001)(74662001)(19580395003)(83322001)(99286001)(19580405001)(16236675002)(85852003)(62966002)(81342001)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:B6D6CAD1.809A0119.797DAFB7.E14259.20179; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D44AEB5215E9461482DBA289F1636261junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1d3ywC-xeZGEBexgpwH4Skip78A Cc: "" , Martin Bjorklund , "" , "" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 20:19:49 -0000 --_000_D44AEB5215E9461482DBA289F1636261junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 23, 2014, at 3:54 PM, Andy Bierman > wrote: Lacking support for network locking model is an issue if there is a service= activated across multiple devices via i2rs and in case of an error on one = device, client has to be able to clean up on the other devices. Is this a v= iable use case that would prevent use of RESTCONF for i2rs? I thought I2RS is starting out focusing on 1 client and 1 agent. Network locking across devices is out of scope. I have same opinion as you on this one, just wanted to spell it out one mor= e time explicitly, as I heard some discussions where network locking was co= ming up. Dean --_000_D44AEB5215E9461482DBA289F1636261junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <01EC816E9FDF5E4686CCE15498891DEE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Apr 23, 2014, at 3:54 PM, Andy Bierman <andy@yumaworks.com> wrote:



Lacking support for network locking model is an issue if there is a service= activated across multiple devices via i2rs and in case of an error on one = device, client has to be able to clean up on the other devices. Is this a v= iable use case that would prevent use of RESTCONF for i2rs?


I thought I2RS is starting out focusing on 1 client and 1 agent.
Network locking across devices is out of scope.

I have same opinion as you on this one, just wanted to spell it out one mor= e time explicitly, as I heard some discussions where network locking was co= ming up.

Dean

--_000_D44AEB5215E9461482DBA289F1636261junipernet_-- From nobody Wed Apr 23 23:16:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7B1A030F for ; Wed, 23 Apr 2014 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KifTgbgqqQqt for ; Wed, 23 Apr 2014 23:16:45 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 013161A0062 for ; Wed, 23 Apr 2014 23:16:44 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id e89so2035197qgf.6 for ; Wed, 23 Apr 2014 23:16: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=v3cFXOVNa7XNC98h9DBta+2hF8tZuAcuYsKZXImXqWM=; b=drQA694aZEIGMStFhXIXSLagUvMwGsDuK5sKpNiP3KuC7dmso+bjp0AqCTUPXr0B1K DY2AeqXiUCccTKawo8echgF9Xb0KRL0+FS/x59AdDjAezuWKJ4c8z/HdrWO2SUvXgdIw kM5ylkCTTDoZ1+UVlnHLi4o3pnACdANS6DFkEueNw5n5gUMd3SDpQIL5IuHx11VJ/loM nDEmBjxzmCgV3gEUhLvLoUOsXl8D7FolJg0bmRhAA1F59raswh+oA0Nx0/W3WU6iEpjn KSVwt5sl2//uH+awETyB7WMaAzIt5CbZK5iYAN0uW+RAjPBae7Loo1KoNoiJJDrkN8h1 SIWw== MIME-Version: 1.0 X-Received: by 10.224.57.142 with SMTP id c14mr65594844qah.23.1398320198891; Wed, 23 Apr 2014 23:16:38 -0700 (PDT) Received: by 10.229.192.74 with HTTP; Wed, 23 Apr 2014 23:16:38 -0700 (PDT) In-Reply-To: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> Date: Thu, 24 Apr 2014 14:16:38 +0800 Message-ID: From: chong feng To: "t.petch" Content-Type: multipart/alternative; boundary=089e01536d4abcbc4b04f7c3caa3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/sf0Neq0YPERvMzrN6Uoh5VMjbvc Cc: i2rs@ietf.org, Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 06:16:47 -0000 --089e01536d4abcbc4b04f7c3caa3 Content-Type: text/plain; charset=UTF-8 I think we can introduce a new own protocol that is similar with NETCONF. For example, extensiable RPC mechanism, session control will be reserved, but capabilities and operations and datastores about configuration management(edit-config/get-config etc) will be not reserved, and introduce new datastore/capablities/operations about I2RS. The data model what the new protocol operates will be open, but must be suitable for requirements of I2RS. The encoding of new protocol is open, xml, json, binary,etc are all acceptable. We can suggest YANG model language as preferred data model language of I2RS. YANG is a excellent data model language for configuration management, but it must be extend to adapt to the requirements of I2RS. 2014-04-24 0:07 GMT+08:00 t.petch : > YANG (with NETCONF) is designed for writing configuration and reading > everything else, and does an excellent job at it. Trouble is, for me, > that configuration doesn't mean what I think of it as; it means, in the > YANG context, what you might put in through the CLI and it excludes > everything else, such as data learnt via a protocol. > > Take routing. A static route is configuration; anything learnt, via > BGP, IS-IS, RIP etc, is not configuration (and is read only). > > An interface configured automatically on a hot-plugged card is not > configuration; adding 'ospf passive' is. > > And so on, for DHCP, NTP, ..... > > In practice, this means that the YANG model comes in twin sets, one of > read-write configuration and one of read-only not-configuration (as can > be seen in the current I-Ds that the netmod WG is producing) with no > formal way in YANG of relating the one to the other. So if you want > e.g. the routing table, the host software has to know where to look and > how to combine the pieces to produce a coherent picture (and then you > cannot edit most of it). > > So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS is only producing a Information Model (and ignoring whether or not > data is read-only or read-write), and not moving on to an > implementation, then YANG is fine. > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension to YANG, a new sub-statement for all data objects, semantics > not too clear but designed to separate out the not-configuration, learnt > via a protocol, 'editable-state' (and in doing so, making it > read-write - but still 'config false'). > > Yes, YANG allows for such extensions but it seems to me that I2RS would > then be getting YANG++ (and NETCONF++), once the necessary work has been > done. > > Tom Petch > > > ----- Original Message ----- > From: "Edward Crabbe" > To: > Sent: Friday, April 11, 2014 6:50 PM > Subject: [i2rs] consensus on I2RS protocol and model > > > > Dear I2RSers, > > > > > > At the last I2RS WG meeting there was a great deal of conversation > > regarding selection of both modeling language and underlying transport > > protocol. Consensus at the time was to make use of Yang and (NetConf > or > > RestConf) (unclear). > > > > Before coming to a final consensus, we'd like to give people > adequate > > time to review source material, marshall arguments and discuss on the > > mailing list. To this end, we're asking that interested parties do > just > > this over the course of the next ~two weeks. Following that period, on > > 4/28, we'll be initiating a consensus call that will last an > additional two > > weeks, with the aim of converging modeling language / protocol by > Friday, > > 5/9. > > > > The consensus call should also generate proposals for any material > changes > > required to the underlying protocols. These proposals in turn will > form > > the basis for a later draft including gap analysis and said changes. > Those > > strongly in favor of one protocol over another should be prepared to > > contribute to this analysis. > > > > > > best, > > > > -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 > --089e01536d4abcbc4b04f7c3caa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we can introduce a new own protocol that is simila= r with NETCONF. For example, extensiable RPC=C2=A0mech= anism, session control will be reserved, but capabilities and operations an= d datastores=C2=A0
about configuration management(edit-config/get-config = etc) will be not reserved, and introduce new=C2=A0
datastore/capablities/operations about I2RS.

The data model w= hat the new protocol operates will be open, but must be suitable for requir= ements of I2RS.

The encoding of n= ew protocol is open, xml, json, binary,etc are all acceptable.

We can suggest YA= NG model language as preferred data model language of I2RS.=C2=A0

YANG is a excelle= nt data model language for configuration management, but it must be extend = to adapt=C2=A0
to the requirements of I2RS.


2014-04-24 0:07 GM= T+08:00 t.petch <ietfc@btconnect.com>:
YANG (with NETCONF) is designed for writing = configuration and reading
everything else, and does an excellent job at it. =C2=A0Trouble is, for me,=
that configuration doesn't mean what I think of it as; it means, in the=
YANG context, what you might put in through the CLI and it excludes
everything else, such as data learnt via a protocol.

Take routing. =C2=A0A static route is configuration; anything learnt, via BGP, IS-IS, RIP etc, is not configuration (and is read only).

An interface configured automatically on a hot-plugged card is not
configuration; adding 'ospf passive' is.

And so on, for DHCP, NTP, .....

In practice, this means that the YANG model comes in twin sets, one of
read-write configuration and one of read-only not-configuration (as can
be seen in the current I-Ds that the netmod WG is producing) with no
formal way in YANG of relating the one to the other. =C2=A0So if you want e.g. the routing table, the host software has to know where to look and
how to combine the pieces to produce a coherent picture (and then you
cannot edit most of it).

So if I2RS never wants to write anything to a router, YANG is fine; if
I2RS is only producing a Information Model (and ignoring whether or not
data is read-only or read-write), and not moving on to an
implementation, then YANG is fine.

Rather, as Andy Bierman said at IETF89, likely I2RS would need an
extension to YANG, a new sub-statement for all data objects, semantics
not too clear but designed to separate out the not-configuration, learnt via a protocol, 'editable-state' (and in doing so, making it
read-write - but still 'config false').

Yes, YANG allows for such extensions but it seems to me that I2RS would
then be getting YANG++ (and NETCONF++), once the necessary work has been done.

Tom Petch


----- Original Message -----
From: "Edward Crabbe" <edc@g= oogle.com>
To: <i2rs@ietf.org>
Sent: Friday, April 11, 2014 6:50 PM
Subject: [i2rs] consensus on I2RS protocol and model


> Dear I2RSers,
>
>
> =C2=A0 At the last I2RS WG meeting there was a great deal of conversat= ion
> regarding selection of both modeling language and underlying transport=
> protocol. =C2=A0Consensus at the time was to make use of Yang and (Net= Conf
or
> RestConf) (unclear).
>
> =C2=A0 Before coming to a final consensus, we'd like to give peopl= e
adequate
> time to review source material, marshall arguments and discuss on the<= br> > mailing list. =C2=A0To this end, we're asking that interested part= ies do
just
> this over the course of the next ~two weeks. Following that period, on=
> 4/28, we'll be initiating a consensus call that will last an
additional two
> weeks, with the aim of converging modeling language / protocol by
Friday,
> 5/9.
>
> The consensus call should also generate proposals for any material
changes
> required to the underlying protocols. =C2=A0These proposals in turn wi= ll
form
> the basis for a later draft including gap analysis and said changes. Those
> strongly in favor of one protocol over another should be prepared to > contribute to this analysis.
>
>
> best,
>
> =C2=A0 -ed
>


------------------------------------------------------------------------ --------


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

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

--089e01536d4abcbc4b04f7c3caa3-- From nobody Thu Apr 24 02:20:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4000A1A07EF for ; Thu, 24 Apr 2014 02:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eY_R1032DTd for ; Thu, 24 Apr 2014 02:20:05 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 188341A07DC for ; Thu, 24 Apr 2014 02:20:04 -0700 (PDT) Received: from DBXPRD0210HT004.eurprd02.prod.outlook.com (157.56.253.181) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 09:19:57 +0000 Message-ID: <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> Date: Thu, 24 Apr 2014 10:17:41 +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-ClientProxiedBy: AM3PR07CA007.eurprd07.prod.outlook.com (10.242.16.47) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Forefront-PRVS: 01917B1794 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(13464003)(24454002)(199002)(189002)(80976001)(83322001)(19580405001)(50226001)(31966008)(15975445006)(74502001)(74662001)(19580395003)(99396002)(85852003)(89996001)(83072002)(46102001)(76482001)(79102001)(42186004)(47776003)(44716002)(62236002)(20776003)(84392001)(66066001)(77982001)(15202345003)(80022001)(4396001)(86362001)(93916002)(87286001)(33646001)(88136002)(81816999)(76176999)(81686999)(23756003)(87976001)(50986999)(77156001)(50466002)(81542001)(14496001)(81342001)(62966002)(92726001)(92566001)(61296002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB049; H:DBXPRD0210HT004.eurprd02.prod.outlook.com; FPR:E63BF119.E3F6E733.B3C5ADBB.93E61F01.2050C; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/A2UEbsNMhiihZSMq32jdk29aU04 Cc: i2rs@ietf.org, edc@google.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 09:20:08 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Wednesday, April 23, 2014 6:08 PM > t.petch wrote: > > > In practice, this means that the YANG model comes in twin sets, one of > > read-write configuration and one of read-only not-configuration (as can > > be seen in the current I-Ds that the netmod WG is producing) > > Correct. This reflects how it usually works on devices; most routers > and similar equipment has a "config mode CLI" and "show commands"; a > linux box has config files and various ways of reading and writing > operational state (/proc, direct apis...) These are different > structures with different syntax and semantics. > > (SNMP tried to combine the two into one, but this turned out to be > problematic.) > > > with no > > formal way in YANG of relating the one to the other. So if you want > > e.g. the routing table, the host software has to know where to look and > > how to combine the pieces to produce a coherent picture (and then you > > cannot edit most of it). I see this lack of combination as a separate issue. When the interest is in configuration, then the focus is on 'config true' and anything else - state - can be ignored; NETCONF provides get-config, edit-config etc which does just that. NETCONF did not have to provide this - it could have used filtering to filter out the 'config true' - but I do not think that that would have been viable. I2RS will have an interest in (some of) 'config true' and some of the state - e.g. routing table entries learnt by BGP but not, at least in some use cases, the read-only statistics. The models have two separate schema trees for 'config true' and state, as http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt Figure 1 and Figure 2 show. What YANG does not have is a way of correlating the two trees - rather, each data model has to craft its own, such as look for value 'mm' in both object X in one list and object Y in another list and assume that they refer to matching entries of the lists. Splitting state into two, operational and the rest, with an i2rs:edit-data for the former, does nothing to help with this - it could make things more complex. We now have a three way split - do we now have three separate trees (if not, why not)? How do we get the i2rs:edit-data? Do we use filters to separate out the i2rs:edit-data, like a NETCONF get were get-config not to exist? Or do we need an i2rs:get-edit-data, except that that still leaves the issue of correlation, so do we need some help from YANG for that? Do we need a i2rs:get-i2rs that spans 'config true' and i2rs:edit-data? Or do we make everything of interest to I2RS i2rs:edit-data and scrap 'config true' as far as I2RS is concerned? Most things are possible with YANG and NETCONF, but it will take time to work out the details; perhaps we will end up changing some of the tenets of RFC6020. Knowing how long operational state has been a topic on the netmod WG list, will we still be working out the details of this in a year's time? Tom Petch p.s. if only draft-ietf-i2rs-rib-info-model were updated to use YANG, with or without i2rs:edit-data, so as to make this concrete? > > > > So if I2RS never wants to write anything to a router, YANG is fine; if > > I2RS is only producing a Information Model (and ignoring whether or not > > data is read-only or read-write), and not moving on to an > > implementation, then YANG is fine. > > > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > > extension to YANG, a new sub-statement for all data objects, semantics > > not too clear but designed to separate out the not-configuration, learnt > > via a protocol, 'editable-state' (and in doing so, making it > > read-write - but still 'config false'). > > > > Yes, YANG allows for such extensions but it seems to me that I2RS would > > then be getting YANG++ (and NETCONF++), once the necessary work has been > > done. > > You can call it YANG++ and NETCONF++, but the fact is that these > things can be done today, without having to revise the YANG or NETCONF > specs, by using the current extensibility mechanisms. > > > /martin > From nobody Thu Apr 24 02:24:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C375E1A07EF for ; Thu, 24 Apr 2014 02:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJpNOnqd65Zd for ; Thu, 24 Apr 2014 02:24:50 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) by ietfa.amsl.com (Postfix) with ESMTP id BE9651A07DC for ; Thu, 24 Apr 2014 02:24:49 -0700 (PDT) Received: from [86.189.1.58] (helo=[10.210.2.226]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WdFtY-0003ku-JS; Thu, 24 Apr 2014 10:24:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rob Shakir In-Reply-To: <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> Date: Thu, 24 Apr 2014 10:24:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <558E2DF2-8C8B-454D-820C-40526A65FE16@rob.sh> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_dyIzZygNWjeqpUVsdpIlKAE2NY Cc: "" , Martin Bjorklund , "" , "" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 09:24:54 -0000 Hi Dean, On 23 Apr 2014, at 19:20, Dean Bogdanovic wrote: > Does the WG see a need for i2rs to provide mechanism for persistent = changes? Whilst it would be nice from an i2rs view to say =93no, we can clearly = make these changes via NETCONF=94, from my perspective, it is very = important that we ensure that we do not end up with unnecessary = fragmentation between different approaches to changing the state of an = element of the routing system. As soon as we say we interact with the = i2rs agent for a particular set of ephemeral state, and then with via a = separate path using NETCONF other persistent state then we drive = complexity into the systems layer above the element - which is, IMVHO, = best avoided. We end up having to have such fragmentation today where we = have MIBs that give us a subset of information/writable configuration, = and another subset available via CLI - and it causes pain. =46rom my reading of the architecture -02 draft, then within the = overview of the architecture (=A71.2) then currently we state (under the = definition of =93Static System State=94) =93How the I2RS agent modifies = of obtains this information is out of scope=94 =97 which seems to = support the view that persistent changes are something we consider = required for I2RS.=20 Cheers, r. >=20 > Following 3, I view very connected, simplified defaults handling, = atomicity of transaction and abstracted simplified config model. With = simplified configuration models, we can create=20 > With RESTCONF we want to ensure that a single transaction is making a = meaningful request that can be fulfilled. This means that request can be = either fulfilled or the transaction will fail. The simplified defaults = handling makes the process easier. In case of writing, if not all the = parameters are provided and there are no default arguments for the = missing parameter, transaction will fail. >=20 > For the performance reasons, support for PATCH is very good, as it = allows multiple updates in single transaction. It is not the same to = send 1000 transactions to update 1000 routes or 1000 routes are updated = in single transaction. With this capability clients can execute much = faster changes to the system. >=20 > Lacking support for network locking model is an issue if there is a = service activated across multiple devices via i2rs and in case of an = error on one device, client has to be able to clean up on the other = devices. Is this a viable use case that would prevent use of RESTCONF = for i2rs? >=20 > Dean >=20 >=20 > On Apr 23, 2014, at 1:08 PM, Martin Bjorklund wrote: >=20 >> t.petch wrote: >>> YANG (with NETCONF) is designed for writing configuration and = reading >>> everything else, and does an excellent job at it. Trouble is, for = me, >>> that configuration doesn't mean what I think of it as; it means, in = the >>> YANG context, what you might put in through the CLI and it excludes >>> everything else, such as data learnt via a protocol. >>=20 >> This is true, but more for NETCONF than for YANG. I think it has = been >> clear from the start that I2RS probably needs some (hopefully minor) >> extensions to NETCONF and/or YANG, should we choose to use these >> technologies. >>=20 >> Also, I think it has been pretty clear that what is missing is a way >> to identify writable data that is not configuration (in the >> NETCONF/YANG sense). >>=20 >>> In practice, this means that the YANG model comes in twin sets, one = of >>> read-write configuration and one of read-only not-configuration (as = can >>> be seen in the current I-Ds that the netmod WG is producing) >>=20 >> Correct. This reflects how it usually works on devices; most routers >> and similar equipment has a "config mode CLI" and "show commands"; a >> linux box has config files and various ways of reading and writing >> operational state (/proc, direct apis...) These are different >> structures with different syntax and semantics. >>=20 >> (SNMP tried to combine the two into one, but this turned out to be >> problematic.) >>=20 >>> with no >>> formal way in YANG of relating the one to the other. So if you want >>> e.g. the routing table, the host software has to know where to look = and >>> how to combine the pieces to produce a coherent picture (and then = you >>> cannot edit most of it). >>>=20 >>> So if I2RS never wants to write anything to a router, YANG is fine; = if >>> I2RS is only producing a Information Model (and ignoring whether or = not >>> data is read-only or read-write), and not moving on to an >>> implementation, then YANG is fine. >>>=20 >>> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >>> extension to YANG, a new sub-statement for all data objects, = semantics >>> not too clear but designed to separate out the not-configuration, = learnt >>> via a protocol, 'editable-state' (and in doing so, making it >>> read-write - but still 'config false'). >>>=20 >>> Yes, YANG allows for such extensions but it seems to me that I2RS = would >>> then be getting YANG++ (and NETCONF++), once the necessary work has = been >>> done. >>=20 >> You can call it YANG++ and NETCONF++, but the fact is that these >> things can be done today, without having to revise the YANG or = NETCONF >> specs, by using the current extensibility mechanisms. >>=20 >>=20 >> /martin >>=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 From nobody Thu Apr 24 02:48:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E131A014B for ; Thu, 24 Apr 2014 02:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKJ5L4i-f6Qg for ; Thu, 24 Apr 2014 02:48:50 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 584771A013C for ; Thu, 24 Apr 2014 02:48:50 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so2632729vcb.16 for ; Thu, 24 Apr 2014 02:48:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=aOoyX7j9rgmLdLRYVTAnX7rriv3y81rJPDDbbFHqkgc=; b=iQdx24askdrFz/QJzAOOXv1gSHCVFRiZyExzKREWCzE+DFAr5BFM7JTGYBDpF0wy7S OHZ7bNOTbQDA6nvVZVoYe2r4g6rO+VlXKetWYweHAEB+ZzwhO3PIFOyCxfBZm6SlVufI eAvQcJ4MpTy2t5Oo90zZOvSXEG1Q6fdLgoACroQO7JbQoKz+gf+kud12i/I/oO2OXU2/ C6kD3NCwVK5ywN2WgtwnQX5uL1GXX7kXAB78ehbmUnii2vngiQss6YsnIasL8Nx4X7AB aP7Sb7l1Qfg9PyZAoJN+7Q3Qml5JRT0Zrh8rUGBLxtZ42h7SBLBv5XUelOm3v2e0q91L 82cQ== X-Gm-Message-State: ALoCoQm/WZZAXIDDJH+Guc0ZMhSKbBszby55Rq9Sg1kluo4a3WI+Dbm7AMjORQMqDUHKguRzbD+/ X-Received: by 10.220.105.4 with SMTP id r4mr518934vco.27.1398332923154; Thu, 24 Apr 2014 02:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 02:48:23 -0700 (PDT) In-Reply-To: References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 05:48:23 -0400 Message-ID: To: ramki Krishnan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vEXw8kIOuHiAtpNu5n6x45cllzU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 09:48:52 -0000 I dont know of any. But it looks like an interesting academic paper one could write. cheers, jamal On Tue, Apr 22, 2014 at 10:30 AM, ramki Krishnan wrote: > My point is that it is good to have an empirical performance comparison (= which would mean everything is apple-to-apple including setup, use case etc= .) between Netconf and FORCES given that both the protocols have been in ex= istence for a while. > > I agree that there may be some flaws in this particular comparison betwee= n SNMP and Netconf. I couldn't find anything else which is easily publicly = available; if you have any better publicly available reference, please sugg= est. > > Thanks, > Ramki > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Tuesday, April 22, 2014 7:15 AM > To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman;= Jamal Hadi Salim; Russ White; i2rs@ietf.org; Jan Medved (jmedved); Dean Bo= gdanovic; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model > > I see a different flaw just from the first few pages and looking at the c= onclusion. > Sorry - didnt have time to look at the whole thing. > The paper picks a model entity of about 90% strings (theres one "int" iir= c). > I am not sure what that was supposed to emulate. From that perspective th= e question answered to me seems to be "how bad does SNMP do when you have m= ostly strings?". It seemed to do fairly well at the end. I liked the fact t= hey tried to batch things with SNMP. > If i was emulating what I2RS is doing by building on say the RIB model, i= t will not be 90% ascii on the wire for SNMP. > > Agree with Juergen on apple-apple comparison needed. > > cheers, > jamal > > > On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder wrote: >> On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: >> >>> It would be good to have an empirical performance analysis of Netconf >>> vs FORCES; this would substantiate performance advantages, if any, of >>> either protocol. The following reference provides a reasonable >>> empirical performance analysis of Netconf vs SNMP - >>> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. >> >> I believe this comparison is flawed. ncclient uses a pure Python >> implementation of SSH while the authors used a Python wrapper around >> NET-SNMP (a C implementation) to measure SNMP performance. And the >> authors state that they used SNMPv2c (no security) and SSH as the >> NETCONF transport. (It is also unclear whether all NETCONF >> transactions were executed over a single session or multiple >> sessions.) >> >> The design of such experiments is not as easy as it may look at first >> glance and it is in particular important to use comparable security >> algorithms (ideally the same crypto library). >> >> /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 nobody Thu Apr 24 02:49:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F981A07FC for ; Thu, 24 Apr 2014 02:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOUOUvob9iAd for ; Thu, 24 Apr 2014 02:49:31 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 035281A014B for ; Thu, 24 Apr 2014 02:49:30 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so2574232veb.34 for ; Thu, 24 Apr 2014 02:49:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8GVGFOGJAIJDw2OyhlroxFJjdGF25GIOdiOsy5kl4BE=; b=D7xAEaFzOEJgU/8XD8HoqsZuT9unqwyUO/FfjFlKY6MvZVRge4Z2e0iVhpAyyXUGtU BJlQXck/S/fIZVt9JcbSQ2FnY8rbrJ2Lr76d/oRhMSpkNudheaCjI+tZIB9cuhL3BLtU VdeKqk/0sYvSB6BMxV0Zpvyj8bp9G6LPLQAjhUW/FKAMhfRyTGXOgKvvrEMEKM6cZ3Vy +dL+tdbIkZmndVsqLK9s0pPH5jlPsCqmbAykhtjPYETeKhTrsdTBRpFi+YYRetuQlc+l msp+WCIwDud3xbcwFo2Eh+Evxl+jAdhtIRU7SvG7RISWQsk2pTk8D1ozRda1sakCcF5l RzsA== X-Gm-Message-State: ALoCoQmke0IrC3w6Zmcgkr1vao1jASlg3DBK2Bt+sCXebfxV3O5CPOXi3Gmmg3k6GrqL7inwogKA X-Received: by 10.52.104.7 with SMTP id ga7mr443400vdb.29.1398332964847; Thu, 24 Apr 2014 02:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 02:49:04 -0700 (PDT) In-Reply-To: References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 05:49:04 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/8G-OKErhdzln22UL5Cx7ZCGFrPY Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Juergen Schoenwaelder , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 09:49:33 -0000 Our code (which is used in production for a few years) unfortunately is not open source (we dont have the resources as a small company). However, i do plan to implement i2rs with quagga (zebra to be specific) and hope to show up with some results - that is if i dont get overruled to using ForCES before the next meeting. cheers, jamal On Tue, Apr 22, 2014 at 10:44 AM, Andy Bierman wrote: > > > > On Tue, Apr 22, 2014 at 7:30 AM, ramki Krishnan wrote: >> >> My point is that it is good to have an empirical performance comparison >> (which would mean everything is apple-to-apple including setup, use case >> etc.) between Netconf and FORCES given that both the protocols have been in >> existence for a while. >> > > It would be good to have a pointer to implementations, open-source tools, > tutorials, etc. > > The NETCONF WG maintains a wiki to help provide this information: > http://trac.tools.ietf.org/wg/netconf/trac/wiki > > Benoit asked at the London meeting, "where is this list for ForCES?" > We still have not heard an answer. > > >> I agree that there may be some flaws in this particular comparison between >> SNMP and Netconf. I couldn't find anything else which is easily publicly >> available; if you have any better publicly available reference, please >> suggest. >> >> Thanks, >> Ramki >> > > > Andy > >> >> -----Original Message----- >> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] >> Sent: Tuesday, April 22, 2014 7:15 AM >> To: Juergen Schoenwaelder; ramki Krishnan; Joel M. Halpern; Andy Bierman; >> Jamal Hadi Salim; Russ White; i2rs@ietf.org; Jan Medved (jmedved); Dean >> Bogdanovic; Edward Crabbe >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> I see a different flaw just from the first few pages and looking at the >> conclusion. >> Sorry - didnt have time to look at the whole thing. >> The paper picks a model entity of about 90% strings (theres one "int" >> iirc). >> I am not sure what that was supposed to emulate. From that perspective the >> question answered to me seems to be "how bad does SNMP do when you have >> mostly strings?". It seemed to do fairly well at the end. I liked the fact >> they tried to batch things with SNMP. >> If i was emulating what I2RS is doing by building on say the RIB model, it >> will not be 90% ascii on the wire for SNMP. >> >> Agree with Juergen on apple-apple comparison needed. >> >> cheers, >> jamal >> >> >> On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder >> wrote: >> > On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: >> > >> >> It would be good to have an empirical performance analysis of Netconf >> >> vs FORCES; this would substantiate performance advantages, if any, of >> >> either protocol. The following reference provides a reasonable >> >> empirical performance analysis of Netconf vs SNMP - >> >> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. >> > >> > I believe this comparison is flawed. ncclient uses a pure Python >> > implementation of SSH while the authors used a Python wrapper around >> > NET-SNMP (a C implementation) to measure SNMP performance. And the >> > authors state that they used SNMPv2c (no security) and SSH as the >> > NETCONF transport. (It is also unclear whether all NETCONF >> > transactions were executed over a single session or multiple >> > sessions.) >> > >> > The design of such experiments is not as easy as it may look at first >> > glance and it is in particular important to use comparable security >> > algorithms (ideally the same crypto library). >> > >> > /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 nobody Thu Apr 24 02:59:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D861A04DC for ; Thu, 24 Apr 2014 02:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbzj5m78ST1x for ; Thu, 24 Apr 2014 02:59:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2F1A0644 for ; Thu, 24 Apr 2014 02:59:14 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0DB2A14087A; Thu, 24 Apr 2014 11:59:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1398333547; bh=nHJf/o7ycmlW3qFfYHFarxLvLglte2mT4IMD/+2b7n0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BOkEaGhnK1uZCYsCt62V2MVA2oWPdB87WusikK4kLhPaqDf1MuFCEh1D57W9Cy/PO tNwUYIvUrEn7lNq2y7paKTf2DA2L6FfsQvcvYJEPKrmQkptTKJCW4oFtU6BxGUXEq0 OUmC0ySC6CQRh6WdrY2a6hWZjW1NK6GXdmKePvYI= Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> Date: Thu, 24 Apr 2014 11:59:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FrQmduG-Hda4JbMcmMEAjz51ArM Cc: i2rs@ietf.org, =?iso-8859-1?Q?Martin_Bj=F6rklund?= , edc@google.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 09:59:17 -0000 On 24 Apr 2014, at 11:17, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Wednesday, April 23, 2014 6:08 PM >> t.petch wrote: >>=20 > >>> In practice, this means that the YANG model comes in twin sets, one > of >>> read-write configuration and one of read-only not-configuration (as > can >>> be seen in the current I-Ds that the netmod WG is producing) >>=20 >> Correct. This reflects how it usually works on devices; most routers >> and similar equipment has a "config mode CLI" and "show commands"; a >> linux box has config files and various ways of reading and writing >> operational state (/proc, direct apis...) These are different >> structures with different syntax and semantics. >>=20 >> (SNMP tried to combine the two into one, but this turned out to be >> problematic.) >>=20 >>> with no >>> formal way in YANG of relating the one to the other. So if you want >>> e.g. the routing table, the host software has to know where to look > and >>> how to combine the pieces to produce a coherent picture (and then > you >>> cannot edit most of it). >=20 > I see this lack of combination as a separate issue. >=20 > When the interest is in configuration, then the focus is on 'config > true' and anything else - state - can be ignored; NETCONF provides > get-config, edit-config etc which does just that. NETCONF did not = have > to provide this - it could have used filtering to filter out the = 'config > true' - but I do not think that that would have been viable. >=20 > I2RS will have an interest in (some of) 'config true' and some of the > state - e.g. routing table entries learnt by BGP but not, at least in > some use cases, the read-only statistics. The models have two = separate > schema trees for 'config true' and state, as >=20 > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt >=20 > Figure 1 and Figure 2 show. What YANG does not have is a way of > correlating the two trees - rather, each data model has to craft its > own, such as look for value 'mm' in both object X in one list and = object > Y in another list and assume that they refer to matching entries of = the > lists. We tried to address this duality in this draft (now expired): http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 The result was, at least in my view, less than satisfactory. There = certainly is a correlation between configuration and state data but it = can be tight or loose depending on at least the following two factors: - The amount of processing done by the configuration system. For = example, it can turn high-level configuration into corresponding = low-level settings in the device. - Often there are other factors beside configuration (e.g. network = protocols) that influence the final result. So we eventually came to the conclusion that configuration and state = data are in general independent, and separate trees were introduced - = not only in the routing-cfg draft. Lada >=20 > Splitting state into two, operational and the rest, with an > i2rs:edit-data for the former, does nothing to help with this - it = could > make things more complex. >=20 > We now have a three way split - do we now have three separate trees = (if > not, why not)? How do we get the i2rs:edit-data? Do we use filters = to > separate out the i2rs:edit-data, like a NETCONF get were get-config = not > to exist? Or do we need an i2rs:get-edit-data, except that that still > leaves the issue of correlation, so do we need some help from YANG for > that? Do we need a i2rs:get-i2rs that spans 'config true' and > i2rs:edit-data? Or do we make everything of interest to I2RS > i2rs:edit-data and scrap 'config true' as far as I2RS is concerned? >=20 > Most things are possible with YANG and NETCONF, but it will take time = to > work out the details; perhaps we will end up changing some of the = tenets > of RFC6020. Knowing how long operational state has been a topic on = the > netmod WG list, will we still be working out the details of this in a > year's time? >=20 > Tom Petch >=20 > p.s. if only draft-ietf-i2rs-rib-info-model were updated to use YANG, > with or without i2rs:edit-data, so as to make this concrete? >=20 >>>=20 >>> So if I2RS never wants to write anything to a router, YANG is fine; > if >>> I2RS is only producing a Information Model (and ignoring whether or > not >>> data is read-only or read-write), and not moving on to an >>> implementation, then YANG is fine. >>>=20 >>> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >>> extension to YANG, a new sub-statement for all data objects, > semantics >>> not too clear but designed to separate out the not-configuration, > learnt >>> via a protocol, 'editable-state' (and in doing so, making it >>> read-write - but still 'config false'). >>>=20 >>> Yes, YANG allows for such extensions but it seems to me that I2RS > would >>> then be getting YANG++ (and NETCONF++), once the necessary work has > been >>> done. >>=20 >> You can call it YANG++ and NETCONF++, but the fact is that these >> things can be done today, without having to revise the YANG or = NETCONF >> specs, by using the current extensibility mechanisms. >>=20 >>=20 >> /martin >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 24 03:02:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FA81A081A for ; Thu, 24 Apr 2014 03:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtgGtkSgwgn5 for ; Thu, 24 Apr 2014 03:02:31 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id C34231A0804 for ; Thu, 24 Apr 2014 03:02:31 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so2637080vcb.6 for ; Thu, 24 Apr 2014 03:02:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z4E4qM0C/86NjsubR7kS0Uvnfwu6vYc5xSwOXC0BWYM=; b=UOcAkP5ohLr/RWF1uob4zhLmlYECkGGBiLbD9N046T65zQmPz6xkwjxriRczGjpDRs MrkR1YsL5/U12RlFv5kYRnJFD7UFlPJdrskvRxDw6Gauk6AO8rRJ6ACB747CqKm2O0ml RHF1OGavNnuH5CSVaQDjvSHDyKiT/4FY/hUpGdZb6/5rxrDm7QbDTa57lrkoUcvKtSQt wYmBE69ZMkrcYgBrdSSRVG8cZbjpb7tLihebiX+hzG0QUTepyymsBdPv8XbZSCeoKEdG LfBDfbiqi5gIyih7KpyTuqpNB0aEvC5fwxAPNliMCMd+F2t4d9oeRV2nxPWo2l0S0M22 ODAQ== X-Gm-Message-State: ALoCoQkkJaVszW4hxrAoVTJzfBScaurD8QDEhHMRsSWcnx9np1DWvp7O2bmhXbe7ZrG0dFnPsh3c X-Received: by 10.221.29.137 with SMTP id ry9mr633984vcb.6.1398333745568; Thu, 24 Apr 2014 03:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:02:05 -0700 (PDT) In-Reply-To: <20140422150829.GN8955@pfrc> References: <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> <20140422150829.GN8955@pfrc> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:02:05 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AYv9fBih0Chc8YcsXW2dsnQqO4o Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "Jan Medved \(jmedved\)" , Dean Bogdanovic , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:02:35 -0000 Hi Jeff, Apologies, on travel mode - so some latency involved. On Tue, Apr 22, 2014 at 11:08 AM, Jeffrey Haas wrote: > I can definitely see such a case, although the more likely paradigm is > injecting a large number of RIB entries that may have some BGP properties, > such as communities or inputs to various BGP-like policy mechanisms. > It will be useful to come up with some hand-wavy numbers; at minimal for implementations to check if they are within expected ranges. > I have created stubs in the wiki for such comparisons. Would you mind > starting the work for FORCES? > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki > > You will require a datatracker login. If you run into issues with editing, > please unicast me. This is the first time I'll have done more than editing > it myself. > > If someone is willing to start stubbing in similar items for Netconf/Yang, > that would be helpful. > I will update the ForCES bits at the next opportunity i get. Useful again to have a matrix of I2RS requirements vs what a model/protocol offers. While the presentations at the meeting attempted to follow that, it was not "standard" requirements. >> On compute: >> I would expect json to perform better than XML when sending to a browser. > > While I think that detail is true, I suspect a browser is not the first > order consumer of the information. > > My general experience with such things is that JSON does fine when you want > to pass around JavaScript native data, but that you lose some of the > semantic layering in turning things into JavaScript. My personal preference > would be that if we provide JSON layers that they effectively be at the far > end of the pipe (UI facing) rather than the native object in-protocol. > > Obviously such details are discussion points and the above is simply my > opinion and experience. > it does make sense; note what i said earlier are arguements the pro-json camp uses against xml. Mostly they deal with a browser as an endpoint. Having said that there will always be an impedence mismatch of some form between a representation and the native format; i just claim it is less so with binary than it is with any form of ascii. > > While certainly not a constraint on the working group, I tend to remember > that we want I2RS to be as pervasive as possible. This means that anything > we can make work well on older platforms means it's more likely to be > supported across a wide range of devices. This has impact, for example, on > crypto load. > Nod. > [Several other good points that should be in the wiki entry elided.] > > I think I made this observation at the last IETF session: Even for simple > compression, XML tends to compress *very* nicely with small dictionaries. > Since HTTP compression is well deployed, I suspect this isn't quite as big a > deal as it could be. Of course, that presumes we're layering on top of > something HTTP-like. > Yes, http compression is pretty ubiquitous - so something like restconf could take advantage of that. > It's pretty common to either tap before or after the transport APIs for > debugging. I think the distintion is that in something text-like you can > tap and do thinks potentially simpler than if you have to look at binary > PDUs. That requires tapping one level back before the binary marshalling > layer. Obviously that is doable as well, but simply moves the point of > complexity one layer up/down. > So I am sensing development debugging then? The arguement i have heard is that operators debug by capturing on the wire packets and that ascii was easier to follow. > To offer a somewhat BGP network operations example, those who use the MRT > file format (RFC 6396) typically have programs that convert from/to that > format in human-readable form. Some users may use binary API to interact > with the files but the majority of operators I've interacted with that use > it tend to simply transform it to ASCII and Do Something Clever using their > favorite scripting language. > Ok, understood. > I've left a stub in the wiki for helping to derive or map requirements. I will be picking requirements as i find them (architecture doc etc) and filling up the ForCES responses. cheers, jamal From nobody Thu Apr 24 03:12:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686B1A0158 for ; Thu, 24 Apr 2014 03:12: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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74q_NHLbWZOB for ; Thu, 24 Apr 2014 03:12:48 -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 7E49A1A0176 for ; Thu, 24 Apr 2014 03:12:42 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so2695383veb.30 for ; Thu, 24 Apr 2014 03:12:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BtTU8zPTWpEobDLtIJBT9UnjVSfuc44aQFOeC1Qsor0=; b=PwAndsRkM9oLvjfD6+BfyccrpQfkNGWqGRQFZ3fkRD+SmOI5IqfQBZZs1zMtDiq85d PxxFsdtdQlp1MgstSqDBJQ0rpqCJ86BbW2/n3iyb3oAAs6HM+xA25DblpSroASxcNFVz GpdlcCi9e825BY6MSubEX3MB7XK229y9g2sF6l7jUlgOCM/ZIfk4je8UU6fBNiENtTkI Pfgwoj6fDs3aNTb/r2LoMTO6y9rbcUcXHEhxRqn7GYNTBoptacyFnsNt/heG8/oJjhYR XLAuRGzuGFmh17s4jHca64lWtYkDjbwCQxRDfdBHYdbx2aNGfAm3wm9gZ7tQ0jOQL9dr IDNQ== X-Gm-Message-State: ALoCoQkmcPsMLZnqj9BxdDLzTNEa9uuKGi1Mv/XxSCITvfSbXl5c2tvXA5/hvPZqF1w/ejnqY41C X-Received: by 10.58.31.136 with SMTP id a8mr679775vei.20.1398334356376; Thu, 24 Apr 2014 03:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:12:15 -0700 (PDT) In-Reply-To: <5356964F.9060608@hq.sk> References: <5351C11F.1070109@joelhalpern.com> <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <20140421190218.GB2046@pfrc> <5356964F.9060608@hq.sk> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:12:15 -0400 Message-ID: To: Robert Varga Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qOpUkECEwZedZ7zEZ0Hvtkdhhpg Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , "Jan Medved \(jmedved\)" , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:12:51 -0000 Thanks for posting on that draft. Google was kind to find it for me. For other folks, Robert is talking about his draft here: http://tools.ietf.org/html/draft-varga-netconf-exi-capability-01 I thought ive heard claims that "CPUs are fast enough, dont worry" and this draft's problem statement is (to make netconf): " ... more efficient from both CPU and bandwidth utilization perspective... What do you have to say for yourself Jan/Thomas ? ;-> cheers, jamal On Tue, Apr 22, 2014 at 12:18 PM, Robert Varga wrote: > On 04/21/2014 09:02 PM, Jeffrey Haas wrote: >> >> The binary encoding of FORCES may help with speed. >> It was asserted elsewhere (copied below) that this may only be 3-5% of a >> speed improvement. (I had thought I recalled a discussion in netmod(?) at >> one point of a BER format for YANG, but my google-fu is failing me.) >> A somewhat negative property of XML is that a document is only considered >> valid once you have the whole document. Thus, document size may matter. > > > There is a draft for using EXI encoding in NETCONF. There is a (partial) > implementation in OpenDaylight, so benchmarking should be possible. Sorry, > don't have the cycles to actually design/run a reasonable test suite. > > Bye, > Robert From nobody Thu Apr 24 03:25:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F701A0176 for ; Thu, 24 Apr 2014 03:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmmsmuAA7XII for ; Thu, 24 Apr 2014 03:24:58 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 04DAA1A0158 for ; Thu, 24 Apr 2014 03:24:57 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id id10so2605814vcb.40 for ; Thu, 24 Apr 2014 03:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bcf0wQTzEMmkBVny0jrvrPDReUL/Gd4KulrodkZo668=; b=Ezq/EbTx9j8OEi8/xfuzvn8I2IjFDES7DswXikguIuLoRok3/ufX0dODitDvT5hPBt cCPEwleuG2E03zyKHAUyovcz8PLghMoGCCrLA3e100nLCLmrBdrOC6LlbWtGzODVO9W3 qBn+wl7Fq2VENtXxbTvXXwHFlEgqgsD7VHC16Hc/he1SWGpAS1/5vP8jWhZBWQc2GdNl sldT+YhvzPuNX6Ap4Mv9ANRLiGUlzLbB5p4SZHnI/Q+WeJn+rej/PGk2R+OtemilkuaK I4nR6ndE2Vp8ozXfUv9mTShMmV5NBPvUk3/7OyhtdjzqksbYQNdDzPGBXYS+OuFi7ZwQ i4tw== X-Gm-Message-State: ALoCoQmK9F9nJbFBgkIfuiLH3RyE4EmbERqBfpGDHxvcc+QOc1lzTnhcW7glaCxEgUs8ZWCZ5sQb X-Received: by 10.58.1.97 with SMTP id 1mr667910vel.23.1398335091890; Thu, 24 Apr 2014 03:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:24:31 -0700 (PDT) In-Reply-To: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:24:31 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/nUPTImgGqfz7X4EFCSI79TJlp4s Cc: "" , Martin Bjorklund , "" , Andy Bierman , "" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:25:02 -0000 On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic wrote: > > On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: > > I thought I2RS is starting out focusing on 1 client and 1 agent. Dont think so. > Network locking across devices is out of scope. > > > > I have same opinion as you on this one, just wanted to spell it out one more > time explicitly, as I heard some discussions where network locking was > coming up. > Either I am misunderstanding both of you or both of you misunderstood the requirement. The idea is to allow a single writer per object as a starting point. OTOH, if you really mean what you say then I violently disagree. cheers, jamal PS:- Changing the topic so this is not lost in the noise because i think that the many clients-single agent brings needs for other protocol requirements. From nobody Thu Apr 24 03:28:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2A41A0175 for ; Thu, 24 Apr 2014 03:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxPRAmCHbhMA for ; Thu, 24 Apr 2014 03:28:25 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB41A0171 for ; Thu, 24 Apr 2014 03:28:25 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so2609422veb.41 for ; Thu, 24 Apr 2014 03:28:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=N0TbnNC1+/F1KVgFuYSJ6pqwjVR6Qruwn9zNzeKcXZc=; b=bv+yS4zEBV2i76QFfgNStMiL57k+TAIRfg0l+kYwdDVZmgLHKy+OnxY8XN9QIRn5By I4ZefXsNLzxpvUCGJN1hUugmj3L3ceeEiOfhUrQVBR6ZInZznAxok/U6XW7ZNS2TC8Z5 G2nxeTgcUAZw/BXJWFtYXYWQLwP/h5nzF0xllSvL46xh4N1JpcRUyuPJfHWRoPXXeSBU 8JYPNglGR3VcnAEMRBe661jXfjsw0iYhJAXv0o06JzIH0L3ru+8gdDlNs9bxXnUkRXl0 8AS/bGZV2FlpHK6pbm41e7G3BQcmqnSOazZGb9+rz/wuJ5TW2F4vITUxQCZaR7wVe++4 2s9w== X-Gm-Message-State: ALoCoQlncpwm6StxPRbD1hKBXnWZOmkHAs3kIVUau95PJLnteNsVSQPUEqc3+R3/BCeXvDWSVINI X-Received: by 10.220.92.193 with SMTP id s1mr64021vcm.34.1398335299598; Thu, 24 Apr 2014 03:28:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:27:58 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:27:58 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LGYx3epOPs1-BKebhCz0riYoIrQ Subject: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:28:30 -0000 Forgot to change the topic. I would like to follow up and build on this - but i wanted to make sure there was some sanity first. cheers, jamal ---------- Forwarded message ---------- From: Jamal Hadi Salim Date: Thu, Apr 24, 2014 at 6:24 AM Subject: Re: [i2rs] consensus on I2RS protocol and model To: Dean Bogdanovic Cc: Andy Bierman , "" , Martin Bjorklund , "" , "" On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic wrote: > > On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: > > I thought I2RS is starting out focusing on 1 client and 1 agent. Dont think so. > Network locking across devices is out of scope. > > > > I have same opinion as you on this one, just wanted to spell it out one more > time explicitly, as I heard some discussions where network locking was > coming up. > Either I am misunderstanding both of you or both of you misunderstood the requirement. The idea is to allow a single writer per object as a starting point. OTOH, if you really mean what you say then I violently disagree. cheers, jamal PS:- Changing the topic so this is not lost in the noise because i think that the many clients-single agent brings needs for other protocol requirements. From nobody Thu Apr 24 03:32:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982F61A017C for ; Thu, 24 Apr 2014 03:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfWgdKr5lIbl for ; Thu, 24 Apr 2014 03:32:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 60DB91A0171 for ; Thu, 24 Apr 2014 03:32:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D202110DA; Thu, 24 Apr 2014 12:32:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aeenDo5mUypk; Thu, 24 Apr 2014 12:32:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Apr 2014 12:32:02 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 469002002C; Thu, 24 Apr 2014 12:32:02 +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 Up8a9OBd-CzY; Thu, 24 Apr 2014 12:31:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2D6520013; Thu, 24 Apr 2014 12:31:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 93CF02CA94F6; Thu, 24 Apr 2014 12:31:43 +0200 (CEST) Date: Thu, 24 Apr 2014 12:31:43 +0200 From: Juergen Schoenwaelder To: Jamal Hadi Salim Message-ID: <20140424103143.GB3420@elstar.local> Mail-Followup-To: Jamal Hadi Salim , Robert Varga , "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , "Jan Medved (jmedved)" , Jeffrey Haas , "Joel M. Halpern" References: <5F3A5839-0428-4F8F-8069-8022121C437C@juniper.net> <20140421190218.GB2046@pfrc> <5356964F.9060608@hq.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LIaP8ppvKWtabR94u3JfRJZvsQA Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Robert Varga , "Jan Medved \(jmedved\)" , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:32:11 -0000 On Thu, Apr 24, 2014 at 06:12:15AM -0400, Jamal Hadi Salim wrote: > Thanks for posting on that draft. Google was kind to find it for me. > For other folks, Robert is talking about his draft here: > http://tools.ietf.org/html/draft-varga-netconf-exi-capability-01 > > I thought ive heard claims that "CPUs are fast enough, dont worry" > and this draft's problem statement is (to make netconf): > " ... more efficient from both CPU and bandwidth utilization perspective... > > What do you have to say for yourself Jan/Thomas ? ;-> Frankly, I think it is the job of those who propose alternate encodings to provide evidence that the proposed encoding leads to noticable improvements. And I like to insist on security being included in such a study since NETCONF by definition runs over secure transports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Apr 24 03:41:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777A31A01C1 for ; Thu, 24 Apr 2014 03:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoRXmFRbPspX for ; Thu, 24 Apr 2014 03:41:45 -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 B7CC01A01BB for ; Thu, 24 Apr 2014 03:41:44 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so2728822veb.30 for ; Thu, 24 Apr 2014 03:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AjXE2pR3TTup1YIFlTViqQNK5FSaxFmFYGlsPzrWzU8=; b=hNmvsfbwSyY5JngA7WcuznXJX9ODbu4++stkrHKL4suPWGY7pQbjWGmPGxS2w02+nS nV/STITQuri+8Mr3BgaFPKC09SwB1mtvmLQGbJtvB71ZUm/j5b351HVLcZJZViGeEEPJ inolQ/RpnqyKDN8JT8T+NnVWWYHTynMJ3FlESp846R+LShHGsGns2zcuwL3iL+sBMZtT 4K1U3CpvvFMSR9+KW9fwntY/pkNYgJ2cI8llntbwioYya8/XZUceamX2xUTCMZzOjotH 7ptYlufcuO05Hmpa6paHXKT+3NVCLs/i2oXsJ3cCkDcfKc028wxMoT9+TMsJvBWzmJub LYHA== X-Gm-Message-State: ALoCoQmnvxKu3u/bym2rULdeuYbnVyqb/ISJTEZRxMvexMU6p/YX3X+DphXI6G4Dl59M14wuiJ9h X-Received: by 10.220.250.203 with SMTP id mp11mr764098vcb.2.1398336098607; Thu, 24 Apr 2014 03:41:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:41:18 -0700 (PDT) In-Reply-To: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:41:18 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ey4mB_5FB25svlxD5-ppgAxk4Wg Cc: "i2rs@ietf.org" , Edward Crabbe , "t.petch" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:41:46 -0000 For comparison completion, ForCES data model does not need ANY changes. We do need to specify some new data types and models for the different objects as will always be the case for any new LFB but we dont need any changes to the model. cheers, jamal On Wed, Apr 23, 2014 at 12:59 PM, Andy Bierman wrote: > > > > On Wed, Apr 23, 2014 at 9:07 AM, t.petch wrote: >> >> YANG (with NETCONF) is designed for writing configuration and reading >> everything else, and does an excellent job at it. Trouble is, for me, >> that configuration doesn't mean what I think of it as; it means, in the >> YANG context, what you might put in through the CLI and it excludes >> everything else, such as data learnt via a protocol. >> >> Take routing. A static route is configuration; anything learnt, via >> BGP, IS-IS, RIP etc, is not configuration (and is read only). >> >> An interface configured automatically on a hot-plugged card is not >> configuration; adding 'ospf passive' is. >> >> And so on, for DHCP, NTP, ..... >> >> In practice, this means that the YANG model comes in twin sets, one of >> read-write configuration and one of read-only not-configuration (as can >> be seen in the current I-Ds that the netmod WG is producing) with no >> formal way in YANG of relating the one to the other. So if you want >> e.g. the routing table, the host software has to know where to look and >> how to combine the pieces to produce a coherent picture (and then you >> cannot edit most of it). >> >> So if I2RS never wants to write anything to a router, YANG is fine; if >> I2RS is only producing a Information Model (and ignoring whether or not >> data is read-only or read-write), and not moving on to an >> implementation, then YANG is fine. >> >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >> extension to YANG, a new sub-statement for all data objects, semantics >> not too clear but designed to separate out the not-configuration, learnt >> via a protocol, 'editable-state' (and in doing so, making it >> read-write - but still 'config false'). >> >> Yes, YANG allows for such extensions but it seems to me that I2RS would >> then be getting YANG++ (and NETCONF++), once the necessary work has been >> done. > > > > So far, 2 extensions have been identified that are needed by I2RS. > > 1) identification of editable operational state. > The config=false property in YANG will cause NETCONF and RESTCONF > to (correctly) treat operational state as read-only. I2RS servers must > implement the extension: The I2RS protocol will use its own access > control > model on this data. NACM is not required. > > e.g. (not real data, just example!) > > extension edit-data { > description > "If this statement is present, and the parent statement represents > a non-configuration data node, then instances of this data node > can be modified by a client."; > } > > container rib { > config false; > i2rs:edit-data; > .... > } > > 2) identification of objects associated with event notifications > > This could also be done with a YANG extension, and there is a proposal > to change YANG 1.1 to support this feature: > > extension event-object { > description > "If this statement is present, and the parent statement is > a notification statement, then the 'path' argument represents > the resource associated with the notification."; > argument path; > } > > notification some-interface-event { > i2rs:event-object /if:interfaces/if:interface; > > leaf name { > type leafref { path /if:interfaces/if:interface/if:name; } > } > leaf some-data { type string; } > .... > } > > Nobody said YANG or ForCES could be used without any modifications > to support I2RS. YANG allows instant modifications that require no > changes to the language specification. > > > >> >> Tom Petch > > > Andy > > >> >> >> >> ----- Original Message ----- >> From: "Edward Crabbe" >> To: >> Sent: Friday, April 11, 2014 6:50 PM >> Subject: [i2rs] consensus on I2RS protocol and model >> >> >> > Dear I2RSers, >> > >> > >> > At the last I2RS WG meeting there was a great deal of conversation >> > regarding selection of both modeling language and underlying transport >> > protocol. Consensus at the time was to make use of Yang and (NetConf >> or >> > RestConf) (unclear). >> > >> > Before coming to a final consensus, we'd like to give people >> adequate >> > time to review source material, marshall arguments and discuss on the >> > mailing list. To this end, we're asking that interested parties do >> just >> > this over the course of the next ~two weeks. Following that period, on >> > 4/28, we'll be initiating a consensus call that will last an >> additional two >> > weeks, with the aim of converging modeling language / protocol by >> Friday, >> > 5/9. >> > >> > The consensus call should also generate proposals for any material >> changes >> > required to the underlying protocols. These proposals in turn will >> form >> > the basis for a later draft including gap analysis and said changes. >> Those >> > strongly in favor of one protocol over another should be prepared to >> > contribute to this analysis. >> > >> > >> > best, >> > >> > -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 > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Apr 24 04:12:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609F1A0188 for ; Thu, 24 Apr 2014 04:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzkjEQVXE1WG for ; Thu, 24 Apr 2014 04:12:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4171A004E for ; Thu, 24 Apr 2014 04:12:51 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6643E394190; Thu, 24 Apr 2014 13:12:44 +0200 (CEST) Date: Thu, 24 Apr 2014 13:12:44 +0200 (CEST) Message-Id: <20140424.131244.180603940339430480.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EQDR8BGV3OxHuaXe5pO4CW2q-hE Cc: i2rs@ietf.org, edc@google.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 11:12:53 -0000 t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Wednesday, April 23, 2014 6:08 PM > > t.petch wrote: > > > > > > In practice, this means that the YANG model comes in twin sets, one > of > > > read-write configuration and one of read-only not-configuration (as > can > > > be seen in the current I-Ds that the netmod WG is producing) > > > > Correct. This reflects how it usually works on devices; most routers > > and similar equipment has a "config mode CLI" and "show commands"; a > > linux box has config files and various ways of reading and writing > > operational state (/proc, direct apis...) These are different > > structures with different syntax and semantics. > > > > (SNMP tried to combine the two into one, but this turned out to be > > problematic.) > > > > > with no > > > formal way in YANG of relating the one to the other. So if you want > > > e.g. the routing table, the host software has to know where to look > and > > > how to combine the pieces to produce a coherent picture (and then > you > > > cannot edit most of it). > > I see this lack of combination as a separate issue. > > When the interest is in configuration, then the focus is on 'config > true' and anything else - state - can be ignored; NETCONF provides > get-config, edit-config etc which does just that. NETCONF did not have > to provide this - it could have used filtering to filter out the 'config > true' - but I do not think that that would have been viable. > > I2RS will have an interest in (some of) 'config true' and some of the > state - e.g. routing table entries learnt by BGP but not, at least in > some use cases, the read-only statistics. The models have two separate > schema trees for 'config true' and state, as > > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt > > Figure 1 and Figure 2 show. What YANG does not have is a way of > correlating the two trees See also Lada's reply. What kind of correlation are you looking for? The point is that these are *different* structures, with different semantics. If an entry exists in the operational state, it doesn't imply there is a corresponding entry in the config, and vice versa. And just b/c a config entry also exists in operational state doesn't mean that it is *exactly* as configured; some other dynamic mechanism might have changed it. It all depends on what you model. > - rather, each data model has to craft its > own, such as look for value 'mm' in both object X in one list and object > Y in another list and assume that they refer to matching entries of the > lists. > > Splitting state into two, operational and the rest, with an > i2rs:edit-data for the former, does nothing to help with this - it could > make things more complex. > > We now have a three way split - do we now have three separate trees (if > not, why not)? I don't think a separate structure for i2rs routes are needed, b/c it is supposed to directly modify the operational state. Also, I don't think this is a YANG-specific issue; any modelling language can model one, two or three separate structures. If we put the configuration part aside, you still have to decide if you need one or two (or N) structures for "i2rs" state and "complete" state. > How do we get the i2rs:edit-data? Do we use filters to > separate out the i2rs:edit-data, like a NETCONF get were get-config not > to exist? Sure, just like might want to get the routes from bgp or some other protocol. /martin From nobody Thu Apr 24 06:23:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C799B1A0232 for ; Thu, 24 Apr 2014 06:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpA9pKsahS-p for ; Thu, 24 Apr 2014 06:23:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 430921A022E for ; Thu, 24 Apr 2014 06:23:36 -0700 (PDT) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 24 Apr 2014 13:23:28 +0000 Message-ID: <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , 'Edward Crabbe' , References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> Date: Thu, 24 Apr 2014 14:15:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: DBXPR07CA012.eurprd07.prod.outlook.com (10.141.8.170) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 01917B1794 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(13464003)(51704005)(377454003)(50466002)(76482001)(80976001)(99396002)(81686999)(14496001)(46102001)(76176999)(86362001)(42186004)(77156001)(85852003)(4396001)(81816999)(80022001)(19580395003)(83072002)(83322001)(19580405001)(50226001)(33646001)(93916002)(87286001)(66066001)(74662001)(62966002)(89996001)(61296002)(92726001)(23756003)(74502001)(77982001)(47776003)(50986999)(88136002)(20776003)(44716002)(87976001)(92566001)(79102001)(31966008)(84392001)(81342001)(81542001)(62236002)(44736004)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DB3PRD0210HT003.eurprd02.prod.outlook.com; FPR:E6FFF2E4.E3FA9737.B3E3BD0B.90A6FD61.204FE; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Y0Rgq6h8Rgpl6RIC1Vz12a5IVvw Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:23:42 -0000 ----- Original Message ----- From: "Susan Hares" To: "'t.petch'" ; "'Edward Crabbe'" ; Sent: Wednesday, April 23, 2014 5:21 PM > Tom: > > 100% agree with your comments. I2RS cares whether it is read-only or > read-write. My work toward the revision found: > > - RBNF RBNF did not even allow you a place to r/w or r-only or permissions > (needed for security, but that's my next draft). > - The yang tree I wrote was r-w for config, but did not express the ro-only > tree. I wanted some feedback to figure out why I had 2 write 2 trees. > (your telling me it is a yang short-coming). Sue That is a feature of YANG. Spend half a day on the netmod WG archives for 1H2013, particularly May and June and for interfaces-cfg, and all will be clear. As Ladislav said on 2May13, "In the current model, the operational state data are not present unless the corresponding entry in the "interface" list is *configured*. So, what I have in mind is a data tree like this: ..." That is, 'config false' nodes under a 'config true' node do not get instantiated in the data model unless and until the 'config true' node is configured. So if you have the one routing table, you will be unable to see the routes learnt via BGP - 'config false' - unless and until you configure the table by creating a static route - 'config true'. It is a tenet of YANG so fundamental, so basic, that I know of nowhere where it is written down:-( Tom Petch > - UML seems to be able to handle read/write variants, and I'm looking to see > if graphical tools will help the developer. > > Not shown in the reduction: > ... And I started working on BGP, ISIS, RIP.. only to find some of these > issues you mention. DCHP and NTP. Any suggestions or help would be > gratefully accepted. > > I will continue to try to get more details on Yang++ and ForCES to see how > many wheels fall off. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Wednesday, April 23, 2014 12:08 PM > To: Edward Crabbe; i2rs@ietf.org> > YANG (with NETCONF) is designed for writing configuration and reading > everything else, and does an excellent job at it. Trouble is, for me, that > configuration doesn't mean what I think of it as; it means, in the YANG > context, what you might put in through the CLI and it excludes everything > else, such as data learnt via a protocol. > > Take routing. A static route is configuration; anything learnt, via BGP, > IS-IS, RIP etc, is not configuration (and is read only). > > An interface configured automatically on a hot-plugged card is not > configuration; adding 'ospf passive' is. > > And so on, for DHCP, NTP, ..... > > In practice, this means that the YANG model comes in twin sets, one of > read-write configuration and one of read-only not-configuration (as can be > seen in the current I-Ds that the netmod WG is producing) with no formal way > in YANG of relating the one to the other. So if you want e.g. the routing > table, the host software has to know where to look and how to combine the > pieces to produce a coherent picture (and then you cannot edit most of it). > > So if I2RS never wants to write anything to a router, YANG is fine; if I2RS > is only producing a Information Model (and ignoring whether or not data is > read-only or read-write), and not moving on to an implementation, then YANG > is fine. > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an extension > to YANG, a new sub-statement for all data objects, semantics not too clear > but designed to separate out the not-configuration, learnt via a protocol, > 'editable-state' (and in doing so, making it read-write - but still 'config > false'). > > Yes, YANG allows for such extensions but it seems to me that I2RS would then > be getting YANG++ (and NETCONF++), once the necessary work has been done. > > Tom Petch > > > ----- Original Message ----- > From: "Edward Crabbe" > To: > Sent: Friday, April 11, 2014 6:50 PM > Subject: [i2rs] consensus on I2RS protocol and model > From nobody Thu Apr 24 06:29:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E271A01DA for ; Thu, 24 Apr 2014 06:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsPxqYMemKWe for ; Thu, 24 Apr 2014 06:29:20 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id A19191A01D5 for ; Thu, 24 Apr 2014 06:29:20 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so2193692qac.26 for ; Thu, 24 Apr 2014 06:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g6ALtODM3AOYTMTzwUziM6Iv6sTFUl+8oGI5WvLhkE8=; b=j9V4NqVxf9EiRED07JMWFtT7TuyG5anYunTShv/uXakHVeWDW6KoRsBrGZHFmnLsP7 Hz/DRFsGDOsPp0xZeQYyBGbmEwEU8KuQ6NY6WLSXSZt0YAMBBONJyvTTyW8Lt1MU37Pq re6y1iwpB6pE9f5d04KNtGyXrHRVA1j4sHty0Qs7dE2kGL7ta8bzAXLJQgpR2kV4Cify RwC+neyKIf/j6pnMOraRkadmBJj5FEcCtI66pve1iXRP3sdhPniAqVMrihMcJLTysGxF piP6GhBBbfyKFMlsbjdhqfvWsps6NpRTQGDfElxA7uH7TstN3JxxfcTNMgDV/o0xnhMs mu4A== X-Gm-Message-State: ALoCoQnV8N6bj82fjhRYaX+mtgZyhk6zQbpqK3dmzDd7KjSZyj0na4+suXmUtcIm4Eb5IiXjsTuM MIME-Version: 1.0 X-Received: by 10.229.236.1 with SMTP id ki1mr2701729qcb.8.1398346153912; Thu, 24 Apr 2014 06:29:13 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 06:29:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 06:29:13 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a1134bddac705f504f7c9d5a6 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kuh6kKNqlQfqQqVmgxt0Aq3lTBI Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:29:23 -0000 --001a1134bddac705f504f7c9d5a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 3:27 AM, Jamal Hadi Salim wrote: > Forgot to change the topic. > I would like to follow up and build on this - but i wanted to make sure > there was some sanity first. > > Which drafts shows 1 I2RS client performing a network-wide edit across N locked I2RS agents? The agents do not coordinate with each other. The clients do not coordinate with each other. This is currently out of scope for the I2RS protocol. cheers, > jamal > Andy > > ---------- Forwarded message ---------- > From: Jamal Hadi Salim > Date: Thu, Apr 24, 2014 at 6:24 AM > Subject: Re: [i2rs] consensus on I2RS protocol and model > To: Dean Bogdanovic > Cc: Andy Bierman , "" > , Martin Bjorklund , "" > , "" > > > On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic > wrote: > > > > On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: > > > > > I thought I2RS is starting out focusing on 1 client and 1 agent. > > Dont think so. > > > Network locking across devices is out of scope. > > > > > > > > I have same opinion as you on this one, just wanted to spell it out one > more > > time explicitly, as I heard some discussions where network locking was > > coming up. > > > > Either I am misunderstanding both of you or both of you misunderstood the > requirement. > The idea is to allow a single writer per object as a starting point. > OTOH, if you really mean what you say then I violently disagree. > > cheers, > jamal > > PS:- Changing the topic so this is not lost in the noise because i think > that > the many clients-single agent brings needs for other protocol requirements. > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1134bddac705f504f7c9d5a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 24, 2014 at 3:27 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Forgot to change the topic.
I would like to follow up and build on this - but i wanted to make sure
there was some sanity first.


Which drafts shows 1 I2RS client perfo= rming a network-wide edit
across N locked I2RS agents?
=
The agents do not coordinate with each other.
The clients do not coordinate with each other.
This is currently = out of scope for the I2RS protocol.

cheers,
jamal

Andy
=A0

---------- Forwarded message ----------
From: Jamal Hadi Salim <hadi@mojata= tu.com>
Date: Thu, Apr 24, 2014 at 6:24 AM
Subject: Re: [i2rs] consensus on I2RS protocol and model
To: Dean Bogdanovic <deanb@juniper.= net>
Cc: Andy Bierman <andy@yumaworks.c= om>, "<i2rs@ietf.org>= ;"
<i2rs@ietf.org>, Martin Bjorklun= d <mbj@tail-f.com>, "<<= a href=3D"mailto:edc@google.com">edc@google.com>"
<edc@google.com>, "<ietfc@btconnect.com>" <<= a href=3D"mailto:ietfc@btconnect.com">ietfc@btconnect.com>


On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <deanb@juniper.net> wrote:
>
> On Apr 23, 2014, at 3:54 PM, Andy Bierman <andy@yumaworks.com> wrote:
>

> I thought I2RS is starting out focusing on 1 client and 1 agent.

Dont think so.

> Network locking across devices is out of scope.
>
>
>
> I have same opinion as you on this one, just wanted to spell it out on= e more
> time explicitly, as I heard some discussions where network locking was=
> coming up.
>

Either I am misunderstanding both of you or both of you misunderstood the requirement.
The idea is to allow a single writer per object as a starting point.
OTOH, if you really mean what you say then I violently disagree.

cheers,
jamal

PS:- Changing the topic so this is not lost in the noise because i think th= at
the many clients-single agent brings needs for other protocol requirements.=

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

--001a1134bddac705f504f7c9d5a6-- From nobody Thu Apr 24 06:40:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73EE1A019B for ; Thu, 24 Apr 2014 06:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD-2bkiI83Sq for ; Thu, 24 Apr 2014 06:40:39 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48A1A01DC for ; Thu, 24 Apr 2014 06:40:38 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so2962117veb.32 for ; Thu, 24 Apr 2014 06:40:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=m/N4SxKjGmf82ADLpw12k7nUYV1PDV7E2hv6CLb6CH8=; b=K12rKD8lq/L9remBazv7qhreSkPCQb3iSyxdjNdnRr3zMQzAfPHV1J7BpxgQDjiXQC pYdxWyd9kaAwehqAK7aRIC7ac6zFNNdp3s/xdlvIW3jzD4icxH03mA7nDaIClAqEVKNn tnhm4s4h8cq7vRIxkr0yDAm5ifHV7c9Ka1UB0aH0j6vSAQTgkKi1pbpIiTIowpSFoO/2 qmxAArGZQWXAnm8g5fkxL4+MpOR3fHe94nX23GuhZCbR5SvpLPgUD+hK4lzyOCHqiTmp FiFIBoeX8YNNlih0qkb4rb9tuPrOCX0t6jS/PWUbbh+ahOJ2/hO11r+NMGVTG/2GGh4e XXcQ== X-Gm-Message-State: ALoCoQlwq9+NYZsDuL+OS1N1djcB9PQcBMFpbQ8QHkcfxrPAOvknhUGmjHw427Nnr8qAvwpIdkzZ X-Received: by 10.221.36.73 with SMTP id sz9mr249835vcb.62.1398346832157; Thu, 24 Apr 2014 06:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 06:40:11 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 09:40:11 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0E9_4jAX3Ox1YwUaKEwntGI-hq8 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:40:42 -0000 On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrote: > > > Which drafts shows 1 I2RS client performing a network-wide edit > across N locked I2RS agents? > There is a requirement to allow only one client to own write access to a specified object in order to avoid locking. There is nothing objecting to a client being able to write to multiple objects as long as that rule is met. > The agents do not coordinate with each other. > The clients do not coordinate with each other. > > This is currently out of scope for the I2RS protocol. > Both assertions true. But what i was responding to is: There are multiple clients that connect to the same agent. And a client can connect to multiple agents. I believe that such a requirement _may_ call out certain features in the protocol. Essentially the agent is a broker. cheers, jamal >> cheers, >> jamal > > > Andy > >> >> >> ---------- Forwarded message ---------- >> From: Jamal Hadi Salim >> Date: Thu, Apr 24, 2014 at 6:24 AM >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> To: Dean Bogdanovic >> Cc: Andy Bierman , "" >> , Martin Bjorklund , "" >> , "" >> >> >> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >> wrote: >> > >> > On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: >> > >> >> > I thought I2RS is starting out focusing on 1 client and 1 agent. >> >> Dont think so. >> >> > Network locking across devices is out of scope. >> > >> > >> > >> > I have same opinion as you on this one, just wanted to spell it out one >> > more >> > time explicitly, as I heard some discussions where network locking was >> > coming up. >> > >> >> Either I am misunderstanding both of you or both of you misunderstood the >> requirement. >> The idea is to allow a single writer per object as a starting point. >> OTOH, if you really mean what you say then I violently disagree. >> >> cheers, >> jamal >> >> PS:- Changing the topic so this is not lost in the noise because i think >> that >> the many clients-single agent brings needs for other protocol >> requirements. >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu Apr 24 06:46:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F86A1A01DA for ; Thu, 24 Apr 2014 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weRCEstJa5_Y for ; Thu, 24 Apr 2014 06:46:48 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 48AF01A01B3 for ; Thu, 24 Apr 2014 06:46:48 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so2522128qcz.30 for ; Thu, 24 Apr 2014 06:46:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J4Q59Cudu9kLFOTqOv+akX+riJUt6NHvcTfPdO+ZeMo=; b=SYvxLOhd8ekAK9FK97xN37331f6VxAAT/f2gpCCxWb73TQfg8qUusxA8JvpfarlYUh 1YpBIIl8d3h3U6vWr4dXYTwAJUleDrBWCyOfGnHk1q3bnZlOPqqcIfL6hxEqBveTvx5m 6iNFGKtwX/X9Oo6j6uRZb7eJidmWWPy/EQMSv1R2Vtn0+cnF6MuYb3iHdfB2w6cROwnM 8ibOdu6jRq00cfnOJ/Xl6TeVGQXrtDD2S5Yj7cNgN39r5c6r6A9imFfa3+UwJjB3p2/9 dejgZdHJeccWjuqU+IkAU3GERwSrQNE/9WWYNGl8Mt1K+rVmG5sb2S4Jl72JNmwHMNiZ QdGg== X-Gm-Message-State: ALoCoQkn9Tqolj5qqEI0MYSNHBQS1hHTaNrCKKTXvIcZn6v7aPBHrh/qgVaw8wNkfJYYsg7vJhxw MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr2636770qge.34.1398347183862; Thu, 24 Apr 2014 06:46:23 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 06:46:23 -0700 (PDT) In-Reply-To: <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> Date: Thu, 24 Apr 2014 06:46:23 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a113abfd82afd4a04f7ca13da Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qvDjYRjf_skAJjWljMbpzTy4en0 Cc: "i2rs@ietf.org" , Edward Crabbe , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:46:50 -0000 --001a113abfd82afd4a04f7ca13da Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 6:15 AM, t.petch wrote: > ----- Original Message ----- > From: "Susan Hares" > To: "'t.petch'" ; "'Edward Crabbe'" > ; > Sent: Wednesday, April 23, 2014 5:21 PM > > Tom: > > > > 100% agree with your comments. I2RS cares whether it is read-only or > > read-write. My work toward the revision found: > > > > - RBNF RBNF did not even allow you a place to r/w or r-only or > permissions > > (needed for security, but that's my next draft). > > - The yang tree I wrote was r-w for config, but did not express the > ro-only > > tree. I wanted some feedback to figure out why I had 2 write 2 trees. > > (your telling me it is a yang short-coming). > > Sue > > That is a feature of YANG. Spend half a day on the netmod WG archives > for 1H2013, particularly May and June and for interfaces-cfg, and all > will be clear. > > As Ladislav said on 2May13, > > "In the current model, the operational state data are not present unless > the corresponding entry in the "interface" list is *configured*. So, > what I have in mind is a data tree like this: ..." > > That is, 'config false' nodes under a 'config true' node do not get > instantiated in the data model unless and until the 'config true' node > is configured. So if you have the one routing table, you will be unable > to see the routes learnt via BGP - 'config false' - unless and until you > configure the table by creating a static route - 'config true'. > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > where it is written down:-( > > I am confused. How would a router that has no 'eth27' interface configured suddenly start reporting statistics for an interface named 'eth27'? I think the operational state is usually related to the configuration, wrt/ instance naming (at least). The same YANG module could have config data and operational state. NETCONF could read everything and write config, and I2RS could read everything and write operational state. Even if the objects are separated, the data types, identities, features, and instance naming can be easily shared across protocols. Using different data types and instance naming for config and operational state would mean that humans and machines would need to know both, and be able to translate from 1 to the other. This would be an operational nightmare. > Tom Petch > > Andy > > > - UML seems to be able to handle read/write variants, and I'm looking > to see > > if graphical tools will help the developer. > > > > Not shown in the reduction: > > ... And I started working on BGP, ISIS, RIP.. only to find some of > these > > issues you mention. DCHP and NTP. Any suggestions or help would be > > gratefully accepted. > > > > I will continue to try to get more details on Yang++ and ForCES to see > how > > many wheels fall off. > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > > Sent: Wednesday, April 23, 2014 12:08 PM > > To: Edward Crabbe; i2rs@ietf.org> > > YANG (with NETCONF) is designed for writing configuration and reading > > everything else, and does an excellent job at it. Trouble is, for me, > that > > configuration doesn't mean what I think of it as; it means, in the > YANG > > context, what you might put in through the CLI and it excludes > everything > > else, such as data learnt via a protocol. > > > > Take routing. A static route is configuration; anything learnt, via > BGP, > > IS-IS, RIP etc, is not configuration (and is read only). > > > > An interface configured automatically on a hot-plugged card is not > > configuration; adding 'ospf passive' is. > > > > And so on, for DHCP, NTP, ..... > > > > In practice, this means that the YANG model comes in twin sets, one of > > read-write configuration and one of read-only not-configuration (as > can be > > seen in the current I-Ds that the netmod WG is producing) with no > formal way > > in YANG of relating the one to the other. So if you want e.g. the > routing > > table, the host software has to know where to look and how to combine > the > > pieces to produce a coherent picture (and then you cannot edit most of > it). > > > > So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS > > is only producing a Information Model (and ignoring whether or not > data is > > read-only or read-write), and not moving on to an implementation, then > YANG > > is fine. > > > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension > > to YANG, a new sub-statement for all data objects, semantics not too > clear > > but designed to separate out the not-configuration, learnt via a > protocol, > > 'editable-state' (and in doing so, making it read-write - but still > 'config > > false'). > > > > Yes, YANG allows for such extensions but it seems to me that I2RS > would then > > be getting YANG++ (and NETCONF++), once the necessary work has been > done. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Edward Crabbe" > > To: > > Sent: Friday, April 11, 2014 6:50 PM > > Subject: [i2rs] consensus on I2RS protocol and model > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113abfd82afd4a04f7ca13da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 24, 2014 at 6:15 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Susan Hares" <shares= @ndzh.com>
To: "'t.petch'" <ietfc@btconnect.com>; "'Edward Crabbe'"
<edc@google.com>; <i2rs@ietf.org>
Sent: Wednesday, April 23, 2014 5:21 PM
> Tom:
>
> 100% agree with your comments. I2RS cares whether it is read-only or > read-write. =A0My work toward the revision found:
>
> - RBNF =A0RBNF did not even allow you a place to r/w or r-only or
permissions
> (needed for security, but that's my next draft).
> - The yang tree I wrote was r-w for config, but did not express the ro-only
> tree. =A0I wanted some feedback to figure out why I had 2 write 2 tree= s.
> =A0(your telling me it is a yang short-coming).

Sue

That is a feature of YANG. =A0Spend half a day on the netmod WG archives for 1H2013, particularly May and June and for interfaces-cfg, and all
will be clear.

As Ladislav said on 2May13,

"In the current model, the operational state data are not present unle= ss
the corresponding entry in the "interface" list is *configured*. = So,
what I have in mind is a data tree like this: ..."

That is, 'config false' nodes under a 'config true' node do= not get
instantiated in the data model unless and until the 'config true' n= ode
is configured. =A0So if you have the one routing table, you will be unable<= br> to see the routes learnt via BGP - 'config false' - unless and unti= l you
configure the table by creating a static route - 'config true'.

It is a tenet of YANG so fundamental, so basic, that I know of nowhere
where it is written down:-(


I am confused.
How would a r= outer that has no 'eth27' interface configured suddenly
s= tart reporting statistics for an interface named 'eth27'?

I think the operational state is usually related to the= configuration,
wrt/ instance naming (at least). =A0The same YANG= module could have
config data and operational state. =A0NETCONF = could read everything and
write config, and I2RS could read everything and write operational sta= te.

Even if the objects are separated, the data ty= pes, identities, features,
and instance naming can be easily shar= ed across protocols.

Using different data types and instance naming for conf= ig
and operational state would mean that humans and machines woul= d
need to know both, and be able to translate from 1 to the other= .
This would be an operational nightmare.


<= /div>
=A0
Tom Petch


Andy
=A0

> - UML seems to be able to handle read/write variants, and I'm look= ing
to see
> if graphical tools will help the developer.
>
> Not shown in the reduction:
> ... And I started working on BGP, ISIS, RIP.. only to find some of
these
> issues you mention. DCHP and NTP. =A0 Any suggestions or help would be=
> gratefully accepted.
>
> I will continue to try to get more details on Yang++ and ForCES to see=
how
> many wheels fall off.
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounc= es@ietf.org] On Behalf Of t.petch
> Sent: Wednesday, April 23, 2014 12:08 PM
> To: Edward Crabbe; i2rs@ietf.org&= gt;
> YANG (with NETCONF) is designed for writing configuration and reading<= br> > everything else, and does an excellent job at it. =A0Trouble is, for m= e,
that
> configuration doesn't mean what I think of it as; it means, in the=
YANG
> context, what you might put in through the CLI and it excludes
everything
> else, such as data learnt via a protocol.
>
> Take routing. =A0A static route is configuration; anything learnt, via=
BGP,
> IS-IS, RIP etc, is not configuration (and is read only).
>
> An interface configured automatically on a hot-plugged card is not
> configuration; adding 'ospf passive' is.
>
> And so on, for DHCP, NTP, .....
>
> In practice, this means that the YANG model comes in twin sets, one of=
> read-write configuration and one of read-only not-configuration (as can be
> seen in the current I-Ds that the netmod WG is producing) with no
formal way
> in YANG of relating the one to the other. =A0So if you want e.g. the routing
> table, the host software has to know where to look and how to combine<= br> the
> pieces to produce a coherent picture (and then you cannot edit most of=
it).
>
> So if I2RS never wants to write anything to a router, YANG is fine; if=
I2RS
> is only producing a Information Model (and ignoring whether or not
data is
> read-only or read-write), and not moving on to an implementation, then=
YANG
> is fine.
>
> Rather, as Andy Bierman said at IETF89, likely I2RS would need an
extension
> to YANG, a new sub-statement for all data objects, semantics not too clear
> but designed to separate out the not-configuration, learnt via a
protocol,
> 'editable-state' (and in doing so, making it read-write - but = still
'config
> false').
>
> Yes, YANG allows for such extensions but it seems to me that I2RS
would then
> be getting YANG++ (and NETCONF++), once the necessary work has been done.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Edward Crabbe" <= edc@google.com>
> To: <i2rs@ietf.org>
> Sent: Friday, April 11, 2014 6:50 PM
> Subject: [i2rs] consensus on I2RS protocol and model
>

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

--001a113abfd82afd4a04f7ca13da-- From nobody Thu Apr 24 06:52:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BC1A0266 for ; Thu, 24 Apr 2014 06:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvrzdgOrQZg0 for ; Thu, 24 Apr 2014 06:51:56 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 981A01A0232 for ; Thu, 24 Apr 2014 06:51:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DC9B51C258E7; Thu, 24 Apr 2014 06:51:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (74-84-92-146.client.mchsi.com [74.84.92.146]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 452FA1C258E5; Thu, 24 Apr 2014 06:51:49 -0700 (PDT) Message-ID: <535916F0.3050206@joelhalpern.com> Date: Thu, 24 Apr 2014 09:51:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jamal Hadi Salim , Andy Bierman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HZcyAmuF-KEaIEXQXO_-Q0Hd5nw Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:52:00 -0000 No, there is no requirement that the client is a broker. He may be, or he may not. And the scope of his brokering, if he is a broker, may be application specific or more general. We have placed requirements to be able to provide traceability when the client is brokering. This is as much because even a non-broker may be acting on behalf of several different applications. As far as I can tell, the fact that a client may itneract with multiple agents does not in itself palce new protocol or model requirements on the system. If we wanted inter-agent atomicity, then there would be requirements. But we explicitly decided that was out of scope. Yours, Joel On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: > On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrote: >> >> >> Which drafts shows 1 I2RS client performing a network-wide edit >> across N locked I2RS agents? >> > > There is a requirement to allow only one client to own write access to > a specified object in order to avoid locking. There is nothing objecting > to a client being able to write to multiple objects as long as that rule > is met. > >> The agents do not coordinate with each other. >> The clients do not coordinate with each other. >> >> This is currently out of scope for the I2RS protocol. >> > > Both assertions true. > But what i was responding to is: > There are multiple clients that connect to the same agent. > And a client can connect to multiple agents. > > I believe that such a requirement _may_ call out certain features in > the protocol. Essentially the agent is a broker. > > cheers, > jamal > >>> cheers, >>> jamal >> >> >> Andy >> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Jamal Hadi Salim >>> Date: Thu, Apr 24, 2014 at 6:24 AM >>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>> To: Dean Bogdanovic >>> Cc: Andy Bierman , "" >>> , Martin Bjorklund , "" >>> , "" >>> >>> >>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>> wrote: >>>> >>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: >>>> >>> >>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>> >>> Dont think so. >>> >>>> Network locking across devices is out of scope. >>>> >>>> >>>> >>>> I have same opinion as you on this one, just wanted to spell it out one >>>> more >>>> time explicitly, as I heard some discussions where network locking was >>>> coming up. >>>> >>> >>> Either I am misunderstanding both of you or both of you misunderstood the >>> requirement. >>> The idea is to allow a single writer per object as a starting point. >>> OTOH, if you really mean what you say then I violently disagree. >>> >>> cheers, >>> jamal >>> >>> PS:- Changing the topic so this is not lost in the noise because i think >>> that >>> the many clients-single agent brings needs for other protocol >>> requirements. >>> >>> _______________________________________________ >>> 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 nobody Thu Apr 24 07:08:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8391A0248 for ; Thu, 24 Apr 2014 07:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1zwT9HMmfHA for ; Thu, 24 Apr 2014 07:08:37 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBDA1A0245 for ; Thu, 24 Apr 2014 07:08:37 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so2976317vcb.14 for ; Thu, 24 Apr 2014 07:08:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Wk4ifZvrlChGaTDoChdQ8HaYSJUyFXRccX4LJotFjAY=; b=RjHnU+dBVeGhRqjuc3rDyY0aFYhAzF9REhe48RbW1+TNmne7QBp4irsw5vaaYEDOeY e3sS9c8IMFPmHpBtndo0SvY8GHw4fE3La2cUlSOPJ8arGQq7xtpZ78XGWeJ8qiTVuAIr bv+QHAA/JaxVpwhJABwC8kOI/QGdIB2dGZ1wt/E7dtlJrvUTDUfcXerD5KbqB/0HX/Gr nSMdgG+92HTdtC0PbgQsA1izYH54ZuwsJnzuYs6PJ1UiZ2mnIMt5dYVkZ7qQxRivI5ed 1t2kFUtwhEYtaNTZIIoOJ97vQMYwRSaPli0IJw4QFieHU58wDWxjuPoahzIa3xuexrNo WASg== X-Gm-Message-State: ALoCoQnJMxm1UanqJsYMfMab9Fj0hBpYgnPt6a5wletVVar45co+9iEothkn68/S/4foZRafv9zr X-Received: by 10.220.113.207 with SMTP id b15mr36145vcq.55.1398348511010; Thu, 24 Apr 2014 07:08:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 07:08:09 -0700 (PDT) In-Reply-To: <535916F0.3050206@joelhalpern.com> References: <535916F0.3050206@joelhalpern.com> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 10:08:09 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dyAF6dFJk4eb8mWiJutzj5FQ4sE Cc: "i2rs@ietf.org" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 14:08:39 -0000 I was more looking at the agent - it brokers between clients and the RIB subsystem as shown in figure 1 of the architecture doc. Different clients bring different latencies/capacities. Congestions will kick in, reliability requirements will need to be considered. And there may be need to signal these details to the clients (SIP proxying is the closest i can think of). You cant solve this problem by just inserting a reliable transport where the i2rs protocol runs. cheers, jamal On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wrote: > No, there is no requirement that the client is a broker. He may be, or he > may not. And the scope of his brokering, if he is a broker, may be > application specific or more general. > > We have placed requirements to be able to provide traceability when the > client is brokering. This is as much because even a non-broker may be > acting on behalf of several different applications. > > As far as I can tell, the fact that a client may itneract with multiple > agents does not in itself palce new protocol or model requirements on the > system. If we wanted inter-agent atomicity, then there would be > requirements. But we explicitly decided that was out of scope. > > Yours, > Joel > > > On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >> >> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrote: >>> >>> >>> >>> Which drafts shows 1 I2RS client performing a network-wide edit >>> across N locked I2RS agents? >>> >> >> There is a requirement to allow only one client to own write access to >> a specified object in order to avoid locking. There is nothing objecting >> to a client being able to write to multiple objects as long as that rule >> is met. >> >>> The agents do not coordinate with each other. >>> The clients do not coordinate with each other. >>> >>> This is currently out of scope for the I2RS protocol. >>> >> >> Both assertions true. >> But what i was responding to is: >> There are multiple clients that connect to the same agent. >> And a client can connect to multiple agents. >> >> I believe that such a requirement _may_ call out certain features in >> the protocol. Essentially the agent is a broker. >> >> cheers, >> jamal >> >>>> cheers, >>>> jamal >>> >>> >>> >>> Andy >>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Jamal Hadi Salim >>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>> To: Dean Bogdanovic >>>> Cc: Andy Bierman , "" >>>> , Martin Bjorklund , "" >>>> , "" >>>> >>>> >>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>> wrote: >>>>> >>>>> >>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: >>>>> >>>> >>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>> >>>> >>>> Dont think so. >>>> >>>>> Network locking across devices is out of scope. >>>>> >>>>> >>>>> >>>>> I have same opinion as you on this one, just wanted to spell it out one >>>>> more >>>>> time explicitly, as I heard some discussions where network locking was >>>>> coming up. >>>>> >>>> >>>> Either I am misunderstanding both of you or both of you misunderstood >>>> the >>>> requirement. >>>> The idea is to allow a single writer per object as a starting point. >>>> OTOH, if you really mean what you say then I violently disagree. >>>> >>>> cheers, >>>> jamal >>>> >>>> PS:- Changing the topic so this is not lost in the noise because i think >>>> that >>>> the many clients-single agent brings needs for other protocol >>>> requirements. >>>> >>>> _______________________________________________ >>>> 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 nobody Thu Apr 24 07:27:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E641A0266 for ; Thu, 24 Apr 2014 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTWpqnFSajfG for ; Thu, 24 Apr 2014 07:27:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CD7961A01DA for ; Thu, 24 Apr 2014 07:27:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7783E540680; Thu, 24 Apr 2014 16:27:08 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt+DG3YiPW0X; Thu, 24 Apr 2014 16:27:03 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 852CB5402E5; Thu, 24 Apr 2014 16:27:02 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , Susan Hares , 'Edward Crabbe' , i2rs@ietf.org In-Reply-To: <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 24 Apr 2014 16:27:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/84RDvXgYPaLB_SSC-qM2-qaerEY Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 14:27:18 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Susan Hares" > To: "'t.petch'" ; "'Edward Crabbe'" > ; > Sent: Wednesday, April 23, 2014 5:21 PM >> Tom: >> >> 100% agree with your comments. I2RS cares whether it is read-only or >> read-write. My work toward the revision found: >> >> - RBNF RBNF did not even allow you a place to r/w or r-only or > permissions >> (needed for security, but that's my next draft). >> - The yang tree I wrote was r-w for config, but did not express the > ro-only >> tree. I wanted some feedback to figure out why I had 2 write 2 trees. >> (your telling me it is a yang short-coming). > > Sue > > That is a feature of YANG. Spend half a day on the netmod WG archives > for 1H2013, particularly May and June and for interfaces-cfg, and all > will be clear. > > As Ladislav said on 2May13, > > "In the current model, the operational state data are not present unless > the corresponding entry in the "interface" list is *configured*. So, > what I have in mind is a data tree like this: ..." > > That is, 'config false' nodes under a 'config true' node do not get > instantiated in the data model unless and until the 'config true' node > is configured. So if you have the one routing table, you will be unable This issue only affects 'config false' data appearing in the subtree of a 'config true' node. In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. > to see the routes learnt via BGP - 'config false' - unless and until you > configure the table by creating a static route - 'config true'. Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration. > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > where it is written down:-( Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work. Lada > > Tom Petch > > >> - UML seems to be able to handle read/write variants, and I'm looking > to see >> if graphical tools will help the developer. >> >> Not shown in the reduction: >> ... And I started working on BGP, ISIS, RIP.. only to find some of > these >> issues you mention. DCHP and NTP. Any suggestions or help would be >> gratefully accepted. >> >> I will continue to try to get more details on Yang++ and ForCES to see > how >> many wheels fall off. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch >> Sent: Wednesday, April 23, 2014 12:08 PM >> To: Edward Crabbe; i2rs@ietf.org> >> YANG (with NETCONF) is designed for writing configuration and reading >> everything else, and does an excellent job at it. Trouble is, for me, > that >> configuration doesn't mean what I think of it as; it means, in the > YANG >> context, what you might put in through the CLI and it excludes > everything >> else, such as data learnt via a protocol. >> >> Take routing. A static route is configuration; anything learnt, via > BGP, >> IS-IS, RIP etc, is not configuration (and is read only). >> >> An interface configured automatically on a hot-plugged card is not >> configuration; adding 'ospf passive' is. >> >> And so on, for DHCP, NTP, ..... >> >> In practice, this means that the YANG model comes in twin sets, one of >> read-write configuration and one of read-only not-configuration (as > can be >> seen in the current I-Ds that the netmod WG is producing) with no > formal way >> in YANG of relating the one to the other. So if you want e.g. the > routing >> table, the host software has to know where to look and how to combine > the >> pieces to produce a coherent picture (and then you cannot edit most of > it). >> >> So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS >> is only producing a Information Model (and ignoring whether or not > data is >> read-only or read-write), and not moving on to an implementation, then > YANG >> is fine. >> >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension >> to YANG, a new sub-statement for all data objects, semantics not too > clear >> but designed to separate out the not-configuration, learnt via a > protocol, >> 'editable-state' (and in doing so, making it read-write - but still > 'config >> false'). >> >> Yes, YANG allows for such extensions but it seems to me that I2RS > would then >> be getting YANG++ (and NETCONF++), once the necessary work has been > done. >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Edward Crabbe" >> To: >> Sent: Friday, April 11, 2014 6:50 PM >> Subject: [i2rs] consensus on I2RS protocol and model >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 24 07:45:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA641A031A for ; Thu, 24 Apr 2014 07:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B0UWcQ5J7-U for ; Thu, 24 Apr 2014 07:45:10 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC261A0318 for ; Thu, 24 Apr 2014 07:45:10 -0700 (PDT) Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 14:45:02 +0000 Message-ID: <011c01cf5fcb$7cf0f640$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net><20140423.190851.213360502.mbj@tail-f.com><008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> Date: Thu, 24 Apr 2014 15:42:51 +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.69] X-ClientProxiedBy: DBXPR07CA007.eurprd07.prod.outlook.com (10.255.191.165) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Forefront-PRVS: 01917B1794 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(57704003)(13464003)(199002)(189002)(51704005)(24454002)(77982001)(85852003)(31966008)(33646001)(81342001)(87976001)(92726001)(74662001)(74502001)(44716002)(76482001)(62236002)(92566001)(93916002)(50226001)(79102001)(86362001)(50986999)(81686999)(81816999)(76176999)(50466002)(42186004)(84392001)(80976001)(81542001)(19580395003)(46102001)(66066001)(62966002)(44736004)(77156001)(20776003)(83072002)(47776003)(61296002)(99396002)(87286001)(88136002)(23756003)(19580405001)(83322001)(14496001)(89996001)(4396001)(80022001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB050; H:DB3PRD0210HT005.eurprd02.prod.outlook.com; FPR:D4F8F248.13EB8FFF.79F499B9.82F5DE89.202F0; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gD9yQXdXAC3ypIh0Tdbdg18sKxA Cc: i2rs@ietf.org, edc@google.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 14:45:12 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Thursday, April 24, 2014 12:12 PM > t.petch wrote: > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: ; > > Sent: Wednesday, April 23, 2014 6:08 PM > > > t.petch wrote: > > > > > > > > > Splitting state into two, operational and the rest, with an > > i2rs:edit-data for the former, does nothing to help with this - it could > > make things more complex. > > > > We now have a three way split - do we now have three separate trees (if > > not, why not)? > > I don't think a separate structure for i2rs routes are needed, b/c it > is supposed to directly modify the operational state. > > Also, I don't think this is a YANG-specific issue; any modelling > language can model one, two or three separate structures. If we put > the configuration part aside, you still have to decide if you need one > or two (or N) structures for "i2rs" state and "complete" state. Martin The reason I speculate about three structures relates to the rules of YANG, for example that 'config true' cannot be subordinate to 'config false' in the schema tree. I cannot now recall what goes wrong were that not to be the case, but if we introduce i2rs:edit-data, then what are the rules about that? Can it be freely mixed with 'config true' in the tree, or do we need more rules about what can appear under what? or do we need to work more on the semantics of i2rs:edit-data? I don't know, hence my question (and my underlying concern that some way down the road, I2RS Information Models complete, we will hit a snag related to this that makes data models difficult to derive from the Information Models).. Tom Petch > > > > How do we get the i2rs:edit-data? Do we use filters to > > separate out the i2rs:edit-data, like a NETCONF get were get-config not > > to exist? > > Sure, just like might want to get the routes from bgp or some other > protocol. > > > /martin > From nobody Thu Apr 24 07:50:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58F61A033E for ; Thu, 24 Apr 2014 07:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RdI9oSKrX1a for ; Thu, 24 Apr 2014 07:50:29 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id ED2041A0318 for ; Thu, 24 Apr 2014 07:50:28 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so2662265qcv.1 for ; Thu, 24 Apr 2014 07:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G87+7PpjZUO+CnEauSYsTAmbVMIRnG9LuAL2hiIhZhM=; b=Jiu4gwq8NUCrDPLLQWQ7TrQ1fSmXYHfnas0zAH1fDUX1UFSfWEFCtgic4PYDNxV5aY ckdhR+EmyLbjx5VHJxRAhw+s++QKFqBqZwIMPeCFfisS3bN+5bFMiMth9tXbvPJIhR2Z 6PQ9tnuZwgyji04xAnT53Okjw3ZHjWuUTLYGTRPoZRW8xOkdANBRaNCer7jydNy+rnjZ 7NRVDrz4eJjH125OxiJkPUiqzub4ktAPZDvoDoSFp6T6ZJG8K/aDzFWchoCVcbp9CNZP zid/Yq1O78WpSgDDoHHL7HseW597Jf38leFMZRAfdEiW9rmJ0D4v0HtftTT+7iuJ+Do+ U4Zw== X-Gm-Message-State: ALoCoQl4o7mOhLC5a/Sty0mrAQi7xOkNssXWKZpX9k1XN3uXxzevi7DHG4nzfxmaxSt1rHYE/CBF MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr3188764qge.34.1398351022587; Thu, 24 Apr 2014 07:50:22 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 07:50:22 -0700 (PDT) In-Reply-To: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> Date: Thu, 24 Apr 2014 07:50:22 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113abfd8f9174904f7caf70c Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TTZ0tyKp-coTYwjS1c4VADytPUU Cc: "i2rs@ietf.org" , Edward Crabbe , "t.petch" , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 14:50:32 -0000 --001a113abfd8f9174904f7caf70c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 7:27 AM, Ladislav Lhotka wrote: > "t.petch" writes: > > > ----- Original Message ----- > > From: "Susan Hares" > > To: "'t.petch'" ; "'Edward Crabbe'" > > ; > > Sent: Wednesday, April 23, 2014 5:21 PM > >> Tom: > >> > >> 100% agree with your comments. I2RS cares whether it is read-only or > >> read-write. My work toward the revision found: > >> > >> - RBNF RBNF did not even allow you a place to r/w or r-only or > > permissions > >> (needed for security, but that's my next draft). > >> - The yang tree I wrote was r-w for config, but did not express the > > ro-only > >> tree. I wanted some feedback to figure out why I had 2 write 2 trees. > >> (your telling me it is a yang short-coming). > > > > Sue > > > > That is a feature of YANG. Spend half a day on the netmod WG archives > > for 1H2013, particularly May and June and for interfaces-cfg, and all > > will be clear. > > > > As Ladislav said on 2May13, > > > > "In the current model, the operational state data are not present unless > > the corresponding entry in the "interface" list is *configured*. So, > > what I have in mind is a data tree like this: ..." > > > > That is, 'config false' nodes under a 'config true' node do not get > > instantiated in the data model unless and until the 'config true' node > > is configured. So if you have the one routing table, you will be unable > > This issue only affects 'config false' data appearing in the subtree of a > 'config true' node. > In my opinion, such a data organisation should be generally avoided, and > that's why we now have configuration and state data in separate trees. > > So to be clear -- it is a property of the data model, not the language. YANG allows top-level config=true or false nodes. The data model authors need to pick the design patterns that are most appropriate. (just like code ;-) Generally, the correlation is embodied in the list keys -- the data naming. For example in the interfaces module, the keys are the same. typedef interface-ref { type leafref { path "/if:interfaces/if:interface/if:name"; } description "This type is used by data models that need to reference configured interfaces."; } typedef interface-state-ref { type leafref { path "/if:interfaces-state/if:interface/if:name"; } description "This type is used by data models that need to reference the operationally present interfaces."; } A weakness of YANG (perhaps Tom's point?) is that the correlation between the 2 'name' leafs is defined in the description statements, (elsewhere in the module) not any machine-readable statements. In general, this correlation is very model-specific, and it might be too hard to formalize into machine-readable statements. > to see the routes learnt via BGP - 'config false' - unless and until you > > configure the table by creating a static route - 'config true'. > > Note this has never been the case in the ietf-routing module. Routing > tables (later renamed to ribs) were always "pure" state data and the > default rib for every address family is supposed to be present > independently of any configuration. > > > > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > > where it is written down:-( > > Please see the definitions of system-controlled versus user-controlled > list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. > > I also think think is no idiosyncrasy of YANG, just the way how most > systems and their CLIs work. > > Lada > > Andy > > > > Tom Petch > > > > > >> - UML seems to be able to handle read/write variants, and I'm looking > > to see > >> if graphical tools will help the developer. > >> > >> Not shown in the reduction: > >> ... And I started working on BGP, ISIS, RIP.. only to find some of > > these > >> issues you mention. DCHP and NTP. Any suggestions or help would be > >> gratefully accepted. > >> > >> I will continue to try to get more details on Yang++ and ForCES to see > > how > >> many wheels fall off. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > >> Sent: Wednesday, April 23, 2014 12:08 PM > >> To: Edward Crabbe; i2rs@ietf.org> > >> YANG (with NETCONF) is designed for writing configuration and reading > >> everything else, and does an excellent job at it. Trouble is, for me, > > that > >> configuration doesn't mean what I think of it as; it means, in the > > YANG > >> context, what you might put in through the CLI and it excludes > > everything > >> else, such as data learnt via a protocol. > >> > >> Take routing. A static route is configuration; anything learnt, via > > BGP, > >> IS-IS, RIP etc, is not configuration (and is read only). > >> > >> An interface configured automatically on a hot-plugged card is not > >> configuration; adding 'ospf passive' is. > >> > >> And so on, for DHCP, NTP, ..... > >> > >> In practice, this means that the YANG model comes in twin sets, one of > >> read-write configuration and one of read-only not-configuration (as > > can be > >> seen in the current I-Ds that the netmod WG is producing) with no > > formal way > >> in YANG of relating the one to the other. So if you want e.g. the > > routing > >> table, the host software has to know where to look and how to combine > > the > >> pieces to produce a coherent picture (and then you cannot edit most of > > it). > >> > >> So if I2RS never wants to write anything to a router, YANG is fine; if > > I2RS > >> is only producing a Information Model (and ignoring whether or not > > data is > >> read-only or read-write), and not moving on to an implementation, then > > YANG > >> is fine. > >> > >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an > > extension > >> to YANG, a new sub-statement for all data objects, semantics not too > > clear > >> but designed to separate out the not-configuration, learnt via a > > protocol, > >> 'editable-state' (and in doing so, making it read-write - but still > > 'config > >> false'). > >> > >> Yes, YANG allows for such extensions but it seems to me that I2RS > > would then > >> be getting YANG++ (and NETCONF++), once the necessary work has been > > done. > >> > >> Tom Petch > >> > >> > >> ----- Original Message ----- > >> From: "Edward Crabbe" > >> To: > >> Sent: Friday, April 11, 2014 6:50 PM > >> Subject: [i2rs] consensus on I2RS protocol and model > >> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113abfd8f9174904f7caf70c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 24, 2014 at 7:27 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
"t.petch" <ietfc@btconnect.com> writes:

> ----- Original Message -----
> From: "Susan Hares" <s= hares@ndzh.com>
> To: "'t.petch'" <ietfc@btconnect.com>; "'Edward Crabbe'"
> <edc@google.com>; <i2rs@ietf.org>
> Sent: Wednesday, April 23, 2014 5:21 PM
>> Tom:
>>
>> 100% agree with your comments. I2RS cares whether it is read-only = or
>> read-write. =A0My work toward the revision found:
>>
>> - RBNF =A0RBNF did not even allow you a place to r/w or r-only or<= br> > permissions
>> (needed for security, but that's my next draft).
>> - The yang tree I wrote was r-w for config, but did not express th= e
> ro-only
>> tree. =A0I wanted some feedback to figure out why I had 2 write 2 = trees.
>> =A0(your telling me it is a yang short-coming).
>
> Sue
>
> That is a feature of YANG. =A0Spend half a day on the netmod WG archiv= es
> for 1H2013, particularly May and June and for interfaces-cfg, and all<= br> > will be clear.
>
> As Ladislav said on 2May13,
>
> "In the current model, the operational state data are not present= unless
> the corresponding entry in the "interface" list is *configur= ed*. So,
> what I have in mind is a data tree like this: ..."
>
> That is, 'config false' nodes under a 'config true' no= de do not get
> instantiated in the data model unless and until the 'config true&#= 39; node
> is configured. =A0So if you have the one routing table, you will be un= able

This issue only affects 'config false' data appearing in the subtre= e of a 'config true' node.
In my opinion, such a data organisation should be generally avoided, and th= at's why we now have configuration and state data in separate trees.

So to be clear -- it is a property of = the data model, not the language.
YANG allows top-level config=3D= true or false nodes. =A0The data model
authors need to pick the d= esign patterns that are most appropriate.
(just like code ;-)

Generally, the correlatio= n is embodied in the list keys -- the data naming.
For example in= the interfaces module, the keys are the same.

 =
    typedef interface-ref {
       type leafref {
         path "/if:interfaces/if:interface/if:name";
       }
       description
         "This type is used by data models that need to reference
          configured interfaces.";
     }

     typedef interface-state-ref {
       type leafref {
         path "/if:interfaces-state/if:interface/if:name";
       }
       description
         "This type is used by data models that need to reference
          the operationally present interfaces.";
     }

A weakness of YANG (perhaps Tom's point?) is that = the correlation
between the 2 'name' leafs is defined in the des= cription statements,
(elsewhere in the module) not any machine-readable statements.
In general, this correlation is very model-specific, and it might be too= hard
to formalize into machine-readable statements.



> to see the routes learnt via BGP - 'config false' - unless and= until you
> configure the table by creating a static route - 'config true'= .

Note this has never been the case in the ietf-routing module. Routing table= s (later renamed to ribs) were always "pure" state data and the d= efault rib for every address family is supposed to be present independently= of any configuration.

>
> It is a tenet of YANG so fundamental, so basic, that I know of nowhere=
> where it is written down:-(

Please see the definitions of system-controlled versus user-controlled list= entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13.

I also think think is no idiosyncrasy of YANG, just the way how most system= s and their CLIs work.

Lada



Andy
=A0
>
> Tom Petch
>
>
>> - UML seems to be able to handle read/write variants, and I'm = looking
> to see
>> if graphical tools will help the developer.
>>
>> Not shown in the reduction:
>> ... And I started working on BGP, ISIS, RIP.. only to find some of=
> these
>> issues you mention. DCHP and NTP. =A0 Any suggestions or help woul= d be
>> gratefully accepted.
>>
>> I will continue to try to get more details on Yang++ and ForCES to= see
> how
>> many wheels fall off.
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of t.petch
>> Sent: Wednesday, April 23, 2014 12:08 PM
>> To: Edward Crabbe; i2rs@ietf.org<= /a>>
>> YANG (with NETCONF) is designed for writing configuration and read= ing
>> everything else, and does an excellent job at it. =A0Trouble is, f= or me,
> that
>> configuration doesn't mean what I think of it as; it means, in= the
> YANG
>> context, what you might put in through the CLI and it excludes
> everything
>> else, such as data learnt via a protocol.
>>
>> Take routing. =A0A static route is configuration; anything learnt,= via
> BGP,
>> IS-IS, RIP etc, is not configuration (and is read only).
>>
>> An interface configured automatically on a hot-plugged card is not=
>> configuration; adding 'ospf passive' is.
>>
>> And so on, for DHCP, NTP, .....
>>
>> In practice, this means that the YANG model comes in twin sets, on= e of
>> read-write configuration and one of read-only not-configuration (a= s
> can be
>> seen in the current I-Ds that the netmod WG is producing) with no<= br> > formal way
>> in YANG of relating the one to the other. =A0So if you want e.g. t= he
> routing
>> table, the host software has to know where to look and how to comb= ine
> the
>> pieces to produce a coherent picture (and then you cannot edit mos= t of
> it).
>>
>> So if I2RS never wants to write anything to a router, YANG is fine= ; if
> I2RS
>> is only producing a Information Model (and ignoring whether or not=
> data is
>> read-only or read-write), and not moving on to an implementation, = then
> YANG
>> is fine.
>>
>> Rather, as Andy Bierman said at IETF89, likely I2RS would need an<= br> > extension
>> to YANG, a new sub-statement for all data objects, semantics not t= oo
> clear
>> but designed to separate out the not-configuration, learnt via a > protocol,
>> 'editable-state' (and in doing so, making it read-write - = but still
> 'config
>> false').
>>
>> Yes, YANG allows for such extensions but it seems to me that I2RS<= br> > would then
>> be getting YANG++ (and NETCONF++), once the necessary work has bee= n
> done.
>>
>> Tom Petch
>>
>>
>> ----- Original Message -----
>> From: "Edward Crabbe" <edc@google.com>
>> To: <i2rs@ietf.org>
>> Sent: Friday, April 11, 2014 6:50 PM
>> Subject: [i2rs] consensus on I2RS protocol and model
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--001a113abfd8f9174904f7caf70c-- From nobody Thu Apr 24 11:02:12 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92661A036B for ; Thu, 24 Apr 2014 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRSjmbB8b4kj for ; Thu, 24 Apr 2014 11:02:09 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB71A037A for ; Thu, 24 Apr 2014 11:02:09 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0C18AC0E8; Thu, 24 Apr 2014 14:02:03 -0400 (EDT) Date: Thu, 24 Apr 2014 14:02:02 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140424180202.GA3509@pfrc> References: <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> <20140422150829.GN8955@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VIhAqKCtUTLTffq9_GOuJP0z8DU Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , "Jan Medved \(jmedved\)" , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 18:02:11 -0000 Jamal, On Thu, Apr 24, 2014 at 06:02:05AM -0400, Jamal Hadi Salim wrote: > > It's pretty common to either tap before or after the transport APIs for > > debugging. I think the distintion is that in something text-like you can > > tap and do thinks potentially simpler than if you have to look at binary > > PDUs. That requires tapping one level back before the binary marshalling > > layer. Obviously that is doable as well, but simply moves the point of > > complexity one layer up/down. > > > > So I am sensing development debugging then? > The arguement i have heard is that operators debug > by capturing on the wire packets and that ascii was easier to follow. Such tap points are definitely there (or should be, IMO) for development debugging. The "capture on the wire" scenario is complicated by whether encryption is in use or not. Binary or not isn't critical here in some respects. After all, wireshark does perfectly fine in decoding various binary protocols. But it does mean in terms of our security and usability requirements that permitting integrity-only options vs. encryption required needs to be carefully thought through. -- Jeff From nobody Thu Apr 24 11:16:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56D51A0321 for ; Thu, 24 Apr 2014 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TslRy79Hbmia for ; Thu, 24 Apr 2014 11:16:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3B1A037A for ; Thu, 24 Apr 2014 11:16:36 -0700 (PDT) Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 24 Apr 2014 18:16:28 +0000 Message-ID: <012601cf5fe9$06477a00$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Susan Hares , 'Edward Crabbe' , References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> Date: Thu, 24 Apr 2014 19:12:20 +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.69] X-ClientProxiedBy: AM3PR07CA004.eurprd07.prod.outlook.com (10.242.16.44) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 01917B1794 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(51704005)(13464003)(77982001)(74502001)(47776003)(66066001)(74662001)(62966002)(89996001)(61296002)(23756003)(92726001)(81342001)(81542001)(84392001)(44736004)(62236002)(50986999)(92566001)(87976001)(79102001)(31966008)(20776003)(88136002)(44716002)(86362001)(46102001)(76176999)(575784001)(77156001)(83322001)(42186004)(80976001)(76482001)(50466002)(99396002)(81686999)(19580395003)(83072002)(80022001)(19580405001)(50226001)(87286001)(93916002)(33646001)(14496001)(15975445006)(85852003)(4396001)(81816999)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DB3PRD0210HT005.eurprd02.prod.outlook.com; FPR:E60FF1E4.A3EA93F7.73D3BD0B.92A6ED61.20688; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GVbCammLUOvW9YMw_LKjG2URbos Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 18:16:39 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" ; "Susan Hares" ; "'Edward Crabbe'" ; Sent: Thursday, April 24, 2014 3:27 PM > "t.petch" writes: > > > ----- Original Message ----- > > From: "Susan Hares" > > To: "'t.petch'" ; "'Edward Crabbe'" > > ; > > Sent: Wednesday, April 23, 2014 5:21 PM > >> Tom: > >> > >> 100% agree with your comments. I2RS cares whether it is read-only or > >> read-write. My work toward the revision found: > >> > >> - RBNF RBNF did not even allow you a place to r/w or r-only or > > permissions > >> (needed for security, but that's my next draft). > >> - The yang tree I wrote was r-w for config, but did not express the > > ro-only > >> tree. I wanted some feedback to figure out why I had 2 write 2 trees. > >> (your telling me it is a yang short-coming). > > > > Sue > > > > That is a feature of YANG. Spend half a day on the netmod WG archives > > for 1H2013, particularly May and June and for interfaces-cfg, and all > > will be clear. > > > > As Ladislav said on 2May13, > > > > "In the current model, the operational state data are not present unless > > the corresponding entry in the "interface" list is *configured*. So, > > what I have in mind is a data tree like this: ..." > > > > That is, 'config false' nodes under a 'config true' node do not get > > instantiated in the data model unless and until the 'config true' node > > is configured. So if you have the one routing table, you will be unable > > This issue only affects 'config false' data appearing in the subtree of a 'config true' node. > In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. > > > to see the routes learnt via BGP - 'config false' - unless and until you > > configure the table by creating a static route - 'config true'. > > Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration. > > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > > where it is written down:-( > > Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. > > I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work. Is it, though, the right approach for I2RS? I see the rationale of I2RS as being able to take a holistic view of the routing system, not one based on where the information is coming from (a view that may make sense when building boxes or installing them). Rather, I am minded of problems I have been called upon to resolve which are the result of misconfiguration, misconfiguration which is not apparent because the integrated view of what is controlling the box is not available. For example, a static route is inserted to circumvent a quirk of topology, the quirk is fixed but the static route is not removed, the topology changes again and that static route becomes a liability. Being able to see everything at once makes the problem apparent, looking for a configuration error or a BGP error separately is fruitless. My sense is that I2RS needs an integrated view whereas NETCONF/YANG focus on the configuration (as their RFC explicitly state). YANG is a good start, but as Andy said at IETF89, not enough. Tom Petch > Lada > > > > > Tom Petch > > > > > >> - UML seems to be able to handle read/write variants, and I'm looking > > to see > >> if graphical tools will help the developer. > >> > >> Not shown in the reduction: > >> ... And I started working on BGP, ISIS, RIP.. only to find some of > > these > >> issues you mention. DCHP and NTP. Any suggestions or help would be > >> gratefully accepted. > >> > >> I will continue to try to get more details on Yang++ and ForCES to see > > how > >> many wheels fall off. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > >> Sent: Wednesday, April 23, 2014 12:08 PM > >> To: Edward Crabbe; i2rs@ietf.org> > >> YANG (with NETCONF) is designed for writing configuration and reading > >> everything else, and does an excellent job at it. Trouble is, for me, > > that > >> configuration doesn't mean what I think of it as; it means, in the > > YANG > >> context, what you might put in through the CLI and it excludes > > everything > >> else, such as data learnt via a protocol. > >> > >> Take routing. A static route is configuration; anything learnt, via > > BGP, > >> IS-IS, RIP etc, is not configuration (and is read only). > >> > >> An interface configured automatically on a hot-plugged card is not > >> configuration; adding 'ospf passive' is. > >> > >> And so on, for DHCP, NTP, ..... > >> > >> In practice, this means that the YANG model comes in twin sets, one of > >> read-write configuration and one of read-only not-configuration (as > > can be > >> seen in the current I-Ds that the netmod WG is producing) with no > > formal way > >> in YANG of relating the one to the other. So if you want e.g. the > > routing > >> table, the host software has to know where to look and how to combine > > the > >> pieces to produce a coherent picture (and then you cannot edit most of > > it). > >> > >> So if I2RS never wants to write anything to a router, YANG is fine; if > > I2RS > >> is only producing a Information Model (and ignoring whether or not > > data is > >> read-only or read-write), and not moving on to an implementation, then > > YANG > >> is fine. > >> > >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an > > extension > >> to YANG, a new sub-statement for all data objects, semantics not too > > clear > >> but designed to separate out the not-configuration, learnt via a > > protocol, > >> 'editable-state' (and in doing so, making it read-write - but still > > 'config > >> false'). > >> > >> Yes, YANG allows for such extensions but it seems to me that I2RS > > would then > >> be getting YANG++ (and NETCONF++), once the necessary work has been > > done. > >> > >> Tom Petch > >> > >> > >> ----- Original Message ----- > >> From: "Edward Crabbe" > >> To: > >> Sent: Friday, April 11, 2014 6:50 PM > >> Subject: [i2rs] consensus on I2RS protocol and model > >> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Thu Apr 24 11:58:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5390E1A03C2 for ; Thu, 24 Apr 2014 11:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuNqo2j3ruFc for ; Thu, 24 Apr 2014 11:57:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B76451A03AB for ; Thu, 24 Apr 2014 11:57:58 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id B0885394128; Thu, 24 Apr 2014 20:57:50 +0200 (CEST) Date: Thu, 24 Apr 2014 20:57:50 +0200 (CEST) Message-Id: <20140424.205750.516350209.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <012601cf5fe9$06477a00$4001a8c0@gateway.2wire.net> References: <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> <012601cf5fe9$06477a00$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3QdVONlit0YShhpoywLcCiYrG88 Cc: i2rs@ietf.org, edc@google.com, lhotka@nic.cz, shares@ndzh.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 18:58:00 -0000 t.petch wrote: > Is it, though, the right approach for I2RS? I see the rationale of I2RS > as being able to take a holistic view of the routing system, not one > based on where the information is coming from (a view that may make > sense when building boxes or installing them). > > Rather, I am minded of problems I have been called upon to resolve which > are the result of misconfiguration, misconfiguration which is not > apparent because the integrated view of what is controlling the box is > not available. For example, a static route is inserted to circumvent a > quirk of topology, the quirk is fixed but the static route is not > removed, the topology changes again and that static route becomes a > liability. Being able to see everything at once makes the problem > apparent, looking for a configuration error or a BGP error separately is > fruitless. > > My sense is that I2RS needs an integrated view whereas NETCONF/YANG > focus on the configuration (as their RFC explicitly state). YANG is a > good start, but as Andy said at IETF89, not enough. I am not sure I what you mean by "integrated view". One reason for separating config from operational state is to make sure the view of operational state is exactly what is really currently in use. So if a static route has been configured, and it really is in use, it will show up in the operational state (marked as being a static route). Isn't the "integrated view" the complete operational state? If not, how is it different? /martin From nobody Thu Apr 24 13:03:23 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05F1A03C6 for ; Thu, 24 Apr 2014 13:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTLn2KyCMAnm for ; Thu, 24 Apr 2014 13:03:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1161A038E for ; Thu, 24 Apr 2014 13:03:16 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 20:03:07 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.20]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.20]) with mapi id 15.00.0929.001; Thu, 24 Apr 2014 20:03:07 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model Thread-Index: AQHPX6gAN4nxTXmJ50qCjM9BhMCPLpsgwwyAgAADEYCAAAM6AIAABJaAgABjK4A= Date: Thu, 24 Apr 2014 20:03:06 +0000 Message-ID: References: <535916F0.3050206@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(479174003)(24454002)(377454003)(51704005)(51694002)(189002)(199002)(66066001)(46102001)(99396002)(50226001)(19580405001)(77156001)(83072002)(81542001)(4396001)(83322001)(85852003)(62966002)(81342001)(19580395003)(99286001)(74662001)(20776003)(74502001)(83716003)(80976001)(50986999)(86362001)(57306001)(15975445006)(36756003)(79102001)(76176999)(80022001)(76482001)(2656002)(92566001)(33656001)(82746002)(87936001)(89996001)(31966008)(87286001)(77982001)(92726001)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:F6F4F5E7.AAF6D1E3.F2DDBF8B.42E8C849.20482; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <99205C642D62B04FB35E70A3210FE8E9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YzaSjPu8oLWcY03kwyFgQKkz01U Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 20:03:20 -0000 On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wrote: > I was more looking at the agent - it brokers between clients and the > RIB subsystem > as shown in figure 1 of the architecture doc. Different clients bring > different latencies/capacities. > Congestions will kick in, how does client latency influence agent? The agent sees request coming in f= rom different authorized clients at a rate and it is processing those reque= sts. The agent will depend on the daemon performance, but not on client. > reliability requirements will need to be > considered. And there may > be need to signal these details to the clients (SIP proxying is the > closest i can think of). > You cant solve this problem by just inserting a reliable transport > where the i2rs protocol > runs. >=20 > cheers, > jamal >=20 > On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wr= ote: >> No, there is no requirement that the client is a broker. He may be, or = he >> may not. And the scope of his brokering, if he is a broker, may be >> application specific or more general. >>=20 >> We have placed requirements to be able to provide traceability when the >> client is brokering. This is as much because even a non-broker may be >> acting on behalf of several different applications. >>=20 >> As far as I can tell, the fact that a client may itneract with multiple >> agents does not in itself palce new protocol or model requirements on th= e >> system. If we wanted inter-agent atomicity, then there would be >> requirements. But we explicitly decided that was out of scope. >>=20 >> Yours, >> Joel >>=20 >>=20 >> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>=20 >>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrot= e: >>>>=20 >>>>=20 >>>>=20 >>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>> across N locked I2RS agents? >>>>=20 >>>=20 >>> There is a requirement to allow only one client to own write access to >>> a specified object in order to avoid locking. There is nothing objectin= g >>> to a client being able to write to multiple objects as long as that rul= e >>> is met. >>>=20 >>>> The agents do not coordinate with each other. >>>> The clients do not coordinate with each other. >>>>=20 >>>> This is currently out of scope for the I2RS protocol. >>>>=20 >>>=20 >>> Both assertions true. >>> But what i was responding to is: >>> There are multiple clients that connect to the same agent. >>> And a client can connect to multiple agents. >>>=20 >>> I believe that such a requirement _may_ call out certain features in >>> the protocol. Essentially the agent is a broker. >>>=20 >>> cheers, >>> jamal >>>=20 >>>>> cheers, >>>>> jamal >>>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>>=20 >>>>>=20 >>>>> ---------- Forwarded message ---------- >>>>> From: Jamal Hadi Salim >>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>> To: Dean Bogdanovic >>>>> Cc: Andy Bierman , "" >>>>> , Martin Bjorklund , "= " >>>>> , "" >>>>>=20 >>>>>=20 >>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote= : >>>>>>=20 >>>>>=20 >>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>>=20 >>>>>=20 >>>>> Dont think so. >>>>>=20 >>>>>> Network locking across devices is out of scope. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I have same opinion as you on this one, just wanted to spell it out = one >>>>>> more >>>>>> time explicitly, as I heard some discussions where network locking w= as >>>>>> coming up. >>>>>>=20 >>>>>=20 >>>>> Either I am misunderstanding both of you or both of you misunderstood >>>>> the >>>>> requirement. >>>>> The idea is to allow a single writer per object as a starting point. >>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>=20 >>>>> cheers, >>>>> jamal >>>>>=20 >>>>> PS:- Changing the topic so this is not lost in the noise because i th= ink >>>>> that >>>>> the many clients-single agent brings needs for other protocol >>>>> requirements. >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Apr 24 18:56:51 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A31A03BF for ; Thu, 24 Apr 2014 18:56: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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOPZzbhll5CY for ; Thu, 24 Apr 2014 18:56:47 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3BA1A03BE for ; Thu, 24 Apr 2014 18:56:47 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so4061253vcb.1 for ; Thu, 24 Apr 2014 18:56:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M7juLtm+ehFajpCvNMk627Ppg3Bf7Vht/QF+R5SVXqw=; b=EDA6xJRWBRIPqub1ZXoVx2goqFoxGRcJHyyZqwlP2CU8JhyH71q6dpNPTrrnGrnlK+ KNE1Wo6HE2kxFfQR34s/NRcgLVwXSiH31ceuK37MiSXCDAIgMU6mpZ5T1HMXqnmxgrQL pqvFNlK0+VZkd+zAsS941NE1BuvP9vW6wFtbNuRg0pZjL2ES2Be7SU6h6kA2Wl6s2ZU/ v5toN1cB/TP1fyVTK5mLs/pSvzjy/ncTYMDJI/s5R6pE358WP8WDCk67eXlvsW1cNBNg OQCZxDFHEafmne5XLgVhO8BIXPx4iINsgECYqVFrexUiEApKv3Ozf8z3mQOhBBzXrC7f z4ZQ== X-Gm-Message-State: ALoCoQksZWE/RDizN+DG8wBRoFiA65nPEoTRlvHIJ314SGeQ3j1Bp661xH6j0X88k491V6IRtyCn X-Received: by 10.58.55.170 with SMTP id t10mr3944587vep.29.1398391000717; Thu, 24 Apr 2014 18:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 18:56:20 -0700 (PDT) In-Reply-To: References: <535916F0.3050206@joelhalpern.com> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 21:56:20 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/l0w64b804B6Ia7lCTKgkMJrcmQs Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 01:56:49 -0000 I was mostly referring to overload conditions (of both compute and wire resources). It is feasible for a client not to be able to keep up (eg a table dump response; i.e a single request resulting in a large fast bulk response). However, the more interesting case is for a daemon overload as a result of some client transaction; assuming possibly N daemons talk to an agent on the south bound multiplexing to M clients on the northbound, where M>>N - and how to deal with the client(s) that are responsible for the overload without adversely affecting the other clients that dont contribute to overload. Some of this could be implementation issues. I think l misunderstood what you and Andy were saying to imply you meant M equals N equals 1. cheers, jamal On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic wrote: > > On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wrote: > >> I was more looking at the agent - it brokers between clients and the >> RIB subsystem >> as shown in figure 1 of the architecture doc. Different clients bring >> different latencies/capacities. >> Congestions will kick in, > how does client latency influence agent? The agent sees request coming in from different authorized clients at a rate and it is processing those requests. The agent will depend on the daemon performance, but not on client. > >> reliability requirements will need to be >> considered. And there may >> be need to signal these details to the clients (SIP proxying is the >> closest i can think of). >> You cant solve this problem by just inserting a reliable transport >> where the i2rs protocol >> runs. >> >> cheers, >> jamal >> >> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wrote: >>> No, there is no requirement that the client is a broker. He may be, or he >>> may not. And the scope of his brokering, if he is a broker, may be >>> application specific or more general. >>> >>> We have placed requirements to be able to provide traceability when the >>> client is brokering. This is as much because even a non-broker may be >>> acting on behalf of several different applications. >>> >>> As far as I can tell, the fact that a client may itneract with multiple >>> agents does not in itself palce new protocol or model requirements on the >>> system. If we wanted inter-agent atomicity, then there would be >>> requirements. But we explicitly decided that was out of scope. >>> >>> Yours, >>> Joel >>> >>> >>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>> >>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>>> across N locked I2RS agents? >>>>> >>>> >>>> There is a requirement to allow only one client to own write access to >>>> a specified object in order to avoid locking. There is nothing objecting >>>> to a client being able to write to multiple objects as long as that rule >>>> is met. >>>> >>>>> The agents do not coordinate with each other. >>>>> The clients do not coordinate with each other. >>>>> >>>>> This is currently out of scope for the I2RS protocol. >>>>> >>>> >>>> Both assertions true. >>>> But what i was responding to is: >>>> There are multiple clients that connect to the same agent. >>>> And a client can connect to multiple agents. >>>> >>>> I believe that such a requirement _may_ call out certain features in >>>> the protocol. Essentially the agent is a broker. >>>> >>>> cheers, >>>> jamal >>>> >>>>>> cheers, >>>>>> jamal >>>>> >>>>> >>>>> >>>>> Andy >>>>> >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Jamal Hadi Salim >>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>> To: Dean Bogdanovic >>>>>> Cc: Andy Bierman , "" >>>>>> , Martin Bjorklund , "" >>>>>> , "" >>>>>> >>>>>> >>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: >>>>>>> >>>>>> >>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>>> >>>>>> >>>>>> Dont think so. >>>>>> >>>>>>> Network locking across devices is out of scope. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have same opinion as you on this one, just wanted to spell it out one >>>>>>> more >>>>>>> time explicitly, as I heard some discussions where network locking was >>>>>>> coming up. >>>>>>> >>>>>> >>>>>> Either I am misunderstanding both of you or both of you misunderstood >>>>>> the >>>>>> requirement. >>>>>> The idea is to allow a single writer per object as a starting point. >>>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>> PS:- Changing the topic so this is not lost in the noise because i think >>>>>> that >>>>>> the many clients-single agent brings needs for other protocol >>>>>> requirements. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Fri Apr 25 06:46:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9F01A04C8 for ; Fri, 25 Apr 2014 06:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy3ocdLQqh_9 for ; Fri, 25 Apr 2014 06:46:47 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7511A01DF for ; Fri, 25 Apr 2014 06:46:47 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:64838 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WdgSW-0003pv-Lk for i2rs@ietf.org; Fri, 25 Apr 2014 13:46:32 +0000 From: "Russ White" To: Date: Fri, 25 Apr 2014 09:46:28 -0400 Message-ID: <03a901cf608c$c2a90b20$47fb2160$@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: Ac9gjLc8zv7omGMWS7W+RA9X8f3OOQ== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/XFl0bSwudR5nckRrOWDkW_2jw98 Subject: [i2rs] Thoughts on draft-bitar-i2rs-service-chaining-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 13:46:49 -0000 Some thoughts on draft-bitar-i2rs-service-chaining-01... == This document describes use cases and I2RS (Information to the Rousting System) requirements for the discovery and maintenance of services topology and resources. == Rousting/Routing == Several networking scenarios involve applying a set of services to a packet or flow. For instance, when a host in a protected zone initiates a session to a server outside the zone, the session may be directed to a chain of a Wide Area Network (WAN) application acceleration service, a network address and port translation (NAPT) service, and a firewall. On the server side, another set of services may also be applied. Such a sequence of services applied to a packet or flow is referred to as a service chain. Services in the chain may include deep packet inspection (DPI), load-balancing, firewalling, intrusion prevention, and routing among others. == I found this paragraph confusing... Maybe something more like: Several network designs require flows to be processed through a set of services located in different locations. For instance, when a host in a protected zone initiates a session to a server outside that protected zone, the flow might need to pass through an application acceleration service, a network address translation service, and a stateful (or deep packet) inspection service. The corresponding flow from the server to the initiating host might be required to pass through another set of services, such as load balancing, stateful inspection, and intrusion prevention. == The tuple (service node IP address, hosting system IP address). This applies when there is need to identify the system hosting the service node or when the service node IP address is only reachable within the hosting system. == "there is need" should be "there is a need" I'm not certain about the two IP addresses here. Which "hosting system IP address?" Do you mean the address of the hypervisor, or the physical interface (if it has one), or... ?? This might need clarification. == For each service node, virtual context and service type, the following information may be specified, depending on the service resource requirement. That is, some of the information listed here may not be relevant for some services. == You might want to add stretch and utilization (both network and per link) here. Both of these are impacted by/rely on traffic engineering. == The following is a set of parameters that needs be monitored per service node per virtual context, and per service type as applicable. It should be noted that some services may not require all the parameters listed here to be monitored. == For which section of the network? The smallest link between the source and the destination, the link between the service and the default gateway, or first hop device (router or switch), the bandwidth of the fabric, etc. ... ? I think this probably needs some clarification. == Service Chaining via BGP-based Redirection == I'm really confused by this section. Why should BGP flow spec be specifically called out here? Either cover all of the different options (flowspec, YANG, etc.), or justify including one and not the others, I think. HTH :-) Russ From zaccantte@gmail.com Fri Apr 25 12:15:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6661A02F2 for ; Fri, 25 Apr 2014 12:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXOKHGUjjddQ for ; Fri, 25 Apr 2014 12:15:12 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id CAE6A1A065D for ; Fri, 25 Apr 2014 12:15:11 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so5195285vcb.7 for ; Fri, 25 Apr 2014 12:15:05 -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=4cFomMuLdTy6ckYh9UskYbUxyRqsWkvYROO9biyGGyY=; b=WgFfxumxDl0vevbFvJVeGls/EiSHB+N2VOQbgeaDX2950s+W1lLedIoo6tgDBCWKsz TYMph0vnHWVUwrr9L82KKfqfdo3Yw3CwdADmT7wUw7NzT+2DZyj2BKCtCjH7x2TDHi5W 0NKkxsLb7Ax0O2HY9vLfPQ3rECoi5R92UW97p3BR6404TJlEwOdlDx5NWnCbKHU+Ys9n ORuKc6W2O/BGRI8jm1WXx/srXqQ8hLqinsTKte22Zj+lHMhfWshd1H3kLBN9OFDfZ2si 110MjEQB1Og0QYeFgiU17McNntZ35+p4EOSdYL5a7GwPDqzYj22Ip3tD5PToPIPdOfu8 o0+A== MIME-Version: 1.0 X-Received: by 10.52.189.193 with SMTP id gk1mr6802616vdc.12.1398453305171; Fri, 25 Apr 2014 12:15:05 -0700 (PDT) Received: by 10.221.19.129 with HTTP; Fri, 25 Apr 2014 12:15:05 -0700 (PDT) Date: Fri, 25 Apr 2014 16:15:05 -0300 Message-ID: From: FABIO ZACCANTTE To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=001a1133fd5c7d68a204f7e2c864 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PXyr5wm64kuxcQKrCrVt9TJ7msw Subject: [i2rs] Interface to the routing system (I2RS) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 19:23:49 -0000 --001a1133fd5c7d68a204f7e2c864 Content-Type: text/plain; charset=UTF-8 Hi I am start studying the interface to the routing system (I2RS) but I can not find any video on this subject and neither figure that demonstrates the relationship in the router with I2RS in OpenFlow. Someone will can help me with any video or picture tips. regards, Fabio --001a1133fd5c7d68a204f7e2c864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

I am start studying the i= nterface to the routing system (I2RS) but I can not find any video on this = subject and neither figure that demonstrates the relationship in the router= with I2RS in OpenFlow.=C2=A0

Someone will can help me with any video or picture tips= .

regards,=C2=A0
Fabio
--001a1133fd5c7d68a204f7e2c864-- From nobody Mon Apr 28 13:24:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF981A702F for ; Mon, 28 Apr 2014 13:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tlTxrjQbkhJ for ; Mon, 28 Apr 2014 13:24:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9EF1A6FE7 for ; Mon, 28 Apr 2014 13:24:00 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 28 Apr 2014 20:23:58 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.20]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.113]) with mapi id 15.00.0929.001; Mon, 28 Apr 2014 20:23:58 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model Thread-Index: AQHPX6gAN4nxTXmJ50qCjM9BhMCPLpsgwwyAgAADEYCAAAM6AIAABJaAgABjK4CAAGKyAIAF7HOA Date: Mon, 28 Apr 2014 20:23:57 +0000 Message-ID: <55AA400B-3D5A-4980-8330-3541A1663586@juniper.net> References: <535916F0.3050206@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 01952C6E96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(377454003)(479174003)(51704005)(51694002)(199002)(189002)(83322001)(2656002)(19580395003)(87936001)(82746002)(77156001)(80022001)(88136002)(19580405001)(551934002)(83716003)(20776003)(101416001)(4396001)(15975445006)(99286001)(87286001)(33656001)(89996001)(46102001)(99396002)(74502001)(31966008)(92726001)(76176999)(80976001)(86362001)(81342001)(79102001)(62966002)(36756003)(50986999)(66066001)(77982001)(92566001)(81542001)(50226001)(93916002)(57306001)(74662001)(76482001)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:F6F4F5E4.AAF6D1C3.F2DDBF8B.42E9C849.20548; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mLOdGDo-4eKt8_fxXTMJsz1ufqk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 20:24:06 -0000 Jamal, There is only one agent to one daemon. There is no scenario of one agent to= multiple daemons. There are multiple clients to one agent. So agent is depending on the speed of daemon and agent should protect overl= oading daemon with requests, so it can police requests from clients. Dean On Apr 24, 2014, at 9:56 PM, Jamal Hadi Salim wrote: > I was mostly referring to overload conditions (of both compute and > wire resources). > It is feasible for a client not to be able to keep up (eg a table dump > response; i.e a single > request resulting in a large fast bulk response). However, > the more interesting case is for a daemon overload as a result of some > client transaction; > assuming possibly N daemons talk to an agent on the south bound > multiplexing to M clients > on the northbound, where M>>N - and how to deal with the client(s) > that are responsible for the > overload without adversely affecting the other clients that dont > contribute to overload. > Some of this could be implementation issues. >=20 > I think l misunderstood what you and Andy were saying to imply you > meant M equals N equals 1. >=20 > cheers, > jamal >=20 >=20 > On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic wrot= e: >>=20 >> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wrote= : >>=20 >>> I was more looking at the agent - it brokers between clients and the >>> RIB subsystem >>> as shown in figure 1 of the architecture doc. Different clients bring >>> different latencies/capacities. >>> Congestions will kick in, >> how does client latency influence agent? The agent sees request coming i= n from different authorized clients at a rate and it is processing those re= quests. The agent will depend on the daemon performance, but not on client. >>=20 >>> reliability requirements will need to be >>> considered. And there may >>> be need to signal these details to the clients (SIP proxying is the >>> closest i can think of). >>> You cant solve this problem by just inserting a reliable transport >>> where the i2rs protocol >>> runs. >>>=20 >>> cheers, >>> jamal >>>=20 >>> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern = wrote: >>>> No, there is no requirement that the client is a broker. He may be, o= r he >>>> may not. And the scope of his brokering, if he is a broker, may be >>>> application specific or more general. >>>>=20 >>>> We have placed requirements to be able to provide traceability when th= e >>>> client is brokering. This is as much because even a non-broker may be >>>> acting on behalf of several different applications. >>>>=20 >>>> As far as I can tell, the fact that a client may itneract with multipl= e >>>> agents does not in itself palce new protocol or model requirements on = the >>>> system. If we wanted inter-agent atomicity, then there would be >>>> requirements. But we explicitly decided that was out of scope. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>=20 >>>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>>>=20 >>>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wr= ote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>>>> across N locked I2RS agents? >>>>>>=20 >>>>>=20 >>>>> There is a requirement to allow only one client to own write access t= o >>>>> a specified object in order to avoid locking. There is nothing object= ing >>>>> to a client being able to write to multiple objects as long as that r= ule >>>>> is met. >>>>>=20 >>>>>> The agents do not coordinate with each other. >>>>>> The clients do not coordinate with each other. >>>>>>=20 >>>>>> This is currently out of scope for the I2RS protocol. >>>>>>=20 >>>>>=20 >>>>> Both assertions true. >>>>> But what i was responding to is: >>>>> There are multiple clients that connect to the same agent. >>>>> And a client can connect to multiple agents. >>>>>=20 >>>>> I believe that such a requirement _may_ call out certain features in >>>>> the protocol. Essentially the agent is a broker. >>>>>=20 >>>>> cheers, >>>>> jamal >>>>>=20 >>>>>>> cheers, >>>>>>> jamal >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Jamal Hadi Salim >>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>>> To: Dean Bogdanovic >>>>>>> Cc: Andy Bierman , "" >>>>>>> , Martin Bjorklund , "" >>>>>>> , "" >>>>>>>=20 >>>>>>>=20 >>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wro= te: >>>>>>>>=20 >>>>>>>=20 >>>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>>>>=20 >>>>>>>=20 >>>>>>> Dont think so. >>>>>>>=20 >>>>>>>> Network locking across devices is out of scope. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I have same opinion as you on this one, just wanted to spell it ou= t one >>>>>>>> more >>>>>>>> time explicitly, as I heard some discussions where network locking= was >>>>>>>> coming up. >>>>>>>>=20 >>>>>>>=20 >>>>>>> Either I am misunderstanding both of you or both of you misundersto= od >>>>>>> the >>>>>>> requirement. >>>>>>> The idea is to allow a single writer per object as a starting point= . >>>>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>>>=20 >>>>>>> cheers, >>>>>>> jamal >>>>>>>=20 >>>>>>> PS:- Changing the topic so this is not lost in the noise because i = think >>>>>>> that >>>>>>> the many clients-single agent brings needs for other protocol >>>>>>> requirements. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> i2rs mailing list >>>>>>> i2rs@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 From nobody Mon Apr 28 15:30:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C5B1A885A for ; Mon, 28 Apr 2014 15:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsxeB_xmerso for ; Mon, 28 Apr 2014 15:30:38 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E45521A8852 for ; Mon, 28 Apr 2014 15:30:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Mon, 28 Apr 2014 18:30:26 -0400 Message-ID: <000601cf6331$74424080$5cc6c180$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CF630F.ED329C50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9jLld/Jvp+XOrGRn+mTxUo61geqw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UYRn1gV7I7CcU2ZTHcXpz2zxJGY Cc: 'Jeffrey Haas' , 'adrian' , Alia Atlas , Edward Crabbe Subject: [i2rs] RIB information model - replacing RBNF with UML and RBNF X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 22:30:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CF630F.ED329C50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01CF630F.ED32C360" ------=_NextPart_001_0008_01CF630F.ED32C360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: I have attached a revision to the RIB info-model that replaces RBNF with UML and yang topology drafts. I am hoping to have a discussion of the UML with an approved draft before launching the UML/Yang topology models for the PBR and BGP drafts. This was posted ~1 weeks ago, but the chairs suggest this go on another list rather than the yang/forces discussion. To enforce this, the files were not sent to the general i2rs list. Some people were directly copied so a brief discussion occurred on list. Hopefully, under this new header all the files will be forwarded for discussions. This document inherits the yang data trees (as pseudo informational models from) the following locations as ietf-netmod-routing-cfg-13 has this chart that indicates +--------+---------------------------+-----------+ | Prefix | YANG module | Reference | +--------+---------------------------+-----------+ | if | ietf-interfaces | [YANG-IF ] | | | | | | ip | ietf-ip | [YANG-IP ] | | | | | | rt | ietf-routing | Section 7 | | | | | | v4ur | ietf-ipv4-unicast-routing | Section 8 | | | | | | v6ur | ietf-ipv6-unicast-routing | Section 9 | | | | | | yang | ietf-yang-types | [RFC6991 ] | | | | | | inet | ietf-inet-types | [RFC6991 ] | +--------+---------------------------+-----------+ Table 1: Prefixes and corresponding YANG modules What changes did I make to the RIB section: 1)Revised RIB Grammar in RBNF (section 6.1) 2)(section 6.2) Spot for the pdf graphic attached as draft-hares-i2rs-info-rib-only-v7.pdf 3)(section 6.3) Yang tree structure (per yang documents) 4)Revised Usage - using simplified grammar Basically: Basically the complex RIB-info RBNF grammar boils down to very few simply statement. The Yang Tree does not provide an easy way to design/debug redundancy. I think that the use of the UML tools that create the Yang modules/Yang Tree structures could speed time to market on the designs. For example, all the I2RS RIB is simply 5 power-point slides, that then can be generated into Yang module. This seems the normal progression of the process you started with the Yang-modules. CAVEATS: 1)For all mistakes on the UML and diagrams blame me - this was the first pass on the UML. 2) Some of the redundancies could have been fixed in other ways 3) I did Yang modules to demonstrate proof of concept 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES Chair's /AD opinion: 1) Jeff is in favor of UML to improve the data model language 2) Ed Crabbe states he does not think informational models are useful - why not go to the data modeling direct. 3) Adrian and Alia encouraged me to look at UML I'm in favor of Information models that can quickly express the concepts to operators AND that can be used to generate code. UML-2.0 tools are out there for to/from yang models, and yang to/from code. Seems like a no-brainer tome to discuss 6 slides for the RIB info rather than the RBNF. What do you think? Sue Hares ------=_NextPart_001_0008_01CF630F.ED32C360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all:

 

I have attached a revision to the RIB info-model that = replaces RBNF with UML and yang topology drafts.  I am hoping to = have a discussion of the UML with an approved draft before launching the = UML/Yang topology models for the PBR and BGP drafts.

 

This was = posted ~1 weeks ago, but the chairs suggest this go on another list = rather than the yang/forces discussion. To enforce this, the files were = not sent to the general i2rs list.  Some people were directly = copied so a brief discussion occurred on list. Hopefully, under this new = header all the files will be forwarded for discussions. =

 

This document inherits the yang data trees (as pseudo = informational models from)  the following locations as = 

 
ietf-netmod-routing-cfg-13 has this chart that indicates = 
 
 =
  +--------+---------------------------+-----------+=

   | Prefix | YANG =
module           &=
nbsp;   | Reference |
  =
 +--------+---------------------------+-----------+
   | if     | =
ietf-interfaces =
          | [YANG-IF] |
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | ip     | =
ietf-ip           =
        | [YANG-IP] |
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | rt     | =
ietf-routing          &=
nbsp;   | Section 7 =
|
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | v4ur   | =
ietf-ipv4-unicast-routing | Section 8 |
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | v6ur   | =
ietf-ipv6-unicast-routing | Section 9 |
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | yang   | =
ietf-yang-types         &nbs=
p; | [RFC6991] =
|
   =
|        =
|            =
            &=
nbsp;  =
|           =
|
   | inet   | =
ietf-inet-types         &nbs=
p; | [RFC6991] =
|
   =
+--------+---------------------------+-----------+
 
        &nb=
sp;    Table 1: Prefixes and corresponding YANG =
modules
 
 
What changes =
did I make to the RIB section: 
 
 =
1)Revised RIB Grammar in RBNF (section 6.1)
 2)(section 6.2) Spot for the pdf graphic attached =
as 
    draft-hares-i2rs-info-rib-on=
ly-v7.pdf
 3)(section 6.3) Yang =
tree structure (per yang documents)
 
 =
4)Revised Usage – using simplified grammar
 
Basically: 
 
 =
Basically the complex RIB-info RBNF grammar boils down to very few =
simply 
 statement.  The =
Yang Tree does not provide an easy way to design/debug 
 redundancy. I think that the use of the UML =
tools that create the Yang 
 modules/Yang Tree structures could speed time =
to market on the designs.
For =
example, all the I2RS RIB is simply 5 power-point slides, that =

then can be generated into Yang =
module.  This seems the normal 
progression of the process you started with the =
Yang-modules.
 
 =
CAVEATS:
 
 1)For all mistakes on the UML and diagrams blame =
me – this was the first pass on the UML.  
 2) Some of the redundancies could have been =
fixed in other ways
 3) I did Yang =
modules to demonstrate proof of concept
 4) I suspect with Jamal and Joel Halpern’s =
help (FoRCES gurus).. FoRCES 
 
Chair’s /AD opinion: 
1)      =
Jeff is in favor of UML to improve the data =
model language 
2)      =
Ed Crabbe states he does not think informational =
models are useful – why not go to the data modeling direct. =

3)      =
Adrian and Alia encouraged me to look at UML =

 
I’m in favor of Information models that can =
quickly express the concepts to operators AND that can be used to =
generate code.   UML-2.0 tools are out there for to/from yang =
models, and yang to/from code.   Seems like a no-brainer tome =
to discuss 6 slides for the RIB info rather than the RBNF. =

 
What do you think?  
 
 
 Sue =
Hares
 
------=_NextPart_001_0008_01CF630F.ED32C360-- ------=_NextPart_000_0007_01CF630F.ED329C50 Content-Type: application/pdf; name="draft-hares-i2rs-info-rib-only-v7.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-hares-i2rs-info-rib-only-v7.pdf" JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwvQ3JlYXRpb25EYXRlIChEOjIwMTQwNDIzMTQxMzI2 WikvTW9kRGF0ZSAoRDoyMDE0MDQyMzE0MTMyNVowMCcwMCcpL1Byb2R1Y2VyIChQREYgQ29tcGxl dGUgMy41LjMxMC4yMDAyKS9UaXRsZSAoTWljcm9zb2Z0IFBvd2VyUG9pbnQgLSBkcmFmdC1oYXJl cy1pMnJzLWluZm8tcmliLW9ubHktdjcucHB0eCk+Pg1lbmRvYmoNMiAwIG9iag08PC9QYWdlcyA0 OSAwIFIvVHlwZSAvQ2F0YWxvZy9WZXJzaW9uIC8xLjQ+Pg1lbmRvYmoNMyAwIG9iag08PC9Db3Vu dCA1L0tpZHMgWzQgMCBSIDE4IDAgUiAyMSAwIFIgMjQgMCBSIDI3IDAgUl0vUGFyZW50IDQ5IDAg Ui9UeXBlIC9QYWdlcz4+DWVuZG9iag00IDAgb2JqDTw8L0NvbnRlbnRzIDE3IDAgUi9NZWRpYUJv eCBbMCAwIDc5MiA2MTJdL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgPDwvRm9udCAxMyAwIFIvUHJv Y1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4N ZW5kb2JqDTUgMCBvYmoNPDwvQmFzZUZvbnQgL0NhbGlicmkvRW5jb2RpbmcgL1dpbkFuc2lFbmNv ZGluZy9GaXJzdENoYXIgMC9Gb250RGVzY3JpcHRvciA2IDAgUi9MYXN0Q2hhciAyNTUvU3VidHlw ZSAvVHJ1ZVR5cGUvVHlwZSAvRm9udC9XaWR0aHMgWzAgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgMCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyMjYgMzI2IDQwMSA0OTgg NTA3IDcxNSA2ODIgMjIxIDMwMyAzMDMgNDk4IDQ5OCAyNDkgMzA3IDI1MyAzODYgNTA3IDUwNiA1 MDgKNTA3IDUwNyA1MDcgNTA3IDUwNiA1MDYgNTA3IDI2OCAyNjggNDk4IDQ5OCA0OTggNDYzIDg5 NCA1NzkgNTQzIDUzMyA2MTUgNDg4IDQ1OSA2MzAgNjIzIDI1MiAzMTkgNTE5IDQyMCA4NTUgNjQ1 IDY2MiA1MTYgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgODkwIDUxOSA0ODcgNDY4IDMwNiAzODYg MzA2IDQ5OCA0OTggMjkxIDQ3OSA1MjUgNDIzIDUyNQo0OTggMzA1IDQ3MSA1MjYgMjMwIDIzOSA0 NTUgMjMwIDc5OSA1MjYgNTI3IDUyNSA1MjUgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1 MyAzOTUgMzE1IDQ2MCAzMTUgNDk4IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDIyNiAzMjYgNDk4IDUwNyA0 OTggNTA3IDQ5OCA0OTggMzkzIDgzNCA0MDIgNTEyIDQ5OCAzMDcgNTA3IDM5NCAzMzkgNDk4IDMz NiAzMzQgMjkyIDU1MCA1ODYgMjUyIDMwNyAyNDYgNDIyIDUxMiA2MzYgNjcxIDY3NSA0NjMgNTc5 IDU3OSA1NzkgNTc5IDU3OSA1NzkgNzYzIDUzMyA0ODgKNDg4IDQ4OCA0ODggMjUyIDI1MiAyNTIg MjUyIDYyNSA2NDYgNjYyIDY2MiA2NjIgNjYyIDY2MiA0OTggNjY0IDY0MiA2NDIgNjQyIDY0MiA0 ODcgNTE3IDUyNyA0NzkgNDc5IDQ3OSA0NzkgNDc5IDQ3OSA3NzMgNDIzIDQ5OCA0OTggNDk4IDQ5 OCAyMzAgMjMwIDIzMCAyMzAgNTI1IDUyNSA1MjcgNTI3IDUyNyA1MjcgNTI3IDQ5OCA1MjkgNTI1 IDUyNQo1MjUgNTI1IDQ1MyA1MjUgNDUzXT4+DWVuZG9iag02IDAgb2JqDTw8L0FzY2VudCA3NTAv QXZnV2lkdGggNDg1LjIwMy9DYXBIZWlnaHQgNjM4L0Rlc2NlbnQgLTI1MC9GbGFncyAzMi9Gb250 QkJveCBbLTUwMiAtMzA3IDEyNDAgOTYzXS9Gb250RmlsZTIgNyAwIFIvRm9udE5hbWUgL0NhbGli cmkvSXRhbGljQW5nbGUgMC9NYXhXaWR0aCA4OTQvU3RlbVYgODEvVHlwZSAvRm9udERlc2NyaXB0 b3I+Pg1lbmRvYmoNNyAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMTIwNC9M ZW5ndGgxIDc2Nzc2Pj4Nc3RyZWFtCnic7Lx3fFTH1T88c8vc3du2d+3uXa12V9Kq94a0qIAqIIki AQLRe68GjDHgBu7GBXfHibEdF9EFuOCEuCU42HFJ4thxSWLiBMd2EnetfjN370oC4+f3vO/71/v5 eMXeKbfsnO+cc+aUuQAIABDBNkCD2Jxls1Yy9fmLcM9vAEj7YM76tUrfXadeAyDUBwCbMn/lgmVf fNEmApCJz+vdC5ZeMl/35TO7ACg8C0DrmYXzZs3957sF7wOwrR8/o2Qh7pAeN8/D7U9xO23hsrUb O/KOfQjA5VYAqvYsXTFnFqNjxgHw9MO4ffeyWRtXBsaGQwB8U4+vV5bPWjYv8+fh23F7LgBS58oV a9YOesCVAHLk+crK1fNWLnmSiuP27/HjjbiP1r4pgNAFTJtwC9csOwFjmqHStQ0g0IprEthKLaSe pFfQ6+it9C76WvoB+hXmStYi13if9b7su8t3r+9rv83v9Tf42/xT/N3+af4e/6X+Q/5T/t/53/b/ y/8ff1wxKqlKWMlTipQKpVqpV2Yqq5TrlT3KYeW48k6ADVgCjoASSA2EAzmBgsC4wMzAzsDewMOp VCpKNaSaU22p7lR/akZqNLUxdVbqvCAVNAYDaWvS/hMCISokhowha8gZeiD089BvQr8N/S1yWdbS rA05jn3ufYFvmXgwPjg4SOjE1CjgfmoR1UevpTfROzE119MP0meYqzE1wHvSG8fU3O8Hfqdf8Tf6 J2jUzPRv8x/xP+9/0/+O/3P/FwpQzJiaXKVAKVeqMDUzlJXKWuVG5X6lX6PGPoKatkBnYEfgxiFq TJgaV6pPo6Y3da5KjZLWm/Zx2uB51DwaelmlZn1Wb9ZaTI1jn/ItiCsqNXDwv4Qg9i0ABnNILd4P tM/g0n9cRcpPd4IRn39cgf+2g4t8PiwE4Jz+wyiu/eVcO+n5+40AfLLkn/d90PdhGQAfbP/gsg+j H6b8dVLyjn/CD1o+aP4Ac98/7lGfnftB8P1vAXj/w4+7Pm75uOrjB0nv2Z6zE8+2nx13tuWs5awA wEdnP3otcf+fM+bQs+MAGH4iv5DgQPAixKNlzQCg69Ft+Hg/ep5L0V1NTunv1D8BAP834Q7hF8Jv RLuoJJ4ipotzxd+IZyVKEqU8qUiqlwj/qzRK2xJH0pIOJcctvTlMtfSKdEY6K3081P4P+UpfaK3P R1z5sRQ/H7HEWelzmZFTEj3JEtB0M307fZR+mCmn76BvwzJzGX09M4qeRK+mu+il9D/pc/Qn9L/o T+nP6M/pf9P/of9LT6EnM/XMaKaBbqPvAgwwATNwYtkMgwjIArmgAlSBalAPGkALmAK6wVQwA8wF C8EasBZcAjaBy+ht9Er6cnoPvQmegxQ0QCN0Qx9MhxPgVNgDF8GlcAVcB9fDS+E1cDe8Ft4I74SH 4Un4HHwevgB/Q2+nl9M76Fvx6FvoR+nH6J/SROJvojj6XniGXsg04dHfT0n0g8wY+iv6a/g500Hf TG+hMukv4av0IiaLyWQK6HGAxVqDAzqgx7rSABzAC3zADwIgD+SDAlAEPKARa5U2MA6MBxOYGjAR LAKLwRKwDGwBXfAOSEMGshBBDvJQgjbohwoMwCCcAWfCXjgbeuElcCu8DG6Dl8PtTAxeCY/Ao7Af HocvwV3w14CHOiBAPZChCCzQBKzQDOzQCmzQAlzQA9wwBaTCNBCEIZAGwyAEI0CBqSAdtoMM2AEy YSeIwokgG04DOXA6KISzQDGcA0rgXFAG54FSOB+UwwWgEi4Bo+AyuBzUwJVgNFwNYnAVqINrQS1c A8bADaAJbgJj4Ua4GTTDLaAd7gAdmMM74RVgMrwaTIPXgR54A5gOrwcz4U2gF94MZsM9YBa8hTWy JjAP3gUWwHvAUngMLIcnwAr4FFgJnwar4DNgNXwWbICnwKXwZbAVbIOnwXb4W3A5fAXuRdewv2Nf R7vYN9Bu9k32LXQt+3v2D+wf0XXoevZt9k/sO+y76Ab2z+x76Eb2ffYD9kN0M7oF7WH/wv4V3cr+ jbmJeZb9CN3GnkW3s39nP0Z3sP9A76G97D/Rnew5Zi/zAvsJ+y/2U3QX+xm6m/2c/Te6B92L3mf/ g+5DH6Cb0IfoL+iv6G/sf9kv0P3sl+xX6AH2a/Yb9BP2W/Qg+x36KTuAfsbG0UPsINqHAHoYQfQI otCj6OeIRo8hBj2OWPQEQuhJxKE+pEP7kR4dQDw6iAR0CB1GIpLQESSjo8iAjMiE+oEEBWCEMpgE r0JmdAxZ0HFkRSeQDT2F7Ohp5EDPICd6FrnQSeRGzyEP+gVKQb9EXnQKzIG3gvnwbuRDv0J+9DxS 0AsogF5EqeglFEQvozT0axRCv0FhdBpF0CsoHf0WZaAz6FX0GvodXIxeR2+gTBRFb6IslI3eQr9H OegPKBfloXxUgP6ICtHbqAi9g4rRu6gE/VkX1kV06boMXaYuqsvSZetydLm6PF2+rkBXqCvSFetK dKW6Ml25rkJXqavSjdJV68fqG/VN+mZ9i75V36Yfpx8vVUpV+g59p36ifpJ+sn6KvkvfrZ+qn6af Dr+E3+l7KEk/Qz9T36ufpZ+tn6Ofq5+nn69foF+oX6RfrF9Cmak0ykFlURTl1y/VL9Mv16/Qr9Sv 0q/Wr9Gv1a/Tr9dv4Bme5RHP8Tpez/O8wIu8xMu8gTfyJt7MW3grb+PtvIN38i74Kfwv/IZiKaNc SNmodEqQFcpNpcJBuVgulcvlSnmUXCOPlusoyI5hx8oN8hh5rPSo3CQ3yy1yq9wmj5PHywXyBLld 9lFRKlvukDvlifIkebI8Re6Su+Wp8jR5utzDzmbnsvPZhfJMuVeeJc+W58jz2NXsWna9/KL8LnWP /E95gbxIXiwvkZfKy+WV8mp5DXuFvFZeL2+UN8mb5S3ypfJWeZu8Xd4h75SvlK+Sr5F3y9fK18s3 yjfJt8i3yrfLe+W75Hvk++QH5Afln8n75EfEKfwSfim/jHqAupO6m8qn7qVKqHKqimqmJlDbqTyq gCqkiqhiqpQqoyqoSqqaqqFi1GiqlqqjGqgx1FiqkWqiWqk2ahw1nhpFtVBrqEuoLdQ26hZqNbWW Wk9toDZSm6jN1KXUZdQOaid1BXUldRV1DbWbupa6nrqOuoG6kdpD3UbdTt1BXU7dTO2ibqL28rP5 eXwX381P5ZfzC/gN/HR+Jd/Lr+Wn8Sv4Hn4VP5NfI82VlkjzpKXSfGmZtEBaLi2UVkiLpJXSYmkV P59fyC/m1/Gd/Bx+Lj+LX89P5Gfwq/lF/CR+Mj+Feox6nHqDeph6jfoFdZA6RB2mjlFPUW9SR6kD 1K+ol6mfUj+jHqL2UY9SP6eeoJ6k+qj91BGqnzpOnaCepp6lTlLPUb+kTlEvUC9SL1G/pn5DnaZe oX5LnaFepX5HvU6LtEQbaCNtpe20i3bTHjqFDtBBOkSH6XQ6k86is+lcOp8uoovpErqMLqcr6Eq6 ih5FV9MxejTtoJ10LW2ia+gc2kf7aYVOoyN0HZ1Ke+kCulS6TLqOeouuxxbA9dLl0g3SdulGaYd0 k7RTulm6QrpFulLaQz1DZ1DP04XSVdKt0tXSbdI10u3SLukOabe0V7pWulPaLH8i/0v+TP63dKm0 VZwm3idOF+8Xe8QHqEdoszhD/Ik4U3xQ7BV/Ks4SfybOFh8S54j7sE3ysDhPfEScLz4qLhB/Li4U HxMXiY+Li8UnxCXik+JSsU9cJu4Xl4sHxBXiQXGleEhcJR4WV4tHxDXiUXGt2C+uE9eLx8QN4nFx o3hCvER8StwkPi1uFp8Rt4jPiifFS8XnxK3iL8TLxF+K28RT4uXir8Tt4vPiDvEFcaf4oniF+JJ4 pfiyeJX4a/FqbCNdI54Wd4mviLvF34rXimfE68RXxevF18QbxN+JN4qvizeJb4g3i2+Kt4hviXvE 34u3in8QbxP/KN4uvi3eIf5J3Cu+I94pviveJf5ZvFt8T7xHfF+8V/xA/rn8OPuc/KTcJx+QD8lH 5H75uPyU/LT8LCpFH6EydBaVo7+jCvQxqkT/QFXon2gUOoeq0SeoBv0LxdCnaDT6DNWiz1Ed+jeq R/9BDei/aAz6Ao1FX6JG9BVqQl+jZvQNakHfolb0HWpDA2gcGkTjOYAmcBC1cxTq4GjUyTFoIsei SRxCkzkOTeF0qIvTo26OR1M5AU3jRDSdk1APJ6MZnAHN5IyolzOhWZwZzeYsaA5nRXM5G5rH2dF8 zoEWcE60kHOhRZwbLeY8aAmXgpZyXrSM86HlnB+t4BS0kgugVVwqWs0F0RouDa3lQmgdF0bruQhY B38B1sNfgo3wV2gDl442chnoEi4TbeKiaDOXhbZw2ehSLgdt5XK5PC6fK+AKuSKumFnL/IRZxzzI rGd+ymxgfsZsZB5iLmH2MZuYh5nNzCPMFuZR5lLm58xW5jHmMuZxZhvzBHM58ySzneljdjD7mZ3M AeYK5iBzJXOIuYo5zFzNHGGuYY4yu5h+ZjdzjLmWOc5cx5xgrmeeYm5gnmZuZJ5hbmZOMrcwzzF7 mF8wtzK/ZG5jTjG3M79i7mCeZ+5kXmTuYl5i7mZeZu5hfs3cy/wGbIYvMvcxp5kHmN8y9zOvCJSA BEbQCbTACayg56/id/PX8NfxV/PX8rv46wWP4BO8giKkCH7+Z/zD/D7+Uf4h/hEhKESEkJAhpAnp QljI5B/n9/NP8gf5J/gDfB9/SKgQqoUqISZUCjXCKGE0/xJ/mv81/1v+Zf4V/jf8GaFZaBNahfFC izCOf4P/Pf8W/0f+Tf4PwkShS5gsTBUmCd3CFGEa/74wV1gozBcWC/OERcICYQn/N/5j/iz/T/4j /h/83/lzgiDwQqoQELKEqDBGaBDahQlCrzBTWCYsFYyCVTALdsEk2ASL4OD38Hfwt/F38rfye/nb +buEXKFQyBeKhTyhSCgQSvh+/in+OP8Mf4x/mj/BPyusFNYKq4X1wiphnbBG2MB/xv+X/zf/Jf85 /wX/H/4rQRYkwSUYBKcgCm7+Zv4m/kb+Bv4WcaI4RRwjNoudQpmQI5QK2UI5/xj/c/4If5g/KraK LWKb0CQ0CnVCrTBWqOdf53/Hv8a/Ko4Xx4kThDnCbKFHmC50CJ3CLGEG/1f+L/yH/Af8O2KH2C42 CZcIK4SNwnJhE/8n/m3+X/wn/KdiozhWikjpUoaUKUWlLClbypFysWeVLxVIhdi/ekx6nF4tFWPf eT29USqVyuip9DR6tlROz6Bn0nOkCvoG+kZ6s/QEUyFV0xOkGvoLaT/9Df0t/R09QMfpQQYwkKEY mmHgewzLIIZjdIye4RmBERmJkRkDY2RMjJmxSKOlWqkOe3QN0hhprNQoNUnNUgtzhn5IapXapHHS eGmC1C51SJ3SRPoIfZ80matmokwek83kM4VMMZPDlDC5TBFTypQxGehKbhQzmelipjDdzAxmJjON mcpMZ3qYiUw1vYUZz7RKU5haqdtAGZwGl8Ft8BhSDF6Dz+A3KIaAdFCawUxiXmX10jHpuHRCekp6 WnpGelY6KT1ncKDLuBK0DV2OtnOlXBnawZWjnVwFuoKr5KrQ1VwNF4NRmAPHwjLYAhDFEycRAs3r Hf5AQOE/8qEu5qOfd+X///1MoHqIDuwdNoIJYBn2+mjs92F1jv0+G/b5/KrXNxP7fcTruwR7fFux z7cde31HsceH/T3MaQ+qnupN9Gb6ZngHfT99L/0A/JzimFrseU5kWpkxzFimkX6S6WDa8Dx3UruZ cfAMfJVpx57llfQ4uoVpYsajG5g6ZgK9kF5EdwMa+6867JliD03lccLVmMOZGDMJ+5ZbmXT6IXou PY/MJubzLfRseg5Tgf1dP/Z6A9jXTfi4eap/C7CfSzzbRXA+/BJb25JmeWdSfioLfvdjnO3HONuP cbYf42w/xtl+jLP9GGf7Mc72Y5ztxzjbj3G2H+NsP8bZfoyz/Rhn+zHO9mOc7f9TnA1/uHuxr37L ee7kBOwDrQHb8N+V4DpwC3gWvA1mgx24thfcDx4Cj4A+8Bx4Cbx1Me/9/+0nfgm7DIj0UeyxWQAY /GbwXPwh/O1n5RE9t+CWhVGGewaNg59c0PdJ/JZBY7wfmQGv3itRr+Hef8OBwW+oGtIeLCFt6ipc N6h3fMbdG38yvu8CDNqxXzsNTAc9oBfMwvQTDzfhHS7F/uFytbUcn1uAj/Nxaya+ag6+itSHr1oB VuLvauwZrwPr8d9KXF+jtci5VWp7HdiA/zaq3vNm7Hteqh03qD1b8JlNansj/m4Fl+GZuRxsV2vJ MtGzA+wEV+BZuwpcDa75H1vXDNV2gd3gWjzP14MbfrB+3XmtG/HfTeBmzA97wK3gNnAH5ou7wN0X 9N6u9t8J7gX3YZ4h527FPfepNXL2KfA8OAyeAE+CIyqWczBqCUSSuMxXMVyJMdiCKdwxYsQJ/DYM obUV005o26VRuhH3bx9xx3oNR3LlDnxl4imJeSBPufQCJG7ENCTqwxQlWreq9A/3jkTlf+pN4nH3 CGTuUlukdmHvD9VvA/dgCXwAHwmqpPYTXE/U7lPrI/vvHbr2frX9IPgp+Bmei31qLVkmeh7C9X3g YSzbj4Kfg8fw33B9ZC1RPgEeV2euD+wHB8BBcAjP5BFwFPSr/f/TuYv1H9T6Dwz1HAPHwQnMIc+A k1jT/AL/JXuexn3Par2n1L5E+xfgl7hNrkq0ngcvYA31Mvg1+A34LfgVbr2iHl/ErTPgNfA78BaU cO1V8Hd8HABn2L8AGYwGgD2Ocb4bzAAzYmPnzpzRM33a1O6uSRM7O9onjB/X1trS3NQ4dkxDfV3t 6FhN9aiqyorystKS4tyc7Kz0cCgtmOp3Wk1GgyTweh2HWIamIMhqCI7pVfrCvX1MONjYmE3awVm4 Y9aIjt4+BXeNOf+aPqVXvUw5/8oYvnL+BVfGElfGhq6ERqUKVGVnKQ1Bpe90fVDph1Pbu3D9uvpg t9J3Tq23qXUmrDYk3AgE8B1Kg3NhvdIHe5WGvjHrF+5q6K3Hz9sv8HXBunl8dhbYzwu4KuBaX3pw 5X6YXg3VCpXeULGfAjqJ/GwfHWqYNbdvQntXQ70nEOhW+0Cd+qw+VNfHqc9SFpExg93K/qyTu67t N4LZvVFxbnDurOldffQsfNMuumHXrqv6TNG+jGB9X8amvzgxyfP6soL1DX3RIH5YS8fQD8A+NmQM Krv+C/Dgg+f+eX7PLK0HhYz/BaRKSByCCZ9P1gEeGx4hpi8QIGPZ3R8Ds3Gjb1t7V6KtgNmeAyCW G+3uo3rJmZPJM7ZJ5My25Jmh23uDATJVDb3av/ULnX3bZivZWRh99V8I/8PnlT463Dt7zkJSzpq3 K1hfn8BtYldfrB5XYrM0Whv25+Xi62f1YiIWERjau/pygyv7rMHaxAW4QyFzsKizS71Fu63PWtcH eudod/XlNtSTcSkNu3rrEwMkzwq2dx0DhYPv7S9SPAcLQRHoJuPos9fhSQk37OqaO7/P3+uZi/lz vtLlCfTFujF83cGued1kloLGvoz38M8F1F9U78K0XXB18mJCORfSKV2Uh+4ms4U7lDH4EKytwieM eLrUJpnR2iqlC3pA8jL8K9oVpHbec3CDDtU1klM0ubWu0RPoDiQ+/8OQPNqY2FCfbsSzjLhjaEyJ 3/nBoSWuJgPKUBrm1Y8Y4HkPZbUBak+7+DgpgoX2w/gOHZnOxuQpOoQlF/dR+DFqF5lFp9IHJihd wXnB7iDmodiELkIbwVqd35bOYEv71C51tjUumXheK3G+LNHqAwF8Otmg6jAPjol6ktOqtseq7aFm 4wWnm5KnlV26YEvnLvLwoPZAoGAJwkSjcNOs3WXmIiyaY7B2C46ZFVSMyphds/oHt83etT8W27Wy oXdhBXlGsGnurmBnV5VHHWtH16WeTeSnzKAFtkyszc7Cuqd2fxBe3b4/Bq/unNp1zAiAcvXErgMU pOp6a7v3p+FzXccUAGJqL0V6SSdpKKRBntSBGzr1es+xGADb1LOM2qG25/RDoPbpkn0QzOmnEn3G ZB+F+5hEX0ztIx88Sc6FGGKsbhuUuWR6tnQv3NXbTYQL2PFU4n+wDwarQR8VrN4PKST28cF5tX1C sJb015D+mkQ/Iv0cZgxohxgcopN29QaxnsIM1QU8MMGKNHmk0j84OLErcNpzrjuAWW06/k7t6tNH se5nQ834urHk24u7x/ZtmzOLjANM6iL3cqGmOd2YbZMPxJc09enxE/TaE/AVY9R7CDvim+bgucET qN6/DTf6tnX3dUfJj3Yt6lbZ2dgHGoMVeNoTz2TD5Idyu3eZgwWqbGJR4ENXkUKPxwY6uxI9HtzE P9adAIkT8cjnBPGpOb0KRpsBczoxqyd0Ke9J9MzDKpEJz1O/vEc7CQhZdEiQ+D59Dn4g/kfqQg4R STbEdXcnBq+2rtIuwL9t7BPwiMIjoNRuwOjgU01kLPjfVXio5NLnyGPa+0FHcCPWLGTQ6pM4fLpP CjXNwso/cb+Ae4JlyZt1REcI2jNOJXo5QrmIcadDE/sH9wUvCYz4ZGcFyeJAGBN4jmHGBt27Luzo mxbNztJd2Cup3bt26aSL35DASycNlaRTacCrBr6QxR7bGvo17GHRgAPlag5t2lNAgh3ADirg4cO2 +npdNvcMrMOCoMCJQAcgrIsZGEo66nbXBI8Wo+toU1M/zD5Uw11HUaBm4N2BV3IH3j1nLs89B3Pf ef/d942fvWIqzy18//X38/OgKWBSv1aZ4jgrCqbmUMWRcElhYUE1VVwUDqbKlNpXVFJaTRcW+Cja muyppkgb0q99N5UeP4CorcGayYWsz22wSoilUpzm7KqQsXNaqCrHy9Ecolkdl15am9qytCH1j5zJ a7N7zTqd2Wu3eU3cwNus/M3nrPxtHbP02z00qpxek0bfwesoBqF+n9OVWRlommywGBnBYjTZdZzZ JKbXTx+40pZCnpFisyWeNdCGYQkOfsNsZa0gFYTBPcdA2uDZQ6IRtgb7tUq4f/DTQwKuCMkKjysx N6mFjOQoqUdRPcbSYYiczhJgW1owHPqPKIjOVG+Ql6CdEYFoFKkng88Gfxukg2JQNHs7zJPYSaCm psZcXp6b29NjcpSbcNVUaDxXYCrEiEd7ouoHRKMhux2pkEfoAC3TwdRwuKQUJnB2cEE6wKzTQWPI 7w9Z9MyKgb8tpnlLMMUbMkAdPMBIrohPyXTLzGb4Z/iLUXaPzNCcqIeV8Zf0kp5hZY+dOSDIOprW GYTrBjaTd64eA4CBmLt8IArKwIsxt99phG1+o4EcJHxwivigYFr9/VROLN1ti+Hzthg+b7MJWeTi LHJxFrk4i1ycRS7OOk4VYJ//5GFcB+FCjPRBfCUuPz1o0EpJLb84KKrl2YMCKSljTLpfOClQgjvy n/x8Lq0f6g8Y24v6obCfmwhqztWofFsOc3veV0EreD2aqODuaLQ8UcegWmUmGEgNF5uKSgoDGD0b 4WcfDYtyqGDQRJjZMlxloL9s/JxVTfEnHBkZDhheu2dOgT06OrN4ekN6fMBdNrX5wKm6jhLXuNDY Je2vfFPZVReGa0Yt6KjOtPkjzPaIP2vipraciWPLzHxxx3IK5rYWp8R7gpXjB96p6Kryx8tSSjvw 2jVr8FNGZH1YimcfTAGVUQ2VqIYKLv9JUMHlJwSVqIZK9BmqEPtMTpgLAiAMsw5YOpkTMBMUgzyY s18/GYv06+fIF+YmyDe+eSo/L2SV0QixRDZNTIkA26w+itBN2IoRKVZnjc3c3LT11ze0dd726mVl i6eO8ehYmtEJOrlg/Krxk6+bW1o858ZpbWvaiwwcj+ijRqdZtmZEPBN/+tk9D3z35HSbkumRLW6z NcWij+RGGq58bsvmpy8bHc4NI5MPSyDhshswl5mBH2yIeWsC0EI4x0I4x2LFNFvMmGCLE1NrOUE4 B7gT2Lg1bNwax7g1jnFr2LhPUCagx9iIB+R2Tz8M72cTXJLE4vUkR/QQjXYeS3AjGOCGyT/79KH4 J+r0hx4+e0/74aIVj1755P4tj64up+58+NufdSQmesqDZ/cuOryz+TtT9bbnyN43TBm9BVOWBdbv d0e0GY1oo45oo45oo45oo470U6aYXm9RLAoevLsf6mLStjA8GYZnwjAcRq5+TI/UHsHFfjTE9T2r VmOyclU1YtS4X51n6nucHgyYLqjSWxhe0g3cQiik5uskHcviQxzBAzqsGhg9ro+joE7imbFmj1mX oFZn9ljNHpMuvlhvTLGY3UYunq8zeVS6B7+hJ2K6I2D6fs6i0W3R6LZodFs0ui0a3RZM92HJC3xe DpN20GJxoX6YfjC13UUUpLYi5Z4ylQ9RB79HTHK1SZJLT8SEcXGMHocHr9ZjOqvidqZadZjUMWrv KUsKpqKRM3psFo9JP/BXTuJYFh+YJwiVXkLRtMFPmI2sAmrAT2LelBSDk3Cok3Cok+g2Jy+SGqbC SWZPAs9GoBKJRXojdMSg0W/Q6DdokmzQJNmg0W/opwoO5RbBImc/5A+lppbnVp+APF7jeZhxoLzT 2g+z9udOJvONpdmUgEPTc6/39JwaUnQaLudJc0mpiXABkXYVLRPRgMPyzzAbGZ3IiWUzdkxd8uj6 moZNj8yr2lwcf91kYvR4jbhLsJt5c8X02XPzb/vng5N7Hjl3Y/P2eQ1unplh8Vp04ZzwuF3PrNhy cme91wsvSU3DMOp0xhRz3OIOe1OdYs9jn+6585u+We5ghjs1wR/MBLzm5oL+QzX5MChqEIkaRKLG IqLGIqIGkUjATXGkCQR9gaAvEPQFgr5A9INA1ggHiNnwwhKzkIPRBFtBDJ8Hjv7BkwfxCVIewecc mR14AcmKGU6K8IwIxfNXYyxQ52ogXjVeJ7BqLDcsWD2hIVYbyXUJrWnDfckqM0FnDTjdilU3cBDX XITzdNZUpytg1VFtKi/imhujj1lO1FHVA79I1pk/JmsD31AoWdfkC3Zh/GxgwtEax3jHkw4aaBAC DUKgQQg0CIEGITiOdSI/ePIoRoI3dqjkYjKHFGHoe8TAruS49baAwzVytMMjTEr9V3hUhWB2zJRP hCGPzEkuqQV4bXy8Nj5eGx+vjY/XxseTKRZtkY4Ab/R0GIeto5qk0sbo42NinOFwBF4Efs0oslkR B6HdTn/FWVM9wSw7F0+7cA7gy8joCLjdioWTzPFO+IqJSyEKEBl56qqBS4ZUwfBcPEfV6EWOYXGH 5HYMDA7c6bZour4FU+8GjceALUGsTSPWphFr04i1acTaMLGHgN7QYeuHUU2Zw9zTyckYob2HGIso tRaskfUDpxwZQ0ScISZci9Vj0WPd/ERyqN8+oDelaDODolgfV4HHYsbe6pXVlJSX58jN5XOcTnf/ /3IxJRPjS8sXRZ5IH0+kjyfSxxPp48lM84S3sF0XcxFGSytpF5wOKdeZn4P86e3+SUnhqjFjI7cQ E5q0zrClaxyqmcpH5RYWEtt3BC8GIbF3seULg+fpeNX0hYVkvlV8UFRn9bscAYuOihfSgs1rtfms AhUfC7GkuZx4krM8C5W8NKcebmDhlYLbH3YtM3gs4jBLL/h2D8dzNINNGexc7B3qfygzTXSne76b Qj/ky3QJeovXpmmyrawJjAJXHIwYDFYNTLU0aKWklp8SMK0amFYVTB+fk1NAwCxwGsgBX1hgFEkN X1JALjECX1kHn2OIMC6yDhIOUeEj4H0Pu9xCjWUSSGHZCNrttovg5aMdheERXMVslWxuqdQdCQZt 8YXK6BSKonQWv9PpN+uy3B3eiN9rghXekoJ8J8RmgMXvsitm3Vgr9qYEb0GEeq/80srG25q/+/eQ tDyanso7MvwDLxbN6e3JHf/z8dQz2NfAloTIkXcG5gyeY86yAWDBFsKWmNtKMLAShrISc89KzD2r MwFTYUyvgDz1/7LwaeD6NE71aQupT1tIfRq4vhPYJOaBCy+bhs4gkSx28vlmX88IT+A891S1+kbY wMzZ5lve3XPzG7vrm/e8u+eG169rOByZdsfKlXfMzAhPvX31qjtnpFO33fPd/plTHvri/r3fPDlz 8s/+/cjyp3ePm3jtiQWrT+5um3jDU8TCxZrxBSx/KSADbNyfhjRCkEYI0kQOaSKHNEIQYQGHyUvg 8RJ4vEZRgq1e4kN5sbVwAJhC2FY4iJCIyRQO2trFEaZSgkGM51tLwQtNJGaEoUu/ENvw+MZb9JaA i2iVTDe0ZbYtWtaacbhySk/WfXeNWzAmjb5l1t3Lq+I5Q3KBp5pz1Ey/ZMr4xUXywNfpY+ckZng0 exWe4QioBNfHvHzAnE6oSCdUpJNJTieTnE4mOR1TEuOBkpKXsi2FTinQwCnQwCnQZrlAm+UCDRws H4WHzAFeyu6HGYccnSGmlEy1RKb69dMEhPLh+R6yjsrz81gNgQga6QJpPiALL+AATAUvImv32p3V +bfNSXLC7t/d0GjJqM5sWt6YbtXFH7uQKVY7/CYUqJla5cua/NCX99/5NeGMz+9p37NzZXZVXarB EqTeW/7U7nGd1x1fuPrZazGbPA0SfMIImE9KQD24KeYz5phKdZjUUoJaqTr3pQTFUgJbKab/aAbx tzNqTAQrXDNpmJk0hjJpDGXSMDNhhjqQkmPEPsWRlTEYizlGYb45HGh3aKpZ9STODQE3wn8u13SL Gn7Iob/HSHaHj9bcaIfFbodF4Ug4nHSgBGRN87kDVoHZYMuunli5Jsli2KGy5I92t6wZFwnWTi9X irLTrWtlXXygfoKrpvCmh+vn1PqxatZhzYEVY37RlJrgwB+GWA+b5ywtlU1eUTd6wfgKqxytGpcf /zDNS1/RusjBoXhroHIC1tFjB8/RczAvNoGPjoHRg2cPGYywdbQG0WgNutGahh6tQTW6n8qKRQti FitsLYiZYFtaQVqB6HGSez1k2fMYjeSAb/GQ6fAcp/LJ2nfQo9paJw+6tNKaKI8YiCEq5pyAEVCK TfpwTDAppbA0JoiwFc/PyRhPaqWmUpO9Cvs/h0d72IxOO+ZtTXvhKThnIt5dNNpjPGckAj5smZoT Jy5Qa0yStxPhuRz0A+4+oufUbXigZ/SKKZUOATsCOrlwwqrmsp66tIKORcsXdhRWLrppYnRKW5UF MRSNBE7Ire+pKJlQ5C7oXLx8cWchXDLt+jkFdiXVGfLbvWYuNT3oK51QWDquMr+weuKq8e2XTc42 uPwWweS0mFMs+pSg15tXGyoZV1VQOKpzFZ4jA9aQb2HOTwXzjjpjxKMyEdQOEQv2f60uiflhGjx5 mHA+MhPn0atpxAJs4n6mgvOrqPFUdMh1HDbik5pANbDeUl3ePUlbEdc0l5jeqTrEqsf47b1DjDhb Z0qxWBJBRWJvPYrXt0uwLRgFe2Pe3myoEKlViBQrhHUUYjEphGsU4q+YRvormNOAXSPYrhFs1wi2 awTbNYLtxykjseWJV8MTFtLjR/DhDmOHZ5hvVCdG04PRYRbpgd83mzWVN8IwuKRhW/+6JX1b6xNO s0WX1bmuqWVde1SFJmDRw3fXH9tWW33JkQ10MAnHd59PvbI7O6tr+xTaMdI/SMXabSFGJQ0sj3nT iGJLT4NuUobdMN0BwxLMcsEsJ3T1a0KqVojacyZ7SCVmJl0up8sZDvk7nKw54cWYy2tMZpgQBEIh 6OmBPT090Z5oSDUeGWISlZSMMBkL7HbEUUcZ2RXx2gNOk8jR8W4dNKenpgTMegaugXARrcOqy58m 0TofCY5CbPcLOuaAGj7VSfy3zzI1pJ+ETwmNo7Cl/R6msQosOBiugnix+ipWRwQ7hFlQRyrpuTBk VHtCMNVJKhmp0KmQSnY+zM6D2WkwOwhLOzI7gnkCPdIpxXZfDZ45/CFhYe0vNGQZ08nahWSeTzC7 gzGmZPj80RSZiX9GfUPL7gwlkJVioOOPImgKK/40C0fBIIRWWm8N+VICVj0NMyjopZEl6PUFjZAN yyZizZlk+tXvcpN15ucON0FFFr49xVQIBqy1dQbh2+eZSh7XWdntIAjlYUn/QvX982LejFyYkQPD Thh2wIgdpgOY0REUTN4O0wjHD0trj/oZDoBDOBT/HkHtEImQ/ovEmjNSlTSbwMTfi7/DirY0XyBs YCU4K/6kyBmxggrbeQTt0MryllSvP2JixHhftd1tYGmdoKfogQFsrNKswW2nOqkau8fA0BxWCinw LzqJU+d74FeEHp9q21lBJug+hheA/70TLmLBdaixjZMxkQQ7Qh0eZO5AGi/Dkfp8WFENk4tXWUdh SUmpZYiTmxL+oE0Xv1lgDZGAL2QX2IOuAjflyHcdogVLqjstw8gK8Mv4kLDCd6g/kmljOImPX1u8 trJ8VSlcz8scmTA7tkmm49Wzhn4Ze/Ux0BdTDLX+2txaWtA7ikRMURHRZ0VElRUZiXwW9cMvYzKI RAwAioBoPFChrawVmi9UoYFQkZTpin5KF7OaHL8CRcYiqvJkEQRFsKgoZ3RmP/TEDGdSYWoq4/04 p3nUn8Q2BuQmI55qEKxn1YyepGF/Kjqjp1yLfhZgg2UG9iAJw2Bfp3iEsVdYrNl4Wg+j6jousRja SbCMrjGmeNx+ufKm9rFr2rOr1z68aIs9f1z5qFlN+aIOOzKcp3by/KJZV08M//S6+rm1/u4Jo1eM cooitsTFqTVjQmPmj25d2RwaUzSh2OMNenVGl8HldQe9lqxJWyeecmTXZIzprK3H6O7F6L7BrsLc gz3Iw1hZ84ESjVlKNOYp0fAibRWvkn74VcxjixILOqqQnADBP0rWmKhRTRVQfEwPbHxJcYBh8/oh eyTc7BljbC3H1f1sm7oqYAgd5UNe5DBmQ+tCxPb9BSKhTJJOEmey21W34Y3COTf2RJvGjInozB4b dgsRZ1GcLuwjprc0NqbP3j0l/Qlb0eSYUh1riNRvqavuKnXBj9ad2DnGFK7IWI5ZEbOfqGPLVEsP Hwb+mlEWNI7b0beuYfvcUebM2oL43s4pVXM2Y3mbihFT6JdAMbhmf4pqYSUE7j1N0M4eIgJ2kWD7 J+cH2Qc/TgTfKSEm5cpQdn3kj/FSoz+tH1KHLM30P/KJ/aGXGvOz+iHar28jmZToOfUwFHg9NRRm vyCdghLmFRqZTKEViuVcVS1dubNum1c8etXe7mh7fbFTjyizZIhUTarYcFkg1lNVPrkmKpIQxE9M LpPkCnnNsc0H113x7KZKozvVKVuc5og/kB44+sSUHV3RtGhQZ/ES36EX43I3uwyEQTnYHfPXVELB U06ks5xYG+XEWi0n3FFOmKX8BPwaAJCbQC1XAytXAytXk9hcDaxcwlC8JTBGKI94GBmLJXvA2YxF nTkot7GtxMBS2anmgryKyk9DQZyRIojdhSGuosPhkQ5XKX03Z0qxklTt2L3T5lw7Jb1g9k0zx++I cVY/4Sn9Q3WX1tdgDsIcNTowKjYm4koy0Ia2yW079s9ee2Ln2IY6SkhGIwYaMO/M3hKr3z4P81Jd PkGrB6O1F2u1KCgCT8Qyc0tqSlaU0BYiTRaFJCksgSxi22cRtBLpS1W/YV74+nB99KdRiiTmDhNp K2I05mM0HlPbglomFBxD8AsEsl7YxtzIUCcZeIaBDJOS+6dws/PjXnmlTMn6j1NUBusZmc1JCOU7 0QSzqTlMVUBRMDCCrWznMx9li5SogHL03ohr4IBvzMr22NymXJETEE3RnFAyeVVsxb7VFVWr7p+z +Nbe7IfoSzaMml6dSlFUJNCycXKOzW3jZJdZshhEweW0VG/q37T22OUN9Wvu6rJs35PTOq+UrHuh wW+oK9mN2NKZe8BuJAKoCp5H01qepLbyaOrMozETNk2/PpCXGeofPBMzk+h8iD9XMtYdPpfXqLQa G1UvtIDEaqKnCj9LyFjhqQtyGjYtujvSCw1q+Y3CZE6DuhLbaoiz+TI8oSJFfgmv6qzZ8JIOqyan YtFdZjQSVXNZsHFZc7A2TcQ2nMHikFm9oHcWtlfM5kxuS5ry3T+IuUeSnbRNSbO4TVzPjKsmZ0gG 0eIhGfLi+C30NfSLoBqMAzPBmZjNnD2WSNlYHSZ5rGK0wNaxhTXYCiQQ1Gjyhcv3jpBTNdx4XI1J BjNsHe9hDHl0IccR7jGqeJ2MSbiSXch5PFxhNkMwjhURkLvIT3QpRnxbV2YoJuAyZMjj6LLmP4qd Z2223jL671WNmUrtH8qap/1BGa8lCWsSaaM3E6o/WniagOvABjMxmU2403g6iv9FkweCOsbYbk8s BeEIwvrM7tA8/STPleLltahEPSYkO1BA3P+h5ZQk08ORiExrLfoai+HyYEpBz7ZxpXM8Zsfokn/U rezIKVry0Kple2dnGQP5Sn5uQcifVjT98taMsX5oNJni8Xk9eWNzHfOm5TfmOjpntv9dyXDqd65v mVftodcG/WlTcsdt7Mzy2s05vmAOxVOBUd2V1Ssn5Ydi3UWB6rJCl6s1a1RvONRT27ZpYrZeF4h/ Nn2BUtaU3j3fX9o4MKOihtK5sjPSbaPrvHnVhL/3YrvufrwyF4BLDtUUwczhNKXG2CPyl1o+Ey/L Dl8iGaWmpdSMlKo2BHKOT+ShfJkuI15RjmY3p41xtarqUw28wFwtDZNYjMvPT8aoqwl3kVxHwhq0 0ffrzIk115nTlFe9pR431YB3cikee2PT1M2tAVeSnylD24z6tK5JA7uTPSPX35amUfOvmUU05RWD 38B2NhfYQABce7QmOD64IkjbNVvuPI/UopbvXeC5JjzVE9QqkAJsP5QG0SC1YZiO8H6yf8TfD6sP uYxNKj5vnotq2lBbWS6eqbKQZZcwI+ZCWH0hAJasyooo+Q5BQO/kEgRzMK8iM6Mcf5MzvwXPfBG4 NSbWlMCMfJgfM8M2bBCcUYeZryn8fGJEiGqpKvz8E1QEpGLDPkHND2cxMTO47dnZgBCaYAp7qsCm N6WMMSUZQg1fYvMC27OqFix4L0n3EOH/q9TXFh22+j1BpwHFd16ICJyoM7uwx5Bq00uG+HG4XBLU YBt2dPTw87j0fcb47jXsG0h6Gi8jetFpjB+Ph0w2DTNYjTGzgZiakVyhZiQv7vwkZxtgHA7xxjEq xdr8XjwD+b25dH1/aNoo2DN4VZ8APo55zCTvqO4aCav+dkR1tld2wDHf33mQiAGO2KHw8ZBE+3x2 kmPwFSTyXGrGS012qYLN49Xs6AQStZlQ/f2NHInHfm/Dxwn4FVYrRogOtDRjcxPFpNHN1WOyy5qy W10j5n9kyqJci8SaypO5WqIfQHQoE3pxJfFDWsOm+ZAas7BnEsrDorNm1eeUr2kgi6QjYOHsWXU5 5WuHdAkypzjsXiPXekNTWXd9njG7vWVs2pT1Tf5hrRIsv0CrfL+H3omXYprWC7oNk8a7c0en59dn WrC6aU1qXTyDBWBPzJCYQXLQFPCFs/QD+0iIe+QTjMakHlY3CozYIwC/OqqpYqKIY3x2c6YrrSkJ PVknh3RxMn+iof2/UMi2/5tCHgLx9rb/i0I+DygMUC/Rx8T/eRcjRHJnD8dSajJguhlmmEj0LCzC sA6GOZipxmsuki9776L5MmKe+nJ5yI9IxCnnJ+KOk/8LbPDkUQNoW4mnydUP4QFDcxD7SppDSXwi DbLcofRaT/Lzf8uz0e9WrHl89YqfLS8pX/PYGlyWPuGpXjy+aVF9wFOzeHzj4noF/nX5sStbarce Wo3LZlxuado+u7xo5va25u2zyotmbCfedHwP/QbGhnjT24g3HSi5yD6DhPYZ3nBAlm1bwpFWXWo1 xp/wqS/qSTcZx/+gJ30xR/oiPPLDjvTNM9LrR8fSRjCL1eYxcxmtbe3Zs3cRR7pQdaTHROo31VV3 l7rh39c/tWOsMbUoGK9O6kLm75hnaBLHuiSzOsPWuvPJdQ2Xz62yZNTlx+/s7Kqau0XTltQ+NbIz 59DKYhg2aBANb0jSoDJoGBoIVOYRgWqCGXBjBEMxfbQ5bLApTbZWoCkvdfmKDtkyIw34i4mNCgmi 9lFIr9M5vGk2V15xRfBCoQmNrij3SoE0r8jQkJ5t95n0er3OmtNaOtD3fbHZUVIfMdA6ntfL6r60 9sFz1CuY4ibwSkzMbalpGd9yWcuTLeyIZNAXWhJIlZjRJLxguSBJpCaH4J9i/kRGSM0FEeWiJYSI i0MkyHMcfqFuhuDJIi/GBC3UF8bPqxGfFCkx551S/h+mCaZe00oTnUj8vE2yPs32swnWGkr5aAmf HhLCH5HwGbaF/p8mfKhXCmdsH5c3pSHPzjMkoROtmVyWWV/gicQmTGqPRTI6NnekNVZk2Dgar/U8 0qeWNOVmxjJs6bGOSZ2xCJQbluL5drisaX6L28h5FI85WBIKF6X7U6PVk6uKZzVliWabUTTYjSaX kbO77JZgXkqkOF1JzayaSOYiMPgvahnzOKgA0w9lAFMwW8M8W5uLbG0usjUtlq1xZTZhQtEhZZ8L Nnqlc47G/H7I7OcSSug0YbtCLfpw+lQiNMNc3EE83420J91papnOqGTkOMbMjXm3Gswk63Np0uz4 iMT+zIaPSsc60lKsOlbPMtO8qUZZj0Ita8ZRcsJDfDO51eHNhA8Z53tm6nk9KzsJ3XtInIZ+Cq9w N8f8eF0TIoSDIoSDIiQXElHtiohRNSDg10cSkubXUPFrqODyK1U2SeWgugFbE1a/xqPYgP46prdk N0UE1tWEzQx2OFgzcjvVEEtdNFhzQXKopHQ4bHM3Z/baHF4TartNXcg4a8KxduQ25lVvbuCsfiy5 Zv3Q+rZh0riqBdfMplKT0jnwn/Ez60Jdk6h1yR4tS0RvxvhkgQ+PgeAg1s3EbPOruZOQH/oSFR+0 a3TatNI6bMyppXko5z34aayUJMzxGmmCESNMZ2FqOu4YlQrTUmGAVGsCMC0AFbVXgWkKjBjg+gAM kCCF3mRrDChYagMk96THrBggESLSIjMRIM8XyRa39KaA4G4SWofj91Gyb79HXQejiX9qJiOBO8ne RNU3KYY2Nw0vkA6LIxHY91H0ZkjRVPw0I7nTfb50l8zEX2FYsg3H4Q1a9Eycob+leEvA4/CZOPo+ Rs+L3HePkKQUo5N5eopo1tPYxaHwQT/gFkXqb3pRR1M6gaBdjC3mnRjtBvDuMTAWq6dRmLQyErzI KIOlpAzlwHAAhhUY9sOwD4a9MJIC0xmYQcOKSlhZASuzYRV5z9UG24ya+0fKGI/Z1ajgJxgNWjcp 1VSHgXQbRjep1xEwa4zjjSuMlxkZY8xsbzQWNoWaKm7MglnkXBbRmkaLvXFB1oYsqgH3Olr1BOQ3 CJI9p2pqTmMkE3gPp/4Syb/EJwE0GsKZjnAjcmUXgXxEld3JsPEvacmR7vNnukT6aYp6kpbcGT5/ BLfiX7MMtpUdKalmHf0HinqB0psx2/vNOuotCr5J6S0Bt9NLpoWzGoYnhbpOrx9YMzxFBiunF/AM Yb9rwK3X4xmSsOIlmw2dyRal48l8ZWDpaMHzlQuuPAbyMTAmEp8leiOHaIzKHOjE/HiE5GOc0KHp Bnuyyw71hFsziRdG7qkCsCwISwQoKMRYJrMiCPl5GU0kB9dkGjKIE5nV3KGsKmHeBP9GQ3Zr8qUU +iI5OYtlOCdXp7NE/L6gTWB+/xYj2FJTvCET1ENn/EsdtEQUb9DKM6fPMLzJ7/GGzJQ+/nWWbBFZ 7GtycF78LlzQrGiR4VG4T7ZIDI14Lr4fjkdkt55gNcRnEO2BLcAtGJ800HEMeDCtxUTyPTDDA52q K+iEYblEpiJ66CZLcoUbusoIcC7ob3Lxlia+hRkPWjQXjGRbowmhJcIboBOkllrIvtNw0VCW1aIG vuxWjirciPIL3IqJQlv0Rjr+rM6Y5vOlWvUshPRXyJSqpKSZUPyw0cSKVhmWM2aenm5zyiytM0gD OdSbFoHF64RZjbt8QU9hZ4Ai0AjCMTktza+3HmTZPH19BdHtcH/eGLLkvUPezlLjeokY6dBrWXSY rHUJO+B72a4L7XF6SsHUrW1cMGLzmXUI6s0pZvvo6eVuJTartmJKLIPnsBJH1vL2WUVL7pybFz+l d2b4lHSXXu9KV3wZTj39566re0vYzwwGwrYQrwsWLqN+ekH5zIawy+dEJq/d6bL43eZRC6/9rjIQ 9QiCJxoIZLsEwZWN5y0z/i5cA94DHsAfEBwpwPj66cSGI45LSGqpZegVsjVIdpiuYSWLy2Jy8JC5 QnCmuV1pDuEGf1FOtusVjtepwgMt2zyKESGjQvymE4NfwuvoW1W/ybMfWPupzUd5XxB7fYZGUHO6 5jQxHAq+vyXQdEEbXodp9ivpWDKd6Yo/gcF5bVpRsgh9WUpqNimzB9IDiQ5MMFbA7mwiybfj8SzH FAvAsZ9scTl5hGxl0dNY5PBQos8R8keEs5bnVlflkO+ysbk5DfhLos+3DX7JfAreJc8AQZD5LHBS W4APiNRmYMY0bzmKAja9x0CeWVh4uqAAr/nk7/xHsz9Qh4tyqypyyBf+MofUKrGmP5XsWzomN6f+ Il9MGYx/RPPsM8AGdPuNLMjFnOnQJlGLTnEPM5LVa3MFzAyiehjJ4rNh84phP5MMOoaTLBLaLBn0 eA6tEn5eAzxE5VCjgAHIhwAnnGMA2d6oRacDieGSbTtUjtkUn2HGH/gTnYRF7uuIzx8O+5DJDeDg F/AcQ1Fb8VNMB/BTjsEU8EMPYiiL5bsai9lsoZ/TG/QsVRIOBsOhoF59u2Xw6/gtDBh0AgkYDgOO /ztD4uvff46dAUbTd6NMZrOJ/qXRFH8zqPiCqakKpuiK+D74b3Y3nrPUmI0mipsmLgOtbvGjbX7h ClCTi/kxkfxH2EY1O4b2PuTQatQ9gST818yemdNYKHtdZrdFpEs6ylL85R2FUG9MsTtSjBQ7+6V4 95tvxaf+WjQJLIV07PxXf//OqlV/+sNrCxiEsBI1Em7chEf0ER5RABQeA+aERWXWLHJSHiYjM6sb 2QTV50uMMFowtN+MS2r/EnNxERUJa4uq3Qw/SilrL6FFi9vs9kqQnT5jxgyGMqY4bCkmHbVgHeVa 9c7vX53P6hDFCibxZbjvrTfhvpf0Rh6PDjGn4+Px+J6Nn6Q87AbgB/Jh14sG9wtk7nLPJSFPWqqB IYNeNeU9BnkQiHazIJjtIgQIKzGD/OCDpIx/F/BwRo8VRS0eE4eMDpOS8k0VMqh7VKbGT8Ij2q8Z X3QZXkDar7GJ7dWaIzHsUqhRyiOC2SEOytjhFLgHH0yUg6LDLHxj9WAXKWByGBB7KkUxOYyIM3ks 5Jcmx5+h6tltYDzwxqSaGu+LFouu6O1w89s69RfV1xlHJV/p0WxyotCTXFBSUpxMuyTfguLUDFli K6ZNDbCQU1Q99kiQ2WOpm1xgNgVLI+QdBvICaHOTpXBSrcVl5rRXvTKcqTbBmFFfVFSfYeRtAUem XsZW5qDRIekYGJ20bfEr9RNrIgyecYfBaDcgSnfZlgcWbZschQzuMhLyoCl/cvfNTQs6KgW+snN+ 8zNdk/PNUEN3HaZ5Hqa5ndCckdH2PMsai96u9b1t/D7NmKtsyexTUgmXkkVNpR6DoK5uQ6e02Buh WiV6HlkHMsuCsrVg8miL24pbCGHKo85UO29KbygsbEg3ERrTBQPPsHpJjz222skFFoKQjpjJpUa7 zEGmcMKcRpVGbEZLGo3mPExj89q5jQKfVdfV/Ez3pASNZqND5pJINeS4WJ1BjZHfS92NV/Srse3m jMm+dH8k18EZjIgXggJWkmYHdsAgNpQQikQsdqKHSy0cIttoS0sjRK5KHA46TDQzR5eW2LFC4Di6 SaYcDq/4Rgqt5OQodMrros/hgPJnn8nQ4fCJryf73xC9Dgclf0bvQ8FIull/V/wbgxHrHHSX3pwe CaIli/HiHzHr74SsEX/i396J+8NBbjFeOZdgj/VpVlEtkb3HQDO2Oh0Gqq23GUbX1cD5NbCuBhbV wLQaWNNP1cWsYkqKuKkYLi6GLcWwohhGi2ExPnFkJYBE+RFnILE36uxR/BiQJ0Kxf/CbGI8bYsVg Xh4b7ofggKW7vh/a9rMzh97rxeqm53Vsd/a8r1r1ZrLVR62R97GiI0IgzIUhD+6CeFsy6vh00dKH VrVvmT4qZDTnjN/w0PJQaywLzx0FOUEvhEvaCnuunJRBu0e3Tc5fdGN3+AlHydTaUHNDjTtQM6Mm NqPaCx+cdN8lTenNS3f9dEbno/fuXlClN5gFyWCRzW6jTjbJrdsemW7wOQ3l867prZhZmyY5/ObL n1iUndc+j6zgHRjb4+o++VIwFm4/BkqIG28im3xwhSjd4n6tpzjZU5TsKUr2qK9Mm4ZfoW5SNxzj KWqCeclr8pIBgpE9atoqr59yxVzWdHX1SVfDD1pdSWzPd8bcPkPQ5yNvqVjVg8/q48vUa8qIi2zz YqdRvVHrJDeWHafqABh8/SCZ5OFJH9oRre3bOanliE6q2wdqiX/Ck2fU5uGH1iYHXZscdK026FrC aiae2PB88Sg2e8DV3TAwxCzlQ6+0vZ5wts/bJo0L44hoLeEeENU+I82/0oSSHX47gKaLhnb1OEpK yEviybx2CX28atVDS+beu7wivWV5Q9X0WCB/zt75s2/oySKbesauaIn83lvWWbx0had8StW8pZmp DQvqa2aO8l+xc9sO2Dpxx9SczI6NbaPmT25J9Te0Ty+p39BVmNu+vKZwxsQmJdg8aSY1M7M+zzV7 UqSuqtxftHXgJzkto0cF/NW1TVmzFi/BctqIeekF9a2aKPg45rogLRBKpgWyiT8dItyRDUcE/EmW y0qiUFYyeVbysr71BEX+lwklEYBTNOZStOyYooWicHmW2K5pClT6qeyYnicv7MQArf4/CXqyn4gf z1NAjaWoL40lGOKkKvGAB3x2lqcf8gcMneRtluTLOsN7ebHvhQV9ZDZGnbL/IbfAjMgtMPQLucv6 Lt+0b340b2nfts247JM90aq2vEmLR9l9o+c1lk0aha13atetX+yfNeWRL+/f86VaPjbrzvWTSl0T rn1q6U2/3laRVjdj9RVYfT2BxfY+1gFywF9jaWk+mOaFaSkw6IFpbpjm0vayZqjYm4lXnafu4yBw 50FAoAUZWkQzQwM0Q4vtZWiAZmhuewZ5/Uf2OclNToEcBZMmR7hU5cqkydGI/pPaCx8YenzH/SZo spj7Yc3BYEeGsR9yibcMC2oGTqvxZPI5TbbYJHfHJ4RhOHbSo72EmNwej20llIiZlIa07KFqa9H3 IV7iBqZzooBXWEkH5W/IbhoaCXqYyYhmp9mpmNHHOlnP1pOIMWd0W8xuk57+/a08I/kcJqdRRM+S /wSU4QT07Q14ISZr5mqM9t2Yp6vBHmwrlMCoD2Z4SRwq1p9chmLQTrjYrmoeu6LGO6jsI4Uh/AfK NazLj1OXASEBjkCiTgLJCZrKyhWlHDNfzpFCO8rpNJb3w/QkQonoe25CmWAFcnro1XoVIzW+dB44 JGR0gbONhnQHp75YcDeL/YmBYtlm4GjeIH47ZVG5OaV4QpG6sZQT8MrD6pyV3UsqZ1zXk2Mfe+WK 01ShziCwzeStCc7os1vx8i5BfvrNG2dHo20VqanpqTqzz2awG2VbWtBZPH1TQ/XmG55c/aberGY8 FmCdcDPGrwuyx8BUDFkKgWwqzNdhUPKJ4OeruOUT3PL7qeIYP64zPG6c0wLbYiTeGcaXhEkYLoZ7 wzFa9uiMyQyHeqdHUTd1JVjWg5E/rIaW1J2YRL5ljTVljdtlMnEWPA1yJdn+UEkCgq25lVBlXY2F EytApanSZC/ph0KMb+rM+reisE3khRhh6IUYbCcah96Jwao7N6HvNV2vbmwiKXNz+bCe15QFUl3c oTxJ4pVJzZT/XsRkeBJteAW4uXrto0tGr+qqMOgQLUv64s4V9bVz61OjnZe0bcZzxSFB1q+qXdQU cRe1F1fMai3gSeQKe16WikkrYlOvnpatVE+trFsxIRuu7r5hfqnN65dl7A2npSghJbV6UkFpVywV i4fN4jJwqbHu0vSmEn8wPcgaPHaDwyRb8DznTFw3dtSi9nKB4oonEN1PdtX/Tt2FngO+jVWQoG02 jGTBtAhMC8NQCgx7YFBVUCEnDDlg2A7DNhi2wrAR4ilOY2Eatlg9UNVW5oS2yrY7ccWuGLV9PYn9 PO8dJft9UnJyjP2D38W8+AojET9iTOIDifmSRcRInFoj+f83IoBJ6CoGLwDJ7ZExnuyPZPJyI54c dYKZaMBo5AMdfGL3O5a6wnMFBVrUMapldMjLrqfVclgCL/jA8zcFDokmHNZVdhiEAfp3VvPNyXeC Bz4WjRL2jXkOvsZafFm+QL7PeLPJFn+Aik+D++DKQDj+aTKNAY3I6HNafC6HRJuJi8DqJP13zwep vw9UEImbhyXuNlbGGuu5mBQphZESNSlPqxrrSEJhlWpaqVT9L4XIa33khYB0DH06eUmSyEW6PL5g RcFlBXTBxV//PE4Vqm8baGvpYXUnkaWfpOjJ3jSLs+T/tHcm8FEU6d9/qrtnJiQhByRACDDDfRoQ ASMghPsIRziGU47cCeRiMuEURVAUBA8EFRUBbwEVRkW8UVFRXHVd8Vh311tRUfFclTDz/qqermQS DuO7+3/3v5836De/p6urq6ur63iqqgPy7zaI7tb3R4/8ft7RbUKzGk1n1tey6XTvKuLeslvMgVlv cuPhwpWlW91aamwrSheobY2/VARzcPtDNPP64Sv2FPUvmtwHk11DToEju4woHDmkbEJKxwkXTjl/ WocWzdwtjfMjYiMdCY2CLduO6lF6V+l5YlvBbaV945OaxUTHN28UnxwfkdSyuWdo/ugBcwa6o5u3 N2JbexqgE2zXKbjJYfTOXBsK6XmJ4TRfJlny2WgDD6Dk3fT2oxSPvisyvrUYEx8XZ/8CZM1fjDxi j5O/qLroV5tDcfv0VXFxvI2hroqzr1Kno+T+U0WcbDhOe+uptX6zrUWYY/uOcmgT7RE57Fu3I/Zf CfDBw7gm0RG/T5z1YPMJUVW/qKaGZPUWutp7RXrLqHq3SC2zh/+VHuYDpqOBM5jiiG3arnmbDvGG U3x54rrGjR2RMQ2M72MSo5zWgUYtk5Nijr8aHdvAdDZs3NAa3aldY4wrzkYtUJr2TASl+QrJ9dLZ ItXcYo6ihpRMLR+iGFdi1BMiUv5DRPjZjORnpKL7OX/qWXvVK77GkbmlaeyJ6NgmCfHGj40Swm3T 7OR2d2rXpk1wqtzWat+mDf9rcY59E2+d9tHLc2L7/0RJEeqvgX78qwtlnujQXx9cdfy3E1c2OOra S/JfZTPsfycKP50UJHEgctvx337b1uBo7X+xLradFVN9JF4jsrZT27riTA69IrFm0C5rKGWekqM4 d5RusEKULDGP0C4wzNbhNtlgDrjEDt9l3ke7HNE0szZWJdIDjjTyGBbtMqzQaGgn6HngbJABxoNl CG8FOlobEG89uYz1oXutTrgemLMUl5hZtl1GLazZtMv5NtLucgpcYAxl/y7jGee3lG21wb2AIwv2 NNjMJKl4vhE2iaBZ1fFnFBuOow3tqCvWWmrjakXn18bqSD2QVquTeJr62TRX+iPF1RXHBaGPJJZF 281DVHwqrFzaDuZZi6inxFyBuCuQF1aPTTfQGQy2w7ebGbhuJRWdxGKEL6Z11hZKE0dpuzgamgZN go4EHYEXTAQLEB4PmlnJtN0YgIY7ILTOfAlpA+MDxeXGZ7Z9DHk7TNudTqR/bRWbwWJl54EdlPe7 PMYgnTzzedwLWHtgfw2bGaZ0PI1iQj+Bn6uOp1MLc3ooyIr6uJ62gltsvQFU2PZJmCeotXMAnVsb 9Fp9zFV4Z7UppKE2EUoP0wW1aHWKMIWzO2P1os1oPzNsxoGp+thVSjOcfweCQdy51jowD/SiTPM4 zaoLxgJq77yJ2kccpvbWTtg323b/WoyvhR3uXFiLNbWww2vEb4B7DAlLe1X1OetrxtGY2rs6UXvz APWujXrWk9ls9QrdZw0J/SreosvEW6ESaCx0BvAAH5gG8hEeDzab++kyqxVdIb4MHbbJNm9HuI2M A7oYLZSmi+PUwjhBm5058l41GKf0ttAWpal4HzUZf1JYf8b5inp3Op25xsu0mQn9Ci0xW9MEBvW2 deiEPnbczyCtzeI7xL+fWhsHgNQnqIP1GbW2KuoGyrq1Kx31+926gXxuBFfZuhqMBWtse2M45hZq 49hHvWtjLkKftJXanERnmm7jUppKPjOTcszFqKu7aKjxKRUZ45SONPbRCPEMtTNuwDv6gopENmWK 4tA7OC4Ss9GfTUHczxTD1HW4RvwM7UGDxcfUVl5jXEZu81vqZlyEMW41uY1zabAxGf1ZBdgoR+0T cAYqjxhTTg5D/sicA1RY5VaQXytsCygUIRzfBG4D96jwXDDXbIf0fkLYcJCvwreBi8yOOB4F5lWl sdyMxnEsiFdhu8C9xrW4/kawTYV9AT4y4GMYz4KHEfcZ8CF8DuV9VE4EZ4tX4Ye8BV5l8CxjJXi2 S6FLjYuVLhT/pEvl3yzBvkhojfRBzEkYXy+lvuxDBF+UYxr7C8Fb5djM/kIwAN9govIDNlE7Pd6j jCfxGB5qoq7BuG3uhG/C4zDGy2CJVGdj3BPjqZPoGkcGzXZkBH/VY6IcC43jaoxpWzWWoW+1x63t 1kOUx+MWnu1oaLIajz6keD3umJfT7KqxZDGPH+ZMSlfjQVjf7UBJyX7dMY0ul+OLYi18LUka2mlP 1McNGPt6IN6dqKPAOIg+YAzOSQahP1pMTqMnbTR6ho6CpSBW9SsP4fnyoDegrhs01jTRdnSfUESd rEa0ENdPx/u/wEwi0/LSNTbLQRNHH/I6+pEXz93IcS9tdGygHImxRr3LSJSTfNd9DAfdUEU71PsQ lUjU+xxL96n3WWazEO+oI5lhvmOmswD3eJnSHdK/srH9wQzp61X5Wx+T6fwNvM1+o8us9uOsX/k9 Sz9V+154TmYf+oWN/K4dLRDnJ+Ajv/N7pNEK9lcU62wGTQNZNMvKpCxXBOwF8O9CuP57+G6o2Kpu fEO3KT8pwaYj3vcKignzh7o5FmMMXkFTrTU4t4auB5tsH8cr/Rc863YJ3q1Q9WWx7ZPcC+bZdUX6 XdqP2II6uwU+d3c8RyTXF+sqXFOIeL9RsbMt/J1hOJ5DTR2rEHYEfELzzWPwX3rCDmF8n0NuKxug BWIMFyoc4781BOUi69Zh9OsHbA7LMSg0DX5eUzlOhI/hSH8AfIJ0axLq3iT4VJMwpvEY6JPjmrkX 9Q1YidTEaVBjRyHNsUZgHOtkj1Vngy5q/Fld5XPIcSaJIuVYZ/fNzcw3qI0VRDj6btTFzdY5agwd 7HiTNjuCOB5NkY7JCHsWXIm6vR55ewH2IUq1JoV+lWMz3nczswTPZoO6eqfEuFlEGjfT0xLzYboM zFb8A3V7Ln0N9pg5tBRjwRzU4y6yToPHZf12rKbrEbZOhmvFO7oCdNVqh3U19pIf7NdqJcHnS0J7 sNVsSsJ4H2PCA2KtWSnux3EUjs8yyjGGALMS/iRwDaBN4SDsV7OSnqlqc8V0GVhq+PFMfpphXEpT QIWRhn41DeGjaTfIP108pHUrWAQWg4XWbppvnQ9/oJLmgfPFAbrS7E1XOjAmOTA2uf4JMG64+rM6 76MHJJh/rnDcQQMdu2gsnpdw7UDrQRqF8C6wp0Kl7zQN9qNgNI4nQYtRFl1h9zJ/wFi9Fe33Kcwf tyLeVvhprWlUxDnoKyrRv3+MOh5PLa2NNMc4hH75KGWBCagfbcy3oX3oIjMAn60P+oM+qNsxNBLc D3wgH3hALpgPssFExRCUzXpKMi9BP1iO/nAXdTALkI9HUAajqDvqhvwecSLykwHWg1yQBfqCfJXn rag/W1FfEeek/HWqc/56nCp/aB8jxS/wIXZTunEfDTLeo/bGXagj79NMjMs9jQ8R/j78lC9pAnSC 8TpNFU/QXDDtX7nW2EKp4ic625hI/Y1RqJejKcEYjmsmUA8jldoYU5HWWKRd13h7QulmYxrqmAMw ljqa2poCJoGXaJwin0Y4HgG3gT9RR8dyGgZ7GMZ26c+NjBhHIxF2geslvK9KjOuVNAbMBV3BbNue DtCG8K74vBdMkfXZ8QV1sxzU2/kXKsS7zzS+hv9XSRHS35B+gBwznbnoiyfTTKsJjUabuwlcD15S xNADrhjRV2vkOLrJmYq5Wx51EmvhD/xVjbv/IuL1Wms0SSARtLSPW4ShwqrWW45grngkdAR8YesR GYYxNRFsO+Oax8bToNcmXjg1NdYiquaXocfBHrCPwZyyyq4KuyBsfOlhHg+9Z/MuOCTDMb50kGNM 9ZwmdAR8Wa0I23YSo5Tq+cEbVayzdbhUe7wxpGLsnYSyT61eGwk9CfbbetAOO1gThGn/cEXoGLgb bAO3gasQLtcuGoCNYesLrUGbMM2zjp4Ge03AkVjFTbZWSGU/MvSd1DrVu2coz9EOfpPECR/nOvSp kguRf/hMck4nfQ45bw2fk4fPuzGPaGF8TleZTozd6XSVcQ9Yh+OhOJ5JV4m7wCFyGB8gHMdWMc5V oN+swJjzjrJnYOydaqyg4egbLPhRU42Pqbk1DH3Fw0j7SrCPMuBjnpBYeaFQOOYzEowv0dDoKjXk HEIiQqFQOEijgcTYQSttbpRgTnJpWBhzMfIM1HzpWroU7fAEwhNAYzXfqgL3lPMsOX9S4zG4iede RCHM2YJjcM/jTHAgc+JZiX3fBKS/CpoIrpOYN4kxfD0/N+dbzrWkBh+x85Eg7yXLQT6DvmdtLEEJ lhAjZGrGDhkXZfEqw2Umw9V9D0rM7+igPq/nawjfZu6ReeXrXRdQf9cFUsOhgc7XQyEJbNMmTbxP PRSfU08J/UJDJYYLY4KkAY2RiC2Is0WF9VTY4aaNmGMzkZopnqMmiqdRRwHKf0I4KPud5pOoJ81R BpImJBTNayHICEfeQ5YDnluVBdperJq7pFErNSfYgvlYiJIdF6nwMehPixztMTd7GXX+vtBbjhiM FWtRbzMwb+kAXx1zUlcD9I1dcA79qrM7rv8E1+r1YsxHrYH2urCce8o138H2Oi7mQjJdjP0FETtp V0Qi7XLKuc4IpPkISEC7RX+P+VFf1Wefav04bF2/ar29E5Xrfh7pR0Rs4rTlOZecQ7/J82fMwb/l 8ST0IZ6zBPNsOReTvyrRT821poWexnOU4D7d5b1kftU6PvoU5Hks5t/99HhUe3yR4wPSf9caGvrc nEXJ5mcYAzZSjjUfZTsM5YZ5PO57q7GdXJjrZGOO0xz9eLJ6Hrk3wWwO24+oAe55qc1K0EvtQ9j7 D3q/waaTVDxXH7BA7yWAbfZ+Qm8wF+TJ+abmpL2EWs+n9wnC9ggW1dojGPFH9gfkPkD4XoCcw1bt ATxNiVXr/rIsnw3djHlSsryfehcLcN+P8C6GYky7D/7QwwibRx3t9T/LfNBey+0h12ZD3ziH8Nqg XDswBlFH8yH0IWMw3xpA01U45mno09W6H/ylZLVmJutqHvzgAspwyfLaD9+pFeIepimYE05VY3Mv WgquCAfjehbiTJOo9ecxoY/Umuvt1FeP80g7BXPKuSpdXotFuqGn2WdAfOUbBF/FfXLhB3wtrzFe DpUbL1Oc1Qt9QC+6XNXNXvC9/4TnlL70GOTZ9jlqr5dKH8BYQzdaX/Eap/M6muvcgHtnYVyXc1T5 vKiruLa/kRb6p0Sto4ZQVh/Bj/CpuY5PxhU/YH7XGf3HDahjmG+quXb12utqOe891dpyrTXzgXrd XD+/TT5oLP0aPLvbZkbYevJ8jN9r7DVoyXQ5t9aE50PBZVC9bmyft9eH14JIlGuoen1YYar6cL+9 Dnx/6A2JvTY7CCyz12pXm1tIhK/NqvVYvSbbGed4DZZkXKTxgoojz6HMxHc0SdXFw9QZ5663svF8 74GhuOZZ6oNy7Gd8Q/3NJNTTfuRFnY+QazQgwTxEI9X8Uu5Z/UWFT4I/5rPuoDxzLRWYGfAfV1IR 5p2NjZ7wWY6GgnIdz9mTrrWuxTn4ZY4NVII2FWHv9UxSa3ircCz3dPawf4Z5Iu/BXAP/9jqab95I XtertD3Ci3Y4g7ZjDrPL+RptdxWgPcJfxH1GKJ9vPV1/0t5P2J6c3itDniZq3xH3IJ22POf0wnfL om1qzfHH0PPsj8LnXkFjxdHg67hXGa5rqa79OnQHniMH9yF1L+RX7cFdp9acpprr8Ay2P1t7P0z5 mfLcIWqHPqCjOT30lXke5rpyT3Y9jk+gT1gBP2EA0r5S7ZN1xDXRuIdXxkN72IV3vEu1h7n0tV5j tSkJ22OUXGLrJuSlC+gABgECo6v2FPVa7GK6CXikjeftItfZ9P4guMjeIyTQCbSTa26asD1CpvZz 23t/Yft+A8C11ft+Cqre81M0A0n2O11ia4Xe2wvf31N7enpfr5Ac9j6eehakEani2GWvyn025hfP Q5EXay/ifMvr0qquZ6D/2Ixw7bePsAnfV6vtz6+0Cd9T0/toddjPqcseDtru9dX7ZmrNr595c3X/ p8YC4EjGXJ33HNOt3qAf+r5B3McqJuDcFnKbr8OHOEfN67ifQv+APu4HuQYu99GMz0N3G7/KMJxf jT4vmzYqVN8XelZdN4nXIx0YA9W6dh/yop9rGwb3f1fRRtAWbfoyhezbvwwdNgaHflG6NnQA/d8g 2QeiX+loLcQY4KVrdH+n+rEJyLPs4/4CnkD/8ThNUePIRpqtFM/scNEcuQaLZ54BX2iGXDOVaaMv 7yj7NlVO9jXOUoxLb9JcVxLK5AeU7wFq7ViKso7GO7sfcQtRxt9SN1CG5z1sjQ0dNt9CnxIb+hhj bZbVCGkeonnwCzZb0+FLDET8UvLKObYh5zPXYn50jHqotVtZTn6U+yH4NnJ9+h70iZ0owfkKnqEg bKy+B2m8hvFVMhA+yDy0yVxKd7xI6c4czGv+QR5nDMpjPA02u8MfkWMI3qPxPa7DOSsDijQc3WkV xlAh55jww0nOM43jyK+eZ95DGXWYZ/JcM0Aj5XxTzTXteaaaY8q9vV28R2d1tff57D0+xSLMSyU3 UBe5zyf3+Grs742jPkrtvb6q/b334NNP4X0+YzQ1NJ6CPRznVlEnMxf1aw7mL3LfUO4L2vuBVXGQ DuJkyDjOjajbj4futp7EO48M3e28JfSp9RD8wKfQ9ieC5mALxrdYaOfQs3j//UzZh8JHcF6BsRjt wShEXSwA74EDts83Ab4KfAn4qXMt+GjiGM13XqzC9Xg/z1yGMf031BfUX/Qxnc3+8P0uhO/yTph/ YrdR2WZlnVFj8Dlok+/QRnMhpeNZ5qt90xIQAItosNw7Ba6q/dMNmGPuUPuoxcr+FGzE8TKM9+0w 5k7hMjflX0HYAornk+Vt9kGZyz3V4tA74hNV7oR31g3nShSX2fuqG8FdwAdfTb6nL7jM1XUof9De MMGVSFvuya4mtzhAk81eNLnG+j7m6mq+vplyQZFeU7TSaajEmEDfq/1auY8LW64HKFuGnYd2dB6v M5xyrWEHykrOwTNRNrN5r1jtDcv7xNH1tbGm1gRhQ6Cno3ttEF9q+9ogvDn0JBA+GHoqaufjdPEG nyEfpwrvAD2JfzUfZ0i3LfQkzpC/dOipqGs+TlfO7aAncYZ8jIOeihr5QN3KkijfWq4LyT2pHejj GbXuI9e4ZH2tWlNDPLXXZa+Raay00M8S06Ab1ZqXpJ1aIyJXI3pTovpV2X/K9ibrsfxm4t1QiEH7 BnLvOByiyjxJzbU1TltxuvAfa6HDO/Lallr7e9c+Dru+9npo7XTgQ+yVqLk8f/c4RCvm3DHWlOBB qWpNQcaZRa0c8Gmt2yhWxZNzf7lnj/EHDJZ789bbNMF5KebScr+9EeZN3H/206r22Bejz5fj6GbE e15+30Oxcl9e+hjWQiD3jzD+2t/jjazSNag/a4KlSjPUN2ozMRdt5SDYs+A7v4d48tu17aHnre3B tSALdhvwAuwrw45XgGk19xzOfI0zl9o6c0PPO3ODa0EWbISFXoB9pT42jwSPWU8GV4Klyn4muNq2 7wCbrMrgMcefgyvBUsf04I5THN8BNtnffpwxrnM/5ln7g8dcm4IrwVJXSxlW89iwgseMd4MrwVIj 85THd4BNhhUaB5Y6xoScjp+CK53RwWXK/j54sdMR9DvGBF8Du6w2wWPmZ8GNjqbIR+PgRdbW4A4c j2B4P8SRoa5b5mwYXOzYHNxRdRwfvJCPkVZGcBd/g3LmuK4Emu1KCDlde4PLXH8OLnbNkmH28eHg hfK46vuR32fGH4hb4zr9LQoYb+tEGxVuf5+yAVwNNoYdbwg7lkwPs+sUH+1TGD1Dq8EqkCX/vVT7 WDIXxBk9g6/Z9rdgGegMCkHBKb6Zqwm304X2tzArbS49xXEjEAdWhH07MwgskN/Q6O9l/if4I9/3 /qFvgR/9fez9rlE2te1lYfPy36O0LvGc/X8f3mMLZdnknnwcihNHg19Ac+xvttbZawWT7DWSM34P XLUOIOfisq/9t2noJ3MNqBVe9S3Yvwlnxe9Tlz6/Lv1wXfqxuowdtftz2GNrH5/UHyYEM2v0hzjW /of2OdQeWbg/EW6H+RNV/kM0+wWYHyzROMap78Ui1beFeZjvDkJeA/wdm3WnvfY/j5Id0RSr9lr3 0C5XKrQr+xXV3yJi3rQQc+034D/cRH75XRq4z/EzdZLI7+Dk93HWHFwbQ2bV/gXiuVy8D6T3ecwj NF3uSUnsb+oSa3xXF75PkUVjqr6Pk/hogfzmUn4Hp57nMt5nwDP2ds6ic50t6XyrOZ3viiVT7hU5 EmmmozWe4WWa4WiAfM3B/P19nmfKtRdzK+by+/lbMZSn+ibM/ArnR6DMFqAffwfnv4OWYryQflAS Rao5pyRAneEDRZpfwmfer9hsHaQkifr+7DUct6Ymco3Emmx/F7aX5siyMg9Tit5TwPx0StXaEn+3 FiHXX6xJtAncUPU9GjCvJKvGt8H7qbP8Fk5+Y6aeZw+vWcs5sNNLcx0347keo3Snm5o4M5CPYZRh XYI8y3X9rsjbPeo7vI6qz0iAHqXtjtft7wJb8Pd/oCPy0dS6EecE+rFF6O9uo1zl24V9J2o1pj6O YdQC5V8sv/cD2x3jySOR3xWq7w1DuHYGCdVnbre/C+wu14Sr15Pl72XI9CX2N4qmWgNeQ9sU+htE 6Wd+or45rOY3xE/AvVbx81hN7XXLIzTacQWYTj7zHfKhHgtnEvJwBebvQ/EMK6jAugD5gqcvf9NJ q/GA/AUstDEvwjKgT4DNFPZLTaG/gfZWDMnfa2qn2mdl6Fc5Jzen0RV6rm7dARaKSJw7bpRjTv4N jde/rwQfvaP8xkyu+zm6kMc1F/V7pPrm0+P4Se31Jct2GHEP9bT6hoLWSmptBWimtYk8uNYj05Df nwFZXp85ttBn8vsil6AnoFnWRPG2NZGesghzIxJPMtoO/Sz3f/HsM2V7RloLrNepryOL/OZLFIc8 bbS60xyrGdroDJpkRaGtDaJSswPel/w+1gZzs/02BxU7Qusk1gc03fUjRbo+ogTXjWiTRcgr+iBH FLVz3g09SF7XQLSHl6m1/L7Z2kctIi5Qbb+fjCuRz+eYR20cvdT3lcmOB6ArKNkZhTY1jprIb37N N0IHXMNQp2+hGc7B6F8QX9Zx5z4qdjyH9zyJGqGdb8d9h+OZ5PjfRn3LnEJtXN9RniOWCpy7URcR 37wFvKjmpe/hvazndxycIH9XTc45xYt4/3K9bU8oPXIbPWQdpg3GYVolgR2Alsnw3wPzyZFch040 1bWp6tuIdmGEHcv1mqpx4En1vcM6R4b4VH6jruPKOPiDEYE+BF+D5BrpnYHaf6ryM5zTVHPvWPv7 /OH2uZE2tzEqj3NU/FuB/Iq/jW3X4DRzkRhFuK+3r5pwnyzMryqFf3KQQZzT+BMoZ7TeE83BIjCe 6HgQ/Ib3QKfXM3HidWgP5njoZCr17yXcZys4kWzTqxZzbcptUNtOzKnFxUzldmgpf3tT+S343v49 Ccn99v3y7OPuNvJ4jp3n76DF0B+gC2z22L+D8Z1Nd34GWVa89mGfDwc14MQS6D+YE+lM5T2MSvcu pvJj6BgbO96JixD+fvX1lVfbv5MRzgZwg80Um2tx7UqbMpvfbHRZLbG52qbEZilTeZw5sdfmHpsC G7tcqspDMxl0sOls07EWvWsSnr4qh+E2I2yMmqiyzbN/fyac7TanCz+3FrpObOU6ceIcvl/t61Vd NcLqbK10TjzJVKJ1V97OnPhzTSrnSeQaA+YJhxhqLvf3T/p+wN7Xq0sf+T+JtZxuR//eliZTsv3b yINrYsz+48jfgLcOnBrHrTVxXl83XKiPEXtPpsHP1USu++NErWWiO5yahiuIYvaemti7/hhxNzLx rxI1bleThIOnJvH6mjTZVXeaXkPULHAySegzmmfVU8/pSd7/x2mBMbhVZN1wp9bEs7RutF7xv5u2 M+pGu6xq2k/+v6fDFdV0jDk1neDvdP7+9HSN+WN061/NWSk1SXmsbnQP/L+jxxt1p2ca0TnHTqZ3 HPhrPfXUU0899VTT5+CZObeLzWMgSJS68d/IJ6fmvC42/tOwtyZ9R4IjRP2mAPhy/R8iOn9X3RmQ 8/8XA/czg6P/swzxEQ39gGi4h2hkBNGoDUSjK4nScW7MaDCjnj/M6/XUU0899dRTTz311FNPPfXU U0899dRTTz311FNPPfXUU0899dRTTz311FNPPfXUU0899dRTz7+AIIrtIDwUR8+Riwxod8olir+m XRxZ6q8iOctoI/+yBvVLzDn8FzfIX2emGHUkbQO2z7ZNakcrbNsKi+OgZnSHbTvDwl20kJ6w7Qjq QjG23YA8oqdtRxrbxETbjqIp5ve2HU1drJG23dC40dJ5iKEiV2TVX6PS07Ww6t+PdrnusW0D9gO2 bVIj117btsLiOCjaddC2nWHhLurnetO2IyjRtdy2G1BcRKxtR4qMCLdtR1HXBqW2HU2JDW6y7YZi TAOdhxjqE3kcORFWA7uc2eZyZpvLmW0uZ7atsDhczmw7w8K5nNnmcmaby5ltLme2uZzZ5nJmm8uZ bS7ne8lDPakHnY2fHhpLhZSNXJZSOcgjP8KGwPJRmfqZiZBCWCWUgjODqAj/eWgiwvKpAOfK1VEu NBexF+JnDmIOwXVFiJOFsEJ1Pp8qEJKJ45Pv2FfdM/yKKSq1cvvOHuqNNM9FfmvG8gB5/0zgV3nN wXXF6i7zESZTl2cKEHrqJ81XxxV4Vh07G1qM40zct1A9VwqNQYxs6oSwcuqMODkqvRHq2lKkc/pc FeN8jnoW+RTlKtVyZeWquPKOeQgthl1ES3C0CJbMsYxTgRT9CJd343yWILVC/MxXqZTaqfrVU/M9 ZQx+CnlPLkX55kap581DiHyjFQjPVVf4VEiRyrXffo5snOmmUi5WIUUqxUyUCofruxSrdyrrR5md yxKEFKu7cpryOf1hOZB3LFPPwrVL1y3Ou7xTKUrAg+fn+iVzxW8jW+W/UD2xv6r2cZnxXTwq7yX2 c/HbzFIxq3Mc/kSy1Bar6/ip5+M45aSa2FGlVqxSWKLKocKu5+HlreuYvPsiVaqZ9nvxqdogle8o 37XHrnH8NJzHfDuOrPNL7dT9eAp+Qwur3lKmqiOyhhfXeC5do7ORk0x1/2z7/imqpPy4Y1+MFd1x tfwvRdW5mu0hxa793WEvUW8oX6VUhhSWIFSmmKfel3yTNVPV4bI2c8nNr0pvuqq7XIpL1NOXq9Ly q/dcruolX+1R5SbrSK56wkJ1j1z1jFnqWl3Sw8iLdjnIvtYXdobrV45qs9V1ZpG6V7aqU6e6Lx/L uNko5wrVanOq3kGOOl+merAlYeVepp60xC55TitX/ZQ1qfZzy/NcYzvhKtmTyHabVXWnU+Wq5KSU 615G1anrXsNjt3u/ynd2jfZ38rPr1lY7X/3CSkA+CT8L90J61PBV9Wg5qk2XqLadedon5XLOrFGm 3CJK7Z/8VGxXqJpXoa7MUe1DPk1uVToyZpFqY2d6Q/+udlHdJrqr3Mg2wD1jinpXZbT4Xk/PHmf3 9IwtzPaVlpfm+T1DSn1lpb5Mf2FpSYpnUFGRZ2JhfoG/3DMxtzzXtzA3J2VIZlFhlq9wYm5+RVGm r+rCvh77xJRcXzku9vROObenHeQpLPdkevy+zJzc4kzffE9pnsdfkBt203xfaUWZDM4uLS7LLCnM LU8ZU5HdKbO8sycn1zPCV1rqr5FUcWlOrq/EU55ZUu5BtgrzPHmZxYVFSzyLCv0FnvKKLH9Rrgdp luQUluSXe5Cbcn9uMa4sycEtfCXIYopnlN+Tl5vpr/Dllnt8uZlFnkI/7pFd3s1TXpyJB8/OLIMt LymuKPIXliHJkoriXB9iluf6VQLlnjJfKYpLlhZSLyoqXeQpQHl5CvEY2X5PYYnHL4sPOcMlnqLC EtwLj5lVmK8S5hv5cxf7cXHh/NwUXYgdyz3FmSVLPNkVKHPOtyyxktxFHl8mnsVXiMfGhZnFHhQc boMU8xFSXrgU0f2leKCF8pEyPYsyfcV8L1nQ2QWZPmQs15dS4PeX9e3efdGiRSnF+j2koPi7+5eU leb7MssKlnTP9ueVlvjL7ajSzstE5ubLeNNLK5DFJZ6K8lxkDW9FnvZkokRyfcWFfn9ujidricr0 MO+YQTjrUwcor5wKLplFBYXZBWHXQgtLsosqcnApniCnsLysCDeQeS/zFSJCNmLllvhTPPrepSUo 2E6FnT25xVnyouqkSnTkU+ZIRZdVA8VU7vcVZvP7q7q7fG06rX4qA50KcRdUIdk0fLKi5ZQuKikq zQy/KfKcyTnFi8DjluJW+FnhL6vwoxovLMzOlXEKcovKaj1QXd6FehPdc3LzMlEZUzLLyxbruRSF mtFqOsWfQAPTs8+49KEGzcRoGKu0sVIbl2hjhTYu1sZF2liujQu1sUwbS7WxRBuLtbFIGwu1UaEN vzbKtbFAG2XaKNVGiTaKtVGkjfnamKeNQm0UaCNfG3nayNVGjjaytZGljUxtzNXGHG3M1sYsbVyg jZnamKGN6dqYpo2p2piiDa82JmtjkjYmamOCNjK0MV4b47QxVhtjtJGujdHaGKWNkdoYoY3h2him jaHaGKKNwdoYpI00bQzUxgBtnK+N/trop42+2jhPG6naOFcbfbTRWxu9tHGONnpq42xt9NBGd22k aOMsbXTTRldtdNFGZ2100kZHbXTQRntttNNGW2200UZrbXi04dZGK2201EYLbSRro7k2krTRTBtN tdFEG4naSNBGY2000ka8NuK0EauNGG001Ea0NqK0EamNBtqI0IZLG05tOLRhacPUhqENoQ2yDRHS RlAbJ7RRqY3j2vhNG79q4xdt/FMbP2vjJ238qI0ftPG9Nr7TxjFtfKuNb7TxtTaOauMrbXypjS+0 cUQbn2vjM218qo1PtPGxNj7Sxofa+EAb72vjH9r4uzb+po33tPFXbbyrjXe08bY23tLGYW28qY2/ aOMNbfxZG69r4zVtvKqNP2njFW0c0sbL2nhJGwe18aI2XtDG89o4oI3ntPGsNp7Rxn5tPK2Np7Tx pDae0Mbj2nhMG49qY582HtHGXm08rI2HtPGgNgLa2KON3dp4QBv3a+M+bezSxk5t7NDGvdq4Rxt3 a+MubdypjTu0cbs2btPGdm1s08ZWbdyqjS3auEUbN2vjJm1s1saN2rhBG9drY5M2NmrjOm1s0Ma1 2rhGG1dr4yptrNfGOm1cqY212lijjSu0cbk2VmvjMm1ot0dot0dot0dot0dot0dot0dot0dot0do t0dot0dot0dot0dot0dot0dot0dot0dot0dot0f4tKH9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9 H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9 H6H9H6H9H6H9H6H9H6HdHqHdHqHdHqG9HaG9HaG9HaG9HaG9HaG9HaG9HaG9HaG9HTHkQWnAaw60 GuCGzxxolQhZyUeXBFr1hazgo4tZLgq0ioYs56MLWZaxLGVZEmg5CLI40HIIZBHLQpYKPufno3IW HwcuCLQcDCljKWUp4SjFLEUs8wMthkHmsRSyFLDks+QFWgyF5PJRDks2SxZLJstcljkss/m6WXx0 ActMlhks01mmsUxlmcLiZZnMMollIssElgyW8SzjWMayjGFJZxkdSB4FGcUyMpA8GjKCZXggOR0y LJA8BjKUZQjLYD43iK9LYxnI1w1gOZ+lP8fsx9KXLz+PJZXlXJY+LL05sV4s53AqPVnOZunBiXVn SeHrzmLpxtKVpQtLZ5ZOLB056Q4s7TnNdixtWdpw0q1ZPHydm6UVS0uWFizJLM0DzcdBkliaBZqP hzRlacKBiSwJHNiYpRFLPJ+LY4nlwBiWhizRfC6KJZKlAZ+LYHGxOANJGRBHIGkCxGIxOdDgI8FC SkSIJaiiiBN8VMlynOU3PvcrH/3C8k+Wn1l+CjSbDPkx0GwS5Ac++p7lO5ZjfO5bPvqG5WuWo3zu K5YvOfALliMsn7N8xlE+5aNP+OhjPvqI5UOWD/jc+yz/4MC/s/yN5T2Wv3KUd/noHZa3A02nQt4K NJ0COczyJgf+heUNlj+zvM5RXmN5lQP/xPIKyyGWlznKSywHOfBFlhdYnmc5wPIcx3yWj55h2c/y NJ97iuVJDnyC5XGWx1geZdnHMR/ho70sD7M8xPJgoMlASCDQZCZkD8tulgdY7me5j2UXy06WHYEm 6K/FvZzKPSx387m7WO5kuYPldpbbWLazbGPZyondyqlsYbmFz93MchPLZpYb+YIb+Oh6lk0sG/nc dZzKBpZr+dw1LFezXMWynmUdx7ySj9ayrGG5guVyltWBxEzIZYHELMilLKsCiXmQlSyXBBK9kBWB RHTG4uJAYh/IRSzL+fIL+bplLEsDiTmQJXz5YpZFLAtZKlj8LOWctI8vX8BSFkjMhpRyYiUcs5il iGU+yzyWQr6ugCWfc5bHl+ey5HDMbJYslkyWuSxzWGbzQ8/inF3AMpMfegYnPZ1vNI1lKmd3Ct/I y6lMZpnEMpFlQiAhDZIRSJB3GB9IkNV7XCBhFWRsIOEsyBiOks4yOpAAv0CM4qORLCM4cHgg4SLI sEDC5ZChgYSLIUMCCSsggwONhkMGsaSxDGQZEGiE8V2cz0f9A/HTIf1Y+gbiZdU4jyU1ED8Ccm4g fhqkTyB+BqQ3n+vFck4gvhukJ8c8OxAvH6xHIF62ze4sKXz5WXyHbixdObEuLJ05sU4sHVk6sLQP xMtSasfSltNsw2m25sQ8nIqbpRVf15KlBUsyS3OWpEDcLEizQNxsSNNA3BxIE5ZElgSWxiyN+IJ4 viCOA2NZYlgaskRzzCiOGcmBDVgiWFwsTo7p4JgWB5osBotgobRQbJZbEozNdp+IzXFXwj4OfgO/ IuwXhP0T/Ax+Aj8i/AfwPc59h+Nj4FvwDfga4UfBVzj3JY6/AEfA5+CzmHz3pzEF7k/Ax+Aj8CHC PoC+D/4B/o7jv0HfA38F74J3Gs53v93wbPdb0MMNi9xvNuzg/gt4A/afG3Z1vw5eA6/i/J8Q9krD Yvch2C/Dfgn2wYbz3C82LHS/0LDA/XzDfPcBXPsc0nsWPAPSQvvx82nwFHgyeoH7iWif+/Hocvdj 0X73o2AfeAThe8HDOPcQzj2IsADYA3aDB6KWuO+PWuq+L+pC966o5e6dURe5d4B7wT3gbnAXuDPq LPcd0NvBbbhmO3Rb1Hz3Vti3wt4CboF9M9K6CWltRlo3IuwGcD3YBDaC68AGXHct0rsmcpz76sjx 7qsi893rI+90r4u8232Z2d59qZnqXiVS3Su9K7yX7Fzhvdi73HvRzuXeqOUianny8vTly5bvXP7e 8rRGzsgLvUu9y3Yu9S7xLvIu3rnI+5ixmvKMy9L6exfurPBaFQkV/grzxwqxs0IMrRA9KoRBFXEV ngoz2u/1ect3+rzky/Ct8O32Wf12+z7wGeQTkftC+x/0JbcaDk270NcwbvgCb6m3bGeptySv2DsP GSxMzfcW7Mz35qXmeHN35nizU7O8malzvXNSZ3ln75zlvSB1hnfmzhne6anTvFMRf0rqZK9352Tv pNQJ3ok7J3jHp47zjkP42NR075id6d7RqSO9o3aO9I5IHe4dhoenFnEtPC3MOJmBcS2QE0oWg3sk pyV/kHws2aLk3cn7k81Gsc3dzY3OsUliyPgkUZp0cdLVSWZss9eaGWnNOncbHtv0tabvN/22qdU4 rWnnlOHUJK6Jp4mZKJ+tydjJw5UOHMp6dm/1rGObtO0wPDZRxCa6E41h7kRB8R/EH4s3E5+Oey3O iI0VsbGhWCMtFtFjY9wxhvwRijHTYs4+d3hsQ3dDQ/4INTSbpDVEiEyxY3TG5OGxUe4owzswanyU kRY1cMjwtKizegwnU3iEIBEHMSNkLkSiezja9YNNhENgPN8zeVLXrun7Imhi+u6IjJm7xRW720+S P9MmzNjtvGI3eWfMnLZHiKum7xHGkMm7E9InzODjy9avp8Et03e3nDRt97aW09N3r4CRJo0QDGq5 pwkNnt51dnlFedeu/tn4Mbvc31X9jyNRIY+6ykD5f7kfx/K/CnVMXc/4h6NB5pTjj18H+s981f/2 P+I/nYH//j97CFV02qCQcSnlGKvASnAJWAEuBheB5eBCsAwsBUvAYrAILAQVwA/KwQJQBkpBCSgG RWA+mAcKQQHIB3kgF+SAbJAFMsFcMAfMBrPABWAmmAGmg2lgKpgCvGAymAQmggkgA4wH48BYMAak g9FgFBgJRoDhYBgYCoaAwWAQSAMDwQBwPugP+oG+4DyQCs4FfUBv0AucA3qCs0EP0B2kgLNAN9AV dAGdQSfQEXQA7UE70Ba0Aa2BB7hBK9AStADJoDlIAs1AU9AEJIIE0Bg0AvEgDsSCGNAQRIMoEAka gAjgAk7gANagEH6awAACEOUIhIkgOAEqwXHwG/gV/AL+CX4GP4EfwQ/ge/AdOAa+Bd+Ar0n+O7Q5 4ivwJfgCHAGfg8/Ap+AT8DH4CHwIPgDvg3+Av4O/gffAX8G74B3wNngLHAZvgr+AN8CfwevgNfAq +BN4BRwCL4OXwEHwIngBPA8OgOfAs+AZsB88DZ4CT4InwOPgMfAo2AceAXvBw+Ah8CAIgD1gN3gA 3A/uA7vATrAD3AvuAXeDu8Cd4A5wO7gNbAfbwFZwK9gCbgE3g5vAZnAjuAFcDzaBjeA6sAFcC64B V4OrwHqwDlwJ1oI14ApwOVgNLqOcQSsE2r9A+xdo/wLtX6D9C7R/gfYv0P4F2r9A+xdo/wLtX6D9 C7R/gfYv0P4F2r9A+xc+gD5AoA8Q6AME+gCBPkCgDxDoAwT6AIE+QKAPEOgDBPoAgT5AoA8Q6AME +gCBPkCgDxDoAwT6AIE+QKAPEOgDBPoAgT5AoA8Q6AME+gCBPkCgDxDoAwT6AIH2L9D+Bdq/QNsX aPsCbV+g7Qu0fYG2L9D2Bdq+QNsXaPv/6X74v/zP9P90Bv7L/zSbM/v/AGTduuEKZW5kc3RyZWFt DWVuZG9iag04IDAgb2JqDTw8L0Jhc2VGb250IC9DYWxpYnJpL0Rlc2NlbmRhbnRGb250cyBbOSAw IFJdL0VuY29kaW5nIC9JZGVudGl0eS1IL1N1YnR5cGUgL1R5cGUwL1RvVW5pY29kZSAvSWRlbnRp dHktSC9UeXBlIC9Gb250Pj4NZW5kb2JqDTkgMCBvYmoNPDwvQmFzZUZvbnQgL0NhbGlicmkvQ0lE U3lzdGVtSW5mbyAxMCAwIFIvQ0lEVG9HSURNYXAgMTIgMCBSL0RXIDUwNy9Gb250RGVzY3JpcHRv ciAxMSAwIFIvU3VidHlwZSAvQ0lERm9udFR5cGUyL1R5cGUgL0ZvbnQvVyBbMCBbMF0gMTMgWzBd IDMyIFsyMjYgMzI2XSAzNCBbNDAxIDQ5OF0gMzcgWzcxNSA2ODJdIDM5IFsyMjEgMzAzXSA0MSBb MzAzIDQ5OF0gNDMgWzQ5OCAyNDldIDQ1IFszMDcgMjUzXSA0NyBbMzg2XSA0OSBbNTA2IDUwOF0g NTUgNTYgNTA2IDU4IDU5IDI2OCA2MCA2MiA0OTggNjMgWzQ2MyA4OTRdIDY1IFs1NzkgNTQzXSA2 NyBbNTMzIDYxNV0gNjkgWzQ4OCA0NTldIDcxIFs2MzAgNjIzXSA3MyBbMjUyIDMxOV0gNzUgWzUx OSA0MjBdIDc3IFs4NTUgNjQ1XSA3OSBbNjYyIDUxNl0gODEgWzY3MyA1NDNdCjgzIFs0NTkgNDg3 XSA4NSBbNjQyIDU2N10gODcgWzg5MCA1MTldIDg5IFs0ODcgNDY4XSA5MSBbMzA2IDM4Nl0gOTMg WzMwNiA0OThdIDk1IFs0OTggMjkxXSA5NyBbNDc5IDUyNV0gOTkgWzQyMyA1MjVdIDEwMSBbNDk4 IDMwNV0gMTAzIFs0NzEgNTI2XSAxMDUgWzIzMCAyMzldIDEwNyBbNDU1IDIzMF0gMTA5IFs3OTkg NTI2XSAxMTEgWzUyNyA1MjVdIDExMyBbNTI1IDM0OV0gMTE1IFszOTEgMzM1XSAxMTcgWzUyNSA0 NTJdIDExOSBbNzE1IDQzM10gMTIxIFs0NTMgMzk1XSAxMjMgWzMxNSA0NjBdIDEyNSBbMzE1IDQ5 OF0gMTYwIFsyMjYgMzI2XSAxNjIgWzQ5OF0gMTY0IFs0OThdCjE2NiAxNjcgNDk4IDE2OCBbMzkz IDgzNF0gMTcwIFs0MDIgNTEyXSAxNzIgWzQ5OCAzMDddIDE3NSBbMzk0IDMzOV0gMTc3IFs0OTgg MzM2XSAxNzkgWzMzNCAyOTJdIDE4MSBbNTUwIDU4Nl0gMTgzIFsyNTIgMzA3XSAxODUgWzI0NiA0 MjJdIDE4NyBbNTEyIDYzNl0gMTg5IFs2NzEgNjc1XSAxOTEgWzQ2MyA1NzldIDE5MyAxOTcgNTc5 IDE5OCBbNzYzIDUzM10gMjAwIDIwMyA0ODggMjA0IDIwNyAyNTIgMjA4IFs2MjUgNjQ2XSAyMTAg MjE0IDY2MiAyMTUgWzQ5OCA2NjRdIDIxNyAyMjAgNjQyIDIyMSBbNDg3IDUxN10KMjIzIFs1Mjcg NDc5XSAyMjUgMjI5IDQ3OSAyMzAgWzc3MyA0MjNdIDIzMiAyMzUgNDk4IDIzNiAyMzkgMjMwIDI0 MCAyNDEgNTI1IDI0MiAyNDYgNTI3IDI0NyBbNDk4IDUyOV0gMjQ5IDI1MiA1MjUgMjUzIFs0NTMg NTI1XSAyNTUgWzQ1MyA1NzldIDI1NyBbNDc5IDU3OV0gMjU5IFs0NzkgNTc5XSAyNjEgWzQ3OSA1 MzNdIDI2MyBbNDIzIDUzM10gMjY1IFs0MjMgNTMzXSAyNjcgWzQyMyA1MzNdIDI2OSBbNDIzIDYx NV0gMjcxIFs1NjggNjI1XSAyNzMgWzU1MiA0ODhdIDI3NSBbNDk4IDQ4OF0gMjc3IFs0OTggNDg4 XQoyNzkgWzQ5OCA0ODhdIDI4MSBbNDk4IDQ4OF0gMjgzIFs0OTggNjMxXSAyODUgWzQ3MSA2MzFd IDI4NyBbNDcxIDYzMV0gMjg5IFs0NzEgNjMxXSAyOTEgWzQ3MSA2MjNdIDI5MyBbNTI1IDY1Nl0g Mjk1IFs1MzMgMjUyXSAyOTcgWzIzMCAyNTJdIDI5OSBbMjMwIDI1Ml0gMzAxIFsyMzAgMjUyXSAz MDMgWzIzMCAyNTJdIDMwNSBbMjMwIDU3MV0gMzA3IFs0NjkgMzE5XSAzMDkgWzIzOSA1MjBdIDMx MSAzMTIgNDU1IDMxMyBbNDIwIDIzMF0gMzE1IFs0MjAgMjMwXSAzMTcgWzQyMyAyNjRdIDMxOSBb NTQ2IDM3NF0gMzIxIFs0MzAgMjQ4XSAzMjMgWzY0NiA1MjVdIDMyNSBbNjQ2IDUyNV0gMzI3Cls2 NDYgNTI1XSAzMjkgWzU3OSA2MjhdIDMzMSBbNTI1IDY2Ml0gMzMzIFs1MjcgNjYyXSAzMzUgWzUy NyA2NjJdIDMzNyBbNTI3IDg2N10gMzM5IFs4NTAgNTQzXSAzNDEgWzM0OSA1NDNdIDM0MyBbMzQ5 IDU0M10gMzQ1IFszNDkgNDU5XSAzNDcgWzM5MSA0NTldIDM0OSBbMzkxIDQ1OV0gMzUxIFszOTEg NDU5XSAzNTMgWzM5MSA0ODddIDM1NSBbMzM1IDQ4N10gMzU3IFszNDYgNDg3XSAzNTkgWzM0MiA2 NDJdIDM2MSBbNTI1IDY0Ml0gMzYzIFs1MjUgNjQyXSAzNjUgWzUyNSA2NDJdIDM2NyBbNTI1IDY0 Ml0gMzY5IFs1MjUgNjQyXSAzNzEgWzUyNSA4OTBdIDM3MyBbNzE1IDQ4N10gMzc1IFs0NTMgNDg3 XSAzNzcKWzQ2OCAzOTVdIDM3OSBbNDY4IDM5NV0gMzgxIFs0NjggMzk1XSAzODMgWzI0MyA1NTJd IDM4NSBbNjE1IDUzOF0gMzg3IFs1MjUgNTMxXSAzODkgWzUyNSA1NDhdIDM5MSBbNTc3IDQ2Ml0g MzkzIFs2MjUgNjg3XSAzOTUgWzUzOCA1MjVdIDM5NyBbNTIzIDQ4OF0gMzk5IFs2NDMgNDc0XSA0 MDEgWzQ1OSAzMDVdIDQwMyBbNjMyIDU2N10gNDA1IFs3ODMgMjg5XSA0MDcgWzI2OSA1MjBdIDQw OSBbNDU1IDI4Ml0gNDExIFs0NjMgODc5XSA0MTMgWzY0NiA1MzddIDQxNSBbNjYyIDY5N10gNDE3 IFs1NzggNzczXSA0MTkgWzY1NSA2MTFdIDQyMSBbNTI1IDU0M10gNDIzIFs0NTkgMzkxXSA0MjUg WzQ1OSA0MzFdIDQyNwpbMzU5IDUzMV0gNDI5IFszMzUgNDg3XSA0MzEgWzcyMiA2MDNdIDQzMyBb NjY0IDY0Ml0gNDM1IFs1MzIgNDk4XSA0MzcgWzQ2OCAzOTVdIDQzOSA0NDEgNDc0IDQ0MiBbNDI1 XSA0NDUgWzQyNiAzOTFdIDQ0NyBbNTI1IDI0NF0gNDQ5IFszOTUgNTc0XSA0NTEgWzMyNiAxMDg0 XSA0NTMgWzEwMTAgOTIwXSA0NTUgWzc1MSA2NjBdIDQ1NyBbNDY5IDk2NF0gNDU5IFs4ODUgNzY1 XSA0NjEgWzU3OSA0NzldIDQ2MyBbMjUyIDIzMF0gNDY1IFs2NjIgNTI3XSA0NjcgWzY0MiA1MjVd IDQ2OSBbNjQyIDUyNV0gNDcxIFs2NDIgNTI1XSA0NzMgWzY0MiA1MjVdIDQ3NSBbNjQyIDUyNV0g NDc3IFs0OTggNTc5XQo0NzkgWzQ3OSA1NzldIDQ4MSBbNDc5IDc2M10gNDgzIFs3NzMgNjMxXSA0 ODUgWzUzNyA2MzFdIDQ4NyBbNDcxIDUyMF0gNDg5IFs0NTUgNjYyXSA0OTEgWzUyNyA2NjJdIDQ5 MyBbNTI3IDQ3NF0gNDk1IFs0NzQgMjM5XSA0OTcgWzEwNzMgMTAxMF0gNDk5IFs5MjAgNjMxXSA1 MDEgWzQ3MSA4OTVdIDUwMyBbNjA0IDY0Nl0gNTA1IFs1MjUgNTc5XSA1MDcgWzQ3OSA3NjNdIDUw OSBbNzczIDY2NF0gNTExIFs1MjkgNTc5XSA1MTMgWzQ3OSA1NzldIDUxNSBbNDc5IDQ4OF0gNTE3 IFs0OTggNDg4XSA1MTkgWzQ5OCAyNTJdIDUyMSBbMjMwIDI1Ml0gNTIzIFsyMzAgNjYyXSA1MjUg WzUyNyA2NjJdIDUyNyBbNTI3IDU0M10KNTI5IFszNDkgNTQzXSA1MzEgWzM0OSA2NDJdIDUzMyBb NTI1IDY0Ml0gNTM1IFs1MjUgNDU5XSA1MzcgWzM5MSA0ODddIDUzOSBbMzM1IDQ3NF0gNTQxIFs0 NzQgNjIzXSA1NDMgWzUyNSA2NDNdIDU0NSBbNjAwXSA1NDggWzQ5MiA0MTJdIDU1MCBbNTc5IDQ3 OV0gNTUyIFs0ODggNDk4XSA1NTQgWzY2MiA1MjddIDU1NiBbNjYyIDUyN10gNTU4IFs2NjIgNTI3 XSA1NjAgWzY2MiA1MjddIDU2MiBbNDg3IDQ1M10gNTY0IFszMTcgNjE1XSA1NjYgWzMzNSAyMzld IDU2OCBbODIyIDgyMV0gNTcwIFs1NzkgNTMzXSA1NzIgWzQyMyA0MjBdIDU3NCBbNDg3IDM5MV0g NTc2IFszOTUgNDQ3XSA1NzggWzQ0NyA1NTJdCjU4MCBbNjU5IDU3M10gNTgyIFs0ODggNDk4XSA1 ODQgWzMyOSAyODFdIDU4NiBbNjMwIDUyNV0gNTg4IFs1NTEgMzc1XSA1OTAgWzU3OCA0ODVdIDU5 MiBbNDc5IDUyNV0gNTk0IDU5NSA1MjUgNTk2IFs0MjMgNDUxXSA1OTggNTk5IDUyNSA2MDAgNjAx IDQ5OCA2MDIgWzYzOCA0MjNdIDYwNCBbNDIzIDUyNl0gNjA2IFs1MjkgMjgyXSA2MDggNjA5IDUy NSA2MTAgWzU0MCA0NTJdIDYxMiBbNDc3IDUyNV0gNjE0IDYxNSA1MjUgNjE2IFsyODIgMjc0XSA2 MTggWzIzMCAzNjNdIDYyMCBbMzcyIDIzMF0gNjIyIFs1NjUgNzk4XSA2MjQKWzc5OCA3OTldIDYy NiA2MjcgNTI1IDYyOCBbNTQxIDUyN10gNjMwIFs3MTIgNjk2XSA2MzIgWzY1MSAzNDldIDYzNCA2 MzcgMzQ5IDYzOCA2MzkgMzE5IDY0MCA2NDEgNDQ5IDY0MiBbMzkxIDIzOV0gNjQ0IFsyODIgMjM5 XSA2NDYgWzMxNyAzMzVdIDY0OCBbMzM1IDU4MF0gNjUwIFs1NTggNTQyXSA2NTIgWzQ1MiA3MTVd IDY1NCBbNDUzIDQxNV0gNjU2IFszOTUgNDc4XSA2NTggWzQ2NyA0NjZdIDY2MCA2NjIgNDQ3IDY2 MyBbNDIzIDYyOF0gNjY1IFs0NzkgNTI5XSA2NjcgWzU1MiA1MzVdIDY2OSBbMzE3IDQ1NV0gNjcx IFszODcgNTI1XQo2NzMgNjc0IDQ0NyA2NzUgWzgwNCA4NTRdIDY3NyBbODg3IDYxOV0gNjc5IFs0 NzEgNjg1XSA2ODEgWzc1NiA1ODVdIDY4MyBbNTUxIDQ5Ml0gNjg1IFs0OTIgNTI1XSA2ODcgWzUz OCAzNjRdIDY4OSBbMzY0IDE3OF0gNjkxIDY5MiAyNDUgNjkzIFsyNTEgMzE4XSA2OTUgWzQ5MiAz MTVdIDY5NyBbMjIxIDQwMF0gNjk5IDcwMSAyNTAgNzAyIDcwMyAyMjYgNzA0IDcwNSAzMjUgNzA2 IDcwNyA0OTggNzA4IDcwOSA1MzcgNzEwIDcxMSAzOTUgNzEyIFsyOTAgMzk0XSA3MTQgWzI5MiAy OTFdCjcxNiBbMjkwIDM5NF0gNzE4IFsyOTEgMjkyXSA3MjAgNzIxIDI3OCA3MjIgNzIzIDIyNiA3 MjQgNzI3IDMzMyA3MjggWzM4MSAyMjZdIDczMCBbMzIxIDMxMl0gNzMyIFs0NTAgNDY5XSA3MzQg NzM1IDMzMyA3MzYgWzI5NyAxNzFdIDczOCBbMjczIDMxMl0gNzQwIFszMjUgMzgzXSA3NDIgNzQ1 IDM4MyA3NDYgNzQ3IDMzMyA3NDggWzM5NSA1NzVdIDc1MCBbNDE4IDMzM10gNzUyIDc1NCAzMzMg NzU1IFszMjEgMjkxXSA3NTcgNzU4IDQ2OSA3NTkgWzQ1MCAyNjhdIDc2MSA3NjQKMzMzIDc2NSA3 NjYgNTMxIDc2NyBbMzc2IDBdIDc2OSA3ODggMCA3ODkgWzI1MCAwXSA3OTEgNzk0IDAgNzk1IFsz MzMgMF0gNzk3IDg3OSAwIDg4NCA4ODUgMjUwIDg5MCBbMjc0IDQyM10gODkyIDg5MyA0MjMgODk0 IFsyNjhdIDkwMCBbMzE3IDQ5NF0gOTAyIFs1NzkgMjUyXSA5MDQgWzQ4OCA2MjNdIDkwNiBbMjUy XSA5MDggWzY2Ml0gOTEwIFs0ODcgNjY0XSA5MTIgWzI3NCA1NzldIDkxNCBbNTQ0IDQxNl0gOTE2 IFs1NjQgNDg4XSA5MTggWzQ2OCA2MjNdIDkyMApbNjYyIDI1Ml0gOTIyIFs1MjAgNTczXSA5MjQg Wzg1NSA2NDZdIDkyNiBbNDkyIDY2Ml0gOTI4IFs2MjMgNTE3XSA5MzEgWzQ1OSA0ODddIDkzMyBb NDg3IDc1OV0gOTM1IFs1MTkgNzUwXSA5MzcgWzY2NCAyNTJdIDkzOSBbNDg3IDU2N10gOTQxIFs0 NTYgNTM3XSA5NDMgWzI3NCA1NDJdIDk0NSBbNTY3IDUzMV0gOTQ3IFs0NDYgNTIzXSA5NDkgWzQ1 NiAzNDhdIDk1MSBbNTM3IDUzMl0gOTUzIFsyNzQgNDU1XSA5NTUgWzQ2MyA1NTBdIDk1NyBbNDQ5 IDM3Nl0gOTU5IFs1MjcgNTUzXSA5NjEgWzUwOSA0MTFdIDk2MyBbNTMyIDM4N10gOTY1IFs1NDIg NjUxXSA5NjcgWzQyNiA3MDhdIDk2OSBbNjk2IDI3NF0gOTcxCls1NDIgNTI3XSA5NzMgWzU0MiA2 OTZdIDk3NiBbNTI0IDU1OV0gOTc4IFs0ODcgNTQyXSA5ODAgWzQ4NyA2NTRdIDk4MiBbODE0IDYw NV0gOTg0IFs2NjIgNTI3XSA5ODYgWzUzMyA0MTFdIDk4OCBbNDU5IDQzNF0gOTkwIFs1NDUgNDUw XSA5OTIgOTkzIDU3OSA5OTQgWzg3OSA3OTldIDk5NiBbNTQ1IDUyM10gOTk4IFs1NTYgNTEyXSAx MDAwIFs1MzMgNDE5XSAxMDAyIFs2MDIgNTA1XSAxMDA0IFs2NzMgNTMyXSAxMDA2IFs0NzMgMzk0 XSAxMDA4IFs2MDUgNTA5XSAxMDEwIFs0MjMgMjM5XSAxMDEyIFs2NjIgNDMyXSAxMDE0IFs0MzIg NTE3XSAxMDE2IFs1NTggNTMzXSAxMDE4IFs2OTkgNTk2XSAxMDIwIFs1MDkgNTMzXQoxMDIyIDEw MjMgNTMzIDEwMjQgMTAyNSA0ODggMTAyNiBbNjI1IDQzMF0gMTAyOCBbNTQ3IDQ1OV0gMTAzMCAx MDMxIDI1MiAxMDMyIFszMTkgODcyXSAxMDM0IFs4NzYgNjE4XSAxMDM2IFs1NDMgNjQyXSAxMDM4 IFs1MjcgNjIwXSAxMDQwIFs1NzkgNTM4XSAxMDQyIFs1NDQgNDMwXSAxMDQ0IFs2NDQgNDg4XSAx MDQ2IFs4MDEgNDc0XSAxMDQ4IDEwNDkgNjQyIDEwNTAgWzU0MyA2MTFdIDEwNTIgWzg1NSA2MjNd IDEwNTQgWzY2MiA2MjJdIDEwNTYgWzUxNyA1MzNdIDEwNTggWzQ4NyA1MjddIDEwNjAgWzY5NyA1 MTldIDEwNjIgWzYzOSA1NTZdIDEwNjQgWzg2OCA4OTBdIDEwNjYgWzYxNSA3NjJdCjEwNjggWzUz MSA1NDhdIDEwNzAgWzg3OSA1NTVdIDEwNzIgWzQ3OSA1MzNdIDEwNzQgWzQ3OSAzNDZdIDEwNzYg WzU1OCA0OThdIDEwNzggWzY4OSA0MjNdIDEwODAgMTA4MSA1NDEgMTA4MiBbNDY0IDUxMF0gMTA4 NCBbNjc2IDUzNV0gMTA4NiBbNTI3IDUyMV0gMTA4OCBbNTI1IDQyM10gMTA5MCBbMzg3IDQ1M10g MTA5MiBbNjI0IDQzM10gMTA5NCBbNTQyIDQ2OV0gMTA5NiBbNzI5IDc0OV0gMTA5OCBbNTM2IDY2 Nl0gMTEwMCBbNDcwIDQ0M10gMTEwMiBbNzIyIDQ3NF0gMTEwNCAxMTA1IDQ5OCAxMTA2IFs1NDEg MzQ2XSAxMTA4IFs0NDQgMzkxXSAxMTEwIDExMTEgMjMwIDExMTIgWzIzOSA3NTFdIDExMTQKWzc3 MCA1MzNdIDExMTYgWzQ2NCA1NDFdIDExMTggWzQ1MyA1MjVdIDExMjAgWzkyOCA2NzddIDExMjIg WzYyNyA1MTldIDExMjQgWzc4MiA2NTBdIDExMjYgWzYzMCA1MjVdIDExMjggWzgzMiA3MTBdIDEx MzAgWzcyMyA1NjNdIDExMzIgWzkwNiA3NTVdIDExMzQgWzQ3NCA0MTNdIDExMzYgWzc1MCA3MDhd IDExMzggWzY2MiA1MjRdIDExNDAgWzU5MCA0NzhdIDExNDIgWzU5MCA0NzhdIDExNDQgWzEwNDUg OTA5XSAxMTQ2IFs2NjIgNTc2XSAxMTQ4IFs5MjggNzgyXSAxMTUwIFs5MjggNjc3XSAxMTUyIFs1 MzMgNDIzXSAxMTU0IFs2MDkgMF0gMTE1NiAxMTU4IDAgMTE2MCBbOTg1IDk0OV0gMTE2MiBbNjYz IDU0Nl0gMTE2NCBbNTMxIDQ4NF0KMTE2NiBbNTE3IDUyNV0gMTE2OCBbNDMzIDM1NF0gMTE3MCBb NDI1IDM3Ml0gMTE3MiBbNTMyIDQ1M10gMTE3NCBbODM3IDcxOV0gMTE3NiBbNDc0IDQyM10gMTE3 OCBbNTgxIDQ5NF0gMTE4MCBbNTQzIDQ2NF0gMTE4MiBbNTUyIDQ5MF0gMTE4NCBbNjMxIDUzNV0g MTE4NiBbNjQzIDU1NV0gMTE4OCBbNzExIDYwNV0gMTE5MCBbOTAyIDc0M10gMTE5MiBbNjQ2IDU1 NF0gMTE5NCBbNTMzIDQyM10gMTE5NiBbNDg3IDM4N10gMTE5OCBbNDg3IDQ1Ml0gMTIwMCBbNDg3 IDQ1Ml0gMTIwMiBbNTU4IDQ2Ml0gMTIwNCBbNzI4IDU5Nl0gMTIwNiBbNTc1IDQ4OV0gMTIwOCBb NTU2IDQ2OV0gMTIxMCBbNTU2IDQ2OV0gMTIxMiBbNzQ1IDU5OF0gMTIxNCBbNzQ1IDU5OF0KMTIx NiBbMjUyIDgwMV0gMTIxOCBbNjg5IDU0Nl0gMTIyMCBbNDc2IDYzMl0gMTIyMiBbNTE2IDYyM10g MTIyNCBbNTM1IDYyM10gMTIyNiBbNTQxIDU1Nl0gMTIyOCBbNDY5IDg3OF0gMTIzMCBbNzE0IDI1 Ml0gMTIzMiBbNTc5IDQ3OV0gMTIzNCBbNTc5IDQ3OV0gMTIzNiBbNzYzIDc3M10gMTIzOCBbNDg4 IDQ5OF0gMTI0MCBbNjQzIDQ5OF0gMTI0MiBbNjQzIDQ5OF0gMTI0NCBbODAxIDY4OV0gMTI0NiBb NDc0IDQyM10gMTI0OCBbNDc0IDQ2N10gMTI1MCBbNjQyIDU0MV0gMTI1MiBbNjQyIDU0MV0gMTI1 NCBbNjYyIDUyN10gMTI1NiBbNjYyIDUyNF0gMTI1OCBbNjYyIDUyNF0gMTI2MCBbNTQ4IDQ0M10g MTI2MiBbNTI3IDQ1M10gMTI2NCBbNTI3IDQ1M10KMTI2NiBbNTI3IDQ1M10gMTI2OCBbNTU2IDQ2 OV0gMTI3MCBbNDE2IDM0Nl0gMTI3MiBbNzYyIDY2Nl0gMTI3NCBbNDI1IDM3Ml0gMTI3NiBbNTY1 IDQ2MV0gMTI3OCBbNTE5IDQzM10gMTI4MCBbNTMxIDUyNV0gMTI4MiBbNzk1IDc5Ml0gMTI4NCBb NzY0IDcwMV0gMTI4NiBbNTEzIDQ2Nl0gMTI4OCBbODgyIDc2NV0gMTI5MCBbODk1IDc4OV0gMTI5 MiBbNjM1IDUzNF0gMTI5NCBbNjQxIDU2M10gMTI5NiBbNDc0IDQyM10gMTI5OCBbNjI5IDUyMV0g NzQyNCBbNDgwIDYzMl0gNzQyNiBbNzczIDUwOV0gNzQyOCBbNDc0IDUzM10gNzQzMCBbNTQzIDQw Nl0gNzQzMiBbNDI5IDIzMF0gNzQzNCBbMjY5IDQ0Nl0gNzQzNiBbMzY3IDY3Nl0gNzQzOCBbNTQx IDU1N10KNzQ0MCBbNDc0IDU4M10gNzQ0MiBbNTgyIDY0NV0gNzQ0NCBbODUwIDQyNl0gNzQ0NiA3 NDQ3IDUyNyA3NDQ4IFs0NTcgNDc2XSA3NDUwIFs0NzYgNDA2XSA3NDUyIFs1NTIgNTQ5XSA3NDU0 IFs3MjIgNzk5XSA3NDU2IFs0ODMgNzU3XSA3NDU4IFs0MTQgMzk4XSA3NDYwIFszOTEgNDc3XSA3 NDYyIFszNjggNDgzXSA3NDY0IFs1MzkgNDU3XSA3NDY2IFs2NDhdIDc0NjggWzM3MCA0OTNdIDc0 NzAgWzM2MyAzNzNdIDc0NzIgWzQxMiAzMzJdIDc0NzQgWzMzMiA0MDhdIDc0NzYgWzQxOSAyMDZd IDc0NzggWzIyNCAzNTldIDc0ODAgWzI5NCA1NTNdIDc0ODIgNzQ4NCA0MzIgNzQ4NSBbMzM3IDM1 NV0gNzQ4NyBbMzI2IDI5Ml0KNzQ4OSBbMzg1IDUzNF0gNzQ5MSA3NDkyIDMzNCA3NDkzIFszNjIg NTIxXSA3NDk1IDc0OTYgMzYyIDc0OTcgNzQ5OCAzNDAgNzQ5OSA3NTAwIDMwOCA3NTAxIFszMjQg MTczXSA3NTAzIFszMjQgNTQyXSA3NTA1IDc1MDYgMzYyIDc1MDcgWzI4OCAzNjJdIDc1MDkgNzUx MCAzNjIgNzUxMSBbMjM2IDM2NF0gNzUxMyBbMzU3IDU0Ml0gNzUxNSBbMzE1IDI4Nl0gNzUxNyBb MzQzIDI4NF0gNzUxOSBbMzE0IDQyNF0gNzUyMSBbMjk2IDE3M10gNzUyMyBbMjQ1IDM2NF0gNzUy NSBbMzE1IDM0M10gNzUyNyBbMjg0IDM2Ml0gNzUyOSBbNDI0IDI5Nl0gNzUzMSBbODIyIDU5MV0K NzUzMyBbNTkyIDM4MF0gNzUzNSBbODI2IDU4OF0gNzUzNyBbNTkzIDQxNV0gNzUzOSBbMzg4IDQ1 Ml0gNzU0MSBbMzgyIDM5NV0gNzU0MyBbNDcxIDM3N10gNzU0NSBbNDcxIDgxNl0gNzU0NyBbMjgy IDMwMV0gNzU0OSBbNTUxIDYwN10gNzU1MSBbNTk2IDUyNV0gNzU1MyBbNTQwIDMwNV0gNzU1NSBb NjYyIDUxNV0gNzU1NyBbMjQyIDgxMl0gNzU1OSBbNTQwIDUyNV0gNzU2MSBbMzQ5IDQzNV0gNzU2 MyBbMzcyIDQ1Ml0gNzU2NSBbNDkxIDQwNF0gNzU2NyBbNTYxIDYwNV0gNzU2OSBbNTI1IDQ5OF0g NzU3MSA3NTcyIDQyMyA3NTczIFs0OTggMjMwXSA3NTc1IFs0MjMgMjc1XSA3NTc3IFs2MDUgNDMz XSA3NTc5IFszNjIgMjg4XSA3NTgxClszMDQgMzM3XSA3NTgzIFszMDggMjE5XSA3NTg1IFsyMTkg MzI0XSA3NTg3IFszNjQgMTk2XSA3NTg5IFsyMDggMTczXSA3NTkxIFsxOTYgMjM3XSA3NTkzIFsx OTcgMTg1XSA3NTk1IFsyNjggNTQyXSA3NTk3IFs1NDIgMzg4XSA3NTk5IFszODkgMzc3XSA3NjAx IFszNjIgNDAxXSA3NjAzIFsyNzMgMTc4XSA3NjA1IFsyMzYgMzY0XSA3NjA3IFszNDAgMzYyXSA3 NjA5IFszNjIgMzE1XSA3NjExIFsyNzcgMzIyXSA3NjEzIFszMzEgMzA2XSA3NjE1IFszNjIgMF0g NzYxNyA3NjI2IDAgNzY3OCA3Njc5IDAgNzY4MCBbNTc5IDQ3OV0gNzY4MiBbNTQ0IDUyNV0gNzY4 NCBbNTQ0IDUyNV0gNzY4NiBbNTQ0IDUyNV0gNzY4OApbNTMzIDQyM10gNzY5MCBbNjE1IDUyNV0g NzY5MiBbNjE1IDUyNV0gNzY5NCBbNjE1IDUyNV0gNzY5NiBbNjE1IDUyNV0gNzY5OCBbNjE1IDUy NV0gNzcwMCBbNDg4IDQ5OF0gNzcwMiBbNDg4IDQ5OF0gNzcwNCBbNDg4IDQ5OF0gNzcwNiBbNDg4 IDQ5OF0gNzcwOCBbNDg4IDQ5OF0gNzcxMCBbNDU5IDMwNV0gNzcxMiBbNjMxIDQ3MV0gNzcxNCBb NjIzIDUyNV0gNzcxNiBbNjIzIDUyNV0gNzcxOCBbNjIzIDUyNV0gNzcyMCBbNjIzIDUyNV0gNzcy MiBbNjIzIDUyNV0gNzcyNCBbMjUyIDIzMF0gNzcyNiBbMjUyIDIzMF0gNzcyOCBbNTIwIDQ1NV0g NzczMCBbNTIwIDQ1NV0gNzczMiBbNTIwIDQ1NV0gNzczNCBbNDIwIDIzMF0gNzczNiBbNDIwIDIz MF0gNzczOApbNDIwIDIzMF0gNzc0MCBbNDIwIDIzMF0gNzc0MiBbODU1IDc5OV0gNzc0NCBbODU1 IDc5OV0gNzc0NiBbODU1IDc5OV0gNzc0OCBbNjQ2IDUyNV0gNzc1MCBbNjQ2IDUyNV0gNzc1MiBb NjQ2IDUyNV0gNzc1NCBbNjQ2IDUyNV0gNzc1NiBbNjYyIDUyN10gNzc1OCBbNjYyIDUyN10gNzc2 MCBbNjYyIDUyN10gNzc2MiBbNjYyIDUyN10gNzc2NCBbNTE3IDUyNV0gNzc2NiBbNTE3IDUyNV0g Nzc2OCBbNTQzIDM0OV0gNzc3MCBbNTQzIDM0OV0gNzc3MiBbNTQzIDM0OV0gNzc3NCBbNTQzIDM0 OV0gNzc3NiBbNDU5IDM5MV0gNzc3OCBbNDU5IDM5MV0gNzc4MCBbNDU5IDM5MV0gNzc4MiBbNDU5 IDM5MV0gNzc4NCBbNDU5IDM5MV0gNzc4NiBbNDg3IDMzNV0gNzc4OApbNDg3IDMzNV0gNzc5MCBb NDg3IDMzNV0gNzc5MiBbNDg3IDMzNV0gNzc5NCBbNjQyIDUyNV0gNzc5NiBbNjQyIDUyNV0gNzc5 OCBbNjQyIDUyNV0gNzgwMCBbNjQyIDUyNV0gNzgwMiBbNjQyIDUyNV0gNzgwNCBbNTY3IDQ1Ml0g NzgwNiBbNTY3IDQ1Ml0gNzgwOCBbODkwIDcxNV0gNzgxMCBbODkwIDcxNV0gNzgxMiBbODkwIDcx NV0gNzgxNCBbODkwIDcxNV0gNzgxNiBbODkwIDcxNV0gNzgxOCBbNTE5IDQzM10gNzgyMCBbNTE5 IDQzM10gNzgyMiBbNDg3IDQ1M10gNzgyNCBbNDY4IDM5NV0gNzgyNiBbNDY4IDM5NV0gNzgyOCBb NDY4IDM5NV0gNzgzMCBbNTI1IDMzNV0gNzgzMiBbNzE1IDQ1M10gNzgzNCBbNDc5IDI0M10gNzgz OCBbNTYxXSA3ODQwCls1NzkgNDc5XSA3ODQyIFs1NzkgNDc5XSA3ODQ0IFs1NzkgNDc5XSA3ODQ2 IFs1NzkgNDc5XSA3ODQ4IFs1NzkgNDc5XSA3ODUwIFs1NzkgNDc5XSA3ODUyIFs1NzkgNDc5XSA3 ODU0IFs1NzkgNDc5XSA3ODU2IFs1NzkgNDc5XSA3ODU4IFs1NzkgNDc5XSA3ODYwIFs1NzkgNDc5 XSA3ODYyIFs1NzkgNDc5XSA3ODY0IFs0ODggNDk4XSA3ODY2IFs0ODggNDk4XSA3ODY4IFs0ODgg NDk4XSA3ODcwIFs0ODggNDk4XSA3ODcyIFs0ODggNDk4XSA3ODc0IFs0ODggNDk4XSA3ODc2IFs0 ODggNDk4XSA3ODc4IFs0ODggNDk4XSA3ODgwIFsyNTIgMjMwXSA3ODgyIFsyNTIgMjMwXSA3ODg0 IFs2NjIgNTI3XSA3ODg2IFs2NjIgNTI3XSA3ODg4IFs2NjIgNTI3XSA3ODkwCls2NjIgNTI3XSA3 ODkyIFs2NjIgNTI3XSA3ODk0IFs2NjIgNTI3XSA3ODk2IFs2NjIgNTI3XSA3ODk4IFs2OTcgNTc4 XSA3OTAwIFs2OTcgNTc4XSA3OTAyIFs2OTcgNTc4XSA3OTA0IFs2OTcgNTc4XSA3OTA2IFs2OTcg NTc4XSA3OTA4IFs2NDIgNTI1XSA3OTEwIFs2NDIgNTI1XSA3OTEyIFs3MjIgNjAzXSA3OTE0IFs3 MjIgNjAzXSA3OTE2IFs3MjIgNjAzXSA3OTE4IFs3MjIgNjAzXSA3OTIwIFs3MjIgNjAzXSA3OTIy IFs0ODcgNDUzXSA3OTI0IFs0ODcgNDUzXSA3OTI2IFs0ODcgNDUzXSA3OTI4IFs0ODcgNDUzXSA3 OTM2IDc5NDMgNTY3IDc5NDQgNzk1MSA1NzkgNzk1MiA3OTU3IDQ1NiA3OTYwIDc5NjEKNDg4IDc5 NjIgNzk2NCA1OTIgNzk2NSBbNTk0XSA3OTY4IDc5NzUgNTM3IDc5NzYgNzk3NyA2MjMgNzk3OCA3 OTgxIDcyNyA3OTgyIDc5ODMgNjY4IDc5ODQgNzk5MSAyNzQgNzk5MiA3OTkzIDI1MiA3OTk0IDc5 OTcgMzU2IDc5OTggNzk5OSAyOTcgODAwMCA4MDA1IDUyNyA4MDA4IDgwMDkgNjYyIDgwMTAgWzc1 NiA3NTJdIDgwMTIgWzc0NSA3NDNdIDgwMTYgODAyMyA1NDIgODAyNSBbNDg3XSA4MDI3IFs2MzRd IDgwMjkgWzYzNl0gODAzMQpbNTc4IDY5Nl0gODAzMyA4MDM5IDY5NiA4MDQwIDgwNDEgNjY0IDgw NDIgWzc1NiA3NThdIDgwNDQgODA0NSA3NDMgODA0NiA4MDQ3IDcwMCA4MDQ4IDgwNDkgNTY3IDgw NTAgODA1MSA0NTYgODA1MiA4MDUzIDUzNyA4MDU0IDgwNTUgMjc0IDgwNTYgODA1NyA1MjcgODA1 OCA4MDU5IDU0MiA4MDYwIDgwNjEgNjk2IDgwNjQgODA3MSA1NjcgODA3MiA4MDc5IDU3OSA4MDgw IDgwODcgNTM3IDgwODggODA4OSA2MjMgODA5MCA4MDkzCjcyNyA4MDk0IDgwOTUgNjY4IDgwOTYg ODEwMyA2OTYgODEwNCA4MTA1IDY2NCA4MTA2IFs3NTYgNzU4XSA4MTA4IDgxMDkgNzQzIDgxMTAg ODExMSA3MDAgODExMiA4MTE2IDU2NyA4MTE4IDgxMTkgNTY3IDgxMjAgODEyNCA1NzkgODEyNSBb MjMxIDI3NF0gODEyNyBbMjMxIDQ1MF0gODEyOSBbMzkzIDUzN10gODEzMSA4MTMyIDUzNyA4MTM0 IDgxMzUgNTM3IDgxMzYgODEzNyA0ODggODEzOCA4MTQwIDYyMyA4MTQxIDgxNDIgMzk1IDgxNDMg WzM5MyAyNzRdCjgxNDUgODE0NyAyNzQgODE1MCA4MTUxIDI3NCA4MTUyIDgxNTUgMjUyIDgxNTcg ODE1OCAzOTUgODE1OSBbMzkzIDU0Ml0gODE2MSA4MTYzIDU0MiA4MTY0IDgxNjUgNTA5IDgxNjYg ODE2NyA1NDIgODE2OCA4MTcxIDQ4NyA4MTcyIFs1MTcgNDk0XSA4MTc0IFs0OTQgMzE3XSA4MTc4 IDgxODAgNjk2IDgxODIgODE4MyA2OTYgODE4NCA4MTg1IDY2MiA4MTg2IDgxODggNjY0IDgxODkg WzMxNyAyMzFdIDgxOTIgWzUwMCAxMDAwXSA4MTk0IFs1MDAgMTAwMF0gODE5NiBbMzM1IDI1MF0K ODE5OCBbMTY3IDUzOV0gODIwMCBbMjE3IDIwMF0gODIwMiBbMTI1IDBdIDgyMDQgODIwNyAwIDgy MDggWzMwN10gODIxMSBbNDk4IDkwNV0gODIxMyBbOTA1IDM5NV0gODIxNSBbNDk4IDI1MF0gODIx NyA4MjE5IDI1MCA4MjIwIDgyMjMgNDE4IDgyMjQgODIyNiA0OTggODIzMCBbNjkwXSA4MjM5IFsy MjYgMTAzOF0gODI0MiBbMjIxIDQwMF0gODI0NCBbNTgwXSA4MjQ5IDgyNTAgMzM5IDgyNTIgWzU1 OCA0ODNdIDgyNTQgWzQ5OF0gODI2MCBbMzM2XSA4Mjg2IFsyNjggMjIyXSA4MzA0IFszOTEgMTcz XSA4MzA4IFszNTcgMzMxXSA4MzEwClszNTkgMzIxXSA4MzEyIFszNjAgMzU5XSA4MzE0IFszNjQg MzU5XSA4MzE2IFszNTIgMjE3XSA4MzE4IFsyMTcgMzYyXSA4MzIwIFszOTEgMjQ2XSA4MzIyIFsz MzYgMzM0XSA4MzI0IFszNTcgMzMxXSA4MzI2IFszNTkgMzIxXSA4MzI4IFszNjAgMzU5XSA4MzMw IFszNjQgMzU5XSA4MzMyIFszNTIgMjE3XSA4MzM0IFsyMTddIDgzMzYgWzMzNCAzNDBdIDgzMzgg WzM2MiAzMTJdIDgzNDAgWzM0MF0gODM1MiBbNjE2IDUzM10gODM1NCBbNTMzIDQ1OV0gODM1NyBb Nzk5IDY0Nl0gODM1OSBbOTIyIDc4NV0gODM2MSBbODkwIDc0NV0gODM2MyBbNTUyXSA4MzY1IFs1 MjAgNDg3XSA4MzY3IFsxMDgyIDUyOF0gODM2OSBbNTYzIDU4N10gODM3MQpbNTczIDQ1OV0gODM3 MyBbNTMzXSA4NDEzIFs5OTRdIDg0NTMgWzc2Nl0gODQ2NyBbNTAyXSA4NDcwIFsxMDI1IDgzNF0g ODQ4MCBbNzA5XSA4NDgyIFs3MDVdIDg0ODYgWzY2NF0gODQ5NCBbNzM5XSA4NDk4IFs0NTldIDg1 MjUgWzc2NiAzNjZdIDg1MzEgWzY3NiA3MjNdIDg1MzMgWzY3NiA3MjNdIDg1MzUgWzcxNCA3MjVd IDg1MzcgWzY0NyA2ODZdIDg1MzkgWzY2NiA3MDRdIDg1NDEgWzcwNCA2NDZdIDg1NDMgWzM4NF0g ODU3OSBbNTMzIDQyM10gODU5MiA4NTk1IDkwNSA4NTk2IFsxMjg4IDc3N10gODU5OCA4NjAxIDg4 MiA4NjE2IFs0NzJdIDg3MDYKWzUzM10gODcxMCBbNTY0XSA4NzE5IFs3OTldIDg3MjEgWzU0MSA0 OThdIDg3MjUgWzMzNl0gODcyOSBbMjUyIDQ5OF0gODczNCBbODUzIDY4NF0gODc0NSBbNzAyXSA4 NzQ3IFszNjZdIDg3NzYgWzQ5OF0gODgwMCA4ODAxIDQ5OCA4ODA0IDg4MDUgNDk4IDg5NjIgWzg3 NV0gODk3NiBbNDk4XSA4OTkyIDg5OTMgNTQwIDkzMTIgOTMzMSAxMzI4IDk0NTAgOTQ2MCAxMzI4 IDk0NzEgWzEzMjggNTAwXSA5NDc0IFs1MDBdIDk0ODQgWzUwMF0gOTQ4OCBbNTAwXSA5NDkyIFs1 MDBdIDk0OTYgWzUwMF0KOTYzMyBbNjA0XSA5NjQyIDk2NDMgMzU0IDk2NzQgWzUxMSA1NTBdIDk2 NzYgWzU5NF0gOTY3OSBbNjA0XSA5NzAyIFszNTRdIDEwMTAyIDEwMTExIDEzMjggMTEzNjAgWzQy MCAyODJdIDExMzYyIFs0NzAgNTI1XSAxMTM2NCBbNTQzIDQ3OV0gMTEzNjYgWzMzNSA2NDNdIDEx MzY4IFs1NDggNTU1XSAxMTM3MCBbNDgyIDQ4NV0gMTEzNzIgWzQwOF0gMTEzODAgWzQ3MCA0NjNd IDExMzgyIFszODcgNjU0XSAxMTc5OSBbMzA2XSA0Mjc3NSA0Mjc3NiAzOTQgNDI3NzcgWzM5MyAz MzNdIDQyNzg0IDQyNzg1IDg4NCA2NDI1NiBbNTg0IDUyOV0gNjQyNTggWzUyOSA4MDhdIDY0MjYw IFs4MDhdCjY1MDU2IDY1MDU5IDAgNjUyNzkgWzBdXT4+DWVuZG9iag0xMCAwIG9iag08PC9PcmRl cmluZyAoSWRlbnRpdHkpL1JlZ2lzdHJ5IChBZG9iZSkvU3VwcGxlbWVudCAwPj4NZW5kb2JqDTEx IDAgb2JqDTw8L0FzY2VudCA3NTAvQ2FwSGVpZ2h0IDYzOC9EZXNjZW50IC0yNTAvRmxhZ3MgNC9G b250QkJveCBbLTUwMiAtMzA3IDEyNDAgOTYzXS9Gb250RmlsZTIgNyAwIFIvRm9udE5hbWUgL0Nh bGlicmkvSXRhbGljQW5nbGUgMC9NYXhXaWR0aCAxMzI4L1N0ZW1WIDgxL1R5cGUgL0ZvbnREZXNj cmlwdG9yPj4NZW5kb2JqDTEyIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQz Mjk+Pg1zdHJlYW0KeJzt23P4JFfWB/CrOnVZPbZt27Zt27Zte2JnkJlMxszEtm3b3OxvZ7O7eTfY N1nM4vt5ntu3+55Tp051VVf3P804+zniZyM/JGULuVUekdeo6nKb3CLnyLlyjaotO8sJspscJd+R 78r35PvyA/mh/Eh+LD+Rn8qusotqpOqrxrK13MkUS88ysGwsFyvCirJSrCyrwWqxOqwRa8xasq6s O+vB+rBBbBibyCax6WwGmyvnyXFyvtwkZ/B3ueApno7n4Hl4Md6O9+C9+XA+io/lk/kUPpsv5yv5 Kr6O7+CH+I38LL+N387vkQvkGLlQbv5/HeHfOv6WcpfcI6+Q++RYuV7E8iL+gBymmqcd/yUiyMtV E/mF/JJ/pDrIDXKWKCE/5w/K4aqUKqEqyDYsYsRipplhnqVYVpab5WF5WX5WjpVnFVgllpM1Y61Y a9aGtWXtVF3WiQ1nI9hINprNYt34Ni654hEnHnPLA8/M8/J8PD8vyPvwvrwfH8Bz8+l8Dp/L5/H5 fIGqx5fww/wIP8qP8zv5Cn43s1wzxw1LuGcZeXqWiWdgWXgmlplnZNl5TpaD52IFeCFWkBdmhXgR VpgXZfl4AVaMt2fFeQdWgndkJXknVpr3ZGV4L1aR92eV+UBWhQ9i1fhgVpUPYdX5UFaTj2S1+Wg+ htXl41h9PoHV4+NZQz6JNeATWRM+lTXnM1hTPo3PZC34LNaeL2Qd+CLWkS9mXfgy1pOvZr35WtaL r2F9+XrWj29gA/gm1p9vjNJF6dlgvpMN5ReyUfwYG8NPsLH8JBvHT7Hx/DSbwM+wqfwWNpvfxeaw efxetoDfz+bz+/h2Wh49HD1CK6JHaWX0WPQ4rYqeiJ6MnqLVtCZ6OnomejZ6jtZGz0cv0Lroxeil 6GXaQBtpU/RK9Cptjl5T69WZ6HXaEr1BW6M3o7doW/Q2vUDbo3doR/Su2q5uj96L3o8+oJ3Rh3RB 9FH0MV1IF9GL0Sd0Mb1E6+lleoVepdeiT6PP6JLo8+gLujT6MvqKLou+psujb+iK6Fu6MvodXRV9 R1cTo2uI07UkaBftJkl7SNFeiug6ItpHMe0nTdeToQNk6QZydJAOkadAhymhI5SidJSejrLAHUvH E9aZL6UMdIwy0nHKRCcoM52kLHSKstJpykZnKDvdSDnoLOWkmygX3Uy56RY2kG9mQ/gFlIdupbx0 G+Wj2yk/3UEF6E4qSHdRIbqbCtM9VITupaJ0HxWj+6k4PUAP0kP0MB9Bj9CjVIJK0mNUikrT4/QE laEnqSyVo/JUgZ6iivQ0VaJnqTI9R1XoeV1EF9XFdHFdQpfUpXRpXUaX1eV0eV1BV9SVdGVdRVfV 1XR1XUPX1LV0bV1H19P1dQPdUDfSjXUT3VQ30811C91St9KtdRvdVrfT7XUH3VF30p11F91Vd9Pd dQ/dU/fSvXUf3Vf30/31AD1QD9KD9RA9VA/Tw/UIPVKP0qP1GD1Wj9Pj9QQ9UU/Sk/UUPVVP09P1 DD1Tz9Kz9Rw9V8/T8/UCvVAv0ov1EtPUNDPNTQvT0rQyrU0b0zbUDLVMB9PRdDKdTRfT1XQz3U0P 09P04p/zb0xvEUwf09f0M/3NADPQDDKDzRAz1Awzw80IM1JkEIVEVlFKCJHXjDKjzRgz1owz480E M9FMMpPNFDPVKhtZsrHV1lhrnfU22MSmbDqb3mawGW0mm9lmsVltNpudf8A/5V+JSKRLKorMophw ST6RQxTg3yWVk6pJ9aRmUjupm9RPGgoeNYmaJo2TJknTsCtpnrRIWiatktZJm6RtUiFpl7RP8oiS onTSIemYdEo6J12Srkm3pHvSI+mZ9Ep6RwOiQdGQaFjSN+mX9E8GJAOTwdGEaFI0JbkjeU5cmLyT DE2GJyOSkcmoZEwyLpmQTIwWJ5OSKcm0ZEYyM5mVzE7mJPOSBcnCZFGyJFmaLE9WJquSNcm6ZH2y MdmcbE22JzuTC5OLk0uTy5Mrk6uTa//8ZXaZuPxPz31XO9KOsqPFpT/4stshLhDlxUWiiqguaqW9 bpQ2Woh2YoEoJyqIiqKSqCyqimqihqgp6oi6op6oLxqIhqKxaJKW2VQ0E81FK9FatBFtRW3RUkwU 08UsMU9sFBPEJDFFTBXTxAwxU8wWc8VCsUgsFkvEUrFcrBSrxBqxWqwV68QmsUVsFdvEfLFBrBDr xXbG7AA72Haz3W0PO8YOtVNtLzvO9rOTbE871va2421fOzEMCiPD4DAqDAmjw9AwJgwLY8PwMC6M COPtEDvMjrCTbUc70A6y/e0U28n2sRPscNvZdrFdxR6xVzwqrhEPiZvEDeKgOCSOiZPiMXFEHBC3 irvEFeJKcZW4WuwSu8V1Yp/YL64Xh8VRcVycEKfEGXGjOCtuFreI28Ud4k5xt7hH3CvuE/eLB8SD 4mHxiPQyyJRMJzPJLDK7zCFzylwyvywoC8sispgsIUvJ0rKsLC8rycqyiqwmq8sasqasJWvLOrKe rC+zymyygUwv68oyMo/MK/PJQrKobCgLyNyygqwa5obV4nHZKMwLa8L8sDYsCOvCwrA+LAobwuKw MSwJm8RpWVzcJiuGpWFzWBa2hOVha1gRtoWVYXtYFXaEmcl7yfvJh8nHjIXZYY7v6S/2vfwlvre/ VFwrM/g+/jLf11/u+/krfH9/pR/gr/ID/dV+kL/GD/bX+iF+lx/qd/thfo8f7vf6Ef46P9Lv86P8 fj/aX+/H+AN+rL/Bj/MH/Xh/yE/wh/1Ef8RP8kf9ZD/FH/NT/XE/zZ/w0/1JP8Of8jP9aT/Ln/E3 +tn+rJ/jb/Jz/c1+nr/Fz/e3+gX+Nr/Q3+4X+Tv8Yn+nX+Lv8kv93X6Zv8cv9/f6Ff4+v9Lf71f5 B/xq/6Bf4x/ya/3Dfp1/xK/3j/oN/jG/0T/uN/kn/Gb/pN/in/Jb/dN+m3/Gb/fP+h3+Ob/TP+8v 8C/4C/2L/iL/0j/glxIAAAAAAAAAAPzPCbvPdwcAAAAAAAAAAAAAAAAAAP8t9FK9TC/XK/RKvUqv 1mv0Wr1Or9cb9Ea9SW/WW/RWvU1v1zv0Tn2BvlBfpC/Wl+hL9WX6cn2FvlJfpa/W1+hr9S69W+/R e/V1ep/er6/XB/QN+qA+pA/rI/qoPqaP6xP6pD6lT+sz+kZ9Vt+kb9a36Fv1bfp2fYe+U9+l79b3 6Hv1ffp+/YB+UD+kH9aP6Ef1Y/px/YR+Uj+ln9bP6Gf1c/p5/YJ+Ub+kX9av6Ff1a/p1/YZ+U7+l 39bv6Hf1e/p9/YH+UH+kP9af6E/1Z/pz/YX+Un+lv9bf6G/17/R3hhluhJFGmciQiY02xljjjDfB JCZl0pn0JoPJaDKZzCaLyWqymewmh8lpcpncJo/Ja/KZ/KaAKWgKmcKmiClqipnipoQpaUqZ0qaM KWvKmfKmgqloKpnKpoqpaqqZ6qaGqWlqmdqmjqlr6pn6poFpaBqZxqZJsjvZG51N9iX7kwPJweRw cjQ5npz815z75FRyhqrS61SN3qDq9CbVoLeoJr1Ntegdqk3vUh16j+rS+1SPPqD69CE1oI+oIX1M jegTakyfUhP6jJrS59SMvqDm9CW1oK+oJX1Nregbak3fUhv6jtrGjNrFnNrHgjrEkjrGijrFEXWO ibrEMXWNNXWLDXWPLfWIHfWMPfWKA/WOE+oTp6hvnI76xempf5yBBsQZaWCciQbFmWlwnIWGxFlp aJyNhsXZaXicg0bEOWlknItGxblpdJyHxsR5aWycj8bF+Wl8XIAmxAVpYlyIJsWFaXJchKbERdlk fhObwm9m0/itNDUuRtPi4jQ9LkEz4pI0My5Fs+LSNDsuQ3PisnG5uHxcIa4YV4or/+H9SxVgTE1S l6nJ6nI1RV2hpqor1TR1lZqurlYz1DVqprpWzVK71Gy1W81Re9RctVfNU9ep+WqfWqD2q4XqerVI HVCL1Q1qiTqolqpDapk6rJarI2qFOqpWqmNqlTquVqsTao06qdaqU2qdOq02qBvVRnVWbVI3qc3q ZrVF3aK2qlvVNnWb2qHuUDvVneoCdZe6UN2tLlL3sJn8DnWxulddqu5Xl6j7fngNOOHIKaeddLGL nLFL7Uq73K62y+wqu8KucTldHpfb5XO5XN4/5Nsr7TX2arvLXmXP/bfOFXRFXWFX3BVyxVwRV8Lu tdfbffYGe509YPfbg66Gq+NquXqupqvrarv69k57r73b3m/vsvfZe+wDroVr7Vq5tq6la3Ou/qP2 Cfu4fco+Zp88V7+T6+a6uB6us+vuurqeaRnPpY0X0sbzaeNFN8gNc0PcCDfYDXdD3Uj7mn3LvmHf sa/bt+2b9l3nnHUFXH5XypV0TVxj1961c/1cXzfajTpXP53L5DK4LC69y+wyuqx2k91mt9gddrPd brfana6sq+jKu8qunKvkKrgq9qg9aY/b0/aYPWVP2DNunJvkJrgpbryb7Ca6qfZD+6n92H5uP7Kf 2U/sFy5xwWV3KZctbV/e5bAb7Hq7zq61G30n39U38S18R1fNlXFV0+KlXXW7x+62h+0he8S38i19 a9fcNXMNXYNzvTZ1jewj9mH7kH2QMd/Wt/Ht3EA3wPV2vVwH19H1d33sq/YV+7J9yT7rO/j2vvm5 7aa7sW5a2jzGzbDP2Kft+/Y9+4Fv5psyFoqGYqF4KBFKhlKhdCgTyoZyoXyoECqGSmFP2CsnpOVU lpPkFDktVA3VZA/ZUw4I1WUf2VcODDXkWrlOzvzjtSS7//UdJlynaqQ91gy1Qu0/rclBcnDaWh3Z LtT9S6Yq9uvvX2Ff2P+3cuRn4fpz81fya/mN/Fb+Tn6nmOJKKKkUf0FFilSstDLKKqe8CipRKZVO pVcZVMa0KyyfzW8L2IK20M/0UD80CA1Do9A4NAlNQ7PQPLQILdUD8qrQKrQObULb0C60Dx1Cx9Dp D/mpgqlCqcK//lh/Ys+z/hFV/kIe+vmYanku47C8+EdbXZY2vv8frWr/V1u1+ONMS39LP6FLXOfP lUqqcqq0Kq8qqsqqjKqiyqpKqqqqpor/lso/Rkvi2j8dUV1UN9VVdVd9VF/VU/VQvVTvX+z62l+K /ntSrb+f2/0o0jFtdFLnzkM48Mc1OUu1/T7aKnT9cbXQLS3S5jf30vBX5jcI5+46qqlq9lv3+b8u 9PiFWM+/sW2v8IufB4B/ppRMqVSUolSc0imTsimX8qmQSlKpVLpU+lSGVMZUplTmVJbz3ee/Ukqk sqWyp3KkcqZypXKn8qTypvKl8v9UZrgh9El77PsTkX7fz/2/nwd8Pw/8JzT8Hy0c/NHKoXD476mo OqsHI3Ou0pFf1cnRv2evAP/dwrFwPJwIJ8OpcDqcCTeGs6ms57snAAAAAPh1aG5chebRfFoQV42r 0cK4Oi2Ka9DiuOb/zYtr0bK4blzvvDQJ8F8h1DvfHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwL87m8PmtLls7h+s5LF5z18/AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPC/ipfkZXhTXo23PN+dAADAf5JwU7g53BJuPd99wG8Rbjvf HcD59XvYlvs5CmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwvRjAgNSAwIFIvRjEgMTQgMCBS Pj4NZW5kb2JqDTE0IDAgb2JqDTw8L0Jhc2VGb250IC9DYWxpYnJpLUJvbGQvRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZy9GaXJzdENoYXIgMC9Gb250RGVzY3JpcHRvciAxNSAwIFIvTGFzdENoYXIg MjU1L1N1YnR5cGUgL1RydWVUeXBlL1R5cGUgL0ZvbnQvV2lkdGhzIFswIDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDAgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgMjI2IDMy NiA0MzggNDk4IDUwNyA3MjkgNzA1IDIzMyAzMTEgMzEyIDQ5OCA0OTggMjU4IDMwNyAyNjcgNDMw IDUwNyA1MDcgNTA3CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyNzYgMjc2IDQ5OCA0OTgg NDk4IDQ2MyA4OTggNjA2IDU2MCA1MzAgNjMxIDQ4OCA0NTkgNjM4IDYzMSAyNjcgMzMxIDU0NyA0 MjMgODc1IDY1OSA2NzYgNTMyIDY4NiA1NjMgNDcyIDQ5NSA2NTIgNTkxIDkwNSA1NTEgNTE5IDQ3 OCAzMjUgNDMwIDMyNSA0OTggNDk4IDMwMCA0OTQgNTM3IDQxOCA1MzcKNTA0IDMxNiA0NzQgNTM3 IDI0NiAyNTUgNDgwIDI0NiA4MTQgNTM3IDUzOCA1MzcgNTM3IDM1NiAzOTkgMzQ2IDUzNyA0NzQg NzQ1IDQ2MCA0NzQgMzk3IDM0NCA0NzUgMzQ0IDQ5OCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNwo1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyMjYgMzI2 IDQ5OCA1MDcgNDk4IDUwNyA0OTggNDk4IDQxNSA4MzQgNDE2IDUzOSA0OTggMzA3IDUwNyAzOTAg MzQyIDQ5OCAzMzggMzM2IDMwMSA1NjMgNTk4IDI2OCAzMDMgMjUyIDQzNSA1MzkgNjU4IDY5MSA3 MDIgNDYzIDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDc3NSA1MjkgNDg4CjQ4OCA0ODggNDg4IDI2 NyAyNjcgMjY3IDI2NyA2MzkgNjU5IDY3NiA2NzYgNjc2IDY3NiA2NzYgNDk4IDY4MSA2NTMgNjUz IDY1MyA2NTMgNTIwIDUzMiA1NTUgNDk0IDQ5NCA0OTQgNDk0IDQ5NCA0OTQgNzc1IDQxOCA1MDMg NTAzIDUwMyA1MDMgMjQ2IDI0NiAyNDYgMjQ2IDUzNyA1MzcgNTM4IDUzOCA1MzggNTM4IDUzOCA0 OTggNTQ0IDUzNyA1MzcKNTM3IDUzNyA0NzQgNTM3IDQ3NF0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwv QXNjZW50IDc1MC9BdmdXaWR0aCA0OTMuNTA0L0NhcEhlaWdodCA2MzgvRGVzY2VudCAtMjUwL0Zs YWdzIDMyL0ZvbnRCQm94IFstNTE4IC0zMDYgMTI0MCA5NzFdL0ZvbnRGaWxlMiAxNiAwIFIvRm9u dE5hbWUgL0NhbGlicmktQm9sZC9JdGFsaWNBbmdsZSAwL01heFdpZHRoIDkwNS9TdGVtViAxMjMv VHlwZSAvRm9udERlc2NyaXB0b3I+Pg1lbmRvYmoNMTYgMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURl Y29kZS9MZW5ndGggMjY4ODUvTGVuZ3RoMSA2OTQ3Mj4+DXN0cmVhbQp4nOy9B3hTRxY/OuXekXSb JNsqrpKs4iJbcm8YW7iAC6bYFBsw2HQChBpaQkkjCQlppDdSNr2Z7oT0sOkk2YRNNskmm7YbUtjN pm4Ay+/cK8kYh93Nf3f/733v+2L7p5k5d+7cmTNnTpm5AoQRQhLahCgKzVrcvZSry18AlFcQ8nw8 a9VKZ7CxuBEhbw9CTD936bzFt31R8wBC/l6EDPHzFq2de3zJC3CtCOoPf2D+nO7ZXz1Z+BeElq+B NkrmA0HeGtcMZaiDPPMXr1xjeezYWigfQqjyqkVLZnXTSfECQg/Ph/JNi7vXLE2x2O5H6CsO6jtP 714852//+HMrlD0IyeuXLlmxsj8ZbUbop9+o15cun7P0+a9XBqB8ACHLTUCjUaQgdVzIvA5KkIs/ D3Hm6dq4NiGGRkNORhvIfPIwXULPoBvoFnoJvY2+ym3m45Xq1CdTX0q7Me2WtJ8cFkeqo97R4pjs 6HBMdXQ61jt2Ow443nS85/ib4ztH2Glypjt9zjxnkbPCWeWsc85wLnNe6rzKucf5qPN9F++Kd9lc Tle6y+cKuApcY1wzXOe5rnfdk07SWboxPS7dkp6U7kjPSvenN6R3p89xE7fJ7fKs8HznRV7ilbwm b4LX7r3Ne7/3Fe9r3r9kbMxZlLM6YLs76W7XMS7sDvf396vjhNE40a1kAemhK+k6eh6M5lJ6B32d uxBGg1KfSg3DaG51IIfd4XQ0OMZFRzPDscmx1/Gc4y3H+45vHD84kTMORhN0FjjLnZUwmunOpc6V zsudtzp7o6OxDhpNi6vNda7r8oHRmGE0ielp0dF0pc/WRuP0dHm+8PSfNJr7vC9po1mV05WzEkZj u9t5DIWd2mhw//fqgPi3EeoPqLlwL4r+9C/68gI1/fo8NOjny/Ph9xx0ip9PChE6YvjED7lPj4xX KZ9fjtBfF361/eOeT8oQ+vicjzd+4v8k5c8TY3d8hT9u/rjp4zpo9Wat7eDH7o+OIfTRJ1+0f9H8 ReUXd6jUw52HJxwef3jM4ebD8YdFhD47/Nkbkfv/lDWLzgwjZLxdeT4igegFDL3l42D9XMqugc9b 2XO6FP2F6iXDDYaHEBL+Il4nPiO+IlklZ6QVKVOaLb0iHZaJLMl5cpFcJ8+GKdbGKG+KfKoleXes 3/JbJ0Ytvyq/Lh+Wvxgof6dC/iFa+mZQzS/k8Mkci1yVv1E4JSVCiaWI0iZ6Ld1H7+HK6XX0Glgz G+ml3HA6kS6n7XQR/YoeoX+lf6Nf07/Tb+i39Dv6PZ1MJ3F13AiunrbQGxGHzCgO2WFt+lAGykFB VIEqURWqQ/WoGU1GHWgKmo5mo/loBVqJ1qJ1aCPdRJfSs+lVdB0+ggk2YhNOwmk4E4/DU3AnXoAX 4SX4DLwKr8cX4YvxJfhyfAPeg5/CT+Pn8PP4FXoOPZ2eS6+G3jfT++gD9DdUXfFXEB29Bb9O53ON 0PtbiUzv4EbSf9Cf8DdcK72SnkWy6Y/4d3QBl8NlcwV0DOJBa+iQHhlAVxqRDaWiNORALpSH8lEB KkLJqAG0Sgsag8aicVw1moAWoNPQQrQYnYXa8XWYYg7zmGEdFrCMLdiBndiF3Xg6noG78Eycitfi DXgj3oTPxudwIbwZ78X7cC9+FL+It+CXkYD1SMQGpGAJxWMzSsBxyIoTkAXHo0ScjJJwCkrHHuTG XuTBPuTFGciJ01EmHo+ycCvKxm3IjyegXDwVBfA0VIi7UTGehUrwbFSG56BSPBeV43loGF6IhuPF +HRUjZeiEXg5CuFlqBavRDV4BRqJV6NGvA6NwmvwmagJn4XG43NRK0h4Gz4fTcIXoql4K+rEl6Fp +FI0A1+BuvCVaCa+CnXjbbyJN6M5+EY0D9+MFuFH0Ol4P1qCH0NL8eNoGX4CLcdPotX4AFqPX0Ib 0CZ8EJ2DX0Nn41fx9ewi/k3+ENvC/55dzL/Fv80u4f/Av8O/y7ayS/n3+D/y7/MfsMv4P/Efssv5 j/iP+U/YlWwbu4r/lP8zu5r/C3cF9yT/GbuGP8yu5T/nv2DX8V+yD9n1/FfsBv4Idz33PP9X/m/8 1+xG/u/sJv4b/lt2M7uFfcR/x7azj9kV7BP2Kfsz+wv/Pf8Du5X/kf8Hu43/iT/KbuePsTv44+w3 fB+7kw+zu/h+djdD7B6G2b2MsPvY/YyyBxjHHmQ8e4gx9jDTsR6mZzuYge1kAtvFRLab7WESk9le prB9zMhMzMx6kYxFZMIKmogvYHHsERbPHmUJbD+zsMeYlT3ObOwJZmdPskT2FEtiT7Nk9gxLYc+y VHYAzcJXo7n4JpbGfssc7DnmZM8zF3uBpbMXmZu9xDzsZeZlrzAfO8gy2Kssk73Gstjr7HfsDfYm Po0dYr9n2czP3mI5LJe9zf7AAuwdFmR5LJ8VsHdZIXuPFbH3WTH7gJWwP+l9+gx9pj5Ln63363P0 ufqAPqjP0+frC/SF+iJ9sb5EX6ov05frK/TD9JX64foqwyhDg6HR0GRoNow2tBjGGMbKw+RKQ6uh zTDBMNEwyTDZ0G7oMEwxTDVMwz/i44ZOIhumG2YYugzdhpmGWYbZhjmGuYZ5hvmGBYbTDAtJHPEQ G8khhDgMiwyLDacblhiWGpYZlhtWGFYazjCsMqwWOIEXmKAT9IJBEARRkARZUASjYBLMQpwQLyQI FsEq2AS7kIi/xt/jo4QnJqWQWEgmERUnSSLpuF8pVkqVcmWYMlypVkYotQTzI/lRSr0yUhkl36c0 Kk1KszJaaVHGKGOVAmWcMl5JI36Sq7QqbcoEZaIySZmstCsdyhRlqjJN6eRn8rP5ufx8ZYbSpXQr M5VZyhx+Ob+SX6W8oHxAbla+UuYpC5TTlIXKIuV0ZamyXFnBn6+sVFYpa5R1ypnKWcp6ZYOySTlH OVc5T9msXKBcpFysXKJcqlyuXKFsU65WrlWuV25Ubla2K7cpdyh3Kncr90qThYXCImExuY3cQG4i +eQWUkLKSSVpIuPIOSSPFJBCUkSKSSkpIxVkGKki1SRERpAaUkvqyUgyijSQRjKatJAxZCwZTprJ CrKWnEU2kW1kOVlJVpHVZA1ZR84k68lGci45j5xPNpMLyEXkYnIJuZRsJZeRy8lV5BpyLbmOnE2u JFvIFeR6YaYwR2gXOoQpwunCPGG1ME1YKnQJK4WpwhKhU1gmzBBWyLPlhfIceZE8V14sz5NPl+fL S+QF8lL5NHmZMFeYL5wmnCG0CbOE2UK3sEqYIEwXlgsLhInCJGEyeYA8SH5P7iFvkGfILrKb7CGP kMfIW2Qf2Ul+S14ivyF3krvI3eQ+cj95iDxMesgOspf0kkfJfvI4eZI8RZ4mz5ID5HnyAnmRvExe IQfJq+Q18jr5HXmTHKISlamRmmgCtdJEmkSTaQp1UTf1Uh/NpNk0h+bSIM2nRbSYltAyWk4r6DBa SYfTKhqiI6iN2mkNNdNqGqBp1EGd1EMzaC1Np6m0gJbKG+Wt5G1aBx7ApfLZ8mXyOfLl8rnyFfJ5 8pXy+fI2ebN8FXmCZpHnaKF8gXy1fKF8jXyRfK28Rb5Ovli+Xr5EvkE+U/mr8jfl78q38np5gzRV 2i5Nk26VOqXbyL00Tpou3S7NkO6QuqTfSN3SndJM6S5plnQ3+CT3SHOke6W50n3SPOl+ab70gLRA elA6TXpIWig9LC2SeqTF0g7pdGmntETaJS2VdkvLpD3ScmmvtELaJ62UeqUzpFXSI9Jq6VFpjbRf Wis9Jq2THpfOlJ6QzpKelJ6S1ktPSxukZ6SN0rPSJumAdLb0W+kc6TnpXOl56TzpBel86UVps/SS dIH0snQh+EgXSQelLdKr0sXSa9Il0uvSVul30qXSG9Jl0pvS5dIh6Qrp99KV0lvSNult6SrpD9LV 0jvSNdK70rXSe9J10h+l66X3pRukD6QbpT9JN0kfSjdLH0m3SB8r9ysP8k8rDys9yk5lt7JX6VUe VR5THleeZKXsM1bGDrNy9jmrYF+wYexLVsm+YsPZEVbF/sqq2d9YiH3NRrC/sxr2Datl37I69h2r Z9+zkewHNor9yBrYP1gj+4k1saOsmR1jo9lx1sL62BjWz8bqEBunw2y8jrBWHWVtOo5N0PFsoo6x STodm6zTs3adgXXoBDZFJ7KpOolN08msU6ew6Tojm6EzsS6dmXXr4thMXTybpUtgs3UWNkdnZXN1 NjZPZ2fzdYlsgS6JnaZLZgt1KWyRLpUt1qWx03UOtkTnZEt1LrZMl86W69xshc7DVuq87Aydj63S ZaAz8DNoFX4WrcG/Zat1mWyNLout1WWzdTo/O1OXw87S5bL1ugDboAvq8nT5ugJdoa5IV8yt5G7n zuDu4FZxv+FWc3dya7i7uLXc3dw67h7uTO5e7izuPm49dz+3gXuA28g9yG3iHuLO5h7mzuF6uHO5 Hdx53E7ufG4Xt5nbzV3A7eEu5PZyF3H7uC1cL3cx9wh3Cfcot5Xbz13KPcZdxj3OXc49wV3JPcVt 457mruKe4a7mnuWu4Q5w13K/5a7jnuNu4F7gbuRe5G7iXuJu5l7mbuFeQWfiF7jt3EHuNu417lbu VZGITOREvUhFnciLBuEC4WLhImGrcKFwibBFuFRMFtPEVNEppogO4U7hHuFu4T7hLuFe0S1miF4x S/SImaJPzBYeFHYIDwu7hIeEnUKPsFusEKvESjEkDhOrxeHiCOFF4aDwsvCa8JLwqvCK8LrYJLaI o8WxYrM4Rvi98AfhbeFd4S3hHXGC2C5OEqeIE8UOcbI4VfhInC3OF+eKp4lzxAXiPHGh8BfhC+Gw 8JXwmfCl8LlwRBRFQUwXXWKO6BdHivXieHGc2CXOEBeLi0STmCDGiVbRLFrEeNEmXCVcJ1wj3CBc LVwvXCvcKAbFQjFfLBbzxCKxQCwReoXHhEeFJ4RHhMeF/cKT4lJxpbhcXCUuE88QV4irhb8L3wvf Cj8K3wg/CN8J/xAVURYTRaNoFyUxSbhSuEK4XLhM2CZNkCZLI6UmqU0sEwNiqZgrlgsPCPcLe4U9 wj5ptNQstYiNYoNYK9aIo8Q64ZDwpvCG8DtprDRGGifOEmeKneI0sVVsE7vF6cKfhU+FT4SPhfel Vmm81CiuFZeIa8TTxXXCH4X3hL8JfxW+lhqkUXKGnClnydmyX86Rc+WAHITIKl8ukAshvnpAfpAu l4shdl5F18ilchmdQqfSmXI5nU5n0FlyBb2MXk7PlB/iKuQqOk6upj/IO+hReowep300TPs5xGGO cJTj8IcczzFOx+k5AydwIidxMqdwRs7Embk4Ll4eIdfItRDR1csj5VFyg9woN8nN3Ov0Lnm03CKP kcfK4+TxcqvcJk+ge+l2eZKuivNzeVwul88VcsVcgCvhglwRV8qVcVlss244N4lr5yZzHdx0bgY3 lZvCTeM6uQlcFT2LG8uNlidzNXKHkRjtxkRjkjHZmGJMNaYZHUan0SXvkqdzE7nf8Qb5EflReb/8 mPy4/IT8pPyU/LTRxjbqStgmdjY7R1eqK2Pn6srZeboKdr5umK6SXair1oWwHwfwKFyGmxEjghok YhSNek/8YETgV/0hp4rRT6r5//84E2kRog2iwwY0Di2GqI9C3AfqHOI+C8R8Di3qmwFxnxr1rYWI bwPEfOdA1LcPIj6I90DS7tAi1SvomfRKfB29ld5Cb8PfEB1XA5HnBG40N5IbxTXQh7lWrgXmuY1c zI3Br+PfceMhstxMx9BmrpEbyy7jarlxdD5dQDsQhfhVD5EpRGiajKtSDRLOhbiJEFtu4DLpXXQ2 naPOJsj5WXQmncVVQLzrgKjXBbFuJMbN0+JbBHGuGtkuwHPxj+Bty1HPO5s4SA4+/us+26/7bL/u s/26z/brPtuv+2y/7rP9us/26z7br/tsv+6z/brP9us+26/7bL/us/26z/brPtt/tc8GP7pbIFbf NiiYPBt+b0L3oz3oUfQ0egm9ib7FAupC56Mn0SfoC/QNOoYRREQWnIKzThW//2c/4XP5xUimT0HE ZkOo/2j/5+F7+z+HGFwZRNkGJRvnO0Hpj+s/MpQW3hbuDb/KwAvX7jWRl4H6NT7Sf5RUq+X+ErVM LlDz2h1f624JPxzeflJ3lqLl6Ay0Rotnz0TrIbLZiM5Fm9EF6EJ0EfBiI+QvRpegrehSdBm6HF2B rkTb0FXoanQNuhZdh65HN6AbgY83o1vQ9ug1tXwL/F6jXVWv3I7uQveiByC9A/0G3YnuRvdA+T7g /gPoIaBFKJHyg0C5Fd0G1LuAqtZSaQ/Dbw/agXaiXWg3zFmkHCv1oqfQXrQP0kdgNvejx9Dj6AmY x6dgZp/RaColVv7nNSOfz6ID6LfoOfQ8egG9CJLxMnoFHUSvotf+oyu/HaCopdfR79AbIGuH0O/R W+ht9A56D32A/oQ+RB+D1H31s+t/gBrvQp33o7U+glp/Rp9DzSNQM1IvUueP2tXDWguH4N4P0acQ lX+PCTqG+iGnzt412gxdr82jOnvq7PxG47M6Hw9DWZ2huwfm5kHg8YMwn2pJzd8QnY2HoO4O4GCM f6fm2qvR2Ynw+zGoo/JCvXIwyovnozOhtvPEwL0va9d2avc9M9DqCY5GRvj7Qdz54yAe/hn9ReNM hHuRqye4p9b4FOqoXFbbOJm3H8O9Ee6r96r0wfeo196F8uegHb4CTqvpl9pMfIk+G8h/Fr1+BP0V /Q19r31+jf4O+uRb9B2UfwDK11D6OXUo5Uf4/Qf6CR2FGTyO+gaV+oZc6UNhmGOEMSaYovCJ3Amq htgujx4bsIAlLGNF27XSDbkiDlwx/+yKdIprBo0Sh+NxAuhLG7bjJJwMejMVp2l79+mDriUOXIns MXmwN3rNqt2ZOHCvugtlG1Q3C+fh1fCp6vUg5PNxES7GpbgcKLlQLoByBVzL09IaNA7NRIvQUf4w eQXaTwCtsiM0csb0zmlTp3S0T5zQ1jp+3NgxLaObmxobRo2sr6utGRGqrhpeOayivKy0pDgYyM3J 9Hk97nSHPcFsMsqiYNDrGM9RglFOvXtkl7PH19XD+dwNDblq2d0NhO5BhK4eJ5BGnlynx9mlVXOe XDMENecOqRmK1AwN1MQmZyWqzM1x1rudPQfr3M5ePGV8O+S31rk7nD1HtHyLlud8WkGGgssFdzjr 7fPrnD24y1nfM3LV/C31XXXQ3g5RqHXXzhFyc9AOQYSsCLmeTPfSHTizCmsZkllfsYMgvaw+tod6 67tn94wb315fl+xydWg0VKu11cNqe3RaW84Fap/Rxc4dOU9tuaTXhGZ2+aXZ7tnd09p7aDfctIXW b9lyQY/Z35PlruvJWvepHYY8pyfHXVff43dDY82tAw/APbzX5HZu+R5B591HvjqZ0h2lMK/pe6Rm 1SEOsAmux/II+gY9hPG5XGpfLu4NoZlQ6Nk0vj1SdqKZyTtRKOjv6CFd6pWnYlcsE9Urm2JXBm7v crvUqarviv6tmm/v2TTTmZsD3Nf+vPAH15091Nc1c9Z8Ne2es8VdVxfh24T2nlAdZELd0bHW78gL Qv3uLhjEApUN49t7gu6lPQnumkgFIDjVOVjQ1q7dEr2tJ6G2B3XNit7VE6yvU/vlrN/SVRfpoNqW e3z7I6iw/8MdRc7kXYWoCHWo/eix1sKk+Oq3tM+e2+PoSp4N8jnX2Z7s6gl1APs63O1zOtRZcpt6 sj6Ex7m0J2p3wdiG1I5VVkeu8+qd7SSZdqizBQTnSPhw11TCBRNMl1ZUZ7Sm0tmOk1GsGjwlWkPN ndQOFKi3tkG9RNVbaxuSXR2uyM+/6FJytE+8t0c/qC0TEAb6FHnOP+1apLbaoSxn/Zy6QR08qVE+ 2sFoa6fuJ1F5EX0w3KFXp7Mhdol6YeUCjUAzGkmdRbuzB41ztrvnuDvcIEOhce3q2FRea/Pb3OZu Hj+lXZvtqJRMOKkUuV4WKfUgF1yOFUgtyOBIf3JsWrXyKK08UGwYcrkxdtm5Re9ubtuiNu6ONoic sIJg0MzX2H1xWVwRLM2RoN3cI7vdTpNz5Jbu3v5NM7fsCIW2LK3vml+htuFunL3F3dZemaz1tbV9 ffI69VFxqBk3T6jJzQHdU7PDjS8cvyOEL2yb0v4I+LLOCye07ySY1HbVdOzwwLX2R5wIhTQqUakq US041YLaUisU9Fr95EdCCG3SrnIaQSvP6sVIo+ljNIxm9ZIIzRSjEaBxEVpIo6k/MEn2+cBiULf1 ztnq9JzVMX9LV4e6uJAVphL+cA92V6Ee4q7agQmTegT3nJoe0V2j0qtVenWEzlS6DgQDbCEwR9VJ W7rcoKdAoNpRMo6IIlWbdPb2909odx1MPtLhAlGbBpjS3mPwg+7nvU1Qb5SKLiCP6tk0q1vtB5rY rt6r8zbO6gCxjTUIVRp7DNCCIdoC1Bip3aOKI9w0C+YGJlC7fxMUejZ19HT41Ye2L+jQxNnUgxrc FTDtkTZ5n/qgYMeWOHeBtjZhKQjeC9TEAH1Dbe0RSjIU4WEdESbpJOj5LDdcmtXlBG5zaFYbiHpE lwrJEcocUImcb44GITl6EanDol5RFnoMAWgQ/tS8GFCXJO/VdXREOq+VLohWgGebekTokW8QK6M3 AHfgUqPaF/i7ALqqVn1abWZ8L2p1rwHNonZaa0kHl3tkb2M3KP/I/SJQ3GWxm/WqjhCjbRyIUHXq yCXgO/VO6O2/273WNegnN8etGgdVMFHyIyDYqGPLUELPVH9ujn4oVdbIW7bo5VPfEOGXXh5IgQih J0SlK+h7EEVSpEPl2jnhhMeQjG+GULMCv7y7rk6fq3sCigQ58ctIDy7lzaF4jsjJydXuYnYJHW9u rNZdQiag6r4P3n8OPg7GlQcP4uD7R946Yup7zlwePHLoSH4eNrvMGhIUotMx5k4PkOIMX0lhYUEV KS7yudMVotGKSkqraGFBGqEJMUoVUcuYvnd8LK3v85C1rmFt+Tz2e22OeL2eOtJkb6HT2NziLslM 4jk9o7xel1FS4564uin9VcGekZKaYRcgTU2BtO8ZXjn6Da8cm8zVHXuMHC5vr/KwtbJIeIP+5sw0 iyc/ZXizbJR5JdmWlKLTmxUhu6G77/okr00QbN6kFK/alrdvGHDE1n+Ue5ZPQOnIhz6CZVw7Eeys p//wbtGIR7t7+w+H0tScV5LddhlZsWL1iYI7XUBOzo3Nbp+3F2eH0kIiknAclaSMVI/bnSbIVuRO t+viUlvjJvITkb26ujrOVl5mLjQDZ8GHLUxqOVKAE4PTO5PsBwsK119w4AC2H5jeGcnm5yG/P/nk buxRM//N0/Lz/P4Or9UambcM6tIp1J3u85WU4shk2XRu6uJ2SMxall9YniZxk8NJrZycWuwPFCUw CV/GTO6qwmEjM8zsGbwPL5npybbw1GCSMdenxIscs2W7ubPMFpFS0Rr/XN+7II9bEeJKQDLTkB+V oe0x/jrItj1JosUiol5y084cX2EvWbtTTMroxXRXfr7O0xsduKcXe0MG0/giu1oq6sVZO0O6CTBA GJC/+ogfhnekHAePFASPgJDGlYOQJu/4D5vJz+sAwebcrnRfsbmopNAFLLGokp5GcVGAuN1mVczj T2S5El9t59KNY8L3uHJzXbh+9Z3LKu2BWn9pZ31m+AF7XuPw87eV1+Vaa9MqpjTc9ERpc6kDn1e/ dFJVZnxGDjc/JyNz/FkTgm11RSahYOxp+E8ZVVnWcE9ysLrvp9xReUnhy225ter7YWP7v+Qk3g0r ++II/3amIP8T5HmkIDvuRi7kiw7T14u7dsa3cRBW7CvO08aa14tn7gwZJmlj7fMfOlKtfgDHDoGQ JT/2nzYAvPImKBEFUBRXUgLiwyzRta5qAUtCGlFZpIoVJ1EmWKunnlF3/lvXjGu/5f3zS2ZPrEsW GOUExWAMNM4Z2bJ2Yk5w8pktI+c2BmVB0nMHEt2JcTaPy9p6x3e334nRQ1PiUn3JcSm+lLTsJMnt d1efcdf85XcvKnZlOvV2v/qWnSppT4GkxSEHWhbh05MontwIKjSJXIkMyB4dpL0XB0IGZXyyNr7k XjxhZ4gfJAw4ouxg+f3SOyKSQ06SHH6QnDzV+dBPD4Rf1qRk9IN/v3NS+Gv/jKvXnn/Roqtm5ZMb dvbd2hwRiPHbv7hj2i0rRxy/vGzZPTDzMCZ6CYwJwp/IiFTZJleGjIZ4Z7wTxpRkl6FHSY/iLHUO 98q4xedjiTGxT9T6LY/P0PoNqyKwM8ROFnu/Ol5YOOXBoElVEcl7/xdNRsSD/GwpuV3mIVkYnmA0 9K1SeUM2GxSB50EowgX4AoNRzRsN4bX4DTU/DwyAGGGTkJiRBmZADB8QbWAYfDYhvE20Z6hrZWv/ UToLOJaBHolyTBffS64KWeVUlJaqyzTiFp1dkvFonUmE7KN4Morv/3ov5OPjE1lv/4e7oAbTRqvg 0awXT90dSh+fqOlUdYjRAfpVrh0wl2ssC5n/h+0OyNJgTsWsaIyXMEQRuNSBtxoUkdfyKyRHQYav ME0GPnarVO72tCy7FP6NYM9MS8tMEsNpoklkDD64q3MyxMRs4FZj/xfcjbwHVaP3ItzalZJitIOE 7UQZxv3keogyYQ2oXbdD13fJWvr1LklNccbu9PTyYNV+HAQPRIjKhwAjCxnK2xI0+UjoxTN2hoKT YvKhqg7VJEUYCDroCBRiS+3/zmNi/DxJMZWUmsHyaU6JxmWzqvdPuCkcMMUgG+SKrvPbp1+3qGLY aVdPyZnk/T4uQRVOvMeUGC9YRnTNW1B84/f3Tenq+en6CVvm1SVLXH1qdqLgyfaMWH33nCX3Lq9I SMA5uSUpPpsoWh0JfX1puUkpCULHvd/esL1vx3Sby5dSGJFZbiN4IEH0Wsw+BiMC440KjieaitFU iKYI0t2QuqVesm2nzSNCAr6BLbvVozHGsx/PAudRAicmQS0bJYdEJPAbTvIUNBfBr3EOBw8dKTBF fAX1Jzlk+I/biikBTXAHy3DELFiAFstyG+W0Al9GYaocTpHSInIspxX6MgrSJPypnFqY4StIkz2C SWAMPojY930szz0Xy4W9+L1YPsJVfDVw1YKyY1xF5Ko9IcHUGuksDkI3Qfh2xQgndTjWNXy1HOuQ o0Dt0IlunHg0iurqCfC8JNQce54FFI+IDMZWi8ZBSy/uHKwtcfCg+vzQP61wshodYJuqACaAahT6 HnblRtkk42uBwJ+elpUsgZK8NtazY38TE7Mi3GDLQC9WoncivQuJcl6eLRgUAnZ7Ui+ZvduTL0kC ZPYhT8n4REm078e5MN+B/q93m9xkdD6syJBTzdlM6qcc+bQF8/IDzJE53jFxQAhU31MVHtXpLCiI yJS50KR+mMuHBwsLzYUw7D3/26ecNHlurLq24ORi90m6U/NycaHq72q8ZMvE1DyvJy9FIuGLuDhH Xnp6niOOhq8hYloQ6KliSe4DgZo8p4TtHE6XHVll3h3JGYmDZCD12KeyWaC8qldTjn0yQD+7sMTo Ls8+3kdxdoXHqMBdUfvE9fJxaDjaE5mHvRlGIWA0JvSSop1pgQJIdqO0stYslRFxRh8ZnZUZSJdM ak4SmbEXr98H9k81HQHIn5AWde2VgxNc7gfNV35iJQfNEXbv/B+0GeNxhLU+X4bbarX8nMHxadRW 6BskslyvKdkbv9Rd6M9MDD+RUmEjHCcmBzzuQJJQmrnVV5TliT9u9Wf64jClUkrAkx5IFKbZQO8o 3uoC0lmyfljDZaP7pgoRAyZwFweDclpxRjjD39Y2LnPkdfVkhmCSeF6CpUjQuP7P+UTei+LBCxjw BBPIM+AJpsGngBJPODPTYPW1ue2RIEtdffykU3mCv/SOQdYmFvJqjuAgl5hPHHfL59df+9E1zZDe sO2ja1vCXzlbNnV1nzPO5Ry9qVtNyTW3hXd0jr396P03H+uZPub2H/fOvXv1iMZ1d0w97d411Q1n 3an6uyBJFFZ0CspCm6K+joftJ9uQGaWSp0MGZPZqvYSQ0b+LMcndOxBNYv/ukGW8NOB9aLZSlZio D/h/dmNs0O6hfgo32Ammdec8vmlRVJlK+Zk4P9C2cvWEnPCRvJEtWUtXVU8sSaHnL75nRWV41sAq uiQY1NmqZmycWdeeLYYb04dP1ObXym+D+c1Aw9DWqN8iuOIye8kzO1EKLKFndse5BDk31u1cddJE W5uXK9XGVapNmxybtkMHNb+1POaQlKs24T+4H9jARxmQEd0biS0ALYrk8VBJ2KaTFL1r4VlnlwbO HReTiCv+dP1YW04oq6prRIZVCC8fKhtnenLsOk9td7XF0XL7sQdvPvbw9DG3/XDP5OvPWZRVUpYi WwrJH+bctXpEw7o7piy8T5WWu6LS0gLSUoLq0M0Rnu02BcxZwn7yHKyLUnLjzqxqs+pFpARMsYGb IGzeFQrZhscIwyFy3htyjbfFlPCADGhB+KEjmt+lMnDHf9bKIC2eQQP0ZyJltaXRaExus1mtuMiX 4fPFJKxFn1ZRkF2QKnErLZn5oezWmLBB2DW2sCZ5zPrJAVdoemVqYW5m/GKjEH6woiahMHfV5rIJ ZSnpolEArWSWsCt/dGFSOH5ABq/NyeCoWDJ5dcuIhROq4pXM8sZAv89NZ4fa43gWviI5v07V7NX9 n0Mw40WNaH/M/o8g1+7xFHgKpGR1lwNJAdXYlSIB5+41l8KvtTLGkspenBuSRiTzWW1WTcasvbh9 sGpRFbHfHAnTTEfUparFbEe0ID7wP2r2hPbiYqIb2dkLsGh5aJDP6CWjz3loVu2K9mFJIgdhmlI4 bklj3ujilLyWmfNntuTVn7G9IzBtXFWCjidUJ4ti3shppf6Q3xIcO3v+7DF5+Ly5N8wrsjrSk/ID juwk0ZXpsmVX+XKq8/15wyeuHN+5tTOg2NMSFJs7KTUzSUpxJVu8Ran+yPUVwHcJIr4vQLLT0cSo FkQMIr5ddjOLi/EhTou3UgcprgIcPNB3UBXUf1nrRDR2wpONLWzND/tCC1EfU70w1UcMPyZEQliB Xq4GrdztqVmJ0rEjA8IULyVmpaZlJ4pqAAa9v6T/c+5B8Br9aHKk948hJ7kcVqQVPHlJ8LWaWgd2 HaYNnrnqmHEKif+i0mB7dMKDjOqfQQb6wZEXvnDOumc2j9KiSHAnfaNmDa+aWeeV1IHlgxf+8erH zqkbftYjZ9GBldHHtSxr8voaF9ZRcbAnbAVdcxeMyYPaovtVKBFczJa9IU+iU0q0qfG4GJITHa12 Pi7qe8eVV+PEoP0QdDuuPMn0fhIkMLh9Q+qo+kFz7TjV/9D2nWIOXYHVynTUzJs8VQWZ5ZmJZgMX 3ijxiZUlgaIUkcfDMC7mpNSSYKAwXicF1G1KzOkls8ydqe5jckKC8XgS/chskbSNTBiHv/+oLgHG UYk2Rn1mQ1CQUGVengRGpiUkVEo2u+x1u6X0XnJ1KC5kl0pbs1vz3CIdshNbPWhwicHy8rhyu+mQ lo8rj+jLkPGf3jowZlCJbhpzbAdGH18YH92+jeZUPvB/YpbsmsLy+sw4/jVygI/LqC2tgAILv2sg ieWFwdIUgX6Cv+JkR0luXrlD4b4jn1AhpSiYk2+lhlp7qpHnjal2WnT8FVuqSctzCzxZVp6Klvjj LvqHeLvMc7I94Xgm/aPJJvO81e8Fnrlg7uu0WHZjTJ7TyVXIjjxkXEgI2IIBO/wiSY04QlbRKUQ4 h0Sn2y1mtbpFc2qr+UQ0qUlFYTDJDhLRciQqF+XahlVEYYH4n+oulWcndrrpwEb3ILYN8ApzGXGi vbosWOJQ+G+/YYqjNLeoPEGKxyXhD+NkW1V5sNQps0/eZxCI5hZUWEVz+MNZ7mwr4wwmCb8ZzpVM Bo5Zs92kmMR7/CBLQA9PwA+odN6a7en7GjhjAs7YgTPZqCVmH2zk6p2y5FT3vrOTkboshJDkbU1m ca1sYFVAlNpX/v4R01vqaPcNuaqu7xOqadDorFZbYUlJ6cAgyXWRQNEhhW+JF21VpYFSp1F3uSXL QuIz4y/ljWlF/vJqmxSHvwyXxxYzfp487c2C8YhxSviZwNyykrkBXGmKlzjeku0Br2IU2LxV9G1U iEI4K7rWDbaiXjJ1N8rIQBW9pD5kMlMb/taGbb1SET5ehIt6+58KGdStsqKiwIjsXmwPJX+Yjun6 9K3pJJQ+Lr0rnRrTHelE4tLTudTe/g9DigS6LdVuwi2pRwNNqh8RMkBh+KchqYVD9mDM+/ZHth86 O2d0avs//s5lRzqXgaI8UK7ubkbW2f/HvdE8HFUwIUAqHuQmFhZHvcMohdMUsy5iZ63qlhVdleDP zs0yl26dNGr15Lzha3evnmzOGJFXPWt0oUk0i0xIGTl9ybAFV3fl/Ng1fFJJ4qjq4o6AQzHpdCZl 1LAab+OihjErmj0l2dXZCSnpKUqSz+bwpLrT4rMmbp72bpyn0FUWKilS99I3gFVC/FKQ1eHomui8 Cq6S/aQLWZCfnAfBhUUoKXZxfF7MeOb14uaQ7GtKHmkaXa4Zo/Je3ATGqGXAGKlusq08Gmaok7H3 P21jkFnLsPzcvkX0YSzw0pmtVs0/REUzL5uaO2ZUvQeMb5ojK1GQIPr35qVK6XV1DZmztkzODB8z Z9cWJuYVlqQVdxfn1+Um4K9WP7G5weyryOrWPETBKPLuWCAajk/PcyhjN+86o/y01nwlvSQz/Ie6 UQXj5sJ6b+j/grroW6g45m/vTEEZT5CV2qmNAzkGDvc8vdixM76JexQ3oHyQRlHELfk52vBzevHI nSFDS+zwxT9wfHOgIHp889+1dNI5TszDYxEHjw0+xIGh8Dp7RdPkwLzti0pr1/xmZmZLbbHVwNME k9lX1FAwc35SYUthUXOZTzZIOq4nyW032lxJptD63Ss3P7upCpw4q9HuTqwIguhde2XD6U1eh88h JGer8tYMeuQVfjHyoXJ0dZRbYnL5fqJ+qT5IloeEeNdIsTwjmVOyY8ICa7UxZLA3DZzpNe4OKS38 6JjvFpGUiJsUWfqG/7SNwXtLg9cshCMDQkd9vsGxXSl9RbBnpTkzE8X6a6fN3dqRWTjzyhnN6ypF TeRSpKMls0ryR/ktcVl1RUn5hSXO9Jh4zWpqBYmapYrd8GH4k5is9RXVNeS3zikuO62twJhemqny rQn4thf0rx8VYT4aCcfHu3J6Se1OfxHXq3LORXPic0hyzrOcqupsMm5BnIkjo8dxXRy5levhCMel BHsj++9qGnJCneCnvib7D0gxKcRMFYNdwi0GO1Qw/BRKiQmR/xCotyNRTde5bHqn/8j0TjUOfD+6 rR8y/L/7bE0tMLdrkNxaTpZuYsko0eZJR/dmefo+Sh7WOaJmdmOe0SDpKeH0csWUlTWrd60ZVrXq 3tOWbp+b9x2dOiNvVDCR4KOBnPLOEenxtnhdnCvR6rAaFbvNXLnu0fWrnzx/ZM0Zt053nrbWM7wt CGs/sf8ouY5fA57jiuisWE0IgsAZu/KyvUIvTt1VMirJ13vi1NWxN5TX4BxtahiIhwuqYZkfKOw7 UHhA24ESfuFNQ887LBEusMGhdOzsozB23kGu4/QC05kT023JGUnSHWrokhB/h5RS4PHkp4pL4+N5 IC3xtKwenzEyUzFw3Dep7nidTq8ze4f5WwVbZmppsC8gRI7sBPJGsDQ10yY0T71oakA2yokZiKLk 8DZ6O30TVaExaAYmUY96rDFPR8vcTYVNzzZRRxNu+uhFCcOMSy+24bQ2bG/DbX8/aME2C0YWk4UY LZauMvpTZUO2M6fmsRqCanDNwbIm41RsolNfCTnHRgwFyEb1kc5OcJA0y6saYSh2vqUlmv1IDk0c /GSxCf/7h594dmXNKzWEq8HGf/n86Sd6cFIHOmMWDCbFao3YL18GA31rtUX3N2IiWwpeQlGJ9hnR N64CddNjwCtQ30fwZWQoNFqit1tNC6zxRd0XTfCPsUjxhYF3Rq8e769Y+fAZy2+bFzS78hz+YInf nV0688LW7BYXTjZbwo+Pa/SWeePGjfKVeeOHNVTvSnLEsznTysfkJdCuvIB9uGvM2ja/RZE91lQv 0VNv7fTKmjMmFXhCHcWuytICm21scFh3hntm45gzJ+YKhpzwTw3jEv3ljrqx9uzSvkm5eYSPdzvT TAVFNl9QjRA3QMz+BvgXBWhxzBcWyYydBdkJvaRrF4THgzePWkKGUG6TZ2Ti6Ihiju0XRXac1K3t X1b/5OMdzcLpTnEqFfGgLfQNKSXf481PkeI95b68mcUxXyGWjrigcer6lvT0mNDjvhFNxakja/se jlEG+wmh6sr5F89SdfbC/qN4Kz8GHCkXqo/tTlvJkygFWcC/EpADn7knlGhqjPT+Lej8iX3on187 5aFVvGrDVckBkcHrhvY8vmrCxGHDJ06oHOg7XQd2B3oKo8gbXVHWOHpYeWSW8DqYJQuqjq5Wo2zB 4FSIApYRFjkIWbrUA7WRke5ED9Q0n7czeVeMfOpjtZ/1Kv3nbIv0gRnAwo1D90d3d0bGq3o0La0A QscZO8dVZaheaQGEVycEYGdz0+BXf1pCSmhEU9XI3LLG3NEnpEKNE09s9JcfUt8gUt8CAjb/V439 Gzn7Z4JniYZuEefVwgxSSp7Xl5cqmt3F3txpJcAnj8onc3qJJzBtQByFpCyHM9smNG0bV9peX2DO bGluzuhY1+wc4Ccx5w4RzJ9T6Fmx3Lxx42z+Sq+/KiO+ct6WloHVCnNQgM6OzkF2vMr0NG3RojST elgPrqa2CKXYIhRhEWYnehoHeBQX4VD0nCHG6P+TO3/ZCrb8uxU8wLLr2/7NCj6JLcCObli/DRAb ccCNIadLZ2inS2ecfLqUFDIYmwbOilIGRzL/5HTpX97xC06XOK5yXe+Zq3tWlg1ft+/MNT0rysJ9 loK26rIJJcnW/AlV5RNKkvDnyx+7sKlmQ++q5Y9f0DRiQ+/ZNUtaA1ljl4yCNDdrzBI1AgxfzSEY 5eAI0FUixCLA8/9VBNhoGvtfR4D/ro3BEeApROCfRYDghE/PGDG80jkgC4lZjjSIBDOax7QFZ6oR 4FFzVm1BYr4aAXYV5dfnWPCR1U9ubjA6Ao7wtIETyA9igrEgc3hWQsvmnavLF7TmG9UI8N3axoLx cyPrhuzXdkeWRteNzwgaMyShJKPgEIIClamgOr+i+kYHbgsJIX+Tz2hxNlpGR/Z3InI/Q/WqD0RX jPDv6w9xAU+1RDT+MLIfPF5Bn5CYFmfJzoWFMmSBuKvKylLkNKdd5DlCmz2BJEF1+TyVOX2Hfr5E lhSM8BmpziBIlsi7RZ+Tb2D0jejzE+chgYHzkLpQOpK4AA58WgrmRPjMXBpSFUGps5RQ7RDDWIkr 1QPrZO0g41P1EKPJalJ3apAVmzjrNwNCob5xEjnJ6NSOMmZ0+k1HOuHvpGOSkPP/8tP+g9MT8k35 /EvbCqY25FklTi8ZRH9oYkl6cUaCd3jL+Jbh3oLpF0zIHhvKiddzlOokvcFX3pyXXuA0+arGjh9b 5cNpo1eOyTDa7JbcnFS3RZeYlqQkZSal+Z0p6TmhKdWhhaOzpTiL0Whx2JLTE3QWu0VJcic4sp0p rpxQB8ySrf8rcim3A1WgbZFZ2mc2y8OykDtXta62kw5BHbvcDalyjCCrmw22hvxePGpnSBdlDizO g5pqK+wrOFBgjr3dlfufNBLR9typQ5aTAxtrLNwjl4px7mBpSvPpDekL4xNUsTxNTI1YgWcELap5 NjAswZlo1jGR8etygvHg+PjGrmnFL0ZiludhifM8LPHnI1FNuLOxUWfQ6Swe4NZadZ+CPgeWcGF0 RYsZkU0KB5kRMsbnNmaIfGJj9IUpsGVDthO0DW1V7WsRiPJLqp9q72HISU5J6YldiFdUhebKsoNx a522vsWlDR6WdJwXTGB3aWz3IX2wXZt/0VwyQAjrR2pGkIyPUSInOnQXjDsndsa20+Ry9JLz9oYs LidzuXtJZ0gKIacrs9ElJjWKo08c6STZ3x96pjOkUnTd6Abe2Tlh3WzxttLo6QbdhSnPhb/jzRm1 JcW1PjMf/o7psJiS781Sj3xfZuwFKqcEfd5gkkC384rZqhx/Rz3N4SWLiWYkOBUGg+F4g1nqW5aY SC6TzAaeE4yqh+OE8W2F8QXRJSdOLbZopxbZIUPkyMImSr2kO2QMqd8BoFbRGURutwhO6B6V5hSz GtVjiEbzCaflpPGrRz3qMQaoD5UPcSfOXNUjjFPcqx1hxI7Co8c+pfH0FAcYlJ6vxykVebmlDiN3 552cklqUnVNkx4YfPzXgpPL8nOI0hd9+C5WScjNyim1Y/KAImMNTgyzg4eFnBdlAecVqxvvwTXGJ CqNMFsJv4Wy9pOc4JTEhvFCVgPDVdDdwyIPmR99bwgaDgpJAk9fsDXmSnEKSvZesAFYoSY7GRCG+ UWjmxqLmmHf889M99Rsm6uClU1aH0btoRNxL432+DOwrGnTepYbC1gQdOXeRYVxLZp6d6FbLFj58 ULaXB/0FKYruDfoUi88p9Zcn68MHEq06k92M/SxRoUVur0VPpURb3/2kO8ms11u92ntZtvAf8V3Y hZKRZYcJ4ppLd8WJthRkOnQQ1utz+Xle7SsvsVkY+DrLXfq4FMtmndmenpTqMWF+nSm9yOsucBl7 M0dUlKY+JSh6WEMmESfckp5t1ems2eBb3dr/LX6UPqx5kMk7EMS8vfuENDe4u8YGVH2wGh5ZqL6H M9TXMw8p40cVV0lWVolLkiKpMrRMrdllHqPRU5btr/CYTJ6KvobscpVQnp09TE2HqWMfhi8jZaQT GZF5J9KJjwAbOBSEqPOg2gemvX4YffGYlFnt4a5EqzUR3yqZJR7/WBEIlpcFBHsmtNT/U3gbR/pb kIyMe5BO+B6mtPoU7Vg5Em893gQibKN7rfHhrwv82QUFOarXsDC8naTwlyM3Sn8SJeGjoFpN+CfE ECUrd1kc4vmoOoiDfW8dUY/DMAMDEGezJkQP+gJU2zOJKAximzBpciuz5mamZCYbacm44qTkkrHF RLJnOT0BO+Xbnw13v/teeNZzJptJz+lE3fw3335v2dL33j60gNfrqE6xQn+6oT9x0B8X8qjvj67Y GWfh90O3jBCKH9tlSRIiHVK/J6X1SBWTyGljUWlJXHERyfBFVZk1jsQlFY8tocbkzJSsXCtrmzxp Ik8Tc72OzCSRzl9Ekpa99/ab86EjnB66dABvf+9dvP1Z2apAZ/T8G+E2kJ0JYIFe5z2oCDWgT2N+ VVP/U/uMpAU1YX91L7l/t5SSIhU/Ss5GSD2uUq+o/1qohI1UqohZ3opeXLUrL4/3RYO3wRuL1SFD fEedZpXqenEI3O8ZJ4KQ2MtioMgOdfrVnV7tpbFOf/Ie6ICR/q+eAMyERwx2qbihLpRuiJsfjYHo 65Ur71syZfPMKq9i9I858+E1vpaagFHPE6pXBMlX0pg3fulIJ7aW147JmXlJR3Y4HJdZE0wpKcqz 2IOjgoH6gB33zLx7bX1Wy+lbbp86+q5br1gcMihxsik+JcGRZRNkk1Q578LRSkqCXDL70qWFLcXJ AqjOhZdNcKdXtancvgoh2sPbUCD2nmdINmRhQybWZ2Ach/O0Y0eYmVAepiirl1y5K80umnv7P9gD RHN8XC9eHzK4W7OMJizyEBX7T7yVCVwpqO4DJeE/eKBQfYcFPFDUidU9l5A9KxNnwXMGPUp9wi9p T+V3Z6Sdzs7Ye8exw0lwl1hkE7LUG92gMGtWuYeJiqGvRK+ANwW5v79uSzUzolckbOWN9gyHL2jX v2kwivzslAz1u3fa9/hE2rRC5M3ZPrvDquh3czzF4N0ajr2pfokDo3bg3WO8F1XhuCjvFC4Hc35s qMCGciyGgHl7VakOYWsv+eveQi/8ovJHyV+R2P9FSFAviSCJYnYvXrDXXFbudJYnR+Os5JgQJsO1 kFxoZYE200Ck2THo7euCiJPv175XVn5EE3j/kYMRu63KO5reqXIrORR/Uu+gV0b6v3xyZCFEn3by xJSCrhtybswGXjjUaS8oPcarb+rYrc4EAzMlJnxY2xowW7KqsodNrQ/IBlnPUyYk1s5cFZpz7ex8 ++gty6/FYcEssYWpWUmi3pbjdgW9bsvXI1fMGOdxDctJTPM6pJRgus1hM9u9bnvh1PUN1eu23r/s RikxC/STBzypT7W3HALo2+jsJegCWOfHLAXrTFinYCZjUVsAojpTecCugMvUS+btzuA4lPsoMYC/ +U1IhovW5MDAF40m7eZMJsHfi+fsDrlahdg7WqArCvv8BwpgOcDkqIazQNuC9Gu7kOr0lGQYcUYA Z/ixLwVnmHCGgn0yPkWftK788idG5iX6mOhPZFN/YAe/eGCi8IlVY8Vu7KKfWuJWSGl5PvV8JWxW rEZQ8uCPXcnb/TXBwgZ/wgqTLbyAhO/Hk/HKwuIvYt74F7rEYIYz6EuPJ781yAZOffH8+Pf55Ly+ B1W90wX2oYdXUBU6HI3n+BLMF5+0aEp7ibQnsyCzQEl9lBzQjIQ2E0iB8SsV6uua6el8SUxeS3rx 7J054w29eOa+eLs9+oW4SQPvmWlfCoy8wBmxCv6BoDuySGCFZJfg7FIc7Yq2Qv6bx5y8IqIWgg0J utXdQfdJ3z8DDyS6u097Gs/fv7xy0aRSM1gFziDphazartqKGTWetNDcxooZ2amJjnQyxwCxoCUh XOSu9y24Y0kF/s2CO5dVGm02Y1yiL0n9IrItxWYvHleW11yUJKVmkIJMt5TkT6ssCX/JkfwZW1F/ f8xiE0ZfQpF/7Z/vbV3b8e6wGcbK71GiXvtnvPZ/edYravryu7tXH3u3b6vhK91voa4BVlTk3/mG T4bCCB8Qbj327tHNhq+G/o8DRg+nnCjh1xDi3kG2XwpW1P+mCu4stJWrRGNPBV5EWzWkIqMK+hna CqgelFYCWgATAWdE6VvpA3BPImr8GSSgq6hFJpKOtpL0/imQ+iCtAzQAxgCmAjYBPR2Qxr0I9e4C Z/Cu/oe5LugrgM7UsJwui+ZXIQu3AW1lYWi7/hRwARagcf8WyyOAdsZxNfAsAL8e8mdDPoLT1JS+ AGOPwAFwD5R/QNJg8OXokl8Kbj+y6kLIPxTcfOTiMpFpKOibqDCKNDXlRiHhl4K/rP9jFVwZ2kxf RlNOBe4KtBlwNncX8qmgl0Hdy5AnmjqjSAXkAaqj9M20He67CbWfAps1PI2KiAltJqb+LkgdkE4A jAC0AeYAzgS6HWDllkC9BeCEL+i/jePhXgA5ruF8KkfyVEI5nAVtZg1w/flT4FrAu2jiv8WnEbAA yHIftAvgPgCaF9IIpqgpXYJqo8AANlA+EyUD9NE0mXsAnfeLUYyS2RbkHwowjj56EIk/w2WoKgqr ln6LRg1B6SloGlhhBFwz2kA7UEMUwwblG3TrAXrUwJQIoG4z9xxgK6AZjeZ0qOmXgFyIEtkzKNFg QIncq4PyS4bg7CGI0tneIXhhCKL0k+q3gIa9elDbX5y4xlujqEeJuukoEeQ8eSi0sf4cG7jm/u1c d/9P+Ee0EP/YvwbSJEhnAUoBqwCLASuArgds4ChayFWg04nY/14Ui+nbwPMo1DqAArJCS6tJCkqg 3WgDO0d91kmYpaVH+6/R0haYj3+HKRGwJ7S5i7XTTP6ANkTQ/w2kk2k+aoygvx9SFCvzhyLglqKN xAz1n0M2chigpm+hZN4ENuThXwY+hGy6LYDMXwbo59ohmH4Kmgb6IrLyPyD3UNAHQTe9BGtjKAKo PgqqpRPQXFirE+mdaBx5EpWQ79EUUofKIK0gz6MK/DpKITeBLjqGpuB1aCw+r/8d8hTkV4EuWAR1 fwJ8j8q1+9R7EKQVqBIfhfvgHnInyF4ycpJ7AXcB7ypA980DfXYe4FbVah8PAz4h839G+5iWwHyA 7qM3arTrALOH0K4BzMHHoXwp4ErANRp9IWA+HQ9lI2AxQPvfQY5fBFhMHVAeBThdo90GWEcToJwC 8Gi0ewDbyXbozx2AezTax4APCPgY6pfqyB6o+wn4GxZAvXY9BDBiqAWyjLT0Y5XeV6uCLEZzIe0i m7V0IiFoHsmJ+Sv9y1UfBPq0lduO/BEfInyzatMi/kJ4nWqbI/5CeBv4BmM1P+AplBSz9/Rr1BKx 4f1G9R7VbtNnUJNqgyP2Mtyipgx4p9pTtgqtBjvfyC8PfztgF1VbGAd6XkGuAVsGunXAbv2AJkbs Fvgupv5WzR6lIXPM7tBtaPKALbkpYj/oOjRGsweDdDe/H/oAep3/Azqd+wjqqngUdKqKTlinraiV Pg79Bs7Re0FnA8gXKATreYOGaeCPXIY40oTWAhBp6l8PSNX0yqfQNugP+luQdQvYhTRUN6ATbkdO rgrN5qaikXQErHMPItwstDKKFYBM/jpUA6gD+TLwn6FV/BPgAwLIRdpccvQ7ba5LiAetH0AxrBsT mqBCm8/l6FJtPs+IYi3M0UwkDPIZR7N7UQV9D1XxpXAtiqg/OEb19WL+Fq9Hgi4bCdo8w7zqcgb5 cUJknlU/NeZ7cd1Ir+HPoBdeisw1+JpbeR3UuxS16HKhjdM0f1Zis4C2GDAWeDMWjdWNhfx1KAT2 QeKNgCS4X5WLFHShJhuuKCpgvvdqNjjmD6XBXObD2mvieuBaFFEfp031XzgJaCq6EdXk5aaoT/I2 4NqorKh+V8yPeAvZVMB8J0H/NXkB+djMXQ4oQOMZ+EXsGq0dO/82pIlw/19QJ/0r+C8XanWauC0o FeqnAh8Rq4XnLoI6YP+BZ0iTre9Br78VxdeqDepfzN0D+kq1d4NsOP9n8O9OQxXcSpC9lWipmkZt 4CrVrqntqAAfJoGVoDh+T0SO2ZSorWoEjNTsz9oBn0O1M2nIoNq6Ad38E8zZPFSj6m5uI9QfDdcO ozyWDG2Ng/JqkMmdkWfRjTDfm1ATY5A/Dn7S4v6fVNvMjUBmejuMLQqQ1atVkBvRXwA3qqB70ApA mwpOQO0wP68BrqDT0WI6EdXDvNk0mS5GtxI3Ws/vQGcBbaFGj6YwR7Ojfp6WRmnJ5Glo72l0bywF ueoAXBtL6VJEaDXYpoN4KT2OL4ByCpSHgw8wTAU93v+9Cl0VOncwgPYTjPOqgTW3AfqxAXWT69HN gMlgk0oAC0gHWgyYRVajKwFz/lk9qvrNx1EXoBswiXsBtcKcTYZ8GqAcfwC29Ry0lgf9z69CSD8C IV0eoC6SsgfRLSpAVy7gn0UF/DugIx4Hnh+HWGUvqgS6E/KNkLZy7Wg05O8F1EFZzc8CubBAPpX+ CeXS7WB//wFreDuaAOBZMSrXTwddcRyl6KpBlktREsjlGPIB+GvfQL2vUS3o/zT6OcSoNWC/n0BB LoRaID8K2iwHXAVoB0wEJAG6ABMA4wHDATUgw+3kQeD9rWg8PR/i1zdhHW9BM+irqJ3OQF56CPTT H0FPbgc/ejvwYjsaB2gDqP2dCagHjAKUqfhZ/+p+cf88p+ofDYJM8CiV7EZVpAf8kSPITXaiWvIp +HA3owCUKyFfQt4GuXld81Wa8fOoBTDqv7kX7HoQ7vWSpSiPrIT7zgBbdxrKJ+tQNumGNi9GaeR0 kPNfWu8P/QGag8r4CwBXAWqj6RTAlYCjYG9U3IyG8V8CDqNhTAc+3A5UB/k6finK4X8P8rABlfNn oZG6IzAnx1ERoBQwAZAOaIvmx6syBpgLqAdMVGUbEOQ/hxixHKWz3bAOR4MMYqTAmgqr/obqB6g2 k9WAPpgHqEclsOauBFwA2KuC7UOr2D6sj6XCmehK5kPrubkoE78Lvg4A8lH0vwf44ET5lwLfM2SP hv93ezgD+y2fwbx/1n8Y8Djg/QjQSLCpOYAL/9WeB0uD9KpTILovwWynxkl7EQPxZf9LgBui6W+j NEj7XwS8EKMNsi95nA74pevfC3gnAtQE9iVFtTEnYpr+bwBvAP4WyaMGiEFOiVhswAd+hulqOjge 0OLZubB+B/ZG+g8Dno2mh6O0vwO+ieJvKm2Qf4joZf33AM6NpgA0AuxBCmDjoP2FKkBiNC1TafzF p0ZsT4DfcmoM9iVPyJ0qc/9Erp5GcyEGi+yDlYCPswd06rMASFWfSY3pVNulxq2DY/LBcTeNR3Yq oDXUCutsIVpD9gGuhPJZsMbmoTW4B8o8yiTfQQpl7ga4pl6/DXzm7yIpleHahaBvekA3rkGnq21y t8E9L0J89QAyk06UDD7mcRWwFqQIwO4D6NPAZxXSyVBjCBW4/2SAze9XQe4DmxjBdSrwq1D/PnTO SdgIscVGdBr19H9JrgDew3OBnvD/tHce8FFV+R4/c++dmSSkQhKKhIxIFZggRTqGFgKhBgbpMEkm ZCDJjFMIQSk21sVFEFkUFWEVVyAoMKAidsXFVRG7YsWGHSxYCXPf75z/uWEyBMT3dve9z+dN3G9+ 55577un9nLCgiVhvcdJlmHydxddPYjwGN5AdY+H3AGbjJ38jwh2Jk/dxZLjp8P9qaAbgz0y9lYCb k5L4SOrcISyeDzwNRpjRaCaWrplMw7lvxnc8XE5dfpH9sxz1O/as8d5Yr8F+o7qTXWN8b53O+gMW xSWWVzAHeKWeXa7pA2YTfMbacNgvLIejWFlrQTzrxTGtR58JYHeBIB7rZ6DGYywFpllsgKCQpQqe ZhbB4yyOo7bH+BwBY/pqrJeY1kKSqX8iaMEa1cOk65HwMIw84nlhnox6z9cuNyEfu7OLtHew9uH7 3p8J+37oT6dh/BoHtw51m/6G2Y9xYy/qbSnWLWUsTSvB2qIl+sxheMf71bn4vpXYz1qhHsR8FetR rN2ai31hvvbke74uuY/7FdZq37E8jP1j4t5nK+L6sBWWjmivWJ9YvwLj0G7R32N9NET02w3tH0fs 65s70n475kl+o59HGCzuGfKbv7Omw88j1C9gDf4NjSf6Ab6Xj3X2NoQ1Hd/1499qV+qPIx0LEE4f HhaPr1ibX4Bv+2BM/pp1N8aj6PFFjBGHMB7m6W9jrpWmJeg1mFv209ZiLTyTpfB1vPq5fqPyNFOx 7hqrrYfdbmYV6eFnEwaR5xERIMyFkqvAQLC07vzBOG8gMrgiXRgX9cXGWULEeUJPMBuU8vWmwWln CdHpk+cEEWcEK6LOCC75I+cD/Bwg8ixA7P/LM4CIPf/u6irMWT9hjbFuTxNrZaRBewHh/oiy6I81 2zassb6A3WrWUez/zdJPqA/IvdwhfG9W/8VSSXuDfO9AuRLrmU8w58Az5mti3xBr3TzMF8W+n8b3 J/me2evI4wBrh3waYK2GXwrmTpPgFuM61oROMV43tF9nxfwsYg9aC+jviz3XNzEfl+O8ugXjZiN9 HvdX7sXCX/0JmjPoH9PcIHyQ77NiHnCUf4M5ZkB5C3lQgLbP9wS3sAuh49F+C7Rs+NkXcTbmHFH7 pHwOoGzCeFWL9B9E21nPCiwbEHaR/qFYo/L0LkTbP4F57mxm5vD8U+NQFt+jDG9kPflcXm2LOXUW W6ceYuu0XRhrsN4UYUbs4/J1b4N7y/X3zPONfXMj/ZI5WgH6rQKxTu8pcUfsJ2M9znxyD5pTxNfW BlH7yafvIUt7uT/sB0nI199O7Q8LVK5iD1igv8+R5Tta6lRjXzZyb1bsxxp7snZmknuwcSLMf+ib hRv+DnmmpCEMXrd/YC2UX/WbtesQty5I4wB8cxx9TDHWNEdZe3UM6uk61J2fUCZ8j6YT5mXPs1yt I+KwgTU3jxX2gzAfK9JeQZ+9FnOXyfqraFuT4TZdWcDPj9Dvmdkyyyp2lbYf7zAvs7TGHOxhfEtn PcPEHh7m4uJM50Oan6m/yjOY5agLy+H3tWxQnMqWxa1EO9wF/5qi7zjIllnL0P4wX1RS9eHa1lNz u3oYZ3LT9Y/qzsrMKBM5d4T/zPCbv7PAf22jPNsarj9D81F9PeIzWkkNhxCWF9/Fi+/b6rciHW5t m/6ziDfiK/ae+PzPgrUR39+U89no8zA+vxTvnmcTFb7HzPc7urNuWm/WCn4xfmaF75qJ/a17xTkZ Uw/oP4i1cnes/7qyjQhjo7aFlfA9FmOPVbIg4oyxHvCzI7CDcXxvDeRFnCkuiyCeK9I7EDiM88GI M0IGOoBWfM/N4LTzweh0G2d/p879pked+3VWPfrPEWd+5531zA/5FHm+J/byjHO9lSxFnuP1FnvG l7ME7sbIe5HvDv12xIfxOJhzeJnD3Sp8g7qOfBmjJcBuCeYZnH1SjXk8N68lLPdL3pBqzO+5+RU6 n0M5/u55jrX975/hoO0uEn3bKKyBeN+HNqteJ/s/p+jzxnPMbdAm57LBYn9xLOiF/tzBErWZcDNS kK++xhqrh2FH/csi0WfMY6mCkayan6NhHthE7c2aKBrc1Ig+r1rCz+32i/6tDIzAGvFJcA8byve6 0c9lCQ4Jpf5vI6sGmeqX8JeDPs90VH9KydOPCt2g34f+rzdop+3E3OZeVqgNYgGjvxP92G6WjPjw sXIYH4/U+wDmPCBfKMYCcxfUb75v2gt92ETkzQyEvUnfjr68pdqf8flJgfGNZTfGpZOswDqNFZhb oxwsrKl5A8arIpTZcbZQewzuu6NeHmOXajPQj80E7dGnVOlvY6wdj7qToD6M9laEulKE/JyNOoQ8 R97NVSoQ3kdoL78xm9i75fu8m9mlcD9UW4769Wc2xtyBxVkeY4XqQ6fOE9R3xPqxB1imOlDHl6EP 9cDtx3BzM/rceNSrfqjnlair01lf5OMg9N+NsQ5ZhvljghaEwg/zJuZDOTcT68GmiCdfZ7ZHuzfW mQ+i/f/eOnOFXGv+ykaJ9SZfa8p1plhj8rO9bRhbfkQd6yzP+eQZn7KH2ZXLUZ5V4HbWjJ/z8TO+ eud7Q9mFyhHoETrrqzvfewdpLadzPuUe2H0P82LUy3dZL/Vl9MdPsRzhHz8XlOeBdW6+QX5KN5bb UG8/YMnofwrULizZ6mfp5kKsQx5hVrUU864B4GvQBXgBnzd1YSUot4staJNKOer+etYEZWfSPsKc EG1G1Pn7WIGyGWPh/WhL81C/hjO/BfMFjB/GeO/HuDxCLdefwpwyU7NjjC5kw7Q9mLu8gm/mgjQ2 Em2X2mgaG6/MZ/N4e+ZtQXsWY/31LFf5lI0R56aV4DDyqIr14Genpif1E3Xnpz+zdFOIFSI/ppt+ wfjbBWuvR2DexaYr+ehjyynPVaznwVS1NcYN5L36IPzri/lVAktUmqCuXor21ZUNUr5ihcon4El5 rnoHeA7ciblvJuJ0gvJcnNki/00/YQ2aCHYjnPPoPNa0D3P+Iagfp/b35xprYmUd8m4dm2nsKSK/ unGU8XjHz2v5OS4/Y20vzdyuD+Z+fWifocG9hq0YF7eym0AmP0MW6eJnwzycVLY2Gu3S+sBuCPRM 5EQD91zbRgP7FtDTgP1gaENEx+NM7gafJR4N2beDnsb/NB5n8fcC6GmcJX4F0IY413icKZ/bQE/j LPEYA22IevFAvSri8D0r9I3XiDOprexaidj3UTawUl5f1SexFvuY9o7EWdfWuv0hsVem5eo/cVSF 3cLruKCN3BdqzF7jiH51D/pQ3kfyeryfDTAdQt2PgJ8dR1K3Z9UxijaS0+x1XXAc5kgM99m0Pyf2 /g7J50jSo4jyh+/9ccRant97nIR+ztAcrFFywnlcxZ4CdzMP6/bHxFo7EWPuWLH2H4l5zBqMiWtY f/SdjbU3WTvLMxib+7LZ2kD9W3HmyedApHbz3zCmrUafz8fR/fDnKPrjlzBnGI61TyP9HazVa7RP UGffxLhH9/FypQ7AfK+VlhDuzlXMi/chThNZN/NEmAOsF+ZVYg6rHdLXaIfCY0A78A2e74BOAV3B 13geB9rVP1MQ30yWbr6Rz3XfWDZhzrFJX2PZFJ4MuoJv5PMU+fy1+ll4r/ZlOADKI8zzYJ4DZpgT w3stKeEAqDDvD78Y9fwCnsvAdHn3w3hXjncHop5fsDyFddZT4b3WZ8IBUG5dFD4Q9fyC0jq8V20b DoAK5b3wgXrPrcX7OWCGce/U7A6/b7kYYVwcHizNfjAU5tvATG0w0tQhXGS+MRwAt5tv1C/AMwMt jfMQs083WwaGbwRTzT+EXzf7wrXyeZr5t/BreN4JFtIdFOH2CjAO7w7C/juYl8jnF61D2QjrUN0c lxq+AoyzvhA+aB0a/g7mJfL5xbr7I/9GjLsoYFiEuY66+ym/z4w/4Fa4xzy/kTJSXwauBuV4TpDP HDdIl8wGx8DloJt8V/a79+X4vRjOqfswZyIOxEfZTQCXcbNxX+bfwR+53/tHsCSCzLMjz7qm8LOt BsyeqHX5/xjLSDDl7GCu1hbr/uuBT94ZbhHx7AXJIAVU4V08dCMYDEq5+9+7D2zsA4i1OO9r/81a dxfsX4RlLdh4ds6lzz+Xfvi0fswXHl6vH/OF885l7DiX/vxc+sPouYc4Z4ucZ0TOLSLmE3XzB8wT lG5svenYKczXYZy/nqWIu4V/Qj/vYSusLegeG9bgK7RdYn8u1dwJ84Mi5NkreD8ZOpzmFafuIoI3 2fkWM56fZ6P5vTSwwjKAteLwe3D8fpzG5xuTsYbn+T9D3l8bS+dAxjmP+hkbxs+kOPJOXSNxNmPc q4s8pxiL+YRxP44D/7CmW8HvwYn07Gc2cc5QwTpY/sz6WxjrqF3MOlpTWQI/KzK3Qxk3YYn8/Ms8 FH3HA+ibrWJfZrFqYanqPWyxZaC8K8bXnv1AU/i7Am7WwPwjW2w+Dr1a3jPPYvHqQXwHNAVhH0G/ OhBzWotgsdnMMgWfsq5aqrj/la5Nh94B4Mb8IUvheaX+wJLqzhSsrGfd3pK4t6afFOcBdHet3r63 ukQ/Ue9u8OesHb8LJ+6Y8fSEac+a71lZ+rECs59dCHcXWrqydMul8GsG/LkWaZiLuX4l4varuIfH RJ9xvq6jniyztJb3Avme50BxB5BpW9h5mOstM/fB+xtg97Kc40XcE8WY1848FvNHF9LSDUyH+w+Z jcPvFfL7hlouvt3KVNFnHpH3Am8S+4N1f+OBvnkMynUcR95RVMUesHFP0biDyOeZR9AXyXuH4u5h NzaG33fk9wuhTJtG+5ZIY29zLViKdDVlIy09mGrxinnoZG0Z0rAW4+FqxIsxxv/SyVBlO/+n0NDG HLBLFmt/ZlrHIv6oSX8XtJV3otrwsxQ1rP/K1+T8np3pQdaBr9W1Z0CIHVFr9d+UVawv2ts45Jf4 eyX1AdSlZDab7/uZr2Y263TU7/PQDtexzpYsrGmuYI15O4w7iv52kX5Cexjl+yEbof0GP9sjXPjB 759Zzmc9zAvYEfN6Hg6bYDWxR8Q9uULTm1ohe0xjWBsx06OEYdZ/sqax5agXl4jzymTo31F/J+M7 K0vm+5FaH9SZTnqtOp31VF9kFm08xtG+qGvG+orvJUyMYqvu4miHWZ71ONriR/rP1lv0j62r2STL JWiXPWHXgXVEf2OzbkZ7+B5j9nxWxe/Axj2Hcn+IjeNuOVobzCWeZBeg7i3W/oo4jUU+KaylZS/q fCn6rc/YfPVX/VX4k4/6kW+ZjnoP9+pgNsLyNNr9T+LvaRLQZywzF7KLrAx14y+oa/wus5e1iFsI N+0xtjxNiHq9X6xLDyI/plEZh8fzv1VTprC7TftR/gtRbol6QcJGtlt7na1WXmdXc2AOQb3c/vdg rDaf6tDJpkZtMu5W1K0T29R/ViZFjAOPUj6bx5n2YS1YbLjlbjB+tIJ3r4H3lWvQRtpE+XkGon/q 4lNBz/zuvLhzXyFZLe/lD5dmDsqf3/fHzzXgEuQf/+cRgtGY14QrwY3mNXoG1qsayKC1K4ie60lO m29J1AP61wT6ocj5RMS8Afm8EIwFU4kT/G8W0JRPoHxPvE3PJ2ojVCdqWX1OnCRO8r85sBMnE4ja RWAx3n9M1G6TbAVbZPicHpLukuGS+ZJh/G8PouDukeu1y6GVMrzvJDeDdRSGwAvukvHL4X9DQZyc QO6FPz/wv4+QlPK/ywDvSeyUDh4X4ZdX/o3GPGm+DORRntZ+Az6TcR4m/xZjM/l7cgNAL1p7gsIW DJYsjgifsxJMiGK1/DuSWyLsHse3LkmR5IhkvKRYshQsibCfS9R+QZx8QrJccqlkGlH7dBQ+0F9i koyRNJEkS0YSJ++Hvkx5UfsTdJTEKPMcovaAxMjfkGStLN+7JZH2/K74BknvKAz7u2TdG07h1m6K Yossr62SKH94XRH1ZcOpb06aJUlE7RAO2nAR1gUJklb8fP+0uwPynt659JH/TjCW8PGuGevBMuRf I/evj3LrH0dFPTZrZ+Ct+lgTzo04lEH8Y6fTKD2Ca/77JLZumCTUhZTkM3D8j5F6lGgMf5tcU5/0 2obJ2FufzBvOnaYYBZstP53mqLstFsSIcWZajvvjZK1hrNUT50b2L/U5f9W50XrT/23a7Dg32m47 RbtJ/yLebpgOMxnrWH5mLiz8Y3Rae4rOa+pj73tu5JT95+g6+9y5KLdhumF+1X1wjBgxYsSI8Qe4 j+gx8D/Idb/Dc/XpORV8GeNc6bX6/w69X2Ss73KiP9bKA24H22LEiBEjRowYMWLEiBEjRowYMWLE iBEjRowYMWLEiBEjRowYMWLEiBEjRowYMWLEiBHjfwUTYyntTDaWyh5lVqZAc9hsxhKLM25nmvin SLoorfk/1iD+iLmE/uEG/ufMLFk8cbPC4phPmlVmZwulWWPN2CppNsO8WZotMD8hzVY2n70lzXHs QpYszfHMZhojzQnKRlOlNDdikzTDTSK7UDPikKTcot0gzcms3Nqu7p9R6WZdXff/H2217pNmhWnW 56VZZU2tB6VZY4nWt6XZDPMRabbA/L00W1k/a1ia41iGdZ00x7PUuD7SnGAaFzdCmhuxTvGGm0SW EW/EIck0Kv6QNCezixu1RUxMWrzMZzJTPpOZ8pnMlM9kpnwmM+UzmSmfyUz5TGbKZzJTPpOZ8pnM lM9kpnwmM+UzmSmftzAb68a6sovw28ZGMzcrRiw9zA9KWQB2Q2DyMa/47YSNG6ZKxN/GBrFy/Gdj hbCbw8rwzi+eXFAXXM/H7xK4HILvyuGmCHZuNhjfl8P+9LD6itAi3drqXE8SPvpl6DbWE/72Qpzr u+9S5z7aH7eImxMERDpK4F8F1MfmwY6Hz9+UwbbhXJgjnoPIB8N1MbQCz07Exy3SbGej4KKYdYCd n3WEmxLh33DxrQf+nDlWFXhfItLIU+cXvvqFySXc8hBLYVsBczmrxlMVTDzG3E0QPgZgz0OjeFbC Nzd+zxG+eKSvAZFqCpO7oFTwMCl3eamOEOkthQ0v7SDsXeILn7ApF7EOyHQU401n4XOFsCkXPjqR K2RvhFIBf8pF3fHKWFbCpkKESn7ydAYiYsBD9Iq0UM0z6h3FnYfkQQ7YkH6qezxWVBrFIv5ukeJA Xc2kPKNQbCLulTJdVJpFwuWpGEemiOfaAvEdpXoenu2n1dX2wrcK4UO1yIegbAOR+W3UMR56lchV pywXn6gNXClEXtY2WeMoNRTHOdINbwsLpe8BpIJKaH5dKTlFHeE1vKJeuowaXYyYOEX4xTJ8u8ip AELsi3EkB1/z/+yiztVvD3ZZ+3NgrhYlNEf45IUP1bDlPpaK8uIlWd9Xw57XZsq5eXX+TRF1l3Kx WqTeL3IrIMrZL+olfW0T+cbriEuk0C3CcIk0FolvjZwexhxol4Pkt76IN1S/SkSbPVVnqkRYxaJO NRQuPXO3xcjnoGi1JXVlUCLe81pOKTDy3StSWilznvxyid+8JkWnm7+nGtsBX/GehLfborqQGopV 5Wk+n3senfLd6DVsst0HRLyL67W/09NutLboePWLyAGeEkoL9ULGiOKr69FKRJuuFG3becaUUj47 6+UptQiP/E2pInNQ1Lyg+LJEtA+eGledP9xluWhjZyuhf1W7ONUmckRseBugntEuysrLFmyxdet6 UTfbaHexz+P3lAZsQzw+r8fnDLg9lXbboPJyW6F7TlnAbyt0+V2++a4S+xBnubvI5x7sKS+p+6qv TdrauPUkl8+Pz2097b26Sfsu3N5w4/bbnLaAz1niqnD65tk8pbZAmSsiCnN8nqCXWxd7KrzOSrfL bx8VLO7g9He0lbhsw30eT6CeVxWeEpev0uZ3VvptiKS71FbqrHCXV9uq3IEymz9YFCh32eBnZYm7 co7fhpj5A64KfFlZgiB8lYiu3TYiYCt1OQNBn8tv87mc5TZ3AGEU+zvb/BVOZEOx0wsz/6QiWB5w e+FlZbDC5YNLvysgPPDbvD4PMo/nHXwvL/dU2cqQezY3klEcsLkrbQGemYgZPrGVuysRFpJZ5J4j PKaAAq4FAXzsnueyG7na3m+rcFZW24qDKAGKN8+xSleVzedEWnxuJBsfOitsyDgEAx/nwMbvXgjn AQ8SNJ8nyWmrcvoqKCye0cVlTh8i5vLZywIBb9+cnKqqKnuFUQ52ZH9OoNrrmeNzesuqc4oDpZ7K gF865eZSJyI3j7ub4gkiitW2oN+FqKFU+GubEzni8lW4AwFXia2oWkR6mGPUILz1iQfkV0mQcqaq zF1cFvEt1F1ZXB4swadIQYnb7y1HADzuXp8bDorhylUZsNuMsD2VyNgO7o42V0UR/+iUV5WG4wZj JJzzqoFs8gd87mIqv7rQebEZfvUTEejgRiioQryh+HhFK/FUVZZ7nJGBIs5OiikKAsn1ICj8Dga8 wQCq8Xx3sYu7KXOVe6MSdC5lIUoip8RV6kRltDv93gXGWgs/ejO2jDXwszNe3aP8GmqVlb1H+SXU qhPk51CrzpCfSH4kOU7vfqCn70m+I/mW5BjJUXL5DcnXZPkVyZckX5B8TvIZyRGST0k+CbWKh3xM Tx+RfBjKagw5HMpqDvkglJUDeZ/kPZJ3Sd4hJ2/T0yGSt0jeJHmD5HWS10heJXmF5GWSl0gOkrxI kThA8gLJ8yTPUbD/JJfPkuwn+QfJMyT7SJ4meYrkSZInSB4nPx8jeZQsHyF5mGQvyUMke0geJHmA 5H6S3SS7SEIkO0Mtu0F2kGwPtewOuY/kXpJtJDUkW0MtL4JsIdlM391D8neSu0k2kdxFcid9/jeS jSQbSO4gWU9yO3l9G8mt9Pk6kltIbiZZS/JX+m4NyU0kq0luJFlFspLkBvJ6BX3+F5LrSZaT/Jnk OvrgTyTLSK4luYbkapKrQuf1gFxJspRkCclikkUkV5BcTrKQpJpkAUkVyXySIEmAxE/iI7mMxEvi CbXoCakkqSApJ5lHMpfETVJGMoeklMRFUkJSTFJE4iSZTTKLZCbJDJLpJNNIppJMCTXvBZlMcinJ JBIHyUSSCSSFJONJxpGMJRlDMppkFEkByUiSEST5JMNJ8kiGkQwlGUIymGQQSS7JJSQDSQaQ9Cfp R9KXpE+oWR9Ib5JeJBeT9CTpQdKdpBvJRSRdhaimUDM7nnLI0k7ShaQzSSeSC0k6knQgaU/SjqRt qGk/SBuSC0JNeYVuHWraF3I+WdpIsklakWSRtCQ5j6QFSXOSZiRNSTJJMiiEdAqhCVk2JkkjSSVJ IUkmSSJJJGlEkkAST37GkVjJ0kJiJtFIVBKFxETChJh0kjDJSZJakhMkv5H8SvILyc8iWNNPIkWm H8nyOMkPJN+TfEfyLckxkqMk35B8TfIVyZckX5B8TvIZhXcklHkB5FOST0KZqGCmj0k+CmX2hnxI cjiUOQTyQShzKOR9kvdI3g1lDoO8E8rMg7xNcojkLfL6TZI3yLPXybPXSF4leYU8e5m+e4nkIMmL JAdIXiB5nr57jrz+J8mzFPn9JP+g8J4JZQ6G7KMPnqaAnqJYP0mePUHyOMljJI+SPELyMMle8voh 8noPef0gef0Ayf0kuymgXSQhkp0U7A6S7ST3kdf3kmwjqSHZSrIllIF+17Q5lDEIcg/J30MZoyF3 hzLGQDaFMsZC7gplFELuDGXkQv5GTjaSkw3k5A5ysp7e3U4ub6OnW8nlOpJb6IObSdaGMsZB/kqf ryG5iWQ1RelGcrmKXK4kuSGUMR6yglz+heR6kuWh9MmQP4fSp0CuC6VPh/wplD4DsiyUPhJybSh9 GuQaenc1ubyKnFyZux36bcqw7GPJ+dmHE8dkPwWeBE+AxxtNyg6BnWAH2A7uA/eCbaAGbAVbwGZw D/g7uBtsAneBO8HfwEawAdyRUJZ9K1gHbgE3g7Xgr2ANuAmsBjeCVfFl2SvBDWAF+AsYFK/UKr+x SSxbOQEtY9mmJaEmvDkuDjXmVStA4g+l8arlI7mMxEviIakkqSApJ5lHMpekP0m/UCqXviR9SHqT 9CK5mKQnSQ+S7iTdQim8nl5E0pWkMUkaSSpJCkkySVIIhbLHlEjSiCSBJJ4kjsQaSuJFbcmdBj0K vgFfg6/Al+ALFOcH4H3wHngXvAPeBodQLG+BN8Fj4FHwCHgY7AXrURS3gz2mpZTTC0NpvMpXU+Ys IKkimU8SJBlCMpjyYRBJLsklJANJBlCSM0jSSZpweUhVVSWUm73pMVVhu8E+oKqM4nI5yQQq9UKK 2XiScSRjScaQjCYZRVJAMpJkBEk+yXCSPJJhJENJWpOcT5G3kWSTtCLJImlJch5JC5LmJM0omU1J MnNvg54EteAE+A38igL+BfwMfgI/guPgB5Tq9+A78Bk4Aj4Fn4CPwUfgQ5TuAfACeB48B/4JngX7 wT/AM2AfeBrsAQ+ixB8A94PdYBe4jZe+cpLyeBHJFSTuUBqmQqYykjmULaUkLpISkmKSIhInyWyS WSQzSWaQTCeZRjKVZArJZJJLSSaROEgmkuSQ2Cmru5B0JulEciFJR5IOJO1J2pG0pbJpQ3IBiZlE I1FJFBITtUiWeydUB2HwOTL2DfA6eA28Cl4BL4OXwEHwIjL6IXCt2jb7GtWefbXJnn1V/lLHlTVL HUvyFzkW1yxyNFrUb1HBIrXRovMgly+qWfTOIssV+Qsdl9csdGgL0xcqCdX5VY4FNVWORlWmxPn5 QcfE4CfB40E1PTgxWBIMBNcEX4OFdVNwd3BfUN2jP5HbONi7X97S4Kqgko73CguaUrj1+cFGyXmB fJ/DX+NzaL4ePqXfcZ/psM+kdPWZxvlm+xS42uVr0yGPu+7py2yRl+rr6sv1qZflexzeGo9jrMfj WeLZ4HncY17iWelRtsOk5Hrik/Iq8yscH1SY2COKzlLBE4oeUhM8Dyv8pPWYEs7VTfOQAXOREW77 HEdZzRxHqb3E4aopcRTbixxO+2zHLPsMx8yaGY7p9qmOaTVTHVPskx2Xwv0k+0SHo2aiY4J9vKOw ZrxjrH2MYwzsR9sLHKNqChwj7fmOETX5jnH5puH2PMcw9eJsjCCsFf7nbbW01bettEazs7xZijfr cNa3Waq35bctlSXnmVJaLGmxsoWagl8K/Wqe3Xxl8w3Ntzc3pwiDmuhtvLSx4k1bmqZ0TctNeynt cJrG0jamKSkrUzakbE9Rx6bMSjmWoqdo21NM25MfTz6YrI5NnpXsSVZTkvmzmpqbbL8oLyUpOyl3 eE6S2j8n6ZKksUnqyiRTbpK9W15uUpv2eZckjk2clahuSDTlJrbrmHcsQU9QchPw4li8Hq/o8Sam mmwmEzOlQtQ4XkamjOw81MddmSazCVOLnRMndOpUsMeqFxbsiBs3bYfpuh1tJ/DfueOn7rBct4M5 pk6bvNNkumHKTpMyZOKO9ILxU+n52hUr2OCsgh1ZEybv2Jg1pWDHUhhyuUGHgWXtzGSDp3Sa6Q/6 /YFO/k74BWb6YRMI4n9CTPgNDQb4m4CfwUmnM/xwF34uQeHIH5wVhB94AWu/sOZPM4WTM/nxH/05 Y0r+Ez+m/83A/3//NJs1878AKUUMfQplbmRzdHJlYW0NZW5kb2JqDTE3IDAgb2JqDTw8L0ZpbHRl ciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ3Mz4+DXN0cmVhbQp4nH1TTXObMBD9BfoPe9R2YqoPJKDH dPo5ySEpnRw6PRAHx3RscMHutP++WkkY09Kigxak93bf2+U7E0Dr/h2TQKt/ZtqCySzsWWZCtPOR pkDHfcs2L9jdBBZJWuRCF/B34BhfvhWOutyw65JJ5TFuy4ROFKQyMQrKPeMSofzG3pSRdVi3Dign YB6AOUhTJFRIoWlz0C/88+0N9LiSiXZPyutDj1L4F14PdUsv1tqMH1GqEFUoU35s0ERI1wIqmQi+ wWL81KOH2UxxOHQ7lDpgG7R8jWk4479wZTlMTO3GXZyB95QsFjDPuDKRZN891Tv8CuVHcmBRbiaT LMq9/3ANASGNK/nqXItjdLJ8rWmQv1TrYzXUT84v54W/051cWaO49hlXKpY4JpHh6CLPUDu7Vfz+ A7MImGergYwXF653hw6WVRojEnOpMloSZ2LREZUTxDvy6WzraahaeF/1qGLP6+G/vqrcnMfoocE0 0hy35CUNxKSHbI2kOye0enRN1vJyniahPXVA8OGV6zH/h2YtbJKpWQU3DY7m/0Qb85Krri3LHEaT YTMVqPPQ2Iqa+eeI3DXUUH9OEzj+Jw+oDD9dYT723o/SbbXGcEHnfAuvt3U7ifkNzT/vYAplbmRz dHJlYW0NZW5kb2JqDTE4IDAgb2JqDTw8L0NvbnRlbnRzIDIwIDAgUi9NZWRpYUJveCBbMCAwIDc5 MiA2MTJdL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgPDwvRm9udCAxOSAwIFIvUHJvY1NldCBbL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTE5 IDAgb2JqDTw8L0YyIDUgMCBSPj4NZW5kb2JqDTIwIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE2Nj4+DXN0cmVhbQp4nI2NywrCQAxFvyD/kGVHME6TebTbgorulNmJO60PWov+ /8JOq1hBRbLIgZx7cwWNcdZzSDHO7QDi0HqHNXjbU9WRRJDHPkI5gtUr3EMbnsy4bQklFAGMUM7d oSd2TDpDEUuWMdSQrBeFwnCGafjkC2vK3vzxL1sMCQ/sTXK6KE/iXCpJqWKZ8UmjthiWXzqMZsrd vx9N6sgM5brZ7atn4A7y3kZyCmVuZHN0cmVhbQ1lbmRvYmoNMjEgMCBvYmoNPDwvQ29udGVudHMg MjMgMCBSL01lZGlhQm94IFswIDAgNzkyIDYxMl0vUGFyZW50IDMgMCBSL1Jlc291cmNlcyA8PC9G b250IDIyIDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXT4+ L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNMjIgMCBvYmoNPDwvRjMgNSAwIFIvRjQgMTQgMCBSPj4NZW5k b2JqDTIzIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NTY1Pj4Nc3RyZWFt Cnic7X3rkiy3kd4TzDvMzx5FnFEVgLr5n7gmbTokrS7H3nBwHQx5eChKPkPuktTa+/Yu5AXIBKrR PdKgMVxhFbHs70wVEh+AwiWRl3+9G+79/373X+7Ge/+/7/94Z+f7aZnvn++WCX99hF/W/7D032/u vv7Z3W/jy8Oj29bBbvf5j73En39m96Lff333yfu70cA7+3+WwT6aezc+Tub+/fPdyT7cv//z3afv 7/41VoHlhQrEOs2LexwTYBfzuHnstvnRmgzjw9/c/dPP7r7dxQyPZhvG/QFfWTeO6/5jsf7/7n94 +nZ/aXpc3f20Do/DuldGY1/k/h+P9pJZAKKnUDvEWEHH0IM5FKQRvrrjUHeBF3xXAaK9eKmC9mKI 9l4mYap/jnYxT3ur+Ken0IjPsTT76Jxs5IDt42ZkRQETEdFD26PqgwinOT69D6l9RP0WumWdzeKm vTege0b/w22DoV4JXfn8skHAg7ZY/L+Gbg4C1lUIWLE53QoCQhO6tQ+sNz+wrplWvrkzezm+/mb2 rfPMeFwtFG+35XFeU0hPqzEwD8vqrO/6aV5nPwX6zrfbCmTN8rhPgs8Rj17KRxBnjzA8H0ZxEz52 Mwb4mH1Up3ygvoLP4P8j6p9i4vd2+OzTwOb7TNOCakdao/9KIosEMsmGpC7wgQoLOvTJBT4pRn6N +cDsfEwH6iv4jI+LHGUZJn5vhZAZp0UTggoLQoOfzASBFBPBdoQm7JUyK6h1ZDWs6rNJIHN8E5ym YVuPSUGtBaf50ShSKV4bf0oTUpCk1tXYSZOCWgtWVi9DGSaWb4LWOC7zGVpWr06D0atRhm3r1WlC EhdoGb06DeOjkSwSaFqvTkek3L7IaFK+1oLTICkMOb23QGffq07TGTpDJGO2zR93A4UUI7+WhKD6 RUJUZ8GJdqaBU4qJ45ugBYcwT8tv/jQtvSE3G5UTaKS4+YZ8QhIXaJGUgK3aEeU4yGlGa5nd4rev i9/Gwo4C/0XRsmqfZDaDp71AI8W2+T5p/6LcdomWQZVAwGPyLaXYhENue1r43yNWY/JpDcmnlOKx +aeVs4IfitWgv6x1U2enDDPLhqxmr/oqs8JaC1ar2sbmeGt9ohKsxmk+R2tV+1qzLnray/DafF+7 f0bDfInWoqfBHZtV00px62kwp4X9l9AychpcZ3XqzTHRfAu0Rj//naE1q2OwWadHxSKBc/NjMKgw L5HytRacQEcuWKQYSb4tUtB3ihTUWrFympQ74PgmSPmd+1lSagoErbpgkeLWur8J9eYXSEGtBSuT rE8pJpYtaZF6dhn2/boDWtB7ipZJ1qshmfFSbJqvV6T+K7LSekCSFVmkeG2vCQys/GHfs8JBKVlh 2YLVqqe8DG/NlUusASzSWvUcuKxKR3aEW8+CkRZf7B7SGtUYhOIEjRSvzbVmrCwTtGAKUbTgdUFL dc18QLAhIdYuzWwsckRIddKk9WYZbtxDOaFgUaApCEr7pkEySODUXGkWOZEJwwEnX2lFyRrNKcWt Bx4pysqcrOonq1UuGSaSDVmxQkmwgolQ0bJaB7MYrXPJsG2ug4m0yJjmiJbRSpjFJItSjlsrYUj3 coGVXqNGrUrKcPubnZwVLFqK1ahVS8uA9j2BRYrH5qolZuVPvdMZVgNaNQnsVs0qxVvrviLNywVa Ts7t86YVZClmmm+ClrGTPaaF1Va0lILsALfeW7CaItLClTmhpRRm86qvPzK8NVeY8Zl+9lZy4xla q74OmRelIUvh2vwy5IBUMPtUJBQntZ84wI0HIB/oL5BS24s5uS3NcPvb00jLTedYJZen86TX3Qy3 vzzlA31ghbsoxWrS6/Ds9Lqb4an5OhxZ+V9naDm9EO9Yaf4OcOuFmM/zF2gpTeCcXNhn2DXXBAZa /v9Aw55dXM3J/f2O9bqb48brcHBsKbPSy3BihZBh23oZDv4Jc3CKwG2UopVYJcyDVmhmuLlVguNj yOwnDneG1qAVnNOmL0BSzDQb0uINe6SFu0NJC6utaCWsjki+CVJsQXxISnFa0RElsEjx1tg00PFm vUgKaq1YqRXqAC9vhhaZEOOON2GlFqxp0braDDc3tXC8sS2xWrT6dseD06xS3FiB62gHWCY1qK5K 7CoyTCTfACm3b5lA0Y7beMUqMbOYpkerWKS4uaGF4/3fvI9Du5yhBdUWtBLLigwTzYa0eKckaMFG XtFKTC0mq+/fMtzc2MLxVmm2+65iPkPL6vu4yeplN4ON7+SOSME2PiGl5kCjVZsZtq1XYd4mzdbf JpwhZbSmcxqT9SnFprWm0/GeYvaflV+OVzycKFpjsmAN6oIxhWPz5YqWqSKnQd03usRcJMXEsSEn XqXg4xqBFJy3JCmXmI+4VavKMtzcfMTxdD4b/12dobVq3ZlLzEUOcGPd2REtOEYmtNTVnFu0CjDD zc1HHE/oRVqL1gm6WesAM7y01glGWjuXYT1Da9Y6wR2rFeoAN9YJOl6pIi08Hye01JLlJq0DzPDc fMniWX0evUnWGVqTVgo6bROTwqm5SpBn9dnfM05ACs7HipS2kXFW3VmlsLWFjOM5okjJqhssl1jE HODW/cSkOCTHMSl1g+USg5gMNzeQcTxDRFqoyFC0EgMZN2qlZoabG8gIWhSg44jWqJWcLrGIOcCt 1Zw88V2gpZfhxCQmw81NZBzPE4KWnxQVq8REZsdKr3mAW6/CgdU5QkrFaRNjmBQzwYaEeIo4JmQT sxibmMEc4NZrLxMKsTpWVKIltNR9nF21PjPDzc1iHH9FRVqrVnDaxLrnALdWcN6LQB3HjNQNo9WW PSlsbuij+aCaU/HRNj521qrZDLe28bE82oqkZq2p3bHTpNwBx7dAiuN0HJNSM/mkt0MZnhs7xVnu oCKpSe+OdpyQOuLYkBRzCZE6KEZjQkpxSsx5Mjw1Vj5b5lIklVj3WKuVzRlubt0jaFH4kRW17IqW 1crnHavb0QPcWP1smc0FWuq+1OogjTm2re9LLQdTmfjHOmUuL1bHbjQ2sefJcPPYjZYjWIRAHUe0 Evseq0NQHuHWKxaHsrhAS2mgzaYvSFPMNN8WrdTlBWutWBlNyhxwbMmJAj6E8COHnOQkqE5QZs3Z tWRD8QNCHIsDNqp7EiOeDDfuHQ4dEPngVZwilJj0mEnP3hlubtJjOXRAiPdwRGvSs/mOlTr2ALee zek6W7CCm7iElVLPGqfVsRmeWqtnAysei0esnNbOGqeXpAPcWDtr+Z7+Ai29RBmttsywa75EsY99 pIX3i4qW0XpMk9i7HODGekxBi2aOY1rqNtHooMk5bm4AY9k3vUhLh1I2Rlu8pLB5IGXLzuls3bPi VbDipA1gzKAVfQe4cUexD3eZk9L9jZten1JshtbaP8GKJsMDWlhtQSsx48nw1nzB4jNViVVi1TMu Wj+W4eZWPQeswBRBsVq0vmxMjHgOcGuNGTs7h+Awx7TUbeKoQ5LnuLlRj2Vn5yItHaN8bwl9OZXh 5jHKLfsFh6Aqq8nu4LDagpbTk3mGp9aXVZZdaIu0XDK9a4uXFLrmk3skRevxESltATMarSDLcGsL GMsOtEVSRuvLduw0KXfA8W2RAkOfhJSaK1RI/Aya1rc77Dobgt8cUVIB8s2YWE9kuHWYfMOes0VS iUnFsOkbghSPzU0qDLvOcpSYFQ2XJCustWC1oE9OYJXirfWFQchcVmIFtRasZq2lyDCxbMiKfUxD kJgjWrPWWgz6mjSFc2udxREpsDFTpPSt6eC0iiLDrW9NDXuYFkk5rbEYklvSDLvWGotIi3e4R7SS W9PBKBVFCpvfmRr2my2SMkplMSQZDDJsGqss2KZbcAJbQMUpSWgwJAkMMtw8oUFkRSeRI1Y6ocG4 6QQGKQ4sW7Iiv9kCLaq2oKVj4ue4eUYDw36zRVo6Rv6+nD0qFglsHiE/kuID1hGp+VFxUhHxMzi3 nipySmiVqiip+PgeyvnuCDfeVbAj8AVScgIcNx07PsfNb+MMuwIXaelg8uOmg8fnuHkweUGLDsNH tHQw+XEbkxkvxc2DyRu+LyjSGvUMuOo46xlmmm+LFth7S1qrjrs+rlqlnuPmcdcNXwmXWGkVu8cJ qSOOb4ETaWSOOSlKWp2e46X12Yrd0YuktHbdF6sWqAy31q7f+/95BmmB6StJiYm8b3qe8Nfi0/OE 9zzhLfj0POGRQM8TfltOPU+4WoZ6nvBb0ep5wgn2POE3JNTzhAc8a11/zxN+K1o9T3jEPU/4W2HV 84Qjq54n/Fa0ep7wgHue8Dakep7wgJ0m5Q44vglSPU94zxPehFbPE8645wlvTqvnCVddMx8QbEio 5wnvecLbcOp5whn3POGtaPU84YR7nvBGrHqecIF7nvA2tHqecIY9T3hbWj1PeM8T3oZWzxMecc8T 3oRVzxPOuOcJb02q5wnvecJbsOp5wgn3POGNWPU84QFbff/W84Q3I9XzhNsj3DxMcs8TjrDnCW9F q+cJD7jnCW9Nq+cJ73nC25DqecIJ9jzhLWj1POES9zzhbWj1POE9T3hDQj1PeM8T3phPzxNuD2Hr PBI9T3jEPU/47Un1POEC9zzhTWj1POESK41zzxPekFbPE56za8mm5wnvecKb0ep5wiNWS1LPE34z Wj1PeMA9T3gbUj1PuMc9T3gzWj1PeMA9T3gTWj1PeMQ9T3hjUj1PuNOk3AHHt0Wq5wnvecJvRqvn CSfc84S/FVI9T7g9wj1PeBVSPU844Z4nvBGrnic84J4n/A1Q6nnCkUXPE35zWj1PeM8T3opWzxPe 84S3V1mEYGZLDOVI1VRSCO9fjUcKUIV29CRFwgfm8T4qCVP75GgX8yRbD2svIJXjgUVEPHf0JJvB 8m5nZig6IQFPvkVXuBrFfxANSjr1IElgpxvcudjCgn7Q5lDzIEZpokc40Xrl3OcooGIy8iMBr58d HKRcEPA3pesOAqrlz84lvHZCa4gnWTvDdCKkUspnlFI/B3Mip1pSZJBTPUvxOSmvlTZYl18jjy9K qJ9YN5FTLdMtyqmfehbk3CAXLMqpn5w1kVMrW+oZMa+dvhTE1M8nmoipluAT5dTPuHlGzqunwNRy auWkRCm1k0Sek/K6WRsTKZXSKIKUG+Q1RDn1Ew2CnPqZ/7SYaqn4UEz93HiJnGrJ6lBOzexxIKFq OrczEl43v1oipE7CMxRSPQMZiLlBSrBETrUcXSinetKsM2JeO4uVElMvrRSKqZ/nKZFTLfESyLlB JiSUUzs10Tkpr5srCKTcIHlPIqdWNh0UUz29TSKmWr4ZlFM/AYyWUy0jC0TFqZ8iBcXUz1mCcuon EQE51bN6JFIqpdlAKfXzXiRyaiWiADH1M0OgmNqpGpSUerkTUEz9ZAYg5wbZBVBO7XD/56S8bvx9 kHKDgPgop3aEepRSOWQ8CLlBDHeUUz+o+jk5rx3lHOTcIOy4llMvDjjKqR+YG+XUjpQNUiqHrkYZ tWNJayn1gjuDnBtEW07kVAt/jHLqxyNGOdUDBGsx5yT8LRF7QULVELpKQsWYtiinfpBZkHNfMepr LuCVw7CCP2b1uKhaSq1ApSilduRQkFI9lCdKqR9bM5FTLdglyqkffRLk3CAcJMqpH58R5NwgYOI5 Oa8awRCFVAspiMVXjPEHAm4QdA/l1I+CB3Lqh6VTYurFiUMx9QO3oZz6kdQSOdVCm4Gc6rHGUErl 4F8gpH40rkRMtfBYKKd6vKozYl47gBSKqR/RCeTcIMQSyqkf8wjkVA9ClEipFBUIpdQO03NOymvG zUEZtQPZoOdP/cgyKKd6qBcUUz32CoipHgzlnJTXjU6CUuqHC9FyasXvACnVA2qglOoRLrSYaiEn UEz9GBAgp3pQBi2lTpSEMzJeOWwBSqkfRwDk3MCxP5FTzdMe5dR3fT8n57V90VFOZedwLaSStzYI uYH79C7n3v/PF+kfkQ7SqQt04iFNjzP8Btxxfb27M67tzriiRCGhO+N2Z9zujNudcbszbnfGPcLd GVeUK+R0Z9zujCuL7c643Rm3O+N+m5QpZHRnXC2mO+N2Z9zujNudcbszbnfG7c643Rm3O+N2Z9zu jNudcbszbi5UCunOuN0Z964743Zn3O6M251xuzOukNOdcUWxSkx3xu3OuFJOd8btzrjdGTcWKoR0 Z9zujNudcbszbnfG7c643Rm3O+OKUrszbnfG7c643Rk3F6vEdGfc7ox7SU53xu3OuD8RZ9yeXPgt JRfWm38ew0s0cCWLeLvSJoPxMrMtOOEJKGKzLhOyh9Mmob2RB2BCeK/xAJv3UBRhf9U6zRr71wZs UrgipaIQ7CWbAZ+kpmFIVvDh6YAnvzkVggCLigS8giifbHuB1SxwAOS7nziKFXaWrQNwjTuu3uZN 2vxCi1+dYX1fAfa5a3I42RJ0I25CnYFqJxAf9m+H/OrH8QOcgSbwz4OmPWC+vd+l7ZRyrH1Wfnt7 NkfBCnTtBRu+U+fap1jbDDRnowILaBKRlJ3ojoVIpDi50b89qQt8sL6CjyNLWOaT4qnxkLs/jPug qy/o8BUlVz/FTlngNqYT4jLo6gs6bETO1U+xvhm9OZ1SRAvNIXIybEhOHFJstQF7S055AA1NQpCS vaKBtmBvQKcQqUNUX3Dhm0tmkOK2vVMICKIZCEZ8q8gMUqzvTG9PqhR9RJMQpMgUmzkkUF9ovglK IVCIoiAYKQIH5NqTOYh6ImovqLBpORNIcVs6hSAumkFkNG6P8pNJoNFG7S0p5XFcFAXBiHVLTCnF 22PbL6gQmkZzEJxY+cMcUqz1WrcnVYqDo0kIUmQFzhwSqBVPDSgVQu4oCoKR1R9TApUFektCWWwf RUDxGY0mlOKmn1IhjJCmICgZvUfIsLasvz2nQswizUFwGtUeIYWm8ZahFB5JURCMOHoAc0jx2Hbj UIrEpDlITorQAbs3RCeGSBLVj1yGTe97UjwOb4LOQcQnzUAwYrcEZpTirfFOqBTGSpMQpBZ9xMuw 9ol4E6RCpClNQpGysyaV4ranvlKQLk1CkJr1JjXD2kzm9qRKMcE0CUFqUgtRCufGe9ZS+DFFQTDi WBbMIcVT23WpEOlMU1CUlGLrAC9NR14hrJrmIDgl+tQM66AdDTgVYrhpEoLUqE4TKWytXi2Fi1MU FCN1nDjAbUdeITKd5hA4uWARhhxSPCWGaLcnVQqGp0kIUqu64suxNkd7C6SCl5XmoDjJI8URbnrj Vwr3pzlITorAAbt2bM7HFRS1F1TmR1X/BDblUgpeqOqv6Fij+aT4jVDKAxhqDoKTvkDK8aziPjYg dT4oo+agONlZc0px28NFIQKk5iA4OXWWyPHU+GxRCDepOShO46w5pbjt4aIU21KTEKSsMjrJcevL v1IgTU1CkTKakzmg2IxSKWanoiAYGXX5kuPGt5ql8KCag+A0qoNsjk3j25hSNFJNQpEanCaV4rZH 21LwU01CkBqUYjLHY2PboUKkVc0hclrVrXMKmWE7RueDuioGipA8yR7hN8Ioj+uqOQhOlKOIKSRw a3yuLYWqVRQEo0WZqOVY5UdqSCkPV6spKEpK/XCAm5qtlULwag6CEwe/Yw4pXtpqH4rxfjUJQWpS atYc68h7DUgVggtrEoKU06faDE9t9a7FSMaahCBl9bE2w67tMbcYOFmTUKT0gpTjpufcYpxmTUKQ 0n4VOW5s21EKCq05KE7qYHuAm3pblCJQaw6C06jPtRlubLFSCHetKShKRjMyBwSbEzqIrK0YCEKD rP+Qc2vHpRC+W9Q+Ulm0cUqG15bGKsUo4ZqBYKSNU3Lc2FilGJJck1Ck5CXtEW56DCxGQNckBClt nJLjte21bTHguiYhSM3q6JfCxqYqxdjuioJgNOmTX4bnpifBUiB5TUFQ0h5/OZ4anwRLces1CUFK 29vkuLEfYDFIviahSKmj3wFuqqYsRuTXJAQpoy5sU9jYAKcY/F9RUIyGhFKK3walgzwDmoPgpIyI MtjYpqiY0kBRUIzUQfYAN/2WStkTNAfBadBnvgw3tikqJmvQJCKpObEhSjGTbEeqkB1Ck1CklGry ADc1Kiomo9AkJCnF4IBeMzqlnBei+oLLos9+GX4jdPKUF5qBYqQuNQ9w27NgKY+HJiFIJeZRGdbZ wxqQOp80RHMQnBLzqAw3Npc6k6FEV1/RUSfZA9xWg3ycDkVXX9BJjKIy3NhIqph7RZNQpJzm5A4o tqNUSPOiKAhGiUlUhl3bg/r9cUYZXX1Fx2g25oDc22ATk7Go2gsyRmsYMtzWLqqYK0dzUJyUbdcB bqpwKKbm0SQEqcS4K8ONjb2KmYA0CUVKaU0OcFMtSjHxkCYhSA1ax5Dhsa0epZjnSJOIpCZt3pXA eWirdCimVFIUFCOlZDjAbYdeIXuT5iA4JcZQGW5s8FVMFaVJCFKcr5NJpLixeVQxL5UmoUgpJcMB bqp0KCbB0iQkKcXggN5bopO6lUyqfxLTrgy37ZzzSb00AUEoMevKcGMzr1ImMc1BcEqsujLc2Mqr mLxMkxCkEmOhDDe28ipmStMkBKnEWijDja2HSmnZNAfFyWhK5oBhc0YHmdkUA0Fo0Ge/DLc1Iiom m9McIieX2A2lmDm2I1XIbKdJKFJKXXyAm6qPi2n0NAlBKrGHyrDObXR7UqWcfZqEILWoc1IKG1tH lRIEKgaCkI5xk+Ol7ampkI1QUxCUEruhDDeOeVNMfahJKFLKh+QAtz00FfIsag6Ck9MHvwxPbX1K SkkdNQfFSekmD3Dbc2Apg6QmIUglxlAZdo11laV0lZqEIGX0gSnDjc2jirkxNQlBKrG0ybBpfIIq JeLUJASpQbuQZLix6U0x76cmoUipY+ABbupTUkwzqklEUnbTx8AUM8m3RCrkAtUkBKnEfijDW+OT YSmNqiYhSCU2NxlubFVUzNqqSQhSsz5iZLixGU4pRazmIDglNhAZntueOUr5aDUHwcnqHXmGGxtF FJPfahKCVHLTnmHbdodezLWrSShSavt6gJuqW4qpfTUJQSq5lc5w46v3Yh5hTUKQGpRxfwob31EX kxYrCpGRSS5wU0wU21E6nyFZUxCUVr1zzXDj+9xSOmbNQXBKoltkeG27kS3mftYkBKlJb4cy3Djc RTHRtCYhSKnkHhmcGm+OSlmtFQXBKLkgzHDbbB/FJNqag+JkZ80pxU3vC4s5uzUJQSq59MywbWvZ W0wQrkkIUsl9WoYbX4IWs5FrEpHUuGk7xBSbxhdsxdTnmoQgpe9pUri1tUosZllXFAQj7e+dwra3 NqV07oqA4JNc0mS4rfN3KXe8piAoJdcZGW58ZVNMVa9JCFKJw22G295v3Pv/+fonxSUvJMUlwr6B ZNc374+ez1rUvuezvgGpC3x6Puuez/r16PR81oxlr/R81jeh0/NZq8+o57O+AZmez5oI9HzW9Sn1 fNaEez7rRoR6PutIoeezvh2jns86Ejpg94bo9HzWPZ91G1I9n7Xr+axvQ6nns+75rBtx6vmsez7r NqR6PuuAlWtIz2ddl03PZ200n57Pujqpns8acM9n3YBTz2cdsNGczAHFZpR6PmvEPZ91A1I9nzXi ns+6GaOez1pw6Pmsa3Pq+awZ93zWDUj1fNYR93zWDUn1fNaSQ89nfSNCPZ/12vNZ34JUz2dNuOez vj2lns/a9XzWjUj1fNaEjbqw7fmsb0ep57PWlHo+69qkej7riJVqsuezrkun57Pu+azbkOr5rHs+ 6yZ0ej5r1S09n/Wt2PR81mvPZ30jUj2fNeGez7ohpZ7PWnLo+axvQarns2asGBzQe0t0ej5rc0Cw Haeezxpxz2fdgFTPZ93zWbch1fNZE+75rG9Pqeez7vmsG5Hq+awJ93zWNyfV81kz7vmsm5Lq+ax7 Puvbk+r5rAn3fNYNOPV81oh7PusWpHo+a8I9n/WtKfV81oB7PusGpHo+a4A9n3UDUj2fNeGez7oF qZ7P2sOez7oNo57P+i3ns47qiBAQbImhD6mSUgbBfTPn0T6zeTSv96I6O3qSEuekBjNvNKigCAy9 uKqKI/JsIilrEvQkWyDcS+z1Iyzaf39JIF9Z35oQDR7/QbQm5bQNsgQedC2HNTRv4CoMNTeFQVjs DU4HXjlHNwqomDb7SECNTNYg54KIvzG5dBBRLd9zLuG1UzBDPMb6WZETMRUSFaOEmrmDEwnV0vmC nOoZds9Jea2kt7r8GnloUULt1LCJlErZWlFK/QSqIKd6TlOUUjfNaCKjTubPM0JeOxkniKmdHzMR UillJUqpmUXyjIRXTOyoJdTLtYhy6qc/PCfntTMSJnKqJQkEOdXz9qGU2qn0QEr97HZaTLWEcyim dg64REqltGwopX6mNJBzg+RlZ+S8dj6xRMzrp/hCAdWybkHx1RNhJVKq5aZCOdXTRZ0R89oZnJSY ekmVUEz9PEeJnEqph0BK9WxAKKV+gp5zcl47Zw7IuUEam0ROncwyKKRyspdESKX8KyildkoULaVa lhKIRVM/cQiKqZ/LA+XUT68Bcm6Q8SKRUy0JBcqpnxcikVMrVQOIqZ89AcXUTWigZLx+jgEsvmbY f5Bwg0j8KKd+cPxzcl47Xj3IqR5CHqXUjuqOUqoHWgcxN4h9jnLqhyM/J+d1I4SDlOpBu7WUWnG0 UUrt0NYopX60aZBzgwDQKKd+TGYtp0aYZJBQNXJxIqFaMGGUUz++L8qpHnJXizmW8LdFwQUJVQPT KgnVYsWilNrhW0HKfcWIqrmAVw5yCj6SN4g7quXUCwWKcupH5wQ5NwiYiXJqx7BMpFQKK4lS6kd6 BDk3CL6IcurHQwQ5VUMUnpPwalEDUUD1QH4opnpsPRBzg3B3KKd+BDqQUzsonBJSK04bCqkfOg3l 1I9mlsipFmAM5FSP+YVSKofhAiH1I2MlYqoFq0I51eNHnRHz2iGdUEz9KEsg5waBj1BO/VhEIOcG 4YESOdUi9qCc+kF0zsl57bg2KKd+qBn04qkf/QXlVA/IgmKqx0gBMTcIW3JOzmtHEkE59YN7aDm1 4m2AlOohMFBK9agUWky1QBEopn7sBpBTPZyCllIrwsEZKa8edADl1I8DAHJu4JqfyKnmLY9yajuw n5Pymj7lKKOym7cWUs3zGsTcwBl6l3Pv/+eL9I8Id+fEoTlxd6aHGX4DDra+1t29Fsrt7rWiRCGh u9d291ostrvXykKjkO5e291rhYzuXtvda7t7bSxXyenutd29Vhbb3Wu7e22Gu3ttd6/t7rXdvba7 13b32u5eq6V099ruXtvda7t7rRKniu/utVpOd6/t7rXdvba716ZSlZTuXtvda7t7bSi2u9cm5So5 3b22u9d299ruXtvda7t7rZKpxHT32u5e291ru3vtBSHdvba713b32u5eK8oVchIdTHev7e613b22 u9d299ozcrp7rZbT3Wu7e213r5XlXnSv7el/30r6X98ZW7D6T374zpjBRzfsL0bcdof9A2G70aqF jwcounwJvqTJjyiFXnvOSmU8jTj/0uMMhZQruNBrz1mpjC3NVvS4zSevopTx/s934BAyDNP9//Wl 7H2uqO0/ArXf//VFSh6+SObxVxZJ3QwTe6Ru/toSxUiBIkXr/tVlInE1GGexqf4b2tIOsZa+LbnT fZExGkDy7s8/c/fj/fuv7z55fzeCkbB/EH/NcIPgRtCLvX++++L0u+8e3u3T0DbN8+kvD+9mb3Fn ltOPf3rw06h16+nb+K9/fPhf9+//292n7wtlD3DdCmX/4o8f9pf379u6ZTv9eP+w7yL348Jyev/w bjp9/7A+jss+j58+fLgPBf/8M3u29otX3tzbFWZukPAv333/48POZj9ILac/eVmjHZw7ffftvf9n D07ffX1/udp2gfs1KPTHvWLb/upexQ8fwquXu3CD6rHBsFnAlzWYIRNkRQQ/faCYKM5J+r3nrFzC dqaNND0f8NXzhXrvOSuX8bgKIeP6Egn7zL86zWQRLXLdd4OFqGougu51hcSeg2N+oENKiasKEf0N hYQGekkh3CZiDC0mjKEXtci4iuaAjvGvlyaH/SAPOye0k3vl2cGMcErx98sTFf75w0yfqyjkhweW 9+MfvOzVzMMmH3h6cN5Fb7KnK2eNcYMecGYO08bnD+/2XtrFLKdfeyE4Df3+/YP3QR4Xd/qF/1eU Ih74h4d3I5gk29OnD/u23m6jO335a5h24IFflFqA6zHaMNP86tOHfVO9zzWn4hTFbw5DnLb/ca+A har8d6iVr8A+r65Uq1i/3325s93L8Q+f/vPe5HuL2+kqgXaKVW3ZZNYxcd9i9+//fHaM+Q1yfPoL uST8cP+wL5/AXfzrt199+H/7UmGwef7Ph3+/v37C308GfkhPhhZ+u8GqTfgjY//1woRGzwd87ZSv 33vOyyU8OTzh8POMr52Q9XvPebmELdkI8fM2txm6KGffIig+2xz5XDXNcSGystscK3t1IdSDsM8S jK6eskWvYxmxla4vA8mokbTNcSS9qEUsGXxxi3D3XJr+rQO9KDn9n5+hf/zw/cM44AfzNXzefvO1 T9aznJtLn7WfV/x8tvFW8fSu8FXbCW4+49NfnD7u9cK56E/hl1g4xCfsWxWUNfsPUF4tk/gxkWbG rKBI99rHGY+8Fg/jQQvqO9NDPExDV9OCghj0STPrsfCPdGEDG0uPSaUOrbxjAqS9JM3UgGf7oBXF jYlh05YFtweo4kA8R+3mArpgOnF7DFsRj1EJsPhtBJ3PEfqjUNBaLqSOoGgpCykkWNu4AF2PUc1N e5N9jOIVC+1/jAkbUQD4e8IlmDWK8LeR1Ev8IhuJcMFj3Glu+LyR9Rqo9bnarEVkWhxehFjTAS80 yiBaLGgGsT1HNr6g5t4xXVNgd4zBaAK7y8fGEb05BlsH7OodkxIGh8IYXFMMaO5IZ2y09hDH2Bjc S2AE7pDuGHCAjsEUwduFRq0go5nhrB6ekHUoDL4sIWtC2lyVGfU7oaYzsyYa86NiuTBragXa9nAj rbIBV+j62MCkphLWL9ssNbcb9T0B6njs2W3QHe8nYjEutoE6nsbNNuLXQsNqGx9nMei2Eb80HpQb 6dl40G6kheMRzX+nAc+v88dApfO3wrL5W+K68bdGVacvkYmF64WN9YbUARurDq1stTAPUKuKSxAj J5F1FTMM9VacgbA34wwFnW3496SmNhwocerDcRTnRRxncd7EcRimVRymcdKFUWxCXMF/+tndt/uU rpv+GZ6D5ll4/kgmG/q7Vl//ti8OfXHoi0NfHPri8B9tcVi5Z54F3DvGbBYnVI2gk57uNOYXfY/J 309C8sYVg/aHiSWsFRrBs08w0xku6aOGAvg3FRJvYtXPIbhtZKn7Fz3y7AAYLlbDahiQ40efxGKH 08NzNlss02MyddNsPa+qV8LKSPzpuwnfif5uDK/MtDC/zhLfR8NPfzSUFLt2GNhGEfXVp7GkRhhm 1prtc5p6+rJqZd1QAcsxeqYNJquBYvAQtgvZ49HzAV+t6VPvPWflMjZkZcrPm9zq9Bo+9N5zVi5h WluCnIBfIsc3veSzusjnOr0WFSIru7pY2asLoR4EOzFmtG5ROXaxENHtk+ielxVCdNRYWl0cSy8p hDokFBI66JKujz5hu8IuD28UPn+wdO35yVX3KnajqzbYYnEZ7/ha4hPU8s+TGVd5OfCrT4uqQSrU gX8zFBrvDcS9gijwk18+sGpSXDF8DprJdd7m028e3k38z9fIRiUwEvqN13vC/cZnX+JdxnD6r142 3mlHgeKi45cv1z/CMcRfbBu89sM7aXnysitHs1j8jsjDiQ9I3ihiZYeEBaY5jwd5T7tS9Aicoz2k YyCspB7TMRA2fh7TORCuVNaRj4EOr+ApfsMCu0wP6RjoN6Ue0ikQtqx2HfgUCFtcj2n9MDgKh0eG Iz5OB8ERr+Y5JPwC+2+PaRfgd+ce0lEQNvMeG4Ke+LLy0Y/+zJb0C1qTLCuf/ah0Lto3+t7W1OhY tYXN4xe/SHloJLGFowEssHe3C4WHxGZZ2OZ9sTgLsk8/Neoyxzb3o2RhZ3zqk/0/3GVmBWhn0aXL FM7eO3Dx4O2Hw+KieQC0Anmv42BaOI4hHp/D/MwDcWEvdDw+e+z4vDzj83y6hmYwfPomzH/esFXC 29vjLAvXiwMdqGPl8EAdqo4H6sgMD9SROR6oY7OsRrQZHqhDk+KBOrY4HKhjh+CBOnYY7mRih+Iu KnQ3nlXiaFgdjw7DRx8rB9M6Pc5irOFJiQbiOmMjrPEYtYpBvC7YCCE0yIxtRN8Avx0ix07YxMFr BSWHnAvQVvEDpIrz9wn7ufj1Euvwda8WJ6pRqSHi5LAanKlG1eZhalkNT1RBARKnpXXkaUpqT8Ks 5usg5jwaKWFOXAecpqxS3YgpFbc/K4/K0fBkLI+WeNqlCeU5DH7fKjyh6AmHPg6jDE1foHjsq0Jf Ffqq0FeFvir8JFYFh7dDaLKE+Cxa0EpfYoG2+V6Uu6HOB7+a1enVBXGOAvCvDmIszBt+ACglIv+e Qk/yWV97jfaJcmDwxGvVYrK1T9QuIpoPQEpY6HAGeJYTRJjC3SooRBwucbBpCDj+Hb+Dw+9CKBxf Z23vw+GnPxwOLZC8hTGs/Re1jBNq1sLTX5wewYwVbJTEz59db2c4GZy+J8oyNw84GCfKIsfY0jUN P2/z4DRF7aN+7zkrl7CZqCPo+YCv1Qrq956zchkbWkj5eZM7b1+U4yd4yQf0O8TnKk0bFaIq60ct V/bqQqAHZ1TXCUbXGyuGbqdCRDNdXwi3iRxLvk14LL2oTQx533ObcAdd0j5ODrZ4LrpcnLMz/3CV JtLnIgR19hgsBK+3jy6qBLnkAXa4ULLQJv7Ol2LA9+SzT70RMSgKxb+eM4R+qX5wxGgpdiOPXY8N QNhTjQ6mdrvRDbLH4N1l2FHNAcDfsL3xEHZzI0YU2fngbs9j0IXSrczoYHPlMfqTYGQQj/Fx2KiR rSniGeDCf/bbpo2u3b0jk5+btyE66sHb99HRbaX7/BFjXJCmHjHsHMkeYLQr7hzJXmDEeyC7oi2B h7BzJFODHQOwWBYuriuZKXgMO0cyY/AYDsRk9RAKI6uIEeNi2JWsJkJd6GbM19UAdJIJ3cF5DCf5 idscWmGduMnR22uduMmxEdcpNDnuS2OTry5uBXwPDWvcu3AP8tbVY14eufd5z+vxJPQIMHJ4wzxi kJuwoeZhR9vtEWPthN34iJGEwtZdYOwDNz86+ThdSXBpC5IOwhZkHSqz8G6darrybp6YrMSawCpb YEPWoYVw0Q4tOA2ieSecdrn1MRJX7JwJFQah8yZUGIS+xTBkse8nUmfQ0JhAZRDGzUS6EB5XE6oM wribUJXCw3IiTQsPW/ozj+qJNC086rl0/iQm0rTQF8NV4w9qQk1L+OCYGn+QEPssfq/UMvgxT+Rg yh+6b9I4C+DWMc4S2B9xEtl4DjKiK+MUtPIUNMuhEKew5VHNcDiSwgQ44xQUJkcYhnHunNHJN8yt 0LE09YqDn2h7npLlc34GGRz9ORaz6kjX1ysD+xLQl4C+BPQloC8Bb2sJsIb74hnwFPpGoAQ8ySf3 aufIhonpKXw0m1UryQbXBWJZ0Aik8BoUpjhQE5OYY4DvRRR/e0pxUbMzVY2UuVy1AMOKx2DjG6In sZytFJcwmxl4Ns5nZytnFtlHxDx8JauTnwnhmJ6Flt9XWcf7WPjJjwU1EiAE27gY7lIsZzHcNTse FyMaIwBoCkBuwAsuKsYNpAzlaAMZphuv8LzAw8p4XNB4PEMGBI/MdI4licWACHbiZzS9vBL4+89L qt5xRjeLYH76xWl4WK5Q9/qER358WtrKUyJfwh8B+zWbnIIhm7AH+zMMYKV6ukNIDgMfuSD0J4h6 0xTSTV14OmD4QdgjBOsaALzwdIeQavEx1h9X10BP2vH+fbI+sryc8Rp4cxzSoDTGfO5lfxGzBIvE 64bYdWdKn97F68c5FuRM+n+MNuLhgH9Go2BM1WIt2bpTYhWPMarZjPfEluy7mamlQGCQusRa8u/w eUD8pG3J/4Myj3jsVsL4Z4OF4TWxnQk4VOwvjOmiYsKy8JKfFf0UdMRjNNee8a7Gos+Lz0axAppm gn7ysOQxQ8kqPIbJA7NKkJVotMm2uCS7CW+feFh7PDseyQLT3pOSRyhs5zisyNjZGu4EqszInYCX 2nbkTkAuI/cB3ojb8dHIhhi4E0wMKhVaceAewKt4Do0VumCg7vHD3WzcBdh9ZuMuQDMAs3EXQO+b jXsAbQjM+iiHjlm5C8ACwazcAzjyDE3flJbIGjrz8MA1OPv75EietKH1XmCGyyzfXmXReKqPolGj EGsGp/pQ741bgWjhqT6wxhRdsVUWPNaHVltQF4JNutAEyO294KzH3YGrYewuWuNCX+JKzD29oA4n DIQFT/VhnGCSujiOFjzYh3G2oP4ozG54sA+jNE7mo5F/51GPMYTCR8Gl8zezOPE9cdX4e8PMdvF7 JGL0sdJeJHzL3Cz8rdNOIMwF3Ko8Vyw0bc+iP8Issww0R7lVdGecozaeozYxGMIEhwqgOP/hUIrz IyqQ4vyJ4zDOr6iQCtMv7q9tiBZDp06x0mBQ6uRBP8OIdYr/bHTKyOs1j32V6KtEXyX6KtFXiZ/a KjGv3BfPd5Rll7BA3sFboaf4LPRbjuaV0VP4bOyqlxvEce1IwRPMcWM4431M8Blkknex/hF5bgo9 8fplZq6ggGFxDMiEvz3Ftc9QLO5kirg0acemcVEwowXu7+SnYmJRUT35Oqt9Hw//EcbDZcMsB/PZ NFOWrNnCvoDwx4Adztf8uAs6i+vsBOVrz2mhBDlTKT18kLj0GiacHjUplKGTEl5mg+gmtEQjDg52 c8zhOis4N7FCRxTBVby6COgvyp4WqNgXxIwNnUyFhMZ5SSHcHmHkUIPwyHlRizjZHsFKsmgRiHKm yZFzvvZHvt9/2v33ePrsDw/vLASRdqfnB3YvjlEAY2TAfz82HYSNMQiGX9NkMHojbNE40um+oA9u Wbyt3779G7bJnv6He9i3FMvo7OlL7+Y87ptJY9fTJ19+9ouHhf7yq899ONRlHrfTL328VPzX/6ks DM9UYFwuVODf5p3aXvLeHlUqMEyhAr/6DdRgL14V8/uqFXCbPWqBT3dBRv3/L3/1i304OLNO6+kf 9iGw18ite5UefMgiXzvx9idfhn+9f/Bnpv3/ktC3Z2qzjqE2nwXeiuc7n1HCLfMxUb/izsLvaf+4 R3L/Ip8Bj8HhB7BHMzlFxd/OL1gIpwHNBagY31+wYfTGtKAwTzGtb+H5gA0qtwF7BHpvsD4QCAUb duRyQnQMR8EMY5gL2mv8vTK/VqOCe3zwx3rGoyU7IfD+nj1NeNPATgu0a2DPLz7ULvw38BFb+LhN jl0LH7eDi5mRB2p2SWNdDHms0Wmc/dlYF8P+bnyYZ3840sWwtxwrAsiZjrUx7GvHegR2xGNtDDvq sRKCHflYG0N+fqTBYC9A1saE/iEFCHsRCmz040YUZrgLSJThLqCqGO4CqqqJKg+gYiTPMWqdoBlG 7gNspZG7gBqRI8lwIw+qCwbuAuqgIao8Rnx6WEUHzxv3AQ6AeaM+wPExb9wHOHjmjfsAxtYstu4G cdi/gm8L71/xb9QBK8fd36RGRP7dN0N4F1UisWg8MwfRpBIJNcMjd6g4aUSYF53WA23UiYRWocN+ aDXSiYRWJWUBtzkpRUKXkKYhdBkpRUKPLk50N2lEFtZ3LEYMFNzUh3FER7swzuhgFcbhMrNfLc85 wq1WQNLVzOQ1tanC+Auhcxp/P1QV/rpIMxO+PqYxRc0Nfa3UAZbdaBlO8tvnJuSpAZUzYebgDphj BwxrnHeo+3hWIt1MmLWo88OsRuqZMOvR2FmkcibOlxv5c0fljZptV3YH33jYQjtslJ0oaFfC/O9Q KS5m9I8yzlFQ8lDyDBkpva8YfcXoK0ZfMfqK8fewYix8goAZXEIBvEGZQk/yUR/YtYCepHR1u4BY rCKI+OcTX1eGoSGhiEKoUXgz4viiUb+f6ONfsgWR6uXWY4Ra1zBvPAdKcZ64MHGv7B3O/SVA+QOR WvjXWO/7KPjpjoJDUz6cGQa/QilLPqXqJO3Sej+j+sHOQcf52cM+G/qMwF6DefqjT6Hyl+8ffGLN 04f76Q//yXtCe5WVO93/7vNPlNoqlDriih6L1clU4nM46Unxn//6swcf6Pn0j8dFU4VHuDSFN75/ eOegrv/7+A10zYlvnKkLeJvIcn2R3369Mz99d4YlBhi/WPKIUbLFc8/fffXhY7FFLpaJq6qs7789 LNQx5vo4DpREe5opmq7bYJUn/DHgkbcw9PyYp/gu3s/o957zchH7WQPXXnw+4GvvUPR7z3m5hCe6 k6fHpywr9kUp0PqCzWIim+sit2IhqqqLiVW9uhDoPzKTF4Ts9TXhTl9U57ywEGoTOZJ8m/BIelGb TJTUnJqEuuf3Z+Y8iyryrW6GKLeAbUyUVMwQ5cDVcrJbiCcRL4S+itXyyUhNnsEw1jC+tRMQxtSU 0WuhW99h4wUaVp4B9osI3TiIcRYQee8QnkY2zsGSPDZOfvApJmsdfjxCQ8gNmFV5xJRfEUFIHcJU j4+RAV3uBYJrCLCCuom/T+LloMdyd3LRfH+AsxRFEfFPD8Wn4Ugbn74cO0htNOAcB8XBLzNhq8k7 VcjWuEzb6cNXf/n2qz887O0yr9uyf7w+i8a0zj5L7zswB1vt6S/ffoQr1mlcTx9++GH/y766LsaN p4/7ZzybYd72b4Z//eDLgNJkGfHvX70gs6LBA9sweMUYbsQ8+MiAQit+5CcDvjrSunrvOS+XMK8y /PzBWnwNE8OrV1YuYp+0VcoJ+CVynKTjMHEA0bkuqDiWEauKZbxooY09h/HPAp8X5XYMPU6FcCO9 qBBgw0MI7UxhCL3gbeqGUEDoljOrI5lZUqzG82HVD7MvgqojvlrOiehgqpCCrs2JWJrdOLTjxIGU LmRU8DOw8T2c51Oww7b6px8nbt3F7Zv4WXawcRYWFnQFReSTDYBuByHFBjCOHPgCmry/IWHrJnoT 1ECOVFSc5SDDpETixwUcw58poKVHIJjQ9Ihy0WnMOVmScWRNGugRjtZbvVXSVjkaVxhOwEwrJRYo jsJpnPF0A3rkl43DkGdmQEMFO2IqNzKW9nAOWaHsSLldMAQCI8rJwpi3GlTUQi60nFk2w2QTzo8H SOcTjIIw0sEKgyBEBJsrxpwMh0mE9FHEMTMl7E1z2DTFPZUDo+9xWt/anqpQWQwG47+Mf9ZfUrZh BH24eP5d6ekZHotPf7EXvpz2ao7To102e/ret8y4czt9+Li3Ctb4D9BcbnR4BNufG8fTd9/+8M2f Hvb39meW07/888N9ideEAcTdCDPTCzqBy/z/3/oudgplbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2Jq DTw8L0NvbnRlbnRzIDI2IDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCAzIDAgUi9S ZXNvdXJjZXMgPDwvRm9udCAyNSAwIFIvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFn ZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTI1IDAgb2JqDTw8L0Y1IDUgMCBSL0Y2 IDE0IDAgUj4+DWVuZG9iag0yNiAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAx NDE4ND4+DXN0cmVhbQp4nO1925Imt3HmE/Q79GW3wmwXDoVCOWIvJFuyvWFbEjW7ig2Fg0E1h6Yd 06Q9GnnXsbHvvoU8IRNV/6GHXV1DEjMX839TVQAyASQSQB7+42a4LX8//9sbd1v+vv+Xm5Buxynd Pt1MI/56B79C+RHo329uvv7ZzW/rx8NDnPMQ5tv1j6XEv/zVuBT95uubX7y5cR6+Wf6ZhvDgb6N7 GP3tm6ebu3h/++bfbn755uY/ahO4PmlAbdM3N2GalwJCTg8O3kU4lIfJTQ/LWxbgi+XL3//s5tul muEhDVOOYWnsUm5OYWnlnx6/XT7IDz7CBykuJQteGpwLF6b8MPkNDO8Ld377upSE2XugxM/RtZRA SxUl/mFMuuUtJso+BUqGh3ku/WQJggZXgpZ6YlQEtJgJPISgC7RgWxUt0GRFS4uJtsNoifPgT5AC LVSkQEGq6S0m0o4nxbtxsqTAh4aUIVpSWjwdNcJG7IlL9AxmlI0P2bS/xUTfwfSMw5xPEAQNVgRF lL5CQIuJwGMIguZrgnL2YbQERbvcTKGRaS2Oxy03iiDnpnSCoNAINv8Q9Xq5wuE4wTZi8y8QBA1W BLlGnLWYCPxUCIrBRUuQa4ScsxrNBj5OyAlBC1/H8SRBRtGZhgfT/ga649ScERt/gZzS3kpNmh/0 8GogEXcwMeUPEFPUOEMMNNcQExpqWnzcUIPGXyQnGHqmh6QH1woTfYcQNKU4FfVzKmooaAj4P4Yg aLAiKFm9c4WJwGMI8mOcLxGUrDa6YB8tQS0+TBtVBOG/2/T4aOgxjd+g7BOhBH5YSjQZo11kVviw WZNy8tMFSka74KRod9IrPB645FR63JhOERTtznrBwVuCWnzYznpcpsiQLhMUvCVoyJaAFofDpMCa IOyzhqDBDLlgtYIGEnnHkuOKNDtBTrBqQXhw3pLT4uOGWzkuvEyOM8PNP2QzvFpM9H0qBEGPGYKg wYagaOmJG+QdTE7RqU+SEy01Ltn2t/iwhRTPpC+S48z0WbY0uvkN9FzLEeTQEeg0LNp0BHKgvww5 pb2KmqHR0FqM5B1CDh21naVmaBS2wdCyQdixlJQtdqEEB56lRJExzlZBazFQdgwldLp2jhRsraHG HORu4OM0tkqQm5M7SZA52R2zOeRo4XzguS4fRSlyQCgYcrI58xgney69wvm4Uw8+uUl857lFzmSP qRdsjjk28HHH1GuCQDY09JhjjwUb/WwDH3fsUelZRl4+RY/R18Zk9bMVng7U1/g46hw9yaprY7IK zQY+TmHjwxtFDwi8hiCj4Yzjw2wGWIvTgTpOJahIuBMEQYMNQeagcAPPh404Ovm4QI85N1xw0z9+ g7pPhBpYkBpqTOfERbHTzW/xeJwGytSUPeh4ghporiHHnOFu4Pm4yUNnHhcImpr+MTuCDXzcmW4l yIcxnCTI7BFG2/oN0g4hhQ8IKim4tlpSNB2NcdQKH0cK7aZTsf1yJ0hpDKYWbDcFa3zcJmGDINAT GoLsJsHbXUEDw4GbBN5QnyXH201CY7+2gQ/rnUpOHE9TY87cR9fscVp8oDXbyFtroQd1HkOPa/Y8 zhxJr+FxO55KTfl1kpymd+wOZ42P6xzaV18gx+54hmaH02J34I5HCCp/4IR6dcGD7TX0GMOvDXzY jkeso8/TY+zA4mw3OC1m+o6hhzZuaVHZIuhsqPRogrDBhiBjyLaBD9vwRN4apCIY4kmCjGFbbCx0 V/hAi93IynQlCHU5Q1Bjt7tgY5m3gQ/TqhVBbO26SZCx1Gtav0HaMaSQMn2eFE1HY0C9wp8AKWTg ilqpoaQxqV7w6C0xLZ6OWkkjK5/n6Rm9pcdsCjbweNisIW3tPDlmixCT2RO08ED7cCEmLmoOHFOj km2oSWaHsEBjtrKBD5s6rKulZcSF6SQ5xoolNub6K5yOs2KJrNsogkDNNgQ15vsLNvcgG/iwXUJk 5SaFRRtIJwkyFyMxWjV6hcfjLka2CAJF2xAUrV4dG4eKDXycXs3KTQrlDP4kQVaxDo1i3eIDHSwi awSpTKGysGbcOhiCQqNYB3tzsIGPU6xp4blAj7lJiN4etq9wOO4uIfLaA1PJAUGwFzIEeXv8HhuP lw182PF7ZGGdfJlDJwmKTQ+Z4/YNfJxKukEQbO4agszxe2xceFbYH3cIH1lYnyWocelBB2tDUIuP U7KFoIWKIZ8kyGrZjU/SBj5Oy+bVpxKEu9WGIHO3EK1TUgsP9FGKLKuTK2ZHJ8ixPkoLtIr1Gh9G DkvqVG7hRiAHdq0NOUbRDtbJqoFM3THkkBQ4R06wTlehcbLawIcJAyGHgzJskxMaeszZ+wY+Tslm GVAJwkOFhiBzGB+yVapXeD7uMF4RRCEatgjKVslecEPPFnnHkENC7QI5DTXGemoDH0cOSQFFThF3 DTXGlio0PoornI+zpar0bJPSeCsu2FwibODj9gosAE6SYq4TFuxty/0GYYcSIhEaMh5eNeQYida4 ja7wdJgFVeSZcpacxot0wWbPtoGPuxu5VaEZtmkx27fQeMBu4OO2b4YWPFJsaDE7N6vHpA2qjqAi 8Mg6T4qmY7QbtBU+SiBXUjgSwxYpo92thcaZdwMftlsL3CUXCDK7tQWbS50NfNh+LTAdEo8h40Fv Q5C55gmNQ+8Kj8dd9ASm4yxBjYNvaBx6N/BhezZFEIWYyHhy3RBkHHyD9eht4YEOvoGpOEuOdfAN jUPvBj5MwnGYjJF/5HHlYBEaB99gHWBbeKB7b+C4BRKSYYsc6w8bGv/XDXyYMODwBRfIsTscZ+90 VvhAj9gtglrnCmyvocdua9b4sCuewO7+Emhikx671xnslc4Ku+N2O4H9ySWOwQY9g73hCUOzG1jj w254AjuUV3rwEqshyGwR/GwvQFrMBB5DELmUi+f/BkHYYEOQ0UA38GEXIoEufRU9cIfV0OObDjIK 6AY+TiFlenjkbdNj9FFv/ZVbeKD7cuA77LPkWPflBQ4NOS0+rnPIG7uSg/dxDTlGF/WN+/UK5wO1 0UoQyYUtghp/bN/4X2/gw+yOAvsvXyDInB/4xmF5hQ90yA7swMzWLRkvTA09jQPzgqMlJ25Qdwg1 7O17nhoz2hpn5RVOx6nXlRoSc1vkNL7LvvFV3sDHqaO8+zlPj7lF8NZZeQ0Pu0PYoAYu5xtqTOc0 vsorfJzvcmDXWAkJskVO47zsG9/eDXycbs0OshcIMkfWPjS6dYsP9PgN7FUqQTSyX91cYYMNQVb3 XOPjdGt2xLxAkFVGrV9sCw90k1Xk0Jq6RY51k/WNW+wGPky8sSPmBXLGZOkZmu5p8XjccFsTBAYu DUFWu7aesS30B+rW7IgpIU62yLGOsr5xJF3h4xxlPfthniWncSxdsDkL3cCH6aKeHTE5KkhGY52G HnM26hq/yxYzfcfQQ36YZ+hxjRumy9ayYIUPdMP07LUoQUG2CMrW1MBlQ80GaZ8KKWBJZUnRdExW r1nhw2YNey2eJWWySo5r3Po28GFKTiWI9dFtgoyS46xnXwsPdPTz7IV5lhzr6ecaT7gVPs7Tj+2P FTVg42aoafziFpwsNWmDuGOpoZ3CNjVm6jQ+cCs8HqcRsBfmWXIalzjXOFit8IEucZ69MM8S1Hhc uSbH0AY+7ASkEsRbn22CrE7gGx2gxQfmHNogCO0rDUG+0Qkal7ENfJxmwG6lFwgyF4yu8bBa4QNd yDy7lZ4lqPG4ctaBp4UH+lspcmhzukWO9edxjf/OBj6ud/h68Tw5xjpsaDxEWsz0fSoEgYWyJmho PEYG61HRwgP9RTxfl56jxvpXDI0/xQY+TFoLNXQSsk2N2WEPjRPCCh/oX+HZgfksQY1rwtAYI6/w cc4JkFe4tL0pqv3CFKfrWdr82n3Q8w9Ty3v+4R0JukDL1PMPH09Kzz/c8w/vSVDPP9zzDx9OUM8/ 3PMP701Mzz/M7e/5h/ckqOcf7vmH96ak5x++7fmHDyao5x/u+Ydfk6Cef7jFPf/wC5HT8w/3/MM7 U9LzD/f8w69HTs8/3PMPvy49Pf9wzz/8ugT1/MM9//Br0dPzD/f8w69ASs8/3PMPH0FOzz8s5KQN 6g6mpucf5vb3/MO70dPzD8eef/h1Cer5h2PPP/yapPT8w7X9Pf/wrsT0/MPS/p5/eE+Cev7hnn/4 lQnq+Yd7/uHXJajnH+75hw8iqOcfru3v+Yf3IqfnH+75h1+RoJ5/OPb8w69ITs8/bEnp+Yd3I6Tn H9b09PzDu9PS8w8b0o4lpecfNgT0/MP7EdTzD/f8w69HTs8/3PMPH0tQzz/c8w/vRk/PPxx7/uFD 6On5hys5Pf/w/gT1/MOVgJ5/eC9qev7hnn/4QGp6/uEV7vmHX46gnn+45x9+RXJ6/uGef/jVyOn5 h2PPP/yq9PT8w6r1Le75h1+coJ5/mNvf8w/vTU3PP8zt7/mHX4Ognn/YENTzD+9GUM8/3PMPH0tQ zz+c1tQdS03PP1wJ+HTyD9cjAwlKNdVQe9zAWoHgCHlI5ySAWxJvH3V9EarP9Js50oKl9MfKLmyy APh84dlUfhJVgB6F4rGufrM8Fvaan4/Et4iFK67hilkZV/GouTr6ykghVG7wkA0Kxqj5zsmad86i jBXsmNx4q4I9cg5DPReqmL5fKmCpYrcMvesaXjpxLkT92z+fbVPNbmlmsZ79s7829eyWlBXqeYVc qafqeekUpraevTKLYi37Jvxs6tgpDyfWsn96TKjnFbJWYj37J5Ns6nn5HI8nKni51ItQwf4ZEZtq dktUiPXsnz/wRD0vnNbP1rJXtj2sZf8keKfqedncdE0tO6WMg1p2z+SGteydYA1q2TPvma1gh3Rk WMH+WcKaenZK3oW17J1TC2p5hVRXJ+p56QxUTTV7JYbCanbP1wTVvEIapaae3bIbYT07Jx06UcnL 5gIyleyXoger2T9zTlPPDgltoIZd88xgDfunfzlVz8tmZYFadk+W0tSyVw4TrGbn1CJNJTtl/MBa 9k/EYevZLT8GxGLZP20FVrN/NgmsZ/8kD1DPK+ReaOrZISUC1rBnpoKmhr0SCEA1+8f1x2r2Dbdv 6tgrCj5Wsn9weqjnFWLGYz37h3I/Vc9LR1iHel4h8DnWs388cqxn9zDhUM0rRO/GevYPqn2qnpeO dQ31vEIIalvPfpGhsZ69AzZjLXvHUYZadg9vjLXsHXXY1rJfMGCo5xVi9Db17BQ6F2vZO6It1rJ7 oFlbzXYN3y/+K9SwY1hWU/5u0VKxlv2DmEI9t7vGFl1X8YIhP8GDcddInLaG/QJkYj37x62Eel4h nCTWs3+Ux6aenYIvYi17x0SEWnYPVYi17B1BEGp5hcB+p+p54Xh7WM3uYfCwmt2j00E1rxA0DuvZ P5Yb1LN/iDVTzV6Rz7CSvQOSYS37xwlr6tktfBfU8wpRtbCenYNdQSV7x6BqKtktNBTWs3PEphOV vGwgJaxk//hGUM8rhB3CevaPBgT17B6kp6llp9g5WMv+IW1O1fOykWawlr0DwKAPz/5xWbCe3cOl YDW7RzGBanYNLnKqhpeL+YE17B+Kw9azV4QMqGX3wBVYy87xJGwlO4V5wEr2j74A9bxCUARbz36x Ck7U8+IhBLCe/T37oZ7dHe6bWnbyg8da9ndPP1XPy3qNYy07O3PbSnbzsYZqXsH1eanntvwtRTbO za0Ps3Fw1p7P34CTbWlxd7GFcruLrSrR1NBdbLuLbXex7S623cW2u9h2F9vuYttdbLuLra1vs4Lu YttdbLuLbXex7S623cXW1qCL7y623cVW19JdbLuLbXex7S62qk5dTXextZV0F9vuYttdbLuLre8u tt3FtrvYdhfb7mJrSjQ1dBfb7mLb1LhZQ3exreV2F9vuYttdbLuLbXex7S6262q36+kutlJLd7Ht LrZNtbqe7mLbXWy7i213se0utlRJd7HtLrZNtbqe7mLbXWy7i213sX0NF9ue9Pfm1ZP+FrbPYtff /Chs9wm+dxMp3uTgSPid4JBxs8XvM1bdO4n/aPND14PfPa3KJTzjHKC359WMuIaWGaedLZHQhEst vTmtFt6z5bvbf7sBB49hGG//NxTiLUWzrxT97qOLVATMngn42OKgc2mHWMkGcfYxRcr4oCIrXz+6 SOKjHoGzryPw44ucUA2jAqmzS3HV27/57i9/lW7d7Zuvb37x5mZZKMuKu/zFX2Hw5YbZjXDR/Obp 5g93//Ptt/duaeXo/d1X95+lYk7np7vv7j8b6ef7+3++ffPfb375ZqtEP8NcdXEsLIQSf/7hw/ul yOzTMN/96/2i4qZ5nO7+WAv/c/354e2fpPiLHJqH20XMw8Byi+KNv9/hb0+XUOUdv76QOjux6zdP trAC3EjScnlLfl873eo3T7awAjIdyiwv5fX5zNly81zkqm50kb7S7qvGG5ahm1fKkBZeVQb1COjw hYzwjG+5C+Fj4MdzviYO1OEADKAR8YwSMp2kUQncEaWEjeHufCi7qTjCyzDcP1+myvSwDPGU7MCW cf2XvxpPzshl+iySdlEliuzB8n59Pz+EpZBw9z/uP1uUw0VOzXdv7pcVOcwu3v1yeYy/vjg3MbHg ME9FbkDBvylTGr/8vBSyzM883f3ql/eL0u7dZP73nwpNpWJ/99fQCGhPrfqv7pfHYYjx7vaKRmTw O4FG/P39Z5kEwrcf7pftD1D39l/uP+Oq376/vfela9x09we31LOIJpfv/lmJiZBuRxizyw84op9G 9WOkGepmsHl0Gf0jCyyI7sPcjCI6D7gzKrisM5nusQrGxzAe3AyWgAsmUKbKRHdRBfsIeMSyYINS sM+Ey1Sb6L6n4DKYJryYcXPZaBQ0JoLBAw6e8IDP4QTP5WJb5Sa6BikwIEbBksuMKjAwLlyYyJet 4CKwJ7p4cHnCpYpitBQMi2N6YIhPHYmtwi430Uk/C42JNDiF+XHhmkAsjA69C4SlndySpCmRuiAX taFA7AKmhKl2HtZwkqfEhUBdsOCMa7zPmomBu6DcF8IKrbvAcxeAxV/BwesOpENUB80kTxTpfTz6 LHDCx4Ex8IBcPcrAAgbTESYPvImcJ8o4hQ6ixQ2H7UQnkW4GLcUlcoFgrJ/rj0fkgpSdcGhJ3Qm5 IG2bcGBK2yfkA5M24bgWyrPmScauF55l5IPwdCYVKROqOhji2df+8sOAXKD+LDjF2t8FwzAHVXtw 2Pk0UgpOdRz5wWPf0zgrOKhxWHAds34ISDMN6fp05o/HVGeEFI7zpVSdY51O0jSabgVDf9F0FLpo uhYc62RmrvBcX3DSooB4mivLYaiJJKEuYTmTWUwRz6dGTE0spkYzGkTMleNKFoE4kqp8TMCGKj5h HFbpCvb0SvrCQR7K5iKsf/+zm28Xya6YDzv15r0iT4CCETfm/DhZh6Df9jWirxF9jehrRF8jfqRr xOipL54ATiw/FFhGjkWP+tWFQ2tEpS7oUSZNdnapQazWjRV6xJ2+EncMNn6a90tRmUmpvx5lmUpz bUzFahUEJLMfCq+L3ES33yt5cEFAMyekn4jagadKwCFQ5wZBvkKjJfllFvc+AH6QA+CZGpkEUaGl rmBankAnK5hhjDW2CapkEoKEFlqJFkJaWcHERy9BPkgjk2gctMBL1AzSyAqOrA+Mqca8IJ0Mw1OQ blECPIjukQCK6uF8jTJBGpnEg0C1huM2kD4mARZIKSo4sFIU8fWB+6+cu3CsBNLIOKgBTbQCQ7KP ndefD1X9g+KHqv5B9Xz8Sq2T0QRtZyd9Ji3OPLiQdHauJ87E+UHpZMVhfVaKrrjIM9PZoZ07JWbu BOw0eVh6lJ3GobfZtZuHQpx4ZcOhwm7ZNJLIf5rHWUy8bOIwZL9nHqYx8ao7IpXjQ7Iws9IVmtdz 1MXBA1VdQrK5NeVf1dQJiZ7MIq1IzZoJeFMYebmfvGYf3ghW9uKNXGU/9KJ0D6lg3HuomUjXkgIm XU+KjQwN1MFk4JBexOOKVDAZdqRVybAkOSPDlpYXGdbqedKf06SQ4mnSSO00qbhxNOe47TQlmTSe sET5aFXTOt+JbyIOiK+jZnoVJNgpVdBgj1VBlLWUwr4WIYZDoQo4GClV/uE4qvIRx1kVnzgORbri MK3CF4dxjVhl9+3Ee1na5cWVyKHn0dxe9lWirxJ9leirRF8lfryrxOhr+CragFHfnEQh1a0bYYXS rRRbwGOtnk8zeS2C4xNZOVrkPG3ElACk3/wrmJ/1bedvVz+BRNm4STwZhcurdRkEJNM/JL1xkyg5 KwGBGzUtsmNWIrl2hBwb0qpJc4XG/nquVPOr377Y8t4HwA9yAGxZ/cTlV4A2wK3+cD/dPRSTAbzZ Vz9/ds48IMYiJkueAA8F3bn72zf/hnf8MuQoBp0PAzad5Xwg0QrYB5K78J+CeOgQngYS4lQWxcH3 Y7a/p4GkOb2nscACivCeQPVQaMhQJYl2Xma4+bKuyIxi63w7035KZG9Zqs2oHpZ1yYyMzXdB84wO FuFmHF20tyxDfYyZLXaLikKQ7VNHTxoSvezXweEu2I2qz57aQhHGZOoQeL3dqPrsqS2UYOTLDXw5 rsPBXqzDeUvIoi8IJVdZXVEhpqVLIdLUqwvBXsNJIvSI7dbFImpPp1gZ9qwimB968BR+8Oh5Fj8i xfJlfnDnlELOmXT6Ge59xhBJiP7h7h+/vP9sQJNOf/fh8T6QqdY352QxuTvXcu4+OzflApz9qrc/ f8OvnzN386lcM40u0NKhPtt6O4NYUa+fa5PPsPmqby+c+HnhxJQXJkdlQqdM2v7uLE/QfP3K+skp Uddfq/xf8us3Z2uEYEC6iG2bu88cdup58zviNl4flua//3COfxMocer1s9wu41S//OVXX71/+6c/ nWOQK9fUV5ZPjn717T/cff3l078C5cVM8F2xGER2/Nftfcww3u/+2xX8iHhQAUX+33tXInou80Tx VNkoKpvJ/7z/LIJVYryLi7rzF0u/4Du3S9eC5eLF79L2d//4m3v3EJet93z3D/eppBQYw93v/qLY ZRY70Gv6OE51+qtm1MGz9euLMj08Tg89J86TpkxDt4xSP//VzwvtSMSm7ej/U5acfoANavQUPMUH 0A8IvwMMhs6AC5rw7XJhV9HsQfdAPCdWW7CsmU5PaJVoIZ2OyNsKFxUVsQ9FU42wTa6/R9SyAHqK GiMUeDqeIAIlRA6peT9Nuq893YUDrugnviiGrUbBfB9Zik58tgGbnIIntd0rmA5Gitgp0CvbmQXf 4gFdQsP5iXFRJf1Yj/9mdAjQx3/VQQDteqKPD2zzU36LgdCIWAyEgEORT/MGYGDgwz7QrwvmI80B Hwc+GgYeBD5+BWOmwuCsDkwLTsoSijuAjl+lu/D4lUaUHL/K+JPSnJy3lo/ZMoPbMtTjVuivwZx5 FyzHrQO8r9jgxGIEjl8LZpYDEH5HfFn4Xfjvspy3Ihp17zmxdYHj14IHHgmFCU5MZWA7XLA6tSgw 8MAK+LpT487xoQfOqILFcGrE5y5ZzMevhQn19Qn5IMVNyAepzTQlIx+4pRnZoGx+DJ1zw4eZ+TCq 81jmItkXCZPp1FI6geyTpIfwzFM6kKybsHfpvFS6Hi2jZGTQAYOMHDq5kZFFxzo87ooU8VGJxSGi n4vjo2IRo7PXz0UI1QkhRft61uFznVDStMAHw17PRyEs8E7W4RyI9WA41clOB8EiDJinJCjwIFjE CHdIFTMziyU5GCaxJKfzc5VhOBiqgMvINJF/WQvHCRme6sEwcIFFa3rILHjNya1m9JOMbX6RzDKr eGnmwkdc8PUloC8BfQnoS0BfAj6VJaDcHdYdyzBie3BPcgrhDsVgQRDOk4v1GNSg1m7WEcRrREvE jFc3tAZ5tjCYkIOABTl06dDo8UZhsM1s0SyUP8rS5MZmrUO7zhXK/OqjWtccBvDj58lKaKFAJLa6 ptUdRfTzwJ/8rZkok2KHvs17kcW8D4kfx5DYOlSi5SAUtel5FyoRzbXjQCEl0gDLAOF3jCXPPb2/ lff+7KWK/e5pVS7jQMsMv8/42ksP+93TqlzGA4lefn9Yhyu/WE+Mlp5J8eWqywQuRDd2UkRfXQj0 ILVEKBqfcUMj3d50z7MKIXLMWJp8HUvP4snAkeaJJ9xBly5Y6CQszLBQwwnrn+7Z4f/fq8P/28f7 TMeeNejFl8vzu3fnzm9Hj2Y7UvzZU3G6cNGN+VY14f98+KZceEDoDa9jePz7VcEIInoglfzdI/nr /81CShhiGPUR8O/+uvwe7n5ejoKR5M//5uxFPxWMVlPPLXikWCJf/H551fk2IMLflZfx+PyLXy49 Q+fQn//6nov9/Jq2Obpq/oOu/fF+pl8fSu+6ZfwuvSs3D999+1f3RZnHC4Sr45hEcHAbHcfZx7lB WERKzITxdYFXS0j92dOqVMaBjProdYZXyy392dOqVMa8TaHX3TqG88VaysKmiZl8JeY6SUCF6LZO vrb16kKw7+D6utITrpZIqr9HtaQ8rxAixgyiyddB9CyOOA7BTRzh7rkoG1ErGocavuSZ4mhTIsKm uhZ6XiJ6EO+6Ce9E/FZBXEX2h7N1R9gaXlt3pBvTWvfTIjAwYMnbpxLeBESDCn309v2Vkhh21hGd bNvwLe+/+3C/9DNcDi7LznReRH1xW2QU3Gz++/u3X799//bbx/tyFVuu5d6eF43YihF0TmhFvaD8 7suvvvjjl+/uPVX0JZZaHp4vdYwUQ4dLXQT7OSaPcLCh2vC23AI7pOhfiqzGwDHffFASmOZloqiv MeAxUKJbroKLZoG4oPIQVGn5HYp6jjDMrN1hOQVjHE9ciNeYdunyvmA0AEeM+nWY1a9SzeMNQmrE u9r60QjRNFrbsZ8izdedJpcIg6DSUphRijhYMNpHZdhxDpxdLuMGeXDIuYLLmdJAYUgxSFSBGF8Q A1cVjPFDM55oDWR3VzAwaKbovxnMHmdKzJbRwnzmDGoZztIKxjChGSzM50wBdzOIhIIxQ1lGg0CO EZjR4G5mC7aMBnnzxBkBUJmfJVsXasezhNiEiIyzzYQ1pxodv9iXzjWFFQCJNYsPb2toyVlCTWK5 YzVIK5bus6RGmnnMDExGaVUkhhNRkRmOho0zJyJinnDCoIxG+nOoDAeWBuF4GSVzqBzHp467r9go zp45jtbFs2eORwA8MjxCYndEhnHqGhxJBSO784js5pwzOBALxtcT9hadhRYMnUv7N4Xp+YSM4M+n h6QLn5ANUnnGkSaNy8gHafyM45Rpm5kPifGUFF/mQTFtHrDzmafYZGE5tLB2CDaxdhg2qXYoNql2 OLZBxgM2oY4WrLWOJqi1Djaspo5FrIYGKpTZ/KYBLe+xoKNyeDZQNTRXuBE8k7iRPNOYBp6JTCPP VOYBTWRmEc9z4mAW5iN/54b/s/BfSRjqOJE/0LFKPkG/K/kF40LJNxg3VfzBsFLSsYw6JTxhTCrZ CmOWZK86UFbrCKjjGOU2Dlqw+EglxDoJnn2X2KV/l/5d+nfp36X/Jyn9i0TGvguzdCMJf4se1YtI b4toPYnFF6VUnWBB0csIwRUolyqISph0DFNeZRt6T1I9p5B8W3FFt7VQahtN9WaJk7YpkARBNHYj Jp5u1BsifH28NZIZMVWUou0flxQ+PSHqBeL3XLl75/9QO3/Thw/tFtBK52pvwDIGEvuUlbMKMLIS lzM6gkBIBxfkcqYQuJwxHtEuhksayRCGb69WmGxs5H2FJ3leUBTXUYUS1IyQ/eu4KPKpC+q3HFf8 JIm+UktHbYYj3pOyM42spmHejJHVNJwHE+chIlVqiqyuoKpV4vspTWyKVlPDsPpVk5s431BGQJoU qoAl7qDSECfPahh7sZKWhvrlxCl4SP2cRBKhejpp3XXiPDqk204yQ8kVU5ZXdMXkxZcU54nz46Be zQOK1O5J8trg4ySaAO4OuOuw7CQ7EdxaJLUTKU1LaiuSACZNVuKdCO5rkuxEkCuJ9R/aFSXWj4ip aao8n/B9z/2RWPPCDVnBk1edmVjmwX6uQK+HQkoECscSa4M0jtJYRSL4yLIymeVKVNQdGMa8N4EZ VqAoS4S1zl2/LuZ2qnBUuWvlYF6nGoeqW2Kd2kdFFul8QjUuAZUrqDIK03AfIAwlfTMpfVV3B6mr 0l2o6dfuJHWXextV+zoYSFeWsYKqfB1LuLjIUKOlXGTIiGzgcUoypQIZ0fSmDHgqiOcDViOzhVoh k4laKZONqJDJSEROmgMyjYlDMs2RgSIFiL8iJIj9LEOwc0TCUN+J+KG+FfFEfV/FFw4MkW44bqrw w3FVhSMMuyo7cVRW0YqDVlLJiIount1PvLucJIMdi5aB1f5Up8FHHNF04d+Ffxf+Xfh34f/JCH8c cTOahvCOF7Hsfwc+E6vo8Ubh4G/XyMu+5vGGjymnZFYShCsQBD3KIfPUpG2kek4h+bZiRkQblYvo Uc/6Zq2rLawAZkLEWr6xEuPpRr3AIrsR0XrkM2ekp4h+xidnhj6p+Z5LeB8IP/yBsGngPWGkKk4P VS28jb1Xxm/ybUK7qAALIpzy/Op+kRglVW2xsip2OOnuz++LydNw9/Z2/ONf3X+2CNDlT7y7/bxY K8Gr3/35w7135RVjIdRW40CSQzXv7z+LUMMft79A1aF+YQ226mv5wZZbivz266W9d99tF+zQCO5i yQ69hdR7T9999fbd9ruYZOFymZg5QLf3P+8nYqe/yoKMgj+pqp4XFKkMMLRLfLqJDhXRgQ4sCZcQ IOgIhe8Lfk5gpPrd06pcxo4UD37frfO/XkMPffe0KpcweXpKPYKvrwfjcFV6MJId03NlQCAspDYW C3HPjSpEPQiOAIoiUFiusw6t3Q6FKDZdXwiRo8YS7iR4LD2nEOoQKUQ66JogSUv/5yTm55ez9m1G +IEUA1LMhXBAcI+mKwVvgJIdkwPCPCc75qWwSiUaWxol298z0gj+prDixRIDnuMfbjh0M5Wl6pl8 gBfi3xTSRy85BquNauEB+g6oxirz/vrmF79e5Cu+qkisz2v8ps0wTL/47rt39wNY38Z89/bLb8+y Afccusk60eFV5IZZXDQqkZ//fWEbdvrf4m/wsPgnE3EHxckMRyZPHCSQ8DvAiWEBOQKKUSNP4QUL jLQH5ZIiOZ+R0G1h0q8iQIEXMbhgwiJ91ChycMHE9ddCZknZY3GNtfPTonhTGYjqqrNRBq4NyID3 PrwYQJTsQbz9MYQ2C3WOrz2wtz/IYPH2x0CSs3j7YyjJmR3+MbRAwejwD5EH/Ez+/hiWoECKcg7H DAVTlPNyKlEgBTmHZZOi5IkHKC4I7zhoeYEUYgFOTAqWIOeThyzHOtBtwRRiIQHA33AeQRmREfsM nUfxFoqyL8OuwDHxSEM8ZOlreSyJ0PBryYNGhUseNKpcEqHBt7rJEmOeSJIg80SyBJknlkiQeeKY iTJfoPA/AhT2Z3x7MN0lQeaxMzleLXW1xA2moSC5xmioSDxbGkqSq8whFziVGQzDAin8QlmtJQsa DOCCJcj/hM85yD9jeh4ezOcB2SJlw/FMrToiW1SGthR1yyPyRSiDzZuifNR8wbgSlWvo11u5igG5 hOkUrEv6BD38pcswrETtUYwOUHscI0vUEYGhBeqIgdASNJowLEEdZxhXQsYhRjVQEooEmKRRE9nL j3Ouc4C/lrRqAzJV3KqpcgmvMWOfcHgNareE18h28jLdKrxGnfnMMw6vMeHImmoPZCVW0KW7Sh3u MAlDMuLA5iAl1NsSw2RENkiMExotIhLjg5GY6FFB4hTOCZWsBauBKorxPn4QmxuJ36BY/8TDXd5r xU8zOz4igE9fL/p60deLvl709eIHu16ExF3zpHFh2oCbJgNol6SQfETpGDV6rGuQ02sOQlk/VqCE Zglqk/auwQp5C9SXETM1n0CTp9aRADDyAPOn8uy3aH7gmC5aeMhqW4VFjjhBlTAPaienVmfpJVpN ZdpkJd7biaGD/bzAst9Hw49gNGydCxQPdQj8Pfnn3hGMGHYICCpXcRR3iPyKEl7xcWS0kl6CwdW3 A/Wjp1WJjAPHYisvM7j6vL5+9LQqkbGj0254mcH1NZAJuJBBwWSIjOtOv6mQ2lIshFt6ZSGlv+hO gWi59lvpXkl0wKx5JglqwKATOg+YZ/EBO6Hywan7iLO3AJliIn5c5JwTSROylHghY4KD+IzxeTEq /oNVB0qnK8eXNfd4oOzhcn5Z0x8HznE+cz6YBUq4QipI4hMmjE+2whT9kF9niFcyAOmc0mFkREGx JoUpWHKpMwWSuYwojNrX4KdM+cWwLYH3LUUejBm1P9xZEIrkp8fvMr4+epD+7qktFuHS8FoFgusj +shHT6Y0+h1wneXXCD6n9KKO69bnXJt/ZXQcylceawnYxqs/n2Qz+lRJyc8Ixlb7VvXC84pgXqjR kuse+FmcgF6ovKBO+d0JzyDcWVTt4g93P/8Krvvgbu2rKn3f32f6z7d/ul8+Jml4NkYQ7uyq5nI+ ahrsZHVLvob7wHK/CJeyNWxPFcdVRP/X2aZAPoUrWxLL3jcFuburlKsl5+r76NGVm6Za3oVASXg2 omrf7T46ZjBpdGmQu+/vH1SNrTbgem2ZThFOM/i2rcCRL98wsVy5RiuO/ALgTo2gQ8srLsWRVS5P 2hUm32R5XzBeCSIuCF8uHlwCsFpAfHUorVf2Jwgkms9PidytMTTCgQUVcSkHHIaLXvTawoKPuuCk 8Kx+DBT20sGWdUSb3ehwbzuSxUnBZUs3kslvwaW1I+mi0SEjR88mU4Hu/AkUeTSSrXHJXJcB0mNk 1kimygUP+BwDOTng7Yh2zgUFhCNzt8j3kWwAmdsjO+w5PCSLbGQ14IlcRPtrithZYGCMT9FTcMAz skjG3QUXPkQy/o4DAvyNR2SR7MjxGWn85UOPwztGXTCNb4zxSWNaNYsM3AtOWQ0wpipVE7Woxhss /hyQiiyq4sj8xrHKc8DRLT+HX6TuiDSFHM28yPzGzow8RRypHpH5TYpUYKO2CECPokhxEwoGJlBc BRqDoss5VG4jxWSgIMIFI0zIA89mbYL5sfk4GZWIos6rusFmqjZtQq5wy9EOpVKVmStE9dxwZWau ENdm5Aox1Q+K4RgqvnYIhoqv/YVzXbqTkiRFBsASHgcUUlrGCcaCr+MIY8HXcYbWnDIMUcmXQYqK fR3EGOu9jnDaBvAE4MJ4cmCg+Tp5uDE8uSBofZ16TAvNTIqkLROXRB7PawygX+c9cVHkAsbjr2ID O6AKlRkFlAidmWUUTZJMMmrS/S/PhqyFHQydKgsnlFAiK3HkVVmaUEKxqMVhO4YmAj1F0iduP8nw 5xdX8qZOj49LQtKXhL4k9CWhLwl9SfgBLAkooSG5CnXGCQBpFwxkQKkVqMiM6SdU3WZVGSmxUIto wcBaBrwV5ozABQ9RamKEjTDo8UZhCFbXIp+Z7EdZqKJrVj4YHi0iEeA4AYV87R9wlbMyYkBrAE3D pCdA5Q9XTSzwdjrIdAm+llYvKl9ode9j4kcyJk57rdX8BGePBHxAeeSLpczzLjdTwOhtnEdjQlVN 8mgQFssQel/wtYfs9runVbmME5qF8OsErz0MN589tYUypAWKXyb4nDqiJiQa05nr4uJjGdJMLIKa eXUJ0G8OzsyEFhIZV5UhfY1lCHueUwZSooZPNDljnsMN6IfKDeqWS1edaYSwFDWnRT3ZPXuhmRLG HeQPz54oJ/BeVZV8v9PsVIIWXlfxCMEqhvCQdj7ITnFANSaK3+v3P8ge0erLhxFXuuTQ+CuQ2Vpy aByGuCDw+AGRqlAqUp4xG+xwWZnTLdEUWOGZ66L3FU4MCwiJ7VQUilg14kDmc0IGzXkhswpFGPc/ cfIvTnu408FSy7xHnZtrYTyQbSa9zvD6hUd99rQqlbDLtDHE1wVevyioz55WpTJOtEeg1xleXwts 5Awxo+LJldIWCjFtHRXJVxaCfUeLINPjnpHySvpbFlLi0XMKYY7oQTT6OoiexRHsjsoR7p7LSxAe sfjq5VhvWVXerHfK/uXc6oDBVWpx51cIjA2hK/9+i9OEAW6vrX5Ec8fqpLnjCgWG5C7lesv+Avmr wjDnUs/DyENjis4tOj4YJZBoQ2YUCY7qv6fdfHJ4Aoi4oBmfLgNHEJwaPN4QJtPsd1LWMDxo+aYR 2WXLuwYXMwXECXQJMupmIMIbzLM9HV0IAXQwIgQOEgyFpkzny5ovF7hy7Wn7iKuu99DYJ8DlEM9T /poR7Gm9Tw9ogISHwz5R0zLxlvLHjBnBgC8THRT6pmCYzRj0qMAidD0FVBkzWut7ipk0og+/95GN n3Cp9xRyqeAEkJHDtx2WhgY3ng4LyKTHU7inAste2dM5x5jhQcGeIHCBTsbG7HnUTJ4wycWYCfvI owpwAfAL3c65c/EJrSvyGZ31SbGOmU/VDsR9ahUPDG70wNwnogbuAKDZzcx/ZImbif/IMTcz/4Gf bmb2I7tdZvZjd7jM7Mfucvkhqt7kgBnc2W5i/uNgcBN3AD4k7uMwchNxH0eZS8x9GIMuMfNxiDo6 Sh7BqMpjtfyb+mGmmCPyKoX14KJmilHCNc1kaUENQVee2k703alEzGjmwTSir07lAfrqCIvmqNiH vjmVvWhGXtlPZv3SO2S+z51HjvPSt+htU7sevG3qyEDvGiVS8I6BBxZG6pBhh/40dVjOdKbDw5YF Eo9pfu71xzwVqGyeKVwzzyRuGc80ajjNQyaLpymRLdOYuCKznLgmUoC4ykKCmC4iZI5KvlBvifyh 3hT5hJ3N0ouGggg3Gioi/GgkiWSkkSaSk0YiC1YaqCJ2cRyjVFZH7wMoIWbZo/wqI/q8yScrwUPP P+5Sti8TfZnoy0RfJvoy8QNcJjL3UVkl8KQD++gkgs2QxYLKi1imh5e4BdTnsgrBNwbVNWSET1nm sQDErf6t/MR6DXq8UXg07xIiKeozvIs1urFZA0ekt0WRX31US56jfCutzMiOtpkayFRgrsjqSJRT t8lMsTOnHln+9sUX+z4qfvijovbgcxU3vLCvihtfUNOiGZ2st2ji4+ySGx0vucvvgddbun8eeMGl u/CBtR26KR+YN6gKxEHpCWFmhYcO8mfWeUDNCDMPcNRCwsy8QyUl5AelwoTMGg9qOCGzxoMaUMis 8aCGFCZWeVCBCtMDq3ETHikHxl5fMmQ81s166vExLz+M+sPE2g4VPDLzqd6RuU/tGq26GcYHrbiF yB2AVEfmP/EkMv+JZ5H5jyyNmt2B2U/dEZj92FchMP+xL0Ng/mNfB/+gdfjgReEHwNo+Hox75j6O seCY+zAEg3tgLY58CYNS1cLAyy9Cx6svLoj1bVwvuTBaTqUqWm6lKbQcS1NpuRY6cDFnKmmpFyaQ KiBMmqPiICkRwmHSMQJrGHNSXcOR77jrOC5erOqP6XlUf3hckHIkw4aUJxlWqFvJqCPVS0YlyRke tHyFxgO6Ps5Zfy5Xblg6TxaunOYSt22qGmhUM5EJ45nKhPNMZsbQPGe+sRhgps7SA8j0WTpBiRjq LpQ/1JcinLCnRXbRQBDZRgNFZB8NJJaLNM5EbNIwFLFKw1SkLo7iakVFepvlfV3n+cWVsKHnPDs+ el/fl4e+PPTloS8PfXn41JeHzD1Tt22IFYoagMmOxQqVwP9Sas5170ZGp2oFgg8NqotHVDs3Lfq8 FKwQfKrRo37XPHTpVhXrktq+hWG1BtYGCoj8ot68oXiQzZtIC9qvaQII61NDvTaSNe/s7UxoJw4v zrQ2v9Ay3wfEj2FAXGvQNVIgIjZOGsnjh/EwaeM0gc8zTqPPnlalEs5sdwdvM3qeaVq2VnbZGtlx si18l9EzzdIMGaPixnOMsLI15MrPs+PCPgMbezZK4yRjz7FJkyKYPc8pg7mhh87o69B5TiEpGYs0 7pjLBmkY2C3Mkn2g5i0o4Z8yhct/+75kPoBEBDpE1IfzxsvAZSn7guF0gHBENRzJ97Schuw2tbwr bNOce4UwIGSbNlUjvFcxTQsSIvCpmkLRbU4xq/KSw6SgCd6uPx0e/jIexDIYC3K08NG0auDAdsb0 tsbFAgsxGV2h/2oFsxcLLGqGMuVSFlhA3/Mt0356bHlBw7QSDmy2FgcURRe3iWCqZ0wOKLYXYuCt Mjmg+K+4Hy1ycLYmBxjeF3e3iLTFAYWDRTyU59bigMLDIoa0P8bkgGIP4z4cEvoYkwMKGIub+tnf UiRj2eRjAFmEKgcPHRFQrErEMdchRkcMBev7CTcrowMKyGww2xkYgCUpo4MJOz/rhiijA+iuwZyx FCxGB8WCNiurg3iLgaflrKJAMTqAzGnK6qB8nG0PZGV0UAZmZqMD7MCsjA7AJF4ZHZTuz2J0gOM8 V7sDAOq0guJx13GXldUBQuI/jtqsLA2A7GSAMUOoH2MAslo2biNr3RCIWlqGe9Daagw8XamCLWwl GgNNV6bg9ld4hnGlK0tx61xZjrGka49wAFdliOBrf+K+vfY2BouuowG2/XWwYHBoJWgwcd5c7RBg gllDhDpUMQB0Hdf83OuPleGB82rGcN3K8kBlKZOWs+XByLNTLA+8mszElVkZHsSsZAFxlUUFMV0k CfXJrGwPSp+JJMIunZXpQfBVjNGAECmHw2VWpgchKQlJo00kKI3GuZoelME629tLks8nbQ+CLGNP q09oWyfrCz/PpON+1Gl2XzP6mtHXjL5m9DXjB7tmjIn75anBeDJJC4YBjzcVgo2RfLZCj7pdZuFB rFaRFcKDySFaAVjxSdR+S3ZJgwxBix5lLctjbWPFaqmsNkuEHtVKmJWZkhEbl8Q4c4hXSmIC96tM ls3Jc8qE7QWUgT5WfpRjpXZqk5kaIiokCN+EGVaLNytktX771Z+/vfcDprj+6svlN6a+vvtQT67+ P6VLly8KZW5kc3RyZWFtDWVuZG9iag0yNyAwIG9iag08PC9Db250ZW50cyAyOSAwIFIvTWVkaWFC b3ggWzAgMCA3OTIgNjEyXS9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgMjggMCBSL1By b2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAvUGFnZT4+ DWVuZG9iag0yOCAwIG9iag08PC9GNyA1IDAgUi9GOCAxNCAwIFI+Pg1lbmRvYmoNMjkgMCBvYmoN PDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMTYzMzM+Pg1zdHJlYW0KeJztfW2TJLeR3i+Y /zAfZy5uW4XXQinCHySd6DvHnS2RazscugsFPVoepdimJJKST+Hwf3ch31HV3dO97FJxRVAR4jzs qiwkkEgAmYnMPz4Mj/V/n/7nB/dY//f1vz+E/JjG/Hh8GBP+9R7+CvWPQP/+8uGLv3v4pb48HOJU hjA9rv+YKf7ok3Em/faLh5++fXAe3pn/NQ7h4B+jOyT/+Pb48JSeH9/+7uHnbx/+qE3g70kDtE2p jPXNBvg4HWbKczvLdPBlhfHhLx/+5989fDV/ZjjkYSwxzI2d6ZYc5lZ+8/LVTA0ePcQyNwFAjocJ +C/lsIb4qPTKL/+6HITJe+DAT9FZDrCVzIFjOsjBAhJD3wcOhsM01XExjEBjiZFYDlEb3iLmahc2 LnEAzWQG0mE0wrOEyNBuHMRp8KcYgFYyB+4wGeFZQmJofxa8S6NhAZpJLISp0pc2LyBztAcLCXv+ PB/YVuYjouphPhaQ2NqZjzRM5RQj0WhYP1PRhreIudqHDWi0ZaMUH5KyAW1lLuLBmcm8hMjVzmw4 N+ZTbEBbmY/hEOxwLCCxtQsj2OxLjEBjiRE3HrKZEAvIfH1fGInBRWUEG8uMpEpFGVlA4mtfRsLo UzrFCDSWGQmHYpbsJSS+9mEEmn2JEWgsMTLUBkvDW8Rc7cxG/QfYqFssZQPaylzMkmO4aBHytA8T 0ORLTNSmMhPtbnYJkald2BhzHOuGcKwbQ1jN8b8oG2ZvG6fRzuoFFLb2YcSnOF1ghBrLjMRDsYws 4LjjJFdG8N8rPqCtzEc4xGgavoDE1veED/hD+YC2Mh/uMNiGLyCxtQsf87nbj5f4gLYSH8Ue9xaI mdqZC5fyKTaKngDj/BFvuGjRfue/NE+EIV9kYpStbizNuXUFx/22ums2cHSUDXOYjSXOb5iGL+CO h1llxFUddYoRaCwz0hzDV5D42oeRama7yIg5m8dSh860fAH3PJufYATGSBmBxhIjY2NVWELma2dG 6l73BCOjsTLEsRwGs34v4Z5WBrTbXmIEGsuMNPaRFSS+9mGETIfjMO90IzACY6SMGHPJzOIhm7Vv Cfc0mJDZ6jwf0FbiI1tDzwIxU/tyUY+3lQsUNOEiq9Un5mzOfku0o82HLVbnmchyEIw5HYJZ+JYw 73cUVDbclN0pNqCtzEdjc1tBYmsfRsjQYxiBSa+MGBtczI3RbQX3tMGxfSSzr2/FiLHBxSTkoOUL mPe0wa0ZgXkvfGBbmY/GeLiC046nc+VjlrFygg9jSowpN6veEu5pSmRjz1k+jFM2psZ0uII7OmUT G0kMH6DElBFjSYzJN6v3Eu5pS1RGqs46xYg3q3lyjX1kCf2O6zlZF87z4Yy5JA2m1cOaoe8JB7Cc KAcDNz9aW/QCATu7tr+e/NKJ9ke1Ssdo7dBLtKNVmi0K55lQq3SMudl6LOGOVmllw4cUTrGRzUYk NtEuK5h33IjwMVwZwZVQGTExMDH6xrazhDvGwCQ+veYaj+ROMeKNqSc2Do4V9Duaek4wAmu6MmId HmFqjFQLGPd0ePDx9Swj2FhmpDRGqiWcdrRZKSPz+nWKj2JMViE3pp0lLDuarPgQK3zg3kT5yMbQ E1qP0xLmHQ09ykf96xQj1gMVWpfTEu7pgeJT7HlGrAsq+IO3LV/APV1Qwkj9B6y6rdsD28p8tL6z JSS29uBDIm/P8mFdab5xnrUo7OhKi3xkyvMWK8IeC7crwoY3rjTfup2WcD9nWuRteq7TPZ5iw3qh fGjMbUu4oxcq8lZXGcFdlzISjPnNt26nJQz7md8MIxxZuWTEeqF863Zawh29UJE3u+cZsV4o17qd FtDv6IUyjFBoJe4ehQ9nnVCu9Tot4Y5OqMhbxLN8WB+Uy81eZAl39EFF2lmdZSObjYlLjflzCfN+ GxNhI84bEzDq4hZY+UjGGupCs4AvYdrPGhp5X5Vn6QrjKUaCWdCda+yfSxh2XNJ5P2IYgU2wMuKM OXRovIAtYq72YYM2JDnMa3k+wcZgnIJWOTV/7+cQPMUAbH2VAZkWQ+PFXKDdZgRvQXKolulTDBiP 5tC6/pZwP49m5HU71+lQF8CCW3dlwzoCB98Y3JZwR0cge2bP8+GN+W1oPZhL6Pczv0VeKWCCOGAE TiHKiHFohqnx/C2g8LUPI6Rgs68zZM0INZYZaVx/K7ijJ/AUI3CgUkaMKzBMzXWIFdzRFRhZ1Z5n xNyOCFPjxFzBHW9HKCNz64dyihHj05wftk7MFdzRpxl57VBG8GSojBifZpgaJ+YK7ujTjKx1s6sB MacYMU5NbLA0vEXTjo7NyDo3Vx9UAjbgXChsFPUMhtJ40VZwP99g5Pl9ng3jVAul8aKt4I5ONWWE L8evGDFOtVCCNbmt4I5OtcjzWxnBg7oyEtQEF4q3+5EVDDua4JQRuiq/YsSb7Ulp3IEr6HfcnrCi Os+I8Q6GsXEHLmHZ0TsYeY4bRqoSEz5G4xwMY2n2VUu4o3NQ+TjBQjEbrLG5iraCZccNFk/uUyyY O2lhbHyZK7jjnTRhQe7MFzT9KCPGtxnGxpm5gjv6NiPPhvOMGN/mvHlp9lJLuKNvMz6aK/MrHoxb M4yNH3MFd3RrtjygCU55MC7NMDY+zBXc0aUZWI7OM2J8miFPJlBsgcYdfZrKBt+VX7IBbWUurC92 iabdosYCD8F5JtQxG7K91bhE+7llA7ddbskXNIoqE3rHMeTmMuAK7nfHMXDrz7NhrgaG3LiTV3DH q4GGEbrwX9DGq4wY73LIjTt5BXf0Lgdu/3lGjHc5pMYLu4R5R+9y4JQFif8oqQnCp8YyI437cgV3 9MoGvlEuV+VXjBh/ZkiNA3MFd/RnBr5cfp4R49AMKTZbkCXc0aF5ihEbhE9tZT4aT+wKxh13JXwx W679L/kwftmQBruAL9COXtnAd4DlnvmSi0GX82i9sAtELO3CA1//VR7QlSNMRHXJhtjcaVzB/Ryz gS//yr3sFRvmimOIjSdzBXe84hjIsWn4AD+O8mEcmyE2nswV3NGxKXywfK34MI7NgDlMteELuKNj M7CH9jwjzizmQchByxeQ+dqHEbo7q4ygP0oYwcYyI62Hdgmn/SyHhhGa8ytGrIc2tC7ZJdzRQxv4 zul5RqyHNrSezCXc0UMb+NIpR2UUdBAqH9avGVpH5hLu6NcMfFfzLB/WrRkG0+phzdDOHJDaWrHA dxyDb/yXLQp73XEMfOI4135vPJne3mpcov38mCd4ADez8qBXHINv3a9LuN8Vx8BXHCXpwooN6431 rddyCXf0xga+4nieEevE9K2zbwl3dGIGvhkoyQqKb7013vr+XOskW0C/o+8v8IW6s4w46zlzrats CXf0nBlGaAVcMWL9Z651mC3hjv6zwFfqzjNi/WcuNmv2Eu7oPzvFCARjKCPRrOGudTYtYdxxJecr dZJAYsWIdUANjaemRW5H95PnG3Vn2RiM32ZonBwLtJ/fxvOFOs7AUDCcRHkwHo+hdQ0s4X4eD8/3 6c5yYf0EQ3NbawV39BN4voUmSRhWjJjLW7MAWi27gMLX94URiO5hRqixzEjjGFjBHW89eb6Fdp4R 4yeYZ5PVsiu4o59AGeE944oRY1/3U2NQX8Ed7eue79OdZ8QY2H2x1ugFmnY0sHNcq+ECoq2Ei6K2 aW9nQ/P3flZpbT/t3Fftl0lRGlP6Cu42I/gG3XkWjF3dl+ZGygruaFf3fIPuPCPmgso8fxrtuoDM 176M8OFjyQg2lhlp7J0rWHZUtmtGMIpPGTHmz3mltMe+FdzR/On5UuB5RswFFT82Bs8V3PGCik90 OfA8I8YA6rM1GS7QuKMR1LBBh8ElG1mNiLMUWovbCu5nRvRshT7PhjHA+bYe3QruaIA7xQhEuSoj xm41j16johZwzwJ1nl2B5/hIxmzlU2OnWsEdzVbKB9kYVnwYq9U8eo2CWsIdrVaeL52eZ8QYe3xT 6XCB0n6mHqjmWVtsfj/eRnlu9V+773vdz5ah7wMHve7nnhz0up+l1/28Mx+97mfD1c5s9LqfK76+ L4z0up+97uc92eh1Pw1Tu7DR634eTsBe93MLPnrdz17387sx0et+9rqfmzDS636uYa/7eQ9Get3P wwnY637ejYvU636WXvfzPoz0up9r2Ot+3pWPXvdzwdYufPS6n4cTsNf9vC8Hve7nX52HXvez1/3c hJFe93MNe93P+zLS634u2NqZj173c8XXvoz0up8tU/tw0et+9rqf2zLS636u+NqZkV73c8HWPnz0 up+97ucGjPS6nyt+vi8M9Lqfe7DR6372up/bMNLrfp6Ave7nPRnpdT/XfO3DSK/72et+bshIr/u5 5mtnRnrdzxVf+zDS636e4GgXFnrdz1738+6MPPa6n0uWdskf3et+9rqfd2Wi1/1cw1738x6M9Lqf J2Cv+3kHRnrdzxOw1/38zlz0up8N3M8x2+t+Hk7AXvfzDnz0up8n4LSf5bDX/cSW97qfd+ej1/20 /OzDQK/7ueZpHy563c8TsNf9vAMjve7n4QTsdT+3YaTX/ex1P78jE73uZ6/7+VdhpNf97HU/78FI r/u5ZGff9ve6n6XX/bwzI73u55qvfRjpdT973c8N2Oh1P9ew1/28Jx+97ueCq10P5pK4Z9QEY9g+ aoj8XUnNCnr+s54xlHBFL6ZVeAKpeMyM5744DEBF/3qhHqKW4g+1i+b/Sm9XlOOjMAnoRZksLBbQ MsLa1/VcTgA+8jL3QH1WO+xoOywsOlSwb5o5aocK04ljB6hTDJah+lILpZr+rWz7KPQQ5GgtHwLN +G1WAnWj2qSnCN+vZChQv0T4Qyt5CuG7F9hcU75X3UtIjrZdOcoF+TtXiUTqWxVvXFC/e01FoL9h qcNz9O9VgbClf//CgEh/q3p9C+p3LaOHtLeqbgfUNyw6h/S3qwW3oH/vEm1nyN+rchqQ36qg2YL4 XeuMIe2tyn+doX63qlwt/fsXy0L629WwOkf/XqWlFvTvXvEJ6G9YiAnpb1cfCehvVbaoJZ7uWU0I SW9V5GdB/e61d5D+diVxgP6GlWrO0L9XAZkF+XvXdUHym5VbAfIbVkFZ0L97cRKkv0HNkDOEv2sp j4bsfStsIOmtCl8sqN+9HgXQ37BMBNLfrnrDOfr3KqoA9DesdbCgf+8SBEg+bVUZYEH+7gn7kf52 efRb+ndPbw9pJrbKOo/Et0oGj9S3y9EO9DdMnb6gf/eM5kh/u0TjC/r3zv8N5LdLy43kt8qW3VC/ fxJrJL9dbmmgv1nKZ6R+/0zM5+h+1wTJQDdtlbcYqW+XThjpb5blF8hvmHwX6W+XE/cc/XulqgX6 G2aQbenfP7Er0t8u3yrS3yoNKlDfLDspUt8uaWhL//65PIH+hik2F/TvnvkS6W+XkBLpb5YnsiV/ gvIHp28EyptkVWwob5DsEOlvl4MQ6D9ukhpwTfpuGfvgQtZmifRa6vfNb4e0t0k7B7Q3ywaH1LdL 0ragf/fcaUh/u5RmQH/DTGNIf7sEYEB/w7xc5+jfKV0Wkt8oixUS3yS5FJDeLOcTUt8uFRPQ3y5D UkP+/omLkPx2+YSQ/nZpfhb07559B+hvmBQH6W+WqwbIb5FCZkH4bpldkO4mCVfOkL5PHhQkvl16 EqC/YdYQpL9dMg+gv2GOjQX9u6e+QPpps4wU5+jfK1EE0t8qfwNeGdgmrQLS3ijbARLfLAkBkN8w N8A5+ve6so/0t7tJ39K//wV3oL/ZvXOkfvfr4C3ZO97SRsLbXZ4G+hveaW7p3/+q8Rn6d7sBjPS3 u5gL9NNW92UX1NN9r7Ei9e1ul56jf69Ln0h/s7uYLfm7X5EE8pvdXJypP9b/VULmwmEldMNVxS/h fpxS6vfk+j25U5T7PTmh3u/JLT73Cv1+T+4E9X5PbkG/35NbfM2S7/fk+j25fk+u35M7STz1e3It /X5Pbvm10+T7Pbl+T67fk0PQ78n1e3IN+dTvyS0+d5J+vye3pN7vya0+19Dv9+QWX2vI93ty7ecs /X5PztJN/Z5c+zVLvt+TW3/O0u/35Nafa+j3e3LN107S7/fk+j05JdXvyQn9fk/OkiT6/Z7cV4Ye 0+735Jb0+z25fk+u35Mz9Po9uX5Prt+T6/fk+j25fk+u35OzH7Nx9v2eXL8n1+/J9Xty/Z7c8nMN /X5PrvlYQ73fk1t+7ST5j+ye3Cu0X7/wdvpjvazf96Osn/jp13/U7p/HZh6u4D0oBjJjI3zPsD4D vOPDAo14jnKnbPGHfoNeO66oMs74UXqakPnGFXzgW8clSYbRHwwbhK79gnv83QOEqA9Devw/D3Vb MPmWq9ErV599B5qGi9ELFx9EkYY3oO5hzskw/CEURUSIpPTtd6BJfFspHL1I4XfpSRhj7Uka8kpR r/QuXv3RJ+XRPb794uGnbx8c+F3qg/jXfAasqqKegeYJ+vb48Kun4/N8Hpo33+XpD89vcg2A8uPT ++d5J52nND598/xvj2//y8PP354kB1YKpfb05vnx7e/OPRxqI5tvf/1cDm6cVfXT75/fJPr2n7QZ 376Tr//ok/EsV34aq/6pG6L5A0D5X37x7A4xxHF6+ueZlynlFJ4++/U/P4/0X3/y/Gak//zTn89d 4Ocz0zg/y997fcDmI/zMR70tVkfI+2qfJfheIMdu8tMnYjkvqp72veOKLmEfyM9Ozwu+Wjk07x1X dAm7waFdh54XfP135rG17MAACjvXTRWgYZqKQsBNvZKGjB40xPDjr26IGXM7OLcRoR4RMcIOITG6 gQINhZCQoak0Gp0QqmaB2QN/uQgaP45jte3i7Pm8zpnghvj07XM1hblQnl6e59PvkKenLxuVsKQ2 wlxUaq1OWD5dXLWH229/+jxP6vnsMT29vWryOx+rUaHGiuLkf/r07QUt5AKcKs3jl3SWw9BxfXru m1lzzFO0zFv0ODdx/j1M818/e37jIHw0PP3jJZXpxrooXPv5EY4Z9vP6xf8lf/3i4gcnX/f6lkbV d/jmj2d96MIQ49Pj3P4Af89/XiJH3T3AnrMy8PW3FzsQHDbm8cvdDTPJPP35b37z9btvvrn0TnX/ l6u/MIKRRZ/+1dMXnx9/C8zXBeD985uJeuQvj8/ztnheIfxVPRIm8LYDyV+5uV9xUf232rEOBeM/ Pc7TCtaZ//vsahCw97bf/+n5TaFV9xd1OcQh+vPzm1iNY2N8is/j09/PY4fPPM7jD8RefS8v3ruC mXlehotL6d8/O3+Y/2M52Q6VsFN//brOIY9zyE6cG9s4H/EdtdF8+r/WhR03FTpX9NuffvKT2kfI hfm2PvH/rvh21bGzikeF9fs/zUoSO+bp3cWXE9hX9eXLoppWn/p2ZmiaZSU9/eUP734862PurQ+X oSt4HcBqu+zn60SNRON1GRIOGv36wcLhcE2+Sjg+uYZeBovJtcuLefyK5UWf/tXTJ7//+vhj0A6L kf2Hud/mf4f09NlbWCJrd9tOkSc/+/RnlWPcQt/YbSmJsDUfvPQq3g7TVy+zHOEetf3Qq+19fSNW RrC2sIGtxhBW84kY7QhH8m/w83Ht77hsCGjeO67oEo6F3OT0vOCrjQHNe8cVXcaZ4gH5+byOD3zl O7muWYYftI4xP9ftgpGIaSwQkcZeSURGEPawzJC/YU9vRj2bTruJBveIShLlxCJJuqlHMkV2co/w 8Kx25KtTevUiplj/nzRYpk3JL6pqmM+q09Of4+WTeQZjINN47WRuv/bp76uWnOdgzmcO46/2QAzV kIe2i+RTFQSE7wWCzQ+eWwb0XJyC/MaxJcQgOHDuwlP097WTQd85LskxrGqXqdPf11OHjTA3PR+E 86tEil+X9iEBat+VJHBM4KiKLNwyzc0wogOM++QWIsyGiAayMfrrT7tMAvpfSdBwVBInJDziGTcl XWhvn1M1mcO8RiqRi5OKZrv95D+8+6bueOBT3/72Oc2PhVievtI59vn8p/3JmMW+umE5nGD37n3G UGG6bEf4veCBnFj8/LB2ar1iF7fvHVd0Cbs8oiWCnhd8vW3cvndc0WUcR3RD8POMb7HBVy+L5ae6 N5if65Q/Emkam7w29koiNIIjxg4IR/kGO5kMOxGRbrqFCPeJlaXaJyxLN/UJDoj2CQ/QmVlbI+zq AcSBq5gtU28GOJTPZ+eXiytgRK+YvHx5CUywwNtP3c04XcAoOIGbYW1CMkecX/+kWh/wcKS7b/3r UzVUf/bZzbtjFwKGqZLxg/B7wYNvdseCb9wd03vHFV3CfBeEHj9xNeQabvjqyYIowcQOP9pWrh1+ 12zgDCewgRNObtkFakOBBjf0ll1xNYs5uy2ebnBVyWgTDcI30eD+UAnC/mAJumlrTf5GopGMu/Hi nhhjAp0flsv3V3ZKfl3XcjApfAHzqs4VWFSr9Rpn1kUTTb2XUDUTfuYVlQF6VFp0N30BQWbopb+7 cevX/wT/daaWjWLR309+wDTgk3+qDM3/NTj7XaOM2K3vWVYcbr08axsHawHhelN/1rsVzeIoCGT1 5YFxdPounGrMPrz52/PGg54zWGAFLq8QfOLlgTHnVpXmRw2f8EUxBir8cNnOHPqSH2EpH5P5g2M5 QoGG+An7hq6lVowXJ0f4QXLzjvXfaV788eLKCH9UTEYW2FFXjBFTdET3hWJByQyA8U4jBp142n1V XBcEP1LQyVhTI1RIj+NpArdMiOuW31OqhjEdMiC8xTeCsY+OIBVHHGOO9R4jdmJis03ETk4Y7DwG 7AaOqcTrnRWT1SocUCoKB4GM3gwJBi5ozmH+PdAlvdFjv5EECnm+rjoG7PVw8LZxfF+oJjwEODa8 ee71hDLLceHUNZ7+rkdD77jTqVeddnqVDu8OMkgDPj/wCHrMP1zsgA7c7TYVMkvDwH0OYpLcxH0O wuQovnwEkaswMJ7wZ4ruw2ngJFIUZ6KT4CnB8nuVAH3f4aGY6RcP8sOfL5CoSxtX/MG2vQTmm+Jg AwovMw6dSp1SIo6+XOONOPrcp3jzXvu8JBx9HpOScPTxx8xjT+HUmcaeYhIzjz1Fo4889nS1bDxk FaQy4uiba9HBGzksBUef5ZRC5VY4SlReylYTETm51U2f41lDjZFAZWorzTlmhackcSq3M6gjeEZz L/GM517Mh6aTx8UgjDoI3mqbEo0q4tFthp6VGEmGRIWi4IgOJLkSHUlyJ9nNUSxFwZLYogI2sY1G rTsMYCS1P6kOaXQM/e6aa9F9IegLQV8I+kLQF4KPfyEImJ2Bg7ERn0F0XGmxQRr4DuAFZlXt9DC0 ywniNRLwUpWYSsLoUA/AJxTUtxr0oo9iyxdIWHrhlcmV1UJnWqaocoHoRZc1R3eDzAOisL0RZIYi 53Q0lEHiRTLG16eFRsrfZzHvsvCxy8IJo1JKuMSnxJHaji1br9rtcrVcPCa+HDWiFyHxDSjGXGGI Hj9RcOii8bh57biiynggjwE9Ptzo4WleO66oEpZaEfj4qdIRr34F7DKGmeSVmavMpUzEtjV5bevV RHDswOaq/Fwfn2zGG2iYPrqeCDNjhSh5FaJbiEjRDyIiw/OaCTkHuB+QknpibncC5wT7BKFx0USc 0wQ6xnzRXLJQg/G7L+p/HcAq+1u5evEfV9mLsysQB1DW1mITovc/YrXmQsDlh3mZzn0ZN8TXBQfW 2MNf/6JamPGnr9998dvaFvzufxgjMlkptVAY3nWVamAJr3oQNohu2REa4LIdYd7pMS3e2tEcWULa NsrTBvvIGC7pwY6S/yr0Sf6+UggFt47CW5HsXCD9P0Ser7MapIB74sipzwItDhGbnwJuimPEzXvF oH8pAo2mR8WZYAYUGDp8Gi8tBlyCo8cVu2K0oudIkOzoGM6EJgu2udNSLWXxaGcutnzauVccI2Gv tv0EfA64mafjgoTj0XGi4oi0wGYRB7pF6jmaj8CA0jPaECaRJhpMlB+D8d60PM6QqPF40qdCoRHA lgTK78ANDSMNADESRgqnwt9CNh0QRup+6qBAUQrcgSFT/1MH10xHpv8DrSQ8PCFR/+PoBUqVxoMb EnU/Df6MvYoGXyViwQlUApMFi8sGsuAFygvBghkYAKOUCoeeqhhHQLH8DnMmEpgayrWB5sN4HNWG Abum4Zm49oRytEyPzDR1yohjL32GJ2nt04KjT12OUqAjAkKiA0YqSQaUFJYM+CyfIgkouyooKOoq SDgVVM5w2hi94rAfSExVzTSQZZyf5jnA1HiO0NdwAlFTZHZRU2XyVTZkZhKPMnOpD3hWYw/JnKcO FJ1A/Ss6g/pfdAqND6scGj7VSJndfjQAMPiqz1A2VN+h7Ig2BMlSXYmCp7oUpVJ1LUptlNySZEEw nQ3xDiTX9UFWKCBzvELQzzhJPsCU3BeFvij0RaEvCn1R+J4vCqwwjg/UOGacAFqwGvTyYLBvniUk 4KV+HEwrzbKCeI3IDIPf0CWJtB16toLYKU8ietdiQYWOUc4TeHngr4awWvhMC1VH0J8vtMTRq5i8 JljN8IquDs1aSJwzvjwl1KR8n0W9y8HHLAenQh8Ltbb6phpr8qmLEEN1B9YqaXQNYngenw7VCoS2 IvOnu+WGEfhK48Rl4LC3CYto1rKwAQPl8HnG1983su8dV3QZpxHVND/P+Pr7Qfa944ou40AeRH6e 8dXfqVujlp0SlZ3rQoqRhm1qpcFNvfIaD40fJjA07FwfHi1jTkkQtYuup0G8WDGqvLAY3UIDh0Jp 8NC8ZpeOCTYItYL0h99NGuuOVkhcvpk0BrxNKt/75pnv+50OXVZL9akwavUYysWZAfffchFowOgK xBxrukCpiUSNdDUBkztkcn+zmKwwzwp+3uAYGWP1rog3cRjAN+FvasJ7bX46sJPNK1xG/P6wmL7q bM4+UKqhJME0TsK66pfcwAFGFIszaFxX3W26QeO6IJJn4AgjPBy64ZFigIZJg7rAR8Z1JCh+aJg0 qguhBHXBjQRKTEkxXkPRqK664x4KRxjhyjpw0lyKfBpGjerK6E00cVPsr+Mgr2HUoC4Sl8JRWSgt EtQ1obwwjEa42G88JPXtjziaEtPldTAp4mvg4k/clqgxXSCOXFKdOeH0uhTzNUTbDZxRHAO+hqAx XdCLoY2kG4J2ev2ZM9vRBR0umMsjyGWeKORr8BrVBXxzNUGK+hrcwYYIDk7DujxAZyVvGLjPaYpK qXc0BAwmJoEwR88A5/I4GAaEGsXiyNeweJQ2BkN5uKmFfM9SFzEw5xIDRpxTBBKesaSnCp7BuCMp Akm6ucAJTkaB4pdklAqe/2QQMfxp4FCoZvQpckqko+DJU6SHAq8GU1pssJoED7YimhSzIKKLSTNF simsiwWfifG8wKgumTXcFp5VFNYls455GSXqy2UzZbkbJA82hnXJlKdeLNrno1eFwUPA+gR6gXUN j5/UtAmsi0Y7/qjFOB6QVRyJjqhADieUfOAgeaJBORqRFCzHnEhpukWU10A1ZiSWhQvmqVahCD38 nefDh8b79oWgLwR9IegLQV8Ivn8LASlmNFUjNiiXBXqxz5oAUEV6JnqxDWgWFOfw6SWK/CgFeaqW w2BN+so5RC9abFDlTFUjh3lW64FtG+E1KoWRCfMcsCTZUj+wUl4r6RjbceFhigbJtGiniWbnWAT8 fsflvIvDxy8Ot3jNq1FgTGS7QytzxZmdlwUgOaVA/VTMrk4whhpXaAY4sqM0II7Gr1qxZy85ZJo1 LnMyRqHPtt6FHtkTii7dismuDaaLkc3n6BGOoz+wQ7hmOR09+6IRBHaRV+PH6BtPdBydeqKhEzjb E6bvGh07ozN2gmNnNNlMB3ZGY0rZcZAEV4gcvw3WmokNuUgtT+z7r9ugCqNtS54O3PQEFhv1/kNS MzFzU2qxwt5/7Idc2P0PL8ZsupAz0ZCXXOxGPAKZLq2gl7zCwY5ezuRYgO6oMLEs1F7ImX0N0LsV S/wF9AOHJKKbvOKsgpc55BBdSBU747mIObI7MwIgX2dsfsEekTdBOg3liD2SxNMZo21Wwk6RZqPB TtmCdM3KNWwztFMwrbT2Wd1umB4dsU+4x9GFrSOCPmAaLfQp6VCiW0aHGj3UKgpxMHKCHmkRI/RJ q5SBD1plEJ3QKqPodFYZpqQBLOGRsjbzBEBqMj/Q4a3zh9rC0wt95jr7iA+Zneg219lL/SBTG7xV MvGpC0UvoNtc1QaOgGiVQOmpJb4ik4p6FJ+50Vc49qMJsIBuMQEWMVp1mA5WWaLgqS6N2A2iaiPr 4XUYFXa1OFzlOXE/0UjQz7ktidLXg74e9PWgrwd9PfibWA9kJCR0hkbiLDKhMwgNoKgwAS/05dys KCPGCi4AjEM+mKgZIvKeI2H4C4oW4MU+SSmHLEKqyK9EzdTZvFjvXH5cokjPmZgZUgPHhU5QDZ2j wSLvoVkCZYnMJkrGTA6ZDCY10i/vtZZ3EfhYReCPi+fqla7Iaz2+N0bU72h9rsb1BeD+AiSGHaIj Zr884HWrFXb6HUqSK3iQ39MYOLtxtQwrivjpwLsb82mj64V1Lmz0w2b90l3NmmS7LpTTQKVCrgic q3e2Q75j5JzHcoExsrEP/U+ExR8VPYVS8vOMb0kHqu8dV3QJh0ymbnpe8C0JQfW944ou4zBpUv76 PONbvuOL5Qd0jvBzdUZPX2xjMVUBN/ZqIjSCMLcMR9dfDTfDjlketJuuJ8J9orKEfcKydFOf4IBo n/AAvZ4uH66i18TgY74QQJcvJ8zH3ZkQuZz7EzMT20/eJ2s+VptKHG2N+0svQc2IB9oh8PPDuhj7 azn0zXvHFV3C5GiU7wi+IaO+ee+4oss40zUDfj7fWC6jvldPEMoPnMmYnWuz42OlVmlrPkRt6tU0 aPwSBrUKP9dPKTPoGE2qnXQ9Ee4RlSTokZtUFfdIproe1CPZlPU4mWmfAhydVHm8fTLiYVxpvJJo H00a5ot3S7RPDqwwjZrVtQh+z5laCVdUrW0zqsdARZ6SugKk2HshhVcpWFaWkKcGP23wLNyEMdFr fbcqJQHBU2hppFYYOpn9x8Rgllzf1iP4A2T8hrimyPnBKXyk4sjhJLVbBsmJB4a2wQQ1xUFy4qGF bpCceGjBG0xOvBGfp20ThfUONm6mQoqbAfPhIFnx0Lo4SFa8jMXqJCtenWkVcgRPQBg4cqng047D g6DzJZkRrtQTZ8XDcKKKGUZ83HG0EcqMDVUSmeLKvDRi8nPmWCUIhNIRZOqZOx03MFPWWCVonMZg hSlxpxNjXHsaI7gq9sV0i2xVwRrIMkqdShX/3nP4mEg4jQmJ5XuOPhMZpiGtmCQA/g5GHCp2LA7Q C14jlRBmlizoBH9gOOHPErcEfeA0vRQMoHHAQz+4xhNtfqdpLu876Bch77Bf6OsYrKKNw2AWbTtG uihvGAmjvGOkjPRLiabPMMRG+xQjcLTPIUBHhwTjd2TEMLxHBxTDf3S8MTpI5QGjh1ReMLoomCyH KmcYmKRyiHFLRtNU+6SKMfrvSVdKVJTOAn6dZwkGVekkoq9zzfoRB0jyUlLDJS8lLNoygZlvSUuJ URE8/7nXJu100FVD0+mqXXB7pMqnRFVMGMamegsHW/UaBMGp2kNZUbWIMXSkM1HOVJ9i/J3qWxTT qBUr2jgnVCkSICPPLTWOzg5bRq0vC31Z6MtCXxb6svA3tyxkLCFPUYuEzyA8zTTQgCgJTglJtCOa cWWSIVwB/hsjHVUMMF6Rv6DIt+BFn8RWL5Cww3GOde4upr60SgFNem9iHGnSS5CjKgHV0zb61Eg4 dYeMDi+WBGkCnJkQq7DX77aodyH4eIXgooslxUNk1XRrolusVe+o9ivnF3UUx0A4TBR7T88Lvj7V rX3vuKLLOFEABD/P+Po0tPa944ou40B3C/h5xrd8BwZJ+Ik45rdUBmUi2lgkwo29mgiNWIZ0t8zQ tQTMkJsMszcQIDaMDOFSyDJ0U1/gQGhf8MC8nuh2xOX7cgHhiybYnEY28L1ugs15wF2YfHCLNLew sRsljciZRLd5k0S3bMfPV6a6zdenuk10fuE8dmXAfSNtWSvWU0VFeqYwaIAcM4RHqrjAtEZKF16d 41M+gal+gzzPuB5YGVYQ1iiwr3xiKy9GbTEblFCKuQxckxmjBH7IzF8ZoYvJenAvXqN/Au77Jw6m C3RSp1i7wBt/iVGgjT+69iDsh48JFMEghwgK5JNDBsUByiGEIvlkOaYwQt5qUSSfrN41AlHOOxTG J+chCl+U8xKG8YXJxD3KOYuC+OQcRnGTck6jKD45x1HYJR/zKI5PpQo9WZNkRaJToGQ3w58l+Vlm j0O2tCVzGn1bMquNfPgtxbZdErMVPv1atiWrG/WKZH2jXnMyArqVlf52NqizrrsS8wmjxfnoeDQl WR2NtiSzI2kYVFCKZMFDOSqSJQ/lrEgWPRDDwonASEoLJ5aqA0FHWAspX1/CpFL8MIyyoQVSYD6V 0VMrTQGJMk3NxDYA2CUriyOzTF0w4tBLF5VDtD1YdCtc4cRmD+p/mvYyOBMOPQ9eGnjocXDT0Ax9 Gg5WMJLDoWfBSbRNZMFKVuoS7atVw1ivmdGrKNLJN2YReZ1nRDKzhb/Lk4nbxZONms1zkZniucpM Z9sjPMm5x1gJcI9m7f/caJBifHgyWqJ+ZJ+Tixls0V4kCKLdUFBE+aEcqWpEOVPViXKoqhXFVDUv SDHZSDRgt+n64wMlReTnVsqGfi5tXrK+PvT1oa8PfX3o68Pf3vqA3q6A6lpQDTxO5LpqEZ9vGswv 4lHIghf6spjnaYkhTOvFSfTC150a3afYoKEskHkXm38OZWphXbRK0SYCphzHtCYKKvzoi1nxUD8c V+oikDNDWCBMU0GGRUaJls+wmCn5xMQwlzvuss53efhbkIeTKXLx3uAA3uZXQ/0dukgjONLvmyW3 qFGV7kKKUZWxp6WTHmd4S45cee24osp4ICVOjw95ZTa/hhd87biiStiXrAl/i8JbvlJHwjIzemXm 6uS2lYht6+i1rVcTwbEDqWZ+kobfXhFLLONNNTKoj24hwsxYIRr9jZZ5IkLDIURkeF7PkTvP2FBo Ln1QTDHeu1Qir+TIhW23+eI9cuSOYn6s6WIxaIbNkRUXMVfGASNP6JKGIrA3MnZ4m5dJObq+S5Kz hHQvWJ42uOpDxNUBWdctR+FIhCYM5SXIJlbhQer/Eo+EbTTxD5b3KyPHMKIGo8DEqU1hPuwnpSgg DegZpdQ55iUaTSzQKJXOC9q5pdI5hhKNUuociFB0koYhjVzqHN6jYCaNYhql1nl9jgLINAhqlFLn GFk2cqlziKAapdI5RpaNUumcBCFqJBl0g5Q6p8quXD2VxiRqJFk0csWxYaOpdI5DyJFi2Rj8hZqp dI4DHJu2mELnMGTeMiLhexgaNppK59ANEr6HsWGjhO9hL2r0nkdokyFWTH2OP9pMiCFL7B55qzh4 D4c/m0rnER+3qRBDltAgjA3LEjoEkpc5sAj9/bloqFfthCxhSRAJliVqiaH8WqJ9G7c9QhwDw/TT GBimTcPAMGk6BYYJayUq2xQYlk3M0uhNr2FgmPQohThJj1NkGA8IBUjJcFFgmAwnxVfJcFNgmIgD RmdJ4Bf5mSRQLHgjZxgYJlJIIRBWzyQjxKpaJT1YEuVpXpeKwUhdakDTx7XG+lDMfKN2mxLrzXRl tqXGOnWL1lh32egC7tSsYxCtKqExkRrrUV2+OqKj1lg3SoxEQZQcicpoaqxDN3CMGUw+U2M9eKNd SUxV+YIUj4U1uwkj074/cvyZPMihqjo2+DvPjg+IL+6rRF8l+irRV4m+Snw8q8Q08LgcH8jTwFce TgMMHG2wQeif4D9f5LtTu8jQBF4hUEYTfUMXKLlqEcujUXmEYlygF/usf1yB0TPPL3b2L5dB/7gC mR98MQteHjnctNUUqrml/TakR4dERoiWT5k0yT+emjS8PpuQ4zus9F0YPnZhuN4rj75Wnw6YswkD JD1nBqtuWi9pw1C4fGw9317SJEyUoeJR3cM+qOsb7JWhdX37Jt9ZhY3n23O2NFTN3qutPAJsTOVe 7MVotfeSqg1Vs6dMbphKr0JJrQedwIng2DDMCXQCAvJ7Y6yt12xY0Amccg7yAVZjDPm9UTmzncdg T28PsYG+sGHnPeeQEjMQNMRJHj1cQZzk2UMuHPdA/VsS9GEHOEngh2uXkwR/2IFO8v/h0udy0/1O sgfiyukkuSAMnpPcg7juOslNiGPvOHUhLNpOEhui2DhJfIgC7SQxIoqd46wfFC3gKM8WiayLGvtR 3w4a+uHbX3MxL2MOb6UN0QLyaUxFpk2jaAFpOpYlFcYoWkD4xjqk2i/kH5JuQ5eO9GpMOPq5iR+Q MYnZDBg5fWVAY8bBH9vgAcf+5BiNpJC/WSQpFmNdFG+1SGEsOPqckxF93yLS+vNkfd8yI4g6Txhy fst8osbJZEPnt8xFYkzmKjm/eSrHbKY5eb5FDVCHipogz7doERoPVjLkUhMdRMMpKgpjQ0SDkTCI hqPQEm8ESVQjhaSI6iQxFNVKIS1G76KG4qpmkmVR+h7W98VzlPaWflYyPBk+IGirLw99eejLQ18e +vLwkSwPrD2ODeIANlwZWvTyYHBNLynvNQCTnOJ88aldYDxVZZfVokX4EUyk3ei+QVygZ9Hy3dp8 Rb4FL7JiuaAtVGwWRECsC+jkJg+DOjiutINq56X2NrrEDtLY4Mk6hA3ktVnS8d5jke/S8PFLg5EF 8qSk4totQMEgV8QVjTLICrDXCEduL5GKJEfZoR1iiRMpZnrcQLgHC1mTC4YAYV5kBJFlpHCgQ7Rk dDkQYe+Mv5aVF9ZdX/e2VwbqUaqL+wXqZVgMXaYpQRePCctVbRdp0aPHGV5989y+dlxRJczB1fg0 o6tvg5u3jkuSBNndgs/mGxPxZtxYGDZguRc2rrtjjUS0nUCD23k1CRwzyDoqzFyfptMMM5DQ7rme BveGig72BovOLUQyZeAlGvnKBLw5zH8lOB7AjNCQPBMq914ufOvVb42U+8vlu+hwDtJPvHoZvXaA adDPngtd9G7yfErs3m/0T23ca9lBz3WEh16D7/758+c33BUaH6ifgCyk/1s/rn307rpL8fV7LkvM sLmA/vn7ekU9TC64pz+9e7XRA6zOQOT4+bfzsOBF9ZdnvkD/5eUBgpOnUnllgGDXbb/5+z+8+3r+ 7HyMCnNPPP3+a6M5PZSd8SlBgLzH0wHC9zOEsx5CjycJjxnTDXJ13SDMV02IEN8s8fWSzhLRlRV+ 1ED+0eNRdDJ/VfIvDwTp6++13XTkZa40dTPM0x8gs9FVu8TMbMIgTIfXvCqsUZgAfYJMeQ5MFgp8 dXkhTI4uUREZqTFZs4sP8QSma1XyvMFQQABwRR6fbgCUsyRMLXmvHNBNM+ZvklX6h8z2dZZR73H/ icEfR8AQzUFePu9h98eO1QpTVndixUMhD+IMHR65Mq3rFcPnWfQdHg8y3TfzDo0omeeNg61hxnfR gpJ5Zjg052S66FYx/oy94tAUlLmMgkMLSsZbdBVCPA7dsPMOjSiZLpZUDP1A94cqhigXusHnHRix Ml5LqQhCZOj6X8UD/owT0oENJdPVQYWREHQSQ6LFkuXQXJPp1qK0hCXLobkn061H4cTREGQob0D9 T50wcP+jmSkP3P/Yh1wSwqGRKg+m/xOLmUMDV5q4/3HsEoulQwNZmngAcOwTTTQHR+5Et4RYcBLd z6oYbj3QjSSSu0T1oqtYwmkFy0mz1CaqNu19BVSaGgHVpZ4B9IB5Em9TMCFwmutn0N2urcDgM20l RropFxh9xjxiYR3tAixyo10Epem0B7E0nfYwlqaj7oe6dDo0WJdORw4L0+nIeqnKgSPvKf6MpALr 0qnQeIo/Y6GC0nQqc57Cz1gmsTSdiGzA6DOvy42z4s5v82zwFNzGs4U/TpPJS7qfEm3TeSr6YuYp 883z2FOBD5rm1GusBLCUoCoJ6nHRIVhKUHUMDVhmQMqKhiCysoo82tHoNpIV0X2e6qKQakRJU8WJ h3NVrCinqnepGgAF5YlttOn7Iwo7P1Q1S8hmYOy0uNlp1peGvjT0paEvDX1p+IiWhhx5aI4Wz6eK QDHiCwDlCFts3pv/Y4teZMXRFQZBnXggZifQC2g251u9p9ig+m6DmnebHxuARyX6asrcPItZFbR/ vtBSB8+NmEay1RPnNLYT/aJDQ1wzVvF3+cR0UGfZd13W++h/rKN/y3ZsNPX9aKGLntUbOkx81FW0 ALSLaMWyiNbE3l42MXUNrtBszioMvMAXfNqZBT566ZWCtflYQnGDULHZPFToeL9Wf5VtDOjJijNv yGotBi/bmAyAtzzQC7KNwWJ0XrYxCbtBtjGYfMPLPgYTbvhBt1tqSYHBrTD5Bg6xfXqwpNiSRF9y RbeRA9qdZBtZW+qKbiMrJ443GA6B2ZxVGLLpISdCCR3oeFtD/ety2/0uH6IZHZe5+3H0XOL+x9F1 ifsfR98l7n+QDZcOLElVclzkxQwly0Ve7EDwXOSlkBx5kZdKyhnMCiS6wCsugpE3Y2D04hVx9JaG R6OdfCMg/1HX29w0EcskCgeQs1rYo3K4wj4VxJXuwYLy0ntUfp47l+rJS99T9XoZGyooL0OHuxId WqoozyNPv8l2J1qR8WK7DLx78kbicDMlAkn15EVeUf2oeOvvo30dpwaSlmlDX5ZpRS2TaUdzcLIs 8ZQljmU6U4/IdKceE3VAPSragjqclQkOh6gaGi1RRTSaoqpwsEWTkSiwoiNJETVIkqRqEiVN1SiV HBQtS4X/WAmb8pGLIzvZb4/tQ7S2q3HXzogPOrL3NaKvEX2N6GtEXyM+tjUii+I4LjCd0GiVaJGc 32jQzJsr9CJf97YplaauHCskZ7BG6yk+i5bv+mJ/HeICyQmuznDPikExT/72T3OCq5qA1lfH2viC rvbNIBHHjHUinJwYy5P7h6/ufew/zrG/cU9G+VvVjTI1ezJJ/cpulKndlEliS/ajTM2mjPMlshdl ajdlkrSWvChTuyeTnLfsSJmaPZkkzGVHytRuyiThLntSJrMp42S97EWZ2k2ZpPolL8rU7skkUzC7 USazJ5MUw2wgK81gS4Zifre0mzJOcExfLu2eTDKHcsNLuyej7JjKdGm2ZZSUQfusNNsyytGgPV7a bRkWjJPxKu2ujFI26HCXdldGKRxUWEqzLaN6ciprpdmWUUqH9yKppd2WhcL7K2C73Yzpj7F5E03a xWzGvP0u2sO1XWgvL3YvpkyRsb20ezHtFLLUl3YzJl1Khv7SbsZ0RNBPUNq9mI4neRmK7sVUFMg9 Udq9mIoSeTdKuxkTQSTnSGn1jsox2ohLuzfTWUCvT7o30+lDX57avZnOPmr51G7PZPIS01O7PdOJ j302tbsz1RvU5ZPdnanSofGa2t2Z6iwa76ndnonKI2GZ2u2ZKkxvkvPK7szoW88VLcVDOJ0+wdNA HNuHjPKRhVVmxYee4Ptq0VeLvlr01aKvFh/papEjj8xxgdnbWux5jpD6Yos9wa3RmNkXO5nzHBWB MGtIi+yZrFGHhPUEt0bLd/U8x3w1SL2xpT3PEeZVsv3TemOL+MGLnueaVmcj/N43a+SYFeq8WM4T Ey/9yzus8n3kP8aRv35nBorG1+om0L66zFRk1UzFzixSfpJ1AvRMxdmscRUb63WFzqyPfpJVygPI zGZCHHmlrb056bpdUbtsVzyaZb3iaLaIFXveBQR4XrcMfuJ1G7cUFSfdIVboeX8y4eOD2SH6yR80 prCiZDY7FQfeIEZ8euANInSK470Tvu4O7CCCHnW8daJvO928wogMunuFpg+8dyo4nsOhYXvgzVPd KfsyabBr7bUyabQrJNifNNoVf+ZIkDoxSuExwBErhccABLXiWMxwl6I7oNoTHLQI3VRGXrnrElVh spJWRp5tsMLRBRTeD9XM/7xcZoSJtzuVbS4MYLD8ns3bGXtBaGfsBfl2PhTbtBG7QVo+UjfopsHw XLgP7KbD9FnBbpA+nQ7e9PiEvSDjMWEv8HjhlSgZTlSoOtrBoZyTMATHwpAZl2hkCa/nq6zhnXmV RUiPI5KK+W5UjjG3jso5psfReUBv8zTBRAkyifjbPMdC/YpOQW46z1BcVnQGM+dGI+rcp14T3YBb TqM7oM9VtRScoKx4cMRULxWrtHC4VaON2Cmi8VBWJt13p2z1JUqa6tOEIyL6FuRU1XHC8cR9t9ma Ude7A60yzXOigXik6OdFVZO+aPRFoy8afdHoi8YPZtEYM43MsYU+RB4j82c9zUUeK3l+iQI6ZeWj zZIzgVVI1o8WjfQRNCY2utDrd08jt3gX264ot+BF1jCuYtViWSJPoBezAqJu0BVXdAXra8PDaBS2 do8smdQFYTFNGuhtvbhf3m3l78Lw0QvD9Vs3XE4zqMKjLLeZ1Tstx5m0P63WmRcHWs2T2QtghoFm K5DMVmDgDASykUi8bNE+I/GyRtuQxMsebVMSL4u0jUl2f5V4QaU9UOIFF3dIiZdj6vPEyzXNjJT5 tiT8ba9KVmzjFyu2VyVrogq5KpmyJthwNqdG87Pz9vXIuzEiz3ku+PPxEKVpUb1P0OzQeJ8qzmZb mQL7PqhTwsHbPvM8ANShXgcAOtzrAMCA+HY/nOxgOt7Q0FA73vCQKDjeD6GkON4ukSANYuOqcpaG JnilYrFYe3xcotNqP8SJJyxuDON0yC209nDzOm4UlTweWfTzsFGUxuGE1LbjhFXWEvWEvWNnegbX a7kCmbLpUlrrpctpLyBDQnsFGTJfdDhpkyGjTXsQEQbcoois0A5GZIl2OCxntAGy6VayFVPaPYkY 0+5KxFx/t5srmSRMnicRf11229S6rH4hr/OTWZPdNrEuu+1ipj73mdlrw+/FdrjstWlAZK9NoyV7 bRpN2WvjYPNem0RhUr9caRQiCpKoS5QzVacoh6JtUUxVGaMY54GvVsnezfb9Uc7MWQ54CxVEv0cu I33zgb+vGn3V6KtGXzX6qvFxrxqZh+YoENtyGgQ4HVmooP37Rb/rdNFRLEuUIFhQHH3CmaR071tI kU78/QahC5dwbbm+aFGUa948/5fLYn1ap3+L4DtfPrTa47hWF2uFnqS7m2GRYaI1VQxrztuZQzjx mi1n/nss/l0c/gbEQaM7NA0gBVfBO8nEVgmQPIAxmkgIwpPJ5DdlE75UKBhqiTlAiZ83ePSMSU9S eJNBmAuBsEShMBdNKsBVgENnHfPNzLxnrNci+WdyOUg6Gp+xRAdlpVCEDUDsC+8ckJQvtFmY0FfQ It6F8LMGg0uEDgdn0Ag2QcSa/YNZMFklosLOuDpKAnCextZRkkZjFaRNDdtFGbFdFLErnLgHabnC qXrQd7PGnAeInxdct1sEaStW0egtmjDrZ2bvECpJZkO8RWLPDp19Yv9E9mNSIFR28bV88x5K/MQA R41XH8ZKKRBZ+vqzlAYOYmBfbwbVoBquyJHPe+QR4mmbp5ss4gXfKY81Dy3WkIFk0J88zwvl/A8k 437695oj+09fP8+7g+Hp3WN6eXb064+f38SnxyYvdUMS995A8tPnWvxn/ufpv/33tz9/fjMrkPkf 9/T4+C8/ea6ljSu9t8/zIQMe+tk/nqZapaFmwhXKbZ5rfW6Co+DpFrwV2g6er/nXV20fwG0Kb/7r U03HPf8Tn/7w+dfPA/wdytO3j5//6/P8E3bG4/MbZ3tjENpNAnH5SMyOj0Wj5yZOROzdb/701XOt FFTBbz6f/w7Y9m/1A/8fXKrbkwplbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2JqDTw8L0NvbnRlbnRz IDMyIDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8 L0ZvbnQgMzEgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUld Pj4vVHlwZSAvUGFnZT4+DWVuZG9iag0zMSAwIG9iag08PC9GMTAgMTQgMCBSL0Y5IDUgMCBSPj4N ZW5kb2JqDTMyIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyNDczPj4Nc3Ry ZWFtCnic7X1bkyS3ce4vmP8wj9MKb6twKRRKEeeB4iFtOSQfaXcdfqAdCmpIWlJMk/KKlEPhOP/d hbwhgaqu6V5ObTVJUBFifxwUEh8uiQSQQP7XXXef/vf6H+/Mffrfu/+8c+G+H8L96W7o8dcT/HLp h6N///Huq5/d/S5/3B39GDs33s9/TDn+/NNxyvrtV3e/fHtnLHwz/Wvo3NHee3Ps7f3b091DONy/ /fPdJ2/v/isXgeVJAXKZ/njnjTlGf++74WjjlJiwHf3RxylFMN3R2Rmm9CmHf/vZ3deTuO4YuiF6 NxV6yj8GN5X2r49fwwcR0kNhGLqj99PnSdxUpjmG5FJHv9uHjxutBT5TclPxgQJnPlYX3i4wuyUm 3XEcU2sVhKywceNwDDFzqDES3JXQKhcqb6YTjoPVdGpM9HZn5MfOLhOCEmdCfRrvikCNieDtELKm HwpCUOJMyB/7oAnUmAjuSajHVlllBcXOrOwxFsOoxsTyRlj13RiXaUG5M60pTdE4NSaa+9ICEppW jNb1BS0ot9CKI+bCNGrMNG+EljFDWKSF5c604rEraNV4ZCk70kIS67Sg3JnWcDRa5c0w0bw1Wt4Z X9CCcmda4Wj0WJphonkbtNxg+36ZFpQ70+pLg2KGiea+tIDEOq2+MCyi1xz8AsEbIZT+AULJECwI ecXGlVbEDO9txvZY/HVCrjAsIhRdcaixuwHDYgh+SIbskAxasCzwv2haUNxMq6vUQo2J5r60bO/H Z2h1hZoYprlIsaggk7wRUvjvOScodaYUy7XGDCPHG+MEPzSnWKw/BlqdC4kax/3XH2kPwg7rrIo9 iQQ7X7Kq8e57EoqV6cNZWp1S60Mo11IzTDT3peWHLjxDKxSLqwkWduwC3n9xNaeF7VfS0nbtMBkO mkUFww1YtULKJN23TCoVO3Py5bp3hpHkvqTS5uUzpHyxDJ6gL0n5BY63RgrariSldYU7jsXsVGMk eSOkkp2+TAqKrVl5X7Kq8bj7dIV75s/R8rqx7NEWNGp8AzvPPW/SDt1kq3ugBe2naUG5M630/4pF BYnkrqRoA3CNU/p/TcnZklONd9cVwikt7xMn7JAlJ6dGVRiLqamCTHFfTrT3t0IKiq05FbtIC3j3 mSqTMmMw50jpTaUQj0Erhhkeb2BTibfIFC1QHZoWlDvTGorlYQ2J5K6keCcp8HnuAqlBLxdDdTQ1 w8P+y8U5KdAdmlN5XDVBH0tSNd5/uZhZTbnEM6x81KwKCgv89uVDW2RrfBSZvlzrzvDuao83kRQf UISaUF8sfEN1iDjD/Q0sfDOtpPeWaZWnihMsFroLeP+FL+25rLPS697gjsUG+gz7G1j5zlnBpKVZ QbE1KxdKVjXef1edWaX1bn+OldM9sDrHnmF3A7vPvOOyRqs8156gL1n5BZI3Qsq63p0jpTugKRfw M2z3X9Dz5kQmhXOxJmWKBf0EK1JLHPclRav4kHzizDlSmlNXWXo1NvtbfgukwMrQpLrS9OvKPYkF vL/px8v4dVp6j6IfywOPGjPNG6Hl+2VWWOzMKhZbLTUcb+D4gxfywgntJ80p6p2XCRU23wLeXaln TunXOVJ92VBd1VI13t8E5HX8Oi1tA/ZDsYVUw1vw6BFS6R/YUa+PqaDUmlKxgbSA924o8TVf5aT3 k/rKKWmGb8BJyfMyMUzmnwf7D40nTat0Uur78lhghm/AScnz0iMkpeGXafXFMUHvy92WGe73Pybw bKRnWmgValq+2H7pi6bxCwRvhBB7Cy8QUmwqX6sZ3r+FyDhfI1T6Xk2wcKBdwLv7Xila5CaMNm7J SvvT9ra0iiro9vem9WzGrnCyx5JScRy1gPfnhPbeKiV9OtWbcv9ohu3+51NCyk8mEmyko8muWZli P6nvyp2WGTb77yd5tvfC1AvdsEyrK3Ze+q48kFrAu++9eLaOFC0w3Eta+oDKj6WXc42Z5r60yDwK brIkwiItLLemZUtWdoHkrZECw70kpdSFr9wyZ3h/N03PplFw6dRgmVTpp1nYeRXYf9/FsyUR0oBK k3DEpUhBSLEZSptohnfvdjQ5rfEZChPJV76YMzzcgInEsxMMKgO0YG2laZW+mb70WqzhDXhmelbi wabRtEyqcGKckKtI1fgWScFysSTlNKvKFXOG+/2Pcjwr8TVapW+mL50x53B/c0JITUy6eI6UtiYq X8wZ3t830/PMlEnhOliTKn0zfeWLuYB3P8zxrM+DSa5W52jpTRdvK/uhxjfgm+lZn4d0htgDLVgN a1q2NChMec4xw/YGzArWEmu0THHwMcFiZ2IB7370kWnxMxuLtPRWhS9dZ2tobmCrgvVEJoWbF5pU 4UrrK9fZBXxDpOjZjUVSerfCjeXuRI2Z5b60SPmt0MJya1qhZBUWSO5LinSEIpWUYskpFJSKA5wF vLumEE5n6OizHFf5As/wDfgGe1YOy4RKr+AJFodRC3j/TRcmJK9vRNw0K2npwylXPckzw/EGDqd4 DK3RKp/mcaXT9hzuv5d0r57dWOSjR1Mon0KZ4f3dt0s+uKmp+YTiURRXuWov4N0fRXHc29Zp6a0k VzbSAsHbIMQvbSwRUmyq559meP8WooZZI1S+COUqB/QFvPvOmGM28tJGxI3nkpb2SXe+NFdn+AZ8 0h2zWaPlS/u18taeYb+//apo0TMiEXfUNa3SfdtV7toLeHcL1jGbdVqFvig9m2t4A97bjp9E6flH 7OvrK65wdHamsodqvL+js+OXKOTBjQVSpjSPSs/mOdzdPHL8IMU6Ka0rKsfmGd7f0XmJVHV9xZV+ zq7ya17Au2+MOX64QR4RWWKl3Zxt9QRejd0NuDk7fg9A3qWYsbLli3gTLEyJBbz7xpjj5wAyKzyG K2lp08KW7rI1HG/AsODHAOQNhwVShfusrdxlF/DuUxUdYitOcApXctJbLjaUWywzfAPus8KK++EC q1Dsu0ywIrXEcV9OdD6/TkpzqjyAZzjsb1R4ujefSeHJoiZVOgRbX25KzPANOAQrWqQzFmj5YqvC Vn7NC3j/rQq+Zb5OS29VWFcesc3wDXg7O75szh49EQ+CNStXnLjZyhd4Ae9+4uYs3c1eZVVYFpXj 7AzfgHewYkXqcIFW6UtrK9/ZGb4BX1rHa6sVVqUvrTXlYn4B77+4n7MCV4SSlV7bT7C0kOZ4/9U9 X2OWR18WaRU2U/XA6QybG7CZ+CLzGq3ywVNT+s5WkEnuS4ru/MoDKdHWJ3CmcKU1sZx3Z3h/V1rH V2PXSMViGjYlpQV+N0KIZuIlQopN5To7w/sTokuxa4RKX1pTPde6gPc/MVigBW49JS29rDfVu6Yz fAPPtzq+FivP2SzQKt85NZX77AzfwEunlm/GrtEq/WlN6WlawxvwprV8MZbffYnorqQ5FX6nxpbL wxne3+/U8q3YFU62WCya6q3MBbz7YtHyHVJ59mWRlt6wNZXj4gzfwOuZS7TAs0zTKh0Z4f8Viwre gCOj5Xuka6S6Y8mpq0jV+HZIsWW7SEqr9a508asgc9yVFN+OXSHVFS5/XeVBNsP7u/yxJ7fiBD6A mlPpT9ZV/mMzfAP+ZJkVrUEWWJXuZF3lbzXDN+BQZvl+7Bqt0gurq5xfZvgGvLAs349do1U6w3S+ 0OM1vAFXmEyKF1gLpLxW613l+TLDfn+1PieF/qiaVOkI01WOLwt4970yy5d+12lpa70rPV9qeAOO MJYv/a6RKhxhutJHpIb7u8EoSrQYXqBUeIx0lTPFDO/vMWL5jGCNVOFcMS0ui7u+NRaWt0YLfLwz LSp3plX4HczgDbxMZvkYeIWT9kJISO+hL+Hb4UQ7MYuc1I66HYsD+hm8AR8EyxfP10jp83o7lmej c7z7eT3E7U7lr7OsP6mzrEVOHPZqlxbnmwvf4nxvTWiVS4vzfQOBE1qc7xbne09aLc43wRbn+5Zo tTjfQKPF+f6ghFqcb+ZQ4xt4a7Zvcb4JtjjfN8KpxfkOLc73B6XV4nwTbHG+9yHV4nzHFud7R1ot zjfD0ouvxfn+wJxanO+CVIvz/YFotTjfCbU437uz8i3Od4vz/eFptTjfLc73rqxanO8W53sPUi3O N6AW53svWi3ON8EW53tfTi3Od9E2Lc73h+DU4nwzbHG+d6PV4ny3ON8702pxvhWnGu/PqcX5ji3O 9560WpzvDFuc7x1ItTjfLc73HqxanG9CriJV41sk1eJ8hxbn+8ORanG+CbY43/vRanG+CZausy3O 9wcn1eJ8h5JVWCC5L6kW57vF+d6NUIvzPbQ433vyaXG+W5zvD0Goxfkm2OJ83wCtFue7xfneg1SL 8x1bnO8dWbU43wRbnO99SNkW57vF+d6PU4vzDbDF+d6NVovzLbC0LFqc7w/PqsX5DiWrGu+/uG9x vgl2Lc73TqRanG+EBaUFfjdCqMX5zpxanO8PRavF+SZYepq2ON8fiFOL842wxfnei1SL851gi/O9 E6kW5xtgi/O9G60W5xtQi/O9G60W5zu2ON97kWpxvgm2ON+7cmpxvhWLm4vznbcq5IGyIT/LSOUs 5BDup+wmJKGxVZEm9KhFQqFLnFAvGSk0icFv+1AWn/CkgRS5GXrUVSE6WT6Veq+RT2JTvdq0IKT/ UtTrGMp6RdyNZb0jlnpWpMU+pr8TBnmqXThY+qbRyzH7DYKJL2X8krG9If/VrL9nqG0RsFHk63n+ LxuIGt6E3DoudCVkozDNKGXrqMmVlI2CGIOUzWMKn5PysiF+SylbRdxFKdsFwK3yf/F4tJj/1uFh Qcrm0VpRyrbBUysZW8QyPSPiZUOLgpCtI31WQjYKvIlSto6DeUbKi4alLGVsEyUSZWwbtPGcjJeM oVjJ2CikIUjZPMIgSrGbBvwDGdvG3ytFbBIOD0VsG52ukrFRsDiUsm3sNpCxcSi1MzJeNrJZJcS/ cKAxzH6zuF+Qvd06DFclZaOoWChl4yBVZ4S8bMyoQshWIZxQyLYRlSoZmwQ4AhkbxxtCGduG/zkn 42Wj8YCUzYPjVFK2iFWDIjYNHVOJ2CiSC0rZNrBKKWOTOCfwDs3WYUdQiN84CghK2TooB0jZMEZG lf+Lh6zA/LeOIFFJ2SKgA4jYNr4Citg23EEhY6voAyhk62AAIGXzt/lRyrZP5Z+T8ZIv14OMDR+S x/y3e9cd89/4mXUQsvGr5yhj20fIz8l42TfBQcrGT3SXMrZ5MRtlbP2ANUrZ+j1pkLL5884oZevX lksp2zx+DDI2fou4krHR08AoZduXelHGpg/nliLO5P493rGF/Dd8VrbIf7NXXlHKto+ugoz7zd5A nWf/wk+Swv3EDV8ILfN/+Qc7Mf+t388EKZs/Z4lStn5dspKy0WOPKGXbtxdBxsZPIaKMbV8mBBkb PxR4TsaLvtuHQjZ+Rg+FbPyqHQjZ+JE5lLHtm28gY+sn2Aoh27yIhiK2faAMZWz9XlglZaPnu0DK 5q9poZSNH7cCIVu/NVUJ2ejpJ5Sy8UtMZ4S87MNIKGTrd4pAysbPBqGMbV/xARkbPqpT5f/ib9xg /ls/OXNOysu+AINStn6QBe+ybPs+CsrwWz5XgiI2fj0EhGz+mMc5KS/5tgbK2Papi1LGNi9PgIyN H4JAGRu/y1AK2eiZBBSy9asFIGXjRwRKGdvc6T8j44Wv2KOUbW+8g4xNL6BXEja5D44ytr6efU7K S96WRhmbXl4uRWxylxhEbHy1d5Jxn/6Xsksp9OXdlKG+nEtYLpVSesF/hEuiqdTtiqiSp/Nfzbpd EW1XRNsV0VJKuyKq5C3n366ItiuiRaZZRrsi2q6IYqbtiqiW0a6IZhntiijLaFdEtYx2RbRdEc1S 2hXRUog2SdsV0XZFtF0RbVdEtcxFGe2KaLsiqvNXmbcrou2KaLsi2q6ItiuiBNsV0XZFtF0RbVdE K5nLMtoV0XZFtF0RXci+XRFtV0TbFdEso10R5UzbFVEtpF0RFRntiihn2q6ItiuipdBlIe2KaLsi 2q6IVvm3K6I613ZFVIloV0SVjHZFlGS0K6LtimiWuS6jXRHVEpcltCui7Yro10WmWcS1V0RbMNbb C8aammUUb/fqR2qWyX5JQzGSr4aLkAvhJ8GeVgeU3M8XC4Pcl6x+KCmeFiN1rowtSaXkdu4RcgkX W3GxFRfWI5R8Qa2sSjH3f76DCxBd19//N+QytUvBTVF78z2y1EQUj/fNMuZrcgjtSE6b75Oj9BTK kvD3ypOJx5J4/J7EU5Y811CW3Ogpy3y3vfr255+a7t7cv/3q7pdv76bhlibj6X/4K9mek5JNNwKm 8fv2dPfZw+kwmaOTjR4f/nJ4FZLXmh0eng5TVYexHx7+eviP+7f/fPfJ28XsHFzbzdk9vDrcv/3z 2dRwAKOFvztMduowqfSHbw6vehL+XS7Ht1+K+Ofr0MAmkx9xnTetOkAtj7iQY+jIY4RTu7kHyapS KL87zfIlbB1pSEov+OIBW3x3muVL2HTkBUHpBV8uBzVy5hNgamA+l3VfmiZyYSETKeyFmUj7QUkU I3txSVSr6+a5LhOuE+lJWCXUk67JgppD8pDmSZksDBHjwaKIcJwEI+Q3nx9epcm/t9Y+fPt4cEcz LST8wx/XxqUZYP8w57M6Ls0As7dK/fotJ//5p+NZZWLMCFaQ7Xj05++WkrtkoanUq2Waus60gM2p p5r4KNXEpBaC8Q9vJ8Ux6Y3p18eHVwacbd3DP63WSYjQihfKH6AhlPgs8e9/+XJVEFULGnpJ0Ltv 1yRZUIcq+Xq9aCsypf78iy/effnXv659E3roDRdKCGAE5NSfPXz1+elPUy27aapMU8Orkfrg3+8P PkLffLi/oEbowQrI8jNzGGja+Y/7KW+DLfh/7qeJJyQx/3Mwya/ZpqyT6CTx4VeHV5Hmpd+m+QLb 42+HVz7tMg3+wR+Gh3+YJjRMcz81GWT27Heh+u4CMmhCYM/87WEqv/PD+PDrqfzjVCPu4c0/HJIC m2gtluOTSRoWY+nX71Nnt9jZdQ+/sowBdoGgjEr0vxxeDTTr5k6dZb/+9KNUR8hCyc4p/v8Fsq0F jQuyX3/z3bcHgxXzsD52PFybyB+vd1U/E/XtRGic+kqfRukvDl5q6/370AVcO7gaU9fzZV2Nusbz fUgYFIrwvTuHwSnyos7x6SX5od64cBpQqS+YBnLqzx4+/ebd6RegHKqG/b9TtU3/dv3Dm7eHtCGd alvXiaR88/rjRBhNzCtrre+lrxUC1z514NOdP32G8pg8gbWgZ8t7wSLTpgrsAx1DpuvyGT8J9uTH wun93K/lmSWz/u40y5dxF3jNXOLLF836u9MsX8I+Bl41l/gKOSWZaaYWMpcZpCkHXcyUAxfz0hy4 rXAVTFT6K5asqr1Drq7r8gAmugMlJtyBLs6BmkBykCZJOTyzdrVJF/Q+OYaS2gpkifw2KQQbuvHh b351wWpTBUgW68tVdCVR8l5/k5TjNPZCeN9FKu1hwP+nOnBT3oieGAXcoqSUYbZhecGeFX51qnIk ZPOWmK0P7S4pu1Ult6rcHe4QU6putl/8bN7OFgUPmf2FvQuzkPIFJnjx56llaKc307i8f3NzUha5 Xq4ZIkhCdZAQpYdclUU30FjHLKhBziw80wlY2l6YEpullefj+qgC16788TPjKt2I1pKu2AVaW48m 7yHb27x0PmMn/f6jtIRBCyvP4fnX62TpWrDK3ry5Zmin5jZ9hB6c3mAcGT4JtAM6wVFihpcPb/XZ aZYr4ZHUOqZmdPlQzF+d6iwJDuSBgWmHuT/GszPaUNBIOyvC4uJZcdDFTFmM181n3F64U4RUrtn2 Um0MWXDlXJMH14V0G6gK6jXX5DCQBw3mwE1ywayaRBnvZdjkWfVrPQTfpSkWliJfwVBKw2PSEGFS DZ4G0+rSjq6xZknrSqJ3uMLL5XoxLZFukhjjZHvjJZfGv/8V/Ncpt6A0Sv77ogBVgE9/lQhN/9UZ LfdqS98Hn08j0tEi4ifBjrbFKbmbuTtdYufjZ6c6U4bG4rk0p2Z8pZVP351m+RJOT5QaJUfwNVZ+ pgIdj6lcbtfmQmIGXMhrbHyPO3WnzIQuSFxmfnBTUyZSPddkAlxy50Eu3HkuzoGaQHKQJrlAHyVz 2/fdgj5SVn5Yt0dgfZUzeeZYqivkPW/lr6kXb5OXDz05kUQbFv38dDLZLlOx3WDQc6nv+3SGQPhJ MJ/Scvprz7XL706zfBlbfguW0tv5W60X8bH0GGydL+OuJ4dFSs/4cjnwspLiA/st151mcya5sJgJ F/bCTKQF0SphRv5y8121OuQhtXRFHkwm9yQkwz3pqkywOXIm3DzPDmU/wGZuenBH75T3uHP36wPb 4G/WxnLfoR+VZLI6lvsO7AUtMsv56JefHMwxggL5tZpR3Qj2W7rNgxaUBTOS8NQvrYDpZ9qtwMtF CkTwvCEsd34pH7mdS71hhiM9nMDpFU67+IgTspFvECtkAshGjGXJeU1rLbh4IRyjXMSAPvCT5h7u exhiqX+lQg+9+tHToik9TQ7MHC6nxy7fv0wPikMpHW2j4gPj6epkRBeheERIthc46vHNSnooPEGD uQGBdGFxtISduiVJT34n7PH7gHWIfowJiktGgj0MX76aSE9tJ0zuS1Ot5UuFLsJuV5oMEXi81TcE wtDaI15USLP6oC4L0gPYcrGPZ32Lb5+xK1DMZht4CnH7sMsTPTDGdgvd4JPMBq50x81tisIErnSx ABQT2gKLqB9s4CqHSrA91zhsZIjS5zrkq2v0HHrCVjUA3zlLOOJlskE3IN8WSxih1e0vACrFcZVH us3Vc8+CSnBc49jzrOMaH7ES8I2o1GmBp+UhIBibYDRHq1IbpM2ZjTQXsjC03nJhRprYuawYI4CI jI5JC9Z1MHoiTXU0olOQ1OHo6W4h/rVXG0yIe6saaKShzg04klri9h1D0fwjnLXn3jEOR6t6Doad yD1rwlAP3PPGtFaWfpnVCnbbMWKtKLVjgur2nBsNinHASucxQ2XhIYUhKvKQYyY8JPNgpTqQkTyS euSBTnUoigCP4bOioBZgNTI61kJetZ8oodGxEhq5L0StxEYLWohUHPUc0YC4FskKknqeKFCMA5EV LPVbUL5JG//bz+6+LqctcI5P6VLtUDrRKDQj8J+ra4htEmiTQJsE2iTQJoEf6CSAzsz0LkSCjjWG AolHgR5zUhx7M2REMT1q6cVc4rALzxBNEygnGtzxECVnjlnQEhjyh7n0AsK95JjAo8xLfPVdJjpM NUPQmQzKyLOa5a3LWkFknVzqaO77UjPSTsTeFWNjNlTUMux3Lzabtw7xo+gQq5ur6MadVv7+ys3V gI/TiQPL4OBKlTiwMGbnHk5/rQdU+d1pli9hP9J7j5Re8KWbnuV3p1m+jAO9J8rpw/x90WfluKD5 4EbbVU5QlIkqLDYnF/biTKgF4d5iJtRdvDGqWj2oSrsqD66R3JOwRq5yheIaCfQ2LNcIN8+zm6vB D9gO4p2UT0fU+Wi+yPMn+ZUPbP++tvMaMDjQZc5SYQCnF1Wcjw+RnChUcdSJ8hf5Zy7at386JDvF +Vh+tVZMqohkv6Hkv30OZ7BQFfnQOAuBU+s/LF12uuyIhyWaND2hxOze+/lTOszFA9zvVg/EOZuu Q2X22cPp82+npsEj40fZtl696REGOOyTTJ5ppIhekiLxm798+W4SagY82f/mndoWtxb6osXzh9Od 7cGvgfDTXfrh5O8KBQ1cmpXohzFkY1NWxgzajWQGyRGOE2cYPMEE8HfQIEYQ6o9SrqdcfDrLFHpe XE9h4P5kaQMfbx2dQHtYEBB+ApxUJeKEIoDEVwCQBtSjlyFm0lt64IZdWWeYL+pyesFgNxFOKABI d8sYgEh3DFSAp1xyirIjzHLUnZ8o48v2utJVNbjUSS+OJJyMxjDgZE1X2RIO6sZjwp5vWsLlE3zA NcG08gyBLy7C2p5DXiVIl0KxAgwazoE9t0HLYoCp9BuKzv5tBpedgR4pTTgtvgOdUCZsQg4dZQ1u aQQ8Sk0wrTs55lPC+FeHuaE1y9GaEoZ6ILt/wgDg0w53XjgeUsIW02Jf6mAjJ9AKWP6MC+QEocbY jwVyNlzdaEQHw9VNxTJc3bhapsg/Qqrj6sbFNsfskTrpuL5hqc7BdqRKO6rvtPLhMDnUFv3I1Y2b BP3I1Y1N2Y9c3bjHQBFwuCNwrJqEUyX0kesb+xHHmbF0dkyVjZ2QAsQkmM95E4Z9Ew7tkmCqhJ4V L2P19xD155FPqhl6LRvXKblguCDMBR+PQfMasVqItu3KWrEd1grXmiWHN65VvM2UK90a7FrQItaq trLoJCRNaS32DG7qtHWneoJ12DOoo1iHg4H7kfXYMbifWY+Difuh9dgzuJPaHgcj9eG0G5eDdSUI F815APDXPEDSVmAePiybh5Z12GlFoTkeqVjj1mKf55HLzGlgW4tDhsc91Fqf67u3SmlQfYtSsR3q J9VWooxsx8rJR9XUWZnhxkHWdXTdnlUhbg5mTQn9LCtS3BvMihZ7aZC3nGjji/Q7qZMT935OVysb GhuhuOje5oM2H7T5oM0HbT74McwHAYtBTrcKT8uGMyCkLd8SK5SWjAV6lEHDUXdLnOcgADJloJgO z7ylNxQ4IWelEAXCbwnjH/swB+AHxlL7UE98VD5SATP0qGY5DiY4UxEdnr1mCoJN0LWhZsUxKCzj QUaLqpB8FvISc3vrET+WHnG5jQZe83akl7JwOkzYsOh0vcBGnv8CgMD22YCYocW0hqdl8GsXGrQt IlqKNh9EiTncfGAd58hddGSTIb1FYkM2P8DBM2jzg7xJxTpJXqhiupB7p5g25Coqlg+5g4pllHDH lpFlD320qtLvng20HrdQHDcu1ALPODDu0oZL9LmtZQOGv1bm3iBbR0oydxU0HRMOXpec5k4wPBMy BW+xAOFHwkHXmRiAFr1kjTSAkVd6nthoTniwur26wuBO2Hrd3h2BdCFHDEDsK0YswB7fRRQLMADo 2GSDRwfZ/MM+asRMwndwjFhR0KES7mKJ5e9j8T102Jw9+gpn6ehJnIuGBzC56Mloy8xwZifWaLLl KrH8kpFXFluuUbQoco2jxSYNgtZIbi8023JzojGTmxvMttwb0BaSvoJmW+5KYEjlnoZWW+6JaIfl nopWm3TkvCcavf6z2lk0ephw9mJ4oXS2u6hsYnc5HsA2KmZieVkev0PQFRN0rYnpRZUaciP0WrFw o7DioTYjrcQtykqLm1uUGvSGrPOws2SdSG7prDLJL100KnbFrG6xq2Z1jF0Z1fV8YY+twXO/JMs6 KC9xZHi8x7K+TRltymhTRpsy2pTxg54yAhaDHnAvsUIVeNQpo78/g6ARH7X4UJYm8kJPAI5JSCnr vEIp0qFqlJXdHIW8zKOy5+9cjR6zIhiKqTEh0QEzoNZ4pCFOc43BSluKL0rcVRUhsyaxl7ET7ouh oypjtur/HhN/6wk//J5wnelGLt1iuqHTvFhu5OGNMyq5d4vlRg74Mh2Tv7eYbujvLTM5ufOL5Ub+ 32IJkP83m250NUAMCXQHF8stv9eAZw2jGCl4FDGKkYJHFaNYKXiUMbKVggcdo1gpeBAyipWCByWj WCkd++OK+ZUu8ojlRtcneLzR7QpparrXk7+NbCfQYU9kMwLlRrEy8JwoihWC5Y5ipcAxU5TTBWQd uQfjGVWUowmosygnF3jEFUNugFTjMeQWSH0pkhcRtVcM3AJ4uhb7wlKna0JsvNGNmNxbYn9Uthvd GqKeFj1XPx4LRs/Vj700ejYScTss6p3D6NhKJMx/HIsv8XQm54zb6Fkyns/kYuEuvJQajmeEE+3h C2U6n5Eqwf1/qTE6nuEKpdMDqW86nZH2oKMHaS86o5HmpJMLbm08opG+QOce0lXojEa6Ep6aSE+j IxruiHTmIv2UTmikH9NWs/Tz/PchqO9xjFDeMoBQtAwuKtmozppCVIMTiY3Znh2DGtm2fO6Ea000 A9WqKA6qddYr1CaidrDJRClRi4rSohbPSg06hKg87C1ZI2JvyhoTe1vWqNgbs7rF3iraGHvyKBGG qkP8SPFZC6WudZDlbGweH++52m9TRpsy2pTRpow2ZfxApww8f40UbLvECtlYoUedFp5MP4OGoM51 xz5PPoRTaplKAOCQxKT5XFfrRcL0ULqzC0i+zVh92fkK5ZPd6Or5MX2aVcMM6ZPd6NWxrt6kVcUX 3Gmlo+bNMWSIR7h68KiqmJ/xf5+pv/WGH0NvuNh8I/2T9o+hlKB+OIIz6x8z8pSM+seMPCWj/pmw 17MhBWdm9TP911HPpBMebK5NjrXMs7KJeVZOmtjw9n2KNCx7/UPI8Y3ZFjADNxNajhyZmE0JE47q mCjBno8h0rAxgdUoWI4ccZjtGMMXdch0TA+OZSuIYwezkWQkbhP+ma/JkJFkvBhBBlMbdSLijOMa p6K5bASl9jKOa5yYuSPbTDHH/5V6sVzhaCQZKzWew/iykSS7TNAWhmscu6AxXOPUlCYPjDTHGpOP OCDzTk5APCA5H4Ea7LJjI9RClx0fA8QUowpH7zeKb8tzaMe7mOQ81415TiUsf4/qa3TDk8xp/hbZ 1qqC0eQvBSf/P6ZFtoOwJvdBqRWyPKTWyP1QahUNl8JxUZqDLB5pKxzm0pSk6qWpLUZ2446At7Fy P7EDjgjuR3bAnsH9zA44orgfwh+pj+KdodyFbcRK6Lm+I1YSjwCrBgfeT8pjh+Xy2ILblXnkcbF5 ZNKUwQOXSQ+lFSnjnutsyPUdvNIbVN/aShRtw20VsxVpla7ipmZdRmYiqzruKKwJyUoUTcm9bMxW JDw9wpoW+yio4cIwiyiVo45R16d0M12TR4aOeNqmgzYdtOmgTQdtOvjBTwfj0VJDnBQCh+pFgO7U GjKAqinAowyVJJ3nk4zV5EOIpgry2ca9QukGtENKghhhGQr0eKcweEzXKHDve5QZqovVlBe5UDDW F9Cjmt86dk6rdQNt+2YShLnrS31IM1Ed8DDBoZBHih4ZeqH+EvN66xA/ig5xzVHLmEIZddRpcNJN WF1CSJDn7wGh4Sk73fzvxXgLAPTVyoT15nrCbCik3ZFeLDePbz2I5QYWVMKeTaSI6dXdyglmE8f2 YrzhzYxejDe4cNGL7QYVnrBcrUxRh3q23aBr2F5sN9jkTVjfrUxY7lZarx7dwPOS/KqF6QCIq6TH Jy7EVRIyE+MtbSHjuxiqKGK7wSC2vSuOlBIWV0l4ZUNsN6oItt3QD6UX4w3r0OYq7yJgH3UTiPmW TD/bF81nsr2cNsZ6k+1lqASx3jDKci/WG3WdTm9HJSi7zBagOEMGTC3Okqke/Jg3sT3AUCD5I1SK Mv1MkfmItSKy0SWIi4bjL5ccx2dmBvNqJo7GX64YnJYtuwCq6sQJPVc3Wn65OdAeyK2Fpp80JloT ua3R8st9weLbKmJ+ydsqcoXHqJ5m8VEYMcDoxRiZLTBOl3Tj/PCMU1ZUHgOUndhg9NiMGGFUGDHC UA3zCGQqQzZ6R6sGMNeEGGEQvEyGP1ck1yp0NDHCtFJBGyorHW48McEwDA/rLG56McE6rBVRedRz RB+mDqnUJXY80aY4gWRdC902dHypSp2k5Lo+8cJHEs71Df6dRsN7Hb+3OaHNCW1OaHNCmxNud04Q jXG6o70XaoqzCL2OC6wQulpH+v0osk05rSCuEU0ZhmSgCxHm9MQOSCQkA1ejR500lX2GesusH/WI ryc+WA3WyHPSRzXLoUY4zRREVthBQ1HR3C4yJdKUWT9cJ0Olz7npRftLzO2tP/wY+oPytYgQUJf0 svg79ewNJU8ksotBRpafVaQLO54+NPq6DwXwm2He7uD0gumeU2TDIUS+DaQQ7Jz05NHF/iBMQflc RT/3LPgpM6dtO9YAPW2Ty5uYeuubZine8Opl2xwHAOKsPTCvPGQp4HYFaerhxBn2PDHRLEv9WSES SzvuvhCrd6jGDH/ixJeivKbgAvfemVkYxsXE4HA10nu+z6Slt7lgLfN8agwtwq/zrqYlK2eAtUeR unwJOuJHiV4qQ+/AyRXe8/30MGm/6R94U/nhP9NDx9+9O0zLj+7hy/v+D784vJpWJtM//uH+NUTi S0n/37++/SRFxO6mf8zD/SEtbtJ//81Hh2ge3h7S++zTPw8f/1PxErEUw6awEKoY5RvEKhk4tOri TmUImPdbydpA+vRGdvF1D4/U97jwgo///SE9lgxk/vL5u0MHv118+Pb+8CptQScKf/j3w2GcKKnw uZI9v09jaX7vrXrLpacXo2hdRw9r1QiVFELPy5qUj+dFDIyKGeQVEiQVgGdPXpZB9FdnNerxYWHD D8R5zie/D4e0jLwnj++R/1R5Px/kcpITQcmkGJe4QIq0xGEc0A+cUhO6PN5q/upUZ8nQkyMyJWZ4 TQxU+ew0y5WxpTUxJWd4uRTcRREqOHMQlQujimIWuaSYB5f04tCkqdUo4Cuzoa2BC8OsUktL0Fiq oWsyYTK5+yAZ7j5XZYKNkTPhxkmZdIVSrKNiRNy9GmBbCXTjm/S6Pb6+//rjtffj/QhL8vztM+FV Id6HSv2bjz6+Ir4xEsUlBla5CYyfGJtI9/EpveDLx5v+7jTLl3GgLRpOz/jK0UDfnWb5Mvbkuc3p fe3JfYGcqScUfILPfC7uZSkTXdjgc2Gv6qqTNXLSdMA6v3jYpTaHHFQFXZ4DESl6UfC5F11VG9gU uTa4ad4sW5U+wha1GftjeI+BliTyp8+Ms2RR5bTFKKMLNLjQTRF7adsc1734ZAgiei+EFv4KgdOA YLK064z6nFFGaHZL0gxps93zkyeyahQE5r1g2uBUOYH6F3JVeIKfJunLYlNCNChaTp0Aurz0crHj 3U8Y5wkHtXeasD5OcsOIe8C095qwz1uzCdq8ceuGSFvAFFYOI4zIxu+E85awGwbaBSZgY95MTrhT e81uoO0c2otO2Nm8V+0G2jnHrewEQ97odgOtaWkj3A2yEd5FwuooKUGTe4EbaMufls2CqdO4gfbJ BWNu3JwD7bJjR5GykKZN2OEBArYAM3HcArTH77gFqCbckSsGjfEx6Hq03AIDnYPoFrDcApGOQnTb GW6BiL3ScAtQyxtugRFrgYx66TkdxffExT0tB7jf8elP6pZ0GoQtgL2W9wIpkpjsMyrMsK+SR50Z 3u3JwhxWghTGq3L64oSM7oBmmngHNFcD3vrM1YS3PqkO8Y5nruCI4Vm48vFOZ24cvNOZGw/ucErL 4h3O3PB4ZzN3DLy0mTtO3q+joU07udTvouynspZRXTbrU1BJdEkzd/lY7M3yHS0ZMCyaxxPtI/Jw 45LzcMTbqDJYiTYPZbzZmoc61xqrghh4p4hagCo9UnOMVikZbi7WQHCFNysobm1WYHgjWNQbHStR /Ts+WQ9FLxPVCaFSlWrFTiqaF+ITyoa1ilup6/4kfZ0TJvXi1XRRj43roxe3GaLNEG2GaDNEmyF+ ODPEIOrjVGF6IaFGtMIpsXyJVy4K9JhnHlPONIgptOwiegQVZ+8LDZjlCEgfapC/w8KfBRIrlw6X nyqshv8MPdKcF9lXKc+xrC2e0995SvZKNMNRr+/mQ0NHNn6Rqb71iB9Fj1gLKsr6MwX/ePaokN6N TRvvI4Vb7Q7Dw/HwaqBIpuqnUadfrGYdRdqmt2wJP93RY7aEk5gOQFC/oZ+kV27NQC/YUC5moBdr eGdwhulBHEmv8MSKMD7Hm4BXvyEoA0IqxFMufeA2InY5HAYOnp8m68vWBmTDeYqCyTaet2y5RnVe kw1Eb8l0jfDbsKWZSuYN261oeXqT7VaEhdnqjZitMCA7tlvR6uVI02wV+47tVjo56th0pTOvLhvc bmTLFe1xN7LliqPbjWy5gqJxIy8d0CXURVo6oG+ji7x2QI9Sx2HQB3RvdJHXDqboXwmDMwDFPc9/ RjU26NbkvAPXNzpZunAsSha4ynECcT1XORHrucpx3eJ6rnOsl/6oFz3O5ypPVep8rvIAUGo8tYjz XOO44nK6NZ0rl2vOcZVjZ3COqxzXes5xnUfy2niSRaLjuPPUCZ3lCoc1prNc37gidRz0njH/ndYh 8jmtcCV7WomwdFofS8lwISIFp5lAiJEVJ8Rx5eHYQOx0jdGyQ2qUDEipcFp6SIOQ8cntRSsPaU00 XaWxaeEhnYEsX+ksuPbgrkRGs/Q0WnpkvYJGt3RTWnwsYLVSkT7PufGYIJNdxgyVhYcUWew84pgJ D0iy2WW8ckXweCajXcY71SPqAtIiRQuIFiGTXbQMtp4oIV5Wko5io4FVGNsUrOGo64gGpDWtaEjq eaw9cUWcdSv226x7cT3tHd9D5PVBntDAz6tU4oXCIWMG/84D5PodpDZLtFmizRJtlmizxA9ylqDN B9xzQ6yQCxV61GmLP4Z7lSskzNJlqslYzRuELIP0aXeMuWcMeOkHhZwB8l3GCsHWAudJWwuoAsxs HqTiQPdZQI806Yl+OAmzrE/wEpPS1zaqjs8VoZpJt9r6OFFbSC8z17fu8MPvDme2jdLUgJcUn983 SjdLzQjWwcXbRqXP+QCzIOpxcuIeyef8yy+++/pgO3S9/uLz6Td6myeXbM7sfwHcEfeDCmVuZHN0 cmVhbQ1lbmRvYmoNMzMgMCBvYmoNPDwvQ29udGVudHMgMzUgMCBSL01lZGlhQm94IFswIDAgNzky IDYxMl0vUGFyZW50IDQ4IDAgUi9SZXNvdXJjZXMgPDwvRm9udCAzNCAwIFIvUHJvY1NldCBbL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTM0 IDAgb2JqDTw8L0YxMSA1IDAgUi9GMTIgMTQgMCBSL0YxMyA4IDAgUj4+DWVuZG9iag0zNSAwIG9i ag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjE4Mz4+DXN0cmVhbQp4nO1925Icx5Hl F/Q/9NNa1digNuOSkZl6oyRS0ppESSR2Z82EMRlZbBIc6wIpAORwbH9+0/34Lasa1Vkgdk0gCnhA HlRc3T3c4+Lh8Y+b7pb+fva7m3RLf19+c1PabT+028PN0OPrnr8KfRT59/nN1/9y81fP3O3qNHZl uj39mEv8758kKvvp1ze/fnqTMmea/xm6ssu3Ne36fPv0cLMZtrdP/+Pm46c3//A2aIXWAm/U85s0 pd382bc6pxSQUt3lSk3t864bTzAlprz/9i83L+aKul2eujQ1bm9NaZw/hkJ/bl/tX3CheQw1AFCJ hOaGB4SmENqH2o5rJ0yo5FMkGWewaDbwrfcofu5Dz+f00iwC0t7lJ5pHtLNKFrQb8pJ2gtNuQVqC oKR1rFC1984Tw9lo/vUsMn9loo8tD7Wfac3ET/RRpy4bzY2rC64ds/SY5SKVV67+f+cqFAHRlkb4 iBE+3uaOq0p9RwP8b5uPtmXu9/xn83qb+s3rl99uB8Z18+UPr7e539y92k67bnO7/ffbp/+DdMGy vBE9QnmbpApjmWia5Wu0RE/ekKjt6mMFSevzOCfl9r+cW71rrQ2bu69+eLHNHcBXX8zfRTumLScx nLp+HPPt6QeRqg2k/sq0ayNxa6bt/CH43nDXiBP3klpREPVhat3AEn704XUg1+GkTMG55h0zk1Mb CnU83g/JdTgpU3AaM3FF6jC0to50+x+UpHVd19/+501rxJnQr7pLzfv1+VsXGbrBRVo33qpIJn7t qKCDd/xti1PuaYGBsm/dQtDRZRB0VBl8+yKFwVakMZyKPMoxTw+yTw/SrqsYgfw1DrNSqrlhAL7Y PpnH7TDmeQT+9Pr59sk81HPrprz5bvukl1++XyiPo/JStuKWquEk3bQroeb7bZut1tQPm2/t69Ws veaP1sKof6Co2Q7VNHcfBR1mBdf6nMbN3WGbCn3nzZehXy+trOW86ajUoc5cz7NuGjIK/sP2ySgN e/HV3U93X50lw9ygeSbl+Tdf/tftGXKgtln7yVztxUz+M8mnSgMxpD9H6mnY1UXhz7/7/hxnYL9W Fj4b/2VT/rbZzxyYudaXzfMvvt0+meWzdLVuXtyeIxgI0LHZ5lLmnJPk/OruxWzP5gSljvH/v/6W WHLC1kdHVM6sx/rKQ2meBKVZ4hTeK5wTFYKaWvFa07DMdzguFrC2iZhjtRheq7iX+Q7HxQqsE9HY a1G8vpae5i7elYHndNqXVXoMZYSGchnW0pVlCOdI1x+8OyMNtpVlKLdRhBLokhKEGi4+oIbKzyXU ACOcGsoYKuOs3s5l2I31ti+m+H6+7s5Do6mqlXl24OdhIiJ4/ftt1WHvLfli/gwa/cU63ZtLoX9q 70rl2ebFd7fbmVlzsS0qAdLF5ztVicFW1ObZ9tYXwo/JyjypmC11P0/XK1nbOhRmNfC94jrNGo8H NdIbXqsrlvkOJ+UKntkJKy/pDa8dx8t8h5NyBaeJJxVWj+FL6snL7szrCuvOunGKeW9s6lyGNXV1 GcK/Cdsd0p9ywQQsMJ0LMSJdUgh6sxAkWvCpIF1QhjDDyjDmPKozaoeleGFl9zZK4+yoLTTSZqEd pexPt0+GXRrKXNjH85Rg/kh187+fzsqg2/yefpvt+TBt/jz/xnVu/kJVItnfP+URzpk/orTQLH/6 mFTAlMrmV/PcEArg7LRC2zSYmvp8nkqkXaEy5uWxlfzim+2TWenMf9L5EmvXk+INJf4t0TyVp5z/ frt9MiebyVbWtasnJfrzqTXPTRPt+kxt89s5x0yX0s8NGHetG4eZVitaUpuuwuNE9zVNoalVm7tv iCOZC7x7ebud5+9zl4fN37ooHeXNwjdPFEv2eja3/03V8FmpohVCaFzaNqLyig4V2v3kPE7P3332 8UwU0O/zz4lsPUlT10fyP52TILln/OyTjzgty8pvmNrM5I/Pisq8gJznNqElD0ltWuztvKEzuTuZ FZ815WWEAckPbNKcJG20BH+oisD+r8+Piez5H+pjd66PtePlsLZ1FiiXi/Py1DfLtV6aaIpjjV0v Tl3T8f7ZH4hChfn/aygqjP4HFVUYhUqXn6uCpEmFDNAlJCOhmA2G51tJtLmlJMeWT8i2polssaB3 f5i7l1hn1M031GvRJa9ezxoLn1/dbkvCd1xEzoTJsxa8+9W2f6vRU/p6omN/f3708DRc8p0fPRPt DmnKT757efjVmdQ1zxbYUt+9+OFwrmhpfe1U8v7PdtY7vKFxXj7G7ijj4fm3rLOY+Gc3LmSPL+R9 tulmukPCn23/dRZn8HA2daXC5kTb8PLu1atV0psHlaZnszzVB2uQoRMsUrB6P9LeAlLW7eCpn222 T/I8kObPvH1DiVGP/khyica3+bNy8bG4EvpvRf8rGWJu0qre0vbFsTUKo4Codp4tbEqsmLMyCV0V qvyJ6LskwLOZZm/gKqn8mTJnuHpey0iPabIJLfOsy2WdopkFt3rOueF51g3H7Xq26R9r+uv5P2HX f3jx4u5+y6MmzdOn0P8WubrKUEnP8jwbmdobNgVnDdazbeANv8cFg5a6w+kUkLb/VNmF2d9335O9 sd58cbhbU0XubL6/qoq5U1ns22/DrlopHS1WehzbzIupWUd0hu8Z04kcMCE6S55RHSPCSR9woaWU ZCWtM8O4jj7F2avqIi4TTcoFE2oMZjYpoIr2N0DSjHvvAjPh3rsoGKdvH3bXV7kKlNmw0XbUPJVD 4hlTzm7CgSbhlBln3sCgsz2k5/0uwgTnwcS7lrxRQJB35QjTMr4bde902uHnDslH6m7f8ZYYMHeF LAwgbWvNEE4WaeC194xTFkxn0qQ1R8FdZdx8D5WgooLU2CJJ2JKcl4XgV+LNwRm2UWABlg1ZHpOE s0CmQ6UeAKcWBCsV9Fy5lgooo2XVwEEtSw6RqWqmeRGaa1OK0Dz14FkWoktHshK9QW5z3LAm2CmV aDOhS0p0oWJSovN3WXAgKcX5WKTvdDtLGdgpxXlTmLBCJkInJM/84btuLDwEm8rWiM0zkByyR1hF kTKPQvHMHSJcxyUGBzLTY5F+DIXZRp3UxcQPbamxnRVksH5UJUMVuKBC7pUKoFLuQQalYm6QFaVy brvqDMgNgqb8yQOkQfnH8y/nbh5UGMD9PELMRTjyCGFQ2ckTxojKVp4gDSp7ecIYc+2iQuuqNCvO VZVlyKkjgDcawgjRmmUA5XE3huGlzdbhl8fl6JRe6+DNA4aEjG2lmY783DCiVDMoxVVz5B6jUTWL ckwUT+53OaglZbeqrVxBCdVquQaVl7FBqBoRchb0ZQEVTJ9m8Mf0LbxjoI+DQ9aS/AcVd0tICqbW wJ6j4SE7wFfLcLUMV8twtQxXy/CLsgxDVsYcHM+Li9JB/uKnrGYW2PPwymeB9lZ16ha2RbAaiofQ ntVbDrIQoQPKGEHId3v6xR3dq4WicZxVKwDf+pC/lcZLqr1bNtEHh5uQ4lhDW5tbXHE5J8wSiqUE VvkPK7Q4Htzh9x0Z9asMvKcy8NAe4Jhl+rD0wH30kLnPmBv0GT1qHXtOCL43XMQ8aHrFa10elvkO J+UqVg2q6RWvdUVY5juclCu4jg1WRNIbXl8P5ljen+adWXW8ryV4S5s3c2UJwrsCH6vQl/VeBsZw KSQQaH0h2heXouYidEkJwgeUYEx51NWhL7C/ha2ibNU2Ozk1p4cf67kN1L7nGbsVcnbXve8xVQ1V svfTV15b+Hy5HXUf9hWdBorD6ypHCxGrfp4bt9Mz+3MnJGEzd9XirSXsa+YKJxzC7NNYxaG94z1F mq4IKoAJQ2vkSVOWrUzCJBRZHGcI06QpF0zRZt3ATMvYGSVIVitnMJ1wZiiKiP3tCNdRMBnBGWeU RkWrKqEZU05QooTZfTFByRImsuaEKVObtWuP9F0VzFTodvi5sI7GtjpwYyiKq/AgzJ1cLOjYNbtP EyZ7hCvDJohokCZVR4JHceeX1AFyYaMyAJXRutabkkZlAFqaBmUAOpIGZQA6mgZlAAhBC7hAp9SU AaBjasYBBgvyp2bkZ/akwLrUKwPAWTgNO+NTrwyAYKReGQDBoRVykKtUlQGQu1SVAyyVqQoDRGhT EQaQqwzDtkDyI4aYZ8aFJSs74aaO1Z1Y3KxpKYMK2vLEwus9w7TDOi7TASOMLOJBNCzijaCyiDeC yyLeuCGLeOOWLOKVmbKIN17LIt5kAYt4ExVZxJsoySJeBS1FIZRFvAmpLOJPsMq47MLoEEhxdMgW jI0edTXW0SVbMDb4pBs6NmUPxoauEMGGNvZgbOQLDU0zyB4M1Abob/pENmBM3wjvTB/JJNvUlbBe tVnKUFeq7ERwTBmmHDSlSJ1p0gTPPVW0kFnTwgknTNDSYUnXZPdkJm7Kor5dndNASRC3CatW/X3u SZxjrd/su9qLq7242ourvbjai/fUXvDpCfhwWEIFbCoWYH/jcObXm8Hea+7d4Dg262GIbUcvldD2 9Rg1X8SEan0AWV7HlhMdW6B9HP7HRlFaxcPgAbQXC+jK43ATUpg2P6u/nTfKqi4y8vxI8S3Bd2T6 rzLxC5GJh9zD5FQpZdlGiLuE6+Z7dUy4t6RXY0amKWHWcXXknWHCuC818m4wYdaRhPkcTBLPX6JZ 6zDhuEw0L2E+ThPFXIdxB8h6myCfxUGtE+Q9W9H6dRiwTStWgXBB8m4UzBtlYlXqAJ/4ERaHIFAB 5M0lwikLJiqMo96iotMdgg2FMZ0JK6xInZpgosE4+F0vuiw1iqElzPtvYogNi92e8y8AChMjT3gI m3fWFpkkUFMrp4/96JUHfKhFWHgAMvTKgob7Pr3yQIhYd0rTxmjBgrEqC3AfZKzKAnBwLMqCCfvY ZafyQPwfi/JgApVkRLLw6CV4EismsQQXULGTm/wkpUBggAjtmIQB+EFke4Ht9xqzZ5BBCy+ggtVd mAzWtAIyWLsryKD9Ar2s2yCuUwXEd6qBV07VMZIcXDeGQCicXyNf0jN2QsCc2xBIlwYIrIgKhNvl CLLvcoax4nLII8nFFAMPLQAsUcQxDn0ISG4dIRh4PoK0chlg/K8PP223jk6U6qNX+62jG420sa9U U9WALrvqGFvQKyCe6x1hl6ol5oQrLeG16TRw1XWeyIrpRAiJakvImatSFrigallKXROz9IqmDnO+ QPssGjym05uoyin5WcfGxTsEV4txtRhXi3G1GFeL8V5bjN5YczjCaLlISvje3ziq9dYyHaNG6y2r uyyszlR02LEJOUZcyYDQEVEXCqbEb0JHWbP/hk4t0N6sGKuF+yUMJvII7IP9w/+7vTVV4bp7qct1 HDhXhli1YR0np+NGDbbY63di+K/S8AuQhiALEtJGPBNNGYtnomDxS5RSDYFuAm2DVoqy7Qj1UTnG ukGr6SMuTbE4WMr2riLUtb8RrDJrvVDqucRfe//mfaEGp+oQMifsCyGMLUcjKZjkdLzBTtN+mDng e8UUXgDevJxcoeiPh7alCptZum1e5NZitx02O7qiCA+X8PkiuLQ8GnGJ7R6FiivRVS+ZnzN/lEFc ACW94fVxv2K+w0m5iqvYcE2veH1MrpjvcFKu4ixO45pe8fp6eDKx6M/o3VkZ7QplxLaO3tSVZRj/ Ro79Zd2x6DePR9BxnkeSXVSG9GUhR6OL0UX0AC+MHsqaFdG/aC1bJouc+i6Cf5HasCLPx/4acYXV 618X/Mt+OXszOvc0Myg0EdaIJFpEcKC7e0G3lPH9+tstrVAoPODXHOcAV/w119qQj5muKtyWVi0I 4f+bEEbn+o4m9HyR4x3HBVqtKfvMZ0dyq+Sgp4uC7bQxT7gBIskVrncADtkOx4UqHMRPXFMrXu+W G/MdTspVXNVgS3rFl9QzF+i98a6sdHdFfm9naOTqEphrDeHBQk/WexAbq6WQQJ5L3JBHqGaTnyA8 F1EDXBBqKEtWOP/yxlCB6wWPoqfzoNj84NrjxYOfd/dnvYHBDi/2vDvwQPsxsQ1RY7m+ZCX5fRic 2MgpVTyn+d5Btfn8iJACGZuiI8IN8AI+IL6cIDiPg+wFTBTge1wOpxM8yMYCJzbARQgm1KNc3rgw xBcpBEsr7qX5YTuiObT59wfX45XedLjKlbD9No8CniUk2ZxrmLwk3btruKeSdGOv8W3GpPt+Dfdu k+4LNtyFTLJt2DD3SLqr2DAnSqOdePNVRQ8zjouYSTctcaivsbLlDDrpjqd48CRd15ILT9KtBHHh SdhUNReeJMtp8eBJOBgwD56EHVpz4UnYwTUXnjSahu+ZDt2t+e+kYVr476RhUv8ew+YOJOm7UNYw 7mJNw+i+RdSSYVTfI7R0GN03iXoyDO67RB0dhl0LdBj0ZkrCb0J/UHBoi1P+NLQF/Ye2q4E7Q1P6 g3uDXHZU7g5q0YX7g1yWVOEYcJVSZWeQm5YiWoNcxFTJG+RSkkrmINfNRG4HfCN45iDXQQMGR3BN VhPXWArejPBa8HyAt4JbFxrZgwbaB+5r6GI7IgG/WOAUaqCAUhCXZI3AfFvUqY87ss4dXDZ17uGS rLMWV1WN87gj64KBm64uOKULUoXLfi51uGFnQlnSLkpsSaCCSrj9PMTMGB1Sso0cqtaGlbTJhp20 2YaldElHrfTYBrVQxAa9UMw0AghqCkPIrfpEuGHaBswyZSS8NGUlvHZlBlEwXQdJcVUISXJVCUlz TVqjmoWAmhaG/OoRifvSlQR5m7DkPU4o7pny++nAuNz3+motrtbiai2u1uJqLd5PazEZIw5HuGHv XGzFEu1vAp6rCjlP0N7b0y+tDnAwISdoL/7tC+1n8A3gKB8VaoBPGgLYmwUbijfOcRj7gnjkF1Ti 9m+oYm1dMTymt51JxrQuMtFHxYOjJHhdvxujf5WHX4A8nI9DDRcTvAl3dMTWENdG9NHc9lp17gX9 VDHNACZUTJsZyuK4LrgXzShF9aoKW3cMVMNqyoBJcoEJVc6ZWgDMNCBTttp4Vc3St6yngBD3D6/L K90lB4koOiAgi7gCEhYHu8ogq3cAn7IN6l7Hg6HUtgvODwTFv44jAxEW/zo5QGzqX8exSErt1b8u 8V5WL+51fEZRQG3CEnS6VxdHjuVbq3o48hyyVLmDRO/+UFjTiksM8gwQQThoNWxmV7ngRJjpILef CPPhp9yOqlyW+Ic025CD00MbQAbdUmwcHrmq21NrIIPu37UBZMoxr+7ntUEPMvts9ao3VpO9SvXW 0kaLL1fjs52qnl7aZfUEazzrlrisTrFiHqY860YYV6d3MRdTnnXL6blxq5iHKc+6CYuLKZhd1MWU DyCLeZhCVMqw8EMh3KKkFfMwldA/4iwkUlqCjynHozUfU5plE6zjAtqvRBjPzbNsL7yBLlZ3A12s bQ2EsbYPIIz1bRDCqBvwki6j0mV0r+FA1Ul9FMyptM+BKRPoYq5/ODIwnmJ+7DzHfNhlgufDJjCY /ro8Yfrr8sYqxWUR893F3jOPUHX+Ky1IPbSVDwrNrIMGc2sbU1q1jjfM1H08SsN1uGLe78NZ+y2j fV5AuCYQmrmmmDDk+iXJXdHgdMf0EBjmWmqA1mruqL1QcgOIYkoQ0mI6su1q1KCQNdewPThi6hei WoejYGp+pMGneToANN2JzvEB8nZRNq924monrnbiaieuduL9sxMjlMghggc/5ZR7gQOq4xHa64ip o9/dMWg26QG0Z21X7KT9/ggT6kZrwwIhL/CtZ4uf+zjSjw0gN0YH+jHYi61zLXE4UQunantU4Zb+ u1FUq9wvZf+BgRAc59+Jbb/y/n3j/QqvpYZHn6cdQi6wNgD08xsNAC2pDa/3m4v5DiflKm6i2DS9 4vUebTHf4aRcxUU0pKZXfEk93bjszxDostJhDIXExg6h06sLEf5xS0KP1hcSuL5gz0WFSHeiJA3N JOkiioAdThFlz+NedLVbPOv9R3uRLbgUf/PtNuuDbQuPtkc86VhVxdJf/0ARLPFw5aPOeY9Ex8Sz qFi1iPefvuj4P9khll80DI61D/rY/nHbpEOPe/L+Q29O0qvI7LEo2DYFA252tSTJvdDBDsP3JnSy XWjQbnsicYBtUQ0e+B3cfVVszT9189bfHSfn/V4vS+GqeOp1bok7vKnXuSeuiqd+p/ND9tuvulzA ffFUdTmB68Op6mqD74unqlYKF31SWA3UVPTeM99cTkWNCy6Lp7K895yKTxebXmWw2SPBPixk7EqB XrlOWaeqfFs8JZ3J4sZ2SjtdRDEZks6DK4OkCzQmwvLBZ8KtLrEt8CR9ssI6e5UaNXWTrqjQkG7S FRe3s5t2sRfduFiuER7Ceo1wHQOROpvAgIg2Wy+4fBQZ0Jl1B386m4+DeZ3N15m3nU7mwfnO5vqQ jM7WApCcrvnqjG869b56YzrISkPkstOFCMS203WK3NnrdB2j2H7nUee5MSStcFzi9bpxw9fbhhvA 1na5IWx9kxvE2nXcLza6yO1jo5vcTja6jpHmcq9ZLzWD98otuSpp3JRLlsZtuVNt0iB3rlVYcCPb JEnua5ukyX1uk0Rc9zYplWuOJtX286i5eXjqoJDSbcTIVXUdUNI0G29yzd2Go3TNhiuujNpoFsro YJcr9qYLxqgo5HK+KRLhh+kZudwPJSSsNA0lgQFMgYkomIJDXAHTfyJJqh4lKIFrTxZDV6647Zd6 fdk+3AYXWle5wUp8TW2xQ4Sf7+3nri4uoV1twNUGXG3A1QZcbcB7awO41g63xjSAQ5LXuAzVJdjH lG3xY7PYS4I8DERqC1OSEGLoCDAzGupwE2RHGiYYbwDI58i/k8d/AELDWK7rsY3zhhmQYV8t/kOt Ou49/oPpgcdUs5Kk9+31uuAYwuJ4esNqfkM0kJ9txq+S8J5Lwvrj5inciDvoWYzfn2PbStBMLW2s jWpr2TITjIG+CMdYa4RjrLU82tENzwoI69EMUIy1RjjGWsujnRuRsiMYY60RVliROsZay6OeWGEy RDhGZCFssdY6pM8mYXm0oDpsHwgP+nOH36sepTeGWU/SmRA5Aotvl0A1w1KWxbvLILoFvENTNN5d Accs3p30w+Ld4Zp/NwYiDNNitkk4HNsSNA5UJF9wYLCzUtYqhFt1Bg560spzPIJ2DsuXocM5bWPY VDhGhC+oYY6OcAYuekPzGT9HO2g+4yc6DBaGrGOgwQYXv2ALzQKUdSBCiMUT6sX482ZhfHqzYUu9 V5jiea9hio0omOI5ydiOO0Uxw3OKYxrgHOEpnvELMwhnJ2Z4zm7MQFwWMMlzWZHNRBUlTPNc0Hju 43Ioe34mp5g6iVDrjxaTDHnt9FmKttNnqdlOn5uOzhwbbqfPvQ7ONoaO22AGWWysC9VUFQhRTVOA 5qZHhCVjmLMTx8blpN20lDDclJgIhCk5ERhTghAn05EibapCRRhNw5Kkuvad9PZyv5ynYRZLrBAv oWVC8dWR370gvbt8qU/S1UhcjcTVSFyNxNVIvGdGwjTGYQllV0QMxBLtbwznW80Vv/bWgIVxAQ7G 4gTRAqwD2TAaDTz0mY6yoKmO+nyE9mapht6b5tisoATO7fRzH4wcFMDhSBucVc1CjK6GGp1VIv8P jYfoivTzDfqV4+8Lx8/cI+tYS1/20m/r+Vos3qA/3AzYjUz6Jr3iJrpGkitc6660yHY4KVVxt6yl O61lTV+6o1q6ZS2DeGJxYgHra+AZ46IjffaOrHMOkkK6o0K6ywrhmVCHnTrpzHjB47xCDS1BiXNJ EdqRKDx9duG5pJABTk5SxOA+Tmfdk1oruPZ3aYQvDYh3Ngahls7TYTgo/df32ye8n9/nzd2qzHw9 8Ojt4b+syVgmDX34p79saQePohi6/9Xna8rIQpffbQduc958djbyoOZL1uP/9dMft/T62zCWzUef Bl8niTxA4R95kzd3KeD7GeMOATChopElA+CdXMEUM+tey6GAWhIZtSG6+TEWSbX0ATeFBErTt9od caW4AjHJPNnaLxNj659g3Rv9UPu9brmf+NoKdrQPMxpxFijT5oQ7L7WTWXVqADzlTrgtQ5in5Am3 aQhngXw2KxP6BA9rwkMWzCe7siBIrcf5p6wXCHNy+eZTQ5kRpVZxqihml3BlmEeBfCQpy5bUCjbx saohyLv2suhJLePEUxZFhJkKsmginEHhEcVlBsiL0IuTLMcI0/0G407rJObrOMrPXXVmWnasBQkO zWXTah6U/kwswm30lhOu2tHMMHu3y9SUA8xGwoNTjWBVqjVgYwCHdG4CWAp75UAPqeuVA/Agn3pl Afzpp15ZwE7dU92p6GRA4QAudU1VOYAfhfy4DTYVJT8uXk1lpzLKNCjKAdw9m4pywLD9PoXsuMlm hcs9LKtcLsJZy+QilrVcrtFpx+QilnVbbuEZWXATy6gmd/iMqnITCyQfIjPkDpYxS64OGi/FM954 LXdXVBTkaosJilx9MUHCzRiTM7k3Y3Io92pUTHHrxoTYNSyEXO5kRQ2V4hiRO106hKRuHV3qXaKj T16rsdEpvik6eOWlGx3b6tmiQ18eyjHVIG4xpjkkNr9pFjkbhNrBqaFpJGzxucYCs12j8RafKzyI iulDLGZcXULSXJ3iRmDQtZMeNiaV23BKaSv/QP0GHe4aPeof0Td8S1HHxsW7w1dzcTUXV3NxNRdX c/H+motRlzuswiMMoB2jfUw6jrdvQPJMb6jd7I5gSm1WZAFQS5NXCoJGlFcLOHGnK7IlsryOQ84j sDc7mJdmMSMfru4/hPZmA0VBHG4sQXGV3sX1mevwI0oYnyLbbKzEkbNY2v313Rj9qyi8/6KwftqG 2BWDXG9UGzlMPhejiYRs46l9HUadCSBoxjD6XAyPyVQ13vGtHDXug87TqOTBJwIF2KZiZDqGwedi pOyHQScCTI0yNJuLkTUems4EWD0SLjqHwc82FSOzN/Q2FQMdepkL4DdjFtOgd2aRsR3qci42mBxD jAYfc0wEY6b8bPpZstt0WIq36bBUr9NhKsvmwtJsmwtLt2wujF7bVFiIkiPFwlyYCRrmwkzwMBlm hthkWBimk2Gw0+bCwmqbC4so2FyYJaXZVBiC1HQ2DDlrNhuGGDYbLxDTZtNhiHEzxYa5XNPxZDBq mpAdUzsrXmKwWPWY22njJASLtV2mdtY1hGCxnsvMzigjIViUbjKzM7JKDJYhTDTyGNgiMViMbYMx VMKvGLdlamfCgCvzJisyszNZkngrKmcyszMxlMmWialM7UyMZbJmYq6/yyjQ7DpItHgdRFq7DjJt nQ5CabyMT+2aDl/tug7vIQ59pZiqBqWoaA4l+LCcapviUX6pYlJ+quISdsdZvik8ERVTiBAkU5ci Z65OIYembSGmrowhxoOFGAgrfae9Lb8t4akKwu8yPN5isX+1GlercbUaV6txtRrvt9VoyppDgFO+ fRBU3IpZQAd18b2P9eqeL+MRrw+ICXIkBmXKskjrghhEmPoJlET9CzTnVIyWa8Zj1EZpoYz/pVkc kFqG/xKNqOf5kfY4PKAuThR6b+ResMXYJCSouqxLOY4cwbptE1f8P9/4X8XhFyAOC2FAKybRDapA 4dEjmFyGkrYpAO6S4qY7xVJUk51hfbH1FC8SC6j4hT7zrbwl7IAjnAk0OdWmF6dACablg+3y2XBJ 2ASvaZAXR92B8MHE2JGDAbzM3bDPOAtrGtMKjplNo6MB1lHeFEVigetjo4Vsh+NCFeZRYhchcT7S ayv7kbHXeVSowi724sK4azQz8i54+1fG/eLs1jpv2urswiWJgSZdkGnJJa+IWiFGlEsKkY6YuLis XJK9MyJa9LVH3w6lo5beQ5O589737kj4Yzsb4KxfvJ9+9p3QhsOaUCEHUAtPHYfPl9tRApHdvdpS bALyDHy1NjAazoFKb48L/4GCruGR5PBs8I/bJ3VuzDy73bT1rwbDEbWvtHo53AyFpr1A94o0EiJS 5hMH3BWOxL2ExFuWKKjTx5+QVOFlTsSS7XBcKGC1R4V6XDDPRzfg1/m8ejd4+t9fEtlPi/B2ogxt 6AVOxH3fSbxE6w3blXVuxKCPFuH0WV+EdsWEBj0RqbmkCGGElWGMedyRGEvcvvBp75kRX8+6z058 M8dLOTvoG5/axyq/f3CMf03/27G7sj9n/lMYk/Sw2zyz6BMI2BDcGvCeIZGXYUNgawJlgfhszbDm 42JkWiPCcgzFl8BSB1zt98bhuAkMzUDjGvEtmyFWikx/rWfjMkDBh9bjsyqdsmRSim136XSs9Rz+ iLfTaNTwgWHrRV0zqvIWHlIKWq+uPdfhqERBWV+OQ9J84dPui2yH40IB7eQaiQ1eUkfJi240p8VK BYUiYjtb6O7qQiz08iH05hJ1DRY3VddKn0vUNboShKaNJjWXFGHuBlKGMWaFuoaLHV5letsJWoPb lZfyiLrmaE6hyrdV13hqsFZ2HaJ3rhBEu+orlBJiG7jJo+eVdyEDqnjnCrjIPqyWVWTjVUTmGMp+ rqUOuFPY8DTAnDd8IgS34qrvamoP7EVO6WHRSPf6wteH2vN1J2Ty2mvtO16vwGO12sOz8Fit9mAd PFarPiPID80S7KrAsGyU5+0I9u1WH+ojKO/OYkBVe3dW1tD27iycVqu+Owuf1Wrvzgpz7OlZIYs9 PZsZtLg6rs0WyzRXq/bwbCc2Aw+wJQSBqvroakKMqqqPsuLWo9mpDiHdTKQ6BIir+uRrh5BuxkD/ PddF/li2clfr1pdotW36NqE0vSgLpGd5sfNQs7IAoCwolpUBQtGkDBCKJ2GA8CMpA4RfSRkg/OyU AWB3pywQaeh2C1nplAUsSmVSFkDSigWXhyQW2WVUSS0e4576WUZ9bdkwWIIg5J4c7w94afD69to4 X2gNZhHWVrHG2hX4LVpPcycdBx3warHTKSf0XOmIZ4uNzBmXrIwLeLbYuZQzBEC5yM8WO4fxOqUJ AJ6UdPkQzSHvWlbVJJAtvDAbNAs8TeVpXITQNKl1xQqp9t/jQ8c+KrRwfehY6raHjmsYcNpqe+a4 LMer9FlfORaK2DPHQjF75lgoOjgDStQkyhB95lj4Zc8cd6K2ZJQIt02NTbr116twRB0ISXIVCUlz DQpJdA0LQXUNDEHuu9v4au+C9hbrH6lO1I38qGPj8gferybiaiKuJuJqIq4m4v0yEdwGvEKN8NZg zBsRFjkLHBAtiKxQQvtQtTDc7BDnNbtxhLCscZVnKtCgA8oZwT4kpNYfAxQpbaP6yuhmUDAldaMo SHRBlUe8PfWkr9gstEWHsM2x9cCBI5FDXQ3YxsEDgyI86v4OrPxVEN5zQaDQxrCx/YQrGn0nJ4Xi vUe4t98JjQxSNsBN2t8IVBHRgsTi6YnrMRRfL0sdcGe/990AY8yEC4jFQ3EvDonWBYkfpz20A/EP u+Mrw1xKyPUm7iQabb9pgDiOuN4sfBxi9TeLLoeQ682izyHUf7PodIi53hbva9Zmse0Q5rlZ7Dt+ Z6BZaDwOCFebRc7DKwUNabv5axkZrDYLFMlmrzYLFIn3EZoFigTTm0aKlJ1hixQJgjeLFMlvMzSL FckGvvYWKxLvOvQaK5JPI3sLFQmd11uoSLwK0VtoSClNY0PiXYg+xIZk5ltsSAhOb8EhRX5DcEj8 HAnRh9iQrGI9wiMDozfNEXqPDcn0t+h8E076h8i7vteIXwgQ3vf+bGtC+k5FgZLXnf7KJKsa+w+h /PuqoQFZ7vq6fBOiLxpZkB996O2hLoVAeGLAE+MJCC8MgdG8LrwC4W3B+wbW1KYdD7EfQz8H7XeM fBboxCal1++2IDAWaM4ALNCcO1ijGfckzL0yV8LMG+unbhclY8ISzSRnwhrNJGta6pAchXLCEk1V TtCiEOIJG94m5JpfhsCE3WYbIVK1jaAJ8d9sgKHlNv4kYr4OT+m2jV48hmGDW6hmg18ewzDlIFRv +iNrpBCNc1ronOFIJQ27hcbCUxim0CAqru9aVIaQM1eWeArDlSnk1FQtHsNo9iqBvU9h+n0cRUXH hPoMjfFKftfR8RavFF1twtUmXG3C1SZcbcI/rU1g/9Be/BAWkEC15cIS7W8MQ8wk4xEoCI/LI6jV pVmRmEJqI5aoSiUSfKQP4dKbravegMajvGi+I+raAu3NUvXZ2+jYDKGhUcE+mDlWEYdjheEaeqmx LTq5EqeGehX6SFmOnMkssj1c9E5s+1UgfgkCcdZZjnhBPX3gqsMKb3KJ9STSIac17l4mWG/kaXrF 6y8wxHyHk3IV97LdqOkVr79kEPMdTspVXMS6a3rFl9STa+xP6MxKP36U4C0NzVxdwmQBTw7el3KB 25ryW8ow+lxQhvbEZSgv/d5WlwAuSAnKkhUPurPlLCMf8yC88BfbJx3CA+fN/uyNhoaLspb5kUsN 7J8YanIvufB6fAjX/Ppu7SUGXOBtrIeOLzH46+0Pff39Tx9tn8xqY8wtbX4TH2/3x+/YhvSdPa4m 24U45AImRDMQPJ0WEL+PDmg3wqQouwGmwneKF4kFdLgR1nccvA03whxU7Kn623RWgj+KKT1T7Hu6 H1aPHwydX8UB+jhy/nIUjchDlzTYZ59VDwveJ9vZdM5/BvL23HxDt3Z+eLmlaOrHAcKtjIQYbV7K pv8qjiOvjBe/fWLTSuk++8OvH0w48olpSPjk4WS8/vVk87D59JNtnufKmz8/3FTurqx2OMOLu22a bfL8Z/PTtknPXz//7vs3dBVvkHoJb2hZyl1MdLg7fHn3MrDizbogd7iv07Tr6+157vh9IH2aqtQe 72TIBTXFvSw6JLnCtdZ8ke1wUqriTk6/JbnCtTZ2ke1wUqrgNDaNFk7JDV5Sizce1QSSrLJfWkZs aujw6jKIcyMHYEdXZFNgVX5jdaDVZSVoL6LwhDdXLilDuKBlGFMeteW54o0jut2N0fkpOZzn1k2b u59en7PkueFhNc161pDnQV6osnqeu80Olvz7szWO06KQ8zVO/AKZV3hvnvTuU/9qO9DVx9Y257ta 8JJaI1OBCc/dYZumuf/D5svwKsTLs6UMvAdnpTxCMLwe5VXybc7Xr19u9U6ldyM0YTEVWnmhMyd+ marwLi3XFS5xfvbned5T+PGGp/Pc63gu9JvtEzKgy5/DTIpyQ5w+3T4ZZOr297/Qt5RPZc0JZkp+ 8vGW/NOob+F/Q75Q2dk3KKRDudnc7o8zrfDohTfoIyoY//nb+efS1dJv/v7rj1BJqWPIFdK+qT02 O1zRssSbBtyyf/t4Jttc2zBFsv3u91QLvp8unszgrfKScas7YccA8J4hXYJhSIBmuJl3oAMqHNkC OBfRmVJSLuIhJerxGML9yhIr5MkIYMKCmkBboBFxBxDxKYsrlXVg0Mg40j/BHmvhw+z3yrBoEpin 8J46on5OvqrUwDwlBJDGrxaditpW8jI6VbH4owD4RmSrkjVUCeJgl6TBVRAYqySNLoIo2iVpdBHE 1SpJQgYhCHfpNKIQR+UqncYHQwDv0nmAb4pPVDoNEMbxv0t36/HA8qTxwUQmJo0PJhSfND4YIo/n SeODGYf051xVihbYIrLVcYm5OGUoQpnlYbdozKAcEKkclAXckaxCKbHMclMOgA5Z5E5CmeWmTAAV c69MQDCz3C+ZkHtnAn7OgYW5epA82pLIVZmAH6vKBpOhKgcgOwaYBkVZALnLRVmAO3q5aKgqiG0u GsoKoctz1shXhpEc0ao8OSKZe3GIdGXVSShza45EyrJQ2GPohwTZsn5KHHMjwlADhSSUuRJQonsZ eSWSuZFfYoMZeySUubFPYospdxFN3HgvgclMNiT+jokOgh2ZZEkYZhU8nJ0GPTOCBiq2rlcl+Jj9 PgrsxjBItHQdRBInxgaZNk4HoYRRwwhFx2zwSgg1G9xCFhv8CKFmqkGoqppDQqiZYhGemOKRKGqm mIShprgkjJrqNYiDqTwJomYqUUTJVCaCqJlCFUlUfSth1EpRZW6BzyK1DybgxR4GiCbiaDRcHizz ahWuVuFqFa5W4WoV/umtQjalcTjCCT5BpwjLmQUOOWnps0B7b0BdGhhgifX5AKAAhYjp62ov4oAo 6wIt8lL7z6C9xhvN2RtoMAx7QSz/GbU8t8TMwIN11tTCY5rbudO8akN8DOVpFaphtoiYP9++X+Xh lyEPD54zMKvzZGefj8VIZG1j4d/Opc4dRA/RlB9LXSeaUfV5sEOZbjtsdr7n9PBnOnuyK6+J2kHY uylU4i57rLl309ICPtR31v06IQ4sfOveptD/C59fsmUKZW5kc3RyZWFtDWVuZG9iag0zNiAwIG9i ag08PC9Db250ZW50cyAzOCAwIFIvTWVkaWFCb3ggWzAgMCA3OTIgNjEyXS9QYXJlbnQgNDggMCBS L1Jlc291cmNlcyA8PC9Gb250IDM3IDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0lt YWdlQyAvSW1hZ2VJXT4+L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNMzcgMCBvYmoNPDwvRjE0IDUgMCBS L0YxNSAxNCAwIFI+Pg1lbmRvYmoNMzggMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5n dGggMTUyMTE+Pg1zdHJlYW0KeJztfVuTJLd15i/o/9CP3QpPKXFJALlvkk1qtWvLEjkr2eHYYHCb I1GO7qHEi+yfv4lzR2ZVddWwc3I0BPWg/qYyAXzAwQESOJe/3gy39X+f/erG3db/ffunm5Bux5xu n27yiH89wl+h/hHo/7+++ePPbn6nLw+HOJUhTLfrP+YSf/6pi3PZr/9488vXN87DS/P/5SEc/G10 h9Hfvn66uSv3t6//8+aT1zd/1TZwhdICbdTXN76U2zGlQ4rzkxWkfEhl/imGcsh+CenR+uYffnbz dq5mOKQhlxjm1s7llhTmVn738HZ+YTrU5/NhbuYTwzgdSn3dl1ybvML4uHTO794vjzB5Dzz8FF3L AxuqPOJhKJbHEhOvD4HHcJimOkYNHWiv0PERS+HmLzHT24XOeSbYVGUyHOw4LGHk4nfiEafBH6dR GyosXGyavYBEan8S3o3ZkoB2Kon5kWRZLHHcjcaI/X+WC7RWyFQ9a8dgiZnczmzGYSpH6WB7mU6c xkMwY7HEQm8fOtB4S6cUH0ZDh9ordAqVynSWmOntTMe5nI7SwfYqHbegs8RU6y50sPHn6biGTs7N Ir/CTO9DoRPDvNcydLC9SqfhcozYvkRC9uN4nIhl4ZsdyxrvRwSafZ6It9uXmOLBWW22xMxtZzr1 P6BTN2iWDrZX6fiDt2K1wkRvHzrQ+PN0oL1CZ/QH2/oFZHK7kMkp5rqtzHV7CfsA/BdDBporXGJq NsYrTOT2IePnz47zZGKym+UYvd1XrmDab7NsyOD/H+HizWYzxnlP3DR+if1+m801F/jDcoHWCpmQ moFYQKa2C5f5C9/ns1ygtUrFN5v+NU77jYtycWM6Qcbbr4BZkx8GO91X2O/4FTBPkCE9QwfaK3T8 hKct3PwlZnofCB0cL0MH26t08qFhs4DTfkdLSsZVPXacTG2ucgntB9oKI7l9yNQDv2fIhOb7zLt2 KBYw7Ph1doQMjJUl4+zIuKn58l9hIrczmbp3PkoGm6tscitXKzzteBCA58nn6eRG0Nz8KWlbv4B5 R0HjI8w8zDvmCGRgtCyZ2lzhMoxN4xeQqO1ChQ7NzjCBxiqT0J5frPD4AXCpH9CVCwqd5RLsaUaY 2iuLJRZy+7ChE7PTdKi9SicfJm/pLPGONxmGjpuSO04H2qt0km17OkJsHyJ0uGSIgDqwRJJhMTRf /Gu823ThM5nEV5RHiAz28z+U0hwsrTBz+0DogD4wbLC5yiY1R0trXHY8alI2s7yVo2ySPWkKJbZy tcJpx5MmPmA6wya2kjYcmsYvYNxRzvhIxnAB1WbJDOagKeRyiHaWLDGR25lM1WZHyWBzlU2a96aW zRITu33o4EnGOTbQXGXT3o6vMbH7QNjA0mPZNDfms85YSNoS73hnLmzq9+V4nI1vJW1YSNYS+z0l jU4yztEZGlFLpRWtJWZ6O9PxYQxH6WB7lU6qhRk6S1x2lDU+AFA6uJ5aOtBepeObQ+Y1Jnr70KFv 5lSts9xxOt4eO4fUGmissd/x4PkIHdgfWDqNyUYYp+ZwdoWZ3i50+NP5DB1sr9JJrXCt8LTjYa3S ieMJNqmRtTEsBmeJ046yxh/PwgZ3PJZNaMfGNQfnaxz2HBthU/86TsfZg/QQJ3s+u4RMbh8y9P18 hgw0V7nk5nh2jaf9jmuFTP0Pzp4XFzbUWiXTmmmtcd7vtFaMls+waay2QnSLoVjiHa22In+opXmr FmGvhtsdS8c1gxPyIVoVtsRMbx869DmQqjKIR+lge5VOsOfNK0jkdiHD22clg3s3SyaYA+gQWgO6 NQ67HUAbMmyLuibT2NMFPx2yHYslDjva00XePJ+hg+1VOq054BoTvZ3pkCkq7kMtm8Y6MPixPT9f 4R1tBCNvNs+wGZvjdB8WorbE436H6pF2Z2fIhFbQ3EKwljjsKGhMJs4bGziIxi21ZeMaQXNWgTWA ee3Dg/ZlaZa0kI8ScUaXudTeBqzwboqMdzGGCGykLZHU3A241k5zjdN+dwORtzEpzCt/Ok6nsdsM bjgEq7lWeEfLzWN0YDNt6UB7hc5Q2puaJWZ6u9DhjUwK9XT9KB1sr9KJ7WiscNnv6iby2p/q1KnL Z8GPA0sntqPTWAWvYNxzbHB5OcfF2gj7qTRHzkvM3HbhwqsLTB8HZOA7R8lQc5VNbI5o17jsdwId WTUnX+fNcTrRHtn6yS8GZ4njfke2x+jAZ5ul49vRGZr7gDX2O44Oq+ZzdAZ7PzDX0wrXEjO9fenM HIZylA62V+k0htsrWHYUNV5nlAx+h1oy1pDbl9gcN6/xfobckTVzctU86DiZaI+ffWkNt9c47nf8 HFk3p3qbNgId+Aq1dBpDbp8bU+clLDuacUee+2fIZGv5PI9bOxQrvJ/ls5LhkAdHyIztyITmJmCN xx3Hhue+0sEDAksn2JsBn10raAsY9rsZMGQo/MERMtaQ26fWcHuF836G3JEV2RkyqTHk9qk13F7j HQ25I899Q6eqOMumseP2aWzOztd4R0tuZXOUyGhP0X0Ktb2m4Us87niOztP+OBFoqRJpTOlXkGjt SkPiIBQ8hLJkrGW9H6dWmpY47WdbH3mGnCGDzVU2uRWpFZ52FLFbEwDhCJPcyNjYuDisYN5Rxhoe eDRoeYyNeLXuDWu8n7tDYKk6R6bxd/Cja47813hHfwelw9EPjtBx9hLALyJOrTDT24cODcoZOm0g Kh9bd4013tF9IzALiYFQ8NjW0mncN3wMi9FZ4h2dOAKzOEcntKPjFqOxxGHP0RE6FNKh4Cm0pePa 0Rls24cjxPYhQu0/R2RQFqF12VhhILYLEQ5HMfIfZVy4PFBjlYtvTv3XeEcHjsAxAiQAwhE63t4C +NC4bKyg3+8WIHCwgHNkrAeH96W5/VvhsJ8HxzEyrcsDtVbJpFauVrjsdxcY2LleAjqs2aRGzHzr 4rDGaU9BIx9uiRmwZtO4PHjfujis8Y4uD4FduJUNXkFZOo3Lg2+DHS6h39HhIbALt/jZr8k0IRC9 ax0C1ni/EIiBrmgNF7h9slwa9wDvhvYyZoV3dA8QNixvR9gMzd3MUBq5WkDmtg8XunE+Qwaaq1xi 46ixxmVHMSPPZyWD92iWTLR+G35oXQHWOO7nt2HokC44QqfxDfBD6wuwxjv6BgT2GD5Hp/ENcFNr P7/EQm8fOuQyzPYnBa85lQ01V9mMzWCs8Y4G9YH9bM+wGduxcYuxWeJxx7FRNqTejtBpDOpdmZor jBWedjSoD/xtc5oNNlfZtO4Aazztd6VxhA1cqVs2jXeAK2NzyLzGO/oHBHZMlbAbR+iM9uTZLSLs rvG439lzYMfUc3QaDwGXsz05X8I94+0G9uOUYBXFL26esLnKpTU5X+O832k6uz2eI9PYoLvc2pyv 8Y426IYOraNH6DRG6C5NzYHmCucdTdEDOz6eoYPtVTp2zrdg2vGA8wgRMESxRMzsT2ExKEu82+Rn h0cJIXKESGhHZGj8AdY47Dcunj0ez9EZrIvAvC41h4ArzPT2oUMujxx1o6BJjWGDzVU2Q3NutsZp v1NBzx6PZ9gM9hzNxWRPm5eQue3ChX0EJeTGmgw0V7m0Zs1rnHY7fD5GBqydLJnGytnF1qp5jXe0 cvbsIXiOTmPl7Np4zksYd7RxVjK851yTaeI7u9CaAa/xfmbBnr0dz5FpzIKdL23rlzjsaBbMVsGG DdihGTbYXGWTmmPANS4fAhv6HjjCJtljQedby9k1TvsdC3r2ejxHp7GkdW60prNL6He0pPXs+XiG DDRXubTJkNZ43M2SVsnwx80RMk1uJDe01oAr7HbMjXSEDlo/GjpDYx7ohtYccI13NA/07MZ5jk5j I+gWsYPXeEcrQc9unOfoNNZ1U25av4Buz1jChgx9fq7IYHOFS2urtYR5Typ8PXiaSmO4tYjquoDT jlZbx6iAxbBSaWO8ljav0xLuaB/k+ZrzNJMmzVMZ2kFZwB1zPCkTOt9YMxnsmOTWemYBmdguTNhB +DSV3NjSpMbVrEV5PzMayI9b29wUtXx+UZytaW7z++77nke359Hdks55Jj2P7n4keh7dFbmd2fQ8 ukBniXse3Zej0/PoNlyOEduXSM+j2/Pobkin59E1re95dDcn0/Po9jy6W3PpeXSh+T2P7uZkeh7d nkf3fZDpeXTHnkd3Kyo9j642vufRfS90eh7duCS2C5GeR7fn0X1fbHoeXW19z6O7HZ2eR7eRtJ5H dzM2PY9uLczQ6Xl0t6PT8+j2PLrvn07Po3sM9zy6L0Wm59G1je95dDdj0/Po9jy675dMz6OLdHoe 3a3Y9Dy6jWD1PLob8Oh5dKXtPY/u+6TT8+j2PLqbkOl5dC2bnkf3fdLpeXR7Ht1NyPQ8unae9Dy6 m5HpeXR7Ht33S6bn0T2GdzTk7nl0teE9j+5mNHoeXWSzxD2P7gvz6Hl0j7Dbl07Po0t0eh7d7ej0 PLq27T2P7ksT6Xl0ex7dvcj0PLprdvuw6Xl07Vj0PLobkel5dO1I9Dy6W5HpeXR7Ht33Rqfn0W3G pufR3Y5Oz6Pb8+i+Hzo9j25DpufR3Z5Oz6Pb8+huQaTn0e15dN8Xm55H15DpeXQ3o9Pz6FoyPY/u ZnR6Ht2eR/d9kOl5dHse3fdFp+fRta3veXQ3otLz6DKVnkd3SyY9j+6HkUdXP/8lkFPWkHTUPlOF 4LmyiuaGUC5abAv8+aAVUpraiid5FHuESlEwV/GgvUUNJzSvvFSGgsy/PDB32X5kfk77uwFz4Q/Y f/WwIpF6hlIoHABXYGBs+zcW7VDTwdiEYv9uHv1aEg9vmhEYi98sUe+x4l8+fy7Ucr6CH5PWVorf INvsuuyXTAILUfG2zs26qGSjlKlYy9aZTBe1bJRgFGrZPO/nqVpeKh1nW/7LZ8nE8rdOXrmoZaOc kljLtqkeoY6NMzBiHdsmRlzUsUW+whNVvGQaQahi2+x+iyo2SrqHtWydC+9ELS+aoq6tY5vMcVjH tgndTtXxknnWFnVslP4Matk4KxnWsWWyMKhh2xxebRUbpdbCSrbOeLWo5cUTUWH52+WHgvI3T9t0 opaXzaa0qGSbJEdYyaa5h6CKjVMCLerYKFMP1rJxAp0TlbxsXpumkq3SzWAlW2eBWdSyUXIWqGXz nClYy9apTE7V8rIZRqCWzRN/LGrZJh8HVrJxmoxFJZtkr8A6tk0q0daxUa4HiFKydQoGrGTrzAhY y7YJC6COjfMILOrYKLw/1rJ11P1FLdsEw4dKto5Rj5VsGzq+qePlI7pj8dsFWofyN49/jrVsHZb8 VC0vGy0catk8iDfWsm1sbaxj05DXUMXmkaixlq0DRJ+q5WXjNkMtm4dTbmvZJsox1rFt8GGsY+uY wFDLxqF6sY5tI+i2dWwV2BZq2Tje7KKOTcLAYh1bR2fFWjYOmtpWcrT8HxXLFMrfLMRoU/pGkT+x jq0DckItt5vFyVwX/6LhK8Gvb/Ookm0tWwV7xFq2jsEItWweGhFr2Tpi4aKWFw8kiOVvF98Pyt88 7B7Wsm00PKhj4yB1p+p40dhxWMnGId2wko0jrUElGwdAwzq2jUsGdWwdLqypZJsoXljFtsG1sI6t Y14tatkoFBXUsnmEKKxl48BNUMnW8ZQWlWwU5ghr2Tj60IlKXjYoEFaydaweqGXjEDpYx7aRbaCO zQPOLGrZKA4M1rJdeJZT5b9U1BQsf+tgJujHsnWMEaxl49AfWMmmETmgio0DZZyq42XjV2At24aV aOvYJtoD1LF5EAasZePYCG0lG4UswEq2jSQAdWzs4N/WsZXf/YlaXtgdHmvZ2ksdatnYeXxRxwY+ 3VjDlq7Wp2p4OQ9orGFDx+S2gg38haGCDd145/Jv6/9qUY2j7tIbd+Gsa/14vwZn0drS7iraXUUZ dVfRppbuKrqu9ZlauqtodxXVKrqraHcV7a6i3VW0u4p2V9Gb7ipKRXZXUVtJdxVd1dFdRburaHcV XdX6TC3dVXRZaVNJdxXlOrqraHcV9d1VtLuKHqmju4ouqmxq6a6itpbuKmpMULuraFNLdxXVQrur aHcV7a6i3VW0u4oegXndUU3x3VV0WWtTS3cVtaV2V1EtU6vorqLdVbS7inZXUd9dRbur6IlKuqto dxXtrqJtrU0t3VW0u4p2V9HuKtpdRW0l3VWUCu2uot1VtLuKVvShuYr2RKz7JGKtXT+Jnfvij9r1 dbtSe2cie1tf7RwZPjKMZI3MT8e1dXIW/8jFH7aWSCbQi2IR+oHMbuhpwaaWS7jQe0/LYhG6QOqa nhZ8cS23/3kDzg/DMN7+1w3u9wwzWHOE2ufvXKShAUUKj3ctEoY54/GOkC+4n3iXMllUqEju3h9R IvWlyiL2JQvjuxdJgyxFyqDXItWPffHuzz914627ff3Hm1++vnFwz16fxL/qZ/BYXVLhUPL1081/ 3L2+fzXe/XD/KlWTNJ/v3h79883j/f+9ff2/bj55fazYOsq21LtX97ev//Pkw2DAYtvwZq7JU00P 97F6nYzh7su5+ru/SL0zsXiSWDW9qaICbpG1BY5b8Gzfk/Hn6DMdKPgRNDfiR8EDXSvz88P6mvms Omnfe1qVS7j2S9RqGF460ZvXnpaFMkze1JCuUVchgj+BYQFfwMLiInGnQrSRUAY38sIiaNToEkbI ONxxXlSIDDXf5HD3XFMI94jKD/YIy89VPZK86Y/EbTg7p0MabucvnLqBhMn06/t5qxeGGOe5I/P3 b/Hc/A15qku3lnJ2AocC5+e2zheYwCPc88V5JxyFyKv56zRNY7777ayk5r3X5OLd3+5fxXpakONd vM93t1L8X2+qPMAQzH+AMObR/DHS+V/04OAhCrvieRtTMez/qufo5AHDhrbiuqmaRtyjo2dphThr wZFDAhZUHAtg3Nz5WjR9yrN8TeSTUzGsFVFm5xAB4r7KR9CUE52XVUx9hBstDyNAfYYYH/eE6n5y Ir/h6FFFzjh7whFgLAShG8iutDqeJnicAPSBY50ILh8Vj54wsCa7roqhVzCoBjqxVjQmW9rAPe6w xwfucWxKmbjHPaqL6WCJ8Fk++eFW7Lx2Qync6RCVpGLqdOzFuvUkiL+6ZMagZO7zEVdM3tyyQs3c 56S7MnU6Dn9J3OnwR8WZhcsDjCxbCR/3LFsT/A6gtjCWkfsc5ZbP/cmNumJfWiy/Q7fI+9CdVHYY sFO44jDgoswNC8OhmGYHuJxRWsFxr+DP3vRI8Nwj9DkAAqc9io7s2uMBxFfGIwTsEh6uEFEYeDhD PEQz2HhMpsIQRuwFkpUwHqwkhRFnDEtaSDijWBJDwhnHkhoyzkiS45BxvrKY8890dSWv87Tg4nna cPVemybzjRou85GIyXRF3jKbqVt4slOviSqgThVVQZ0uqoQGRVQNDRprouCNlqLBFi1GwiAqDmVF NCCJEitIkjRVnyiGql5RTFX9ohhP4hz5h5/dvJ21e9v5qLeL2WhXneOj1UH4O88P2uH8ri8UfaHo C0VfKPpC8REvFKNokSfAOdHYHAcwTA83LTbI47OjZ/Sg1ed2uUEsa8cR9GCXKpqRM3WpSAC8acCD PAiNX/ztI1N+sCpAGgcYVBgvjAhEGUANXy/Ux9MRdSEqXBoPWJS2jAuNkyyjNHVkqrRTR+1/aJl+ oRW/S8RHIRGXbtt8xtoDWvtXWDsisF95Ao9f0qKI6yjKHX+acKg5WEcqIBeo7yoK+DRefiUI3VK1 KB3XV2MmUrIIA2K8fuFrHVTGHu89NJ5Ygls60rkVw+l5xWh1gq4npIMRw8/wN3jsVZ2L1lUzhm6g JcZDRWzZlwJ2Avt+0aF1oICbKWAfDHqhUjV1YB/UhIc1gQ17CHtcS/lxgViaZ4M/qkxCj1FjxAAi yfxQGr4comHp2U8Ve8CzKwJ1kOc7YupAn7X/awdzQDLqf7GKoOHxHBKEhs8n7n8YXc+WRjT4niUB +mDk/ge58WwbSGLlRx4BFDvPTmsklp7MoElqcWOPeMKfcQQU0++wcZa3cUsuhWfcN0vlGXb00raM 22ZpOjqcEa8cuA+QdMZvCemTHKkTqM8yfotIn2ZUKtTjGT9kZEAy7pplwHIyo5lxyyyDnRMPfiQ4 JSMqGb+/RI4y7plFzjJ+v4kcZtg2s5Rm1IELKCKeUWfJFKDCZIpk3JDzDKK2yAQDZ0Sdf8REJmdO PFlpBBJP64yfETLlqQNFJaADoqoM6n5RKRk/Yljj0OiJQsqh0Vc08qLOMn5BibpDwWFlmPHzS1Ql iZ2o0oyfb6JqSWhFFWf8+AvsaUUbOJ9xvfDkf9RodFQvQ+GfH+Vn33p49xWjrxh9xegrRl8xfhor RmD98dRCA2YeLXqQR3HUzqEHW7ssPIrNKrJC87vJYTeKArQYHbJbIC20kF9DZhY86DoYFuti4AbB VDiCHswiiPrhSciJvnhGg2tfyMgRf5lKZyaLfvS/zOLfReIjEYlGIMDihCIfiVKuOBbGFWVugwFA iTEfUHJRdJjJNiRLOGpFPrZ4YBicw6MhICcIKqoVI2ap5aJ0bUCOjDv3IyYi1d41FX7wWiMvsPAL g3jeQKMIPzL2hYSPnhd8uZGXfe9pVS7jkfw2+flx7cd5CR9672lVLuNA8Sz5+bCOb/lsPbFYPjB4 wudC4yYsRBuLhXBjLy6ERhB8Twyji43GzKiT/4r00hWGZ0DGSBKQEUm6qkeCRCfFHuHhucDoC3bB NSLUrIrBXOpX93n+e/T+7rNPzhp7VV0v7z1j6QVfM7aWl7D0gi8q+rCqTfjV3GCZyHUjG9Ckz8Ny EmAXW8GIv9Q/C8ciVDBW23qE+CX1yCVI2CGWmRUuqHrkeYOHwpjCE1YELREEWg4hNeRRG88e7tBW dTwn9f7T4XqhzQX6CjgnIULANLNi0p9lBo4vacljyh342sDjz3S/WN30KnTmyta5gW8n4WKx4mSu fCtmGPBxZ+6Lq+PUxNes83sVJ71uFr8q+iCq2Fy7uqHwrWwAR6fCd7bw8VVx5FvYiI97c1Xu7BpS nauyuWMXZyv6hKzY6xV9hQPf4If6eDrYX+UuBj44K5bKoHC+lQ0Ikm2VXOjCFqNi17CS+2D4hqw4 RdspfJcM34wVumR6NGiHV+v/QW6qaUDkJru2qkJvRnOQa/CErOWWHKVhkFv0jJ0mt+woTANfUEGP y/V8AUDdXZCl3PULpu6fkLU8PyFrLiwOSNsTsK3A7DXayuiQM7OI7pAMyeiQNPVB9MiZewgdcLUH Y0DO3MMR/QxkAGJA2jQ+zdjFiBLKYxtjO/ZxPHgjGnHETiDJiSPODpaqmLAPWOow95BKZczIm2SW HEFEpNFfQgSeS+MJMdeWipkw3BhuOE09Hy0RnoroFKNTFd/kDg/sTdl04KQdXoyK4P5nFRI9ayBn h481UHSsgRLj2gmiwNDXWRUcyo6qP6hGtSOKnSpPdE5VxQrd4CTcEltTRNgD1K6nu3OroRt1Qpe3 +DtPh+vN7voS0JeAvgT0JaAvAR/eEoAaOeaDQAX1EsGCB/NguV3+HRIP3oOtuVlDHPhqLkGVOXzy 4YZOC1UM8JSJqjkByCDKYoP0RJMQtg8kfViscWjAuEIgTGR49bW+LfGwltphQJkw2nmU/m3GRcaJ +oDEV2ZGO1Oy/QL73cut5V0iPgqJOOabO0GmihDgMGtxxEqXq95TylU/gYYm/Ai4erIjrkXVyAce VhaDILwAYZE0KktaWM+fbYsFczqHSVYHwQIrcNJdBkH3E6amPCoNvu8kloFjvfBRzU+ZPNwv4MX8 vH0f4O4Z4SPAWdoRVjDho3VzrwimDWFX6LaOSnKFSiKiS0i3V/K0wXVdRjwjeHMo8ifXyQ141KbL hRgx0wAsP1HGF5tKaRIyskipOLFFyqy/KlY7qIrE8AmK5FDLaAtTsVg+VVLJseUNLAkVs2WNsynO 0BKn4syWOQjF8GnCx8XwKRVwlmYboJpRTAyf6tXCOInhExzxjxNb3sD+T/OeoflRGIvYPtVuGDkb CFovVSy2TwWgvSUNI2ciwhvtivHtulmrKCT7K2dDQ0upilM0hVM8FTSUoiN20zSJJhIBpIYWx89H S6mKve0VDgSLllIVi6lZ7dExco9DpRX7qAMyGiu2mvmMehwHc+TQ+mAmVaG3oiDZ2ehQeqQE1SRJ IwexQ0spciFXORw5BBKaRtWcaKmF9s6+eXxKpjg0StHq0GhFWoM2LdpYsHhRLmgQo1TRYEa7Auxp qJtwUmoX4iTWLiYdI0OApjw6RGjqIyOIlkA6wATYbgqFfFTTqeyN6ID9kQgWWiep2KHxkoolWEap 1KKtk8g02lWpyHNpPCXQLktnDLeFZxQuSzLhcjKTEe3BdLJyH/BkRiUtc526EPUAWqKpkqD+FyWC lmyqY2jsRAehGZyoKBx5UWBoQ6cKjuRGFCBY4Kl+JLFj7YnWEqpcSWo1paPYPoGdWe1cCJdnVLTV JmyCIdPgXcxku+7vur/r/q77u+7/wHQ/2ZGQDR1hQfj52aCHG4Phe2CJaE1hM0KoP8gychgAwrMW oFE6PYmWisEIQ3I4AbCWU0heVSwImXGxCW3MuFrJtIttQrgCpACglq/tu2Jw2qgINKm0FIp0eTM2 shDmZMcOZ8dqstAaLGavP2oV76LwcYjCNS5L9QSC7fJIY9SPe17XACRtBn34yxJJdpeyhNKwyxJL Ay8rMDZXFmhS87x+06IgyzupfVn+Se3z1kASAuLGgRYB2VjQIiAbD1qwZGNCi4LsW7zs5erpVRaH GgS0zYBFmJYI2S5p1kCMu0knPLTVohVD9nW0aJjS+FQFt4W4oJuWBO7yyIcwzlsaMsHrqk1LiukF 3kzDOk2bDe1C2UzjGV42m2kYgXYzLVkFefxkM13Qsl020zT8spsuh8KTxUjPQGD0PNVJ7JKsvvCK ZhqEBrC9GiNZyqH1zcOTt4XVvjAVeeQ86NKsTcyijWQpVwN3Wfq1B3CUpYNABrT7UGK0e1GitPtz MkNDB6g8cpkOCkUDpHbccVaoXOCsUbnBSSZiBVPQHOUVnFoslHpoSVunCfuFfbzKgWbEEE1p4uKV UcrEx4vaIj5e+SAzjXmIixcdMoqLF3VD0s1qttOc+1B9vIZodASNgLh4RVRA4uVF4ydeXuGQVD/x 6IuTlzcroBEdcfLy2Mfi5IWSx9oT5cBoVpBbNQxvXZCorU+8pZMHjUax/ng8Hd7JabWvAH0F6CtA XwH6CvChrACJxwI9DosoDIOCX6AH++yYbteIbyIfTOXNKlIGnrEtyvLsAx8+WgU3FKnlFJJXFRsE HgNSrHWJFMcCs9AFf7tErBCCF5fDLErhaaUjVCkvdPRgNIpZAnHuCZbZsZwttAQbH9Qfv5Z3ifg4 JOKYnQw9V8Dk4lpXRIzAFydOYIf+kXFSW95sgg7w84wvd0W07z2tymXMhoz8POPLXQTte0+rctnp rtCBLj0v+Jp6vKXTusJe6HcHZWhTsQxu6sVlVL7jwJHnhc/lLpHcSVyI6aRr/CqBjQoSsmFBuqIM Ggz1ZuTBucARkSI68Ew4FYA+nfdJJNd3mU/n3RIxiI1W+RJeiWBSGx3suy+LP59M7PlnunnEzLZj pgThqcZPZfjIcCT7cH6a8aVTvn3vaVkswYFukPhpxpdOxPa9p2WxCCMbPNHTgq+ppaYGslxKUTIX STcXYptairb14kJg7DBbhRDCHflFRfBwYwncQ1cUwESs/JSiAnRNITQUUogMTS3ESV6Zs9N+xE/I cTw7588mnRgpX9b4/IQfpwHHnmr72iSmmSe5v/vK/MO3UulguZye+qMDFTaGeooB5X/+zQ/fPtzX 4NIzpbs3t/evZrUAf//5/tXERGdNMG8u0lAyZaKYPzcq+PKrr7598913/3BfdUnVHrdnu4Fq9/FA eS/+ae7LuYYw3r357vv5byjUVPz2y+/vXThMLth//ebt7X2Yqr5K2pQrmntJG13dTEEbjUL89pvv K9Mwd//dNw/1T1CO3zzevwqkPqWuf7if5J9ezRygT1/Pv2JR+tc/z7xRiR99xfypvfX5P1aFPcxt U7UsIWQ58mt2GIqU7bazwzgXaKmdIa5KCzjQKsAR7bOxlJripdHXK8wOJPy8YJRnxBVBAhlwP1EE lQ4YKZUdi7j54kgkEXJ5oWgj5/6UaB8NGYL55QaHU/uKbfo4YIy5TPepCTcdmS7vCI503MFPM758 xbbvPS2LRRimthbBl6+l9r2nZbEEM5mT89OMr6mljorlkoqSuXCNQiumqS1E2npxITB2lKRKGI3X LNk43lQE99EVJXB/WAlKRUXoqv7AwdD+4MFp1+wTK3Wd6vWwe7WvtYvC2Q36iCFApJTzy3UBtzN9 +Os3X341r8v0xnC2uQ4jvoHbHDT3O1iM3YQrzJsv5uZXx5+6zplV6Peprh3FJ3f3hS7A4aIFmAIj Trz8v+sCDE2DZoZTTftFfR4XtkuWXWyZS7w1+M39q3xwc7H+7s1/f38/UtVfUAefKwuP1U1ZdmE9 9yKFA9QXdZX+9ss//vHPlejcFcM4f3kxty8e7jP9+ag99OV5usm/axOpnwYR8U8f64YwzZ9p857k v+aNUcBNiW4rvvx/bx6hM6FlRzcZ/7P+HufhnO6++cvtvcOHLSEz+k/z3y4eYOy/txsQdHONroAj Scz48eDwpDBmUDKA6t819qHDsJ+KaEmkOKWcd4MKgoibrO8WgM5f5EnFsTCuyEcOxmlQxFoRO7qT kebzWRWzIyz7j58k60vjG1AGAHQt4lQgHFSPU4FwQENOBeIj+/pBNhCO6MfZQHwgF19MBuIDH/JB MhDOjs7JQLxXd3w4I/Tqjg/97Tm7B3ai1+QfEFPOaXIQ6DgnyUNuKWePhA3AlD4SVYASAj1S0AHK /yMujpQ64JHdOCmNgbhxzphAsANC+QtkwPR38QE14kdFu8I9PqCGK+oFiz9L+IM6Xi5zjyMvlw/2 GNVxGk/qEyfZnTFEn0vc5Z6VunQ5q1cdEJc05w2I2qgRECKfUj1yBIqKo5UGSlRPASyii9znKEsu agQE6InInY6y6CJHQAA/WRfNntsFPqbG7Bcu6J6csPwO/YIv4yZfC8ZPAK24YKdIwyboFGk3Rv4T WhN3CvnYD02noFO89hk6zWufolO9dDm63OuAoEu+Dhi67OuAwtZExxsd/kUcMByASguoMxalSIqF JQ0DDagkxlZPRqsbHzmIQcUS1MCoIX4bp0gkfcfzh6qW+RVJX/L8o3bL9IwUgtsdDGmZ25EiffLE pz4TxRAxQKlve5zVCoa0UK1DAyZaCcNhGK2F461KbUItxToPhEU1YuEopdY52ihUCWmqUur5wkdC HoiKJw9tlH56bqVwdHLYA9u+KPRFoS8KfVHoi8JHsihgLgj+qmGIny6nEH7INNig2r0NepBJw7kX WiwrkaBBkkRomi+RhgZTokhqhAUPNwoHSaaxRBj+k+t0YbX4maxox9CDWelQJTytVQQlC1MGhFlP U2eYsRpM2guZDjpb7OywsXBeYoXvQvHRCMVf2ZoyclieGrncC34EXKtBzHHNMaibQTmZqOcsP1wW NYGNSJaQtLY8bfAQGQeHexH0wBbgMdo6QI4sJxQkGQhRJNypX+H8HgcKYM6pdzhAD9ksR4pNx5l7 JL4P2lNHDsfEiX8kfg9epkcOhUdJgwbOeAF7jDhIOiq8tR8kHRVYE3AUPk5YNEg2KhT2gdNR4fZh kHRUkc9O2UscFkoOEEh27HGQfFSRDlrFBD4OkowqcI+THTnsDzhyISd5kgGhVB6Dt0CST+FmwmIj j5whiiOTSVM0HRUMkKSjIhaSjgo3QoMYdKK/+8R2gRgkYGL3CbqDEvcJjC8wTXYEwlR0BBLiFHUA KzbG+BWK90T1IpzEfQJjI0ziPoEe75O4T0BohYndJya+L6MxwKkxid31oJdn7FdMFtgMeH6gD7I+ 7A5NQY4v4iZjJC3tQP9naSR5RwsJ8p4WkuRdPRkD7hK1j8g5W7qQPLeli9GxWwaA/L5lgMgvnMcv 26GlFFEy9JRYSUSDckQNJk1TjCpZlCJKBI+yOolgYoooEVvVqzmZn0UnYQ4omSJcuuRmgiRQMsG4 bRqtC6RYUjMlnqvip5Dt3KbUWTL3KRMUqwbMuyWKgy5+RLFQ2i7RO5gIStQSZf1irUV5oESnUcYw 0XmUCUp0IiUcE51JmaBYpWK2MlG4lFqGw302DvHa35o9iB/k/Dg6HmZGvFNElL4o9EWhLwp9UeiL wge8KODX4kCmxC3mlG4rlJNJBodY3vT2zwdbtV1WCJNb4lEkydxI4fHf/BdWa4G+gQ0+CTRYxzRq sxTLXBdU4+4gYs8beJpMseSJpKr7tKrWHpHBIdYyRdJiTgBuT2leYj3vAvB3KgDH3DQGDLiVQKm9 Ww64XNAZgH1usmRgcBzaDSOn0vOMr8wBR+89rcplHCI7ROHzjK/MAUfvPa3KZexIs/PzjK/MAWf4 eI7IJW4DFxeijcVCuLFX5YDL9Wz/SQnR0nZVDjgqQzrpmjKYjEoSkmFJuqoQRxGluRAenktdr0KK bCr5L78Vn4N/Flu8z887XlGgRSrjvN/VhPNfK3yxbHAhivtDJUFmd2qu97kxqWsiUtWjysAB5vDY L2B0OogqiJ1JYaUMgoBPjCNtN7ikmOhkEsVrCUfOY0lPG1wD2yGuyMO7dcsqAOMzI+RwXkJA4utJ JK+0PKP96fE+GqUeP/vKKkh9O18KvlPdpMBZKcCXKBqI3s/zZP6v2vWmuz9Vgf3h22rUO9y9uR2/ +h/VdyXM/8W7289+/ctmBkmpLtXdv5bazh3zGNC3tf/6N5/e10zrd/96vGRqr3Pii/j6fhzvfnj7 9s3jibbMva3Pn2oJXl7Zct+8fZCe+PIvV/szhkRZmtGljSD7ALIE8cMEr/RmxNeeFmUS8nhdz48S vNKTEV97WpRJaPBNDQSv9GK0HIrOtGu89mwjS5FWXuPBGPKAK7iQucZ7kPqDy+DueQcHxEZqSlGx uaqQwTf9QQOz8mE84/dHZy4YBRWmw9NfHu9f1Xujaix+3ja/0CaPX37GgZHi/srTV7lE4Dof4LQE 18i5nY58FM43M2CcX3n3fDPBBdJWZK33G4v523sImZvvvvnLm2+rP0RG/4zGIeK7tSF8CJiPnSy7 ET4CrGsBwAro0dAgWL0E83tQjHhIoWSvMIW0kecN9gzJzruinBQlMgkHQIdLUk5haxVqVGnX7J8m 66tsHuvWL0Uyeiy0ExSTxwodm0DWLUWUXHD1TIluj8WqrWIyeouoaTkXHFQSouSCoy2Q5ILD3VOU XHC0qZFccLiTYeO9ug2OkgrOo44X70T80bOhYP2+iJIaDm/Q43AwdoQVitlh7as4NBmZKh7YiLGg ABU1YhR5QrMIEiExYtHxozzxgU5M+W0eTrSBrDiaukPhEahtDiHzAGDTQ+YRQGuAkNXUEz5H88GY hVYZnWyvhdTkPxQZph4PSQcApooxgCSRZQNIFW8a7CC2MpiYPow8BigrgUx90ADSfDejpAWxDYPj x4oHNogsoCUlBaVHbEwgKwwLbGzLzNuFv4OtYZqpvD0cQLs2bfqEvSLMJu4Yz0ZztmPQpk77DY0g qVPRHk97HE0gdUDQnE8HDE0gdUDBGlCGGy0gVRrQlFClJUYjSpFWKZY0NIEUQYykhozaITVUjD2P in1E9UaTIooSY+NLnK48pahymXJoBKlTklrOMxZtIHVCI22Z72gEqcqAek2UBRhBkiKhHo9tqkdV QjRcoqTQBNIoMRxt0XET6ixRgSAqqiELqi1RoChpqmCt8kUpjZEVe2sXTxpFrObkwZXG0clhgxf1 RaIvEn2R6ItEXyQ+zkUCz3Sx658W+ATi75wGG1S/iRokNtGUNO9xgWVpOoLEJrrRgorR7pkbYQHb RHPz+bUj6MHO+uVqSE2iSb9CbBTtRYc8WSUhar1V5IRZ4rk7dLi8GT2eDyfmx8pS/seu+V0uPiK5 OBZrh5YCzLZzfbCdEbOVpijRVghygBqJNcxPM74m2I6+97QslmAkByR+mvE1YXD0vadlsQS9b7l4 v+LybC1DbLlQ2HR/xVEqFmKbWgvhtl5cyChJbp+UkbsiDCUPOJXBnXRNEUzGylAqKkRXFYLDoYXw 8FwZIq/G3i6wMMNp6q/u55mXRu/vPvvk/OFy/WzRN5+JtlMwxK/W89Lx8SgCL2xakMjc/lk/+DRM dxD1ZlgF5Pnin+4jnVB/cj/RP37++p5P14+GXGnK/W09bcb3PvvX+4kC62j0mfpv+Og/QgvgZ/1H vTz+4vX8J77z7/K2aer5sSD2cZJD8aaV//uT+3qT9+9N0Dky2mHXspTRNod9yTTM/fwnR8ivKpQR +VQRHCfaq1E544SbM55pK8yRd/l5g+c6CVc0YOnegghh3whTRGth0JqwCNa4cz9V5s8ae2BiZ9xO zx3j4ROH8KNgdgrm5xlfbntk33talUt4ok8/epzh5RZB5rWnZaEEM5mI0sMML68DtpeGCXz3CZML bWygEG0olMENvbAIGTmIGa10Ll5UzGBj2GnpoIuL4N5Q+cHeYPm5phAcCSmDB+Z5eyNMRenQq5Li kSXSg7//VdXsECnt/NoWCiavl1KeMzlqKrzI4OjSMfUuNbORsM7GKbWzcVpHRLxoNk6pnY1cDuPs 2eIQn2d85Xyk955W5TIe6bKen2d87ZxUPiiFU7p+TprGYiHc2GtmZR0xOysro3jtvJRCTDddXgjR MbKECVtYlq7qk5HCO3OfjMa64uiMhG3yILESf/9vdRbWLaYxAPzFb56bj7W9XMgzkdcx24/W+BIW gHD45YpnC8Df/1vduw3zf+7uF3UTiIX+5hrzJNwPOFL89D3hSPEjdBxelp4WfOX3JL33tCyW4EiH m/w04yu/J+m9p2WxBENuuTC+8nuy4QKqishc8/XUNBUmVL5iQpmxy0m/J11IV1gK64Bnjd56XRH8 KWhlCLTFNbsH7hEcDu0RHp6rvicxo9gA58EwUf723491osCnF0y5t8+ZLNUvGSngWZOlmsvFVLfJ Z6XDCLuryLTxfv4dthZ/O0vKwyeAlvKMgRNcONg60RDr5/cDWS1dkfXhRB/HcnFzJjgyWzcHYseT ndXz36Yuwen8ed0pgWPt97pGutVvdPOofmubXvn013XU538Nzrz1WWPqJbTQ6KmuFojmvUjGGQGw Ah0PQZTK12C8fKCCUnNAt8Yc8okeN3BMjCNuNxyaVQmCmh5uDC6lqdlcejFUW6+fJO1L7/Hr/VNd 5OkaH66ncNGXe94KJabcrOtccXqNnBNge41csVwjD/g8X4jX0gaNKldpFRNWbsDfo95wVyhR5QJg vdxw2USVg92riaUDu9dJP35BH0mUOVj7XKbjBF9vPivCa0MMQFsxbdQTqg/5XE8gJXSuD6uZSBSG 9yEhQkwSRvf4YyMnWBYNpYdjYhUxbgdHR8MwuSpEzIKDq/EHBsVe407g0GxwFVJh9rYPo/Y3fK5E 7XB4m/4GIZOIcTh2WSLKDSjOEmcIRx6n1yObTjiQXBUcnAQgWOaziKQue75W99gLjq/dA7J0fEsv 2JiHmMfjIdrSIrKW2uQjjZoyHpJp6Mi8B2PZYngm5j3yldHQ9FNG3uZmVjs42N4PtERJWL2CrE1c Pa9Di/fFOvKB1lsTV88lIzl4Ha2ShdfVVoeEZIRSdabj2+5kZBptD0TkuTCJozccopkt3BY5q5tw vIqaRdi5iOcxOlW5IyTkV8FJwlM9WD2Al2ikJKjzRYOA8YfqFxo71T+J9Y+NwKjaa0T9I8oNBUeV H34sqnIEuVPdCXf3qlpRaItcY8ktvahzPA5CayZ5UPSJxKjE33k2vIMpV18C+hLQl4C+BPQl4ENZ AvDoLdOVOdmlETYIDHIsetBnMRDRCg2ilx5sA5qlpJCFyxJ5frRa1cRDo+EizgGs5zhK+qpigxIH 2ibwwEsTppkySx2GpF0h0gBij8MvJ1pGrYZQldyqaBPpOZVmqMzA6RK9nCorG60XWcy7SHwcInE8 Fdqtm/K72WbVlSRIIk48S5WkogAd9RM/zfjKRGj03tOyWIRJcorCw+nqlKLmtadFmZTvK6hBQfWG C9ddkFG2roZFKkrjmpRftpmpSDuvSYDmAhtkIZfLD+F5kLWfrnqd+8HKTCoqNFflTwuc8hRPsIJe iV18co4nZBh+HY5J35ospX/69v7VgNZF7u7N+dNd3D1IQc+eoJem1pc/QJ83Dxhd7Vxmt/NpWAPs mKSUZ8/P5540VeJ59e29iwc4R/55PTPHI2XJ+nnBkfpzGb4m2Fuaek1yrjffPpv8DHuqRAoa9B93 v/9zfR8tyr79vl411Ib+8OVjbR8lVfv8/1Rf5rnZKd39Ek7FMaGYHnrr+Xh7qH6WSd3HmpZYO7iA Ynj3ab28RXJqz/YHynxXj+ZNHXXJBt3vBrpjIi9dx5GWyHWYcMRtuYMYagaMeAAMuPDmGksqpVG7 S8jLGD1soCdEfsQFz7757xLVxdhxiDdpPJtIMDk1vaB9yk+O9FGba7ykK+t1/ejT2CeYYmGxC7gw 4ilEIfV+wgteCltZce0cikLqfeG4k7BLqTjz79XWgBPCUsxMjylgJQ6p9/xj/Y0jqmEMUs/JZila Z8X0eAQwYEEwSt5z7FVYSSqkyJ9k5SuxV+GDvGKK/AlbV+8l9ipssipOtxykraLA0OHTFPlzwF6Q 4Kv1E7VCivw5YCdQgMVxQgtjjr+Ihojec3xGxbF5XmKvUnEcfhUrk+ir1BaJvkptlfCrSEWirxJR b3uBY+txL0n0VepFE34VetktBoHDr0b4W2KvwuiZ2KswuhJ7Fe/vTejV2glOY69O+LNEvwWbGxN7 FWxyTPDV2gvOBF+tYus0+Gpl7STYKmEJxgqnC/o4HCaY0uphgqkMDg9MY9BmRhqbByWCQfGUJwbN 027A8KvaTRgAU7sR469KF2P8TB0BiL+qA4ThN3UAMf6qDjAE76TBx9irKhkY+FMFB4OvqmBh2FAV PIy+KmKJUUdVaglMzY8mBKkvOkO4aBODdExmfnHTTAxSmq3B0uIYpIFnq8QgLcXMfeozCUFKXZoW Pa4hSKNVPDxgrJV4QFlr0YB7jRMp6g7FRHUhipHqSpAyVaUohKpqUUZFE6MI+4mNjSQWasIGwDfm U6vQUbt4/vWRf+WJcX2A7L5c9OWiLxd9uejLxd/vchFFfTwt8EmUCgQfttigyS/Qg22ALDyKdRlZ gvlN9OkxCtDiirIsaC3CdwnX9uubK/RglsLFykhNIo2wQg+6DIJCeLL6gjX0WQ3OXSFDh/wZnpwn Nor2j1/0uyz8/cvCsViqpAjwYO+dzwTqA37iRCgUoXLihR1TX/hy4NW1euv7wms7hhfwhdd2DNzh i13bg8+8tmPYD58PZmdQIa3tEYDjLUfG+J7FbDkqTrzlGDTiJ+1YKnS8g6lhOvzICz16uPuRxx3C dPiRBwcDpfjxYPZ1wUfdW0WAmX+GbqA7edqoVeyNKAQCGODF01W//EimAeQIWfEQbeH+wFtK6BfP XU5N89zlGGPEe+5yJOa4yzE8iXeHplscdzkEN/FOOx06ddBOr+EG/KCdDoMyHHg8PT7u7IC6SXPP QJBv0QYgDo51F6VhcbyQoTA580kRAWaz06s48sx1+Lg382vGDeAfMQeLM0tsFRdn1thiq8YkLNIy ylnHDa85WIQURdoX0hRpXzqF0rBwn+E2QruU0rBIl+MuRIcE87DIgOEeRsaT0rDIcMMGSIWBsrCI sOD+SYWJ0rCwrOH2S0WR0rCIqOLu7RjOvJsDcYm2sKjbymLmDDeF5xRliJEpR0xoQlJ6GZmv3A08 nSk9jUx37kVWB5TchrUFD0LSQfBG1/AQsi6iZAuiqOr4ixLD5Iaq41B0VAVO2A2iIlHyVIUW7AfW sCi4qoAhrKufVnlRsN8xJ0ajxRuVM/IWsf7uaCv6TmcBfZnoy0RfJvoy0ZeJv69lAqdeIMXdYIM0 thKhB/sspBg6jR5M/bLgCDSLByEQRUqOTd9uRu9h1Dqq5xSSdxUb5OUbkdCD6oG8WhOpVccBf/ep DuFvcNUa8A3eaG6pWPtCB86ZcXxmqjTnAD96we/y8HHIwzFPfFx0xiE+a0pAawiZ8T//NCqmEVTo JU+DIIlJ0tmncZ2tjuoXmECQNDvMYb96WlKlUJ6xMRSJefXZ/USJUt589cPb+7qoVvDVl/PfmCzm 7ns1Yvr/+3hSFAplbmRzdHJlYW0NZW5kb2JqDTM5IDAgb2JqDTw8L0NvbnRlbnRzIDQxIDAgUi9N ZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgNDAg MCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAv UGFnZT4+DWVuZG9iag00MCAwIG9iag08PC9GMTYgNSAwIFI+Pg1lbmRvYmoNNDEgMCBvYmoNPDwv RmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMjQ2Pj4Nc3RyZWFtCnicjZDBTsMwDIafIO+QY4I0 E9uJk1wnAYIbU26IA6LtGFpbMWASb0/bTVAkmJAP+eN8/x8nL8rpsVZXCvVYu7Vi0SGKblUMB7Wd FI+Cj+uTas7U7bf5IAbz+SXKEFMatSzKM2SaTg6KhMClIQHHXWmVWV0vrS7P6qL8xjM5SD/4xSma PTDN6Duz6WwEFkE2jR3DfDS9vdfl5o8M7wiy/PdGjwJ+Drd9VW9PGJD89AEuAx5H3Fl0QI7I1FYA s0Q2+81rXWm7CJAkJTFvFglCDmL6oSsQhFKYO9t+b5EhOp9NPSAEMYYsc6R676qH7vHj6/Wf679q /wplbmRzdHJlYW0NZW5kb2JqDTQyIDAgb2JqDTw8L0NvbnRlbnRzIDQ0IDAgUi9NZWRpYUJveCBb MCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgNDMgMCBSL1Byb2NT ZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAvUGFnZT4+DWVu ZG9iag00MyAwIG9iag08PC9GMTcgNSAwIFIvRjE4IDE0IDAgUj4+DWVuZG9iag00NCAwIG9iag08 PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NDA5Pj4Nc3RyZWFtCnic7V1tkxzHbf4F9x/2 466ruOm36elxlT9YiZQoiWyLZOxKyS4WfTpKcm5J+XR2nErlv2eAB0Bj9pbLOYmp2NTKH3wPdwbd DaCBbjTQ88ersKH/Pf3Hq7ih/919dZXrZhjr5nA1Dvjrlv/K9EeW///66tVPrj7vL4d9mVrI0+bh HzPFv/skjjPt56+uPnp+FRO/NP/fGPI+bUrcD2nz/HD1xTbu6jbsfrd5/s9XHz+/+uNMNYeZSJmJ DWFobX5zP5YY5z59d/36KrW2T2Xu0LgvZe5vjnXPHWU8dzaO+9QUE5obyrXup+pRaZvrK8U57zFQ oZXLPifCZdjHdAKnffGPdxiawByHPX5qzQA3Q80yRC86mTpQx2/7CAXPbJ+5fmHMGcZMyo/jP4gx w7Cf5r6NaT+mmS8xo6/At4bzRP93q48rFKWnVsaphrFtHv7hWsFrhwdUBacpgWN43KBrZcVY5LXD A6qKx7h3jQha20bc/IEeqSGEYfOfRORoXLUP69n3JbgYQu0j+J4EWcBkWA426ADxfh+CpiKgaFz9 ASTBRa+Dtavg9+cii9aYKIJ+Zkb6xHuzWW7dLMc92ROyzPxXxawcJgJsnZ++2T0Z93Uaat3+afdk npljS+P2/pvdMD+TS9u+7v/6lZnxt9OeLUUT2j//6mZ+edrPZMZpe7/ZpTZbnThun++eDNu7XdvH MU9pe3OzMcJLr3LcBBuGnAaycNzEt2/u7nex7Wto4/YbaizmUMr2zesN/TOB7ZtXmxX9jolsDxO9 n3s2za/Ofby5WXiu8wKcAul4ma0Y2ec0TrPMgG4V5UAW79aeVbzWCi3fOxyTBcyz9x1dK4ZXW4jF e4djsoCppd4EwGr6bSIl6aNogRyIDWPdfAGR3kkQsV6uI9JlNivBoQ+H1y8riXRJMw1lz2NIKEdU d4QhojyPIUGSMAIQC71+1iykyKuEMhayV+/ZLqTZ6c+MKLUvCT/dVZmnjsh3O23v/iW13VINk3/g elf28+9D3q61F3HiZU6Zh1eLNv1kFtPczrj9BbUCC/Ts+W5+YzZNZftz+lc04x74+92TGKgfefvx btrP/xbL9sW5YWvb83JYjZWj51r57OMdsT/m7U/PsjFHWkR5es/uqdeZXr37phN8/dXuSd7P7iDE 7WY3z6nZ/LbtF5H4O5vftv3din7nIRjPnv5yHnLmwf8b84HGMBvxJnzoHHn6YuYv9Yla/IdZyrOQ 83B+YNrg7Bxmjf1/EVKOhabueSGdk03CwtWRcb7ou83MKTDC/evrL2/+ctYvad9C3Fcmuv2Pm//a 7DbP/wBvZDs63b7Zfq5v8b6eDUGm5VKJA3YNhGdyhBMvubFbKzT/CSY2BLFg4UK4NMalCZ4HSjix V2tsbGcsgGdbFjfReByEBxAL+8ZQVvswvTMORTDZvNkRt+4wZ2SeLQPzOjKNbG0Jhya4UmORjCBw rIzx+gg2RGx4CBc8HpNg+jkQUYKVGEC4FsHMhyDOvPLfEaQG5kGYqIUFLvou8cxjojXjJJBYHpqI AD2Z4agdI3nNGBKQgYQmEhjJRZQFD8LY/XRMjCEA4WEYRQIjnM6MFxIIda8CGipDiADymyEkMIs3 AaN1EX8YRAINQPWKeTAI+xuvjAlH1TNmQhH+N7ZyhMF/0doZA5Y9foUEDOqPrfl3B3DBaFOfXNMD mGBd4/H1nlcwwUbFzHKjHpULwpUR0jemeYY2SN743cAFlUeb9l5cbQITVJxtEtETmFj9uh5MAbJX PZkCuKB6NIn7UDWb4r52JZwSJK86OiWMWnVafjedn3ia2XwQ4jZdJp5WfTpJ52y2TfRen4wyMJ2r M2QTpVMZbLGZ3hpslFoC4apZCkQRzI6IQLqZGdVKpeYE2q1UFSs1enUQC1fBBjN/rErdOg5gg1lP aGK3rgVsUNtbYKIGMP3rq9/85Or1bNkd9ysvKI8eJAvDM41/74R0Psgy/POLk7g4iYuTuDiJi5P4 QJ2ECeOwhGnK0D/m0RJdXzksseZ2BCDBa50zFLVvy77Qs91pLBEaGTlWtzCAqbfzNrR4V7rfEQ1t ga7NdYWsffTYPKOhouDa+T02CodjEyEm+oQJL86+OB8p49e5kNNyruTUieFo4/P35+wvCvEhKMSJ MEAOgS1X4gUBhQFijwG8IyRIxzi08JvYhR+uypDItgi+NTyMwPq84rVR6eV7hwd0BcdxgnmV5w2v jRsv3zs8oKs4jfBI+rzi9e00nJPYeDKfF+l4VsVjhYjrLBOxzq4kIquxgNM0N6KymoiwxYg4Nq0n ojzpugSeqC49iicQSOeJCuidkercOEqYZx87TxtEJz/dZTmu+WhdWDiXiuON4ok80RjnRy9+QQCx 0rcEakeJ4lFoj8+e3h6LPRPiK4nX4r4jPkzbw4PRTvvODCfyGubEcD7xg6AArcTZ/3VX5V///Wwv oTed/jx+sUAnn+ajz/7wzyxmGdaMYja2g4ziv3e0VhxS8gHhX+2eDBLa/XWhEHRLNW5fPHWB5x88 YumLrFiPQ9KuB3/ePSl8pFm2dTf+H/UCm1TuxWe/2kU5Tu1EnnGz2rv31mzlBenx4Htg/dRfLz6b 204iExeOP2LMZjdP+Jle3Z6NgGtPhmiKTWMb5DzobWPTY4n/WUN73gAoc/swTp8BfESNoGk34k95 lDwYpxgvnv6KeMaa8cnZIwjpSJyasdsx7p+oeQi8t+l+/5ezRyu50WbJk/7ozZvbXWBzWdr25uXr 2d7oJJvtzfwnn7r9bI1cYhtOysVp5sfu9HxlKArhh8xpFBKbyKMdPMNejlFjFRTXIJhc2IMwdnEI i+Qx7PXnxEiCRUiNGoMGi3iFRThoeIezkSYNFvFwCevqj1OqJg0WDcybOmmwaN7XzbBpsIhTqQhL sKiwI6uaHpA5M6rp0pIzpiiXS8JFSFKooyxqRyywNPeLcMTzeDwyI5D8BUw5YbVqvIgSSSwPiyDx qVYNF+nrQho5WWP1LQ8qAiwDLIdLez6oDDKf0teyb37YRYVQkAJWVAjgWlEZIOOj5i4DZnoWGVT+ O1cvr6wC4NFm5Hd0edekEkCiXE17ryw1qQgaWBpVBKxrNaoEsByqUSUAVa1xr1E0ejmoAJCrUIMK wPCkUbPs3kZQrRNHkLQ3jqha7xsirL3vLfVxITrbh42oWmcLB3c71xBU61zFNsY4jv1TFwiiFV1g iGZ0eSLa0eXdkAEo2oBQSVcWxFFcQmDdN6driMJ0XWya1dhDOF2JNZlQlbz/PqbFyyoCIS5TSJrW CaY90wmoPdcJKuPS+avDbj7a2Ce/ck2Ng3J16kKYvG1RoYjpEZFNFkNliZrhEombYWve6omqqE0U TTKTKZpmJlU00SyuKOroUoFIkUdsrzQ2teC95Q+dtj06UUa3Q3vE0cXFX1z8xcVfXPzFxV/8bfsL 1jnkcSogebwVcR3DEjs0piN07Zrunqdjc1EKsiF6NcAUmD30WPLGtRMLhHcF0wD6mwsk/cuwAUee kZ80A7BERQLX/eVJM3YXBuOERQf2nHBCytXh1mzStE7DnWH8UH9/UYG/ZRU4FSKIsAMUGlkeWpx8 GMZRH/5iu+cEYA44uT9/sj4Xvxayr8PAdvNwNcaJ7JPgW8NJzJg8rnDtucfitcMDqoJLE3HicYNr TyMWrx0eUFU8iGuRx4dHnnlUlHgtBjM6nqyK7wuRRV9HN+TVREh2AyqS+njWH1aYvIWG49F6IsoR r0Rj7Ur0KI4McuKhHBnWnnhUrGaGEiyI9+ub17vZv3LQ7sueH/+mh+Duzha8oPxnSP284Of393cz SaTcf7OrMuF+34n7GoCb79ZPxCFwGDm3DLUaZBXdJNNC8YBEDH1c4OriPP/a4QFRwJQl+UOeNry6 OG/x3uEhXeA4SdmXPG/4Me2Q27LRYGcho1mldkLCdZVpWFdXExHZDVx518eTVk8AJ3AQ6Ux6BBHh SNcisES16DFERBxGxMTz7LQro3nCmydebJ8tjrlZd/444NBBiiwfWWJx9jBBKSdOwWDK7lDiKVFJ fFz5ycc7Knij4wn3r2+rpTjXYp20Jk9b9KejK/oakxUduXOm1/e7mMGFm6/oMBM9vLnb7NKEKsKT FS1r40YxY/sWm1ZsohY5SmocYT70lNQ5qsBs/LwAO+PsFcZRcvJixvYtSsoeYVRkhyKQB46Ev5g5 /USKoYELFkVS85tQwi3JhIRpNRkl2ZBw0rprhvx3Boiobxm0ShnbtyhpjrOY9oC1CGQmIOGFYMDP vEuNCYvEmOG7CBOTo6TaEGY+ZHjZKMfblEUnUCotp+pf10LtxKvdmFQC0npSCcgxdHId10LHLAvJ qBKQcUeVAHaxMaoIhGdhrywtTRetjuVBRcAb6BhUApBYmFQC2H6HSSTA4g6TygCb97CsFM+hqQyw 9w9NhQBNC02EgMVxkFCBKmqQBQThxhAyyLBWQVY6Dtvv4+L1BW3sl6xpnhyuZ5Rj6TrOuUxuYJOy AQMvnNtkbClB+QCulQB1UK6WCHVQppe4r04mJfVNAmBOTqIliUJA4CUvFaJkVQgoTMlQCPxYoA2q aQXexjSxwA+aohYu9jY9LgMmsKi5/KqTQF/WSaLEdRJp4zrJtGcyB7XjOkV1YDqDZdw6wZUtagCU a2IchKdqOpTlalpUJGp6RGRmmkSiZrkg8G7YJr16IunvC7MIdepmE9omJrV5Ywsl7cYYShzbfhk4 MtYn7HmXVt1ZIBWV/K6z49HHDRe3cXEbF7dxcRsXt/G37jampJI5HGGHaLe7QNf9WRLb2wBnorvm zfkwpuGZI1mAJm0kPjv0BlHtIf0d6zFI/b2O9TUMyoNr7wiT94t8uGWTf4no0WvnA2EbDg9thRps 130x4GNaisXEJKOXeTNAH9y8KY4d/dzhPbn/i0J8CAqxUAeOPsfqrXFtaq0pCFSb2mriRUdgm+CG 2g2m06ReS+/GeYClJgYPG4BFAiY04FGKgHXEAhBouiq+oSoHPP6xjvjUNRkl4iI2Sjh410lTHFjp W79AKuzGFadNZUQjSE4/XNHFPLxGkTQFXNQjkEAFkquFBAU6qBMs1Y63SkqqISlojOvTjqCUCdnT hkeUaaHQs42o7+LKyQ5q4YaRsBIk9cLGgEwNGyKgatiPdeSnKhta2KR5nuT0GNVZt68sFTsLXvQe CPYFsdycZAtmwqn1BXWpvKnR5TbBodpqnKDfCJQBuzFdyRPOtRtrwswN8ZFlECnCMRTMoCBZMHKO RXhMgis8RWmC8XMCMeRUhSqAtw2SnkOYeSDpO2VAAl2Q7B7CzIdBq72QQReQHFQGTgUzxRyK1pPk 5HHWmjQ8blCIiU5oW5LWZH2RtCfrq2RF2Vgka8oGiqQqZUNSGQiXospAuBhVBmByPBJB3CcvoaAy EAkGlYFIWA5dTQOCCEEVJJjypGkSGUC3CA+qa0NiDBlUAAgASpumtpff+HhshpBAx/g5oxTV3kYN ZiddMMGtadrKuJ4hOiK9HpQFMiSOrPQRD8oBcKRKbZFyrMpmWBhaZf2i/K6yflFxiE8zcdXmZCme UyVdZfOrilAnkbzMVdn8qh5V2fyqno1haZpk86ta2q0xlFp/V6Ufw97NCCWuE6ZOUDudUNI3nW+1 QWd1PurIFKTiZrLyRCe6OHMzBNUvIMFyXTM6gaiRqRKtUCMk8lQbVS3WERe6oCZOQiVmAREp6wbS Ai3C9KwRCDGwHKeRgIPtEh2zQ4NRhminbkGy/X6rv5v+Pzq4eHECFydwcQIXJ3BxAn9dTiBXZf6B sUEF7AAW4PqqQ9oKHYNs6FqniEW01c8AP0TFot/XbMBC8wYO5RPS0tuQvOuxIYxM6TJCHymfaGoP fF3vo0My5QNSU93b6ki9TXiXkRb+iGiUBQr77u3k7OjRwvfkzy868YHoxLtzN1PA9SIjyeZwNeI6 MMG3hotcA6XPK16dRrx47/CAruAml0/J4wpXJ/j61w7HRAVqRZA8rPAxbVBKnR9J7QNZlzELGr6f 1bq5moLIjeenDkY8+boM4i5rpqH8eQwN5YbXn9rV5zE0IAgloWJ5d/IwPuARq7+Eukqe781f7r/e PQlAyacPf3s2fXhkR9ppbp+cibjWkZdRvge3ll/cM43d5d8rPwWQRuIlUguOEx3v3tzv6CiTbpu4 ud7pBQ79Xv/FlwJevOPzANyQu0L827ubVzd3N6+vd3TYShmSNysIuHu7+wUJb15++eL3L293STrz EkTpx+3N2UxPUJ2CfbTgNzfzoCjUT3ezf0WxSGRMfn3vgpHDhKg6vs5iM0Mwpn2z32uy0DqbBkP8 MRfBAy3+usWgqC3PEMniP4a1N8RPO2xQdJ4Q2yBDhZvF4lg/XWNDEFtvQ8x2hxXPsx/x0NdFHwZU MOqHYIYm3/iR9fMgFYxZ1tcDrsQkrDDjcTZNQ5Pv48jqfZASxiyL+4EvSyNY8DpW5xlbgwFXeeYs G4cBFYxZ9hUDbgIlXJrggsdTEUz7lIx3kcSTZUcz4ApSwkMSTJuULBuigW8wJYgCBalgzNhODfKV iVw055+zj/RDSYPUTWVZQw5S9msikor0jK2d+zlX/7rsDJV6UhkE/dBSXfQt7YvreVIRyMCiikAG HlUEwpioMhCuyceFlKlBZSBMDyoEyCSoDERkQWUgEg1d2mlSEUAZ0qQigLKkSUUAZUqTygC6ltre q2KShbmqamoiBGhyknXpgNtXc5Lb2wy738fF6wva2P9a09jZ957x7rl3HDv7PjBsvm3gk8zgIIB1 QTk2iQVSjuL6qc5wvo21ywPXrZq4cKFglybf3NiFjTseuzJMSBAyZZmQP6SqNCG9yDRtQvqRaeKE 9CRT1AlH8qrXEz4qZYaJj477rFBqOmum4maU9kQm3MR3sPb5qAPR6Yr7M/t0Vj7odMcttGILhIVq Jyax62pHVAJqZ/g4sVshlZ4aKURSug2D8LuJQyilm0DoTjeRiKaYBV1YV/lAm1lf6Gz/apnEJ5zN 5zXmIGXp9rWzbnDEGuL3tLzi8eImLm7i4iYubuLiJj54NwGzPcnnLBk7RE5gga79s4sfAfqG49o3 v3A2mczTEVAvgiZwWY43f7LRIcdzGtiLHTtEozKiMXHnMN3HB44w9851lOzZ6+71YAsOD23DCfvd jN1OLs5LetinxfE0cRu5z9+fu78oxIegEI9bssn9VViy8b2yap/YTcp1V/CidSO3YZmTldvO4JQb HhcHzk46mcem49vRFlFZ73MfdDHQ72zXxYFchYa1A9+moosouYpFTX7Db1mXKWPdyAVhwHRoPSrH sazBRWlY9Ax1I9eN2ZpIriPDEqrR4+q58BHHUR0bruvC5WY2zeTiM/ezulEs0OSKFUdd10z4OuNo aybpnK2Z+Dx+tDWTDM3WTDiPH4MypdqKCYfx1RYWYGi1hQdOWaqtSyCPqssWnMZXW9VAnNWWPHwa X21FBFWotmLCd3Tp0quuSNXmF6/OCEfVO75nuPYpQEyotfs2EmCte7ccIxjrEjtP6N5unnQDW6zp BrZY1xrYoh3HlwX6uCZlS1D/v2AL+//ONSwPjKlYPXSe8+KiiwQLjy4yLEy6SLFwEWFjVdM1Aaue rilYFHVFmorTMiynTAmx2uo6OukXh6szQV3FsZSzGaDE3Mov+fmjPTELlqGzOv90JLoSTHs/eYUJ NrmxiO2THzw0w4AlsNkNEYCZFaygu9UR+XWrZF+dGL38DSRv7qA63Rw28MHM5cKUjmCCWlqo7Gjl J8vVmfDavLo9+MDc9Knhj+cuHuHiES4e4eIRLh7hQ/IIsNDYZYks3oqm1Ldngg1xBMfoMrr2HVh4 FuBjpE4DzfBuSijd2g1T0o4i9GGBrq8cpv4/QEUHrpu0VIcjzzf4/nWU7Nm+SYNBODywD9iSLQbQ jOUL2fRooaE+F2yqFMeNBzv2H+rbLyrxYajEqVSOyMZmSLTyWV1ZdupGLSy8Ij5D+YgaNacCnC8V TG6c3hBUqnNfg2grD8qQCFFwjOKphFBM4pw0MesYR/F8+nzHrFiCKxKDCc1G2qGRczKAbR7ZIJw4 qpPlUV7Ij3DsJzUIRyR8cfTjvjVXi9yHrVd/Jrn0Vq8pFVwko1WfV7z+zlX/3uEBXcFWQSDPG15/ H6p/7/CArmL17Pq84vXtgOV9PHxfsg5n5SWjWCj3vsa96+pKGiY/vkvBjWf91a1O6EzEMekx97+K Epom4Qbpx90hC45AGsYRFc6KW1chhao3En/2klIl+c7VtL2/3mXJ2Pv6bJLeJLopZM5nSk5Ir7aH nz7vk08D66hGmaUTp0WxkKaGASOlTEpVFIh7F6hXZCghvUOlliI/LyC+AGwPd8g1+gQJlKJXVjjE 10so1oIZ679tFmR8go+z9n5s414bxtEKmYpDiEGr+IoGYlqvt9Hj9GB7EamQsY1K1jI+O6ovrtpH TvKDhhXG1MuENAsg2AYq9RIjzSAIFtSR2kUN6kQt4Rtc7MOy9TV9IViyxOSqEjQwo9VSEnixYio9 eQm5n5C5mj09ITKByGc9goZ1lkV6w2hFepOnZlEeK9KzKE9MVmOmeRtagmYjcVEeKdIrzXPCwjwo 8gydiVYapyGgqQd6elmdRoEmi/JYcYYPAk0W5ZEqPYvySJWeC/NwlZ6FQ1Clp8ESBIEmF+ahcMdk sRaOAk0uykM7+UnDNgarYv4WY/UnZY6YuGl3ijck1xfst3tPm1YrBr9Z7yNtR5zgvb7xadJqRUvr mDybEfYxEUiUwUQkeQSQn6RtmGwlAcFkL3kbphuSwBBcXkfrmiXpD6Z4krdhijkVp7SStREscOMN krzoojbJTx9p1oI20qsetOklQm5QFrXxZU6OI6UHymqvXZTEim43rJQxOXE4o6OljKOL4anB0jrG HrWRUsbis3u6MbRSRgvcuPuR5Ly2W1orZZTbaiyOU7QwNFaJtEuNo9kT7x+OJsP3COxfPMLFI1w8 wsUjXDzCX69HGM1eHI6wJkweIQ3NLrC9SUJbgOvefFv4FcGaKHsKXbNFU0q3C9T/5niuA/0tie6+ DVxf6anfZMd2HrvJLkimetS8K3u6NXd0bcbgHda6Le8csLEr1olwemL4sP77cOwXdfgA1OH8tz5U Rmyx3nU/oVzGgYt1Fw8vo1UN71DEg8Y5ZB4uvsS9m33p/B9X11IhaN3+6Y6+pRG2N5vh5U/pcyV5 /q9sN08//WgRvTKqETerdLLLwFV/DjeP+OY//cUnuzSPdftLIx35cYrKnep6ZNNNbfx2e7IR/iZi f+yL7dNdxBC2N3/eFTfY726+/O1u/aeJ8shrmiGxDhyuSuEVhOBbxfTxKjb48rzhtRHr5XuHB3QV Z7nKWZ9XvDaSvHzv8ICu4pgwPn1e8fp2eG24GE/tw1kVn1Uavq+1d3UlDZMfTX0bTtyvJuFE3hzH HkNCRrLQotqV6FHcgCSMGyoYohEWk+j4A3qNF7P0RR0tUv90VyVC/dp/oGi2BAF18a/4Az9UIf6S bMT1rkhN+tli9oK7+ntLZ0PaufGyuEyT1b73kn/35bKbuY9J+/jNjkwlVbH3Lva3bu7W3Q+QG5sm ucXp3NeF7l69vCau8DeFzhfdK1FchHJM9MsbIltQge9uGHj1DT0jI7376ZoGcKE6N/BspjkvkaeY Pc3Xs2GfTfr8X9xudllkevKLSKeaIfo8Y3F7wDacE2KpuM213zXw7hPlhF1ACeTP5rmJRHbA2yvJ zgdEHj/9bZVBBCpdEyOw9teISpUYvs74B3jCmtueN5ygE5PeBABQigOJm2UUjuhEuXpWB6dYg/Y/ wkGf0Bf9eDFqGRaLmL4SeMetJUH3k4vXg3/93JJL0lto4bAg8L9bStlNCmVuZHN0cmVhbQ1lbmRv YmoNNDUgMCBvYmoNPDwvQ29udGVudHMgNDcgMCBSL01lZGlhQm94IFswIDAgNzkyIDYxMl0vUGFy ZW50IDQ4IDAgUi9SZXNvdXJjZXMgPDwvRm9udCA0NiAwIFIvUHJvY1NldCBbL1BERiAvVGV4dCAv SW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTQ2IDAgb2JqDTw8 L0YxOSA1IDAgUi9GMjAgMTQgMCBSPj4NZW5kb2JqDTQ3IDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVE ZWNvZGUvTGVuZ3RoIDEwNTgwPj4Nc3RyZWFtCnic7V3rrhzHcX6C8w77c9cwN9M9PT09BvKDtqXE gW3JFGMnEAxCPqIsB2elhKKdBEHePVNVX11md7lnlqKNUFwLxtmP09eq6qq+VFf/x123of+e/cNd 2tB/r/5419fNMNbN4W4c5NcD/+rpR4+/X9999aO733jmbl+m1vXT5vTHXOLffZymueznX9399Pld ypxp/jN2/T5vStoPefP8cPf5Nu3q/P/fb57/091Hz+/+Yy516obW5gwnP767/+Yu12Ff2yaNeT9Q e/ux35ei+MFw3/YTYU2vGJ2gesapdmPbnP6I9Ui+w0m5wFPbF68FKNSxpi+c63BUItA4p/DygdaW nzb/Rklq13XD5j+5kLzs0ZS9R5+9dZGhA1PWDrxtcczcft9Rid7tWXLerkiTDxTpdH3rIkHHKIFT dgl8+yKZvVYgmP2ZDbkz+f7u49z5IEvURR5n/Kvv8r7OXR8a/eHB9tuX3+zmoVeHnLdf7p7UfRlb Hrff7p4M+PnKhuKZEvNU96luUhmIhlzi09evX81Ftly7afunXd23Og3j9g9e+J/95+uX360f6VO3 KWPHkpVaxe8H+Z0Has4Dp9Hfa0e25zksCyOQhmHP2m9OZb/XjjfPc1gWRqCVfUaT9efacttE2jI2 el+at3uVwEkZsXlUhrVwVRngSGtzAdSN/oq8ykLOzPS4Jjco4OLABIBEXFGCUN5KUEZQCWfEPeV+ 38qmDJyYxf3ZPFTG/SzitS4F2+R6afeOSpzHz6xrywwSzN+zT3bTvp9L6bf/vHuSuv2sqabt813b z39T2X40f5ZfLy6NTCm4n0bSHFzwpzSmJeczKmQeoG3cfvzRLuV9TuPiX39NnaKK8/Zn3Ahuj1f9 k938ue9K2W5WNGKm6ohG/GL3pEEjfPN6l3rp3cs/7p5o1S9fbXaZeJPG7edprmfWTaltfx/0hM1N dCJiMxOfrHx9l6bC2q6lWZMeGBLqxLilSZT0jMcMTJZmxjNrBctnFog0Zco3YwAaK+OE0TzjXBgP UlaiD4RzA6axNmPRK5NI0ziTguE8ChgNFbDPjPsM3Mn3jpPPkkuFjySKAnvBolkaDSmCvWKiwozZ vhEmjT1WSkZ4FGNVKZlgNo91r1C+JugtIleaTdGUgZkSbJYXWD8T1QxKYQUsmCEb9wIWaFMKWNBo 4kBQWKA90V6nzFYcChVU6MGCGTex8rlFIvbKgo6oTTY6siArCxJlI9znyMAMFnAzExig3E97FYZR PveKmQYJDJgw/+jAAAjejIUBs5wyg2DdRGxnJAyYeJ6S6gQGAMfvMfMgVLCyq4iW1V2FCta2UQTT 2j4KHbRro8i19bxFmjRhvdGsCR2MphMmSQ3IZ2GCp+z8yl0nVAA/Cdfi/CbMYs6T7S4J8yEphKvL Ue6y8B5yRrgPckjYZTZ3vfQZIu1fJ808VB8RVriMF6q6FR9O1jQMN8LMLwxH6xeGK+Hig1mpomN9 xjWqAtC0OclZ1EyTgCWqZ5qqKdB8PFJTo6qpYSENpubqvpkKFEly/ViZDK4+WQ5duw5MBte+hdnH upmU9e9+dPfNrNkD8UuB0g7pSJ9wD/izF6OjAfOn39xsxM1G3GzEzUbcbMQP1EYMGbw4MBxVfwQw S84S3cekM4VOEUqd0b0Nmrn2hakRHOzGCbqXpX5QdwrO/Fykp6KadsV/3ZuZqpM3xnGwgoxs9HPh buRk/B9O9cEjClopYXxCbzsdKr2IgI8NQC5ttskwye/GuN8E4L0UgCtnZP1QsTMkpo4wzBPPyQgr LJI86ZSNvurcQwwt4dp8VkYYdJSPYUbWDzr1EANPeNTvtIk66NRDpgeEs04XeipO5x6NEoe5R2Vo U4+UGWedxrTGuNN5DOWGIZT5GMEhTIoI9zopKpK8U/7RvsugNlhmZISV3bkw7Ovyc8oxe+fTPy6+ 8+kfV6/7r2idSRO3vejsA10rkwqXdL2oKAtlyrQPc7K+NGWCELU0ZYIQvTRlgjClNGWCMM0+EkfL aHNwBoOKBolCGdWyiaiUUS0fS1Kpe52BEQ1KVbMpYliqmlUR01LV6g7Sy2Ffl7DppKs/St5KLI4/ hOqqdFtbQ39DU0fp9Lgw0qGrLRKBSaUUatJpIx/TPZB3km4b+ZmLxh5MwZR7MjMx1mICZqzHxMZE Q+ZgJjiYF6lcYQpmYodZlYkl9IyJLcyLiXX4XmN2DAorHoPGaseg0sZhzGnbMSS1azpg0fNhOTX1 8Q66mToAXYdIdFckwhRXNMIxV0QtainhtSkxEQVXcCwprv9Ejlw/ipy5+hQ5NO0qYurKV8R4wEz1 eN0O2ptpt4QnKgffy+L88mYlblbiZiVuVuJmJX64VmLIyhtbuYE3b0Rz2fd3SxxQ3VixBO69et3N VFvE2ydmOY5RyliIBQWI3/qrX/z01ClvTn5yF23hRkPaDB8wJXUzyMiGPxf/dUzdii/cXEHIQi2q 7NKCSnZG2LYhrCbGCmT/dKzAKi9X7t/TvN8E4L0UgHNuP2X+1XMb+FS/243bPbkMyMl++PmjcGxv UsSqeuZ+30lrVHX30JaMcw9Vyv9oSKUBuA7Y+0VZFS4weWjHoMZkCuQ3/SJFXNn5JaAhc11Q02oy tN1mI2x0tLLxDY8Pq79nxKQkGaQ02yJB2abd5vm/rfTq5DYMFRqnH3liAvxguOgeFNIrXu/VGfMd TsoFLrMh7UM9htd7dsZ8h5NyFfcJ/EV6xavrGXgKEfrDswLrzyrXKBQSGsuFWGPXFeIcbOK6aT1a 76QW2N5KINtVhShNXJaEJipLV9FEGOI0UQZRIRedL8lVkhgxmqfkr77YPenE9zJvX9/verhUfX3J parPPCnzcrZPdFCdTc3nNiH1s+eaPJkP6UUPtVzZUA6ZlxHLIs4lH/kENiS/1L48U9eTziR5SiQZ W66pBJ+34IP2j2RbyrxOmbYvPv5kN/8z0+zZr35iVHPn2AvdSb1Zr5/vKhXSD9vPnu/mVOwM9+OL bq9NJCoU8tmzn5Frm3j//Xg3wf5t5j6wW9vZSl5Qrkv1oLFyALia9p78Udpb0nW0vySYiRcJKyvv Ey9tYv1e5b/ar08v1tiz+YplRA/Fx+lamg2LV68v0nWepcXUF8k68kZHSP3Fl1++evnddxepwef/ K2sgSs962FN/vv3qi8OfZj7Ns7dZ1B7ImVJUyX9vdqWxitn+/UVPTaWIHI9zmf9Dg4sdwzdcNJUY /TeDP+lfdk8Ke2yWbdmdFf9H89Xz+X716S5huP9yHkHT3JV++9mPyWeVfGQvu59qp2oyBRPa4bJy 7tcLGg5ZhkMcA5f7Fvxmz3nsPvv4KXVeerFwrL0k5pVdXrwX2//1aVTueIVfcpIz1dzzTgTwA+Om MPc8vSdEB56OJpn2CZ6wm6RFTVhrqAE/wdhfsvQBk5gKJjSrh8I7DQEMMrsVLE3xonLGHg86mffL +fWH2/e12+SiKfKoJ+7cfsJ6sEtFV90k4tUi4TGsmwljh4ncjAjm4IQ0443sdFa5gjAqLoWx7aNO crUi7qP6VQtxkCq57NV5in6bp9Ug2DytcmPcuWNWEd982/wlrHvDnXzudY+dadDrPjZ7hRGBW9h5 JlyDS5kyAPvYxi7Zx4ZY2T62yaCVlmzjmjKri4u2pfN9a+ZXtzg8IGz71iy2XSBDMtcb3scmrCRn YPQuktjoTfRPzTauBQ2Re8mchngfm3CnkkBESOZzxPsKhMP2D8FeBauX5CnIXdLdI9leJGweaIN8 T3WJdR+bF5eWfBQ6WHGyRvDaFk1pQgdtaRMyBOepRT+nIzpMSochbGwrFeGoZUTG9q8xAY5exiHZ PDYGwk1MuIuNZ2O9uJiZZGCnxiQHW2AmWdgfU7kjLZJLUI1dkRtDSffcTZVOOX43JeQDworOvmmU mw8oa1qvO+w5jkfrWK+7CUnGQPEd9uqDHTvqpgyUplAUsqNuakQZ4mpmUrVkO+xQS3bMMbkOE2Fw BSdLPNd/LSrHUQhefYedqaCqte6bKt7FFngk9MFkWxPCv9XVy9FYeIuT0psJuJmAmwm4mYCbCfj/ YgLoENZXLd0g7ZGFyZuQLFMW2FCmDmuxDO5D7Qs7IvgUwURMcgYGG5TVVWMUCjI2lORuTET3dwGz k+sxmqzn92aa0nBk68RB9gQ1TXof7BprhIN2V/WDamjrgWnscN4dGYX+q+CPebMYKGMgRzwWfSfG /CYSPwyROLcDBXPQ07TpuhOwAUoRV9yrnMbpFXeFBR4cmlrx2vOvZb7DSbmKVbtq+jMxFlb1RkMW HJcL3JOy9moUXlOLt15qiVRZddKjhcSmxi6vLgTcY0+H0KH1YUYCz7mQQKT1hWh3ghyZWF1XhHDD ilDmvCFWwtDRjIjOx2YzexKAwIMcnNsnDVuj/jlss1JuCTASNlxffEq/v2eAA/dWKHKNbMiIjlPo uCLDo62U+JHQkBmRVnBUyAMEuG/ie0Xl0G+edJXEk7JTDKcuSewgfCREvh4SXMGQ3BcBRBsetPH0 y7q18d3ED6mv65bNpROftgnn6ITJ/2LC5Lt04kkzYW5OmCH/Fq/Phkk9YXLra5jzF454RVBa2WWJ koElA2HunqwoCDIlsOAonbirNixICDPJsWAhTKcGDeuZQrNlhhWI/BkbFkOEO/nMKkUGdd+wkCLY C+aJfz+Jm24To0qQqNAwoSFMniMN5hvhR4zlhCESpQC7tNhXOC1abng0WumQEasdHpHWuBJbDl9K 7VivPEC/e2UC6NIrE4Rqeb+gaXYeMM2z84B5kpUH4FlSHoClCUwAx5MyQQQCLqomL/DKMnmC3xBk rYkGV0ls8I9VSR3hPquSPMK9ljBp7xHutwHjO099Qn5xBvXyR6GFVi+upN64UUhhjW+xZ03pgI6L D6vRZQIdQDVxf3WqTkIHpXoSPyXjShI/JWVaEvcqY2lKKhHC8pQWEpGySoSM2iSev9KUlPfNJY0c m7qorRLUHiRVHZ9UkoPqW3zGMLDsphlRPIaR1o5RZi2TQWgNxxjVfmEIW7cxwo0sqgGUalAQStTR mTAt1AuYYupHeGbaCRxV5QWGm25rUfFBVEwvQpRMb4qkQamKGLrCFTF1hSxiPJkDGJbbC9qLIq+e bKmB8FGHxtWbrTercbMaN6txsxo3q/FDsBq+4jhEzPH6ziKsRyIMgE8RIrqP1U81Noe27NVSxd+c 7n5WSwisZxoxYkKjKsgFkJxj1pZbvmM0ZrROVEC0jbIK1OG/RNNeduI8Z20wg1FZnFPoUOFjXnLF uFQDTDFtCgX51uz3t/o3GXifZeDcbYSeSiBP+Kk+dm3lm4tuhd0o13w0tqbv6i49wJtkapvK52RD z8qVq/54Nzdm/t9IIXK3f9w9qds/v6J4mN325Wb4w092T/p9P/+vbDfPdonTjttv//x6lxMlWTTv uJrEJ19czavdk8I1/OF8DrFqnmPpd+rJSC/HcqnIb76a27v99nzBSY5THy05yRFhSHf49suXD+fT Soiqx8uUuEuxvX/ZjSBntva6//sZIhZxZgARJ2R++ZddCWz77uWXZ5zOL3vTyz2e0Ier78Tkhstg MKrAZmQpdHQJToqGr7wTg3yHk3IVd0f1dKf1rOpPd1RPt6zH4kUhveEr78Qs+kNnZfWaUwEtpDsq pLuqEOVglYs13qO1JRjPUYLT6NqORCmijqgUXVMIWGGFGGtW3YahS28jn6CtjKR89oIL23kv55Hr MDRdjZV+QZqXIparH/o1EcvX3JvJgx+AXBHa+V2cZay6CtFXdm2IzfyT3x+4EKP5cb/73PP0nst0 530/uwmNfUpdkO+e8sUns9Y+Oebx735NJIajtqsKP/3224fdLLUE2vblFxdtej+ym5U3efv5JTmS gPyxg/Rqxe/P2JbLowCEyrzYhoz883M6J5O7QkEinv5s1yNQPyXY/mKmg/T5txevD2gdKYy0N9Xx i3kYSJm/pmHApP+MZF/YzvU+/eVMbMG/nHMKK7yMn8d4/kYFuPDkaZDZIK6UAttVWGAYSUKlRJT9 Jix57GfNWsW/X1yooGNPsIZo0PQBG8TVV7k5YIBrsnux0hAvaLKQkWhnsSuookpvVFg/O8Kqrao2 D7Ojtf6usmnWYQuWo7l05kwpO25dcKbMnHhjnpV5MmdKUQmTOVPyZh/hrF6iTdJ36udJyeFOKV6f BAf1N2Heqh8hO40S7NRplKlqEXvZTYaw+tuQEEwWsZeXaYQtGM+Y2arGgAywsoxxAZV+syccnu4Q nEXq4M5KfnUmlASHqmIouGvGf/tsAXslt8XrReEWrxeVW8BezhubbLGQ0CULhoQuWzAkkMSCIYFi i2hIBI3+haGRv0nqbsEuC4YkzNS4CmC1xbeAKFhMXIiKxV2AKFlM3SRU0JC7LIYE4d2a+UqpBaMi g9w0EpK46RIuZYmr++2G7L2QxcoWU2VVFyFLiCRcS2x5EbpYz9g0hZ4PkS7itutUE7cpp6rceDKi 4zqU8UQcKI1l4rXrHBXnS+e4OO66RIjnpksMe+5CmsTr0+VM3HZNDsVpNGgt02LwnQ3a1jxObQxo bgv/aypxyrFy816WSbsOQG23eS+35eDVfgfvZR/5SjP1Xh5FskbnQAtqRTzmXOsow8zLexDBVh9w cNtcxAchg7mQQ1pMJZb9QmPKkQPUqZxHuK7l4wpXxXKa0R3vvC5If1Bxt3TH6udodLzF/YibvbjZ i5u9uNmLm714b+1FX5U1h4iJaHyV5AhgCRWQZULY8Iju3QalaHMEmv04AeT53gu1TBVGHFBegpCz yIsib0BjRuugABb6QOL86+hfIj2kWSoPs7auLFqRARqUeR9Wd8E6G5dgTW3YtKDejwdGvEvxDsz+ TRp+ANJwbl8g9bxvyxb+ykOTwe5+HXDua1fBcAw84T4Xh01TsPqwxDMdjgsE7GP5/Wn5j7YfmQ7H BQJ2GhOOkipYX75EBo1dqIEOK48DpJD+qJD+ukL4bh0NWnRk/XULZWx1Il2VHx1YCEq8NHgVFbpl IcaSRw9FyBCKHw5v037jpw4v/+v11xSdibdkc3ye9d8vR0jim8la5OWzkYK7w1b/gx2F+KHIdzs9 onl9edOZ/Q7Yp0rCY/ku8qcUV4i3luOFj4avvq0dNppf/HpXsB3tef5lN+LMhvelX/zjJ+sOZhBh 0Ro3N+gCVSRUZujJyqcvQYE6KTU9AFi4yPIZBw3r4vnHs5/vBvT1cgwyqYBj8F6o4KmLSij5xe/m NHQisDyAisHVPtrZAdSzT3Za3rM1bSr9Xh8z9VOqs0dToaW//YjCovGzn5twhmDPT9meOR5Hsj1z PJ5ke+b++kuvTzxNGkJzhnbJGAXZrWI8NX2CcWdZkyuUt6UYYg8cr8Ma4orudYfcn5LSHljgZvSw 2LE2a5sPt+ePnYHLtR5Zoh7uhiaLClmwAhXcTNe0itea9WW+w3GxAuVlMSQVsNbshkyHRWn43cPh CskArymdVnmx9a1589e5Gox4rql4CdLG1dlH2+M4eFfaFXMC523gwnVFKC2CtDTfWrmKEswFpwWY 8qhZL7J09enr59unX/IZOx9oh2fXX816Vv7x5XekDWFyL2jcIcvWgU+NL9n4QcKcxZZ8xWqZFDS7 Qhxm1SwPLrvN93nAf19sSk3LSfqllhR2wOGNGfhYac/D3Ga1F8iQaMrn5V0mQpbNt1D7X88LpMhr dqnyBqDw3m39vR2gv577T54KQ/S++Pabn+woxInEYAxXU+EEJIe7dF2TKa9nvQSbfS6FN9cI0QzX UZYLm4KTxNJASQmxM3QMn2BE5tDkAfaGCdGKPrFZCUjqXZ5faxfsqgR6CGwXVT/Qnp+TrIE3ynI+ WhGfS8ohYMjF59TncOXFJnHnJAPCL8ghmE4uSe8a8N4jYdxFEPeukvSuQt0LlNS88ZmLujxLQIes QaoJy2f19WX9WdSJXzyoKQi9XZLIvbr/yy0JwoPemqD9z16vD8gtCcKd39EgT562sUsScOyxWxKE cXlEmKXXGuSWRO712kNC8Ha/FcFOFuHSRJLkSW9BsBuRXrpQ3uudDP9eYna70YHi7cIHarcLIWid XRiRxut1EnTNbpug6+ZULYQJl1XcQyPQtUSi2y0YMMVuyQjHTObB0d4u2TDDe72Cgxmt3dARcent Bk/dW1BNl7VeLwBBFntcD4Ko9np7SCI5YRobsN42kshOIf2kjrsKc4u1TdJ1bc08EfCWSqwm74nE arKOyrg0Knik0qyfpxyoiKguRmUJxwQWSCwm5484Vjv/MF9X7soc3bkvwZZMODi2kkuOxL5wyZJ9 EZe8jIcEVDIlfpIJroRPcrn2z63F7DoutHgdN1o9hhUap4NOm66DUrumYxY91yGthMGIV7qpPlCi qr5Qoqs+UaaovgHTRBkJQ01Rgd2myCAOpudIVlwJiiCZjhQ5cw0qYugaVsTUNbCIcbGQNHqTaUH8 wx0im1nCE6WD7zo+rr8Ee7MVN1txsxU3W3GzFe+jrRiz8uZwhBHoUDgVQOVrjAscMrZ2hO5j/dHi lKwRRGE+lkguS7LLRlSCXosByhdBzBc/UZ8iuDfb1eu9dMdlEyyjBQRFyvtg90Q5HE6VRSdbNbHx wCkqm2gnWwnYR8LxwFFDrZdf343Jv8nDD0Ae3nx/Fe99PbZ5AN1Id1ROXPIfi1/Xs77se/hWjohY 0EOnAZvjEtIbXrtZv8x3OClXcRU1rskB126qL7IdjgtVSG+ihjoAr6mjxI6UhWfXuqiBUoY1U4pA M1eXwHxLvN9tfUHg0FVlGK+lDCPPNWVIT4L4yO0QFZ9rqMF8cGqALY9u3Vd+yJUe3PGLz9gYvnjw XiubYst4cUO61rKs5PtthtepW1sxv6HbU+CYv/Y+eC0cOScPxa7Af/998GHC9HuQ+Ls1iXeiTjWr PEkFXOXZJOjLgFhfK1aPMi2rIQqiDoITPGldSB9wVUigr+pIFVCRqgWrObZuYNRbN10tsuR/4N1/ dOCPbvFp5GNphloUd1hQIbnC9aYnZDuclAqcGgKnS3KD681CyHY4KVVxzbKWQHKF62uRaWPszBBo slLfciGLtg6hyysLEd7BDGp/wlOLK+zPpOtAmFLQ6JpClCJRiIbsQnQVRYQdThFlzwojJHs1Odup rR/T/rsr44fgpXXJPozi1WnFXbYRoyiRUPn3M09jJ3cbVlY/iEPu9Dc4q62F7zqk2vyc/p3ZqAzu 1ySXFrKO1dRwjEd/CBUmjv9kt7z7O2DcDXjQgnBRwQb9MYSrhKUOeLDvhMjBQS4aGDIFLXcGpCUP 3oUkesG6mEx3LuzTB9j1dTvlg5jHnLmSA2Nal2e8IjewZ3bOdS8+R3LtI+ONOsJMpSp7V0MT0Eli NBRRPQhzR+RFdoKkHTNeJR+a3PvIA2yuxBfJuai/k9jkXETxEa4MFSVJnaQ08bHJvTAEXjy5l+0o grRNlnvErm/8gXAGLCIWk5Qm7jOiMARDf5UG7GLEmKWIfrGyN+7JFxgAy5Zk886KVdZqtR2oj1Z1 Sn00ulPqo1OdMoD7nCalv5AkIb49KJYmpT/TM01KfiF3akp+YUdqSn5hV2r7EriZmtJfmJ1Gpb8I QxqVAfIR1BcxSiOoL1KWqlKfZTBVJb6IaMKDKAP7UWWpVn+DD3JnLCSFH4QWNcFnQmuSW2HWkAn+ GdpOuQXmneBbYN5HufXlNJBbX0aiqQTyyS0vJ69cSHDy44KIcQcXQZR5iM9gvJV7W856vrflkiH3 tFxyZDVvgsU3s4JGkV0eE8sJ2y8qtq5xRKb1e46ZdSigbB0pWrOOJG2ZjjQ0HONQu6XDFN22YQyq 2CgH1UwLgKqqJEB0UyFTCfoF3DL9A26afhJmq/aCKJhyg6iY8oMkmWaEpJnmhCSqYoWgmtoVORat HHbHl6Q/cDom0Kga5Ejd4PvbPdx2Mw4343AzDjfjcDMO741xaMoZsg2y/SCceSPi5c0SG6KEUmbm RFovOG22h/MskFuOgbOqplO1J8vvjf2Uehfo/i7gYZEWCLqTfWm1xjQcWb5B+nuMiia9D4ZOVMPh RFO0hFVjBDYAlCpmE9FzW571eXM6Xnwf8TfvyLDfJOB9lYBrJ2Tq16bWTs9jYQzV6UJtpTplqCmF zwabWfXnUBuszh5qo9UZRG24OouoiWdHErX/6mWi8wP1QsH0QZ1UdHahTiw6+YCPC6Ym6gGjMxd1 kNGZjTrQ6MxHHWx0YgT3G503qXeOzqtsb7+F03uVKd1d1Y8lZqw6i0HBgxIf9Q5KfbRrWE4j4bNk 3SrKAOl1UfoXdZAqC5oVpb+QtERy90p+sKNX8guv1FNLeameXMpr+HmpKKgbGMuJ+oipDKkDmcqY OphBBOF+pgKq3mkYKurloTCpVe3UNa6PdlALg5m0qmBGrSkws9ZUmGHrhxhp7SVMuBEBJt6INJVA wck8BMc4d+h15jDVwBoNl6is02CKxac1C87LtEblApMeExtMikysZM5kUocplUkltIsKrZ5cqUD7 59ZidjvpktJ1sGjlGEvattFnliWMRO2YjlTtuI5kJQzGudJN1YASdTIOqK+sMiGoGLBL9A94acpJ OG26C4Jgug2CYroPgqR6EXJmahNiaGoVYmpaV6T4xJVtSXu36ZrwRNng+1u7Pd/Mw8083MzDzTzc zMP7Yh7M19IXa4IDKhGwp8wSB0RPb1ip7NfqlUcLI46sR8iNRwnrtaj6shUcEGeN6D6mXXxMdROK TTUs2tS7NdhAb6CBsgnOrZYVzq3H2gKrtNiB6PSvlAm2ccqRazYSjgfOkavzOzLzN4H4IQjEWj+q oZenL9QnSLD7UXVj9AkzeJ1PGLIdTkoF1ofXJLWi6zzC2tK5rS1922qN7mCKrvQGW3RjCNS4xvep Lf2n2nXuU8KzIg+eoDPYZrrGFcyKUPJcU4ZSI4rOkF10rimk1oUjmDJmhR+YRPzrJ7w79XmIpETx wRriP718tdPYTjGG2MWIXZWjpnnZj3gs9xxQyMOIfE+XZX5gystb4RKW0t8ifAdcwkZ3fns3HmE9 R4d0n6gEp9nGv+AYhbC/AfFmruLOXG2liNTtg9Jaou7Icyriwb6r91MHP11DU3ZfKLQj+FUFXyju 1xk3sA+pv+u3CyjI1rQ83kfIY1m7cYzOxfk+ImYJZiKF830E65VFInu4Lc/3JRazLDkFxeN9xO4V 3NH35fE+YvkKprhj0+J8H4GiZXFMQb+mxfk+ovvKSpteipqW5/sS7VegRE6Nx/sILCqYPQGXx/uE 41FBmsIJP8RqgfVQfwFU6uyEnwmuJ/xoSDjhZ3Z1i40PwnbCT76kLRzxl41ECbcNBIJ2ws8vCoYj fsrclhxo4YSfJK/pCb8wsIUTfnYPDyf8xP5mJ/wiyM0P+RmELQQET3e5a+GIXyDoj+fHwrE+d7su wOLM3zNLWC8vW9Z2XjdHDbeWycLQWy1Rwr1XvK70TktUcCeKrEmNZhIE3Ekq61knuQT+do5otN1w 6p+dn7KYdm5LZG+XBl6Lu7BIJG8XJlnJm6xJ7O6gaEYZgOEMq2tBrvV7jpnDKX/KYcRo3eGYv4QB py3XY/5BR6cd8+cwmEGVKZzylxZ0AaiqqgJEN00CnkzhoJ94ZppIWDqFc/4+uxqDQJiWE3GZwjl/ X4OGhLSZBoU0Tn7OT8I6LQ8SoZ+Pdg6g9ocMxR0TYoVlZkO/N0w332pj+WYpbpbiZiluluJmKd4z SzFU5cbhCMvWIMzEAtzfOWTXHst2gu5jaxbmRnCwHSdIdgY7W3c9HOE3ouO8cAfqTPCW6N4sWBu8 jY6DgXRXIaD7YP9a8A5aKIvHlLdSSO0jiKDctCFydsgst5rfgeG/ycUPSC7WRkEe6FVxlhkhS9XT XIEaSQmJAa+MVS3ZDseFKtQ4p0gMeGW8asl2OC4UsEB7I7HCK6NWez/YMGk/ronU7M2UItDMa+JW D7WX0Wmd6a+IXGF87nXODgJdU4h2xmRHOgPZuaYI4YQVoYyhIla+VDx0cmBUmsVvWPk8hSX67uzL wEPH57ulZ9M9k3vgaRnwA2N6iUMwoSKpZ7tvqCCOkOBed/ZRVq877Ag1d4o1yK+mN8xTQmBCRaPm OGBtKxANefBOYDajfbTxcPQw8IdMhEcEWN4269skrtk1sxoGfjBcMdvW9IpX69BFvsNJuYr7o3r6 03pW9ac/qqc/qichzoamV7y+Hl65LfozVO/POu2BQvqjQvrrCpEeTJ2Y6dCjslqPKVm0kECm9YVo d6IsDdVl6apChCFeiDLos/WvXQ+dvODCjjesUv1t+092E55qCQdO/sLLi58+ledU+tJCrpD21/RT TuTOvrzy4ncfzdnkrZfwCss/8BMw8vt5UNgrQ792tODqR8yQCfaCRZV0rBoI88qJMD2uM8pqliBp mrHTUOjyPOCIxTDhIskleGPX44kdie3YyetjVVbaBEvUDJ18Q+w1edi1No29Jg+71qbRVOX1nyp7 AKXrZPQ0DaDHTeorthD6idtAmFe7hCtDXgsTTJJcUnOtpIFZZAiLQh71MytcbH7oM1KqsAmzgq8R hCfNOLHhqL29LjyOZU2RCZI1FC/BaD8Q5d66WZQBIEOvHACZenAAROyVAyByf8QEfauFOZSVA2Af YgIqcy2EofBeY+FBNKpGvIToVI2ICdGqCJgJwasaTxOCWTXYJgS3ajDObpCOdwsAA9pVMRWWuAoV rDBaUYS6RqGCNkUeDfOWttgNWCXrZjuiAmsdJ9IkVDAaTiIMSmAJCuwM4ENT54/EBDb2pSTCoNzl kMDO/JRUGBBpN4swFA+HPFQTLcQENskjnFuYZkhYYBPceVoCEbcvNmFBzrqINmzjxyqui2DFOvqs 3WOMdGxD13o9LgIl+9AHzaAYlKLtiOKmV8AR0ztgmCmlttRZNgtpJgyu7kRSXB2KILm6ZDkzZSpS 6LpWpNR1sUjxiN0KjwHr80FW+Audbm8O2uxSvvLAuD5S+M1c3MzFzVzczMXNXLzX5qKYBjkc4YBo D22B7j1t+LT4eR/rNXvj2A3IMbi/oxdsmXaimQzgZdvFz8GzOLY83JMlulfbNUwLOyhQG3kO3bvd Ew1wiBrCNPgbNXYgABilvcY4iWltUITY4N/XvN9Y/j6x/A2vgbHSGdXV9+LbYSMfjtJrafqAXbcb t3vfJgg/064uH6rDXs+A19jLUAN+YNwpLIPwYGBZCChzxHbgIsczWlIZ1R6U8xhnupY+YJI4wYRI CgorwYBkQ1XgoK9laCf0aQ3tZL88GfqgO79+AUAJhiye+YTJmg76QAomXoM+oNLR5jHBOOEf9PWV jp0NCCed5WV97lnmhDSch245ZRw6mzJmeR066fSTaT7pZIpVJOGqawCaR5RJZ2JkSQnmMNctuo/b sVkmPOrcuDIsOpPuBec40S46Ca/C3lEXADSLKKPrbKKDsl/1Rxl11s46HcKjU/5SddKO3FVn7Tzl L3COsMrhO6Fz/iKuFdZwnFTonL8MygP0Ww8FMOcvRZkgVMPBIab8pTgPBnlQGjwQUFtgWOmVATLn Lz04IOwuWTkgc/6SdZ4t0lKyzsNlzl+yztNZ1oouAJgdwSQxEZJr6MpwMVkqQWEDZ51s9YvsMvny 4kcRrThv83bJBrS3u8VONRnZ1um2pMm0z5FiMt10ik4iCr1PZlMN7JBHpIxbmOsaL+UNKee1TJVN FOQRKRMVnWhDkuQNKZMznaarHOINKddhmOarGAed19QO6gCwvKMvHpikoxpNqRrjS1cEWC5kHbhZ O8m8bLqcSDpyR10vpDjwlWbQC7IecKUBik/Ogdqi0pmgwhYLOFNZTTVYVQwV1nQJwGbEFKIsCVxh ipyZPuUVgStbkVJXxrIkGHCF+2THiElvM0pNttQ+PlLilbqbxbhZjJvFuFmMm8X4cCyGL0AOEQ++ G3CCWthAYGiAW7VEvpEw5H0cYwzdSC1/+yaC68KIdb+Aq18A30uQdlu+Y9SHvYTSLawiazob+8eo xZ2EAufRY01xTpWXuPZzKnShaoMppo1D4nQL6e3t/U0C3l8JOLujhG6zrnl8Rwkb7BWpL+8o6W7S /wHIBnCDCmVuZHN0cmVhbQ1lbmRvYmoNNDggMCBvYmoNPDwvQ291bnQgOS9LaWRzIFszMCAwIFIg MzMgMCBSIDM2IDAgUiAzOSAwIFIgNDIgMCBSIDQ1IDAgUiA1MCAwIFIgNTMgMCBSIDU5IDAgUl0v UGFyZW50IDQ5IDAgUi9UeXBlIC9QYWdlcz4+DWVuZG9iag00OSAwIG9iag08PC9Db3VudCAxNC9L aWRzIFszIDAgUiA0OCAwIFJdL1R5cGUgL1BhZ2VzPj4NZW5kb2JqDTUwIDAgb2JqDTw8L0NvbnRl bnRzIDUyIDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2Vz IDw8L0ZvbnQgNTEgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFn ZUldPj4vVHlwZSAvUGFnZT4+DWVuZG9iag01MSAwIG9iag08PC9GMjEgNSAwIFIvRjIyIDE0IDAg Uj4+DWVuZG9iag01MiAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA1ODg2Pj4N c3RyZWFtCnic7V1rjxvXef4F+x/4kQyy7JzrnDFQFKpjtQ7qxpa2KArDMJT1Kla6tJyV7DYI8t97 3vs75C53KAkoLFP+YD7Lc32vz7nM8C8Xwwr+e/YvF2EF/9396SLVVRnrancxFvp0i58SfEj8/+8v Xv7m4iurPGzz1IY0rQ4/9Bb/4WmEtq9eXvzz1UWIWKn/bxzSNq5y2Ja4utpdfL0Om7qOm29WV7+/ +Ozq4i82EulWx2FD+/4ij2Wb86qksIWyDFOO25ihaBq2UG0PU3Go/5+/ufihdzZs4zSEqeLIcwit fxgT/Fu9uf4Bm42zTgi1vDoAPJqOrn13TbpvAsf+vyHfgyrWROgGLnhFjcgnml2vYVPvxWlU8Pme T9DiNctu0r/MhDfGufAUpzgXZooqTDfZIGNgYSieopP9y25EX6HwW41jLl3mqIQAH/I0RJW90/Ce BvcVvG8AbKtnDf+/aRhEPw2ltbg6/ACiT3nEibdhW3GQvXcYFOFbxbltc4MwxOUFOxWPUx1G1Oze B98P1dsdtCs4cr9SXrDrZ9F84t584t58hoGELOUFL+0nrP4MReowDGX1P72Z6qYD3aaZmJ6/R5s2 lTQTybu1yeoO24ThnXCcpi3G9HdpU02G22T8Xm3K3Nve3Nt7zb061VubovrnmlbvqdwTabREisEC cymFjTptMVHWXoES6m4zbWuJoa1/3FzWbR5bHNe3m9qj7VTG9RvNtfc1NwWIJNra+nKzuvrzg4Uz zsr1fbdp2zCmKa5fby4L9/2TDePtjcv0j8lwRGX2qL0FmcVRPt/S524/oGMpxnBpVJhV281ahM89 aZC6uZzixV46q7ebNwogNDd6Aqe0PTQ/dnB1Gf4yA6Um/PCgDR3h4kZYQw1Cj06mALtb2IjoFVsg wZxSXWRhVoKyYEM5pQnQgTZACoHq9xh+HIgT9JAwMov94sXmEpJkiTGu315v0jakIef198e8LSaM W9bOUXeLKUMxV/rZlRQPGjzuqRhGDIc5JcjS84r3FZ+QnLvix0YVSHVWusviydXmsjOJOrRx/WmP CPTpX4+KIk5AKRZ2GlPczvvsPZb1f315tIs8odZcrc96qOzRKuT1JxCjcJirzWUg7fWP0pwF5/my 5gFJR1XR3dtjsmsjrIXiIvWHCUmYK/3iu+/ubt68OSanWNDAlvUQY0MDi2bWL1/sXqE8QDK3m8uJ zfqvq03nF2DuTkhHBDKMut77OmxGzk/fgKwDpIa0/sfVhhXwt00YoED0qvh8c9k4gX0JmYW09vPm sqegGMa8zptx/duuTiqz6laHjT1ar+7Ve3wykPaSmPqXmz7+TmWm9b/18U9dImn9/LebELf9j+3e cZjR3ffp2y+egPP0bFlDd57LLguUz4ljbEjNcYyu63/fXI6cn6/6yPb7fvb0CciIZuH6thJ/176D 94iH+YmMp+TDoPVw7HHFF8QeK/1esWdhpxR7XOGnf3j2hZRfGCe6bkE9fuCfdK8g31qkX91AWRJh XOkFESa5zZm3XYJTH1ZZ//TjLQgWpXlzVJrdZVte2mf3wdkAe8h5fbdbQQhAB3o4WiwQUo9n4qhf /663w+55tenF0Pm9U2moef7sU/AYIqz3hJTfdUfv5VKBlo7mG6LHOorjgujsDZbsbsyzgXyzWs6c eV1fyMpguZGBoTO+VZwHWv5LecHLV9a+3u6gXcFDlZU1lRe8fGXt6+0O2mWcW5WVdSSmVE9bWfP+ h5sP7XPIfBaxSWnEBkuNyGAXN8IapLUyT6icsK51Wq8mtNPakMmYJdFkxJJOaYTVoY2oeqCRRxa5 DWRXMsQKzmmVo+WXECp6kJ/WP+ejK9vWgORrG4+sbAMpXjt89hpSZw8EtT6wnj0a8FPnnrBDFvsq nLLgsaidygTh0EofHWuNkAS18Nfr3Yu3m8wh6rrHLwp7R1ciaRrQVpb1SATI9fjKmOGPnVsFzrrA yRbmNRFQD8L1kTaPtdINBWQhrRyfxki2bV3+eHfz8hUot4sut/X/nhJxaTOrgUjAwkfwD4K3Cmvd uo0/gSfuY1K13X6jAqPbKiVw4v4lVNrNmxMw0AaDFBwOdlweaR83wfz4qw5/YSChFnSElQe4sDbr qDt1cxuQw3hCLFPNciNONKcERJqHs5aqxnJSC8PIsR1bGGwD6Hg8HTGdxDHpImG2f3F9PFTErjGr +0iowGzjezphi/B4SO3kubtvLNGRf5gELp2yX798+wRiCYVBY2/26RkscCi8PH9+itMnyBKhNDLo mrehMrxVGEcodKulBS93e19vd9Au44nTOhcXuNw5XbXdfqMMR9xN0D4EnkKvpjqfSXUSWUwmpjob aLXpLmxC9dYoENB0cDG5NA6YsrENkdApbYg8nP3UrPZzShOkCW1CFLOUWIVs61BjVj94n7zTFdlL 9CvwlR4yao8VmT3r6KowD5jfraejYSP3nNzDqx/XhwsbuMMdeg9j/fAbJN9+jn/trVUXYOz7eztw A3j6OUyp/zUF3+/Jaz86EqYTscboVlBJ4sdUVvCJ6z6ut9tvluGAKcp6EXziqo/r7fabJZh61gyu F8UnrvncXND0dDInrXBsqNSIjPWUNR8fpu9sRmVbl8cl1fdk6j+tCZmMWhDNhU3olCZYGdqGKmdB YMKckKvtC9275KvHl3wVjybqop0oWALFeZcfZtGXE24vLl31ueILln1W+n3WfUv7pIWf79Ov0qrq 5fSFX464GXBs5Xdc17Tys2aWLP18p+++9iuFTsAqX7apuXubwFuBmS8KSWnBS2PuvN5uv1mCQLcH 14vipdFwXm+33yzDiluV1ovgU3rJfiqVjrN5LotCDLXhBopt6EgXt8Gaw/0+N5/lhNTUjW2YiJY3 wfIwAyJ5iAWdIg9ShclDVPNoxC2V7xTY/rPFWUe57CLJK/1kHPCvx3y0jxWDTV60IV76OhOCjRuQ nee4ATma+p19tMG9fbUp7NSzWscGyrKIo54U//wCeR1Kw6io9YJc+I/33bdZmCykz2CU151SvrgF iki08KejRFvaGSyNvUNeKD0vhOpaeURVCTOX6/P1jzd3vdsw0qLh9Z2Lp7B5AhsvpZD/p1BwD4Xw LeIqEECjwtWDBHcpGYdQadnFLQXo1i1UDzFvxElxgej+BAFUKlpnqJe4vmDMA7m1KWS+4CNTzHrS gU78q546RbWY6Cih2yPdZ0i0cwZYv04DxnFAcLvNEE6dYKGtTmqmxJEuDcnJyQGWW6RS3uGk3wOC U4KOgL8qwl6zjL9aOzniX29teox/5dNedos/jnj627lbkLtXk+MXfBcLMC5fAMdsyTWOuO0DODIs enuRMFLDSsd3EXZnEObGMFHxmBljyqS6CdM47ysBTIQLNRWJKZRtbIzBVyrTD8AByuctfR3wcLdm Wg8ChhsHFUdAmL4moY544JhqoqgAGOWQ+H7igJ9RnLHSWXdlewIMSy1aHhDm5QK5Z51ISHGbffVI KzPoCkUcRAXcdRAVDKSiICqgkYetzKNC6UE0wPMeRAMRScogGmCpDaIB8oI6OJGXyVTQdJVk6iqT qICO28skKkBtwwYd20IkWMQ28KJJEw1UBIO3szKK/NGCAPP9UJRB4dAKVpypOKlgRHtNhUOzYvf9 FH192PGz1nFPznU+0V0RHRzd+LWRTyQXmVkbSC488TbMxdLwGQOVWgskF5Fq4ws4IvWm+mi0pldl NdqeUGW2SJYhum6JbFxsoePazFRaJg8RQ2rEX8XOGlNxscNWyDTEThvRbLbiRglTjb4VcldxCqkt TtMyGR47FPct7taSeCvHOB65eGtLW+/MMnH29Q5zc6FA5FZM4qMPJSxxDTWNF7TVtKUhqg0SsnJz urYIN231QraZisbHNlveiKVZeG2kEg2/ZKcUnt1TUxz0Oabs1AGk4EHMEQdhh+B14jlPnPPEOU+c 88Q5T3zEeSKpMnYe012Z+0CFRxjn2KE+rjm6Vrehs8zbPexy0wHqdWHb2AdBBwGUqmOYIapZxLKs nv8cKo+Oc99+LuTxcAg4QNec+Cxk7A5DxD1RPGrvThZOVTk7bA6h7uIdxB7W/UA5/2wUH4tRnMLd 4CgvTnTAylkRcBDyhk+dNMmClc5mVHMVgRC5QmWDZOeoG7WSywFWl+pz1ECWZV83GlOAU6DJkTfA o3wf6GjK0xA+NRKW0qExmByVCGKCAlyMuQGMjh4BHhxzg20U+RplIKmj8nNFklmInNkuDDkfbNK0 bBqXTRutLmmtE0PdgNKuxVqIVAKu2Y2cMygxUoBhNm/lgfgF4DqTmfJAOraMQVXADyipCvR5Jaew YUbFAcfs9D2wLeDVEeWBZCtBeSCqBnD0dhaUB9KTg0GIIJlpUCKIz2oFZVNoY4CHNsdJcmiYVQcL tsbptNL6RmdwY4P87IZOT67p1Ci987ybPhfGuZ+u0KjMiLmZTIlXmMhbNHUQJzFtEXczbSKjMWUT dTNjIEKktkLUzSyJ2JRZGnE3s8TGT6sp+8KTNTFi20ht2X2r5IsrK/nixpV9cefCvnhsyr6S+G9s fmrKvtLWu7cIpnqpKfvyQUPEXU38sbmgI+rimCTalJAlqtaQRqZgEQ8txQIiGZLGSz4V11iKVmih lozUQjEZMYXqwwU/qUJzv5Zz4cetc9Q33mm5f04Z55RxThnnlHFOGb/clIGj4HuVc+zQHrj2JVte PYBQhde++zofTdN13SGqushz4bBt1VJ4GXeIqq3xeOhaLe0BXeTlMM6zIj6qIb5/ANwCjyPD7jBS SKx2sTxqzzMxqJJ46uo1La9mXtPyau8Q96sPlfjPxvDLN4YTqZvey5M98ClrioTN4EkPOGgHfdID Dio7yF487HhOerxBe/OTWBtu3E86T9rXn5Sk0L7/pCSFzgUmJSl0bjAJS6EzhUlZCp05TI6lEKz+ pGZy5xuwpzLZAUeU27XK3QCP/rRkUpJCpymTJGQ+bZkGY26pSSrnnbYmqZ63d5owAa7clCkM+PRr cx035Rh0gtSUg+C4m1IUOn9qesZAs25ixXR61fSAgmTW9ACDTr9aNRWAyFs1FRD052pySVzO3Vrx TF3vssupXSt2yFeouONuqWVRAVlay6ICOjOELX1H3gBH2ZKD1vzmYUvCExlLggyzinhKY+3SZrr1 S8c0Ni7citdR0yGNToo38nXSfEqjMml60z0INeCL9kLsRi/wFp02+ABCtcUHNapNOr4QXfMxjZoC H36oqfA5jVoSH52opfFBjRgin7yokdI5jdow7zarjevXY3W1yT+4ZXUe7lmdi0c2uQOnyTsnz0xc l6Y9zfmsOT5LTeNC80GD5S0xhbWhIafpE5TNa1NDFmvbQhpZgwY8NBULh2RJFi7J0iyWoiFaqCU7 1UhMNmw3xPcO90kVttEvBV34idIQGkaaPXF4ThnnlHFOGeeUcU4Zv46UkaJoZreHHYptD137siWu HkRjdYe6U7HUwxhKWx6ZI+qHTmAtIgqEsnxse4C0pmGrOOQ5sGPdlg5SI9S0kHCA/LFuy+5M1+/N zsJ5bM4TRA6mp5wN8vGt9xvGkrD3zvjfM/WfDeJjMIjF9I0jEGweo6rpqlEcbHsRnl6ZbPMxEa4+ AoVpftcItrVdBApNUh9dNQpNUiPNLDRJnZiCQ5PEStwxSLqGMBxGSckVgd/qBxyFKkQqPAhVANMP deuOiQAWTzxClUBKzDFUCbTJnuEx5ohP+xjpCcVIUV7xgzXGmUIWThTdgzmuelZamqh4qK7vZJwI FBSSnXjh0JOdeNHX0c872l1ZoEwhigJYbtE4UaTyqgEUuhAoIEwhGCmKCIu/DxmCectE3w+OJsHr FbylDKICym1hsPuOKIbB7kOCSoZJ2AgZ6sC7hZxYB9napBt1w2R5tvlvKS1rZbqbZ21TUte++W6f jo0ZgY6drwbK1IhP6Lz5XqHKhdmIyo2uJapUmczMbjSqPpgGqb7Y91WfnAJU343eXC7mgC8pMluh 1yCZLbWRrENsjc2SmQ49XSRm2hr5pj431kgGYvWNHk1Sp5Dq7DNtJBGLS0nX4nH0GJp5JI9cHJYz ifizTHuccUuNBiK10STefCgRkXvyqEFI1CUxismjxjDWdtPDNZLLtJ2ZyqTk0kVPsbPJuH30wZfN FGPzjLBN2ygBZae2z8UO4o25Bmrm9BX+OUWcU8Q5RZxTxDlF/KJSRBZV7DzEu9cPILp7PcOK6DHx GboWp+m9a6pR6NISI04ifMObNhYtBHosm6s8hhmiuozxhjXX3EeZBwjdDm0vGTYZVLsXXLu8N8g9 tr0IcRjDve2LJILEGp69espUZ57iPcOv6T9Aqj+bw8dgDssPZJBRxTrIj7JgkgXsn1YAbNvegILs msPLRYvSOfplmaJ0riLwT2YCFqoAWyGlGZXAd0kol0NOBdhf7gOsDwbiSzKMUMWiXC7ReyqUztED HUXpHD6oUZTNoWfEImwOTQSgfzITcJLjmYmK+0cz9cUefFxD7/JAaG/QcN/p9cqR3qih1yuxbSVz 3LeQOR5atmMoHLmyOZqYkjmet5I5louwOZKakjmWaDQNoMSjaaBQ+Zi9xmbqVDLH2lY2R0AvV2Yq rJcrUQrC5dDKilI5ssGiVI5stAy2sw1CyEK3iAoCrnOoX6NQHBOESzzFMcXqeidiqGMjb7Sho7Pa zCjF2rSJCppYKEWzzIgHmkApuZvAiQeaQpAamL6ICKo2iViYspEHmi00fpeLkjF9l4s++ZOqWVrj d9AoH6skBs0e9FZiNWQkVGbnRKjMJ6Q55WP08hulYzwY5WMUvMUjeSpKxzJZ/WgMuDbn7kSpLByI HEWoo48jogTlY9EFIVGfsrFAVi5sjJSvZGwgmSgfY9Nxq92Wffgky9PgOtFbvjX2kuHWQZ7FUr6m bxbiO/Nt68rtBRz8jn3hHQ7sz/nhnB/O+eGcH8754ZeXH3QhONKoivs9g0NEl5dn2CECg8Sta+s+ zDINwQOASSRwH3QFSQMg3WDiTgykfXTti6Ik9tFYZdbX3u33MiEuEvcAR4AkF7F9yNjdEyP2QzhB jdKqGdUUZ1F1lj1fadqYX8+/Z54/m8LHYAruskbDHxGhpb/cleLNC4K8z8Hn/Q5FeZ8jPPCTBq2Z EWGQlZeSH2DOXVLcQXg8iDBv8mb+hXNB0BH0y7fBJt+Su6+ld1HG87R1G4+9nneOdeebd44Z874x b/8oYsNnrCGD21JH1d8Z2scDvyqUiwvEhEmQd7/ZkB3ijnn/Pc86tk0r2anM54nf9wuBE/5oOJgV v5M3HPs9wWmym8+PFx7lvUdLCuNNU9pCXlIY14Y49lnp+euoG1UCjwQiVFLWV7M/3fTI1//hW53X f4I3Lf90t4EfpV3frMofP9lcpm3q//J69WwTsOy4/sN/XH0G75Ef+r+wXsEvsuLfv3iyaWF9tYHf Wez/1p/OfxpUhwG/zVzdMOYvQHbFUHJ+uH0Mldq+uufXUudzRRMqAQ9r+WdOJp7Lzc+b7Kb95ua7 2S9AaoP69pZI2ZzP8fRtLXxux/hBlNFOCWZexkhTmdct7BCHmFdFWt7hQSAfPgJK0aNCrzMO8n65 7Fqy18vxJIO+aZ5ein4Ww1dLf3Q2DbiALsleqD5sxvUWfuOCXlXuPsajP7ZAJ438wv73ailirE0Z 10rv11KkX5fDy+XvOzv4qaKovwv4cEPh/uBRBribnydMStjEVz/dvNmkRDGIXkmPgek1/twPOvwP 3cs/WR1tcLQfLXpytwHZQZi5WUGgo0Z2L+DHbfHPb3ssXF9/v4kSUN702DLgL932cvjTJvTFnQZN 39LtRqLqK/303xo2b/7JRvp/VNhhowplbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2JqDTw8L0NvbnRl bnRzIDU4IDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2Vz IDw8L0ZvbnQgNTQgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFn ZUldPj4vVHlwZSAvUGFnZT4+DWVuZG9iag01NCAwIG9iag08PC9GMjMgNSAwIFIvRjI0IDE0IDAg Ui9GMjUgNTUgMCBSL0YyNiA4IDAgUj4+DWVuZG9iag01NSAwIG9iag08PC9CYXNlRm9udCAvQ2Fs aWJyaS1Cb2xkSXRhbGljL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcvRmlyc3RDaGFyIDAvRm9u dERlc2NyaXB0b3IgNTYgMCBSL0xhc3RDaGFyIDI1NS9TdWJ0eXBlIC9UcnVlVHlwZS9UeXBlIC9G b250L1dpZHRocyBbMCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyAwIDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDIyNiAzMjYgNDM4IDQ5OCA1MDcgNzI5IDcwNSAyMzMgMzEy IDMxMiA0OTggNDk4IDI1OCAzMDYgMjY3IDQzNCA1MDcgNTA3IDUwNwo1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgMjc2IDI3NiA0OTggNDk4IDQ5OCA0NjMgODk4IDYwNiA1NjEgNTE5IDYzMCA0 ODggNDU5IDYzNyA2MzEgMjY3IDMzMSA1NDcgNDIzIDg3NCA2NTYgNjY4IDUzMiA2NzcgNTYzIDQ2 NSA0OTUgNjUzIDU5MSA5MDcgNTUxIDUyMCA0NzggMzI1IDQyNSAzMjUgNDk4IDQ5OCAzMDAgNTI4 IDUyOCA0MTIgNTI4CjQ5MSAzMTYgNTI4IDUyNyAyNDYgMjU1IDQ4MCAyNDYgODA0IDUyNyA1Mjcg NTI4IDUyOCAzNTIgMzk0IDM0NyA1MjcgNDY5IDc0NSA0NTkgNDcwIDM5NyAzNDQgNDc1IDM0NCA0 OTggNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcKNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgMjI2IDMyNiA0OTggNTA3IDQ5OCA1MDcgNDk4IDQ5OCA0MTUg ODM0IDQ0MSA1MzkgNDk4IDMwNiA1MDcgMzkwIDM0MiA0OTggMzM4IDMzNiAzMDEgNTU0IDU5OCAy NjggMzAzIDI1MiA0MzUgNTM5IDY1OCA2OTEgNzAyIDQ2MyA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA3NzUgNTE5IDQ4OAo0ODggNDg4IDQ4OCAyNjcgMjY3IDI2NyAyNjcgNjM5IDY1NiA2NjggNjY4 IDY2OCA2NjggNjY4IDQ5OCA2NzcgNjUzIDY1MyA2NTMgNjUzIDUyMCA1MzIgNTU1IDUyOCA1Mjgg NTI4IDUyOCA1MjggNTI4IDc2NCA0MTIgNDkxIDQ5MSA0OTEgNDkxIDI0NiAyNDYgMjQ2IDI0NiA1 MzcgNTI3IDUyNyA1MjcgNTI3IDUyNyA1MjcgNDk4IDU0NCA1MjcgNTI3CjUyNyA1MjcgNDcwIDUy OCA0NzBdPj4NZW5kb2JqDTU2IDAgb2JqDTw8L0FzY2VudCA3NTAvQXZnV2lkdGggNDkzLjEyMS9D YXBIZWlnaHQgMC9EZXNjZW50IC0yNTAvRmxhZ3MgMzIvRm9udEJCb3ggWy02OTEgLTMwNiAxMjY0 IDk2Nl0vRm9udEZpbGUyIDU3IDAgUi9Gb250TmFtZSAvQ2FsaWJyaS1Cb2xkSXRhbGljL0l0YWxp Y0FuZ2xlIC0xMS9NYXhXaWR0aCA5MDcvU3RlbVYgMjUzL1R5cGUgL0ZvbnREZXNjcmlwdG9yPj4N ZW5kb2JqDTU3IDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDIwMzE5L0xlbmd0 aDEgNTY4MjA+Pg1zdHJlYW0KeJzsvQd8FcXbP/rszOyek7NnT0IvAXJSaYHQuxB678UEEBKSANE0 k1BFAbGi0kVBQWwoKBqQLioogqJgF3tBVARBpCole7+zs4GA6M/3ff/l3vtJ8Jvv9PrMzPPMLEga EflpBnFKTMtOzTvwnL8tQt4lijmQNrEwOPSD/klEsUVExvNj88ZlP3640/NE8SOJQiqMy5oy1lc+ awFR8zwiz/rxGanpR+a37kp0XQzKaDEeAdbZap/Cj/QUMz67cHLfr061h38G8HxWbloq5RyB+5Z4 +Ndnp07Oq+mv1oto83dIH8xJzc5Y/tXLvxJtgdfakpdbUGiH0V1Eu7bJ+Lz8jLzXp01F+3Z9RVSl CsK4ixok+0XlpsIHV4U7SJQb5fRrBhnURxZHt7Hx7EWeyyfw2/hsfj9/nO8Td+kVAh1qvlZzT61H ai2v9WdEpYiaEV0j+kZcH5EcMSLihohbI9ZH7Iz4KOLLiN8iTkUUB8OCUcG4YKNgs2CbYPtgl+Do 4M3BOcFFwQ3BrcGvI/XICpFVIoORUZFxkQ0jm0T2ixwdeUfkkshno1iUERUaVT6qUlT1qIioulH1 o3pEpUZlRLPosOjImIKYU7EUy2L9sWGxFWOrxj4e+1zsu7Hvxf5Ue3p8VvykhlWeqf5M5HlRHF1s 27bsJ3oTpBUskxXxQj6V34HezOFP8vfFPegN1dxesxi9WRFBEVUjghE9Iga4vRkdMSNiY8SuiE8j vo44EXEmSMHy6E1CsEmwdbAdejMqmBcsDM4LrghudntTuVRv+kYOjpwVOe9Sb8qhN9Wiarm9SYlK d3oTjEmJORxjX9Gb1bF7nN5MjE+JL0RvqjwTPE/FQac3mn1adsioSWQ3lK7izeT+2OuO7JV8fA+V +jnyDv68Rdf4+aEp0dH+P9SH6+DRh2TIL5DFY2t//fFA0Q+tiA7cfmD6D/V/qPHj6JIcv3Y/0PtA rwNdUOoPTtkTDkR/f57o+x8OLz88//Dth3+RoYeePLT00EOHFh2afyj50ED4Gx6qqvJ/m5vWMw25 Qw+FWkoC6S3tDiK9PHo0x1iM3yuMXZ4a3ntkVMjSkBeIfD+ZD5uvm+/6K/uDqhR/HX+6/13/IYtZ fquR1czqYqVjim93JnqG+i191vqSdlufXu61tc963zpkHb7kPyVhnXF9J0qlPGwVXzliKtY6ERCB GiqkhInzXvwhvok/K1rzh/lirJnpfI64jg/l+TyJZ/Ff+VF+jP/Gj/Pf+Ql+kp/ip/n1fJjoIjqK rrwvf4QElaPyVBVrM45qUzwlUBtqR+2pC3Wl3nQ9JdNwGkXpNJ4KqJCm0FSazmfwPD6TL+JTtaMa 00K1MK26Vkurow3Qhms3aJlalparTdAmardq92r3afdr87Sl2gZtu7ZD26Xt1t7lt/McPos/iNb3 5qv58/wpLlf8fObhy7X3+XjRE61fwSz+pOjG/+B/aifEIL6AT2P1+FntA54p4kU90YT3Ix27hoe8 FIK9MpSqUE2qRREUSY2oMTWhZhROPbCr9KV+1J8GiA40hDLpRrqJsmkaJWkPa1wTmq4ZmkfzaZZW SYvQglqkFq2N0kZrKdoYraY2RbtNm67N0GZqt4tE7S5to7ZJ26xt1d7WZmvvkE/zkqmFUEDzUwWt HFXUylNlrSJV0ipQNS2cqms1KEqLoWgtlmK0OIrValNQi6I62kCqqw2ietpgqq8NoQbaCGqojaSm Wio119KohZZOrbQMaqmNpdbaOGqr3UTXadlaDnXQ8qijlk+J2s3UWSukTloBddMmUU9tKnXXJmu3 UC9tGg3UZtEgSPhg7U4apt1DI7QH6AZtLo3U5tBobT6laAtojLaIUrWFekW9EmVoj9A4bRllaVso R3uZcrVtlKe9Qjdrr1K+9hpN0nbSrdoeuo1maHvpdu09mqnt05YYC/Wv9W+MRfq3xoP6d/r3xmL9 gP6DftB4yHhY/1H/Sf9ZP2Qs0X/RDxtL9SP6r/pR41FjmbFcP6b/ZjymHxfzxWv678YK/YTxuH5S P2U8oZ82DhtP6meMp/SzYonYrf+h/6mfM57Wzxsr9Qv6ReMZ41njiF5srDJ+NR4xjhrHjN+M47pt kLHa0AxmPGdwQxjPG7qxxjCMFwyP8aLhNYqMEGOt4TPWGabxkuE31hsbDMvYaASMTUaosdkIM7YY 5YytRnnjZaOCsc2oaLxiVDJeNV4zKhtVjO1GVWOHUc2oboQbr5OlmRSmBWiodrdRw3jDqGnsNGoZ bxoRxi4jaOw2Io23jCjjbSPa2GPEGO8Ysca7Rpyx16ht7KM07UEaqz1q1DHeM+oa7xv1jA+M+saH RrzxkdHA+NhoaHxiJBifGo2M/UZj4zOjifG50dT4wvjS+Mr4WrvR+Mb41mhmNDe+M1oYLY3vjQNG K+MHo7XRxmhrtDMOGtcZPxrtjZ+NDsYhI9H4xZvlzfbmeHO9ed6bvfneAm+hd4J3oneSd7J3ineq 9xbvNO+t3tu8070zvDO9t3tnee8IeSBkTsjckHkh80MWhCwMWRTyoDXTuj3k4ZAl2BUfCXk0ZFnI 8pDHQlaEPB7yhHZWuxDyJLNCngp5OmRlyDMhz4asClkd8lzI8yFrQl4IeTGkKGQtK89iWBUWzxiL CFkX8lLI+pANIRtDNoVsDtkSsjXk5ZBtIa/4evl6+/r4+vr6+fr7BvgG+gb5BvuG+Ib6hvmu9yX5 kn3DfSN8I303+Eb5RmvHtdPaOaazsMAUVonVYWZgLKvOojQ7cEvg1sD0wMzArMCdgbsD9zJNH6AP DNwXuD/wgHU8MDcwLzA/sCCwMLAo8GBgcmBx4KFAOqvPGgQeDiwJLA08Eng0sCywPPBYYEXg8cAT gSf1LD1Hz9PzA08HVgaeCTwbWBV4Tp+m36bPCA2ExrBloU0CawIvBooCawPrAusDGwObA1v0uYGt gW2BVwPbAzsCrwfeCOwM7Aq8FXg7sCfwbmBv4L3AB4EPAx8HPg3sD3we+DLwdeDbwPeBHwI/Bn4O /BI4Ejga+M2/zLfWt873EnucLWWPssZsOWvBWrN2rBcbwG5njVgT1pQ1Y81ZS9aKtWFtWXvWgSWy jqwT68y6sm6sO+vBerI+rC/rx/qz61hvVsCmsGlsBlvI8lkhm8gmsclsKruF3cqms1nsDnYnu4vd ze5l97H72Rz2AJvL5rFFbDF7iD3MZrIFbDabz5b4nvU951vue8y3wrfet8b3iu8J30bfSt9W3+O+ Db4nfZt8T/u2WKuttdZz1jrreesla4213nrB2mC9aG20iqxNvud9L/iKfC/7lvhW+Vb7nvFt8y31 PeXb7HvR94jvUd8y9jxbwz5hz7IP2evsJbaebWBb2Db2KdvE1rE32R72FHuarWTPsNXsOfYCe5EV sbVsI9vMtrKX2SvsNbad7WBvsJ1sN3uLvc3eYe+yvWwfe4+9zz5gH7GPuZ9bPJSH8Yq8Mq/Gq/Nw XoNH8mgey+N4HV6Px/MGPIE35s14c96Ct+KteRvelrfj1/H2PJF35FV4Vd6Jl+MdeENei0fwII/h tXlnHsVr8ia8pfWm9RHbz7tYu6yPrd3WJ9Zb1qfW29Z+a4/1mfWO9bn1rvUFe5XXZbt4U2uv9SW0 ga+s96yvoRN8Y31gfWt9aH1n7QhtFto8tGVoa+sNa6f/cf+P/if8P/mf9P/MVvHy/qf8h/xP+3/x r/Qf9j/jP+J/1v+rf5X/qH+1/5j/Of9v/uf9x/1r/L/7X/Cf8L/oP+kv8p/yr/Wf9q/zn/G/5D/r X+//w7/B/6d/o/+cf5P/vH+z/4J/i/+if6u/2P+yf5vf9r9ikf9VS/O/ZjH/dov7d1jC/7qlW4b/ Dcvj32l5/W9aIf5dls+/2zL9b1l+/9uW5d9jBfzvWKH+d60w/16rnH+fVd7/nlXB/75V0f+BVcn/ oVXZ/5FVxf+xVdX/iVXN/6lV3b/fCvd/ZtXwf27V9H9h1fJ/aUX4v7KC/q+tSP83VpT/Wyva/50V 4//eivUfsOL8P1i1/QetOoHfAyf1dwKnA2cCfwTOBS4EikMplIXyUN3oaPxudDJOGJ2Nk0YX45TR 1ThtdDPOGN2Ns0YP4w+jp/Gn0cs4Z/Q2zht9jAtGX+Oi0c8oNvobtjHAQ8ZADzMGebgx2COMIR7d GOoxjGEej3G9x2skeXxGssc0hnv8xgiPZYz0BIwbPKHGKE+YMdpTzkjxlDdSPRWMMZ6KRpqnkpHu qWxkeKoYYz1VjXGeasZ4T3Uj0xNu3OipYdzkqWlkeWoZ2Z4II8cTNHI9kUaeJ8q42RNt5HtijAJP rFHoiTMmeGobEz11jEmeusZkTz1jiqe+MdUTb9ziaWBM8zQ0bvUkGLd5GhnTPY2NGZ4mNEF7nSZq b9Bk7U1jpqepcbunmTHL09y4w9PCuNPT0rjL08q429PauMfTxtPW085znae9p4MnURSKJ8QE8aSY KJ4Sk8TTYrJYKaaIZ8RU8ay4RawS08Rqcat4TtwmnhfTxRoxQ7wgZooXxe2iSMwSa8UdYp24U7wk 7hLrxd1ig7hHbBT3ik1ittgs7hNbxP1iq3hAvCzmiG1irnhFzBOvigViu1godohF4nXxoHhDLBY7 xUPiTfGw2CWWirfEI+Jt8ajYI5aJd8Ry8S7dor0lHhN7xePiPbFC7DN7mH3MXmY/s6fZ1+xt9vft 9X3ge8/3kW+f70Pf+76PzVQz3Uwzx5pjzAzfEd8x31Hfcd+vvt/MTDPbvMnMNW80c8wsM8930nfW d9r3p++U7w/fGd85c4Z5h3m7eZc507zTnGXebYaaFcxyZiUzzKxoljcrm/PMheYC80FzvrnIDDdr mTXNoFnDjDCXmsvNR80V5iPmY+Yy83GztrnafMF83iwynzNfNNeYa814s5HZ0GxiNjAbmwlmU3Og OcAcb44z882bzfvN+8yHzMXmSvNp8yVznTnMHG4mmSPN680RZrJ5g+8L3ze+r3zf+b70fev72ve9 OcGcYk4ybzEnmlPNyeY0X7HJTDKFzza5qZm6udHcam42t5mbzJfNLeYrZkuzrdnavM5sZbYz25jt zSHmYHO0OdQcZQ4yU3yf+fb7PvV94vvcv9S/zH+/f55/iXmbWWjeahaY030nfL/7LvjO+y76F/jn +xeac8055r3mPeYD5myzulnNrGpW8T/oX+RfbK4ynzWfNJ+AzbTEfMZ8yqxv1jPrmnXMaP/D/of8 c83XzA3mq+Z6c7sZZUaazc1mZgv/HP8DVraVY+VaedbNVr5VYBVaE6yJ1iRrsjXFmmqdsE7yfOsW 2M4T+WTrVus2PpyP4GOs6XwUH83TrBl8Lp/Hb7FOiTbWHXyAdSc/Y53l5/h5foFf5MXcFiQ0wQQX QvtO6MIQHuEVIcInTOEXlgiIUBEmyonyooJ1t3WPda8127rPut96wJpjzbXmWfPF+3yltcBaaC2y HrQWWw9ZD1tLrKV8I3/MetTTU9QXjUQD0Vg0Fc1FQ9FCJIhmoqVoJeoa8zw9xDCRJK4XyWKUGC1G iOFipLhBDBHt+TTRX/SxlolO1mOhPUJHhY4OTQlNDR0TmhaaHpoROjZ0nPWn9ZQYKj7QQyw7ANMi wAIclp8eMAKe0BuMez0djdnGfcb9nk6ezsYDni7GHE9XY66nm6e7scDTy9Nbq6811LprrbTeZDCf NBI1cq3eyz8aMfyRP+xaNvoVKf+/b2eSYyFWgXXYgwZQNqw+DrvPA8vPB6svCLtPWn2jYfdJq28K LL7bYPPdDqtvEyw+2HuQtCcdS3U+v4Uv0B7mK/hy/rh2gnlEJ1ieQ0Qf0U10Fz34i2KQ6It5Hszu E/2097UPxEBYlnfxfry36Cn6G0tEZzGAj+eZPJk47FcvLFNYaI6MS6mGhItEMRS25W2iDl/J03mG nE3I+TQ+hqeJNrB3I2D1RsLWVTZuI8e+Jdi50rLN1MZqZ6FtW67mXY9FsHjtQtk9W9k9W9k9W9k9 W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k92//ong0/nuWw1ReWMibzaCY9 Ss/RBtpKO2gPfUQnNR+l0J30Gv1Ah+kEndcIFlElrYZW91r2+3/vp3iWnk0W3w6LrQqRfc7+pXiV DbtdD5QKWQhfFRF3OcQubx+9Oqx4YfHm4n0GtHAnbxh7B6HHtaP2OdZB+u0W0s/ulm4nx3HP8uIX ix+7ojmj0eMcysVo3ExjaBx8+TQZtu0tdCusnOk0g2ZhRO6iu+le/L6fHqA5NJfm0wJaSIvoQVpM D9HDtISW0iMYzWW0HOGL4V/uxJITs4KeoJX0LK2m52kNvUCPw/8kPUVP0zMIXYXw5+B/xknxnJtm OUJWImyVm+tFKqK1bpxyr6OXaD1m78Wr/JtoM22hjS5vpZdpG71Cr2JWt2OeX3d/q5jS4X+f4116 g3bSm7SLdtNb9DZk5R2E7aV99N5fwq8VVpL270t5nz6gDyGBH9Mn9Cl9Rp/TF/QlfUPf0gHI4kH6 1UmhYr+irxHzHUIP0KGrcu6/lFel+hbpvnfL+Il+Rvpf6CgdK5VHpf8KqQ7RGToLmfdq1WHvB2C5 n6Y/4Le0yog5p4XAFanV1hpgVSVozbTmWluto9ZJGwRfI+c2YR7kYhFmX8nDUsjDJMjRvQiT0qJm fCVW3apLs/wi5k3O2iMYc/nnNWfkX7/GSO1FT59FrrXOHP91rl53c7yFeHn/VjqVnMk3rihNjvhq pwVSbrYixXY399uXZuMTlPLxFaN5gH5EjBw3Gf+ZE/OOM8rfOqN8EPE/ObMgU6nx3Y/5/fRSCTvR 3u+R90PMy4dOKjlrnwMyzdtI9Tziv3Fn7hAdwWzJOTsM389wb3N2ph/RYjmXP7hx7yLmOParU5jZ 3+h3uE7CLf/sQMgJ4BhCf0MNJwGZ5gjadRwt+hVzfAKzfhYxf8J9hi7gzym06Bydh0vGfIGYM47/ PNlUTDZ2RU1jGke4dJOT5wL6fxGtKUbKYk2ji86dkrxR8kJyfJqp+SE/MqcTokqBVDGkknFeJ8RJ T39cSi9v1Mpp5bUKWkXsw5VRagBh5bWqbkxISYxWBWGBUukrETlh1bTqcNWS91m0Dzt5LToD+a4B CQ9qUYhlWk3M8ydaNCS7jlZXa6Q11ZojR4wWi9qkpLfXOmjRCInV4rTa4ProHyRea4eYjloXrSti bS1ea4H10F7rdq09ny3BCnB+sH9/pgc0Hfv/66wfTYZ/P2RwBQ2gJBpFN+qH2LuJ3UaPumHkiOHJ SUOHDB40cED/fn379O7Vs0f3bl27dO7UMbFD++vatW3TulXLFs0TGjaIrxMXGxMdFVG1YrmwUMv0 hXg9hi440yi+a3S3lGBRXEqRiIvu0aOB9EenIiC1VEBKURBB3a5MUxRMcZIFr0yZiJRjr0qZqFIm XkqphQXbUbsG8cGu0cGivV2ig5u14QOT4H6gS3RysOio4+7ruEWc47HgiYxEjmDXquO7BIu0lGDX om4Tx8/umtIF5a01fZ2jO2f4GsTTWp8JpwlXUZ3ovLVanfaa42B1urZZy8hryWqLeGzX1PSiAQOT unYJj4xMdsKos1NWkdG5yOOUFcyUbab7gmvjt8++f3MYjUmp70+PTk8dmVTEU5FpNu86e/bdReXq F9WN7lJUd+rBquhyRlF8dJeuRfWjUVjvQZcq0Ir02LDo4OzThMZHH/31ypBUN8SIDTtN0im7eGmY EF/iJrQNLUT/IiNlW+7bnEhj4CmaMTBJ+YM0JnwdJSbUTy5iKTJme0lMpaEyZkZJzKXsKdGRcqq6 prj/TRxftWjGmGCDeIy+818s/kN8sIjHpYxJGy85NWN2dJcuatyGJBUldoEjMdXta9e1jRKQPjUF nciUwzAwqSghOq+oYnQnlQABQTkHmYOTnCxutqKKnYsoJc3NVZTQtYtsV7Dr7JQuqoGyrOiBSVuo qf3d2mbB8JeaUjNKlu0oqtwZkxLXdXZS+tiiiJTwdMjn2GBSeGRRYjKGLzk6KSNZzlJ0WFHd71Bd pFOjkwt9uyp1SWLZc0+sN5jEwnmynC0EBLvhV3SndogIw3Q5XjmjndoFk7RwKkmGWtwU0nVFOfDw 2M49ZBSXWTv3CI9MjlQ//9CkcLdNemyRt1RZYQi41CZVz982TaWWDaob7JrRpVQDryhUdxvolnbt djI5Fm7FyOGV09mjJIrHYuUijKEYJ0jOYtVgEQ0IJkVnRCdHQ4YSByTJvsmxdua39+Do3gOHJzmz 7UrJkCt8Kr6V8hVRJKJLPKwzZLBb/fCSaXX83R3/JW+Pq6J7lkQHZ3ujew+eLQuPdgukIFYQOm3E 9Uy9r1X5Zlia3bC7RXdLjQ6GBbvNTt1szxgze21i4uy8rinj28gyonumz44enNQu3GnroKRbw6fK qspTb633kE4N4rH3dFobrd0zcG2ids/g4UlboG8H7xmStI5prHNKp+S1MYhL2hIkSnRCmQyVgdIT lB5Z0iB4vE768C2JRDOcWOEEOP60zRo5Yd6SMI3SNjMVFlYSxhAmVFiiEyZ/MElVx2OIsd12DabL 6ZmWPH52SrJcXFQZU4n/tCItuj0Vsej2azVm+It80RmdiszoTjK8gwzvoMINGe6BYODUxeDIPWl2 SjT2KQhUEoVrShS5LDK42baHJEXuDT+aHAlRGwkMTyoKqY+9X4/thXTdJVIQ3L1oRlqqbAcNTZJ5 PbE905IhtiUFIknPohCUEOKWgBTdnDxSHJEpDXODCXTyz4CnaEZyUXJ9WWlSZrIjzmFF1CO6DaZd lanHyYoSkmeXj27irE0sBV/s3ZJC0DYanKRCwuFFZclqkDx+tDwtGlFpKUGMtqC0wRB1tZf6wlVI BrZEEZfhwBfuRpLsFo81LV9RSEMUiP+k22wol6Qe60lOVo13fHe7CVB3WJGJFsWVGko3A0YHUT1l W/Df3WiqTLpDFjNwMw2KnoydRTbaKcmD6CIrtmcqNn+V30RIdKuSzF65R5huGTtVqEf23I9x57FD NtvPRE+JLPXTID5aHg5SMCl8CwSbkmdfHVA0on6DeO/VoZYTPHu217p2BjVeXusSIxDmMSznAv4d LF1OHmpLQ2kY9d/QoHKDyt52HX2sDfUkj1YE6Q8yIi90y7WJ5QWLbWnwgeFWubyB2sAuHjaEOnz9 zdc3fPP1XvBeLeHro58eDbv46dHyrVsnJDRupJWLLOegYoB5PIYRHdWQtWzZokXTpk3as+bNGrLo qAAQ17xZe9ayPW/apBZzkqqUTigSy1D+3YX+vNvFGDYx2GV8j1q8QWzliPIerZoeXd1M6FSnvFUz ITquTd3qhtcjDJ/HW7tlp6iu47pEFb8jvIGQQP1gjegKhggJNa26kdWjKniK4/TAuRN64Pz1osv5 bbxci4x+TY0plsn0EO8zkeG1GrWtVTG2Zjkr1AoEPDUiang85UN90dcNvLg8pEawps8KhIRV8ps1 I2r5An5vaOWLkdg61tvn9C56RYqi1K28G+9OSfWxwDsPTUqsQVWiqlSu7Kvkq2rWHES+ylWizEpV vXrYIH1onfpVO3QoX6V1By1hZ+um5fCnSbmmjRuFJ5b725SNGyXHBrgcoto8rj2TA1SlQlNNDmDl yoaHvRpSMa5D07bdYiy2nLPqLRs3blnTy3KYdtZTPrJlg0YtygcqNCxXyeTcrFxBzA+PLKcLs2LY hRr8UKCCTxiV68fIr6Ta27+Ianw/xUE6HtzKe/Cel3r0UkhNb63NrP76uNpxbb1wrKO4xpvZqkR/ hZC2tWtCCeeRPett1oauq96rxWZtyIbEQF/ex+lA9b5HOxztAAGp0lpLOPrx10fR47Cj5Vq3ln02 /wu55SiUiJQaDQiMwBBUcYXGo8XFQcBEpYq1mBS4ljxdtLwuonZVD6sR2ml4dpsBNyaGV23SL/uB 5MEzGoUhrladKl5W/EH00Fb1urWoG26FVK0TET9ywHWByErlpfDMDXZvE9dq9NTOHR5cdO+NHbp2 6l+pvB4S6is+1bJlnc5Jo1Pr1mpRr1rzEVO6yvFra//C38b4NaR2tOHK8dtYr0lLQ1DIZrYwMSS6 nL8Wr1gxOmEzm5tYm6LLlfM3OVyv5a46ZIQZicYAI8UoMrYbnnBuGLXq9fLbibX6ysGQY1G+dQLB uKl/VA5hglyACKnSGr4qzoDG/vcLw/jKxRgdbRiVKlaWA4ixrSSXZ+nRxjA3k6PMPDIFf7vjvR8t GCnEkBs6ZfZv5vf7DLOc6U8cntcmZW5Ko2qtkm59KnPErCF1z3Zo16R/u/rWkAFZnWqxL3oUDI6v 0qDCwEEVqlQIhJaLrx/n81etaNUZNP36zksevGdc+/rdR3Su0zzmusEJlWIaY63F2edYfT2PKlH3 K0c2MawSmYk+8lUyhR7WTe9Tsmq0hOp7mzZxhOyvkZdXVEtN7UMeLZqF1moSE5dQPYRpHhYINo6N TajuZVG+UJ+uy1/RvjDTMMwwn/y2EHPtwVx3o1lXtmcbhbIpWEDN2IOJFSq3xR+KDm2WGN71Z933 S2IvGHO0sV7Cn4nh7ixc/PhoB6AcRFxuCNhGwzAdstn+f5mtZN6i1PYK6ReVXH/tuLiSWXN3YCE3 WWcDqcw9nkAFvxXdpHOD6JYxFZr2SerTpE3uY+mNru/ayO/1cE+IP+ANRLXo37budXUqNO51fa/G LcYvGlWvf4cEn8kn+RMaRVeoUr58RL2qEfVi67Qb1rHPzFHNAxWrm97ygZAaUVE1ylWtWa1CVHy1 6Pi4Om2Gdew+dURTs3xl0ye/uLwee01Vvgsr5Zar5jPcrEqN2zVpHB1TrSqZVWMaN2kXXS1Eb9mz Vs/4zdr1GxLD+uqX9wY105jonTuxjZZz1kDYv8tWSgYu7SctWlZwxYHLVeDuI5fC0pgVXi8ionZl Dw+v2G3Eja26pbYND/HksNCIJjGxUnJu1PWQihGV6yYP6BDWRwtzgsO9LNIXGqLLnWN+dPe2MbU7 j2oZ1T2W1S0JvXiocqPKVWvXCDS/YXov7faSYOcLM33zoPnT9u0ZHdruNFXzOncgLx+Z9q7kd77Y 8u25yRcf8NXybMOpHoI9SH2Tht8GFZO207fi3OQ/3/XVwnm+tPR9SuiNInDZp71HJD63t/9bGM3s qRJiGrXE5p1yDYzRTWrroCYlSPCfqR0Q63JroIHrvhLPU3O9Gt3wF/ipmYPONJBFYXlF2fXBNcBd gM5AH2AYMA3hNcEPibeRbqW9AXhepFBzCT4GdUjc7PJEqiRuo3ZGMcpOvAaqAck0+j/iJqovgXJG i07UDGgK/2gxE+5S4Fts+5o4Qw8ClVyeo7emif8SE8TLtN7TkXZdDTHe3i3qUBHQyuWhQAb/yP6x NER3+6V/iXX6XPt+CdEKc/oSXX8tiPnU1MFKSpDgc9HvuRTuchCoDtQE6rhhCknUQDxKSX/BQwiX 2EEdWBg1YGF2D3Ad8BCgIzAYyABuQXhV8ByRi3SZ9lpgqdCRF2AXIA8At1z2UzVRiZoZPShevHQN PAS8TYP+Iw5SBwmjIQ3m5yHX55HvPYRHot5S4GPt4lI4fsl9C00CCMgEJmLM0v814ul+YxI9fDWE sPfwPTQDiHG5ARDP59q/lYZoTe3/LYwaVEMC7hjem9q6aFLK3dYzgtoa5wFScPJuAO4BetN1/BjS /Quwe+xexlq7l/cPu5fYZ7cyXoT7NNy5V2HmVXDDjY1X4a2r4IZfSr8J6Is6HixV9uHLZemWi3Z2 L89QhLemFleDv2M/dTWwTuIc9KJ22lmK087aXcAGeDjQCMgDMoBs4HaZRnCgJUUz0+5aAugasS7i VDkUxwqc8p5hNagxT6U4I8et62octb9z3e3+I4ZTLQnjXrhb298qUHv2AepzYP8AfMZrE1OwfweO A7b0629K2LbIs5uzcnY9totGsUPALurMPqVwPYxGiRf/HbD/jvLMBur8O6D91wN9XJboV8p9BfgO ytHP0LSrwdfYu/kbVBHgLis0tE9egbuxj95CufxpGsB+pWXsMD3AWtJSx72NHtHeJw73cvY7zdGm 0jztDvsI204PaBPpAZFKc9kJmsOOIP4IZQDLtAsIa0PTtHP0AuKK2NO0VYTTdvYUDWUrUXY7ymHj YGbcAayQp/aFYuAHNv4vYQd4C+wlmcAjTtjDQPpVYYuBDNRJfA6wAFjshN8EjOcD4Q8FsgHnS/YL 9wLZPAL+7kCOE/Y4MJVXhL8GEOOEPQs8xh5De54EnnXCDgDfMOgY7HVgA9L+AH2jEtDViU8EQrVv oIecBQ4oEF3sLMGy7X2If4vdZX8Pfp8x+x0Wf0lfmS51ELSpmXjM/lrpEMWPyzNN6QvFD+ipNFrp C8VLpY7g6AHb7Z0l5z0/bherM7z4lMwjz27+un1RnsM4K9eIOsXD5blpYOzkeWpMpKf0fPtPPb/4 Z/dMnOicheWxxwfs99VZVrzZ2Vudc6t4i/gdMuKcW8VFOJsGOedRLXtLybnDF5JXnSV2d5x38c4Z MtU9F/bSrXxv8Z3gaP1ltAH7uv4ZzRTfExff2+liDfZVievpBpFsf8NfoSyBkeOrcL4CkMvaojvW vsRcqitG0kjWi/qwXpDHXvatgCb3FH7QfkHk2N/yNyHTlSia10Lakj3hCfu8aG+/IUZQK96R2mOu e4g01HcZ4frDdB3Qmj9i5+o/U4b+KnWWYPc6cyn4KWeuW7AY+ozFaOHgo6y5vRzj8jTG5GNnPvPp Omc+J2AMJaZgjsbYN5fWHY1V9kH+Jca/JeJcuPpgH6nrlehZutfe6Klnb3TmGfPqiS+lx/nUPEtd tUT3wprsAXQWP9IGfY+aa+iaLXUPdNw5tNDTgFp6boS/Ji0y0jAm2UB/8gGjPANQ1sP2T3plWqiH 0iK9OvJL2agBHUjKhjz7Jdpg3jfaU0rpQzX1z+zPsfaEKIIsuHB1nMFSfxFehEmk2msceZEyJWVl H/CQo2s0cPSuEj3iU+oEEPbw+9F+R17EVmok5gFNaJqRS42MxXA/SgX6fuhn1dC+n6gKztzBxl0o v4l9XMymSUg/CeNIRmfUm4U65TneCeVJ2TpNbfhoCpVgx50zKEP0kOcFzsBSZ7jxGM6GG+1T7p7b BOjpnoE3O2faacgdIJrbrxrN7Vf0DfZJMRjn2HD3rGoPeejmuK+X55CjY+CMkeeccQMlq70ZZ8+f lKt/C7nE3i3yaBjSD+OHqI9MYyykZDGJ+urrqB//nfrz6fY5PgO6jEDdF+z9IhP14GwWHVHeE+ib C8jqgxLsEXoEiAE68A30MRAOtBQ+2scyaSYQz0fRZj6UqmPOZjky3ZyGsWjYMUXUFHO5E0gF9gOF mKNtwDjgPWCqzMNvse9hOygNSAduBW6DXKUDowHpnsKnYB10sBdjH3iPX6Af+Fj6inegT6ADtAWS EaYBlT3taR7wdAmjj6MRvgnrbS6wjN1Gyew2+3W2hLxsCXg7dWXb7c9YMsKTwZMowCbZB5EuC+k+ QbpwpPsE6ZKQ7gjK+hbYAfQFWou36ElxA90NdzwwF/v4IX47HdKx/+sTibwdiTyNgC4OVzLW0FYJ 2J8f62/QG/rndB97BWN+wX5LbIS+GKBIlGOCK4ok8sG9DXEnsbdegLuD6As5CkDf+ZZq8MeoPP+D TDADGhp1qKN3GNbWBQr1tIDMtsS+9Sz1Zt9g7k+gjuP2hyLF3sd/sT+DLI/jr0KXTaT6opN9EWU2 AroBPtR1EHgHOAz/YEC2Kxz+s6KQBrE1kK8VGO87ycM/QrmzIYf7qBfWQwP+MZXjX1Ft2R6gPX8M +8tjZAE6UAVoDgwE/EB1tC8Z7bsF7dP4cayvLijzF/K47eul2gcEsP4utY8quFzNbd+Nqn2Q6QTo Dzr0hvWQrSKazI7SdLaOZrGDtJktw/wfpflwL2H7ke59ep7tpqe03bQNGMUT7DPI62XrIRdF9nZ2 1N7N1uG8PYhze5n9I/yfs4P292w/0r1vn2K77aPIJ7Td9kqc617kjWR59lesEPIywf6I3Wh/y3CO sVT7JLsP7hz7GNLNRronWR50wkLI1AToNzdifUylGSyVJrD74M6hPPZZ8W4ejz31bmARzvPOLg+3 f9AXAOeoj4Nl1F4/grPnEOwvDyXra6kN3G30PPt1/RPq5L2NOul3UzvPHzhXLlAXoLsrq42ANi6u AwYDsYAAdBeJ+i/YE7GvGetpsuiDdBr2b5Qj9Q2pB8gz0+iEuHH2K9BnRmDNLQDuBjZKGJtoorFJ 85aw7xZaYMTRrWIs1dG+gK4DwP0/hBbxX7m/kSh159Ka/2y/DSDM3gm8gbC2OFPjcaba/3TnYQSu jZK7CaMKzbgW3LuIng5fsi9xTrW2X3P5TTcMbL8NvFUSVup8iefH7BXAY8CTwDIZ7uiQZ+1fLts0 9lagCNgMrHHCzv8NSuyD85fQ1+VBkl1bwJAs7rE/wNi3+i/cnTgodd9B0BFnXAnoMWFUA2fCmVL3 C5VLIUyG6ZnXRsmdgD772nDvASIk/yu520Fj+Umqyu4hCxgq7Vm9ArVwcbN4AfuSwgjoUFNg40Xj TGsr7djSNnppO1zkkiXaKRgbL4NXoD7cR+t5ZXqX30Tr2SbYQAtoDZ9GO/k4WqMV0RrsG+PZKfA4 yM1SxMn4x+ltGSaZW4i7B/tdEX3CJ+OcrED7xeP0G3sbZ8DztIfdQD2hi24HTjDYOEANrJ3KQBO+ QxOwCZ/jFbXyQAL30x7ut9+StgbQTrM1C2gPlAdasXHF3wOfsdX2pwpaXaC7tg/28WrkKY3p9kbg Jx5TvIfNv/gG6o1GnnnAk7xF8VcOKhZ/yv3FP/A5xR/ziOKD6ty2u/A59k3AH0TF+9HuibLtLta7 qCyh7ZN1ocz5pIHvQ1uaAl34Um0/X8pCkH+ti8YumkigfauBXbIuMdb+Au4w2IRH+BytGQD7UJaB vXAp1qNmzxAaveN8kbdaywEe0/ZpFYFGGK+NwHuouwfKaAkMgL7VUrbLwTfKrkN4Rb4WZ8dqrSsw 2jMSevpI+tozUiPwVuAEwpYbH9JHxvtaNfhfAn5H2FbtpH1OO0m1tAP2nygrkv4gBjTVztu/a+ep hmYT5ogaaIvtk9piKoewSKCPZtsHER7OwMxGuhHkATpqg6CLDqJG2hbwFhqsvWZvBo5Ax9zKa2sm eB0Ayxo20itaDVFdGwosAMKAvsBkYAPQCpgA9ALuLmFtdPF+9P0b4JQcCz0Je182dNo50OuaQjd5 k1Kc+/GfET4NesFBCoE9kwZuz5+3r9MLYFttpXZsAI2Bnd9IpFNzTzmapSfa7Z3990YaodeCLTgZ Ni3DPg67FfbddGnP6Pk0Um+OcoejD5/ZP2LNh/DvqZ7UGbzfUFtvK+jnjaidPh5n47ewjzrAhsG5 gD2/jbO/X+OuufT9v15H3ctLe7rkPEAdnpKyZZynFtr1k31M2tmXzx17rzx3YI8/Ie/rka+tzCtm Yu+XdltrjAfqku11bHjo0dj3Gzj31O65dfU5hHOkL+Imi272WOj2LYRpt4QOukLcb5/SR2HcYO9D 56sp7UPYZyliGWyK9dCZZJvkG4YDe/EV7xamvdPlTZfPSvt6oMIV7xQl7xIO7InAZ+hbDPp2W8mb A3TO5XyMfdRFR6CttEtLcPm9wT4DfP2X/nVy7dUr3hLste7bwael3hHeVu8H9q9AP6CF3tr+BFgN 7L80jy/TAmDgFe8E7ltBqXeBHnwe1YcsxsG+H4I6I/Ux6MsbsPGO2Iek/EJGz0FXbS6mYyxbU4wY gHP5WffOtyUNdO5whyK8u/2dvLtkM6F/fW+/IO8i9aXqfpG3wHl3zLkfHCUqUiXnbu0obMtCew3G 6YJnHNbCb7D3OqAdKBdny/Xu2f7XO73zsA1K3VWj/AWOTYq6S/QBvspeIW1PWa5zb9tKlVtat0Ad bzr3sG6ekrvPS/WgDCffW8gXQU1lm0vyX32fKnUF9oi9S3wHG/J9+3fjVrQNgL2ei71Fc/o7lfKh v2xlKXauhGhD7dl52AfFVI3Pp3VS1+ex0Llr2n/yz6FzvkTTpF3qtjsGKIe+Tpb2sas3nQHGue4R l3UmeyBQs+R+XZ7rl8agFWwKh+2bgJu1s8UVFOxMde9snwaGIOxXFwOAVo4tnnPF3XNF5J8CpPzl btm9T1bjWXzMxdfuPfKdpe6UZzr3xrvsArareAewDuUNB+oBSaXucEP4DvvjK+5uS+5vL93VFp+U 7UFZu5w0UneT99nybnqelBf7RcTVERMxjtHo53XIc4pq8t6wc47Zn/F+FKsvwZ59hjo79zm1YQO8 RELURRtWYq/q74TXhe5WTXSnGL4Yc55kJzrvVvWpHptMI6HPHRQ6xRvzqL94yW4ndTgjCvray7Dn 5L1QLvLJ+77PqaO8wxHfK12O/4m9XL7TzIbOORv2y51kefZRUy90LP1O7Bd/UDuck/GehdgPoFui nj6OznitdyJX/3Te7kre1XT3Lgngs+3zJWXLOGMd7J4V9jHnHeyS7mqvkv1kYcXbUNcA5Cvn5I+0 n3HeuFYSd9qN9jr3VK/hvDHQP3kX6uq+V7+dYZ9PQNxS/hJszQv2F/wWexZvSrdgzt4QK21bxGNP m2tnO3dha7APRUI+9sC2lvZ3U/soawQ91QBWUWt5H+O0tRXKdGDnX/EeOd+e6fLky3q4Hc7nFp+4 4v2x5L3RAfI8ZD+CPkfJe7mSt0Sh29PUeyLk+YJdmV0o/lPez5Xg8juivRFY+pd+q3fCBle+Edpz rnojLP0+CGDt3lJ8DuOyFMgDFpZ6B2xc+i3QufcreQO8/N4Xgb6sQjm2TIO4SY7cXIDOM9AOQ3vq oB1V9QS0pTvaNw95IOuQ53PCh/G8+u2tBBOv9P/l7e0a+DfvP//mzccoIst7FvvYPtgRL8B9Gu7c f4/SNsg/4Yr0/VDPg/DnuDiiWMbplgvYN56h/1D3xP9aG2CHJbr7fZx6f7W/57e5+30/nCdfwPY6 hr3Kiz0sBTq8vHcdBjSHjPa3c0Rf952yL/avjymLf0oD4Zd7aYwEy8A5JdEL+jLOPuzDrXgrSoTN 5RHPOfv79S7kGdHE2evH41xtT9fpO4BnqJW8/8cZt8fBBw6+Av5kiynIFtJwfhhtOyzLtj/Xjtnx rJudpB0jkz1mx2C/L8+2UXfxGFXFOu8sOtIw7O2H9TP27/wN+zBfT9m8lX2cfwLg/OUv2EVSxwMW 89vtMzyZPHoDGsJPQ99riX1pCPSSG6BzPGXH8g/tA7wd1Rb90ffbKVLmMZ7GOXyM2nsGUnu9PI3A HjJKX0AjjH6QzZ9wVm3HWmhKbfhvdjHKG+agtr1Wn2TPdHSLWOzJcv8egz1tDMY7hRLkexnOy/dZ tv0uP4C9/5xt6xvs06IQ4/Qs9vaXoZ/Pxnzdi/GqQ9cZd2I8tlAE5qQ70Jh/iTV3GDrRGfBQ6NZ3 QffLJa/+A4Vi3f4kQqjQaIszIcf+hY/E2mwMHeGwvQN2VwPoZOvFTVQPZdTTn6IC0ct+U9rUogp1 cOzq2vToJbt6E8r4T3b1A9AFpW39Jz3j2NfStnbtasemfo1mwaa+X75dYt+Z5bx/um+fbDNwM3SU bCqUb6DaVBoh3z6vePdsibif6AlgrnwDvfTu+SVNw3g675/sGRrGTtjn2W20kX1FC/gHtIm9Ts20 qfbnjKBn/26fRToNaTqz2+yL7Kj9NP/Attnr9jQjE/v+GzRL7MLaaGA/5ymwz+mD7LOwBfL5aMzd dcCv0JkbkIfnYV5aQ0eNpiX8gL3beAS6RxZVYsuokkizp4kDVFl8DEhdazl0h2dhmzyFtXQT5Ku7 /YXxBtbC/XJdSt0GZ9iTOKOy7Hj5xiwaQh8ZBP1wM5XXIWuwx5SeeaOzRt+FrhHLJmJNjLD3YE0M Ehuh19xnf4hxmMna0FKWQ4+y72iJHEv5pqztQH/Vu/KLWKe3aOvoWYzvfO0PmsoaUHVtG92jvURZ rActxDjOlWPJo6gc8ACwlJ2m5XwTymtDGcxHNVkFeoH3pTt5I1rpzMtBYAf1QXwOWw7soUz2BPXi lTEnv2PujtN98i1bvldrZzCvfmA96pFv1SvpAW0T3cE70x2X3z00Dfbvn/KegC2hH4HdJXetojf2 tN500LmLke/Y45w7mWgeUfwLG1f8Ixtf/DVrTQ9LoIw7gOlsNd1+FZoCC4GN8m1dvqE7b+aynjDs DVdBXH8lENYZ/HdIuBpILzn2aiC8OvgvQHgn8LVwdTv+Ll2nf2jHtcLjwH/B/7Qd/1BuNPgv+If2 9QZfC/+2HX83zjHgv+Af2tEPfC1c0Q7I1RgJ3qL4E7FU88m3O/ivczEDuIfNt99h4+zRWO+j+A92 Bp9T/BlrTlsQ9wdwHJgHJIlEu58EZzhbaxM5iFF3hJ7y9A4wgv1q/8K22b+zI/YpnF1Pw/2N9jnO lVKQb+qlQXTxUQleF+WVRoyLvws/dRVKwuV3HhVRl7rztBx/aVS8CleVw5qQDoQ5dxfye9BhmKMS TqB7xElbB3dx7lAysd/fRLX0V3Fevwu9vynOrE7Q0a+nG/gi2O6L7CPOdwv77YvGm4hrgz25PWxS +RacBntY8UPy+wN+j/2F1HP4bvs7cQy25vs0mXfHfg17X/S3q4qD2Of3QfdW3ykKxfaD0G2zhO/i BanjOjbA25QB/aGhPhg6QCHa53HuFuLF5/Zj4vPiUUAj4Dj8y8HJQBPX3wWoc9Vby2LEjQQaAydd /wi3jDPGU/Z24DHjqeJRQCPgOPzLwclAE+nnPxdv4z9fvBWYAPf2Uu4xwCDdX/yq7r84GZgAdwVg O9yTXH8VYAww2P0m5gWE3wikwW26/ptcv9/A+Wq8XrzV82ZxIZDlubV479V+FlW8k0VdnAlMgTvy Gv7xQDKLsgcDU/Xk4l/15IsbgZlwHwFvAm6HezGQLjoVy+9s0kWdiwEgHngNOIcwXdShkcB0+b2N nn/xGSAf7ibAIbhXu/6mwIPAaPfbnF+M9sUpQAu46wP74U4Dmkm/p4v9p6dL8c/esOJpwADPu8Uv w/873NNL/Je+q/nfiJJvdP4Ol77b+Vew//yvAHq+yXrZdwGzgCz4fa5f4kYgjPUq/hWcAvwG3ALU BTKB8f/xO0L5vZDEld8JXQsmEHJVWMcSd8l3RP878F99u/u3MPxA5X/GFd89XwNX3kH8z2H0ApL/ Ge53Rw8C+cC98MeA73P9twGRQIzznUsYdMcwW3671QkYC0z7T99Jl9x5yDsJueeCJ7s8BHwjON31 l8TnuNwN3AMsv7sZVCp+jMsR4ETnLslH/cGJ4IHqG7n/dTAWAyv+Ge6evwh7e5K7xx91/cklfncf 3mqEFhcCWfru4r1/8V+5jw2AOxH4vfQ+5p4di3BGJLlnx1HXn3zJ/y/2c3c//AV7X4qz/3UtTnT3 wzSgGdz1r9Y9+NKr9InS7lL6hMxTojNIvUD7jUaVQL+HSNxHw51vLhfCbs+lFp7q6vs+cQpr4CXg Kbper0/z5duD/iE19ySBe9Io59u9M7TA/ZZgCPSD3YYO/zuwe+Y4aGbUpcES8vtA+d2geJ5a6En2 Rox/c/0G6Bvyu77+l9+m5LuW/HspektKlij51tB5iyr53rD0u4z8/k99N6gwh9Jg1zWT3wfyXNLE bvddJZt8xr1UwyDolC1okSfM3uipiDaUx/5WgebJ9z69i71RTMU4XUTf5LuIAbv0EYoznne/oeuN Pb4tUIW6iwegB82B+1eK1U+BZ8HGhx4k72b4e1hH71FDwZxv4fqJIPWBvTlIGLBTDkKHOUhN5Hd5 Qurzk+xXxWCEPwj75RD10Y/aJ+VYwc6lkjcUfsy+gPyREiXf87nvHyXvLuo7PYBPt3++4pvpQ1RX fiPofHtnwN4uVvfzTtn10OcCSufbaazRyH7V6Ad9vT91EHdSb3l/JXLQtjPYu+T3ieed7ycJctLA qOp+L9mK6otxgBdYhX3kfYrXWyN+DtVz9hqp28k7U/XNw1gx3N6t96d8kQF9rgkwEvMMXVFC7nvy O0znW6vV9hrn7338JL+FpGnGwsv33/Lu3Nmbu8s3LYpxv93kzn13yfebJd9mSj1Tflf5KWT7U6on v8tEeV3kd6Dyu0seaZ8WIzAW8p62GoXrF4AZ9ADm9wHI4RojD2XthM1wFxXINwWxAO0i+TezMQ4u sxfV/9xAG4qwAeBtwJLS/ysE+ysgVgTkt8kYw8/tc7z4YmPo9Br03MOOrV6Xpoi1wDp6BDb5y2we efVImiOGY2+Va2yj/Qvy+qVs6bMozjOSmhvh1MSzhOoaNXFOy3frM5TvPUa1xK32E+Jl6oq9Mkmc sw+I2piLdpQiv8szImmEPpl+0pfRT873eZr8ro8ai0HafjGIXhVknxGkvaJQ4rbPeMrR7eIGukPW g3bUFivtnXoXrD0P1uftNAKy1FPUt5/kI8ni++wiMZCG8zaYl9q0DLgb2MCGaL2BoWwIxmsI1Wer 7WPAOfEdpXlOURXPAfus52H7B88Caoe+Ndeb2y95GkE2PrR3eZ5F/07Yj8rvvsWP9gXvGzRY30Ip SEsyPdZRir6DpulcriN7o9Efa5LZu4ytWFNj7Uflt9Dy+1TP45CbIsj9SCKZnrfAen2D+up7nTeG 57FnxOuD7O+M0xTPF9urnW+8h9P93kE0SK9NA2RaCUeudzt26VGMh67muHig/Dt8LJnKabsx/1Ox p/iLD/pW0E/iE1rAPqFZEnCvA+fJ8P8E2JNjIUDnUXY78DEpTc6ev7SUnRhzpZ8NK3UOvKLsWn0A E2y6/TaP0cL4Uq0N0uzC+REk+S/nEY1ndzjfk9O/wdU/pduDcfhCVNIacD9Vhv+AapvGeA/N5N2B BXADbAKt5JlaPNIfAb4HHnXXyVfK7ywtr74IZ+6i4gLgD5Fw8SfgLGzWYcD4v+h6Lv6ib7nge+wT CtT3Cn2ilN6A8U4BZgA4FS9uld/KA5DYC62AcUB1oBnQGEgFOgK3Ahj1C3eXYhmfjjJuAyIVit8F rwK3V3DqAi7YChcvuJitIP+dRwePKlxMUCgep+CkS7gKPqATREbW5QduR9nvADsQ9ibwMfAa/B+A nwJ+BCBX579DWBuFi3NV+otNwXtR10QXnyhcPKrg5JHtbut+zyWxUeHC+y7qwd8c+Z53sUPh4msu ML4XuwBZSLsLcU8rXCwB4i68gLC5Cucmo95NwEVgDXASYRjT818gHeT5PHbfC9iOzz2D9COAx4Ex wLMA2mNXBg8CHgYw9sUrgSkA2lKcCWA3L+4DYGe5KPtewS3jZ5XGlv+CxyzgbQAndPH0Un0pwZeu /Lzp/v0ZKU/PAYeAmwC05eKtSr4uMeSkeI7CBfk92ZNXIdVFljtW7vherHEVfC4sF+EKFy64WOVi tYsTChc9gPw+balbn+l+0xbuylF9IA6oCmDdXsDcXFjo/p0kjPXF9i5WAMuAz92xPVCqz1gTF1uK hOL2sAs0gAEp8jtR/o7d84q/r+f+XUDsgev/bwI6WWv5bTf1tf90/5b2gDL8/wUsWIYy/PfAU/7P Qmwrw/8Uep//+zDu/38fPOvLUIYylKEMZShDGcpQhjKUoQxlKEMZylCGMpShDGUoQxnKUIYylKEM ZShDGcpQhjKUoQxlKEMZylCGMpShDGUoQxnKUIYylKEMZfg/Co0oNEsLUhh9Tx5i4ARKIbIqVqlC wvknWhqwKPzmJH/Snd/SrVHA8Uk3o8qU77o5taN7XLegOFruunWqSjtdt0Ex9JXr9tBEraRML9Wj gOsOoaA20XX72Aptses2aZho4br9VE/c77ot9rDY6LoDlOXpd+mfl2ni2Xrp/zfu8fzquhmZnpOu m1MtT7HrFlTBG+K6dfJ7a7hug8p767huD7X1tnHdXqrk2eG6QyjMO8F1+7QB3jtdt0n1Qz5x3X6q 5Cv5p28srY+vkusOUAszFS3RRIg7zsqtxlm51Tgrtxpn5VbjrNxqnJVbjbNyq3FWbjXOyq3GWbnV OCu3GmflVuOs3GqclVuN8yoKUhNqRI3xO0h9KZPS0MpcKgDGUiHCOsOVT3nO71SEZMKVQw0R05Gy 8CdIgxA2jsYjrsDxZYAzkHoifqcjZWfky0KaMQjLpE7In4XwIPVEDhWTdo2a2zh1l84Z/Ju8w5za CtyWBak56myJ/lyZu8Gl3KXzXl1DptOHVKDQ6W86ys4G59NNCJMtkzHjEXrt0Rrn+CdgvEpSp4Gz 4U9F2zKdsWlIfZAijeogrIDqIk26U153J28uyvn7VmUjPt3pr+xpgVNqgePKcNLKGsciNBvuLJoC 3yS4ZItlmgkosRDhsjbVzhyUlonf45xSct1SC51eqzpznPFOc+Y/xx3phu4MyLoyHKmYgPAMJ0e+ E5LltPryOBdQvFNythOS5ZSYilFR4SW1ZKOcLEfG8txW5iAk26lVlSn7WViqBbLGPKcvSkJL5FO1 XdaUixEIov9KRmWr1GykOe3PdHpceEmC1ZipWoJO23PcfqnZHOOkvNzi0j2SozbZyad6fRP8Df8i xbWd0rKdEqY44zDBXSulx7tExmTtk5xRTXXnJd+RBsmqRjnXQVfiVG9UG8e5aeS6mOqWXoheqBma eGmWUh0ZkRKefUW/SiQ6DS1JdepPc+tv6IxUIWpsg/MmAbnln4aOzF25Hhq60p8A9xRnhsY5JeWh hCkIlSWOdeZLzuSVpZaES2lWI3fTpfKSHdlVozjF6X2BM1qFzjwXOHKpcgedcZMykuH0MNOpI8Pp 4xgnb8lId6WhWJcd3bz5pWKUfKU7a/ayzExy6kpzZOpa9Sq/TJuGcZ7grNr0S3OQ7sRLKVc9KBn3 PKenOe7Iq7IynN9Skq7ut4xXElsHueROItftmEs1XatVOX8p+d+P0eXSS3aNoLvuC512p12x/v7a 95LVdnW72pYaAdkT1Re1C5WcPPmXdrR0Z03nOGs79W97qsY59YoxVSsi1/2teqXcExzJm+DkTHfW h+xNxqVyZMosZ4390wz9r1oXl9dEgtMauQbUztjQmas8mrwq2KRR4ybBvplp+bkFuWMLg51z8/Ny 81MLM3NzGgY7ZmUFB2WOG19YEByUUZCRPzEjvWHn1KzMMfmZnXKz0oM9C+FJu5S5TdCNDJaKHZaR X4DCgs0btmziRjeQ0Sq2JENmQTA1WJifmp6RnZp/UzB3bLBwfEapZo3Lz52QJ4PTcrPzUnMyMwoa 9pmQVie1oG4wPSPYPT83t/CKorJz0zPyc4IFqTkFQTQ8c2xwbGp2ZtaU4KTMwvHBggljCrMygigz Jz0zZ1xBEO0rKMzIRs6cdFSRn4NGN0QHgmMzUgsn5GcUBPMzUrOCmU6bC+KDBdmpGJq01Dy4ZZbs CVmFmXkoMmdCdkY+UhZkFDoFFATz8nMxoHI8UXpWVu6k4HiMaDAT3UgrDGbmBAvlAKNlyBLMysxB XejmmMxxTsGqosKMyYXInHlTRsOSIa5dEMxOzZkSTJuAWVHtliOWkzEpmJ+KvuRnotvImJodxMCh GpQ4DiEFmVORvDAXHZoou5QanJSan63qkgOdNj41Hw3LyG84vrAwr01CwqRJkxpml8xDQwx/QuGU vNxx+al546ckpBWOzc0pLHCTSvfYVDTuJpkuOXcCmjglOKEgA03DrMjoYCpGJCM/O7OwMCM9OGaK 0+iuQ/t0RGy+48F4pU9QIzNpfGba+FJ5wZk5aVkT0pEVPUjPLMjLQgWy7Xn5mUiQhlQZOYUNgyV1 5+ZgYOtk1g1mZI+RmS4XlVOS+JotcpJL0cAwFRTmZ6ap+btUu5y2krLaOg2ok4laIEJy8eRLQUvP nZSTlZtaulK0OVW1FBOB7uaiKvyeUJg3oRBiPDEzLUOmGZ+RlXdVh/7NXDgzkZCeMTYVwtgwtSBv smtT2aeBqnQXXeNnbQjfzJ5cF94sYjN7ZF315qA5ivLXVWsJullRnqKR66q2Bo1QNFxR9LoqbUFR iiIVBRVFKKqlqKaiGoqqKQpXVFVRlXWVu0Vs1r5X9J2ibxV9o+hrRV8p+lLRF4o+V/SZov2KPlX0 kaJPFH2s6ENFHyh6X9E+RXsVvavoHUV7FL2t6C1FuxXtUrRT0RuKXle0Q9HWdZUkvbeu0lDQFkWb FW1StHFdpXTQBkXrFb2kaJ2iNx3izdZFNAA1VdREUWNFjRQlOHPLGyqfta5WAsh0iJ1fV7MR6Jyi PxSdVXRG0WlFpxSdVHRC0RfrajQFfa7oM0X7FX2i6GNFHynaotriV+K2SdGHij5QtFHRekWblSg+ oehxRSsUbVC0XNGnih5V9JiS1vsVPaDoXiVgdynfnYpylQjfp+huRdmKshTdpOhGlX2oomRFSYqu VzRM0WxFgxUNVLRMUT9F9ygaoKi/or6K+jjEQ5Wvl6Leiio7QsQqKcpRNEhRRUUVFJVXVE5RmKJQ RQFFliK/IlORT9EQRSFKaLcrqXtNSV0tJUs1FdVQFK6omqKqioQSN67E7WclNj8p+lHRQUW7lYTs UvSmop1KCt5QtEbR84qeU7JUXU14CzU8zRWlOa3mlVUjKimqqKiCovKKyikKU6Sp5pJqrq3ooqIL ig6o5n6v6DtF3yr6RtHXir5S9KWi11WPdijarug1Ra8qekXRNkUvK9qqaJXq9LOKnlG0UtHTip5S 9IMakAcVLVI0X9FcRQuV6C9QNFXRFEWTFU1SNE/RREUTFBUqKlA0Rq2O0YpGKbpBUaqiZmpWmipq oqixokaKUhQlKGqoqIGi+orqKaqrKE5RrKIYRXUU1VYLiCkRjlcifEbRKUUnFZ1Q9Lui44p+U3RM 0VFFvyo6ouiwol8UHVL0s6KfFP2o6LSig4p+UHRAyWcDJXXxiuorqqeorqI6imorilUUrShKUaSi CEU+JcIhiryKPIoMJcK/K4k8rug3RccUHVX0q6LDin5RdEjRe0oi9yk6ouh9RXsVvatEcY+itxW9 pRZsnPKtU6JYpOhFRS8oWqpoiaKHFb2jaLVDXFfCt1jRLEUzFM1UNF3RbYoylCi+pChT0XglL2MV pStaq6iroh6K/p/y6zy8iTKB4/i885ajbZJp2lpsSzpVOcTooHiBRRkKhEC0B80LtEiLCIIuR0w6 VguRyrGiHAVE8aSAeI7aNLi7YVeF3XXXPRWvvXRXvM9duqvuesdf+vNP/9fn2Tz5zmeOJO287zyT tpZMJjaZRNaTtWQXmUguIDXkPDKBzCDTSYiMJ+eSobyEh5DzyWAyiOQRSb655gWZSqYQjaziNZgl X3HnEm59Sb4gn5PPyKfkE/IEvxEeJ4+Rn5G+dOkmkBpAT3ICVg8gquynimrN//nC5n/Rx96Z5mvo VXTUU2f+Cj2Jfol+gX6ODqNDhbPNJ9Cj6ABKoz6UQr3oEfQwegi56EH0ALof3YfuRfeg/ehutLdg qbkH9aDd6C50J7oD3Y5uQ7eiXegWdHN+h7kdbUPdaCs6KJtkg10w29yCjc35i83J+XKWbMC/3qZs pGJfumQcTnov2ZMuzg1BD9lOtqX9NugmW8kWsplsIjeSG8hGcj2pIxelMbgZcSGJkJlkBgmT6SRE ppGpaWMamEJqSYAMJ5WkgpST49OYy4wYRsrIcaSUlJDiNGY6I/z2HPgR+hD9B/0b9aNj6F+Y8VfQ P9Df0cvoJfQ39FfM3l/Q4+gx9FN0EO3DLO3ERGTEbRzsW8nlHJilZAm5jCwmi8ilZCG5hCwgZ5Oz OExnknHkDHI6GUsschrH51QyhAwmg3IclPWyLl1jnnVI1mlTURTJ7GHsHHNq6ODASnFZKCMeTpeU 4k0PpUsqgUseTJecBB4g95P7eOL3knvIfnI32UVuITeTnbwebyI7SBtp5fnPJxeTeaSFNJO5ZA6Z TRSJkiYyizSSBlJPguQUjuIYcjIZTUaRkWQEOYmcSE7gQFcTk+QRSXQiiGavw1WaRV+hL9EX6HP0 GS7LT9En6AP0PnoPvYveQW+jt3B5voneQK+jZ9DT6I/oD+j36Hfot+g36Cn0a5RBP8El/GP0I5QR vZyRR8huche5kzNyB7md/JBsSPstsJ6jt46sJdeRLrKGXEuSZDVZRTrJNeRq0kGuIg5pJwkSJ1eS GFlJVpDlZBmZTGxO2iRyATmfTCQ15DwygYwn53IKzyFFxCA+4iUeUsg7UgHJJ0PtsfCfmJE/oz+h F9EL6Hn0HHoWHcEs3YSbzY6BG84POPhX2CtwHhvkSHO9tMx1wjLXhrvUdW6XWhNOqmvdpCpM1iQj SVmYrASrkm7ypeTg1eFOtcrtVHmdpZ16wTXhDnW126EKO4TnqrCjos4bzkeOLHWiziKn3dnpvIAd Q/Y7jzpPOjKTPWwXO+NrQl3ONkcvxXFdc4SR213tFPpC7eG4SrhxlRcfEY/G5YT+uNDtuFgQj8V1 vOhAfMTJodyLK+NlFaHquB1viMsrwytVzF2pVoSXq2PLRdHkAqm0anQESc2QUa1bRu2sri2LLdPz r8DZXm4tUUvdJeoya5Fa7C5Sl1oL1SXWAtVmzVet7nx1sdWi5rktqtmaq+bg9bOtqFJuVDVZjWqW 26jqrTpVh/0XWRF1oRtRM62wmuGGVUNYTLdCapo8x8Q3qVaFZ6yqq6q/Kq9wQSAW0GOBo4H+gIwN 7x+ur6kURsWaiu4KaWChc1FulneX95T3lg8yBlakJ1bcVazH/F1+/XS/7T/iP+rP0/x7/LrRbfQY vYasN9qMY0bWyOs1RK/vkO8Zn6z3tflW+qThy23LIttnnREyvHbE9I71yoljvZO89V7Z7RW21xoX sr0jRocmeeo9bR7Z4xG2Z9SY0LGCbIFuF+CAnT/qNCyGVYY0KaqF0EQRkENzcyGOM3GT1w6UiUEC fxP0RZuCwUhmSHZWJDW0YV5KbEyNbMot7caW1OCNKU21zJvbJ8TW5j6hT4mmSiONLdzesGWLVhuI pAJNc1N7As2RVBdW7NxKFitaoK9Mq20OtiacRDAYTAQT7Vi2tyawp93BcwCBJXTac0faE1ruhd/+ yB3mBwUTThvePbAvkftcJ5jbypX7Gd/zx/ftNxTf9S/wf/04vq1V+xrnDJXUCmVuZHN0cmVhbQ1l bmRvYmoNNTggMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggODU4OT4+DXN0cmVh bQp4nO1dWZMbx5H+BfMf8Ag4RGzX1YffZJs6NkxZJrlaO0iFgguNRDkGY4mkbDn2z2/lnQVggMaQ G2GKkB6mP6K7jsyszKqsrKyfrroF/P/406uwgP9ffX+V+kUZ+sX2aij0dINPCR4S/3159d1vrv5s H3frPI1dmhb7D7XE//gkplr20++ufvf0KkT8qP4ZurSOixzWJS6ebq+eLcOqX6bV14un/3n18OnV T7XUqSvjWD/Ye3i9ub0K/VS/L32CArZXKeR1nwXfKM4R/tzI6wK5C1DLMPXdMC72H1wt9Nl2r1TG oc++FoWulhl94c+2e6UK7oY1MoRfFzi7lsXf4JW+67qy+GctZVwPTd/KOjgSPbl/ma4nWKb25H5l EqOhPOt5HO9ZnAqKp/TbFCh0NEkkOookvg0dicVGR2H5Ex1+Bz6uAy7bgAvrLtOYw6cY4zqPlcvT uqdxd7t60K/zMMZhef3Lm5erB916jH03xeXfVw8K//KjDsyg1R4oPQy1qEWJY20Nlf7Fqqfilp9p EYc+nLo1KBz9cvlgtXj6tzvfTuspNvV8Uhub1t3y1WpchyHV1m+1vu5Yk2MY1v3oa/6t1Nxqrj1C gv7yTXi4mta15pBrpx8M3Ir/Wj0IHT4vHy1WlY2VnP1yUVvZd+OwfBZWtfoSw7j8eqENrhWXOytm GkNRXPFXL1a1jtTlvLwBcvdTGZY/XwNBqD2vm6Lv7lMYxnUlRReBF0CK58tjXBjjOvTu9We+45/B Y055mJbf1H+e+J9fbK+PyUFMOGp8mc+X3aowjZ6vPqqUq49DXi6OytMY1jkv8jit0/G2fY4MqjTr l3+oxKtUTKWWnSpBq+jX2sMqu9pn1Fn5E47X+THQYyp9Sa5Oe3oMkhRRPp48qU0pxNvny1hfkabM aUkfRaafHeVjrlx3L9++PDr2ajOjf/34SJ1gdNnbz5ZvKgenkLqy/NeP1x+B+ENHF5UNaV3/OS9f fPvtq+vXr7/+aFWHJjJBh8txnqP05qrZhuPkf1grpYHxaSX1yPrpyZMAwwjY4lvzvE5KyjyqU/2p l9FznOg4eNzbJ6iekI72+nGqD/DH3p5B9evvQShJ6oD8R0dpCW35R1sTS163jfkB9QEK9e2bFbQA 9ON3R6vska2+lI/qKCFdN0csqroWTcAC9hGo49PfV8avx7aAx59DB0A00/J339ye0ml19lONuS8A ZDugHnOq5kQvQOtnsCX3E+64CvGAcGcn3DPImOrol4H8DESGBemkxMDI6t3nxyWmTsuqjvGV3SW/ rBi2LzbHBXacXXcfgE3ubRCXYx+MbUsb3p7kaBrTKXX1x2qAyFj8CSQe+fkpSSCai9+jBUNh/Bg+ o3f/WG0FPX3ztD6SSLjZiKvMPdocxr73xrDM1oXYuaHT0frsC5hNkun2vbPG/bUyk56+hFfp0RrU 0FUl+Kl+9PPt7fXN8XHYNW06IQbIF98DGOdfg9IhUs1hbhlOTT/ekjduuLs3D0uEo+piVeIaxs3z ZX8eR3NWBfTsDdjLWnScQfsOtYd+fWL4o230dV3fbkB/ofS8+PH4DHKCP66qOrE+YiqpW6nT8btr CBeriKpnbypoE9EHKdMMso7KkW2So/Y/Vg8yv5tXQzOe/IzuYInOVP5YywncsH7llF87RZk7Q6aO h0HVj8kX6vWZU4Euo2LXco5ztooBKHZX6y9AVG6u9iff0Z87ZyvNAqe/e9FGswjX2sXzLqZ5C76h gJOgaTuwb7ft5d68qKTcn67R0OqwyKowXEUHR+6M5XmslvzAJMLY/xdQSp1XU2Z4nFj7ZZ1TM48e zlx4F5zS+tb8tiozknXt5pM3oPUTjL9XP1glt9/jcr/+F07M3uoKcIquFlhyHxHQCfSUb9PXIHWB lOmBdcgcevdZlUs7c0QCEgtbAoYeNc5iJiXjAItmX49R8q0JWNAV5Qv3TovTYg2LhQMznJ9vQJJI Vx41HbDgHJtSXr8RPtzdI1Gx2+sXt6DCB5rp3/4ddCt9fGreTs0PpYP+Y8VOvd9+e/3L9be0OId6 /udfZ8lESIM6vo+NwW8+AxE5MghVJF0p9xiMqRIo1DVKp4pRR8lJ32UaK3HrunsE7bW9ymMAxz7B G4ERR9SNvCxwrh+++Wy7WyjDrupDq4LRXO+4/2q7UyKhNFYDoOULOqf8ENsuwIpe+jDLTSyFuFZC GdzM2UX06CXp0APOncEl6swihMNchFDnnCKkI15ooCciNecUQpzQMoQxUMRRV3iu9hYW9gn3AHiA 9zLZMq/4P/IxLZEjWm0r5egEKNdxVs2Rr/NFrWn5rVXnHs2Zff0atDhqntd+qnP3dCVN1K66lI55 T30dm53aFpxuBsrOn24F2u7gy6sUC/QJ1sB5hJcr7mm9HXH7KgJDKsRnmi5OhTYyAOcRMW3bRWwu YNyQSZGWYRV3mXGJ2Dn52foKOKKTAt0HBBO93Y2MO/g9rUcqLYDwg2+NUSJI252xA/kAHCLjHiqL 8M+EYZky6WbgRHSIa4GZXifNFyYkQ4CXAKJdBdyPjJES6LpFjCDqc0fjC15EEjmMBXXwPWEkccfk l3Z0DHCMTEJ/6kPFRfqYEcbRkWCchPyBRtzI5Ef6jaNQPwBdATfkr1jJDwJUh+2YHfdQBRGECfY4 CP2J9zTKUTYq6IX4JDgVE/Ejqh/ATubGnmlfIdBgLEx8FtmxMPEj+WJYwSsiTsSeiKAvq9rhwkiF al0DUUFaQksea+hIRNCOTEIE7uW0Q4VJqIAwdY6AqSMiCIFTR0QQBiTSzMKfFIgKzL0UiAjC3BRF Foj5CQXbZCNFEQaSnZRovHQMvNClTCNNhDKxR0+EFta3CEktyM8i/AlHqA0OLl3GTsIhaUOLWyYj L8FfG5fcLx23ieyEjmsmi477xL7KJBSn8ZWM6DE7pQIcMY0ziX4qveOm6ityoqo2I1kwbTcS1VQb kiiZthzYN+nE0NRsT+qpJ5K/vPrv31zdghb3tN6KdNfXWH0MpGGFFc1Q4NnNny/G4GIMLsbgYgwu xuC9NwaFlCT2Y7uDAcXxAKqVbK5arF+iWHmw8dV7o0IQQOgPow3aoxKdtnNQQSc+Z0PuS2r8EUQN DLTu1QYaljGvoFe0QRvHL6MO2GpvVSfcqa2NLMol7rsOlNK3A6P0WlY1xmKL396kX0Th/RcFLwg0 2+qRNqpoe1ZmZBl6VnVEBkNEMsI5iCnCogBic8hrtIPEKvGrCrFIxoAG+hUUlCCsZXPF2ESVO6Cq n7rH8MPu9SzHXsgchkpeOYbiwgyBrT29y+g8Jyx9td0pkdBk/tfpfOfrZJ7Xydyug/fqDuc7dUNs mly5LW0+x8k4OS/ldKazNWTztA6F5hlnOFrpcyXG/M+l914koPv5nMhkLmRoPM6DOZxPuFhxjy/U ic/ITsinqwdl+bP5OG8PPh6PJsiw69K7Yo/7XBMFU7tGuJrQ/bpdyT7ctXd/0gwslAH9yxDNMWaG VSCL+xVAnfOFQobMEJkYxt3EVoFLomguG44t7Cauh152UH7k+BIAOXvUo5ZhXGRaIO1Xk8MdYKza 9UPs9nFfesIw4twnqHBnd2ymXyTQEY8IlW5lXV7xQlf7oQ88s6dFPeDi5nOAaWVAMxjAtHIIGO4Z qlWhn2HDFBCtOgIG7AKmVUnFHf1OSxaIgqzkmHhFE2hslYnUbsBNEoBJMJyYqDjIOZsAr49sQAOG 5gNmPwjSDLBA+pXdIBGHZhnED4KnEwDz9Il+ZCcI0kcFMSA5WPYazK4PJJ/D0QlBQEaE0rRCVlYB o5UBM/25D7IyC6TViqzchAa8rgsZ941l1ScUlFUhn+UouaV/MvqjuPKCk7lXZD0aMAAWcBDZAN4X Wc+GgaigfiiSnSJ+KPotiJwhtVsvFGCmPspsUSfURN2WWYtgnt6S98heR++RFUbeI6uMvEfWGHQf aTvJe2TdIO+RdZO8R0YG8h4Zmch9pFQk75EROWbHAPIeGYPIe2QMRPeRcpe8R8Z88h6ZcNBE3oSH JvomXORAYsmLqqtYN6GWU5E1VTU4F4CJvHzOI4KcADZgpOrBO7ZssEnLR/OLIT9H5zWzgUzOWhvo QrVJHXI0oqbGYad6hHy1pmaYYaqF0FlrSor5rUqMnLWq4khYVAGSs9YUJMuaKlBy1pqCZVFl7Yue WlbN3lXSUH+r8i4vJg7oUO7sjI/zfecXG3GxERcbcbERFxvxPtmIpApku4PZpb+P2PHosfsSPY0e bbztaWwNYd7VO4jgWyCI04EOGsAPHfDfQePvBBvZVORIyZsd7FTCHtqw1ctZdMLWqwxV6cd1uJDC Vd3vDIU8Hhgazp/+bkz9RR5+BfIwwyOGvOCo6+1VHiYXhX0jmOKWb+R1gfOdre6z7W6hAofIupDf FjzfQeq/2+6VK1jtOb+/J/gzvIhjbnpTjCazHZFjbptaXJdnFsK8w8Fpncmzm6Hc9lw5qwTuSCM/ JZr8nEWNwluAQg1hzAzXLBq+GJJ6Rf+4klPpLvPD9z+sIkWYb/QcIvpM53hofelvfobwUzqyeNLp eyK0FedRcIS6WnD2Ko9vdYzu5FGWn0Q9x27iPB/k3WR8g3gUaAB2SRXUxm/4xTDKJIi9pKPMesY7 sEyqyj4G20VYvJ0jTrkcSj37RkH0OonykD5o0A73kbF3CX+wfT8r7o1mkVtZAtACRybKPKfU5QNP K3WizKaL1h5sunSWTCstXbawd0Bnybww02UPL9x0mswOA102wSpPJsm8ANQFFzsPdJLMC0ZZr/F6 UufI5ExQy8vLTzW+vDy9EYcGOxd0Lcmr2RvxadBiV5elvBamdSkvlHVdyq4GV1bWeDtCoWlJklUs RefRIt11JNm6tKf3GzJEITkFBwaZfTEVo1G8o9dj9hwQ9sBvusxg7ukyhGIagy5TmPm6jKGYyCCL nCwTsCKCxdO4JOs3msh1sjAFDnW6wiKp7WQBRucQdXkmUFCf/be0t21l0863VU3xStY0imfSllO4 k3VsZLpEiYSLo6fLJHQZNPSNI7YoBEupzSFayg2O4FJmcYSXMpMjwITXHCCmokDxYyopHF2mksTR ZyppFJwmYsihayqlHNqmUsxRHSriHCknI4ALk/HBMXY6fqQtMr44Rk/Hn3Slb0L8dPQKIWRwJxdY 4+g4KMVJ1DTOzTQKn6pVjTOJhhqEd6yhJqdpTaHxoWDVdyw4qgwxpNJ0Jcmd6VKKyFRNi0JLA3gn CtpIvRUfjL64p234dxkM946EvliEi0W4WISLRbhYhH9Di6D6w8JfCd+BkCubqxY7BMzgYgsvO7j2 0JoVVqs7iC1G4Fo4UpWKupF9G6nHECtoQxt7Nzt17VBRmdv4Mb9r+lwbDWUBG2fmUCdsdzWEKezU YJF2ZY3XPQJlKOwPDbHILhz6Hdj2i0j8OkTinP12yEASMh1CZ33D2cd0dgLYz07YqaWzE8C8VYrP 2i12r+kebBwxtdFoG/AAWUJRQwMW2I2SCOlGNnxj0F1Ydq/pLizyGHCW3eae3pcNeM3BdiP774AH 2btGOuihMTB8AHUfHMnQMcjk0NF98JidJ4jMMXt/HObA4xD9MxUlDhiyx5wjSJvRyXkmsr+xk/NO 3Itu0CCE0CP0QQiANQhhhNok0ptJ2MlRLLSwAD0DOjnHRRY1dnLMi9jXaZg/WlDAWRROodddcAbn SjLB6bKd2kNK5ObUHuBoc9fYuR322KVmnxJwHFvs9zWb95EOblPUKsJpq7WDpq3WTpq2Wj9w5qq9 pImrEYEmrkYkmrgaDWniajSmmauygCauxiCcuBr/aOJq/CVNYfxHPaLSQVNVEx6aMphw0VTVZC+y s3BspqoquuYP1akq+0Pj6D/Xk5TDuneDhmunEUWzFRtu1HAdjKRrbbByv3Uw07JShzpTTTUBrStN UzDRVZPE7NQMc0y0EK0rTUkRu0MbX2EqjqVFVSAtK1U9sqwFd94WiaAhFiSoqn1R57Ny3tlyN9pv VeCDxtLQxobxph0g9wrLupiJi5m4mImLmbiYiffJTAgntg1i58MOkA3KBstn5L3wYKMVl9bMBF74 UdrBQ2hzxT6tRvsZdoj9gIbct845dgBsxKMJI1o1gmE3/jtZbjGQIBx+mTZ89YVZ6lt5kpxv1bFM d17HA6OiDct6B6b+IgzvuzAczFiIDIhygdDZCQvTECnYj/PXDewNZlg0sgpfLvuBVTPOyvJn291C GSbRrvSywPNOzfJn291CGaq7nF4WeOYJ2qYj4Bsv50VdUSG+pVCINPWMs7RpSHQqUbuD8nzGcVop wegzvwTpiBcd6IjIzlmFECusEGHN3MSFqaAWOJK4sJ+RuNBKmZO40Nf5/5u4MKXRpWU8kbiw93Fa vMdRCh9fpa2IwrPPvuNnOIQPu0SF9scMUbAr4yy7S1xMlj0lkr9dKHtV8rbD4F4lDAj+0OVnDg0U p8SBUzKblg7I5Fv6l3eO7X6o/Z65G0975NS9raxCgCw6ReUadQHDrdcpKrdQ1j88FnSKSrFtunQC WGQpleVwtM4NOHRNV2ocnnajO9NFFqy0RV50wUrb2kUXrLRFXnTBOiLo3QITsMBIP+tydUSx0NVq IZHpxfnQ0e9Z1r5IBlmu0qZD0eUqbTsoA3GpDDCP/mtdrfZE5OyrluUnrZQB6/E2bLksX3nXoOh8 hmySDwQoUWaJTLFoMxCCSn+kdzD6o6YL696zK1giuJ5e10RwyO1OljsUCVBk74llRfYzKBCg6FYl SVrWrUyMBciTrYWBDHlq1sqAZSmNw80FfiCedJEXm68pNMBKJxVglaN+sLZRaEBpt2KsY3TFRWf7 Ni1deOKgdKNgACUrbekq1TkWQLnCO8LKNAoGUJ7yhrKwnGMBVBxgM1plhcMBVJZ4G1tljcMBit8C N63D8x2RYtNCGjswRTcI5HseI7SDriNIqpYRxjvoOgKx3eroYAUojo5JBm8vuPMDXyimng7aRFfF IRQflAG90zrCLvV09KLEUnTcVp3WixLzUSSmESnWyRQmSZopVIp2MoVLksraOIuebnbrPeG3OhR6 dT/uaB8ZKuN9T+NeLMbFYlwsxsViXCzG+2sxlC9bB4F+hwEtgTw0gHkOHdjo4Ok7MzmGnYHaQxvZ Z3Kq0GPelZI2NGhz5XC2CJ49FDO3kc3grlnEI6iqDlokZzG99tjuaYsD6jz5FZvSw1VMwMaAjhk/ Jnxo1zsx+xdpeO+l4WBerlFi5ca9vFzz3IkdplwAJxzJWccpGBjHUSLN8HWF57mB+bPtXqmCe7EV 9LrA8xzB/Nl2r1TBOblMioLOdAQ3XYF9OOnKOa7PpqV9tpae4wju5Ii9duecxIrM7b6l2FmFiB/X ixCGw7MInUUR5IYRhJlz2hUccRcpTjgJQmfpoxdwhTtcyxjjcnOWzzUOOK/Z9bnaidlDT988+nj1 IOK95mH5+8YRq8GZuNjKHKPKkeyZJvc05TeQGkSBq4TjwNlVqCC+j0/leRfKfrG87TAQnDBcEwm7 6gNF4RvCTbPMsbESNiw9cLH7xWGfnvYD7PjBTToyWf3IJ7VNQbdiPdJHcBtTNSYl42YDyuEncMth /W9Y/rDq4WbKfvnzK7gzultetxfXaRmUu90KWZZv/c6G1YUrxBJxVQnvPf78dwdfHNDb7V58cPg1 XGHaa3UQffHJCkbo8k93NJW6S4EzlJn0egU7o/W/5S9wNyj2/M3Lv/84cyBn3ImCvnOB3WpYruFI O43lw4/h2EaRzFkG2Wp9J4UWMox2ve67aCiupEKI77RQ7H2YRuXRmYWetgEDTlZL35NpLQPOfxjf KM6St4TfFzx7MtJ8t90rl3Ee23oUz54qNN9t98oV3MupJX5f8Dn11AJdf9B4an/mGWAqxDUWC9HG zi4EOYgr56316IyL+ZTrXIZS6ZzL/ZgiJklEEZGksyhC7DCKCHtOT0oor1kpUWcTX1RdRndXfnZ0 T7pHR5N9eXxPekDnja8Hs0v/9cvVwBvDD2eqTbqvpSTTHCfv6z5xXbm/y1avLbafXfEuY8mj36L2 p6+OKSVub5j0fvH/hcu4YdI395o/vUe4u+uy5eO3Wn/VAwFw1udvtD7njuzDE8tj8jGiTbd+H5eP CbedPZVgrtpRq7O/Jt2Rw1/JDazL9IZT7bNYQ+Gqe9fGvoGpC/L6+tV3LzZ4gzpcaV/nMv2p27yV hJ8+flj/mcaTk64Z92ZrP7/6C2S/odtyXcYbJ5YzrrTWBs2hSJ68OtBqvoLOgOjSvcquM/2pzjz6 chV4XFoqnycLCDihdg9OFhfz7XEZ6JLOiQKFhg6nfwRvFA7kSJaXGc61xc1n291CBSY+mCtvC55r IdvvtnvlCg7sbZb3BZ9TT85NbwajyUzzR0X4pg6uy7MLYc71ZLq4P+fcTev43XvenFWIdMfJ0BBV hs4qgphhZQhzTtrhHndnIDNYHPfM8Defw+CoY6Zf/mGekSwjLgdzkcXcW14f/zmqX9Qff6hfUGaw A1fA36E+v4eUXRHfuH51TP9IuzPuOOwYy7vn8qEuN79ubsOl/aoSE0Ux0lYSwzqLpa0kxryXtI8y pcEiHGSmTUUFSWnI08l97N/l50I/8L4XfINbV4ooJSPjKDkMuO2avoK7FttMiB9il2eeCRvJJcCu 8AAly54qbaEDHtxONOBsZ7oA6q42lBzdBnqJkmKBtsCL5AZkRxHg6E50Ae7ciS7wQYwMCRV3oos9 FDdyoguwnp2CnzX7CtIGsBy8gsVF1JPb7BbRbCyB/B+akCUQHTQhCw3HKAlZOiSDJmTphF0cWtAR JSTNhmH5Galm0DOXot8BD9E3RTKABAI+z3fFDMCBEjXPOtNA86yjOAH2eb4BKwNg+he7hgGaZx1p A9jn+Qbs8nzDhNXn+QbsTpfxfNYkJ2iedZSCEjTPOgleGC22AxgUJM86/aZ5vqHfQbOsM3a/T/5b jBBwRdPCTaumGAhrGka0WMspBEI7RuEw1m+MgDCq0P6OUS3yyHaJn4ujeWStpHlkWBO1CXSMpTE7 flPEAwsDuS9NUtCgmhTRnrVJGcU7NComOBk1ZeqvEjUJxw1zGwDydW6CK3T4SOUyumjD3EaftF1z XmQZrcyCbCObduNs4AvFRC9EUp290b/0Tq1QiIoqHWGX5oQKrc5ibkeXUqrPTueRrEQJtZmiV5Yk Z6ZLp3WjaklKTRWTPyROfGueHg5T0me5asG9xxmNjFP8swyOexwhvpiLi7m4mIuLubiYi/fSXAzU BD575iFHKTKbWrS5chii3ezDFk0UyKO1N1Yncg5FNSEtonowu5IJg0LO7XcA7HyXs/stNs8btV9h sKYZduZxD22c9SPlYNbWlIXq6l1dHj0dHJew7+POSm5v3Iix1uPE78LqX8ThVyAOd+8e54Sq/V3t HrMaTUViEfzNkTRDyphVBtxT4KpEFZlhCxOf9QldkArQw9HAm7aEMgDDdp6JQPae4X4UDChTqUP0 iKv0eL8s69KOV+UD6uo5SYUyXTekSYWy3efGO8g6cUSble0+N5T6rPe5jfhc3Ioi221uaEqz3eYG ljfbbW5omHOxaWNHPye3psh2mxtOCbLd5qZu4d6tKbLe5pbXhIJbU2S7zS0RR/Q2Nxi22e5zw8lR 1vvcWprzXDzbvTxITuWZYXrZnqgYd5kbENdf5kZQJ+2ZtrWZ9twHu8sN9rf8ZW5IAM14gHOs7C9z QwK629wINuR3l7mliDhExzx3lxtuubu73ID3epfbQARw17khwdx1bkgJzRBFYufvc4sI5RwMMkuT ynTUc01Co3hwU7Xm/XG04mimZ5XhPN7aQvNEayvN460vOM3UntI03ghBk1QjFE3jjY6kmY3ONJNX NtD82JhEeyl2HxwrEs1iUUQk9LRDNgkhG2QCRKbeBIymBSZ/dPDC5JOOumR/T0Xeuc/YxgAe07Ah ImUPag7H0Q0waZq7/y30bnxKx9wFcNmNbiaLuwBu0C0iR1S7AM4pFuGI3f4WvVpihvrb36DfO9e/ mdajdURurn/L/vq3EJ0+ZVH0179lUcf72eaY2pqCJts9nIHETLnRDon7Zpu7GIaLYbgYhothuBiG f2PDIAsae+Yjlu2jnL3yWD+ho1YObLTK2JoUwuziOog0IVij5ww7FPMO8t8uDj9qGjEYt+pfM+xG eZQ0YgxcGjFWApJGzHTCURWtXCjR1WtMGkkD9A1QE9zmk3tbY35h/vvG/ENRQQnDonK2k1PvOq4f wq7hMBfFcW2v+gnNHeMbxUWi/Pj9sh/ldzyWsPluu1euYNnRkPcFz47ya77b7pXLOEycLYDfV3xO PaH3/UHDr/2ZFz3HhVhjqRBp7OxCmIMY/+R6NDuMz3Edy3BUmh8KyJ0xSaLOiCSdUwizQwtR9pyM JywT5fXtk3pILerv+1erOvkNqSuHc74djE+kHMNa3tFo7p5T0rraf4BwRgoMtNxzb65fQXQfhqN/ hyGGECKIyersBtPrmSGPA87y4Dhm2g/mdtGPdv+oUeTxJx9DtCNV6GLN3dHJgyGQBw8JWAWuAZ88 XME6B8KiH+8EKgJd00gHOMB5ahg8mXTmlDAgOCeYSHEaQqXf4pu9smSE7GHO66DvO6w/C0ADqM9c r4P7xWgXJ1WVfovng+z63EiUKs6ZqCMJx7MuOCn7vBwU53Tl2a04izslLdnOc7QFP44WXXJirvQs K046f5p1xUlnTrOuODH7fNYFJyVqz7rgpOzzWVaclOY9d7bgBy2bdUJBWeKzJqunBPTZstUDsEkf 0FMngZHoWyxWJCbNbovLCmMH7U4RJxuY5OsUW+xkiINcYtJUTtwYSeVEqXSTpnKiXiRN5US58ZOm ciIqJM3mhLnxkyRzIhKmvnG5xFQaDqRiHOgJZ8/A1CRzisnlewDuJ03mRLnxk2ZzIulJLpsT/uwE L7lkTkgGTeZEP6rHCzvdJG+Cn9UBhjTQ1zErvhVFifGtKspHnGS2nV0TOde4doFzkWsXOVe5koBT mQuFONO5EpAzoSuBKVG6kp/WucYeclQo95Dxva2nGfvwDRMMzu+ugsPp30WuODu8ih1nj08ul092 QmtaVZ0YvWgv97XL5TNFN2Skcs3lgyn6k0vlM+ho5Oz+Ok550GbnqrFBzhRTJUCeAdURTG9VIXwv gaoYZpdqILrWQBUUc1v0F89WVLuRrKjy4xzaphxJzkx50q0hqltJSrO7JASJkOUMbBuqyLTX3XJ9 kaMWjDft6LhPqOLFQFwMxMVAXAzExUC8HwbCL2m2HieNR9tH5NJrsPtybIFGo0H1jZnJWa6WRj4c QBJVpsLgkD3DZx74r1Jc3AG60aLRYnLZOxnzLdesDFqElby0txM5m/a1xV3qu/PKJe9c9qU4tovE nZGxF5z4lnb+Ig6/AnE4mOkuk2YaOauAxREe9G3TNVT3zgL0f0gGo5oKZW5kc3RyZWFtDWVuZG9i ag01OSAwIG9iag08PC9Db250ZW50cyA2MSAwIFIvTWVkaWFCb3ggWzAgMCA3OTIgNjEyXS9QYXJl bnQgNDggMCBSL1Jlc291cmNlcyA8PC9Gb250IDYwIDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9J bWFnZUIgL0ltYWdlQyAvSW1hZ2VJXT4+L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNNjAgMCBvYmoNPDwv RjI3IDUgMCBSL0YyOCAxNCAwIFI+Pg1lbmRvYmoNNjEgMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURl Y29kZS9MZW5ndGggNjQxNz4+DXN0cmVhbQp4nO1de5Mct3H/BPcd9s9dl281eAyAyX+WLTlKHD9E xo4rlWIxq5No1y1JkRTtjx/0u2f3bm/nqFSJ4kpV0v5uMHh0N7obQDfm+6thBf9+/dursIJ/33x3 lcpqrGW1v6oj/brFXwl+JP7/i6tvf3H1J3t52OapDWlaHf/oNX72Zay97qffXn3+9CpEfKn/rw5p G1c5bMe4erq/+u912JR13vzP6um/XX3x9Or7Xus0jK31F45+vN29vAq5bFtb5alsR+hvLHGr8FZg ztuYO5TSgnkI0EqdylDb6viHb4Xe2x9WSzAO43aK1opi18o5Y+H39ofVEgxp2mY3FsVnt7L6OxQp wzCMq39gNdmPrPPDDe3Jo6t0w8AqdRyPrRLZXLcDdFMH33qZR9YposJVCnk/oEampcki0VKE8fFV MpO1SmX6E52Ad7zbp1yzKRdgmDjr8FeoCeZcbhEIiVPv6eZ6XP+wue4t1hbr+uWdP29udXbeUS1w 2de6vt6snv793sINKOP7cNNbitzSbpO301jGtH7em1+/1nbnuuSg0jRgbXns1WAPgvTge1NrosNU qZmee3EVa1dcvYY0bpGNHfa5ADCRTpm2vSTgEBkDJVOGdgkPGXEh7dBAzjoUlKh0KIwHeJxkltdt QVgaw0Q40+s0ERKoTYIF2ooktYBDQVzpOU46wLkxzlSeNReyK1HZDC/lFLa1MEYyoHJGjCBSRYmI gDS/VVlPw1YeIw0G08PA6Y6T6DKkwgCDNxynrS+ukGrrMBXXWMfMAepMbMKBjIDJT8PoOLtRdsj0 RwrEKuQnAnVcmiNgx0p/IHDHnv6xGP2BPR3X6NjXcW7G3Q6jCMOAxZ1kxFHoj3LT4ShihkQYhQMk dh0zB0gsYyYOsNR2SByooBkQEwcM8/OAdJC3A4zfKu94iq7xCrPL+tZhya7rXbmEKOPqIPlBd9yy o0nNTASmWc3EfKFpzUgHpngdiffCkDoSGYRhtThu1kJEEGbXIszPDKfiRKVWYr7IUa1EBZGz2oj5 Ioe1bbNJaW3E+zlUEa+NpqpMAa5Mp0itNFV5BnFfdILVuo1u/vFIdHLWIpOVOVBkWteRZqpMeSag qoQ60lSNc/KrSqmZpiprHOaeKqSOvb5izqs6q6SNVd2R4Igy7AhpIKqSxU5Vacc5O1XLQququGOk wrgl1f2XX1y97Ho+1onkb4K+7ucandTL0OTxrT6WucGu1J8uFuNiMS4W42IxLhbjk7AYSfTHfg4d 6OOYo50WJa6dQjvfuhoew86KHKH+bglERlWAHgMqB0B76KG8RiPzYGd2MB3YxSQdwqlwB9o5I0j6 Ya+DU33xgAY3WijnePw6lU5Mlm6z2WT/OMb/IhI/E5GYCURCVy4kMk2slFPITkkDkvHbbxwQwTHy 5gvUk4+xSpa0Y/qb+iH44+jfHVssuWQyTPg/3LcZNnW93VzXbSvTOPsZ3GYu2JiE+4wpIqcTGhgA Iz2Bn63/F90zA91i7a4IkpNzKzWAE4P2LWXcuTvGjUaj5R0emuAUA02FRj1R1LBhhNyRW+t8Ektb DBhXP5Wx3rWzN1WsJeGEPdiFYx8rRhTrrhUmdIkZ3yKGfXDCUFWXyhhRWB0qqD4Jh0E2/KmuMFTq YcojPT/EhTWOlHdYIYDeA0BATUMjqkbC3JVbG4a4PTxKgk4sPt3Bn72a7n9EL3AvixbARRYtXeYB 21IZkK6NscogizNcLgHWxTHIZQmyOMPVFmBZfAVobLDFWcmIqyzeCOraeKLiujYu0NqwkmViGidb G/c6AcvaGCoBzIszPHEBrMtjmGpj0+UxkGFsYjlxCgLW5XFD6A1pGiubbXJ6ABd2FAqiVPzTIqth 0lFjEZpT5WXrFu4AQ/Fd03OqjKDMhjUKwXExDTh6qmQhOJYDrLsRQNExC8WxUcAxG0NGt9GRxiQU J2aOSShecdBJCE6iMIpiY+U4RiY4SdIYheATETwKwUkOxyiLtYEGGtR1YejdulnxqbjqaN1izdG6 RntDyx7rLC6KbCy0ZrKh0prKSIFLLiYTLceMhLRaMxLTas5YQKs9YxGtBpWDtFg0BjOQpTUJ+Wir a6SCiA4uUVWwaAFrYkfrWxNLXDyb1NJyWGWalt4m8lKbTAlautuMkb7IjCKVpROuFjcZacvAJqvQ QCYzbjjYXGcSkh6gzQpTEkx/VSK02WE6hnmnOoh2SlRFEedVgdE2iyk4lhtVgLhJY/qRxU60JznU plxZakn5zpbHuBUBxA2RHHkrZdpEvHSdBo/ZSb3o/ovuv+j+i+6/6P6fmO4vrJVpm4WxIlqazNDu yuFUVseIbYrsNGH7yTZ7BoRY1gM6t+CStJmVnDB0GKK2ch/SVw0ropFJtYh2clwC09p3kOARYAWA rbzw7+qe5ExF0K6bH0JTks94o4awFs87mh1Hk4VtsO6MfpAVv4jCz0MUlpxqVxgCGgntKSs1EhHW aLfiq5G1URPJCk58NdZvamHZdqmvxvpODTQpPHXV2BKqeWcFqL4aK0BxDdiuqq9G+lAdC9aH4q3x aNUvYf2o3hqPXt0aGL26aswFdYiYGuqr6U4du1eyscchnsV5drHZvp3Wpq4dVKV+HfWjiKCg0WZS 2TCKTGhyr9hTMioUdfRoR6eIp4ckLOro8UQYLegAp8loznVZcRvGvyKuXqP9SHX1iP1FXb2JqKSu HklPUVdvIipnEbui3g1yiQmlvhYTUmwgc8FDfYo00bdRoFztkWgiflfJrlMkvNbpyiopmzEvbsw0 bZQkNKuMYuhGGD3J8zJ6kxdi/CDXS7nF+23KTHK+jNnkAJkwoPNlskL+k4oSOV8maahETApJW5uU 0rmBSTEdcamMk6q3KcC1qf/UiMbqQFWenebI2dzjcejcJEfO5i7TQac20EimPZNQtQI5cqY0iAOq U8iRM53D/BOVVJNoqCI4eY1Gqs40HkuPKkSsR9UlC55qU+qUU7Uot1XPKOfH1kTqvbh4Wu5Q2/Dj Ytv3y+OcLhbhYhEuFuFiES4W4SdrEfQkmKJW7Kz3XtQ4akWhApqGXCmCnWvbWxUm1gGoUnAnG5Nc za1sPepU1zPqNge7KwdRSRwiO+vWgBrSo87mkZY9QDT3IzZi5o2Uwf5IN4imdv0fi5d6IYtu89UZ 1kmgkyS56uYRTB9s1S+i8LGLwl1xFVyw4RH9QVzFA5ll44B2ZyTFsr8qDSzFKNqN4cjhoVJa8Lmp kvP39ofVMhzYIkppwecmMc7f2x9WSzA3njBcWvGSVrpRmY2lNRvMWQl9UonvamvW17MrQd6Bidjb gMhWnFWFsJtqEAotqEAG4uWnNROgJZUwK7QSZQ1UEjSh8WQG40jOyDhy6uBXm+4JpSHn9WvLVnyf T2Urjq0CJ7mKk7mK4zQQ77m1Fy4j8vnmOq6/cX94o40Ofiz3Jy2OAX2KMYG7hfU/efXDm90mRhzS +ma1uQ4j/f7b5nqSgb7vf97GMrS6zpu6Xm26Hwbg+TffvLl5+/aXm/4SRuGtTpKBW495y+F8v+m0 7C2kcX3z9l3/jZW6hl8+f7eB6MGQ/F9fvVxt0gRxf8W6sqC75/QxgGLFPv5xc9093jSFvH7z6h2M NHXyr1/t4GcMtffndnOdOAxR2/rlZtI/XfcxIE2f9qdUlf36XR83pZ/e+Yr7adR68uvNdfeJe9/O zmAfB0pFqbynXhqml1T20xmOnPogpQWfr5b9e/vDagmmad6K4vMVpn9vf1gtw8rhZlJa8JJWIB/B j6U0G8yZiohOsqd5JdrXsytB3lWK3NURjUv0MvGbqxAaLahB6OElqDQToUX0IGYYPYQ5c8V8jzqG wHZwkUQh97lA88bP/HJaI2OAodZyWie3CQOYtfCLm+ffdOXLbwwnuxsoMSSDx4fdfYsaN0ykRm6e 9e53nYPKzKmaPxdQEC2WsH5mWjadpWU5f2oSHf9YLYtdw26m+7r2KyhP2usc3Uo9C0X0/+8hfjv0 auP65p/vNiM3/YwJfKouWtS7urz2PPUiZw3Zi6aK3zz/9tu/wUA7KYZxvdvI2J7tNpV/3hqFnp8e bomP7SLTaVAR//IWrH4ZY+iG5x/d+iWyPGY7nv/vzS0SE3t2pyX5V3ieOzun9avXq02gwn5Ajvv7 /hvC/IH372ah9ZT8MARasHS6YbD/wOlfgIs+BwQzZ0BP1qEK56+CJd9O6sLkPNF5B4B2V6yk4Sgw TTwBKPjCUMbAc8YD56PpADQLjQcY9e4WPZP+JAd+fkBdHiqvYjnjUwLCeQcuD2Urm6yQ3qHx5LSs zhQCrpu2WePFyQPPg+QuUa7qIIlWuLUIMLkNY8DBAuryoEnQlCc7aBI0WbFBsqApzXbQLOgsc1Ei zzBXaEiz4DPAEnzGE1c30YGik9tkB1wtoA5gdot9YwhnkA3RA815phQmj5tJoyQmDy4LGrtiWdDI IM2C5lFoFjQtnwZNmKIYukmS2SjwcJIsaPZpNAuaYhanyXMgTc04UAjrkQvEQEzNH7kA1CMXiEyY NBGa4i0nTYSmKLpJE6ExXHOSPOhJ/K9JjodG8hWrxp+IMyaxSlOZAZkfFNdkhcN2VlEQx25yG6va D4qp0k5yxJUOgiOydJAcsaVE4IguoREHfCkJORpMSUzBYsoAjiVTBnGsmfCvetZyZrKynvN5VTQ4 NXlw2cE5m2RxZrIKHicTq2BSZrKKrWnVWtxj1UmUeqxTRGrXlGDMPdYJJn2z7BCUYs0ILjJX9aij +rnNGds69zkBWVQDpXur4mBHQhULZ4ur3qH8Y1VLnGwuWovTj1WncaK66jxOQFadyHnuqjM5AVlU KiXJq8LljEZSyAdBdkZvS1qVgpKWafxwM+JRUdYXo3AxChejcDEKF6PwEzYKlJA98PnDHMtNAkeo FncHAWF9M/qfO9+0NyuM+ZD9TqR3CLDCk9/yi5r1wN6gDt8LLAB4Gq1bhnWuK8JV1UiNvLDSvLWn JYqp7vtVtVFEmcOj1ilSDuYEYj5YcqHWH2rPLwLwkQrAPbdSQsJKQaV2lBDvwt/3smMhQdu8KUEw TVESX9IMYXS54CTvQTVJN/XJLTjCfCWTlncYkmjSKFslEQHaHwKyZxItb0A7r3FHmjJQDrdtPq0x 33lNAvmB7eiWhPnJZ6N34LAVjzwTuqa0A7npJqr/AxvHZf0dXJT6wxvYNR7WN6vxm3+BE7DU/8nr 1ddffT7b3dRaQwF3wGqdb7q7YmjefOtf/f7LDdz4tf7D3TVzfwPShzd1x3H9w8uXB9fIWiN9Llr5 +3oS0EH29d683Cklnr9ecvxGElH4tiA6GGcokQQpk+GWwgwXxkTQa/uDOhlFCtuTogwXxkPQa/uD OhkNcdYCw4WxEH4Mrekglpz9+062pr1cEgeR6kDhAzqYJTEITA+pQ8jziDCGmdS0ZmKzqJIhzujB jDmKhDgRPcCLMEq1xOmwf327uYazcjiNOH340xrlRsrLD4RBcHKxll505saqGpdP2M//6P0MfAh2 upuJkon13dPdxEAK35A/Hpodyaw2mJdb169e37yBA7dKB4CzE7e3y87zR7owpWQ90GUoZ+C8uLnV 0oKXnOfbe/vDahlmDkWV0oKXnLTbe/vDahnGOB9LjEdjebAVjG1zY8FQ17LgDnqpxHcVKpG+nl3J qPfs7G1E7KUvONDXOoRIS6qQwXgZKs2EaFElxA6rRNizMNQKQpcbruRxPv12U/vadoxx/fUXp9UL LKHtzQcO9OkeK9fOjx1npRGhSQbS+9/XarEM0xoP1oejM/9nv9lk1lFfbCb+45OnG9Gvd57qzur9 I+gbeu/rP2wmPru3A274GxX9NfYAH9sf7Tj52dP+k975q77tunqaFzz6PKlanPXy37/YgC/3V6fs 5jeN7a/4TlYN3edTTNkzphNOvXiWEUXuChz5OjqpapzI8MpkO8L8RQYtb1gAXyMLr0YPcsZ2OTGC wqV1BHI32sHdaXq8+smO/EwlGUYiDCu4wBf9EgwTbylyacULDRy/tz+sluHIO7RSWvBCA8fv7Q+r ZZjqfCyCFxq42Vi6JtbBLFHns65CJdLXRQYujLQtpSNa8okSY3i1iLVlVYht8jIEtkmEaBFFUp2T VdizyMBR5tyAef6oGd//83YD27tgC/D7Iy8f8qJhimsFD3rRkLbgmvt/sXOBogqPovHypj9Hnf/+ 5KAiKiSr5QGfm75N49qktcFnm4EdadcHZ7Peb65zl0KwpA/EBuI+ybndmXCH9bg7GBTNrv/DxjIU PF/A9//8X2CIh/5PWP8KLDrZZBcs5x0Ii+4zp8EVNePvqPLlV8D1/tcU3FtfL44mDklTFmhyavoF wsD3VkhpwQujifm9/WG1BItmX2Dhsjj5wr22P6iTg2aT2Us4GkrLvrfFIa+zUZRmw1gSN+u7WZr2 c0kUcUiy5KCxnK/VhclGp0WvCx28zJRmQrMoCDlJcggd1CfbVDlbFZNJCrh1iPPOfX3q/XdvNtcD +c9hfXNaXaAbZBU9qJLbrNUfXyN3Z4uOlE+FR59OWEkDaCOt5UGF3CnpmiQFuNqEvEXF9BkoYdJR mh9xho5+KEx2ws0h166LcL1582AEMVGqZT4p6Xr3b/A+rZnevAPbBR394fkt9I8jk5/8J+zX9G6X sv4c1SxF5ZoWNYU719InRwLbSK4nfqWXSAzXX/6u/5EGZyu2v3D4OOh618b3B3fywrICgwH0jl76 ngZD/ppGwHNjB/AKXsaNU7K5otZmWvcQcnq3FHaw+yONPz0iwP9utKBAqBcOa+f5HPzwgmFbS32K gz4vFIuuSYj6gT+61wJC1FcaHhVjm11KCVgvpcRrmNvsVkrAeitlxvIriQOKUY56+XqIWGe3UgKW WykRaEgSLCVj0ZAkyJSPGhTGe00aFEb5sFGDwigzN2pQGF06HiUqLCARNCiM7s6KGhQ2yJ3YHJM0 bOnKbA5JGogIHPnRl79Fb9AmnLPcoT3DeVZeg8IGudo6usY0LIz7omFh3FeNC6OhaFgYDzR6Kuj3 kphKGhbGVHRxYUjlcMAEiQvL+FuDwpB7LigMuatBYbRoczFhQIRgQWETPdawPKBBcEFh0FpwUWFA heCiwkBsg0WFwaiDRoEx1igxutxFi1P6ttWGid/WGN39YZ2hi2W0s3D9R7BPRsTsxsmZ10oGzvpW MvF9H0pGvmZBSMzXfSgH6I4GZRBf+KEM5CselMF04UeUZy07yeDrPlRw+HYJFSy+70MFjy+n0BvW aW8nWriUE3F56GKjYrMZIlXnWUCazS/pmguO4tma/LAkOCrJbNXgqNbc3GeaaWwUk7QcUNxio7JX PMIw0UrCUNFazPBoASyq7khMTBeSGJmuRCkzVUpCaKqWZFQ1MYlw1M/tapCWXnVfGmvwYuVoZ87u yaenMjGWR+5ezMXFXFzMxcVcXMzFx2susqqP/QG+F9H3XmbYoSkeoJ3vgL/9nrGZkUPQ36STJacA PQZU1aDNEb3LOOuB1Z1o50zhgWXkLrFGOEI7M4OoEPZeX4iGPqnBhRTKOhq/wHvniQ/v/XCjf5GF j18W7orpZEVAm2+P+wA9x3PFSTK0OFJOb5uinJwoV0bShxGi3hlJGT1R74ykDyvE5m17iu7WyErY eQYA5dZIBEFcjkpxhs25HICLuByDRR7KxySi3hnJHxPTOyP5Y2N6ZyTeQR71zki6hDuOW+fXpZjN t8oIqzxGMsjti+SoAY5OFBIDinqLcq+jPJQLvugs3j57JpXLFyIG4oB+IYK7pl+IoAvDo3zygQem d3zTRzcifzBCyBLsmxz0NERP1MGIDtHJcTCiI1MG/V5xpOLBMzRMlhQHQw+qDVAcguguzg8LYshI mIJbUmSE1Xl6gLPM3EDFo5tfHc/A7GPG7mVKDgvOxjbfNGWHac8oOUw7DslhOihOAdBBcwqAEoXz w4Rm/AkOJSnnhynJ+RscyhJKEFOG8Tc4hJ+cH6bspk9wqDBwepgKC3+FQ4WJ88NE1vgjHPYFPsoP U1Hlr3DcgavPH4vZV+a+ANLcnJGu6I2llLqmU45HIjeWUt6bzlchg15ZSnlzOt2FinplKUX5i7YQ JhRjQnS6RlhoXyiYKyrgvyoxuhXfdByJjqlA+qKLqUj+FqKqUP5SomhYElxTwBheGqejhK0iX07U tbmWcipHv0kDzwO7oo/aC7iYiYuZuJiJi5m4mImPy0zQ1NPLZT12yCL89cPADmPu4/1o59r3H0Ej 6IwHIxTFiVuhtZvTe42ISO3ch/Rdww5FXSMy2pkeqEc2kXt1N5B1n+kQWYOb1sA1+Exza8NGC2Nc cHx8YKrM9gE+2OBf5OHnIQ/3fyh9zPIZ7HM/lM6fZh9pH0Lz3EbZl1AsX3aW8oeRyT9SRXeNrepl 28OisUnMcc3UpRRwM53xLeKkzxNG+3RE3oeCTB+8H+xu8Fup6fha7eNrtuOsvMMa0Z9kO4dMgG3u 4J1tBLkjtzaGcRbBr1hiQj7dsd8pQeQs56bZPvdL0J3CdOeUQ+0aGh4O/WiVor8YKOf/MZX+H0xf 8aoKZW5kc3RyZWFtDWVuZG9iag14cmVmDTAgNjINMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDE2IDAwMDAwIG4NCjAwMDAwMDAyMTAgMDAwMDAgbg0KMDAwMDAwMDI3MCAwMDAwMCBuDQowMDAw MDAwMzY1IDAwMDAwIG4NCjAwMDAwMDA1MjAgMDAwMDAgbg0KMDAwMDAwMTY4OCAwMDAwMCBuDQow MDAwMDAxODkzIDAwMDAwIG4NCjAwMDAwMzMxODIgMDAwMDAgbg0KMDAwMDAzMzMxMyAwMDAwMCBu DQowMDAwMDQ2OTUyIDAwMDAwIG4NCjAwMDAwNDcwMjMgMDAwMDAgbg0KMDAwMDA0NzIxMiAwMDAw MCBuDQowMDAwMDUxNjEyIDAwMDAwIG4NCjAwMDAwNTE2NTIgMDAwMDAgbg0KMDAwMDA1MjgyNyAw MDAwMCBuDQowMDAwMDUzMDQwIDAwMDAwIG4NCjAwMDAwODAwMTEgMDAwMDAgbg0KMDAwMDA4MDU1 NCAwMDAwMCBuDQowMDAwMDgwNzEwIDAwMDAwIG4NCjAwMDAwODA3NDAgMDAwMDAgbg0KMDAwMDA4 MDk3NiAwMDAwMCBuDQowMDAwMDgxMTMyIDAwMDAwIG4NCjAwMDAwODExNzIgMDAwMDAgbg0KMDAw MDA5NTgwOSAwMDAwMCBuDQowMDAwMDk1OTY1IDAwMDAwIG4NCjAwMDAwOTYwMDUgMDAwMDAgbg0K MDAwMDExMDI2MSAwMDAwMCBuDQowMDAwMTEwNDE3IDAwMDAwIG4NCjAwMDAxMTA0NTcgMDAwMDAg bg0KMDAwMDEyNjg2MiAwMDAwMCBuDQowMDAwMTI3MDE5IDAwMDAwIG4NCjAwMDAxMjcwNjAgMDAw MDAgbg0KMDAwMDEzOTYwNSAwMDAwMCBuDQowMDAwMTM5NzYyIDAwMDAwIG4NCjAwMDAxMzk4MTQg MDAwMDAgbg0KMDAwMDE1MjA2OSAwMDAwMCBuDQowMDAwMTUyMjI2IDAwMDAwIG4NCjAwMDAxNTIy NjggMDAwMDAgbg0KMDAwMDE2NzU1MSAwMDAwMCBuDQowMDAwMTY3NzA4IDAwMDAwIG4NCjAwMDAx Njc3MzkgMDAwMDAgbg0KMDAwMDE2ODA1NSAwMDAwMCBuDQowMDAwMTY4MjEyIDAwMDAwIG4NCjAw MDAxNjgyNTQgMDAwMDAgbg0KMDAwMDE3NTczNCAwMDAwMCBuDQowMDAwMTc1ODkxIDAwMDAwIG4N CjAwMDAxNzU5MzMgMDAwMDAgbg0KMDAwMDE4NjU4NSAwMDAwMCBuDQowMDAwMTg2NzEwIDAwMDAw IG4NCjAwMDAxODY3NzIgMDAwMDAgbg0KMDAwMDE4NjkyOSAwMDAwMCBuDQowMDAwMTg2OTcxIDAw MDAwIG4NCjAwMDAxOTI5MjggMDAwMDAgbg0KMDAwMDE5MzA4NSAwMDAwMCBuDQowMDAwMTkzMTQ4 IDAwMDAwIG4NCjAwMDAxOTQzMjkgMDAwMDAgbg0KMDAwMDE5NDU0OCAwMDAwMCBuDQowMDAwMjE0 OTUzIDAwMDAwIG4NCjAwMDAyMjM2MTMgMDAwMDAgbg0KMDAwMDIyMzc3MCAwMDAwMCBuDQowMDAw MjIzODEyIDAwMDAwIG4NCnRyYWlsZXINPDwvSW5mbyAxIDAgUi9Sb290IDIgMCBSL1NpemUgNjI+ Pg1zdGFydHhyZWYNMjMwMzAwDSUlRU9GCg== ------=_NextPart_000_0007_01CF630F.ED329C50 Content-Type: text/plain; name="draft-hares-i2rs-rib-model-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hares-i2rs-rib-model-03.txt" =0A= =0A= =0A= =0A= I2RS working group N. Bahadur=0A= Internet-Draft Bracket Computing=0A= Intended status: Standards Track R. Folkes=0A= Expires: October 25, 2014 Juniper Networks, Inc.=0A= S. Kini=0A= Ericsson=0A= S. Kini=0A= Cisco=0A= April 23, 2014=0A= =0A= =0A= Routing Information Base Info Model=0A= draft-ietf-i2rs-rib-info-model-03=0A= =0A= Abstract=0A= =0A= Routing and routing functions in enterprise and carrier networks are=0A= typically performed by network devices (routers and switches) using a=0A= routing information base (RIB). Protocols and configuration push=0A= data into the RIB and the RIB manager installs state into the=0A= hardware; for packet forwarding. This draft specifies an information=0A= model for the RIB to enable defining a standardized data model. Such=0A= a data model can be used to define an interface to the RIB from an=0A= entity that may even be external to the network device. This=0A= interface can be used to support new use-cases being defined by the=0A= IETF I2RS WG.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on October 25, 2014.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 1]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2014 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Conventions used in this document . . . . . . . . . . . . 5=0A= 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . 6=0A= 2.2. Routing instance . . . . . . . . . . . . . . . . . . . . 6=0A= 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11=0A= 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12=0A= 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 13=0A= 2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . 14=0A= 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 14=0A= 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 6. RIB Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 6.1. RBNF Form of Grammar . . . . . . . . . . . . . . . . . . 15=0A= 6.2. UML Form of Grammar . . . . . . . . . . . . . . . . . . . 20=0A= 6.3. Yang Data Model Tree Form-IM . . . . . . . . . . . . . . 20=0A= 7. Using the Rib Grammar . . . . . . . . . . . . . . . . . . . . 22=0A= 7.1. Using Route preference . . . . . . . . . . . . . . . . . 22=0A= 7.2. Using different nexthop types . . . . . . . . . . . . . . 22=0A= 7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 22=0A= 7.2.2. Replication List . . . . . . . . . . . . . . . . . . 22=0A= 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . 23=0A= 7.2.4. Protection lists . . . . . . . . . . . . . . . . . . 23=0A= 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . 23=0A= 7.2.6. lists of lists . . . . . . . . . . . . . . . . . . . 23=0A= 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 24=0A= 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 8.2. RIB Writes . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 8.3. RIB events and notifications . . . . . . . . . . . . . . 24=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 2]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24=0A= 10. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25=0A= 12. Informative References . . . . . . . . . . . . . . . . . . . 25=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26=0A= =0A= 1. Introduction=0A= =0A= Routing and routing functions in enterprise and carrier networks are=0A= traditionally performed in network devices. Traditionally routers=0A= run routing protocols and the routing protocols (along with static=0A= config) populate the Routing information base (RIB) of the router.=0A= The RIB is managed by the RIB manager and the RIB manager provides a=0A= north-bound interface to its clients i.e. the routing protocols to=0A= insert routes into the RIB. The RIB manager consults the RIB and=0A= decides how to program the forwarding information base (FIB) of the=0A= hardware by interfacing with the FIB manager. The relationship=0A= between these entities is shown in Figure 1.=0A= =0A= +-------------+ +-------------+=0A= |RIB client 1 | ...... |RIB client N |=0A= +-------------+ +-------------+=0A= ^ ^=0A= | |=0A= +----------------------+=0A= |=0A= V=0A= +---------------------+=0A= |RIB manager |=0A= | |=0A= | +-----+ |=0A= | | RIB | |=0A= | +-----+ |=0A= +---------------------+=0A= ^=0A= |=0A= +---------------------------------+=0A= | |=0A= V V=0A= +-------------+ +-------------+=0A= |FIB manager 1| |FIB manager M|=0A= | +-----+ | .......... | +-----+ |=0A= | | FIB | | | | FIB | |=0A= | +-----+ | | +-----+ |=0A= +-------------+ +-------------+=0A= =0A= =0A= Figure 1:RIB manager, RIB clients and FIB managers=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 3]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Routing protocols are inherently distributed in nature and each=0A= router makes an independent decision based on the routing data=0A= received from its peers. With the advent of newer deployment=0A= paradigms and the need for specialized applications, there is an=0A= emerging need to guide the router's routing function=0A= [I-D.ietf-i2rs-problem-statement]. Traditional network-device=0A= protocol-based RIB population suffices for most use cases where=0A= distributed network control is used. However there are use cases=0A= which the network operators currently address by configuring static=0A= routes, policies and RIB import/export rules on the routers. There=0A= is also a growing list of use cases [I-D.white-i2rs-use-case],=0A= [I-D.hares-i2rs-use-case-vn-vc] in which a network operator might=0A= want to program the RIB based on data unrelated to just routing=0A= (within that network's domain). Programming the RIB could be based=0A= on other information such as routing data in the adjacent domain or=0A= the load on storage and compute in the given domain. Or it could=0A= simply be a programmatic way of creating on-demand dynamic overlays=0A= (e.g. GRE tunnels) between compute hosts (without requiring the hosts=0A= to run traditional routing protocols). If there was a standardized=0A= publicly documented programmatic interface to a RIB, it would enable=0A= further networking applications that address a variety of use-cases=0A= [I-D.ietf-i2rs-problem-statement]=0A= =0A= A programmatic interface to the RIB involves 2 types of operations -=0A= reading from the RIB and writing (adding/modifying/deleting) to the=0A= RIB. [I-D.white-i2rs-use-case] lists various use-cases which require=0A= read and/or write manipulation of the RIB.=0A= =0A= In order to understand what is in a router's RIB, methods like per-=0A= protocol SNMP MIBs and show output screen scraping are used. These=0A= methods are not scalable, since they are client pull mechanisms and=0A= not proactive push (from the router) mechanisms. Screen scraping is=0A= error prone (since the output format can change) and is vendor=0A= dependent. Building a RIB from per-protocol MIBs is error prone=0A= since the MIB data represent protocol data and not the exact=0A= information that went into the RIB. Thus, just getting read-only RIB=0A= information from a router is a hard task.=0A= =0A= Adding content to the RIB from an external entity can be done today=0A= using static configuration mechanisms provided by router vendors.=0A= However the mix of what can be modified in the RIB varies from vendor=0A= to vendor and the method of configuring it is also vendor dependent.=0A= This makes it hard for an external entity to program a multi-vendor=0A= network in a consistent and vendor-independent way.=0A= =0A= he purpose of this draft is to specify an information model for the=0A= RIB. Using the information model, one can build a detailed data=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 4]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= model for the RIB. That data model could then be used by an external=0A= entity to program a network device.=0A= =0A= The rest of this document is organized as follows. Section 2 goes=0A= into the details of what constitutes and can be programmed in a RIB.=0A= Guidelines for reading and writing the RIB are provided in section 3.=0A= and Section 4 respectively. Section 5 provides a high-level view of=0A= the events and notifications going from a network device to an=0A= external entity, to update the external entity on asynchronous=0A= events. The RIB grammar is specified in Section 6. Examples of=0A= using the RIB grammar are shown in Section 7. Section 8 covers=0A= considerations for performing RIB operations at scale.=0A= =0A= 1.1. Conventions used in this document=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 2. RIB data=0A= =0A= This section describes the details of a RIB. It makes forward=0A= references to objects in the RIB grammar (Section 6). A high-level=0A= description of the RIB contents is as shown below.=0A= =0A= routing-instance=0A= =0A= | |=0A= | |=0A= 0..N | | 1..N=0A= | |=0A= =0A= =0A= interface(s) RIB(s)=0A= =0A= =0A= |=0A= |=0A= | 0..N=0A= =0A= =0A= route(s)=0A= =0A= Figure 2: RIB model=0A= =0A= Figure 3: RIB Model=0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 5]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.1. RIB definition=0A= =0A= A RIB is an entity that contains routes. A RIB is identified by its=0A= name and a RIB is contained within a routing instance (Section 2.2).=0A= The name MUST be unique within a routing instance. All routes in a=0A= given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST belong=0A= to a routing instance.=0A= =0A= A RIB is an entity that contains routes. A RIB is identified by its=0A= name and a RIB is contained within a routing instance (Section 2.2).=0A= The name MUST be unique within a routing instance. All routes in a=0A= given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST belong=0A= to a routing instance.=0A= =0A= A routing instance can have multiple RIBs. A routing instance can=0A= even have two or more RIBs with the same type of routes (e.g. IPv6).=0A= A typical case where this can be used is for multi-topology routing=0A= ([RFC4915], [RFC5120].=0A= =0A= Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK=0A= attribute that enables Reverse path forwarding (RPF) checks on all IP=0A= routes in that RIB. Reverse path forwarding (RPF) check is used to=0A= prevent spoofing and limit malicious traffic. For IP packets, the IP=0A= source address is looked up and the rpf interface(s) associated with=0A= the route for that IP source address is found. If the incoming IP=0A= packet's interface matches one of the rpf interface(s), then the IP=0A= packet is forwarded based on its IP destination address; otherwise,=0A= the IP packet is discarded.=0A= =0A= 2.2. Routing instance=0A= =0A= A routing instance, in the context of the RIB information model, is a=0A= collection of RIBs, interfaces, and routing parameters. A routing=0A= instance creates a logical slice of the router and allows different=0A= logical slices; across a set of routers; to communicate with each=0A= other. Layer 3 Virtual Private Networks (VPN), Layer 2 VPNs (L2VPN)=0A= and Virtual Private Lan Service (VPLS) can be modeled as routing=0A= instances. Note that modeling a Layer 2 VPN using a routing instance=0A= only models the Layer-3 (RIB) aspect and does not model any layer-2=0A= information (like ARP) that might be associated with the L2VPN.=0A= =0A= The set of interfaces indicates which interfaces are associated with=0A= this routing instance. The RIBs specify how incoming traffic is to=0A= be forwarded. And the routing parameters control the information in=0A= the RIBs. The intersection set of interfaces of 2 routing instances=0A= MUST be the null set. In other words, an interface MUST NOT be=0A= present in 2 routing instances. Thus a routing instance describes=0A= the routing information and parameters across a set of interfaces.=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 6]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= A routing instance MUST contain the following mandatory fields.=0A= =0A= o INSTANCE_NAME: A routing instance is identified by its name,=0A= INSTANCE_NAME. This MUST be unique across all routing instances=0A= in a given network device.=0A= =0A= o rib-list: This is the list of RIBs associated with this routing=0A= instance. Each routing instance can have multiple RIBs to=0A= represent routes of different types. For example, one would put=0A= IPv4 routes in one RIB and MPLS routes in another RIB.=0A= =0A= A routing instance MAY contain the following optional fields.=0A= =0A= o interface-list: This represents the list of interfaces associated=0A= with this routing instance. The interface list helps constrain=0A= the boundaries of packet forwarding. Packets coming on these=0A= interfaces are directly associated with the given routing=0A= instance. The interface list contains a list of identifiers, with=0A= each identifier uniquely identifying an interface.=0A= =0A= o ROUTER_ID: The router-id field identifies the network device in=0A= control plane interactions with other network devices. This field=0A= is to be used if one wants to virtualize a physical router into=0A= multiple virtual routers. Each virtual router MUST have a unique=0A= router-id. ROUTER_ID MUST be unique across all network devices in=0A= a given domain.=0A= =0A= 2.3. Route=0A= =0A= A route is essentially a match condition and an action following the=0A= match. The match condition specifies the kind of route (IPv4, MPLS,=0A= etc.) and the set of fields to match on. Figure 3 represents the=0A= overall contents of a route.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 7]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= route=0A= =0A= =0A= | | |=0A= +---------+ | +----------+=0A= | | |=0A= 0..N | | | 1..N=0A= =0A= route-attribute match nexthop-list=0A= =0A= =0A= |=0A= |=0A= +-------+-------+-------+--------+=0A= | | | | |=0A= | | | | |=0A= =0A= IPv4 IPv6 MPLS MAC Interface=0A= =0A= =0A= (Unicast/Multicast)=0A= =0A= =0A= =0A= Figure 3: Route model=0A= =0A= =0A= This document specifies the following match types:=0A= =0A= o IPv4: Match on destination IP address in the IPv4 header=0A= =0A= o IPv6: Match on destination IP address in the IPv6 header=0A= =0A= o MPLS: Match on a MPLS label at the top of the MPLS label stack=0A= =0A= o MAC: Match on MAC destination addresses in the ethernet header=0A= =0A= o Interface: Match on incoming interface of the packet=0A= =0A= o IP multicast: Match on (S, G) or (*, G), where S and G are IP=0A= prefixes=0A= =0A= Each route MUST have associated with it the following mandatory route=0A= attributes.=0A= =0A= o ROUTE_PREFERENCE: This is a numerical value that allows for=0A= comparing routes from different protocols. Static configuration=0A= is also considered a protocol for the purpose of this field. It=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 8]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= is also known as administrative-distance. The lower the value,=0A= the higher the preference. For example there can be an OSPF route=0A= for 192.0.2.1/32 with a preference of 5. If a controller programs=0A= a route for 192.0.2.1/32 with a preference of 2, then the=0A= controller's route will be preferred by the RIB manager.=0A= Preference should be used to dictate behavior. For more examples=0A= of preference, see Section 7.1.=0A= =0A= Each route can have associated with it one or more optional route=0A= attributes.=0A= =0A= o route-vendor-attributes: Vendors can specify vendor-specific=0A= attributes using this. The details of this attribute is outside=0A= the scope of this document.=0A= =0A= 2.4. Nexthop=0A= =0A= A nexthop represents an object resulting from a route lookup. For=0A= example, if a route lookup results in sending the packet out a given=0A= interface, then the nexthop represents that interface.=0A= =0A= Nexthops can be fully resolved nexthops or unresolved nexthop. A=0A= resolved nexthop has adequate information to send the outgoing packet=0A= to the destination by forwarding it on an interface to a directly=0A= connected neighbor. For example, a nexthop to a point-to-point=0A= interface or a nexthop to an IP address on an Ethernet interface has=0A= the nexthop resolved. An unresolved nexthop is something that=0A= requires the RIB manager to determine the final resolved nexthop.=0A= For example, a nexthop could be an IP address. The RIB manager would=0A= resolve how to reach that IP address, e.g. is the IP address=0A= reachable by regular IP forwarding or by a MPLS tunnel or by both.=0A= If the RIB manager cannot resolve the nexthop, then the nexthop=0A= remains in an unresolved state and is NOT a candidate for=0A= installation in the FIB. Future RIB events can cause an unresolved=0A= nexthop to get resolved (like that IP address being advertised by an=0A= IGP neighbor). Conversely resolved nexthops can also become=0A= unresolved (e.g. in case of a tunnel going down) and hence would no=0A= longer be candidates to be installed in the FIB.=0A= =0A= When at least one of a route's nexthops is resolved, then the route=0A= can be used to forward packets. Such a route is considered eligible=0A= to be installed in the FIB and is henceforth referred to as a FIB-=0A= eligible route. Conversely, when all the nexthops of a route are=0A= unresolved that route can no longer be used to forward packets. Such=0A= a route is considered ineligible to be installed in the FIB and is=0A= henceforth referred to as a FIB-ineligible route. The RIB=0A= information model allows an external entity to program routes whose=0A= nexthops may be unresolved initially. Whenever an unresolved nexthop=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 9]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= gets resolved, the RIB manager will send a notification of the same=0A= (see Section 5 ).=0A= =0A= The overall structure and usage of a nexthop is as shown in the=0A= figure below.=0A= =0A= route=0A= =0A= =0A= |=0A= | 0..N=0A= =0A= =0A= nexthop-list=0A= =0A= |=0A= +------------------+------------------+=0A= 1..N | |=0A= | |=0A= =0A= nexthop-list-member special-nexthop=0A= =0A= =0A= |=0A= |=0A= =0A= nexthop-chain=0A= =0A= =0A= |=0A= 1..N |=0A= =0A= =0A= nexthop=0A= =0A= =0A= |=0A= |=0A= +--------+------+------------------+------------------+=0A= | | | |=0A= | | | |=0A= =0A= nexthop-id egress-interface logical-tunnel tunnel-encap=0A= =0A= Figure 4: Nexthop model=0A= =0A= Nexthops can be identified by an identifier to create a level of=0A= indirection. The identifier is set by the RIB manager and returned=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 10]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= to the external entity on request. The RIB data-model SHOULD support=0A= a way to optionally receive a nexthop identifier for a given nexthop.=0A= For example, one can create a nexthop that points to a BGP peer. The=0A= returned nexthop identifier can then be used for programming routes=0A= to point to the same nexthop. Given that the RIB manager has created=0A= an indirection for that BGP peer using the nexthop identifier, if the=0A= transport path to the BGP peer changes, that change in path will be=0A= seamless to the external entity and all routes that point to that BGP=0A= peer will automatically start going over the new transport path.=0A= Nexthop indirection using identifiers could be applied to not just=0A= unicast nexthops, but even to nexthops that contain chains and nested=0A= nexthops (Section 2.4.1).=0A= =0A= 2.4.1. Nexthop types=0A= =0A= This document specifies a very generic, extensible and recursive=0A= grammar for nexthops. Nexthops can be=0A= =0A= o Unicast nexthops - pointing to an interface=0A= =0A= o Tunnel nexthops - pointing to a tunnel=0A= =0A= o Replication lists - list of nexthops to which to replicate a=0A= packet=0A= =0A= o Weighted lists - for load-balancing=0A= =0A= o Protection lists - for primary/backup paths=0A= =0A= o Nexthop chains - for chaining headers, e.g. MPLS label over a GRE=0A= header=0A= =0A= o Lists of lists - recursive application of the above=0A= =0A= o Indirect nexthops - pointing to a nexthop identifier=0A= =0A= o Special nexthops - for performing specific well-defined functions=0A= =0A= It is expected that all network devices will have a limit on how many=0A= levels of lookup can be performed and not all hardware will be able=0A= to support all kinds of nexthops. RIB capability negotiation becomes=0A= very important for this reason and a RIB data-model MUST specify a=0A= way for an external entity to learn about the network device's=0A= capabilities. Examples of when and how to use various kinds of=0A= nexthops are shown in Section 7.2.=0A= =0A= Tunnel nexthops allow an external entity to program static tunnel=0A= headers. There can be cases where the remote tunnel end-point does=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 11]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= not support dynamic signaling (e.g. no LDP support on a host) and in=0A= those cases the external entity might want to program the tunnel=0A= header on both ends of the tunnel. The tunnel nexthop is kept=0A= generic with specifications provided for some commonly used tunnels.=0A= It is expected that the data-model will model these tunnel types with=0A= complete accuracy.=0A= =0A= Nexthop chains can be used to specify multiple headers over a packet,=0A= before a packet is forwarded. One simple example is that of MPLS=0A= over GRE, wherein the packet has an inner MPLS header followed by a=0A= GRE header followed by an IP header. The outermost IP header is=0A= decided by the network device whereas the MPLS header and GRE header=0A= are specified by the controller. Not every network device will be=0A= able to support all kinds of nexthop chains and an arbitrary number=0A= of header chained together. The RIB data-model SHOULD provide a way=0A= to expose nexthop chaining capability supported by a given network=0A= device.=0A= =0A= 2.4.2. Nexthop list attributes=0A= =0A= For nexthops that are of the form of a list(s), attributes can be=0A= associated with each member of the list to indicate the role of an=0A= individual member of the list. Two kinds of attributes are=0A= specified:=0A= =0A= o PROTECTION_PREFERENCE: This provides a primary/backup like=0A= preference. The preference is an integer value that should be set=0A= to 1 (primary) or 2 (backup). Only when all the primary nexthops=0A= fail is the traffic re-routed through the backup nexthops. This=0A= attribute must be specified for all the members of a list or none=0A= of them.=0A= =0A= o LOAD_BALANCE_WEIGHT: This is used for load-balancing. Each list=0A= member MUST be assigned a weight between 1 and 99. The weight=0A= determines the proportion of traffic to be sent over a nexthop=0A= used for forwarding as a ratio of the weight of this nexthop=0A= divided by the weights of all the nexthops of this route that are=0A= used for forwarding. To perform equal load-balancing, one MAY=0A= specify a weight of "0" for all the member nexthops. The value=0A= "0" is reserved for equal load-balancing and if applied, MUST be=0A= applied to all member nexthops.=0A= =0A= A nexthop list MAY contain elements that have both=0A= PROTECTION_PREFERENCE and LOAD_BALANCE_WEIGHT set. When both are=0A= set, it means under normal operation the network device should load=0A= balance the traffic over all FIB-eligible nexthops of the current=0A= protection preference.=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 12]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.4.3. Nexthop content=0A= =0A= At the lowest level, a nexthop can be one of:=0A= =0A= o identifier: This is an identifier returned by the network device=0A= representing another nexthop or another nexthop chain=0A= =0A= o EGRESS_INTERFACE: This represents a physical, logical or virtual=0A= interface on the network device. Address resolution must not be=0A= required on this interface. This interface may belong to any=0A= routing instance.=0A= =0A= o IP address: A route lookup on this IP address is done to determine=0A= the egress interface. Address resolution may be required=0A= depending on the interface.=0A= =0A= * An optional RIB name can also be specified to indicate the RIB=0A= in which the IP address is to be looked up. One can use the=0A= RIB name field to direct the packet from one domain into=0A= another domain. By default the RIB will be the same as the one=0A= that route belongs to.=0A= =0A= o EGRESS_INTERFACE and IP address: This can be used in cases e.g.=0A= where the IP address is a link-local address.=0A= =0A= o EGRESS_INTERFACE and MAC address: The egress interface must be an=0A= ethernet interface. Address resolution is not required for this=0A= nexthop.=0A= =0A= o tunnel encap: This can be an encap representing an IP tunnel or=0A= MPLS tunnel or others as defined in this document. An optional=0A= egress interface can be specified to indicate which interface to=0A= send the packet out on. The egress interface is useful when the=0A= network device contains Ethernet interfaces and one needs to=0A= perform address resolution for the IP packet.=0A= =0A= o logical tunnel: This can be a MPLS LSP or a GRE tunnel (or others=0A= as defined in this document), that is represented by a unique=0A= identifier (E.g. name).=0A= =0A= o RIB_NAME: A nexthop pointing to a RIB indicates that the route=0A= lookup needs to continue in the specified RIB. This is a way to=0A= perform chained lookups.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 13]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.4.4. Special nexthops=0A= =0A= This document specifies certain special nexthops. The purpose of=0A= each of them is explained below:=0A= =0A= o DISCARD: This indicates that the network device should drop the=0A= packet and increment a drop counter.=0A= =0A= o DISCARD_WITH_ERROR: This indicates that the network device should=0A= drop the packet, increment a drop counter and send back an=0A= appropriate error message (like ICMP error).=0A= =0A= o RECEIVE: This indicates that that the traffic is destined for the=0A= network device. For example, protocol packets or OAM packets.=0A= All locally destined traffic SHOULD be throttled to avoid a denial=0A= of service attack on the router's control plane. An optional=0A= rate-limiter can be specified to indicate how to throttle traffic=0A= destined for the control plane. The description of the rate-=0A= limiter is outside the scope of this document.=0A= =0A= 3. Reading from the RIB=0A= =0A= A RIB data-model MUST allow an external entity to read entries, for=0A= RIBs created by that entity. The network device administrator MAY=0A= allow reading of other RIBs by an external entity through access=0A= lists on the network device. The details of access lists are outside=0A= the scope of this document.=0A= =0A= The data-model MUST support a full read of the RIB and subsequent=0A= incremental reads of changes to the RIB. An external agent SHOULD be=0A= able to request a full read at any time in the lifecycle of the=0A= connection. When sending data to an external entity, the RIB manager=0A= SHOULD try to send all dependencies of an object prior to sending=0A= that object.=0A= =0A= 4. Writing to the RIB=0A= =0A= A RIB data-model MUST allow an external entity to write entries, for=0A= RIBs created by that entity. The network device administrator MAY=0A= allow writes to other RIBs by an external entity through access lists=0A= on the network device. The details of access lists are outside the=0A= scope of this document.=0A= =0A= When writing an object to a RIB, the external entity SHOULD try to=0A= write all dependencies of the object prior to sending that object.=0A= The data-model MUST support requesting identifiers for nexthops and=0A= collecting the identifiers back in the response.=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 14]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Route programming in the RIB MUST result in a return code that=0A= contains the following attributes:=0A= =0A= o Installed - Yes/No (Indicates whether the route got installed in=0A= the FIB)=0A= =0A= o Active - Yes/No (Indicates whether a route is fully resolved and=0A= is a candidate for selection)=0A= =0A= o Reason - E.g. Not authorized=0A= =0A= The data-model MUST specify which objects are modify-able objects. A=0A= modify-able object is one whose contents can be changed without=0A= having to change objects that depend on it and without affecting any=0A= data forwarding. To change a non-modifiable object, one will need to=0A= create a new object and delete the old one. For example, routes that=0A= use a nexthop that is identified by a nexthop-identifier should be=0A= unaffected when the contents of that nexthop changes.=0A= =0A= 5. Notifications=0A= =0A= Asynchronous notifications are sent by the network device's RIB=0A= manager to an external entity when some event occurs on the network=0A= device. A RIB data-model MUST support sending asynchronous=0A= notifications. A brief list of suggested notifications is as below:=0A= =0A= o Route change notification, with return code as specified in=0A= Section 4.=0A= =0A= o Nexthop resolution status (resolved/unresolved) notification=0A= =0A= 6. RIB Grammar=0A= =0A= 6.1. RBNF Form of Grammar=0A= =0A= This section specifies the RIB information model in Routing Backus-=0A= Naur Form [RFC5511]=0A= =0A= =0A= RIB_GRAMMAR=0A= =0A= ::=3D ! import routing IM=0A= [ ] ! (sequence of interfaces)=0A= ! (sequences of ribs)=0A= [ ] ! import routing IM=0A= =0A= ! no list identifier for these lists=0A= ::=3D ( ...)=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 15]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ::=3D ( ...)=0A= =0A= !RIB Definitions=0A= ::=3D ! imported routing IM=0A= ! import routing IM=0A= [ ... ]=0A= [ ] ! I2RS Boolean=0A= =0A= ::=3D ! I2RS=0A= [ ] ! I2RS=0A= [ ] ! I2RS=0A= =0A= ::=3D [ ] ! I2RS=0A= [ =0A= | =0A= | =0A= | =0A= | ]=0A= =0A= ::=3D | ! I2RS=0A= | ! I2RS=0A= =0A= ::=3D | ! I2RS=0A= | | ! I2RS=0A= =0A= =0A= =0A= ! import from IETF information models=0A= =0A= ::=3D ( ...) ! I2RS=0A= ::=3D (ipv6-prefix>...) ! I2RS=0A= ::=3D ( ...) ! I2RS=0A= ::=3D ( ... ) ! I2RS=0A= ::=3D ! I2RS=0A= =0A= =3D ! I2RS (per Nitin)=0A= [( ... )=0A= [PROTECTION_PREFERENCE] ! I2RS=0A= [LOAD_BALANCE_WEIGHT] ! I2RS=0A= =0A= =0A= =0A= :: =3D ! [New] I2RS nexthop format=0A= [ ] ! [Nitin] NH type=0A= [ | ]=0A= [ ]=0A= [ | =0A= | ]=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 16]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= [ ]=0A= [ >]=0A= [ ]=0A= =0A= ! types of formats (I2RS ENUM) ! Format=0A= =0A= :: =3D ! Name of NH chain=0A= | ! ID of NH chain=0A= | ! NH-TYPE address (v4/v6, mac, egress-if)=0A= | ! NH_TYPE, egress-if, address(v4/v6),=0A= ! RIB_name=0A= | ! INTERFACE_IDENTIFIER, mac-adders=0A= | ! NH_TYPE, tunnel-name (string)=0A= | ! tunnel encapsulation=0A= =0A= ::=3D | !IRS ENUM=0A= | =0A= | | | =0A= | | =0A= =0A= ::=3D [ipv4-header] | ! import from ip=0A= [ipv6-header] | ! import from ip=0A= [mpls-header] | ! import mpls header=0A= [gre-header] | ! import from gre header=0A= [vxlan-header] | ! import from vxlan header=0A= [nvgre-header] ! import from nvgre header=0A= =0A= ::=3D ! I2RS defined=0A= [ ] ! I2RS defined=0A= [ROUTE_ACTIVE][ROUTE_INSTALLED] ! I2RS defined=0A= [ | ! imported=0A= | ! imported=0A= ] ! imported=0A= =0A= :: <> ! imported from Vendor=0A= =0A= ::=0A= =0A= RIB RBNF GRAMMAR PART 2 - Definitions=0A= =0A= ! Definitions to be Imported from Other IETF Informational models=0A= ! From routing IM (yang)=0A= =0A= ::=3D=3D rt.routing-instance.name !String=0A= :: =3D rt.routing-instance.router-id ! UNIT32=0A= ::=3D = rt.routing-instance.interfaces.interface.name=0A= =0A= ::=3D rt.routing-instance.ribs.rib.address-family=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 17]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ! IPV4_RIB_FAMILY | IPV6_RIB_FAMILY |=0A= ! MPLS_RIB_FAMILY | IEEE_RIB_FAMILY=0A= =0A= ::=3D rt.routing-instance.ribs.rib.name !STRING=0A= ::=3D rt.mpls.label=0A= ::=3Drt.route.admin-distance=0A= =0A= !I2RS redefinition=0A= =0A= ::=3D =0A= ::=3D =0A= ::=3D=0A= ::=3D =0A= ::=3D =0A= =0A= !From RFC6991 Common types=0A= =0A= ::=3D yang.mac_address=0A= ::=3D yang.ipv4-prefix=0A= ::=3D yang.ipv6-prefix=0A= ::=3D yang.ipv4-address=0A= ::=3D yang.ipv6-address=0A= =0A= !I2RS Definition - may want to add to Routing IM=0A= =0A= ::=3D STRING ! Next hop name=0A= ::=3D INTEGER-32 ! Next hop ID number=0A= ::=3D STRING ! tunnel name=0A= ::=3D BOOLEAN ! denotes if only LOCAL=0A= ::=3DBOOLEAN ! route ACTIVE route=0A= ::BOOLEAN ! route installed in FIB=0A= =0A= ! Should be in Yang IM -ip packet=0A= =0A= ::=3D =0A= =0A= =0A= []=0A= []=0A= =0A= ::=3D UINT8=0A= ::=3D UNIT8=0A= ::=3D=0A= =0A= =0A= []=0A= []=0A= []=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 18]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ! Should be in mpls-packet IM=0A= ::=3D ([]=0A= [ [] )=0A= | [])=0A= ! Should be in encapsulations=0A= =0A= ::=3D =0A= =0A= =0A= ::=3D( | )=0A= []=0A= =0A= ::=3D( | )=0A= []=0A= []=0A= =0A= ! Definitions of ENUM or BOOLEAN=0A= ::=3D BOOLEAN ! I2RS TRUE/FALSE=0A= ::=3D ! I2RS ENUM=0A= | =0A= | =0A= | =0A= =0A= ::=3D | ! I2RS ENUM=0A= | =0A= ::=3D BOOLEAN ! I2RS LOGICAL TRUE/FALSE=0A= ::=3D BOOLEAN ! I2RS LOGICAL = TRUE/FALSE=0A= ::=3D =0A= | ! (Per NITIN's EMAIL)=0A= =0A= ::=3D , ! I2RS ENUM list=0A= | ! nexthop-id format=0A= | ! single address format=0A= | ! Egress interface 1 format=0A= | ! Egress interface 2 format=0A= | ! Logical tunnel format=0A= | ! tunnel encapsulation=0A= =0A= :: =3D !I2RS Enum=0A= | =0A= | =0A= | =0A= | =0A= | =0A= =0A= !Imported from undefined Information Models=0A= :: =3D <> ! imported from rt-routing=0A= :: =3D <> ! imported from mpls-routing=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 19]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ::=3D <> ! imported from ethernet=0A= :: <> ! imported from vendors=0A= =0A= =0A= =0A= 6.2. UML Form of Grammar=0A= =0A= The UML form will be inserted here if graphics can be associated=0A= =0A= 6.3. Yang Data Model Tree Form-IM=0A= =0A= Format of the Yang=0A= =0A= o Brackets "[" and "]" enclose list keys.=0A= =0A= o Abbreviations before data node names: "rw" means configuration=0A= (read-write) and "ro" state data (read-only).=0A= =0A= o Symbols after data node names: "?" means an optional node, "!"=0A= means a presence container, and "*" denotes a list and leaf-list.=0A= =0A= o Parentheses enclose choice and case nodes, and case nodes are also=0A= marked with a colon (":").=0A= =0A= o Ellipsis ("...") stands for contents of subtrees that are not=0A= shown.=0A= =0A= o I: is the symbol for the import definition=0A= =0A= o D: is the symbol for the I2RS definition=0A= =0A= o (M) is yang definition for this is missing=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 20]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= +--ir2s=0A= +--rw routing-instance=0A= +--rw INSTANCE_NAME [1] I:rt.routing-instance.name=0A= +--rw interface-list [1] ?=0A= | +--rw Interface_Identifier* [0..n] ?=0A= I:rt.routing-instance.interfaces.interface.name=0A= | +--rw rib-list [1]=0A= | | +--rw rib [1..n]=0A= | | | +--rw name [1] I:rt.routing-instance.ribs.rib.name=0A= | | | +--rw address-family [1]=0A= | | | +--rw route [1..n]=0A= | | | |--+--rw rt-match=0A= | | | | |--+--rw route-type [1] D:I2RS ENUM=0A= | | | | | +--rw route-form [1] D:I2RS ENUM=0A= | | | | | +--rw route-prefix [1..2]=0A= | | | | | +--rw ip-v4-prefix [0..2] ? I:yang.ipv4-prefix=0A= | | | | | +--rw ip-v6-prefix [0..2] ? = I:yang.ipv6-prefix=0A= | | | | | +--rw mpls-prefix [0..1] ? I:mpls.mpls-label=0A= | | | | | +--rw ieee-mac-prefix [0..2] ? I:yang.MAC_ADDRESS=0A= | | | | | +--rw interface-identifier [0..1]=0A= = I:rt.routing-instance.interfaces.interface.name=0A= | | | |--+--rw next-hop-list=0A= | | | | | +--rw nexthop [1..N]=0A= | | | | | | +--NH_FORM [1] D:I2RS ENUM=0A= | | | | | | +--NH_TYPE [1] ? D:I2RS ENUM=0A= | | | | | | +--NEXTHOP_NAME [0..1] ? D:I2RS STRING=0A= | | | | | | +--NEXTHOP_ID [0..1] ? D:I2RS UINT32=0A= | | | | | | +--INTERFACE_IDENTIFIER [0..1] ? I:STRING=0A= = I:rt.routing-instance.route.outgoing-interface=0A= | | | | | | +--ipv4-address [0..1] ? I.yang.ipv4-address=0A= | | | | | | +--ipv6-address [0..1] ? I.yang.ipv6-address=0A= | | | | | | +--rw ieee-mac-prefix [1] ? I:yang.MAC_ADDRESS=0A= | | | | | | +--rw RIB_ID [0..1] ? D:I2RS to rib-name=0A= I:rt.routing-instance.ribs.rib.name=0A= | | | | | | +--rw TUNNEL-NAME [0..1] ? D:I2RS STRING=0A= | | | | | | +--rw tunnel-encap [0..1] ?=0A= | | | | | | | +--ipv4-header [0..1] ? I:ip-packets (M)=0A= | | | | | | | +--ipv6-header [0..1] ? I:ip-packets (M)=0A= | | | | | | | +--mpls-header [0..1] ? I:mpls-packets (M)=0A= | | | | | | | +--gre-header [0..1] ? I:gre-packets (M)=0A= | | | | | | | +--vxlan-header [0..1] ? I:vxlan-packets (M)=0A= | | | | | | | +--nvgre-header [0..1] ? I:nvgre-packets (M)=0A= | | | | | +--rw PROTECTION_PREFERENCE [0..1] ? D:I2RS = Boolean=0A= | | | | | +--rw LOAD_BALANCE_WEIGHT [0..1] ? D:I2RS = Boolean=0A= | | | | | +--rw special-nexthop [1] ? I:IR2S ENUM:=0A= ENUM VALUES: DISCARD, DISCARD_WITH_ERROR=0A= |--+rw router-id [0..1] ? I:rt.routing.instance.router-id=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 21]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= One thing the examination of the yang data models indicates is that=0A= you do not have the read-only portion versus the read-write portion=0A= of the informational model done.=0A= =0A= 7. Using the Rib Grammar=0A= =0A= The RIB grammar is very generic and covers a variety of features.=0A= This section provides examples on using objects in the RIB grammar=0A= and examples to program certain use cases.=0A= =0A= 7.1. Using Route preference=0A= =0A= Using route preference a client can pre-install alternate paths in=0A= the network. For example, if OSPF has a route preference of 10, then=0A= another client can install a route with route preference of 20 to the=0A= same destination. The OSPF route will get precedence and will get=0A= installed in the FIB. When the OSPF route is withdrawn, the=0A= alternate path will get installed in the FIB.=0A= =0A= Route preference can also be used to prevent denial of service=0A= attacks by installing routes with the best preference, which either=0A= drops the offending traffic or routes it to some monitoring/analysis=0A= station. Since the routes are installed with the best preference,=0A= they will supersede any route installed by any other protocol.=0A= =0A= 7.2. Using different nexthop types=0A= =0A= The RIB grammar allows one to create a variety of nexthops. This=0A= section describes uses for certain types of nexthops.=0A= =0A= 7.2.1. Tunnel nexthops=0A= =0A= A tunnel nexthop points to a tunnel of some kind. Traffic that goes=0A= over the tunnel gets encapsulated with the tunnel encap. Tunnel=0A= nexthops are useful for abstracting out details of the network, by=0A= having the traffic seamlessly route between network edges.=0A= =0A= 7.2.2. Replication List=0A= =0A= One can create a replication list for replication traffic to multiple=0A= destinations. The destinations, in turn, could be complex nexthops=0A= in themselves - at a level supported by the network device. Point to=0A= multipoint and broadcast are examples that involve replication.=0A= =0A= ::=3D () ...=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 22]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 7.2.3. Weighted lists=0A= =0A= A weighted list is used to load-balance traffic among a set of=0A= nexthops. From a modeling perspective, a weighted list is very=0A= similar to a replication list, with the difference that each member=0A= nexthop MUST have a LOAD_BALANCE_WEIGHT associated with it.=0A= =0A= ::=3D ( )...=0A= =0A= 7.2.4. Protection lists=0A= =0A= Protection lists are similar to weighted lists. A protection list=0A= specifies a set of primary nexthops and a set of backup nexthops.=0A= The attribute indicates which nexthop is=0A= primary and which is backup.=0A= =0A= ::=3D ( )...=0A= =0A= A protection list can also be a weighted list. In other words,=0A= traffic can be load-balanced among the primary nexthops of a=0A= protection list. In such a case, the list will look like:=0A= =0A= ::=3D ( =0A= )...=0A= =0A= 7.2.5. Nexthop chains=0A= =0A= A nexthop chain is a nexthop that puts one or more headers on an=0A= outgoing packet. One example is a Pseudowire - which is MPLS over=0A= some transport (MPLS or GRE for instance). Another example is VxLAN=0A= over IP. A nexthop chain allows an external entity to break up the=0A= programming of the nexthop into independent pieces - one per=0A= encapsulation.=0A= =0A= ::=3D ( ) ( )...=0A= =0A= 7.2.6. lists of lists=0A= =0A= Lists of lists is a complex construct. One example of usage of such=0A= a construct is to replicate traffic to multiple destinations, with=0A= high availability. In other words, for each destination you have a=0A= primary and backup nexthop (replication list) to ensure there is no=0A= traffic drop in case of a failure. So the outer list is a protection=0A= list and the inner lists are replication lists of primary/backup=0A= nexthops.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 23]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 8. RIB operations at scale=0A= =0A= This section discusses the scale requirements for a RIB data-model.=0A= The RIB data-model should be able to handle large scale of=0A= operations, to enable deployment of RIB applications in large=0A= networks.=0A= =0A= 8.1. RIB reads=0A= =0A= Bulking (grouping of multiple objects in a single message) MUST be=0A= supported when a network device sends RIB data to an external entity.=0A= Similarly the data model MUST enable a RIB client to request data in=0A= bulk from a network device.=0A= =0A= 8.2. RIB Writes=0A= =0A= Bulking (grouping of multiple write operations in a single message)=0A= MUST be supported when an external entity wants to write to the RIB.=0A= The response from the network device MUST include a return-code for=0A= each write operation in the bulk message.=0A= =0A= 8.3. RIB events and notifications=0A= =0A= There can be cases where a single network event results in multiple=0A= events and/or notifications from the network device to an external=0A= entity. On the other hand, due to timing of multiple things=0A= happening at the same time, a network device might have to send=0A= multiple events and/or notifications to an external entity. The=0A= network device originated event/notification message MUST support=0A= bulking of multiple events and notifications in a single message.=0A= =0A= 9. Security Considerations=0A= =0A= All interactions between a RIB manager and an external entity MUST be=0A= authenticated and authorized. The RIB manager MUST protect itself=0A= against a denial of service attack by a rogue external entity, by=0A= throttling request processing. A RIB manager MUST enforce limits on=0A= how much data can be programmed by an external entity and return=0A= error when such a limit is reached.=0A= =0A= The RIB manager MUST expose a data-model that it implements. An=0A= external agent MUST send requests to the RIB manager that comply with=0A= the supported data-model. The data-model MUST specify the behavior=0A= of the RIB manager on handling of unsupported data requests.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 24]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 10. IANA=0A= =0A= This document does not generate any considerations for IANA.=0A= =0A= 11. Acknowledgements=0A= =0A= The authors would like to thank the working group co-chairs and=0A= reviewers on their comments and suggestions on this draft. The=0A= following people contributed to the design of the RIB model as part=0A= of the I2RS Interim meeting in April 2013 - Wes George, Chris=0A= Liljenstolpe, Jeff Tantsura, Sriganesh Kini, Susan Hares, Fabian=0A= Schneider and Nitin Bahadur.=0A= =0A= 12. Informative References=0A= =0A= [I-D.hares-i2rs-use-case-vn-vc]=0A= Hares, S. and M. Chen, "Use Cases for Virtual Connections=0A= on Demand (VCoD) and Virtual Network on Demand (VNoD)=0A= using Interface to Routing System", draft-hares-i2rs-use-=0A= case-vn-vc-02 (work in progress), February 2014.=0A= =0A= [I-D.ietf-i2rs-architecture]=0A= Atlas, A., Halpern, J., Hares, S., Ward, D., and T.=0A= Nadeau, "An Architecture for the Interface to the Routing=0A= System", draft-ietf-i2rs-architecture-02 (work in=0A= progress), February 2014.=0A= =0A= [I-D.ietf-i2rs-problem-statement]=0A= Alia, A., Nadeau, T., and D. Ward, "Interface to the=0A= Routing System Problem Statement", draft-ietf-i2rs-=0A= problem-statement-00 (work in progress), August 2013.=0A= =0A= [I-D.ietf-i2rs-rib-info-model]=0A= Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing=0A= Information Base Info Model", draft-ietf-i2rs-rib-info-=0A= model-02 (work in progress), February 2014.=0A= =0A= [I-D.white-i2rs-use-case]=0A= White, R., Hares, S., and A. Retana, "Protocol Independent=0A= Use Cases for an Interface to the Routing System", draft-=0A= white-i2rs-use-case-02 (work in progress), February 2014.=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.=0A= Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC=0A= 4915, June 2007.=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 25]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi=0A= Topology (MT) Routing in Intermediate System to=0A= Intermediate Systems (IS-ISs)", RFC 5120, February 2008.=0A= =0A= Authors' Addresses=0A= =0A= Nitin Bahadur=0A= Bracket Computing=0A= 320 Soquel Way=0A= Sunnyvale, CA 94085=0A= USA=0A= =0A= Email: nitin_bahadur@yahoo.com=0A= =0A= =0A= Ron Folks=0A= Juniper Networks, Inc.=0A= 1194 N. Mathilda Avenue=0A= Sunnyvale, CA 94089=0A= USA=0A= =0A= Phone: +1 408 745 2000=0A= Email: ronf@juniper.net=0A= URI: www.juniper.net=0A= =0A= =0A= Sriganesh Kini=0A= Ericsson=0A= =0A= Email: sriganesh.kini@ericsson.com=0A= =0A= =0A= Jan Medved=0A= Cisco=0A= =0A= Email: jmedved@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 26]=0A= ------=_NextPart_000_0007_01CF630F.ED329C50 Content-Type: application/pdf; name="draft-hares-i2rs-rib-model-03.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-hares-i2rs-rib-model-03.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1WTXPbNhC961fs5FJ7xqI+3NZJeopcJeM2cV2JMz3UPUAgKKEmAQYALau/ vm9BMJIcZ5xOeyg1GlEk9u3bt29BfqRxNqExf9KvrAejxQWt/WBM7/BdDz4OJnEBpR9Z0yzHopc0 mVJeDrq4CU3P6eL8FeX14ORquljS1ro7bda0drZt6B8c1xnNxEYUrTvN/xxMzil/D0gTlDMqDH90 ogxfjTVzQt6pQJe2btoAOqffdFimUAX5IELrX9MyCFMIV3jKef0zmIuM3trqTnnGmj802ilg/CKD XSlH0+/OaDqefPvF8J9aoxssvFaBJfJndGVkxlhfXdWXjmVGP2uj/wusudPSe2v+b7xwXGov7b/D etM4XcGxXauAxcZ9/xTiwkbboEeldbUI2hq406t4gT7YQlUITyZ9IlPBdh1qFcqhnjo/dHo11Agd 1hw6HJ8jevp9jH6z8gH2C6m0PjOsSS6dl62RTMGTNqR4JFAIyPAaKZzT8JVJviLh1BG1sGu0FFW1 I9iPq8EErHb9eirUvZbK0+0JZ1POR1S/1UFulL89pdZHOoleT0kfCLNiYW5PFlez29OM6MbZYKWt OiRpTanXreuWNq3fJKRCBAGYYClsFCE4Lu/Pa2HEGmVpg2mtgMVDqz6tTxgbTO8WBf9AYENNN/Q4 xbUCLEEm32jfdYN8o6QutWJeh/wTVuxMxOk5IJUyYlUpiFTCyCwD84ibhv4LOsYaYiBSLVvZ1yYO 7qBDkEhBRwQAMmKpjgP0LoVUdCBC6WyNmwkIzdZhh5siQJIdqXsVwdQD74ui6iOPu5nqThj7NI+Y +LZprAsI3vK1oUQfPRZwoR3L6JS93Ffz/C3FXf63d9newcu4n5ItO7U/qLqf0/j/0R6OK75d1ToE wMPPZVtV0SXcDwOWsN4mJd27uHH2Xvs4A8gzu7yhi5fRMPH01QEb5nmUMY7Ep+dSYWVbQ9aIw9L1 i2lu1ihZue5xsU+dC3+Hrd9JNjlLEF1+bWHH2BcLFNc973xskqg82qwx1nqFkUpafE5APNbGx8Yp qhDL9GTrHFbuVyWoVBaURPpNCM3r0YgNF+Jjz2W872TWrUfR+H6UcEbPq9RNyp7ivah0EYcCbhYP um5rJub1A8xtwsYfKcX9YAHYYw0IqeKMnGoqeA9nALErbysVOl91uh3IEQCwSyUGXbONr6JftBEN DIBNj/cAOLf16nP6HrlKhUJlLznmG+3ElPBQW5I6tkzVKTW6ZzjsRRwdWBE51niq++zFkVBPuXir 4VoV3wII+9rj1wBWejK5iAjpreaM4DHBG0U60jvEs68Qv99gJ6TJH4Cc54Nf8fkbJWa6q2VuZHN0 cmVhbQplbmRvYmoKNiAwIG9iagoxMDEwCmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydl21v4jgQx9/zKebdtlJLSSile++OPqyQ aLdXclqdrvfCJBPwKrGztkOXb38zTgKB7ukCRIWS2D//ZzwP5gcM+gEM+Ko/47x39TqGpe0N4Av9 LXs/eoEfAPVHnMMkokG3EIQQpb1qXgDhEMbjW4jy3tlUOTQK3eW9EamDw9c0fJ3D63QC06cPz+j1 e2FkBuEguD6PvveGnyGa9c7udLExcrly8KydjPH8Uy+88U9oxu7h21n8du7nwvQheoTIlNaBUAm4 FUKBxmplQSaonEwlJiAsPyFaMGxoiY7LnAaAKN1KG9snSVkGfgELBi2aNSb9PQXRStrdRPrflovv GDtwGiZ3L0COaUTsdH2yMMOlyPZWfzF6La1kma+YCSfVkiF+1n29gKUZPPbtbOVc8dvVlWMcYl+i S/vaLK8ycpGyeClVqskhUgGmKevRyotIhEPQac0pygVNoLXoqU5pQMsYsv4lQ2GRLF9LfOfp9CU5 kBILg2mZZZuL2qUbSNDGRi4QNro0jfvYC+RCZ2TsvJHv0q34TkHqahaZeyjhTidIb3mhFS8K+NMZ ETvawNTofH845OSMGiVVnJU0dS7zIqt2fDK/h1nlHnDEYb2N1IQ9NUcvDa77LRex06pg8lvW3iY2 iayHgm8lxGCTdOngXRgjlNvQCjVlbx1G/lpXK7YischYBhlPSbXzd0BOoTQzOikrtdA/8gIY7gUe MwPvarXm9GDTSttIbfv3v4mjWl1IXzjBKczE8cr2WUwLGh6mUslj7QW4abG8NtoeTiyprBMqxu60 fdawZuGJNo5brGu68UzxuNLFSazPW1ZFC1o8tynQdmcFwQErbLEyyRXVUQYvyPD/o1KTOGANW6y4 CurOuoYHLPbZnCqHpIxUFdN220ug7lKx/B6iSDge6mKCPtiO8FfDYj3fjGyK9tGkNmvEftLcpqrK 3H3/dqwmh27q/PliRJ4LczSpzWKaz8fJ8yM8apNzdWrAJ7A4tv58mn1AddQVDlos3su/BDn/ngvP EzWNjKo2oodf8nGjG2vMmqzfRd5CuTjacxDu4n7s/VXxqmpRULNEgx0rzz4r3LISmXqKa2K/Q563 WRWNtUWlUthKoeNtrFi+tmKxPUzMuFacyOK9/IZ8aqAexEWnY2Yza3jA4rykju3qzn4E7SNr1K5f K0Et5HRdnJeVGAr8E228rXNb0+m2LhTCgY1F1rUrQXi91XW77bWGauIJNWeP1ZwDuCZiZ9t+zRrW LFz7EyCfutReeezAGoX+tDMRK5GU5gKQOlnW3/7yePhZSDqKwtfY6QUaCEcX1W+Jg9ffL2KJEP5D xIeo9wdd/wLOwhOqZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagoxMDA4CmVuZG9iagoxNyAwIG9i ago8PC9MZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVl1vmzAU fedX3LemassC6efe0q2dIq3dlqK+rJvkgAGvxE6NaVaJH79rMIlpoUl2UQRyzj333A8bnmDoejDU l7mHc+fD9AyS3BnCF/wlzpPjVQAwt3AOlwGCzsHzIYid2s8DfwRnZ+cQzJ3BhCsqOVVHnyWJFby2 iT+9g+nkEiY3b/5DGy8ky8Afesf7wR9ndAHBV2eA6xcuwB0NC8nUC3wSPGcRlUQxfAJ3qwv84/09 xxs1jN7Qhcn4dgxb+ncxniBjxeW5MA4fuVhmNEronHKV78Zrcfmoi8dCzjG9ZwpTGlNJeUi3Zlxz jQuVCpnvwTiKJM3z7TnWXKfI5Z9WVcMsUZqSIipCXXoTZSoKxXgChEcgzXNc8LDuDuNA9UhgY3Na YUIiJaMScEiWQj7mQCRttUZJEjHtTbLsBRZU6mrQSFMZH4joM8OSoKCgBdbxqcyNMlnwlaKFFEqE IssrDSqlHf88DEgmcGXJVAq5wgaEhikUPGbJwz4sxKLIiKIVQ5M5a/olOMwIpvkwwBFHtIhXkah0 DVegPXEHsBzmhJMEM5u91Hy4Wi/JlUp7DZU+4+BjCoaKC6nSo5kouK4OxohJiNIEMBzAMGPVIDKX uj0JK2GIGM+pVLVQ3TOkMMHdteBGBhYjLzJkbvShVsMT0bASmIqlloGREknmFRBLtCQy6qnXtVUv w5UiGj2ork6THGu6oxmv15qMSkmz+lBI2cKwzHBiKOXaAQNhQXBYdIo55CiS66G6ZkmBYTx3Per2 mXRwZNtBz3JrgldW6vLUjcBjsgS3stbyLZRG6u4RW17Gfnedq7jcAy+74W80dWrYKGYLRsvudwra F7O0Z3Vj+O78N6EPWp3ZhC6rXVJuid6Oe7eaWNY3CLaSN5Cetr8buWey3o1zv9HHmpGebdIr25JY WmcHeF1KW4gbS2kJdosqV3dlXYi2a1kdWyV01+cV4t2oHa6dUf+nTOsvL9uag/KjtcMOYX2W1e9W q3D6RXziV1SXJCVRgXCqgGTuivPq74Lhtwl8C5WYYan9k8Pq+++1xp/fkRBGv5DxKnB+4PUP4X1l 0mVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKODA4CmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGgg MjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFV9ty2zYQfddX7FvtGVO2lWsf 40km1UzTpI46fYjzABMgiYQEGACUrH59z+JCSXYv1tiiBWD37Nmzu9APulpe0xW/8ns9LC5vX1Hr F1f0Hr/t4sfiOm6g/FYPdLPBptd0vaJNs0jnrmn1jF69ek2bYXG2NkE5o0L11okm0OOf9er2M92u b2j94ckaft6MTve0urp+fr75tnj2M21+XZzh81s7BW1aGp0Ntra9J+EUadMpp0zo9yS1D07fT0FJ fExGhAkbhJGkRN2d/7S4flZsOdhSjgbxXcGMwXapRoU/JpBUtfbaGroXHpbwEDoVT7B3KYKAqWhE 1UpvsaVxdiAdPI1KOb8k+lOHLp4ScssmbUNG7eAQXnq7H/BZtjEKJ6RuBx9x8hGj2KJ15EcAEb3+ C/+Lcex1LQJg+QvexpHzmWxGDcq1DC+eDpbaSUs1A1fuJz9H0EymZkP56Jd19XapVWgqvXK+Arv3 vRoqH0RQDPQr4tkwSD4jengIO+u+V1Jtda1KGDknVeKMkzvaceojYvJT02Cvj2EN1geavKIaWz3t OJZs5TiB2Q3V1gRne44WhyTA/GJ3agsuEwusgdlatrPrdN1lMpMVOyongnWe6slluQgpnfKe7vfs pNHt5JgeDlzXJcVMHhgfLejXKmWJo9PDaF24VA/8Rm7qsXaklCSDzVFsnK3eWxLUOrtjRz2iZWUc uIipAPigUi6wUvHK14vjXHUI2Z9uqLam2tZfWfUpdvEkchp02xXV7QRECZUgba0TQ4TNUc2KZ5XT ZJxCBpOgvk1AmyWUrdyd7aBzzVGLUBxCaNIOQpu7czDwKTkYON7ipLZTL+leJW/ZFnxaTihCgEiG ohsOxZ/UHmmTK+ubqGO5Rm9kXbbEi70VMQyPwEWbekBthxGJKedbVK7JhwH0IzyHBC3b8UgxVAKc ovDEsGqQt+e01U6JiMoa1MLALuTeiAE7LOTZi72feVLLdknvb99RmIxRvb87h92wU0BQYHUoC58p RbhoLj8m7QpvcbUEaKE3BHFUk+5xa4zkr5tcIztwKFjYRgonuaGUsp3uoWtunbaeuNiR65NYNXfy BkSzV8Hpu2CedjGFygi0imyqmVzMX5YBozluWkkjpeQEbYVDz9ln/VfH1fu/DQn7Vi9LJ3/zH4CL 4rTZ2n6LAltR2I9cqU2uiwitOh0NCrxym+SmXixwdndOR5LvzhAGHi4HK3Wz5yepesVryGtym0PB 0SX9e1nHFuAjF3byByJyEScJqHnaQNPAcYlaZigK08voucfapoBdnvCz5tKQ3C4tChoPUQbwgHSg J6EaxGFExPwOCgqUHuC+K0w0d0pPkRh9/u3DJ/qwvkk90Xd2RzADLZNHaUDZeBNj1EFq0TJ1RF8C Kn542Vg+JnoW1AVKz9RxeO3jYt1rLnSE2uNQ3SFsnwZmtsSngUtgrG0BefIdkjTnL0WH1BzOAsnn RyB1kZ9yDgzDnFGwMkMpwaXuhIaN0oW1VsEwEwAu0VDk3Ibm+wR83Uy6j5qKFZSUxcTOXEYaYeHI 99yFin/sSQ3QqRFFFBkp5+PnjIKZ4M3qAWSUyXPUUWMV7vgsCmUukJiYCWMuNvlWhahzFlxlDboD tvyDrRhGEU+cb4TRhGEh/PdTDb6J9RJHuUqDp9RVsmGAl2+M6GRY12gLTC86r+QkBCvF/kSDkz8M 6nl2J1BH+gA7W1yCJA/4DDJlyC9zNEc3CYzHB66hWBfZe6xvnS6TBXDsWz7hPsk3gkr/zxe5pO84 Ko6uFzrMV4G8/6CUbGrTYUe6mmJ35LSJdp/QdDTCBQ1TH3R1AqpcAmKVA4VHv+EMMMS0sTq++WKy nSau42pyo8UNJfYX4JLxSo8H+I431GafLtAHYYA31UfIqRMeEpe09ocvY+3JqQvijEf+uWaAWqog dI8k5Iv3yxfR2I3ohJzcBSlE0y/nLw/vHka0TE8f62DvkdrVi4v4VeLxl4wvn/he8JxnybvN4ne8 /gZ0DU5PZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iagoxNTA5CmVuZG9iagoyNyAwIG9iago8PC9M ZW5ndGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVcFu2zgQvesrBrls AiReS26adG9O4nYN2HHrKIdF0wMtjWU2EqmSlB0X+/E7Q0mOFTdouzIMUeLwzXtvhtQ36PdC6POv uSdF8Of8AjIb9OED/bPgWxD6AGhuSQFXMQVdQhhBvAzqdSFEA7i4uIS4CI7HyqFR6M5ujFg6eHmN o/kdzMdXMJ4ezNE1LI3MIeqHb07ir8HgHcST4JjeFzrFHJbagFshr+8BxCvhIBVONLOJrvKU5xUs ECqLKSy2IBTgE1MS+ckfQThoEVE56bbgNJRGZ0YUIIBob7R5hBTXMsEexUdv2/iY8hq0DvSSckgL qU6qglCAxtpkQsnvlFFYYpnnemOJ4R0mTmoFEWQabSe9VJSZtaTohMwtw25YUKKVJWaVQ0vcU0iE l9OQLCiFVESVLSBAhvpQSZIvFVpvkEGRSpX5xRsjHY8b00AYj7SmBR7HNgQHLRYvalm/Yb0lP6wx 3+7JOW8xiCGsZLY6y5FCYC1xQzoaKM5Jr5WrdSjt5FImghEs+cG0lkYf2s4lEaoBaUvXlOuUJ6uS io41fncaiJywW5WsjFa6si2IZ9Gra8g2eCeF4cqxQOJV29EKfEuxoydRlDnaZ0GV3beyxWBL7Upv 1D7AxZ5bl1TSNZqWDNeXrDONEVyxEg3dCkZnZF3uZqkfbCLy/VYMeyGBX2vFonyQ73RK3unKJhsr fsQtkL+phaPp/V18dFrf4Xbmx/PRp/vxfHTD47u/h5PJblBHdNqWJmb3kyaWR88o17PpdHR7UwNN h//Qjet+NPsYj2e3w8lRy7Ghtts/7CCVlZpc8tlRGnT1RqIGS4xc1Oo+z99fR2H47sueFxE5wY7x IbATzEVtrG8B7MudJpojZOygEI/1xtkIk3a0GlyiQZXwcg168ZVQbS2i2wIPx7vGeTgh1OHepmjF eialD/IHSI1AzeD8DiHSJLjuowXS8dE9fF6/jK54h59JOjUEcW3yvX79233qKP6dVa/F93u924N4 COnt/6D2/AH44eX7ZSkSfDi2Dyf+FbnqH36a7EXqX/ThcNVvxXt3fq7r4OIqY6vrV9oC4L3MKtpY 0V++0fwX8gdsm6hBHTVtovhTThmuxEqklTkFpE2a93aLRk+lpE8DzBKnF2ggOj/1n+yXFD5/FBnC +RdCHMXBJ/r9B81DNtNlbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjg4NAplbmRvYmoKMzIgMCBv YmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VZNc9s2 EL3rV+wt8oyiWvRXMj3ZrtxqqjiqrPoSeTwQCIqoQYAGQCv699kFQZGSnJmeeqo1Hn1w8fbt291H vsLpcASn9IrvvOj9Mr+Cteudwu/4v+699kYhAOIbL+BmgUGfYJTAIuvV50aQnMHV1SdYFL3+RHth tfAff7Ms83D4N0nmDzCf3MDky9E1/LsurVSQnI7OTxb/9M4+w2La6yfD0RDCoVRkUksvjT750Esu w1U6FS5KB0yD0F76LficeeBGeya1A2sqL9ywEylTCsykSGG1BekdAo7OGkDNCoFgKbAmPkJh+Eb6 XGq8QqBSrwETeKa5gGX/QXAiB8kwWZ4MEZLAFrmoAb/8/bCAlYBKy9dK/ByIeCoVSQOFRKS1fBM6 MGqgTIaVCnAE77clcRDD9RAms7dzZAAwZjzvnlBGryOaN+/l/l/Y/0bYoyI5apyzNwFFpbwslSD0 Wtr3YvdkFUQ/HPYbA8ZCYWx9PohxUArWFiVoi7psZb2mKMmZwjQO1cwFYqGiLlAkmR12C79mlIjI fvSmNMqstw3TiLTsf5vf3Z5/Hl08DYA+XoyS06d9JXY6RnBTUqOZUltgzhkumY+zgaKO769vpuPn yex5Prt7vv1jfPvnng7MeytXWFo9pkKzlcIy56iPxVJKhijIesNsSnou+wizPAGeC/7iAOcL86Ia kX47JwENSZIN/RssUieo5E3EKi31yIMrjckonpZAyUJ6KJiSXJrKgUfLzCTHLHco7WSGSfiL8G4Q Grjj5UxlcQhYmlrhHOVSxrxgtqoMsBRsywyJoxVnjItl3yGzAzmbYaVgKjS0MxSKiY9TZKbSKTKb 1IshNTcF1bFjVXP94Nq0WJlHOUjY3UId8wrF6f0Ka6w4Y6QwuQkjQbFH6ClEMRUOR40FW4g8fwWD MHYjnRh0ytsJSYCpdDwAdsYQXYU6e7Blu3U4XL9BPRIieJf47pvagqNpZFzUrAqTCjUI9rk3pdwo Ff0MT9KWDlpN8DP1sMlZMot7i9f2nCBSa/3ACkajynAS1mF1Hc5UKzr119a+q5TZkApZhmutfUTa O4Y6Mm6NIzwn/M4vLF5Ab8PGF+i0HDPWeylwhSNO0B+ZTtkWE57Bo7S+QtyZlW8Ufy/QoOwLOc/j 7J6aX0cmgF/p12kSfo9wxPgQYoo+8SDsmww3hsfZ9IG2rjaPoDhOCXM/UYpUvDeNP4TwsIxdGri5 9W+HfW9q1OhN4agL6oajH8/IASY3Yc9K7G7gnhpsijYxE/60BRWikx2vdlyWfSVfBFzPZwhS85Pr 3FNdh04Y0pJS+15KN8TYsHae8GMamoX3glyi2XYuMXuEvTepwfXfuYsu8nh3oVJltoXcbFpLiDZG g7/zv5VoV5kmubGpozEPS2WNii7TyiN1Z6XjrXERYuhY3Kfj6vFbclSCi1DN3Z4gdYXej+fJ43Q9 yICzmoaF7JhaOHP/lc613u7I29EV3kkVaFbuvecatDCO96sdna4i3dJplDoKHS5nWy2Nw0USunfD cpZWdgAYw9Rw94Q9/l5K5AtfuTcrGvmLQXjePnwS/zZjawGXT4g4XvT+wtcPJL/ZdGVuZHN0cmVh bQplbmRvYmoKMzMgMCBvYmoKMTE5NwplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVXbctpIEH3XV/Tb2lWYGPCGxG/2hqSoii+L lYdUspUaRi2Y9WhGnhlB2K9Pz0VIgLMIiqq5nD59+nTrBS6HI7j0T/rnVfZmMYWVzS7hE/1W2Us2 Cgcg/fEKbnM69A5GY8jLLN4bwXgC0+k7yKvsbK4cGoXu4oNhpYPjz3y8eILF/Bbmdyd79LmpjZAw vhxdnef/ZpP3kH/Ozvw6GN04oVYglHVMcYS7L085cK0cEwrcGqHUUuqtP1MxVTCnzQ5KgbKww/M/ svHbFksTi/un/Ob+r9mP+5u72fVr6MKCKFA5QQgFLHcgnAXFKhwQ1mjSYsER1hAgX9PdQG6J0Cjx 0iAwbrS1wKQ8iWQJLyFRHgxWYoMKSMCtNs9Q4EZwPOFvxPJCCuuuYzT6egH8CujSy0uxrNVcMEfs t8Kt6QCdSsGPU2i5EPsZ4+tTNThTsGYbhKqRTtQSYwynO/IGa4OWFAu30XoihShLNH7N7Wq0BP9R G8CfrCKIAWiFsNWNLKBuXIc0f9xctSAkiT/lDUM1hbvHz0+9LaY05W389qFEr9nl5utv3KJrJ7Ri smeWJLPwXi4Zx77Y+0QPRd+f7Ut/LPRJJfrS54S2R4m4a5S19bStM0S808hHXuqGbG5E1Lpm/Bkd pWW2zBQETYiPYc0DVCHRkLnFvuM60gapXga5k7tXzIPJmJ2DTr3zSgJJcYLvhGrbythBQO+w0Juv 20/dQ3zS2s5nQVbcBzlpjMXDl3y2+DH/cB3YBKuYC1HE2nbYsXaHXQZB4IN6efpGS6glUyk3xr1b bNQl2u8QxrYzIITsCeX7JcwES7KKMtqfBR9p2AjjGibFfzQsoF7vrOBMJv4+cK/T9j2Y7qRTtu3e w+U4ikLzsiRor2lbfYY96f5neB1lCn1LtqOr0BVVvFeZ8XDi4X2odDq2ZxiyaH0rCQIn19HgdpQA qV4Ir3Loeap31LzXsiT7QanCveTAYwxbI+9K/iwIklwYCXw/88NmEObKIJFDx4ffz0Nof8FicG2c Db5SEV8rP83EqqG2mRzNhHaAbMgtJJo3UdgiGBYDB3WupoH+LVuzojEDCkwaD/evwtnPmtrRwgN3 ekl1HP85CC/G41fmt0e2Qpj+Q5CzPPubnl9EXHIvZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago4 NTcKZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCA0MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJVV31PiMBB+71+xbwcnIC2KHm/qVaczh3KlPh03N7FNae7apiapP2b8428TSqlF ERNgt83ut5tvN+EehgMbhnpWMsysQ/8EltIawhV+l9a9ZRsDqESYwXmARqdgOxDE1srPBmcEJyen EGRWx8sVFTlV/e+CxAraw3P8OfjeOXjTrTUcZ4VgKThD+6gb/LVG3yD4YXXeMmwPwUtFu1/2M37R E43t0Qf4B/31OECXzVP/YHeol3d0E/Vtv+FgcL3DD2xcR2dnvJWy2XqfKCXYHWr1+4yoMKmfcvqk El70UyYV4nyCWtiPq7bDO6ZrEt+Tu6h9+UDuiruX7xvs1sObPRxVcqzldPZjbuTZhXmt+z4mId1F 7qJzm7OQSHU4LVNltEUXHY6dPci9ZMtSUBhNwNcVh4xHNH0VLUiYhIiHZUZzBbKgIYsZlaASCjFP U/7I8mXVF+q5oHLyas98tckJTI0FzyGiUrGcKIa6NwMSRYJKCSw3kIaRhJKIior3FcL4MwjjLQRN bAOBrJhOyR1NgSjjp3gBPDZqY1EqEv5r4JxdNGB0mZrJVJnQOheKP/ri2t7RurINNJaHPNNksvXi Op8Cc6CqyQdk61o3ABadeQ+uFl3gAvWvRu/BI6ZAYQ4kj+AKiNAMtc9eIWjMnqh8VTqXIKy5CGB6 Ow8gIQ8UiJQ8ZETRCB6ZSoCprU7II6K4eK6vz02k+j6Rg3aT+De3gftn5ruXru9eX7iTVePhh0CO vSdwsyk8kLTESiVYMqIDSgws2ptBFgsidC4mA7QRPIOIxTESgT1cCK54yFM5AJgrrFyILnmsT4Ip 4+a86+ip5HpZMqwfbprU7jr0qjqlKLisioUueDzSCLE9tTmF5yQhUSl62BEIOajPn/tUMGwZuAkV v6MCnOOe+adqn9NfM7KkcPobEd3A+onzPzDFzf1lbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjcw NQplbmRvYmoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicjVZNc9s2EL3rV+wt9oykWHJSJ73FrZPRTBK7saY91D2AJCgiBgEFAKXo3/ctCH5I dppKow+Si4fdt2938Y0u5gu64Hf6zevJyy9XtPGTC/qAz2bybbKIBpR+8pqu1zB6Q4slrctJu25B y0u6unpD63pytjJBOiPD7HcnykCnr9Xyyz19WV3T6tOTZ3i92zqlaXmxeHW+/jq5fEvrj5Oz9pHy JLS39Gjs3pDAVVEro3xwIqidnBX4K0wu50TrSpK2e+ko4N9O6EZOz19MFpcjOH5SqU2VjLZOltLJ dv1760h+F/VWS37oJOXCUCYJ37f3d+/J2SZIICasEvaLt8v5xXw5X7y8XNJehYrECJRsSa+BvCpx O7cmOKs1tt46u3Gi9gOWaMH/J+Zyyg4a/hogBvwXPqHtldYcQLvayYKyQ4ybU1ELIzbSzQeEu2ET X9lGF7y28VgWLBUqDwKYmazETlmXCKsteEqsjeKBk4PLU/JS0r3Mg7KGruYL3nP5S5eWG5FXyWEm HPCg3HubK+xXtAyoQNYg9rSh3TKU0H1KhiSLEJzKcNcf72KpNZ7tpCmsmw12v9Kf8ZaP2/utzFV5 oGTWXqr8VEjDcjCkzAa0Kp9EWMgglPZMAt8dbFnN8MGrYpQ3zofP7Vb29oXNm1qaMApgOX8F8M/y e6jsNq19R6a9JidBtscKz1q12VdQjZu+0YFdK52te4Vpax+bbZu9o6BSEqekyhPjBOVJgR7Q0oYL WYn8UQaOCAs2qEaTPFPcDUrBme90+pyvoRJhsD1OVwrVdzVYNlof2BGrdxCF6R5DEY05vY3o3h3F dmoAkXEnkd8alrQyKLtaRHVC6RxidBmBbSwH2waagoNFiEn2ILddhKoCwl64SE3UKieiD43XCFSQ Q170IeGgXg2uo1PoSFlfUn0iRO9uXL+FL2EW7Cz+OaWamTheYGh1hyALBO+TRzfc19CmR8vARBfY UZZawphJ8wzDrGRvawm9RjGIzh8HThGnP20zsYVIbIruHdsrlSoW8GnqEs4PiMi7tnQUXaq78XZ7 Nux9intQZffshpPccKL4BogpyflmHucNOzc86DGwSGQYDRnLcNNo4dhqlHd4jGeCPt19vKfQILs6 3ctsqLrAVuUTaiBxY0Pv5igPT+und6cWysSKFEf58bFJCygYkXy+XfPgwZUqRDtdetnAUOtWvqrd 4f3qmhXYhMa1/sldLFOuwFxgDhxvlZBGitvIMOTz4UyrR3lKM1LHVIliJ11Qvp1Iousbqw93fTE8 nMOZ36yBoZfPlj77Fc8GmcwhxYQx4uLhLOZUsfs+tlfR5aWt6wJniofzyFYVx15UDRmbsLQ1nJ9M Dhx6DjSTHYHYZcTeUQf7izOH4LUUPk2vvrFiQvdhIE+dx6N0Px1sqRF28zgJL/UmLoH7Jq/6zg1U NBieNDz2pVYbBfEOLewHIXTKiXRgC4ze/uzAPQVdk81mCajDbTc9StiU9pEAnEBG8vUjEki4Z5IW BTOcBowdZeG/Y09YzzOArtP5+tPoE9DPOBhBduGnLtQX2TBXaltAdtjQ7uOQBh3oxGiAKDEVDgyc ToUtmAd91svjIvNoGYdIxMAXDsNBAfcwbyWHonUnPWFoHa+XUU3XohJF49DzMLn1vD+H33zfxt59 mwebAWb5ehpP5afn9b/v0Lfo7T9AvFlP/sD7X28++PplbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2Jq CjEyNzkKZW5kb2JqCjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1VTY/aMBC951fMraAllISlbHsr6rZCarctm1u3B+NMgivHZm0HtlJ/fMch FMIGxKJOFIWM5735sPN4hEE/goG/6icvgtezMeQ2GMAnuvPgMYiqAKgfvIBJQkE3EMWQZMEGF0E8 hPH4BpIi6EyVQ6PQhR8Myxwc2jSe3cNsOoHpl2drZO+XRkiIB9F1N/kVDN9C8jnokD9HZ8Gg1XKF aQ/cAiuSgimWo4G1kBIsqhQYKO1EJjhzQivQWRVrWYHdV0E03PI9dCwi3COvokbw0O3Tevxmu54Q SK/QMM/rTMldaRAYJSgtZfS8lAmf3EIvQVhgFuxCrxUI5RM2cmUi9+A5Sr1uZjnLjC6dJ9wN4wz7 06jgHACdgv7dC9LUzYdSWPfSpk5XdxU+szYXcTTRETXgGzm3grbc56NbGt4fSVhgMaeT2WJ2iVww GdbhJ2d+elJH6thVwhdMqIsS1MM8jt1Vf1nde/6rg22+6AAc7lzLTra5/hdJcxu28xcpvWBOwmVD 4YUxYxx9gNQ5SZQMXakUygqz+Rmi4uzYVHf2caMp1+/grhahQqcoa1zts8CZIt0BkaLyoogpzH+T iu0cBpwGbpA5UjeQuKJidNbYPKFSYTZC2d8I4x6apM+i86yHkuy10iDJpsKU+EZxxTdhC5aWpgcE YrL/r5/bpyUlsfCVO+0/m3jUq/4FDtr+8c2LbzT4SYy3SfCdrr+FLHL3ZW5kc3RyZWFtCmVuZG9i ago1MyAwIG9iago1NDQKZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nHVWTXMaORC98yv6FrvKEIOTdfa4rni9VNkbL+Daw2YPzUwz o1gjjSWNMf8+3ZJmwDiGoihGre7X7/UHT3A+mcK5vPN30Yw+Li6h8qNzuOFPNXoaTaMB5K+igasV G32B6QxWm1G6N4XZBVxefoFVMzqZm0DOUBh/dbgJcPyazxZLWMyvYH735oxff7ROaZidTz+drn6M Ln6H1e3ohJ8HC6EmoBdxjhrIBBV2YA04eurIhwnAig3Ec4kBx40tScPyr28Pt1/Bd21rXTj9MJpe 9B4RtrgTv7YNyrJPvWNfBaln4jPDkWrbgiol0kaRg411fFDxuemPJ+xRfP3JR/SCTavpjDERFGig cITh0FeoMUBrlQle4iJc3dxDS+QS9uzLUeiYv/JXEMQt02BgTdB5thFMrbOVw6ZRpgJnu0A+e+IY MVpPnseGBuQANzGTCCpk5ho0WHGcGn2GX2ZfHFiZUjFBQlaMG2/2KTAciS+O3uI+A7WRox6XQ+NF D2gx1D26wVNRo6nIn6UA6RcHT8ZbpTVnnz15wkaT9++VB5oSWNhMy4EA6ULCn33F2NE9dsE2GFQR a8IHZKSVlfTsM7mc4/Yojb4U/u6zP2ArcbPng8m1nS5FRWxbrVhIxmNsgB+dD9lRZxiADz2dzMe6 C0BRMzs8zSRZE5ApYrKU8TFtwz0xqDdYfz9ZZkyzyafJ9PupwJ79FnsiPpnsMwi7diilVa08lLbo Gs4BfEuFJMKRgBnZQUWGnCrOogDGq7WmCIIJ6JznOnvVebFaMTVUj2wf18cqjxJnYHzFAjwc8QHj JGUsO5sKlNXfYNFXB19adcbwGHjvDoR4vrdfEMtRYGRIKx/khnyD3RxQbmFbqyJWrssXON9XOUpB YfFI4TiNf0lVNSszuBcWtMVyvEaNpmBoezj3zoas16E5z0jmb/dxzRG6Npaf31/q9cvFkK7EH5J2 TVhyBbJUk2oCd/e3S9C4Zo5ibSPcLK6PE0lXjhO5jYCYlx7ZIHYq6syijZ0PuLbPB7rMc3e8r8zb KbK/vZT6w1eyRlpYfeviHMwVWsCWtB6XtFEyUTediWT2ZM0DcFnTCxuLIrGVZFzw9tpa9wglPauC qzxOhRrjYtCqUUH2Tm23Mi93r9jS3J86sWKtaJNquYfGQWJv2hSnRldu0VE/1ZglTfvhnbdWNH3k eeIPq5AbRiZ2gS2ulZZhZ6iyQSXW11TYZuje2KOqEWfI7ZuGN2fOE96zcZySx5vz7mG5yjTuYm2L I9mYcQ2aN6OW8WpCZ0TpLuQheUjjhx7NAJkHCGdxnfZmTG4ru03gCLnskXccPKNTtvMDA8cjTfjz bC/9D/10u5zMJq8K9ngQMKcc4td55IUqk5+XwH5G7GXOTZT2tqNeZZ5PUi3xkRDgqOH+zQ44QDlO y6e0UZrPs+jvCmssO16SJFJPhr9C1y8t94iHb0Wwa+7N2eez+Mfo6B/Tf/e8smE6/Z89Xq9G//D7 J1fQKaZlbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjExMjUKZW5kb2JqCjYyIDAgb2JqCjw8L0xl bmd0aCA2MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nH1WXW/bOBB8969Y9OUS wHFj97tvSeO0BtIk57goDpdDQElriReJVCXKrv/9zVKUZCfBJS3siNRydmdml7/odDKlU/kNn3Ex er38QGk9OqWv+J+Ofo2mfgOFj7ig8xU2faTpjFbrUfvelGZv6MOHj7QqRkcL47gy7E4uKrV29PRn MVve0XJxTovvz9bwc1ZWOqfZ6fTt8erf0ZtPtLoaHeG5sY7qpixt5SjZGVXomGqdGpVrk9L9EU/S CTbR1cVtv88aUpTZ2t0fkzIJaXP8x2j6pgvpsMQUq5prfGfi3wJc5cTGabejQqeZo60yjpylsrJp pQq/0zXGcI5gEiZjlXAlh0XWZXg5qcmu9/ZNiFb9H2RwTGZL0jU9culCkJQNV0hpqxGiLjnWax0r p62p5eSNTjihta2otgUw26KwJt9RU+NxG7iehFALJ7H5N4I4Wc2U82AS5dRJYRNg2Oo8p/YrVuoe m9uVqIVgCLFwUJmzY1Jx3FQq3skhs/ddBa9DLnGmNIDGCjXgAMqGNFDHJncaYUKlUJ0N6qWoVPEj u/EBJxEjSe4XJRM82KoK+aOON4bBumBCgsp/6rpNESX/fnt1F4D7I74u52PaZlyxNr4EIWimaugB ckDN/Usdh2ub53YL9NGOVIiEIC8uG1rchoVAsG2gnwJyG1aALoRJUIukfVWQwB9bWz3i8UbH3IJU rQz3AYlqBwAhlEKBgkSGgLE1rgI+j+YaZmFUYPfsHCE+4i5QhPoJUcEvCouPOujXHHIrSJCzqiLt KiWRmyLqIWF/QOy3e/5TBq6uNmL4PQHefbv5cXXRKRt0b9UuhAIeaFeceYBAXB6rUkU6F28GyIEL SvWGTZdsX3FJeU+ws8nbyWwyqDbXoEo5V+kIzHVEXcJk4eSgLKl3MDS0WMh35V++P6rvj8d7IYID DhSt6trGWglUb25WcUYFS/G6qB4I8kbpxfTsH4JMf6wyAZisoloNGtTz16XMWzuwt4cJ8EOEXjSf D1xsiW6XN6v5l9Xi5vrhdjm/nC/n11/mn8Gc7ttPLaasdAHuX0fwUSMFfDzMFT9lxWto2aDyLfPD A7Gqt53jFOg3Km+4rXCd2SZPpHfU3HXEVgpTtPZwKpo4qJnhQXv8/bFvCOiCcI/x4vUeb3f3HA7h 1gqTRbcmg4bX6LBU8UklvpU+iS9p5ldDfl0In4nei9RXF70N1EX7fpQm3WFpeaoHxUgGxhoeQrUc FpOnjFzdnF08nJ9dnYGIh5/zxddvq8AH/vkOKwflViUnkcqViWEQ4JyLuuSkp7wEyXz/cbcSvFAl hieiwHrs51wE8zDqOPVW//Qp0NeuDngTliYHi9eh2lZ8iDnlMwlVBXGeS0zO0OtDKYc4fQqhvYu/ pS1TJVOvk3bA5v9C3s+ieEcMTbDd3tY7UNBbuYvh6e6N/b+ApAQY/Fx52/Mvsd5hxccY++jYZ38N cbqpp/bAvzp99YIuDvXFrSGGQPKS4MV8rjYB20sY2qsNMi7LHAIcdxzvybVdEVoEwdPTD6R31rdd r1ek5kcLOjBxzgUoDV0xUxv2N54Dpb3YSDzCFwQtbkfuP8W+/u6016pwMSDtgFVh+DRGRosBC8je ghB/M3ppkIZOIhUKkdo68YHrW1GiFJeL8xPOdaplEh5KBSO1qdC3Ou1D6Q43Kjl3r8dh8f07n/y5 ylTSVGNiGaST/kI7/11qcEg3sbNS9tm7sb/ePrn3/n2rUsal+h9EnK9Gf+L3P3LCr4llbmRzdHJl YW0KZW5kb2JqCjYzIDAgb2JqCjEzMjAKZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCA2OCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WTXPjNgy961fg1qSTdWN722xzc7bujmeS bGr71nR2GImy2UikIlLx+t/3gZRkfXja0nHsUCDw8PAA5o2uJ1O65lf9GefRT+sb2tnomr7gvYve oqk3oPojzuluC6NPNJ3RNo3CuSnN5nRz84m2eXSx0k6WWroPv5UidTRcq9l6Q+vVHa0eRs+wFkWp MppdTz9ebv+O5r/S9j66mE0+TuYTokf53e1NQbFBDO0uf4hmv3gDPujI7SVl5iCto0y+y+yKBOnm iND0IslovNNbnOQzhkglcKRSJctb2u6VJfzA9LRNpXQV8kno5egjILWDKV8pke8qlvA0nTcYsEpZ lNLyYb2DI4MTZQvClKOteC+U7iUCUMsv6+Vm8231uF2uf198XtbQWt+ASMX+aFUskGRmdvyFvb+r 0lUiG4JSXJJUxJz/mRzA7CJJ4JpDWJNVTsEur8Aj0IK2mi6f3lulSpDhHTFdjWs42fY2KBdHnM0M iHAGiR87bkzlCVLaOqFxeMjA6olEgHRLC2/OpTWvVdFGPplwzRKuLMIkEuFzpUeF4bTlLph3MJ9L 3ONuUz2hTmQhdcK4axpPjnr4sX6EZ02mYIcoDetdi1x6GYrMGg5gCxmzxBLGreA4FsiS/cJ8CN9X kQ57Fe+9ST975x0yQfBWFcjrqw7BKutdnpLAatEgeOajJ0g0Dg1UiPhVOkpLk/tuSUwOhXKqpuek EXJ4joh3RxCUiipzTQ50UFnGwPhvywGF9d+N7gNye+HqIgfBcEYjTQy7AhCSnlC8/upGR94JMxYL Ky3JyW4yZPQA9PIMl4IypV8/ZIZ7qt7/f1geFp+7YMZ6Cz0FdEIP0UgmE235X+IEQO7Jtg9TdD23 w4nPerKMILtKa5mR1LEo+lzht98dDi8mpj5lyiHgh6f7zekpeTFYLjBEoHQg3/dpYuIqh89JryVO eEck1ajOt0fogJNxV5VAnnQ1DEFBan4wnakFoEEkaZWxEnS/Sfrz0d83ELml5ahK1leeG0VLmdge ngImpsxbcXXKGMrmpRfAjsrVTPVA8aBggf37zZO/UghibErxfNEWY1ixf6nN8+VVaMLuLROuPEGV Vm9Vh5zO3fh8sURn+WHyfDlKASPg2+PiYckjvLnvCqOCvPhK8EOiKa0NCJgVPwqG8Ovx39Dsi6J0 JUMyXb3Aa3sbcT8fMNDP1cXfvbAPnn2TT6c3PuSd2IukKq/Ql5jXk3ZSLb8XaDtLX2NnXkDA7Ocr /88K9defT2InaTr/Cy6X2+gPvP4BYDLeE2VuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoKOTY1CmVu ZG9iago3MiAwIG9iago8PC9MZW5ndGggNzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJy9Vu9v2zYQ/e6/4r41ARwvdtKm6zcn8VYDDdI57oJhHQqaom02FKmQVJ3893tHUf6VBGs3 YBJiR9bdu3d37066p+Nen475zN+y7Pw0OaNF6BzTr/hbdO47/WRA+UuWdD6F0VvqD2g67zR+fRqc 0NnZW5qWnYOxjcpbFY8uvZhH2j/Gg8kNTcbnNL56cg/HsPLa0OC4f3o4/do5+ZmmHzoHg94pTqKb SkktDFn1EJeuCoevOoM3yQKe06UOVDhZl8pGCmw61yqQVD4KbZtftpx77KKoqn3lgiI3B1r/pEVT Qi7xG8WlKgnA6qEyQFEFzZRxq3c7oR3R5fjmYji5fNfQ0LbQUkREj0sRGQRh48r5OyrUNy0VhaWr TUGFdxXf3omNoxLyTkUStgCW9CrlJBpz6Wouce8FCl9ux9P3X0aTyfXkB9nsk2jJZTbdF6kknkHh YwZLXAEpY4iqgqHXCE/Ke+epVCGIhaLPB0bfKRpfXH1s7nw+fJLSZHQxGv8+eimPnEyE0OZacpsK FWLq0hyRnqnrbt6QwC+wUw+irIzqEqhGJ53JCQfCzevhVXvZ26Q1NIaMk8KYx03MlsfN++tPHy4h FDAAYjR8z5H45nTBlVMWOtxgQWVB+dQHESMX0NmUl3c1ivsKEnY2eqZlhGXSQ0uuitrZbRiPyhwZ XWpuiBSW47dTkOK35aOlW/F1S67lvYHar+ITAjw4MJJeJxp5UBoKG5iWDPqCTIIuVLIK0lWqcdma 2K3enyDCRIlC2wXNvSuTF1ZGRh6m9VGIKI5KVyhDV59upoRWIC2kjfHG/sGgA1THR87UA4wvPfZB l5PakQXQUGLYRJ7ux0ZXjXNOdW9aRFFqqwPKFlGfq+EfmVhDwWfmSNCBuG/wgfscN7SgXixJSImp yDAG0KHVwBPBNqXHRjOBQzSe2Ud41VY6Y31XvSmj7lU01FXlPM/6vIbcUxFzo7kBaebrWVD3NeB2 KrreE6JxS0zlUtgFz65rIRolr2uCpYDNsh6etqgzVij3EHHCLhvBGxJV1KVCzARr9FzJR2lywi0K BGyVZK0i6O1S2bSuuE2cdZrOJ93prlMthQU5n7Eyw+iTttLaQ+fRlAr/Kiv5ocOdwVjMviIo1orm OXJtzHVvwL8x2WoGP+duvY7MbVOqfy39FaDU/6b9FC21+Ael3wg4Y/1H6W+1/Xukn9SwyhXfNI0l wfwbFeyz39HATkWbgj8nCMZ5QRH7WvinkczDwJ5IGJSw431I67p9veH5XIvfGBZ/iqN2PNLzOo+O V6FyNigm8OZ1yudcLEVR+y7xu4jprd/SRg+Vhjldy+hm6PPgdTe9s+29zP35kR/0/dO/gDiadn7D +Tfue01mZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iagoxMDI5CmVuZG9iago3NyAwIG9iago8PC9M ZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9VWFvGjkQ/c6vmH5q IgUSSGl6URoJGoiQLvRus/1QlSoyuwbc7trE9oZwv/7eeHcJS6IuiiD2+M17b8azj3TW6dIZf6rv JG+dRhe0dK0zusXfsvXY6oYAqr6SnIYxgj5Rt0fxolWe61LvnC4uPlGct44m2kurpW/fWLHwdPhM etE9RZMhTe5e7eEZrK3KqHfW/XAc/2qd/0Xx360jrEem8JLW1iytyHOll6Q0+ZUMUHff7mOy0hWZ 52WB376wmhKTSgQJf/y+1T2voRKjvVDaheMLk2Vmw3jCe6vmyOIuEd77WIcbcNbOiyyTKbXpu3Sn U0Mz6ExVIhBOm5UElA14NvBcGiZSH1K6kR8PR44nw9nxYaZB4tWT/HMaUSVRjhZFlm1ZucmekEjo 9DATggQl2FApQCDXkpOZRBqjX6ePpHBGI/2os+zQFCpE4VfGqv8kI3NUDOqAEu0c5mal9W4tE7XY gqFKVmTmv4CPvFYSgrDRFvNM1usdqGywfB3DrI2WwDNOhnpJDUDIoDn+Xwm9hNqNArXCV7xW4omr 6E21v6PB9adUrqVOAUrKs031YRKLBZvB9dfbCorlsVMbYVPsgHC8QxWkjW4HymqP8UnJV2UZaQlu 3lRYiZXsO47JTa2O88M76WVoBJMxMYk0Y1RHPot8ncmTssiubl/GKlwJ9Azq61IXjFIpzAEbZJ1v X/bbu3VUHFKRZC5rIF3KZhNXsrxHO5fNooSu85TCXeelV/qgit4ANhoTfeQq2IHb6mRljTaFg017 AaEXHOCZImfDfNgY+xs2PKlEvnd8jZtNIbRY8p0ysAum8EwRGbEkvy1ZO5NLkk+MapKksNwz++B1 NUMK7rowK171brFeG+uZXRraYE9EhdCQEoDmVskFZcp5tssVSxjEbjZF891zcB0D5tVIKedZ1VT7 x05CazYmGEDKG6beHCb35W2mD53DJNOqhGFAFCEIM8mjOrOjemicFrr+OTtuMGH1HyGXXbvlqSts udTlxeF0zP2aswF7u2FCQLirSNXE3W5YK42rlYcMVNYBI5vtYPeHIvlduHZD4lQUtkz1Ixp/6fe7 3Z/Yf3k1MOrDbTS4uxtEDQeubInaDqNYJ/L68vIzXU2m9/Fg+mX0MB3cja7pHak8dEAVjRfTocPN 5wddKX7HLUQi29wD1z8JKLMjJx8LiTRsyS7ChSn7JhAzVPMSYre0DxQuI0L+hAE20ddv8Sh6mNww kRLjLUk7Y96hzGXz7s0IfjOgRBgxvOOaFhwKZh9nR2wlEo8H8HJyM5rGk/FkFF1Tp9MJhPu9ADAU K5EW9oQkRl/W2TEfPa8VWo++Jt7MwaDXPwkv/kOB/2AQULfPRR/FrX/x+R/+lqDEZW5kc3RyZWFt CmVuZG9iago3OCAwIG9iagoxMDMyCmVuZG9iago4MiAwIG9iago8PC9MZW5ndGggODMgMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVW1vmlAU/s6vOPs0mxSntrVd40gQrvVmiAzI tsYaQvVqWeSlQLsu2Y/ffQEUi5pBDHjveZ7znHPPOTxDp92FDruL5yKUPtnXsM6kDtzR31p6lrrc AIrHIoShS41uoNsDdyUJXBd6F3B9fQNuKLVwlJM0Irmsp/4qh/0L92wHbDwEPHm3Ry81SYMN9Drd yzP3l3TxGVxDarGNQRo8ypsgy5Xb2y/w0OILCrTb7Yezs49Sr19YfmDcOlkFUZAHcZTRve5FjUUB xgADauiZ6gQpdP0DBGESpzlZQhq/5EG0pvootFVXxzEjdYKNe2ULOgaZUZd0l3ClMG/aR6Y6NJCH Lc+2Rp42RtpXZc418VwN43hD/Gg3RqhIRSShny+eqKBBRN7ypzgReYKKo56DBnWyn+c0M/Qt466h hj2IeiXRMk7r4Aq1q7YQKNROVFcbe6OpPVEYlfjr3ltIuD4umQKC5PVSTnNZkL7X95eb9E+YhMkm O2XiL075YbW+8hdka8fPeCf2erwiA7rjKhQOA8fWlB3GE6clnHK4vIfcwzf45wnm/gfY+n6pMCL6 0v9P/zzsiWU4IgCMEJInaqGlwl/1SnzVI6s0DgEjdwRBtIpTmizanRDGS7LJaor3zrfsdr6apLSx 3xTe9Mc07xWA4OBrxxgKbL0ySv8sZs9Qh8gohk4zdrdk+GFzrKp5qq7byHHEHODofexOMfHmFrWC TRfZI1WjA0JHpotHGNnKobPenwD0sB0LaVg1PBP9dL3x1HKUarI8tBKSgknnZMRn6LFThxkLpGAv g2iYDaW1ZU9dpLl4anqWjUbIRqaGtlPtCNKYqro3VA2VArwfCN+N3WokNVXYNmiaMWApM8tuKzEz k/yei5gLUxAleDToGWfaDiZOxJI1B3MM+Z+ENEfBcDTZNNfF54U1SrmCdeX9R6CENZ71YXPWEp6/ XKYky4QXVuLVyoEccztCiMxqtbSdb1M69J/85Ut6DiQHf9OucOgtCagtTBd5/Ejrpnd1zr/T+7os f02g22eMyJW+0fsfB+n5XGVuZHN0cmVhbQplbmRvYmoKODMgMCBvYmoKNzg3CmVuZG9iago4NyAw IG9iago8PC9MZW5ndGggODggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVm1v okoU/s6vOH7amohbabfdu+mSUB3bSQBdpOZuVmOmOlhueFugZpvsj98zA6si4C2mdYTzPHNenjmH n3DZH8Cl+JTf61D56NzCNlMu4QH/tspPZSANoPxah3DvotFnGGjgekqBG4B2Bbe3n8ENlQsa5TyN eK6OUublcHpRzZmBQ++BWrVneBlJ6gegXQ6uu+5/ytU/4JrKRd3sB9whx4qO9GX3gzK4ajdzn2yb mCvbsIgujZvN8tco4oHKozVLpJl2s+fsQP6W8AxiD7w4DVmeweJCxkHsJ2vRFRZj+WBPf2c/rsYT x9K/fIGv4pdqs5DrBZtYCjL7EdYvzI8aIvgtKVSMr+JoB+joBFnDGKORQ2Yz/YDBm+73KQG22aQ8 E87vrj/ubnoQsnUP+FbcVH1v0W2iIw+CbVChWwm6I2TvL3XJvOj2mhNdvzpCC6sIM9K+uXa0ObVd 4oyNIcHaE9ulY0ocGYiKLvA0a2BZmZMHOjTMVSEF/TiEsuxif0xLlqd+tG3MQwlWiT00pnohCokF KZnsNWC5H0dV4ZRI3Al1gDKg0/m1LglxdYOO0FJD5zRc2BNCVMsY6i15lTZ/U1NsgakrFvN/TcM+ B7Tne1tras70kyCqZ0ME8sNPdtfqC2eY8aXAFbXxwyROc/DSOAQ/ORuTuATLzSlLE00rQZgEWTuB eArF03MkKOI9R4sXaPIOot2vgEXnsyJN3kEV7SpeNVFJkwNVpWBp/JpzleUo52dcZTqIqmHLnDy5 ZDV1yJg4KGQijoLsYxvu+RHftJYMG6Q5EUdoYpvf9SXUrhpPjaHY2xi6dE6W5S9qz1zDNMlo+R4G uPMTtR7a74MPRX4a0Ri9VEsr/v/QPH8pxlqdYXmCbqjFjkebOD1G4WCAO/1k66K0c2l8mCWV84el bHBQDFTn3h7Dg2NYluHA1HBc0ECFkUioL3rTcW/sHN+HPIZnDrTixETEC5S4Y6BRMfbQlgUQxhse ZDWp4AgUMBEu9lAx3RcXb6zsppWeKDoV1h31V0xl1OZXSPN+CVX9KMtZtOZ92ZWhM5NdubZhoWZH vAPIIdvEIJOfqv5GOvhkU/dKO8rCoWXuPWmk8cUrjcfWPDss++XMOglNTLOxYVE8Jm1sqIBM/OuX Q1P1WOgHb8j1SZNc9+yFbV5THLA5sKC/LzL5lfgIgMk6j5+xONqnnnxTOj0oU7blMLgVbzHEVb7h 5w8aaX5BZW5kc3RyZWFtCmVuZG9iago4OCAwIG9iago5MjQKZW5kb2JqCjkyIDAgb2JqCjw8L0xl bmd0aCA5MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1V73OaMBj+zl/x+mnb 3XTVOtvu3O4QQpe7CA7Sbb3djksltWwQGGLX3u2PXxKsRnGucIqS50fy8L7hF5z0+nCizvV1nltv wjNYLK0TuJSfhfXL6msArC/zHCZUgs6hPwB6azW8PgxO4ezsHGhuvcSi5pXgddet2G0N+wcehBGE eAJ42hqTh11WaQaDk/7wFf1hnV4AJdbLQ0B9dADPPg9jKRd79hSTa/ij7ox27rx6YfVP/6cznZFo TwchZNyRKoORqTJWY749RR/evXsPVd2rilWdikU3FcuaiTnvVenNUn31BMs5dCIaYv+yNZuxtib2 BJEnpbzMlr2M3fBMord+wRVF8SxEHgqR72jftS3vsSRPRTdJG+vWZDs69oon/DYVaZ0WwlTGPkWh Zzsoxi7yKZYGeirGgF5oe+4qA+w24E0epnTKOe/mbN5lSVLx5VJBx1PbiW3XDVEU7YCj4CpUk5jd DzfjWjot74cbBZPhoohi36Y48J9B28vEq4ocQs8ZXVz0wSnyvBBQP5Z8aTqYc1Wij0wsenJB8Vq3 nYl2LSuZ9MOWYdzciae8Hx3Cjg5jh2aMhvB2LrvKh9AjA20G0pSIuykQ6ELOHuE3EzXUBUiSuoRN kcvuNc189JV+DGbbdmhqfdtePn+o4a4oQbVCO7KGT55KSZXdJQq7p4MdLnZBrPIbXpnW9Mr3ETno 3IF6JQTPnkw3HBI4NokDn1xryiQICLL9NSfhoqj5EtJbKET2CBrc7kPbofiztjTpWkF3JDSA5k+b jv2I2oQgteCNwBNV7yBZxhP5Czw82X1SHYjuilWWwI1CwjXTjwO6aQklm//kdato7jhLeNX0xKEe +/8O+e9GM8zarFkY0MAJyFHUtzGl5MP34xA3cmYas7cJbxzU4q5k4Zy3q0vJ62Ef6+HdHtmGY2Qz es769kN5HknVevwR2a7cZI/gZCqh7XnYiR1iS8lj+XwbeyT4sn6HHAeqLiV4iqnGvR3ooCbsjiWr 6jXwGljW28DRQ5nKnQKCeV3ItoPB29f61byvOmMLDv1zpYio9UmefwFryAeJZW5kc3RyZWFtCmVu ZG9iago5MyAwIG9iago4MDIKZW5kb2JqCjk3IDAgb2JqCjw8L0xlbmd0aCA5OCAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W72+bPBD+zl9x/bRUKluTdu02MSRDnMQav15w2k1t hWjipGwEGJCqH/LHzxiSF5KWxigCh7vHd889PvMXzj/24by86vtsJX1yr2GZS+cw5r+l9FfqCwOo b7MVaJQbfYH+AOhCqvz6MLiA6+svQFdSj8QFy2JWyMMsWBSwP8jA9cAlGhDz4B0fKM3CCAbn/ctT +lu6+ArUkHrlixPwnpJ1NIdHBmEMqzTK5TSY/WEFRzr9IPUvdqZ8KOL9EwvmLFO/ffsO9z3FdAzP d6beRK0eDaRhQ71TPF8j9EF94CC910Iqx51Cbc+/QcYUq+WEGvXkAe5Puxw3UK9rO1tHpFNiW+rD /457ubF4FqT5OgqKMIlzbjS4auW2zFgzNWXsYp84/hB7lFhIgB8Q8soQfo5rU1u3DZ/+crDalUnt 8AP/apgpzy9REDei4TyH6fPl9p8yfz6/2s67yaqYvvlpIMsnQ2xRMiLYFZVpUaDEz20Ojln1XT7E 2sSlU2T43lSzMOVBdMuichoZ9u3WtBnnCQzZIoxDUUZIFoCtqQlJBpptGxhZh6rFFtIMUUzXGfn6 BOs/RIlrhwpU7CDqTvGnETI83IhPMRHVJ1UphTKIc3OpAjT8yhA6MtoIn6suIdSKfseEYIxlE+nq oXyrIEe2a1ZBDj0qKua5uvpKqN112wh/ufRtElHKGot9xhWOR9jFlo7bVNarGPaY6Mh4g1DDRkNf Q1yQOvZvMRlP6H5BGhF3Y3kO1gnXloV/Un9iO16dPvF05A7f4nOzs/BvCZ342HVtV60Wve85LAOL 8G3/IQdsImIIqe8RbjXZtiayFayYetZapUE5RGFedPK+EShc8Hv/n0DMXoqnJJXDOSySbBUUbyfF EdBw6GLPU5sIeRgvIwbBfJ6xPD8GBY9LkH4LBS+Fd1geRYtgxvgJdTTSoBtpcASSXwvBp1PL4meM QDKSZTgLIijWccyiY1Aqb5lLFznbnVF7t46I1you100AvkOrDVQwVbHj9eqYvnhET4CDPf+OpUWx O0L6eyfOTmnHmFnIxIft5oSs0iQrGFdklqxgHc/LnsynJK5KwAkEM5mzKD/sx2EqZ8m6YHJQFFn4 yJ9yFQSpSlXUsAWeFcKcS7i578WnyNsw+yA78wrm80BEpAVPwXydnQH/3gmij7vU8UsacoWCPSuS R94MBp/PxNfTHkN3TrDku+BreURhKv3Hr38iT0okZW5kc3RyZWFtCmVuZG9iago5OCAwIG9iago5 MTkKZW5kb2JqCjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicdVRdc9owEHz3r7j4pdABF0zzUSZNJ0zSDDNhmibuQyfkQdhnUCNLRCdC+fc9 yaZpILVhzFm7e3unQ0/QS/rQ83fzzKvow+0xzCnqwRV/59FT1A8AaB55BaOMQSfQTyEro5rXh3QA x8cnkFVRa6wdWo2ue2FF6WD3Gqe3d3A7HsF4srfG1/nSSgVpr/+xnf2KBp8gu45azdopukUtbc3K YVc4Z+WMf9EZDIef4fQMDkBWS2MdFlBaU8GW0X4X9QevtGqJZ9SFsf8qDYdeZ0+oBhLrHKZB5yhJ E4Afk2v4amwFpoQrK6pKWIakR9tU2QIDpvSYtVQKZghSEwZl9sZRCXMrlguZE+RCe4AgMrkUDGEx zjTgTD+FnsOFcAImpkAFmUUMqbvjiUdxMh8J561w1YHQLBiAkRX5IzqC+D4GoQuIH2JAnStDCEqS g0fcUPJCOJ/NLD6zCWk0sSmuAKHw+TXnBy0qpCHEdh1DhYIhudGlnK9sYOz2e9qyKIru2kqH03Zt wJoYyHGVtWwDMVptpu3kVRfZzt2mmhlFwCOF9g0fX7Y2uINm6S0IFRAdiA/iXTsNFJYWiZuA3rwT UqPt1N7ex1CgNjwQjArt8a8VirLroz17N8Ki5q4TE7ZdzRdGsrQn5oJj74Y6OzEwEYQis2dR2Ece kbV0C7aQG2U0tygexm8051IpuSRJHpAkCUN8Y3VBfu5CbWyO/GDQauZ4cIgnhCfF5+Yid1PTwqz1 XpLxECSFyaKwF0Hbh/UfhftVSi2bzW84F//jhFPgLca0NWH3TNr4eX9BNExe4E8liWSY7vSoFyyO xEIUK9495KpU8vc4ufy9lLzH8C13ZsaDkx52wuGyc+rc34g58sIDS15m0Xe+/wAAVXp0ZW5kc3Ry ZWFtCmVuZG9iagoxMDMgMCBvYmoKNjY4CmVuZG9iagoxMDcgMCBvYmoKPDwvTGVuZ3RoIDEwOCAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK2W71ObMBjH3/NX5N10E1ZQq+sbj0qq uWtpR+PcTne9SNOWjQJCdHrnH78QfpQCCp0r15ZLnufDNzw/knvQUVTQia/0315Ln60TsIykDrjg 36V0L6nCAKR/9hr0MTc6BaoG8EJK/FSgHYKTk1OA19Ie8hgNPcpkIyQLBsofpFlTYKE+QKPKHP/o Qei4QOuoR/v4l3T4BeChtAfAJ1l2Qi3a/yCph+kQEKPhHxD6D8zxlrLjRYx4NuVGexkusUDmFOvm OZyZ+giCG/Unl9ELmVL2VDyyrnF34hUtiE1l14mY8D8rWr3kz8kMZ2hOPeYsHBp+BDcdRfFKLtXX Uqsnf3K0ua2IzB8fOne5wpJB0YZPx4JKcl627eKHiJXWC+OYKP6pE1PEkPk8pFEkL8jacZ/rhb0U A0lr1OVmL7KcWjJ5TZi9qrcqGsZImT0HyWKMnkg/aF6NXnXdUiMv/HD9j65BSBfOk1iP9sp6Cj5O ID8eZT4iZzSeM0lqPBNvqThBPt8K1q2FFWjdtrR14EY5TNDUXFo8pwgDl9xRt1kZpZTHzq6KS4WN 9POZbhgWnE6bYXlhOnm9ZQLfrLb31lspyzz6xOSVH4jqa1QdW3NjkRjmW4mReJiXs8HYGiVtq2Ua 5p74xyRpeGe7ecLv+HI8SftlFvCUMMUWMi9aM5BRTJmUcYVMfKg1MrgVtAY679zIgCZGAwStDQ31 qlLax1oUqcJ/ln4ynsa7UZQoxLSxFcQomypNJ9uQum+Ruq1JtZWl7lxWOYxv0HHgtqs9jR3zxU5T Losd3nzj5lFSg69MEw7l92Qjp7AHz6OuTD2bBDnmbcdCwFeUzHl32bwP1ONdNiD2b8oicLs3ut1v yer+L5ZouzWspF/vSluGtArjtHg8g7WnPT65xKvwUC8Z31mc91gnD/WS8ba4JA8m1hjDc4zG5mxi wQG0ID8aVvKq7/suJV4jbTjWjVlfH4rz5TVEF5e4WDY70qKA2g5x5c0ekYUBWVrSvHtNRSeswDd9 eAWnPWCg6bluGQfZzewa4csZtKyxtaWG72XZySXk22nxJW9qWNnunrEhh3SPxZG8T1Zk/hAeAMoA cZWNnKfA4U0MjG3m3/HwaccH4oBfUn0zIUsKNLFzQyx95ddf7BA2yGVuZHN0cmVhbQplbmRvYmoK MTA4IDAgb2JqCjg2MwplbmRvYmoKMTEyIDAgb2JqCjw8L0xlbmd0aCAxMTMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1Vl1v20YQfNev2LfagKxIclsnQRsgRuPAQAq7soo+NH04 kUvpYvKOuTtK1r/v7PFIkUpiwZZ8H7OzO7tDfaX5bEFzeaX3rJq8Wt3Q1k/m9BG/28nXySIeoPSW VXS7xqHXtFjSupi09xa0vKabm9e0riYX9yawMxyu/nCqCHT+c79cPdHq/pbu//xmDz/va6dLWs4X P1+uv0yu39D60+QC6w+GKey02eIvE7+oShsVtDVki7h0VNjLVVBU2ZxLT9rkOlOB8cnjhAqXP00W 1x3e0TaUWzI20E7tOUI4VvmVNeWRausi9p6db/xp8+B04G4XeIKU4mtTWFdFSqpsOSCA4RmOLX+N YW9mRH/7LoeV3tBHp6pKuYS0llVUZtuuCm8QONKWDTudkTI5ZVY4kaK9cprDUcIXrELj2M9GGa53 uO85i4nUzu51jlpI5eoSH7DYRC528wWHpF4trROBREvC9teCFSw5QBm7oLTAMGXKt/H7VBd9sivb SNEcF+zYZJxg2013tonMslKzCYAU2nyljQ+qLEmV0ldKTquwE76jdIU7uu5g3TMi31nXcZ6SLujh 6fEOQkvhvomICi7mUwEwfcYW/7khk55Fun/QYfddqOVcaoTrCcurigmVD6lfZ63OkVAHBdwtBwHK OG+rgJp36wkoMeC8U+ru/hZg/4B2/HeACOGFX+7UwUwHXMYlPAX+LvRJTNw81zDWRJXe0oalAfK2 MXgv9UIKGjOAYnh2ex0VPwmlQlDZs6fNsYvb90FLOzLYoGKDeFM67HS2I9YiTEond7Zuh9MWBWPc ZbJgOgVmBfonSB2Em7eQobJGB+tw7pXClB699p1KoRPnSUt6ceLb+8rxoEA/JJiAsHVsC+ubGpMK PSHmsROmx0H2stz2GSYq2MyWowFa9gOU6yJGCWjwl7CzNYVjzf4HrgF8e5D5Zsk7g28FHvtFQvGz 1iRG6nSGgY7NnEaSoq4neFs/7zH4CGdMWyZ/3RgDA+xOJKrvKYzW4aTahGgqqtuSrhGtnuHfApT0 FAOnreUxWzHDqEa6jGaGxZlM1b4pkfdAr3QibvYEE6+OZtQa+RZNGTNWG49+QkHEJhtpbBSg9J3l J7uZQswEhEdJZ+9dI3pWFYzTl10PbHCLMbPpNnG+5fMSivYrrkt5gIkan7TvbEAehDJ8vbBucK7E uch8uNgxQZWrpgwanjgq4sCcfHKn4dI0mkLj4CSZbcpcJj6z4qwv5/q27lF5LvfokCuMOviVMIU4 DfLYbDt/UDyEEodA3EfpBZBMWC3VuCZmuHFW5XjKhKjR6XEkbaHN3iLiMOmxe/2WeF5Jfd7R27e/ 0+eLbvHd50uazeTCm0W8cKt2Km/clOCMqpz1X00+vNQaT1l6yILdoO+Wv0zjF5WzbzD/Pqot03L5 HxA/rCd/4fU/0ZoGtGVuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2JqCjEwNzUKZW5kb2JqCjExNyAw IG9iago8PC9MZW5ndGggMTE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZd c+I2FH33r7hvTWaADbC72U3TzJBdNssMCZS43YduJyNsgdXYkleSgfz7HsnG2JCZtlOY4CBdHd17 zv3gB130+nTh3tUzyoI3i0tam+CC7vC3Dn4EfW9A1SPK6DaE0QfqDyhcBeW5Pg2GdHn5gcIsOJtI y7XktvtZs5Wl49dksHikxeSWJvcne3iNci1SGlz0356HfwXDjxROg7PL3qA37BF942KdWB5TKow1 5z8Fg/d+352jbXOThKHC4ItVlCoWd5csZTLiZOHUSkTEMiXXxMhwS2oFqP5wDyX5ziYqN7jwi1YZ jDIV81TAPufa5DyyYsM7WD+5csP1C7AcihGZSJl2DjDSPE9FxKxQ0tt2aCtsQjbhFIvVimvufUuY Jc6ihDKeLbmukCp/6P63x5AStuEAnM5Gn59uR9PRw6fx07fx5O5rSMwYFQnm/PHowvZaFF1XQF3n wQ1dXf1C38/2izd0/QrmzffzXs+heAnegpG5VtYRUAViKh+Pl4lp3qSgxZRjdkR5+0hLAkeyWAlu aoVgLjKmX2p1iMn4sLtk0XORH6Sr3ApB8PV8MQvHn8LJ7OFpvhh/GS/GCPCGmLVaLAvLScjYiYPb tokA+3vCxT66/d3uytIEWpdX/jeKX3elJple4YUiJomlRtGSH6cceJxIUkgjTVulY9NpsbjPdYeA w806iKsCcBl4wiz4ZHXkLWfKC00BBhhgDarAIXg/tyJNcYd6xtdnfvW/U68Vyj8wV93kkvQdfHyo BIwSJqSpmZXNZSchq5d86eUFEldJTkqj5JHACWcxKh5rkL7ljyrsWvmOgCzgjpcZzvEdy/KUl9Bz w4tYbQVwuoesuZ9PH0lt6uI2KvNNSZpcaQtWSgNNd4sxrfBEANYphlARgyzFblz0+w6sVWAOlybz 3mmwLE3V1tUMjrr2zFLi0gr74opzqTl7psKxwA+6rzXLMhci0sGJXFeFxBGUDM85PiRoEzxC7XQ9 dXkdGVoay02R+q73b8rERY5cQGCmWzIPfd0GqPgZG2vND+uNtvQe8ZZNB542m9K0tViqEilH3A5P 8KqL6Fg6WBeGrf0/Ls9bqrPDMYcGHvaN/TBYsJgVqRUOLObGCukJMGXLrzxLUMTENgztcSlSyHBa yV58PwwaKPSiimoEvNKa2k0QzB2PHdAJ97g0hXbTBmPHhSFVhbUPIdZeZl/gvhnQCp7iDLx8VD4Z kP/wdD/2WKNPVFh+yznlrIWUlXU5GI79Mo0G/6aMoj37fEP/2Pc63LKExYXuEDo/S3v1L4fxLket GZpFVmF40uBdx/+OOPqB8cfcqTsY/gnEcRj8ivffy7DNRmVuZHN0cmVhbQplbmRvYmoKMTE4IDAg b2JqCjEwMDgKZW5kb2JqCjEyMiAwIG9iago8PC9MZW5ndGggMTIzIDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnicjVZNb+M2EL37V8ytCeA4tpM22WPSLooAXWybuOih2wNNjSVuJFIh qTjZX9/HD9mW7C1qI5EhDd/Me3wz1AvNZwuah2++ymZy+XhDpZvM6Vf8lZOXySIGUL7Ihu5XCLql xZJWm0lat6DlFd3c3NKqmZw9aM9Ws7/4xYqNp/HnYfn4RI8P9/Tw6egZPnetVTUt54vr89XXydUH Wv02ObudUVxiWrbCK6MdCU9OiprPf5gsf4pBWLyqlCPHMoRQoZzsnGNHvuIUTJZfOmW5Ye0dbYwl EXEL4cVFYwquZ8BbXO3xePScXGW6uqA1k1gD0BuqhC7wqxa27NOYDWACwL7gaQhlHRcV3NbmPRSB yJhAtG2tZKamdALLGJBya+yzm+2p3s4WWRHLonA58L6rn5Uu6ctZaU3Xhp+Ab7raqzYUtf4KZSK8 IIenuNewc6LkL+f06c+nFVgN6LuubY31XNC24rAqlwICr0qCLOvC7QQKBIUmfgvbL2qQ9cq/z3Jx T6pRYFW/x92I8UnQmDgLk3ZD1ipIA7iwXex8Clc6Q63BkzbWNEcVDSRaZon+ssrz/9RoG2IPbXZS rIFIWbgjsY6UoK0IrgOtlAU/fPJXr1Gwm2XXIjEngiFgJHrMp7SsuyIIZtl3Vl9IaBkMnZFYyGpM JnAJeFG+zGUg2FUWjF9je8DWpI1Xm96Y+yotkwTBdbiEBtvGWzuh+oojUGAEeaOUvc4DAffpLtGQ g4zfFWFotZ50MhzR50TU4J+N7TmlokuCw4WjLfcV7vTcKjQi6xCC+RLHhmg4rOLpsf0bVVYeS14j dGiGjLLD/i9qp7slyjts/D6dsapUWgSHRdzLQ7x+Q5M9shcP+mXM+nt7fMrwByb5gAKfWHY2+Pln xKuib5Wc7K6ugQFSQibANVhwnB7BW43QQLQx8YkWOTWFRIeNwGMZqceFuAM1vnEx28/oHjlCtNZ4 DDtS3nHdD2NRCqUxTQQU1QpJIYhjG8UV3gv5TOv30FKmhFtGpU3xLOP4Cui+DpL2Awr5JMTCLVR0 d1wPa/Qm0tTwH2Q3/SirzBZ7gl6NEy73FMBKK5oGbEM9xyoFDVLf9863Fv6Kc8cFNJESEU5DG0YB hBqdkyc047fWuNDFB6edr0QQkVQD08RTM/DTw/7tqwMU2j0ZkGOJURx3MOl2GSOwNIDFXFS+2kl7 OEgPjuVU80FlKU3LUm3SkbJmdKLaTUDs7TgnuiSe1bkXOj3MtKs3vgPMryO/e1GJorNTYvgmlJE/ H99avEc4+iy9WQN7+eM0vrSM3mb+/j305PL6H0B+XE3+wPdf6KMHfmVuZHN0cmVhbQplbmRvYmoK MTIzIDAgb2JqCjk5MwplbmRvYmoKMTI3IDAgb2JqCjw8L0xlbmd0aCAxMjggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVV1X4kgQfedX1OFl9JwkS1DX8RFBZ3XEYSA7Pozz0CZF 6KHTjf2Bw7/f6k5QMbIPhkM+q6tu3VtV/Qi9JIWe/zXXvOr8NT2F0nR68IX+ZeexkwYDaC55BecZ GX2GtA/ZvFOvS6F/BKennyGrOgdX0qKWaOORZnMLb4+r/nQG06tzuBq3vtExWGkuoN9Ljw+z352j M8huOgdpL6GFg9vB4adO/+/wikyzBTdQqNxVKC3doAGpLJQoUTOLwOQGciUNL/wzpzuYKx38JOTo IE3J6yBfSvUksCjRuzH+Q/BN651dKG3gSTlRgOBLBKvALphc0hnpvV5yWUKplVtRpDhfME72TBbk JT3a4tS45viE9EVJv5BrMq5CNG8LxpUlmhpgsPBpee6SgKNBNFdCqCcfb4VqJdCnZjV/cBaLGhdC gYaXEtQ8PHmSK1WgAGZgxbRtPDWfgxBBLF5BhWi9by5fFDiCGO6I1C+odIkRDBeab/m54eI3SmOV WNGXa5zPIWOUkNMsgpnmJZNoFvCVS07PzjAJ/zCNJoJL9sCZbNzM8oVEr08g4pYTBjhnC1Y4nbxo nfa9/JLEq0jHNWWGc9Qoc9zC+XkVj5KFDxDzvjaxMxjnjE5rGa/zXztyvDoaSLMkhB8nlCLKCLr/ GoQhLa8L5gfX1jEBQyUl5kGnJuyrg4QbYeXd3B/8GKrR/WHwuV17i9aXy67ZrTdru3LGKxGUmbM8 FN1UuSDPbGMsVt2oro/4TcZtVy8cxL0+hQwYiOOVViUtNfeHJAg+aMf0JjRdstNhgVaOdl7HYDpf cEsUOI17OR1YwYjTQRIRvVQdmgi9Dg8N1xHcMV1EMKI7T0SWtHHfsgKZIyUGVI+vogY9QvG+ZicU e81Q29Ubyt7PZoedto+P0UWrHgRWsbE0jXy77+dMcFZTtk08a8gZJQ1b3bcZt1HuFglM6vAw24Z/ h4N3U90FHfd6ewpn4EpnbJgU/8sDDamYU/fGYRjtJaHpe+KAcr9UYunLZUr3zRBpGLlOYIzFGj0n e0V/HhbKzxOD4QWMffx3WHgG2HYUIH+8d558he2OpL3533nbOuNXveJTHiQ08SyTVCNdUtWqXAnK qMAV0knaNuzdAUbDd1+/vG2Ptqt3UvgYH9PLYT9Nz36R0poVtEfXCXa/4sZvpUWNlWJ4p2RsPFTK kudUiftIm+Kj4zoUKtzgGoWhVM6HE0iPI+8EfMgIxr7ZIT07O22DOj5LTwjUxKBkywgmhGlMU1tp 2qhqiFO1abqzdBu/Qdw0wkySfbgmXAi2iS+MZE5YynJMFx5naqWEKjdE3zijLWKrAmX8bTa57AbM bQ08RJqiTiIR2ws5nPRD1OemQQtMJM8rLv6siBYD33KrHmh77dN6r8muX/g5YSX5PPFFeZF1vtPv P7iS1b5lbmRzdHJlYW0KZW5kb2JqCjEyOCAwIG9iagoxMDY3CmVuZG9iagoxMzIgMCBvYmoKPDwv TGVuZ3RoIDEzMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVT23KbMBB95yvO 5CXxlFDAdnx58qVOh7ROU6DThyTTUUABxSA5kohLv77Cxk2dizTMCuns2bOr1SNcx4PbzNYmpfUx HCBTlovP5susR8vbAtCapMQsNqAhPB/xvbXz8+B3MRgMEZfWScA1lZzq00+S3Gu8HIEfRgiDGYLl qzMzpmvJCviu1+vED1Z3hPirdWL2r8Pzed/z3VvgSv6pM0Z5SmzEjo0op9zGpVkRnhrbbOjcxtHy NIiCaIxlVWjWOba87p7tvxGLtShEVuPmZBnfdBCKSjOegXFsMylpyoimiGqlaQktDNELijdwytAF kYmvbjpHNox4NOptnNM7WRFZmxTdoWO4/LOtqGmlcyHVMaZpKqlSVLVxLpmRgxnJSVrJgyRmkiQr qjEX5XqrufXo+i4i8VjRAj9J3W5GFef1EymojfkUGPXcYb89+hFNn3WY/0VJWDEGbwL/utsFntQk F8JJRGmgz7cSCo5zUazUgbCLirM1lbikeiPkStmmQonTRvO8Ua+5pCXROStSgukT5RV9X+boHZlX ueB0jA8eDAiDXr8pqXsgpM1ECn4/ediJckxn7gnDYGzMZrNxDg+f84skywinKscXxg9baCFZopTg b5VO7d2clXGb0Bb6qnwXhGNJ0yeaHlDPmUrEW7wP5RY8SRpAy+ab5BtU2yE2TEeQwvnXnIvfa2Ya Ct8SLe7Mpfh9e/u8Xry76yuSUfhnt4ZyEVvfzfwLkDoSX2VuZHN0cmVhbQplbmRvYmoKMTMzIDAg b2JqCjU2MAplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgOSAwIFIKL0ZvbnQgMTAgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRv YmoKMTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE0IDAgUgovRm9udCAxNSAwIFIKPj4KL0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKMTYgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgov Rm9udCAyMCAwIFIKPj4KL0NvbnRlbnRzIDE3IDAgUgo+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDI0IDAgUgovRm9udCAyNSAw IFIKPj4KL0NvbnRlbnRzIDIyIDAgUgo+PgplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDI5IDAgUgovRm9udCAzMCAwIFIKPj4KL0Nv bnRlbnRzIDI3IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9UZXh0XQovRXh0R1N0YXRlIDM0IDAgUgovRm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMy IDAgUgo+PgplbmRvYmoKMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDM5IDAgUgovRm9udCA0MCAwIFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+Pgpl bmRvYmoKNDEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0 YXRlIDQ0IDAgUgovRm9udCA0NSAwIFIKPj4KL0NvbnRlbnRzIDQyIDAgUgo+PgplbmRvYmoKNDYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAg UgovRm9udCA1MCAwIFIKPj4KL0NvbnRlbnRzIDQ3IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDU0IDAgUgovRm9udCA1 NSAwIFIKPj4KL0NvbnRlbnRzIDUyIDAgUgo+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4K L0NvbnRlbnRzIDU3IDAgUgo+PgplbmRvYmoKNjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY0IDAgUgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRz IDYyIDAgUgo+PgplbmRvYmoKNjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDY5IDAgUgovRm9udCA3MCAwIFIKPj4KL0NvbnRlbnRzIDY3IDAgUgo+ PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDc0IDAgUgovRm9udCA3NSAwIFIKPj4KL0NvbnRlbnRzIDcyIDAgUgo+PgplbmRvYmoK NzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5 IDAgUgovRm9udCA4MCAwIFIKPj4KL0NvbnRlbnRzIDc3IDAgUgo+PgplbmRvYmoKODEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg0IDAgUgovRm9u dCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgyIDAgUgo+PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIK Pj4KL0NvbnRlbnRzIDg3IDAgUgo+PgplbmRvYmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk0IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRl bnRzIDkyIDAgUgo+PgplbmRvYmoKOTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDk5IDAgUgovRm9udCAxMDAgMCBSCj4+Ci9Db250ZW50cyA5NyAw IFIKPj4KZW5kb2JqCjEwMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMTA0IDAgUgovRm9udCAxMDUgMCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSCj4+ CmVuZG9iagoxMDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDEwOSAwIFIKL0ZvbnQgMTEwIDAgUgo+PgovQ29udGVudHMgMTA3IDAgUgo+PgplbmRv YmoKMTExIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMTQgMCBSCi9Gb250IDExNSAwIFIKPj4KL0NvbnRlbnRzIDExMiAwIFIKPj4KZW5kb2JqCjEx NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE5 IDAgUgovRm9udCAxMjAgMCBSCj4+Ci9Db250ZW50cyAxMTcgMCBSCj4+CmVuZG9iagoxMjEgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyNCAwIFIK L0ZvbnQgMTI1IDAgUgo+PgovQ29udGVudHMgMTIyIDAgUgo+PgplbmRvYmoKMTI2IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjkgMCBSCi9Gb250 IDEzMCAwIFIKPj4KL0NvbnRlbnRzIDEyNyAwIFIKPj4KZW5kb2JqCjEzMSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTM0IDAgUgovRm9udCAxMzUg MCBSCj4+Ci9Db250ZW50cyAxMzIgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvS2lkcyBbCjQgMCBSCjExIDAgUgoxNiAwIFIKMjEgMCBSCjI2IDAgUgozMSAwIFIKMzYgMCBS CjQxIDAgUgo0NiAwIFIKNTEgMCBSCjU2IDAgUgo2MSAwIFIKNjYgMCBSCjcxIDAgUgo3NiAwIFIK ODEgMCBSCjg2IDAgUgo5MSAwIFIKOTYgMCBSCjEwMSAwIFIKMTA2IDAgUgoxMTEgMCBSCjExNiAw IFIKMTIxIDAgUgoxMjYgMCBSCjEzMSAwIFIKXSAvQ291bnQgMjYKPj4KZW5kb2JqCjEgMCBvYmoK PDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDEzNiAwIFIKPj4KZW5kb2Jq CjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKOSAwIG9iago8PC9SNwo3 IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNCAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxOSAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iagoyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyNCAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyOSAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoz NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agozOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0MCAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iago0NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NSAwIG9iago8PC9SOAo4IDAgUj4+ CmVuZG9iago0OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MCAwIG9iago8PC9SOAo4IDAg Uj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1NSAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2MCAwIG9iago8PC9S OAo4IDAgUj4+CmVuZG9iago2NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2NSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3MCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iago3NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3NSAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago4 MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i ago4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4OSAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iago5MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5NCAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iago5NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5OSAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iagoxMDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTA0IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjEwNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDkgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTEwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjExNCAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK MTE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iagoxMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTI1IDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjEyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMzAgMCBvYmoKPDwvUjgK OCAwIFI+PgplbmRvYmoKMTM0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEzNSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0NvdXJpZXIvVHlwZS9Gb250 Ci9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjEzNiAwIG9iago8PC9UeXBlL01ldGFkYXRhCi9TdWJ0 eXBlL1hNTC9MZW5ndGggMTMyOT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVN ME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+ Cjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0 IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFk b2JlLmNvbS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzMxYTNjMDI1LTAz MGYtMTFlZi0wMDAwLTRhMWQ3ZWQxNTc4OScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29t L3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjAyJy8+CjxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSczMWEzYzAyNS0wMzBmLTExZWYtMDAwMC00YTFkN2VkMTU3ODkn IHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+PHhtcDpNb2RpZnlEYXRl PjIwMTQtMDQtMjNUMTY6MjI6MDUrMDI6MDA8L3htcDpNb2RpZnlEYXRlPgo8eG1wOkNyZWF0ZURh dGU+MjAxNC0wNC0yM1QxNjoyMjowNSswMjowMDwveG1wOkNyZWF0ZURhdGU+Cjx4bXA6Q3JlYXRv clRvb2w+R05VIEVuc2NyaXB0IDEuNi41LjkwPC94bXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3Jp cHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSczMWEzYzAyNS0wMzBmLTExZWYtMDAw MC00YTFkN2VkMTU3ODknIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv bW0vJyB4YXBNTTpEb2N1bWVudElEPSczMWEzYzAyNS0wMzBmLTExZWYtMDAwMC00YTFkN2VkMTU3 ODknLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzMxYTNjMDI1LTAzMGYtMTFlZi0wMDAw LTRhMWQ3ZWQxNTc4OScgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv JyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkg eG1sOmxhbmc9J3gtZGVmYXVsdCc+RW5zY3JpcHQgT3V0cHV0PC9yZGY6bGk+PC9yZGY6QWx0Pjwv ZGM6dGl0bGU+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0K ZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDIpCi9DcmVhdGlv bkRhdGUoRDoyMDE0MDQyMzE2MjIwNSswMicwMCcpCi9Nb2REYXRlKEQ6MjAxNDA0MjMxNjIyMDUr MDInMDAnKQovVGl0bGUoRW5zY3JpcHQgT3V0cHV0KQovQ3JlYXRvcihHTlUgRW5zY3JpcHQgMS42 LjUuOTApPj5lbmRvYmoKeHJlZgowIDEzNwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMzE4NTUg MDAwMDAgbiAKMDAwMDAzNTAwNSAwMDAwMCBuIAowMDAwMDMxNjEzIDAwMDAwIG4gCjAwMDAwMjcz NzUgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxMDk1IDAwMDAwIG4gCjAwMDAw MzE5MjEgMDAwMDAgbiAKMDAwMDAzMzUzNiAwMDAwMCBuIAowMDAwMDMxOTYyIDAwMDAwIG4gCjAw MDAwMzE5OTEgMDAwMDAgbiAKMDAwMDAyNzUzNCAwMDAwMCBuIAowMDAwMDAxMTE1IDAwMDAwIG4g CjAwMDAwMDIxOTUgMDAwMDAgbiAKMDAwMDAzMjAyMSAwMDAwMCBuIAowMDAwMDMyMDUxIDAwMDAw IG4gCjAwMDAwMjc2OTYgMDAwMDAgbiAKMDAwMDAwMjIxNiAwMDAwMCBuIAowMDAwMDAzMDk2IDAw MDAwIG4gCjAwMDAwMzIwODEgMDAwMDAgbiAKMDAwMDAzMjExMSAwMDAwMCBuIAowMDAwMDI3ODU4 IDAwMDAwIG4gCjAwMDAwMDMxMTYgMDAwMDAgbiAKMDAwMDAwNDY5NyAwMDAwMCBuIAowMDAwMDMy MTQxIDAwMDAwIG4gCjAwMDAwMzIxNzEgMDAwMDAgbiAKMDAwMDAyODAyMCAwMDAwMCBuIAowMDAw MDA0NzE4IDAwMDAwIG4gCjAwMDAwMDU2NzQgMDAwMDAgbiAKMDAwMDAzMjIwMSAwMDAwMCBuIAow MDAwMDMyMjMxIDAwMDAwIG4gCjAwMDAwMjgxODIgMDAwMDAgbiAKMDAwMDAwNTY5NCAwMDAwMCBu IAowMDAwMDA2OTYzIDAwMDAwIG4gCjAwMDAwMzIyNjEgMDAwMDAgbiAKMDAwMDAzMjI5MSAwMDAw MCBuIAowMDAwMDI4MzQ0IDAwMDAwIG4gCjAwMDAwMDY5ODQgMDAwMDAgbiAKMDAwMDAwNzkxMyAw MDAwMCBuIAowMDAwMDMyMzIxIDAwMDAwIG4gCjAwMDAwMzIzNTEgMDAwMDAgbiAKMDAwMDAyODUw NiAwMDAwMCBuIAowMDAwMDA3OTMzIDAwMDAwIG4gCjAwMDAwMDg3MTAgMDAwMDAgbiAKMDAwMDAz MjM4MSAwMDAwMCBuIAowMDAwMDMyNDExIDAwMDAwIG4gCjAwMDAwMjg2NjggMDAwMDAgbiAKMDAw MDAwODczMCAwMDAwMCBuIAowMDAwMDEwMDgxIDAwMDAwIG4gCjAwMDAwMzI0NDEgMDAwMDAgbiAK MDAwMDAzMjQ3MSAwMDAwMCBuIAowMDAwMDI4ODMwIDAwMDAwIG4gCjAwMDAwMTAxMDIgMDAwMDAg biAKMDAwMDAxMDcxOCAwMDAwMCBuIAowMDAwMDMyNTAxIDAwMDAwIG4gCjAwMDAwMzI1MzEgMDAw MDAgbiAKMDAwMDAyODk5MiAwMDAwMCBuIAowMDAwMDEwNzM4IDAwMDAwIG4gCjAwMDAwMTE5MzUg MDAwMDAgbiAKMDAwMDAzMjU2MSAwMDAwMCBuIAowMDAwMDMyNTkxIDAwMDAwIG4gCjAwMDAwMjkx NTQgMDAwMDAgbiAKMDAwMDAxMTk1NiAwMDAwMCBuIAowMDAwMDEzMzQ4IDAwMDAwIG4gCjAwMDAw MzI2MjEgMDAwMDAgbiAKMDAwMDAzMjY1MSAwMDAwMCBuIAowMDAwMDI5MzE2IDAwMDAwIG4gCjAw MDAwMTMzNjkgMDAwMDAgbiAKMDAwMDAxNDQwNiAwMDAwMCBuIAowMDAwMDMyNjgxIDAwMDAwIG4g CjAwMDAwMzI3MTEgMDAwMDAgbiAKMDAwMDAyOTQ3OCAwMDAwMCBuIAowMDAwMDE0NDI2IDAwMDAw IG4gCjAwMDAwMTU1MjcgMDAwMDAgbiAKMDAwMDAzMjc0MSAwMDAwMCBuIAowMDAwMDMyNzcxIDAw MDAwIG4gCjAwMDAwMjk2NDAgMDAwMDAgbiAKMDAwMDAxNTU0OCAwMDAwMCBuIAowMDAwMDE2NjUy IDAwMDAwIG4gCjAwMDAwMzI4MDEgMDAwMDAgbiAKMDAwMDAzMjgzMSAwMDAwMCBuIAowMDAwMDI5 ODAyIDAwMDAwIG4gCjAwMDAwMTY2NzMgMDAwMDAgbiAKMDAwMDAxNzUzMiAwMDAwMCBuIAowMDAw MDMyODYxIDAwMDAwIG4gCjAwMDAwMzI4OTEgMDAwMDAgbiAKMDAwMDAyOTk2NCAwMDAwMCBuIAow MDAwMDE3NTUyIDAwMDAwIG4gCjAwMDAwMTg1NDggMDAwMDAgbiAKMDAwMDAzMjkyMSAwMDAwMCBu IAowMDAwMDMyOTUxIDAwMDAwIG4gCjAwMDAwMzAxMjYgMDAwMDAgbiAKMDAwMDAxODU2OCAwMDAw MCBuIAowMDAwMDE5NDQyIDAwMDAwIG4gCjAwMDAwMzI5ODEgMDAwMDAgbiAKMDAwMDAzMzAxMSAw MDAwMCBuIAowMDAwMDMwMjg4IDAwMDAwIG4gCjAwMDAwMTk0NjIgMDAwMDAgbiAKMDAwMDAyMDQ1 MyAwMDAwMCBuIAowMDAwMDMzMDQxIDAwMDAwIG4gCjAwMDAwMzMwNzEgMDAwMDAgbiAKMDAwMDAz MDQ1MSAwMDAwMCBuIAowMDAwMDIwNDczIDAwMDAwIG4gCjAwMDAwMjEyMTUgMDAwMDAgbiAKMDAw MDAzMzEwMiAwMDAwMCBuIAowMDAwMDMzMTMzIDAwMDAwIG4gCjAwMDAwMzA2MTcgMDAwMDAgbiAK MDAwMDAyMTIzNiAwMDAwMCBuIAowMDAwMDIyMTczIDAwMDAwIG4gCjAwMDAwMzMxNjQgMDAwMDAg biAKMDAwMDAzMzE5NSAwMDAwMCBuIAowMDAwMDMwNzgzIDAwMDAwIG4gCjAwMDAwMjIxOTQgMDAw MDAgbiAKMDAwMDAyMzM0MyAwMDAwMCBuIAowMDAwMDMzMjI2IDAwMDAwIG4gCjAwMDAwMzMyNTcg MDAwMDAgbiAKMDAwMDAzMDk0OSAwMDAwMCBuIAowMDAwMDIzMzY1IDAwMDAwIG4gCjAwMDAwMjQ0 NDcgMDAwMDAgbiAKMDAwMDAzMzI4OCAwMDAwMCBuIAowMDAwMDMzMzE5IDAwMDAwIG4gCjAwMDAw MzExMTUgMDAwMDAgbiAKMDAwMDAyNDQ2OSAwMDAwMCBuIAowMDAwMDI1NTM2IDAwMDAwIG4gCjAw MDAwMzMzNTAgMDAwMDAgbiAKMDAwMDAzMzM4MSAwMDAwMCBuIAowMDAwMDMxMjgxIDAwMDAwIG4g CjAwMDAwMjU1NTcgMDAwMDAgbiAKMDAwMDAyNjY5OCAwMDAwMCBuIAowMDAwMDMzNDEyIDAwMDAw IG4gCjAwMDAwMzM0NDMgMDAwMDAgbiAKMDAwMDAzMTQ0NyAwMDAwMCBuIAowMDAwMDI2NzIwIDAw MDAwIG4gCjAwMDAwMjczNTQgMDAwMDAgbiAKMDAwMDAzMzQ3NCAwMDAwMCBuIAowMDAwMDMzNTA1 IDAwMDAwIG4gCjAwMDAwMzM1OTggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMzcgL1Jvb3Qg MSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8MTJENzNDNjUzREZDNEYwREY1MThDRUVGQTFDRDExRkE+ PDEyRDczQzY1M0RGQzRGMERGNTE4Q0VFRkExQ0QxMUZBPl0KPj4Kc3RhcnR4cmVmCjM1MTg0CiUl RU9GCg== ------=_NextPart_000_0007_01CF630F.ED329C50-- From nobody Mon Apr 28 17:01:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7791A8841 for ; Mon, 28 Apr 2014 17:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRut-zDCS5rl for ; Mon, 28 Apr 2014 17:01:52 -0700 (PDT) Received: from nm29-vm6.bullet.mail.gq1.yahoo.com (nm29-vm6.bullet.mail.gq1.yahoo.com [98.136.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 536151A6F17 for ; Mon, 28 Apr 2014 17:01:52 -0700 (PDT) Received: from [98.137.12.174] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:01:51 -0000 Received: from [208.71.42.204] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:01:51 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:01:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398729711; bh=IaDQSaV/I8VxWYMFfa+Dvvsy8qYY24gt8RM8k5dCB5s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=klHYNCpi9QRZ0c7AWRWtO3NFkxrUoGfe745l4a+n1H+cuLRk4qDAe+Y2MwDuZmQ4K94rImQ50BXKzHR3IEVsQYpsqcQxgPKLoiRYONRROB7PJmdNn50Kc3ApX7SDz0VuZRaCszcrvv1IGYHYK941x1gIwaKBj5sitK+0hn20MCA= X-Yahoo-Newman-Id: 577313.14429.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: J5WCr70VM1lyUKLLiEvjKLJmwJ7U2PQv5OS2GHlV__t3eEL JGdl3sYMi.HsRCnG5Z_ka4cHfVk9Vmr0b1ij3PJCripj1dsFiJY33VoKPp5g kDekm87.T3kt8NY88fGwN4nVDPJMd1NxliXp_BGDBij.F6eAq_abuaKqgTI. osby11uC28BR_L5rG3t66JOrR500WrT1guxKTpCBx5jBLgnmVcOkldv2j44V FfGVY4VGP9Z7uWqP3wsDiPwaaoRN2GXOHl7qzhdn1m.AtOccCEW83lXibY2R ouVb7QZUSonwhja9B3xXc8rRGu8eR0r17AfKdRlQsl4kLFgDaYx9Emgq3m87 Ug3IhXHurCWAJMtnIYMOeGVlEKAUXsgmZ5UoirQXfbbdeghTmX3N3krwRrSL wEpuEVIF6ieJ2r2nLFwC3QW5L6HsquiaXmAGVjemKQ93ViXWdTfUiJPdLshP hquzJwDxuoecnSZ.7MhKGT_Y3tsviyZ_7Qac7A59KEQTPGzweSE1kkWBC.96 t4Lg7.ya.VPXdH.O1DOi4RSoGrpKyYA-- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [98.138.105.21]) by smtp215.mail.gq1.yahoo.com with SMTP; 28 Apr 2014 17:01:51 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 17:01:57 -0700 From: Nitin Bahadur To: Dean Bogdanovic Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wLO2sgpL1aVD0XwBE5WtMZyylds Cc: "i2rs@ietf.org" , Mach Chen , "draft-ietf-i2rs-rib-info-model@tools.ietf.org" Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 00:01:54 -0000 Hi Dean, >Have a question about RIB grammar > >Based on the description >interface-list: This represents the list of interfaces associated > with this routing instance. The interface list helps constrain > the boundaries of packet forwarding. Packets coming on these > interfaces are directly associated with the given routing > instance. The interface list contains a list of identifiers, with > each identifier uniquely identifying an interface. >So based on this description, example grammar for Interface list is clear > ::=3D ( ...) > >but then interface route has interface and interface identifier > ::=3D >Could you please explain the difference between and >? In section 2.3, there is an ingress interface >match condition, but from the document would presume that > would be enough to identify the ingress interface >for match condition? The was supposed to be a reference to the route-type. I=B9ve removed that from the latest (yet to be published) revision, wherein there is a in the and ::=3D Hope that brings more clarity. Thanks Nitin From nobody Mon Apr 28 17:32:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBC1A8841 for ; Mon, 28 Apr 2014 17:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4jVTAMuwaRW for ; Mon, 28 Apr 2014 17:32:36 -0700 (PDT) Received: from nm29-vm2.bullet.mail.gq1.yahoo.com (nm29-vm2.bullet.mail.gq1.yahoo.com [98.136.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4BE1A8844 for ; Mon, 28 Apr 2014 17:32:36 -0700 (PDT) Received: from [98.137.12.191] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:32:35 -0000 Received: from [208.71.42.191] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:32:35 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:32:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398731555; bh=hUlAQuRCt3B+thM+8DMvEA9H488KlruO8DAurQ7btPM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=JAKnVQPzwu5VqIJSj+Va+zcvIwNfNJtIEB6KkBt1n2UVVKzro9c5tHqSPNDTYhraQuNsArnv78gmseQ3+wlRMLL5IQN0lwVuFBvV5qz0RUPkHq1uQbd6zk7y56Cv8V2T1nI2swLRev32VZ/bnbJUXLCPaEQKeBFuBOwpso6q80s= X-Yahoo-Newman-Id: 476667.44133.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l3cXrXEVM1nBnTlQEQeXwsMIFjSkkn2WE32qxaDBGBIyqSh 8eRk0F8iwwvYjVe5rcPNejtLzbZOWrNVib_YHu.OCXnf2_MsY7EAvOP1jvCy 6C_RhZETJ0Rxffr3HSUAhXKI.cTIl2a5bbxmFbbA_zooa2n44b_YxJ3Rkb50 MwiPOfmAl13OzZc8pymuw6nWQxuSSbc0Bf1EN811ENO7.1BwYaetw6bj_o5u GuUZlJTkXU6Z0_g21iJ7wxbQEd.cVRBQAyqINCvz4p9vg7SzZRnpwQrJ9ntB 0MTwn0Cmsvu9eus0QbW9a2q.LhsiQl9419WsxYZeVQzKtHqJ7IHQwuw03X.W aF2yp9FIBqUb6C.tSbjighMX4e0GfDK9X_ZkzLSzi4hItOhIgD6HbcTEr.T0 yhjroVjnu.v3dKg6r3Ze25yNoT2y4jjDT0nZxIB4yFPDMKwG0T7D6Xq.uRtB rJIK4v.mJ4CKneAqTAwhn0De5E.hJisHxNEEZRf1hnauXuZ73HBy191PSpFJ nmmw0hSSsDz2Qv89W9kRxzwIy1JX5PC9xojBtCQ08fm6l5JNu6esvaJ4fZge YwPJE147ydGVF.94Fvr7yrSdEBVLbD_71Jo56CfO_ X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.19] (nitin_bahadur@24.4.100.156 with plain [63.250.193.228]) by smtp202.mail.gq1.yahoo.com with SMTP; 28 Apr 2014 17:32:35 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 17:32:27 -0700 From: Nitin Bahadur To: Jamal Hadi Salim , "i2rs@ietf.org" Message-ID: Thread-Topic: [i2rs] comments on draft-ietf-i2rs-rib-info-model-02 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/53sH0pErYoEQFjEYGUu32OTbjbI Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 00:32:38 -0000 Hi Jamal, > >-nexthop-address is recognized in the grammar but not used. >It may need to expand to {ipv4-prefix, ipv6-prefix, IEEE_MAC} This is lingering from the -02 edit. It will be removed in -03. Thanks for catching this. > >- What is syntax like: >" ::=3D <>" >intended to imply? The intention was to imply that there should be some expansion to these (as part of this draft or as part of some other draft). For now, we will remove all such references to <> (since we haven=B9t found a good use-case for the expansions yet). > >- ::=3D >What is the difference between INTERFACE and INTERFACE_IDENTIFIER? >Are both needed? Couldnt tell from the text. >Same question on occurances of "IEEE_MAC MAC_ADDRESS" Removed. See previous email to WG. > >- somewhere in the structuring do we need to reflect what route in >what shape has been synced with a FIB? The notifications are supposed to tell you that. The notification should tell you if a route is in the FIB or just in the RIB. > >- the whole nexthop structuring is quiet funky. I am wondering if someone >has implemented that? Yup=8Awe=B9ve had folks from Cisco, Juniper & Ericsson go over it. So I=B9m presuming they implement some form of it. > >Still section 8: I see that we are asking for fast table dumps, fast >table writes; >is there need for fast table deletes? A =B3delete=B2 is nothing but a form of a write=8A.so in short yes. > >- Section 11: I think some of the people in the acknowledgements are now >authors; so it may not make sense to list them there. Ack. Thanks nitin From nobody Mon Apr 28 17:49:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533281A8854 for ; Mon, 28 Apr 2014 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7JIi6Lf1D6H for ; Mon, 28 Apr 2014 17:49:12 -0700 (PDT) Received: from nm20-vm5.bullet.mail.gq1.yahoo.com (nm20-vm5.bullet.mail.gq1.yahoo.com [98.136.217.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB6C1A8844 for ; Mon, 28 Apr 2014 17:49:12 -0700 (PDT) Received: from [98.137.12.58] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:49:11 -0000 Received: from [208.71.42.191] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:49:11 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 00:49:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398732551; bh=VqQ2P0whAUEb4G/0UqlwP/yhVt37kMAWf6H7GPnBfnA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=JeLuzs/4CZR1uGURpwEYdgMQUwtPHWSn/AXFx9/pLc3Tq5QwT/u9tQA++5AZ9iPJUYT2gJIFr/mTCImqNLI0Iu0FQiNRAsFq2SrBQLPPkQsPxWy+k89m2n5nfeilwyTtmZD+jmgde35z3cJ7haLw4ud4EBrhfBXXU5pPnhCnNt4= X-Yahoo-Newman-Id: 528098.44130.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dblI6EkVM1m1u0w04NfS8PSel7eptPXz619LH9hOnoxj8WO _LybmhxjuweJWk1MWn4RuIgIOsYQBYM.itch257lzNi6Wqd7m1ibEAK5QM0s ASCA7UcykRfzZD.YdalIf6FSFdE0IoEt9_PIqSQizRLKUk8Qw73.npezhVFa nl0475moyjNotU9N4RWSgy0cQ6IKMD_UrBbZdcBsxGKcqXO_kpPGgHZP3e5o 0o8kAB.ezzRqeYeRnWxbai_m.Cnwdlke_3Ya.bsqf_vmki.ag.eo4JLNWft3 jMLFxqYbYwvaPKBIX6yq2BzZvIBJTdEgkfuX4o4UE6bBHbBAXTRNh.W0bH_7 b.LYojwHfBPuA8F8kCOkC_kKi9w4NFoJp_daS2AQUTSovGSoibv45KUU.98P _hKFsGya86KHOaw5mdOTXOtOhpfz.lk89crPTo98qeUO141Gu5H9fUYhSd1C 8ihTCJhBCaybq8KM9X2RMT4VFLSERZFU5tmRDG9RqiiKwhzJNPt1M0yxw86Y U78ifydDqfSwFGWyS.h4z205yPqOYDdpr X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.19] (nitin_bahadur@24.4.100.156 with plain [98.138.105.21]) by smtp202.mail.gq1.yahoo.com with SMTP; 28 Apr 2014 17:49:11 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 17:49:00 -0700 From: Nitin Bahadur To: Linda Dunbar , "ronf@juniper.net" , "sriganesh.kini@ericsson.com" , "jmedved@cisco.com" Message-ID: Thread-Topic: [i2rs] questions to draft-ietf-rib-info-model-02 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CF8CED@dfweml701-chm.china.huawei.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3481552151_63852" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/l3kV7gE6N0uWxb_3PI93Di7H2u0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] questions to draft-ietf-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 00:49:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3481552151_63852 Content-type: multipart/alternative; boundary="B_3481552151_92797" --B_3481552151_92797 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Linda, >=20 > Your draft is written very well and clear. Thank you :-) > =20 > Here are some questions to the draft: > =20 > - Figure 3 (Page 8): Is the "nexthop-list" counted as the "Acti= on" > when the "match" condition is met? Yes=8A. > =20 > - What is the relationship between "nexthop-list" and > "route-attribute"? Route-attributes are properties of the route. Nexthop-list is your action-list. So they are kind of orthogonal. For ex. Route-preference allow= s route selection across multiple similar routes. Only the route that gets selected will have it=B9s nexthop-list applied when a packet hits that route. >=20 >=20 > =20 >=20 > - Why the Route-attribute ranges 0-N, whereas the =B3nexthop-list=B2 > starts from 1?=20 >=20 > =20 Route-attributes are optional entities. Whereas there MUST be at least one next-hop for the given match condition. What=B9s the point of a route without a nexthop. If you want to =B3discard=B2 a packet by the given route, =B3discard=B2 is a next-hop. > - What kind of scenario will cause =B3Lists of lists=B2, i.e. the =B3Ch= ain=B2 > in the =B3nexthop-list-member=B2? >=20 > =20 >=20 > You have a statement in the draft: > =20 > Isn=B9t one node supposed to deal with only the outer header? > =20 In a simple case, one node will deal with only the outer header. However if a node is originating a tunneled packet, it might need to send 2 headers over. Other examples include a PW - MPLS over some transport (MPLS or GRE for instance) and VxLAN over IP. draft-bitar-i2rs-service-chaining and draft-hu-i2rs-overlay-use-case could likely use this paradigm as well. Thanks Nitin --B_3481552151_92797 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Linda,


Your draft is written very well and cl= ear.


Thank you = :-)

Here are some questions to the draft:

 

-       &= nbsp;  Figure 3 (Page 8): Is the  "nexthop-list"  counted as the "Action" when the "match" = condition is met?


=
Yes….

<= span id=3D"OLK_SRC_BODY_SECTION">

 

-          What is the relationship between "nexthop-list= " and "route-attribute"?


=
Route-attributes are properties of the r= oute. Nexthop-list is your action-list. So they are kind of orthogonal. For = ex. Route-preference allows route selection across multiple similar routes. = Only the route that gets selected will have it’s nexthop-list applied = when a packet hits that route. 

=


 

-         = Why the Route-attribute ranges 0-N, whereas the= “nexthop-list” starts from 1?

 

=

Route= -attributes are optional entities. Whereas there MUST be at least one next-h= op for the given match condition. What’s the point of a route without = a nexthop. If you want to “discard” a packet by the given route,= “discard” is a next-hop.


-<= span style=3D"font-style: normal; font-variant: normal; font-weight: normal; f= ont-size: 7pt; line-height: normal; font-family: 'Times New Roman';"> &= nbsp;        What kind of scenario will cause “Lists o= f lists”, i.e. the “Chain” in the “nexthop-list-memb= er”?

 

You have a statement in the draft:

 

Isn’t one node supposed to deal with only the oute= r header?

 

=

In a simple case, one node will deal with o= nly the outer header. However if a node is originating a tunneled packet, it= might need to send 2 headers over. Other examples include a PW - MPLS over some transport (MPLS or GRE for i= nstance) and VxLAN over IP.
=
draft-bitar-i2rs-servic= e-chaining and draft-hu-i2rs-overlay-use-case could likely use this par= adigm as well.

Nitin
<= style> --B_3481552151_92797-- --B_3481552151_63852 Content-type: image/png; name="image001.png" Content-ID: Content-disposition: inline; filename="image001.png" Content-transfer-encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAgcAAAA7CAYAAADvhinEAAAAAXNSR0ICQMB9xQAAAAlwSFlz AAAOxAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAEkj SURBVHja7d0FkC1XtTfwQxWv6j0+qCBfPSB5BIIkwMXdCe7u7u7uENzd3d0hQQIx3N0lAQJE kADBrb/8+nz/mTU7Z+b0mXvn3pm8XlVdM+ec7t17L/kv2bt3T7qu2/eEY7/hx5EnHD8dj/EY j/EYj/EYj5PoMfn/Tn8gPfGEYzIe4zEe4zEe4zEeJ+FjgeDgqyccp9hlHf3GNybdxz8+6f70 p83DPH362Mcm3W9/u/42jj120r31rZPur3896SrZD34wld3xx2/N/v/qV5PuAx+Yyvo3v/nf CxY//emke8c7Vv/9F7+Y8umjH510Rx65a/v6ox8ty4yNLXo9e3z726djHnrNH/846Q44YHp8 5zs7biyHHz7pDjxw0v361xvLsy9+cdr3L31pdIyb/fjXvybdZz876T7xiUn3z3/u8uDg7v0F 73znpLvvfSfdoYdOG3jlK6efH/3oKThsT2cM8pnPnA68/e1d75p0e+01NZLNIqD3vnfSnfOc k+5tb1t/G0cfPemue91Jd9xxJ11FPuSQSXe2s026979/a/afjB784El37nNPuje/edg1L3jB pPvZz05acvzWtybdjW406f797xP/9s1vTrp73WvSPfzhk+4xj5l0Bx20a/sKJ+5+90l3vvNN ule8YuVvEoxnPWt+Gze72aT79KcXCyLvc59Jd73rTbprXGPS/eMfO2Ysn/nMpDvveSfdC1+4 sTwTDN385pPukpecLePx2DwHX/mc50y6s5510n3/++tr46UvnXQ//vF2Bwd/OuE4x1K2vPfe k+5CF5oq/5e/POkufelJd+97L2eGFOtTn5oqW735V74y6d7znuXAQnTNYfisrY98ZOpsdVqG IiColYJ73GPSvfvdk+7b357+dswxKwcjg//wh6fXHnXU9Ls//GHSve990347X5/0bVFGfv7z 02vd+6tfnXR///v0+/vffxocyFT07ec/XxndGb++fuhDy9fkOPjgadXA9TX6+8lPplkPp3TE EdN2WwXAL3xz3te/Pum+973FxuNa4/nud6fX/+1v0+/JEBj5rWY/Aj/BkIzwl7+c9sl1Q++H T294w7SfkWEbCYuC3deYh7Spr8Yv44ms6VOb+dBR7frr+Mtfln/zv6rG/vvPrgrghXHLPh/1 qEn32tcOqyid//zTgJkuVn2sAccHPzjVjUUDw9gWe/ra16a6EJ2h4xy1dmdlvdFjcm9/+93v ptfJ/MkpOkc27EpghBezMk5O5drXnvKfjf/5z1M9cb5xBhvc12cB41pjpAOyWNmRzFnfjI+M Ixe/x6Y48fo5B5m9+MUr9Yw8znWuSfea10z/18fov4Ne+/6Nb5x0v//9ShuAJWxcNQyv/J1V KRMgVD3LgS/aoG+LVAuf/vRJ94xnTGXqvvCmPQevjIUutHZCRqthH13UJzwkH0FRDWx851rB Ya2SkDVZGgf8gt/sK+fwA2xLf/GUXSySGQcPqj3rY+7rHFjsfzoX3dAXeOu7Wq00Dn1JH+mV toZUfo1F5eaTn5zqRotfqx3w0j3oTu7fyo5ORD7GMysQgNf0m11W2xWsu8bY6ZTkveIyu8EL wXL1pdrhwx/xiGVfy17XERx8/oRjt6WL7nCHqQIxLp8f9rBJ9/rXT/8HsE94wqR76EOnx53u NO1wovmrX33Snec8089PfvLUSFUfGLXIWCR0t7tNsxDtVuP0/fWvPzUUwYg+BHS/8IVJ98AH Tu8piBDBAxDX68OZzzwFa+e4FlOGTlE89anTLER/HvKQaVtxJD7LElQ8OED3TsZISO4l69SH /fZbCULPf/70+4tcZGps+Z7i+e7CF562Kxsz7hiJMT372dOxGtONbzzprnnNYWMBWK69610n 3YMeNOWDYC+O5GUvm/Jen29zm+UMEOCRnQwGP1x361sPz6xUl4zHdfp9v/tNwTcZF974Hj/v eMcpWM1rk1O97W0n3dWutvxZn/Uz57zpTVO5uC/Zn/70y2NluL7HB+Ml3xg93dAn8vO98+gq A57XL8Z49rNPHSY9NNYf/nBlUPiAB0zveZe7TP/n5IcA5stfPpUPPnF85zjHFGwAxgUusByU PPKRk+6Wt1yutAHJpz1tep3x3PnOyzYbsNAPNvb4x0+rWYAn4MRWyfuKVzxxVglcLn/5SXeJ S0zHRI4AT78kDnQmwC3wZ+PVYc862PMee0z5ox/6TLZk5f76vueey8nHq189tcs2sGQ7L3nJ SqB90pOmlax73nPKS5UO/c05nA2ZwSkON9+7l3FKYLSLz3gcfKu8vMENThwccMLuRSfw2j3a BGe1g81e7nLTAIEMr3OdZUdCV8mWnuM/PadjSSKcn+/pZOzOcdhhUx7jK33SbzJL9ZbDZwNk CjNe97plW4Pz27ZN8UB1hoxcz65SBTZO7d7kJlNMGzp9RX9dG/ukfzDS/S94wel93IPusQFj 0Cd69pSnTPvsOrgtCEgFkw5f5jJTmeHZrW416Z74xPl9EhCyGWMhN3JPkrvWATfxU9XRWFzv 2opvMIou4jEdF9TkNwEJeyTbxz1u6vOuetXl32G/YND02alPPfUnsXnBHJnjg4PuZboPL+g3 O9e2o50KGxgcfKzLegOGCZBFqG7MURk04/Q7o6+gw3kTUIxYEMCoAmC1QwTLCa6WSQlKGGUi bozCFEqjT4KBnMtwKLPfAC+ACgDrAwG15cZZByECkDhv0ZV2E21SFIqYQMNYVQMSXQcUHRx4 6wQEGbKMNmsFAre73XLka9yUPkEHBclcqs/OH2J4nAu+J8PCa30OqNZ+iCbxvF4LXCIfpVkK N+S+nA5Ay3j0nf7IZF/1qpXleoYoyBoy3wu8GXjNLOpngYKIOxE6AxOMGD9wkI3mXFkBHgMd MnRugjlGtc8+y7Kdd9AvY2u/B1QAoGZhDBU41ABx1kGXAE2CRP0EbAE//1/pSsuODnjRE59V bTjmGli5p35wBPhdeaF6QOfq/QU4N7zh7Gm/5z1vCuCzpiKAXvQNPiiHDgmEAJ/qBXuDL3Tn ylde1j+/J5jDC5/bChqHVYODYBLnMi9zZ38CvfqdytFFL7psJ8YnYKhrLGDarOCAblXg5+jw bWiCAu+CJ5x9+MjZv+hFK50rJ5TEqVYzE+TDcRhGB2o1gU3IKHMufAvWubfApmbNnI7zg2vO NW78oKuZaha8CsrmjVMw89jHTjEh1VTtuTbJqIAg00L0Q59yPT7EFzlk7YKYakOmp7UXLBoS oMGBOm2uD7e//fDyvcBZFp8K+r77LssHzxJwkwU9zmf2ImmOzfFxgqb8Do/xgu1rt1aLYHP1 iXx21RPYrjqzndMKB59w/J+l4ICSUhAMEghwNokoL3vZKTCKsmSADJtjBry5KQf7H/+xEqzC JA5EhD2rs9qq89YcjlKKkgzQas/nJAAkh6HPrZOk+EMy3qpsDqAS4QgMajbJ2N7ylmVnxOmJ 5gAk3rQOg4IYc1vaAiQqJPVzggPGQmlE4xwNEHOfWaDdHpSpXbeRsmCMmDGRH+WpBgCMapQt M2DIQwyEAbeOFTBq71rXmkb00RlyNVcsexyynqEGAzKh+pnDI3vtGw9wJzvgLtM2PvJxX/9f 4QpTfgiYWsOhL0OmFcLnWYbHZtyr/V6AWEuyqx2yDPZlPOQuq0iQqNLx3OeuPF9mAOT9pS+R K1syfrrA3uIw2ipT/czmOb1ZekYXKgi3fBNsAEd9HrKwjgxUDGAFByRI1x+2Qnb6oC8JBnJ+ O/02KzjguPCjViVnHRIOmXML9Bxv/c59axY5Kzjg9GT+dDH6JhFyjyH6xPbxOJ85NwGD/03n cCixH1n0pS61rE/+CvTc1yGAjCNqdRE/6WISI1US9ph2VaYqfpDNrCQLnlh3o18wim2lmrHW AQfpaZsgcnzaSQJDp8jPPWrlhlz1P7xgh3Qmus3Bw5uatA096DAc0zZ/M8uOZx1wjp3W78g+ VSmJmaCMbATpNQBn66YJV7NLCaeKTGv3rlHpJLPIXVvuW/3jWtN7C1cO0mHzRxhO6XQwDpFR iPAAI6B2c9FLXY9gIErq/tYyINAAUlUxKmBxvDU4wEgC42AZaHWwMvmb3nQKjO4vUqsKIcsx nTFPsCKt/fY7cTk7zlQ5pgYHgonMy/pN0CQ40U8ZRls50GcCa7MYlYAaHPg/0bLMUVDEKQBs Ro7vQ9ZSGIuovM1Ik3VTpshMdadWDkSwNTggvyHZQIIDQWT9TmRLb+iTILPqDMOZl0k7XAOA aqZwi1ssl6YBknaUuAVmMk9AQx9NBwGWet/M19GP6HQO0xdDphViB7UkXef8jbfKW+ZCf+ct YKR3ggMOE4irjgk645QFakCgVmDci1MWTNBlQXrGSl/wAX/83i5Oap2nykHldT3oQoLXWWNO aVhQPoR/+AMkjVWmJMjTT8BvPMCTI0gWS4dVSVoecuStvivDkn2VwayAh+634GnarQIs/nFA qd4E7Fs+uZcpGddHBgKKOt201iEwqMGBwCCVA7KDp2mXzuM5jEqFN0kSR36VqyzLUxCcjNah yiZATiArkMiqeLzQRtUL+K8q1faXHUo0YLqAzToj9jPPKXN8gpHPfW7l9xKLGpTRefc1tqq3 dIKjpdvR8zpHrz9DqkazpnXot3Zho3ELEoZcSzYCnmrHfJMKJt6wWWsztAvjM52X4LZd51Pl pV2yVj2qQZKKFl9qrRA+RN9qpR42uG/1tXWtycDg4LsnHP936abKSCIhgnbTyWQZNCmXaQbz duarlf05JE4aIzh0GXQELsK1IE+WrXQjAKD0BsVBxvkwuItffOqwnKt0drGLLZd+ORelNkqo L0CTIcZJnO5009/1j7Ao4JDokfMW3euLa2XsnD4DEYVyNgxMn3wGAByh4ER0K1CioDJOc6Sy GCVWfRaBq0qYj/I3C6rcEwgCHf9TJkoPBPSZIpzlLNMSZRbtyASHrFoFniJGjoKMjMe1+qut KKq+GTeeAz7jBZZAVZ8oqN8FhvMeFZOpaWf33af3E9hwFJwZMNAPgUN0xr2jM/PGIzCUjQnC yB6w4Q3HiKfuyclrk/HQv5SAM3WA7+4rUwI6nBD9UhUiP/2lh//5n9Pgb8gjmdoxJnosCOXg 8DAZFT0mv6yJaAOR1fhoXl2gyNC1DRxTkRG4WVPBAeuzzCbTNXSQTQBtY3Ww4WSXeEe/nO8c tpJg1HjxSAZknpK94mcCZIkCoJGhkaF71zl8jheQmusd+jge+2BLAJNO4j/dl7lmASoewhp9 A6InP/m0//rFIZCnPhmX4CL6pB1BMF3EQ23XaTl2QDYyMjrq2ug4Oz7taafBkGvhlXYAK5vA O05cP/EJPoZPghT64zo2Rk5DgiU8gwd4HDxQLWDH7slhka3xkqtEhF5n8aJpUfczDusPlNVd o8/6xNG5lh6pbpzqVFPMNGbYpo/BBO2SN5xyL/bmHA6sVr70zRoj/NAfNqCPdc3VagfdJh+2 4Z4CGhhVp4wEeNautFNUxutcOsj38Av01lj5ELhnnQQM1beh+si2YBJ5wlsJiPENCe5Um/gf dm+aiu9JtUWyqKqiQqW/9IM/yHoSyQpeGAfbou9J0NiBCqs+0AP6SpdVDciH/4MV9I2syJee JxDGF0E7+dBrNl+noAYGB/864Th/fwHGAFhHBgBE6gpJkQxwpJScoc+UgrEALM5T5ykrh+O8 zL/IFLLow2ASFRogJaRgzqGsPlP2DIhRy0b1rZYDMYYDcQ3AZ7xDFwJlfhwY6CeHw+gomwg9 ix/1wf3z2TlZBMagKDbBZJElB0TZgItxuI7ggSpe+i5zwo58FvkBOYqGP8aD/+0K5bUO/NMv 4wEOjCYKI/vgrGQNjF2/8F7g4V76QaGBbz7PmluvB6V3HiVkFAyAM68LQmUn+KFPlBo4DQGS lHEpOSCPTDgM/ccn99Su6L99/h4QcTJ+51iMK7wQSLkGP7L6WdtDghZjY3x4RGfwrGanQI8u tHO+89o0Ho7ceF1fpy4AAx44x3jIrV7PXmU/fnOOLLDKgBzJRtv4lwyFvrC7qqsAKvLBN9/5 TdvG3AaM+Oiei2RrnC6dAeTuJ5AUZAH+VDYyVucZWxYXxnHXftUsiX0ak+BK0FgrmJKHjNVf PIljokv6QKbGSRZVX5wbfHStcdcslb653r1dO+RxV3pc8QD453Nw11/VBOPkjFwT+XAqwS4V NDhTZYF3ZA4TOBx9y1QMHmvP9fhC38hBkCL4TT8cmVqOkxYQBGc4nyGVwFqlgpd4TA/alfQC LpXMWftJ0GO2gc98TnwIHKqygdNDbDnTQoIk/RFURAZDHs/WT36K7ri+XWytkkkP8S9YX6sx +o+PxgOXU1nHX36SPNiqoEMQnoQAj9ixe9NL+lYrXK4jF30ibxhVn5obGBygJy88R7NZDgZp rnOr9n88xmPIIbha1AHvjIMj5iBqNWGrHgLXoYtwx2M8EmwOnX7dTMcCwcExJxx7bbkBmtdR tlGOFZHNe756PMZjKx6yDwt/rYqWJWyGDZhU12TzSs+mAOvK6a14yDLx15SBbKs+cTIe4zHr UIn0dIupeJWKRfej2SLBAXp/N51e2LZljuOP39Yddti27tBDt3UHHLCtO+KIrdP38RiPoceR R27rDj54W3fQQdu6/fff1h133Obo1yGHbOsOPHDar8MP39o8PuaYKY8dsOToo0e9G4+1j6OO mup+dObYY7dO3xcMDkYaaaSRRhpppJM6jcHBSCONNNJII420gsbgYKSRRhpppJFGWkELBwdf +9rXuo997GPdn//85+268Te/+c3ufe97X3fIIYd0xx577CiJQj/+8Y+7j370o92vfvWrXXL/ v//9793b3va27sgjj9zhbZP1+9///u7DH/5w9/3vf39LyCN9PvDAA7vf/OY3C1379a9/vfvA Bz7QfepTn+r+/e9//6/V6c997nPdhz70oR3WHl5+5jOf6eUCQ+jsSZm+8Y1vLOngH/7whx3e vra/8pWv7JSxfOtb3+rHcfzxx29KXv/ud7/rDjjggN5uv/e97/2vtdmFg4N3vOMd3VnOcpbt UqSPfOQj3f3ud7/uMY95TPekJz2pB9CRlumzn/1sd77zna97/vOfv67rP/GJT3RvectbtqsP t7zlLbtPf/rTO3RcxxxzTPegBz2oe/jDH9497nGP697znvdsCXno98Me9rBu27Zt3Zve9KaF rhXk3elOd+qv/f3vf7/hfWWX7Oo+97lPD3CbhV73utd197///XdYe4KDF77whd2d73zn7hzn OEd3+OGHn6QxAe7e4x736Pbee+8eP3c03fe+9+1e//rX79A2n/70p3d/+9vfTvT9Bz/4we7s Zz97nxyuh+CG4GIj6Le//W3vmx796Ed3j3jEI7p3vetd3b/+9a81r/nkJz/Zy+Y1r3nN0ndw 4p73vOdScnCve92ru/e9790f7FOSjV760pcu/fb4xz9+ZvIhOaHr+vOKV7xiYQxaL61rWuHW t751nwkddNBB3Vvf+tbu17/+9YrfMTMO6oc//OEKgxahXvGKV+zudre7de9973v7KkRlvmyZ 8N/+9revMHgRnGyW40RHHHFEf16tOgDf/fffv7/HIln3n/70p15YxiKjHUJ/+ctfeiX/4he/ 2EfynEDLi3/+85/9+I3FubMMRRTN8GUGgF1f0FOf+tTuiU984pLyOYeSVZKN4bEqTIhyAcwr XelK/W/69KUvfWkwL7761a/2173yla88kVzTPjngk3ZVOYaQcx/wgAd0l7zkJbt3v/vdvdFV GdGBww47rL/3F77whaXvRfHGDkj+8Y9/9HzHh+985zu9007mGCILvzv/r3/9a3/9xz/+8b7d 1oG4zzvf+c6l4NRnsvrjH/+4wvD19eijj+4e9ahHda997WuXflNZwQs612au+KRv7u28m970 pn1/N5KMGyABD/fmjJ/ylKf0fWFrdAzPnYfXLR133HH9eDgfursI0UE8Zp+f//znl7Jb/Mc/ wQFbqST4ZP+wwvna8Dl2YQx0kJ6T0yz+0Zsb3ehG3Xe/+90T/ebe68ED9LOf/azXU30LPtEn uoiX7BqesWs686Mf/WgJyOkju/v2t7+9gj9sxlj8TpcFb+k3ZwdPZdPuuxpe3PWud+3H05K+ 4Cdew8ahxH7JjWObVSnUh9gPG2Yj+DqPyHGfffbpnve85/W8cNSKB92kp+yYzv3iF79YIdOf /vSnfaXJdb/85S+XfnPeta51re5mN7vZEr5pYxHCc9fhPzmEVDIf8pCHdBe+8IV7PpKDfswj vulUpzpVd4UrXKFvT1X94he/eHemM52pO+qoo/r+nfe85+2dP5/15je/ufehbIWOXP/61+9u cIMbzKzIwx3BiiACpgkiLn/5y88NWHZZcHDzm9+8u+ENb9hngQ996EO7O97xjkuREGPeb7/9 +kxLhug3xhMFpiwYdb3rXa974AMf2D3nOc9ZAiLMMXgCEiX5n+Igwcgd7nCHnunaE5Xe7na3 66MwRACuczz4wQ/uM6ehFQlOWOTs2lvc4hbdc5/73BVKs1pAYez/9V//1fdDpMlw73KXuyxV VfDEGJzn+8c+9rErDF6kTvD45Le99tpriY9AXT8QI7va1a7W8y73Nn7t4pO2RZRRppvc5Cbd hS50of53918kQwdKeHHuc5+7B/lKjEeb5PaEJzyhO+c5z9nzbAiR7TWucY3ughe8YC8fgcJP fvKT/jcGiAfa5YDpFUMClEAdb/GArrz4xS/u+3D729++d3B77LFH/xlfATQAutzlLtcHIa5/ 1rOe1fNY2+RUK16AnlECG2BBBgyVIyL/ZOB47NCH6DKgNwZ6rn18jvP68pe/3MvEOIwHEKgc bGQZ9ec//3l/zxoAARDj5iAFDac//en7MarWcagCwOok8NFYjIuMhvYXaLnukY98ZD/e0572 tEsBKX2EB1e/+tX7PlQimzOf+cz9tfjuvGte85q9XFzvt4te9KJ9lYl+3OpWt1oROMZhu7Yt /wLdYMGieMBRO59stfGMZzyjtznATS933333PpNDqhYclftxYvCO3nB+qm+CiwRu+K9NcvKX bGAGvX3JS17S7bbbbv01sWnjbqcQVKHaJEEwCy/ILfbJoQ8h/HQNu3zDG95womARBukr2RoX 2Q6pKL785S/vzna2s/XjgyfuUbNi/CFrOKbf9DGOGM9ue9vb9roqicSLTEH+4Ac/6J3wZS5z mb5Ncjr44IMH24kgCH8c2naP2C0fw6+d5zzn6XWG/Q4JPARLN77xjfukTBuCDnJi9/Ej/q+6 C0fwBakQk98sIms6EYKHT3va03bKFOW6ggOAymjSQZEscATQlLwqGXC4+93vvhRZI2AAgCsB NYokcw2JgAFKvpM1KkdVoxGpqxgQdr3WfCSnP2RthOguAQpDu+pVr9qD7Twytj333HNFJC+r EMS4r6MCLGOI8+d4GUUqH86lLDImBJCUqhglEK/K8MY3vrF70YtetPTZPZSmOCUkSwOm20O3 uc1tukMPPXTFd9oVeKQvFHyR6QtGwyArxQm/+tWvXpIBwGcs1XkxNhFzQALQuJYRAxMZmWqJ awFaSm8VkAQXLV9E7wIh+pjsn7GL7jmrBHMyFsGQQIuB0v+a0agoaF8bQKXOr5MXvd3I4EAQ TV9awge6wr7wL3qt0gWQE0TQs1qBEYjWMulaJFmosnryk5+8omKI8INdVGKv9IkNXPayl+1l JVsT+CFOgR4GYAVw+lyrGuymDQ6CB7G1RfAAn+hUtX+BQA2wtYXX9LaOm67Aksp7eouUqwWh xihYk4Qg+Bb8uNjFLtbbQUj7L3vZy1b0T/DRBgeSDEFzSNVDkFb1cx65V5KPkCBAUhLnye5V NIc4zARtq1XLjBv+wfTgDdkj2F6rloIAgWSIHBOcLUICevhTMUFSlQotUr2JzIYSPODAYYBg x0EvjCnjI+9aOcPHYNEzn/nMPuicRao5/CJevepVrzpR9W0jaeHggIIokSq3hjCA45MJmjIQ 4YuigIGBmT+v54v22nkTxjdrThKjM/dOCO7TzssAhkSpBMuA3HvfffcdVE5UZiIc13Kyl7jE JVYY+WokigVWtcRDsQUXlJuBBCA4EwCYbJwjoRSVgEvaevazn93z7cpXvvKS0YSATCJV4wSi F7nIRZYADKAwqO0hytyWnhk6JZUpAXBBXrL/ISTDJJtKQBMP/a0kw68RM6OWUbYEaAUpdEQV QQDCGSYYxW9G6HqOqOWLEnq9TwXhZH0h4wXMqisyWkGv88jXGPzPubTt0cHrXOc6G7rAVJCW TKQS8BPk0HF2GWKPcVCcqcxRtpbxqPIIcoYQPmlbdkQfyaKdZsGzFnQFdHjFYV/3utftcYQ8 6TOScFTdZ1MqENX+ZwUH/heMrQcP8FFZmfMPL7Tf8kJ2L4sO+Ifon36zTdfpA5JIGCNMMCbn oEwTGAe7rs5UgBpeVL1sgwOYGDzwu2sufelLLzSdKJh4wQtesOI7wSyMkk2Trcob3Jo13dGS JIvOC1RmER8g2Kufk1TihYDHePAHbtb1VyqJ61mPxfbbMeofncp0riA2welQolMq4XwGWeBV fEP0w+9+o4d+F7wmAGqDA/qtupfpTe3CNDro2lk4uCmCAyQ4qBEz4CFIIENJZZiiTiUWwCE7 q1mTICDl2ZCICIDX+d6URQFLHC8mtxkYQVzlKlfpgT735dhkDkMWkwB5WROwkvkzrNZZzSKO AJDUeXfZO5CmFIRJ4bWrrC5zSzbDUbaOCv8CqioHsmcKxODNgYVEpIxDBhMe+18ZEJFNG2gN MehKlLBOK+iXDJgMZCR4Lttk1EOJ4QUsQ/iE/22pEkgDrJCgbdZcq1Ix2WuXE6Sb+o4ScOKN kp77APVKSpKzMgXZL3CuJOhTcnZwatqtei5QAu7uU0HRvWWFrSMBSJzFjiAZhmyszpHSfU6I TqpI1eCATdIjRG8udalL9TZpTGzCMWS+VTmdXOiX8ZMHEGwXQ7LNtmqkD/qED+waL7SV6QeY okpYMQJwt+shakk6eCDjXQ8eqCAJfl3jWnzwf23fGOmmLL9WSZV72S17d7B/uhCAN0ZVEOAu 0EQcuX4aOyfoupBqQFs5oOeqPq2tcnrBA2PFq0WeKMPn9l6qP/gBg2CcNjl8GDmP4AQZCIpC VW6SjBoc4EcW/7FZfIU/bEdwUisjpgJqJWEovgmUTZFUMv0i6EnffF60csBXkC09VsGDcyqN fGHwXCDu/nSe/lS7b6cVBBuqoOySTGoVRWVDu5syOAAy5k/Pf/7z9+BJoDKOLOTDGJka5wdE KTJhphRFeTlfoEXxnEMhCIeCy7CBuuiYwoqogCpHbMpCaZdRum+ibNcqibmvQMI9KbDr5zl5 zE40LmsRsZkq4JzmLcqiAKc+9al7wesPhWbsWcQkSFAKonBKtNoVAVJkhstRARO8suBEVKmc qc/Xvva1+74goGadBv4AKSCATzIQY9U+xxhg4QwABv46x7lDHiPL42HAS2asf65X9sWL//mf /+nlhk/4BSCHlp6Bi2vJXpscUZQev4CebIEeMQiOBDjhk76r5gAUY6rlYv1SNWHgIm76kaAr 83oCM23IhjmuLLxSnTDGLEByTjIIU1oCH4EWh6X0aH0J4GK8ZGNe1TX4z/DpZ4ISfcVHfQAc JzvZyfpz45wEuKpsStg7ivRTdUS1ih3oq35mmkZ1QCBP/6wZMW52Se6mYvCNU2eTdWpmLXI+ G8AnsiMfzj3TY4Ik/MBL88R+z9yrvxwiXutbHm+2ZoTN0wlPRtEx1wnI2CviZAX0MIhtsCM2 D1DphP6TLV1lI9odggeSE7whS/LCCzarZIxvHNoFLnCBpeSITqkyGC8ewysBp/PIgh0Jmug6 fhsz25Eo0AHYo1/GaxycL35pnzwy7ZjFs3jIkTonAagAJnigv+QAc4c8hgcrtCXwFXhpI+tW 8Po0pznNkmzZSJ3mXYvIRz8FTGTAmesTgmFwgI2wN/ZojRDHTT50BR66P0xwroAtFSM6Byvp O2esnXYtymoBC51QlTVONivpyLXGrQ/wxO/4XYObtXyiyrVx1iCTn+Qj2JwqMF7AolpVEyiY phfgkgPMgCuSCXZrjR1+ZBE3OUu+N2VwQBgUhJM3WIDfll9FmAwM4wnZZ4YFhBgPY/KbdrRR F/+JerMwikHHQQMC5zvy6EddDYzhlMVvDlku4xiy6lqGoF0RHAVR5uFs50XenJeolhIrdZm3 qwveKLppEW3JZhgI5YtT1D4A5sA4fu1xHgwWj5K5Myb94zDz+A8gxTtj1W9jiGNDnDweAR68 GzLf7d4MJnwOrzPPb56P/FVzOLWhi54Q5TamtOmoi+f8jz/6TGcyreMvg4jOONqqk88JfgQW FbwACV0CmvTU9dFXAWD00F+6meoLEqgpo3KysrtktZwZMCc7/SVTv9VqAfsQrGqTPAUX5JUM h86bd9zeR05bojN0Ub9ScQOqQFHf6U/9XCtSxug617t2yNMVbIwjFhjjoTHV9UXG7vsq+2Tb +gEn2LH+uL9rnccpyrzpHKdLhnQ6BDiBfNVV52StADzI6m73JKuheMCJcO6u1S+6w5bpBl1Q 0QDi8IwtyDTzGCD9cx29Y6P6lcQJDghmjM33Ama/0R/9hiV4wNnRm8r/8LfaZdYYtXjAftjA kGya7UQ+sS+6i8iC/sNS35PDInuTCKKNOVMI0Qu44X7ky2bYY/0Mx1yHDxIea5+MuSYF+KZP 8JVeDK3AJbsnI5XPWvV1n4oHjiGBUPpf14sILvMoI2wIf9u1Sioilfe5dwIpbdIZ19G9RTB3 pwcHIy0TZc+irpFGGmnHkpL8ep+F32rEkVqTcFLfzGmkrUNjcLBOUn4UfXqWVTluPatnRxpp pNkkW1eqNfcqg6wVnZMaCQhk5RbUevKjfaRwpJF2BY3BwTpJGcviEiU4c5pDyk8jjTTSMFKV M5du/l6g0C7mPCmRqQ5Tr7DEWOumZiONtKtoDA5GGmmkkUYaaaQVNAYHI4000kgjjTTSChqD g11EVs0uuvfAjiQrsj1BsTO24VQ2db9F9+vfleRJkp1dysYfa1l2xr7pO5s8EjZk34SRTkym MHeGLsIkdjpv6/gdTXYk9TTVkPvCK310zLITNmS/mF1lR/pnLEPu7/fNbO8nqeDAM6UemTNP SeHMW/rrUROPCHmO1O91C0qKZM2A3/3msEK6PjazEWQBkmd7dxVgeuTSzmA7EgjMlc5ae+Ex Lc9v1014Njt5fMjGQPXZ5UXI462zXly1FuGTFeuztkHe6uRR3WwItFmJY/EoNdnVR+NgAXzw OKPHLvNYK6zwfx55zr76Do/a1Q3dQvDItR69ZS/tNtOzyDoEulgfO90IsleM/VXsz7AzyGPK 9uGwCNPjoHnp1lqUvSHsV+K69hFGjxnDGRswte/y2BlkcanHDu1s61HJtcgiW/s3tLtgbhZa d3AgQvL4Td3KVAQEEDncvLmLQfm/bj7CIckkWuPBLOclkvL70P3obTphYwzPiNqch2LYQtVz rJ6l9rIUQvCEgb+e3c0YbOLkJS9+80wupbMRy/bsXifS1/f64hSKgxf4Y5ycc97EuJojcV67 cQsw0u/sawDU2m1h8RCPZ70mmMyAnGfs262fc37uMZRUQfLyJM9ne5Y78sVnAZjNPnL/WXJ1 f30eWs2gR/iWMbi27vUQMiZ9Wq1dMnEt+eCl88gPCNnEyn30zZjavS+028rH2MiW8/C7Y4gu GQenYtOk8GmWg9E3bc76DcUG9XuRrMT52q0643r9yCN2/h/yVr7aJr5xuvUFOXiMb6meabM+ kVBtx3jr21cr4SvZ1XHOGod+z6tcGaNdIyeTydJW5GzgjGc8Y78BGGdGPp5QsjWy/Uk8ew5r bHRk7wMb6NjQCea0Ns3m7FXiGo7DhkbZpXJevzyxYaMn41xNl+m+/s76jd66bpZ9ZJz2GLDI WoBQk4bgdX3MMphTdaHKcx6RjT1YPOnlbaH2bGjxhg64b7U5YzMO53sBU7sXR/pq/4bVdhKM fszSt8qfVFIqVkUXZyVVeOLeklRPnLRbxc8iAVHsPXtphNi372rVlb7j3dDEg760fnpDgwMb YdikgxMF+DZqIECDIGw7geVtiYzB57xkQhTOMERM9Q1jhG5DC7th2VTF5hGuAbLz3gLmXNFi 3aDDvuJeqENQGB7HlP7XrNnGEjY2CdmQx/4F2/OiHM7Qbn224Y3iABA7X8mikR3f8JGRUBDZ VZTAvW2kgZ+CHrvERXFlJgxYO9lcyRbC2WLUd9lK2M6BdaMdygJoZKiAqQKJnbfs/ia4smkP Hsgmhjg2u4DZzcuYZR7GU7dHJSO7sNEVmbF7p4KjT4I7gZ0+2wRryO5uDNzulEDCxlWuFejl PR7ky7kzUmOhk9VI8NOmT3SULtv8x453cUQCHVkeXRJo4lm2rgWkqj+uo3vuE/BUdRCM6he9 s7nN0DcC4qPH9+xKx+nodzZtwie79ZEf4GNDdf98ek5n6JUNZehHu2HUagSgXUN2eJosjk2T F9l6XFfw7L5DN2Ox+x39JXubFlWHx77ttJrNwfAqb2FVvbNjoM224IJ+2RimgrfMm4PWH+dl F1Z2hgd2J7QplCCNvsGbeTbNVthotnpmd9qp24Rrq74rht0KBhD5sL1ZhI91C3AbMw19f4XN iOiZe9E5/akBU968adyy8WzIBU9skhad8XutitqQh637Hi9jA8EhyRXZ4LFNprKbIIdjB0u8 oQsqKDBU34YkFcYBn+0cSN/YbRxjdqIkA78Jptr3STgXBq62UZdgdNY7UwQV8C32k/cUwGE7 GhoHTGRrqju+y061NpPDA32ii9XfsB8VA+Pn3/S93S58Fqlu2/0VluAnvIclghDBtOqyNsMb m5PBaFW4eUmUscAwvOXv4NIileKFg4O8JYoyil4YIsOwKxeisAYY8NAhiizCjKJlZ0NtUcjs 9IUhtikFxBQa47IX9VoEdGa9ljg7fVEggIuxAg2GRhnCXEykKAzKLmPKd7bE3J65oLzdkQNk UDVYsj0mIjC8EYy4N2fif/2y0xoHAQwdHD8HmqwWD72WmfC1r5xmbIzdrm7ViAFnzdrIws5j QKBG+v7n1G29TFb4BpSHvAlMvwRCAF9k22bZZOhVqAIQegP8OQ3X+d/OesnAZWcChCEZKsdp i1c85ciMS2VIuZYh2PUsAIIv2ZPdfekYudBh8nIusMsOZoCbXjNWOiYrECjpJ3DIVr7uq53o YN5IZxzGWqth84iD82po4CiQkYEAhwQHtgjOzpL6C+QyH62P+pyKG9tq98tfjQRj2X5bHwRC CaTIbu+99+710XfGrU9DKjz6rC+cLJCqJBP3ymMBKH2hZ7aUBoSuo3sCK8EuPnIG2QmTvQDh YAm8Id/MRdMdMlABhFVk6tpZlbRKeaUvBwIX6GV27gy17x0RgKUCwOlxsLMou6hyzpIWvFyt ItKSAMnUAqzEH/fLFs5sgD5qk0zwAo7RA06eXmb6UtAniHaeAA0PBX364RwO lUNEeK6/0QuY kspg5tYFBColsMn9Bc9DthyGDfqMJ6mmRp+MC2bRSdiHXwKr2FswvX1RVSXntsFB3gEkcGCT MII/gj/wXoIFA92f3bFjGC4IyC6ecBaRf14rT455gZaxsB8OfFZw0hJbPsUpTtEHIHSUXmuX H0Qq3HU6zhST4GTIu3/4vwSx+siW6rs7dnhwAITbaFdHK5gAsGwKxGHk7X4UXOAgYDB4kTPA qHMzBJUXlAyl+m4HwCCzBuiMAoBSPI6JsJT9ML+2z7hsuCJAOMMZzrDD9q7GK8IALvaIF+wA wkScwK9mfu5vzp7Cm7OShdiW1cHYZZHJThmiYAJwVpKZZ399PKZcApB2Xktf8LktA8pOKvDN ejvjapSXRc0iwFLLfHldL3lRWsahr9ELmeoQRab8KcuF6GfevgZcZB14mPe4IwBWI/KQbDTO loMAfLKuSkCAvusvXQEkQK7ulolvCU4XIdNM+FH7g2/RV/Ln5PBJlUDQmyCMU1AlwUu6wwaH zGnXAE67gJ7+RbcAY5UdkMXzRRaz5h33lThyDjxAx5kJAPLuC5lwfckPB5FqFL4LrqMz/tKZ un25qtmim5PlFb4SCbKnA+3LeNgpPeJEVDlhWmQt4KwvDONgXJ/t49mx6wUYHGDeQTGP4Khr Q+xM4IL0TTDNbvAFP/Am2OLeAiTf4wfZRtdamXDEkgbE0XsHBP2OXXoXRrA2tpbEZ1EyBpjR 6gScrq/MDkZXJ7me4ADu80GVBCBwiO6pPkoUVNzYoP/xmNzwV4DId8XmYQCs5LOy3XHI70Ne 4KTiYP1EnfKC7XAYDrFteh+9llzWIGkewV39VZHjL4as61h3cMB4ArAhQQFBJQr2F0gZEKcU B4S5QIaiA1MHha/OiEOvUfoQYqB1X2uOQMDBIfuewgW4AXurIDIEkThHRdCMmWFs72I9AEOw MriUyzmatMs51ReGAA1gIWtXUlWRoXTAxv8puSIAqgzbAjQDYNwMLzz2v5JYGxwA5pYoZZ3G 4eRUb4YQQ0oJriVAZXxVad0LL5RxRfCmV4zVmIHskL39BX+MtJJ26BHDz/iBEH7nrYza1p+1 SqDkhe8CurxUCcnGgabxAkb3MO76JkL6NpRvLVgAq8iVw84CMU7Z/dzLQccZfKoSMhb3BOQC UmVOfJ03104GeYeB8bJPGXeyJMFBDXwELItuG443deoOybryqts4hvpZcFBfT1vfBaFKYgoS fuA/nREQ1rnYvPFwEeLwtQeY8UDFje1UoGcTAg96hs81IBGUVWepP5wxXlZ9EDQIdIZklwhm VdwiozhW2S3MNJ0R+yFPWSz9ic64hj4kOFCFaGUiOIDlSP9UJ903VQ98T/AWG1nvjo5rBQf1 HkiCUsv0eTndahk0XMjbWUN5v0mlBLqCbr+ZNiBrfOHn+BYEv/k09oHHeW20xFPlqL49ND5o yEJDNluncZDqgb5nCowN6IeqAR4M8Uv4SFbkzifQU1XRRRKWhYMDEZ0OysYALEdGKdv3a3PK SoR1b3RGpuzsGsYnWjPgdFiUpHyuEgC0CX5IdkKROBpCUprRDscgytVHmXoWrxACoYmks6BL pgTsZJEOGSsDqosJKRFjWeRxPGU6Cx1F15yhYCVrLwjeitpEgT4zchEy3sTBMXCf3d/cqfsD FoAka8RLwVgCMAYvI3E+PsictZlpniwaBVTGqI8BVO0ylJTH3VcU3c73rUaiakalPQouYs2U EWM1vig8XZDd6CNQV2Uhc30gJzJps4fVgo7//u//7p032akkMOq87tR8JR7IAjhZDiYyNGWQ l68wcjwBWHhO74yFzPFM8Gh82pJRk2kWk+IT+dbgwLXGry19NL4ha1joA77kXJE+8ABe2rAu g17iDcCQ3SbAYQP0Bk/1X384snn79Se4F5hqG++tBchOfcaWV8gi9lE/r0V4Qx/gAdCnq7Er DnPfffddqm4osfoscAWA+p63fhqDYC5VPc7CZ7btHuxevxNYwA6JiIqCe662EK8lU45Z5S6D Cz4kQHMvwajqTft4oT7jvwTAmOkxOwxvLUAU4NM1PId1Q9YckKVAj0MKHrpHslXOWdZr7Fmg KYjSB/fg8GAdnOSMVU+DK7BblVVf8V3GDKfon0AVDwUYzqVn9a2NxsGR0kO/LbJGS39goWAF LyrW0xV8IVttsjNle74iAZe+wXTO1fUJkOmJvqg4kVNdMKw9dingcw4fASsT3JDzbrvt1suI rZ/udKdbsmmYyMnCNTx2T9/hBd2TAKqo+F5V1NRMu7BzFsHHk5/85H3gxqYz9U5vQ1koqzI2 tIrLdt1f//BasivhJL8NCw4QYxZBMU7ZJ4NtDSXlqRhrCAOBN6UT7VLqlL9EqAxIJikr9vtQ hcsiPNGdtjFYvwAYQ7LwJYsDZUICB9EUYQMtc0RZPMZpE0YNBJTm/b7oOgSBiH5QfAFIsnLO jLAoK4VSkclnhguYGLIIUtQqqqW8WSgDcAC4v6k41ChbRO9+jEo7qRxo11y/UpbrKRAwpIDK hjIF/GOAPnM+gHHIPCJZAQo8FECmTEcG+GB8HLbP+uUzh2e8xm/s7iVDwZ8hlQNvZONQRMj6 TU6ZhzYGfeBkACAemrdNNsmJko2+4DG9ZDyMHxDRwzzKSIfoiHPJEmDJIPBYWVnbNTgAPM41 HiBonPOeVacH9C6vBM7css/67zOdNU484gBUMFLG5izcE7Aaj3PaaafVCGCyHcGU6hqe+p/9 +ktWZEtWeOxz1m+sRQJ/dqOfMhd4wWEBTc5OO/pNd/IZCMuW6J5glY3SeZ9dn4oGGdFd/MAD WXsCU4GS8wXArskc7lokwGZvFoHFAbIL1T924b4cB7uBEe6RviCZmmvpGBvQd8G1oFiAQpZk ourgWucPWXUuaOUYYBZc5XzopsoG50KvODj9pG/4yM7oEweuwoVHAhcYop1kumwsNuJ6fRI8 BCsFgoKLYKrgiRPLPLvF5nQFj1XYhpJkEp8sxmND9DVBLp7n1d+wjf5lIXCeLuNbgl/0MYEq HNQWnkd/6EYCD/wjA/JxXhIuBOO0J4gQfNDbBBbpk3uFF/QtazkEKfieCjE80r9a+WpJn+kB HcVvumdseT14Jb/X6cZ5pL8CJGOAxbACBtPbIUnXuoODCmbreSFKsol2wRlFdgAKv2t70U16 tEmBKhBrM4+l1O+y4Uc2zXDPLCCr2RbDliktspgjxJlnDDXYMEZ9cu9sfpPPNQDBA32qEaix 5TE3f+ujZhXowsNK7pXHI3N9+Oyzo/apfh5KeZSu8iAyyKYf+VyDP9/VRzSHkGArpVGyb5+s MC79Sf/JvH0c0XfuW3noHH2L7KI/2sp3eZQSD2fpqb5od+jjXXUDl8on/1fddc/ot7bD6+hN xrPoplOxv4ALfsY+IqvVZLeWw42tx66NJ5vZhK/arZ+r7ukDeeRzlVOwpOqM82MfsZ/VHvts dSW8zj3qpja+iw5r1z2qXRpjNugJljgn+hb5JFNeBC/zmDF+0qt8rvqun6vZT9WZPA5XSX8i z6pT0YWWh3QrjyQbt98XqRyET5VXrb66X6qJ7X1b/KqVg+BeML0dqzZ8X22q/jbr/1AeF501 1lRl09/o8Fq+oeKz/2ctmDUmCciQheGzApDqZ30eOl0+7pA4gJRolJ939s5hI61NQFdE7ZEo mdPQLHmkkUYaaSuQqpGqjif4NnpjvpbG4GAA7YwthkdanETpyvlKfOZkh87HjTTSSCNtBTId aUrTQur17ta6XhqDg5FGGmmkkUYaaQWNwcFII4000kgjjbSCxuBgpJFGGmmkkTaYrFnbSm+m 3a7gICupK1nNaaFYXi5UV3VaxZkVnFkxX1eEr0UeOfFIS/YM3wiyKtSjPOZ46nOmG0l4YTGd e3rkaMiiOo+iOB8/6vsLEF56xMzjRzb9GLJKe0dT9iD3COW8Z+w9CmQcNozaSkRv6W903Yrg rJgGAn73m3Pmbdkb8iiVtRN5tn+jyL4F9MfRbjazmQiWZLW/leVZoV7fF7DIS6B2BlnJPlTe m4HoarZdXpTYdjCcrPxfn6LJE1h5edAQ0o+8P2SRJzoWJTjrHvY5aB+33yiCyxtt2zuS1hUc MEjPoXteF7B7jjuPk1lA4dlXz256ftWRzSuAkuedPQvsWVG/eVa33bVqFtmIQ7v1xSUbQR5X BNCL7gC3XhIQWGzi2XuHfQHmkcdRPG/tOvsVtIbtmXBK6DnfvIxmZxJj86wuec17phaweA6X Lm0lsieHZ7s9/+7ZYc8oZy8Iz8h7vtj46blnmTmz9hHKloCpgC472G0U0R92pH9DX6C0s8mm WZ7l99y45+7xBC89G0/32amNZmzcs5nIM/R5/8NWIPY55O2Bs4gM6DkMtw8D+WTDNLve2v/A PgZ5mZfNjYa8xM1GYLa7t4HURpEgRkJCtxbdRXO9JAnc6Ndu70haODgQaXp8zK52doaSeYi+ bNSCAByHZbMjIGTHJ5s35H0CHBrnKyMQTdoQZegWojagEJTIlu0Ul40xqrLa8MLqdeASopB2 mlMVsNGHAKbuJZCtTO1yZbMZjrVuK+pRRps+2ZSDQqU0ZDMo7YlAs5OXDWhsrDNvsyR85GC8 eAa/8LC+lyCbHeGV+856M6VHW/ISlVkkwLGZR0s2DiIHPLQTWKJ6m0hx1DWg8JY6m2dkP3VB mvOMU//qvUXjNlexmRADt0NZNglZi7RtgxgyIjsBE71BHIH7yybwxOEcO7PN23dC34yVwyWn +nIumxTZq53B0iPjoVtDX9NNzwUDNqFS1bIXRvTCfekA2dBz1S7t4/U8AojZehkvHfXlPDIy O4EKytlg3SgKz1S86IzxZofDELnSY/yzk6SApu7T7p50zaZE9a2Y2SjKbqf4A+TdfyMdM7nA DRgCH/LSJzLLNsL4S3fsdMkGW12nHx5BbvFgHsn8bQCGh67POPPK5fDMhjs+Z4MxDvFc5zpX v3MfPrq+3UKb/eCdPtnMKMRp4LFxy8iDR/RBYEkmAg/O146nKnN14zNYAD/cU99rxU72DtPg p82RbGSUPStsOOV11O6Nt9oYWm3Mq8P1TdvkE/vRtk2BjFUFgG6SUd2GfC2y1TmstTmaNiqv 4BWdhF/ZGbLapc1/YBAetTrhCSd2g7fwhg3UYM6mXbBRwpu3oSKJLd7CaTZo07DYxLyqCznp q3vO2qtA/1VZ6Qz+8K+zcHvTBwcYZpAtw7OjVow2b4MCjDU4cB6gj1OQuQzd0pFDsBmRXacY k/9jIHanExjIiCgVISaKBa4Ak3MQJeo/A4mTzp7kHhUB4Bx2XjQDVCg1JaBM/qeweR+9+8nQ OTCGB7i1Na+Mxngoop2+0lf3ytvSBDLAwH31iaK3b54EfqsFB9oX1VcH4TwgYedJu33hBaXE G0btfrI1wMFggCIj8FIqzgLQMRry8jvgzPSL34G4YAIf9QtQDtlZEV9PecpT9m2TnX3JGROd EYDZ5SzbTiM7PMpE5pUDgZfgE/+M1UYiidzzKuI99tij54nqFkAaCl4hVYFZjgePjCFEvu4/ JDjwTLMd1vLKVbJPYMAxKk/qL96TQcqvxikQwk/gqW/ZmljgKgDzPfkAQDzPuz2ytbnf6AZ9 zi6BgMr5Kg3uT8cFcLPehLqjCH5kV8PoKwL8+ki/bTNtBz02QmfwNzsOOid4gPcVD9YiVVH2 wCG7VrJAjpw6neFMsuWxIILO2xEvIK+aBF/cnw7UaVA7wWpbf7UtAckbZ8mdLeYVwWRpR0pB gnO9FVOgnF0WBUt5bS9d0Ee/448AkHyy+VbeAwBr6Qx8Y6+udb7s3rVsgx7MmwpsiT7mldWV VIRrVdi92jdzziJBtqBbkOwawY7Koikbzp9cYTC78xcfYgP0nY7CJ2Ni06nGkq1gLryg07Ze z/b95JIADM/ZXpIiSTBZ2MGTnbgvnRNozEso+B+2nN1fKwmuBD/6ivf6cKYznWnwq9Y3VXBA YesbqJSlGIBBZq6NY1VqAupKVjUCIxjbqHL09q5Ohjg0OGCsIcbFCN2XIonK9MMBXER2dQcq yuU3hpe90gmEcGqmL3AAApSU4lE01xEyI5YR17la4wQQ65m30347345f7l+N1Lwgh1hfFLRo cCCzJ4/2ZUMMGzAYk0BJpqF8Kyq3PazsFS8AoawpPBbNk4n2OKmq0II2OjBkTpshyrbqeBlJ tgU2TvzVBwaON0MqEiE6kG1i6xsWAWV14AA3jngokcmst6RxDPiFf4BYZlVfDrYayQBNU2QK gvPIFBdA4yiBnfEIvMiutus635MJR5XqGudYK21kzCkEGPWVk6Hj2gb41c7JwBbkQ98iuCOJ jdSXjqG890NlKMQuBbTkjWec8Vp4MIu8sKgF8GzTjPA6wQBShayBK/1ZrXQMryQ26ZPgh16E yFVA3b4chw4I9BDnBo84fuMla7Jr5UJPkhELpgW9Kh+cJ73PWo1UdreHBDXti4fyPQfLBtxb n4a88RYOwNS6bwksI1vJB/kIxMJHAVfeworgIT0WKML5bGvOd1TZ4qHXNPMBqh50Bq/Tru/x O4me802VDLHjWdS+lAsJwAVCMBCPyMP/i+DbpgkOZFmcaYhg7EdtjijgQyCyF4Ksyh+FoawE z7HIaExPDCGCqq9wZeyCAwzea6+9egPKWgZOU5QqcKBIghrRJ0PS37yxy3hagVEmgEQpZHGu SbsyFeOrc+nt+90XIYDRVk5EysbWEiWq5SZZn3GuRgyqggaAnDW/yGiUFxEjp/zWhgBE1RBZ G1C1E6H7VR6LzAUueFRLqIxLVWTIAlIZaH0dKwLsAUSkL3RFX/NmxXkkm3A+Xsq48K9eS/b1 xTd5j/wiZNyqKy2xBbqDR3QGOA8JHgVcNeDzOVUsGZE5UnzJeh66mBfHsDnjcT+2Zaov01G+ a6cB8lppmY+MSFuRLd2przvmINntriAVnjaT0mdOLWMSFAmGBKO+O+tZz7oqHqxFsI3DrwSw Tf0h9lCDAZ+rTulrG8ikv9ZacXr4HPmp9IQ4JvbUkvcnxM5VdMiZbrte4Klv7Xs79ClvFIQB 7Dr4x9ay216Sne1ZRS/ollS0ROdhhjHRP9M/Q3aZFRwYW6Y3OWWyFgjBAYmENsNDcs+UHX6Y GjFO/sKbO7PmzVRODSJiFyoQ+OCFU7C86gydzzQLngtIh7wPYxaRRxtEGav+CZzcy7j0YZFX rW8ULRwciGiAbd62h4AjZxIywAgW2NbMCsDlDY6yW1nzkDeTIUpdS4OED4QZPCDgLCmfdmVO smb/a59g8j1FzjoH0ZoyYCI1Rkw4+Z2xUx7G53oRJiOui8s4nvW8njdjahdZyvD1oc79UyCB RJ0P5CzXWq9ByauSiaaNpzozBid7zrypSJ9BK5kJmmQyAh8GqmwLmCg0XjAWPPaZ0dXXNSvB cWRDVhxrk2Fmnlt7DLxG6IJJBku38mKlecS5AXt91w/6UoHdGGsW6H5DA48QOc1aD0Kvs25l kZd14WcN+ASDedW1oJV8sr6BrtIVn8kZcMk+/aYdwJi+eSkOp5egQ5XNlAon4TuBHB1zLX5p rwYTbHit4MA1ZDRkQe2iRD9rUoD0ueq3ftMPwQEbJRdjbPFg3nsuJBtsRBuRHd2O8xMM+D1j FoRVBw9rMm2qTxxz3sGgf+zC/3Q8VaUQva6vNQ8JlGPn7gePtMkpaodO1OBJQC4QEFg6j0Ot T3VwUKYacq7pmWTH+KTPi1RB6dasaQUV2FSfFq2qCqAq/iUhU3mAM3mfAhvg2FOhJPe8TIlu yPSDbXwFDMgTdPRBUExPOHw+BM9cq212hRepaMJ8wV1dA7QItRiJ2JhqU+7h3vxr+5bjLREc IKU8CqlqAEwBbLJvWeaee+7ZKzFHRkCUmPLIXAUR5uhzPeENee81cFIdYDyEo/TOoXAWBMvB aIcz0K4gRFla+TRlQX31vXPM6yTQADwExLCNRanpDGc4Q+9EOUbfiTr9VfnQDqeax/CMl+GL /hKlziNKwHj22Wef/tXW7m89RhxJ1jfoU94tnikCPBXQUFQ8AZ6icgR4KCAjAP5ARX9TnTGe 8F7gpp1a6gOO+IrHIn8OPnNqHA0e53q8wBeVGbLWFj4bi76bz+Pk1wJk/eLU8FCgpG3joS/t y004u0XK/oxee6Y8zBHihacLBLbu6+103pyW6pX2ZdtDqkB4Rt76LavBh0zXaIuDVznA4xpI r0UAmtzoJoDLkxw+542cHLx70QvVHmOjx4JXPMM7jkwwbNpABUC/yBNQkwvZqehpF08EThwO 2eGX8+h6HpP111vujMd1fm8fIWQL5D2rvLxeAsbGYs2LqRbz19FFgR39ziu5lcp33333vv/O 4QjoasZLV+HBkBfFpaJEn7WBr5Gt4Md3AgT9se5JRSAyliT4ndwFoviVqVNOnny0TW6OVCkE k3DSK96dg/+xWQEiOxdMsBGOP5U8eoL37uUa1+qbaTmkqmeNAT64X7AsWAKHTCFp12/sK8HN PJIk4RG7MeVkXJkK4Ni9YZc91fsNIVUAiyTZF1xRifHZvTLlBdPwGGaSb6YOXEsHUgFl3/EZ iMzgKX7wWfiqosQGtNH6kLwxFEYEUwUg+lIXSa5F1hvgq+l0a7pcmyckBIenOc1p+nvqE17R +fq2zy0VHCDKSaGBVo3wADIHY/B5OxiD8Z0Iz19gJtJ1cMxZ+LQWieBcS4Dujak+O2LwIkv9 0S6DqtEq5fQ9x8ogtEPgNYJzLQMGLubrInzA4LPrXZMoj8K5JouPzCcOfXQQ0AsA8BAPtK2d 2mfggFfarmDsvu6lHO8a/2cBqHbx3nfGaP5TZaJezwn5zT3bfRUYY/jCENu5TPd2X9cCxFqO FJhYwGM87iGAS6VhNRLY5b3ogMz/xtJm26pDpoMWffkI4MSDvDoaP4G1+2axmnuTcT4PKenp Ix5H9sacqo5sLbqJT0MNnb1wamSDt5yjz9qpq5zptnbxuq4fEYRxCr7Hc+PSr8jedwJe52QF ud9Tahfk0Wf3r2tF2G8WAhoznW0fy6QHgqoduQ+J8ZCH+7p/xoWsgdBP6zAERqqGPtO3BKPG oL+z8GAewRfX4n97Hbv0mzbZA72pa6dgiXsKpttyP74bi2sq7sEaehQeV7nhte/Zo/vAIvYh I87r7t3HZ9dWm8Yv/aSD7EA7bTWP7PDNtYs4JXjrmtiNMefxQ3rgu3y/iF7Qo8jS2Om+z2SR aQnnaFcy1q6hohvuy57gMUypQaHfXSvBg2/VBuBFdKZin+9jG/jo/6GvPtYH7eGTo/oJmEE+ ZOYcY1zk7ZabMjgYaaSdRQxb1iOzGmmkkUYaaeNpDA5G2tQkU1CaVZ403VOffBlppJFGGmlj aAwORtr0pDyojKpEuugz2CONNNJIIy1OY3Aw0kgjjTTSSCOtoP8HTPHI+XZ4xuEAAAAASUVO RK5CYII= --B_3481552151_63852-- From nobody Mon Apr 28 18:01:01 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164A31A885B for ; Mon, 28 Apr 2014 18:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRg-3cACgCOV for ; Mon, 28 Apr 2014 18:00:57 -0700 (PDT) Received: from nm23-vm6.bullet.mail.gq1.yahoo.com (nm23-vm6.bullet.mail.gq1.yahoo.com [98.136.217.85]) by ietfa.amsl.com (Postfix) with ESMTP id BB7C41A7031 for ; Mon, 28 Apr 2014 18:00:57 -0700 (PDT) Received: from [98.137.12.188] by nm23.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 01:00:57 -0000 Received: from [98.136.164.69] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 01:00:57 -0000 Received: from [127.0.0.1] by smtp231.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 01:00:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398733257; bh=Fi/QZSyarjMJDaP11UqQHW09ZYiqlBDgg+8DVh4qMVE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=IaGYqsXt/Su2CPF8d/O7asOrWDFyXnLT/YuxQ2cZi43QSJcpUIU5hJx8U5r0gdPJRAMp6xUyWTktelD+QUwxK/sSlAI+Lm7x3bFgzb8Yb8XH/N+uhgN95YP9kVn9PZE/f/YQ7s4aYpTpqQhJPr3MJOlh2BQV0r8hNRcT+LYfGMU= X-Yahoo-Newman-Id: 70873.25866.bm@smtp231.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zQw14BoVM1kjL6iVwIG1OKqZTSLVDqS0w48mXz7vLDhDa_5 v5xuD466yzzRbjV5u.OJNre0Ps79kDO1rovK7LpWuwOnlBwQ51TQqHO59OoO SGj_mNK.Ww3Hk.wxJaNx7HmwwZmLhY__Jx91Y1h1uoP3h708bWsENaoTPz4v biMcW2f9KHwwsIVKES4hhuAVVlmCyavXV6lgFSoWd1cTkrwxJI6HO0ZWv58v 2cCU4SaLVqvxnBcswtPMCenZQdKvArWuSgQsSR0BQ2P7uEfjxsxVJEb77rSa gXYynStJe7He49nk3as2Hfd.i.rWgY3HLfl3iDYJdbrHrsUYcblmCWcPn6m0 gJfpi5GhCblgoH1EXJghe0zqKKnaUweh.Wo.aG0otIuPcG_dZQ2wCFdkmBVO yfDscPbt9l1z3EiVooawMwxTTssBmz.iKsJnfZhYJRyShKw8e7v3IYdM67Fz .eWABM8SufMOVWKB9sritcNyRdCszzt5ZxBw65vclEh0hUr3et.LFwrE3OE1 WXzFSCltTtut8svS.bRI5eYiAVPh.3no- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.19] (nitin_bahadur@24.4.100.156 with plain [98.139.211.125]) by smtp231.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 01:00:57 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 18:00:49 -0700 From: Nitin Bahadur To: Susan Hares , 'Mach Chen' , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <000001cf5bc9$51f0bf80$f5d23e80$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eRIpZwXalyBxjf56U8X6oQD-xTE Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 01:00:59 -0000 Hi Sue, > >I've been digging into the RBNF forms in Section 6 >draft-ietf-i2rs-rib-info-model-02 based on what you indicated to mach. I >would like to confirm I understand your intent of the RBNF. > >1) match will augment its sequence with a type > ::=3D | | | | > > >Will be redefined as: > ::=3D [ | | | >mac-route> | ] >This sequence occurs wit: 1 route-type, 1 following definition. > >Route-type::=3D | | | | >(these are the values) > >Do I understand your values? Correct. > >2) Let's take one example of your IPv4 > > ::=3D [ | > >| >::=3D > ::=3D > >Are you intending to allow: destination-ipv4-address or >source-ipv4-address >or the combination of ? >If >so, do you want a tag to identify the type of form it is? > > ::=3D [ | > | ] >::=3D| | | < Yes, I am intending to allow all 3 possibilities. A tag is needed. ::=3D | | (this will apply to IPv4 and IPv6) > > >3) Let's take the use case of matching a destination-ipv4-address: > > ::=3D > >I doubt you really wanted the redundant tag. This will occur for IPv6 as >well. > >If you use a tag form that has ip-form >:: > > >4) Would a corrections to the above be useful: >Given the above you could simplify your match RBNF: > >:: =3D [ipv4-route | ipv6-route | mpls-route | >mac-route] The is not needed for mpls and mac routes=8A.since MPLS has no concept of SRC or DEST. So that simplification will actually not help :( The will need to be associated specifically with and . >ipv4-route ::=3D [ipv4-prefix] | [ipv4-prefix][ipv4-prefix] >ipv6-route ::=3D [ipv6-prefix] | [ipv6-prefix][ipv6-prefix] >mpls-route::=3D [mpls-label] | [mpls-label][mpls-label] >mac-route::=3D [MAC_ADDRESS] | [MAC_ADDRESS][MAC_ADDRESS] > >These basic variables are defined in YANG Data Models and FORCES data >models. You do not need to go further with the simple definitions. > >5) Why did you specify differently? > >multicast-source-ipv4-address ::=3D >multicast-source-ipv6-address ::=3D > >Where you trying to express some checking that the node should have on >these >address?=20 Thanks for catching this. They have no reference in the -02 version. They are a remnant of -00 of the draft. After the grammar was modified in -01, they should have been deleted. > I've got similar questions on , >and . I will start a different mail thread for these. Looking forward=8A Thanks Nitin From nobody Mon Apr 28 18:20:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FBC1A8874 for ; Mon, 28 Apr 2014 18:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL5qAhtplx-s for ; Mon, 28 Apr 2014 18:20:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EB0941A8869 for ; Mon, 28 Apr 2014 18:20:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Mach Chen'" , References: <000001cf5bc9$51f0bf80$f5d23e80$@ndzh.com> In-Reply-To: Date: Mon, 28 Apr 2014 21:19:55 -0400 Message-ID: <005201cf6349$21d7b1a0$658714e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGspTEYodJ472J0ChYpflFrjNdqlZttRPuw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/w7yWjiQaez3fAOBtrlRj4O-p8vU Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 01:20:12 -0000 Nitin: Thanks for the quick response. Just one thing to consider:=20 >4) Would a corrections to the above be useful: >Given the above you could simplify your match RBNF: > >:: =3D [ipv4-route | ipv6-route | = mpls-route=20 >| mac-route] [Nitin] The is not needed for mpls and mac routes=A9.since = MPLS has no concept of SRC or DEST. So that simplification will actually not help = :( [Sue]: Yes, not all forms would benefit. However, MPLS does have the = stack tags that we may want to save and match on. Also: the 5-tuples may be a part of matching some routes. By using rt-form, we are using the TLV = format to set-up these multiple formats. Each format, would have the = appropriate expectations for the appropriate address families.=20 [Sue]: I think it provides table based code.=20 The will need to be associated specifically with and . [Sue]: yes, it could. With the rt-form and the rib-family type, perhaps = we can remove the rt-type.=20 [snip]=20 >5) Why did you specify differently? > >multicast-source-ipv4-address ::=3D =20 >multicast-source-ipv6-address ::=3D > >Where you trying to express some checking that the node should have on=20 >these address? Thanks for catching this. They have no reference in the -02 version. = They are a remnant of -00 of the draft. After the grammar was modified in = -01, they should have been deleted. Here's the next question - how were you planning to handle the multiple next-hops for the multicast. Did you have a plan?=20 You will have both ECMP (unicast) multiple nexthops, and multicast replication next hops. A flag might do nicely to differentiate. We could put this on the next hop. Thanks for your review=20 Sue=20 From nobody Mon Apr 28 22:47:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703FF1A8864 for ; Mon, 28 Apr 2014 22:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQOR5b1IamKf for ; Mon, 28 Apr 2014 22:47:02 -0700 (PDT) Received: from nm7-vm2.bullet.mail.gq1.yahoo.com (nm7-vm2.bullet.mail.gq1.yahoo.com [98.136.218.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0555F1A885E for ; Mon, 28 Apr 2014 22:47:01 -0700 (PDT) Received: from [216.39.60.180] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:47:01 -0000 Received: from [208.71.42.206] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:47:00 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:47:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398750420; bh=zEc+uExs4a51YkBMukxTsmoB22g34+tgRzr+g+Ns4jI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=ce4PGbVHKbAo9Zu7xwrz/4UvL9ASniuojX4zdzwDe8Hi30/G6UvCZYZMCFVpcjQGBca/el/gNsCBIS8gu6KfqP8G4EILzJQI8KiV/oh/zXceNBrZLGSO/vwvlHSfRldmXl3YKv+2dEa3F5v0Njo7L1kQXxJctlZO/oGx/lmleSM= X-Yahoo-Newman-Id: 969519.79797.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GQO__H4VM1kXDieJh4PqV8bRHvhTvSK7TtgN1CO0E58l95f WVR6Yil2rYVcRdjqt4HJBzv3nfOQeM4DMRBl_5dwwddC8QgA8vJ9hOewagv4 PhEfoOKARGahEJFHOKhzfdNT_SWAO.GyDcWd4ZT.CBALAbC_8E5_dtI8FlSn lUwOPa7mGSh5NYBvn1GS9wmanZT8qtpjlgce3mdJe6dbMLStkpFlQMWmkxVb 8LmEDHCEYDFHuAowyWaQZUWmu8uYUqioyATRabyy3aonO7maeCCmwm7hliDP lEmmrygbo.U2NkQ2xIFg.LkIBLUgUv1rCW_F0007aZkoXzrTR0WX_DdBQhKG svaAmPWW2fu3C466d09oLjFP0XCm7o9nux_QvQod7B6kQcVWfZUZqalCRsmh Q4NFdUXc9.eSRYlIkXIMMuZ.d9F9rxFEXfg6PV6SxIgxzV5gx7hCCqSxjhcU EhhjecrD0ir95C.zinyfiSdSCMDEPM3IzIz4Lja47bXfrXrbgvUgVHIAnina FYCA5zu2XaVPwLcWglzClapQxDK1OiLbY X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.21] (nitin_bahadur@24.4.100.156 with plain [98.138.105.21]) by smtp217.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 05:47:00 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 22:46:54 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] draft-ietf-i2rs-rib-info-model-02 draft - rib-family variable In-Reply-To: <000f01cf5bce$97da7220$c78f5660$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3481570020_190312" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xT_YFEsLpY_Smf-3AcbAp_M8Gxk Cc: Qin Wu Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 draft - rib-family variable X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 05:47:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3481570020_190312 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sue, > This question RIB Grammar section 6: > =20 > ::=3D [ =8A ][ENABLE_IP_RPF_CHECK] > ::=3D=3D | | = | > > =20 > In your grammar, my understanding of the =B3=8A=B2 is limited. I assumed this = means > that this is a sequence of routes. Yes =B3=8A=B2 means additional. > =20 > You do not provide a grammar for RIB_NAME. Are you looking for this to b= e an > ASCII String or what? The draft does not define terminal types for anything (including RIB_NAME). We had discussed that earlier with a bunch of folks and at that time the consensus was that the info-model should not be defining data-types and tha= t should be left to the data-model. The current info-model is not a compilabl= e real-grammar per-se. > =20 > You do not provide a grammar for ENABLE_IP_RPF_CHECK =AD what is your gramm= ar > type for this?=20 > =20 It=B9s a boolean. > My initial reading had been that , , and > [ENABLE_IP_RPF_CHECK] only occur once even if you have 10K routes. That is correct. Thanks Nitin --B_3481570020_190312 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Sue,

This question RIB Grammar se= ction 6:

 

<rib>::=3D<RIB_NAME> <rib-family> [<route> = … ][ENABLE_IP_RPF_CHECK]

<rib-fa= mily>::=3D=3D<IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> | <MPLS_RIB= _FAMILY> | <IEEE_MAC_RIB_FAMILY>

 

In your grammar, my understanding= of the “…” is limited.  I assumed this means that th= is is a sequence of routes.


Yes “&#= 8230;” means additional.

 

You do not = provide a grammar for RIB_NAME.  Are you looking for this to be an ASCI= I String or what?


The dr= aft does not define terminal types for anything (including RIB_NAME). We had= discussed that earlier with a bunch of folks and at that time the consensus= was that the info-model should not be defining data-types and that should b= e left to the data-model. The current info-model is not a compilable re= al-grammar per-se.

You do not provide a = grammar for ENABLE_IP_RPF_CHECK – what is your grammar type for this? =

 

<= /blockquote>

ItR= 17;s a boolean.

My initial reading had been that <RIB_NAME>, <rib-family>, a= nd [ENABLE_IP_RPF_CHECK] only occur once even if you have 10K routes. <= /o:p>


That is correct.=

Thanks
Nitin
--B_3481570020_190312-- From nobody Mon Apr 28 22:48:23 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88C11A885E for ; Mon, 28 Apr 2014 22:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKvoGFlxdSdw for ; Mon, 28 Apr 2014 22:48:18 -0700 (PDT) Received: from nm5.bullet.mail.gq1.yahoo.com (nm5.bullet.mail.gq1.yahoo.com [98.136.218.70]) by ietfa.amsl.com (Postfix) with ESMTP id D44701A8882 for ; Mon, 28 Apr 2014 22:48:18 -0700 (PDT) Received: from [216.39.60.182] by nm5.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:48:18 -0000 Received: from [98.136.164.78] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:48:18 -0000 Received: from [127.0.0.1] by smtp240.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 05:48:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398750498; bh=lOu7Hzs1BJo12r5ybSTpQ0tVYaXM4ojyrDu8lZwPslA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=6F73+u31NXaZmFLYXg5v0pyefwv+sZRX3nrK8iCWN6ZYJmPiDOsLvj4GNKIQSHJej8R4rtDZC9ZACCJByQw7KWoWwX33cQ1RDMbzVxBFycAKvD3THcWdh38EazYv4XDu6pUJdd9xl9FqDtDasrWTD42OI/W2DP9sjYfVmXnVC/k= X-Yahoo-Newman-Id: 55503.10264.bm@smtp240.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DkZdankVM1l1J91sfz7VyJ51KPIzy2cZMPB.8EiEi7L_Rci oggvIRoq12DXRCCYLsdXuxLtbTY07tyH0HE2YAEOxUFw144zosjC4t9YqRUx SSjMwZBeHh.oAiFlP6MKgs9Rw5DUoM0UxUr9XvGxRXBkpDyjsZ92REHjojLM 8ZVLQOcl7zM1fD2JQq25zLOlWGdNOyPevMWuR0GJNSc8CCKWtzmG5gfITUV8 djvxSd3FEWMv02r159QXq7u1MgkWwlAS1YrpaLPAbx.ukJ4t864TKijQNpR. qxQDqryIxkuCst09CAVx0mqUa2Ny6kqOEfPS7sjSj6j30ma7DfA3XSDRfDo0 kfDNLSPKJjjt6mOiCgDZgavrQiBvkMld3TLttxiFOIpGAyRF6f_PK9ooQj1G DJaNcoFLIZXbe.6Nk1viBuy3HvmgH59sJUhl_MW_zeH2ACV92E4lnVk8zmaD 6CPxscugoRSTlCvVGyMKAxIB3V5MwE0tWpfOwE1SPSiMB1pm8acCDlAYZ9pz ORkPW1dZqPD75InJLHIEF5akdDmiinSntWg-- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.21] (nitin_bahadur@24.4.100.156 with plain [63.250.193.228]) by smtp240.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 05:48:17 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 22:48:09 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] draft-ietf-i2rs-rib-info-model-02 In-Reply-To: <006301cf5ce5$a4e23cb0$eea6b610$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3481570097_183955" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GolhecPNCbCM_Wupkmd0HNEl3ZA Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 05:48:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3481570097_183955 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This will be removed in the next rev. Thanks NItin From: Susan Hares Date: Sunday, April 20, 2014 at 3:12 PM To: Cc: 'Jeffrey Haas' , , 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 > Nitin, Ron, Kini and Jan: > =20 > Did you replace the nexthop-address and not remove this text? > =20 > =20 > ::=3D ( ) | > ( ) | > ( ) > =20 > The paper only his this definition once? > =20 > Sue=20 > =20 > =20 >=20 > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Sunday, April 20, 2014 6:00 PM > To: i2rs@ietf.org > Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; 'Alia Atlas' > Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 > =20 > Nitin, Ron, Kini and Jan: > =20 > I forgot to ask question on the grammar: > =20 > :: =3D | | ( > [COS_VALUE] []) > =20 > Rater limited is not defined. Is there a reason why this would be in a > standard document without a definition? Did I miss something on the list= ? > =20 > Sue=20 > =20 >=20 > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Sunday, April 20, 2014 5:31 PM > To: i2rs@ietf.org > Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia Atlas > Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 > =20 > Nitin, Ron, Kini, Jan: > =20 > 1) Is Section 7 of your document normative or informative? >=20 > =20 >=20 > 2) Your grammar seems wordy/inconsistent in the repetition of the ne= xt > hop below=20 >=20 > =20 > Your RIB grammar on page 17 states: >=20 > =20 > ::=3D | > ((nexthop-list-member>) | > ( =8A | )) > =20 > ::=3D ( | > ) > =20 > [] > =20 > ::=3D ( =8A) > =20 > Questions: Why do you have nexthop-list-member listed twice? Why list > twice? Is this readability or technical matter? > =20 > Why not:=20 > ::=3D (( | (nexthop-list-member) =8A ) =8A > =20 > Why not:=20 > ::=3D ((( | ( =8A > ))[ =20 > Were you trying to name the chains? > =20 > 3) Two variables seem orphaned: >=20 > =20 >=20 > Multicast-source-ipv4-address ::=3D >=20 > Multicast-source-ipv6-address ::=3D >=20 > =20 > Did I miss someplace where they attached to the normative sectio= n 6. > You indicated the PIM paths can be chains (section 7.3), but y= ou do > not give the normative section. > =20 > Sue Hares=20 > =20 > _______________________________________________ i2rs mailing list > i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --B_3481570097_183955 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

This will be r= emoved in the next rev.

Thanks
NItin

From: Susan Hares <shares@ndzh.com>
Date: Sunday, April 20, 2014 at 3:12 PM
To: <i2rs@ietf.= org>
Cc: 'Jeffrey Haas' <= ;jhaas@pfrc.org>, <adrian@olddog.co.uk>, 'Alia Atlas' <akatlas@juniper.net>
Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02=

Nitin, Ron, Kini and Jan:

 

Did you replace the nexthop-address and not remove t= his text?

 

 

   <nexthop-address> ::=3D (<IPv4> <ipv4-add= ress>) |

           &n= bsp;            = (<IPV6> <ipv6-address>) |

       = ;            &nb= sp;     (<IEEE_MAC> <IEEE_MAC_ADDRESS>)=

 = ;

The paper= only his this definition once?

 

<= span style=3D"color:#1F497D">Sue

 

<= span style=3D"color:#1F497D"> 

i2rs [mailto:i2rs-bounces@ietf= .org] On Behalf Of Susan Hares
Sent: Sunday, April 20, = 2014 6:00 PM
To: i2rs@ietf.org<= br>Cc: 'Jeffrey Haas'; adrian@ol= ddog.co.uk; 'Alia Atlas'
Subject: Re: [i2rs] draft-ietf-i2rs-r= ib-info-model-02

=  

Nitin, Ron,= Kini and Jan:

 

I forgot to ask question on the grammar:

 

<special-nexthop> :: =3D = <DISCARD> | <DISCARD_WITH_ERROR> | (<RECEIVE> [COS_VALUE] = [<rate-limiter>])

 

Rater limited is not defined.  Is there a reason wh= y this would be in a standard document without a definition?  Did I mis= s something on the list?

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Sunday, April 20, 2014 5:= 31 PM
To: i2rs@ietf.org
C= c: 'Jeffrey Haas'; adrian@olddog.co= .uk; Alia Atlas
Subject: [i2rs] draft-ietf-i2rs-rib-info-model= -02

 <= /p>

Nitin, Ron, Kini, Jan:

 

1)      Is Section = 7 of your document normative or informative?

 

2)      Your g= rammar seems wordy/inconsistent in the repetition of the next hop below

 

Your RIB grammar on page 17 states:

 

<nexthop-list> ::=3D <spec= ial-nexthop> |

   &nbs= p;            &n= bsp;            =    ((nexthop-list-member>) |

           &nb= sp;            &= nbsp;        (<nexthop-list-membe= r> … | <nexthop-list>))

 

<nexthop-list-member> ::=3D (<= ;nexthop-chain> |

   &= nbsp;            = ;            &nb= sp;            &= nbsp;         <nexthop-chain= -identifier>)

    =             &nbs= p;            &n= bsp;            =         [<nexthop-list-member-attribut= es>]

 

<nexthop-chain>::=3D (<nexthop> …)

<= p class=3D"MsoNormal"> 

Questions: Why= do you have nexthop-list-member listed twice?  Why list <nexthop-li= st> twice? Is this readability or technical matter?

 

Why not:

<nexthop-list>::=3D ((<special-nexthop> = | (nexthop-list-member) … ) …

 

Why not:

<nexthop-list-member> ::=3D (((<nexthop-chain-identifier= > | (<nexthops> … ))[<nexthop-list-member-attributes]) )&#= 8230;

 

Were you trying to name the chains?

 

3)      Two variables = seem orphaned:

 <= /p>

Multicast-source-ipv4-address ::=3D <IPv4_AD= DRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D <IPv6_ADDRESS> <IPv6_PREFIX_LE= NGTH>

 

         Did I miss s= omeplace where they attached to the normative section 6.

          = ; You indicated the PIM paths can be chains (section 7.3), but you do n= ot give the normative section.

&nbs= p;

Sue Hares

 

__________________________________= _____________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/m= ailman/listinfo/i2rs
--B_3481570097_183955-- From nobody Mon Apr 28 23:36:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3891A8884 for ; Mon, 28 Apr 2014 23:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi4phFsL0phG for ; Mon, 28 Apr 2014 23:36:51 -0700 (PDT) Received: from nm15-vm6.bullet.mail.gq1.yahoo.com (nm15-vm6.bullet.mail.gq1.yahoo.com [98.137.176.78]) by ietfa.amsl.com (Postfix) with ESMTP id BB7EE1A8836 for ; Mon, 28 Apr 2014 23:36:51 -0700 (PDT) Received: from [98.137.12.59] by nm15.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 06:36:50 -0000 Received: from [208.71.42.212] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 06:36:50 -0000 Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 06:36:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398753410; bh=PvlggFLL2+npdLqjXfQA1282J2A0HV4ONNeskn2w2wg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=twTZLp9yG9ZnDYMjvMu/jjFValA3XU7zJOf7D0H0oV0gRA0KfCYT1WdEZzvmOIi7G7lJS5YRSu64gO79yKfu+qwOq7BMcAtjVJf9PUhrJ09F/TkhhY/ue/IotpleP8Qfq2lWZyV518We5bkFvzQZ6+L+wLQ2XQU/YzhAv7BaZ50= X-Yahoo-Newman-Id: 797644.78056.bm@smtp223.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jCTpy28VM1l2IMUsBU4NZdeMtb.imLqXGwH8U4LNYNlnvfC sp70W0OjXpLW2AGKXvXG_6LOsRKWDGmIz.c8oDHPAKyc.2KQ8sHJJmgsppD. uWvyD96iXq6AnB0khft9.Y77RFaug29WnvyTKl79EjbmSCEAurE1G6upGXio qaHN5mCwGvMZeqaNPwweQz5LddYFSaFQ1BOUfMVUwYY3DMHxBSo9nHZjAH9e FpE2FN.qawPNUqyriOvX6UYd34dylw4kSJkQGz_.kC3DVoFAYMOyVKfJkT1N NeIH.6qcx4hy2IqjSNGn_3PZdrxwDmiDnngpZkkNt8hG7t5pbOWBNI4svNSL tTpIqO5FY6AQMUEx_jzb2xkaN3EOpTj2.HfKa3hIHp8JeS.xOxLNP00tscOD 1YTf3SjMGMMMgq8SxAqcWtZbYQUJsG.dUo.Rk.TuOm2YaUIi.ISEaTFQVNiT Be_zHOWsWcqE7QU0Vvud.7KVUeUofwNeGfxKL8oT2_n4Th0SNcXNQ5SY9rOu Pjx8QGf7_ukcJA1Ah.TBWtMvjVLjJXrwU X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [192.168.0.21] (nitin_bahadur@24.4.100.156 with plain [98.138.105.21]) by smtp223.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 06:36:50 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Mon, 28 Apr 2014 23:36:43 -0700 From: Nitin Bahadur To: Susan Hares , 'Mach Chen' , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <005201cf6349$21d7b1a0$658714e0$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/S6UG7t5QLJO30WkpaWIUx4VuJ2c Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 06:36:53 -0000 Hi Sue, > > > >>4) Would a corrections to the above be useful: >>Given the above you could simplify your match RBNF: >> >>:: =3D [ipv4-route | ipv6-route | mpls-route >>| mac-route] > >[Nitin] The is not needed for mpls and mac routes=A9.since MPLS >has >no concept of SRC or DEST. So that simplification will actually not help >:( > >[Sue]: Yes, not all forms would benefit. However, MPLS does have the >stack >tags that we may want to save and match on. Also: the 5-tuples may be a >part of matching some routes. By using rt-form, we are using the TLV >format >to set-up these multiple formats. Each format, would have the appropriate >expectations for the appropriate address families. > >[Sue]: I think it provides table based code. The main issue is that the grammar will not be deterministic. In other words, one needs a way to specify that is valid and is NOT valid. > >The will need to be associated specifically with > and . > >[Sue]: yes, it could. With the rt-form and the rib-family type, perhaps >we >can remove the rt-type. >[snip]=20 Rib-family-type and route-type are kind of the same thing. I need to think if there is a case where they can be different... > >>5) Why did you specify differently? >> >>multicast-source-ipv4-address ::=3D >>multicast-source-ipv6-address ::=3D >> >>Where you trying to express some checking that the node should have on >>these address? > >Thanks for catching this. They have no reference in the -02 version. They >are a remnant of -00 of the draft. After the grammar was modified in -01, >they should have been deleted. > >Here's the next question - how were you planning to handle the multiple >next-hops for the multicast. Did you have a plan? >=20 >You will have both ECMP (unicast) multiple nexthops, Unicast multiple next hops are covered in Section 7.2.3. > and multicast replication next hops. Section 7.3 talks about multicast replication (and refers to Section 7.2.2). > A flag might do nicely to differentiate. >We could put this on the next hop. LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to indicate ECMP/load-balancing. Thanks Nitin From nobody Tue Apr 29 03:15:23 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73A51A0753 for ; Tue, 29 Apr 2014 03:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-yImsLIwBDB for ; Tue, 29 Apr 2014 03:15:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D21A014C for ; Tue, 29 Apr 2014 03:15:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Mach Chen'" , References: <005201cf6349$21d7b1a0$658714e0$@ndzh.com> In-Reply-To: Date: Tue, 29 Apr 2014 06:14:53 -0400 Message-ID: <00b501cf6393$dda76070$98f62150$@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: AQD7MnlZh5dWEJhlAdE4T282rDtaO5zQua0Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/N0WhwJjiLv5GVICqBYfrQmdeHPg Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 10:15:18 -0000 Nitin: Thanks for responding [snip] > >[Sue]: Yes, not all forms would benefit. However, MPLS does have the >stack tags that we may want to save and match on. Also: the 5-tuples >may be a part of matching some routes. By using rt-form, we are using >the TLV format to set-up these multiple formats. Each format, would >have the appropriate expectations for the appropriate address families. > >[Sue]: I think it provides table based code. [Nitin] The main issue is that the grammar will not be deterministic. [Nitin] In other words, one needs a way to specify that is valid and is NOT valid. [Sue-2 on] Why is the grammar not explicit? Let's put the type back in for each (addresses are just a specific type of prefix) (addresses are just a specific type of prefix) This is TLV where (form-type) implies a specific length (in example, 8,8, 16). If you want to go with the traditional TLV form, consider the (form-type) as a Type field, And put in a length field. The same is true of the nh-form and nh-type fields > - this is the only valid (note address is just a specific type of prefix) (note that prefix is just a specific type of prefix) I did change these directly to TLV forms - so there would be a stepping stone to the > >The will need to be associated specifically with > and . > >[Sue]: yes, it could. With the rt-form and the rib-family type, >perhaps we can remove the rt-type. >[snip] Rib-family-type and route-type are kind of the same thing. I need to think if there is a case where they can be different... [Sue-2-off] [snip] >>5) Why did you specify differently? [Nitin]:: Unicast multiple next hops are covered in Section 7.2.3. [Nitin] LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to indicate ECMP/load-balancing > and multicast replication next hops. [Nintin] Section 7.3 talks about multicast replication (and refers to Section 7.2.2). [Sue]: You are stating that: ::= ( ) [( )... ] Is the flag for NH ECMP ::= ( ) [( )... ] Sets primary/backup, and mixed with LOAD_BALANCE_WEIGHT - you groupings of next-hops that are used for multicast (as default). ::= [ ... ] This makes it specific, but requires you specify the LOAD_BALANCE_WEIGHT with each next hoip. Were you intended your LOAD_BALANCE_WEIGHT to be a integer, and the LOAD_PROTECTION_PREFERENCE to be a number. Thanks Nitin From nobody Tue Apr 29 06:48:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC571A08FE for ; Tue, 29 Apr 2014 06:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSf5iAz-0U7O for ; Tue, 29 Apr 2014 06:48:21 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id EFEA91A08F9 for ; Tue, 29 Apr 2014 06:48:20 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id lf12so297726vcb.13 for ; Tue, 29 Apr 2014 06:48:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b6f1gpD5q0mZaplkIbZLn29S3Mu+AmXUbLTaZLzBgy8=; b=E/fyWRNONAgi34v5WjSdzhtx8J/KuARP7MpxxLHB3TFIOJh6GliMXt/BTijAUiGK8z 6OKkyDGP9350bu3aP7eB0SR7zcNTE3TlYiRCMvMVXIQGGvcUq53F+4k/3Zgy0vS2em75 2WJUkiQVSObx0jb5FVwwOLa9W/8Ri7wLizlwZoiY2Nm1pHEA/N0c/EG9y+zluUJKm+HY JZZPYJvk3zjOACLcHzKSc2mwAP4WNqpCcjgydMk7ZNTy0Trcb7Qvuj/A5IKF1SgMPn3s mX7qJGA07O8RXmA0QV+W+fHq+QW3TY3Wc/LGxOi+ppCq+4pIyFYZc49vrcZChZWKkvLt jNzA== X-Gm-Message-State: ALoCoQmOavqCmszp9oeV1gc1gB91CO7D9vWrRWUvHoh7p9fdG8os8vFPUba5yZzCShIydTEWcGPw X-Received: by 10.52.126.107 with SMTP id mx11mr807899vdb.41.1398779299504; Tue, 29 Apr 2014 06:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 29 Apr 2014 06:47:59 -0700 (PDT) In-Reply-To: <55AA400B-3D5A-4980-8330-3541A1663586@juniper.net> References: <535916F0.3050206@joelhalpern.com> <55AA400B-3D5A-4980-8330-3541A1663586@juniper.net> From: Jamal Hadi Salim Date: Tue, 29 Apr 2014 09:47:59 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FK-0A5gr-PD1flyYlAd_eEw3Iys Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 13:48:23 -0000 Dean, In your slides, IIRC, at the meeting you illustrated several daemons all interacting with the agent doing different things. In our case it will very likely be multiple daemons doing different things for the agent (and sometimes remote machines). In any case, this may end up being an implementation issue. I have another issue I will post probably under a separate topic: Prioritization. cheers, jamal On Mon, Apr 28, 2014 at 4:23 PM, Dean Bogdanovic wrote: > Jamal, > > There is only one agent to one daemon. There is no scenario of one agent to multiple daemons. > > There are multiple clients to one agent. > > So agent is depending on the speed of daemon and agent should protect overloading daemon with requests, so it can police requests from clients. > > Dean > > > On Apr 24, 2014, at 9:56 PM, Jamal Hadi Salim wrote: > >> I was mostly referring to overload conditions (of both compute and >> wire resources). >> It is feasible for a client not to be able to keep up (eg a table dump >> response; i.e a single >> request resulting in a large fast bulk response). However, >> the more interesting case is for a daemon overload as a result of some >> client transaction; >> assuming possibly N daemons talk to an agent on the south bound >> multiplexing to M clients >> on the northbound, where M>>N - and how to deal with the client(s) >> that are responsible for the >> overload without adversely affecting the other clients that dont >> contribute to overload. >> Some of this could be implementation issues. >> >> I think l misunderstood what you and Andy were saying to imply you >> meant M equals N equals 1. >> >> cheers, >> jamal >> >> >> On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic wrote: >>> >>> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wrote: >>> >>>> I was more looking at the agent - it brokers between clients and the >>>> RIB subsystem >>>> as shown in figure 1 of the architecture doc. Different clients bring >>>> different latencies/capacities. >>>> Congestions will kick in, >>> how does client latency influence agent? The agent sees request coming in from different authorized clients at a rate and it is processing those requests. The agent will depend on the daemon performance, but not on client. >>> >>>> reliability requirements will need to be >>>> considered. And there may >>>> be need to signal these details to the clients (SIP proxying is the >>>> closest i can think of). >>>> You cant solve this problem by just inserting a reliable transport >>>> where the i2rs protocol >>>> runs. >>>> >>>> cheers, >>>> jamal >>>> >>>> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wrote: >>>>> No, there is no requirement that the client is a broker. He may be, or he >>>>> may not. And the scope of his brokering, if he is a broker, may be >>>>> application specific or more general. >>>>> >>>>> We have placed requirements to be able to provide traceability when the >>>>> client is brokering. This is as much because even a non-broker may be >>>>> acting on behalf of several different applications. >>>>> >>>>> As far as I can tell, the fact that a client may itneract with multiple >>>>> agents does not in itself palce new protocol or model requirements on the >>>>> system. If we wanted inter-agent atomicity, then there would be >>>>> requirements. But we explicitly decided that was out of scope. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> >>>>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>>>> >>>>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>>>>> across N locked I2RS agents? >>>>>>> >>>>>> >>>>>> There is a requirement to allow only one client to own write access to >>>>>> a specified object in order to avoid locking. There is nothing objecting >>>>>> to a client being able to write to multiple objects as long as that rule >>>>>> is met. >>>>>> >>>>>>> The agents do not coordinate with each other. >>>>>>> The clients do not coordinate with each other. >>>>>>> >>>>>>> This is currently out of scope for the I2RS protocol. >>>>>>> >>>>>> >>>>>> Both assertions true. >>>>>> But what i was responding to is: >>>>>> There are multiple clients that connect to the same agent. >>>>>> And a client can connect to multiple agents. >>>>>> >>>>>> I believe that such a requirement _may_ call out certain features in >>>>>> the protocol. Essentially the agent is a broker. >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>>>> cheers, >>>>>>>> jamal >>>>>>> >>>>>>> >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: Jamal Hadi Salim >>>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>>>> To: Dean Bogdanovic >>>>>>>> Cc: Andy Bierman , "" >>>>>>>> , Martin Bjorklund , "" >>>>>>>> , "" >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman wrote: >>>>>>>>> >>>>>>>> >>>>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>>>>> >>>>>>>> >>>>>>>> Dont think so. >>>>>>>> >>>>>>>>> Network locking across devices is out of scope. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have same opinion as you on this one, just wanted to spell it out one >>>>>>>>> more >>>>>>>>> time explicitly, as I heard some discussions where network locking was >>>>>>>>> coming up. >>>>>>>>> >>>>>>>> >>>>>>>> Either I am misunderstanding both of you or both of you misunderstood >>>>>>>> the >>>>>>>> requirement. >>>>>>>> The idea is to allow a single writer per object as a starting point. >>>>>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>>>> >>>>>>>> cheers, >>>>>>>> jamal >>>>>>>> >>>>>>>> PS:- Changing the topic so this is not lost in the noise because i think >>>>>>>> that >>>>>>>> the many clients-single agent brings needs for other protocol >>>>>>>> requirements. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Tue Apr 29 07:19:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FFC1A08D3 for ; Tue, 29 Apr 2014 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opu27hpfWxFn for ; Tue, 29 Apr 2014 07:19:35 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id B16141A08D5 for ; Tue, 29 Apr 2014 07:19:35 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so346290vcb.24 for ; Tue, 29 Apr 2014 07:19:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=dT85Ex1GPPZm710G1XrhLGfXDQEIg7DSH0sr4U7HmrY=; b=HI0NSvx6qoOlV7imm+FeJus2ERcxnzb7X2Mvf7Tg5aqPL1b/t4m5OkB0fJ5SVEg8Ca NifDjYkECIYQaK9/9hTvZyKwH4kTlmQGw8QU25TlMU8+ZVkvbafPAsG/zUTiU5uh0Fcj ijTrr2y+cE1Hi5xM5DsTXeKpcPXOR5NVBzaBiMg7TXEKuVoMNj/fogvgafpwryoRs2bR CL7QWQSTqLxs/dlnYYvdqDeDIhfS5WYVsxB9gHtiLa5M7b+wTgFlSCxHH4KEh5MfgcA8 DYGmhNNQ3YPwvlVRRrWn25L7y2yH4EOqnDYz0sJOPncohuIMBNw0j2j7jUfoEjyNvnZW 0MSw== X-Gm-Message-State: ALoCoQljOT1uia3GC2rlFtE6itE4vZf2ywFuG9EQT/yZ/8DoUlvC/vehk4vygDm45/v8GADvGc9m X-Received: by 10.220.103.141 with SMTP id k13mr9022106vco.25.1398781174434; Tue, 29 Apr 2014 07:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 29 Apr 2014 07:19:14 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 29 Apr 2014 10:19:14 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tvF0czAkxKjIKrDJvebfP1ijRq4 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: [i2rs] Clients-Agents protocol prioritization X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:19:36 -0000 This is back again with node overload. Our experience with ForCES made us prioritize events and request-response differently. This is important only when there is an overload case. As an example if i had sufficient cycles/bandwith/ram space to respond to either an ADD or an event - I choose to use those resources to process and respond to the ADD; which means events are not reliably delivered to the clients. I think something like this would be needed for I2RS. cheers, jamal From nobody Tue Apr 29 07:20:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11841A08EE for ; Tue, 29 Apr 2014 07:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSX-LcAY16xk for ; Tue, 29 Apr 2014 07:20:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2A85F1A08E3 for ; Tue, 29 Apr 2014 07:20:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 61DD52409B6; Tue, 29 Apr 2014 07:20:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4946A24005A; Tue, 29 Apr 2014 07:20:01 -0700 (PDT) Message-ID: <535FB50A.6090608@joelhalpern.com> Date: Tue, 29 Apr 2014 10:19:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nitin Bahadur , Susan Hares , 'Mach Chen' , i2rs@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/v1b0mgTd9SBGoRzn2AO8dWMBsZw Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:20:05 -0000 Remember that an information model is not a grammar. It is perfectly okay in an IM to have two branches that are just different things. Discriminators are added in when one goes from teh information model to the data model. Yours, Joel On 4/29/14, 2:36 AM, Nitin Bahadur wrote: > Hi Sue, > >> >> >> >>> 4) Would a corrections to the above be useful: >>> Given the above you could simplify your match RBNF: >>> >>> :: = [ipv4-route | ipv6-route | mpls-route >>> | mac-route] >> >> [Nitin] The is not needed for mpls and mac routes©.since MPLS >> has >> no concept of SRC or DEST. So that simplification will actually not help >> :( >> >> [Sue]: Yes, not all forms would benefit. However, MPLS does have the >> stack >> tags that we may want to save and match on. Also: the 5-tuples may be a >> part of matching some routes. By using rt-form, we are using the TLV >> format >> to set-up these multiple formats. Each format, would have the appropriate >> expectations for the appropriate address families. >> >> [Sue]: I think it provides table based code. > > The main issue is that the grammar will not be deterministic. In other > words, one needs a way to specify that is valid > and is NOT valid. > > >> >> The will need to be associated specifically with >> and . >> >> [Sue]: yes, it could. With the rt-form and the rib-family type, perhaps >> we >> can remove the rt-type. >> [snip] > > Rib-family-type and route-type are kind of the same thing. I need to think > if there is a case where they can be different... > > >> >>> 5) Why did you specify differently? >>> >>> multicast-source-ipv4-address ::= >>> multicast-source-ipv6-address ::= >>> >>> Where you trying to express some checking that the node should have on >>> these address? >> >> Thanks for catching this. They have no reference in the -02 version. They >> are a remnant of -00 of the draft. After the grammar was modified in -01, >> they should have been deleted. >> >> Here's the next question - how were you planning to handle the multiple >> next-hops for the multicast. Did you have a plan? >> >> You will have both ECMP (unicast) multiple nexthops, > > Unicast multiple next hops are covered in Section 7.2.3. > > >> and multicast replication next hops. > > Section 7.3 talks about multicast replication (and refers to Section > 7.2.2). > > >> A flag might do nicely to differentiate. >> We could put this on the next hop. > > LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to indicate > ECMP/load-balancing. > > > > Thanks > Nitin > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Apr 29 07:21:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74341A08C9 for ; Tue, 29 Apr 2014 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyAyMKc0ZXzz for ; Tue, 29 Apr 2014 07:21:11 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id B142B1A08D5 for ; Tue, 29 Apr 2014 07:21:11 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so342836veb.35 for ; Tue, 29 Apr 2014 07:21:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qSnb5Mi/9P8Bu4TfRl6OoKkPysgLCbr6E56o3PYfvi8=; b=anvj4jURS4Zr9ZG82MTyq+lZQ/G7FEKDn/PUXGo3cpPT6tyPusqLIXa+6HZo5VIiUm E3s4H2K9rjxqapEC7R/VjlkgeCyC4rO8rAhro+mpHVsy5wW6v7mqKX8g3IKBuiULb4eu KwbvNVOXtKCQcMEeiL+qL1H8cTo1Ci+PbZJ0Zkf/40l3OdqZuq9WNoyaSioDL4PXLCch MmCH0+GJYKupyTT6P/WnyKWk3gCmMbxsbPLAAx6lZByrVmwQ0Aycwwdp7RQMnvzRDy8M Z1FhvcJUkvL+v2bTtMDIeuAgx5xluJrsuPBns4H+HRWDkOM07VRkOEzbptWD87gvyMU+ 0TxQ== X-Gm-Message-State: ALoCoQm80yOCPixDSPZo74EUvXawLv3fYTMDQUYeswo7V3T7OpN4dvGWvqe5WXVqyXJ5vXN4ipev X-Received: by 10.220.146.13 with SMTP id f13mr233542vcv.57.1398781270425; Tue, 29 Apr 2014 07:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 29 Apr 2014 07:20:50 -0700 (PDT) In-Reply-To: <000601cf6331$74424080$5cc6c180$@ndzh.com> References: <000601cf6331$74424080$5cc6c180$@ndzh.com> From: Jamal Hadi Salim Date: Tue, 29 Apr 2014 10:20:50 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QB6keOuT8oLrJheJm5IDtF8DAPg Cc: "i2rs@ietf.org" , Edward Crabbe , Evangelos Haleplidis , Alia Atlas , Jeffrey Haas , adrian Subject: Re: [i2rs] RIB information model - replacing RBNF with UML and RBNF X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 14:21:12 -0000 Sue, Thanks for the hard work. We will take a look and probably drop in with a ForCES data model representation. cheers, jamal On Mon, Apr 28, 2014 at 6:30 PM, Susan Hares wrote: > Hi all: > > > > I have attached a revision to the RIB info-model that replaces RBNF with = UML > and yang topology drafts. I am hoping to have a discussion of the UML wi= th > an approved draft before launching the UML/Yang topology models for the P= BR > and BGP drafts. > > > > This was posted ~1 weeks ago, but the chairs suggest this go on another l= ist > rather than the yang/forces discussion. To enforce this, the files were n= ot > sent to the general i2rs list. Some people were directly copied so a bri= ef > discussion occurred on list. Hopefully, under this new header all the fil= es > will be forwarded for discussions. > > > > This document inherits the yang data trees (as pseudo informational model= s > from) the following locations as > > > > ietf-netmod-routing-cfg-13 has this chart that indicates > > > > +--------+---------------------------+-----------+ > > | Prefix | YANG module | Reference | > > +--------+---------------------------+-----------+ > > | if | ietf-interfaces | [YANG-IF] | > > | | | | > > | ip | ietf-ip | [YANG-IP] | > > | | | | > > | rt | ietf-routing | Section 7 | > > | | | | > > | v4ur | ietf-ipv4-unicast-routing | Section 8 | > > | | | | > > | v6ur | ietf-ipv6-unicast-routing | Section 9 | > > | | | | > > | yang | ietf-yang-types | [RFC6991] | > > | | | | > > | inet | ietf-inet-types | [RFC6991] | > > +--------+---------------------------+-----------+ > > > > Table 1: Prefixes and corresponding YANG modules > > > > > > What changes did I make to the RIB section: > > > > 1)Revised RIB Grammar in RBNF (section 6.1) > > 2)(section 6.2) Spot for the pdf graphic attached as > > draft-hares-i2rs-info-rib-only-v7.pdf > > 3)(section 6.3) Yang tree structure (per yang documents) > > > > 4)Revised Usage =E2=80=93 using simplified grammar > > > > Basically: > > > > Basically the complex RIB-info RBNF grammar boils down to very few simply > > statement. The Yang Tree does not provide an easy way to design/debug > > redundancy. I think that the use of the UML tools that create the Yang > > modules/Yang Tree structures could speed time to market on the designs. > > For example, all the I2RS RIB is simply 5 power-point slides, that > > then can be generated into Yang module. This seems the normal > > progression of the process you started with the Yang-modules. > > > > CAVEATS: > > > > 1)For all mistakes on the UML and diagrams blame me =E2=80=93 this was th= e first > pass on the UML. > > 2) Some of the redundancies could have been fixed in other ways > > 3) I did Yang modules to demonstrate proof of concept > > 4) I suspect with Jamal and Joel Halpern=E2=80=99s help (FoRCES gurus).. = FoRCES > > > > Chair=E2=80=99s /AD opinion: > > 1) Jeff is in favor of UML to improve the data model language > > 2) Ed Crabbe states he does not think informational models are usefu= l =E2=80=93 > why not go to the data modeling direct. > > 3) Adrian and Alia encouraged me to look at UML > > > > I=E2=80=99m in favor of Information models that can quickly express the c= oncepts to > operators AND that can be used to generate code. UML-2.0 tools are out > there for to/from yang models, and yang to/from code. Seems like a > no-brainer tome to discuss 6 slides for the RIB info rather than the RBNF= . > > > > What do you think? > > > > > > Sue Hares > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Apr 29 14:56:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D101A09C1 for ; Tue, 29 Apr 2014 14:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBqOF2cHk4No for ; Tue, 29 Apr 2014 14:56:02 -0700 (PDT) Received: from nm11-vm7.bullet.mail.gq1.yahoo.com (nm11-vm7.bullet.mail.gq1.yahoo.com [98.136.218.174]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF61A09A9 for ; Tue, 29 Apr 2014 14:56:02 -0700 (PDT) Received: from [98.137.12.57] by nm11.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 21:56:01 -0000 Received: from [208.71.42.214] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 21:56:01 -0000 Received: from [127.0.0.1] by smtp225.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 21:56:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398808561; bh=YKf/JjDp+aDu+LB0llsv0blOTYwoMmx4dtcddUP1TNM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=pCOvwEf2iOdgLLyUEOaMfGmCR41ZiN3vTguBPkzvSDmrGVdm38/+EUCpfFoRfuvTivHJIoytzSkFap8e6NKrnkTNRU6MQqZLjKNVS8E+sEq9x6IYPP0bY3k+bhQMRFVeRBwoJO+48zGtangg4ok+1r7UhehNSApeubbl+3TgWPQ= X-Yahoo-Newman-Id: 129132.40365.bm@smtp225.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l3os80UVM1nPHtMyJ.SMvgo0iwMMdXo0Emti4w5dp7oEvuP 66zDMi1LxwLcIZH62o5CEKF.tikCRKjvbIUKFp6_vQikKY78Gf7W1ew8n5aP btSFTEacldK5oEZmEPeZ0E4rYjgMAN1tbtVUiZGoWeLFOITmOJzHux7SL51N KfzhmHVkzZrYYxGauKe_ycUuY3SIy.ZTAXqT6zK__F9I1k10Co8hVH3MEjdE gzvfLu60blQ2YkWUcGV8wLMe9Le8uNsqCzVc7_DG_UxdonEkTkifNPrnDyTz siLGS0d4ZnahNR4lhdv8SOrzPfw9qHZiQR2EwdjbLYXNR3kN0mZdYerbcaNX nzfvUuqPUvZL_drgCTI5YwFhEWA8.UWo7qdoVXQZJC33XfhJf4jUEZoxZDiL DiJS8A45CEv2heu9JxhWsintkqEjJfvf5cSOR67zinnWCIQZwVUE49dyFLIg HdJ7PqLGm8fJ994gDQ7H9VzkAeep8tkYsGcNlssGZZz5B89uj5qvwyfLjI6A SDI49zq00_UjL.ws_KK4Ct52eqgN02AVE_RZTGVqJvyYvwycvAaR6iZ.oRQ- - X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [63.250.193.228]) by smtp225.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 21:56:01 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 29 Apr 2014 14:55:56 -0700 From: Nitin Bahadur To: Susan Hares , 'Mach Chen' , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <00b501cf6393$dda76070$98f62150$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GWz4T_2b9JJNG6bYbFB1TVVD6nI Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 21:56:04 -0000 >[Nitin]:: Unicast multiple next hops are covered in Section 7.2.3. > >[Nitin] LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >indicate ECMP/load-balancing >> and multicast replication next hops. >[Nintin] Section 7.3 talks about multicast replication (and refers to >Section 7.2.2). > >[Sue]: You are stating that: > > ::= ( ) [( >)... ] >Is the flag for NH ECMP > > ::= ( ) > [( )... ] > >Sets primary/backup, and mixed with LOAD_BALANCE_WEIGHT - you groupings of >next-hops that are used for multicast (as default). > > ::= [ ... ] > >This makes it specific, but requires you specify the LOAD_BALANCE_WEIGHT >with each next hoip. >Were you intended your LOAD_BALANCE_WEIGHT to be a integer, and the >LOAD_PROTECTION_PREFERENCE to be a number. >From the draft: o PROTECTION_PREFERENCE: This provides a primary/backup like preference. The preference is an integer value that should be set to 1 (primary) or 2 (backup). Only when all the primary nexthops fail is the traffic re-routed through the backup nexthops. This attribute must be specified for all the members of a list or none of them. o LOAD_BALANCE_WEIGHT: This is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of "0" for all the member nexthops. The value "0" is reserved for equal load-balancing and if applied, MUST be applied to all member next hops. From nobody Tue Apr 29 15:09:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0E1A09F2 for ; Tue, 29 Apr 2014 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGkIuEiTOhNk for ; Tue, 29 Apr 2014 15:09:19 -0700 (PDT) Received: from nm17-vm7.bullet.mail.gq1.yahoo.com (nm17-vm7.bullet.mail.gq1.yahoo.com [98.137.177.231]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF9F1A09E6 for ; Tue, 29 Apr 2014 15:09:19 -0700 (PDT) Received: from [98.137.12.56] by nm17.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 22:09:18 -0000 Received: from [98.136.164.65] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 22:09:18 -0000 Received: from [127.0.0.1] by smtp227.mail.gq1.yahoo.com with NNFMP; 29 Apr 2014 22:09:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398809358; bh=HX0PSPZn9JWDdQlPe0KNr/3iWNykIIz5p8aZmakQtuE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=MmZ91pjnDPxfrw/9yuB+6npErcs869t1G4+v3zV7uGwYQ893nccvv4kHi6yTsoOITvv2hFBlnl1gNXb8zbdUeK0z6GpicNHk7wI6N+BvC3S6Cwgu5IqUCPb4Oje3d/2zYA+qrGktNRBbwr22DTPjPCW7DBCsxjyiBfe5V+ZrpjY= X-Yahoo-Newman-Id: 470625.19350.bm@smtp227.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7w3ptB4VM1niGr6T0E1bsA2ffCMlDcKtONi2DiYrGOSvq4j F9gwa0eFYcy.eRvcAVoPbFZhdRZcIUBA0GNfJXFn.BIuhkluMC8dlQ9ePCdi I0o0M3GcxWTTlVXPy.Lf0fwQVa.3RzeBs6JnNmC7mrsisCOM1SiRSBvWu8o6 yc9487saRyrgzqRVpEdNJPM09rcx9XPgRXijxk_ik4bHBMK7QVwONM6kOIoZ PYy4hKKXfRZ9y2H9322gFdygv2tMQnQgohbQcPXT2afgjs0_WT993vMTRI8s yUn0sx5btQzcKmdV3DRxxg1QBj1XDPVWW0LCLz5lDBQgDnhQZzH4y.EnUlUN PgI3ptC0hA.oJdP2554uM7Z.kYTiGovfyGT9NrTyPnC8lcCONme7okCRLfGa QY.NmzRKWJl4itPuyzs1u6RXNjs4X8hYzc.i7rwX9FvYCK5yuIrDFcAdg_8p NEIm9U5vzIXxtiT6UoAsljb1t2KHm1kurK_GYtZwDIhWz38xYsDTuX_Lmgp8 _n5m18IZpf7bzRLM5d2w9lSyzGc0lAiD6t3HQRPcCNuDEsmvwxhekWQ_SdQ- - X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [63.250.193.228]) by smtp227.mail.gq1.yahoo.com with SMTP; 29 Apr 2014 22:09:18 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 29 Apr 2014 15:09:15 -0700 From: Nitin Bahadur To: Susan Hares , 'Mach Chen' , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <00b501cf6393$dda76070$98f62150$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IJ1WIW5eRmxcULrAHI0OXQljoSg Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 22:09:21 -0000 >[Nitin] The main issue is that the grammar will not be deterministic. >[Nitin] In other words, one needs a way to specify that > is valid and is NOT valid. > >[Sue-2 on]=20 >Why is the grammar not explicit? Let's put the type back in for each > > (addresses are >just >a specific type of prefix) > (addresses are >just a specific type of prefix) > > >This is TLV where (form-type) implies a specific length (in example, 8,8, >16).=20 >If you want to go with the traditional TLV form, consider the (form-type) >as >a Type field,=20 >And put in a length field. Unfortunately this is not our typical TLV, sub-TLV definitions specified in IANA registry=8Ausing which one can easily see what is valid and what is not. In fact we don=B9t want anyone to refer to a registry, since all the code is going to be auto-generated (using the data-model tool=8Atbd). I think I=B9m just not clear on your proposal. Here is the grammar I have. ::=3D ( | | | | ) ::=3D | | | | ::=3D ( | | ( )) ::=3D ( | | ( )) ::=3D | | ::=3D ::=3D ::=3D If you could express what you are saying in the same-way, maybe I=B9ll get more clarity. Thanks Nitin From nobody Tue Apr 29 16:04:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534E21A09C2 for ; Tue, 29 Apr 2014 16:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flJoHTQ0GF7j for ; Tue, 29 Apr 2014 16:04:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 39DF11A09BF for ; Tue, 29 Apr 2014 16:04:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.147.102.204; Date: Tue, 29 Apr 2014 18:43:22 -0400 Message-ID: <8axb4s53c260furnr2jendso.1398811402217@email.android.com> Importance: normal From: Sue Hares To: Nitin Bahadur , 'Mach Chen' , i2rs@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_3212184680662220" X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/8VO4AiELfarFg6vPTjqluLJYXiY Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 23:04:10 -0000 ----_com.android.email_3212184680662220 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Tml0aW46CgpJJ20gb2ZmbGluZSBmb3IgMiBob3Vycy4gwqBJZiB5b3UgY291bGQgdGFrZSBhIHBl YWsgYXQgdGhlIMKgbGlzdCBJIGhhdmUgdGhlIHJldmlzZWQgZ3JhbW1hciBpbiBzZWN0aW9uIDYu MS4gwqBBbmQgdGhlIHlhbmcgbW9kdWxlIGluIHRoZSA2LjMuIMKgT2YgY291cnNlLCBJIHdpbGwg cmVzcG9uZCBsYXRlciB0aGlzIHBtLiDCoFN1ZQoKU3VlCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcg R0FMQVhZIFPCrjQsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKCi0tLS0tLS0tIE9yaWdpbmFs IG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogTml0aW4gQmFoYWR1ciA8bml0aW5fYmFoYWR1ckB5YWhv by5jb20+IApEYXRlOjA0LzI5LzIwMTQgIDY6MDkgUE0gIChHTVQtMDU6MDApIApUbzogU3VzYW4g SGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4sJ01hY2ggQ2hlbicgPG1hY2guY2hlbkBodWF3ZWkuY29t PixpMnJzQGlldGYub3JnIApDYzogZHJhZnQtaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVsQHRvb2xz LmlldGYub3JnIApTdWJqZWN0OiBSZTogW2kycnNdIFNvbWUgY29tbWVudHMgb24gZHJhZnQtaWV0 Zi1pMnJzLXJpYi1pbmZvLW1vZGVsLTAxIAoKCj5bTml0aW5dIFRoZSBtYWluIGlzc3VlIGlzIHRo YXQgdGhlIGdyYW1tYXIgd2lsbCBub3QgYmUgZGV0ZXJtaW5pc3RpYy4KPltOaXRpbl0gSW4gb3Ro ZXIgd29yZHMsIG9uZSBuZWVkcyBhIHdheSB0byBzcGVjaWZ5IHRoYXQgPHJvdXRlLXRhZy0xPgo+ PHJ0LWZvcm0tQT4gaXMgdmFsaWQgYW5kIDxyb3V0ZS10YWctMT4gPHJ0LWZvcm0tQj4gaXMgTk9U IHZhbGlkLgo+Cj5bU3VlLTIgb25dIAo+V2h5IGlzIHRoZSBncmFtbWFyIG5vdCBleHBsaWNpdD8g TGV0J3MgcHV0IHRoZSB0eXBlIGJhY2sgaW4gZm9yIGVhY2gKPgo+PG1hdGNoX2Zvcm0gPSBEU1Q+ IDxtYXRjaF90eXBlID0gSVB2ND4gPGlwLXY0LXByZWZpeD7CoMKgwqAgKGFkZHJlc3NlcyBhcmUK Pmp1c3QKPmEgc3BlY2lmaWMgdHlwZSBvZiBwcmVmaXgpCj48bWF0Y2hfZm9ybT1TUkM+IDxtYXRj aF90eXBlID0gSVB2ND4gPGlwdjQtcHJlZml4PsKgwqDCoMKgwqDCoMKgIChhZGRyZXNzZXMgYXJl Cj5qdXN0IGEgc3BlY2lmaWMgdHlwZSBvZiBwcmVmaXgpCj48bWF0Y2hfZm9ybT1EU1QtU1JDPiA8 bWF0Y2hfdHlwZSA9IGlwdjQ+IDxpcHY0LXByZWZpeD4gPGlwdjQtcHJlZml4Pgo+Cj5UaGlzIGlz IFRMViB3aGVyZSAoZm9ybS10eXBlKSBpbXBsaWVzIGEgc3BlY2lmaWMgbGVuZ3RoIChpbiBleGFt cGxlLCA4LDgsCj4xNikuIAo+SWYgeW91IHdhbnQgdG8gZ28gd2l0aCB0aGUgdHJhZGl0aW9uYWwg VExWIGZvcm0sIGNvbnNpZGVyIHRoZSAoZm9ybS10eXBlKQo+YXMKPmEgVHlwZSBmaWVsZCwgCj5B bmQgcHV0IGluIGEgbGVuZ3RoIGZpZWxkLgoKVW5mb3J0dW5hdGVseSB0aGlzIGlzIG5vdCBvdXIg dHlwaWNhbCBUTFYsIHN1Yi1UTFYgZGVmaW5pdGlvbnMgc3BlY2lmaWVkCmluIElBTkEgcmVnaXN0 cnnCinVzaW5nIHdoaWNoIG9uZSBjYW4gZWFzaWx5IHNlZSB3aGF0IGlzIHZhbGlkIGFuZCB3aGF0 IGlzCm5vdC4gSW4gZmFjdCB3ZSBkb27CuXQgd2FudCBhbnlvbmUgdG8gcmVmZXIgdG8gYSByZWdp c3RyeSwgc2luY2UgYWxsIHRoZQpjb2RlIGlzIGdvaW5nIHRvIGJlIGF1dG8tZ2VuZXJhdGVkICh1 c2luZyB0aGUgZGF0YS1tb2RlbCB0b29swop0YmQpLgoKSSB0aGluayBJwrltIGp1c3Qgbm90IGNs ZWFyIG9uIHlvdXIgcHJvcG9zYWwuIEhlcmUgaXMgdGhlIGdyYW1tYXIgSSBoYXZlLgoKPG1hdGNo PiA6Oj0gPHJvdXRlLXR5cGU+ICg8aXB2NC1yb3V0ZT4gfCA8aXB2Ni1yb3V0ZT4gfCA8bXBscy1y b3V0ZT4gfArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8bWFjLXJvdXRlPiB8IDxpbnRlcmZhY2Utcm91dGU+KQo8cm91dGUtdHlwZT4gOjo9IDxJUFY0 PiB8IDxJUFY2PiB8IDxNUExTPiB8IDxJRUVFX01BQz4gfCA8SU5URVJGQUNFPgoKPGlwdjQtcm91 dGU+IDo6PSA8aXAtcm91dGUtdHlwZT4gKDxkZXN0aW5hdGlvbi1pcHY0LWFkZHJlc3M+IHwKPHNv dXJjZS1pcHY0LWFkZHJlc3M+IHwKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICg8ZGVzdGluYXRpb24taXB2NC1hZGRyZXNz Pgo8c291cmNlLWlwdjQtYWRkcmVzcz4pKQo8aXB2Ni1yb3V0ZT4gOjo9IDxpcC1yb3V0ZS10eXBl PiAoPGRlc3RpbmF0aW9uLWlwdjYtYWRkcmVzcz4gfAo8c291cmNlLWlwdjYtYWRkcmVzcz4gfArC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKDxkZXN0aW5hdGlvbi1pcHY2LWFk ZHJlc3M+IDxzb3VyY2UtaXB2Ni1hZGRyZXNzPikpCjxpcC1yb3V0ZS10eXBlPiA6Oj0gPFNSQz4g fCA8REVTVD4gfCA8REVTVF9TUkM+CjxtcGxzLXJvdXRlPiA6Oj0gPE1QTFNfTEFCRUw+CjxtYWMt cm91dGU+IDo6PSA8TUFDX0FERFJFU1M+CjxpbnRlcmZhY2Utcm91dGU+IDo6PSA8SU5URVJGQUNF X0lERU5USUZJRVI+CgoKCklmIHlvdSBjb3VsZCBleHByZXNzIHdoYXQgeW91IGFyZSBzYXlpbmcg aW4gdGhlIHNhbWUtd2F5LCBtYXliZSBJwrlsbCBnZXQKbW9yZSBjbGFyaXR5LgoKVGhhbmtzCk5p dGluCgoK ----_com.android.email_3212184680662220 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5OaXRpbjo8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PkknbSBvZmZsaW5lIGZvciAyIGhvdXJzLiAmbmJzcDtJZiB5b3UgY291 bGQgdGFrZSBhIHBlYWsgYXQgdGhlICZuYnNwO2xpc3QgSSBoYXZlIHRoZSByZXZpc2VkIGdyYW1t YXIgaW4gc2VjdGlvbiA2LjEuICZuYnNwO0FuZCB0aGUgeWFuZyBtb2R1bGUgaW4gdGhlIDYuMy4g Jm5ic3A7T2YgY291cnNlLCBJIHdpbGwgcmVzcG9uZCBsYXRlciB0aGlzIHBtLiAmbmJzcDtTdWU8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN1ZTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjlweDtjb2xvcjojNTc1NzU3Ij5TZW50 IHZpYSB0aGUgU2Ftc3VuZyBHQUxBWFkgU8KuNCwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhv bmU8L2Rpdj48L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08 YnI+RnJvbTogTml0aW4gQmFoYWR1ciA8bml0aW5fYmFoYWR1ckB5YWhvby5jb20+IDxicj5EYXRl OjA0LzI5LzIwMTQgIDY6MDkgUE0gIChHTVQtMDU6MDApIDxicj5UbzogU3VzYW4gSGFyZXMgPHNo YXJlc0BuZHpoLmNvbT4sJ01hY2ggQ2hlbicgPG1hY2guY2hlbkBodWF3ZWkuY29tPixpMnJzQGll dGYub3JnIDxicj5DYzogZHJhZnQtaWV0Zi1pMnJzLXJpYi1pbmZvLW1vZGVsQHRvb2xzLmlldGYu b3JnIDxicj5TdWJqZWN0OiBSZTogW2kycnNdIFNvbWUgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1p MnJzLXJpYi1pbmZvLW1vZGVsLTAxIDxicj48YnI+PGJyPiZndDtbTml0aW5dIFRoZSBtYWluIGlz c3VlIGlzIHRoYXQgdGhlIGdyYW1tYXIgd2lsbCBub3QgYmUgZGV0ZXJtaW5pc3RpYy48YnI+Jmd0 O1tOaXRpbl0gSW4gb3RoZXIgd29yZHMsIG9uZSBuZWVkcyBhIHdheSB0byBzcGVjaWZ5IHRoYXQg Jmx0O3JvdXRlLXRhZy0xJmd0Ozxicj4mZ3Q7Jmx0O3J0LWZvcm0tQSZndDsgaXMgdmFsaWQgYW5k ICZsdDtyb3V0ZS10YWctMSZndDsgJmx0O3J0LWZvcm0tQiZndDsgaXMgTk9UIHZhbGlkLjxicj4m Z3Q7PGJyPiZndDtbU3VlLTIgb25dIDxicj4mZ3Q7V2h5IGlzIHRoZSBncmFtbWFyIG5vdCBleHBs aWNpdD8gTGV0J3MgcHV0IHRoZSB0eXBlIGJhY2sgaW4gZm9yIGVhY2g8YnI+Jmd0Ozxicj4mZ3Q7 Jmx0O21hdGNoX2Zvcm0gPSBEU1QmZ3Q7ICZsdDttYXRjaF90eXBlID0gSVB2NCZndDsgJmx0O2lw LXY0LXByZWZpeCZndDsmbmJzcDsmbmJzcDsmbmJzcDsgKGFkZHJlc3NlcyBhcmU8YnI+Jmd0O2p1 c3Q8YnI+Jmd0O2Egc3BlY2lmaWMgdHlwZSBvZiBwcmVmaXgpPGJyPiZndDsmbHQ7bWF0Y2hfZm9y bT1TUkMmZ3Q7ICZsdDttYXRjaF90eXBlID0gSVB2NCZndDsgJmx0O2lwdjQtcHJlZml4Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoYWRkcmVzc2VzIGFyZTxi cj4mZ3Q7anVzdCBhIHNwZWNpZmljIHR5cGUgb2YgcHJlZml4KTxicj4mZ3Q7Jmx0O21hdGNoX2Zv cm09RFNULVNSQyZndDsgJmx0O21hdGNoX3R5cGUgPSBpcHY0Jmd0OyAmbHQ7aXB2NC1wcmVmaXgm Z3Q7ICZsdDtpcHY0LXByZWZpeCZndDs8YnI+Jmd0Ozxicj4mZ3Q7VGhpcyBpcyBUTFYgd2hlcmUg KGZvcm0tdHlwZSkgaW1wbGllcyBhIHNwZWNpZmljIGxlbmd0aCAoaW4gZXhhbXBsZSwgOCw4LDxi cj4mZ3Q7MTYpLiA8YnI+Jmd0O0lmIHlvdSB3YW50IHRvIGdvIHdpdGggdGhlIHRyYWRpdGlvbmFs IFRMViBmb3JtLCBjb25zaWRlciB0aGUgKGZvcm0tdHlwZSk8YnI+Jmd0O2FzPGJyPiZndDthIFR5 cGUgZmllbGQsIDxicj4mZ3Q7QW5kIHB1dCBpbiBhIGxlbmd0aCBmaWVsZC48YnI+PGJyPlVuZm9y dHVuYXRlbHkgdGhpcyBpcyBub3Qgb3VyIHR5cGljYWwgVExWLCBzdWItVExWIGRlZmluaXRpb25z IHNwZWNpZmllZDxicj5pbiBJQU5BIHJlZ2lzdHJ5wop1c2luZyB3aGljaCBvbmUgY2FuIGVhc2ls eSBzZWUgd2hhdCBpcyB2YWxpZCBhbmQgd2hhdCBpczxicj5ub3QuIEluIGZhY3Qgd2UgZG9uwrl0 IHdhbnQgYW55b25lIHRvIHJlZmVyIHRvIGEgcmVnaXN0cnksIHNpbmNlIGFsbCB0aGU8YnI+Y29k ZSBpcyBnb2luZyB0byBiZSBhdXRvLWdlbmVyYXRlZCAodXNpbmcgdGhlIGRhdGEtbW9kZWwgdG9v bMKKdGJkKS48YnI+PGJyPkkgdGhpbmsgScK5bSBqdXN0IG5vdCBjbGVhciBvbiB5b3VyIHByb3Bv c2FsLiBIZXJlIGlzIHRoZSBncmFtbWFyIEkgaGF2ZS48YnI+PGJyPiZsdDttYXRjaCZndDsgOjo9 ICZsdDtyb3V0ZS10eXBlJmd0OyAoJmx0O2lwdjQtcm91dGUmZ3Q7IHwgJmx0O2lwdjYtcm91dGUm Z3Q7IHwgJmx0O21wbHMtcm91dGUmZ3Q7IHw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDttYWMtcm91dGUmZ3Q7IHwgJmx0O2ludGVyZmFjZS1yb3V0ZSZndDspPGJy PiZsdDtyb3V0ZS10eXBlJmd0OyA6Oj0gJmx0O0lQVjQmZ3Q7IHwgJmx0O0lQVjYmZ3Q7IHwgJmx0 O01QTFMmZ3Q7IHwgJmx0O0lFRUVfTUFDJmd0OyB8ICZsdDtJTlRFUkZBQ0UmZ3Q7PGJyPjxicj4m bHQ7aXB2NC1yb3V0ZSZndDsgOjo9ICZsdDtpcC1yb3V0ZS10eXBlJmd0OyAoJmx0O2Rlc3RpbmF0 aW9uLWlwdjQtYWRkcmVzcyZndDsgfDxicj4mbHQ7c291cmNlLWlwdjQtYWRkcmVzcyZndDsgfDxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKCZsdDtkZXN0aW5hdGlvbi1pcHY0LWFkZHJl c3MmZ3Q7PGJyPiZsdDtzb3VyY2UtaXB2NC1hZGRyZXNzJmd0OykpPGJyPiZsdDtpcHY2LXJvdXRl Jmd0OyA6Oj0gJmx0O2lwLXJvdXRlLXR5cGUmZ3Q7ICgmbHQ7ZGVzdGluYXRpb24taXB2Ni1hZGRy ZXNzJmd0OyB8PGJyPiZsdDtzb3VyY2UtaXB2Ni1hZGRyZXNzJmd0OyB8PGJyPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoJmx0O2Rlc3RpbmF0aW9u LWlwdjYtYWRkcmVzcyZndDsgJmx0O3NvdXJjZS1pcHY2LWFkZHJlc3MmZ3Q7KSk8YnI+Jmx0O2lw LXJvdXRlLXR5cGUmZ3Q7IDo6PSAmbHQ7U1JDJmd0OyB8ICZsdDtERVNUJmd0OyB8ICZsdDtERVNU X1NSQyZndDs8YnI+Jmx0O21wbHMtcm91dGUmZ3Q7IDo6PSAmbHQ7TVBMU19MQUJFTCZndDs8YnI+ Jmx0O21hYy1yb3V0ZSZndDsgOjo9ICZsdDtNQUNfQUREUkVTUyZndDs8YnI+Jmx0O2ludGVyZmFj ZS1yb3V0ZSZndDsgOjo9ICZsdDtJTlRFUkZBQ0VfSURFTlRJRklFUiZndDs8YnI+PGJyPjxicj48 YnI+SWYgeW91IGNvdWxkIGV4cHJlc3Mgd2hhdCB5b3UgYXJlIHNheWluZyBpbiB0aGUgc2FtZS13 YXksIG1heWJlIEnCuWxsIGdldDxicj5tb3JlIGNsYXJpdHkuPGJyPjxicj5UaGFua3M8YnI+Tml0 aW48YnI+PGJyPjxicj48L2JvZHk+ ----_com.android.email_3212184680662220-- From nobody Wed Apr 30 04:27:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E941A0754 for ; Wed, 30 Apr 2014 04:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6QlYfRlf8su for ; Wed, 30 Apr 2014 04:27:10 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 285B71A0723 for ; Wed, 30 Apr 2014 04:27:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Nitin Bahadur'" , "'Mach Chen'" , References: <535FB50A.6090608@joelhalpern.com> In-Reply-To: <535FB50A.6090608@joelhalpern.com> Date: Wed, 30 Apr 2014 07:26:55 -0400 Message-ID: <000f01cf6467$187b0c00$49712400$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKknMgRLJA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OAn6N49suAqC2YBwALybzdzItJI Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 11:27:11 -0000 Joel: Great! This is the answer I hoped to get. Just to make sure, We are defining a role as: identity + rib tree + access (read or write or read-write). If I define a tree portion that is read-only does that align with our = role definitions.=20 If this is a common definition, then I'm good to release the next = version of the draft with read/write for the RIB-info.=20 Sue =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, April 29, 2014 10:20 AM To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 Remember that an information model is not a grammar. It is perfectly = okay in an IM to have two branches that are just different things.=20 Discriminators are added in when one goes from teh information model to = the data model. Yours, Joel On 4/29/14, 2:36 AM, Nitin Bahadur wrote: > Hi Sue, > >> >> >> >>> 4) Would a corrections to the above be useful: >>> Given the above you could simplify your match RBNF: >>> >>> :: =3D [ipv4-route | ipv6-route |=20 >>> mpls-route >>> | mac-route] >> >> [Nitin] The is not needed for mpls and mac routes=A9.since=20 >> MPLS has no concept of SRC or DEST. So that simplification will=20 >> actually not help :( >> >> [Sue]: Yes, not all forms would benefit. However, MPLS does have the = >> stack tags that we may want to save and match on. Also: the 5-tuples = >> may be a part of matching some routes. By using rt-form, we are=20 >> using the TLV format to set-up these multiple formats. Each format,=20 >> would have the appropriate expectations for the appropriate address=20 >> families. >> >> [Sue]: I think it provides table based code. > > The main issue is that the grammar will not be deterministic. In other = > words, one needs a way to specify that is=20 > valid and is NOT valid. > > >> >> The will need to be associated specifically with=20 >> and . >> >> [Sue]: yes, it could. With the rt-form and the rib-family type,=20 >> perhaps we can remove the rt-type. >> [snip] > > Rib-family-type and route-type are kind of the same thing. I need to=20 > think if there is a case where they can be different... > > >> >>> 5) Why did you specify differently? >>> >>> multicast-source-ipv4-address ::=3D = =20 >>> multicast-source-ipv6-address = ::=3D >>> >>> Where you trying to express some checking that the node should have=20 >>> on these address? >> >> Thanks for catching this. They have no reference in the -02 version.=20 >> They are a remnant of -00 of the draft. After the grammar was=20 >> modified in -01, they should have been deleted. >> >> Here's the next question - how were you planning to handle the=20 >> multiple next-hops for the multicast. Did you have a plan? >> >> You will have both ECMP (unicast) multiple nexthops, > > Unicast multiple next hops are covered in Section 7.2.3. > > >> and multicast replication next hops. > > Section 7.3 talks about multicast replication (and refers to Section=20 > 7.2.2). > > >> A flag might do nicely to differentiate. >> We could put this on the next hop. > > LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to=20 > indicate ECMP/load-balancing. > > > > Thanks > Nitin > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Apr 30 04:54:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614B1A6F56 for ; Wed, 30 Apr 2014 04:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.245 X-Spam-Level: *** X-Spam-Status: No, score=3.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, MANGLED_OFF=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdgEnDhtxVDE for ; Wed, 30 Apr 2014 04:54:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC6011A6F55 for ; Wed, 30 Apr 2014 04:54:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Mach Chen'" , References: <00b501cf6393$dda76070$98f62150$@ndzh.com> In-Reply-To: Date: Wed, 30 Apr 2014 07:54:26 -0400 Message-ID: <001101cf646a$f02b8a50$d0829ef0$@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: AQG7AQVQ1fkVRyoZOhGOG5sGYqpbpJtSycVA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/StMoucS6QPTcor55BexGjgif7Rs Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 11:54:41 -0000 Nitin: Let me start with my perception of the problem: Problem: Your grammar does not handle source-destination form choice as a generic form used by all of the interfaces. Solution: Specify form as specific variable for all forms. Confusion: I am suggesting two tags and you want see one tag for compilation. See the two tags: [form-type] as two parts to one tag: [high order tag form] [low order form - address form] At this point, all I have done is reduce your complex forms to 1 tag = Then your grammar is as follows: ::= ( | | | | ) ::= | | | | = = Routing protocols would have: [rrr ff ttt] r = reserved/0 ff = 0/1 (for src/dst), ttt = type] ::= | | | | Each of these forms for matches could use the SRC and destination in the filter. I'm sure that IPv4, IPv6, and IEEE_MAC are obvious from your emails. Interfaces can be viewed as the same for flows: . This can be that the traffic flow comes in on interface1 and goes out on interface 2 for all interfaces. MPLS could but it can be ingress/egress label as source/destination. Do you agree/disagree have a potential of having source-destination for most of these types? Your grammar could then be restated: ================================ ::= ( | | | | ) ::= | | | | ::= | | ::= ( | | ( )) ::= ( | | ( )) ::= | | :: = ( (egress-MPLS-label) | (Ingress-MPLS_LABEL>) | ()) ::= > ( | [] | ()) ::= ( | | ( ) ) If you need context on the interfaces, pleases consider multicast and flows. The rest hopefully is QED based the above grammar. If we can start with this, I hopefully, you can see the extension to other forms n-tuple and next-hops. Sue _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Apr 30 06:39:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACCE1A08D9 for ; Wed, 30 Apr 2014 06:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtBZqADEHGxh for ; Wed, 30 Apr 2014 06:39:30 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5261A08C8 for ; Wed, 30 Apr 2014 06:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EA25224097E; Wed, 30 Apr 2014 06:39:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CDFE72408F9; Wed, 30 Apr 2014 06:39:27 -0700 (PDT) Message-ID: <5360FD05.6030407@joelhalpern.com> Date: Wed, 30 Apr 2014 09:39:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Susan Hares , 'Nitin Bahadur' , 'Mach Chen' , i2rs@ietf.org References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> In-Reply-To: <000f01cf6467$187b0c00$49712400$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DjqffL2qnSj92QUWrrESiOk3bak Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 13:39:32 -0000 I do not think that matches the definition of role we are using. An identity has a role. Several identities may have the same role. And a role is defined by a collections if pairs. This is not specific to the RIB model, and should not be in the rib model at all as far as I can tell. Separate from the definition of role, and again applicable across all information models, an agent may itself have access restrictions. A client using an agent is restricted to the access set which is permitted both by its role and by what the agent has permission to do. Again, if we want to model that, we should model it outside of any specific IM. Yours, Joel On 4/30/14, 7:26 AM, Susan Hares wrote: > Joel: > > Great! This is the answer I hoped to get. Just to make sure, We are > defining a role as: identity + rib tree + access (read or write or > read-write). > If I define a tree portion that is read-only does that align with our role > definitions. > > If this is a common definition, then I'm good to release the next version of > the draft with read/write for the RIB-info. > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 29, 2014 10:20 AM > To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org > Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > > Remember that an information model is not a grammar. It is perfectly okay > in an IM to have two branches that are just different things. > Discriminators are added in when one goes from teh information model to the > data model. > > Yours, > Joel > > On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >> Hi Sue, >> >>> >>> >>> >>>> 4) Would a corrections to the above be useful: >>>> Given the above you could simplify your match RBNF: >>>> >>>> :: = [ipv4-route | ipv6-route | >>>> mpls-route >>>> | mac-route] >>> >>> [Nitin] The is not needed for mpls and mac routes©.since >>> MPLS has no concept of SRC or DEST. So that simplification will >>> actually not help :( >>> >>> [Sue]: Yes, not all forms would benefit. However, MPLS does have the >>> stack tags that we may want to save and match on. Also: the 5-tuples >>> may be a part of matching some routes. By using rt-form, we are >>> using the TLV format to set-up these multiple formats. Each format, >>> would have the appropriate expectations for the appropriate address >>> families. >>> >>> [Sue]: I think it provides table based code. >> >> The main issue is that the grammar will not be deterministic. In other >> words, one needs a way to specify that is >> valid and is NOT valid. >> >> >>> >>> The will need to be associated specifically with >>> and . >>> >>> [Sue]: yes, it could. With the rt-form and the rib-family type, >>> perhaps we can remove the rt-type. >>> [snip] >> >> Rib-family-type and route-type are kind of the same thing. I need to >> think if there is a case where they can be different... >> >> >>> >>>> 5) Why did you specify differently? >>>> >>>> multicast-source-ipv4-address ::= >>>> multicast-source-ipv6-address ::= >>>> >>>> Where you trying to express some checking that the node should have >>>> on these address? >>> >>> Thanks for catching this. They have no reference in the -02 version. >>> They are a remnant of -00 of the draft. After the grammar was >>> modified in -01, they should have been deleted. >>> >>> Here's the next question - how were you planning to handle the >>> multiple next-hops for the multicast. Did you have a plan? >>> >>> You will have both ECMP (unicast) multiple nexthops, >> >> Unicast multiple next hops are covered in Section 7.2.3. >> >> >>> and multicast replication next hops. >> >> Section 7.3 talks about multicast replication (and refers to Section >> 7.2.2). >> >> >>> A flag might do nicely to differentiate. >>> We could put this on the next hop. >> >> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >> indicate ECMP/load-balancing. >> >> >> >> Thanks >> Nitin >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Wed Apr 30 06:54:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038E61A6F90 for ; Wed, 30 Apr 2014 06:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4-hjysxI4cP for ; Wed, 30 Apr 2014 06:54:08 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91B1A08DC for ; Wed, 30 Apr 2014 06:54:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Nitin Bahadur'" , "'Mach Chen'" , References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> In-Reply-To: <5360FD05.6030407@joelhalpern.com> Date: Wed, 30 Apr 2014 09:53:56 -0400 Message-ID: <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhJyn3cTA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ZE2_y2d0bwIR6txQjQ4H21ECMu4 Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 13:54:10 -0000 Joel: Thank you for the clarification, I should have been clearer. Identity = is uniquely defined by a security entity.=20 Role =3D pairs of (im-tree-portion, access-permission) pairs If the IM model wants to have=20 (im-tree-portion =3D rib-rw section, read-write) pair =20 (im-tree-portion =3D rib-ro-section, read-only) pair=20 Then this is the role of the client-agent pair. This assumes that agent = can grant both the RIB structure has both r-w for configuration (as in the current document), and a read-only section (dynamic statistics). =20 Therefore, If I understand correctly - I can utilize Yang-tree model as poor-man's Info-Model since it can both represent the r-w tree (configuration) and the rib-ro tree for dynamics status. For the notifications sequence (it may config state (turn on/off reporting) and ro-state. Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 30, 2014 9:39 AM To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; i2rs@ietf.org Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 I do not think that matches the definition of role we are using. An identity has a role. Several identities may have the same role. And a role is defined by a collections if pairs. This is not specific to the RIB model, and should not be in the rib = model at all as far as I can tell. Separate from the definition of role, and again applicable across all information models, an agent may itself have access restrictions. A = client using an agent is restricted to the access set which is permitted both = by its role and by what the agent has permission to do. Again, if we want to model that, we should model it outside of any = specific IM. Yours, Joel On 4/30/14, 7:26 AM, Susan Hares wrote: > Joel: > > Great! This is the answer I hoped to get. Just to make sure, We are = > defining a role as: identity + rib tree + access (read or write or=20 > read-write). > If I define a tree portion that is read-only does that align with our=20 > role definitions. > > If this is a common definition, then I'm good to release the next=20 > version of the draft with read/write for the RIB-info. > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 29, 2014 10:20 AM > To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org > Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > > Remember that an information model is not a grammar. It is perfectly=20 > okay in an IM to have two branches that are just different things. > Discriminators are added in when one goes from teh information model=20 > to the data model. > > Yours, > Joel > > On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >> Hi Sue, >> >>> >>> >>> >>>> 4) Would a corrections to the above be useful: >>>> Given the above you could simplify your match RBNF: >>>> >>>> :: =3D [ipv4-route | ipv6-route |=20 >>>> mpls-route >>>> | mac-route] >>> >>> [Nitin] The is not needed for mpls and mac routes=A9.since = >>> MPLS has no concept of SRC or DEST. So that simplification will=20 >>> actually not help :( >>> >>> [Sue]: Yes, not all forms would benefit. However, MPLS does have=20 >>> the stack tags that we may want to save and match on. Also: the=20 >>> 5-tuples may be a part of matching some routes. By using rt-form,=20 >>> we are using the TLV format to set-up these multiple formats. Each=20 >>> format, would have the appropriate expectations for the appropriate=20 >>> address families. >>> >>> [Sue]: I think it provides table based code. >> >> The main issue is that the grammar will not be deterministic. In=20 >> other words, one needs a way to specify that =20 >> is valid and is NOT valid. >> >> >>> >>> The will need to be associated specifically with=20 >>> and . >>> >>> [Sue]: yes, it could. With the rt-form and the rib-family type,=20 >>> perhaps we can remove the rt-type. >>> [snip] >> >> Rib-family-type and route-type are kind of the same thing. I need to=20 >> think if there is a case where they can be different... >> >> >>> >>>> 5) Why did you specify differently? >>>> >>>> multicast-source-ipv4-address ::=3D=20 >>>> multicast-source-ipv6-address=20 >>>> ::=3D >>>> >>>> Where you trying to express some checking that the node should have = >>>> on these address? >>> >>> Thanks for catching this. They have no reference in the -02 version. >>> They are a remnant of -00 of the draft. After the grammar was=20 >>> modified in -01, they should have been deleted. >>> >>> Here's the next question - how were you planning to handle the=20 >>> multiple next-hops for the multicast. Did you have a plan? >>> >>> You will have both ECMP (unicast) multiple nexthops, >> >> Unicast multiple next hops are covered in Section 7.2.3. >> >> >>> and multicast replication next hops. >> >> Section 7.3 talks about multicast replication (and refers to Section=20 >> 7.2.2). >> >> >>> A flag might do nicely to differentiate. >>> We could put this on the next hop. >> >> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to=20 >> indicate ECMP/load-balancing. >> >> >> >> Thanks >> Nitin >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Wed Apr 30 07:02:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D551A08DC for ; Wed, 30 Apr 2014 07:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG9Hp4NfGrAm for ; Wed, 30 Apr 2014 07:02:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id A12071A08D0 for ; Wed, 30 Apr 2014 07:02:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7AF4B240851; Wed, 30 Apr 2014 07:02:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 33FBA24054E; Wed, 30 Apr 2014 07:02:04 -0700 (PDT) Message-ID: <53610252.4000800@joelhalpern.com> Date: Wed, 30 Apr 2014 10:01:54 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Susan Hares , 'Nitin Bahadur' , 'Mach Chen' , i2rs@ietf.org References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> In-Reply-To: <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/SGql8udaxuNVCrfT2gHqqVTvSkI Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:02:08 -0000 As an Information model, treating the YANG tree as an info model has the problem that the information model is probably not a tree. There will be a well-defined tree if the data model is YANG. But there is not such a restriction at the info model level. But I still don't understand why you even need to mention this in the rib information model. Just for clarity, I would have written the permissions paradigm as: (im-tree = portion definition 1, read-write) * (im-tree = portion definition 2, read-only) * Where the "*" indicates that each of those can occur 0 or more times. There is not a well defined information model notion of the rib-rw section. Yours, Joel On 4/30/14, 9:53 AM, Susan Hares wrote: > Joel: > > Thank you for the clarification, I should have been clearer. Identity is > uniquely defined by a security entity. > > Role = pairs of (im-tree-portion, access-permission) pairs > > If the IM model wants to have > (im-tree-portion = rib-rw section, read-write) pair > (im-tree-portion = rib-ro-section, read-only) pair > > Then this is the role of the client-agent pair. This assumes that agent can > grant both the RIB structure has both r-w for configuration (as in the > current document), and a read-only section (dynamic statistics). > > Therefore, If I understand correctly - I can utilize Yang-tree model as > poor-man's Info-Model since it can both represent the r-w tree > (configuration) and the rib-ro tree for dynamics status. For the > notifications sequence (it may config state (turn on/off reporting) and > ro-state. > > Sue > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 30, 2014 9:39 AM > To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; i2rs@ietf.org > Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > > I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if permission> pairs. > > This is not specific to the RIB model, and should not be in the rib model at > all as far as I can tell. > > Separate from the definition of role, and again applicable across all > information models, an agent may itself have access restrictions. A client > using an agent is restricted to the access set which is permitted both by > its role and by what the agent has permission to do. > > Again, if we want to model that, we should model it outside of any specific > IM. > > Yours, > Joel > > On 4/30/14, 7:26 AM, Susan Hares wrote: >> Joel: >> >> Great! This is the answer I hoped to get. Just to make sure, We are >> defining a role as: identity + rib tree + access (read or write or >> read-write). >> If I define a tree portion that is read-only does that align with our >> role definitions. >> >> If this is a common definition, then I'm good to release the next >> version of the draft with read/write for the RIB-info. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org >> Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org >> Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 >> >> Remember that an information model is not a grammar. It is perfectly >> okay in an IM to have two branches that are just different things. >> Discriminators are added in when one goes from teh information model >> to the data model. >> >> Yours, >> Joel >> >> On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >>> Hi Sue, >>> >>>> >>>> >>>> >>>>> 4) Would a corrections to the above be useful: >>>>> Given the above you could simplify your match RBNF: >>>>> >>>>> :: = [ipv4-route | ipv6-route | >>>>> mpls-route >>>>> | mac-route] >>>> >>>> [Nitin] The is not needed for mpls and mac routes©.since >>>> MPLS has no concept of SRC or DEST. So that simplification will >>>> actually not help :( >>>> >>>> [Sue]: Yes, not all forms would benefit. However, MPLS does have >>>> the stack tags that we may want to save and match on. Also: the >>>> 5-tuples may be a part of matching some routes. By using rt-form, >>>> we are using the TLV format to set-up these multiple formats. Each >>>> format, would have the appropriate expectations for the appropriate >>>> address families. >>>> >>>> [Sue]: I think it provides table based code. >>> >>> The main issue is that the grammar will not be deterministic. In >>> other words, one needs a way to specify that >>> is valid and is NOT valid. >>> >>> >>>> >>>> The will need to be associated specifically with >>>> and . >>>> >>>> [Sue]: yes, it could. With the rt-form and the rib-family type, >>>> perhaps we can remove the rt-type. >>>> [snip] >>> >>> Rib-family-type and route-type are kind of the same thing. I need to >>> think if there is a case where they can be different... >>> >>> >>>> >>>>> 5) Why did you specify differently? >>>>> >>>>> multicast-source-ipv4-address ::= >>>>> multicast-source-ipv6-address >>>>> ::= >>>>> >>>>> Where you trying to express some checking that the node should have >>>>> on these address? >>>> >>>> Thanks for catching this. They have no reference in the -02 version. >>>> They are a remnant of -00 of the draft. After the grammar was >>>> modified in -01, they should have been deleted. >>>> >>>> Here's the next question - how were you planning to handle the >>>> multiple next-hops for the multicast. Did you have a plan? >>>> >>>> You will have both ECMP (unicast) multiple nexthops, >>> >>> Unicast multiple next hops are covered in Section 7.2.3. >>> >>> >>>> and multicast replication next hops. >>> >>> Section 7.3 talks about multicast replication (and refers to Section >>> 7.2.2). >>> >>> >>>> A flag might do nicely to differentiate. >>>> We could put this on the next hop. >>> >>> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >>> indicate ECMP/load-balancing. >>> >>> >>> >>> Thanks >>> Nitin >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > From nobody Wed Apr 30 07:02:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F661A08F4 for ; Wed, 30 Apr 2014 07:02: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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0exMOIUiFSFf for ; Wed, 30 Apr 2014 07:02:21 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7A1A08F3 for ; Wed, 30 Apr 2014 07:02:21 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id m5so1697621qaj.29 for ; Wed, 30 Apr 2014 07:02:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gPAI8gojpu3Zu2/Nyf6XFHY8DN42w5Gcj6kG/Z98n4Y=; b=b67kQ0XSttIFInJ1QTS/zcmuY1isVfEan2sy3wliuekyId79WqGu2cnDiuK3hsbR5f kKSHohVpttEQBP9LggJKFGJQtvOvPc7v93e+4RI2jyit9L+6G5nKhaaEdppuMwG32IXI 5cP6QaVHpQg+g4VWaf+a8Ccpr3oWVZtsd5agV3tW8WiK5U2FvlD5FWM5c/EY5DxKh8Gh DweVZspZCxxwHHBm1/zob7Mu3YUeLJEMX8KQ2dch/g0cvjcJ86Q8Fvcf0ECual35wXqT hHA8x1Z3iNsqFv4wpj7ICDrsCfGmkCN4gXRhtAVSj5vkZMZFR/giLKbwmB+NYOx3Cygw D+Og== X-Gm-Message-State: ALoCoQk3MqGanUTYdjvjks/cm+S0aNanuuMNaHBbMrWiONzh93+cxdZQIjlj4vbQSDb+OnQSXtiX MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr5109434qad.88.1398866539629; Wed, 30 Apr 2014 07:02:19 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 07:02:19 -0700 (PDT) In-Reply-To: <5360FD05.6030407@joelhalpern.com> References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> Date: Wed, 30 Apr 2014 07:02:19 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e0158a9e42ee7f504f842ff74 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vqJzh7GmWFhhVR9guesxpWQ__oI Cc: Nitin Bahadur , "i2rs@ietf.org" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org, Susan Hares Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:02:24 -0000 --089e0158a9e42ee7f504f842ff74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern wrote= : > I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if permission> pairs. > > This is not specific to the RIB model, and should not be in the rib model > at all as far as I can tell. > > Separate from the definition of role, and again applicable across all > information models, an agent may itself have access restrictions. A clie= nt > using an agent is restricted to the access set which is permitted both by > its role and by what the agent has permission to do. > > Again, if we want to model that, we should model it outside of any > specific IM. > > NETCONF and RESTCONF already have a standard Role-Based Access Control Model, called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, leave it to vendors, or something else? > Yours, > Joel > Andy > > On 4/30/14, 7:26 AM, Susan Hares wrote: > >> Joel: >> >> Great! This is the answer I hoped to get. Just to make sure, We are >> defining a role as: identity + rib tree + access (read or write or >> read-write). >> If I define a tree portion that is read-only does that align with our ro= le >> definitions. >> >> If this is a common definition, then I'm good to release the next versio= n >> of >> the draft with read/write for the RIB-info. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org >> Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org >> Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 >> >> Remember that an information model is not a grammar. It is perfectly ok= ay >> in an IM to have two branches that are just different things. >> Discriminators are added in when one goes from teh information model to >> the >> data model. >> >> Yours, >> Joel >> >> On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >> >>> Hi Sue, >>> >>> >>>> >>>> >>>> 4) Would a corrections to the above be useful: >>>>> Given the above you could simplify your match RBNF: >>>>> >>>>> :: =3D [ipv4-route | ipv6-route | >>>>> mpls-route >>>>> | mac-route] >>>>> >>>> >>>> [Nitin] The is not needed for mpls and mac routes=C5=A0.sinc= e >>>> MPLS has no concept of SRC or DEST. So that simplification will >>>> actually not help :( >>>> >>>> [Sue]: Yes, not all forms would benefit. However, MPLS does have the >>>> stack tags that we may want to save and match on. Also: the 5-tuples >>>> may be a part of matching some routes. By using rt-form, we are >>>> using the TLV format to set-up these multiple formats. Each format, >>>> would have the appropriate expectations for the appropriate address >>>> families. >>>> >>>> [Sue]: I think it provides table based code. >>>> >>> >>> The main issue is that the grammar will not be deterministic. In other >>> words, one needs a way to specify that is >>> valid and is NOT valid. >>> >>> >>> >>>> The will need to be associated specifically with >>>> and . >>>> >>>> [Sue]: yes, it could. With the rt-form and the rib-family type, >>>> perhaps we can remove the rt-type. >>>> [snip] >>>> >>> >>> Rib-family-type and route-type are kind of the same thing. I need to >>> think if there is a case where they can be different... >>> >>> >>> >>>> 5) Why did you specify differently? >>>>> >>>>> multicast-source-ipv4-address ::=3D >>>>> multicast-source-ipv6-address ::=3D >>>>> >>>>> Where you trying to express some checking that the node should have >>>>> on these address? >>>>> >>>> >>>> Thanks for catching this. They have no reference in the -02 version. >>>> They are a remnant of -00 of the draft. After the grammar was >>>> modified in -01, they should have been deleted. >>>> >>>> Here's the next question - how were you planning to handle the >>>> multiple next-hops for the multicast. Did you have a plan? >>>> >>>> You will have both ECMP (unicast) multiple nexthops, >>>> >>> >>> Unicast multiple next hops are covered in Section 7.2.3. >>> >>> >>> and multicast replication next hops. >>>> >>> >>> Section 7.3 talks about multicast replication (and refers to Section >>> 7.2.2). >>> >>> >>> A flag might do nicely to differentiate. >>>> We could put this on the next hop. >>>> >>> >>> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >>> indicate ECMP/load-balancing. >>> >>> >>> >>> Thanks >>> Nitin >>> >>> >>> _______________________________________________ >>> 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 > --089e0158a9e42ee7f504f842ff74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern = <jmh@joelhalper= n.com> wrote:
I do not think that matches the definition o= f role we are using.
An identity has a role. =C2=A0Several identities may have the same role. And a role is defined by a collections if <im-tree-portion, access permi= ssion> pairs.

This is not specific to the RIB model, and should not be in the rib model a= t all as far as I can tell.

Separate from the definition of role, and again applicable across all infor= mation models, an agent may itself have access restrictions. =C2=A0A client= using an agent is restricted to the access set which is permitted both by = its role and by what the agent has permission to do.

Again, if we want to model that, we should model it outside of any specific= IM.


NETCONF and RESTCONF already have a st= andard Role-Based Access Control Model,
called NACM (RFC 6536). = =C2=A0Does the I2RS WG plan to create its own ACM, leave it
to ve= ndors, or something else?

=C2=A0
Yours,
Joel

Andy
=C2=A0

On 4/30/14, 7:26 AM, Susan Hares wrote:
Joel:

Great! =C2=A0This is the answer I hoped to get. =C2=A0Just to make sure, = =C2=A0We are
defining a role as: =C2=A0identity + rib tree + access (read or write or read-write).
If I define a tree portion that is read-only does that align with our role<= br> definitions.

If this is a common definition, then I'm good to release the next versi= on of
the draft with read/write for the RIB-info.

Sue

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Tuesday, April 29, 2014 10:20 AM
To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org
Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-= 01

Remember that an information model is not a grammar. =C2=A0It is perfectly = okay
in an IM to have two branches that are just different things.
Discriminators are added in when one goes from teh information model to the=
data model.

Yours,
Joel

On 4/29/14, 2:36 AM, Nitin Bahadur wrote:
Hi Sue,




4) Would a corrections to the above be useful:
Given the above you could simplify your match RBNF:

<match>:: =3D <route-tag> <rt-form> [ipv4-route | ipv6-ro= ute |
mpls-route
| mac-route]

[Nitin] The <rt-form> is not needed for mpls and mac routes=C5=A0.sin= ce
MPLS has no concept of SRC or DEST. So that simplification will
actually not help :(

[Sue]: Yes, not all forms would benefit. =C2=A0However, MPLS does have the<= br> stack tags that we may want to save and match on. =C2=A0Also: the 5-tuples<= br> may be a part of matching some routes. =C2=A0By using rt-form, we are
using the TLV format to set-up these multiple formats. =C2=A0Each format, would have the appropriate expectations for the appropriate address
families.

[Sue]: =C2=A0I think it provides table based code.

The main issue is that the grammar will not be deterministic. In other
words, one needs a way to specify that <route-tag-1> <rt-form-A>= ; is
valid and <route-tag-1> <rt-form-B> is NOT valid.



The <ip-route-type> will need to be associated specifically with
<ipv4-route> and <ipv6-route>.

[Sue]: yes, it could. =C2=A0With the rt-form and the rib-family type,
perhaps we can remove the rt-type.
[snip]

Rib-family-type and route-type are kind of the same thing. I need to
think if there is a case where they can be different...



5) Why did you specify differently?

multicast-source-ipv4-address ::=3D<IPv4-Address> <IPV4_PREFIX_LEN= GTH>
multicast-source-ipv6-address ::=3D<IPv6-Address><IPV6_PREFIX_<= /u>LENGTH>

Where you trying to express some checking that the node should have
on these address?

Thanks for catching this. They have no reference in the -02 version.
They are a remnant of -00 of the draft. After the grammar was
modified in -01, they should have been deleted.

Here's the next question - how were you planning to handle the
multiple next-hops for the multicast. =C2=A0Did you have a plan?

You will have both ECMP (unicast) multiple nexthops,

Unicast multiple next hops are covered in Section 7.2.3.


and multicast replication next hops.

Section 7.3 talks about multicast replication (and refers to Section
7.2.2).


A flag might do nicely to differentiate.
We could put this on the next hop.

LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to
indicate ECMP/load-balancing.



Thanks
Nitin


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



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

--089e0158a9e42ee7f504f842ff74-- From nobody Wed Apr 30 07:14:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357C11A08DF for ; Wed, 30 Apr 2014 07:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJxG_zJccPHJ for ; Wed, 30 Apr 2014 07:14:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 870501A078F for ; Wed, 30 Apr 2014 07:14:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4EA3C2408F9; Wed, 30 Apr 2014 07:14:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-96.clppva.east.verizon.net [70.106.134.96]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C74A42401E2; Wed, 30 Apr 2014 07:14:06 -0700 (PDT) Message-ID: <53610524.7050600@joelhalpern.com> Date: Wed, 30 Apr 2014 10:13:56 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Bierman References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uIJ4xcOAogJJPnT_Bz2JZCh3Poc Cc: Nitin Bahadur , "i2rs@ietf.org" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org, Susan Hares Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:14:11 -0000 There are at least two reasons why I at least find the reasonable quesiton you have asked to be difficult to answer. First, it is not at all obvious that manipulation of the access control is within scope for I2RS. The permissions may not even be defined and manipulated on the same device where the I2RS agent resides. Second, we are working on an information model. RFC 6536 is a data model, and specific to the NetConf/YANG data model. Personally, as I have said repeatedly, I do not see any reason for us to have an information model for this until we conclude that there is some manipulation of it which is within scope. Yours, Joel On 4/30/14, 10:02 AM, Andy Bierman wrote: > > > > On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern > wrote: > > I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if permission> pairs. > > This is not specific to the RIB model, and should not be in the rib > model at all as far as I can tell. > > Separate from the definition of role, and again applicable across > all information models, an agent may itself have access > restrictions. A client using an agent is restricted to the access > set which is permitted both by its role and by what the agent has > permission to do. > > Again, if we want to model that, we should model it outside of any > specific IM. > > > NETCONF and RESTCONF already have a standard Role-Based Access Control > Model, > called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, > leave it > to vendors, or something else? > > Yours, > Joel > > > Andy > > > On 4/30/14, 7:26 AM, Susan Hares wrote: > > Joel: > > Great! This is the answer I hoped to get. Just to make sure, > We are > defining a role as: identity + rib tree + access (read or write or > read-write). > If I define a tree portion that is read-only does that align > with our role > definitions. > > If this is a common definition, then I'm good to release the > next version of > the draft with read/write for the RIB-info. > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com > ] > Sent: Tuesday, April 29, 2014 10:20 AM > To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org > > Cc: draft-ietf-i2rs-rib-info-__model@tools.ietf.org > > Subject: Re: [i2rs] Some comments on > draft-ietf-i2rs-rib-info-__model-01 > > Remember that an information model is not a grammar. It is > perfectly okay > in an IM to have two branches that are just different things. > Discriminators are added in when one goes from teh information > model to the > data model. > > Yours, > Joel > > On 4/29/14, 2:36 AM, Nitin Bahadur wrote: > > Hi Sue, > > > > > 4) Would a corrections to the above be useful: > Given the above you could simplify your match RBNF: > > :: = [ipv4-route | > ipv6-route | > mpls-route > | mac-route] > > > [Nitin] The is not needed for mpls and mac > routesÅ .since > MPLS has no concept of SRC or DEST. So that > simplification will > actually not help :( > > [Sue]: Yes, not all forms would benefit. However, MPLS > does have the > stack tags that we may want to save and match on. Also: > the 5-tuples > may be a part of matching some routes. By using > rt-form, we are > using the TLV format to set-up these multiple formats. > Each format, > would have the appropriate expectations for the > appropriate address > families. > > [Sue]: I think it provides table based code. > > > The main issue is that the grammar will not be > deterministic. In other > words, one needs a way to specify that > is > valid and is NOT valid. > > > > The will need to be associated > specifically with > and . > > [Sue]: yes, it could. With the rt-form and the > rib-family type, > perhaps we can remove the rt-type. > [snip] > > > Rib-family-type and route-type are kind of the same thing. I > need to > think if there is a case where they can be different... > > > > 5) Why did you specify differently? > > multicast-source-ipv4-address ::= > > multicast-source-ipv6-address > ::= > > Where you trying to express some checking that the > node should have > on these address? > > > Thanks for catching this. They have no reference in the > -02 version. > They are a remnant of -00 of the draft. After the > grammar was > modified in -01, they should have been deleted. > > Here's the next question - how were you planning to > handle the > multiple next-hops for the multicast. Did you have a plan? > > You will have both ECMP (unicast) multiple nexthops, > > > Unicast multiple next hops are covered in Section 7.2.3. > > > and multicast replication next hops. > > > Section 7.3 talks about multicast replication (and refers to > Section > 7.2.2). > > > A flag might do nicely to differentiate. > We could put this on the next hop. > > > LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to > indicate ECMP/load-balancing. > > > > Thanks > Nitin > > > _________________________________________________ > 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 nobody Wed Apr 30 07:20:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D6C1A6F24 for ; Wed, 30 Apr 2014 07:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUahrjtjyLQV for ; Wed, 30 Apr 2014 07:20:01 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE031A078F for ; Wed, 30 Apr 2014 07:20:01 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DEC832789496; Wed, 30 Apr 2014 10:19:59 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5EBBA659-E593-4B3A-B797-C362ADFAE290"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 30 Apr 2014 10:19:59 -0400 Message-Id: References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eNt6CcREi5D06jkiusih2Wt6Drg Cc: b nitin , "i2rs@ietf.org" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org, "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:20:04 -0000 --Apple-Mail=_5EBBA659-E593-4B3A-B797-C362ADFAE290 Content-Type: multipart/alternative; boundary="Apple-Mail=_690212E0-471C-4801-A837-1FF5C95AD0EC" --Apple-Mail=_690212E0-471C-4801-A837-1FF5C95AD0EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2014:10:02 AM, at 10:02 AM, Andy Bierman = wrote: >=20 >=20 >=20 > On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern = wrote: > I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if pairs. >=20 > This is not specific to the RIB model, and should not be in the rib = model at all as far as I can tell. >=20 > Separate from the definition of role, and again applicable across all = information models, an agent may itself have access restrictions. A = client using an agent is restricted to the access set which is permitted = both by its role and by what the agent has permission to do. >=20 > Again, if we want to model that, we should model it outside of any = specific IM. >=20 >=20 > NETCONF and RESTCONF already have a standard Role-Based Access Control = Model, > called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, = leave it > to vendors, or something else? It was very much my understanding/intention to use RFC6536. =09 --Tom >=20 > =20 > Yours, > Joel >=20 > Andy > =20 >=20 > On 4/30/14, 7:26 AM, Susan Hares wrote: > Joel: >=20 > Great! This is the answer I hoped to get. Just to make sure, We are > defining a role as: identity + rib tree + access (read or write or > read-write). > If I define a tree portion that is read-only does that align with our = role > definitions. >=20 > If this is a common definition, then I'm good to release the next = version of > the draft with read/write for the RIB-info. >=20 > Sue >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 29, 2014 10:20 AM > To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org > Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 >=20 > Remember that an information model is not a grammar. It is perfectly = okay > in an IM to have two branches that are just different things. > Discriminators are added in when one goes from teh information model = to the > data model. >=20 > Yours, > Joel >=20 > On 4/29/14, 2:36 AM, Nitin Bahadur wrote: > Hi Sue, >=20 >=20 >=20 >=20 > 4) Would a corrections to the above be useful: > Given the above you could simplify your match RBNF: >=20 > :: =3D [ipv4-route | ipv6-route | > mpls-route > | mac-route] >=20 > [Nitin] The is not needed for mpls and mac routes=8A.since > MPLS has no concept of SRC or DEST. So that simplification will > actually not help :( >=20 > [Sue]: Yes, not all forms would benefit. However, MPLS does have the > stack tags that we may want to save and match on. Also: the 5-tuples > may be a part of matching some routes. By using rt-form, we are > using the TLV format to set-up these multiple formats. Each format, > would have the appropriate expectations for the appropriate address > families. >=20 > [Sue]: I think it provides table based code. >=20 > The main issue is that the grammar will not be deterministic. In other > words, one needs a way to specify that is > valid and is NOT valid. >=20 >=20 >=20 > The will need to be associated specifically with > and . >=20 > [Sue]: yes, it could. With the rt-form and the rib-family type, > perhaps we can remove the rt-type. > [snip] >=20 > Rib-family-type and route-type are kind of the same thing. I need to > think if there is a case where they can be different... >=20 >=20 >=20 > 5) Why did you specify differently? >=20 > multicast-source-ipv4-address ::=3D > multicast-source-ipv6-address ::=3D >=20 > Where you trying to express some checking that the node should have > on these address? >=20 > Thanks for catching this. They have no reference in the -02 version. > They are a remnant of -00 of the draft. After the grammar was > modified in -01, they should have been deleted. >=20 > Here's the next question - how were you planning to handle the > multiple next-hops for the multicast. Did you have a plan? >=20 > You will have both ECMP (unicast) multiple nexthops, >=20 > Unicast multiple next hops are covered in Section 7.2.3. >=20 >=20 > and multicast replication next hops. >=20 > Section 7.3 talks about multicast replication (and refers to Section > 7.2.2). >=20 >=20 > A flag might do nicely to differentiate. > We could put this on the next hop. >=20 > LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to > indicate ECMP/load-balancing. >=20 >=20 >=20 > Thanks > Nitin >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=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=_690212E0-471C-4801-A837-1FF5C95AD0EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 30, 2014:10:02 AM, at 10:02 AM, = Andy Bierman <andy@yumaworks.com> = wrote:




On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern = <jmh@joelhalpern.com> wrote:
I do not think that = matches the definition of role we are using.
An identity has a role.  Several identities may have the same = role.
And a role is defined by a collections if <im-tree-portion, access = permission> pairs.

This is not specific to the RIB model, and should not be in the rib = model at all as far as I can tell.

Separate from the definition of role, and again applicable across all = information models, an agent may itself have access restrictions. =  A client using an agent is restricted to the access set which is = permitted both by its role and by what the agent has permission to = do.

Again, if we want to model that, we should model it outside of any = specific IM.


NETCONF and RESTCONF already have a = standard Role-Based Access Control Model,
called NACM (RFC = 6536).  Does the I2RS WG plan to create its own ACM, leave = it
to vendors, or something = else?

It was = very much my understanding/intention to use RFC6536.
=
= --Tom



 
Yours,
= Joel

Andy
 

On 4/30/14, 7:26 AM, Susan Hares wrote:
Joel:

Great!  This is the answer I hoped to get.  Just to make sure, =  We are
defining a role as:  identity + rib tree + access (read or write = or
read-write).
If I define a tree portion that is read-only does that align with our = role
definitions.

If this is a common definition, then I'm good to release the next = version of
the draft with read/write for the RIB-info.

Sue

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Tuesday, April 29, 2014 10:20 AM
To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org
Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org=
Subject: Re: [i2rs] Some comments on = draft-ietf-i2rs-rib-info-model-01

Remember that an information model is not a grammar.  It is = perfectly okay
in an IM to have two branches that are just different things.
Discriminators are added in when one goes from teh information model to = the
data model.

Yours,
Joel

On 4/29/14, 2:36 AM, Nitin Bahadur wrote:
Hi Sue,




4) Would a corrections to the above be useful:
Given the above you could simplify your match RBNF:

<match>:: =3D <route-tag> <rt-form> [ipv4-route | = ipv6-route |
mpls-route
| mac-route]

[Nitin] The <rt-form> is not needed for mpls and mac = routes=8A.since
MPLS has no concept of SRC or DEST. So that simplification will
actually not help :(

[Sue]: Yes, not all forms would benefit.  However, MPLS does have = the
stack tags that we may want to save and match on.  Also: the = 5-tuples
may be a part of matching some routes.  By using rt-form, we = are
using the TLV format to set-up these multiple formats.  Each = format,
would have the appropriate expectations for the appropriate address
families.

[Sue]:  I think it provides table based code.

The main issue is that the grammar will not be deterministic. In = other
words, one needs a way to specify that <route-tag-1> = <rt-form-A> is
valid and <route-tag-1> <rt-form-B> is NOT valid.



The <ip-route-type> will need to be associated specifically = with
<ipv4-route> and <ipv6-route>.

[Sue]: yes, it could.  With the rt-form and the rib-family = type,
perhaps we can remove the rt-type.
[snip]

Rib-family-type and route-type are kind of the same thing. I need to
think if there is a case where they can be different...



5) Why did you specify differently?

multicast-source-ipv4-address ::=3D<IPv4-Address> = <IPV4_PREFIX_LENGTH>
multicast-source-ipv6-address = ::=3D<IPv6-Address><IPV6_PREFIX_LENGTH>

Where you trying to express some checking that the node should have
on these address?

Thanks for catching this. They have no reference in the -02 version.
They are a remnant of -00 of the draft. After the grammar was
modified in -01, they should have been deleted.

Here's the next question - how were you planning to handle the
multiple next-hops for the multicast.  Did you have a plan?

You will have both ECMP (unicast) multiple nexthops,

Unicast multiple next hops are covered in Section 7.2.3.


and multicast replication next hops.

Section 7.3 talks about multicast replication (and refers to Section
7.2.2).


A flag might do nicely to differentiate.
We could put this on the next hop.

LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to
indicate ECMP/load-balancing.



Thanks
Nitin


_______________________________________________
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/ma= ilman/listinfo/i2rs

= --Apple-Mail=_690212E0-471C-4801-A837-1FF5C95AD0EC-- --Apple-Mail=_5EBBA659-E593-4B3A-B797-C362ADFAE290 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTYQaPAAoJEPcO+I7eiUJZaP0QAKrvmDY9O7TQMLc3YEC5cgW1 AEK5ToPG+3GY0otIYOOuLx7kuxSNpqWWzETZp+J9g20CqI4j2qyKDFlMh2DrpzKu DP8soyj2L9ajR9A/pj+CCNemFdDQ0juoR+4zUqnsv5sUCQdN//YTkkjnXO8ua9qH uXjqhakt7ximj7qMeBemjT87+kiUAnPZgwex3zeIXkr3gdOXeljjCBI/Au3DfMxx nYM6NXbMoUjl5GPmzFp0xVgY9aTps+Sya2fZlo1LUkoRtLwayOOYjsObgbbSEOkz kyQdP/bDtSgMao0w8jQh2GHyhv4SQTyPgLKeRJ4+sjFPqHB1dE9PBVLlROtd++Cv DOZ3OlSDckaG44XGMIGReLUdZy0VrGc0MpOCqcmcJBiiu9woRQCPwTnTBYCNMbM8 oK9UpzG+pswZ5Si+yf1aqWu3Z80gvwIVCkPyZN/w03HPBcmUyTtVq4lX8TmVPclG HaMPFlsGEV2lUKlltkgh0yaufg+fCi/s5nbDB0+vJoJeIx1HtekmvRUpsG5C4KfH rhpnr50C4pW87FnvBt+QhoSr9HntHOZaZjdGfPsFlyioVKya0efgCiGfEnIGJ4/V 80jdpbXmvXGVbFrScCCLiXvq/ypUpnE1kVtxvrGRH+ygt9nbHiZ27yG1NuhCETWI DDMcU4d9wUSNuRvlD3eF =3k0P -----END PGP SIGNATURE----- --Apple-Mail=_5EBBA659-E593-4B3A-B797-C362ADFAE290-- From nobody Wed Apr 30 07:29:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18B1A6F92 for ; Wed, 30 Apr 2014 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkvFV-PdCrri for ; Wed, 30 Apr 2014 07:29:12 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1071A08F6 for ; Wed, 30 Apr 2014 07:29:12 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 14:29:08 +0000 Message-ID: <008301cf6480$3e99ebe0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Susan Hares , 'Edward Crabbe' , References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <010a01cf5f10$2498c1a0$6dca44e0$@ndzh.com> <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> Date: Wed, 30 Apr 2014 15:25:06 +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.252.181] X-ClientProxiedBy: DB4PR07CA029.eurprd07.prod.outlook.com (10.242.229.39) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0197AFBD92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(51704005)(51444003)(377454003)(189002)(199002)(62236002)(44716002)(66066001)(20776003)(84392001)(92726001)(99396002)(88136002)(33646001)(77156001)(87286001)(79102001)(87976001)(81686999)(50986999)(76176999)(80022001)(80976001)(46102001)(86362001)(81542001)(92566001)(61296002)(93916002)(76482001)(42186004)(50226001)(44736004)(85852003)(14496001)(4396001)(31966008)(74662001)(62966002)(50466002)(575784001)(19580395003)(81342001)(77982001)(47776003)(83322001)(19580405001)(101416001)(83072002)(81816999)(89996001)(23756003)(74502001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0610HT003.eurprd06.prod.outlook.com; FPR:E60FF02B.A36A9F3B.71D31D3B.50E5C969.2051D; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/J6QPUNRgWgWBWErPwGoAkEf3u2Q Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:29:15 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" ; "Susan Hares" ; "'Edward Crabbe'" ; Sent: Thursday, April 24, 2014 3:27 PM > "t.petch" writes: > > ----- Original Message ----- > > From: "Susan Hares" > > To: "'t.petch'" ; "'Edward Crabbe'" > > ; > > Sent: Wednesday, April 23, 2014 5:21 PM > >> Tom: > >> > >> 100% agree with your comments. I2RS cares whether it is read-only or > >> read-write. My work toward the revision found: > >> > >> - RBNF RBNF did not even allow you a place to r/w or r-only or > > permissions > >> (needed for security, but that's my next draft). > >> - The yang tree I wrote was r-w for config, but did not express the > > ro-only > >> tree. I wanted some feedback to figure out why I had 2 write 2 trees. > >> (your telling me it is a yang short-coming). > > > > Sue > > > > That is a feature of YANG. Spend half a day on the netmod WG archives > > for 1H2013, particularly May and June and for interfaces-cfg, and all > > will be clear. > > > > As Ladislav said on 2May13, > > > > "In the current model, the operational state data are not present unless > > the corresponding entry in the "interface" list is *configured*. So, > > what I have in mind is a data tree like this: ..." > > > > That is, 'config false' nodes under a 'config true' node do not get > > instantiated in the data model unless and until the 'config true' node > > is configured. So if you have the one routing table, you will be unable > > This issue only affects 'config false' data appearing in the subtree of a 'config true' node. > In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. > > > to see the routes learnt via BGP - 'config false' - unless and until you > > configure the table by creating a static route - 'config true'. > > Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration. > > > > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > > where it is written down:-( > > Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. Lada I find the I-D slightly inconsistent and incomplete on this matter. I find it inconsistent in its definition of user-controlled entry. s2.1 " user-controlled entry: An entry of a list in operational state data ("config false") ... " versus s4.1 " Additional entries may be created in the configuration by the user via the NETCONF protocol. These are so-called user-controlled entries. " where configuration means, to me, configuration which is then not operational state. Also in s4.1 " Deleting a user-controlled entry from the configuration list results .........." suggests to me again that user-controlled entries can appear in the configuration. Given the length and quantity of discussion on this issue over the years, I think that precision is called for. I am easy as to whether user-controlled entries can appear in configuration and operational state, or only in operational state, but think that the I-D needs to be precise and consistent. If you take the latter option, then you probably need a new term to describe entries in a configuration list that correspond to entries in an operational state list in order to specify the interactions arising from operations on the entry in the configuration. Separately, most discussions, although not all I-Ds, split two ways, into configuration and state and may then subdivide state into operational state and read-only statistics. This I-D seems not to allow for read-only statistics, and seems to use state and operational state interchangeably. Again, I think that precision is called for. I2RS may be interested in statistics. And the point I first raised, of when state is instantiated in the data model, I do not see covered here (not that I was too hopeful that it would be:-( As you say, above, > This issue only affects 'config false' data appearing in the subtree of a 'config true' node. but given the quantity of discussion arising from it a year ago, I still think that it is a pitfall that should be written down. I keep this on the I2RS list since I imagine that these issues may arise as and when YANG is used to create I2RS models. Tom Petch > I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work. > > Lada > > > > > Tom Petch > > > >> Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Wed Apr 30 07:43:21 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344F1A08F1 for ; Wed, 30 Apr 2014 07:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_hykUU5DLWC for ; Wed, 30 Apr 2014 07:43:17 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id A31DD1A08D7 for ; Wed, 30 Apr 2014 07:43:17 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id m5so1769707qaj.1 for ; Wed, 30 Apr 2014 07:43:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u+/suMnKodjnvK7p6IYmCrcykFg3HFTRU6M+9P+j92M=; b=PsSrXH5EC8pI3KSkYPl/mvR01jj8lxfpVnUHW6AizAl3/qRIBFTMhO9mhYS4hBX+pT Li2sD1bNO7IQVQrRSWSYcMKURHGLWX3TiFWQuvz3NQAcXJn0qA//nBugPw+kogbPxE3K av+miDkg/1lLa6dhzwQsq6ge5ANrJekQIhkAVlrTZcUSESvCHgDjjFJU2H+dvTRXA1qe UFXrvYQZOJEs7hnPJalPMyqYzrnpWTgKyQn1bmo6dafF+362x4BAmpP9D4zVZF6nPWMz INlUQuJEa0cpKukiG/zXw6ZLJ9Hevir1rUbm33o42sHr+kMZjqB9LfCBUCx9+CMo8aYA 4pVQ== X-Gm-Message-State: ALoCoQlZsbf43SzHaE22i+bIhn1lNaHdzjaTKyRBYuqBJF50tVVc6x/dq721ELmP7uKBYHAH3w6t MIME-Version: 1.0 X-Received: by 10.140.27.212 with SMTP id 78mr5591932qgx.18.1398868995891; Wed, 30 Apr 2014 07:43:15 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 07:43:15 -0700 (PDT) In-Reply-To: <53610524.7050600@joelhalpern.com> References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <53610524.7050600@joelhalpern.com> Date: Wed, 30 Apr 2014 07:43:15 -0700 Message-ID: From: Andy Bierman To: Joel Halpern Direct Content-Type: multipart/alternative; boundary=001a11c14d66967b5604f8439140 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gw10yt7aCYYI6bhC_MpCgLaA_io Cc: Nitin Bahadur , "i2rs@ietf.org" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org, Susan Hares Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:43:20 -0000 --001a11c14d66967b5604f8439140 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2014 at 7:13 AM, Joel Halpern Direct < jmh.direct@joelhalpern.com> wrote: > There are at least two reasons why I at least find the reasonable quesito= n > you have asked to be difficult to answer. > > First, it is not at all obvious that manipulation of the access control i= s > within scope for I2RS. The permissions may not even be defined and > manipulated on the same device where the I2RS agent resides. > > Agreed. Vendors and operators would prefer a single ACM that applies to all protocols. (Even though NACM says it is only for NETCONF, nobody implements it that way. CLI, WEBui, RESTCONF, etc. all use the same authorization rules. Second, we are working on an information model. RFC 6536 is a data model, > and specific to the NetConf/YANG data model. > > Most of it is YANG-specific, not NETCONF-specific. The access rules are based on YANG statements. But only the behavior for the NETCONF protocol is defined in detail. I doubt NACM could be used without additional text in some I2RS RFC. Personally, as I have said repeatedly, I do not see any reason for us to > have an information model for this until we conclude that there is some > manipulation of it which is within scope. > > Agreed. The info model and the data model are written (mostly) independent of access control. Yours, > Joel > Andy > > On 4/30/14, 10:02 AM, Andy Bierman wrote: > >> >> >> >> On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern > > wrote: >> >> I do not think that matches the definition of role we are using. >> An identity has a role. Several identities may have the same role. >> And a role is defined by a collections if > permission> pairs. >> >> This is not specific to the RIB model, and should not be in the rib >> model at all as far as I can tell. >> >> Separate from the definition of role, and again applicable across >> all information models, an agent may itself have access >> restrictions. A client using an agent is restricted to the access >> set which is permitted both by its role and by what the agent has >> permission to do. >> >> Again, if we want to model that, we should model it outside of any >> specific IM. >> >> >> NETCONF and RESTCONF already have a standard Role-Based Access Control >> Model, >> called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, >> leave it >> to vendors, or something else? >> >> Yours, >> Joel >> >> >> Andy >> >> >> On 4/30/14, 7:26 AM, Susan Hares wrote: >> >> Joel: >> >> Great! This is the answer I hoped to get. Just to make sure, >> We are >> defining a role as: identity + rib tree + access (read or write >> or >> read-write). >> If I define a tree portion that is read-only does that align >> with our role >> definitions. >> >> If this is a common definition, then I'm good to release the >> next version of >> the draft with read/write for the RIB-info. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org >> >> Cc: draft-ietf-i2rs-rib-info-__model@tools.ietf.org >> >> Subject: Re: [i2rs] Some comments on >> draft-ietf-i2rs-rib-info-__model-01 >> >> Remember that an information model is not a grammar. It is >> perfectly okay >> in an IM to have two branches that are just different things. >> Discriminators are added in when one goes from teh information >> model to the >> data model. >> >> Yours, >> Joel >> >> On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >> >> Hi Sue, >> >> >> >> >> 4) Would a corrections to the above be useful: >> Given the above you could simplify your match RBNF: >> >> :: =3D [ipv4-route | >> ipv6-route | >> mpls-route >> | mac-route] >> >> >> [Nitin] The is not needed for mpls and mac >> routes=C5=A0.since >> MPLS has no concept of SRC or DEST. So that >> simplification will >> actually not help :( >> >> [Sue]: Yes, not all forms would benefit. However, MPLS >> does have the >> stack tags that we may want to save and match on. Also: >> the 5-tuples >> may be a part of matching some routes. By using >> rt-form, we are >> using the TLV format to set-up these multiple formats. >> Each format, >> would have the appropriate expectations for the >> appropriate address >> families. >> >> [Sue]: I think it provides table based code. >> >> >> The main issue is that the grammar will not be >> deterministic. In other >> words, one needs a way to specify that >> is >> valid and is NOT valid. >> >> >> >> The will need to be associated >> specifically with >> and . >> >> [Sue]: yes, it could. With the rt-form and the >> rib-family type, >> perhaps we can remove the rt-type. >> [snip] >> >> >> Rib-family-type and route-type are kind of the same thing. I >> need to >> think if there is a case where they can be different... >> >> >> >> 5) Why did you specify differently? >> >> multicast-source-ipv4-address ::=3D >> >> multicast-source-ipv6-address >> ::=3D >> >> Where you trying to express some checking that the >> node should have >> on these address? >> >> >> Thanks for catching this. They have no reference in the >> -02 version. >> They are a remnant of -00 of the draft. After the >> grammar was >> modified in -01, they should have been deleted. >> >> Here's the next question - how were you planning to >> handle the >> multiple next-hops for the multicast. Did you have a >> plan? >> >> You will have both ECMP (unicast) multiple nexthops, >> >> >> Unicast multiple next hops are covered in Section 7.2.3. >> >> >> and multicast replication next hops. >> >> >> Section 7.3 talks about multicast replication (and refers to >> Section >> 7.2.2). >> >> >> A flag might do nicely to differentiate. >> We could put this on the next hop. >> >> >> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used >> to >> indicate ECMP/load-balancing. >> >> >> >> Thanks >> Nitin >> >> >> _________________________________________________ >> 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 >> >> >> >> --001a11c14d66967b5604f8439140 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 30, 2014 at 7:13 AM, Joel Halpern Direct <jmh= .direct@joelhalpern.com> wrote:
There are at least two reasons why I at leas= t find the reasonable quesiton you have asked to be difficult to answer.
First, it is not at all obvious that manipulation of the access control is = within scope for I2RS. =C2=A0The permissions may not even be defined and ma= nipulated on the same device where the I2RS agent resides.


Agreed. =C2=A0Vendors and operators wo= uld prefer a single ACM that applies
to all protocols. (Even thou= gh NACM says it is only for NETCONF, nobody
implements it that wa= y. CLI, WEBui, RESTCONF, etc. all use the same
authorization rules.

Personally, as I have said repeatedly, I do not see any reason for us to ha= ve an information model for this until we conclude that there is some manip= ulation of it which is within scope.


Agreed.
The info model and t= he data model are written (mostly) independent
of access control.= =C2=A0

Yours,
Joel

Andy
=C2=A0

On 4/30/14, 10:02 AM, Andy Bierman wrote:



On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 I do not think that matches the definition of role we are usi= ng.
=C2=A0 =C2=A0 An identity has a role. =C2=A0Several identities may have the= same role.
=C2=A0 =C2=A0 And a role is defined by a collections if <im-tree-portion= , access
=C2=A0 =C2=A0 permission> pairs.

=C2=A0 =C2=A0 This is not specific to the RIB model, and should not be in t= he rib
=C2=A0 =C2=A0 model at all as far as I can tell.

=C2=A0 =C2=A0 Separate from the definition of role, and again applicable ac= ross
=C2=A0 =C2=A0 all information models, an agent may itself have access
=C2=A0 =C2=A0 restrictions. =C2=A0A client using an agent is restricted to = the access
=C2=A0 =C2=A0 set which is permitted both by its role and by what the agent= has
=C2=A0 =C2=A0 permission to do.

=C2=A0 =C2=A0 Again, if we want to model that, we should model it outside o= f any
=C2=A0 =C2=A0 specific IM.


NETCONF and RESTCONF already have a standard Role-Based Access Control
Model,
called NACM (RFC 6536). =C2=A0Does the I2RS WG plan to create its own ACM,<= br> leave it
to vendors, or something else?

=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel


Andy


=C2=A0 =C2=A0 On 4/30/14, 7:26 AM, Susan Hares wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Joel:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Great! =C2=A0This is the answer I hoped to get.= =C2=A0Just to make sure,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 defining a role as: =C2=A0identity + rib tree += access (read or write or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 read-write).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If I define a tree portion that is read-only do= es that align
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with our role
=C2=A0 =C2=A0 =C2=A0 =C2=A0 definitions.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If this is a common definition, then I'm go= od to release the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 next version of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the draft with read/write for the RIB-info.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sue

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Joel M. Halpern [mailto:jmh@joelhalpern.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:jmh@joelhalpern.com>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Tuesday, April 29, 2014 10:20 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Nitin Bahadur; Susan Hares; 'Mach Chen&= #39;; i2rs@ietf.org<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:i2rs@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: draft-ietf-i2rs-rib-info-__model@tools.ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:draft-ietf-i2rs-rib-i= nfo-model@tools.ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [i2rs] Some comments on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-i2rs-rib-info-__model-01

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Remember that an information model is not a gra= mmar. =C2=A0It is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 perfectly okay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in an IM to have two branches that are just dif= ferent things.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Discriminators are added in when one goes from = teh information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 model to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 data model.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Joel

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 4/29/14, 2:36 AM, Nitin Bahadur wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Sue,




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Wo= uld a corrections to the above be useful:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Given= the above you could simplify your match RBNF:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= atch>:: =3D <route-tag> <rt-form> [ipv4-route |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ipv6-= route |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mpls-= route
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | mac= -route]


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Nitin] The <rt-= form> is not needed for mpls and mac
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routes=C5=A0.since<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS has no concept= of SRC or DEST. So that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 simplification will=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actually not help := (

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Sue]: Yes, not all= forms would benefit. =C2=A0However, MPLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 does have the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stack tags that we = may want to save and match on. =C2=A0Also:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the 5-tuples
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may be a part of ma= tching some routes. =C2=A0By using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rt-form, we are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using the TLV forma= t to set-up these multiple formats.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Each format,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would have the appr= opriate expectations for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate address=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 families.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Sue]: =C2=A0I thin= k it provides table based code.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The main issue is that the gramma= r will not be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deterministic. In other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 words, one needs a way to specify= that <route-tag-1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rt-form-A> is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid and <route-tag-1> <= ;rt-form-B> is NOT valid.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The <ip-route-ty= pe> will need to be associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifically with =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ipv4-route> = and <ipv6-route>.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Sue]: yes, it coul= d. =C2=A0With the rt-form and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rib-family type, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 perhaps we can remo= ve the rt-type.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [snip]


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rib-family-type and route-type ar= e kind of the same thing. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 think if there is a case where th= ey can be different...



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5) Wh= y did you specify differently?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multi= cast-source-ipv4-address ::=3D<IPv4-Address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <I= PV4_PREFIX_LENGTH>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multi= cast-source-ipv6-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ::=3D= <IPv6-Address><IPV6_PREFIX___LENGTH>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Where= you trying to express some checking that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node = should have
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on th= ese address?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for catching= this. They have no reference in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -02 version.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 They are a remnant = of -00 of the draft. After the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 grammar was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 modified in -01, th= ey should have been deleted.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here's the next= question - how were you planning to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 handle the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple next-hops = for the multicast. =C2=A0Did you have a plan?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 You will have both = ECMP (unicast) multiple nexthops,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unicast multiple next hops are co= vered in Section 7.2.3.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and multicast repli= cation next hops.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 7.3 talks about multicast= replication (and refers to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7.2.2).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A flag might do nic= ely to differentiate.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We could put this o= n the next hop.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LOAD_BALANCE_WEIGHT is the flag o= n the next-hop that is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicate ECMP/load-balancing.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Nitin


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________________= ___________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i2rs@ietf.org <mailto:i2rs@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/_= _listinfo/i2rs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/i2rs>



=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 i2rs mailing list
=C2=A0 =C2=A0 i2rs@ietf.= org <mailto:i2rs@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/i2rs
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/i2rs>


--001a11c14d66967b5604f8439140-- From nobody Wed Apr 30 07:49:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCD91A08E8 for ; Wed, 30 Apr 2014 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT0LBZ1R0gCn for ; Wed, 30 Apr 2014 07:49:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 592CC1A6FD4 for ; Wed, 30 Apr 2014 07:49:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joel Halpern Direct'" , "'Nitin Bahadur'" , "'Mach Chen'" , References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> In-Reply-To: <53610252.4000800@joelhalpern.com> Date: Wed, 30 Apr 2014 10:49:21 -0400 Message-ID: <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhAKicq5hAnZX0SqcfyRMMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-uD2wWjqHjDtsIL0-iULTkJcEns Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:49:51 -0000 Joel: Ok - so I've got to get something to describe this:=20 (im-tree =3D portion definition 1, read-write) * (im-tree =3D portion = definition 2, read-only) * I'm trying to get a workable alternative to RBNF to discuss the actual im-tree. UML is best, but I'm not sure If I can it in the documents. 5 pages of UML covers all the RIB models. UML tools can create yang data models and forces (In my understanding). However, some human beings = seem to need the yang tree models to see the tree and links to yang.=20 I'm working through RIB-info so I can have a meaningful discussion on = the rest of the RIB models with precise language. And I need to know that = I've gotten a precise definition in order to finalize the security.=20 Help - online or offline would be useful. If you or anyone else sends offline help, I will summarizes to list. =20 Sue=20 -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Wednesday, April 30, 2014 10:02 AM To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; i2rs@ietf.org Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 As an Information model, treating the YANG tree as an info model has the problem that the information model is probably not a tree. There will = be a well-defined tree if the data model is YANG. But there is not such a restriction at the info model level. But I still don't understand why you even need to mention this in the = rib information model. Just for clarity, I would have written the permissions paradigm as: (im-tree =3D portion definition 1, read-write) * (im-tree =3D portion = definition 2, read-only) * Where the "*" indicates that each of those can occur 0 or more times. There is not a well defined information model notion of the rib-rw = section. Yours, Joel On 4/30/14, 9:53 AM, Susan Hares wrote: > Joel: > > Thank you for the clarification, I should have been clearer. = Identity is > uniquely defined by a security entity. > > Role =3D pairs of (im-tree-portion, access-permission) pairs > > If the IM model wants to have > (im-tree-portion =3D rib-rw section, read-write) pair > (im-tree-portion =3D rib-ro-section, read-only) pair > > Then this is the role of the client-agent pair. This assumes that=20 > agent can grant both the RIB structure has both r-w for configuration=20 > (as in the current document), and a read-only section (dynamic statistics). > > Therefore, If I understand correctly - I can utilize Yang-tree model=20 > as poor-man's Info-Model since it can both represent the r-w tree > (configuration) and the rib-ro tree for dynamics status. For the=20 > notifications sequence (it may config state (turn on/off reporting)=20 > and ro-state. > > Sue > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 30, 2014 9:39 AM > To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; i2rs@ietf.org > Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > > I do not think that matches the definition of role we are using. > An identity has a role. Several identities may have the same role. > And a role is defined by a collections if permission> pairs. > > This is not specific to the RIB model, and should not be in the rib=20 > model at all as far as I can tell. > > Separate from the definition of role, and again applicable across all=20 > information models, an agent may itself have access restrictions. A=20 > client using an agent is restricted to the access set which is=20 > permitted both by its role and by what the agent has permission to do. > > Again, if we want to model that, we should model it outside of any=20 > specific IM. > > Yours, > Joel > > On 4/30/14, 7:26 AM, Susan Hares wrote: >> Joel: >> >> Great! This is the answer I hoped to get. Just to make sure, We=20 >> are defining a role as: identity + rib tree + access (read or write=20 >> or read-write). >> If I define a tree portion that is read-only does that align with our = >> role definitions. >> >> If this is a common definition, then I'm good to release the next=20 >> version of the draft with read/write for the RIB-info. >> >> Sue >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org >> Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org >> Subject: Re: [i2rs] Some comments on=20 >> draft-ietf-i2rs-rib-info-model-01 >> >> Remember that an information model is not a grammar. It is perfectly = >> okay in an IM to have two branches that are just different things. >> Discriminators are added in when one goes from teh information model=20 >> to the data model. >> >> Yours, >> Joel >> >> On 4/29/14, 2:36 AM, Nitin Bahadur wrote: >>> Hi Sue, >>> >>>> >>>> >>>> >>>>> 4) Would a corrections to the above be useful: >>>>> Given the above you could simplify your match RBNF: >>>>> >>>>> :: =3D [ipv4-route | ipv6-route |=20 >>>>> mpls-route >>>>> | mac-route] >>>> >>>> [Nitin] The is not needed for mpls and mac = routes=A9.since=20 >>>> MPLS has no concept of SRC or DEST. So that simplification will=20 >>>> actually not help :( >>>> >>>> [Sue]: Yes, not all forms would benefit. However, MPLS does have=20 >>>> the stack tags that we may want to save and match on. Also: the=20 >>>> 5-tuples may be a part of matching some routes. By using rt-form,=20 >>>> we are using the TLV format to set-up these multiple formats. Each = >>>> format, would have the appropriate expectations for the appropriate = >>>> address families. >>>> >>>> [Sue]: I think it provides table based code. >>> >>> The main issue is that the grammar will not be deterministic. In=20 >>> other words, one needs a way to specify that =20 >>> is valid and is NOT valid. >>> >>> >>>> >>>> The will need to be associated specifically with=20 >>>> and . >>>> >>>> [Sue]: yes, it could. With the rt-form and the rib-family type,=20 >>>> perhaps we can remove the rt-type. >>>> [snip] >>> >>> Rib-family-type and route-type are kind of the same thing. I need to = >>> think if there is a case where they can be different... >>> >>> >>>> >>>>> 5) Why did you specify differently? >>>>> >>>>> multicast-source-ipv4-address ::=3D=20 >>>>> multicast-source-ipv6-address=20 >>>>> ::=3D >>>>> >>>>> Where you trying to express some checking that the node should=20 >>>>> have on these address? >>>> >>>> Thanks for catching this. They have no reference in the -02 = version. >>>> They are a remnant of -00 of the draft. After the grammar was=20 >>>> modified in -01, they should have been deleted. >>>> >>>> Here's the next question - how were you planning to handle the=20 >>>> multiple next-hops for the multicast. Did you have a plan? >>>> >>>> You will have both ECMP (unicast) multiple nexthops, >>> >>> Unicast multiple next hops are covered in Section 7.2.3. >>> >>> >>>> and multicast replication next hops. >>> >>> Section 7.3 talks about multicast replication (and refers to Section = >>> 7.2.2). >>> >>> >>>> A flag might do nicely to differentiate. >>>> We could put this on the next hop. >>> >>> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to=20 >>> indicate ECMP/load-balancing. >>> >>> >>> >>> Thanks >>> Nitin >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > From nobody Wed Apr 30 07:56:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0581A6F03 for ; Wed, 30 Apr 2014 07:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHbFxeBmBeCB for ; Wed, 30 Apr 2014 07:56:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 01E5B1A08F1 for ; Wed, 30 Apr 2014 07:56:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" , "'Joel M. Halpern'" References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> In-Reply-To: Date: Wed, 30 Apr 2014 10:56:36 -0400 Message-ID: <004e01cf6484$628de200$27a9a600$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CF6462.DB8A72D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhAHmIE/vnJi+t2A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cY9Fv2aW4jS95JkwaiQycOnJrv0 Cc: 'Nitin Bahadur' , i2rs@ietf.org, 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 14:56:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CF6462.DB8A72D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy: =20 My goal is not to invent something new, so as an expert in = netconf/restconf role-based access control model could you:=20 =20 1 =E2=80=93 comment if this can be handle by netconf/restconf =20 Identity + role pairs =20 2 =E2=80=93 provide me with references to these RFCs that I should pull = out to reference to identify how this could be expressed?=20 =20 =20 =20 NETCONF and RESTCONF already have a standard Role-Based Access Control = Model, called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, = leave it to vendors, or something else? =20 =20 Sue=20 ------=_NextPart_000_004F_01CF6462.DB8A72D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

My goal is not to invent something new, so as an expert in = =C2=A0netconf/restconf role-based access control model could you: =

 

1 =E2=80=93 comment if this can be handle by = netconf/restconf

 

Identity + role =C2=A0<im-tree-portion, access permission> = pairs

 

2 =E2=80=93 provide me with references to these RFCs = that I should pull out to reference to identify how this could be = expressed?

 

<snip>

 

NETCONF and RESTCONF = already have a standard Role-Based Access Control = Model,

called NACM (RFC 6536). =  Does the I2RS WG plan to create its own ACM, leave = it

to vendors, or something = else?

 

<snip>

Sue

------=_NextPart_000_004F_01CF6462.DB8A72D0-- From nobody Wed Apr 30 08:36:36 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A821A08DD for ; Wed, 30 Apr 2014 08:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9uKvn0pgz0D for ; Wed, 30 Apr 2014 08:36:33 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65E1A08E6 for ; Wed, 30 Apr 2014 08:36:33 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m20so2063585qcx.0 for ; Wed, 30 Apr 2014 08:36:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jhdyKfv6Daelfxch86k/M9F0XC3LUNAz0zbot8feQsU=; b=OCeYIUd16E3Lht6KGeNLSqK6qnZBBesXH9WxgD8npNA/jPm4m/OJda5XO4KDZIhIH2 tBg3oCKo9WLvglZx8KLUfIaH2/X5LKpZxasUETZ6XtKOBROwcw5RHf/zX93OYA17wDUA WpFGdsYGnOZdDl36TNeLVLjOJVAKq7OV1SpfkF6QUlWbVnTjBJ5v1Mu4Mj8E5xtHuYXm UlQ61Q5DLF8yXX8BNsZfYoAG1CwB0AMCl62IqvDXx9h6DTgWfVxOVf+hrT40a3T7Besc wIzywZpFUxNtLcZu4CeqfPSOV2tr8s1V+Y1/GhKyPI07XzkJNTuD8kjdRsloCXCYCv1y 4vYg== X-Gm-Message-State: ALoCoQndxNguA7swZGR1VK7v+nyPt0Z9yv9biqu91WVvpB5Ael+ZLILven6Nih0lo4BzgGGom1+7 MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr6482312qai.16.1398872191261; Wed, 30 Apr 2014 08:36:31 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Wed, 30 Apr 2014 08:36:31 -0700 (PDT) In-Reply-To: <004e01cf6484$628de200$27a9a600$@ndzh.com> References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <004e01cf6484$628de200$27a9a600$@ndzh.com> Date: Wed, 30 Apr 2014 08:36:31 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c20e7a0c13d604f84450e3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pFfCLfUYOGSoBpo8b2zfHL_xnfs Cc: Nitin Bahadur , "i2rs@ietf.org" , "Joel M. Halpern" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 15:36:35 -0000 --001a11c20e7a0c13d604f84450e3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares wrote: > Andy: > > > > My goal is not to invent something new, so as an expert in > netconf/restconf role-based access control model could you: > > > > 1 - comment if this can be handle by netconf/restconf > > > > Identity + role pairs > yes. NACM assigns users to admin-configured groups. Groups are used to represent roles. Rule-lists are used to specify policy for various groups. There are several wildcards and defaults to make rule specification simple. Rules are processed in order (first match == process and exit) http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#rule-list.310 > > 2 - provide me with references to these RFCs that I should pull out to > reference to identify how this could be expressed? > > > The access control model is in RFC 6536. A 'data rule' would be configured to achieve the policy above: - 'admin' group has full access the /foo/rib-data subtree - 'monitor' group has read access the /foo/rib-data subtree - all others have no access admin-can-write-rib-data admin foo-rib-data /acme:foo/acme:rib-data create read update delete permit monitor-can-read-rib-data monitor foo-rib-data /acme:foo/acme:rib-data read permit no-access-to-rib-data foo-rib-data /acme:foo/acme:rib-data deny > > > > > NETCONF and RESTCONF already have a standard Role-Based Access Control > Model, > > called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, > leave it > > to vendors, or something else? > > > > > > Sue > > Andy --001a11c20e7a0c13d604f84450e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares <= shares@ndzh.com>= ; wrote:
Andy:<= u>

 

My goal= is not to invent something new, so as an expert in  netconf/restconf = role-based access control model could you:

 

1 – comment if thi= s can be handle by netconf/restconf

 

Identity + role  <im-tree-portion, access permission> pairs



yes.
= NACM assigns users to admin-configured groups.
Groups are used to= represent roles. Rule-lists are
used to specify policy for vario= us groups. There are several
wildcards and defaults to make rule specification simple.
Ru= les are processed in order (first match =3D=3D process and exit)
=


 

2 – provide me with referenc= es to these RFCs that I should pull out to reference to identify how this c= ould be expressed?

 


The access control model is in RFC 6536.

A 'data rule' would be configured to achieve the policy = above:

 -  'admin' group has= full access the /foo/rib-data subtree
 -  'monitor= ' group has read access the /foo/rib-data subtree
 -  all others have no access


  <rule-list>
    <name&g= t;admin-can-write-rib-data</name>
     <g= roup>admin</group>
     <rule>
        <= name>foo-rib-data</name>
        <= ;path>/acme:foo/acme:rib-data</path>
     = ;   <access-operations>create read update delete</access-oper= ations>
        <action>permit</action>
<= div>     </rule>
  <rule-list>
  <rule-list>
    <name>m= onitor-can-read-rib-data</name>
     <gro= up>monitor</group>
     <rule>
       = <name>foo-rib-data</name>
       = ; <path>/acme:foo/acme:rib-data</path>
    =     <access-operations>read</access-operations>
        <action>permit</action>
<= div>     </rule>
  <rule-list>
  <rule-list>
    <nam= e>no-access-to-rib-data</name>
     <r= ule>
        <name>foo-rib-data</name>
        <path>/acme:foo/acme:rib-data</p= ath>
        <action>deny</action= >
     </rule>
  <rule-= list>


 

<snip>

 

NETCONF and RESTCONF already have a standard Role-Based Access Co= ntrol Model,

called NACM (RFC 6536).  Does the I2RS WG plan = to create its own ACM, leave it

to = vendors, or something else?

 

<snip>

Sue



Andy

--001a11c20e7a0c13d604f84450e3-- From nobody Wed Apr 30 09:11:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD5F1A6FF4 for ; Wed, 30 Apr 2014 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OAbVq1f9YA0 for ; Wed, 30 Apr 2014 09:10:58 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 781791A0930 for ; Wed, 30 Apr 2014 09:10:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <004e01cf6484$628de200$27a9a600$@ndzh.com> In-Reply-To: Date: Wed, 30 Apr 2014 12:10:26 -0400 Message-ID: <001701cf648e$b382a150$1a87e3f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01CF646D.2C732430" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhAHmIE/vAhVHwNEB9Fzv/Jx4h9yQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/yGYQRcCcbgD42G6HQVlEnUkI9SU Cc: 'Nitin Bahadur' , i2rs@ietf.org, "'Joel M. Halpern'" , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 16:11:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0018_01CF646D.2C732430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: Thanks. The pointer are helpful! Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Wednesday, April 30, 2014 11:37 AM To: Susan Hares Cc: Joel M. Halpern; Nitin Bahadur; i2rs@ietf.org; Mach Chen; draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares wrote: Andy: My goal is not to invent something new, so as an expert in netconf/restconf role-based access control model could you: 1 - comment if this can be handle by netconf/restconf Identity + role pairs yes. NACM assigns users to admin-configured groups. Groups are used to represent roles. Rule-lists are used to specify policy for various groups. There are several wildcards and defaults to make rule specification simple. Rules are processed in order (first match == process and exit) http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#rule-list. 310 2 - provide me with references to these RFCs that I should pull out to reference to identify how this could be expressed? The access control model is in RFC 6536. A 'data rule' would be configured to achieve the policy above: - 'admin' group has full access the /foo/rib-data subtree - 'monitor' group has read access the /foo/rib-data subtree - all others have no access admin-can-write-rib-data admin foo-rib-data /acme:foo/acme:rib-data create read update delete permit monitor-can-read-rib-data monitor foo-rib-data /acme:foo/acme:rib-data read permit no-access-to-rib-data foo-rib-data /acme:foo/acme:rib-data deny NETCONF and RESTCONF already have a standard Role-Based Access Control Model, called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, leave it to vendors, or something else? Sue Andy ------=_NextPart_000_0018_01CF646D.2C732430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

Thanks.  The pointer are helpful!

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Wednesday, = April 30, 2014 11:37 AM
To: Susan Hares
Cc: Joel M. = Halpern; Nitin Bahadur; i2rs@ietf.org; Mach Chen; = draft-ietf-i2rs-rib-info-model@tools.ietf.org
Subject: Re: = [i2rs] Some comments on = draft-ietf-i2rs-rib-info-model-01

 

 

 

On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

My goal is = not to invent something new, so as an expert in  netconf/restconf = role-based access control model could you:

 

1 – = comment if this can be handle by = netconf/restconf

 

Identity + = role  <im-tree-portion, access permission> = pairs

 

 

yes.

NACM assigns users to admin-configured = groups.

Groups are used to = represent roles. Rule-lists are

used to specify policy for various groups. There are = several

wildcards and = defaults to make rule specification simple.

Rules are processed in order (first match =3D=3D = process and exit)

 

 

 

 <= /o:p>

2 – = provide me with references to these RFCs that I should pull out to = reference to identify how this could be expressed?

 

 

The access control model is in RFC = 6536.

 

A = 'data rule' would be configured to achieve the policy = above:

 

 -  'admin' group has full access the = /foo/rib-data subtree

 -  'monitor' group has read access the = /foo/rib-data subtree

 -  all others have no = access

 

 

  <rule-list>

    = <name>admin-can-write-rib-data</name>

    =  <group>admin</group>

    =  <rule>

  =       = <name>foo-rib-data</name>

        = <path>/acme:foo/acme:rib-data</path>

        = <access-operations>create read update = delete</access-operations>

        = <action>permit</action>

    =  </rule>

  = <rule-list>

  <rule-list>

    = <name>monitor-can-read-rib-data</name>

    =  <group>monitor</group>

    =  <rule>

  =       = <name>foo-rib-data</name>

        = <path>/acme:foo/acme:rib-data</path>

        = <access-operations>read</access-operations>

        = <action>permit</action>

    =  </rule>

  = <rule-list>

  <rule-list>

    = <name>no-access-to-rib-data</name>

<= p class=3DMsoNormal>    =  <rule>

  =       = <name>foo-rib-data</name>

        = <path>/acme:foo/acme:rib-data</path>

        = <action>deny</action>

    =  </rule>

  = <rule-list>

 

 

 

<snip>

 

NETCONF and = RESTCONF already have a standard Role-Based Access Control = Model,

called NACM = (RFC 6536).  Does the I2RS WG plan to create its own ACM, leave = it

to vendors, = or something else?

 

<snip>

Sue

 

 

Andy

 

------=_NextPart_000_0018_01CF646D.2C732430-- From nobody Wed Apr 30 09:26:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9521A6FA9 for ; Wed, 30 Apr 2014 09:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvxNASZGppLN for ; Wed, 30 Apr 2014 09:26:41 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9189E1A0903 for ; Wed, 30 Apr 2014 09:26:40 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 16:26:37 +0000 Message-ID: <013401cf6490$a7c1d500$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <002e01cf5fc0$17f18ee0$4001a8c0@gateway.2wire.net> <012601cf5fe9$06477a00$4001a8c0@gateway.2wire.net> <20140424.205750.516350209.mbj@tail-f.com> Date: Wed, 30 Apr 2014 17:24:16 +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.252.181] X-ClientProxiedBy: AM3PR07CA0018.eurprd07.prod.outlook.com (10.141.45.146) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0197AFBD92 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(51704005)(51444003)(377454003)(189002)(199002)(62236002)(44716002)(20776003)(66066001)(84392001)(99396002)(92726001)(77156001)(33646001)(88136002)(87976001)(79102001)(87286001)(81686999)(50986999)(76176999)(80022001)(80976001)(92566001)(81542001)(46102001)(86362001)(93916002)(61296002)(76482001)(42186004)(50226001)(44736004)(85852003)(14496001)(4396001)(31966008)(74662001)(62966002)(50466002)(19580395003)(81342001)(77982001)(83322001)(47776003)(19580405001)(101416001)(83072002)(81816999)(89996001)(23756003)(74502001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0610HT003.eurprd06.prod.outlook.com; FPR:FCBBF1C5.AFF6D3FE.73F795B9.4AC6C94A.203D8; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/u5zEQynPi5lHsQpTfb5J9ysnxtw Cc: i2rs@ietf.org, edc@google.com, lhotka@nic.cz, shares@ndzh.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 16:26:42 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; ; Sent: Thursday, April 24, 2014 7:57 PM > t.petch wrote: > > Is it, though, the right approach for I2RS? I see the rationale of I2RS > > as being able to take a holistic view of the routing system, not one > > based on where the information is coming from (a view that may make > > sense when building boxes or installing them). > > > > Rather, I am minded of problems I have been called upon to resolve which > > are the result of misconfiguration, misconfiguration which is not > > apparent because the integrated view of what is controlling the box is > > not available. For example, a static route is inserted to circumvent a > > quirk of topology, the quirk is fixed but the static route is not > > removed, the topology changes again and that static route becomes a > > liability. Being able to see everything at once makes the problem > > apparent, looking for a configuration error or a BGP error separately is > > fruitless. > > > > My sense is that I2RS needs an integrated view whereas NETCONF/YANG > > focus on the configuration (as their RFC explicitly state). YANG is a > > good start, but as Andy said at IETF89, not enough. > > I am not sure I what you mean by "integrated view". > > One reason for separating config from operational state is to make > sure the view of operational state is exactly what is really currently > in use. So if a static route has been configured, and it really is in > use, it will show up in the operational state (marked as being a > static route). > > Isn't the "integrated view" the complete operational state? If not, > how is it different? Martin >From what you say, then yes, it is. Is it always the case that an entry in a config list is replicated in the matching operational state list for some meaning of the word matching? If so, then how is matching defined? Is it up to each individual model to specify this in the description? Lada says "have to be populated with at least one entry in any properly functioning device, and additional entries may be configured by the user." which fits the case of routers but this issue occurred in 2013 for interfaces, system, routing, ... and my expectation is that it will occur in most models. Except that with routing, you may have 350k entries in the operational state list and none in the config list, whereas in other models, the common case may have many entries in the config list and few or none system-controlled ones in which case, I am uncertain if the same logic should apply. I think that more explanation is still needed. Tom Petch > > /martin > From nobody Wed Apr 30 10:49:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670391A8838 for ; Wed, 30 Apr 2014 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qdyRGJE_9U4 for ; Wed, 30 Apr 2014 10:49:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0429F1A883A for ; Wed, 30 Apr 2014 10:49:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 37EC310B3; Wed, 30 Apr 2014 19:49:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PTyhyKO_NGd6; Wed, 30 Apr 2014 19:49:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 19:49:29 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9014020017; Wed, 30 Apr 2014 19:49:29 +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 OXp-heMiKtux; Wed, 30 Apr 2014 19:49:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3927220013; Wed, 30 Apr 2014 19:48:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 67A782CC6EAF; Wed, 30 Apr 2014 19:48:54 +0200 (CEST) Date: Wed, 30 Apr 2014 19:48:54 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140430174854.GB31746@elstar.local> Mail-Followup-To: Susan Hares , 'Joel Halpern Direct' , 'Nitin Bahadur' , 'Mach Chen' , i2rs@ietf.org, draft-ietf-i2rs-rib-info-model@tools.ietf.org References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/U9s1qaOn-RAv7kIc_D3vRdOgmMM Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 30 Apr 2014 17:49:34 -0000 On Wed, Apr 30, 2014 at 10:49:21AM -0400, Susan Hares wrote: > I'm trying to get a workable alternative to RBNF to discuss the actual > im-tree. UML is best, but I'm not sure If I can it in the documents. 5 > pages of UML covers all the RIB models. UML tools can create yang data > models and forces (In my understanding). However, some human beings seem > to need the yang tree models to see the tree and links to yang. I assume people mean UML class diagrams when they say UML. That said, yes tools can turn UML into other stuff. However, whether the result is 'nice' or 'implementable are reasonable pain' is a different question (and I understand that 'nice' and 'pain' have no clear definition). UML class diagrams allow the representation of arbitrary relationships between classes. If you have to turn this into a hierarchy for a protocol using a hierarchical namespace, then tools most likely only create _a_ solution not a _good_ solution. If you believe tools do a good job translating IMs to DMs, you will likely soon find that this is generally not the case and in order to make it work better you will start to augment you IM with lots of additional detail for the translator to do a reasonably good job, in which case your IM deteriorates to some extend into a DM. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 30 11:10:36 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94781A86E7 for ; Wed, 30 Apr 2014 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_OFF=2.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqgHnMoX4gTp for ; Wed, 30 Apr 2014 11:10:34 -0700 (PDT) Received: from nm2-vm2.bullet.mail.gq1.yahoo.com (nm2-vm2.bullet.mail.gq1.yahoo.com [98.136.218.129]) by ietfa.amsl.com (Postfix) with ESMTP id EA9181A091A for ; Wed, 30 Apr 2014 11:10:33 -0700 (PDT) Received: from [216.39.60.180] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 18:10:32 -0000 Received: from [208.71.42.190] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 18:10:32 -0000 Received: from [127.0.0.1] by smtp201.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 18:10:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398881432; bh=wEW/SfW+ZP0hsaQSETkbm5CtiUFdQHFpXrLIFg7F9vc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=n1ilYTuqiDbqIoQbfBsYHcua/Xcua+btMh/DKirAPM3DULfLAUK1e1zk6v93I7RdBW1VF1Na26ohWjRz1hf+kfU18c1PIt28zyALbNCLnxl3wHaOa3Is0qQbA15faLzeisaEvyY2dGU6fzE389kS84eoI4WaHwzD5z1zjTIb4SM= X-Yahoo-Newman-Id: 416838.52465.bm@smtp201.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4vA1yDgVM1nRIzCwMZPy8RQCeqaVGsgyO10zPRFLXKeo1mx yAGkZsX7a0Mhp4SbCCt2VPkqaZSe60XJhXX1w5OxWXExRsyCtEodEFQbpx1L xqXyFtVJcqBh7VJyKJ9HMAA5c3Vtq33ovKDJSCvjshdyvkAsJg6cT6thLav0 _NYxCaGvG3oB3cfDtf8fUIbzIxydu266K87tLjeF5SCMdMrlZoNBfy3ilCnJ cVUm2L2AJJRDP3kjIEe0gO4pOJWAHPnPVDaoI8sFEN5sOeWW.qQujVCdve3u eGlrOSmqsGL8MZzoD7Kmi6FT7hxnUJgML.cEhlNyvdtjzCHSOypVl445GPZq 5mAL5HkLE8ZjXopIsvmko_f26IgAbdROTC3ctL41g_tnY98uSmaYT_4C4E8l D4K1Vrj6Ao_3kYH8_mpp._MYmzF1q7GvPPW34rVQF5QFfaBzG6IEuB_T7WgC .FuDjBnkxG_bR1XokL9LI9oS.eAF4aOnsWJZZyRq0A33gPNxcrB1Y.96Xtf1 0geLWY5SJc3DJ_N5dJV.34I9F1xf5aBwtNwWdhit.hr0sJoSsBxll0L7Bxnk IlxO7PR5jiUwDYHCJaERuezl7ZzC8qR9EchlIGCr_eGM- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [63.250.193.228]) by smtp201.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 18:10:32 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 30 Apr 2014 11:10:28 -0700 From: Nitin Bahadur To: Susan Hares , 'Mach Chen' , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <001101cf646a$f02b8a50$d0829ef0$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ln8FmvmjEhfTUisepOTAoiDppdQ Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 18:10:35 -0000 Hi Sue, Thanks for putting this down in detail. Now it=B9s easier to explain what I was trying to convey. -----Original Message----- From: Susan Hares >Problem: Your grammar does not handle source-destination form choice as a >generic form used by all of the interfaces. Yes=8Ait is by design. See more below. >=20 >Solution: Specify form as specific variable for all forms. >Confusion: I am suggesting two tags and you want >see >one tag for compilation. > >See the two tags: [form-type] as two parts to one tag: > >[high order tag form] [low order form - address form] > >At this point, all I have done is reduce your complex forms to 1 tag > =3D > >Then your grammar is as follows: > > ::=3D ( | | | > | ) >::=3D > | | | | > > =3D > =3D >Routing protocols would have: [rrr ff ttt] r =3D reserved/0 ff =3D 0/1 (for >src/dst), ttt =3D type] > > ::=3D | | | | What the above grammar does is that it allows one to construct a match that looks like: ::=3D This is obviously incorrect. That=B9s the part I have been trying to convey. In the world of routing protocols, we have IANA registries that specify what combination is legal. In the world of data-models, we can=B9t depend on that. So with the grammar above, how do you prevent a badly-written controller from sending a match condition that looks like above (not that the data-model will successfully compile this match condition=8Asince the rules allow it)? > >Each of these forms for matches could use the SRC and destination in the >filter.=20 > >I'm sure that IPv4, IPv6, and IEEE_MAC are obvious from your emails. >Interfaces can be viewed as the same for flows: >.=20 Match is always on an incoming packet. A packet does not have embedded in it the dst-interface. So you cannot have a dst-interface as part of the match condition. =20 >This can be that the traffic flow comes in on interface1 >and goes out on interface 2 for all interfaces. MPLS could but it can be >ingress/egress label as source/destination. > >Do you agree/disagree have a potential of having source-destination for >most >of these types?=20 I disagree that there is a potential of having a src-dst for most types. Src-dst is only possible =B3in a match condition=B2 for a route-type that has src and dest information embedded in the packet. IPv4/IPv6 & IEEE-MAC are the only possibilities. For IEEE-MAC, there has been no use-case (requirement yet) to have SRC-DST based routing=8A.so it wasn=B9t included so far. > If you need context on the interfaces, pleases consider multicast and >flows. Multicast and flows have a next-hop that points to multiple interfaces. The incoming packet does not contain the list of outgoing interfaces. Mcast has RPF which is done based on incoming interface (which the network device knows for a given packet). So you match on mcast-address (S,G) + incoming-interface and then decide (as part of nexthop) where all and how (load-balance, multiple copies, etc) you want to send the packet. Thanks Nitin From nobody Wed Apr 30 12:01:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8451A8872 for ; Wed, 30 Apr 2014 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyuWCWKwbs64 for ; Wed, 30 Apr 2014 12:01:17 -0700 (PDT) Received: from nm11-vm10.bullet.mail.gq1.yahoo.com (nm11-vm10.bullet.mail.gq1.yahoo.com [98.136.218.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68B1A88E1 for ; Wed, 30 Apr 2014 12:01:02 -0700 (PDT) Received: from [98.137.12.190] by nm11.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 19:01:00 -0000 Received: from [98.136.164.76] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 19:01:00 -0000 Received: from [127.0.0.1] by smtp238.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 19:01:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398884460; bh=oGgLcF55xou3DHrSlKleAMj5j95YUl8QKxyaTIwl0DY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=ENuQtKA0ZPhILzoOdsU8DQ97wJqyxLAHmjRdhdX8bnjswd6AVaWf0MZ5D4iIWuDJoC+Qet5O5+lC3AjDKH3K0a03tx9GUoatkC9XCiApFrTNwh5+8edwapbXhqZ9O1eOfAflU9rFqxXCxfJ4CxIHPScCX0sdwRRlXUNdrwfEpEk= X-Yahoo-Newman-Id: 656604.93085.bm@smtp238.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nINwJdUVM1np1DCIW5rDm2H.ro3j_G4T8bhmT8_xyE8Q0vh 0zpReaHM.LiXNQFoYOL4yyW4CPWyXmlsK_Jy7NTtjA_OCGcXnPMbqx2eVntB aF2MFEaQlwdtwnx36mwPDcCfXwMcNU6V.ltZcDUZsj6ZHSufCmRenqTRCG_u VigQ5pfH1OPb34nvkQO1kJrsUsqlll9ySSs2YIN.ptzAqgAG5v1SFulxhTh5 _UiF0RC5P_r4CnZvv47rqiThLgg1wPW0iA0uXIDraMxkTIK19NYpd3PAmw0Z yk6ozEBmTWBe6GXUiTCc6mPC5EmkNSFLQ1QiVXlrOP3VmRYOiXnIxIkVTB_I FXzKw9bZPF_udDeBm_nBP998IjD5pyg2n9viers53N679VYX.Ez2TIouI4OW Qnbj73DpJWYSrfusjXaNJkkYnc.oYMYtNEt5upIEpqzSLWallx7Juk0usiGS XZJ60RqyKnKz_ETnh5RR9dtnD7mOhKIyYmWdiRnYosyoQPA6EjC5wVTU7XCO jokONAzl2aEB1kddYxj32OnQXTECzjsHjXg-- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [98.139.211.125]) by smtp238.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 19:01:00 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 30 Apr 2014 12:00:52 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] draft-ietf-i2rs-rib-info-model-02 In-Reply-To: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3481704059_2467766" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/F4RNfqfbRysO38ULi5yEIJ3OhtM Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, Alia Atlas Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 19:01:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3481704059_2467766 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sue, From: Susan Hares Date: Sunday, April 20, 2014 at 2:31 PM To: Cc: 'Jeffrey Haas' , , Alia Atlas Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 > Nitin, Ron, Kini, Jan: > =20 > 1) Is Section 7 of your document normative or informative? >=20 > =20 Section 7 is informative. > 2) Your grammar seems wordy/inconsistent in the repetition of the ne= xt > hop below=20 >=20 > =20 > Your RIB grammar on page 17 states: >=20 > =20 > ::=3D | > ((nexthop-list-member>) | > ( =8A | )) > =20 > ::=3D ( | > ) > =20 > [] > =20 > ::=3D ( =8A) > =20 > Questions: Why do you have nexthop-list-member listed twice? Why list > twice? Is this readability or technical matter? > =20 >=20 > Why not:=20 > ::=3D (( | (nexthop-list-member) =8A ) =8A Good question. It=B9s a technical matter. The above (and below) format is needed to satisfy certain types of nexthops. I will list each of them. ([ ... ] )) =3D=3D=3D> recursion. What you get from this is a way to perform the following actions on a given packet: * RECEIVE (send to local host) AND * Replicate to interface-1 and interface-2 AND * Load-balance among interface-3 and interface-4 > =20 > Why not:=20 > ::=3D ((( | ( =8A > ))[ =20 > Were you trying to name the chains? > =20 The tag acts like an enclosing tag for a list of next hops. It also indicates that the nexthops are related and should be treated as a chain to be applied one after the other to the same packet. Nothing magic. What it also allows (down the road) is to maintain an association of nexthop-chain contents to a chain-ID. And when a network-device supports nexthop-chain-IDs, the controller can replace the chain with just it=B9s ID. Maintaining just a list of nexthops makes it harder for a controller to correlate whether 2 nexthops-list-members are effectively the same (without a bunch of crazy comparisons and sorting). Nexthop-chain tag also allows ease of understanding for Section 7.2.5. > 3) Two variables seem orphaned: >=20 > =20 >=20 > Multicast-source-ipv4-address ::=3D >=20 > Multicast-source-ipv6-address ::=3D >=20 > =20 > Did I miss someplace where they attached to the normative secti= on 6. > You indicated the PIM paths can be chains (section 7.3), but y= ou do > not give the normative section. These are going to be removed. Now that you have understood a lot of the IM model, looking forward to an implementation of the same :-) Thanks Nitin --B_3481704059_2467766 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Sue,

From: Susan Hares <shares@n= dzh.com>
Date: Sunday, Apri= l 20, 2014 at 2:31 PM
To: <i2rs@ietf.org>
Cc: 'Jeffrey Haas' <jhaas@= pfrc.org>, <adrian@olddog.co.= uk>, Alia Atlas <akatlas@juni= per.net>
Subject: [i2rs] dr= aft-ietf-i2rs-rib-info-model-02

Nitin, Ron, Kini, Jan:

 

1)      Is Section 7 of your document normative or informative?

 


Section 7 is informative.

Nitin
--B_3481704059_2467766-- From nobody Wed Apr 30 12:22:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70B61A885F for ; Wed, 30 Apr 2014 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xk6wbx4BY8c for ; Wed, 30 Apr 2014 12:22:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 44A421A064D for ; Wed, 30 Apr 2014 12:22:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> <20140430174854.GB31746@elstar.local> In-Reply-To: <20140430174854.GB31746@elstar.local> Date: Wed, 30 Apr 2014 15:22:00 -0400 Message-ID: <002701cf64a9$76159410$6240bc30$@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: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhAKicq5hAnZX0SoCoDeitgJb3B4TnFeSd6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/92IlgZQw419w11GYhZzgua3MWAs Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 19:22:33 -0000 Juergen: Thanks for the high quality and pragmatic response. Yes, I did mean UML Class diagrams. As the teens say "my bad". As to the tools and code generation: During my days of writing protocol software or managing protocol software writers, I found it often took 3+ rewrites to get efficient code after working good. If tools create inefficient code but working code - at least a prototype to test against comes up quickly. If tools improve the prototype may get closer and the re-writes less. As to descending into detail with UML: that's actually a plus for me. The purpose behind UML is to quicken the pace of the process from high level agreement to DM. We can standardize the high level and then use the UML to provide quicken layers of agreement. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, April 30, 2014 1:49 PM To: Susan Hares Cc: 'Nitin Bahadur'; 'Joel Halpern Direct'; 'Mach Chen'; draft-ietf-i2rs-rib-info-model@tools.ietf.org; i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 On Wed, Apr 30, 2014 at 10:49:21AM -0400, Susan Hares wrote: > I'm trying to get a workable alternative to RBNF to discuss the actual > im-tree. UML is best, but I'm not sure If I can it in the documents. > 5 pages of UML covers all the RIB models. UML tools can create yang data > models and forces (In my understanding). However, some human beings seem > to need the yang tree models to see the tree and links to yang. I assume people mean UML class diagrams when they say UML. That said, yes tools can turn UML into other stuff. However, whether the result is 'nice' or 'implementable are reasonable pain' is a different question (and I understand that 'nice' and 'pain' have no clear definition). UML class diagrams allow the representation of arbitrary relationships between classes. If you have to turn this into a hierarchy for a protocol using a hierarchical namespace, then tools most likely only create _a_ solution not a _good_ solution. If you believe tools do a good job translating IMs to DMs, you will likely soon find that this is generally not the case and in order to make it work better you will start to augment you IM with lots of additional detail for the translator to do a reasonably good job, in which case your IM deteriorates to some extend into a DM. /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 nobody Wed Apr 30 12:40:21 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEA21A0956 for ; Wed, 30 Apr 2014 12:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeZx47v7qN3z for ; Wed, 30 Apr 2014 12:40:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD2591A099D for ; Wed, 30 Apr 2014 12:40:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF06D110A; Wed, 30 Apr 2014 21:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OxQHyul-o-rm; Wed, 30 Apr 2014 21:40:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 21:40:11 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FD5A20013; Wed, 30 Apr 2014 21:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MZQxbTR2MX3q; Wed, 30 Apr 2014 21:40:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD2852002C; Wed, 30 Apr 2014 21:40:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4A4322CC7004; Wed, 30 Apr 2014 21:40:09 +0200 (CEST) Date: Wed, 30 Apr 2014 21:40:08 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140430194008.GB31986@elstar.local> Mail-Followup-To: Susan Hares , 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> <20140430174854.GB31746@elstar.local> <002701cf64a9$76159410$6240bc30$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002701cf64a9$76159410$6240bc30$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hmneIlmR2465H-f0SzIAP6rwz6E Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 30 Apr 2014 19:40:19 -0000 On Wed, Apr 30, 2014 at 03:22:00PM -0400, Susan Hares wrote: > Juergen: > > Thanks for the high quality and pragmatic response. Yes, I did mean UML > Class diagrams. As the teens say "my bad". > > As to the tools and code generation: > During my days of writing protocol software or managing protocol software > writers, I found it often took 3+ rewrites to get efficient code after > working good. If tools create inefficient code but working code - at least > a prototype to test against comes up quickly. If tools improve the > prototype may get closer and the re-writes less. But we are talking about standardizing data models we want to interoperate. You can't apply iterative code development to this. > As to descending into detail with UML: that's actually a plus for me. The > purpose behind UML is to quicken the pace of the process from high level > agreement to DM. We can standardize the high level and then use the UML to > provide quicken layers of agreement. As usual, the hard is finding agreement, not so much the format. A format that people do not read carefully may help in the sense that you get less reviews and thus you believe you were faster (but you might have just moved the difficult parts of the agreement finding process to a later stage). As such, a format that increases the chances of getting a fair number of substantial reviews of key parties should be the target. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 30 12:48:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1081A03F3 for ; Wed, 23 Apr 2014 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DedUkH_ej5wQ for ; Wed, 23 Apr 2014 08:03:35 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id C73971A03E0 for ; Wed, 23 Apr 2014 08:03:23 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so1029862qcq.23 for ; Wed, 23 Apr 2014 08:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5tFvm+29MVzLhVBZjljDxTUcJ4eHaqL5sHjrqTwmqpc=; b=jTBTmmU+HFkiXdW49CS+cicPSxXA4oZgGLMfliQeH7cEBsX+qeMz7Z9R7+8act5ui9 RscN3EXnwTszScNzHrLVd9SPso4/x+RhpaRbTDkZ9w1eHPmP5ByFb/GvZu+f00ZCbjwK CRmgjjf4vE2sIA2LuJourL3sSMrQOnigDxDqnY+Fdm7WeGVni9HG54vumEzVlg8VVdFn vLzNZVCByR67Y+Hf1iEgUUXYtGXL5XdadHZ8BnsaGF8VkXNZ9dhZVACopyai7jPcNSLB jC04u97rcD35kF0bs85Sc2el7zwqM/8jzc6C/Re0kL3vEz50XbdB3EmrSZkEd4AxWetN xkrA== X-Gm-Message-State: ALoCoQmB9wKP9tzAuu7OoYvH8H23TMV8nJd2nVG51si36BNR1VpO6DTkFfbQL2CGnyisFkllTcL+ MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr59283725qai.16.1398265397837; Wed, 23 Apr 2014 08:03:17 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Wed, 23 Apr 2014 08:03:17 -0700 (PDT) In-Reply-To: <006701cf5f02$211325b0$63397110$@ndzh.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> Date: Wed, 23 Apr 2014 08:03:17 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c20e7a5788a204f7b7081d Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qu6qEre3w06E43qCur5OzD2zneM X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:49 -0700 Cc: Nitin Bahadur , "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , Alia Atlas , Jeffrey Haas , Adrian Farrel , "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 15:03:41 -0000 --001a11c20e7a5788a204f7b7081d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares wrote: > Andy: > > > > I started using UML to do the information models because Adrian Farrel and > Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf > models are still mining the existing SNMP/Configuration structures. For new > development, I suspect UML may help us root out redundancy. Why? Because I > think I've found lots of redundancy in the RIB_INFO model. I've attached > slides that may convince you, and an alternate drafts. > > > I do not have any objections to using UML. They are painful to read and write in ASCII art. Maybe that's why we tend to describe the model in introductory text. We also try to avoid duplicating normative text, and try to keep as much normative text in the YANG modules themselves (since they tend to get extracted and the RFC tossed ;-). This is an awesome step forwards. Thanks! I was going to translate the next info-model draft to YANG so we can compare YANG and ForCES using the same data definitions. Looks like you already did that, but I just see the YANG tree diagram in the draft, not the YANG module. It is still enough to see how YANG features would be defined, based on protocols. Clearly, not every I2RS router is going to implement the exact same set of protocols. Not every conceivable piece of data is going to be mandatory to implement. Data organization and modularity are really important aspects to get right the first time. Andy > I've assumed in the information model that yang models as defined below > > +--------+---------------------------+-----------+ > > | Prefix | YANG module | Reference | > > +--------+---------------------------+-----------+ > > | if | ietf-interfaces | [YANG-IF] > | > > | | | | > > | ip | ietf-ip | [YANG-IP] > | > > | | | | > > | rt | ietf-routing *| [routing] |* > > | | | | > > | v4ur | ietf-ipv4-unicast-routing *| [routing] |* > > | | | | > > | v6ur | ietf-ipv6-unicast-routing |* [routing * | > > | | | | > > | yang | ietf-yang-types | [RFC6991] > | > > | | | | > > | inet | ietf-inet-types | [RFC6991] > | > > +--------+---------------------------+-----------+ > > > > I've attached a revision of the RIB-info-model draft that provides: > > 1) Revised RIB Grammar in RBNF (section 6.1) > > 2) (section 6.2) Spot for the pdf graphic attached as > draf-thares-i2rs-info-rib-only-v7.pdf > > 3) (section 6.3) Yang tree structure (per yang documents) > > 4) Revised Usage - using simplified grammar > > > > Basically the complex RBNF grammar boils down to very few simply > statement. The Yang Tree does not provide an easy way to design/debug > redundancy. I think that the use of the UML tools that create the Yang > modules/Yang Tree structures could speed time to market on the designs. > For example, all the I2RS RIB is simply 5 power-point slides, that then > can be generated into Yang module. This seems the normal progression of > the process you started with the Yang-modules. > > > > CAVEATS: > > 1) For all mistakes on the UML and diagrams blame me - this first > pass at UMLs, and it will need revising > > 2) Some of the redundancies could have been fixed in other ways > > 3) I did Yang modules to demonstrate proof of concept > > 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. > FoRCES Data model can do the same > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, April 22, 2014 8:46 PM > *To:* Susan Hares > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Russ White; Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > <..snip> > > 1) Why do you think that only the RIB matters in the long run (Short > run = RIB + BGP) - > > [Andy] Why do you think I said that I don't see anything special about > I2RS at all. Editing operational state would probably work the same for > other data. > > [Sue]: Agree! > > > > 2) Your modeling questions are important .. so let me ask a > meta-question and then go a level deeper... > > Why does netmod never really publish an informational model? > > NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. > > [Sue]: Other designers on lists stated they suggested they considered IM > in their design of YANG. I think the graphical finds redundancies > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Saturday, April 19, 2014 1:46 PM > *To:* Russ White > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > Hi, > > > > On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > > > > And the basic premise of I2RS is that there are requirements for the work > > that were not addressed properly by the existing configuration protocols. > > Otherwise the WG would not even need to discuss protocol modifications. > > So the fact that NetConf / YANG works for device configuration does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the problem, and said, > "let's use YANG." But I think we're starting to confuse the problem set > because we started by trying to boil the ocean. Once you actually get to > town, it's hard to keep in focus that you're just there for a new pitchfork > handle -- that game of checkers over there on the porch of the hotel looks > so interesting, and the hardware store has so much other stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB interface, and not > protocol, configuration, device, etc., etc., what specific points have the > use cases brought out that either NETCONF/YANG or FORCES not fulfill? One > of > the primary points was timing -- are these other systems fast enough? > > >From my perspective, these two systems don't fulfill the I2RS mandate on > the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit heavy weigh for > what > we want here. The flexibility is there, but so is the cost of that > flexibility. > > > > > > Can you explain how an off-line representation of the data model can be > fast or slow? > > You mean the YANG compiler takes too long to process a YANG file? > > You mean the unspecified I2RS protocol will be too slow on the wire if > > it uses XML or JSON encoding of YANG data structures? > > > > > > > - I'm not convinced YANG has handled the atomicity issues in a way that > makes sense for the application environment we have in mind. RESTCONF seems > to go that direction, but I'm not certain it's a complete solution (?). > > > > YANG is a data modeling language. > > RESTCONF is a protocol. > > Atomicity is a property of the protocol. > > Which YANG statements prevent this from being accomplished in the TBD I2RS > protocol? > > > > > > So, IMHO, I think we need to either consider FORCES, or "something new." > But > we're going to have a hard time determining if this is true if we can't > make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing routes in > the RIB > - An immediate feedback system within the RESTful mold that tells the > installing process what happened, and why, with the route it just tried to > install in the RIB > > So, it seems to me that we need to return to the use cases -- there are two > in the charter. If we want to discuss adding others, that's fine, but we > need to gain some focus, and stop trying to boil the ocean, if we want to > make any progress. > > > > It seems to me this WG needs to start asking the right questions about the > > data modeling language requirements. E.g.: > > > > - What are the data types needed? Is this a static set of will it ever > change? > > - What are the high level data modeling constructs needed? > > - Are user defined types needed? > > - Are re-usable data definitions needed? > > - Does the data model need to be modular? How does it grow over time? > > - Can vendors add data definitions that extend the standard definitions? > > - How are new definitions added in a way that does not break existing > clients? > > - How is mandatory to implement vs. optional to implement functionality > handled? > > - How is mandatory to use vs. optional to use functionality handled? > > > > You are asking about protocol requirements, not data modeling. > > IMO it would be near-sighted and extremely impractical to choose > > a language that only supported description on RIB info. I fail to see what > > is so special about RIB info that would warrant its own DML. > > > > > > :-) > > Russ > > > > Andy > > > > > --001a11c20e7a5788a204f7b7081d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares <= shares@ndzh.com>= ; wrote:

Andy:<= u>

 

I started using UML= to do the information models because Adrian Farrel and Alia Atlas encourag= ed it to replace RBNF.   I think that the yang/netconf models are= still mining the existing SNMP/Configuration structures. For new developme= nt, I suspect UML may help us root out redundancy. Why?  Because I thi= nk I’ve found lots of redundancy in the RIB_INFO model.  I&rsquo= ;ve attached slides that may convince you, and an alternate drafts.<= u>

 

<= /div>


I do not have an= y objections to using UML.
They are painful to read and write in ASCII art.
Maybe that&= #39;s why we tend to describe the model in introductory text.
We = also try to avoid duplicating normative text, and try to keep as much
normative text in the YANG modules themselves (since they tend to get<= /div>
extracted and the RFC tossed ;-).

This i= s an awesome step forwards.  Thanks!
I was going to translat= e the next info-model draft to YANG so we
can compare YANG and ForCES using the same data definitions.
Looks like you already did that, but I just see the YANG tree diagram in t= he draft,
not the YANG module.

It is sti= ll enough to see how YANG features would be defined, based on protocols.
Clearly, not every I2RS router is going to implement the exact same se= t of protocols.
Not every conceivable piece of data is going to b= e mandatory to implement.
Data organization and modularity are re= ally important aspects to get right the first time.


Andy

 
=

I’ve assumed in the i= nformation model that yang models as defined below

  +--------+---------------------------+--------= ---+

  | Prefix | YANG module=             &nb= sp;  | Reference |

  +--------+---------------------------+-----------+<= u>

  | if    = ; | ietf-interfaces         &n= bsp; | [YANG-IF] |

  |        | =             &nb= sp;            = |           |<= /u>

  | ip     | ietf-i= p            &n= bsp;      | [YANG-IP] |

  |        | =             &nb= sp;            = |           |<= /u>

  | rt     | ietf-r= outing           &nb= sp;  | [routing] |

 |        | =             &nb= sp;            = |           |<= /u>

 | v4ur   | ietf-ipv4-unicas= t-routing | [routing] |

  |        | =             &nb= sp;            = |           |<= /u>

  | v6ur   | ietf-ipv6-unicas= t-routing | [routing  |

  |        | =             &nb= sp;            = |           |<= /u>

  | yang   | ietf-yang-types&= nbsp;          | [RFC6991] |

  |        | =             &nb= sp;            = |           |<= /u>

  | inet   | ietf-inet-types&= nbsp;          | [RFC6991] |

  +--------+---------------------------+-----------+<= u>

<= u> 

I’ve attached a rev= ision of the RIB-info-model draft that provides:

1)      = Revised RIB Grammar in RBNF (section 6.1)=

2)      (section 6.2) Spot for the pdf graphic = attached as draf-thares-i2rs-info-rib-only-v7.pdf

3)      (section 6.3) Yang tree structure (per = yang documents)

4)      Revised Usage – using simplified = grammar

 

Basically the compl= ex RBNF grammar boils down to very few simply statement.  The Yang Tre= e does not provide an easy way to design/debug redundancy. I think that the= use of the UML tools that create the Yang modules/Yang Tree structures cou= ld speed time to market on the designs.  For example, all the I2RS RIB= is simply 5 power-point slides, that then can be generated into Yang modul= e.  This seems the normal progression of the process you started with = the Yang-modules.

 

CAVEATS: =

1)      For all mistakes on the UML and diagram= s blame me – this first pass at UMLs, and it will need revising

2)      Some of the redundancies could have bee= n fixed in other ways

3)      I did Yang modules to demonstrate proof= of concept

4)      I suspect with Jamal and Joel Halpern&r= squo;s help (FoRCES gurus).. FoRCES Data model can do the same

 

Sue Hares  =

 

From: i2= rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, April 22, 2014 8:46 PM
To: Susan Hares
<= b>Cc: i2rs@ietf.org<= /a>; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medv= ed (jmedved); Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

 = ;

2)      Your modeling questions are important .. so let me ask a meta-question and= then go a level deeper…

 Why does netmod nev= er really publish an informational model?

 NETMOD = publishes YANG modules. I suppose it i= s perceived an unnecessary.

[Sue]: Other designers on= lists stated they suggested they considered IM in their design of YANG. &n= bsp;I think the graphical finds redundancies

<snip)  

 

From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Andy Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: Russ White
<= b>Cc: i2rs@ietf.org<= /a>; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan Medved (jmedved)= ; Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

Hi,

 

On Sat, Apr 19, 2014 at= 8:22 AM, Russ White <= russw@riw.us> wrote:


>= ; And the basic premise of I2RS is that there are requirements for the work=
> that were not addressed properly by the existing configuration protoco= ls.
> Otherwise the WG would not even need to discuss protocol modifi= cations.
> So the fact that NetConf / YANG works for device configura= tion does not
> seem to be evidence that it works for what I2RS wants to do.

Pr= ecisely. Otherwise, we could have just looked at the problem, and said,
= "let's use YANG." But I think we're starting to confuse t= he problem set
because we started by trying to boil the ocean. Once you actually get totown, it's hard to keep in focus that you're just there for a new = pitchfork
handle -- that game of checkers over there on the porch of the= hotel looks
so interesting, and the hardware store has so much other stuff than justpitchfork handles, after all.

So, given we are _supposed_ to be foc= used on the RIB interface, and not
protocol, configuration, device, etc.= , etc., what specific points have the
use cases brought out that either NETCONF/YANG or FORCES not fulfill? One o= f
the primary points was timing -- are these other systems fast enough?<= br>
>From my perspective, these two systems don't fulfill the I2R= S mandate on the
RIB side for various reasons:

- I'm not convinced on the speed s= ide. YANG feels a bit heavy weigh for what
we want here. The flexibility= is there, but so is the cost of that
flexibility.

 

 

Can yo= u explain how an off-line representation of the data model can be fast or s= low?

You mean the YANG compiler takes too long= to process a YANG file?

You mean the unspecified I2RS protocol will be too slow on the wire if<= /u>

it uses XML or JSON encoding of YANG data= structures?

 

 


- I'm not con= vinced YANG has handled the atomicity issues in a way that
makes sense f= or the application environment we have in mind. RESTCONF seems
to go tha= t direction, but I'm not certain it's a complete solution (?).

 

YANG is a data modeling language.

=

RESTCONF is a protocol.

=

Atomicity is a property of the protocol.

Which YANG statements prevent this = from being accomplished in the TBD I2RS protocol?

 

 

So, IMHO, I think we = need to either consider FORCES, or "something new." But
we'= ;re going to have a hard time determining if this is true if we can't m= ake
a solid requirements list. For me, these are:

- Atomic operations at= the RIB level
- Speed that's comparable to a local routing process = installing routes in
the RIB
- An immediate feedback system within th= e RESTful mold that tells the
installing process what happened, and why, with the route it just tried to<= br>install in the RIB

So, it seems to me that we need to return to t= he use cases -- there are two
in the charter. If we want to discuss addi= ng others, that's fine, but we
need to gain some focus, and stop trying to boil the ocean, if we want tomake any progress.

 

It seems to m= e this WG needs to start asking the right questions about the=

data modeling language requirements. &nbs= p;E.g.:

 =

  - What are the data types = needed?  Is this a static set of will it ever change?

  - What are the high level data mod= eling constructs needed?

  - Are user defined types needed?

  - Are re-usable data definitions needed?

  - Does the data model need to be modular? &n= bsp;How does it grow over time?

  - Can vendors add data definitions that extend the standard = definitions?

  - How are new definitions added in= a way that does not break existing clients?

  - How is mandatory to implement vs. optional to= implement functionality handled?

  - How is mandatory to use vs. opti= onal to use functionality handled?

 

You ar= e asking about protocol requirements, not data modeling.

IMO it would be near-sighted and extremel= y impractical to choose

= a language that only supported description on RIB info.  I fail to see= what

is so special about RIB info that would w= arrant its own DML.

&nbs= p;

 <= /p>

:-)

Russ

<= p class=3D"MsoNormal"> 

Andy

 <= u>

=  


<= /div>

2)&= nbsp;     Your grammar seems= wordy/inconsistent in the repetition of the next hop below

<= p class=3D"MsoNormal"> 

Your RI= B grammar on page 17 states:

 =

<nexthop-list> ::=3D <special-nexthop&= gt; |

     &nbs= p;            &n= bsp;            =  ((nexthop-list-member>) |

 = ;            &nb= sp;            &= nbsp;      (<nexthop-list-member> …= ; | <nexthop-list>))

 

<nexthop-list-member> ::=3D (<nexthop-cha= in> |

     &= nbsp;            = ;            &nb= sp;            &= nbsp;       <nexthop-chain-identifier&= gt;)

      =             &nbs= p;            &n= bsp;            =       [<nexthop-list-member-attributes>]=

 

<= ;nexthop-chain>::=3D (<nexthop> …)

 

Questions: Why do you have= nexthop-list-member listed twice?  Why list <nexthop-list> twice= ? Is this readability or technical matter?

 

Why not:

<next= hop-list>::=3D ((<special-nexthop> | (nexthop-list-member) … ) = …


=
Goo= d question. It’s a technical matter. The above (and below) format is n= eeded to satisfy certain types of nexthops. I will list each of th= em.

([<nexthop-list-member> ... ] <nexthop= -list> )) =3D=3D=3D> recursion.

What you get from this is a way to perform the following= actions on a given packet:


  • RECEIVE (send= to local host)    AND
  • Replicate to interface-1 and interface-2   AND
  • Load-balance among i= nterface-3 and interface-4

 =

Why not:

= <nexthop-list-member> ::=3D (((<nexthop-chain-identifier> | (<n= exthops> … ))[<nexthop-list-member-attributes]) )…

 

Were = you trying to name the chains?

&nbs= p;


The <nexthop= -chain> tag acts like an enclosing tag for a list of next hops. It also i= ndicates that the nexthops are related and should be treated as a chain to b= e applied one after the other to the same packet. Nothing magic. What i= t also allows (down the road) is to maintain an association of nexthop-chain= contents to a chain-ID. And when a network-device supports nexthop-chain-ID= s, the controller can replace the chain with just it’s ID. Maintaining=  just a list of nexthops makes it harder for a controller to corre= late whether 2 nexthops-list-members are effectively the same (without a bun= ch of crazy comparisons and sorting).

Nexthop-ch= ain tag also allows ease of understanding for Section 7.2.5.


3)      Two variables seem orphaned:

 

Multicast-so= urce-ipv4-address ::=3D <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D <IP= v6_ADDRESS> <IPv6_PREFIX_LENGTH>

 

     &n= bsp;   Did I miss someplace where they attached to the normat= ive section 6.

    &= nbsp;      You indicated the PIM paths can be = chains (section 7.3), but you do not give the normative section. =


These are goi= ng to be removed.

Now that you have underst= ood a lot of the IM model, looking forward to an implementation of the same = :-)

Thanks

<= /div> --001a11c20e7a5788a204f7b7081d-- From nobody Wed Apr 30 12:48:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C491A042E for ; Tue, 22 Apr 2014 07:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFBGaPmCqc93 for ; Tue, 22 Apr 2014 07:15:24 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 606A91A021C for ; Tue, 22 Apr 2014 07:15:24 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so9877655veb.27 for ; Tue, 22 Apr 2014 07:15:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=DU9sqpZMoBgyd43mHPL+KXiqqhbs7yBL7MkGrdG28k8=; b=DDEN0FGbsZTjhoTeEGqnA1a92MfpI4lm2jA3JhsevsbEdoUWxm8fOHpNQe1tZPGgav IeAZmc1K5C9ieXQ9QysYxkA6ULaOIRZbSNujGdG/4nH/eP4FLIRknYYRcLvU7uOXPQXM xILYjFjJq5In008UiYe9bjAyI1uND1kYRe8JKoiB0MB6vW1uB2wjEhKyvvI08VZWXCQU dCfN3IZgfOrF6ZKkIIDAgRB2AzzlsruID3qjJl9nBTuKQ0mAfxdKS2sF5HcyWC0TzAre 2XRybsvuflzf5zwtCpYWlkV3FCt7EjK4ddtPVVhxcPRNCHpB/9HXfzN9DzcUFOufuLr1 CKlg== X-Gm-Message-State: ALoCoQnt58grrRXo8hjoyqypCo0VLrBP8sKkdkIrDdVQa/WH3ORvW3ylz0FDI4KF3USK/3RT4G2m X-Received: by 10.52.250.4 with SMTP id yy4mr217296vdc.56.1398176118897; Tue, 22 Apr 2014 07:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 22 Apr 2014 07:14:58 -0700 (PDT) In-Reply-To: <20140422071954.GA10717@elstar.local> References: <0E6647BF-2F45-4DC7-8F36-9B8CB29D6C99@juniper.net> <5355E678.8030309@joelhalpern.com> <20140422071954.GA10717@elstar.local> From: Jamal Hadi Salim Date: Tue, 22 Apr 2014 10:14:58 -0400 Message-ID: To: Juergen Schoenwaelder , ramki Krishnan , "Joel M. Halpern" , Andy Bierman , Jamal Hadi Salim , Russ White , "i2rs@ietf.org" , "Jan Medved (jmedved)" , Dean Bogdanovic , Edward Crabbe Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/b4z6QKNFeY0qG9UKVLcMksGev0w X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:49 -0700 Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:15:29 -0000 I see a different flaw just from the first few pages and looking at the conclusion. Sorry - didnt have time to look at the whole thing. The paper picks a model entity of about 90% strings (theres one "int" iirc). I am not sure what that was supposed to emulate. From that perspective the question answered to me seems to be "how bad does SNMP do when you have mostly strings?". It seemed to do fairly well at the end. I liked the fact they tried to batch things with SNMP. If i was emulating what I2RS is doing by building on say the RIB model, it will not be 90% ascii on the wire for SNMP. Agree with Juergen on apple-apple comparison needed. cheers, jamal On Tue, Apr 22, 2014 at 3:19 AM, Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2014 at 10:26:58PM -0700, ramki Krishnan wrote: > >> It would be good to have an empirical performance analysis of >> Netconf vs FORCES; this would substantiate performance advantages, >> if any, of either protocol. The following reference provides a >> reasonable empirical performance analysis of Netconf vs SNMP - >> http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf. > > I believe this comparison is flawed. ncclient uses a pure Python > implementation of SSH while the authors used a Python wrapper around > NET-SNMP (a C implementation) to measure SNMP performance. And the > authors state that they used SNMPv2c (no security) and SSH as the > NETCONF transport. (It is also unclear whether all NETCONF > transactions were executed over a single session or multiple > sessions.) > > The design of such experiments is not as easy as it may look at first > glance and it is in particular important to use comparable security > algorithms (ideally the same crypto library). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Wed Apr 30 12:48:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0661A02B5 for ; Wed, 23 Apr 2014 07:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.445 X-Spam-Level: *** X-Spam-Status: No, score=3.445 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKSDcq-DE3dn for ; Wed, 23 Apr 2014 07:42:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DD40B1A03D6 for ; Wed, 23 Apr 2014 07:42:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> In-Reply-To: Date: Wed, 23 Apr 2014 10:41:35 -0400 Message-ID: <006701cf5f02$211325b0$63397110$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0068_01CF5EE0.9A12EAD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHQB8lGI9QG/kFEwl0YY9mA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/8gIYHVCA3qvn7p97oFE8vmYv6WM X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:49 -0700 Cc: Nitin Bahadur , i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' , 'Dean Bogdanovic' , 'Russ White' , "'Jan Medved \(jmedved\)'" , Alia Atlas , 'Jeffrey Haas' , adrian@olddog.co.uk, "'Joel M. Halpern'" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 14:42:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0068_01CF5EE0.9A12EAD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0069_01CF5EE0.9A12EAD0" ------=_NextPart_001_0069_01CF5EE0.9A12EAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: I started using UML to do the information models because Adrian Farrel and Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf models are still mining the existing SNMP/Configuration structures. For new development, I suspect UML may help us root out redundancy. Why? Because I think I've found lots of redundancy in the RIB_INFO model. I've attached slides that may convince you, and an alternate drafts. I've assumed in the information model that yang models as defined below +--------+---------------------------+-----------+ | Prefix | YANG module | Reference | +--------+---------------------------+-----------+ | if | ietf-interfaces | [YANG-IF ] | | | | | | ip | ietf-ip | [YANG-IP ] | | | | | | rt | ietf-routing | [routing] | | | | | | v4ur | ietf-ipv4-unicast-routing | [routing] | | | | | | v6ur | ietf-ipv6-unicast-routing | [routing | | | | | | yang | ietf-yang-types | [RFC6991 ] | | | | | | inet | ietf-inet-types | [RFC6991 ] | +--------+---------------------------+-----------+ I've attached a revision of the RIB-info-model draft that provides: 1) Revised RIB Grammar in RBNF (section 6.1) 2) (section 6.2) Spot for the pdf graphic attached as draf-thares-i2rs-info-rib-only-v7.pdf 3) (section 6.3) Yang tree structure (per yang documents) 4) Revised Usage - using simplified grammar Basically the complex RBNF grammar boils down to very few simply statement. The Yang Tree does not provide an easy way to design/debug redundancy. I think that the use of the UML tools that create the Yang modules/Yang Tree structures could speed time to market on the designs. For example, all the I2RS RIB is simply 5 power-point slides, that then can be generated into Yang module. This seems the normal progression of the process you started with the Yang-modules. CAVEATS: 1) For all mistakes on the UML and diagrams blame me - this first pass at UMLs, and it will need revising 2) Some of the redundancies could have been fixed in other ways 3) I did Yang modules to demonstrate proof of concept 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES Data model can do the same Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, April 22, 2014 8:46 PM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern Subject: Re: [i2rs] consensus on I2RS protocol and model <..snip> 1) Why do you think that only the RIB matters in the long run (Short run = RIB + BGP) - [Andy] Why do you think I said that I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. [Sue]: Agree! 2) Your modeling questions are important .. so let me ask a meta-question and then go a level deeper. Why does netmod never really publish an informational model? NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. [Sue]: Other designers on lists stated they suggested they considered IM in their design of YANG. I think the graphical finds redundancies wrote: > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) Russ Andy ------=_NextPart_001_0069_01CF5EE0.9A12EAD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

I started using UML to do the information models because Adrian = Farrel and Alia Atlas encouraged it to replace RBNF.   I think = that the yang/netconf models are still mining the existing = SNMP/Configuration structures. For new development, I suspect UML may = help us root out redundancy. Why?  Because I think I’ve found = lots of redundancy in the RIB_INFO model.  I’ve attached = slides that may convince you, and an alternate = drafts.

 

I’ve assumed in the information model that yang models as = defined below

  +--------+---------------------------+-----= ------+

  = | Prefix | YANG = module           &= nbsp;   | Reference |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal style=3D'page-break-before:always'>  = | if     | = ietf-interfaces         &nbs= p; | [YANG-IF] |

  = |        = |            =             &= nbsp;  = |           = |

  = | ip     | = ietf-ip           =         | [YANG-IP] |

  = |        = |            =             &= nbsp;  = |           = |

  = | rt     | = ietf-routing          &= nbsp;   | = [routing] |

=  |        = |            =             &= nbsp;  = |           = |

=  | v4ur   | ietf-ipv4-unicast-routing | = [routing] |

  = |        = |            =             &= nbsp;  = |           = |

  = | v6ur   | ietf-ipv6-unicast-routing | = [routing  |

  = |        = |            =             &= nbsp;  = |           = |

  = | yang   | = ietf-yang-types         &nbs= p; | [RFC6991] = |

  = |        = |            =             &= nbsp;  = |           = |

  = | inet   | = ietf-inet-types         &nbs= p; | [RFC6991] = |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal> 

I’ve attached a revision of the RIB-info-model draft that = provides:

1)      = Revised RIB Grammar in RBNF (section 6.1)

2)      = (section 6.2) Spot for the pdf graphic attached as = draf-thares-i2rs-info-rib-only-v7.pdf

3)      = (section 6.3) Yang tree structure (per yang = documents)

4)      = Revised Usage – using simplified = grammar

 

Basically the complex RBNF grammar boils down to very few simply = statement.  The Yang Tree does not provide an easy way to = design/debug redundancy. I think that the use of the UML tools that = create the Yang modules/Yang Tree structures could speed time to market = on the designs.  For example, all the I2RS RIB is simply 5 = power-point slides, that then can be generated into Yang module.  = This seems the normal progression of the process you started with the = Yang-modules.

 

CAVEATS:

1)      = For all mistakes on the UML and diagrams blame me – this first = pass at UMLs, and it will need revising

2)      = Some of the redundancies could have been fixed in other ways =

3)      = I did Yang modules to demonstrate proof of = concept

4)      = I suspect with Jamal and Joel Halpern’s help (FoRCES gurus).. = FoRCES Data model can do the same

 

Sue Hares  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, April 22, 2014 8:46 PM
To: = Susan Hares
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi = Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

<..snip>  

1)      = Why do you think that only the RIB matters in the long run (Short run = =3D RIB + BGP) -

[Andy] Why do you = think I said that I don't see = anything special about I2RS at all. = Editing operational state would probably work the same for other = data.

[Sue]: Agree!

 

2)      = Your modeling questions are important .. so let me ask a = meta-question and then go a level deeper…

 Why does netmod never really publish an informational model? =

 NETMOD publishes YANG modules. I suppose it is perceived an = unnecessary.

[Sue]: Other designers on lists stated they suggested they considered = IM in their design of YANG.  I think the graphical finds = redundancies

<snip)  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: = Russ White
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi,

 <= /p>

On Sat, Apr = 19, 2014 at 8:22 AM, Russ White <russw@riw.us> wrote:


> = And the basic premise of I2RS is that there are requirements for the = work
> that were not addressed properly by the existing = configuration protocols.
> Otherwise the WG would not even need to = discuss protocol modifications.
> So the fact that NetConf / YANG = works for device configuration does not
> seem to be evidence that = it works for what I2RS wants to do.

Precisely. Otherwise, we = could have just looked at the problem, and said,
"let's use = YANG." But I think we're starting to confuse the problem = set
because we started by trying to boil the ocean. Once you actually = get to
town, it's hard to keep in focus that you're just there for a = new pitchfork
handle -- that game of checkers over there on the porch = of the hotel looks
so interesting, and the hardware store has so much = other stuff than just
pitchfork handles, after all.

So, given = we are _supposed_ to be focused on the RIB interface, and = not
protocol, configuration, device, etc., etc., what specific points = have the
use cases brought out that either NETCONF/YANG or FORCES not = fulfill? One of
the primary points was timing -- are these other = systems fast enough?

>From my perspective, these two systems = don't fulfill the I2RS mandate on the
RIB side for various = reasons:

- I'm not convinced on the speed side. YANG feels a bit = heavy weigh for what
we want here. The flexibility is there, but so = is the cost of that
flexibility.

 <= /o:p>

 <= /o:p>

Can you = explain how an off-line representation of the data model can be fast or = slow?

You mean = the YANG compiler takes too long to process a YANG = file?

You mean = the unspecified I2RS protocol will be too slow on the wire = if

it uses XML = or JSON encoding of YANG data structures?

 <= /o:p>

 <= /o:p>


- I'm not = convinced YANG has handled the atomicity issues in a way that
makes = sense for the application environment we have in mind. RESTCONF = seems
to go that direction, but I'm not certain it's a complete = solution (?).

 <= /o:p>

YANG is a = data modeling language.

RESTCONF is = a protocol.

Atomicity = is a property of the protocol.

Which YANG = statements prevent this from being accomplished in the TBD I2RS = protocol?

 <= /o:p>

 <= /o:p>

So, IMHO, I think = we need to either consider FORCES, or "something new." = But
we're going to have a hard time determining if this is true if we = can't make
a solid requirements list. For me, these are:

- = Atomic operations at the RIB level
- Speed that's comparable to a = local routing process installing routes in
the RIB
- An immediate = feedback system within the RESTful mold that tells the
installing = process what happened, and why, with the route it just tried = to
install in the RIB

So, it seems to me that we need to = return to the use cases -- there are two
in the charter. If we want = to discuss adding others, that's fine, but we
need to gain some = focus, and stop trying to boil the ocean, if we want to
make any = progress.

 <= /o:p>

It seems to = me this WG needs to start asking the right questions about = the

data = modeling language requirements.  E.g.:

 <= /o:p>

  - = What are the data types needed?  Is this a static set of will it = ever change?

  - = What are the high level data modeling constructs = needed?

  - = Are user defined types needed?

  - = Are re-usable data definitions needed?

  - = Does the data model need to be modular?  How does it grow over = time?

  - = Can vendors add data definitions that extend the standard = definitions?

  - = How are new definitions added in a way that does not break existing = clients?

  - = How is mandatory to implement vs. optional to implement functionality = handled?

  - = How is mandatory to use vs. optional to use functionality = handled?

 <= /o:p>

You are = asking about protocol requirements, not data = modeling.

IMO it = would be near-sighted and extremely impractical to = choose

a language = that only supported description on RIB info.  I fail to see = what

is so = special about RIB info that would warrant its own = DML.

 <= /o:p>

 <= /o:p>

:-)

R= uss

 <= /o:p>

Andy

 <= /o:p>

 

------=_NextPart_001_0069_01CF5EE0.9A12EAD0-- ------=_NextPart_000_0068_01CF5EE0.9A12EAD0 Content-Type: application/pdf; name="draft-hares-i2rs-info-rib-only-v7.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-hares-i2rs-info-rib-only-v7.pdf" JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwvQ3JlYXRpb25EYXRlIChEOjIwMTQwNDIzMTQxMzI2 WikvTW9kRGF0ZSAoRDoyMDE0MDQyMzE0MTMyNVowMCcwMCcpL1Byb2R1Y2VyIChQREYgQ29tcGxl dGUgMy41LjMxMC4yMDAyKS9UaXRsZSAoTWljcm9zb2Z0IFBvd2VyUG9pbnQgLSBkcmFmdC1oYXJl cy1pMnJzLWluZm8tcmliLW9ubHktdjcucHB0eCk+Pg1lbmRvYmoNMiAwIG9iag08PC9QYWdlcyA0 OSAwIFIvVHlwZSAvQ2F0YWxvZy9WZXJzaW9uIC8xLjQ+Pg1lbmRvYmoNMyAwIG9iag08PC9Db3Vu dCA1L0tpZHMgWzQgMCBSIDE4IDAgUiAyMSAwIFIgMjQgMCBSIDI3IDAgUl0vUGFyZW50IDQ5IDAg Ui9UeXBlIC9QYWdlcz4+DWVuZG9iag00IDAgb2JqDTw8L0NvbnRlbnRzIDE3IDAgUi9NZWRpYUJv eCBbMCAwIDc5MiA2MTJdL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgPDwvRm9udCAxMyAwIFIvUHJv Y1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4N ZW5kb2JqDTUgMCBvYmoNPDwvQmFzZUZvbnQgL0NhbGlicmkvRW5jb2RpbmcgL1dpbkFuc2lFbmNv ZGluZy9GaXJzdENoYXIgMC9Gb250RGVzY3JpcHRvciA2IDAgUi9MYXN0Q2hhciAyNTUvU3VidHlw ZSAvVHJ1ZVR5cGUvVHlwZSAvRm9udC9XaWR0aHMgWzAgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgMCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyMjYgMzI2IDQwMSA0OTgg NTA3IDcxNSA2ODIgMjIxIDMwMyAzMDMgNDk4IDQ5OCAyNDkgMzA3IDI1MyAzODYgNTA3IDUwNiA1 MDgKNTA3IDUwNyA1MDcgNTA3IDUwNiA1MDYgNTA3IDI2OCAyNjggNDk4IDQ5OCA0OTggNDYzIDg5 NCA1NzkgNTQzIDUzMyA2MTUgNDg4IDQ1OSA2MzAgNjIzIDI1MiAzMTkgNTE5IDQyMCA4NTUgNjQ1 IDY2MiA1MTYgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgODkwIDUxOSA0ODcgNDY4IDMwNiAzODYg MzA2IDQ5OCA0OTggMjkxIDQ3OSA1MjUgNDIzIDUyNQo0OTggMzA1IDQ3MSA1MjYgMjMwIDIzOSA0 NTUgMjMwIDc5OSA1MjYgNTI3IDUyNSA1MjUgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1 MyAzOTUgMzE1IDQ2MCAzMTUgNDk4IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDIyNiAzMjYgNDk4IDUwNyA0 OTggNTA3IDQ5OCA0OTggMzkzIDgzNCA0MDIgNTEyIDQ5OCAzMDcgNTA3IDM5NCAzMzkgNDk4IDMz NiAzMzQgMjkyIDU1MCA1ODYgMjUyIDMwNyAyNDYgNDIyIDUxMiA2MzYgNjcxIDY3NSA0NjMgNTc5 IDU3OSA1NzkgNTc5IDU3OSA1NzkgNzYzIDUzMyA0ODgKNDg4IDQ4OCA0ODggMjUyIDI1MiAyNTIg MjUyIDYyNSA2NDYgNjYyIDY2MiA2NjIgNjYyIDY2MiA0OTggNjY0IDY0MiA2NDIgNjQyIDY0MiA0 ODcgNTE3IDUyNyA0NzkgNDc5IDQ3OSA0NzkgNDc5IDQ3OSA3NzMgNDIzIDQ5OCA0OTggNDk4IDQ5 OCAyMzAgMjMwIDIzMCAyMzAgNTI1IDUyNSA1MjcgNTI3IDUyNyA1MjcgNTI3IDQ5OCA1MjkgNTI1 IDUyNQo1MjUgNTI1IDQ1MyA1MjUgNDUzXT4+DWVuZG9iag02IDAgb2JqDTw8L0FzY2VudCA3NTAv QXZnV2lkdGggNDg1LjIwMy9DYXBIZWlnaHQgNjM4L0Rlc2NlbnQgLTI1MC9GbGFncyAzMi9Gb250 QkJveCBbLTUwMiAtMzA3IDEyNDAgOTYzXS9Gb250RmlsZTIgNyAwIFIvRm9udE5hbWUgL0NhbGli cmkvSXRhbGljQW5nbGUgMC9NYXhXaWR0aCA4OTQvU3RlbVYgODEvVHlwZSAvRm9udERlc2NyaXB0 b3I+Pg1lbmRvYmoNNyAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMTIwNC9M ZW5ndGgxIDc2Nzc2Pj4Nc3RyZWFtCnic7Lx3fFTH1T88c8vc3du2d+3uXa12V9Kq94a0qIAqIIki AQLRe68GjDHgBu7GBXfHibEdF9EFuOCEuCU42HFJ4thxSWLiBMd2EnetfjN370oC4+f3vO/71/v5 eMXeKbfsnO+cc+aUuQAIABDBNkCD2Jxls1Yy9fmLcM9vAEj7YM76tUrfXadeAyDUBwCbMn/lgmVf fNEmApCJz+vdC5ZeMl/35TO7ACg8C0DrmYXzZs3957sF7wOwrR8/o2Qh7pAeN8/D7U9xO23hsrUb O/KOfQjA5VYAqvYsXTFnFqNjxgHw9MO4ffeyWRtXBsaGQwB8U4+vV5bPWjYv8+fh23F7LgBS58oV a9YOesCVAHLk+crK1fNWLnmSiuP27/HjjbiP1r4pgNAFTJtwC9csOwFjmqHStQ0g0IprEthKLaSe pFfQ6+it9C76WvoB+hXmStYi13if9b7su8t3r+9rv83v9Tf42/xT/N3+af4e/6X+Q/5T/t/53/b/ y/8ff1wxKqlKWMlTipQKpVqpV2Yqq5TrlT3KYeW48k6ADVgCjoASSA2EAzmBgsC4wMzAzsDewMOp VCpKNaSaU22p7lR/akZqNLUxdVbqvCAVNAYDaWvS/hMCISokhowha8gZeiD089BvQr8N/S1yWdbS rA05jn3ufYFvmXgwPjg4SOjE1CjgfmoR1UevpTfROzE119MP0meYqzE1wHvSG8fU3O8Hfqdf8Tf6 J2jUzPRv8x/xP+9/0/+O/3P/FwpQzJiaXKVAKVeqMDUzlJXKWuVG5X6lX6PGPoKatkBnYEfgxiFq TJgaV6pPo6Y3da5KjZLWm/Zx2uB51DwaelmlZn1Wb9ZaTI1jn/ItiCsqNXDwv4Qg9i0ABnNILd4P tM/g0n9cRcpPd4IRn39cgf+2g4t8PiwE4Jz+wyiu/eVcO+n5+40AfLLkn/d90PdhGQAfbP/gsg+j H6b8dVLyjn/CD1o+aP4Ac98/7lGfnftB8P1vAXj/w4+7Pm75uOrjB0nv2Z6zE8+2nx13tuWs5awA wEdnP3otcf+fM+bQs+MAGH4iv5DgQPAixKNlzQCg69Ft+Hg/ep5L0V1NTunv1D8BAP834Q7hF8Jv RLuoJJ4ipotzxd+IZyVKEqU8qUiqlwj/qzRK2xJH0pIOJcctvTlMtfSKdEY6K3081P4P+UpfaK3P R1z5sRQ/H7HEWelzmZFTEj3JEtB0M307fZR+mCmn76BvwzJzGX09M4qeRK+mu+il9D/pc/Qn9L/o T+nP6M/pf9P/of9LT6EnM/XMaKaBbqPvAgwwATNwYtkMgwjIArmgAlSBalAPGkALmAK6wVQwA8wF C8EasBZcAjaBy+ht9Er6cnoPvQmegxQ0QCN0Qx9MhxPgVNgDF8GlcAVcB9fDS+E1cDe8Ft4I74SH 4Un4HHwevgB/Q2+nl9M76Fvx6FvoR+nH6J/SROJvojj6XniGXsg04dHfT0n0g8wY+iv6a/g500Hf TG+hMukv4av0IiaLyWQK6HGAxVqDAzqgx7rSABzAC3zADwIgD+SDAlAEPKARa5U2MA6MBxOYGjAR LAKLwRKwDGwBXfAOSEMGshBBDvJQgjbohwoMwCCcAWfCXjgbeuElcCu8DG6Dl8PtTAxeCY/Ao7Af HocvwV3w14CHOiBAPZChCCzQBKzQDOzQCmzQAlzQA9wwBaTCNBCEIZAGwyAEI0CBqSAdtoMM2AEy YSeIwokgG04DOXA6KISzQDGcA0rgXFAG54FSOB+UwwWgEi4Bo+AyuBzUwJVgNFwNYnAVqINrQS1c A8bADaAJbgJj4Ua4GTTDLaAd7gAdmMM74RVgMrwaTIPXgR54A5gOrwcz4U2gF94MZsM9YBa8hTWy JjAP3gUWwHvAUngMLIcnwAr4FFgJnwar4DNgNXwWbICnwKXwZbAVbIOnwXb4W3A5fAXuRdewv2Nf R7vYN9Bu9k32LXQt+3v2D+wf0XXoevZt9k/sO+y76Ab2z+x76Eb2ffYD9kN0M7oF7WH/wv4V3cr+ jbmJeZb9CN3GnkW3s39nP0Z3sP9A76G97D/Rnew5Zi/zAvsJ+y/2U3QX+xm6m/2c/Te6B92L3mf/ g+5DH6Cb0IfoL+iv6G/sf9kv0P3sl+xX6AH2a/Yb9BP2W/Qg+x36KTuAfsbG0UPsINqHAHoYQfQI otCj6OeIRo8hBj2OWPQEQuhJxKE+pEP7kR4dQDw6iAR0CB1GIpLQESSjo8iAjMiE+oEEBWCEMpgE r0JmdAxZ0HFkRSeQDT2F7Ohp5EDPICd6FrnQSeRGzyEP+gVKQb9EXnQKzIG3gvnwbuRDv0J+9DxS 0AsogF5EqeglFEQvozT0axRCv0FhdBpF0CsoHf0WZaAz6FX0GvodXIxeR2+gTBRFb6IslI3eQr9H OegPKBfloXxUgP6ICtHbqAi9g4rRu6gE/VkX1kV06boMXaYuqsvSZetydLm6PF2+rkBXqCvSFetK dKW6Ml25rkJXqavSjdJV68fqG/VN+mZ9i75V36Yfpx8vVUpV+g59p36ifpJ+sn6KvkvfrZ+qn6af Dr+E3+l7KEk/Qz9T36ufpZ+tn6Ofq5+nn69foF+oX6RfrF9Cmak0ykFlURTl1y/VL9Mv16/Qr9Sv 0q/Wr9Gv1a/Tr9dv4Bme5RHP8Tpez/O8wIu8xMu8gTfyJt7MW3grb+PtvIN38i74Kfwv/IZiKaNc SNmodEqQFcpNpcJBuVgulcvlSnmUXCOPlusoyI5hx8oN8hh5rPSo3CQ3yy1yq9wmj5PHywXyBLld 9lFRKlvukDvlifIkebI8Re6Su+Wp8jR5utzDzmbnsvPZhfJMuVeeJc+W58jz2NXsWna9/KL8LnWP /E95gbxIXiwvkZfKy+WV8mp5DXuFvFZeL2+UN8mb5S3ypfJWeZu8Xd4h75SvlK+Sr5F3y9fK18s3 yjfJt8i3yrfLe+W75Hvk++QH5Afln8n75EfEKfwSfim/jHqAupO6m8qn7qVKqHKqimqmJlDbqTyq gCqkiqhiqpQqoyqoSqqaqqFi1GiqlqqjGqgx1FiqkWqiWqk2ahw1nhpFtVBrqEuoLdQ26hZqNbWW Wk9toDZSm6jN1KXUZdQOaid1BXUldRV1DbWbupa6nrqOuoG6kdpD3UbdTt1BXU7dTO2ibqL28rP5 eXwX381P5ZfzC/gN/HR+Jd/Lr+Wn8Sv4Hn4VP5NfI82VlkjzpKXSfGmZtEBaLi2UVkiLpJXSYmkV P59fyC/m1/Gd/Bx+Lj+LX89P5Gfwq/lF/CR+Mj+Feox6nHqDeph6jfoFdZA6RB2mjlFPUW9SR6kD 1K+ol6mfUj+jHqL2UY9SP6eeoJ6k+qj91BGqnzpOnaCepp6lTlLPUb+kTlEvUC9SL1G/pn5DnaZe oX5LnaFepX5HvU6LtEQbaCNtpe20i3bTHjqFDtBBOkSH6XQ6k86is+lcOp8uoovpErqMLqcr6Eq6 ih5FV9MxejTtoJ10LW2ia+gc2kf7aYVOoyN0HZ1Ke+kCulS6TLqOeouuxxbA9dLl0g3SdulGaYd0 k7RTulm6QrpFulLaQz1DZ1DP04XSVdKt0tXSbdI10u3SLukOabe0V7pWulPaLH8i/0v+TP63dKm0 VZwm3idOF+8Xe8QHqEdoszhD/Ik4U3xQ7BV/Ks4SfybOFh8S54j7sE3ysDhPfEScLz4qLhB/Li4U HxMXiY+Li8UnxCXik+JSsU9cJu4Xl4sHxBXiQXGleEhcJR4WV4tHxDXiUXGt2C+uE9eLx8QN4nFx o3hCvER8StwkPi1uFp8Rt4jPiifFS8XnxK3iL8TLxF+K28RT4uXir8Tt4vPiDvEFcaf4oniF+JJ4 pfiyeJX4a/FqbCNdI54Wd4mviLvF34rXimfE68RXxevF18QbxN+JN4qvizeJb4g3i2+Kt4hviXvE 34u3in8QbxP/KN4uvi3eIf5J3Cu+I94pviveJf5ZvFt8T7xHfF+8V/xA/rn8OPuc/KTcJx+QD8lH 5H75uPyU/LT8LCpFH6EydBaVo7+jCvQxqkT/QFXon2gUOoeq0SeoBv0LxdCnaDT6DNWiz1Ed+jeq R/9BDei/aAz6Ao1FX6JG9BVqQl+jZvQNakHfolb0HWpDA2gcGkTjOYAmcBC1cxTq4GjUyTFoIsei SRxCkzkOTeF0qIvTo26OR1M5AU3jRDSdk1APJ6MZnAHN5IyolzOhWZwZzeYsaA5nRXM5G5rH2dF8 zoEWcE60kHOhRZwbLeY8aAmXgpZyXrSM86HlnB+t4BS0kgugVVwqWs0F0RouDa3lQmgdF0bruQhY B38B1sNfgo3wV2gDl442chnoEi4TbeKiaDOXhbZw2ehSLgdt5XK5PC6fK+AKuSKumFnL/IRZxzzI rGd+ymxgfsZsZB5iLmH2MZuYh5nNzCPMFuZR5lLm58xW5jHmMuZxZhvzBHM58ySzneljdjD7mZ3M AeYK5iBzJXOIuYo5zFzNHGGuYY4yu5h+ZjdzjLmWOc5cx5xgrmeeYm5gnmZuZJ5hbmZOMrcwzzF7 mF8wtzK/ZG5jTjG3M79i7mCeZ+5kXmTuYl5i7mZeZu5hfs3cy/wGbIYvMvcxp5kHmN8y9zOvCJSA BEbQCbTACayg56/id/PX8NfxV/PX8rv46wWP4BO8giKkCH7+Z/zD/D7+Uf4h/hEhKESEkJAhpAnp QljI5B/n9/NP8gf5J/gDfB9/SKgQqoUqISZUCjXCKGE0/xJ/mv81/1v+Zf4V/jf8GaFZaBNahfFC izCOf4P/Pf8W/0f+Tf4PwkShS5gsTBUmCd3CFGEa/74wV1gozBcWC/OERcICYQn/N/5j/iz/T/4j /h/83/lzgiDwQqoQELKEqDBGaBDahQlCrzBTWCYsFYyCVTALdsEk2ASL4OD38Hfwt/F38rfye/nb +buEXKFQyBeKhTyhSCgQSvh+/in+OP8Mf4x/mj/BPyusFNYKq4X1wiphnbBG2MB/xv+X/zf/Jf85 /wX/H/4rQRYkwSUYBKcgCm7+Zv4m/kb+Bv4WcaI4RRwjNoudQpmQI5QK2UI5/xj/c/4If5g/KraK LWKb0CQ0CnVCrTBWqOdf53/Hv8a/Ko4Xx4kThDnCbKFHmC50CJ3CLGEG/1f+L/yH/Af8O2KH2C42 CZcIK4SNwnJhE/8n/m3+X/wn/KdiozhWikjpUoaUKUWlLClbypFysWeVLxVIhdi/ekx6nF4tFWPf eT29USqVyuip9DR6tlROz6Bn0nOkCvoG+kZ6s/QEUyFV0xOkGvoLaT/9Df0t/R09QMfpQQYwkKEY mmHgewzLIIZjdIye4RmBERmJkRkDY2RMjJmxSKOlWqkOe3QN0hhprNQoNUnNUgtzhn5IapXapHHS eGmC1C51SJ3SRPoIfZ80matmokwek83kM4VMMZPDlDC5TBFTypQxGehKbhQzmelipjDdzAxmJjON mcpMZ3qYiUw1vYUZz7RKU5haqdtAGZwGl8Ft8BhSDF6Dz+A3KIaAdFCawUxiXmX10jHpuHRCekp6 WnpGelY6KT1ncKDLuBK0DV2OtnOlXBnawZWjnVwFuoKr5KrQ1VwNF4NRmAPHwjLYAhDFEycRAs3r Hf5AQOE/8qEu5qOfd+X///1MoHqIDuwdNoIJYBn2+mjs92F1jv0+G/b5/KrXNxP7fcTruwR7fFux z7cde31HsceH/T3MaQ+qnupN9Gb6ZngHfT99L/0A/JzimFrseU5kWpkxzFimkX6S6WDa8Dx3UruZ cfAMfJVpx57llfQ4uoVpYsajG5g6ZgK9kF5EdwMa+6867JliD03lccLVmMOZGDMJ+5ZbmXT6IXou PY/MJubzLfRseg5Tgf1dP/Z6A9jXTfi4eap/C7CfSzzbRXA+/BJb25JmeWdSfioLfvdjnO3HONuP cbYf42w/xtl+jLP9GGf7Mc72Y5ztxzjbj3G2H+NsP8bZfoyz/Rhn+zHO9mOc7f9TnA1/uHuxr37L ee7kBOwDrQHb8N+V4DpwC3gWvA1mgx24thfcDx4Cj4A+8Bx4Cbx1Me/9/+0nfgm7DIj0UeyxWQAY /GbwXPwh/O1n5RE9t+CWhVGGewaNg59c0PdJ/JZBY7wfmQGv3itRr+Hef8OBwW+oGtIeLCFt6ipc N6h3fMbdG38yvu8CDNqxXzsNTAc9oBfMwvQTDzfhHS7F/uFytbUcn1uAj/Nxaya+ag6+itSHr1oB VuLvauwZrwPr8d9KXF+jtci5VWp7HdiA/zaq3vNm7Hteqh03qD1b8JlNansj/m4Fl+GZuRxsV2vJ MtGzA+wEV+BZuwpcDa75H1vXDNV2gd3gWjzP14MbfrB+3XmtG/HfTeBmzA97wK3gNnAH5ou7wN0X 9N6u9t8J7gX3YZ4h527FPfepNXL2KfA8OAyeAE+CIyqWczBqCUSSuMxXMVyJMdiCKdwxYsQJ/DYM obUV005o26VRuhH3bx9xx3oNR3LlDnxl4imJeSBPufQCJG7ENCTqwxQlWreq9A/3jkTlf+pN4nH3 CGTuUlukdmHvD9VvA/dgCXwAHwmqpPYTXE/U7lPrI/vvHbr2frX9IPgp+Bmei31qLVkmeh7C9X3g YSzbj4Kfg8fw33B9ZC1RPgEeV2euD+wHB8BBcAjP5BFwFPSr/f/TuYv1H9T6Dwz1HAPHwQnMIc+A k1jT/AL/JXuexn3Par2n1L5E+xfgl7hNrkq0ngcvYA31Mvg1+A34LfgVbr2iHl/ErTPgNfA78BaU cO1V8Hd8HABn2L8AGYwGgD2Ocb4bzAAzYmPnzpzRM33a1O6uSRM7O9onjB/X1trS3NQ4dkxDfV3t 6FhN9aiqyorystKS4tyc7Kz0cCgtmOp3Wk1GgyTweh2HWIamIMhqCI7pVfrCvX1MONjYmE3awVm4 Y9aIjt4+BXeNOf+aPqVXvUw5/8oYvnL+BVfGElfGhq6ERqUKVGVnKQ1Bpe90fVDph1Pbu3D9uvpg t9J3Tq23qXUmrDYk3AgE8B1Kg3NhvdIHe5WGvjHrF+5q6K3Hz9sv8HXBunl8dhbYzwu4KuBaX3pw 5X6YXg3VCpXeULGfAjqJ/GwfHWqYNbdvQntXQ70nEOhW+0Cd+qw+VNfHqc9SFpExg93K/qyTu67t N4LZvVFxbnDurOldffQsfNMuumHXrqv6TNG+jGB9X8amvzgxyfP6soL1DX3RIH5YS8fQD8A+NmQM Krv+C/Dgg+f+eX7PLK0HhYz/BaRKSByCCZ9P1gEeGx4hpi8QIGPZ3R8Ds3Gjb1t7V6KtgNmeAyCW G+3uo3rJmZPJM7ZJ5My25Jmh23uDATJVDb3av/ULnX3bZivZWRh99V8I/8PnlT463Dt7zkJSzpq3 K1hfn8BtYldfrB5XYrM0Whv25+Xi62f1YiIWERjau/pygyv7rMHaxAW4QyFzsKizS71Fu63PWtcH eudod/XlNtSTcSkNu3rrEwMkzwq2dx0DhYPv7S9SPAcLQRHoJuPos9fhSQk37OqaO7/P3+uZi/lz vtLlCfTFujF83cGued1kloLGvoz38M8F1F9U78K0XXB18mJCORfSKV2Uh+4ms4U7lDH4EKytwieM eLrUJpnR2iqlC3pA8jL8K9oVpHbec3CDDtU1klM0ubWu0RPoDiQ+/8OQPNqY2FCfbsSzjLhjaEyJ 3/nBoSWuJgPKUBrm1Y8Y4HkPZbUBak+7+DgpgoX2w/gOHZnOxuQpOoQlF/dR+DFqF5lFp9IHJihd wXnB7iDmodiELkIbwVqd35bOYEv71C51tjUumXheK3G+LNHqAwF8Otmg6jAPjol6ktOqtseq7aFm 4wWnm5KnlV26YEvnLvLwoPZAoGAJwkSjcNOs3WXmIiyaY7B2C46ZFVSMyphds/oHt83etT8W27Wy oXdhBXlGsGnurmBnV5VHHWtH16WeTeSnzKAFtkyszc7Cuqd2fxBe3b4/Bq/unNp1zAiAcvXErgMU pOp6a7v3p+FzXccUAGJqL0V6SSdpKKRBntSBGzr1es+xGADb1LOM2qG25/RDoPbpkn0QzOmnEn3G ZB+F+5hEX0ztIx88Sc6FGGKsbhuUuWR6tnQv3NXbTYQL2PFU4n+wDwarQR8VrN4PKST28cF5tX1C sJb015D+mkQ/Iv0cZgxohxgcopN29QaxnsIM1QU8MMGKNHmk0j84OLErcNpzrjuAWW06/k7t6tNH se5nQ834urHk24u7x/ZtmzOLjANM6iL3cqGmOd2YbZMPxJc09enxE/TaE/AVY9R7CDvim+bgucET qN6/DTf6tnX3dUfJj3Yt6lbZ2dgHGoMVeNoTz2TD5Idyu3eZgwWqbGJR4ENXkUKPxwY6uxI9HtzE P9adAIkT8cjnBPGpOb0KRpsBczoxqyd0Ke9J9MzDKpEJz1O/vEc7CQhZdEiQ+D59Dn4g/kfqQg4R STbEdXcnBq+2rtIuwL9t7BPwiMIjoNRuwOjgU01kLPjfVXio5NLnyGPa+0FHcCPWLGTQ6pM4fLpP CjXNwso/cb+Ae4JlyZt1REcI2jNOJXo5QrmIcadDE/sH9wUvCYz4ZGcFyeJAGBN4jmHGBt27Luzo mxbNztJd2Cup3bt26aSL35DASycNlaRTacCrBr6QxR7bGvo17GHRgAPlag5t2lNAgh3ADirg4cO2 +npdNvcMrMOCoMCJQAcgrIsZGEo66nbXBI8Wo+toU1M/zD5Uw11HUaBm4N2BV3IH3j1nLs89B3Pf ef/d942fvWIqzy18//X38/OgKWBSv1aZ4jgrCqbmUMWRcElhYUE1VVwUDqbKlNpXVFJaTRcW+Cja muyppkgb0q99N5UeP4CorcGayYWsz22wSoilUpzm7KqQsXNaqCrHy9Ecolkdl15am9qytCH1j5zJ a7N7zTqd2Wu3eU3cwNus/M3nrPxtHbP02z00qpxek0bfwesoBqF+n9OVWRlommywGBnBYjTZdZzZ JKbXTx+40pZCnpFisyWeNdCGYQkOfsNsZa0gFYTBPcdA2uDZQ6IRtgb7tUq4f/DTQwKuCMkKjysx N6mFjOQoqUdRPcbSYYiczhJgW1owHPqPKIjOVG+Ql6CdEYFoFKkng88Gfxukg2JQNHs7zJPYSaCm psZcXp6b29NjcpSbcNVUaDxXYCrEiEd7ouoHRKMhux2pkEfoAC3TwdRwuKQUJnB2cEE6wKzTQWPI 7w9Z9MyKgb8tpnlLMMUbMkAdPMBIrohPyXTLzGb4Z/iLUXaPzNCcqIeV8Zf0kp5hZY+dOSDIOprW GYTrBjaTd64eA4CBmLt8IArKwIsxt99phG1+o4EcJHxwivigYFr9/VROLN1ti+Hzthg+b7MJWeTi LHJxFrk4i1ycRS7OOk4VYJ//5GFcB+FCjPRBfCUuPz1o0EpJLb84KKrl2YMCKSljTLpfOClQgjvy n/x8Lq0f6g8Y24v6obCfmwhqztWofFsOc3veV0EreD2aqODuaLQ8UcegWmUmGEgNF5uKSgoDGD0b 4WcfDYtyqGDQRJjZMlxloL9s/JxVTfEnHBkZDhheu2dOgT06OrN4ekN6fMBdNrX5wKm6jhLXuNDY Je2vfFPZVReGa0Yt6KjOtPkjzPaIP2vipraciWPLzHxxx3IK5rYWp8R7gpXjB96p6Kryx8tSSjvw 2jVr8FNGZH1YimcfTAGVUQ2VqIYKLv9JUMHlJwSVqIZK9BmqEPtMTpgLAiAMsw5YOpkTMBMUgzyY s18/GYv06+fIF+YmyDe+eSo/L2SV0QixRDZNTIkA26w+itBN2IoRKVZnjc3c3LT11ze0dd726mVl i6eO8ehYmtEJOrlg/Krxk6+bW1o858ZpbWvaiwwcj+ijRqdZtmZEPBN/+tk9D3z35HSbkumRLW6z NcWij+RGGq58bsvmpy8bHc4NI5MPSyDhshswl5mBH2yIeWsC0EI4x0I4x2LFNFvMmGCLE1NrOUE4 B7gT2Lg1bNwax7g1jnFr2LhPUCagx9iIB+R2Tz8M72cTXJLE4vUkR/QQjXYeS3AjGOCGyT/79KH4 J+r0hx4+e0/74aIVj1755P4tj64up+58+NufdSQmesqDZ/cuOryz+TtT9bbnyN43TBm9BVOWBdbv d0e0GY1oo45oo45oo45oo470U6aYXm9RLAoevLsf6mLStjA8GYZnwjAcRq5+TI/UHsHFfjTE9T2r VmOyclU1YtS4X51n6nucHgyYLqjSWxhe0g3cQiik5uskHcviQxzBAzqsGhg9ro+joE7imbFmj1mX oFZn9ljNHpMuvlhvTLGY3UYunq8zeVS6B7+hJ2K6I2D6fs6i0W3R6LZodFs0ui0a3RZM92HJC3xe DpN20GJxoX6YfjC13UUUpLYi5Z4ylQ9RB79HTHK1SZJLT8SEcXGMHocHr9ZjOqvidqZadZjUMWrv KUsKpqKRM3psFo9JP/BXTuJYFh+YJwiVXkLRtMFPmI2sAmrAT2LelBSDk3Cok3Cok+g2Jy+SGqbC SWZPAs9GoBKJRXojdMSg0W/Q6DdokmzQJNmg0W/opwoO5RbBImc/5A+lppbnVp+APF7jeZhxoLzT 2g+z9udOJvONpdmUgEPTc6/39JwaUnQaLudJc0mpiXABkXYVLRPRgMPyzzAbGZ3IiWUzdkxd8uj6 moZNj8yr2lwcf91kYvR4jbhLsJt5c8X02XPzb/vng5N7Hjl3Y/P2eQ1unplh8Vp04ZzwuF3PrNhy cme91wsvSU3DMOp0xhRz3OIOe1OdYs9jn+6585u+We5ghjs1wR/MBLzm5oL+QzX5MChqEIkaRKLG IqLGIqIGkUjATXGkCQR9gaAvEPQFgr5A9INA1ggHiNnwwhKzkIPRBFtBDJ8Hjv7BkwfxCVIewecc mR14AcmKGU6K8IwIxfNXYyxQ52ogXjVeJ7BqLDcsWD2hIVYbyXUJrWnDfckqM0FnDTjdilU3cBDX XITzdNZUpytg1VFtKi/imhujj1lO1FHVA79I1pk/JmsD31AoWdfkC3Zh/GxgwtEax3jHkw4aaBAC DUKgQQg0CIEGITiOdSI/ePIoRoI3dqjkYjKHFGHoe8TAruS49baAwzVytMMjTEr9V3hUhWB2zJRP hCGPzEkuqQV4bXy8Nj5eGx+vjY/XxseTKRZtkY4Ab/R0GIeto5qk0sbo42NinOFwBF4Efs0oslkR B6HdTn/FWVM9wSw7F0+7cA7gy8joCLjdioWTzPFO+IqJSyEKEBl56qqBS4ZUwfBcPEfV6EWOYXGH 5HYMDA7c6bZour4FU+8GjceALUGsTSPWphFr04i1acTaMLGHgN7QYeuHUU2Zw9zTyckYob2HGIso tRaskfUDpxwZQ0ScISZci9Vj0WPd/ERyqN8+oDelaDODolgfV4HHYsbe6pXVlJSX58jN5XOcTnf/ /3IxJRPjS8sXRZ5IH0+kjyfSxxPp48lM84S3sF0XcxFGSytpF5wOKdeZn4P86e3+SUnhqjFjI7cQ E5q0zrClaxyqmcpH5RYWEtt3BC8GIbF3seULg+fpeNX0hYVkvlV8UFRn9bscAYuOihfSgs1rtfms AhUfC7GkuZx4krM8C5W8NKcebmDhlYLbH3YtM3gs4jBLL/h2D8dzNINNGexc7B3qfygzTXSne76b Qj/ky3QJeovXpmmyrawJjAJXHIwYDFYNTLU0aKWklp8SMK0amFYVTB+fk1NAwCxwGsgBX1hgFEkN X1JALjECX1kHn2OIMC6yDhIOUeEj4H0Pu9xCjWUSSGHZCNrttovg5aMdheERXMVslWxuqdQdCQZt 8YXK6BSKonQWv9PpN+uy3B3eiN9rghXekoJ8J8RmgMXvsitm3Vgr9qYEb0GEeq/80srG25q/+/eQ tDyanso7MvwDLxbN6e3JHf/z8dQz2NfAloTIkXcG5gyeY86yAWDBFsKWmNtKMLAShrISc89KzD2r MwFTYUyvgDz1/7LwaeD6NE71aQupT1tIfRq4vhPYJOaBCy+bhs4gkSx28vlmX88IT+A891S1+kbY wMzZ5lve3XPzG7vrm/e8u+eG169rOByZdsfKlXfMzAhPvX31qjtnpFO33fPd/plTHvri/r3fPDlz 8s/+/cjyp3ePm3jtiQWrT+5um3jDU8TCxZrxBSx/KSADbNyfhjRCkEYI0kQOaSKHNEIQYQGHyUvg 8RJ4vEZRgq1e4kN5sbVwAJhC2FY4iJCIyRQO2trFEaZSgkGM51tLwQtNJGaEoUu/ENvw+MZb9JaA i2iVTDe0ZbYtWtaacbhySk/WfXeNWzAmjb5l1t3Lq+I5Q3KBp5pz1Ey/ZMr4xUXywNfpY+ckZng0 exWe4QioBNfHvHzAnE6oSCdUpJNJTieTnE4mOR1TEuOBkpKXsi2FTinQwCnQwCnQZrlAm+UCDRws H4WHzAFeyu6HGYccnSGmlEy1RKb69dMEhPLh+R6yjsrz81gNgQga6QJpPiALL+AATAUvImv32p3V +bfNSXLC7t/d0GjJqM5sWt6YbtXFH7uQKVY7/CYUqJla5cua/NCX99/5NeGMz+9p37NzZXZVXarB EqTeW/7U7nGd1x1fuPrZazGbPA0SfMIImE9KQD24KeYz5phKdZjUUoJaqTr3pQTFUgJbKab/aAbx tzNqTAQrXDNpmJk0hjJpDGXSMDNhhjqQkmPEPsWRlTEYizlGYb45HGh3aKpZ9STODQE3wn8u13SL Gn7Iob/HSHaHj9bcaIfFbodF4Ug4nHSgBGRN87kDVoHZYMuunli5Jsli2KGy5I92t6wZFwnWTi9X irLTrWtlXXygfoKrpvCmh+vn1PqxatZhzYEVY37RlJrgwB+GWA+b5ywtlU1eUTd6wfgKqxytGpcf /zDNS1/RusjBoXhroHIC1tFjB8/RczAvNoGPjoHRg2cPGYywdbQG0WgNutGahh6tQTW6n8qKRQti FitsLYiZYFtaQVqB6HGSez1k2fMYjeSAb/GQ6fAcp/LJ2nfQo9paJw+6tNKaKI8YiCEq5pyAEVCK TfpwTDAppbA0JoiwFc/PyRhPaqWmUpO9Cvs/h0d72IxOO+ZtTXvhKThnIt5dNNpjPGckAj5smZoT Jy5Qa0yStxPhuRz0A+4+oufUbXigZ/SKKZUOATsCOrlwwqrmsp66tIKORcsXdhRWLrppYnRKW5UF MRSNBE7Ire+pKJlQ5C7oXLx8cWchXDLt+jkFdiXVGfLbvWYuNT3oK51QWDquMr+weuKq8e2XTc42 uPwWweS0mFMs+pSg15tXGyoZV1VQOKpzFZ4jA9aQb2HOTwXzjjpjxKMyEdQOEQv2f60uiflhGjx5 mHA+MhPn0atpxAJs4n6mgvOrqPFUdMh1HDbik5pANbDeUl3ePUlbEdc0l5jeqTrEqsf47b1DjDhb Z0qxWBJBRWJvPYrXt0uwLRgFe2Pe3myoEKlViBQrhHUUYjEphGsU4q+YRvormNOAXSPYrhFs1wi2 awTbNYLtxykjseWJV8MTFtLjR/DhDmOHZ5hvVCdG04PRYRbpgd83mzWVN8IwuKRhW/+6JX1b6xNO s0WX1bmuqWVde1SFJmDRw3fXH9tWW33JkQ10MAnHd59PvbI7O6tr+xTaMdI/SMXabSFGJQ0sj3nT iGJLT4NuUobdMN0BwxLMcsEsJ3T1a0KqVojacyZ7SCVmJl0up8sZDvk7nKw54cWYy2tMZpgQBEIh 6OmBPT090Z5oSDUeGWISlZSMMBkL7HbEUUcZ2RXx2gNOk8jR8W4dNKenpgTMegaugXARrcOqy58m 0TofCY5CbPcLOuaAGj7VSfy3zzI1pJ+ETwmNo7Cl/R6msQosOBiugnix+ipWRwQ7hFlQRyrpuTBk VHtCMNVJKhmp0KmQSnY+zM6D2WkwOwhLOzI7gnkCPdIpxXZfDZ45/CFhYe0vNGQZ08nahWSeTzC7 gzGmZPj80RSZiX9GfUPL7gwlkJVioOOPImgKK/40C0fBIIRWWm8N+VICVj0NMyjopZEl6PUFjZAN yyZizZlk+tXvcpN15ucON0FFFr49xVQIBqy1dQbh2+eZSh7XWdntIAjlYUn/QvX982LejFyYkQPD Thh2wIgdpgOY0REUTN4O0wjHD0trj/oZDoBDOBT/HkHtEImQ/ovEmjNSlTSbwMTfi7/DirY0XyBs YCU4K/6kyBmxggrbeQTt0MryllSvP2JixHhftd1tYGmdoKfogQFsrNKswW2nOqkau8fA0BxWCinw LzqJU+d74FeEHp9q21lBJug+hheA/70TLmLBdaixjZMxkQQ7Qh0eZO5AGi/Dkfp8WFENk4tXWUdh SUmpZYiTmxL+oE0Xv1lgDZGAL2QX2IOuAjflyHcdogVLqjstw8gK8Mv4kLDCd6g/kmljOImPX1u8 trJ8VSlcz8scmTA7tkmm49Wzhn4Ze/Ux0BdTDLX+2txaWtA7ikRMURHRZ0VElRUZiXwW9cMvYzKI RAwAioBoPFChrawVmi9UoYFQkZTpin5KF7OaHL8CRcYiqvJkEQRFsKgoZ3RmP/TEDGdSYWoq4/04 p3nUn8Q2BuQmI55qEKxn1YyepGF/Kjqjp1yLfhZgg2UG9iAJw2Bfp3iEsVdYrNl4Wg+j6jousRja SbCMrjGmeNx+ufKm9rFr2rOr1z68aIs9f1z5qFlN+aIOOzKcp3by/KJZV08M//S6+rm1/u4Jo1eM cooitsTFqTVjQmPmj25d2RwaUzSh2OMNenVGl8HldQe9lqxJWyeecmTXZIzprK3H6O7F6L7BrsLc gz3Iw1hZ84ESjVlKNOYp0fAibRWvkn74VcxjixILOqqQnADBP0rWmKhRTRVQfEwPbHxJcYBh8/oh eyTc7BljbC3H1f1sm7oqYAgd5UNe5DBmQ+tCxPb9BSKhTJJOEmey21W34Y3COTf2RJvGjInozB4b dgsRZ1GcLuwjprc0NqbP3j0l/Qlb0eSYUh1riNRvqavuKnXBj9ad2DnGFK7IWI5ZEbOfqGPLVEsP Hwb+mlEWNI7b0beuYfvcUebM2oL43s4pVXM2Y3mbihFT6JdAMbhmf4pqYSUE7j1N0M4eIgJ2kWD7 J+cH2Qc/TgTfKSEm5cpQdn3kj/FSoz+tH1KHLM30P/KJ/aGXGvOz+iHar28jmZToOfUwFHg9NRRm vyCdghLmFRqZTKEViuVcVS1dubNum1c8etXe7mh7fbFTjyizZIhUTarYcFkg1lNVPrkmKpIQxE9M LpPkCnnNsc0H113x7KZKozvVKVuc5og/kB44+sSUHV3RtGhQZ/ES36EX43I3uwyEQTnYHfPXVELB U06ks5xYG+XEWi0n3FFOmKX8BPwaAJCbQC1XAytXAytXk9hcDaxcwlC8JTBGKI94GBmLJXvA2YxF nTkot7GtxMBS2anmgryKyk9DQZyRIojdhSGuosPhkQ5XKX03Z0qxklTt2L3T5lw7Jb1g9k0zx++I cVY/4Sn9Q3WX1tdgDsIcNTowKjYm4koy0Ia2yW079s9ee2Ln2IY6SkhGIwYaMO/M3hKr3z4P81Jd PkGrB6O1F2u1KCgCT8Qyc0tqSlaU0BYiTRaFJCksgSxi22cRtBLpS1W/YV74+nB99KdRiiTmDhNp K2I05mM0HlPbglomFBxD8AsEsl7YxtzIUCcZeIaBDJOS+6dws/PjXnmlTMn6j1NUBusZmc1JCOU7 0QSzqTlMVUBRMDCCrWznMx9li5SogHL03ohr4IBvzMr22NymXJETEE3RnFAyeVVsxb7VFVWr7p+z +Nbe7IfoSzaMml6dSlFUJNCycXKOzW3jZJdZshhEweW0VG/q37T22OUN9Wvu6rJs35PTOq+UrHuh wW+oK9mN2NKZe8BuJAKoCp5H01qepLbyaOrMozETNk2/PpCXGeofPBMzk+h8iD9XMtYdPpfXqLQa G1UvtIDEaqKnCj9LyFjhqQtyGjYtujvSCw1q+Y3CZE6DuhLbaoiz+TI8oSJFfgmv6qzZ8JIOqyan YtFdZjQSVXNZsHFZc7A2TcQ2nMHikFm9oHcWtlfM5kxuS5ry3T+IuUeSnbRNSbO4TVzPjKsmZ0gG 0eIhGfLi+C30NfSLoBqMAzPBmZjNnD2WSNlYHSZ5rGK0wNaxhTXYCiQQ1Gjyhcv3jpBTNdx4XI1J BjNsHe9hDHl0IccR7jGqeJ2MSbiSXch5PFxhNkMwjhURkLvIT3QpRnxbV2YoJuAyZMjj6LLmP4qd Z2223jL671WNmUrtH8qap/1BGa8lCWsSaaM3E6o/WniagOvABjMxmU2403g6iv9FkweCOsbYbk8s BeEIwvrM7tA8/STPleLltahEPSYkO1BA3P+h5ZQk08ORiExrLfoai+HyYEpBz7ZxpXM8Zsfokn/U rezIKVry0Kple2dnGQP5Sn5uQcifVjT98taMsX5oNJni8Xk9eWNzHfOm5TfmOjpntv9dyXDqd65v mVftodcG/WlTcsdt7Mzy2s05vmAOxVOBUd2V1Ssn5Ydi3UWB6rJCl6s1a1RvONRT27ZpYrZeF4h/ Nn2BUtaU3j3fX9o4MKOihtK5sjPSbaPrvHnVhL/3YrvufrwyF4BLDtUUwczhNKXG2CPyl1o+Ey/L Dl8iGaWmpdSMlKo2BHKOT+ShfJkuI15RjmY3p41xtarqUw28wFwtDZNYjMvPT8aoqwl3kVxHwhq0 0ffrzIk115nTlFe9pR431YB3cikee2PT1M2tAVeSnylD24z6tK5JA7uTPSPX35amUfOvmUU05RWD 38B2NhfYQABce7QmOD64IkjbNVvuPI/UopbvXeC5JjzVE9QqkAJsP5QG0SC1YZiO8H6yf8TfD6sP uYxNKj5vnotq2lBbWS6eqbKQZZcwI+ZCWH0hAJasyooo+Q5BQO/kEgRzMK8iM6Mcf5MzvwXPfBG4 NSbWlMCMfJgfM8M2bBCcUYeZryn8fGJEiGqpKvz8E1QEpGLDPkHND2cxMTO47dnZgBCaYAp7qsCm N6WMMSUZQg1fYvMC27OqFix4L0n3EOH/q9TXFh22+j1BpwHFd16ICJyoM7uwx5Bq00uG+HG4XBLU YBt2dPTw87j0fcb47jXsG0h6Gi8jetFpjB+Ph0w2DTNYjTGzgZiakVyhZiQv7vwkZxtgHA7xxjEq xdr8XjwD+b25dH1/aNoo2DN4VZ8APo55zCTvqO4aCav+dkR1tld2wDHf33mQiAGO2KHw8ZBE+3x2 kmPwFSTyXGrGS012qYLN49Xs6AQStZlQ/f2NHInHfm/Dxwn4FVYrRogOtDRjcxPFpNHN1WOyy5qy W10j5n9kyqJci8SaypO5WqIfQHQoE3pxJfFDWsOm+ZAas7BnEsrDorNm1eeUr2kgi6QjYOHsWXU5 5WuHdAkypzjsXiPXekNTWXd9njG7vWVs2pT1Tf5hrRIsv0CrfL+H3omXYprWC7oNk8a7c0en59dn WrC6aU1qXTyDBWBPzJCYQXLQFPCFs/QD+0iIe+QTjMakHlY3CozYIwC/OqqpYqKIY3x2c6YrrSkJ PVknh3RxMn+iof2/UMi2/5tCHgLx9rb/i0I+DygMUC/Rx8T/eRcjRHJnD8dSajJguhlmmEj0LCzC sA6GOZipxmsuki9776L5MmKe+nJ5yI9IxCnnJ+KOk/8LbPDkUQNoW4mnydUP4QFDcxD7SppDSXwi DbLcofRaT/Lzf8uz0e9WrHl89YqfLS8pX/PYGlyWPuGpXjy+aVF9wFOzeHzj4noF/nX5sStbarce Wo3LZlxuado+u7xo5va25u2zyotmbCfedHwP/QbGhnjT24g3HSi5yD6DhPYZ3nBAlm1bwpFWXWo1 xp/wqS/qSTcZx/+gJ30xR/oiPPLDjvTNM9LrR8fSRjCL1eYxcxmtbe3Zs3cRR7pQdaTHROo31VV3 l7rh39c/tWOsMbUoGK9O6kLm75hnaBLHuiSzOsPWuvPJdQ2Xz62yZNTlx+/s7Kqau0XTltQ+NbIz 59DKYhg2aBANb0jSoDJoGBoIVOYRgWqCGXBjBEMxfbQ5bLApTbZWoCkvdfmKDtkyIw34i4mNCgmi 9lFIr9M5vGk2V15xRfBCoQmNrij3SoE0r8jQkJ5t95n0er3OmtNaOtD3fbHZUVIfMdA6ntfL6r60 9sFz1CuY4ibwSkzMbalpGd9yWcuTLeyIZNAXWhJIlZjRJLxguSBJpCaH4J9i/kRGSM0FEeWiJYSI i0MkyHMcfqFuhuDJIi/GBC3UF8bPqxGfFCkx551S/h+mCaZe00oTnUj8vE2yPs32swnWGkr5aAmf HhLCH5HwGbaF/p8mfKhXCmdsH5c3pSHPzjMkoROtmVyWWV/gicQmTGqPRTI6NnekNVZk2Dgar/U8 0qeWNOVmxjJs6bGOSZ2xCJQbluL5drisaX6L28h5FI85WBIKF6X7U6PVk6uKZzVliWabUTTYjSaX kbO77JZgXkqkOF1JzayaSOYiMPgvahnzOKgA0w9lAFMwW8M8W5uLbG0usjUtlq1xZTZhQtEhZZ8L Nnqlc47G/H7I7OcSSug0YbtCLfpw+lQiNMNc3EE83420J91papnOqGTkOMbMjXm3Gswk63Np0uz4 iMT+zIaPSsc60lKsOlbPMtO8qUZZj0Ita8ZRcsJDfDO51eHNhA8Z53tm6nk9KzsJ3XtInIZ+Cq9w N8f8eF0TIoSDIoSDIiQXElHtiohRNSDg10cSkubXUPFrqODyK1U2SeWgugFbE1a/xqPYgP46prdk N0UE1tWEzQx2OFgzcjvVEEtdNFhzQXKopHQ4bHM3Z/baHF4TartNXcg4a8KxduQ25lVvbuCsfiy5 Zv3Q+rZh0riqBdfMplKT0jnwn/Ez60Jdk6h1yR4tS0RvxvhkgQ+PgeAg1s3EbPOruZOQH/oSFR+0 a3TatNI6bMyppXko5z34aayUJMzxGmmCESNMZ2FqOu4YlQrTUmGAVGsCMC0AFbVXgWkKjBjg+gAM kCCF3mRrDChYagMk96THrBggESLSIjMRIM8XyRa39KaA4G4SWofj91Gyb79HXQejiX9qJiOBO8ne RNU3KYY2Nw0vkA6LIxHY91H0ZkjRVPw0I7nTfb50l8zEX2FYsg3H4Q1a9Eycob+leEvA4/CZOPo+ Rs+L3HePkKQUo5N5eopo1tPYxaHwQT/gFkXqb3pRR1M6gaBdjC3mnRjtBvDuMTAWq6dRmLQyErzI KIOlpAzlwHAAhhUY9sOwD4a9MJIC0xmYQcOKSlhZASuzYRV5z9UG24ya+0fKGI/Z1ajgJxgNWjcp 1VSHgXQbRjep1xEwa4zjjSuMlxkZY8xsbzQWNoWaKm7MglnkXBbRmkaLvXFB1oYsqgH3Olr1BOQ3 CJI9p2pqTmMkE3gPp/4Syb/EJwE0GsKZjnAjcmUXgXxEld3JsPEvacmR7vNnukT6aYp6kpbcGT5/ BLfiX7MMtpUdKalmHf0HinqB0psx2/vNOuotCr5J6S0Bt9NLpoWzGoYnhbpOrx9YMzxFBiunF/AM Yb9rwK3X4xmSsOIlmw2dyRal48l8ZWDpaMHzlQuuPAbyMTAmEp8leiOHaIzKHOjE/HiE5GOc0KHp Bnuyyw71hFsziRdG7qkCsCwISwQoKMRYJrMiCPl5GU0kB9dkGjKIE5nV3KGsKmHeBP9GQ3Zr8qUU +iI5OYtlOCdXp7NE/L6gTWB+/xYj2FJTvCET1ENn/EsdtEQUb9DKM6fPMLzJ7/GGzJQ+/nWWbBFZ 7GtycF78LlzQrGiR4VG4T7ZIDI14Lr4fjkdkt55gNcRnEO2BLcAtGJ800HEMeDCtxUTyPTDDA52q K+iEYblEpiJ66CZLcoUbusoIcC7ob3Lxlia+hRkPWjQXjGRbowmhJcIboBOkllrIvtNw0VCW1aIG vuxWjirciPIL3IqJQlv0Rjr+rM6Y5vOlWvUshPRXyJSqpKSZUPyw0cSKVhmWM2aenm5zyiytM0gD OdSbFoHF64RZjbt8QU9hZ4Ai0AjCMTktza+3HmTZPH19BdHtcH/eGLLkvUPezlLjeokY6dBrWXSY rHUJO+B72a4L7XF6SsHUrW1cMGLzmXUI6s0pZvvo6eVuJTartmJKLIPnsBJH1vL2WUVL7pybFz+l d2b4lHSXXu9KV3wZTj39566re0vYzwwGwrYQrwsWLqN+ekH5zIawy+dEJq/d6bL43eZRC6/9rjIQ 9QiCJxoIZLsEwZWN5y0z/i5cA94DHsAfEBwpwPj66cSGI45LSGqpZegVsjVIdpiuYSWLy2Jy8JC5 QnCmuV1pDuEGf1FOtusVjtepwgMt2zyKESGjQvymE4NfwuvoW1W/ybMfWPupzUd5XxB7fYZGUHO6 5jQxHAq+vyXQdEEbXodp9ivpWDKd6Yo/gcF5bVpRsgh9WUpqNimzB9IDiQ5MMFbA7mwiybfj8SzH FAvAsZ9scTl5hGxl0dNY5PBQos8R8keEs5bnVlflkO+ysbk5DfhLos+3DX7JfAreJc8AQZD5LHBS W4APiNRmYMY0bzmKAja9x0CeWVh4uqAAr/nk7/xHsz9Qh4tyqypyyBf+MofUKrGmP5XsWzomN6f+ Il9MGYx/RPPsM8AGdPuNLMjFnOnQJlGLTnEPM5LVa3MFzAyiehjJ4rNh84phP5MMOoaTLBLaLBn0 eA6tEn5eAzxE5VCjgAHIhwAnnGMA2d6oRacDieGSbTtUjtkUn2HGH/gTnYRF7uuIzx8O+5DJDeDg F/AcQ1Fb8VNMB/BTjsEU8EMPYiiL5bsai9lsoZ/TG/QsVRIOBsOhoF59u2Xw6/gtDBh0AgkYDgOO /ztD4uvff46dAUbTd6NMZrOJ/qXRFH8zqPiCqakKpuiK+D74b3Y3nrPUmI0mipsmLgOtbvGjbX7h ClCTi/kxkfxH2EY1O4b2PuTQatQ9gST818yemdNYKHtdZrdFpEs6ylL85R2FUG9MsTtSjBQ7+6V4 95tvxaf+WjQJLIV07PxXf//OqlV/+sNrCxiEsBI1Em7chEf0ER5RABQeA+aERWXWLHJSHiYjM6sb 2QTV50uMMFowtN+MS2r/EnNxERUJa4uq3Qw/SilrL6FFi9vs9kqQnT5jxgyGMqY4bCkmHbVgHeVa 9c7vX53P6hDFCibxZbjvrTfhvpf0Rh6PDjGn4+Px+J6Nn6Q87AbgB/Jh14sG9wtk7nLPJSFPWqqB IYNeNeU9BnkQiHazIJjtIgQIKzGD/OCDpIx/F/BwRo8VRS0eE4eMDpOS8k0VMqh7VKbGT8Ij2q8Z X3QZXkDar7GJ7dWaIzHsUqhRyiOC2SEOytjhFLgHH0yUg6LDLHxj9WAXKWByGBB7KkUxOYyIM3ks 5Jcmx5+h6tltYDzwxqSaGu+LFouu6O1w89s69RfV1xlHJV/p0WxyotCTXFBSUpxMuyTfguLUDFli K6ZNDbCQU1Q99kiQ2WOpm1xgNgVLI+QdBvICaHOTpXBSrcVl5rRXvTKcqTbBmFFfVFSfYeRtAUem XsZW5qDRIekYGJ20bfEr9RNrIgyecYfBaDcgSnfZlgcWbZschQzuMhLyoCl/cvfNTQs6KgW+snN+ 8zNdk/PNUEN3HaZ5Hqa5ndCckdH2PMsai96u9b1t/D7NmKtsyexTUgmXkkVNpR6DoK5uQ6e02Buh WiV6HlkHMsuCsrVg8miL24pbCGHKo85UO29KbygsbEg3ERrTBQPPsHpJjz222skFFoKQjpjJpUa7 zEGmcMKcRpVGbEZLGo3mPExj89q5jQKfVdfV/Ez3pASNZqND5pJINeS4WJ1BjZHfS92NV/Srse3m jMm+dH8k18EZjIgXggJWkmYHdsAgNpQQikQsdqKHSy0cIttoS0sjRK5KHA46TDQzR5eW2LFC4Di6 SaYcDq/4Rgqt5OQodMrros/hgPJnn8nQ4fCJryf73xC9Dgclf0bvQ8FIull/V/wbgxHrHHSX3pwe CaIli/HiHzHr74SsEX/i396J+8NBbjFeOZdgj/VpVlEtkb3HQDO2Oh0Gqq23GUbX1cD5NbCuBhbV wLQaWNNP1cWsYkqKuKkYLi6GLcWwohhGi2ExPnFkJYBE+RFnILE36uxR/BiQJ0Kxf/CbGI8bYsVg Xh4b7ofggKW7vh/a9rMzh97rxeqm53Vsd/a8r1r1ZrLVR62R97GiI0IgzIUhD+6CeFsy6vh00dKH VrVvmT4qZDTnjN/w0PJQaywLzx0FOUEvhEvaCnuunJRBu0e3Tc5fdGN3+AlHydTaUHNDjTtQM6Mm NqPaCx+cdN8lTenNS3f9dEbno/fuXlClN5gFyWCRzW6jTjbJrdsemW7wOQ3l867prZhZmyY5/ObL n1iUndc+j6zgHRjb4+o++VIwFm4/BkqIG28im3xwhSjd4n6tpzjZU5TsKUr2qK9Mm4ZfoW5SNxzj KWqCeclr8pIBgpE9atoqr59yxVzWdHX1SVfDD1pdSWzPd8bcPkPQ5yNvqVjVg8/q48vUa8qIi2zz YqdRvVHrJDeWHafqABh8/SCZ5OFJH9oRre3bOanliE6q2wdqiX/Ck2fU5uGH1iYHXZscdK026FrC aiae2PB88Sg2e8DV3TAwxCzlQ6+0vZ5wts/bJo0L44hoLeEeENU+I82/0oSSHX47gKaLhnb1OEpK yEviybx2CX28atVDS+beu7wivWV5Q9X0WCB/zt75s2/oySKbesauaIn83lvWWbx0had8StW8pZmp DQvqa2aO8l+xc9sO2Dpxx9SczI6NbaPmT25J9Te0Ty+p39BVmNu+vKZwxsQmJdg8aSY1M7M+zzV7 UqSuqtxftHXgJzkto0cF/NW1TVmzFi/BctqIeekF9a2aKPg45rogLRBKpgWyiT8dItyRDUcE/EmW y0qiUFYyeVbysr71BEX+lwklEYBTNOZStOyYooWicHmW2K5pClT6qeyYnicv7MQArf4/CXqyn4gf z1NAjaWoL40lGOKkKvGAB3x2lqcf8gcMneRtluTLOsN7ebHvhQV9ZDZGnbL/IbfAjMgtMPQLucv6 Lt+0b340b2nfts247JM90aq2vEmLR9l9o+c1lk0aha13atetX+yfNeWRL+/f86VaPjbrzvWTSl0T rn1q6U2/3laRVjdj9RVYfT2BxfY+1gFywF9jaWk+mOaFaSkw6IFpbpjm0vayZqjYm4lXnafu4yBw 50FAoAUZWkQzQwM0Q4vtZWiAZmhuewZ5/Uf2OclNToEcBZMmR7hU5cqkydGI/pPaCx8YenzH/SZo spj7Yc3BYEeGsR9yibcMC2oGTqvxZPI5TbbYJHfHJ4RhOHbSo72EmNwej20llIiZlIa07KFqa9H3 IV7iBqZzooBXWEkH5W/IbhoaCXqYyYhmp9mpmNHHOlnP1pOIMWd0W8xuk57+/a08I/kcJqdRRM+S /wSU4QT07Q14ISZr5mqM9t2Yp6vBHmwrlMCoD2Z4SRwq1p9chmLQTrjYrmoeu6LGO6jsI4Uh/AfK NazLj1OXASEBjkCiTgLJCZrKyhWlHDNfzpFCO8rpNJb3w/QkQonoe25CmWAFcnro1XoVIzW+dB44 JGR0gbONhnQHp75YcDeL/YmBYtlm4GjeIH47ZVG5OaV4QpG6sZQT8MrD6pyV3UsqZ1zXk2Mfe+WK 01ShziCwzeStCc7os1vx8i5BfvrNG2dHo20VqanpqTqzz2awG2VbWtBZPH1TQ/XmG55c/aberGY8 FmCdcDPGrwuyx8BUDFkKgWwqzNdhUPKJ4OeruOUT3PL7qeIYP64zPG6c0wLbYiTeGcaXhEkYLoZ7 wzFa9uiMyQyHeqdHUTd1JVjWg5E/rIaW1J2YRL5ljTVljdtlMnEWPA1yJdn+UEkCgq25lVBlXY2F EytApanSZC/ph0KMb+rM+reisE3khRhh6IUYbCcah96Jwao7N6HvNV2vbmwiKXNz+bCe15QFUl3c oTxJ4pVJzZT/XsRkeBJteAW4uXrto0tGr+qqMOgQLUv64s4V9bVz61OjnZe0bcZzxSFB1q+qXdQU cRe1F1fMai3gSeQKe16WikkrYlOvnpatVE+trFsxIRuu7r5hfqnN65dl7A2npSghJbV6UkFpVywV i4fN4jJwqbHu0vSmEn8wPcgaPHaDwyRb8DznTFw3dtSi9nKB4oonEN1PdtX/Tt2FngO+jVWQoG02 jGTBtAhMC8NQCgx7YFBVUCEnDDlg2A7DNhi2wrAR4ilOY2Eatlg9UNVW5oS2yrY7ccWuGLV9PYn9 PO8dJft9UnJyjP2D38W8+AojET9iTOIDifmSRcRInFoj+f83IoBJ6CoGLwDJ7ZExnuyPZPJyI54c dYKZaMBo5AMdfGL3O5a6wnMFBVrUMapldMjLrqfVclgCL/jA8zcFDokmHNZVdhiEAfp3VvPNyXeC Bz4WjRL2jXkOvsZafFm+QL7PeLPJFn+Aik+D++DKQDj+aTKNAY3I6HNafC6HRJuJi8DqJP13zwep vw9UEImbhyXuNlbGGuu5mBQphZESNSlPqxrrSEJhlWpaqVT9L4XIa33khYB0DH06eUmSyEW6PL5g RcFlBXTBxV//PE4Vqm8baGvpYXUnkaWfpOjJ3jSLs+T/tHcm8FEU6d9/qrtnJiQhByRACDDDfRoQ ASMghPsIRziGU47cCeRiMuEURVAUBA8EFRUBbwEVRkW8UVFRXHVd8Vh311tRUfFclTDz/qqermQS DuO7+3/3v5836De/p6urq6ur63iqqgPy7zaI7tb3R4/8ft7RbUKzGk1n1tey6XTvKuLeslvMgVlv cuPhwpWlW91aamwrSheobY2/VARzcPtDNPP64Sv2FPUvmtwHk11DToEju4woHDmkbEJKxwkXTjl/ WocWzdwtjfMjYiMdCY2CLduO6lF6V+l5YlvBbaV945OaxUTHN28UnxwfkdSyuWdo/ugBcwa6o5u3 N2JbexqgE2zXKbjJYfTOXBsK6XmJ4TRfJlny2WgDD6Dk3fT2oxSPvisyvrUYEx8XZ/8CZM1fjDxi j5O/qLroV5tDcfv0VXFxvI2hroqzr1Kno+T+U0WcbDhOe+uptX6zrUWYY/uOcmgT7RE57Fu3I/Zf CfDBw7gm0RG/T5z1YPMJUVW/qKaGZPUWutp7RXrLqHq3SC2zh/+VHuYDpqOBM5jiiG3arnmbDvGG U3x54rrGjR2RMQ2M72MSo5zWgUYtk5Nijr8aHdvAdDZs3NAa3aldY4wrzkYtUJr2TASl+QrJ9dLZ ItXcYo6ihpRMLR+iGFdi1BMiUv5DRPjZjORnpKL7OX/qWXvVK77GkbmlaeyJ6NgmCfHGj40Swm3T 7OR2d2rXpk1wqtzWat+mDf9rcY59E2+d9tHLc2L7/0RJEeqvgX78qwtlnujQXx9cdfy3E1c2OOra S/JfZTPsfycKP50UJHEgctvx337b1uBo7X+xLradFVN9JF4jsrZT27riTA69IrFm0C5rKGWekqM4 d5RusEKULDGP0C4wzNbhNtlgDrjEDt9l3ke7HNE0szZWJdIDjjTyGBbtMqzQaGgn6HngbJABxoNl CG8FOlobEG89uYz1oXutTrgemLMUl5hZtl1GLazZtMv5NtLucgpcYAxl/y7jGee3lG21wb2AIwv2 NNjMJKl4vhE2iaBZ1fFnFBuOow3tqCvWWmrjakXn18bqSD2QVquTeJr62TRX+iPF1RXHBaGPJJZF 281DVHwqrFzaDuZZi6inxFyBuCuQF1aPTTfQGQy2w7ebGbhuJRWdxGKEL6Z11hZKE0dpuzgamgZN go4EHYEXTAQLEB4PmlnJtN0YgIY7ILTOfAlpA+MDxeXGZ7Z9DHk7TNudTqR/bRWbwWJl54EdlPe7 PMYgnTzzedwLWHtgfw2bGaZ0PI1iQj+Bn6uOp1MLc3ooyIr6uJ62gltsvQFU2PZJmCeotXMAnVsb 9Fp9zFV4Z7UppKE2EUoP0wW1aHWKMIWzO2P1os1oPzNsxoGp+thVSjOcfweCQdy51jowD/SiTPM4 zaoLxgJq77yJ2kccpvbWTtg323b/WoyvhR3uXFiLNbWww2vEb4B7DAlLe1X1OetrxtGY2rs6UXvz APWujXrWk9ls9QrdZw0J/SreosvEW6ESaCx0BvAAH5gG8hEeDzab++kyqxVdIb4MHbbJNm9HuI2M A7oYLZSmi+PUwjhBm5058l41GKf0ttAWpal4HzUZf1JYf8b5inp3Op25xsu0mQn9Ci0xW9MEBvW2 deiEPnbczyCtzeI7xL+fWhsHgNQnqIP1GbW2KuoGyrq1Kx31+926gXxuBFfZuhqMBWtse2M45hZq 49hHvWtjLkKftJXanERnmm7jUppKPjOTcszFqKu7aKjxKRUZ45SONPbRCPEMtTNuwDv6gopENmWK 4tA7OC4Ss9GfTUHczxTD1HW4RvwM7UGDxcfUVl5jXEZu81vqZlyEMW41uY1zabAxGf1ZBdgoR+0T cAYqjxhTTg5D/sicA1RY5VaQXytsCygUIRzfBG4D96jwXDDXbIf0fkLYcJCvwreBi8yOOB4F5lWl sdyMxnEsiFdhu8C9xrW4/kawTYV9AT4y4GMYz4KHEfcZ8CF8DuV9VE4EZ4tX4Ye8BV5l8CxjJXi2 S6FLjYuVLhT/pEvl3yzBvkhojfRBzEkYXy+lvuxDBF+UYxr7C8Fb5djM/kIwAN9govIDNlE7Pd6j jCfxGB5qoq7BuG3uhG/C4zDGy2CJVGdj3BPjqZPoGkcGzXZkBH/VY6IcC43jaoxpWzWWoW+1x63t 1kOUx+MWnu1oaLIajz6keD3umJfT7KqxZDGPH+ZMSlfjQVjf7UBJyX7dMY0ul+OLYi18LUka2mlP 1McNGPt6IN6dqKPAOIg+YAzOSQahP1pMTqMnbTR6ho6CpSBW9SsP4fnyoDegrhs01jTRdnSfUESd rEa0ENdPx/u/wEwi0/LSNTbLQRNHH/I6+pEXz93IcS9tdGygHImxRr3LSJSTfNd9DAfdUEU71PsQ lUjU+xxL96n3WWazEO+oI5lhvmOmswD3eJnSHdK/srH9wQzp61X5Wx+T6fwNvM1+o8us9uOsX/k9 Sz9V+154TmYf+oWN/K4dLRDnJ+Ajv/N7pNEK9lcU62wGTQNZNMvKpCxXBOwF8O9CuP57+G6o2Kpu fEO3KT8pwaYj3vcKignzh7o5FmMMXkFTrTU4t4auB5tsH8cr/Rc863YJ3q1Q9WWx7ZPcC+bZdUX6 XdqP2II6uwU+d3c8RyTXF+sqXFOIeL9RsbMt/J1hOJ5DTR2rEHYEfELzzWPwX3rCDmF8n0NuKxug BWIMFyoc4781BOUi69Zh9OsHbA7LMSg0DX5eUzlOhI/hSH8AfIJ0axLq3iT4VJMwpvEY6JPjmrkX 9Q1YidTEaVBjRyHNsUZgHOtkj1Vngy5q/Fld5XPIcSaJIuVYZ/fNzcw3qI0VRDj6btTFzdY5agwd 7HiTNjuCOB5NkY7JCHsWXIm6vR55ewH2IUq1JoV+lWMz3nczswTPZoO6eqfEuFlEGjfT0xLzYboM zFb8A3V7Ln0N9pg5tBRjwRzU4y6yToPHZf12rKbrEbZOhmvFO7oCdNVqh3U19pIf7NdqJcHnS0J7 sNVsSsJ4H2PCA2KtWSnux3EUjs8yyjGGALMS/iRwDaBN4SDsV7OSnqlqc8V0GVhq+PFMfpphXEpT QIWRhn41DeGjaTfIP108pHUrWAQWg4XWbppvnQ9/oJLmgfPFAbrS7E1XOjAmOTA2uf4JMG64+rM6 76MHJJh/rnDcQQMdu2gsnpdw7UDrQRqF8C6wp0Kl7zQN9qNgNI4nQYtRFl1h9zJ/wFi9Fe33Kcwf tyLeVvhprWlUxDnoKyrRv3+MOh5PLa2NNMc4hH75KGWBCagfbcy3oX3oIjMAn60P+oM+qNsxNBLc D3wgH3hALpgPssFExRCUzXpKMi9BP1iO/nAXdTALkI9HUAajqDvqhvwecSLykwHWg1yQBfqCfJXn rag/W1FfEeek/HWqc/56nCp/aB8jxS/wIXZTunEfDTLeo/bGXagj79NMjMs9jQ8R/j78lC9pAnSC 8TpNFU/QXDDtX7nW2EKp4ic625hI/Y1RqJejKcEYjmsmUA8jldoYU5HWWKRd13h7QulmYxrqmAMw ljqa2poCJoGXaJwin0Y4HgG3gT9RR8dyGgZ7GMZ26c+NjBhHIxF2geslvK9KjOuVNAbMBV3BbNue DtCG8K74vBdMkfXZ8QV1sxzU2/kXKsS7zzS+hv9XSRHS35B+gBwznbnoiyfTTKsJjUabuwlcD15S xNADrhjRV2vkOLrJmYq5Wx51EmvhD/xVjbv/IuL1Wms0SSARtLSPW4ShwqrWW45grngkdAR8YesR GYYxNRFsO+Oax8bToNcmXjg1NdYiquaXocfBHrCPwZyyyq4KuyBsfOlhHg+9Z/MuOCTDMb50kGNM 9ZwmdAR8Wa0I23YSo5Tq+cEbVayzdbhUe7wxpGLsnYSyT61eGwk9CfbbetAOO1gThGn/cEXoGLgb bAO3gasQLtcuGoCNYesLrUGbMM2zjp4Ge03AkVjFTbZWSGU/MvSd1DrVu2coz9EOfpPECR/nOvSp kguRf/hMck4nfQ45bw2fk4fPuzGPaGF8TleZTozd6XSVcQ9Yh+OhOJ5JV4m7wCFyGB8gHMdWMc5V oN+swJjzjrJnYOydaqyg4egbLPhRU42Pqbk1DH3Fw0j7SrCPMuBjnpBYeaFQOOYzEowv0dDoKjXk HEIiQqFQOEijgcTYQSttbpRgTnJpWBhzMfIM1HzpWroU7fAEwhNAYzXfqgL3lPMsOX9S4zG4iede RCHM2YJjcM/jTHAgc+JZiX3fBKS/CpoIrpOYN4kxfD0/N+dbzrWkBh+x85Eg7yXLQT6DvmdtLEEJ lhAjZGrGDhkXZfEqw2Umw9V9D0rM7+igPq/nawjfZu6ReeXrXRdQf9cFUsOhgc7XQyEJbNMmTbxP PRSfU08J/UJDJYYLY4KkAY2RiC2Is0WF9VTY4aaNmGMzkZopnqMmiqdRRwHKf0I4KPud5pOoJ81R BpImJBTNayHICEfeQ5YDnluVBdperJq7pFErNSfYgvlYiJIdF6nwMehPixztMTd7GXX+vtBbjhiM FWtRbzMwb+kAXx1zUlcD9I1dcA79qrM7rv8E1+r1YsxHrYH2urCce8o138H2Oi7mQjJdjP0FETtp V0Qi7XLKuc4IpPkISEC7RX+P+VFf1Wefav04bF2/ar29E5Xrfh7pR0Rs4rTlOZecQ7/J82fMwb/l 8ST0IZ6zBPNsOReTvyrRT821poWexnOU4D7d5b1kftU6PvoU5Hks5t/99HhUe3yR4wPSf9caGvrc nEXJ5mcYAzZSjjUfZTsM5YZ5PO57q7GdXJjrZGOO0xz9eLJ6Hrk3wWwO24+oAe55qc1K0EvtQ9j7 D3q/waaTVDxXH7BA7yWAbfZ+Qm8wF+TJ+abmpL2EWs+n9wnC9ggW1dojGPFH9gfkPkD4XoCcw1bt ATxNiVXr/rIsnw3djHlSsryfehcLcN+P8C6GYky7D/7QwwibRx3t9T/LfNBey+0h12ZD3ziH8Nqg XDswBlFH8yH0IWMw3xpA01U45mno09W6H/ylZLVmJutqHvzgAspwyfLaD9+pFeIepimYE05VY3Mv WgquCAfjehbiTJOo9ecxoY/Umuvt1FeP80g7BXPKuSpdXotFuqGn2WdAfOUbBF/FfXLhB3wtrzFe DpUbL1Oc1Qt9QC+6XNXNXvC9/4TnlL70GOTZ9jlqr5dKH8BYQzdaX/Eap/M6muvcgHtnYVyXc1T5 vKiruLa/kRb6p0Sto4ZQVh/Bj/CpuY5PxhU/YH7XGf3HDahjmG+quXb12utqOe891dpyrTXzgXrd XD+/TT5oLP0aPLvbZkbYevJ8jN9r7DVoyXQ5t9aE50PBZVC9bmyft9eH14JIlGuoen1YYar6cL+9 Dnx/6A2JvTY7CCyz12pXm1tIhK/NqvVYvSbbGed4DZZkXKTxgoojz6HMxHc0SdXFw9QZ5663svF8 74GhuOZZ6oNy7Gd8Q/3NJNTTfuRFnY+QazQgwTxEI9X8Uu5Z/UWFT4I/5rPuoDxzLRWYGfAfV1IR 5p2NjZ7wWY6GgnIdz9mTrrWuxTn4ZY4NVII2FWHv9UxSa3ircCz3dPawf4Z5Iu/BXAP/9jqab95I XtertD3Ci3Y4g7ZjDrPL+RptdxWgPcJfxH1GKJ9vPV1/0t5P2J6c3itDniZq3xH3IJ22POf0wnfL om1qzfHH0PPsj8LnXkFjxdHg67hXGa5rqa79OnQHniMH9yF1L+RX7cFdp9acpprr8Ay2P1t7P0z5 mfLcIWqHPqCjOT30lXke5rpyT3Y9jk+gT1gBP2EA0r5S7ZN1xDXRuIdXxkN72IV3vEu1h7n0tV5j tSkJ22OUXGLrJuSlC+gABgECo6v2FPVa7GK6CXikjeftItfZ9P4guMjeIyTQCbSTa26asD1CpvZz 23t/Yft+A8C11ft+Cqre81M0A0n2O11ia4Xe2wvf31N7enpfr5Ac9j6eehakEani2GWvyn025hfP Q5EXay/ifMvr0qquZ6D/2Ixw7bePsAnfV6vtz6+0Cd9T0/toddjPqcseDtru9dX7ZmrNr595c3X/ p8YC4EjGXJ33HNOt3qAf+r5B3McqJuDcFnKbr8OHOEfN67ifQv+APu4HuQYu99GMz0N3G7/KMJxf jT4vmzYqVN8XelZdN4nXIx0YA9W6dh/yop9rGwb3f1fRRtAWbfoyhezbvwwdNgaHflG6NnQA/d8g 2QeiX+loLcQY4KVrdH+n+rEJyLPs4/4CnkD/8ThNUePIRpqtFM/scNEcuQaLZ54BX2iGXDOVaaMv 7yj7NlVO9jXOUoxLb9JcVxLK5AeU7wFq7ViKso7GO7sfcQtRxt9SN1CG5z1sjQ0dNt9CnxIb+hhj bZbVCGkeonnwCzZb0+FLDET8UvLKObYh5zPXYn50jHqotVtZTn6U+yH4NnJ9+h70iZ0owfkKnqEg bKy+B2m8hvFVMhA+yDy0yVxKd7xI6c4czGv+QR5nDMpjPA02u8MfkWMI3qPxPa7DOSsDijQc3WkV xlAh55jww0nOM43jyK+eZ95DGXWYZ/JcM0Aj5XxTzTXteaaaY8q9vV28R2d1tff57D0+xSLMSyU3 UBe5zyf3+Grs742jPkrtvb6q/b334NNP4X0+YzQ1NJ6CPRznVlEnMxf1aw7mL3LfUO4L2vuBVXGQ DuJkyDjOjajbj4futp7EO48M3e28JfSp9RD8wKfQ9ieC5mALxrdYaOfQs3j//UzZh8JHcF6BsRjt wShEXSwA74EDts83Ab4KfAn4qXMt+GjiGM13XqzC9Xg/z1yGMf031BfUX/Qxnc3+8P0uhO/yTph/ YrdR2WZlnVFj8Dlok+/QRnMhpeNZ5qt90xIQAItosNw7Ba6q/dMNmGPuUPuoxcr+FGzE8TKM9+0w 5k7hMjflX0HYAornk+Vt9kGZyz3V4tA74hNV7oR31g3nShSX2fuqG8FdwAdfTb6nL7jM1XUof9De MMGVSFvuya4mtzhAk81eNLnG+j7m6mq+vplyQZFeU7TSaajEmEDfq/1auY8LW64HKFuGnYd2dB6v M5xyrWEHykrOwTNRNrN5r1jtDcv7xNH1tbGm1gRhQ6Cno3ttEF9q+9ogvDn0JBA+GHoqaufjdPEG nyEfpwrvAD2JfzUfZ0i3LfQkzpC/dOipqGs+TlfO7aAncYZ8jIOeihr5QN3KkijfWq4LyT2pHejj GbXuI9e4ZH2tWlNDPLXXZa+Raay00M8S06Ab1ZqXpJ1aIyJXI3pTovpV2X/K9ibrsfxm4t1QiEH7 BnLvOByiyjxJzbU1TltxuvAfa6HDO/Lallr7e9c+Dru+9npo7XTgQ+yVqLk8f/c4RCvm3DHWlOBB qWpNQcaZRa0c8Gmt2yhWxZNzf7lnj/EHDJZ789bbNMF5KebScr+9EeZN3H/206r22Bejz5fj6GbE e15+30Oxcl9e+hjWQiD3jzD+2t/jjazSNag/a4KlSjPUN2ozMRdt5SDYs+A7v4d48tu17aHnre3B tSALdhvwAuwrw45XgGk19xzOfI0zl9o6c0PPO3ODa0EWbISFXoB9pT42jwSPWU8GV4Klyn4muNq2 7wCbrMrgMcefgyvBUsf04I5THN8BNtnffpwxrnM/5ln7g8dcm4IrwVJXSxlW89iwgseMd4MrwVIj 85THd4BNhhUaB5Y6xoScjp+CK53RwWXK/j54sdMR9DvGBF8Du6w2wWPmZ8GNjqbIR+PgRdbW4A4c j2B4P8SRoa5b5mwYXOzYHNxRdRwfvJCPkVZGcBd/g3LmuK4Emu1KCDlde4PLXH8OLnbNkmH28eHg hfK46vuR32fGH4hb4zr9LQoYb+tEGxVuf5+yAVwNNoYdbwg7lkwPs+sUH+1TGD1Dq8EqkCX/vVT7 WDIXxBk9g6/Z9rdgGegMCkHBKb6Zqwm304X2tzArbS49xXEjEAdWhH07MwgskN/Q6O9l/if4I9/3 /qFvgR/9fez9rlE2te1lYfPy36O0LvGc/X8f3mMLZdnknnwcihNHg19Ac+xvttbZawWT7DWSM34P XLUOIOfisq/9t2noJ3MNqBVe9S3Yvwlnxe9Tlz6/Lv1wXfqxuowdtftz2GNrH5/UHyYEM2v0hzjW /of2OdQeWbg/EW6H+RNV/kM0+wWYHyzROMap78Ui1beFeZjvDkJeA/wdm3WnvfY/j5Id0RSr9lr3 0C5XKrQr+xXV3yJi3rQQc+034D/cRH75XRq4z/EzdZLI7+Dk93HWHFwbQ2bV/gXiuVy8D6T3ecwj NF3uSUnsb+oSa3xXF75PkUVjqr6Pk/hogfzmUn4Hp57nMt5nwDP2ds6ic50t6XyrOZ3viiVT7hU5 EmmmozWe4WWa4WiAfM3B/P19nmfKtRdzK+by+/lbMZSn+ibM/ArnR6DMFqAffwfnv4OWYryQflAS Rao5pyRAneEDRZpfwmfer9hsHaQkifr+7DUct6Ymco3Emmx/F7aX5siyMg9Tit5TwPx0StXaEn+3 FiHXX6xJtAncUPU9GjCvJKvGt8H7qbP8Fk5+Y6aeZw+vWcs5sNNLcx0347keo3Snm5o4M5CPYZRh XYI8y3X9rsjbPeo7vI6qz0iAHqXtjtft7wJb8Pd/oCPy0dS6EecE+rFF6O9uo1zl24V9J2o1pj6O YdQC5V8sv/cD2x3jySOR3xWq7w1DuHYGCdVnbre/C+wu14Sr15Pl72XI9CX2N4qmWgNeQ9sU+htE 6Wd+or45rOY3xE/AvVbx81hN7XXLIzTacQWYTj7zHfKhHgtnEvJwBebvQ/EMK6jAugD5gqcvf9NJ q/GA/AUstDEvwjKgT4DNFPZLTaG/gfZWDMnfa2qn2mdl6Fc5Jzen0RV6rm7dARaKSJw7bpRjTv4N jde/rwQfvaP8xkyu+zm6kMc1F/V7pPrm0+P4Se31Jct2GHEP9bT6hoLWSmptBWimtYk8uNYj05Df nwFZXp85ttBn8vsil6AnoFnWRPG2NZGesghzIxJPMtoO/Sz3f/HsM2V7RloLrNepryOL/OZLFIc8 bbS60xyrGdroDJpkRaGtDaJSswPel/w+1gZzs/02BxU7Qusk1gc03fUjRbo+ogTXjWiTRcgr+iBH FLVz3g09SF7XQLSHl6m1/L7Z2kctIi5Qbb+fjCuRz+eYR20cvdT3lcmOB6ArKNkZhTY1jprIb37N N0IHXMNQp2+hGc7B6F8QX9Zx5z4qdjyH9zyJGqGdb8d9h+OZ5PjfRn3LnEJtXN9RniOWCpy7URcR 37wFvKjmpe/hvazndxycIH9XTc45xYt4/3K9bU8oPXIbPWQdpg3GYVolgR2Alsnw3wPzyZFch040 1bWp6tuIdmGEHcv1mqpx4En1vcM6R4b4VH6jruPKOPiDEYE+BF+D5BrpnYHaf6ryM5zTVHPvWPv7 /OH2uZE2tzEqj3NU/FuB/Iq/jW3X4DRzkRhFuK+3r5pwnyzMryqFf3KQQZzT+BMoZ7TeE83BIjCe 6HgQ/Ib3QKfXM3HidWgP5njoZCr17yXcZys4kWzTqxZzbcptUNtOzKnFxUzldmgpf3tT+S343v49 Ccn99v3y7OPuNvJ4jp3n76DF0B+gC2z22L+D8Z1Nd34GWVa89mGfDwc14MQS6D+YE+lM5T2MSvcu pvJj6BgbO96JixD+fvX1lVfbv5MRzgZwg80Um2tx7UqbMpvfbHRZLbG52qbEZilTeZw5sdfmHpsC G7tcqspDMxl0sOls07EWvWsSnr4qh+E2I2yMmqiyzbN/fyac7TanCz+3FrpObOU6ceIcvl/t61Vd NcLqbK10TjzJVKJ1V97OnPhzTSrnSeQaA+YJhxhqLvf3T/p+wN7Xq0sf+T+JtZxuR//eliZTsv3b yINrYsz+48jfgLcOnBrHrTVxXl83XKiPEXtPpsHP1USu++NErWWiO5yahiuIYvaemti7/hhxNzLx rxI1bleThIOnJvH6mjTZVXeaXkPULHAySegzmmfVU8/pSd7/x2mBMbhVZN1wp9bEs7RutF7xv5u2 M+pGu6xq2k/+v6fDFdV0jDk1neDvdP7+9HSN+WN061/NWSk1SXmsbnQP/L+jxxt1p2ca0TnHTqZ3 HPhrPfXUU0899VTT5+CZObeLzWMgSJS68d/IJ6fmvC42/tOwtyZ9R4IjRP2mAPhy/R8iOn9X3RmQ 8/8XA/czg6P/swzxEQ39gGi4h2hkBNGoDUSjK4nScW7MaDCjnj/M6/XUU0899dRTTz311FNPPfXU U0899dRTTz311FNPPfXUU0899dRTTz311FNPPfXUU0899dRTz7+AIIrtIDwUR8+Riwxod8olir+m XRxZ6q8iOctoI/+yBvVLzDn8FzfIX2emGHUkbQO2z7ZNakcrbNsKi+OgZnSHbTvDwl20kJ6w7Qjq QjG23YA8oqdtRxrbxETbjqIp5ve2HU1drJG23dC40dJ5iKEiV2TVX6PS07Ww6t+PdrnusW0D9gO2 bVIj117btsLiOCjaddC2nWHhLurnetO2IyjRtdy2G1BcRKxtR4qMCLdtR1HXBqW2HU2JDW6y7YZi TAOdhxjqE3kcORFWA7uc2eZyZpvLmW0uZ7atsDhczmw7w8K5nNnmcmaby5ltLme2uZzZ5nJmm8uZ bS7ne8lDPakHnY2fHhpLhZSNXJZSOcgjP8KGwPJRmfqZiZBCWCWUgjODqAj/eWgiwvKpAOfK1VEu NBexF+JnDmIOwXVFiJOFsEJ1Pp8qEJKJ45Pv2FfdM/yKKSq1cvvOHuqNNM9FfmvG8gB5/0zgV3nN wXXF6i7zESZTl2cKEHrqJ81XxxV4Vh07G1qM40zct1A9VwqNQYxs6oSwcuqMODkqvRHq2lKkc/pc FeN8jnoW+RTlKtVyZeWquPKOeQgthl1ES3C0CJbMsYxTgRT9CJd343yWILVC/MxXqZTaqfrVU/M9 ZQx+CnlPLkX55kap581DiHyjFQjPVVf4VEiRyrXffo5snOmmUi5WIUUqxUyUCofruxSrdyrrR5md yxKEFKu7cpryOf1hOZB3LFPPwrVL1y3Ou7xTKUrAg+fn+iVzxW8jW+W/UD2xv6r2cZnxXTwq7yX2 c/HbzFIxq3Mc/kSy1Bar6/ip5+M45aSa2FGlVqxSWKLKocKu5+HlreuYvPsiVaqZ9nvxqdogle8o 37XHrnH8NJzHfDuOrPNL7dT9eAp+Qwur3lKmqiOyhhfXeC5do7ORk0x1/2z7/imqpPy4Y1+MFd1x tfwvRdW5mu0hxa793WEvUW8oX6VUhhSWIFSmmKfel3yTNVPV4bI2c8nNr0pvuqq7XIpL1NOXq9Ly q/dcruolX+1R5SbrSK56wkJ1j1z1jFnqWl3Sw8iLdjnIvtYXdobrV45qs9V1ZpG6V7aqU6e6Lx/L uNko5wrVanOq3kGOOl+merAlYeVepp60xC55TitX/ZQ1qfZzy/NcYzvhKtmTyHabVXWnU+Wq5KSU 615G1anrXsNjt3u/ynd2jfZ38rPr1lY7X/3CSkA+CT8L90J61PBV9Wg5qk2XqLadedon5XLOrFGm 3CJK7Z/8VGxXqJpXoa7MUe1DPk1uVToyZpFqY2d6Q/+udlHdJrqr3Mg2wD1jinpXZbT4Xk/PHmf3 9IwtzPaVlpfm+T1DSn1lpb5Mf2FpSYpnUFGRZ2JhfoG/3DMxtzzXtzA3J2VIZlFhlq9wYm5+RVGm r+rCvh77xJRcXzku9vROObenHeQpLPdkevy+zJzc4kzffE9pnsdfkBt203xfaUWZDM4uLS7LLCnM LU8ZU5HdKbO8sycn1zPCV1rqr5FUcWlOrq/EU55ZUu5BtgrzPHmZxYVFSzyLCv0FnvKKLH9Rrgdp luQUluSXe5Cbcn9uMa4sycEtfCXIYopnlN+Tl5vpr/Dllnt8uZlFnkI/7pFd3s1TXpyJB8/OLIMt LymuKPIXliHJkoriXB9iluf6VQLlnjJfKYpLlhZSLyoqXeQpQHl5CvEY2X5PYYnHL4sPOcMlnqLC EtwLj5lVmK8S5hv5cxf7cXHh/NwUXYgdyz3FmSVLPNkVKHPOtyyxktxFHl8mnsVXiMfGhZnFHhQc boMU8xFSXrgU0f2leKCF8pEyPYsyfcV8L1nQ2QWZPmQs15dS4PeX9e3efdGiRSnF+j2koPi7+5eU leb7MssKlnTP9ueVlvjL7ajSzstE5ubLeNNLK5DFJZ6K8lxkDW9FnvZkokRyfcWFfn9ujidricr0 MO+YQTjrUwcor5wKLplFBYXZBWHXQgtLsosqcnApniCnsLysCDeQeS/zFSJCNmLllvhTPPrepSUo 2E6FnT25xVnyouqkSnTkU+ZIRZdVA8VU7vcVZvP7q7q7fG06rX4qA50KcRdUIdk0fLKi5ZQuKikq zQy/KfKcyTnFi8DjluJW+FnhL6vwoxovLMzOlXEKcovKaj1QXd6FehPdc3LzMlEZUzLLyxbruRSF mtFqOsWfQAPTs8+49KEGzcRoGKu0sVIbl2hjhTYu1sZF2liujQu1sUwbS7WxRBuLtbFIGwu1UaEN vzbKtbFAG2XaKNVGiTaKtVGkjfnamKeNQm0UaCNfG3nayNVGjjaytZGljUxtzNXGHG3M1sYsbVyg jZnamKGN6dqYpo2p2piiDa82JmtjkjYmamOCNjK0MV4b47QxVhtjtJGujdHaGKWNkdoYoY3h2him jaHaGKKNwdoYpI00bQzUxgBtnK+N/trop42+2jhPG6naOFcbfbTRWxu9tHGONnpq42xt9NBGd22k aOMsbXTTRldtdNFGZ2100kZHbXTQRntttNNGW2200UZrbXi04dZGK2201EYLbSRro7k2krTRTBtN tdFEG4naSNBGY2000ka8NuK0EauNGG001Ea0NqK0EamNBtqI0IZLG05tOLRhacPUhqENoQ2yDRHS RlAbJ7RRqY3j2vhNG79q4xdt/FMbP2vjJ238qI0ftPG9Nr7TxjFtfKuNb7TxtTaOauMrbXypjS+0 cUQbn2vjM218qo1PtPGxNj7Sxofa+EAb72vjH9r4uzb+po33tPFXbbyrjXe08bY23tLGYW28qY2/ aOMNbfxZG69r4zVtvKqNP2njFW0c0sbL2nhJGwe18aI2XtDG89o4oI3ntPGsNp7Rxn5tPK2Np7Tx pDae0Mbj2nhMG49qY582HtHGXm08rI2HtPGgNgLa2KON3dp4QBv3a+M+bezSxk5t7NDGvdq4Rxt3 a+MubdypjTu0cbs2btPGdm1s08ZWbdyqjS3auEUbN2vjJm1s1saN2rhBG9drY5M2NmrjOm1s0Ma1 2rhGG1dr4yptrNfGOm1cqY212lijjSu0cbk2VmvjMm1ot0dot0dot0dot0dot0dot0dot0dot0do t0dot0dot0dot0dot0dot0dot0dot0dot0dot0f4tKH9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9 H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9H6H9 H6H9H6H9H6H9H6H9H6HdHqHdHqHdHqG9HaG9HaG9HaG9HaG9HaG9HaG9HaG9HaG9HTHkQWnAaw60 GuCGzxxolQhZyUeXBFr1hazgo4tZLgq0ioYs56MLWZaxLGVZEmg5CLI40HIIZBHLQpYKPufno3IW HwcuCLQcDCljKWUp4SjFLEUs8wMthkHmsRSyFLDks+QFWgyF5PJRDks2SxZLJstcljkss/m6WXx0 ActMlhks01mmsUxlmcLiZZnMMollIssElgyW8SzjWMayjGFJZxkdSB4FGcUyMpA8GjKCZXggOR0y LJA8BjKUZQjLYD43iK9LYxnI1w1gOZ+lP8fsx9KXLz+PJZXlXJY+LL05sV4s53AqPVnOZunBiXVn SeHrzmLpxtKVpQtLZ5ZOLB056Q4s7TnNdixtWdpw0q1ZPHydm6UVS0uWFizJLM0DzcdBkliaBZqP hzRlacKBiSwJHNiYpRFLPJ+LY4nlwBiWhizRfC6KJZKlAZ+LYHGxOANJGRBHIGkCxGIxOdDgI8FC SkSIJaiiiBN8VMlynOU3PvcrH/3C8k+Wn1l+CjSbDPkx0GwS5Ac++p7lO5ZjfO5bPvqG5WuWo3zu K5YvOfALliMsn7N8xlE+5aNP+OhjPvqI5UOWD/jc+yz/4MC/s/yN5T2Wv3KUd/noHZa3A02nQt4K NJ0COczyJgf+heUNlj+zvM5RXmN5lQP/xPIKyyGWlznKSywHOfBFlhdYnmc5wPIcx3yWj55h2c/y NJ97iuVJDnyC5XGWx1geZdnHMR/ho70sD7M8xPJgoMlASCDQZCZkD8tulgdY7me5j2UXy06WHYEm 6K/FvZzKPSx387m7WO5kuYPldpbbWLazbGPZyondyqlsYbmFz93MchPLZpYb+YIb+Oh6lk0sG/nc dZzKBpZr+dw1LFezXMWynmUdx7ySj9ayrGG5guVyltWBxEzIZYHELMilLKsCiXmQlSyXBBK9kBWB RHTG4uJAYh/IRSzL+fIL+bplLEsDiTmQJXz5YpZFLAtZKlj8LOWctI8vX8BSFkjMhpRyYiUcs5il iGU+yzyWQr6ugCWfc5bHl+ey5HDMbJYslkyWuSxzWGbzQ8/inF3AMpMfegYnPZ1vNI1lKmd3Ct/I y6lMZpnEMpFlQiAhDZIRSJB3GB9IkNV7XCBhFWRsIOEsyBiOks4yOpAAv0CM4qORLCM4cHgg4SLI sEDC5ZChgYSLIUMCCSsggwONhkMGsaSxDGQZEGiE8V2cz0f9A/HTIf1Y+gbiZdU4jyU1ED8Ccm4g fhqkTyB+BqQ3n+vFck4gvhukJ8c8OxAvH6xHIF62ze4sKXz5WXyHbixdObEuLJ05sU4sHVk6sLQP xMtSasfSltNsw2m25sQ8nIqbpRVf15KlBUsyS3OWpEDcLEizQNxsSNNA3BxIE5ZElgSWxiyN+IJ4 viCOA2NZYlgaskRzzCiOGcmBDVgiWFwsTo7p4JgWB5osBotgobRQbJZbEozNdp+IzXFXwj4OfgO/ IuwXhP0T/Ax+Aj8i/AfwPc59h+Nj4FvwDfga4UfBVzj3JY6/AEfA5+CzmHz3pzEF7k/Ax+Aj8CHC PoC+D/4B/o7jv0HfA38F74J3Gs53v93wbPdb0MMNi9xvNuzg/gt4A/afG3Z1vw5eA6/i/J8Q9krD Yvch2C/Dfgn2wYbz3C82LHS/0LDA/XzDfPcBXPsc0nsWPAPSQvvx82nwFHgyeoH7iWif+/Hocvdj 0X73o2AfeAThe8HDOPcQzj2IsADYA3aDB6KWuO+PWuq+L+pC966o5e6dURe5d4B7wT3gbnAXuDPq LPcd0NvBbbhmO3Rb1Hz3Vti3wt4CboF9M9K6CWltRlo3IuwGcD3YBDaC68AGXHct0rsmcpz76sjx 7qsi893rI+90r4u8232Z2d59qZnqXiVS3Su9K7yX7Fzhvdi73HvRzuXeqOUianny8vTly5bvXP7e 8rRGzsgLvUu9y3Yu9S7xLvIu3rnI+5ixmvKMy9L6exfurPBaFQkV/grzxwqxs0IMrRA9KoRBFXEV ngoz2u/1ect3+rzky/Ct8O32Wf12+z7wGeQTkftC+x/0JbcaDk270NcwbvgCb6m3bGeptySv2DsP GSxMzfcW7Mz35qXmeHN35nizU7O8malzvXNSZ3ln75zlvSB1hnfmzhne6anTvFMRf0rqZK9352Tv pNQJ3ok7J3jHp47zjkP42NR075id6d7RqSO9o3aO9I5IHe4dhoenFnEtPC3MOJmBcS2QE0oWg3sk pyV/kHws2aLk3cn7k81Gsc3dzY3OsUliyPgkUZp0cdLVSWZss9eaGWnNOncbHtv0tabvN/22qdU4 rWnnlOHUJK6Jp4mZKJ+tydjJw5UOHMp6dm/1rGObtO0wPDZRxCa6E41h7kRB8R/EH4s3E5+Oey3O iI0VsbGhWCMtFtFjY9wxhvwRijHTYs4+d3hsQ3dDQ/4INTSbpDVEiEyxY3TG5OGxUe4owzswanyU kRY1cMjwtKizegwnU3iEIBEHMSNkLkSiezja9YNNhENgPN8zeVLXrun7Imhi+u6IjJm7xRW720+S P9MmzNjtvGI3eWfMnLZHiKum7xHGkMm7E9InzODjy9avp8Et03e3nDRt97aW09N3r4CRJo0QDGq5 pwkNnt51dnlFedeu/tn4Mbvc31X9jyNRIY+6ykD5f7kfx/K/CnVMXc/4h6NB5pTjj18H+s981f/2 P+I/nYH//j97CFV02qCQcSnlGKvASnAJWAEuBheB5eBCsAwsBUvAYrAILAQVwA/KwQJQBkpBCSgG RWA+mAcKQQHIB3kgF+SAbJAFMsFcMAfMBrPABWAmmAGmg2lgKpgCvGAymAQmggkgA4wH48BYMAak g9FgFBgJRoDhYBgYCoaAwWAQSAMDwQBwPugP+oG+4DyQCs4FfUBv0AucA3qCs0EP0B2kgLNAN9AV dAGdQSfQEXQA7UE70Ba0Aa2BB7hBK9AStADJoDlIAs1AU9AEJIIE0Bg0AvEgDsSCGNAQRIMoEAka gAjgAk7gANagEH6awAACEOUIhIkgOAEqwXHwG/gV/AL+CX4GP4EfwQ/ge/AdOAa+Bd+Ar0n+O7Q5 4ivwJfgCHAGfg8/Ap+AT8DH4CHwIPgDvg3+Av4O/gffAX8G74B3wNngLHAZvgr+AN8CfwevgNfAq +BN4BRwCL4OXwEHwIngBPA8OgOfAs+AZsB88DZ4CT4InwOPgMfAo2AceAXvBw+Ah8CAIgD1gN3gA 3A/uA7vATrAD3AvuAXeDu8Cd4A5wO7gNbAfbwFZwK9gCbgE3g5vAZnAjuAFcDzaBjeA6sAFcC64B V4OrwHqwDlwJ1oI14ApwOVgNLqOcQSsE2r9A+xdo/wLtX6D9C7R/gfYv0P4F2r9A+xdo/wLtX6D9 C7R/gfYv0P4F2r9A+xc+gD5AoA8Q6AME+gCBPkCgDxDoAwT6AIE+QKAPEOgDBPoAgT5AoA8Q6AME +gCBPkCgDxDoAwT6AIE+QKAPEOgDBPoAgT5AoA8Q6AME+gCBPkCgDxDoAwT6AIH2L9D+Bdq/QNsX aPsCbV+g7Qu0fYG2L9D2Bdq+QNsXaPv/6X74v/zP9P90Bv7L/zSbM/v/AGTduuEKZW5kc3RyZWFt DWVuZG9iag04IDAgb2JqDTw8L0Jhc2VGb250IC9DYWxpYnJpL0Rlc2NlbmRhbnRGb250cyBbOSAw IFJdL0VuY29kaW5nIC9JZGVudGl0eS1IL1N1YnR5cGUgL1R5cGUwL1RvVW5pY29kZSAvSWRlbnRp dHktSC9UeXBlIC9Gb250Pj4NZW5kb2JqDTkgMCBvYmoNPDwvQmFzZUZvbnQgL0NhbGlicmkvQ0lE U3lzdGVtSW5mbyAxMCAwIFIvQ0lEVG9HSURNYXAgMTIgMCBSL0RXIDUwNy9Gb250RGVzY3JpcHRv ciAxMSAwIFIvU3VidHlwZSAvQ0lERm9udFR5cGUyL1R5cGUgL0ZvbnQvVyBbMCBbMF0gMTMgWzBd IDMyIFsyMjYgMzI2XSAzNCBbNDAxIDQ5OF0gMzcgWzcxNSA2ODJdIDM5IFsyMjEgMzAzXSA0MSBb MzAzIDQ5OF0gNDMgWzQ5OCAyNDldIDQ1IFszMDcgMjUzXSA0NyBbMzg2XSA0OSBbNTA2IDUwOF0g NTUgNTYgNTA2IDU4IDU5IDI2OCA2MCA2MiA0OTggNjMgWzQ2MyA4OTRdIDY1IFs1NzkgNTQzXSA2 NyBbNTMzIDYxNV0gNjkgWzQ4OCA0NTldIDcxIFs2MzAgNjIzXSA3MyBbMjUyIDMxOV0gNzUgWzUx OSA0MjBdIDc3IFs4NTUgNjQ1XSA3OSBbNjYyIDUxNl0gODEgWzY3MyA1NDNdCjgzIFs0NTkgNDg3 XSA4NSBbNjQyIDU2N10gODcgWzg5MCA1MTldIDg5IFs0ODcgNDY4XSA5MSBbMzA2IDM4Nl0gOTMg WzMwNiA0OThdIDk1IFs0OTggMjkxXSA5NyBbNDc5IDUyNV0gOTkgWzQyMyA1MjVdIDEwMSBbNDk4 IDMwNV0gMTAzIFs0NzEgNTI2XSAxMDUgWzIzMCAyMzldIDEwNyBbNDU1IDIzMF0gMTA5IFs3OTkg NTI2XSAxMTEgWzUyNyA1MjVdIDExMyBbNTI1IDM0OV0gMTE1IFszOTEgMzM1XSAxMTcgWzUyNSA0 NTJdIDExOSBbNzE1IDQzM10gMTIxIFs0NTMgMzk1XSAxMjMgWzMxNSA0NjBdIDEyNSBbMzE1IDQ5 OF0gMTYwIFsyMjYgMzI2XSAxNjIgWzQ5OF0gMTY0IFs0OThdCjE2NiAxNjcgNDk4IDE2OCBbMzkz IDgzNF0gMTcwIFs0MDIgNTEyXSAxNzIgWzQ5OCAzMDddIDE3NSBbMzk0IDMzOV0gMTc3IFs0OTgg MzM2XSAxNzkgWzMzNCAyOTJdIDE4MSBbNTUwIDU4Nl0gMTgzIFsyNTIgMzA3XSAxODUgWzI0NiA0 MjJdIDE4NyBbNTEyIDYzNl0gMTg5IFs2NzEgNjc1XSAxOTEgWzQ2MyA1NzldIDE5MyAxOTcgNTc5 IDE5OCBbNzYzIDUzM10gMjAwIDIwMyA0ODggMjA0IDIwNyAyNTIgMjA4IFs2MjUgNjQ2XSAyMTAg MjE0IDY2MiAyMTUgWzQ5OCA2NjRdIDIxNyAyMjAgNjQyIDIyMSBbNDg3IDUxN10KMjIzIFs1Mjcg NDc5XSAyMjUgMjI5IDQ3OSAyMzAgWzc3MyA0MjNdIDIzMiAyMzUgNDk4IDIzNiAyMzkgMjMwIDI0 MCAyNDEgNTI1IDI0MiAyNDYgNTI3IDI0NyBbNDk4IDUyOV0gMjQ5IDI1MiA1MjUgMjUzIFs0NTMg NTI1XSAyNTUgWzQ1MyA1NzldIDI1NyBbNDc5IDU3OV0gMjU5IFs0NzkgNTc5XSAyNjEgWzQ3OSA1 MzNdIDI2MyBbNDIzIDUzM10gMjY1IFs0MjMgNTMzXSAyNjcgWzQyMyA1MzNdIDI2OSBbNDIzIDYx NV0gMjcxIFs1NjggNjI1XSAyNzMgWzU1MiA0ODhdIDI3NSBbNDk4IDQ4OF0gMjc3IFs0OTggNDg4 XQoyNzkgWzQ5OCA0ODhdIDI4MSBbNDk4IDQ4OF0gMjgzIFs0OTggNjMxXSAyODUgWzQ3MSA2MzFd IDI4NyBbNDcxIDYzMV0gMjg5IFs0NzEgNjMxXSAyOTEgWzQ3MSA2MjNdIDI5MyBbNTI1IDY1Nl0g Mjk1IFs1MzMgMjUyXSAyOTcgWzIzMCAyNTJdIDI5OSBbMjMwIDI1Ml0gMzAxIFsyMzAgMjUyXSAz MDMgWzIzMCAyNTJdIDMwNSBbMjMwIDU3MV0gMzA3IFs0NjkgMzE5XSAzMDkgWzIzOSA1MjBdIDMx MSAzMTIgNDU1IDMxMyBbNDIwIDIzMF0gMzE1IFs0MjAgMjMwXSAzMTcgWzQyMyAyNjRdIDMxOSBb NTQ2IDM3NF0gMzIxIFs0MzAgMjQ4XSAzMjMgWzY0NiA1MjVdIDMyNSBbNjQ2IDUyNV0gMzI3Cls2 NDYgNTI1XSAzMjkgWzU3OSA2MjhdIDMzMSBbNTI1IDY2Ml0gMzMzIFs1MjcgNjYyXSAzMzUgWzUy NyA2NjJdIDMzNyBbNTI3IDg2N10gMzM5IFs4NTAgNTQzXSAzNDEgWzM0OSA1NDNdIDM0MyBbMzQ5 IDU0M10gMzQ1IFszNDkgNDU5XSAzNDcgWzM5MSA0NTldIDM0OSBbMzkxIDQ1OV0gMzUxIFszOTEg NDU5XSAzNTMgWzM5MSA0ODddIDM1NSBbMzM1IDQ4N10gMzU3IFszNDYgNDg3XSAzNTkgWzM0MiA2 NDJdIDM2MSBbNTI1IDY0Ml0gMzYzIFs1MjUgNjQyXSAzNjUgWzUyNSA2NDJdIDM2NyBbNTI1IDY0 Ml0gMzY5IFs1MjUgNjQyXSAzNzEgWzUyNSA4OTBdIDM3MyBbNzE1IDQ4N10gMzc1IFs0NTMgNDg3 XSAzNzcKWzQ2OCAzOTVdIDM3OSBbNDY4IDM5NV0gMzgxIFs0NjggMzk1XSAzODMgWzI0MyA1NTJd IDM4NSBbNjE1IDUzOF0gMzg3IFs1MjUgNTMxXSAzODkgWzUyNSA1NDhdIDM5MSBbNTc3IDQ2Ml0g MzkzIFs2MjUgNjg3XSAzOTUgWzUzOCA1MjVdIDM5NyBbNTIzIDQ4OF0gMzk5IFs2NDMgNDc0XSA0 MDEgWzQ1OSAzMDVdIDQwMyBbNjMyIDU2N10gNDA1IFs3ODMgMjg5XSA0MDcgWzI2OSA1MjBdIDQw OSBbNDU1IDI4Ml0gNDExIFs0NjMgODc5XSA0MTMgWzY0NiA1MzddIDQxNSBbNjYyIDY5N10gNDE3 IFs1NzggNzczXSA0MTkgWzY1NSA2MTFdIDQyMSBbNTI1IDU0M10gNDIzIFs0NTkgMzkxXSA0MjUg WzQ1OSA0MzFdIDQyNwpbMzU5IDUzMV0gNDI5IFszMzUgNDg3XSA0MzEgWzcyMiA2MDNdIDQzMyBb NjY0IDY0Ml0gNDM1IFs1MzIgNDk4XSA0MzcgWzQ2OCAzOTVdIDQzOSA0NDEgNDc0IDQ0MiBbNDI1 XSA0NDUgWzQyNiAzOTFdIDQ0NyBbNTI1IDI0NF0gNDQ5IFszOTUgNTc0XSA0NTEgWzMyNiAxMDg0 XSA0NTMgWzEwMTAgOTIwXSA0NTUgWzc1MSA2NjBdIDQ1NyBbNDY5IDk2NF0gNDU5IFs4ODUgNzY1 XSA0NjEgWzU3OSA0NzldIDQ2MyBbMjUyIDIzMF0gNDY1IFs2NjIgNTI3XSA0NjcgWzY0MiA1MjVd IDQ2OSBbNjQyIDUyNV0gNDcxIFs2NDIgNTI1XSA0NzMgWzY0MiA1MjVdIDQ3NSBbNjQyIDUyNV0g NDc3IFs0OTggNTc5XQo0NzkgWzQ3OSA1NzldIDQ4MSBbNDc5IDc2M10gNDgzIFs3NzMgNjMxXSA0 ODUgWzUzNyA2MzFdIDQ4NyBbNDcxIDUyMF0gNDg5IFs0NTUgNjYyXSA0OTEgWzUyNyA2NjJdIDQ5 MyBbNTI3IDQ3NF0gNDk1IFs0NzQgMjM5XSA0OTcgWzEwNzMgMTAxMF0gNDk5IFs5MjAgNjMxXSA1 MDEgWzQ3MSA4OTVdIDUwMyBbNjA0IDY0Nl0gNTA1IFs1MjUgNTc5XSA1MDcgWzQ3OSA3NjNdIDUw OSBbNzczIDY2NF0gNTExIFs1MjkgNTc5XSA1MTMgWzQ3OSA1NzldIDUxNSBbNDc5IDQ4OF0gNTE3 IFs0OTggNDg4XSA1MTkgWzQ5OCAyNTJdIDUyMSBbMjMwIDI1Ml0gNTIzIFsyMzAgNjYyXSA1MjUg WzUyNyA2NjJdIDUyNyBbNTI3IDU0M10KNTI5IFszNDkgNTQzXSA1MzEgWzM0OSA2NDJdIDUzMyBb NTI1IDY0Ml0gNTM1IFs1MjUgNDU5XSA1MzcgWzM5MSA0ODddIDUzOSBbMzM1IDQ3NF0gNTQxIFs0 NzQgNjIzXSA1NDMgWzUyNSA2NDNdIDU0NSBbNjAwXSA1NDggWzQ5MiA0MTJdIDU1MCBbNTc5IDQ3 OV0gNTUyIFs0ODggNDk4XSA1NTQgWzY2MiA1MjddIDU1NiBbNjYyIDUyN10gNTU4IFs2NjIgNTI3 XSA1NjAgWzY2MiA1MjddIDU2MiBbNDg3IDQ1M10gNTY0IFszMTcgNjE1XSA1NjYgWzMzNSAyMzld IDU2OCBbODIyIDgyMV0gNTcwIFs1NzkgNTMzXSA1NzIgWzQyMyA0MjBdIDU3NCBbNDg3IDM5MV0g NTc2IFszOTUgNDQ3XSA1NzggWzQ0NyA1NTJdCjU4MCBbNjU5IDU3M10gNTgyIFs0ODggNDk4XSA1 ODQgWzMyOSAyODFdIDU4NiBbNjMwIDUyNV0gNTg4IFs1NTEgMzc1XSA1OTAgWzU3OCA0ODVdIDU5 MiBbNDc5IDUyNV0gNTk0IDU5NSA1MjUgNTk2IFs0MjMgNDUxXSA1OTggNTk5IDUyNSA2MDAgNjAx IDQ5OCA2MDIgWzYzOCA0MjNdIDYwNCBbNDIzIDUyNl0gNjA2IFs1MjkgMjgyXSA2MDggNjA5IDUy NSA2MTAgWzU0MCA0NTJdIDYxMiBbNDc3IDUyNV0gNjE0IDYxNSA1MjUgNjE2IFsyODIgMjc0XSA2 MTggWzIzMCAzNjNdIDYyMCBbMzcyIDIzMF0gNjIyIFs1NjUgNzk4XSA2MjQKWzc5OCA3OTldIDYy NiA2MjcgNTI1IDYyOCBbNTQxIDUyN10gNjMwIFs3MTIgNjk2XSA2MzIgWzY1MSAzNDldIDYzNCA2 MzcgMzQ5IDYzOCA2MzkgMzE5IDY0MCA2NDEgNDQ5IDY0MiBbMzkxIDIzOV0gNjQ0IFsyODIgMjM5 XSA2NDYgWzMxNyAzMzVdIDY0OCBbMzM1IDU4MF0gNjUwIFs1NTggNTQyXSA2NTIgWzQ1MiA3MTVd IDY1NCBbNDUzIDQxNV0gNjU2IFszOTUgNDc4XSA2NTggWzQ2NyA0NjZdIDY2MCA2NjIgNDQ3IDY2 MyBbNDIzIDYyOF0gNjY1IFs0NzkgNTI5XSA2NjcgWzU1MiA1MzVdIDY2OSBbMzE3IDQ1NV0gNjcx IFszODcgNTI1XQo2NzMgNjc0IDQ0NyA2NzUgWzgwNCA4NTRdIDY3NyBbODg3IDYxOV0gNjc5IFs0 NzEgNjg1XSA2ODEgWzc1NiA1ODVdIDY4MyBbNTUxIDQ5Ml0gNjg1IFs0OTIgNTI1XSA2ODcgWzUz OCAzNjRdIDY4OSBbMzY0IDE3OF0gNjkxIDY5MiAyNDUgNjkzIFsyNTEgMzE4XSA2OTUgWzQ5MiAz MTVdIDY5NyBbMjIxIDQwMF0gNjk5IDcwMSAyNTAgNzAyIDcwMyAyMjYgNzA0IDcwNSAzMjUgNzA2 IDcwNyA0OTggNzA4IDcwOSA1MzcgNzEwIDcxMSAzOTUgNzEyIFsyOTAgMzk0XSA3MTQgWzI5MiAy OTFdCjcxNiBbMjkwIDM5NF0gNzE4IFsyOTEgMjkyXSA3MjAgNzIxIDI3OCA3MjIgNzIzIDIyNiA3 MjQgNzI3IDMzMyA3MjggWzM4MSAyMjZdIDczMCBbMzIxIDMxMl0gNzMyIFs0NTAgNDY5XSA3MzQg NzM1IDMzMyA3MzYgWzI5NyAxNzFdIDczOCBbMjczIDMxMl0gNzQwIFszMjUgMzgzXSA3NDIgNzQ1 IDM4MyA3NDYgNzQ3IDMzMyA3NDggWzM5NSA1NzVdIDc1MCBbNDE4IDMzM10gNzUyIDc1NCAzMzMg NzU1IFszMjEgMjkxXSA3NTcgNzU4IDQ2OSA3NTkgWzQ1MCAyNjhdIDc2MSA3NjQKMzMzIDc2NSA3 NjYgNTMxIDc2NyBbMzc2IDBdIDc2OSA3ODggMCA3ODkgWzI1MCAwXSA3OTEgNzk0IDAgNzk1IFsz MzMgMF0gNzk3IDg3OSAwIDg4NCA4ODUgMjUwIDg5MCBbMjc0IDQyM10gODkyIDg5MyA0MjMgODk0 IFsyNjhdIDkwMCBbMzE3IDQ5NF0gOTAyIFs1NzkgMjUyXSA5MDQgWzQ4OCA2MjNdIDkwNiBbMjUy XSA5MDggWzY2Ml0gOTEwIFs0ODcgNjY0XSA5MTIgWzI3NCA1NzldIDkxNCBbNTQ0IDQxNl0gOTE2 IFs1NjQgNDg4XSA5MTggWzQ2OCA2MjNdIDkyMApbNjYyIDI1Ml0gOTIyIFs1MjAgNTczXSA5MjQg Wzg1NSA2NDZdIDkyNiBbNDkyIDY2Ml0gOTI4IFs2MjMgNTE3XSA5MzEgWzQ1OSA0ODddIDkzMyBb NDg3IDc1OV0gOTM1IFs1MTkgNzUwXSA5MzcgWzY2NCAyNTJdIDkzOSBbNDg3IDU2N10gOTQxIFs0 NTYgNTM3XSA5NDMgWzI3NCA1NDJdIDk0NSBbNTY3IDUzMV0gOTQ3IFs0NDYgNTIzXSA5NDkgWzQ1 NiAzNDhdIDk1MSBbNTM3IDUzMl0gOTUzIFsyNzQgNDU1XSA5NTUgWzQ2MyA1NTBdIDk1NyBbNDQ5 IDM3Nl0gOTU5IFs1MjcgNTUzXSA5NjEgWzUwOSA0MTFdIDk2MyBbNTMyIDM4N10gOTY1IFs1NDIg NjUxXSA5NjcgWzQyNiA3MDhdIDk2OSBbNjk2IDI3NF0gOTcxCls1NDIgNTI3XSA5NzMgWzU0MiA2 OTZdIDk3NiBbNTI0IDU1OV0gOTc4IFs0ODcgNTQyXSA5ODAgWzQ4NyA2NTRdIDk4MiBbODE0IDYw NV0gOTg0IFs2NjIgNTI3XSA5ODYgWzUzMyA0MTFdIDk4OCBbNDU5IDQzNF0gOTkwIFs1NDUgNDUw XSA5OTIgOTkzIDU3OSA5OTQgWzg3OSA3OTldIDk5NiBbNTQ1IDUyM10gOTk4IFs1NTYgNTEyXSAx MDAwIFs1MzMgNDE5XSAxMDAyIFs2MDIgNTA1XSAxMDA0IFs2NzMgNTMyXSAxMDA2IFs0NzMgMzk0 XSAxMDA4IFs2MDUgNTA5XSAxMDEwIFs0MjMgMjM5XSAxMDEyIFs2NjIgNDMyXSAxMDE0IFs0MzIg NTE3XSAxMDE2IFs1NTggNTMzXSAxMDE4IFs2OTkgNTk2XSAxMDIwIFs1MDkgNTMzXQoxMDIyIDEw MjMgNTMzIDEwMjQgMTAyNSA0ODggMTAyNiBbNjI1IDQzMF0gMTAyOCBbNTQ3IDQ1OV0gMTAzMCAx MDMxIDI1MiAxMDMyIFszMTkgODcyXSAxMDM0IFs4NzYgNjE4XSAxMDM2IFs1NDMgNjQyXSAxMDM4 IFs1MjcgNjIwXSAxMDQwIFs1NzkgNTM4XSAxMDQyIFs1NDQgNDMwXSAxMDQ0IFs2NDQgNDg4XSAx MDQ2IFs4MDEgNDc0XSAxMDQ4IDEwNDkgNjQyIDEwNTAgWzU0MyA2MTFdIDEwNTIgWzg1NSA2MjNd IDEwNTQgWzY2MiA2MjJdIDEwNTYgWzUxNyA1MzNdIDEwNTggWzQ4NyA1MjddIDEwNjAgWzY5NyA1 MTldIDEwNjIgWzYzOSA1NTZdIDEwNjQgWzg2OCA4OTBdIDEwNjYgWzYxNSA3NjJdCjEwNjggWzUz MSA1NDhdIDEwNzAgWzg3OSA1NTVdIDEwNzIgWzQ3OSA1MzNdIDEwNzQgWzQ3OSAzNDZdIDEwNzYg WzU1OCA0OThdIDEwNzggWzY4OSA0MjNdIDEwODAgMTA4MSA1NDEgMTA4MiBbNDY0IDUxMF0gMTA4 NCBbNjc2IDUzNV0gMTA4NiBbNTI3IDUyMV0gMTA4OCBbNTI1IDQyM10gMTA5MCBbMzg3IDQ1M10g MTA5MiBbNjI0IDQzM10gMTA5NCBbNTQyIDQ2OV0gMTA5NiBbNzI5IDc0OV0gMTA5OCBbNTM2IDY2 Nl0gMTEwMCBbNDcwIDQ0M10gMTEwMiBbNzIyIDQ3NF0gMTEwNCAxMTA1IDQ5OCAxMTA2IFs1NDEg MzQ2XSAxMTA4IFs0NDQgMzkxXSAxMTEwIDExMTEgMjMwIDExMTIgWzIzOSA3NTFdIDExMTQKWzc3 MCA1MzNdIDExMTYgWzQ2NCA1NDFdIDExMTggWzQ1MyA1MjVdIDExMjAgWzkyOCA2NzddIDExMjIg WzYyNyA1MTldIDExMjQgWzc4MiA2NTBdIDExMjYgWzYzMCA1MjVdIDExMjggWzgzMiA3MTBdIDEx MzAgWzcyMyA1NjNdIDExMzIgWzkwNiA3NTVdIDExMzQgWzQ3NCA0MTNdIDExMzYgWzc1MCA3MDhd IDExMzggWzY2MiA1MjRdIDExNDAgWzU5MCA0NzhdIDExNDIgWzU5MCA0NzhdIDExNDQgWzEwNDUg OTA5XSAxMTQ2IFs2NjIgNTc2XSAxMTQ4IFs5MjggNzgyXSAxMTUwIFs5MjggNjc3XSAxMTUyIFs1 MzMgNDIzXSAxMTU0IFs2MDkgMF0gMTE1NiAxMTU4IDAgMTE2MCBbOTg1IDk0OV0gMTE2MiBbNjYz IDU0Nl0gMTE2NCBbNTMxIDQ4NF0KMTE2NiBbNTE3IDUyNV0gMTE2OCBbNDMzIDM1NF0gMTE3MCBb NDI1IDM3Ml0gMTE3MiBbNTMyIDQ1M10gMTE3NCBbODM3IDcxOV0gMTE3NiBbNDc0IDQyM10gMTE3 OCBbNTgxIDQ5NF0gMTE4MCBbNTQzIDQ2NF0gMTE4MiBbNTUyIDQ5MF0gMTE4NCBbNjMxIDUzNV0g MTE4NiBbNjQzIDU1NV0gMTE4OCBbNzExIDYwNV0gMTE5MCBbOTAyIDc0M10gMTE5MiBbNjQ2IDU1 NF0gMTE5NCBbNTMzIDQyM10gMTE5NiBbNDg3IDM4N10gMTE5OCBbNDg3IDQ1Ml0gMTIwMCBbNDg3 IDQ1Ml0gMTIwMiBbNTU4IDQ2Ml0gMTIwNCBbNzI4IDU5Nl0gMTIwNiBbNTc1IDQ4OV0gMTIwOCBb NTU2IDQ2OV0gMTIxMCBbNTU2IDQ2OV0gMTIxMiBbNzQ1IDU5OF0gMTIxNCBbNzQ1IDU5OF0KMTIx NiBbMjUyIDgwMV0gMTIxOCBbNjg5IDU0Nl0gMTIyMCBbNDc2IDYzMl0gMTIyMiBbNTE2IDYyM10g MTIyNCBbNTM1IDYyM10gMTIyNiBbNTQxIDU1Nl0gMTIyOCBbNDY5IDg3OF0gMTIzMCBbNzE0IDI1 Ml0gMTIzMiBbNTc5IDQ3OV0gMTIzNCBbNTc5IDQ3OV0gMTIzNiBbNzYzIDc3M10gMTIzOCBbNDg4 IDQ5OF0gMTI0MCBbNjQzIDQ5OF0gMTI0MiBbNjQzIDQ5OF0gMTI0NCBbODAxIDY4OV0gMTI0NiBb NDc0IDQyM10gMTI0OCBbNDc0IDQ2N10gMTI1MCBbNjQyIDU0MV0gMTI1MiBbNjQyIDU0MV0gMTI1 NCBbNjYyIDUyN10gMTI1NiBbNjYyIDUyNF0gMTI1OCBbNjYyIDUyNF0gMTI2MCBbNTQ4IDQ0M10g MTI2MiBbNTI3IDQ1M10gMTI2NCBbNTI3IDQ1M10KMTI2NiBbNTI3IDQ1M10gMTI2OCBbNTU2IDQ2 OV0gMTI3MCBbNDE2IDM0Nl0gMTI3MiBbNzYyIDY2Nl0gMTI3NCBbNDI1IDM3Ml0gMTI3NiBbNTY1 IDQ2MV0gMTI3OCBbNTE5IDQzM10gMTI4MCBbNTMxIDUyNV0gMTI4MiBbNzk1IDc5Ml0gMTI4NCBb NzY0IDcwMV0gMTI4NiBbNTEzIDQ2Nl0gMTI4OCBbODgyIDc2NV0gMTI5MCBbODk1IDc4OV0gMTI5 MiBbNjM1IDUzNF0gMTI5NCBbNjQxIDU2M10gMTI5NiBbNDc0IDQyM10gMTI5OCBbNjI5IDUyMV0g NzQyNCBbNDgwIDYzMl0gNzQyNiBbNzczIDUwOV0gNzQyOCBbNDc0IDUzM10gNzQzMCBbNTQzIDQw Nl0gNzQzMiBbNDI5IDIzMF0gNzQzNCBbMjY5IDQ0Nl0gNzQzNiBbMzY3IDY3Nl0gNzQzOCBbNTQx IDU1N10KNzQ0MCBbNDc0IDU4M10gNzQ0MiBbNTgyIDY0NV0gNzQ0NCBbODUwIDQyNl0gNzQ0NiA3 NDQ3IDUyNyA3NDQ4IFs0NTcgNDc2XSA3NDUwIFs0NzYgNDA2XSA3NDUyIFs1NTIgNTQ5XSA3NDU0 IFs3MjIgNzk5XSA3NDU2IFs0ODMgNzU3XSA3NDU4IFs0MTQgMzk4XSA3NDYwIFszOTEgNDc3XSA3 NDYyIFszNjggNDgzXSA3NDY0IFs1MzkgNDU3XSA3NDY2IFs2NDhdIDc0NjggWzM3MCA0OTNdIDc0 NzAgWzM2MyAzNzNdIDc0NzIgWzQxMiAzMzJdIDc0NzQgWzMzMiA0MDhdIDc0NzYgWzQxOSAyMDZd IDc0NzggWzIyNCAzNTldIDc0ODAgWzI5NCA1NTNdIDc0ODIgNzQ4NCA0MzIgNzQ4NSBbMzM3IDM1 NV0gNzQ4NyBbMzI2IDI5Ml0KNzQ4OSBbMzg1IDUzNF0gNzQ5MSA3NDkyIDMzNCA3NDkzIFszNjIg NTIxXSA3NDk1IDc0OTYgMzYyIDc0OTcgNzQ5OCAzNDAgNzQ5OSA3NTAwIDMwOCA3NTAxIFszMjQg MTczXSA3NTAzIFszMjQgNTQyXSA3NTA1IDc1MDYgMzYyIDc1MDcgWzI4OCAzNjJdIDc1MDkgNzUx MCAzNjIgNzUxMSBbMjM2IDM2NF0gNzUxMyBbMzU3IDU0Ml0gNzUxNSBbMzE1IDI4Nl0gNzUxNyBb MzQzIDI4NF0gNzUxOSBbMzE0IDQyNF0gNzUyMSBbMjk2IDE3M10gNzUyMyBbMjQ1IDM2NF0gNzUy NSBbMzE1IDM0M10gNzUyNyBbMjg0IDM2Ml0gNzUyOSBbNDI0IDI5Nl0gNzUzMSBbODIyIDU5MV0K NzUzMyBbNTkyIDM4MF0gNzUzNSBbODI2IDU4OF0gNzUzNyBbNTkzIDQxNV0gNzUzOSBbMzg4IDQ1 Ml0gNzU0MSBbMzgyIDM5NV0gNzU0MyBbNDcxIDM3N10gNzU0NSBbNDcxIDgxNl0gNzU0NyBbMjgy IDMwMV0gNzU0OSBbNTUxIDYwN10gNzU1MSBbNTk2IDUyNV0gNzU1MyBbNTQwIDMwNV0gNzU1NSBb NjYyIDUxNV0gNzU1NyBbMjQyIDgxMl0gNzU1OSBbNTQwIDUyNV0gNzU2MSBbMzQ5IDQzNV0gNzU2 MyBbMzcyIDQ1Ml0gNzU2NSBbNDkxIDQwNF0gNzU2NyBbNTYxIDYwNV0gNzU2OSBbNTI1IDQ5OF0g NzU3MSA3NTcyIDQyMyA3NTczIFs0OTggMjMwXSA3NTc1IFs0MjMgMjc1XSA3NTc3IFs2MDUgNDMz XSA3NTc5IFszNjIgMjg4XSA3NTgxClszMDQgMzM3XSA3NTgzIFszMDggMjE5XSA3NTg1IFsyMTkg MzI0XSA3NTg3IFszNjQgMTk2XSA3NTg5IFsyMDggMTczXSA3NTkxIFsxOTYgMjM3XSA3NTkzIFsx OTcgMTg1XSA3NTk1IFsyNjggNTQyXSA3NTk3IFs1NDIgMzg4XSA3NTk5IFszODkgMzc3XSA3NjAx IFszNjIgNDAxXSA3NjAzIFsyNzMgMTc4XSA3NjA1IFsyMzYgMzY0XSA3NjA3IFszNDAgMzYyXSA3 NjA5IFszNjIgMzE1XSA3NjExIFsyNzcgMzIyXSA3NjEzIFszMzEgMzA2XSA3NjE1IFszNjIgMF0g NzYxNyA3NjI2IDAgNzY3OCA3Njc5IDAgNzY4MCBbNTc5IDQ3OV0gNzY4MiBbNTQ0IDUyNV0gNzY4 NCBbNTQ0IDUyNV0gNzY4NiBbNTQ0IDUyNV0gNzY4OApbNTMzIDQyM10gNzY5MCBbNjE1IDUyNV0g NzY5MiBbNjE1IDUyNV0gNzY5NCBbNjE1IDUyNV0gNzY5NiBbNjE1IDUyNV0gNzY5OCBbNjE1IDUy NV0gNzcwMCBbNDg4IDQ5OF0gNzcwMiBbNDg4IDQ5OF0gNzcwNCBbNDg4IDQ5OF0gNzcwNiBbNDg4 IDQ5OF0gNzcwOCBbNDg4IDQ5OF0gNzcxMCBbNDU5IDMwNV0gNzcxMiBbNjMxIDQ3MV0gNzcxNCBb NjIzIDUyNV0gNzcxNiBbNjIzIDUyNV0gNzcxOCBbNjIzIDUyNV0gNzcyMCBbNjIzIDUyNV0gNzcy MiBbNjIzIDUyNV0gNzcyNCBbMjUyIDIzMF0gNzcyNiBbMjUyIDIzMF0gNzcyOCBbNTIwIDQ1NV0g NzczMCBbNTIwIDQ1NV0gNzczMiBbNTIwIDQ1NV0gNzczNCBbNDIwIDIzMF0gNzczNiBbNDIwIDIz MF0gNzczOApbNDIwIDIzMF0gNzc0MCBbNDIwIDIzMF0gNzc0MiBbODU1IDc5OV0gNzc0NCBbODU1 IDc5OV0gNzc0NiBbODU1IDc5OV0gNzc0OCBbNjQ2IDUyNV0gNzc1MCBbNjQ2IDUyNV0gNzc1MiBb NjQ2IDUyNV0gNzc1NCBbNjQ2IDUyNV0gNzc1NiBbNjYyIDUyN10gNzc1OCBbNjYyIDUyN10gNzc2 MCBbNjYyIDUyN10gNzc2MiBbNjYyIDUyN10gNzc2NCBbNTE3IDUyNV0gNzc2NiBbNTE3IDUyNV0g Nzc2OCBbNTQzIDM0OV0gNzc3MCBbNTQzIDM0OV0gNzc3MiBbNTQzIDM0OV0gNzc3NCBbNTQzIDM0 OV0gNzc3NiBbNDU5IDM5MV0gNzc3OCBbNDU5IDM5MV0gNzc4MCBbNDU5IDM5MV0gNzc4MiBbNDU5 IDM5MV0gNzc4NCBbNDU5IDM5MV0gNzc4NiBbNDg3IDMzNV0gNzc4OApbNDg3IDMzNV0gNzc5MCBb NDg3IDMzNV0gNzc5MiBbNDg3IDMzNV0gNzc5NCBbNjQyIDUyNV0gNzc5NiBbNjQyIDUyNV0gNzc5 OCBbNjQyIDUyNV0gNzgwMCBbNjQyIDUyNV0gNzgwMiBbNjQyIDUyNV0gNzgwNCBbNTY3IDQ1Ml0g NzgwNiBbNTY3IDQ1Ml0gNzgwOCBbODkwIDcxNV0gNzgxMCBbODkwIDcxNV0gNzgxMiBbODkwIDcx NV0gNzgxNCBbODkwIDcxNV0gNzgxNiBbODkwIDcxNV0gNzgxOCBbNTE5IDQzM10gNzgyMCBbNTE5 IDQzM10gNzgyMiBbNDg3IDQ1M10gNzgyNCBbNDY4IDM5NV0gNzgyNiBbNDY4IDM5NV0gNzgyOCBb NDY4IDM5NV0gNzgzMCBbNTI1IDMzNV0gNzgzMiBbNzE1IDQ1M10gNzgzNCBbNDc5IDI0M10gNzgz OCBbNTYxXSA3ODQwCls1NzkgNDc5XSA3ODQyIFs1NzkgNDc5XSA3ODQ0IFs1NzkgNDc5XSA3ODQ2 IFs1NzkgNDc5XSA3ODQ4IFs1NzkgNDc5XSA3ODUwIFs1NzkgNDc5XSA3ODUyIFs1NzkgNDc5XSA3 ODU0IFs1NzkgNDc5XSA3ODU2IFs1NzkgNDc5XSA3ODU4IFs1NzkgNDc5XSA3ODYwIFs1NzkgNDc5 XSA3ODYyIFs1NzkgNDc5XSA3ODY0IFs0ODggNDk4XSA3ODY2IFs0ODggNDk4XSA3ODY4IFs0ODgg NDk4XSA3ODcwIFs0ODggNDk4XSA3ODcyIFs0ODggNDk4XSA3ODc0IFs0ODggNDk4XSA3ODc2IFs0 ODggNDk4XSA3ODc4IFs0ODggNDk4XSA3ODgwIFsyNTIgMjMwXSA3ODgyIFsyNTIgMjMwXSA3ODg0 IFs2NjIgNTI3XSA3ODg2IFs2NjIgNTI3XSA3ODg4IFs2NjIgNTI3XSA3ODkwCls2NjIgNTI3XSA3 ODkyIFs2NjIgNTI3XSA3ODk0IFs2NjIgNTI3XSA3ODk2IFs2NjIgNTI3XSA3ODk4IFs2OTcgNTc4 XSA3OTAwIFs2OTcgNTc4XSA3OTAyIFs2OTcgNTc4XSA3OTA0IFs2OTcgNTc4XSA3OTA2IFs2OTcg NTc4XSA3OTA4IFs2NDIgNTI1XSA3OTEwIFs2NDIgNTI1XSA3OTEyIFs3MjIgNjAzXSA3OTE0IFs3 MjIgNjAzXSA3OTE2IFs3MjIgNjAzXSA3OTE4IFs3MjIgNjAzXSA3OTIwIFs3MjIgNjAzXSA3OTIy IFs0ODcgNDUzXSA3OTI0IFs0ODcgNDUzXSA3OTI2IFs0ODcgNDUzXSA3OTI4IFs0ODcgNDUzXSA3 OTM2IDc5NDMgNTY3IDc5NDQgNzk1MSA1NzkgNzk1MiA3OTU3IDQ1NiA3OTYwIDc5NjEKNDg4IDc5 NjIgNzk2NCA1OTIgNzk2NSBbNTk0XSA3OTY4IDc5NzUgNTM3IDc5NzYgNzk3NyA2MjMgNzk3OCA3 OTgxIDcyNyA3OTgyIDc5ODMgNjY4IDc5ODQgNzk5MSAyNzQgNzk5MiA3OTkzIDI1MiA3OTk0IDc5 OTcgMzU2IDc5OTggNzk5OSAyOTcgODAwMCA4MDA1IDUyNyA4MDA4IDgwMDkgNjYyIDgwMTAgWzc1 NiA3NTJdIDgwMTIgWzc0NSA3NDNdIDgwMTYgODAyMyA1NDIgODAyNSBbNDg3XSA4MDI3IFs2MzRd IDgwMjkgWzYzNl0gODAzMQpbNTc4IDY5Nl0gODAzMyA4MDM5IDY5NiA4MDQwIDgwNDEgNjY0IDgw NDIgWzc1NiA3NThdIDgwNDQgODA0NSA3NDMgODA0NiA4MDQ3IDcwMCA4MDQ4IDgwNDkgNTY3IDgw NTAgODA1MSA0NTYgODA1MiA4MDUzIDUzNyA4MDU0IDgwNTUgMjc0IDgwNTYgODA1NyA1MjcgODA1 OCA4MDU5IDU0MiA4MDYwIDgwNjEgNjk2IDgwNjQgODA3MSA1NjcgODA3MiA4MDc5IDU3OSA4MDgw IDgwODcgNTM3IDgwODggODA4OSA2MjMgODA5MCA4MDkzCjcyNyA4MDk0IDgwOTUgNjY4IDgwOTYg ODEwMyA2OTYgODEwNCA4MTA1IDY2NCA4MTA2IFs3NTYgNzU4XSA4MTA4IDgxMDkgNzQzIDgxMTAg ODExMSA3MDAgODExMiA4MTE2IDU2NyA4MTE4IDgxMTkgNTY3IDgxMjAgODEyNCA1NzkgODEyNSBb MjMxIDI3NF0gODEyNyBbMjMxIDQ1MF0gODEyOSBbMzkzIDUzN10gODEzMSA4MTMyIDUzNyA4MTM0 IDgxMzUgNTM3IDgxMzYgODEzNyA0ODggODEzOCA4MTQwIDYyMyA4MTQxIDgxNDIgMzk1IDgxNDMg WzM5MyAyNzRdCjgxNDUgODE0NyAyNzQgODE1MCA4MTUxIDI3NCA4MTUyIDgxNTUgMjUyIDgxNTcg ODE1OCAzOTUgODE1OSBbMzkzIDU0Ml0gODE2MSA4MTYzIDU0MiA4MTY0IDgxNjUgNTA5IDgxNjYg ODE2NyA1NDIgODE2OCA4MTcxIDQ4NyA4MTcyIFs1MTcgNDk0XSA4MTc0IFs0OTQgMzE3XSA4MTc4 IDgxODAgNjk2IDgxODIgODE4MyA2OTYgODE4NCA4MTg1IDY2MiA4MTg2IDgxODggNjY0IDgxODkg WzMxNyAyMzFdIDgxOTIgWzUwMCAxMDAwXSA4MTk0IFs1MDAgMTAwMF0gODE5NiBbMzM1IDI1MF0K ODE5OCBbMTY3IDUzOV0gODIwMCBbMjE3IDIwMF0gODIwMiBbMTI1IDBdIDgyMDQgODIwNyAwIDgy MDggWzMwN10gODIxMSBbNDk4IDkwNV0gODIxMyBbOTA1IDM5NV0gODIxNSBbNDk4IDI1MF0gODIx NyA4MjE5IDI1MCA4MjIwIDgyMjMgNDE4IDgyMjQgODIyNiA0OTggODIzMCBbNjkwXSA4MjM5IFsy MjYgMTAzOF0gODI0MiBbMjIxIDQwMF0gODI0NCBbNTgwXSA4MjQ5IDgyNTAgMzM5IDgyNTIgWzU1 OCA0ODNdIDgyNTQgWzQ5OF0gODI2MCBbMzM2XSA4Mjg2IFsyNjggMjIyXSA4MzA0IFszOTEgMTcz XSA4MzA4IFszNTcgMzMxXSA4MzEwClszNTkgMzIxXSA4MzEyIFszNjAgMzU5XSA4MzE0IFszNjQg MzU5XSA4MzE2IFszNTIgMjE3XSA4MzE4IFsyMTcgMzYyXSA4MzIwIFszOTEgMjQ2XSA4MzIyIFsz MzYgMzM0XSA4MzI0IFszNTcgMzMxXSA4MzI2IFszNTkgMzIxXSA4MzI4IFszNjAgMzU5XSA4MzMw IFszNjQgMzU5XSA4MzMyIFszNTIgMjE3XSA4MzM0IFsyMTddIDgzMzYgWzMzNCAzNDBdIDgzMzgg WzM2MiAzMTJdIDgzNDAgWzM0MF0gODM1MiBbNjE2IDUzM10gODM1NCBbNTMzIDQ1OV0gODM1NyBb Nzk5IDY0Nl0gODM1OSBbOTIyIDc4NV0gODM2MSBbODkwIDc0NV0gODM2MyBbNTUyXSA4MzY1IFs1 MjAgNDg3XSA4MzY3IFsxMDgyIDUyOF0gODM2OSBbNTYzIDU4N10gODM3MQpbNTczIDQ1OV0gODM3 MyBbNTMzXSA4NDEzIFs5OTRdIDg0NTMgWzc2Nl0gODQ2NyBbNTAyXSA4NDcwIFsxMDI1IDgzNF0g ODQ4MCBbNzA5XSA4NDgyIFs3MDVdIDg0ODYgWzY2NF0gODQ5NCBbNzM5XSA4NDk4IFs0NTldIDg1 MjUgWzc2NiAzNjZdIDg1MzEgWzY3NiA3MjNdIDg1MzMgWzY3NiA3MjNdIDg1MzUgWzcxNCA3MjVd IDg1MzcgWzY0NyA2ODZdIDg1MzkgWzY2NiA3MDRdIDg1NDEgWzcwNCA2NDZdIDg1NDMgWzM4NF0g ODU3OSBbNTMzIDQyM10gODU5MiA4NTk1IDkwNSA4NTk2IFsxMjg4IDc3N10gODU5OCA4NjAxIDg4 MiA4NjE2IFs0NzJdIDg3MDYKWzUzM10gODcxMCBbNTY0XSA4NzE5IFs3OTldIDg3MjEgWzU0MSA0 OThdIDg3MjUgWzMzNl0gODcyOSBbMjUyIDQ5OF0gODczNCBbODUzIDY4NF0gODc0NSBbNzAyXSA4 NzQ3IFszNjZdIDg3NzYgWzQ5OF0gODgwMCA4ODAxIDQ5OCA4ODA0IDg4MDUgNDk4IDg5NjIgWzg3 NV0gODk3NiBbNDk4XSA4OTkyIDg5OTMgNTQwIDkzMTIgOTMzMSAxMzI4IDk0NTAgOTQ2MCAxMzI4 IDk0NzEgWzEzMjggNTAwXSA5NDc0IFs1MDBdIDk0ODQgWzUwMF0gOTQ4OCBbNTAwXSA5NDkyIFs1 MDBdIDk0OTYgWzUwMF0KOTYzMyBbNjA0XSA5NjQyIDk2NDMgMzU0IDk2NzQgWzUxMSA1NTBdIDk2 NzYgWzU5NF0gOTY3OSBbNjA0XSA5NzAyIFszNTRdIDEwMTAyIDEwMTExIDEzMjggMTEzNjAgWzQy MCAyODJdIDExMzYyIFs0NzAgNTI1XSAxMTM2NCBbNTQzIDQ3OV0gMTEzNjYgWzMzNSA2NDNdIDEx MzY4IFs1NDggNTU1XSAxMTM3MCBbNDgyIDQ4NV0gMTEzNzIgWzQwOF0gMTEzODAgWzQ3MCA0NjNd IDExMzgyIFszODcgNjU0XSAxMTc5OSBbMzA2XSA0Mjc3NSA0Mjc3NiAzOTQgNDI3NzcgWzM5MyAz MzNdIDQyNzg0IDQyNzg1IDg4NCA2NDI1NiBbNTg0IDUyOV0gNjQyNTggWzUyOSA4MDhdIDY0MjYw IFs4MDhdCjY1MDU2IDY1MDU5IDAgNjUyNzkgWzBdXT4+DWVuZG9iag0xMCAwIG9iag08PC9PcmRl cmluZyAoSWRlbnRpdHkpL1JlZ2lzdHJ5IChBZG9iZSkvU3VwcGxlbWVudCAwPj4NZW5kb2JqDTEx IDAgb2JqDTw8L0FzY2VudCA3NTAvQ2FwSGVpZ2h0IDYzOC9EZXNjZW50IC0yNTAvRmxhZ3MgNC9G b250QkJveCBbLTUwMiAtMzA3IDEyNDAgOTYzXS9Gb250RmlsZTIgNyAwIFIvRm9udE5hbWUgL0Nh bGlicmkvSXRhbGljQW5nbGUgMC9NYXhXaWR0aCAxMzI4L1N0ZW1WIDgxL1R5cGUgL0ZvbnREZXNj cmlwdG9yPj4NZW5kb2JqDTEyIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQz Mjk+Pg1zdHJlYW0KeJzt23P4JFfWB/CrOnVZPbZt27Zt27Zte2JnkJlMxszEtm3b3OxvZ7O7eTfY N1nM4vt5ntu3+55Tp051VVf3P804+zniZyM/JGULuVUekdeo6nKb3CLnyLlyjaotO8sJspscJd+R 78r35PvyA/mh/Eh+LD+Rn8qusotqpOqrxrK13MkUS88ysGwsFyvCirJSrCyrwWqxOqwRa8xasq6s O+vB+rBBbBibyCax6WwGmyvnyXFyvtwkZ/B3ueApno7n4Hl4Md6O9+C9+XA+io/lk/kUPpsv5yv5 Kr6O7+CH+I38LL+N387vkQvkGLlQbv5/HeHfOv6WcpfcI6+Q++RYuV7E8iL+gBymmqcd/yUiyMtV E/mF/JJ/pDrIDXKWKCE/5w/K4aqUKqEqyDYsYsRipplhnqVYVpab5WF5WX5WjpVnFVgllpM1Y61Y a9aGtWXtVF3WiQ1nI9hINprNYt34Ni654hEnHnPLA8/M8/J8PD8vyPvwvrwfH8Bz8+l8Dp/L5/H5 fIGqx5fww/wIP8qP8zv5Cn43s1wzxw1LuGcZeXqWiWdgWXgmlplnZNl5TpaD52IFeCFWkBdmhXgR VpgXZfl4AVaMt2fFeQdWgndkJXknVpr3ZGV4L1aR92eV+UBWhQ9i1fhgVpUPYdX5UFaTj2S1+Wg+ htXl41h9PoHV4+NZQz6JNeATWRM+lTXnM1hTPo3PZC34LNaeL2Qd+CLWkS9mXfgy1pOvZr35WtaL r2F9+XrWj29gA/gm1p9vjNJF6dlgvpMN5ReyUfwYG8NPsLH8JBvHT7Hx/DSbwM+wqfwWNpvfxeaw efxetoDfz+bz+/h2Wh49HD1CK6JHaWX0WPQ4rYqeiJ6MnqLVtCZ6OnomejZ6jtZGz0cv0Lroxeil 6GXaQBtpU/RK9Cptjl5T69WZ6HXaEr1BW6M3o7doW/Q2vUDbo3doR/Su2q5uj96L3o8+oJ3Rh3RB 9FH0MV1IF9GL0Sd0Mb1E6+lleoVepdeiT6PP6JLo8+gLujT6MvqKLou+psujb+iK6Fu6MvodXRV9 R1cTo2uI07UkaBftJkl7SNFeiug6ItpHMe0nTdeToQNk6QZydJAOkadAhymhI5SidJSejrLAHUvH E9aZL6UMdIwy0nHKRCcoM52kLHSKstJpykZnKDvdSDnoLOWkmygX3Uy56RY2kG9mQ/gFlIdupbx0 G+Wj2yk/3UEF6E4qSHdRIbqbCtM9VITupaJ0HxWj+6k4PUAP0kP0MB9Bj9CjVIJK0mNUikrT4/QE laEnqSyVo/JUgZ6iivQ0VaJnqTI9R1XoeV1EF9XFdHFdQpfUpXRpXUaX1eV0eV1BV9SVdGVdRVfV 1XR1XUPX1LV0bV1H19P1dQPdUDfSjXUT3VQ30811C91St9KtdRvdVrfT7XUH3VF30p11F91Vd9Pd dQ/dU/fSvXUf3Vf30/31AD1QD9KD9RA9VA/Tw/UIPVKP0qP1GD1Wj9Pj9QQ9UU/Sk/UUPVVP09P1 DD1Tz9Kz9Rw9V8/T8/UCvVAv0ov1EtPUNDPNTQvT0rQyrU0b0zbUDLVMB9PRdDKdTRfT1XQz3U0P 09P04p/zb0xvEUwf09f0M/3NADPQDDKDzRAz1Awzw80IM1JkEIVEVlFKCJHXjDKjzRgz1owz480E M9FMMpPNFDPVKhtZsrHV1lhrnfU22MSmbDqb3mawGW0mm9lmsVltNpudf8A/5V+JSKRLKorMophw ST6RQxTg3yWVk6pJ9aRmUjupm9RPGgoeNYmaJo2TJknTsCtpnrRIWiatktZJm6RtUiFpl7RP8oiS onTSIemYdEo6J12Srkm3pHvSI+mZ9Ep6RwOiQdGQaFjSN+mX9E8GJAOTwdGEaFI0JbkjeU5cmLyT DE2GJyOSkcmoZEwyLpmQTIwWJ5OSKcm0ZEYyM5mVzE7mJPOSBcnCZFGyJFmaLE9WJquSNcm6ZH2y MdmcbE22JzuTC5OLk0uTy5Mrk6uTa//8ZXaZuPxPz31XO9KOsqPFpT/4stshLhDlxUWiiqguaqW9 bpQ2Woh2YoEoJyqIiqKSqCyqimqihqgp6oi6op6oLxqIhqKxaJKW2VQ0E81FK9FatBFtRW3RUkwU 08UsMU9sFBPEJDFFTBXTxAwxU8wWc8VCsUgsFkvEUrFcrBSrxBqxWqwV68QmsUVsFdvEfLFBrBDr xXbG7AA72Haz3W0PO8YOtVNtLzvO9rOTbE871va2421fOzEMCiPD4DAqDAmjw9AwJgwLY8PwMC6M COPtEDvMjrCTbUc70A6y/e0U28n2sRPscNvZdrFdxR6xVzwqrhEPiZvEDeKgOCSOiZPiMXFEHBC3 irvEFeJKcZW4WuwSu8V1Yp/YL64Xh8VRcVycEKfEGXGjOCtuFreI28Ud4k5xt7hH3CvuE/eLB8SD 4mHxiPQyyJRMJzPJLDK7zCFzylwyvywoC8sispgsIUvJ0rKsLC8rycqyiqwmq8sasqasJWvLOrKe rC+zymyygUwv68oyMo/MK/PJQrKobCgLyNyygqwa5obV4nHZKMwLa8L8sDYsCOvCwrA+LAobwuKw MSwJm8RpWVzcJiuGpWFzWBa2hOVha1gRtoWVYXtYFXaEmcl7yfvJh8nHjIXZYY7v6S/2vfwlvre/ VFwrM/g+/jLf11/u+/krfH9/pR/gr/ID/dV+kL/GD/bX+iF+lx/qd/thfo8f7vf6Ef46P9Lv86P8 fj/aX+/H+AN+rL/Bj/MH/Xh/yE/wh/1Ef8RP8kf9ZD/FH/NT/XE/zZ/w0/1JP8Of8jP9aT/Ln/E3 +tn+rJ/jb/Jz/c1+nr/Fz/e3+gX+Nr/Q3+4X+Tv8Yn+nX+Lv8kv93X6Zv8cv9/f6Ff4+v9Lf71f5 B/xq/6Bf4x/ya/3Dfp1/xK/3j/oN/jG/0T/uN/kn/Gb/pN/in/Jb/dN+m3/Gb/fP+h3+Ob/TP+8v 8C/4C/2L/iL/0j/glxIAAAAAAAAAAPzPCbvPdwcAAAAAAAAAAAAAAAAAAP8t9FK9TC/XK/RKvUqv 1mv0Wr1Or9cb9Ea9SW/WW/RWvU1v1zv0Tn2BvlBfpC/Wl+hL9WX6cn2FvlJfpa/W1+hr9S69W+/R e/V1ep/er6/XB/QN+qA+pA/rI/qoPqaP6xP6pD6lT+sz+kZ9Vt+kb9a36Fv1bfp2fYe+U9+l79b3 6Hv1ffp+/YB+UD+kH9aP6Ef1Y/px/YR+Uj+ln9bP6Gf1c/p5/YJ+Ub+kX9av6Ff1a/p1/YZ+U7+l 39bv6Hf1e/p9/YH+UH+kP9af6E/1Z/pz/YX+Un+lv9bf6G/17/R3hhluhJFGmciQiY02xljjjDfB JCZl0pn0JoPJaDKZzCaLyWqymewmh8lpcpncJo/Ja/KZ/KaAKWgKmcKmiClqipnipoQpaUqZ0qaM KWvKmfKmgqloKpnKpoqpaqqZ6qaGqWlqmdqmjqlr6pn6poFpaBqZxqZJsjvZG51N9iX7kwPJweRw cjQ5npz815z75FRyhqrS61SN3qDq9CbVoLeoJr1Ntegdqk3vUh16j+rS+1SPPqD69CE1oI+oIX1M jegTakyfUhP6jJrS59SMvqDm9CW1oK+oJX1Nregbak3fUhv6jtrGjNrFnNrHgjrEkjrGijrFEXWO ibrEMXWNNXWLDXWPLfWIHfWMPfWKA/WOE+oTp6hvnI76xempf5yBBsQZaWCciQbFmWlwnIWGxFlp aJyNhsXZaXicg0bEOWlknItGxblpdJyHxsR5aWycj8bF+Wl8XIAmxAVpYlyIJsWFaXJchKbERdlk fhObwm9m0/itNDUuRtPi4jQ9LkEz4pI0My5Fs+LSNDsuQ3PisnG5uHxcIa4YV4or/+H9SxVgTE1S l6nJ6nI1RV2hpqor1TR1lZqurlYz1DVqprpWzVK71Gy1W81Re9RctVfNU9ep+WqfWqD2q4XqerVI HVCL1Q1qiTqolqpDapk6rJarI2qFOqpWqmNqlTquVqsTao06qdaqU2qdOq02qBvVRnVWbVI3qc3q ZrVF3aK2qlvVNnWb2qHuUDvVneoCdZe6UN2tLlL3sJn8DnWxulddqu5Xl6j7fngNOOHIKaeddLGL nLFL7Uq73K62y+wqu8KucTldHpfb5XO5XN4/5Nsr7TX2arvLXmXP/bfOFXRFXWFX3BVyxVwRV8Lu tdfbffYGe509YPfbg66Gq+NquXqupqvrarv69k57r73b3m/vsvfZe+wDroVr7Vq5tq6la3Ou/qP2 Cfu4fco+Zp88V7+T6+a6uB6us+vuurqeaRnPpY0X0sbzaeNFN8gNc0PcCDfYDXdD3Uj7mn3LvmHf sa/bt+2b9l3nnHUFXH5XypV0TVxj1961c/1cXzfajTpXP53L5DK4LC69y+wyuqx2k91mt9gddrPd brfana6sq+jKu8qunKvkKrgq9qg9aY/b0/aYPWVP2DNunJvkJrgpbryb7Ca6qfZD+6n92H5uP7Kf 2U/sFy5xwWV3KZctbV/e5bAb7Hq7zq61G30n39U38S18R1fNlXFV0+KlXXW7x+62h+0he8S38i19 a9fcNXMNXYNzvTZ1jewj9mH7kH2QMd/Wt/Ht3EA3wPV2vVwH19H1d33sq/YV+7J9yT7rO/j2vvm5 7aa7sW5a2jzGzbDP2Kft+/Y9+4Fv5psyFoqGYqF4KBFKhlKhdCgTyoZyoXyoECqGSmFP2CsnpOVU lpPkFDktVA3VZA/ZUw4I1WUf2VcODDXkWrlOzvzjtSS7//UdJlynaqQ91gy1Qu0/rclBcnDaWh3Z LtT9S6Yq9uvvX2Ff2P+3cuRn4fpz81fya/mN/Fb+Tn6nmOJKKKkUf0FFilSstDLKKqe8CipRKZVO pVcZVMa0KyyfzW8L2IK20M/0UD80CA1Do9A4NAlNQ7PQPLQILdUD8qrQKrQObULb0C60Dx1Cx9Dp D/mpgqlCqcK//lh/Ys+z/hFV/kIe+vmYanku47C8+EdbXZY2vv8frWr/V1u1+ONMS39LP6FLXOfP lUqqcqq0Kq8qqsqqjKqiyqpKqqqqpor/lso/Rkvi2j8dUV1UN9VVdVd9VF/VU/VQvVTvX+z62l+K /ntSrb+f2/0o0jFtdFLnzkM48Mc1OUu1/T7aKnT9cbXQLS3S5jf30vBX5jcI5+46qqlq9lv3+b8u 9PiFWM+/sW2v8IufB4B/ppRMqVSUolSc0imTsimX8qmQSlKpVLpU+lSGVMZUplTmVJbz3ee/Ukqk sqWyp3KkcqZypXKn8qTypvKl8v9UZrgh9El77PsTkX7fz/2/nwd8Pw/8JzT8Hy0c/NHKoXD476mo OqsHI3Ou0pFf1cnRv2evAP/dwrFwPJwIJ8OpcDqcCTeGs6ms57snAAAAAPh1aG5chebRfFoQV42r 0cK4Oi2Ka9DiuOb/zYtr0bK4blzvvDQJ8F8h1DvfHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwL87m8PmtLls7h+s5LF5z18/AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAPC/ipfkZXhTXo23PN+dAADAf5JwU7g53BJuPd99wG8Rbjvf HcD59XvYlvs5CmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwvRjAgNSAwIFIvRjEgMTQgMCBS Pj4NZW5kb2JqDTE0IDAgb2JqDTw8L0Jhc2VGb250IC9DYWxpYnJpLUJvbGQvRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZy9GaXJzdENoYXIgMC9Gb250RGVzY3JpcHRvciAxNSAwIFIvTGFzdENoYXIg MjU1L1N1YnR5cGUgL1RydWVUeXBlL1R5cGUgL0ZvbnQvV2lkdGhzIFswIDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDAgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgMjI2IDMy NiA0MzggNDk4IDUwNyA3MjkgNzA1IDIzMyAzMTEgMzEyIDQ5OCA0OTggMjU4IDMwNyAyNjcgNDMw IDUwNyA1MDcgNTA3CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyNzYgMjc2IDQ5OCA0OTgg NDk4IDQ2MyA4OTggNjA2IDU2MCA1MzAgNjMxIDQ4OCA0NTkgNjM4IDYzMSAyNjcgMzMxIDU0NyA0 MjMgODc1IDY1OSA2NzYgNTMyIDY4NiA1NjMgNDcyIDQ5NSA2NTIgNTkxIDkwNSA1NTEgNTE5IDQ3 OCAzMjUgNDMwIDMyNSA0OTggNDk4IDMwMCA0OTQgNTM3IDQxOCA1MzcKNTA0IDMxNiA0NzQgNTM3 IDI0NiAyNTUgNDgwIDI0NiA4MTQgNTM3IDUzOCA1MzcgNTM3IDM1NiAzOTkgMzQ2IDUzNyA0NzQg NzQ1IDQ2MCA0NzQgMzk3IDM0NCA0NzUgMzQ0IDQ5OCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1 MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNwo1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyMjYgMzI2 IDQ5OCA1MDcgNDk4IDUwNyA0OTggNDk4IDQxNSA4MzQgNDE2IDUzOSA0OTggMzA3IDUwNyAzOTAg MzQyIDQ5OCAzMzggMzM2IDMwMSA1NjMgNTk4IDI2OCAzMDMgMjUyIDQzNSA1MzkgNjU4IDY5MSA3 MDIgNDYzIDYwNiA2MDYgNjA2IDYwNiA2MDYgNjA2IDc3NSA1MjkgNDg4CjQ4OCA0ODggNDg4IDI2 NyAyNjcgMjY3IDI2NyA2MzkgNjU5IDY3NiA2NzYgNjc2IDY3NiA2NzYgNDk4IDY4MSA2NTMgNjUz IDY1MyA2NTMgNTIwIDUzMiA1NTUgNDk0IDQ5NCA0OTQgNDk0IDQ5NCA0OTQgNzc1IDQxOCA1MDMg NTAzIDUwMyA1MDMgMjQ2IDI0NiAyNDYgMjQ2IDUzNyA1MzcgNTM4IDUzOCA1MzggNTM4IDUzOCA0 OTggNTQ0IDUzNyA1MzcKNTM3IDUzNyA0NzQgNTM3IDQ3NF0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwv QXNjZW50IDc1MC9BdmdXaWR0aCA0OTMuNTA0L0NhcEhlaWdodCA2MzgvRGVzY2VudCAtMjUwL0Zs YWdzIDMyL0ZvbnRCQm94IFstNTE4IC0zMDYgMTI0MCA5NzFdL0ZvbnRGaWxlMiAxNiAwIFIvRm9u dE5hbWUgL0NhbGlicmktQm9sZC9JdGFsaWNBbmdsZSAwL01heFdpZHRoIDkwNS9TdGVtViAxMjMv VHlwZSAvRm9udERlc2NyaXB0b3I+Pg1lbmRvYmoNMTYgMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURl Y29kZS9MZW5ndGggMjY4ODUvTGVuZ3RoMSA2OTQ3Mj4+DXN0cmVhbQp4nOy9B3hTRxY/OuXekXSb JNsqrpKs4iJbcm8YW7iAC6bYFBsw2HQChBpaQkkjCQlppDdSNr2Z7oT0sOkk2YRNNskmm7YbUtjN pm4Ay+/cK8kYh93Nf3f/733v+2L7p5k5d+7cmTNnTpm5AoQRQhLahCgKzVrcvZSry18AlFcQ8nw8 a9VKZ7CxuBEhbw9CTD936bzFt31R8wBC/l6EDPHzFq2de3zJC3CtCOoPf2D+nO7ZXz1Z+BeElq+B NkrmA0HeGtcMZaiDPPMXr1xjeezYWigfQqjyqkVLZnXTSfECQg/Ph/JNi7vXLE2x2O5H6CsO6jtP 714852//+HMrlD0IyeuXLlmxsj8ZbUbop9+o15cun7P0+a9XBqB8ACHLTUCjUaQgdVzIvA5KkIs/ D3Hm6dq4NiGGRkNORhvIfPIwXULPoBvoFnoJvY2+ym3m45Xq1CdTX0q7Me2WtJ8cFkeqo97R4pjs 6HBMdXQ61jt2Ow443nS85/ib4ztH2Glypjt9zjxnkbPCWeWsc85wLnNe6rzKucf5qPN9F++Kd9lc Tle6y+cKuApcY1wzXOe5rnfdk07SWboxPS7dkp6U7kjPSvenN6R3p89xE7fJ7fKs8HznRV7ilbwm b4LX7r3Ne7/3Fe9r3r9kbMxZlLM6YLs76W7XMS7sDvf396vjhNE40a1kAemhK+k6eh6M5lJ6B32d uxBGg1KfSg3DaG51IIfd4XQ0OMZFRzPDscmx1/Gc4y3H+45vHD84kTMORhN0FjjLnZUwmunOpc6V zsudtzp7o6OxDhpNi6vNda7r8oHRmGE0ielp0dF0pc/WRuP0dHm+8PSfNJr7vC9po1mV05WzEkZj u9t5DIWd2mhw//fqgPi3EeoPqLlwL4r+9C/68gI1/fo8NOjny/Ph9xx0ip9PChE6YvjED7lPj4xX KZ9fjtBfF361/eOeT8oQ+vicjzd+4v8k5c8TY3d8hT9u/rjp4zpo9Wat7eDH7o+OIfTRJ1+0f9H8 ReUXd6jUw52HJxwef3jM4ebD8YdFhD47/Nkbkfv/lDWLzgwjZLxdeT4igegFDL3l42D9XMqugc9b 2XO6FP2F6iXDDYaHEBL+Il4nPiO+IlklZ6QVKVOaLb0iHZaJLMl5cpFcJ8+GKdbGKG+KfKoleXes 3/JbJ0Ytvyq/Lh+Wvxgof6dC/iFa+mZQzS/k8Mkci1yVv1E4JSVCiaWI0iZ6Ld1H7+HK6XX0Glgz G+ml3HA6kS6n7XQR/YoeoX+lf6Nf07/Tb+i39Dv6PZ1MJ3F13AiunrbQGxGHzCgO2WFt+lAGykFB VIEqURWqQ/WoGU1GHWgKmo5mo/loBVqJ1qJ1aCPdRJfSs+lVdB0+ggk2YhNOwmk4E4/DU3AnXoAX 4SX4DLwKr8cX4YvxJfhyfAPeg5/CT+Pn8PP4FXoOPZ2eS6+G3jfT++gD9DdUXfFXEB29Bb9O53ON 0PtbiUzv4EbSf9Cf8DdcK72SnkWy6Y/4d3QBl8NlcwV0DOJBa+iQHhlAVxqRDaWiNORALpSH8lEB KkLJqAG0Sgsag8aicVw1moAWoNPQQrQYnYXa8XWYYg7zmGEdFrCMLdiBndiF3Xg6noG78Eycitfi DXgj3oTPxudwIbwZ78X7cC9+FL+It+CXkYD1SMQGpGAJxWMzSsBxyIoTkAXHo0ScjJJwCkrHHuTG XuTBPuTFGciJ01EmHo+ycCvKxm3IjyegXDwVBfA0VIi7UTGehUrwbFSG56BSPBeV43loGF6IhuPF +HRUjZeiEXg5CuFlqBavRDV4BRqJV6NGvA6NwmvwmagJn4XG43NRK0h4Gz4fTcIXoql4K+rEl6Fp +FI0A1+BuvCVaCa+CnXjbbyJN6M5+EY0D9+MFuFH0Ol4P1qCH0NL8eNoGX4CLcdPotX4AFqPX0Ib 0CZ8EJ2DX0Nn41fx9ewi/k3+ENvC/55dzL/Fv80u4f/Av8O/y7ayS/n3+D/y7/MfsMv4P/Efssv5 j/iP+U/YlWwbu4r/lP8zu5r/C3cF9yT/GbuGP8yu5T/nv2DX8V+yD9n1/FfsBv4Idz33PP9X/m/8 1+xG/u/sJv4b/lt2M7uFfcR/x7azj9kV7BP2Kfsz+wv/Pf8Du5X/kf8Hu43/iT/KbuePsTv44+w3 fB+7kw+zu/h+djdD7B6G2b2MsPvY/YyyBxjHHmQ8e4gx9jDTsR6mZzuYge1kAtvFRLab7WESk9le prB9zMhMzMx6kYxFZMIKmogvYHHsERbPHmUJbD+zsMeYlT3ObOwJZmdPskT2FEtiT7Nk9gxLYc+y VHYAzcJXo7n4JpbGfssc7DnmZM8zF3uBpbMXmZu9xDzsZeZlrzAfO8gy2Kssk73Gstjr7HfsDfYm Po0dYr9n2czP3mI5LJe9zf7AAuwdFmR5LJ8VsHdZIXuPFbH3WTH7gJWwP+l9+gx9pj5Ln63363P0 ufqAPqjP0+frC/SF+iJ9sb5EX6ov05frK/TD9JX64foqwyhDg6HR0GRoNow2tBjGGMbKw+RKQ6uh zTDBMNEwyTDZ0G7oMEwxTDVMwz/i44ZOIhumG2YYugzdhpmGWYbZhjmGuYZ5hvmGBYbTDAtJHPEQ G8khhDgMiwyLDacblhiWGpYZlhtWGFYazjCsMqwWOIEXmKAT9IJBEARRkARZUASjYBLMQpwQLyQI FsEq2AS7kIi/xt/jo4QnJqWQWEgmERUnSSLpuF8pVkqVcmWYMlypVkYotQTzI/lRSr0yUhkl36c0 Kk1KszJaaVHGKGOVAmWcMl5JI36Sq7QqbcoEZaIySZmstCsdyhRlqjJN6eRn8rP5ufx8ZYbSpXQr M5VZyhx+Ob+SX6W8oHxAbla+UuYpC5TTlIXKIuV0ZamyXFnBn6+sVFYpa5R1ypnKWcp6ZYOySTlH OVc5T9msXKBcpFysXKJcqlyuXKFsU65WrlWuV25Ubla2K7cpdyh3Kncr90qThYXCImExuY3cQG4i +eQWUkLKSSVpIuPIOSSPFJBCUkSKSSkpIxVkGKki1SRERpAaUkvqyUgyijSQRjKatJAxZCwZTprJ CrKWnEU2kW1kOVlJVpHVZA1ZR84k68lGci45j5xPNpMLyEXkYnIJuZRsJZeRy8lV5BpyLbmOnE2u JFvIFeR6YaYwR2gXOoQpwunCPGG1ME1YKnQJK4WpwhKhU1gmzBBWyLPlhfIceZE8V14sz5NPl+fL S+QF8lL5NHmZMFeYL5wmnCG0CbOE2UK3sEqYIEwXlgsLhInCJGEyeYA8SH5P7iFvkGfILrKb7CGP kMfIW2Qf2Ul+S14ivyF3krvI3eQ+cj95iDxMesgOspf0kkfJfvI4eZI8RZ4mz5ID5HnyAnmRvExe IQfJq+Q18jr5HXmTHKISlamRmmgCtdJEmkSTaQp1UTf1Uh/NpNk0h+bSIM2nRbSYltAyWk4r6DBa SYfTKhqiI6iN2mkNNdNqGqBp1EGd1EMzaC1Np6m0gJbKG+Wt5G1aBx7ApfLZ8mXyOfLl8rnyFfJ5 8pXy+fI2ebN8FXmCZpHnaKF8gXy1fKF8jXyRfK28Rb5Ovli+Xr5EvkE+U/mr8jfl78q38np5gzRV 2i5Nk26VOqXbyL00Tpou3S7NkO6QuqTfSN3SndJM6S5plnQ3+CT3SHOke6W50n3SPOl+ab70gLRA elA6TXpIWig9LC2SeqTF0g7pdGmntETaJS2VdkvLpD3ScmmvtELaJ62UeqUzpFXSI9Jq6VFpjbRf Wis9Jq2THpfOlJ6QzpKelJ6S1ktPSxukZ6SN0rPSJumAdLb0W+kc6TnpXOl56TzpBel86UVps/SS dIH0snQh+EgXSQelLdKr0sXSa9Il0uvSVul30qXSG9Jl0pvS5dIh6Qrp99KV0lvSNult6SrpD9LV 0jvSNdK70rXSe9J10h+l66X3pRukD6QbpT9JN0kfSjdLH0m3SB8r9ysP8k8rDys9yk5lt7JX6VUe VR5THleeZKXsM1bGDrNy9jmrYF+wYexLVsm+YsPZEVbF/sqq2d9YiH3NRrC/sxr2Datl37I69h2r Z9+zkewHNor9yBrYP1gj+4k1saOsmR1jo9lx1sL62BjWz8bqEBunw2y8jrBWHWVtOo5N0PFsoo6x STodm6zTs3adgXXoBDZFJ7KpOolN08msU6ew6Tojm6EzsS6dmXXr4thMXTybpUtgs3UWNkdnZXN1 NjZPZ2fzdYlsgS6JnaZLZgt1KWyRLpUt1qWx03UOtkTnZEt1LrZMl86W69xshc7DVuq87Aydj63S ZaAz8DNoFX4WrcG/Zat1mWyNLout1WWzdTo/O1OXw87S5bL1ugDboAvq8nT5ugJdoa5IV8yt5G7n zuDu4FZxv+FWc3dya7i7uLXc3dw67h7uTO5e7izuPm49dz+3gXuA28g9yG3iHuLO5h7mzuF6uHO5 Hdx53E7ufG4Xt5nbzV3A7eEu5PZyF3H7uC1cL3cx9wh3Cfcot5Xbz13KPcZdxj3OXc49wV3JPcVt 457mruKe4a7mnuWu4Q5w13K/5a7jnuNu4F7gbuRe5G7iXuJu5l7mbuFeQWfiF7jt3EHuNu417lbu VZGITOREvUhFnciLBuEC4WLhImGrcKFwibBFuFRMFtPEVNEppogO4U7hHuFu4T7hLuFe0S1miF4x S/SImaJPzBYeFHYIDwu7hIeEnUKPsFusEKvESjEkDhOrxeHiCOFF4aDwsvCa8JLwqvCK8LrYJLaI o8WxYrM4Rvi98AfhbeFd4S3hHXGC2C5OEqeIE8UOcbI4VfhInC3OF+eKp4lzxAXiPHGh8BfhC+Gw 8JXwmfCl8LlwRBRFQUwXXWKO6BdHivXieHGc2CXOEBeLi0STmCDGiVbRLFrEeNEmXCVcJ1wj3CBc LVwvXCvcKAbFQjFfLBbzxCKxQCwReoXHhEeFJ4RHhMeF/cKT4lJxpbhcXCUuE88QV4irhb8L3wvf Cj8K3wg/CN8J/xAVURYTRaNoFyUxSbhSuEK4XLhM2CZNkCZLI6UmqU0sEwNiqZgrlgsPCPcLe4U9 wj5ptNQstYiNYoNYK9aIo8Q64ZDwpvCG8DtprDRGGifOEmeKneI0sVVsE7vF6cKfhU+FT4SPhfel Vmm81CiuFZeIa8TTxXXCH4X3hL8JfxW+lhqkUXKGnClnydmyX86Rc+WAHITIKl8ukAshvnpAfpAu l4shdl5F18ilchmdQqfSmXI5nU5n0FlyBb2MXk7PlB/iKuQqOk6upj/IO+hReowep300TPs5xGGO cJTj8IcczzFOx+k5AydwIidxMqdwRs7Embk4Ll4eIdfItRDR1csj5VFyg9woN8nN3Ov0Lnm03CKP kcfK4+TxcqvcJk+ge+l2eZKuivNzeVwul88VcsVcgCvhglwRV8qVcVlss244N4lr5yZzHdx0bgY3 lZvCTeM6uQlcFT2LG8uNlidzNXKHkRjtxkRjkjHZmGJMNaYZHUan0SXvkqdzE7nf8Qb5EflReb/8 mPy4/IT8pPyU/LTRxjbqStgmdjY7R1eqK2Pn6srZeboKdr5umK6SXair1oWwHwfwKFyGmxEjghok YhSNek/8YETgV/0hp4rRT6r5//84E2kRog2iwwY0Di2GqI9C3AfqHOI+C8R8Di3qmwFxnxr1rYWI bwPEfOdA1LcPIj6I90DS7tAi1SvomfRKfB29ld5Cb8PfEB1XA5HnBG40N5IbxTXQh7lWrgXmuY1c zI3Br+PfceMhstxMx9BmrpEbyy7jarlxdD5dQDsQhfhVD5EpRGiajKtSDRLOhbiJEFtu4DLpXXQ2 naPOJsj5WXQmncVVQLzrgKjXBbFuJMbN0+JbBHGuGtkuwHPxj+Bty1HPO5s4SA4+/us+26/7bL/u s/26z/brPtuv+2y/7rP9us/26z7br/tsv+6z/brP9us+26/7bL/us/26z/brPtt/tc8GP7pbIFbf NiiYPBt+b0L3oz3oUfQ0egm9ib7FAupC56Mn0SfoC/QNOoYRREQWnIKzThW//2c/4XP5xUimT0HE ZkOo/2j/5+F7+z+HGFwZRNkGJRvnO0Hpj+s/MpQW3hbuDb/KwAvX7jWRl4H6NT7Sf5RUq+X+ErVM LlDz2h1f624JPxzeflJ3lqLl6Ay0Rotnz0TrIbLZiM5Fm9EF6EJ0EfBiI+QvRpegrehSdBm6HF2B rkTb0FXoanQNuhZdh65HN6AbgY83o1vQ9ug1tXwL/F6jXVWv3I7uQveiByC9A/0G3YnuRvdA+T7g /gPoIaBFKJHyg0C5Fd0G1LuAqtZSaQ/Dbw/agXaiXWg3zFmkHCv1oqfQXrQP0kdgNvejx9Dj6AmY x6dgZp/RaColVv7nNSOfz6ID6LfoOfQ8egG9CJLxMnoFHUSvotf+oyu/HaCopdfR79AbIGuH0O/R W+ht9A56D32A/oQ+RB+D1H31s+t/gBrvQp33o7U+glp/Rp9DzSNQM1IvUueP2tXDWguH4N4P0acQ lX+PCTqG+iGnzt412gxdr82jOnvq7PxG47M6Hw9DWZ2huwfm5kHg8YMwn2pJzd8QnY2HoO4O4GCM f6fm2qvR2Ynw+zGoo/JCvXIwyovnozOhtvPEwL0va9d2avc9M9DqCY5GRvj7Qdz54yAe/hn9ReNM hHuRqye4p9b4FOqoXFbbOJm3H8O9Ee6r96r0wfeo196F8uegHb4CTqvpl9pMfIk+G8h/Fr1+BP0V /Q19r31+jf4O+uRb9B2UfwDK11D6OXUo5Uf4/Qf6CR2FGTyO+gaV+oZc6UNhmGOEMSaYovCJ3Amq htgujx4bsIAlLGNF27XSDbkiDlwx/+yKdIprBo0Sh+NxAuhLG7bjJJwMejMVp2l79+mDriUOXIns MXmwN3rNqt2ZOHCvugtlG1Q3C+fh1fCp6vUg5PNxES7GpbgcKLlQLoByBVzL09IaNA7NRIvQUf4w eQXaTwCtsiM0csb0zmlTp3S0T5zQ1jp+3NgxLaObmxobRo2sr6utGRGqrhpeOayivKy0pDgYyM3J 9Hk97nSHPcFsMsqiYNDrGM9RglFOvXtkl7PH19XD+dwNDblq2d0NhO5BhK4eJ5BGnlynx9mlVXOe XDMENecOqRmK1AwN1MQmZyWqzM1x1rudPQfr3M5ePGV8O+S31rk7nD1HtHyLlud8WkGGgssFdzjr 7fPrnD24y1nfM3LV/C31XXXQ3g5RqHXXzhFyc9AOQYSsCLmeTPfSHTizCmsZkllfsYMgvaw+tod6 67tn94wb315fl+xydWg0VKu11cNqe3RaW84Fap/Rxc4dOU9tuaTXhGZ2+aXZ7tnd09p7aDfctIXW b9lyQY/Z35PlruvJWvepHYY8pyfHXVff43dDY82tAw/APbzX5HZu+R5B591HvjqZ0h2lMK/pe6Rm 1SEOsAmux/II+gY9hPG5XGpfLu4NoZlQ6Nk0vj1SdqKZyTtRKOjv6CFd6pWnYlcsE9Urm2JXBm7v crvUqarviv6tmm/v2TTTmZsD3Nf+vPAH15091Nc1c9Z8Ne2es8VdVxfh24T2nlAdZELd0bHW78gL Qv3uLhjEApUN49t7gu6lPQnumkgFIDjVOVjQ1q7dEr2tJ6G2B3XNit7VE6yvU/vlrN/SVRfpoNqW e3z7I6iw/8MdRc7kXYWoCHWo/eix1sKk+Oq3tM+e2+PoSp4N8jnX2Z7s6gl1APs63O1zOtRZcpt6 sj6Ex7m0J2p3wdiG1I5VVkeu8+qd7SSZdqizBQTnSPhw11TCBRNMl1ZUZ7Sm0tmOk1GsGjwlWkPN ndQOFKi3tkG9RNVbaxuSXR2uyM+/6FJytE+8t0c/qC0TEAb6FHnOP+1apLbaoSxn/Zy6QR08qVE+ 2sFoa6fuJ1F5EX0w3KFXp7Mhdol6YeUCjUAzGkmdRbuzB41ztrvnuDvcIEOhce3q2FRea/Pb3OZu Hj+lXZvtqJRMOKkUuV4WKfUgF1yOFUgtyOBIf3JsWrXyKK08UGwYcrkxdtm5Re9ubtuiNu6ONoic sIJg0MzX2H1xWVwRLM2RoN3cI7vdTpNz5Jbu3v5NM7fsCIW2LK3vml+htuFunL3F3dZemaz1tbV9 ffI69VFxqBk3T6jJzQHdU7PDjS8cvyOEL2yb0v4I+LLOCye07ySY1HbVdOzwwLX2R5wIhTQqUakq US041YLaUisU9Fr95EdCCG3SrnIaQSvP6sVIo+ljNIxm9ZIIzRSjEaBxEVpIo6k/MEn2+cBiULf1 ztnq9JzVMX9LV4e6uJAVphL+cA92V6Ee4q7agQmTegT3nJoe0V2j0qtVenWEzlS6DgQDbCEwR9VJ W7rcoKdAoNpRMo6IIlWbdPb2909odx1MPtLhAlGbBpjS3mPwg+7nvU1Qb5SKLiCP6tk0q1vtB5rY rt6r8zbO6gCxjTUIVRp7DNCCIdoC1Bip3aOKI9w0C+YGJlC7fxMUejZ19HT41Ye2L+jQxNnUgxrc FTDtkTZ5n/qgYMeWOHeBtjZhKQjeC9TEAH1Dbe0RSjIU4WEdESbpJOj5LDdcmtXlBG5zaFYbiHpE lwrJEcocUImcb44GITl6EanDol5RFnoMAWgQ/tS8GFCXJO/VdXREOq+VLohWgGebekTokW8QK6M3 AHfgUqPaF/i7ALqqVn1abWZ8L2p1rwHNonZaa0kHl3tkb2M3KP/I/SJQ3GWxm/WqjhCjbRyIUHXq yCXgO/VO6O2/273WNegnN8etGgdVMFHyIyDYqGPLUELPVH9ujn4oVdbIW7bo5VPfEOGXXh5IgQih J0SlK+h7EEVSpEPl2jnhhMeQjG+GULMCv7y7rk6fq3sCigQ58ctIDy7lzaF4jsjJydXuYnYJHW9u rNZdQiag6r4P3n8OPg7GlQcP4uD7R946Yup7zlwePHLoSH4eNrvMGhIUotMx5k4PkOIMX0lhYUEV KS7yudMVotGKSkqraGFBGqEJMUoVUcuYvnd8LK3v85C1rmFt+Tz2e22OeL2eOtJkb6HT2NziLslM 4jk9o7xel1FS4564uin9VcGekZKaYRcgTU2BtO8ZXjn6Da8cm8zVHXuMHC5vr/KwtbJIeIP+5sw0 iyc/ZXizbJR5JdmWlKLTmxUhu6G77/okr00QbN6kFK/alrdvGHDE1n+Ue5ZPQOnIhz6CZVw7Eeys p//wbtGIR7t7+w+H0tScV5LddhlZsWL1iYI7XUBOzo3Nbp+3F2eH0kIiknAclaSMVI/bnSbIVuRO t+viUlvjJvITkb26ujrOVl5mLjQDZ8GHLUxqOVKAE4PTO5PsBwsK119w4AC2H5jeGcnm5yG/P/nk buxRM//N0/Lz/P4Or9UambcM6tIp1J3u85WU4shk2XRu6uJ2SMxall9YniZxk8NJrZycWuwPFCUw CV/GTO6qwmEjM8zsGbwPL5npybbw1GCSMdenxIscs2W7ubPMFpFS0Rr/XN+7II9bEeJKQDLTkB+V oe0x/jrItj1JosUiol5y084cX2EvWbtTTMroxXRXfr7O0xsduKcXe0MG0/giu1oq6sVZO0O6CTBA GJC/+ogfhnekHAePFASPgJDGlYOQJu/4D5vJz+sAwebcrnRfsbmopNAFLLGokp5GcVGAuN1mVczj T2S5El9t59KNY8L3uHJzXbh+9Z3LKu2BWn9pZ31m+AF7XuPw87eV1+Vaa9MqpjTc9ERpc6kDn1e/ dFJVZnxGDjc/JyNz/FkTgm11RSahYOxp+E8ZVVnWcE9ysLrvp9xReUnhy225ter7YWP7v+Qk3g0r ++II/3amIP8T5HmkIDvuRi7kiw7T14u7dsa3cRBW7CvO08aa14tn7gwZJmlj7fMfOlKtfgDHDoGQ JT/2nzYAvPImKBEFUBRXUgLiwyzRta5qAUtCGlFZpIoVJ1EmWKunnlF3/lvXjGu/5f3zS2ZPrEsW GOUExWAMNM4Z2bJ2Yk5w8pktI+c2BmVB0nMHEt2JcTaPy9p6x3e334nRQ1PiUn3JcSm+lLTsJMnt d1efcdf85XcvKnZlOvV2v/qWnSppT4GkxSEHWhbh05MontwIKjSJXIkMyB4dpL0XB0IGZXyyNr7k XjxhZ4gfJAw4ouxg+f3SOyKSQ06SHH6QnDzV+dBPD4Rf1qRk9IN/v3NS+Gv/jKvXnn/Roqtm5ZMb dvbd2hwRiPHbv7hj2i0rRxy/vGzZPTDzMCZ6CYwJwp/IiFTZJleGjIZ4Z7wTxpRkl6FHSY/iLHUO 98q4xedjiTGxT9T6LY/P0PoNqyKwM8ROFnu/Ol5YOOXBoElVEcl7/xdNRsSD/GwpuV3mIVkYnmA0 9K1SeUM2GxSB50EowgX4AoNRzRsN4bX4DTU/DwyAGGGTkJiRBmZADB8QbWAYfDYhvE20Z6hrZWv/ UToLOJaBHolyTBffS64KWeVUlJaqyzTiFp1dkvFonUmE7KN4Morv/3ov5OPjE1lv/4e7oAbTRqvg 0awXT90dSh+fqOlUdYjRAfpVrh0wl2ssC5n/h+0OyNJgTsWsaIyXMEQRuNSBtxoUkdfyKyRHQYav ME0GPnarVO72tCy7FP6NYM9MS8tMEsNpoklkDD64q3MyxMRs4FZj/xfcjbwHVaP3ItzalZJitIOE 7UQZxv3keogyYQ2oXbdD13fJWvr1LklNccbu9PTyYNV+HAQPRIjKhwAjCxnK2xI0+UjoxTN2hoKT YvKhqg7VJEUYCDroCBRiS+3/zmNi/DxJMZWUmsHyaU6JxmWzqvdPuCkcMMUgG+SKrvPbp1+3qGLY aVdPyZnk/T4uQRVOvMeUGC9YRnTNW1B84/f3Tenq+en6CVvm1SVLXH1qdqLgyfaMWH33nCX3Lq9I SMA5uSUpPpsoWh0JfX1puUkpCULHvd/esL1vx3Sby5dSGJFZbiN4IEH0Wsw+BiMC440KjieaitFU iKYI0t2QuqVesm2nzSNCAr6BLbvVozHGsx/PAudRAicmQS0bJYdEJPAbTvIUNBfBr3EOBw8dKTBF fAX1Jzlk+I/biikBTXAHy3DELFiAFstyG+W0Al9GYaocTpHSInIspxX6MgrSJPypnFqY4StIkz2C SWAMPojY930szz0Xy4W9+L1YPsJVfDVw1YKyY1xF5Ko9IcHUGuksDkI3Qfh2xQgndTjWNXy1HOuQ o0Dt0IlunHg0iurqCfC8JNQce54FFI+IDMZWi8ZBSy/uHKwtcfCg+vzQP61wshodYJuqACaAahT6 HnblRtkk42uBwJ+elpUsgZK8NtazY38TE7Mi3GDLQC9WoncivQuJcl6eLRgUAnZ7Ui+ZvduTL0kC ZPYhT8n4REm078e5MN+B/q93m9xkdD6syJBTzdlM6qcc+bQF8/IDzJE53jFxQAhU31MVHtXpLCiI yJS50KR+mMuHBwsLzYUw7D3/26ecNHlurLq24ORi90m6U/NycaHq72q8ZMvE1DyvJy9FIuGLuDhH Xnp6niOOhq8hYloQ6KliSe4DgZo8p4TtHE6XHVll3h3JGYmDZCD12KeyWaC8qldTjn0yQD+7sMTo Ls8+3kdxdoXHqMBdUfvE9fJxaDjaE5mHvRlGIWA0JvSSop1pgQJIdqO0stYslRFxRh8ZnZUZSJdM ak4SmbEXr98H9k81HQHIn5AWde2VgxNc7gfNV35iJQfNEXbv/B+0GeNxhLU+X4bbarX8nMHxadRW 6BskslyvKdkbv9Rd6M9MDD+RUmEjHCcmBzzuQJJQmrnVV5TliT9u9Wf64jClUkrAkx5IFKbZQO8o 3uoC0lmyfljDZaP7pgoRAyZwFweDclpxRjjD39Y2LnPkdfVkhmCSeF6CpUjQuP7P+UTei+LBCxjw BBPIM+AJpsGngBJPODPTYPW1ue2RIEtdffykU3mCv/SOQdYmFvJqjuAgl5hPHHfL59df+9E1zZDe sO2ja1vCXzlbNnV1nzPO5Ry9qVtNyTW3hXd0jr396P03H+uZPub2H/fOvXv1iMZ1d0w97d411Q1n 3an6uyBJFFZ0CspCm6K+joftJ9uQGaWSp0MGZPZqvYSQ0b+LMcndOxBNYv/ukGW8NOB9aLZSlZio D/h/dmNs0O6hfgo32Ammdec8vmlRVJlK+Zk4P9C2cvWEnPCRvJEtWUtXVU8sSaHnL75nRWV41sAq uiQY1NmqZmycWdeeLYYb04dP1ObXym+D+c1Aw9DWqN8iuOIye8kzO1EKLKFndse5BDk31u1cddJE W5uXK9XGVapNmxybtkMHNb+1POaQlKs24T+4H9jARxmQEd0biS0ALYrk8VBJ2KaTFL1r4VlnlwbO HReTiCv+dP1YW04oq6prRIZVCC8fKhtnenLsOk9td7XF0XL7sQdvPvbw9DG3/XDP5OvPWZRVUpYi WwrJH+bctXpEw7o7piy8T5WWu6LS0gLSUoLq0M0Rnu02BcxZwn7yHKyLUnLjzqxqs+pFpARMsYGb IGzeFQrZhscIwyFy3htyjbfFlPCADGhB+KEjmt+lMnDHf9bKIC2eQQP0ZyJltaXRaExus1mtuMiX 4fPFJKxFn1ZRkF2QKnErLZn5oezWmLBB2DW2sCZ5zPrJAVdoemVqYW5m/GKjEH6woiahMHfV5rIJ ZSnpolEArWSWsCt/dGFSOH5ABq/NyeCoWDJ5dcuIhROq4pXM8sZAv89NZ4fa43gWviI5v07V7NX9 n0Mw40WNaH/M/o8g1+7xFHgKpGR1lwNJAdXYlSIB5+41l8KvtTLGkspenBuSRiTzWW1WTcasvbh9 sGpRFbHfHAnTTEfUparFbEe0ID7wP2r2hPbiYqIb2dkLsGh5aJDP6CWjz3loVu2K9mFJIgdhmlI4 bklj3ujilLyWmfNntuTVn7G9IzBtXFWCjidUJ4ti3shppf6Q3xIcO3v+7DF5+Ly5N8wrsjrSk/ID juwk0ZXpsmVX+XKq8/15wyeuHN+5tTOg2NMSFJs7KTUzSUpxJVu8Ran+yPUVwHcJIr4vQLLT0cSo FkQMIr5ddjOLi/EhTou3UgcprgIcPNB3UBXUf1nrRDR2wpONLWzND/tCC1EfU70w1UcMPyZEQliB Xq4GrdztqVmJ0rEjA8IULyVmpaZlJ4pqAAa9v6T/c+5B8Br9aHKk948hJ7kcVqQVPHlJ8LWaWgd2 HaYNnrnqmHEKif+i0mB7dMKDjOqfQQb6wZEXvnDOumc2j9KiSHAnfaNmDa+aWeeV1IHlgxf+8erH zqkbftYjZ9GBldHHtSxr8voaF9ZRcbAnbAVdcxeMyYPaovtVKBFczJa9IU+iU0q0qfG4GJITHa12 Pi7qe8eVV+PEoP0QdDuuPMn0fhIkMLh9Q+qo+kFz7TjV/9D2nWIOXYHVynTUzJs8VQWZ5ZmJZgMX 3ijxiZUlgaIUkcfDMC7mpNSSYKAwXicF1G1KzOkls8ydqe5jckKC8XgS/chskbSNTBiHv/+oLgHG UYk2Rn1mQ1CQUGVengRGpiUkVEo2u+x1u6X0XnJ1KC5kl0pbs1vz3CIdshNbPWhwicHy8rhyu+mQ lo8rj+jLkPGf3jowZlCJbhpzbAdGH18YH92+jeZUPvB/YpbsmsLy+sw4/jVygI/LqC2tgAILv2sg ieWFwdIUgX6Cv+JkR0luXrlD4b4jn1AhpSiYk2+lhlp7qpHnjal2WnT8FVuqSctzCzxZVp6Klvjj LvqHeLvMc7I94Xgm/aPJJvO81e8Fnrlg7uu0WHZjTJ7TyVXIjjxkXEgI2IIBO/wiSY04QlbRKUQ4 h0Sn2y1mtbpFc2qr+UQ0qUlFYTDJDhLRciQqF+XahlVEYYH4n+oulWcndrrpwEb3ILYN8ApzGXGi vbosWOJQ+G+/YYqjNLeoPEGKxyXhD+NkW1V5sNQps0/eZxCI5hZUWEVz+MNZ7mwr4wwmCb8ZzpVM Bo5Zs92kmMR7/CBLQA9PwA+odN6a7en7GjhjAs7YgTPZqCVmH2zk6p2y5FT3vrOTkboshJDkbU1m ca1sYFVAlNpX/v4R01vqaPcNuaqu7xOqadDorFZbYUlJ6cAgyXWRQNEhhW+JF21VpYFSp1F3uSXL QuIz4y/ljWlF/vJqmxSHvwyXxxYzfp487c2C8YhxSviZwNyykrkBXGmKlzjeku0Br2IU2LxV9G1U iEI4K7rWDbaiXjJ1N8rIQBW9pD5kMlMb/taGbb1SET5ehIt6+58KGdStsqKiwIjsXmwPJX+Yjun6 9K3pJJQ+Lr0rnRrTHelE4tLTudTe/g9DigS6LdVuwi2pRwNNqh8RMkBh+KchqYVD9mDM+/ZHth86 O2d0avs//s5lRzqXgaI8UK7ubkbW2f/HvdE8HFUwIUAqHuQmFhZHvcMohdMUsy5iZ63qlhVdleDP zs0yl26dNGr15Lzha3evnmzOGJFXPWt0oUk0i0xIGTl9ybAFV3fl/Ng1fFJJ4qjq4o6AQzHpdCZl 1LAab+OihjErmj0l2dXZCSnpKUqSz+bwpLrT4rMmbp72bpyn0FUWKilS99I3gFVC/FKQ1eHomui8 Cq6S/aQLWZCfnAfBhUUoKXZxfF7MeOb14uaQ7GtKHmkaXa4Zo/Je3ATGqGXAGKlusq08Gmaok7H3 P21jkFnLsPzcvkX0YSzw0pmtVs0/REUzL5uaO2ZUvQeMb5ojK1GQIPr35qVK6XV1DZmztkzODB8z Z9cWJuYVlqQVdxfn1+Um4K9WP7G5weyryOrWPETBKPLuWCAajk/PcyhjN+86o/y01nwlvSQz/Ie6 UQXj5sJ6b+j/grroW6g45m/vTEEZT5CV2qmNAzkGDvc8vdixM76JexQ3oHyQRlHELfk52vBzevHI nSFDS+zwxT9wfHOgIHp889+1dNI5TszDYxEHjw0+xIGh8Dp7RdPkwLzti0pr1/xmZmZLbbHVwNME k9lX1FAwc35SYUthUXOZTzZIOq4nyW032lxJptD63Ss3P7upCpw4q9HuTqwIguhde2XD6U1eh88h JGer8tYMeuQVfjHyoXJ0dZRbYnL5fqJ+qT5IloeEeNdIsTwjmVOyY8ICa7UxZLA3DZzpNe4OKS38 6JjvFpGUiJsUWfqG/7SNwXtLg9cshCMDQkd9vsGxXSl9RbBnpTkzE8X6a6fN3dqRWTjzyhnN6ypF TeRSpKMls0ryR/ktcVl1RUn5hSXO9Jh4zWpqBYmapYrd8GH4k5is9RXVNeS3zikuO62twJhemqny rQn4thf0rx8VYT4aCcfHu3J6Se1OfxHXq3LORXPic0hyzrOcqupsMm5BnIkjo8dxXRy5levhCMel BHsj++9qGnJCneCnvib7D0gxKcRMFYNdwi0GO1Qw/BRKiQmR/xCotyNRTde5bHqn/8j0TjUOfD+6 rR8y/L/7bE0tMLdrkNxaTpZuYsko0eZJR/dmefo+Sh7WOaJmdmOe0SDpKeH0csWUlTWrd60ZVrXq 3tOWbp+b9x2dOiNvVDCR4KOBnPLOEenxtnhdnCvR6rAaFbvNXLnu0fWrnzx/ZM0Zt053nrbWM7wt CGs/sf8ouY5fA57jiuisWE0IgsAZu/KyvUIvTt1VMirJ13vi1NWxN5TX4BxtahiIhwuqYZkfKOw7 UHhA24ESfuFNQ887LBEusMGhdOzsozB23kGu4/QC05kT023JGUnSHWrokhB/h5RS4PHkp4pL4+N5 IC3xtKwenzEyUzFw3Dep7nidTq8ze4f5WwVbZmppsC8gRI7sBPJGsDQ10yY0T71oakA2yokZiKLk 8DZ6O30TVaExaAYmUY96rDFPR8vcTYVNzzZRRxNu+uhFCcOMSy+24bQ2bG/DbX8/aME2C0YWk4UY LZauMvpTZUO2M6fmsRqCanDNwbIm41RsolNfCTnHRgwFyEb1kc5OcJA0y6saYSh2vqUlmv1IDk0c /GSxCf/7h594dmXNKzWEq8HGf/n86Sd6cFIHOmMWDCbFao3YL18GA31rtUX3N2IiWwpeQlGJ9hnR N64CddNjwCtQ30fwZWQoNFqit1tNC6zxRd0XTfCPsUjxhYF3Rq8e769Y+fAZy2+bFzS78hz+YInf nV0688LW7BYXTjZbwo+Pa/SWeePGjfKVeeOHNVTvSnLEsznTysfkJdCuvIB9uGvM2ja/RZE91lQv 0VNv7fTKmjMmFXhCHcWuytICm21scFh3hntm45gzJ+YKhpzwTw3jEv3ljrqx9uzSvkm5eYSPdzvT TAVFNl9QjRA3QMz+BvgXBWhxzBcWyYydBdkJvaRrF4THgzePWkKGUG6TZ2Ti6Ihiju0XRXac1K3t X1b/5OMdzcLpTnEqFfGgLfQNKSXf481PkeI95b68mcUxXyGWjrigcer6lvT0mNDjvhFNxakja/se jlEG+wmh6sr5F89SdfbC/qN4Kz8GHCkXqo/tTlvJkygFWcC/EpADn7knlGhqjPT+Lej8iX3on187 5aFVvGrDVckBkcHrhvY8vmrCxGHDJ06oHOg7XQd2B3oKo8gbXVHWOHpYeWSW8DqYJQuqjq5Wo2zB 4FSIApYRFjkIWbrUA7WRke5ED9Q0n7czeVeMfOpjtZ/1Kv3nbIv0gRnAwo1D90d3d0bGq3o0La0A QscZO8dVZaheaQGEVycEYGdz0+BXf1pCSmhEU9XI3LLG3NEnpEKNE09s9JcfUt8gUt8CAjb/V439 Gzn7Z4JniYZuEefVwgxSSp7Xl5cqmt3F3txpJcAnj8onc3qJJzBtQByFpCyHM9smNG0bV9peX2DO bGluzuhY1+wc4Ccx5w4RzJ9T6Fmx3Lxx42z+Sq+/KiO+ct6WloHVCnNQgM6OzkF2vMr0NG3RojST elgPrqa2CKXYIhRhEWYnehoHeBQX4VD0nCHG6P+TO3/ZCrb8uxU8wLLr2/7NCj6JLcCObli/DRAb ccCNIadLZ2inS2ecfLqUFDIYmwbOilIGRzL/5HTpX97xC06XOK5yXe+Zq3tWlg1ft+/MNT0rysJ9 loK26rIJJcnW/AlV5RNKkvDnyx+7sKlmQ++q5Y9f0DRiQ+/ZNUtaA1ljl4yCNDdrzBI1AgxfzSEY 5eAI0FUixCLA8/9VBNhoGvtfR4D/ro3BEeApROCfRYDghE/PGDG80jkgC4lZjjSIBDOax7QFZ6oR 4FFzVm1BYr4aAXYV5dfnWPCR1U9ubjA6Ao7wtIETyA9igrEgc3hWQsvmnavLF7TmG9UI8N3axoLx cyPrhuzXdkeWRteNzwgaMyShJKPgEIIClamgOr+i+kYHbgsJIX+Tz2hxNlpGR/Z3InI/Q/WqD0RX jPDv6w9xAU+1RDT+MLIfPF5Bn5CYFmfJzoWFMmSBuKvKylLkNKdd5DlCmz2BJEF1+TyVOX2Hfr5E lhSM8BmpziBIlsi7RZ+Tb2D0jejzE+chgYHzkLpQOpK4AA58WgrmRPjMXBpSFUGps5RQ7RDDWIkr 1QPrZO0g41P1EKPJalJ3apAVmzjrNwNCob5xEjnJ6NSOMmZ0+k1HOuHvpGOSkPP/8tP+g9MT8k35 /EvbCqY25FklTi8ZRH9oYkl6cUaCd3jL+Jbh3oLpF0zIHhvKiddzlOokvcFX3pyXXuA0+arGjh9b 5cNpo1eOyTDa7JbcnFS3RZeYlqQkZSal+Z0p6TmhKdWhhaOzpTiL0Whx2JLTE3QWu0VJcic4sp0p rpxQB8ySrf8rcim3A1WgbZFZ2mc2y8OykDtXta62kw5BHbvcDalyjCCrmw22hvxePGpnSBdlDizO g5pqK+wrOFBgjr3dlfufNBLR9typQ5aTAxtrLNwjl4px7mBpSvPpDekL4xNUsTxNTI1YgWcELap5 NjAswZlo1jGR8etygvHg+PjGrmnFL0ZiludhifM8LPHnI1FNuLOxUWfQ6Swe4NZadZ+CPgeWcGF0 RYsZkU0KB5kRMsbnNmaIfGJj9IUpsGVDthO0DW1V7WsRiPJLqp9q72HISU5J6YldiFdUhebKsoNx a522vsWlDR6WdJwXTGB3aWz3IX2wXZt/0VwyQAjrR2pGkIyPUSInOnQXjDsndsa20+Ry9JLz9oYs LidzuXtJZ0gKIacrs9ElJjWKo08c6STZ3x96pjOkUnTd6Abe2Tlh3WzxttLo6QbdhSnPhb/jzRm1 JcW1PjMf/o7psJiS781Sj3xfZuwFKqcEfd5gkkC384rZqhx/Rz3N4SWLiWYkOBUGg+F4g1nqW5aY SC6TzAaeE4yqh+OE8W2F8QXRJSdOLbZopxbZIUPkyMImSr2kO2QMqd8BoFbRGURutwhO6B6V5hSz GtVjiEbzCaflpPGrRz3qMQaoD5UPcSfOXNUjjFPcqx1hxI7Co8c+pfH0FAcYlJ6vxykVebmlDiN3 552cklqUnVNkx4YfPzXgpPL8nOI0hd9+C5WScjNyim1Y/KAImMNTgyzg4eFnBdlAecVqxvvwTXGJ CqNMFsJv4Wy9pOc4JTEhvFCVgPDVdDdwyIPmR99bwgaDgpJAk9fsDXmSnEKSvZesAFYoSY7GRCG+ UWjmxqLmmHf889M99Rsm6uClU1aH0btoRNxL432+DOwrGnTepYbC1gQdOXeRYVxLZp6d6FbLFj58 ULaXB/0FKYruDfoUi88p9Zcn68MHEq06k92M/SxRoUVur0VPpURb3/2kO8ms11u92ntZtvAf8V3Y hZKRZYcJ4ppLd8WJthRkOnQQ1utz+Xle7SsvsVkY+DrLXfq4FMtmndmenpTqMWF+nSm9yOsucBl7 M0dUlKY+JSh6WEMmESfckp5t1ems2eBb3dr/LX6UPqx5kMk7EMS8vfuENDe4u8YGVH2wGh5ZqL6H M9TXMw8p40cVV0lWVolLkiKpMrRMrdllHqPRU5btr/CYTJ6KvobscpVQnp09TE2HqWMfhi8jZaQT GZF5J9KJjwAbOBSEqPOg2gemvX4YffGYlFnt4a5EqzUR3yqZJR7/WBEIlpcFBHsmtNT/U3gbR/pb kIyMe5BO+B6mtPoU7Vg5Em893gQibKN7rfHhrwv82QUFOarXsDC8naTwlyM3Sn8SJeGjoFpN+CfE ECUrd1kc4vmoOoiDfW8dUY/DMAMDEGezJkQP+gJU2zOJKAximzBpciuz5mamZCYbacm44qTkkrHF RLJnOT0BO+Xbnw13v/teeNZzJptJz+lE3fw3335v2dL33j60gNfrqE6xQn+6oT9x0B8X8qjvj67Y GWfh90O3jBCKH9tlSRIiHVK/J6X1SBWTyGljUWlJXHERyfBFVZk1jsQlFY8tocbkzJSsXCtrmzxp Ik8Tc72OzCSRzl9Ekpa99/ab86EjnB66dABvf+9dvP1Z2apAZ/T8G+E2kJ0JYIFe5z2oCDWgT2N+ VVP/U/uMpAU1YX91L7l/t5SSIhU/Ss5GSD2uUq+o/1qohI1UqohZ3opeXLUrL4/3RYO3wRuL1SFD fEedZpXqenEI3O8ZJ4KQ2MtioMgOdfrVnV7tpbFOf/Ie6ICR/q+eAMyERwx2qbihLpRuiJsfjYHo 65Ur71syZfPMKq9i9I858+E1vpaagFHPE6pXBMlX0pg3fulIJ7aW147JmXlJR3Y4HJdZE0wpKcqz 2IOjgoH6gB33zLx7bX1Wy+lbbp86+q5br1gcMihxsik+JcGRZRNkk1Q578LRSkqCXDL70qWFLcXJ AqjOhZdNcKdXtancvgoh2sPbUCD2nmdINmRhQybWZ2Ach/O0Y0eYmVAepiirl1y5K80umnv7P9gD RHN8XC9eHzK4W7OMJizyEBX7T7yVCVwpqO4DJeE/eKBQfYcFPFDUidU9l5A9KxNnwXMGPUp9wi9p T+V3Z6Sdzs7Ye8exw0lwl1hkE7LUG92gMGtWuYeJiqGvRK+ANwW5v79uSzUzolckbOWN9gyHL2jX v2kwivzslAz1u3fa9/hE2rRC5M3ZPrvDquh3czzF4N0ajr2pfokDo3bg3WO8F1XhuCjvFC4Hc35s qMCGciyGgHl7VakOYWsv+eveQi/8ovJHyV+R2P9FSFAviSCJYnYvXrDXXFbudJYnR+Os5JgQJsO1 kFxoZYE200Ck2THo7euCiJPv175XVn5EE3j/kYMRu63KO5reqXIrORR/Uu+gV0b6v3xyZCFEn3by xJSCrhtybswGXjjUaS8oPcarb+rYrc4EAzMlJnxY2xowW7KqsodNrQ/IBlnPUyYk1s5cFZpz7ex8 ++gty6/FYcEssYWpWUmi3pbjdgW9bsvXI1fMGOdxDctJTPM6pJRgus1hM9u9bnvh1PUN1eu23r/s RikxC/STBzypT7W3HALo2+jsJegCWOfHLAXrTFinYCZjUVsAojpTecCugMvUS+btzuA4lPsoMYC/ +U1IhovW5MDAF40m7eZMJsHfi+fsDrlahdg7WqArCvv8BwpgOcDkqIazQNuC9Gu7kOr0lGQYcUYA Z/ixLwVnmHCGgn0yPkWftK788idG5iX6mOhPZFN/YAe/eGCi8IlVY8Vu7KKfWuJWSGl5PvV8JWxW rEZQ8uCPXcnb/TXBwgZ/wgqTLbyAhO/Hk/HKwuIvYt74F7rEYIYz6EuPJ781yAZOffH8+Pf55Ly+ B1W90wX2oYdXUBU6HI3n+BLMF5+0aEp7ibQnsyCzQEl9lBzQjIQ2E0iB8SsV6uua6el8SUxeS3rx 7J054w29eOa+eLs9+oW4SQPvmWlfCoy8wBmxCv6BoDuySGCFZJfg7FIc7Yq2Qv6bx5y8IqIWgg0J utXdQfdJ3z8DDyS6u097Gs/fv7xy0aRSM1gFziDphazartqKGTWetNDcxooZ2amJjnQyxwCxoCUh XOSu9y24Y0kF/s2CO5dVGm02Y1yiL0n9IrItxWYvHleW11yUJKVmkIJMt5TkT6ssCX/JkfwZW1F/ f8xiE0ZfQpF/7Z/vbV3b8e6wGcbK71GiXvtnvPZ/edYravryu7tXH3u3b6vhK91voa4BVlTk3/mG T4bCCB8Qbj327tHNhq+G/o8DRg+nnCjh1xDi3kG2XwpW1P+mCu4stJWrRGNPBV5EWzWkIqMK+hna CqgelFYCWgATAWdE6VvpA3BPImr8GSSgq6hFJpKOtpL0/imQ+iCtAzQAxgCmAjYBPR2Qxr0I9e4C Z/Cu/oe5LugrgM7UsJwui+ZXIQu3AW1lYWi7/hRwARagcf8WyyOAdsZxNfAsAL8e8mdDPoLT1JS+ AGOPwAFwD5R/QNJg8OXokl8Kbj+y6kLIPxTcfOTiMpFpKOibqDCKNDXlRiHhl4K/rP9jFVwZ2kxf RlNOBe4KtBlwNncX8qmgl0Hdy5AnmjqjSAXkAaqj9M20He67CbWfAps1PI2KiAltJqb+LkgdkE4A jAC0AeYAzgS6HWDllkC9BeCEL+i/jePhXgA5ruF8KkfyVEI5nAVtZg1w/flT4FrAu2jiv8WnEbAA yHIftAvgPgCaF9IIpqgpXYJqo8AANlA+EyUD9NE0mXsAnfeLUYyS2RbkHwowjj56EIk/w2WoKgqr ln6LRg1B6SloGlhhBFwz2kA7UEMUwwblG3TrAXrUwJQIoG4z9xxgK6AZjeZ0qOmXgFyIEtkzKNFg QIncq4PyS4bg7CGI0tneIXhhCKL0k+q3gIa9elDbX5y4xlujqEeJuukoEeQ8eSi0sf4cG7jm/u1c d/9P+Ee0EP/YvwbSJEhnAUoBqwCLASuArgds4ChayFWg04nY/14Ui+nbwPMo1DqAArJCS6tJCkqg 3WgDO0d91kmYpaVH+6/R0haYj3+HKRGwJ7S5i7XTTP6ANkTQ/w2kk2k+aoygvx9SFCvzhyLglqKN xAz1n0M2chigpm+hZN4ENuThXwY+hGy6LYDMXwbo59ohmH4Kmgb6IrLyPyD3UNAHQTe9BGtjKAKo PgqqpRPQXFirE+mdaBx5EpWQ79EUUofKIK0gz6MK/DpKITeBLjqGpuB1aCw+r/8d8hTkV4EuWAR1 fwJ8j8q1+9R7EKQVqBIfhfvgHnInyF4ycpJ7AXcB7ypA980DfXYe4FbVah8PAz4h839G+5iWwHyA 7qM3arTrALOH0K4BzMHHoXwp4ErANRp9IWA+HQ9lI2AxQPvfQY5fBFhMHVAeBThdo90GWEcToJwC 8Gi0ewDbyXbozx2AezTax4APCPgY6pfqyB6o+wn4GxZAvXY9BDBiqAWyjLT0Y5XeV6uCLEZzIe0i m7V0IiFoHsmJ+Sv9y1UfBPq0lduO/BEfInyzatMi/kJ4nWqbI/5CeBv4BmM1P+AplBSz9/Rr1BKx 4f1G9R7VbtNnUJNqgyP2Mtyipgx4p9pTtgqtBjvfyC8PfztgF1VbGAd6XkGuAVsGunXAbv2AJkbs Fvgupv5WzR6lIXPM7tBtaPKALbkpYj/oOjRGsweDdDe/H/oAep3/Azqd+wjqqngUdKqKTlinraiV Pg79Bs7Re0FnA8gXKATreYOGaeCPXIY40oTWAhBp6l8PSNX0yqfQNugP+luQdQvYhTRUN6ATbkdO rgrN5qaikXQErHMPItwstDKKFYBM/jpUA6gD+TLwn6FV/BPgAwLIRdpccvQ7ba5LiAetH0AxrBsT mqBCm8/l6FJtPs+IYi3M0UwkDPIZR7N7UQV9D1XxpXAtiqg/OEb19WL+Fq9Hgi4bCdo8w7zqcgb5 cUJknlU/NeZ7cd1Ir+HPoBdeisw1+JpbeR3UuxS16HKhjdM0f1Zis4C2GDAWeDMWjdWNhfx1KAT2 QeKNgCS4X5WLFHShJhuuKCpgvvdqNjjmD6XBXObD2mvieuBaFFEfp031XzgJaCq6EdXk5aaoT/I2 4NqorKh+V8yPeAvZVMB8J0H/NXkB+djMXQ4oQOMZ+EXsGq0dO/82pIlw/19QJ/0r+C8XanWauC0o FeqnAh8Rq4XnLoI6YP+BZ0iTre9Br78VxdeqDepfzN0D+kq1d4NsOP9n8O9OQxXcSpC9lWipmkZt 4CrVrqntqAAfJoGVoDh+T0SO2ZSorWoEjNTsz9oBn0O1M2nIoNq6Ad38E8zZPFSj6m5uI9QfDdcO ozyWDG2Ng/JqkMmdkWfRjTDfm1ATY5A/Dn7S4v6fVNvMjUBmejuMLQqQ1atVkBvRXwA3qqB70ApA mwpOQO0wP68BrqDT0WI6EdXDvNk0mS5GtxI3Ws/vQGcBbaFGj6YwR7Ojfp6WRmnJ5Glo72l0bywF ueoAXBtL6VJEaDXYpoN4KT2OL4ByCpSHgw8wTAU93v+9Cl0VOncwgPYTjPOqgTW3AfqxAXWT69HN gMlgk0oAC0gHWgyYRVajKwFz/lk9qvrNx1EXoBswiXsBtcKcTYZ8GqAcfwC29Ry0lgf9z69CSD8C IV0eoC6SsgfRLSpAVy7gn0UF/DugIx4Hnh+HWGUvqgS6E/KNkLZy7Wg05O8F1EFZzc8CubBAPpX+ CeXS7WB//wFreDuaAOBZMSrXTwddcRyl6KpBlktREsjlGPIB+GvfQL2vUS3o/zT6OcSoNWC/n0BB LoRaID8K2iwHXAVoB0wEJAG6ABMA4wHDATUgw+3kQeD9rWg8PR/i1zdhHW9BM+irqJ3OQF56CPTT H0FPbgc/ejvwYjsaB2gDqP2dCagHjAKUqfhZ/+p+cf88p+ofDYJM8CiV7EZVpAf8kSPITXaiWvIp +HA3owCUKyFfQt4GuXld81Wa8fOoBTDqv7kX7HoQ7vWSpSiPrIT7zgBbdxrKJ+tQNumGNi9GaeR0 kPNfWu8P/QGag8r4CwBXAWqj6RTAlYCjYG9U3IyG8V8CDqNhTAc+3A5UB/k6finK4X8P8rABlfNn oZG6IzAnx1ERoBQwAZAOaIvmx6syBpgLqAdMVGUbEOQ/hxixHKWz3bAOR4MMYqTAmgqr/obqB6g2 k9WAPpgHqEclsOauBFwA2KuC7UOr2D6sj6XCmehK5kPrubkoE78Lvg4A8lH0vwf44ET5lwLfM2SP hv93ezgD+y2fwbx/1n8Y8Djg/QjQSLCpOYAL/9WeB0uD9KpTILovwWynxkl7EQPxZf9LgBui6W+j NEj7XwS8EKMNsi95nA74pevfC3gnAtQE9iVFtTEnYpr+bwBvAP4WyaMGiEFOiVhswAd+hulqOjge 0OLZubB+B/ZG+g8Dno2mh6O0vwO+ieJvKm2Qf4joZf33AM6NpgA0AuxBCmDjoP2FKkBiNC1TafzF p0ZsT4DfcmoM9iVPyJ0qc/9Erp5GcyEGi+yDlYCPswd06rMASFWfSY3pVNulxq2DY/LBcTeNR3Yq oDXUCutsIVpD9gGuhPJZsMbmoTW4B8o8yiTfQQpl7ga4pl6/DXzm7yIpleHahaBvekA3rkGnq21y t8E9L0J89QAyk06UDD7mcRWwFqQIwO4D6NPAZxXSyVBjCBW4/2SAze9XQe4DmxjBdSrwq1D/PnTO SdgIscVGdBr19H9JrgDew3OBnvD/tHce8FFV+R4/c++dmSSkQhKKhIxIFZggRTqGFgKhBgbpMEkm ZCDJjFMIQSk21sVFEFkUFWEVVyAoMKAidsXFVRG7YsWGHSxYCXPf75z/uWEyBMT3dve9z+dN3G9+ 55577un9nLCgiVhvcdJlmHydxddPYjwGN5AdY+H3AGbjJ38jwh2Jk/dxZLjp8P9qaAbgz0y9lYCb k5L4SOrcISyeDzwNRpjRaCaWrplMw7lvxnc8XE5dfpH9sxz1O/as8d5Yr8F+o7qTXWN8b53O+gMW xSWWVzAHeKWeXa7pA2YTfMbacNgvLIejWFlrQTzrxTGtR58JYHeBIB7rZ6DGYywFpllsgKCQpQqe ZhbB4yyOo7bH+BwBY/pqrJeY1kKSqX8iaMEa1cOk65HwMIw84nlhnox6z9cuNyEfu7OLtHew9uH7 3p8J+37oT6dh/BoHtw51m/6G2Y9xYy/qbSnWLWUsTSvB2qIl+sxheMf71bn4vpXYz1qhHsR8FetR rN2ai31hvvbke74uuY/7FdZq37E8jP1j4t5nK+L6sBWWjmivWJ9YvwLj0G7R32N9NET02w3tH0fs 65s70n475kl+o59HGCzuGfKbv7Omw88j1C9gDf4NjSf6Ab6Xj3X2NoQ1Hd/1499qV+qPIx0LEE4f HhaPr1ibX4Bv+2BM/pp1N8aj6PFFjBGHMB7m6W9jrpWmJeg1mFv209ZiLTyTpfB1vPq5fqPyNFOx 7hqrrYfdbmYV6eFnEwaR5xERIMyFkqvAQLC07vzBOG8gMrgiXRgX9cXGWULEeUJPMBuU8vWmwWln CdHpk+cEEWcEK6LOCC75I+cD/Bwg8ixA7P/LM4CIPf/u6irMWT9hjbFuTxNrZaRBewHh/oiy6I81 2zassb6A3WrWUez/zdJPqA/IvdwhfG9W/8VSSXuDfO9AuRLrmU8w58Az5mti3xBr3TzMF8W+n8b3 J/me2evI4wBrh3waYK2GXwrmTpPgFuM61oROMV43tF9nxfwsYg9aC+jviz3XNzEfl+O8ugXjZiN9 HvdX7sXCX/0JmjPoH9PcIHyQ77NiHnCUf4M5ZkB5C3lQgLbP9wS3sAuh49F+C7Rs+NkXcTbmHFH7 pHwOoGzCeFWL9B9E21nPCiwbEHaR/qFYo/L0LkTbP4F57mxm5vD8U+NQFt+jDG9kPflcXm2LOXUW W6ceYuu0XRhrsN4UYUbs4/J1b4N7y/X3zPONfXMj/ZI5WgH6rQKxTu8pcUfsJ2M9znxyD5pTxNfW BlH7yafvIUt7uT/sB0nI199O7Q8LVK5iD1igv8+R5Tta6lRjXzZyb1bsxxp7snZmknuwcSLMf+ib hRv+DnmmpCEMXrd/YC2UX/WbtesQty5I4wB8cxx9TDHWNEdZe3UM6uk61J2fUCZ8j6YT5mXPs1yt I+KwgTU3jxX2gzAfK9JeQZ+9FnOXyfqraFuT4TZdWcDPj9Dvmdkyyyp2lbYf7zAvs7TGHOxhfEtn PcPEHh7m4uJM50Oan6m/yjOY5agLy+H3tWxQnMqWxa1EO9wF/5qi7zjIllnL0P4wX1RS9eHa1lNz u3oYZ3LT9Y/qzsrMKBM5d4T/zPCbv7PAf22jPNsarj9D81F9PeIzWkkNhxCWF9/Fi+/b6rciHW5t m/6ziDfiK/ae+PzPgrUR39+U89no8zA+vxTvnmcTFb7HzPc7urNuWm/WCn4xfmaF75qJ/a17xTkZ Uw/oP4i1cnes/7qyjQhjo7aFlfA9FmOPVbIg4oyxHvCzI7CDcXxvDeRFnCkuiyCeK9I7EDiM88GI M0IGOoBWfM/N4LTzweh0G2d/p879pked+3VWPfrPEWd+5531zA/5FHm+J/byjHO9lSxFnuP1FnvG l7ME7sbIe5HvDv12xIfxOJhzeJnD3Sp8g7qOfBmjJcBuCeYZnH1SjXk8N68lLPdL3pBqzO+5+RU6 n0M5/u55jrX975/hoO0uEn3bKKyBeN+HNqteJ/s/p+jzxnPMbdAm57LBYn9xLOiF/tzBErWZcDNS kK++xhqrh2FH/csi0WfMY6mCkayan6NhHthE7c2aKBrc1Ig+r1rCz+32i/6tDIzAGvFJcA8byve6 0c9lCQ4Jpf5vI6sGmeqX8JeDPs90VH9KydOPCt2g34f+rzdop+3E3OZeVqgNYgGjvxP92G6WjPjw sXIYH4/U+wDmPCBfKMYCcxfUb75v2gt92ETkzQyEvUnfjr68pdqf8flJgfGNZTfGpZOswDqNFZhb oxwsrKl5A8arIpTZcbZQewzuu6NeHmOXajPQj80E7dGnVOlvY6wdj7qToD6M9laEulKE/JyNOoQ8 R97NVSoQ3kdoL78xm9i75fu8m9mlcD9UW4769Wc2xtyBxVkeY4XqQ6fOE9R3xPqxB1imOlDHl6EP 9cDtx3BzM/rceNSrfqjnlair01lf5OMg9N+NsQ5ZhvljghaEwg/zJuZDOTcT68GmiCdfZ7ZHuzfW mQ+i/f/eOnOFXGv+ykaJ9SZfa8p1plhj8rO9bRhbfkQd6yzP+eQZn7KH2ZXLUZ5V4HbWjJ/z8TO+ eud7Q9mFyhHoETrrqzvfewdpLadzPuUe2H0P82LUy3dZL/Vl9MdPsRzhHz8XlOeBdW6+QX5KN5bb UG8/YMnofwrULizZ6mfp5kKsQx5hVrUU864B4GvQBXgBnzd1YSUot4staJNKOer+etYEZWfSPsKc EG1G1Pn7WIGyGWPh/WhL81C/hjO/BfMFjB/GeO/HuDxCLdefwpwyU7NjjC5kw7Q9mLu8gm/mgjQ2 Em2X2mgaG6/MZ/N4e+ZtQXsWY/31LFf5lI0R56aV4DDyqIr14Genpif1E3Xnpz+zdFOIFSI/ppt+ wfjbBWuvR2DexaYr+ehjyynPVaznwVS1NcYN5L36IPzri/lVAktUmqCuXor21ZUNUr5ihcon4El5 rnoHeA7ciblvJuJ0gvJcnNki/00/YQ2aCHYjnPPoPNa0D3P+Iagfp/b35xprYmUd8m4dm2nsKSK/ unGU8XjHz2v5OS4/Y20vzdyuD+Z+fWifocG9hq0YF7eym0AmP0MW6eJnwzycVLY2Gu3S+sBuCPRM 5EQD91zbRgP7FtDTgP1gaENEx+NM7gafJR4N2beDnsb/NB5n8fcC6GmcJX4F0IY413icKZ/bQE/j LPEYA22IevFAvSri8D0r9I3XiDOprexaidj3UTawUl5f1SexFvuY9o7EWdfWuv0hsVem5eo/cVSF 3cLruKCN3BdqzF7jiH51D/pQ3kfyeryfDTAdQt2PgJ8dR1K3Z9UxijaS0+x1XXAc5kgM99m0Pyf2 /g7J50jSo4jyh+/9ccRant97nIR+ztAcrFFywnlcxZ4CdzMP6/bHxFo7EWPuWLH2H4l5zBqMiWtY f/SdjbU3WTvLMxib+7LZ2kD9W3HmyedApHbz3zCmrUafz8fR/fDnKPrjlzBnGI61TyP9HazVa7RP UGffxLhH9/FypQ7AfK+VlhDuzlXMi/chThNZN/NEmAOsF+ZVYg6rHdLXaIfCY0A78A2e74BOAV3B 13geB9rVP1MQ30yWbr6Rz3XfWDZhzrFJX2PZFJ4MuoJv5PMU+fy1+ll4r/ZlOADKI8zzYJ4DZpgT w3stKeEAqDDvD78Y9fwCnsvAdHn3w3hXjncHop5fsDyFddZT4b3WZ8IBUG5dFD4Q9fyC0jq8V20b DoAK5b3wgXrPrcX7OWCGce/U7A6/b7kYYVwcHizNfjAU5tvATG0w0tQhXGS+MRwAt5tv1C/AMwMt jfMQs083WwaGbwRTzT+EXzf7wrXyeZr5t/BreN4JFtIdFOH2CjAO7w7C/juYl8jnF61D2QjrUN0c lxq+AoyzvhA+aB0a/g7mJfL5xbr7I/9GjLsoYFiEuY66+ym/z4w/4Fa4xzy/kTJSXwauBuV4TpDP HDdIl8wGx8DloJt8V/a79+X4vRjOqfswZyIOxEfZTQCXcbNxX+bfwR+53/tHsCSCzLMjz7qm8LOt BsyeqHX5/xjLSDDl7GCu1hbr/uuBT94ZbhHx7AXJIAVU4V08dCMYDEq5+9+7D2zsA4i1OO9r/81a dxfsX4RlLdh4ds6lzz+Xfvi0fswXHl6vH/OF885l7DiX/vxc+sPouYc4Z4ucZ0TOLSLmE3XzB8wT lG5svenYKczXYZy/nqWIu4V/Qj/vYSusLegeG9bgK7RdYn8u1dwJ84Mi5NkreD8ZOpzmFafuIoI3 2fkWM56fZ6P5vTSwwjKAteLwe3D8fpzG5xuTsYbn+T9D3l8bS+dAxjmP+hkbxs+kOPJOXSNxNmPc q4s8pxiL+YRxP44D/7CmW8HvwYn07Gc2cc5QwTpY/sz6WxjrqF3MOlpTWQI/KzK3Qxk3YYn8/Ms8 FH3HA+ibrWJfZrFqYanqPWyxZaC8K8bXnv1AU/i7Am7WwPwjW2w+Dr1a3jPPYvHqQXwHNAVhH0G/ OhBzWotgsdnMMgWfsq5aqrj/la5Nh94B4Mb8IUvheaX+wJLqzhSsrGfd3pK4t6afFOcBdHet3r63 ukQ/Ue9u8OesHb8LJ+6Y8fSEac+a71lZ+rECs59dCHcXWrqydMul8GsG/LkWaZiLuX4l4varuIfH RJ9xvq6jniyztJb3Avme50BxB5BpW9h5mOstM/fB+xtg97Kc40XcE8WY1848FvNHF9LSDUyH+w+Z jcPvFfL7hlouvt3KVNFnHpH3Am8S+4N1f+OBvnkMynUcR95RVMUesHFP0biDyOeZR9AXyXuH4u5h NzaG33fk9wuhTJtG+5ZIY29zLViKdDVlIy09mGrxinnoZG0Z0rAW4+FqxIsxxv/SyVBlO/+n0NDG HLBLFmt/ZlrHIv6oSX8XtJV3otrwsxQ1rP/K1+T8np3pQdaBr9W1Z0CIHVFr9d+UVawv2ts45Jf4 eyX1AdSlZDab7/uZr2Y263TU7/PQDtexzpYsrGmuYI15O4w7iv52kX5Cexjl+yEbof0GP9sjXPjB 759Zzmc9zAvYEfN6Hg6bYDWxR8Q9uULTm1ohe0xjWBsx06OEYdZ/sqax5agXl4jzymTo31F/J+M7 K0vm+5FaH9SZTnqtOp31VF9kFm08xtG+qGvG+orvJUyMYqvu4miHWZ71ONriR/rP1lv0j62r2STL JWiXPWHXgXVEf2OzbkZ7+B5j9nxWxe/Axj2Hcn+IjeNuOVobzCWeZBeg7i3W/oo4jUU+KaylZS/q fCn6rc/YfPVX/VX4k4/6kW+ZjnoP9+pgNsLyNNr9T+LvaRLQZywzF7KLrAx14y+oa/wus5e1iFsI N+0xtjxNiHq9X6xLDyI/plEZh8fzv1VTprC7TftR/gtRbol6QcJGtlt7na1WXmdXc2AOQb3c/vdg rDaf6tDJpkZtMu5W1K0T29R/ViZFjAOPUj6bx5n2YS1YbLjlbjB+tIJ3r4H3lWvQRtpE+XkGon/q 4lNBz/zuvLhzXyFZLe/lD5dmDsqf3/fHzzXgEuQf/+cRgtGY14QrwY3mNXoG1qsayKC1K4ie60lO m29J1AP61wT6ocj5RMS8Afm8EIwFU4kT/G8W0JRPoHxPvE3PJ2ojVCdqWX1OnCRO8r85sBMnE4ja RWAx3n9M1G6TbAVbZPicHpLukuGS+ZJh/G8PouDukeu1y6GVMrzvJDeDdRSGwAvukvHL4X9DQZyc QO6FPz/wv4+QlPK/ywDvSeyUDh4X4ZdX/o3GPGm+DORRntZ+Az6TcR4m/xZjM/l7cgNAL1p7gsIW DJYsjgifsxJMiGK1/DuSWyLsHse3LkmR5IhkvKRYshQsibCfS9R+QZx8QrJccqlkGlH7dBQ+0F9i koyRNJEkS0YSJ++Hvkx5UfsTdJTEKPMcovaAxMjfkGStLN+7JZH2/K74BknvKAz7u2TdG07h1m6K Yossr62SKH94XRH1ZcOpb06aJUlE7RAO2nAR1gUJklb8fP+0uwPynt659JH/TjCW8PGuGevBMuRf I/evj3LrH0dFPTZrZ+Ct+lgTzo04lEH8Y6fTKD2Ca/77JLZumCTUhZTkM3D8j5F6lGgMf5tcU5/0 2obJ2FufzBvOnaYYBZstP53mqLstFsSIcWZajvvjZK1hrNUT50b2L/U5f9W50XrT/23a7Dg32m47 RbtJ/yLebpgOMxnrWH5mLiz8Y3Rae4rOa+pj73tu5JT95+g6+9y5KLdhumF+1X1wjBgxYsSI8Qe4 j+gx8D/Idb/Dc/XpORV8GeNc6bX6/w69X2Ss73KiP9bKA24H22LEiBEjRowYMWLEiBEjRowYMWLE iBEjRowYMWLEiBEjRowYMWLEiBEjRowYMWLEiBHjfwUTYyntTDaWyh5lVqZAc9hsxhKLM25nmvin SLoorfk/1iD+iLmE/uEG/ufMLFk8cbPC4phPmlVmZwulWWPN2CppNsO8WZotMD8hzVY2n70lzXHs QpYszfHMZhojzQnKRlOlNDdikzTDTSK7UDPikKTcot0gzcms3Nqu7p9R6WZdXff/H2217pNmhWnW 56VZZU2tB6VZY4nWt6XZDPMRabbA/L00W1k/a1ia41iGdZ00x7PUuD7SnGAaFzdCmhuxTvGGm0SW EW/EIck0Kv6QNCezixu1RUxMWrzMZzJTPpOZ8pnMlM9kpnwmM+UzmSmfyUz5TGbKZzJTPpOZ8pnM lM9kpnwmM+UzmSmftzAb68a6sovw28ZGMzcrRiw9zA9KWQB2Q2DyMa/47YSNG6ZKxN/GBrFy/Gdj hbCbw8rwzi+eXFAXXM/H7xK4HILvyuGmCHZuNhjfl8P+9LD6itAi3drqXE8SPvpl6DbWE/72Qpzr u+9S5z7aH7eImxMERDpK4F8F1MfmwY6Hz9+UwbbhXJgjnoPIB8N1MbQCz07Exy3SbGej4KKYdYCd n3WEmxLh33DxrQf+nDlWFXhfItLIU+cXvvqFySXc8hBLYVsBczmrxlMVTDzG3E0QPgZgz0OjeFbC Nzd+zxG+eKSvAZFqCpO7oFTwMCl3eamOEOkthQ0v7SDsXeILn7ApF7EOyHQU401n4XOFsCkXPjqR K2RvhFIBf8pF3fHKWFbCpkKESn7ydAYiYsBD9Iq0UM0z6h3FnYfkQQ7YkH6qezxWVBrFIv5ukeJA Xc2kPKNQbCLulTJdVJpFwuWpGEemiOfaAvEdpXoenu2n1dX2wrcK4UO1yIegbAOR+W3UMR56lchV pywXn6gNXClEXtY2WeMoNRTHOdINbwsLpe8BpIJKaH5dKTlFHeE1vKJeuowaXYyYOEX4xTJ8u8ip AELsi3EkB1/z/+yiztVvD3ZZ+3NgrhYlNEf45IUP1bDlPpaK8uIlWd9Xw57XZsq5eXX+TRF1l3Kx WqTeL3IrIMrZL+olfW0T+cbriEuk0C3CcIk0FolvjZwexhxol4Pkt76IN1S/SkSbPVVnqkRYxaJO NRQuPXO3xcjnoGi1JXVlUCLe81pOKTDy3StSWilznvxyid+8JkWnm7+nGtsBX/GehLfborqQGopV 5Wk+n3senfLd6DVsst0HRLyL67W/09NutLboePWLyAGeEkoL9ULGiOKr69FKRJuuFG3becaUUj47 6+UptQiP/E2pInNQ1Lyg+LJEtA+eGledP9xluWhjZyuhf1W7ONUmckRseBugntEuysrLFmyxdet6 UTfbaHexz+P3lAZsQzw+r8fnDLg9lXbboPJyW6F7TlnAbyt0+V2++a4S+xBnubvI5x7sKS+p+6qv TdrauPUkl8+Pz2097b26Sfsu3N5w4/bbnLaAz1niqnD65tk8pbZAmSsiCnN8nqCXWxd7KrzOSrfL bx8VLO7g9He0lbhsw30eT6CeVxWeEpev0uZ3VvptiKS71FbqrHCXV9uq3IEymz9YFCh32eBnZYm7 co7fhpj5A64KfFlZgiB8lYiu3TYiYCt1OQNBn8tv87mc5TZ3AGEU+zvb/BVOZEOx0wsz/6QiWB5w e+FlZbDC5YNLvysgPPDbvD4PMo/nHXwvL/dU2cqQezY3klEcsLkrbQGemYgZPrGVuysRFpJZ5J4j PKaAAq4FAXzsnueyG7na3m+rcFZW24qDKAGKN8+xSleVzedEWnxuJBsfOitsyDgEAx/nwMbvXgjn AQ8SNJ8nyWmrcvoqKCye0cVlTh8i5vLZywIBb9+cnKqqKnuFUQ52ZH9OoNrrmeNzesuqc4oDpZ7K gF865eZSJyI3j7ub4gkiitW2oN+FqKFU+GubEzni8lW4AwFXia2oWkR6mGPUILz1iQfkV0mQcqaq zF1cFvEt1F1ZXB4swadIQYnb7y1HADzuXp8bDorhylUZsNuMsD2VyNgO7o42V0UR/+iUV5WG4wZj JJzzqoFs8gd87mIqv7rQebEZfvUTEejgRiioQryh+HhFK/FUVZZ7nJGBIs5OiikKAsn1ICj8Dga8 wQCq8Xx3sYu7KXOVe6MSdC5lIUoip8RV6kRltDv93gXGWgs/ejO2jDXwszNe3aP8GmqVlb1H+SXU qhPk51CrzpCfSH4kOU7vfqCn70m+I/mW5BjJUXL5DcnXZPkVyZckX5B8TvIZyRGST0k+CbWKh3xM Tx+RfBjKagw5HMpqDvkglJUDeZ/kPZJ3Sd4hJ2/T0yGSt0jeJHmD5HWS10heJXmF5GWSl0gOkrxI kThA8gLJ8yTPUbD/JJfPkuwn+QfJMyT7SJ4meYrkSZInSB4nPx8jeZQsHyF5mGQvyUMke0geJHmA 5H6S3SS7SEIkO0Mtu0F2kGwPtewOuY/kXpJtJDUkW0MtL4JsIdlM391D8neSu0k2kdxFcid9/jeS jSQbSO4gWU9yO3l9G8mt9Pk6kltIbiZZS/JX+m4NyU0kq0luJFlFspLkBvJ6BX3+F5LrSZaT/Jnk OvrgTyTLSK4luYbkapKrQuf1gFxJspRkCclikkUkV5BcTrKQpJpkAUkVyXySIEmAxE/iI7mMxEvi CbXoCakkqSApJ5lHMpfETVJGMoeklMRFUkJSTFJE4iSZTTKLZCbJDJLpJNNIppJMCTXvBZlMcinJ JBIHyUSSCSSFJONJxpGMJRlDMppkFEkByUiSEST5JMNJ8kiGkQwlGUIymGQQSS7JJSQDSQaQ9Cfp R9KXpE+oWR9Ib5JeJBeT9CTpQdKdpBvJRSRdhaimUDM7nnLI0k7ShaQzSSeSC0k6knQgaU/SjqRt qGk/SBuSC0JNeYVuHWraF3I+WdpIsklakWSRtCQ5j6QFSXOSZiRNSTJJMiiEdAqhCVk2JkkjSSVJ IUkmSSJJJGlEkkAST37GkVjJ0kJiJtFIVBKFxETChJh0kjDJSZJakhMkv5H8SvILyc8iWNNPIkWm H8nyOMkPJN+TfEfyLckxkqMk35B8TfIVyZckX5B8TvIZhXcklHkB5FOST0KZqGCmj0k+CmX2hnxI cjiUOQTyQShzKOR9kvdI3g1lDoO8E8rMg7xNcojkLfL6TZI3yLPXybPXSF4leYU8e5m+e4nkIMmL JAdIXiB5nr57jrz+J8mzFPn9JP+g8J4JZQ6G7KMPnqaAnqJYP0mePUHyOMljJI+SPELyMMle8voh 8noPef0gef0Ayf0kuymgXSQhkp0U7A6S7ST3kdf3kmwjqSHZSrIllIF+17Q5lDEIcg/J30MZoyF3 hzLGQDaFMsZC7gplFELuDGXkQv5GTjaSkw3k5A5ysp7e3U4ub6OnW8nlOpJb6IObSdaGMsZB/kqf ryG5iWQ1RelGcrmKXK4kuSGUMR6yglz+heR6kuWh9MmQP4fSp0CuC6VPh/wplD4DsiyUPhJybSh9 GuQaenc1ubyKnFyZux36bcqw7GPJ+dmHE8dkPwWeBE+AxxtNyg6BnWAH2A7uA/eCbaAGbAVbwGZw D/g7uBtsAneBO8HfwEawAdyRUJZ9K1gHbgE3g7Xgr2ANuAmsBjeCVfFl2SvBDWAF+AsYFK/UKr+x SSxbOQEtY9mmJaEmvDkuDjXmVStA4g+l8arlI7mMxEviIakkqSApJ5lHMpekP0m/UCqXviR9SHqT 9CK5mKQnSQ+S7iTdQim8nl5E0pWkMUkaSSpJCkkySVIIhbLHlEjSiCSBJJ4kjsQaSuJFbcmdBj0K vgFfg6/Al+ALFOcH4H3wHngXvAPeBodQLG+BN8Fj4FHwCHgY7AXrURS3gz2mpZTTC0NpvMpXU+Ys IKkimU8SJBlCMpjyYRBJLsklJANJBlCSM0jSSZpweUhVVSWUm73pMVVhu8E+oKqM4nI5yQQq9UKK 2XiScSRjScaQjCYZRVJAMpJkBEk+yXCSPJJhJENJWpOcT5G3kWSTtCLJImlJch5JC5LmJM0omU1J MnNvg54EteAE+A38igL+BfwMfgI/guPgB5Tq9+A78Bk4Aj4Fn4CPwUfgQ5TuAfACeB48B/4JngX7 wT/AM2AfeBrsAQ+ixB8A94PdYBe4jZe+cpLyeBHJFSTuUBqmQqYykjmULaUkLpISkmKSIhInyWyS WSQzSWaQTCeZRjKVZArJZJJLSSaROEgmkuSQ2Cmru5B0JulEciFJR5IOJO1J2pG0pbJpQ3IBiZlE I1FJFBITtUiWeydUB2HwOTL2DfA6eA28Cl4BL4OXwEHwIjL6IXCt2jb7GtWefbXJnn1V/lLHlTVL HUvyFzkW1yxyNFrUb1HBIrXRovMgly+qWfTOIssV+Qsdl9csdGgL0xcqCdX5VY4FNVWORlWmxPn5 QcfE4CfB40E1PTgxWBIMBNcEX4OFdVNwd3BfUN2jP5HbONi7X97S4Kqgko73CguaUrj1+cFGyXmB fJ/DX+NzaL4ePqXfcZ/psM+kdPWZxvlm+xS42uVr0yGPu+7py2yRl+rr6sv1qZflexzeGo9jrMfj WeLZ4HncY17iWelRtsOk5Hrik/Iq8yscH1SY2COKzlLBE4oeUhM8Dyv8pPWYEs7VTfOQAXOREW77 HEdZzRxHqb3E4aopcRTbixxO+2zHLPsMx8yaGY7p9qmOaTVTHVPskx2Xwv0k+0SHo2aiY4J9vKOw ZrxjrH2MYwzsR9sLHKNqChwj7fmOETX5jnH5puH2PMcw9eJsjCCsFf7nbbW01bettEazs7xZijfr cNa3Waq35bctlSXnmVJaLGmxsoWagl8K/Wqe3Xxl8w3Ntzc3pwiDmuhtvLSx4k1bmqZ0TctNeynt cJrG0jamKSkrUzakbE9Rx6bMSjmWoqdo21NM25MfTz6YrI5NnpXsSVZTkvmzmpqbbL8oLyUpOyl3 eE6S2j8n6ZKksUnqyiRTbpK9W15uUpv2eZckjk2clahuSDTlJrbrmHcsQU9QchPw4li8Hq/o8Sam mmwmEzOlQtQ4XkamjOw81MddmSazCVOLnRMndOpUsMeqFxbsiBs3bYfpuh1tJ/DfueOn7rBct4M5 pk6bvNNkumHKTpMyZOKO9ILxU+n52hUr2OCsgh1ZEybv2Jg1pWDHUhhyuUGHgWXtzGSDp3Sa6Q/6 /YFO/k74BWb6YRMI4n9CTPgNDQb4m4CfwUmnM/xwF34uQeHIH5wVhB94AWu/sOZPM4WTM/nxH/05 Y0r+Ez+m/83A/3//NJs1878AKUUMfQplbmRzdHJlYW0NZW5kb2JqDTE3IDAgb2JqDTw8L0ZpbHRl ciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDQ3Mz4+DXN0cmVhbQp4nH1TTXObMBD9BfoPe9R2YqoPJKDH dPo5ySEpnRw6PRAHx3RscMHutP++WkkY09Kigxak93bf2+U7E0Dr/h2TQKt/ZtqCySzsWWZCtPOR pkDHfcs2L9jdBBZJWuRCF/B34BhfvhWOutyw65JJ5TFuy4ROFKQyMQrKPeMSofzG3pSRdVi3Dign YB6AOUhTJFRIoWlz0C/88+0N9LiSiXZPyutDj1L4F14PdUsv1tqMH1GqEFUoU35s0ERI1wIqmQi+ wWL81KOH2UxxOHQ7lDpgG7R8jWk4479wZTlMTO3GXZyB95QsFjDPuDKRZN891Tv8CuVHcmBRbiaT LMq9/3ANASGNK/nqXItjdLJ8rWmQv1TrYzXUT84v54W/051cWaO49hlXKpY4JpHh6CLPUDu7Vfz+ A7MImGergYwXF653hw6WVRojEnOpMloSZ2LREZUTxDvy6WzraahaeF/1qGLP6+G/vqrcnMfoocE0 0hy35CUNxKSHbI2kOye0enRN1vJyniahPXVA8OGV6zH/h2YtbJKpWQU3DY7m/0Qb85Krri3LHEaT YTMVqPPQ2Iqa+eeI3DXUUH9OEzj+Jw+oDD9dYT723o/SbbXGcEHnfAuvt3U7ifkNzT/vYAplbmRz dHJlYW0NZW5kb2JqDTE4IDAgb2JqDTw8L0NvbnRlbnRzIDIwIDAgUi9NZWRpYUJveCBbMCAwIDc5 MiA2MTJdL1BhcmVudCAzIDAgUi9SZXNvdXJjZXMgPDwvRm9udCAxOSAwIFIvUHJvY1NldCBbL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTE5 IDAgb2JqDTw8L0YyIDUgMCBSPj4NZW5kb2JqDTIwIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE2Nj4+DXN0cmVhbQp4nI2NywrCQAxFvyD/kGVHME6TebTbgorulNmJO60PWov+ /8JOq1hBRbLIgZx7cwWNcdZzSDHO7QDi0HqHNXjbU9WRRJDHPkI5gtUr3EMbnsy4bQklFAGMUM7d oSd2TDpDEUuWMdSQrBeFwnCGafjkC2vK3vzxL1sMCQ/sTXK6KE/iXCpJqWKZ8UmjthiWXzqMZsrd vx9N6sgM5brZ7atn4A7y3kZyCmVuZHN0cmVhbQ1lbmRvYmoNMjEgMCBvYmoNPDwvQ29udGVudHMg MjMgMCBSL01lZGlhQm94IFswIDAgNzkyIDYxMl0vUGFyZW50IDMgMCBSL1Jlc291cmNlcyA8PC9G b250IDIyIDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXT4+ L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNMjIgMCBvYmoNPDwvRjMgNSAwIFIvRjQgMTQgMCBSPj4NZW5k b2JqDTIzIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NTY1Pj4Nc3RyZWFt Cnic7X3rkiy3kd4TzDvMzx5FnFEVgLr5n7gmbTokrS7H3nBwHQx5eChKPkPuktTa+/Yu5AXIBKrR PdKgMVxhFbHs70wVEh+AwiWRl3+9G+79/373X+7Ge/+/7/94Z+f7aZnvn++WCX99hF/W/7D032/u vv7Z3W/jy8Oj29bBbvf5j73En39m96Lff333yfu70cA7+3+WwT6aezc+Tub+/fPdyT7cv//z3afv 7/41VoHlhQrEOs2LexwTYBfzuHnstvnRmgzjw9/c/dPP7r7dxQyPZhvG/QFfWTeO6/5jsf7/7n94 +nZ/aXpc3f20Do/DuldGY1/k/h+P9pJZAKKnUDvEWEHH0IM5FKQRvrrjUHeBF3xXAaK9eKmC9mKI 9l4mYap/jnYxT3ur+Ken0IjPsTT76Jxs5IDt42ZkRQETEdFD26PqgwinOT69D6l9RP0WumWdzeKm vTege0b/w22DoV4JXfn8skHAg7ZY/L+Gbg4C1lUIWLE53QoCQhO6tQ+sNz+wrplWvrkzezm+/mb2 rfPMeFwtFG+35XFeU0hPqzEwD8vqrO/6aV5nPwX6zrfbCmTN8rhPgs8Rj17KRxBnjzA8H0ZxEz52 Mwb4mH1Up3ygvoLP4P8j6p9i4vd2+OzTwOb7TNOCakdao/9KIosEMsmGpC7wgQoLOvTJBT4pRn6N +cDsfEwH6iv4jI+LHGUZJn5vhZAZp0UTggoLQoOfzASBFBPBdoQm7JUyK6h1ZDWs6rNJIHN8E5ym YVuPSUGtBaf50ShSKV4bf0oTUpCk1tXYSZOCWgtWVi9DGSaWb4LWOC7zGVpWr06D0atRhm3r1WlC EhdoGb06DeOjkSwSaFqvTkek3L7IaFK+1oLTICkMOb23QGffq07TGTpDJGO2zR93A4UUI7+WhKD6 RUJUZ8GJdqaBU4qJ45ugBYcwT8tv/jQtvSE3G5UTaKS4+YZ8QhIXaJGUgK3aEeU4yGlGa5nd4rev i9/Gwo4C/0XRsmqfZDaDp71AI8W2+T5p/6LcdomWQZVAwGPyLaXYhENue1r43yNWY/JpDcmnlOKx +aeVs4IfitWgv6x1U2enDDPLhqxmr/oqs8JaC1ar2sbmeGt9ohKsxmk+R2tV+1qzLnray/DafF+7 f0bDfInWoqfBHZtV00px62kwp4X9l9AychpcZ3XqzTHRfAu0Rj//naE1q2OwWadHxSKBc/NjMKgw L5HytRacQEcuWKQYSb4tUtB3ihTUWrFympQ74PgmSPmd+1lSagoErbpgkeLWur8J9eYXSEGtBSuT rE8pJpYtaZF6dhn2/boDWtB7ipZJ1qshmfFSbJqvV6T+K7LSekCSFVmkeG2vCQys/GHfs8JBKVlh 2YLVqqe8DG/NlUusASzSWvUcuKxKR3aEW8+CkRZf7B7SGtUYhOIEjRSvzbVmrCwTtGAKUbTgdUFL dc18QLAhIdYuzWwsckRIddKk9WYZbtxDOaFgUaApCEr7pkEySODUXGkWOZEJwwEnX2lFyRrNKcWt Bx4pysqcrOonq1UuGSaSDVmxQkmwgolQ0bJaB7MYrXPJsG2ug4m0yJjmiJbRSpjFJItSjlsrYUj3 coGVXqNGrUrKcPubnZwVLFqK1ahVS8uA9j2BRYrH5qolZuVPvdMZVgNaNQnsVs0qxVvrviLNywVa Ts7t86YVZClmmm+ClrGTPaaF1Va0lILsALfeW7CaItLClTmhpRRm86qvPzK8NVeY8Zl+9lZy4xla q74OmRelIUvh2vwy5IBUMPtUJBQntZ84wI0HIB/oL5BS24s5uS3NcPvb00jLTedYJZen86TX3Qy3 vzzlA31ghbsoxWrS6/Ds9Lqb4an5OhxZ+V9naDm9EO9Yaf4OcOuFmM/zF2gpTeCcXNhn2DXXBAZa /v9Aw55dXM3J/f2O9bqb48brcHBsKbPSy3BihZBh23oZDv4Jc3CKwG2UopVYJcyDVmhmuLlVguNj yOwnDneG1qAVnNOmL0BSzDQb0uINe6SFu0NJC6utaCWsjki+CVJsQXxISnFa0RElsEjx1tg00PFm vUgKaq1YqRXqAC9vhhaZEOOON2GlFqxp0braDDc3tXC8sS2xWrT6dseD06xS3FiB62gHWCY1qK5K 7CoyTCTfACm3b5lA0Y7beMUqMbOYpkerWKS4uaGF4/3fvI9Du5yhBdUWtBLLigwTzYa0eKckaMFG XtFKTC0mq+/fMtzc2MLxVmm2+65iPkPL6vu4yeplN4ON7+SOSME2PiGl5kCjVZsZtq1XYd4mzdbf JpwhZbSmcxqT9SnFprWm0/GeYvaflV+OVzycKFpjsmAN6oIxhWPz5YqWqSKnQd03usRcJMXEsSEn XqXg4xqBFJy3JCmXmI+4VavKMtzcfMTxdD4b/12dobVq3ZlLzEUOcGPd2REtOEYmtNTVnFu0CjDD zc1HHE/oRVqL1gm6WesAM7y01glGWjuXYT1Da9Y6wR2rFeoAN9YJOl6pIi08Hye01JLlJq0DzPDc fMniWX0evUnWGVqTVgo6bROTwqm5SpBn9dnfM05ACs7HipS2kXFW3VmlsLWFjOM5okjJqhssl1jE HODW/cSkOCTHMSl1g+USg5gMNzeQcTxDRFqoyFC0EgMZN2qlZoabG8gIWhSg44jWqJWcLrGIOcCt 1Zw88V2gpZfhxCQmw81NZBzPE4KWnxQVq8REZsdKr3mAW6/CgdU5QkrFaRNjmBQzwYaEeIo4JmQT sxibmMEc4NZrLxMKsTpWVKIltNR9nF21PjPDzc1iHH9FRVqrVnDaxLrnALdWcN6LQB3HjNQNo9WW PSlsbuij+aCaU/HRNj521qrZDLe28bE82oqkZq2p3bHTpNwBx7dAiuN0HJNSM/mkt0MZnhs7xVnu oCKpSe+OdpyQOuLYkBRzCZE6KEZjQkpxSsx5Mjw1Vj5b5lIklVj3WKuVzRlubt0jaFH4kRW17IqW 1crnHavb0QPcWP1smc0FWuq+1OogjTm2re9LLQdTmfjHOmUuL1bHbjQ2sefJcPPYjZYjWIRAHUe0 Evseq0NQHuHWKxaHsrhAS2mgzaYvSFPMNN8WrdTlBWutWBlNyhxwbMmJAj6E8COHnOQkqE5QZs3Z tWRD8QNCHIsDNqp7EiOeDDfuHQ4dEPngVZwilJj0mEnP3hlubtJjOXRAiPdwRGvSs/mOlTr2ALee zek6W7CCm7iElVLPGqfVsRmeWqtnAysei0esnNbOGqeXpAPcWDtr+Z7+Ai29RBmttsywa75EsY99 pIX3i4qW0XpMk9i7HODGekxBi2aOY1rqNtHooMk5bm4AY9k3vUhLh1I2Rlu8pLB5IGXLzuls3bPi VbDipA1gzKAVfQe4cUexD3eZk9L9jZten1JshtbaP8GKJsMDWlhtQSsx48nw1nzB4jNViVVi1TMu Wj+W4eZWPQeswBRBsVq0vmxMjHgOcGuNGTs7h+Awx7TUbeKoQ5LnuLlRj2Vn5yItHaN8bwl9OZXh 5jHKLfsFh6Aqq8nu4LDagpbTk3mGp9aXVZZdaIu0XDK9a4uXFLrmk3skRevxESltATMarSDLcGsL GMsOtEVSRuvLduw0KXfA8W2RAkOfhJSaK1RI/Aya1rc77Dobgt8cUVIB8s2YWE9kuHWYfMOes0VS iUnFsOkbghSPzU0qDLvOcpSYFQ2XJCustWC1oE9OYJXirfWFQchcVmIFtRasZq2lyDCxbMiKfUxD kJgjWrPWWgz6mjSFc2udxREpsDFTpPSt6eC0iiLDrW9NDXuYFkk5rbEYklvSDLvWGotIi3e4R7SS W9PBKBVFCpvfmRr2my2SMkplMSQZDDJsGqss2KZbcAJbQMUpSWgwJAkMMtw8oUFkRSeRI1Y6ocG4 6QQGKQ4sW7Iiv9kCLaq2oKVj4ue4eUYDw36zRVo6Rv6+nD0qFglsHiE/kuID1hGp+VFxUhHxMzi3 nipySmiVqiip+PgeyvnuCDfeVbAj8AVScgIcNx07PsfNb+MMuwIXaelg8uOmg8fnuHkweUGLDsNH tHQw+XEbkxkvxc2DyRu+LyjSGvUMuOo46xlmmm+LFth7S1qrjrs+rlqlnuPmcdcNXwmXWGkVu8cJ qSOOb4ETaWSOOSlKWp2e46X12Yrd0YuktHbdF6sWqAy31q7f+/95BmmB6StJiYm8b3qe8Nfi0/OE 9zzhLfj0POGRQM8TfltOPU+4WoZ6nvBb0ep5wgn2POE3JNTzhAc8a11/zxN+K1o9T3jEPU/4W2HV 84Qjq54n/Fa0ep7wgHue8Dakep7wgJ0m5Q44vglSPU94zxPehFbPE8645wlvTqvnCVddMx8QbEio 5wnvecLbcOp5whn3POGtaPU84YR7nvBGrHqecIF7nvA2tHqecIY9T3hbWj1PeM8T3oZWzxMecc8T 3oRVzxPOuOcJb02q5wnvecJbsOp5wgn3POGNWPU84QFbff/W84Q3I9XzhNsj3DxMcs8TjrDnCW9F q+cJD7jnCW9Nq+cJ73nC25DqecIJ9jzhLWj1POES9zzhbWj1POE9T3hDQj1PeM8T3phPzxNuD2Hr PBI9T3jEPU/47Un1POEC9zzhTWj1POESK41zzxPekFbPE56za8mm5wnvecKb0ep5wiNWS1LPE34z Wj1PeMA9T3gbUj1PuMc9T3gzWj1PeMA9T3gTWj1PeMQ9T3hjUj1PuNOk3AHHt0Wq5wnvecJvRqvn CSfc84S/FVI9T7g9wj1PeBVSPU844Z4nvBGrnic84J4n/A1Q6nnCkUXPE35zWj1PeM8T3opWzxPe 84S3V1mEYGZLDOVI1VRSCO9fjUcKUIV29CRFwgfm8T4qCVP75GgX8yRbD2svIJXjgUVEPHf0JJvB 8m5nZig6IQFPvkVXuBrFfxANSjr1IElgpxvcudjCgn7Q5lDzIEZpokc40Xrl3OcooGIy8iMBr58d HKRcEPA3pesOAqrlz84lvHZCa4gnWTvDdCKkUspnlFI/B3Mip1pSZJBTPUvxOSmvlTZYl18jjy9K qJ9YN5FTLdMtyqmfehbk3CAXLMqpn5w1kVMrW+oZMa+dvhTE1M8nmoipluAT5dTPuHlGzqunwNRy auWkRCm1k0Sek/K6WRsTKZXSKIKUG+Q1RDn1Ew2CnPqZ/7SYaqn4UEz93HiJnGrJ6lBOzexxIKFq OrczEl43v1oipE7CMxRSPQMZiLlBSrBETrUcXSinetKsM2JeO4uVElMvrRSKqZ/nKZFTLfESyLlB JiSUUzs10Tkpr5srCKTcIHlPIqdWNh0UUz29TSKmWr4ZlFM/AYyWUy0jC0TFqZ8iBcXUz1mCcuon EQE51bN6JFIqpdlAKfXzXiRyaiWiADH1M0OgmNqpGpSUerkTUEz9ZAYg5wbZBVBO7XD/56S8bvx9 kHKDgPgop3aEepRSOWQ8CLlBDHeUUz+o+jk5rx3lHOTcIOy4llMvDjjKqR+YG+XUjpQNUiqHrkYZ tWNJayn1gjuDnBtEW07kVAt/jHLqxyNGOdUDBGsx5yT8LRF7QULVELpKQsWYtiinfpBZkHNfMepr LuCVw7CCP2b1uKhaSq1ApSilduRQkFI9lCdKqR9bM5FTLdglyqkffRLk3CAcJMqpH58R5NwgYOI5 Oa8awRCFVAspiMVXjPEHAm4QdA/l1I+CB3Lqh6VTYurFiUMx9QO3oZz6kdQSOdVCm4Gc6rHGUErl 4F8gpH40rkRMtfBYKKd6vKozYl47gBSKqR/RCeTcIMQSyqkf8wjkVA9ClEipFBUIpdQO03NOymvG zUEZtQPZoOdP/cgyKKd6qBcUUz32CoipHgzlnJTXjU6CUuqHC9FyasXvACnVA2qglOoRLrSYaiEn UEz9GBAgp3pQBi2lTpSEMzJeOWwBSqkfRwDk3MCxP5FTzdMe5dR3fT8n57V90VFOZedwLaSStzYI uYH79C7n3v/PF+kfkQ7SqQt04iFNjzP8Btxxfb27M67tzriiRCGhO+N2Z9zujNudcbszbnfGPcLd GVeUK+R0Z9zujCuL7c643Rm3O+N+m5QpZHRnXC2mO+N2Z9zujNudcbszbnfG7c643Rm3O+N2Z9zu jNudcbszbi5UCunOuN0Z964743Zn3O6M251xuzOukNOdcUWxSkx3xu3OuFJOd8btzrjdGTcWKoR0 Z9zujNudcbszbnfG7c643Rm3O+OKUrszbnfG7c643Rk3F6vEdGfc7ox7SU53xu3OuD8RZ9yeXPgt JRfWm38ew0s0cCWLeLvSJoPxMrMtOOEJKGKzLhOyh9Mmob2RB2BCeK/xAJv3UBRhf9U6zRr71wZs UrgipaIQ7CWbAZ+kpmFIVvDh6YAnvzkVggCLigS8giifbHuB1SxwAOS7nziKFXaWrQNwjTuu3uZN 2vxCi1+dYX1fAfa5a3I42RJ0I25CnYFqJxAf9m+H/OrH8QOcgSbwz4OmPWC+vd+l7ZRyrH1Wfnt7 NkfBCnTtBRu+U+fap1jbDDRnowILaBKRlJ3ojoVIpDi50b89qQt8sL6CjyNLWOaT4qnxkLs/jPug qy/o8BUlVz/FTlngNqYT4jLo6gs6bETO1U+xvhm9OZ1SRAvNIXIybEhOHFJstQF7S055AA1NQpCS vaKBtmBvQKcQqUNUX3Dhm0tmkOK2vVMICKIZCEZ8q8gMUqzvTG9PqhR9RJMQpMgUmzkkUF9ovglK IVCIoiAYKQIH5NqTOYh6ImovqLBpORNIcVs6hSAumkFkNG6P8pNJoNFG7S0p5XFcFAXBiHVLTCnF 22PbL6gQmkZzEJxY+cMcUqz1WrcnVYqDo0kIUmQFzhwSqBVPDSgVQu4oCoKR1R9TApUFektCWWwf RUDxGY0mlOKmn1IhjJCmICgZvUfIsLasvz2nQswizUFwGtUeIYWm8ZahFB5JURCMOHoAc0jx2Hbj UIrEpDlITorQAbs3RCeGSBLVj1yGTe97UjwOb4LOQcQnzUAwYrcEZpTirfFOqBTGSpMQpBZ9xMuw 9ol4E6RCpClNQpGysyaV4ranvlKQLk1CkJr1JjXD2kzm9qRKMcE0CUFqUgtRCufGe9ZS+DFFQTDi WBbMIcVT23WpEOlMU1CUlGLrAC9NR14hrJrmIDgl+tQM66AdDTgVYrhpEoLUqE4TKWytXi2Fi1MU FCN1nDjAbUdeITKd5hA4uWARhhxSPCWGaLcnVQqGp0kIUqu64suxNkd7C6SCl5XmoDjJI8URbnrj Vwr3pzlITorAAbt2bM7HFRS1F1TmR1X/BDblUgpeqOqv6Fij+aT4jVDKAxhqDoKTvkDK8aziPjYg dT4oo+agONlZc0px28NFIQKk5iA4OXWWyPHU+GxRCDepOShO46w5pbjt4aIU21KTEKSsMjrJcevL v1IgTU1CkTKakzmg2IxSKWanoiAYGXX5kuPGt5ql8KCag+A0qoNsjk3j25hSNFJNQpEanCaV4rZH 21LwU01CkBqUYjLHY2PboUKkVc0hclrVrXMKmWE7RueDuioGipA8yR7hN8Ioj+uqOQhOlKOIKSRw a3yuLYWqVRQEo0WZqOVY5UdqSCkPV6spKEpK/XCAm5qtlULwag6CEwe/Yw4pXtpqH4rxfjUJQWpS atYc68h7DUgVggtrEoKU06faDE9t9a7FSMaahCBl9bE2w67tMbcYOFmTUKT0gpTjpufcYpxmTUKQ 0n4VOW5s21EKCq05KE7qYHuAm3pblCJQaw6C06jPtRlubLFSCHetKShKRjMyBwSbEzqIrK0YCEKD rP+Qc2vHpRC+W9Q+Ulm0cUqG15bGKsUo4ZqBYKSNU3Lc2FilGJJck1Ck5CXtEW56DCxGQNckBClt nJLjte21bTHguiYhSM3q6JfCxqYqxdjuioJgNOmTX4bnpifBUiB5TUFQ0h5/OZ4anwRLces1CUFK 29vkuLEfYDFIviahSKmj3wFuqqYsRuTXJAQpoy5sU9jYAKcY/F9RUIyGhFKK3walgzwDmoPgpIyI MtjYpqiY0kBRUIzUQfYAN/2WStkTNAfBadBnvgw3tikqJmvQJCKpObEhSjGTbEeqkB1Ck1CklGry ADc1Kiomo9AkJCnF4IBeMzqlnBei+oLLos9+GX4jdPKUF5qBYqQuNQ9w27NgKY+HJiFIJeZRGdbZ wxqQOp80RHMQnBLzqAw3Npc6k6FEV1/RUSfZA9xWg3ycDkVXX9BJjKIy3NhIqph7RZNQpJzm5A4o tqNUSPOiKAhGiUlUhl3bg/r9cUYZXX1Fx2g25oDc22ATk7Go2gsyRmsYMtzWLqqYK0dzUJyUbdcB bqpwKKbm0SQEqcS4K8ONjb2KmYA0CUVKaU0OcFMtSjHxkCYhSA1ax5Dhsa0epZjnSJOIpCZt3pXA eWirdCimVFIUFCOlZDjAbYdeIXuT5iA4JcZQGW5s8FVMFaVJCFKcr5NJpLixeVQxL5UmoUgpJcMB bqp0KCbB0iQkKcXggN5bopO6lUyqfxLTrgy37ZzzSb00AUEoMevKcGMzr1ImMc1BcEqsujLc2Mqr mLxMkxCkEmOhDDe28ipmStMkBKnEWijDja2HSmnZNAfFyWhK5oBhc0YHmdkUA0Fo0Ge/DLc1Iiom m9McIieX2A2lmDm2I1XIbKdJKFJKXXyAm6qPi2n0NAlBKrGHyrDObXR7UqWcfZqEILWoc1IKG1tH lRIEKgaCkI5xk+Ol7ampkI1QUxCUEruhDDeOeVNMfahJKFLKh+QAtz00FfIsag6Ck9MHvwxPbX1K SkkdNQfFSekmD3Dbc2Apg6QmIUglxlAZdo11laV0lZqEIGX0gSnDjc2jirkxNQlBKrG0ybBpfIIq JeLUJASpQbuQZLix6U0x76cmoUipY+ABbupTUkwzqklEUnbTx8AUM8m3RCrkAtUkBKnEfijDW+OT YSmNqiYhSCU2NxlubFVUzNqqSQhSsz5iZLixGU4pRazmIDglNhAZntueOUr5aDUHwcnqHXmGGxtF FJPfahKCVHLTnmHbdodezLWrSShSavt6gJuqW4qpfTUJQSq5lc5w46v3Yh5hTUKQGpRxfwob31EX kxYrCpGRSS5wU0wU21E6nyFZUxCUVr1zzXDj+9xSOmbNQXBKoltkeG27kS3mftYkBKlJb4cy3Djc RTHRtCYhSKnkHhmcGm+OSlmtFQXBKLkgzHDbbB/FJNqag+JkZ80pxU3vC4s5uzUJQSq59MywbWvZ W0wQrkkIUsl9WoYbX4IWs5FrEpHUuGk7xBSbxhdsxdTnmoQgpe9pUri1tUosZllXFAQj7e+dwra3 NqV07oqA4JNc0mS4rfN3KXe8piAoJdcZGW58ZVNMVa9JCFKJw22G295v3Pv/+fonxSUvJMUlwr6B ZNc374+ez1rUvuezvgGpC3x6Puuez/r16PR81oxlr/R81jeh0/NZq8+o57O+AZmez5oI9HzW9Sn1 fNaEez7rRoR6PutIoeezvh2jns86Ejpg94bo9HzWPZ91G1I9n7Xr+axvQ6nns+75rBtx6vmsez7r NqR6PuuAlWtIz2ddl03PZ200n57Pujqpns8acM9n3YBTz2cdsNGczAHFZpR6PmvEPZ91A1I9nzXi ns+6GaOez1pw6Pmsa3Pq+awZ93zWDUj1fNYR93zWDUn1fNaSQ89nfSNCPZ/12vNZ34JUz2dNuOez vj2lns/a9XzWjUj1fNaEjbqw7fmsb0ep57PWlHo+69qkej7riJVqsuezrkun57Pu+azbkOr5rHs+ 6yZ0ej5r1S09n/Wt2PR81mvPZ30jUj2fNeGez7ohpZ7PWnLo+axvQarns2asGBzQe0t0ej5rc0Cw Haeezxpxz2fdgFTPZ93zWbch1fNZE+75rG9Pqeez7vmsG5Hq+awJ93zWNyfV81kz7vmsm5Lq+ax7 Puvbk+r5rAn3fNYNOPV81oh7PusWpHo+a8I9n/WtKfV81oB7PusGpHo+a4A9n3UDUj2fNeGez7oF qZ7P2sOez7oNo57P+i3ns47qiBAQbImhD6mSUgbBfTPn0T6zeTSv96I6O3qSEuekBjNvNKigCAy9 uKqKI/JsIilrEvQkWyDcS+z1Iyzaf39JIF9Z35oQDR7/QbQm5bQNsgQedC2HNTRv4CoMNTeFQVjs DU4HXjlHNwqomDb7SECNTNYg54KIvzG5dBBRLd9zLuG1UzBDPMb6WZETMRUSFaOEmrmDEwnV0vmC nOoZds9Jea2kt7r8GnloUULt1LCJlErZWlFK/QSqIKd6TlOUUjfNaCKjTubPM0JeOxkniKmdHzMR UillJUqpmUXyjIRXTOyoJdTLtYhy6qc/PCfntTMSJnKqJQkEOdXz9qGU2qn0QEr97HZaTLWEcyim dg64REqltGwopX6mNJBzg+RlZ+S8dj6xRMzrp/hCAdWybkHx1RNhJVKq5aZCOdXTRZ0R89oZnJSY ekmVUEz9PEeJnEqph0BK9WxAKKV+gp5zcl47Zw7IuUEam0ROncwyKKRyspdESKX8KyildkoULaVa lhKIRVM/cQiKqZ/LA+XUT68Bcm6Q8SKRUy0JBcqpnxcikVMrVQOIqZ89AcXUTWigZLx+jgEsvmbY f5Bwg0j8KKd+cPxzcl47Xj3IqR5CHqXUjuqOUqoHWgcxN4h9jnLqhyM/J+d1I4SDlOpBu7WUWnG0 UUrt0NYopX60aZBzgwDQKKd+TGYtp0aYZJBQNXJxIqFaMGGUUz++L8qpHnJXizmW8LdFwQUJVQPT KgnVYsWilNrhW0HKfcWIqrmAVw5yCj6SN4g7quXUCwWKcupH5wQ5NwiYiXJqx7BMpFQKK4lS6kd6 BDk3CL6IcurHQwQ5VUMUnpPwalEDUUD1QH4opnpsPRBzg3B3KKd+BDqQUzsonBJSK04bCqkfOg3l 1I9mlsipFmAM5FSP+YVSKofhAiH1I2MlYqoFq0I51eNHnRHz2iGdUEz9KEsg5waBj1BO/VhEIOcG 4YESOdUi9qCc+kF0zsl57bg2KKd+qBn04qkf/QXlVA/IgmKqx0gBMTcIW3JOzmtHEkE59YN7aDm1 4m2AlOohMFBK9agUWky1QBEopn7sBpBTPZyCllIrwsEZKa8edADl1I8DAHJu4JqfyKnmLY9yajuw n5Pymj7lKKOym7cWUs3zGsTcwBl6l3Pv/+eL9I8Id+fEoTlxd6aHGX4DDra+1t29Fsrt7rWiRCGh u9d291ostrvXykKjkO5e291rhYzuXtvda7t7bSxXyenutd29Vhbb3Wu7e22Gu3ttd6/t7rXdvba7 13b32u5eq6V099ruXtvda7t7rRKniu/utVpOd6/t7rXdvba716ZSlZTuXtvda7t7bSi2u9cm5So5 3b22u9d299ruXtvda7t7rZKpxHT32u5e291ru3vtBSHdvba713b32u5eK8oVchIdTHev7e613b22 u9d299ozcrp7rZbT3Wu7e213r5XlXnSv7el/30r6X98ZW7D6T374zpjBRzfsL0bcdof9A2G70aqF jwcounwJvqTJjyiFXnvOSmU8jTj/0uMMhZQruNBrz1mpjC3NVvS4zSevopTx/s934BAyDNP9//Wl 7H2uqO0/ArXf//VFSh6+SObxVxZJ3QwTe6Ru/toSxUiBIkXr/tVlInE1GGexqf4b2tIOsZa+LbnT fZExGkDy7s8/c/fj/fuv7z55fzeCkbB/EH/NcIPgRtCLvX++++L0u+8e3u3T0DbN8+kvD+9mb3Fn ltOPf3rw06h16+nb+K9/fPhf9+//292n7wtlD3DdCmX/4o8f9pf379u6ZTv9eP+w7yL348Jyev/w bjp9/7A+jss+j58+fLgPBf/8M3u29otX3tzbFWZukPAv333/48POZj9ILac/eVmjHZw7ffftvf9n D07ffX1/udp2gfs1KPTHvWLb/upexQ8fwquXu3CD6rHBsFnAlzWYIRNkRQQ/faCYKM5J+r3nrFzC dqaNND0f8NXzhXrvOSuX8bgKIeP6Egn7zL86zWQRLXLdd4OFqGougu51hcSeg2N+oENKiasKEf0N hYQGekkh3CZiDC0mjKEXtci4iuaAjvGvlyaH/SAPOye0k3vl2cGMcErx98sTFf75w0yfqyjkhweW 9+MfvOzVzMMmH3h6cN5Fb7KnK2eNcYMecGYO08bnD+/2XtrFLKdfeyE4Df3+/YP3QR4Xd/qF/1eU Ih74h4d3I5gk29OnD/u23m6jO335a5h24IFflFqA6zHaMNP86tOHfVO9zzWn4hTFbw5DnLb/ca+A har8d6iVr8A+r65Uq1i/3325s93L8Q+f/vPe5HuL2+kqgXaKVW3ZZNYxcd9i9+//fHaM+Q1yfPoL uST8cP+wL5/AXfzrt199+H/7UmGwef7Ph3+/v37C308GfkhPhhZ+u8GqTfgjY//1woRGzwd87ZSv 33vOyyU8OTzh8POMr52Q9XvPebmELdkI8fM2txm6KGffIig+2xz5XDXNcSGystscK3t1IdSDsM8S jK6eskWvYxmxla4vA8mokbTNcSS9qEUsGXxxi3D3XJr+rQO9KDn9n5+hf/zw/cM44AfzNXzefvO1 T9aznJtLn7WfV/x8tvFW8fSu8FXbCW4+49NfnD7u9cK56E/hl1g4xCfsWxWUNfsPUF4tk/gxkWbG rKBI99rHGY+8Fg/jQQvqO9NDPExDV9OCghj0STPrsfCPdGEDG0uPSaUOrbxjAqS9JM3UgGf7oBXF jYlh05YFtweo4kA8R+3mArpgOnF7DFsRj1EJsPhtBJ3PEfqjUNBaLqSOoGgpCykkWNu4AF2PUc1N e5N9jOIVC+1/jAkbUQD4e8IlmDWK8LeR1Ev8IhuJcMFj3Glu+LyR9Rqo9bnarEVkWhxehFjTAS80 yiBaLGgGsT1HNr6g5t4xXVNgd4zBaAK7y8fGEb05BlsH7OodkxIGh8IYXFMMaO5IZ2y09hDH2Bjc S2AE7pDuGHCAjsEUwduFRq0go5nhrB6ekHUoDL4sIWtC2lyVGfU7oaYzsyYa86NiuTBragXa9nAj rbIBV+j62MCkphLWL9ssNbcb9T0B6njs2W3QHe8nYjEutoE6nsbNNuLXQsNqGx9nMei2Eb80HpQb 6dl40G6kheMRzX+nAc+v88dApfO3wrL5W+K68bdGVacvkYmF64WN9YbUARurDq1stTAPUKuKSxAj J5F1FTMM9VacgbA34wwFnW3496SmNhwocerDcRTnRRxncd7EcRimVRymcdKFUWxCXMF/+tndt/uU rpv+GZ6D5ll4/kgmG/q7Vl//ti8OfXHoi0NfHPri8B9tcVi5Z54F3DvGbBYnVI2gk57uNOYXfY/J 309C8sYVg/aHiSWsFRrBs08w0xku6aOGAvg3FRJvYtXPIbhtZKn7Fz3y7AAYLlbDahiQ40efxGKH 08NzNlss02MyddNsPa+qV8LKSPzpuwnfif5uDK/MtDC/zhLfR8NPfzSUFLt2GNhGEfXVp7GkRhhm 1prtc5p6+rJqZd1QAcsxeqYNJquBYvAQtgvZ49HzAV+t6VPvPWflMjZkZcrPm9zq9Bo+9N5zVi5h WluCnIBfIsc3veSzusjnOr0WFSIru7pY2asLoR4EOzFmtG5ROXaxENHtk+ielxVCdNRYWl0cSy8p hDokFBI66JKujz5hu8IuD28UPn+wdO35yVX3KnajqzbYYnEZ7/ha4hPU8s+TGVd5OfCrT4uqQSrU gX8zFBrvDcS9gijwk18+sGpSXDF8DprJdd7m028e3k38z9fIRiUwEvqN13vC/cZnX+JdxnD6r142 3mlHgeKi45cv1z/CMcRfbBu89sM7aXnysitHs1j8jsjDiQ9I3ihiZYeEBaY5jwd5T7tS9Aicoz2k YyCspB7TMRA2fh7TORCuVNaRj4EOr+ApfsMCu0wP6RjoN6Ue0ikQtqx2HfgUCFtcj2n9MDgKh0eG Iz5OB8ERr+Y5JPwC+2+PaRfgd+ce0lEQNvMeG4Ke+LLy0Y/+zJb0C1qTLCuf/ah0Lto3+t7W1OhY tYXN4xe/SHloJLGFowEssHe3C4WHxGZZ2OZ9sTgLsk8/Neoyxzb3o2RhZ3zqk/0/3GVmBWhn0aXL FM7eO3Dx4O2Hw+KieQC0Anmv42BaOI4hHp/D/MwDcWEvdDw+e+z4vDzj83y6hmYwfPomzH/esFXC 29vjLAvXiwMdqGPl8EAdqo4H6sgMD9SROR6oY7OsRrQZHqhDk+KBOrY4HKhjh+CBOnYY7mRih+Iu KnQ3nlXiaFgdjw7DRx8rB9M6Pc5irOFJiQbiOmMjrPEYtYpBvC7YCCE0yIxtRN8Avx0ix07YxMFr BSWHnAvQVvEDpIrz9wn7ufj1Euvwda8WJ6pRqSHi5LAanKlG1eZhalkNT1RBARKnpXXkaUpqT8Ks 5usg5jwaKWFOXAecpqxS3YgpFbc/K4/K0fBkLI+WeNqlCeU5DH7fKjyh6AmHPg6jDE1foHjsq0Jf Ffqq0FeFvir8JFYFh7dDaLKE+Cxa0EpfYoG2+V6Uu6HOB7+a1enVBXGOAvCvDmIszBt+ACglIv+e Qk/yWV97jfaJcmDwxGvVYrK1T9QuIpoPQEpY6HAGeJYTRJjC3SooRBwucbBpCDj+Hb+Dw+9CKBxf Z23vw+GnPxwOLZC8hTGs/Re1jBNq1sLTX5wewYwVbJTEz59db2c4GZy+J8oyNw84GCfKIsfY0jUN P2/z4DRF7aN+7zkrl7CZqCPo+YCv1Qrq956zchkbWkj5eZM7b1+U4yd4yQf0O8TnKk0bFaIq60ct V/bqQqAHZ1TXCUbXGyuGbqdCRDNdXwi3iRxLvk14LL2oTQx533ObcAdd0j5ODrZ4LrpcnLMz/3CV JtLnIgR19hgsBK+3jy6qBLnkAXa4ULLQJv7Ol2LA9+SzT70RMSgKxb+eM4R+qX5wxGgpdiOPXY8N QNhTjQ6mdrvRDbLH4N1l2FHNAcDfsL3xEHZzI0YU2fngbs9j0IXSrczoYHPlMfqTYGQQj/Fx2KiR rSniGeDCf/bbpo2u3b0jk5+btyE66sHb99HRbaX7/BFjXJCmHjHsHMkeYLQr7hzJXmDEeyC7oi2B h7BzJFODHQOwWBYuriuZKXgMO0cyY/AYDsRk9RAKI6uIEeNi2JWsJkJd6GbM19UAdJIJ3cF5DCf5 idscWmGduMnR22uduMmxEdcpNDnuS2OTry5uBXwPDWvcu3AP8tbVY14eufd5z+vxJPQIMHJ4wzxi kJuwoeZhR9vtEWPthN34iJGEwtZdYOwDNz86+ThdSXBpC5IOwhZkHSqz8G6darrybp6YrMSawCpb YEPWoYVw0Q4tOA2ieSecdrn1MRJX7JwJFQah8yZUGIS+xTBkse8nUmfQ0JhAZRDGzUS6EB5XE6oM wribUJXCw3IiTQsPW/ozj+qJNC086rl0/iQm0rTQF8NV4w9qQk1L+OCYGn+QEPssfq/UMvgxT+Rg yh+6b9I4C+DWMc4S2B9xEtl4DjKiK+MUtPIUNMuhEKew5VHNcDiSwgQ44xQUJkcYhnHunNHJN8yt 0LE09YqDn2h7npLlc34GGRz9ORaz6kjX1ysD+xLQl4C+BPQloC8Bb2sJsIb74hnwFPpGoAQ8ySf3 aufIhonpKXw0m1UryQbXBWJZ0Aik8BoUpjhQE5OYY4DvRRR/e0pxUbMzVY2UuVy1AMOKx2DjG6In sZytFJcwmxl4Ns5nZytnFtlHxDx8JauTnwnhmJ6Flt9XWcf7WPjJjwU1EiAE27gY7lIsZzHcNTse FyMaIwBoCkBuwAsuKsYNpAzlaAMZphuv8LzAw8p4XNB4PEMGBI/MdI4licWACHbiZzS9vBL4+89L qt5xRjeLYH76xWl4WK5Q9/qER358WtrKUyJfwh8B+zWbnIIhm7AH+zMMYKV6ukNIDgMfuSD0J4h6 0xTSTV14OmD4QdgjBOsaALzwdIeQavEx1h9X10BP2vH+fbI+sryc8Rp4cxzSoDTGfO5lfxGzBIvE 64bYdWdKn97F68c5FuRM+n+MNuLhgH9Go2BM1WIt2bpTYhWPMarZjPfEluy7mamlQGCQusRa8u/w eUD8pG3J/4Myj3jsVsL4Z4OF4TWxnQk4VOwvjOmiYsKy8JKfFf0UdMRjNNee8a7Gos+Lz0axAppm gn7ysOQxQ8kqPIbJA7NKkJVotMm2uCS7CW+feFh7PDseyQLT3pOSRyhs5zisyNjZGu4EqszInYCX 2nbkTkAuI/cB3ojb8dHIhhi4E0wMKhVaceAewKt4Do0VumCg7vHD3WzcBdh9ZuMuQDMAs3EXQO+b jXsAbQjM+iiHjlm5C8ACwazcAzjyDE3flJbIGjrz8MA1OPv75EietKH1XmCGyyzfXmXReKqPolGj EGsGp/pQ741bgWjhqT6wxhRdsVUWPNaHVltQF4JNutAEyO294KzH3YGrYewuWuNCX+JKzD29oA4n DIQFT/VhnGCSujiOFjzYh3G2oP4ozG54sA+jNE7mo5F/51GPMYTCR8Gl8zezOPE9cdX4e8PMdvF7 JGL0sdJeJHzL3Cz8rdNOIMwF3Ko8Vyw0bc+iP8Issww0R7lVdGecozaeozYxGMIEhwqgOP/hUIrz IyqQ4vyJ4zDOr6iQCtMv7q9tiBZDp06x0mBQ6uRBP8OIdYr/bHTKyOs1j32V6KtEXyX6KtFXiZ/a KjGv3BfPd5Rll7BA3sFboaf4LPRbjuaV0VP4bOyqlxvEce1IwRPMcWM4431M8Blkknex/hF5bgo9 8fplZq6ggGFxDMiEvz3Ftc9QLO5kirg0acemcVEwowXu7+SnYmJRUT35Oqt9Hw//EcbDZcMsB/PZ NFOWrNnCvoDwx4Adztf8uAs6i+vsBOVrz2mhBDlTKT18kLj0GiacHjUplKGTEl5mg+gmtEQjDg52 c8zhOis4N7FCRxTBVby6COgvyp4WqNgXxIwNnUyFhMZ5SSHcHmHkUIPwyHlRizjZHsFKsmgRiHKm yZFzvvZHvt9/2v33ePrsDw/vLASRdqfnB3YvjlEAY2TAfz82HYSNMQiGX9NkMHojbNE40um+oA9u Wbyt3779G7bJnv6He9i3FMvo7OlL7+Y87ptJY9fTJ19+9ouHhf7yq899ONRlHrfTL328VPzX/6ks DM9UYFwuVODf5p3aXvLeHlUqMEyhAr/6DdRgL14V8/uqFXCbPWqBT3dBRv3/L3/1i304OLNO6+kf 9iGw18ite5UefMgiXzvx9idfhn+9f/Bnpv3/ktC3Z2qzjqE2nwXeiuc7n1HCLfMxUb/izsLvaf+4 R3L/Ip8Bj8HhB7BHMzlFxd/OL1gIpwHNBagY31+wYfTGtKAwTzGtb+H5gA0qtwF7BHpvsD4QCAUb duRyQnQMR8EMY5gL2mv8vTK/VqOCe3zwx3rGoyU7IfD+nj1NeNPATgu0a2DPLz7ULvw38BFb+LhN jl0LH7eDi5mRB2p2SWNdDHms0Wmc/dlYF8P+bnyYZ3840sWwtxwrAsiZjrUx7GvHegR2xGNtDDvq sRKCHflYG0N+fqTBYC9A1saE/iEFCHsRCmz040YUZrgLSJThLqCqGO4CqqqJKg+gYiTPMWqdoBlG 7gNspZG7gBqRI8lwIw+qCwbuAuqgIao8Rnx6WEUHzxv3AQ6AeaM+wPExb9wHOHjmjfsAxtYstu4G cdi/gm8L71/xb9QBK8fd36RGRP7dN0N4F1UisWg8MwfRpBIJNcMjd6g4aUSYF53WA23UiYRWocN+ aDXSiYRWJWUBtzkpRUKXkKYhdBkpRUKPLk50N2lEFtZ3LEYMFNzUh3FER7swzuhgFcbhMrNfLc85 wq1WQNLVzOQ1tanC+Auhcxp/P1QV/rpIMxO+PqYxRc0Nfa3UAZbdaBlO8tvnJuSpAZUzYebgDphj BwxrnHeo+3hWIt1MmLWo88OsRuqZMOvR2FmkcibOlxv5c0fljZptV3YH33jYQjtslJ0oaFfC/O9Q KS5m9I8yzlFQ8lDyDBkpva8YfcXoK0ZfMfqK8fewYix8goAZXEIBvEGZQk/yUR/YtYCepHR1u4BY rCKI+OcTX1eGoSGhiEKoUXgz4viiUb+f6ONfsgWR6uXWY4Ra1zBvPAdKcZ64MHGv7B3O/SVA+QOR WvjXWO/7KPjpjoJDUz6cGQa/QilLPqXqJO3Sej+j+sHOQcf52cM+G/qMwF6DefqjT6Hyl+8ffGLN 04f76Q//yXtCe5WVO93/7vNPlNoqlDriih6L1clU4nM46Unxn//6swcf6Pn0j8dFU4VHuDSFN75/ eOegrv/7+A10zYlvnKkLeJvIcn2R3369Mz99d4YlBhi/WPKIUbLFc8/fffXhY7FFLpaJq6qs7789 LNQx5vo4DpREe5opmq7bYJUn/DHgkbcw9PyYp/gu3s/o957zchH7WQPXXnw+4GvvUPR7z3m5hCe6 k6fHpywr9kUp0PqCzWIim+sit2IhqqqLiVW9uhDoPzKTF4Ts9TXhTl9U57ywEGoTOZJ8m/BIelGb TJTUnJqEuuf3Z+Y8iyryrW6GKLeAbUyUVMwQ5cDVcrJbiCcRL4S+itXyyUhNnsEw1jC+tRMQxtSU 0WuhW99h4wUaVp4B9osI3TiIcRYQee8QnkY2zsGSPDZOfvApJmsdfjxCQ8gNmFV5xJRfEUFIHcJU j4+RAV3uBYJrCLCCuom/T+LloMdyd3LRfH+AsxRFEfFPD8Wn4Ugbn74cO0htNOAcB8XBLzNhq8k7 VcjWuEzb6cNXf/n2qz887O0yr9uyf7w+i8a0zj5L7zswB1vt6S/ffoQr1mlcTx9++GH/y766LsaN p4/7ZzybYd72b4Z//eDLgNJkGfHvX70gs6LBA9sweMUYbsQ8+MiAQit+5CcDvjrSunrvOS+XMK8y /PzBWnwNE8OrV1YuYp+0VcoJ+CVynKTjMHEA0bkuqDiWEauKZbxooY09h/HPAp8X5XYMPU6FcCO9 qBBgw0MI7UxhCL3gbeqGUEDoljOrI5lZUqzG82HVD7MvgqojvlrOiehgqpCCrs2JWJrdOLTjxIGU LmRU8DOw8T2c51Oww7b6px8nbt3F7Zv4WXawcRYWFnQFReSTDYBuByHFBjCOHPgCmry/IWHrJnoT 1ECOVFSc5SDDpETixwUcw58poKVHIJjQ9Ihy0WnMOVmScWRNGugRjtZbvVXSVjkaVxhOwEwrJRYo jsJpnPF0A3rkl43DkGdmQEMFO2IqNzKW9nAOWaHsSLldMAQCI8rJwpi3GlTUQi60nFk2w2QTzo8H SOcTjIIw0sEKgyBEBJsrxpwMh0mE9FHEMTMl7E1z2DTFPZUDo+9xWt/anqpQWQwG47+Mf9ZfUrZh BH24eP5d6ekZHotPf7EXvpz2ao7To102e/ret8y4czt9+Li3Ctb4D9BcbnR4BNufG8fTd9/+8M2f Hvb39meW07/888N9ideEAcTdCDPTCzqBy/z/3/oudgplbmRzdHJlYW0NZW5kb2JqDTI0IDAgb2Jq DTw8L0NvbnRlbnRzIDI2IDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCAzIDAgUi9S ZXNvdXJjZXMgPDwvRm9udCAyNSAwIFIvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFn ZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTI1IDAgb2JqDTw8L0Y1IDUgMCBSL0Y2 IDE0IDAgUj4+DWVuZG9iag0yNiAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAx NDE4ND4+DXN0cmVhbQp4nO1925Imt3HmE/Q79GW3wmwXDoVCOWIvJFuyvWFbEjW7ig2Fg0E1h6Yd 06Q9GnnXsbHvvoU8IRNV/6GHXV1DEjMX839TVQAyASQSQB7+42a4LX8//9sbd1v+vv+Xm5Buxynd Pt1MI/56B79C+RHo329uvv7ZzW/rx8NDnPMQ5tv1j6XEv/zVuBT95uubX7y5cR6+Wf6ZhvDgb6N7 GP3tm6ebu3h/++bfbn755uY/ahO4PmlAbdM3N2GalwJCTg8O3kU4lIfJTQ/LWxbgi+XL3//s5tul muEhDVOOYWnsUm5OYWnlnx6/XT7IDz7CBykuJQteGpwLF6b8MPkNDO8Ld377upSE2XugxM/RtZRA SxUl/mFMuuUtJso+BUqGh3ku/WQJggZXgpZ6YlQEtJgJPISgC7RgWxUt0GRFS4uJtsNoifPgT5AC LVSkQEGq6S0m0o4nxbtxsqTAh4aUIVpSWjwdNcJG7IlL9AxmlI0P2bS/xUTfwfSMw5xPEAQNVgRF lL5CQIuJwGMIguZrgnL2YbQERbvcTKGRaS2Oxy03iiDnpnSCoNAINv8Q9Xq5wuE4wTZi8y8QBA1W BLlGnLWYCPxUCIrBRUuQa4ScsxrNBj5OyAlBC1/H8SRBRtGZhgfT/ga649ScERt/gZzS3kpNmh/0 8GogEXcwMeUPEFPUOEMMNNcQExpqWnzcUIPGXyQnGHqmh6QH1woTfYcQNKU4FfVzKmooaAj4P4Yg aLAiKFm9c4WJwGMI8mOcLxGUrDa6YB8tQS0+TBtVBOG/2/T4aOgxjd+g7BOhBH5YSjQZo11kVviw WZNy8tMFSka74KRod9IrPB645FR63JhOERTtznrBwVuCWnzYznpcpsiQLhMUvCVoyJaAFofDpMCa IOyzhqDBDLlgtYIGEnnHkuOKNDtBTrBqQXhw3pLT4uOGWzkuvEyOM8PNP2QzvFpM9H0qBEGPGYKg wYagaOmJG+QdTE7RqU+SEy01Ltn2t/iwhRTPpC+S48z0WbY0uvkN9FzLEeTQEeg0LNp0BHKgvww5 pb2KmqHR0FqM5B1CDh21naVmaBS2wdCyQdixlJQtdqEEB56lRJExzlZBazFQdgwldLp2jhRsraHG HORu4OM0tkqQm5M7SZA52R2zOeRo4XzguS4fRSlyQCgYcrI58xgney69wvm4Uw8+uUl857lFzmSP qRdsjjk28HHH1GuCQDY09JhjjwUb/WwDH3fsUelZRl4+RY/R18Zk9bMVng7U1/g46hw9yaprY7IK zQY+TmHjwxtFDwi8hiCj4Yzjw2wGWIvTgTpOJahIuBMEQYMNQeagcAPPh404Ovm4QI85N1xw0z9+ g7pPhBpYkBpqTOfERbHTzW/xeJwGytSUPeh4ghporiHHnOFu4Pm4yUNnHhcImpr+MTuCDXzcmW4l yIcxnCTI7BFG2/oN0g4hhQ8IKim4tlpSNB2NcdQKH0cK7aZTsf1yJ0hpDKYWbDcFa3zcJmGDINAT GoLsJsHbXUEDw4GbBN5QnyXH201CY7+2gQ/rnUpOHE9TY87cR9fscVp8oDXbyFtroQd1HkOPa/Y8 zhxJr+FxO55KTfl1kpymd+wOZ42P6xzaV18gx+54hmaH02J34I5HCCp/4IR6dcGD7TX0GMOvDXzY jkeso8/TY+zA4mw3OC1m+o6hhzZuaVHZIuhsqPRogrDBhiBjyLaBD9vwRN4apCIY4kmCjGFbbCx0 V/hAi93IynQlCHU5Q1Bjt7tgY5m3gQ/TqhVBbO26SZCx1Gtav0HaMaSQMn2eFE1HY0C9wp8AKWTg ilqpoaQxqV7w6C0xLZ6OWkkjK5/n6Rm9pcdsCjbweNisIW3tPDlmixCT2RO08ED7cCEmLmoOHFOj km2oSWaHsEBjtrKBD5s6rKulZcSF6SQ5xoolNub6K5yOs2KJrNsogkDNNgQ15vsLNvcgG/iwXUJk 5SaFRRtIJwkyFyMxWjV6hcfjLka2CAJF2xAUrV4dG4eKDXycXs3KTQrlDP4kQVaxDo1i3eIDHSwi awSpTKGysGbcOhiCQqNYB3tzsIGPU6xp4blAj7lJiN4etq9wOO4uIfLaA1PJAUGwFzIEeXv8HhuP lw182PF7ZGGdfJlDJwmKTQ+Z4/YNfJxKukEQbO4agszxe2xceFbYH3cIH1lYnyWocelBB2tDUIuP U7KFoIWKIZ8kyGrZjU/SBj5Oy+bVpxKEu9WGIHO3EK1TUgsP9FGKLKuTK2ZHJ8ixPkoLtIr1Gh9G DkvqVG7hRiAHdq0NOUbRDtbJqoFM3THkkBQ4R06wTlehcbLawIcJAyGHgzJskxMaeszZ+wY+Tslm GVAJwkOFhiBzGB+yVapXeD7uMF4RRCEatgjKVslecEPPFnnHkENC7QI5DTXGemoDH0cOSQFFThF3 DTXGlio0PoornI+zpar0bJPSeCsu2FwibODj9gosAE6SYq4TFuxty/0GYYcSIhEaMh5eNeQYida4 ja7wdJgFVeSZcpacxot0wWbPtoGPuxu5VaEZtmkx27fQeMBu4OO2b4YWPFJsaDE7N6vHpA2qjqAi 8Mg6T4qmY7QbtBU+SiBXUjgSwxYpo92thcaZdwMftlsL3CUXCDK7tQWbS50NfNh+LTAdEo8h40Fv Q5C55gmNQ+8Kj8dd9ASm4yxBjYNvaBx6N/BhezZFEIWYyHhy3RBkHHyD9eht4YEOvoGpOEuOdfAN jUPvBj5MwnGYjJF/5HHlYBEaB99gHWBbeKB7b+C4BRKSYYsc6w8bGv/XDXyYMODwBRfIsTscZ+90 VvhAj9gtglrnCmyvocdua9b4sCuewO7+Emhikx671xnslc4Ku+N2O4H9ySWOwQY9g73hCUOzG1jj w254AjuUV3rwEqshyGwR/GwvQFrMBB5DELmUi+f/BkHYYEOQ0UA38GEXIoEufRU9cIfV0OObDjIK 6AY+TiFlenjkbdNj9FFv/ZVbeKD7cuA77LPkWPflBQ4NOS0+rnPIG7uSg/dxDTlGF/WN+/UK5wO1 0UoQyYUtghp/bN/4X2/gw+yOAvsvXyDInB/4xmF5hQ90yA7swMzWLRkvTA09jQPzgqMlJ25Qdwg1 7O17nhoz2hpn5RVOx6nXlRoSc1vkNL7LvvFV3sDHqaO8+zlPj7lF8NZZeQ0Pu0PYoAYu5xtqTOc0 vsorfJzvcmDXWAkJskVO47zsG9/eDXycbs0OshcIMkfWPjS6dYsP9PgN7FUqQTSyX91cYYMNQVb3 XOPjdGt2xLxAkFVGrV9sCw90k1Xk0Jq6RY51k/WNW+wGPky8sSPmBXLGZOkZmu5p8XjccFsTBAYu DUFWu7aesS30B+rW7IgpIU62yLGOsr5xJF3h4xxlPfthniWncSxdsDkL3cCH6aKeHTE5KkhGY52G HnM26hq/yxYzfcfQQ36YZ+hxjRumy9ayYIUPdMP07LUoQUG2CMrW1MBlQ80GaZ8KKWBJZUnRdExW r1nhw2YNey2eJWWySo5r3Po28GFKTiWI9dFtgoyS46xnXwsPdPTz7IV5lhzr6ecaT7gVPs7Tj+2P FTVg42aoafziFpwsNWmDuGOpoZ3CNjVm6jQ+cCs8HqcRsBfmWXIalzjXOFit8IEucZ69MM8S1Hhc uSbH0AY+7ASkEsRbn22CrE7gGx2gxQfmHNogCO0rDUG+0Qkal7ENfJxmwG6lFwgyF4yu8bBa4QNd yDy7lZ4lqPG4ctaBp4UH+lspcmhzukWO9edxjf/OBj6ud/h68Tw5xjpsaDxEWsz0fSoEgYWyJmho PEYG61HRwgP9RTxfl56jxvpXDI0/xQY+TFoLNXQSsk2N2WEPjRPCCh/oX+HZgfksQY1rwtAYI6/w cc4JkFe4tL0pqv3CFKfrWdr82n3Q8w9Ty3v+4R0JukDL1PMPH09Kzz/c8w/vSVDPP9zzDx9OUM8/ 3PMP701Mzz/M7e/5h/ckqOcf7vmH96ak5x++7fmHDyao5x/u+Ydfk6Cef7jFPf/wC5HT8w/3/MM7 U9LzD/f8w69HTs8/3PMPvy49Pf9wzz/8ugT1/MM9//Br0dPzD/f8w69ASs8/3PMPH0FOzz8s5KQN 6g6mpucf5vb3/MO70dPzD8eef/h1Cer5h2PPP/yapPT8w7X9Pf/wrsT0/MPS/p5/eE+Cev7hnn/4 lQnq+Yd7/uHXJajnH+75hw8iqOcfru3v+Yf3IqfnH+75h1+RoJ5/OPb8w69ITs8/bEnp+Yd3I6Tn H9b09PzDu9PS8w8b0o4lpecfNgT0/MP7EdTzD/f8w69HTs8/3PMPH0tQzz/c8w/vRk/PPxx7/uFD 6On5hys5Pf/w/gT1/MOVgJ5/eC9qev7hnn/4QGp6/uEV7vmHX46gnn+45x9+RXJ6/uGef/jVyOn5 h2PPP/yq9PT8w6r1Le75h1+coJ5/mNvf8w/vTU3PP8zt7/mHX4Ognn/YENTzD+9GUM8/3PMPH0tQ zz+c1tQdS03PP1wJ+HTyD9cjAwlKNdVQe9zAWoHgCHlI5ySAWxJvH3V9EarP9Js50oKl9MfKLmyy APh84dlUfhJVgB6F4rGufrM8Fvaan4/Et4iFK67hilkZV/GouTr6ykghVG7wkA0Kxqj5zsmad86i jBXsmNx4q4I9cg5DPReqmL5fKmCpYrcMvesaXjpxLkT92z+fbVPNbmlmsZ79s7829eyWlBXqeYVc qafqeekUpraevTKLYi37Jvxs6tgpDyfWsn96TKjnFbJWYj37J5Ns6nn5HI8nKni51ItQwf4ZEZtq dktUiPXsnz/wRD0vnNbP1rJXtj2sZf8keKfqedncdE0tO6WMg1p2z+SGteydYA1q2TPvma1gh3Rk WMH+WcKaenZK3oW17J1TC2p5hVRXJ+p56QxUTTV7JYbCanbP1wTVvEIapaae3bIbYT07Jx06UcnL 5gIyleyXoger2T9zTlPPDgltoIZd88xgDfunfzlVz8tmZYFadk+W0tSyVw4TrGbn1CJNJTtl/MBa 9k/EYevZLT8GxGLZP20FVrN/NgmsZ/8kD1DPK+ReaOrZISUC1rBnpoKmhr0SCEA1+8f1x2r2Dbdv 6tgrCj5Wsn9weqjnFWLGYz37h3I/Vc9LR1iHel4h8DnWs388cqxn9zDhUM0rRO/GevYPqn2qnpeO dQ31vEIIalvPfpGhsZ69AzZjLXvHUYZadg9vjLXsHXXY1rJfMGCo5xVi9Db17BQ6F2vZO6It1rJ7 oFlbzXYN3y/+K9SwY1hWU/5u0VKxlv2DmEI9t7vGFl1X8YIhP8GDcddInLaG/QJkYj37x62Eel4h nCTWs3+Ux6aenYIvYi17x0SEWnYPVYi17B1BEGp5hcB+p+p54Xh7WM3uYfCwmt2j00E1rxA0DuvZ P5Yb1LN/iDVTzV6Rz7CSvQOSYS37xwlr6tktfBfU8wpRtbCenYNdQSV7x6BqKtktNBTWs3PEphOV vGwgJaxk//hGUM8rhB3CevaPBgT17B6kp6llp9g5WMv+IW1O1fOykWawlr0DwKAPz/5xWbCe3cOl YDW7RzGBanYNLnKqhpeL+YE17B+Kw9azV4QMqGX3wBVYy87xJGwlO4V5wEr2j74A9bxCUARbz36x Ck7U8+IhBLCe/T37oZ7dHe6bWnbyg8da9ndPP1XPy3qNYy07O3PbSnbzsYZqXsH1eanntvwtRTbO za0Ps3Fw1p7P34CTbWlxd7GFcruLrSrR1NBdbLuLbXex7S623cW2u9h2F9vuYttdbLuLra1vs4Lu YttdbLuLbXex7S623cXW1qCL7y623cVW19JdbLuLbXex7S62qk5dTXextZV0F9vuYttdbLuLre8u tt3FtrvYdhfb7mJrSjQ1dBfb7mLb1LhZQ3exreV2F9vuYttdbLuLbXex7S6262q36+kutlJLd7Ht LrZNtbqe7mLbXWy7i213se0utlRJd7HtLrZNtbqe7mLbXWy7i213sX0NF9ue9Pfm1ZP+FrbPYtff /Chs9wm+dxMp3uTgSPid4JBxs8XvM1bdO4n/aPND14PfPa3KJTzjHKC359WMuIaWGaedLZHQhEst vTmtFt6z5bvbf7sBB49hGG//NxTiLUWzrxT97qOLVATMngn42OKgc2mHWMkGcfYxRcr4oCIrXz+6 SOKjHoGzryPw44ucUA2jAqmzS3HV27/57i9/lW7d7Zuvb37x5mZZKMuKu/zFX2Hw5YbZjXDR/Obp 5g93//Ptt/duaeXo/d1X95+lYk7np7vv7j8b6ef7+3++ffPfb375ZqtEP8NcdXEsLIQSf/7hw/ul yOzTMN/96/2i4qZ5nO7+WAv/c/354e2fpPiLHJqH20XMw8Byi+KNv9/hb0+XUOUdv76QOjux6zdP trAC3EjScnlLfl873eo3T7awAjIdyiwv5fX5zNly81zkqm50kb7S7qvGG5ahm1fKkBZeVQb1COjw hYzwjG+5C+Fj4MdzviYO1OEADKAR8YwSMp2kUQncEaWEjeHufCi7qTjCyzDcP1+myvSwDPGU7MCW cf2XvxpPzshl+iySdlEliuzB8n59Pz+EpZBw9z/uP1uUw0VOzXdv7pcVOcwu3v1yeYy/vjg3MbHg ME9FbkDBvylTGr/8vBSyzM883f3ql/eL0u7dZP73nwpNpWJ/99fQCGhPrfqv7pfHYYjx7vaKRmTw O4FG/P39Z5kEwrcf7pftD1D39l/uP+Oq376/vfela9x09we31LOIJpfv/lmJiZBuRxizyw84op9G 9WOkGepmsHl0Gf0jCyyI7sPcjCI6D7gzKrisM5nusQrGxzAe3AyWgAsmUKbKRHdRBfsIeMSyYINS sM+Ey1Sb6L6n4DKYJryYcXPZaBQ0JoLBAw6e8IDP4QTP5WJb5Sa6BikwIEbBksuMKjAwLlyYyJet 4CKwJ7p4cHnCpYpitBQMi2N6YIhPHYmtwi430Uk/C42JNDiF+XHhmkAsjA69C4SlndySpCmRuiAX taFA7AKmhKl2HtZwkqfEhUBdsOCMa7zPmomBu6DcF8IKrbvAcxeAxV/BwesOpENUB80kTxTpfTz6 LHDCx4Ex8IBcPcrAAgbTESYPvImcJ8o4hQ6ixQ2H7UQnkW4GLcUlcoFgrJ/rj0fkgpSdcGhJ3Qm5 IG2bcGBK2yfkA5M24bgWyrPmScauF55l5IPwdCYVKROqOhji2df+8sOAXKD+LDjF2t8FwzAHVXtw 2Pk0UgpOdRz5wWPf0zgrOKhxWHAds34ISDMN6fp05o/HVGeEFI7zpVSdY51O0jSabgVDf9F0FLpo uhYc62RmrvBcX3DSooB4mivLYaiJJKEuYTmTWUwRz6dGTE0spkYzGkTMleNKFoE4kqp8TMCGKj5h HFbpCvb0SvrCQR7K5iKsf/+zm28Xya6YDzv15r0iT4CCETfm/DhZh6Df9jWirxF9jehrRF8jfqRr xOipL54ATiw/FFhGjkWP+tWFQ2tEpS7oUSZNdnapQazWjRV6xJ2+EncMNn6a90tRmUmpvx5lmUpz bUzFahUEJLMfCq+L3ES33yt5cEFAMyekn4jagadKwCFQ5wZBvkKjJfllFvc+AH6QA+CZGpkEUaGl rmBankAnK5hhjDW2CapkEoKEFlqJFkJaWcHERy9BPkgjk2gctMBL1AzSyAqOrA+Mqca8IJ0Mw1OQ blECPIjukQCK6uF8jTJBGpnEg0C1huM2kD4mARZIKSo4sFIU8fWB+6+cu3CsBNLIOKgBTbQCQ7KP ndefD1X9g+KHqv5B9Xz8Sq2T0QRtZyd9Ji3OPLiQdHauJ87E+UHpZMVhfVaKrrjIM9PZoZ07JWbu BOw0eVh6lJ3GobfZtZuHQpx4ZcOhwm7ZNJLIf5rHWUy8bOIwZL9nHqYx8ao7IpXjQ7Iws9IVmtdz 1MXBA1VdQrK5NeVf1dQJiZ7MIq1IzZoJeFMYebmfvGYf3ghW9uKNXGU/9KJ0D6lg3HuomUjXkgIm XU+KjQwN1MFk4JBexOOKVDAZdqRVybAkOSPDlpYXGdbqedKf06SQ4mnSSO00qbhxNOe47TQlmTSe sET5aFXTOt+JbyIOiK+jZnoVJNgpVdBgj1VBlLWUwr4WIYZDoQo4GClV/uE4qvIRx1kVnzgORbri MK3CF4dxjVhl9+3Ee1na5cWVyKHn0dxe9lWirxJ9leirRF8lfryrxOhr+CragFHfnEQh1a0bYYXS rRRbwGOtnk8zeS2C4xNZOVrkPG3ElACk3/wrmJ/1bedvVz+BRNm4STwZhcurdRkEJNM/JL1xkyg5 KwGBGzUtsmNWIrl2hBwb0qpJc4XG/nquVPOr377Y8t4HwA9yAGxZ/cTlV4A2wK3+cD/dPRSTAbzZ Vz9/ds48IMYiJkueAA8F3bn72zf/hnf8MuQoBp0PAzad5Xwg0QrYB5K78J+CeOgQngYS4lQWxcH3 Y7a/p4GkOb2nscACivCeQPVQaMhQJYl2Xma4+bKuyIxi63w7035KZG9Zqs2oHpZ1yYyMzXdB84wO FuFmHF20tyxDfYyZLXaLikKQ7VNHTxoSvezXweEu2I2qz57aQhHGZOoQeL3dqPrsqS2UYOTLDXw5 rsPBXqzDeUvIoi8IJVdZXVEhpqVLIdLUqwvBXsNJIvSI7dbFImpPp1gZ9qwimB968BR+8Oh5Fj8i xfJlfnDnlELOmXT6Ge59xhBJiP7h7h+/vP9sQJNOf/fh8T6QqdY352QxuTvXcu4+OzflApz9qrc/ f8OvnzN386lcM40u0NKhPtt6O4NYUa+fa5PPsPmqby+c+HnhxJQXJkdlQqdM2v7uLE/QfP3K+skp Uddfq/xf8us3Z2uEYEC6iG2bu88cdup58zviNl4flua//3COfxMocer1s9wu41S//OVXX71/+6c/ nWOQK9fUV5ZPjn717T/cff3l078C5cVM8F2xGER2/Nftfcww3u/+2xX8iHhQAUX+33tXInou80Tx VNkoKpvJ/7z/LIJVYryLi7rzF0u/4Du3S9eC5eLF79L2d//4m3v3EJet93z3D/eppBQYw93v/qLY ZRY70Gv6OE51+qtm1MGz9euLMj08Tg89J86TpkxDt4xSP//VzwvtSMSm7ej/U5acfoANavQUPMUH 0A8IvwMMhs6AC5rw7XJhV9HsQfdAPCdWW7CsmU5PaJVoIZ2OyNsKFxUVsQ9FU42wTa6/R9SyAHqK GiMUeDqeIAIlRA6peT9Nuq893YUDrugnviiGrUbBfB9Zik58tgGbnIIntd0rmA5Gitgp0CvbmQXf 4gFdQsP5iXFRJf1Yj/9mdAjQx3/VQQDteqKPD2zzU36LgdCIWAyEgEORT/MGYGDgwz7QrwvmI80B Hwc+GgYeBD5+BWOmwuCsDkwLTsoSijuAjl+lu/D4lUaUHL/K+JPSnJy3lo/ZMoPbMtTjVuivwZx5 FyzHrQO8r9jgxGIEjl8LZpYDEH5HfFn4Xfjvspy3Ihp17zmxdYHj14IHHgmFCU5MZWA7XLA6tSgw 8MAK+LpT487xoQfOqILFcGrE5y5ZzMevhQn19Qn5IMVNyAepzTQlIx+4pRnZoGx+DJ1zw4eZ+TCq 81jmItkXCZPp1FI6geyTpIfwzFM6kKybsHfpvFS6Hi2jZGTQAYOMHDq5kZFFxzo87ooU8VGJxSGi n4vjo2IRo7PXz0UI1QkhRft61uFznVDStMAHw17PRyEs8E7W4RyI9WA41clOB8EiDJinJCjwIFjE CHdIFTMziyU5GCaxJKfzc5VhOBiqgMvINJF/WQvHCRme6sEwcIFFa3rILHjNya1m9JOMbX6RzDKr eGnmwkdc8PUloC8BfQnoS0BfAj6VJaDcHdYdyzBie3BPcgrhDsVgQRDOk4v1GNSg1m7WEcRrREvE jFc3tAZ5tjCYkIOABTl06dDo8UZhsM1s0SyUP8rS5MZmrUO7zhXK/OqjWtccBvDj58lKaKFAJLa6 ptUdRfTzwJ/8rZkok2KHvs17kcW8D4kfx5DYOlSi5SAUtel5FyoRzbXjQCEl0gDLAOF3jCXPPb2/ lff+7KWK/e5pVS7jQMsMv8/42ksP+93TqlzGA4lefn9Yhyu/WE+Mlp5J8eWqywQuRDd2UkRfXQj0 ILVEKBqfcUMj3d50z7MKIXLMWJp8HUvP4snAkeaJJ9xBly5Y6CQszLBQwwnrn+7Z4f/fq8P/28f7 TMeeNejFl8vzu3fnzm9Hj2Y7UvzZU3G6cNGN+VY14f98+KZceEDoDa9jePz7VcEIInoglfzdI/nr /81CShhiGPUR8O/+uvwe7n5ejoKR5M//5uxFPxWMVlPPLXikWCJf/H551fk2IMLflZfx+PyLXy49 Q+fQn//6nov9/Jq2Obpq/oOu/fF+pl8fSu+6ZfwuvSs3D999+1f3RZnHC4Sr45hEcHAbHcfZx7lB WERKzITxdYFXS0j92dOqVMaBjProdYZXyy392dOqVMa8TaHX3TqG88VaysKmiZl8JeY6SUCF6LZO vrb16kKw7+D6utITrpZIqr9HtaQ8rxAixgyiyddB9CyOOA7BTRzh7rkoG1ErGocavuSZ4mhTIsKm uhZ6XiJ6EO+6Ce9E/FZBXEX2h7N1R9gaXlt3pBvTWvfTIjAwYMnbpxLeBESDCn309v2Vkhh21hGd bNvwLe+/+3C/9DNcDi7LznReRH1xW2QU3Gz++/u3X799//bbx/tyFVuu5d6eF43YihF0TmhFvaD8 7suvvvjjl+/uPVX0JZZaHp4vdYwUQ4dLXQT7OSaPcLCh2vC23AI7pOhfiqzGwDHffFASmOZloqiv MeAxUKJbroKLZoG4oPIQVGn5HYp6jjDMrN1hOQVjHE9ciNeYdunyvmA0AEeM+nWY1a9SzeMNQmrE u9r60QjRNFrbsZ8izdedJpcIg6DSUphRijhYMNpHZdhxDpxdLuMGeXDIuYLLmdJAYUgxSFSBGF8Q A1cVjPFDM55oDWR3VzAwaKbovxnMHmdKzJbRwnzmDGoZztIKxjChGSzM50wBdzOIhIIxQ1lGg0CO EZjR4G5mC7aMBnnzxBkBUJmfJVsXasezhNiEiIyzzYQ1pxodv9iXzjWFFQCJNYsPb2toyVlCTWK5 YzVIK5bus6RGmnnMDExGaVUkhhNRkRmOho0zJyJinnDCoIxG+nOoDAeWBuF4GSVzqBzHp467r9go zp45jtbFs2eORwA8MjxCYndEhnHqGhxJBSO784js5pwzOBALxtcT9hadhRYMnUv7N4Xp+YSM4M+n h6QLn5ANUnnGkSaNy8gHafyM45Rpm5kPifGUFF/mQTFtHrDzmafYZGE5tLB2CDaxdhg2qXYoNql2 OLZBxgM2oY4WrLWOJqi1Djaspo5FrIYGKpTZ/KYBLe+xoKNyeDZQNTRXuBE8k7iRPNOYBp6JTCPP VOYBTWRmEc9z4mAW5iN/54b/s/BfSRjqOJE/0LFKPkG/K/kF40LJNxg3VfzBsFLSsYw6JTxhTCrZ CmOWZK86UFbrCKjjGOU2Dlqw+EglxDoJnn2X2KV/l/5d+nfp36X/Jyn9i0TGvguzdCMJf4se1YtI b4toPYnFF6VUnWBB0csIwRUolyqISph0DFNeZRt6T1I9p5B8W3FFt7VQahtN9WaJk7YpkARBNHYj Jp5u1BsifH28NZIZMVWUou0flxQ+PSHqBeL3XLl75/9QO3/Thw/tFtBK52pvwDIGEvuUlbMKMLIS lzM6gkBIBxfkcqYQuJwxHtEuhksayRCGb69WmGxs5H2FJ3leUBTXUYUS1IyQ/eu4KPKpC+q3HFf8 JIm+UktHbYYj3pOyM42spmHejJHVNJwHE+chIlVqiqyuoKpV4vspTWyKVlPDsPpVk5s431BGQJoU qoAl7qDSECfPahh7sZKWhvrlxCl4SP2cRBKhejpp3XXiPDqk204yQ8kVU5ZXdMXkxZcU54nz46Be zQOK1O5J8trg4ySaAO4OuOuw7CQ7EdxaJLUTKU1LaiuSACZNVuKdCO5rkuxEkCuJ9R/aFSXWj4ip aao8n/B9z/2RWPPCDVnBk1edmVjmwX6uQK+HQkoECscSa4M0jtJYRSL4yLIymeVKVNQdGMa8N4EZ VqAoS4S1zl2/LuZ2qnBUuWvlYF6nGoeqW2Kd2kdFFul8QjUuAZUrqDIK03AfIAwlfTMpfVV3B6mr 0l2o6dfuJHWXextV+zoYSFeWsYKqfB1LuLjIUKOlXGTIiGzgcUoypQIZ0fSmDHgqiOcDViOzhVoh k4laKZONqJDJSEROmgMyjYlDMs2RgSIFiL8iJIj9LEOwc0TCUN+J+KG+FfFEfV/FFw4MkW44bqrw w3FVhSMMuyo7cVRW0YqDVlLJiIount1PvLucJIMdi5aB1f5Up8FHHNF04d+Ffxf+Xfh34f/JCH8c cTOahvCOF7Hsfwc+E6vo8Ubh4G/XyMu+5vGGjymnZFYShCsQBD3KIfPUpG2kek4h+bZiRkQblYvo Uc/6Zq2rLawAZkLEWr6xEuPpRr3AIrsR0XrkM2ekp4h+xidnhj6p+Z5LeB8IP/yBsGngPWGkKk4P VS28jb1Xxm/ybUK7qAALIpzy/Op+kRglVW2xsip2OOnuz++LydNw9/Z2/ONf3X+2CNDlT7y7/bxY K8Gr3/35w7135RVjIdRW40CSQzXv7z+LUMMft79A1aF+YQ226mv5wZZbivz266W9d99tF+zQCO5i yQ69hdR7T9999fbd9ruYZOFymZg5QLf3P+8nYqe/yoKMgj+pqp4XFKkMMLRLfLqJDhXRgQ4sCZcQ IOgIhe8Lfk5gpPrd06pcxo4UD37frfO/XkMPffe0KpcweXpKPYKvrwfjcFV6MJId03NlQCAspDYW C3HPjSpEPQiOAIoiUFiusw6t3Q6FKDZdXwiRo8YS7iR4LD2nEOoQKUQ66JogSUv/5yTm55ez9m1G +IEUA1LMhXBAcI+mKwVvgJIdkwPCPCc75qWwSiUaWxol298z0gj+prDixRIDnuMfbjh0M5Wl6pl8 gBfi3xTSRy85BquNauEB+g6oxirz/vrmF79e5Cu+qkisz2v8ps0wTL/47rt39wNY38Z89/bLb8+y Afccusk60eFV5IZZXDQqkZ//fWEbdvrf4m/wsPgnE3EHxckMRyZPHCSQ8DvAiWEBOQKKUSNP4QUL jLQH5ZIiOZ+R0G1h0q8iQIEXMbhgwiJ91ChycMHE9ddCZknZY3GNtfPTonhTGYjqqrNRBq4NyID3 PrwYQJTsQbz9MYQ2C3WOrz2wtz/IYPH2x0CSs3j7YyjJmR3+MbRAwejwD5EH/Ez+/hiWoECKcg7H DAVTlPNyKlEgBTmHZZOi5IkHKC4I7zhoeYEUYgFOTAqWIOeThyzHOtBtwRRiIQHA33AeQRmREfsM nUfxFoqyL8OuwDHxSEM8ZOlreSyJ0PBryYNGhUseNKpcEqHBt7rJEmOeSJIg80SyBJknlkiQeeKY iTJfoPA/AhT2Z3x7MN0lQeaxMzleLXW1xA2moSC5xmioSDxbGkqSq8whFziVGQzDAin8QlmtJQsa DOCCJcj/hM85yD9jeh4ezOcB2SJlw/FMrToiW1SGthR1yyPyRSiDzZuifNR8wbgSlWvo11u5igG5 hOkUrEv6BD38pcswrETtUYwOUHscI0vUEYGhBeqIgdASNJowLEEdZxhXQsYhRjVQEooEmKRRE9nL j3Ouc4C/lrRqAzJV3KqpcgmvMWOfcHgNareE18h28jLdKrxGnfnMMw6vMeHImmoPZCVW0KW7Sh3u MAlDMuLA5iAl1NsSw2RENkiMExotIhLjg5GY6FFB4hTOCZWsBauBKorxPn4QmxuJ36BY/8TDXd5r xU8zOz4igE9fL/p60deLvl709eIHu16ExF3zpHFh2oCbJgNol6SQfETpGDV6rGuQ02sOQlk/VqCE Zglqk/auwQp5C9SXETM1n0CTp9aRADDyAPOn8uy3aH7gmC5aeMhqW4VFjjhBlTAPaienVmfpJVpN ZdpkJd7biaGD/bzAst9Hw49gNGydCxQPdQj8Pfnn3hGMGHYICCpXcRR3iPyKEl7xcWS0kl6CwdW3 A/Wjp1WJjAPHYisvM7j6vL5+9LQqkbGj0254mcH1NZAJuJBBwWSIjOtOv6mQ2lIshFt6ZSGlv+hO gWi59lvpXkl0wKx5JglqwKATOg+YZ/EBO6Hywan7iLO3AJliIn5c5JwTSROylHghY4KD+IzxeTEq /oNVB0qnK8eXNfd4oOzhcn5Z0x8HznE+cz6YBUq4QipI4hMmjE+2whT9kF9niFcyAOmc0mFkREGx JoUpWHKpMwWSuYwojNrX4KdM+cWwLYH3LUUejBm1P9xZEIrkp8fvMr4+epD+7qktFuHS8FoFgusj +shHT6Y0+h1wneXXCD6n9KKO69bnXJt/ZXQcylceawnYxqs/n2Qz+lRJyc8Ixlb7VvXC84pgXqjR kuse+FmcgF6ovKBO+d0JzyDcWVTt4g93P/8Krvvgbu2rKn3f32f6z7d/ul8+Jml4NkYQ7uyq5nI+ ahrsZHVLvob7wHK/CJeyNWxPFcdVRP/X2aZAPoUrWxLL3jcFuburlKsl5+r76NGVm6Za3oVASXg2 omrf7T46ZjBpdGmQu+/vH1SNrTbgem2ZThFOM/i2rcCRL98wsVy5RiuO/ALgTo2gQ8srLsWRVS5P 2hUm32R5XzBeCSIuCF8uHlwCsFpAfHUorVf2Jwgkms9PidytMTTCgQUVcSkHHIaLXvTawoKPuuCk 8Kx+DBT20sGWdUSb3ehwbzuSxUnBZUs3kslvwaW1I+mi0SEjR88mU4Hu/AkUeTSSrXHJXJcB0mNk 1kimygUP+BwDOTng7Yh2zgUFhCNzt8j3kWwAmdsjO+w5PCSLbGQ14IlcRPtrithZYGCMT9FTcMAz skjG3QUXPkQy/o4DAvyNR2SR7MjxGWn85UOPwztGXTCNb4zxSWNaNYsM3AtOWQ0wpipVE7Woxhss /hyQiiyq4sj8xrHKc8DRLT+HX6TuiDSFHM28yPzGzow8RRypHpH5TYpUYKO2CECPokhxEwoGJlBc BRqDoss5VG4jxWSgIMIFI0zIA89mbYL5sfk4GZWIos6rusFmqjZtQq5wy9EOpVKVmStE9dxwZWau ENdm5Aox1Q+K4RgqvnYIhoqv/YVzXbqTkiRFBsASHgcUUlrGCcaCr+MIY8HXcYbWnDIMUcmXQYqK fR3EGOu9jnDaBvAE4MJ4cmCg+Tp5uDE8uSBofZ16TAvNTIqkLROXRB7PawygX+c9cVHkAsbjr2ID O6AKlRkFlAidmWUUTZJMMmrS/S/PhqyFHQydKgsnlFAiK3HkVVmaUEKxqMVhO4YmAj1F0iduP8nw 5xdX8qZOj49LQtKXhL4k9CWhLwl9SfgBLAkooSG5CnXGCQBpFwxkQKkVqMiM6SdU3WZVGSmxUIto wcBaBrwV5ozABQ9RamKEjTDo8UZhCFbXIp+Z7EdZqKJrVj4YHi0iEeA4AYV87R9wlbMyYkBrAE3D pCdA5Q9XTSzwdjrIdAm+llYvKl9ode9j4kcyJk57rdX8BGePBHxAeeSLpczzLjdTwOhtnEdjQlVN 8mgQFssQel/wtYfs9runVbmME5qF8OsErz0MN589tYUypAWKXyb4nDqiJiQa05nr4uJjGdJMLIKa eXUJ0G8OzsyEFhIZV5UhfY1lCHueUwZSooZPNDljnsMN6IfKDeqWS1edaYSwFDWnRT3ZPXuhmRLG HeQPz54oJ/BeVZV8v9PsVIIWXlfxCMEqhvCQdj7ITnFANSaK3+v3P8ge0erLhxFXuuTQ+CuQ2Vpy aByGuCDw+AGRqlAqUp4xG+xwWZnTLdEUWOGZ66L3FU4MCwiJ7VQUilg14kDmc0IGzXkhswpFGPc/ cfIvTnu408FSy7xHnZtrYTyQbSa9zvD6hUd99rQqlbDLtDHE1wVevyioz55WpTJOtEeg1xleXwts 5Awxo+LJldIWCjFtHRXJVxaCfUeLINPjnpHySvpbFlLi0XMKYY7oQTT6OoiexRHsjsoR7p7LSxAe sfjq5VhvWVXerHfK/uXc6oDBVWpx51cIjA2hK/9+i9OEAW6vrX5Ec8fqpLnjCgWG5C7lesv+Avmr wjDnUs/DyENjis4tOj4YJZBoQ2YUCY7qv6fdfHJ4Aoi4oBmfLgNHEJwaPN4QJtPsd1LWMDxo+aYR 2WXLuwYXMwXECXQJMupmIMIbzLM9HV0IAXQwIgQOEgyFpkzny5ovF7hy7Wn7iKuu99DYJ8DlEM9T /poR7Gm9Tw9ogISHwz5R0zLxlvLHjBnBgC8THRT6pmCYzRj0qMAidD0FVBkzWut7ipk0og+/95GN n3Cp9xRyqeAEkJHDtx2WhgY3ng4LyKTHU7inAste2dM5x5jhQcGeIHCBTsbG7HnUTJ4wycWYCfvI owpwAfAL3c65c/EJrSvyGZ31SbGOmU/VDsR9ahUPDG70wNwnogbuAKDZzcx/ZImbif/IMTcz/4Gf bmb2I7tdZvZjd7jM7Mfucvkhqt7kgBnc2W5i/uNgcBN3AD4k7uMwchNxH0eZS8x9GIMuMfNxiDo6 Sh7BqMpjtfyb+mGmmCPyKoX14KJmilHCNc1kaUENQVee2k703alEzGjmwTSir07lAfrqCIvmqNiH vjmVvWhGXtlPZv3SO2S+z51HjvPSt+htU7sevG3qyEDvGiVS8I6BBxZG6pBhh/40dVjOdKbDw5YF Eo9pfu71xzwVqGyeKVwzzyRuGc80ajjNQyaLpymRLdOYuCKznLgmUoC4ykKCmC4iZI5KvlBvifyh 3hT5hJ3N0ouGggg3Gioi/GgkiWSkkSaSk0YiC1YaqCJ2cRyjVFZH7wMoIWbZo/wqI/q8yScrwUPP P+5Sti8TfZnoy0RfJvoy8QNcJjL3UVkl8KQD++gkgs2QxYLKi1imh5e4BdTnsgrBNwbVNWSET1nm sQDErf6t/MR6DXq8UXg07xIiKeozvIs1urFZA0ekt0WRX31US56jfCutzMiOtpkayFRgrsjqSJRT t8lMsTOnHln+9sUX+z4qfvijovbgcxU3vLCvihtfUNOiGZ2st2ji4+ySGx0vucvvgddbun8eeMGl u/CBtR26KR+YN6gKxEHpCWFmhYcO8mfWeUDNCDMPcNRCwsy8QyUl5AelwoTMGg9qOCGzxoMaUMis 8aCGFCZWeVCBCtMDq3ETHikHxl5fMmQ81s166vExLz+M+sPE2g4VPDLzqd6RuU/tGq26GcYHrbiF yB2AVEfmP/EkMv+JZ5H5jyyNmt2B2U/dEZj92FchMP+xL0Ng/mNfB/+gdfjgReEHwNo+Hox75j6O seCY+zAEg3tgLY58CYNS1cLAyy9Cx6svLoj1bVwvuTBaTqUqWm6lKbQcS1NpuRY6cDFnKmmpFyaQ KiBMmqPiICkRwmHSMQJrGHNSXcOR77jrOC5erOqP6XlUf3hckHIkw4aUJxlWqFvJqCPVS0YlyRke tHyFxgO6Ps5Zfy5Xblg6TxaunOYSt22qGmhUM5EJ45nKhPNMZsbQPGe+sRhgps7SA8j0WTpBiRjq LpQ/1JcinLCnRXbRQBDZRgNFZB8NJJaLNM5EbNIwFLFKw1SkLo7iakVFepvlfV3n+cWVsKHnPDs+ el/fl4e+PPTloS8PfXn41JeHzD1Tt22IFYoagMmOxQqVwP9Sas5170ZGp2oFgg8NqotHVDs3Lfq8 FKwQfKrRo37XPHTpVhXrktq+hWG1BtYGCoj8ot68oXiQzZtIC9qvaQII61NDvTaSNe/s7UxoJw4v zrQ2v9Ay3wfEj2FAXGvQNVIgIjZOGsnjh/EwaeM0gc8zTqPPnlalEs5sdwdvM3qeaVq2VnbZGtlx si18l9EzzdIMGaPixnOMsLI15MrPs+PCPgMbezZK4yRjz7FJkyKYPc8pg7mhh87o69B5TiEpGYs0 7pjLBmkY2C3Mkn2g5i0o4Z8yhct/+75kPoBEBDpE1IfzxsvAZSn7guF0gHBENRzJ97Schuw2tbwr bNOce4UwIGSbNlUjvFcxTQsSIvCpmkLRbU4xq/KSw6SgCd6uPx0e/jIexDIYC3K08NG0auDAdsb0 tsbFAgsxGV2h/2oFsxcLLGqGMuVSFlhA3/Mt0356bHlBw7QSDmy2FgcURRe3iWCqZ0wOKLYXYuCt Mjmg+K+4Hy1ycLYmBxjeF3e3iLTFAYWDRTyU59bigMLDIoa0P8bkgGIP4z4cEvoYkwMKGIub+tnf UiRj2eRjAFmEKgcPHRFQrErEMdchRkcMBev7CTcrowMKyGww2xkYgCUpo4MJOz/rhiijA+iuwZyx FCxGB8WCNiurg3iLgaflrKJAMTqAzGnK6qB8nG0PZGV0UAZmZqMD7MCsjA7AJF4ZHZTuz2J0gOM8 V7sDAOq0guJx13GXldUBQuI/jtqsLA2A7GSAMUOoH2MAslo2biNr3RCIWlqGe9Daagw8XamCLWwl GgNNV6bg9ld4hnGlK0tx61xZjrGka49wAFdliOBrf+K+vfY2BouuowG2/XWwYHBoJWgwcd5c7RBg gllDhDpUMQB0Hdf83OuPleGB82rGcN3K8kBlKZOWs+XByLNTLA+8mszElVkZHsSsZAFxlUUFMV0k CfXJrGwPSp+JJMIunZXpQfBVjNGAECmHw2VWpgchKQlJo00kKI3GuZoelME629tLks8nbQ+CLGNP q09oWyfrCz/PpON+1Gl2XzP6mtHXjL5m9DXjB7tmjIn75anBeDJJC4YBjzcVgo2RfLZCj7pdZuFB rFaRFcKDySFaAVjxSdR+S3ZJgwxBix5lLctjbWPFaqmsNkuEHtVKmJWZkhEbl8Q4c4hXSmIC96tM ls3Jc8qE7QWUgT5WfpRjpXZqk5kaIiokCN+EGVaLNytktX771Z+/vfcDprj+6svlN6a+vvtQT67+ P6VLly8KZW5kc3RyZWFtDWVuZG9iag0yNyAwIG9iag08PC9Db250ZW50cyAyOSAwIFIvTWVkaWFC b3ggWzAgMCA3OTIgNjEyXS9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgMjggMCBSL1By b2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAvUGFnZT4+ DWVuZG9iag0yOCAwIG9iag08PC9GNyA1IDAgUi9GOCAxNCAwIFI+Pg1lbmRvYmoNMjkgMCBvYmoN PDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMTYzMzM+Pg1zdHJlYW0KeJztfW2TJLeR3i+Y /zAfZy5uW4XXQinCHySd6DvHnS2RazscugsFPVoepdimJJKST+Hwf3ch31HV3dO97FJxRVAR4jzs qiwkkEgAmYnMPz4Mj/V/n/7nB/dY//f1vz+E/JjG/Hh8GBP+9R7+CvWPQP/+8uGLv3v4pb48HOJU hjA9rv+YKf7ok3Em/faLh5++fXAe3pn/NQ7h4B+jOyT/+Pb48JSeH9/+7uHnbx/+qE3g70kDtE2p jPXNBvg4HWbKczvLdPBlhfHhLx/+5989fDV/ZjjkYSwxzI2d6ZYc5lZ+8/LVTA0ePcQyNwFAjocJ +C/lsIb4qPTKL/+6HITJe+DAT9FZDrCVzIFjOsjBAhJD3wcOhsM01XExjEBjiZFYDlEb3iLmahc2 LnEAzWQG0mE0wrOEyNBuHMRp8KcYgFYyB+4wGeFZQmJofxa8S6NhAZpJLISp0pc2LyBztAcLCXv+ PB/YVuYjouphPhaQ2NqZjzRM5RQj0WhYP1PRhreIudqHDWi0ZaMUH5KyAW1lLuLBmcm8hMjVzmw4 N+ZTbEBbmY/hEOxwLCCxtQsj2OxLjEBjiRE3HrKZEAvIfH1fGInBRWUEG8uMpEpFGVlA4mtfRsLo UzrFCDSWGQmHYpbsJSS+9mEEmn2JEWgsMTLUBkvDW8Rc7cxG/QfYqFssZQPaylzMkmO4aBHytA8T 0ORLTNSmMhPtbnYJkald2BhzHOuGcKwbQ1jN8b8oG2ZvG6fRzuoFFLb2YcSnOF1ghBrLjMRDsYws 4LjjJFdG8N8rPqCtzEc4xGgavoDE1veED/hD+YC2Mh/uMNiGLyCxtQsf87nbj5f4gLYSH8Ue9xaI mdqZC5fyKTaKngDj/BFvuGjRfue/NE+EIV9kYpStbizNuXUFx/22ums2cHSUDXOYjSXOb5iGL+CO h1llxFUddYoRaCwz0hzDV5D42oeRama7yIg5m8dSh860fAH3PJufYATGSBmBxhIjY2NVWELma2dG 6l73BCOjsTLEsRwGs34v4Z5WBrTbXmIEGsuMNPaRFSS+9mGETIfjMO90IzACY6SMGHPJzOIhm7Vv Cfc0mJDZ6jwf0FbiI1tDzwIxU/tyUY+3lQsUNOEiq9Un5mzOfku0o82HLVbnmchyEIw5HYJZ+JYw 73cUVDbclN0pNqCtzEdjc1tBYmsfRsjQYxiBSa+MGBtczI3RbQX3tMGxfSSzr2/FiLHBxSTkoOUL mPe0wa0ZgXkvfGBbmY/GeLiC046nc+VjlrFygg9jSowpN6veEu5pSmRjz1k+jFM2psZ0uII7OmUT G0kMH6DElBFjSYzJN6v3Eu5pS1RGqs46xYg3q3lyjX1kCf2O6zlZF87z4Yy5JA2m1cOaoe8JB7Cc KAcDNz9aW/QCATu7tr+e/NKJ9ke1Ssdo7dBLtKNVmi0K55lQq3SMudl6LOGOVmllw4cUTrGRzUYk NtEuK5h33IjwMVwZwZVQGTExMDH6xrazhDvGwCQ+veYaj+ROMeKNqSc2Do4V9Duaek4wAmu6MmId HmFqjFQLGPd0ePDx9Swj2FhmpDRGqiWcdrRZKSPz+nWKj2JMViE3pp0lLDuarPgQK3zg3kT5yMbQ E1qP0xLmHQ09ykf96xQj1gMVWpfTEu7pgeJT7HlGrAsq+IO3LV/APV1Qwkj9B6y6rdsD28p8tL6z JSS29uBDIm/P8mFdab5xnrUo7OhKi3xkyvMWK8IeC7crwoY3rjTfup2WcD9nWuRteq7TPZ5iw3qh fGjMbUu4oxcq8lZXGcFdlzISjPnNt26nJQz7md8MIxxZuWTEeqF863Zawh29UJE3u+cZsV4o17qd FtDv6IUyjFBoJe4ehQ9nnVCu9Tot4Y5OqMhbxLN8WB+Uy81eZAl39EFF2lmdZSObjYlLjflzCfN+ GxNhI84bEzDq4hZY+UjGGupCs4AvYdrPGhp5X5Vn6QrjKUaCWdCda+yfSxh2XNJ5P2IYgU2wMuKM OXRovIAtYq72YYM2JDnMa3k+wcZgnIJWOTV/7+cQPMUAbH2VAZkWQ+PFXKDdZgRvQXKolulTDBiP 5tC6/pZwP49m5HU71+lQF8CCW3dlwzoCB98Y3JZwR0cge2bP8+GN+W1oPZhL6Pczv0VeKWCCOGAE TiHKiHFohqnx/C2g8LUPI6Rgs68zZM0INZYZaVx/K7ijJ/AUI3CgUkaMKzBMzXWIFdzRFRhZ1Z5n xNyOCFPjxFzBHW9HKCNz64dyihHj05wftk7MFdzRpxl57VBG8GSojBifZpgaJ+YK7ujTjKx1s6sB MacYMU5NbLA0vEXTjo7NyDo3Vx9UAjbgXChsFPUMhtJ40VZwP99g5Pl9ng3jVAul8aKt4I5ONWWE L8evGDFOtVCCNbmt4I5OtcjzWxnBg7oyEtQEF4q3+5EVDDua4JQRuiq/YsSb7Ulp3IEr6HfcnrCi Os+I8Q6GsXEHLmHZ0TsYeY4bRqoSEz5G4xwMY2n2VUu4o3NQ+TjBQjEbrLG5iraCZccNFk/uUyyY O2lhbHyZK7jjnTRhQe7MFzT9KCPGtxnGxpm5gjv6NiPPhvOMGN/mvHlp9lJLuKNvMz6aK/MrHoxb M4yNH3MFd3RrtjygCU55MC7NMDY+zBXc0aUZWI7OM2J8miFPJlBsgcYdfZrKBt+VX7IBbWUurC92 iabdosYCD8F5JtQxG7K91bhE+7llA7ddbskXNIoqE3rHMeTmMuAK7nfHMXDrz7NhrgaG3LiTV3DH q4GGEbrwX9DGq4wY73LIjTt5BXf0Lgdu/3lGjHc5pMYLu4R5R+9y4JQFif8oqQnCp8YyI437cgV3 9MoGvlEuV+VXjBh/ZkiNA3MFd/RnBr5cfp4R49AMKTZbkCXc0aF5ihEbhE9tZT4aT+wKxh13JXwx W679L/kwftmQBruAL9COXtnAd4DlnvmSi0GX82i9sAtELO3CA1//VR7QlSNMRHXJhtjcaVzB/Ryz gS//yr3sFRvmimOIjSdzBXe84hjIsWn4AD+O8mEcmyE2nswV3NGxKXywfK34MI7NgDlMteELuKNj M7CH9jwjzizmQchByxeQ+dqHEbo7q4ygP0oYwcYyI62Hdgmn/SyHhhGa8ytGrIc2tC7ZJdzRQxv4 zul5RqyHNrSezCXc0UMb+NIpR2UUdBAqH9avGVpH5hLu6NcMfFfzLB/WrRkG0+phzdDOHJDaWrHA dxyDb/yXLQp73XEMfOI4135vPJne3mpcov38mCd4ADez8qBXHINv3a9LuN8Vx8BXHCXpwooN6431 rddyCXf0xga+4nieEevE9K2zbwl3dGIGvhkoyQqKb7013vr+XOskW0C/o+8v8IW6s4w46zlzrats CXf0nBlGaAVcMWL9Z651mC3hjv6zwFfqzjNi/WcuNmv2Eu7oPzvFCARjKCPRrOGudTYtYdxxJecr dZJAYsWIdUANjaemRW5H95PnG3Vn2RiM32ZonBwLtJ/fxvOFOs7AUDCcRHkwHo+hdQ0s4X4eD8/3 6c5yYf0EQ3NbawV39BN4voUmSRhWjJjLW7MAWi27gMLX94URiO5hRqixzEjjGFjBHW89eb6Fdp4R 4yeYZ5PVsiu4o59AGeE944oRY1/3U2NQX8Ed7eue79OdZ8QY2H2x1ugFmnY0sHNcq+ECoq2Ei6K2 aW9nQ/P3flZpbT/t3Fftl0lRGlP6Cu42I/gG3XkWjF3dl+ZGygruaFf3fIPuPCPmgso8fxrtuoDM 176M8OFjyQg2lhlp7J0rWHZUtmtGMIpPGTHmz3mltMe+FdzR/On5UuB5RswFFT82Bs8V3PGCik90 OfA8I8YA6rM1GS7QuKMR1LBBh8ElG1mNiLMUWovbCu5nRvRshT7PhjHA+bYe3QruaIA7xQhEuSoj xm41j16johZwzwJ1nl2B5/hIxmzlU2OnWsEdzVbKB9kYVnwYq9U8eo2CWsIdrVaeL52eZ8QYe3xT 6XCB0n6mHqjmWVtsfj/eRnlu9V+773vdz5ah7wMHve7nnhz0up+l1/28Mx+97mfD1c5s9LqfK76+ L4z0up+97uc92eh1Pw1Tu7DR634eTsBe93MLPnrdz17387sx0et+9rqfmzDS636uYa/7eQ9Get3P wwnY637ejYvU636WXvfzPoz0up9r2Ot+3pWPXvdzwdYufPS6n4cTsNf9vC8Hve7nX52HXvez1/3c hJFe93MNe93P+zLS634u2NqZj173c8XXvoz0up8tU/tw0et+9rqf2zLS636u+NqZkV73c8HWPnz0 up+97ucGjPS6nyt+vi8M9Lqfe7DR6372up/bMNLrfp6Ave7nPRnpdT/XfO3DSK/72et+bshIr/u5 5mtnRnrdzxVf+zDS636e4GgXFnrdz1738+6MPPa6n0uWdskf3et+9rqfd2Wi1/1cw1738x6M9Lqf J2Cv+3kHRnrdzxOw1/38zlz0up8N3M8x2+t+Hk7AXvfzDnz0up8n4LSf5bDX/cSW97qfd+ej1/20 /OzDQK/7ueZpHy563c8TsNf9vAMjve7n4QTsdT+3YaTX/ex1P78jE73uZ6/7+VdhpNf97HU/78FI r/u5ZGff9ve6n6XX/bwzI73u55qvfRjpdT973c8N2Oh1P9ew1/28Jx+97ueCq10P5pK4Z9QEY9g+ aoj8XUnNCnr+s54xlHBFL6ZVeAKpeMyM5744DEBF/3qhHqKW4g+1i+b/Sm9XlOOjMAnoRZksLBbQ MsLa1/VcTgA+8jL3QH1WO+xoOywsOlSwb5o5aocK04ljB6hTDJah+lILpZr+rWz7KPQQ5GgtHwLN +G1WAnWj2qSnCN+vZChQv0T4Qyt5CuG7F9hcU75X3UtIjrZdOcoF+TtXiUTqWxVvXFC/e01FoL9h qcNz9O9VgbClf//CgEh/q3p9C+p3LaOHtLeqbgfUNyw6h/S3qwW3oH/vEm1nyN+rchqQ36qg2YL4 XeuMIe2tyn+doX63qlwt/fsXy0L629WwOkf/XqWlFvTvXvEJ6G9YiAnpb1cfCehvVbaoJZ7uWU0I SW9V5GdB/e61d5D+diVxgP6GlWrO0L9XAZkF+XvXdUHym5VbAfIbVkFZ0L97cRKkv0HNkDOEv2sp j4bsfStsIOmtCl8sqN+9HgXQ37BMBNLfrnrDOfr3KqoA9DesdbCgf+8SBEg+bVUZYEH+7gn7kf52 efRb+ndPbw9pJrbKOo/Et0oGj9S3y9EO9DdMnb6gf/eM5kh/u0TjC/r3zv8N5LdLy43kt8qW3VC/ fxJrJL9dbmmgv1nKZ6R+/0zM5+h+1wTJQDdtlbcYqW+XThjpb5blF8hvmHwX6W+XE/cc/XulqgX6 G2aQbenfP7Er0t8u3yrS3yoNKlDfLDspUt8uaWhL//65PIH+hik2F/TvnvkS6W+XkBLpb5YnsiV/ gvIHp28EyptkVWwob5DsEOlvl4MQ6D9ukhpwTfpuGfvgQtZmifRa6vfNb4e0t0k7B7Q3ywaH1LdL 0ragf/fcaUh/u5RmQH/DTGNIf7sEYEB/w7xc5+jfKV0Wkt8oixUS3yS5FJDeLOcTUt8uFRPQ3y5D UkP+/omLkPx2+YSQ/nZpfhb07559B+hvmBQH6W+WqwbIb5FCZkH4bpldkO4mCVfOkL5PHhQkvl16 EqC/YdYQpL9dMg+gv2GOjQX9u6e+QPpps4wU5+jfK1EE0t8qfwNeGdgmrQLS3ijbARLfLAkBkN8w N8A5+ve6so/0t7tJ39K//wV3oL/ZvXOkfvfr4C3ZO97SRsLbXZ4G+hveaW7p3/+q8Rn6d7sBjPS3 u5gL9NNW92UX1NN9r7Ei9e1ul56jf69Ln0h/s7uYLfm7X5EE8pvdXJypP9b/VULmwmEldMNVxS/h fpxS6vfk+j25U5T7PTmh3u/JLT73Cv1+T+4E9X5PbkG/35NbfM2S7/fk+j25fk+u35M7STz1e3It /X5Pbvm10+T7Pbl+T67fk0PQ78n1e3IN+dTvyS0+d5J+vye3pN7vya0+19Dv9+QWX2vI93ty7ecs /X5PztJN/Z5c+zVLvt+TW3/O0u/35Nafa+j3e3LN107S7/fk+j05JdXvyQn9fk/OkiT6/Z7cV4Ye 0+735Jb0+z25fk+u35Mz9Po9uX5Prt+T6/fk+j25fk+u35OzH7Nx9v2eXL8n1+/J9Xty/Z7c8nMN /X5PrvlYQ73fk1t+7ST5j+ye3Cu0X7/wdvpjvazf96Osn/jp13/U7p/HZh6u4D0oBjJjI3zPsD4D vOPDAo14jnKnbPGHfoNeO66oMs74UXqakPnGFXzgW8clSYbRHwwbhK79gnv83QOEqA9Devw/D3Vb MPmWq9ErV599B5qGi9ELFx9EkYY3oO5hzskw/CEURUSIpPTtd6BJfFspHL1I4XfpSRhj7Uka8kpR r/QuXv3RJ+XRPb794uGnbx8c+F3qg/jXfAasqqKegeYJ+vb48Kun4/N8Hpo33+XpD89vcg2A8uPT ++d5J52nND598/xvj2//y8PP354kB1YKpfb05vnx7e/OPRxqI5tvf/1cDm6cVfXT75/fJPr2n7QZ 376Tr//ok/EsV34aq/6pG6L5A0D5X37x7A4xxHF6+ueZlynlFJ4++/U/P4/0X3/y/Gak//zTn89d 4Ocz0zg/y997fcDmI/zMR70tVkfI+2qfJfheIMdu8tMnYjkvqp72veOKLmEfyM9Ozwu+Wjk07x1X dAm7waFdh54XfP135rG17MAACjvXTRWgYZqKQsBNvZKGjB40xPDjr26IGXM7OLcRoR4RMcIOITG6 gQINhZCQoak0Gp0QqmaB2QN/uQgaP45jte3i7Pm8zpnghvj07XM1hblQnl6e59PvkKenLxuVsKQ2 wlxUaq1OWD5dXLWH229/+jxP6vnsMT29vWryOx+rUaHGiuLkf/r07QUt5AKcKs3jl3SWw9BxfXru m1lzzFO0zFv0ODdx/j1M818/e37jIHw0PP3jJZXpxrooXPv5EY4Z9vP6xf8lf/3i4gcnX/f6lkbV d/jmj2d96MIQ49Pj3P4Af89/XiJH3T3AnrMy8PW3FzsQHDbm8cvdDTPJPP35b37z9btvvrn0TnX/ l6u/MIKRRZ/+1dMXnx9/C8zXBeD985uJeuQvj8/ztnheIfxVPRIm8LYDyV+5uV9xUf232rEOBeM/ Pc7TCtaZ//vsahCw97bf/+n5TaFV9xd1OcQh+vPzm1iNY2N8is/j09/PY4fPPM7jD8RefS8v3ruC mXlehotL6d8/O3+Y/2M52Q6VsFN//brOIY9zyE6cG9s4H/EdtdF8+r/WhR03FTpX9NuffvKT2kfI hfm2PvH/rvh21bGzikeF9fs/zUoSO+bp3cWXE9hX9eXLoppWn/p2ZmiaZSU9/eUP734862PurQ+X oSt4HcBqu+zn60SNRON1GRIOGv36wcLhcE2+Sjg+uYZeBovJtcuLefyK5UWf/tXTJ7//+vhj0A6L kf2Hud/mf4f09NlbWCJrd9tOkSc/+/RnlWPcQt/YbSmJsDUfvPQq3g7TVy+zHOEetf3Qq+19fSNW RrC2sIGtxhBW84kY7QhH8m/w83Ht77hsCGjeO67oEo6F3OT0vOCrjQHNe8cVXcaZ4gH5+byOD3zl O7muWYYftI4xP9ftgpGIaSwQkcZeSURGEPawzJC/YU9vRj2bTruJBveIShLlxCJJuqlHMkV2co/w 8Kx25KtTevUiplj/nzRYpk3JL6pqmM+q09Of4+WTeQZjINN47WRuv/bp76uWnOdgzmcO46/2QAzV kIe2i+RTFQSE7wWCzQ+eWwb0XJyC/MaxJcQgOHDuwlP097WTQd85LskxrGqXqdPf11OHjTA3PR+E 86tEil+X9iEBat+VJHBM4KiKLNwyzc0wogOM++QWIsyGiAayMfrrT7tMAvpfSdBwVBInJDziGTcl XWhvn1M1mcO8RiqRi5OKZrv95D+8+6bueOBT3/72Oc2PhVievtI59vn8p/3JmMW+umE5nGD37n3G UGG6bEf4veCBnFj8/LB2ar1iF7fvHVd0Cbs8oiWCnhd8vW3cvndc0WUcR3RD8POMb7HBVy+L5ae6 N5if65Q/Emkam7w29koiNIIjxg4IR/kGO5kMOxGRbrqFCPeJlaXaJyxLN/UJDoj2CQ/QmVlbI+zq AcSBq5gtU28GOJTPZ+eXiytgRK+YvHx5CUywwNtP3c04XcAoOIGbYW1CMkecX/+kWh/wcKS7b/3r UzVUf/bZzbtjFwKGqZLxg/B7wYNvdseCb9wd03vHFV3CfBeEHj9xNeQabvjqyYIowcQOP9pWrh1+ 12zgDCewgRNObtkFakOBBjf0ll1xNYs5uy2ebnBVyWgTDcI30eD+UAnC/mAJumlrTf5GopGMu/Hi nhhjAp0flsv3V3ZKfl3XcjApfAHzqs4VWFSr9Rpn1kUTTb2XUDUTfuYVlQF6VFp0N30BQWbopb+7 cevX/wT/daaWjWLR309+wDTgk3+qDM3/NTj7XaOM2K3vWVYcbr08axsHawHhelN/1rsVzeIoCGT1 5YFxdPounGrMPrz52/PGg54zWGAFLq8QfOLlgTHnVpXmRw2f8EUxBir8cNnOHPqSH2EpH5P5g2M5 QoGG+An7hq6lVowXJ0f4QXLzjvXfaV788eLKCH9UTEYW2FFXjBFTdET3hWJByQyA8U4jBp142n1V XBcEP1LQyVhTI1RIj+NpArdMiOuW31OqhjEdMiC8xTeCsY+OIBVHHGOO9R4jdmJis03ETk4Y7DwG 7AaOqcTrnRWT1SocUCoKB4GM3gwJBi5ozmH+PdAlvdFjv5EECnm+rjoG7PVw8LZxfF+oJjwEODa8 ee71hDLLceHUNZ7+rkdD77jTqVeddnqVDu8OMkgDPj/wCHrMP1zsgA7c7TYVMkvDwH0OYpLcxH0O wuQovnwEkaswMJ7wZ4ruw2ngJFIUZ6KT4CnB8nuVAH3f4aGY6RcP8sOfL5CoSxtX/MG2vQTmm+Jg AwovMw6dSp1SIo6+XOONOPrcp3jzXvu8JBx9HpOScPTxx8xjT+HUmcaeYhIzjz1Fo4889nS1bDxk FaQy4uiba9HBGzksBUef5ZRC5VY4SlReylYTETm51U2f41lDjZFAZWorzTlmhackcSq3M6gjeEZz L/GM517Mh6aTx8UgjDoI3mqbEo0q4tFthp6VGEmGRIWi4IgOJLkSHUlyJ9nNUSxFwZLYogI2sY1G rTsMYCS1P6kOaXQM/e6aa9F9IegLQV8I+kLQF4KPfyEImJ2Bg7ERn0F0XGmxQRr4DuAFZlXt9DC0 ywniNRLwUpWYSsLoUA/AJxTUtxr0oo9iyxdIWHrhlcmV1UJnWqaocoHoRZc1R3eDzAOisL0RZIYi 53Q0lEHiRTLG16eFRsrfZzHvsvCxy8IJo1JKuMSnxJHaji1br9rtcrVcPCa+HDWiFyHxDSjGXGGI Hj9RcOii8bh57biiynggjwE9Ptzo4WleO66oEpZaEfj4qdIRr34F7DKGmeSVmavMpUzEtjV5bevV RHDswOaq/Fwfn2zGG2iYPrqeCDNjhSh5FaJbiEjRDyIiw/OaCTkHuB+QknpibncC5wT7BKFx0USc 0wQ6xnzRXLJQg/G7L+p/HcAq+1u5evEfV9mLsysQB1DW1mITovc/YrXmQsDlh3mZzn0ZN8TXBQfW 2MNf/6JamPGnr9998dvaFvzufxgjMlkptVAY3nWVamAJr3oQNohu2REa4LIdYd7pMS3e2tEcWULa NsrTBvvIGC7pwY6S/yr0Sf6+UggFt47CW5HsXCD9P0Ser7MapIB74sipzwItDhGbnwJuimPEzXvF oH8pAo2mR8WZYAYUGDp8Gi8tBlyCo8cVu2K0oudIkOzoGM6EJgu2udNSLWXxaGcutnzauVccI2Gv tv0EfA64mafjgoTj0XGi4oi0wGYRB7pF6jmaj8CA0jPaECaRJhpMlB+D8d60PM6QqPF40qdCoRHA lgTK78ANDSMNADESRgqnwt9CNh0QRup+6qBAUQrcgSFT/1MH10xHpv8DrSQ8PCFR/+PoBUqVxoMb EnU/Df6MvYoGXyViwQlUApMFi8sGsuAFygvBghkYAKOUCoeeqhhHQLH8DnMmEpgayrWB5sN4HNWG Abum4Zm49oRytEyPzDR1yohjL32GJ2nt04KjT12OUqAjAkKiA0YqSQaUFJYM+CyfIgkouyooKOoq SDgVVM5w2hi94rAfSExVzTSQZZyf5jnA1HiO0NdwAlFTZHZRU2XyVTZkZhKPMnOpD3hWYw/JnKcO FJ1A/Ss6g/pfdAqND6scGj7VSJndfjQAMPiqz1A2VN+h7Ig2BMlSXYmCp7oUpVJ1LUptlNySZEEw nQ3xDiTX9UFWKCBzvELQzzhJPsCU3BeFvij0RaEvCn1R+J4vCqwwjg/UOGacAFqwGvTyYLBvniUk 4KV+HEwrzbKCeI3IDIPf0CWJtB16toLYKU8ietdiQYWOUc4TeHngr4awWvhMC1VH0J8vtMTRq5i8 JljN8IquDs1aSJwzvjwl1KR8n0W9y8HHLAenQh8Ltbb6phpr8qmLEEN1B9YqaXQNYngenw7VCoS2 IvOnu+WGEfhK48Rl4LC3CYto1rKwAQPl8HnG1983su8dV3QZpxHVND/P+Pr7Qfa944ou40AeRH6e 8dXfqVujlp0SlZ3rQoqRhm1qpcFNvfIaD40fJjA07FwfHi1jTkkQtYuup0G8WDGqvLAY3UIDh0Jp 8NC8ZpeOCTYItYL0h99NGuuOVkhcvpk0BrxNKt/75pnv+50OXVZL9akwavUYysWZAfffchFowOgK xBxrukCpiUSNdDUBkztkcn+zmKwwzwp+3uAYGWP1rog3cRjAN+FvasJ7bX46sJPNK1xG/P6wmL7q bM4+UKqhJME0TsK66pfcwAFGFIszaFxX3W26QeO6IJJn4AgjPBy64ZFigIZJg7rAR8Z1JCh+aJg0 qguhBHXBjQRKTEkxXkPRqK664x4KRxjhyjpw0lyKfBpGjerK6E00cVPsr+Mgr2HUoC4Sl8JRWSgt EtQ1obwwjEa42G88JPXtjziaEtPldTAp4mvg4k/clqgxXSCOXFKdOeH0uhTzNUTbDZxRHAO+hqAx XdCLoY2kG4J2ev2ZM9vRBR0umMsjyGWeKORr8BrVBXxzNUGK+hrcwYYIDk7DujxAZyVvGLjPaYpK qXc0BAwmJoEwR88A5/I4GAaEGsXiyNeweJQ2BkN5uKmFfM9SFzEw5xIDRpxTBBKesaSnCp7BuCMp Akm6ucAJTkaB4pdklAqe/2QQMfxp4FCoZvQpckqko+DJU6SHAq8GU1pssJoED7YimhSzIKKLSTNF simsiwWfifG8wKgumTXcFp5VFNYls455GSXqy2UzZbkbJA82hnXJlKdeLNrno1eFwUPA+gR6gXUN j5/UtAmsi0Y7/qjFOB6QVRyJjqhADieUfOAgeaJBORqRFCzHnEhpukWU10A1ZiSWhQvmqVahCD38 nefDh8b79oWgLwR9IegLQV8Ivn8LASlmNFUjNiiXBXqxz5oAUEV6JnqxDWgWFOfw6SWK/CgFeaqW w2BN+so5RC9abFDlTFUjh3lW64FtG+E1KoWRCfMcsCTZUj+wUl4r6RjbceFhigbJtGiniWbnWAT8 fsflvIvDxy8Ot3jNq1FgTGS7QytzxZmdlwUgOaVA/VTMrk4whhpXaAY4sqM0II7Gr1qxZy85ZJo1 LnMyRqHPtt6FHtkTii7dismuDaaLkc3n6BGOoz+wQ7hmOR09+6IRBHaRV+PH6BtPdBydeqKhEzjb E6bvGh07ozN2gmNnNNlMB3ZGY0rZcZAEV4gcvw3WmokNuUgtT+z7r9ugCqNtS54O3PQEFhv1/kNS MzFzU2qxwt5/7Idc2P0PL8ZsupAz0ZCXXOxGPAKZLq2gl7zCwY5ezuRYgO6oMLEs1F7ImX0N0LsV S/wF9AOHJKKbvOKsgpc55BBdSBU747mIObI7MwIgX2dsfsEekTdBOg3liD2SxNMZo21Wwk6RZqPB TtmCdM3KNWwztFMwrbT2Wd1umB4dsU+4x9GFrSOCPmAaLfQp6VCiW0aHGj3UKgpxMHKCHmkRI/RJ q5SBD1plEJ3QKqPodFYZpqQBLOGRsjbzBEBqMj/Q4a3zh9rC0wt95jr7iA+Zneg219lL/SBTG7xV MvGpC0UvoNtc1QaOgGiVQOmpJb4ik4p6FJ+50Vc49qMJsIBuMQEWMVp1mA5WWaLgqS6N2A2iaiPr 4XUYFXa1OFzlOXE/0UjQz7ktidLXg74e9PWgrwd9PfibWA9kJCR0hkbiLDKhMwgNoKgwAS/05dys KCPGCi4AjEM+mKgZIvKeI2H4C4oW4MU+SSmHLEKqyK9EzdTZvFjvXH5cokjPmZgZUgPHhU5QDZ2j wSLvoVkCZYnMJkrGTA6ZDCY10i/vtZZ3EfhYReCPi+fqla7Iaz2+N0bU72h9rsb1BeD+AiSGHaIj Zr884HWrFXb6HUqSK3iQ39MYOLtxtQwrivjpwLsb82mj64V1Lmz0w2b90l3NmmS7LpTTQKVCrgic q3e2Q75j5JzHcoExsrEP/U+ExR8VPYVS8vOMb0kHqu8dV3QJh0ymbnpe8C0JQfW944ou4zBpUv76 PONbvuOL5Qd0jvBzdUZPX2xjMVUBN/ZqIjSCMLcMR9dfDTfDjlketJuuJ8J9orKEfcKydFOf4IBo n/AAvZ4uH66i18TgY74QQJcvJ8zH3ZkQuZz7EzMT20/eJ2s+VptKHG2N+0svQc2IB9oh8PPDuhj7 azn0zXvHFV3C5GiU7wi+IaO+ee+4oss40zUDfj7fWC6jvldPEMoPnMmYnWuz42OlVmlrPkRt6tU0 aPwSBrUKP9dPKTPoGE2qnXQ9Ee4RlSTokZtUFfdIproe1CPZlPU4mWmfAhydVHm8fTLiYVxpvJJo H00a5ot3S7RPDqwwjZrVtQh+z5laCVdUrW0zqsdARZ6SugKk2HshhVcpWFaWkKcGP23wLNyEMdFr fbcqJQHBU2hppFYYOpn9x8Rgllzf1iP4A2T8hrimyPnBKXyk4sjhJLVbBsmJB4a2wQQ1xUFy4qGF bpCceGjBG0xOvBGfp20ThfUONm6mQoqbAfPhIFnx0Lo4SFa8jMXqJCtenWkVcgRPQBg4cqng047D g6DzJZkRrtQTZ8XDcKKKGUZ83HG0EcqMDVUSmeLKvDRi8nPmWCUIhNIRZOqZOx03MFPWWCVonMZg hSlxpxNjXHsaI7gq9sV0i2xVwRrIMkqdShX/3nP4mEg4jQmJ5XuOPhMZpiGtmCQA/g5GHCp2LA7Q C14jlRBmlizoBH9gOOHPErcEfeA0vRQMoHHAQz+4xhNtfqdpLu876Bch77Bf6OsYrKKNw2AWbTtG uihvGAmjvGOkjPRLiabPMMRG+xQjcLTPIUBHhwTjd2TEMLxHBxTDf3S8MTpI5QGjh1ReMLoomCyH KmcYmKRyiHFLRtNU+6SKMfrvSVdKVJTOAn6dZwkGVekkoq9zzfoRB0jyUlLDJS8lLNoygZlvSUuJ URE8/7nXJu100FVD0+mqXXB7pMqnRFVMGMamegsHW/UaBMGp2kNZUbWIMXSkM1HOVJ9i/J3qWxTT qBUr2jgnVCkSICPPLTWOzg5bRq0vC31Z6MtCXxb6svA3tyxkLCFPUYuEzyA8zTTQgCgJTglJtCOa cWWSIVwB/hsjHVUMMF6Rv6DIt+BFn8RWL5Cww3GOde4upr60SgFNem9iHGnSS5CjKgHV0zb61Eg4 dYeMDi+WBGkCnJkQq7DX77aodyH4eIXgooslxUNk1XRrolusVe+o9ivnF3UUx0A4TBR7T88Lvj7V rX3vuKLLOFEABD/P+Po0tPa944ou40B3C/h5xrd8BwZJ+Ik45rdUBmUi2lgkwo29mgiNWIZ0t8zQ tQTMkJsMszcQIDaMDOFSyDJ0U1/gQGhf8MC8nuh2xOX7cgHhiybYnEY28L1ugs15wF2YfHCLNLew sRsljciZRLd5k0S3bMfPV6a6zdenuk10fuE8dmXAfSNtWSvWU0VFeqYwaIAcM4RHqrjAtEZKF16d 41M+gal+gzzPuB5YGVYQ1iiwr3xiKy9GbTEblFCKuQxckxmjBH7IzF8ZoYvJenAvXqN/Au77Jw6m C3RSp1i7wBt/iVGgjT+69iDsh48JFMEghwgK5JNDBsUByiGEIvlkOaYwQt5qUSSfrN41AlHOOxTG J+chCl+U8xKG8YXJxD3KOYuC+OQcRnGTck6jKD45x1HYJR/zKI5PpQo9WZNkRaJToGQ3w58l+Vlm j0O2tCVzGn1bMquNfPgtxbZdErMVPv1atiWrG/WKZH2jXnMyArqVlf52NqizrrsS8wmjxfnoeDQl WR2NtiSzI2kYVFCKZMFDOSqSJQ/lrEgWPRDDwonASEoLJ5aqA0FHWAspX1/CpFL8MIyyoQVSYD6V 0VMrTQGJMk3NxDYA2CUriyOzTF0w4tBLF5VDtD1YdCtc4cRmD+p/mvYyOBMOPQ9eGnjocXDT0Ax9 Gg5WMJLDoWfBSbRNZMFKVuoS7atVw1ivmdGrKNLJN2YReZ1nRDKzhb/Lk4nbxZONms1zkZniucpM Z9sjPMm5x1gJcI9m7f/caJBifHgyWqJ+ZJ+Tixls0V4kCKLdUFBE+aEcqWpEOVPViXKoqhXFVDUv SDHZSDRgt+n64wMlReTnVsqGfi5tXrK+PvT1oa8PfX3o68Pf3vqA3q6A6lpQDTxO5LpqEZ9vGswv 4lHIghf6spjnaYkhTOvFSfTC150a3afYoKEskHkXm38OZWphXbRK0SYCphzHtCYKKvzoi1nxUD8c V+oikDNDWCBMU0GGRUaJls+wmCn5xMQwlzvuss53efhbkIeTKXLx3uAA3uZXQ/0dukgjONLvmyW3 qFGV7kKKUZWxp6WTHmd4S45cee24osp4ICVOjw95ZTa/hhd87biiStiXrAl/i8JbvlJHwjIzemXm 6uS2lYht6+i1rVcTwbEDqWZ+kobfXhFLLONNNTKoj24hwsxYIRr9jZZ5IkLDIURkeF7PkTvP2FBo Ln1QTDHeu1Qir+TIhW23+eI9cuSOYn6s6WIxaIbNkRUXMVfGASNP6JKGIrA3MnZ4m5dJObq+S5Kz hHQvWJ42uOpDxNUBWdctR+FIhCYM5SXIJlbhQer/Eo+EbTTxD5b3KyPHMKIGo8DEqU1hPuwnpSgg DegZpdQ55iUaTSzQKJXOC9q5pdI5hhKNUuociFB0koYhjVzqHN6jYCaNYhql1nl9jgLINAhqlFLn GFk2cqlziKAapdI5RpaNUumcBCFqJBl0g5Q6p8quXD2VxiRqJFk0csWxYaOpdI5DyJFi2Rj8hZqp dI4DHJu2mELnMGTeMiLhexgaNppK59ANEr6HsWGjhO9hL2r0nkdokyFWTH2OP9pMiCFL7B55qzh4 D4c/m0rnER+3qRBDltAgjA3LEjoEkpc5sAj9/bloqFfthCxhSRAJliVqiaH8WqJ9G7c9QhwDw/TT GBimTcPAMGk6BYYJayUq2xQYlk3M0uhNr2FgmPQohThJj1NkGA8IBUjJcFFgmAwnxVfJcFNgmIgD RmdJ4Bf5mSRQLHgjZxgYJlJIIRBWzyQjxKpaJT1YEuVpXpeKwUhdakDTx7XG+lDMfKN2mxLrzXRl tqXGOnWL1lh32egC7tSsYxCtKqExkRrrUV2+OqKj1lg3SoxEQZQcicpoaqxDN3CMGUw+U2M9eKNd SUxV+YIUj4U1uwkj074/cvyZPMihqjo2+DvPjg+IL+6rRF8l+irRV4m+Snw8q8Q08LgcH8jTwFce TgMMHG2wQeif4D9f5LtTu8jQBF4hUEYTfUMXKLlqEcujUXmEYlygF/usf1yB0TPPL3b2L5dB/7gC mR98MQteHjnctNUUqrml/TakR4dERoiWT5k0yT+emjS8PpuQ4zus9F0YPnZhuN4rj75Wnw6YswkD JD1nBqtuWi9pw1C4fGw9317SJEyUoeJR3cM+qOsb7JWhdX37Jt9ZhY3n23O2NFTN3qutPAJsTOVe 7MVotfeSqg1Vs6dMbphKr0JJrQedwIng2DDMCXQCAvJ7Y6yt12xY0Amccg7yAVZjDPm9UTmzncdg T28PsYG+sGHnPeeQEjMQNMRJHj1cQZzk2UMuHPdA/VsS9GEHOEngh2uXkwR/2IFO8v/h0udy0/1O sgfiyukkuSAMnpPcg7juOslNiGPvOHUhLNpOEhui2DhJfIgC7SQxIoqd46wfFC3gKM8WiayLGvtR 3w4a+uHbX3MxL2MOb6UN0QLyaUxFpk2jaAFpOpYlFcYoWkD4xjqk2i/kH5JuQ5eO9GpMOPq5iR+Q MYnZDBg5fWVAY8bBH9vgAcf+5BiNpJC/WSQpFmNdFG+1SGEsOPqckxF93yLS+vNkfd8yI4g6Txhy fst8osbJZEPnt8xFYkzmKjm/eSrHbKY5eb5FDVCHipogz7doERoPVjLkUhMdRMMpKgpjQ0SDkTCI hqPQEm8ESVQjhaSI6iQxFNVKIS1G76KG4qpmkmVR+h7W98VzlPaWflYyPBk+IGirLw99eejLQ18e +vLwkSwPrD2ODeIANlwZWvTyYHBNLynvNQCTnOJ88aldYDxVZZfVokX4EUyk3ei+QVygZ9Hy3dp8 Rb4FL7JiuaAtVGwWRECsC+jkJg+DOjiutINq56X2NrrEDtLY4Mk6hA3ktVnS8d5jke/S8PFLg5EF 8qSk4totQMEgV8QVjTLICrDXCEduL5GKJEfZoR1iiRMpZnrcQLgHC1mTC4YAYV5kBJFlpHCgQ7Rk dDkQYe+Mv5aVF9ZdX/e2VwbqUaqL+wXqZVgMXaYpQRePCctVbRdp0aPHGV5989y+dlxRJczB1fg0 o6tvg5u3jkuSBNndgs/mGxPxZtxYGDZguRc2rrtjjUS0nUCD23k1CRwzyDoqzFyfptMMM5DQ7rme BveGig72BovOLUQyZeAlGvnKBLw5zH8lOB7AjNCQPBMq914ufOvVb42U+8vlu+hwDtJPvHoZvXaA adDPngtd9G7yfErs3m/0T23ca9lBz3WEh16D7/758+c33BUaH6ifgCyk/1s/rn307rpL8fV7LkvM sLmA/vn7ekU9TC64pz+9e7XRA6zOQOT4+bfzsOBF9ZdnvkD/5eUBgpOnUnllgGDXbb/5+z+8+3r+ 7HyMCnNPPP3+a6M5PZSd8SlBgLzH0wHC9zOEsx5CjycJjxnTDXJ13SDMV02IEN8s8fWSzhLRlRV+ 1ED+0eNRdDJ/VfIvDwTp6++13XTkZa40dTPM0x8gs9FVu8TMbMIgTIfXvCqsUZgAfYJMeQ5MFgp8 dXkhTI4uUREZqTFZs4sP8QSma1XyvMFQQABwRR6fbgCUsyRMLXmvHNBNM+ZvklX6h8z2dZZR73H/ icEfR8AQzUFePu9h98eO1QpTVndixUMhD+IMHR65Mq3rFcPnWfQdHg8y3TfzDo0omeeNg61hxnfR gpJ5Zjg052S66FYx/oy94tAUlLmMgkMLSsZbdBVCPA7dsPMOjSiZLpZUDP1A94cqhigXusHnHRix Ml5LqQhCZOj6X8UD/owT0oENJdPVQYWREHQSQ6LFkuXQXJPp1qK0hCXLobkn061H4cTREGQob0D9 T50wcP+jmSkP3P/Yh1wSwqGRKg+m/xOLmUMDV5q4/3HsEoulQwNZmngAcOwTTTQHR+5Et4RYcBLd z6oYbj3QjSSSu0T1oqtYwmkFy0mz1CaqNu19BVSaGgHVpZ4B9IB5Em9TMCFwmutn0N2urcDgM20l RropFxh9xjxiYR3tAixyo10Epem0B7E0nfYwlqaj7oe6dDo0WJdORw4L0+nIeqnKgSPvKf6MpALr 0qnQeIo/Y6GC0nQqc57Cz1gmsTSdiGzA6DOvy42z4s5v82zwFNzGs4U/TpPJS7qfEm3TeSr6YuYp 883z2FOBD5rm1GusBLCUoCoJ6nHRIVhKUHUMDVhmQMqKhiCysoo82tHoNpIV0X2e6qKQakRJU8WJ h3NVrCinqnepGgAF5YlttOn7Iwo7P1Q1S8hmYOy0uNlp1peGvjT0paEvDX1p+IiWhhx5aI4Wz6eK QDHiCwDlCFts3pv/Y4teZMXRFQZBnXggZifQC2g251u9p9ig+m6DmnebHxuARyX6asrcPItZFbR/ vtBSB8+NmEay1RPnNLYT/aJDQ1wzVvF3+cR0UGfZd13W++h/rKN/y3ZsNPX9aKGLntUbOkx81FW0 ALSLaMWyiNbE3l42MXUNrtBszioMvMAXfNqZBT566ZWCtflYQnGDULHZPFToeL9Wf5VtDOjJijNv yGotBi/bmAyAtzzQC7KNwWJ0XrYxCbtBtjGYfMPLPgYTbvhBt1tqSYHBrTD5Bg6xfXqwpNiSRF9y RbeRA9qdZBtZW+qKbiMrJ443GA6B2ZxVGLLpISdCCR3oeFtD/ety2/0uH6IZHZe5+3H0XOL+x9F1 ifsfR98l7n+QDZcOLElVclzkxQwly0Ve7EDwXOSlkBx5kZdKyhnMCiS6wCsugpE3Y2D04hVx9JaG R6OdfCMg/1HX29w0EcskCgeQs1rYo3K4wj4VxJXuwYLy0ntUfp47l+rJS99T9XoZGyooL0OHuxId WqoozyNPv8l2J1qR8WK7DLx78kbicDMlAkn15EVeUf2oeOvvo30dpwaSlmlDX5ZpRS2TaUdzcLIs 8ZQljmU6U4/IdKceE3VAPSragjqclQkOh6gaGi1RRTSaoqpwsEWTkSiwoiNJETVIkqRqEiVN1SiV HBQtS4X/WAmb8pGLIzvZb4/tQ7S2q3HXzogPOrL3NaKvEX2N6GtEXyM+tjUii+I4LjCd0GiVaJGc 32jQzJsr9CJf97YplaauHCskZ7BG6yk+i5bv+mJ/HeICyQmuznDPikExT/72T3OCq5qA1lfH2viC rvbNIBHHjHUinJwYy5P7h6/ufew/zrG/cU9G+VvVjTI1ezJJ/cpulKndlEliS/ajTM2mjPMlshdl ajdlkrSWvChTuyeTnLfsSJmaPZkkzGVHytRuyiThLntSJrMp42S97EWZ2k2ZpPolL8rU7skkUzC7 USazJ5MUw2wgK81gS4Zifre0mzJOcExfLu2eTDKHcsNLuyej7JjKdGm2ZZSUQfusNNsyytGgPV7a bRkWjJPxKu2ujFI26HCXdldGKRxUWEqzLaN6ciprpdmWUUqH9yKppd2WhcL7K2C73Yzpj7F5E03a xWzGvP0u2sO1XWgvL3YvpkyRsb20ezHtFLLUl3YzJl1Khv7SbsZ0RNBPUNq9mI4neRmK7sVUFMg9 Udq9mIoSeTdKuxkTQSTnSGn1jsox2ohLuzfTWUCvT7o30+lDX57avZnOPmr51G7PZPIS01O7PdOJ j302tbsz1RvU5ZPdnanSofGa2t2Z6iwa76ndnonKI2GZ2u2ZKkxvkvPK7szoW88VLcVDOJ0+wdNA HNuHjPKRhVVmxYee4Ptq0VeLvlr01aKvFh/papEjj8xxgdnbWux5jpD6Yos9wa3RmNkXO5nzHBWB MGtIi+yZrFGHhPUEt0bLd/U8x3w1SL2xpT3PEeZVsv3TemOL+MGLnueaVmcj/N43a+SYFeq8WM4T Ey/9yzus8n3kP8aRv35nBorG1+om0L66zFRk1UzFzixSfpJ1AvRMxdmscRUb63WFzqyPfpJVygPI zGZCHHmlrb056bpdUbtsVzyaZb3iaLaIFXveBQR4XrcMfuJ1G7cUFSfdIVboeX8y4eOD2SH6yR80 prCiZDY7FQfeIEZ8euANInSK470Tvu4O7CCCHnW8daJvO928wogMunuFpg+8dyo4nsOhYXvgzVPd KfsyabBr7bUyabQrJNifNNoVf+ZIkDoxSuExwBErhccABLXiWMxwl6I7oNoTHLQI3VRGXrnrElVh spJWRp5tsMLRBRTeD9XM/7xcZoSJtzuVbS4MYLD8ns3bGXtBaGfsBfl2PhTbtBG7QVo+UjfopsHw XLgP7KbD9FnBbpA+nQ7e9PiEvSDjMWEv8HjhlSgZTlSoOtrBoZyTMATHwpAZl2hkCa/nq6zhnXmV RUiPI5KK+W5UjjG3jso5psfReUBv8zTBRAkyifjbPMdC/YpOQW46z1BcVnQGM+dGI+rcp14T3YBb TqM7oM9VtRScoKx4cMRULxWrtHC4VaON2Cmi8VBWJt13p2z1JUqa6tOEIyL6FuRU1XHC8cR9t9ma Ude7A60yzXOigXik6OdFVZO+aPRFoy8afdHoi8YPZtEYM43MsYU+RB4j82c9zUUeK3l+iQI6ZeWj zZIzgVVI1o8WjfQRNCY2utDrd08jt3gX264ot+BF1jCuYtViWSJPoBezAqJu0BVXdAXra8PDaBS2 do8smdQFYTFNGuhtvbhf3m3l78Lw0QvD9Vs3XE4zqMKjLLeZ1Tstx5m0P63WmRcHWs2T2QtghoFm K5DMVmDgDASykUi8bNE+I/GyRtuQxMsebVMSL4u0jUl2f5V4QaU9UOIFF3dIiZdj6vPEyzXNjJT5 tiT8ba9KVmzjFyu2VyVrogq5KpmyJthwNqdG87Pz9vXIuzEiz3ku+PPxEKVpUb1P0OzQeJ8qzmZb mQL7PqhTwsHbPvM8ANShXgcAOtzrAMCA+HY/nOxgOt7Q0FA73vCQKDjeD6GkON4ukSANYuOqcpaG JnilYrFYe3xcotNqP8SJJyxuDON0yC209nDzOm4UlTweWfTzsFGUxuGE1LbjhFXWEvWEvWNnegbX a7kCmbLpUlrrpctpLyBDQnsFGTJfdDhpkyGjTXsQEQbcoois0A5GZIl2OCxntAGy6VayFVPaPYkY 0+5KxFx/t5srmSRMnicRf11229S6rH4hr/OTWZPdNrEuu+1ipj73mdlrw+/FdrjstWlAZK9NoyV7 bRpN2WvjYPNem0RhUr9caRQiCpKoS5QzVacoh6JtUUxVGaMY54GvVsnezfb9Uc7MWQ54CxVEv0cu I33zgb+vGn3V6KtGXzX6qvFxrxqZh+YoENtyGgQ4HVmooP37Rb/rdNFRLEuUIFhQHH3CmaR071tI kU78/QahC5dwbbm+aFGUa948/5fLYn1ap3+L4DtfPrTa47hWF2uFnqS7m2GRYaI1VQxrztuZQzjx mi1n/nss/l0c/gbEQaM7NA0gBVfBO8nEVgmQPIAxmkgIwpPJ5DdlE75UKBhqiTlAiZ83ePSMSU9S eJNBmAuBsEShMBdNKsBVgENnHfPNzLxnrNci+WdyOUg6Gp+xRAdlpVCEDUDsC+8ckJQvtFmY0FfQ It6F8LMGg0uEDgdn0Ag2QcSa/YNZMFklosLOuDpKAnCextZRkkZjFaRNDdtFGbFdFLErnLgHabnC qXrQd7PGnAeInxdct1sEaStW0egtmjDrZ2bvECpJZkO8RWLPDp19Yv9E9mNSIFR28bV88x5K/MQA R41XH8ZKKRBZ+vqzlAYOYmBfbwbVoBquyJHPe+QR4mmbp5ss4gXfKY81Dy3WkIFk0J88zwvl/A8k 437695oj+09fP8+7g+Hp3WN6eXb064+f38SnxyYvdUMS995A8tPnWvxn/ufpv/33tz9/fjMrkPkf 9/T4+C8/ea6ljSu9t8/zIQMe+tk/nqZapaFmwhXKbZ5rfW6Co+DpFrwV2g6er/nXV20fwG0Kb/7r U03HPf8Tn/7w+dfPA/wdytO3j5//6/P8E3bG4/MbZ3tjENpNAnH5SMyOj0Wj5yZOROzdb/701XOt FFTBbz6f/w7Y9m/1A/8fXKrbkwplbmRzdHJlYW0NZW5kb2JqDTMwIDAgb2JqDTw8L0NvbnRlbnRz IDMyIDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8 L0ZvbnQgMzEgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUld Pj4vVHlwZSAvUGFnZT4+DWVuZG9iag0zMSAwIG9iag08PC9GMTAgMTQgMCBSL0Y5IDUgMCBSPj4N ZW5kb2JqDTMyIDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyNDczPj4Nc3Ry ZWFtCnic7X1bkyS3ce4vmP8wj9MKb6twKRRKEeeB4iFtOSQfaXcdfqAdCmpIWlJMk/KKlEPhOP/d hbwhgaqu6V5ObTVJUBFifxwUEh8uiQSQQP7XXXef/vf6H+/Mffrfu/+8c+G+H8L96W7o8dcT/HLp h6N///Huq5/d/S5/3B39GDs33s9/TDn+/NNxyvrtV3e/fHtnLHwz/Wvo3NHee3Ps7f3b091DONy/ /fPdJ2/v/isXgeVJAXKZ/njnjTlGf++74WjjlJiwHf3RxylFMN3R2Rmm9CmHf/vZ3deTuO4YuiF6 NxV6yj8GN5X2r49fwwcR0kNhGLqj99PnSdxUpjmG5FJHv9uHjxutBT5TclPxgQJnPlYX3i4wuyUm 3XEcU2sVhKywceNwDDFzqDES3JXQKhcqb6YTjoPVdGpM9HZn5MfOLhOCEmdCfRrvikCNieDtELKm HwpCUOJMyB/7oAnUmAjuSajHVlllBcXOrOwxFsOoxsTyRlj13RiXaUG5M60pTdE4NSaa+9ICEppW jNb1BS0ot9CKI+bCNGrMNG+EljFDWKSF5c604rEraNV4ZCk70kIS67Sg3JnWcDRa5c0w0bw1Wt4Z X9CCcmda4Wj0WJphonkbtNxg+36ZFpQ70+pLg2KGiea+tIDEOq2+MCyi1xz8AsEbIZT+AULJECwI ecXGlVbEDO9txvZY/HVCrjAsIhRdcaixuwHDYgh+SIbskAxasCzwv2haUNxMq6vUQo2J5r60bO/H Z2h1hZoYprlIsaggk7wRUvjvOScodaYUy7XGDCPHG+MEPzSnWKw/BlqdC4kax/3XH2kPwg7rrIo9 iQQ7X7Kq8e57EoqV6cNZWp1S60Mo11IzTDT3peWHLjxDKxSLqwkWduwC3n9xNaeF7VfS0nbtMBkO mkUFww1YtULKJN23TCoVO3Py5bp3hpHkvqTS5uUzpHyxDJ6gL0n5BY63RgrariSldYU7jsXsVGMk eSOkkp2+TAqKrVl5X7Kq8bj7dIV75s/R8rqx7NEWNGp8AzvPPW/SDt1kq3ugBe2naUG5M630/4pF BYnkrqRoA3CNU/p/TcnZklONd9cVwikt7xMn7JAlJ6dGVRiLqamCTHFfTrT3t0IKiq05FbtIC3j3 mSqTMmMw50jpTaUQj0Erhhkeb2BTibfIFC1QHZoWlDvTGorlYQ2J5K6keCcp8HnuAqlBLxdDdTQ1 w8P+y8U5KdAdmlN5XDVBH0tSNd5/uZhZTbnEM6x81KwKCgv89uVDW2RrfBSZvlzrzvDuao83kRQf UISaUF8sfEN1iDjD/Q0sfDOtpPeWaZWnihMsFroLeP+FL+25rLPS697gjsUG+gz7G1j5zlnBpKVZ QbE1KxdKVjXef1edWaX1bn+OldM9sDrHnmF3A7vPvOOyRqs8156gL1n5BZI3Qsq63p0jpTugKRfw M2z3X9Dz5kQmhXOxJmWKBf0EK1JLHPclRav4kHzizDlSmlNXWXo1NvtbfgukwMrQpLrS9OvKPYkF vL/px8v4dVp6j6IfywOPGjPNG6Hl+2VWWOzMKhZbLTUcb+D4gxfywgntJ80p6p2XCRU23wLeXaln TunXOVJ92VBd1VI13t8E5HX8Oi1tA/ZDsYVUw1vw6BFS6R/YUa+PqaDUmlKxgbSA924o8TVf5aT3 k/rKKWmGb8BJyfMyMUzmnwf7D40nTat0Uur78lhghm/AScnz0iMkpeGXafXFMUHvy92WGe73Pybw bKRnWmgValq+2H7pi6bxCwRvhBB7Cy8QUmwqX6sZ3r+FyDhfI1T6Xk2wcKBdwLv7Xila5CaMNm7J SvvT9ra0iiro9vem9WzGrnCyx5JScRy1gPfnhPbeKiV9OtWbcv9ohu3+51NCyk8mEmyko8muWZli P6nvyp2WGTb77yd5tvfC1AvdsEyrK3Ze+q48kFrAu++9eLaOFC0w3Eta+oDKj6WXc42Z5r60yDwK brIkwiItLLemZUtWdoHkrZECw70kpdSFr9wyZ3h/N03PplFw6dRgmVTpp1nYeRXYf9/FsyUR0oBK k3DEpUhBSLEZSptohnfvdjQ5rfEZChPJV76YMzzcgInEsxMMKgO0YG2laZW+mb70WqzhDXhmelbi wabRtEyqcGKckKtI1fgWScFysSTlNKvKFXOG+/2Pcjwr8TVapW+mL50x53B/c0JITUy6eI6UtiYq X8wZ3t830/PMlEnhOliTKn0zfeWLuYB3P8zxrM+DSa5W52jpTRdvK/uhxjfgm+lZn4d0htgDLVgN a1q2NChMec4xw/YGzArWEmu0THHwMcFiZ2IB7370kWnxMxuLtPRWhS9dZ2tobmCrgvVEJoWbF5pU 4UrrK9fZBXxDpOjZjUVSerfCjeXuRI2Z5b60SPmt0MJya1qhZBUWSO5LinSEIpWUYskpFJSKA5wF vLumEE5n6OizHFf5As/wDfgGe1YOy4RKr+AJFodRC3j/TRcmJK9vRNw0K2npwylXPckzw/EGDqd4 DK3RKp/mcaXT9hzuv5d0r57dWOSjR1Mon0KZ4f3dt0s+uKmp+YTiURRXuWov4N0fRXHc29Zp6a0k VzbSAsHbIMQvbSwRUmyq559meP8WooZZI1S+COUqB/QFvPvOmGM28tJGxI3nkpb2SXe+NFdn+AZ8 0h2zWaPlS/u18taeYb+//apo0TMiEXfUNa3SfdtV7toLeHcL1jGbdVqFvig9m2t4A97bjp9E6flH 7OvrK65wdHamsodqvL+js+OXKOTBjQVSpjSPSs/mOdzdPHL8IMU6Ka0rKsfmGd7f0XmJVHV9xZV+ zq7ya17Au2+MOX64QR4RWWKl3Zxt9QRejd0NuDk7fg9A3qWYsbLli3gTLEyJBbz7xpjj5wAyKzyG K2lp08KW7rI1HG/AsODHAOQNhwVShfusrdxlF/DuUxUdYitOcApXctJbLjaUWywzfAPus8KK++EC q1Dsu0ywIrXEcV9OdD6/TkpzqjyAZzjsb1R4ujefSeHJoiZVOgRbX25KzPANOAQrWqQzFmj5YqvC Vn7NC3j/rQq+Zb5OS29VWFcesc3wDXg7O75szh49EQ+CNStXnLjZyhd4Ae9+4uYs3c1eZVVYFpXj 7AzfgHewYkXqcIFW6UtrK9/ZGb4BX1rHa6sVVqUvrTXlYn4B77+4n7MCV4SSlV7bT7C0kOZ4/9U9 X2OWR18WaRU2U/XA6QybG7CZ+CLzGq3ywVNT+s5WkEnuS4ru/MoDKdHWJ3CmcKU1sZx3Z3h/V1rH V2PXSMViGjYlpQV+N0KIZuIlQopN5To7w/sTokuxa4RKX1pTPde6gPc/MVigBW49JS29rDfVu6Yz fAPPtzq+FivP2SzQKt85NZX77AzfwEunlm/GrtEq/WlN6WlawxvwprV8MZbffYnorqQ5FX6nxpbL wxne3+/U8q3YFU62WCya6q3MBbz7YtHyHVJ59mWRlt6wNZXj4gzfwOuZS7TAs0zTKh0Z4f8Viwre gCOj5Xuka6S6Y8mpq0jV+HZIsWW7SEqr9a508asgc9yVFN+OXSHVFS5/XeVBNsP7u/yxJ7fiBD6A mlPpT9ZV/mMzfAP+ZJkVrUEWWJXuZF3lbzXDN+BQZvl+7Bqt0gurq5xfZvgGvLAs349do1U6w3S+ 0OM1vAFXmEyKF1gLpLxW613l+TLDfn+1PieF/qiaVOkI01WOLwt4970yy5d+12lpa70rPV9qeAOO MJYv/a6RKhxhutJHpIb7u8EoSrQYXqBUeIx0lTPFDO/vMWL5jGCNVOFcMS0ui7u+NRaWt0YLfLwz LSp3plX4HczgDbxMZvkYeIWT9kJISO+hL+Hb4UQ7MYuc1I66HYsD+hm8AR8EyxfP10jp83o7lmej c7z7eT3E7U7lr7OsP6mzrEVOHPZqlxbnmwvf4nxvTWiVS4vzfQOBE1qc7xbne09aLc43wRbn+5Zo tTjfQKPF+f6ghFqcb+ZQ4xt4a7Zvcb4JtjjfN8KpxfkOLc73B6XV4nwTbHG+9yHV4nzHFud7R1ot zjfD0ouvxfn+wJxanO+CVIvz/YFotTjfCbU437uz8i3Od4vz/eFptTjfLc73rqxanO8W53sPUi3O N6AW53svWi3ON8EW53tfTi3Od9E2Lc73h+DU4nwzbHG+d6PV4ny3ON8702pxvhWnGu/PqcX5ji3O 9560WpzvDFuc7x1ItTjfLc73HqxanG9CriJV41sk1eJ8hxbn+8ORanG+CbY43/vRanG+CZausy3O 9wcn1eJ8h5JVWCC5L6kW57vF+d6NUIvzPbQ433vyaXG+W5zvD0Goxfkm2OJ83wCtFue7xfneg1SL 8x1bnO8dWbU43wRbnO99SNkW57vF+d6PU4vzDbDF+d6NVovzLbC0LFqc7w/PqsX5DiWrGu+/uG9x vgl2Lc73TqRanG+EBaUFfjdCqMX5zpxanO8PRavF+SZYepq2ON8fiFOL842wxfnei1SL851gi/O9 E6kW5xtgi/O9G60W5xtQi/O9G60W5zu2ON97kWpxvgm2ON+7cmpxvhWLm4vznbcq5IGyIT/LSOUs 5BDup+wmJKGxVZEm9KhFQqFLnFAvGSk0icFv+1AWn/CkgRS5GXrUVSE6WT6Veq+RT2JTvdq0IKT/ UtTrGMp6RdyNZb0jlnpWpMU+pr8TBnmqXThY+qbRyzH7DYKJL2X8krG9If/VrL9nqG0RsFHk63n+ LxuIGt6E3DoudCVkozDNKGXrqMmVlI2CGIOUzWMKn5PysiF+SylbRdxFKdsFwK3yf/F4tJj/1uFh Qcrm0VpRyrbBUysZW8QyPSPiZUOLgpCtI31WQjYKvIlSto6DeUbKi4alLGVsEyUSZWwbtPGcjJeM oVjJ2CikIUjZPMIgSrGbBvwDGdvG3ytFbBIOD0VsG52ukrFRsDiUsm3sNpCxcSi1MzJeNrJZJcS/ cKAxzH6zuF+Qvd06DFclZaOoWChl4yBVZ4S8bMyoQshWIZxQyLYRlSoZmwQ4AhkbxxtCGduG/zkn 42Wj8YCUzYPjVFK2iFWDIjYNHVOJ2CiSC0rZNrBKKWOTOCfwDs3WYUdQiN84CghK2TooB0jZMEZG lf+Lh6zA/LeOIFFJ2SKgA4jYNr4Citg23EEhY6voAyhk62AAIGXzt/lRyrZP5Z+T8ZIv14OMDR+S x/y3e9cd89/4mXUQsvGr5yhj20fIz8l42TfBQcrGT3SXMrZ5MRtlbP2ANUrZ+j1pkLL5884oZevX lksp2zx+DDI2fou4krHR08AoZduXelHGpg/nliLO5P493rGF/Dd8VrbIf7NXXlHKto+ugoz7zd5A nWf/wk+Swv3EDV8ILfN/+Qc7Mf+t388EKZs/Z4lStn5dspKy0WOPKGXbtxdBxsZPIaKMbV8mBBkb PxR4TsaLvtuHQjZ+Rg+FbPyqHQjZ+JE5lLHtm28gY+sn2Aoh27yIhiK2faAMZWz9XlglZaPnu0DK 5q9poZSNH7cCIVu/NVUJ2ejpJ5Sy8UtMZ4S87MNIKGTrd4pAysbPBqGMbV/xARkbPqpT5f/ib9xg /ls/OXNOysu+AINStn6QBe+ybPs+CsrwWz5XgiI2fj0EhGz+mMc5KS/5tgbK2Papi1LGNi9PgIyN H4JAGRu/y1AK2eiZBBSy9asFIGXjRwRKGdvc6T8j44Wv2KOUbW+8g4xNL6BXEja5D44ytr6efU7K S96WRhmbXl4uRWxylxhEbHy1d5Jxn/6Xsksp9OXdlKG+nEtYLpVSesF/hEuiqdTtiqiSp/Nfzbpd EW1XRNsV0VJKuyKq5C3n366ItiuiRaZZRrsi2q6IYqbtiqiW0a6IZhntiijLaFdEtYx2RbRdEc1S 2hXRUog2SdsV0XZFtF0RbVdEtcxFGe2KaLsiqvNXmbcrou2KaLsi2q6ItiuiBNsV0XZFtF0RbVdE K5nLMtoV0XZFtF0RXci+XRFtV0TbFdEso10R5UzbFVEtpF0RFRntiihn2q6ItiuipdBlIe2KaLsi 2q6IVvm3K6I613ZFVIloV0SVjHZFlGS0K6LtimiWuS6jXRHVEpcltCui7Yro10WmWcS1V0RbMNbb C8aammUUb/fqR2qWyX5JQzGSr4aLkAvhJ8GeVgeU3M8XC4Pcl6x+KCmeFiN1rowtSaXkdu4RcgkX W3GxFRfWI5R8Qa2sSjH3f76DCxBd19//N+QytUvBTVF78z2y1EQUj/fNMuZrcgjtSE6b75Oj9BTK kvD3ypOJx5J4/J7EU5Y811CW3Ogpy3y3vfr255+a7t7cv/3q7pdv76bhlibj6X/4K9mek5JNNwKm 8fv2dPfZw+kwmaOTjR4f/nJ4FZLXmh0eng5TVYexHx7+eviP+7f/fPfJ28XsHFzbzdk9vDrcv/3z 2dRwAKOFvztMduowqfSHbw6vehL+XS7Ht1+K+Ofr0MAmkx9xnTetOkAtj7iQY+jIY4RTu7kHyapS KL87zfIlbB1pSEov+OIBW3x3muVL2HTkBUHpBV8uBzVy5hNgamA+l3VfmiZyYSETKeyFmUj7QUkU I3txSVSr6+a5LhOuE+lJWCXUk67JgppD8pDmSZksDBHjwaKIcJwEI+Q3nx9epcm/t9Y+fPt4cEcz LST8wx/XxqUZYP8w57M6Ls0As7dK/fotJ//5p+NZZWLMCFaQ7Xj05++WkrtkoanUq2Waus60gM2p p5r4KNXEpBaC8Q9vJ8Ux6Y3p18eHVwacbd3DP63WSYjQihfKH6AhlPgs8e9/+XJVEFULGnpJ0Ltv 1yRZUIcq+Xq9aCsypf78iy/effnXv659E3roDRdKCGAE5NSfPXz1+elPUy27aapMU8Orkfrg3+8P PkLffLi/oEbowQrI8jNzGGja+Y/7KW+DLfh/7qeJJyQx/3Mwya/ZpqyT6CTx4VeHV5Hmpd+m+QLb 42+HVz7tMg3+wR+Gh3+YJjRMcz81GWT27Heh+u4CMmhCYM/87WEqv/PD+PDrqfzjVCPu4c0/HJIC m2gtluOTSRoWY+nX71Nnt9jZdQ+/sowBdoGgjEr0vxxeDTTr5k6dZb/+9KNUR8hCyc4p/v8Fsq0F jQuyX3/z3bcHgxXzsD52PFybyB+vd1U/E/XtRGic+kqfRukvDl5q6/370AVcO7gaU9fzZV2Nusbz fUgYFIrwvTuHwSnyos7x6SX5od64cBpQqS+YBnLqzx4+/ebd6RegHKqG/b9TtU3/dv3Dm7eHtCGd alvXiaR88/rjRBhNzCtrre+lrxUC1z514NOdP32G8pg8gbWgZ8t7wSLTpgrsAx1DpuvyGT8J9uTH wun93K/lmSWz/u40y5dxF3jNXOLLF836u9MsX8I+Bl41l/gKOSWZaaYWMpcZpCkHXcyUAxfz0hy4 rXAVTFT6K5asqr1Drq7r8gAmugMlJtyBLs6BmkBykCZJOTyzdrVJF/Q+OYaS2gpkifw2KQQbuvHh b351wWpTBUgW68tVdCVR8l5/k5TjNPZCeN9FKu1hwP+nOnBT3oieGAXcoqSUYbZhecGeFX51qnIk ZPOWmK0P7S4pu1Ult6rcHe4QU6putl/8bN7OFgUPmf2FvQuzkPIFJnjx56llaKc307i8f3NzUha5 Xq4ZIkhCdZAQpYdclUU30FjHLKhBziw80wlY2l6YEpullefj+qgC16788TPjKt2I1pKu2AVaW48m 7yHb27x0PmMn/f6jtIRBCyvP4fnX62TpWrDK3ry5Zmin5jZ9hB6c3mAcGT4JtAM6wVFihpcPb/XZ aZYr4ZHUOqZmdPlQzF+d6iwJDuSBgWmHuT/GszPaUNBIOyvC4uJZcdDFTFmM181n3F64U4RUrtn2 Um0MWXDlXJMH14V0G6gK6jXX5DCQBw3mwE1ywayaRBnvZdjkWfVrPQTfpSkWliJfwVBKw2PSEGFS DZ4G0+rSjq6xZknrSqJ3uMLL5XoxLZFukhjjZHvjJZfGv/8V/Ncpt6A0Sv77ogBVgE9/lQhN/9UZ LfdqS98Hn08j0tEi4ifBjrbFKbmbuTtdYufjZ6c6U4bG4rk0p2Z8pZVP351m+RJOT5QaJUfwNVZ+ pgIdj6lcbtfmQmIGXMhrbHyPO3WnzIQuSFxmfnBTUyZSPddkAlxy50Eu3HkuzoGaQHKQJrlAHyVz 2/fdgj5SVn5Yt0dgfZUzeeZYqivkPW/lr6kXb5OXDz05kUQbFv38dDLZLlOx3WDQc6nv+3SGQPhJ MJ/Scvprz7XL706zfBlbfguW0tv5W60X8bH0GGydL+OuJ4dFSs/4cjnwspLiA/st151mcya5sJgJ F/bCTKQF0SphRv5y8121OuQhtXRFHkwm9yQkwz3pqkywOXIm3DzPDmU/wGZuenBH75T3uHP36wPb 4G/WxnLfoR+VZLI6lvsO7AUtMsv56JefHMwxggL5tZpR3Qj2W7rNgxaUBTOS8NQvrYDpZ9qtwMtF CkTwvCEsd34pH7mdS71hhiM9nMDpFU67+IgTspFvECtkAshGjGXJeU1rLbh4IRyjXMSAPvCT5h7u exhiqX+lQg+9+tHToik9TQ7MHC6nxy7fv0wPikMpHW2j4gPj6epkRBeheERIthc46vHNSnooPEGD uQGBdGFxtISduiVJT34n7PH7gHWIfowJiktGgj0MX76aSE9tJ0zuS1Ot5UuFLsJuV5oMEXi81TcE wtDaI15USLP6oC4L0gPYcrGPZ32Lb5+xK1DMZht4CnH7sMsTPTDGdgvd4JPMBq50x81tisIErnSx ABQT2gKLqB9s4CqHSrA91zhsZIjS5zrkq2v0HHrCVjUA3zlLOOJlskE3IN8WSxih1e0vACrFcZVH us3Vc8+CSnBc49jzrOMaH7ES8I2o1GmBp+UhIBibYDRHq1IbpM2ZjTQXsjC03nJhRprYuawYI4CI jI5JC9Z1MHoiTXU0olOQ1OHo6W4h/rVXG0yIe6saaKShzg04klri9h1D0fwjnLXn3jEOR6t6Doad yD1rwlAP3PPGtFaWfpnVCnbbMWKtKLVjgur2nBsNinHASucxQ2XhIYUhKvKQYyY8JPNgpTqQkTyS euSBTnUoigCP4bOioBZgNTI61kJetZ8oodGxEhq5L0StxEYLWohUHPUc0YC4FskKknqeKFCMA5EV LPVbUL5JG//bz+6+LqctcI5P6VLtUDrRKDQj8J+ra4htEmiTQJsE2iTQJoEf6CSAzsz0LkSCjjWG AolHgR5zUhx7M2REMT1q6cVc4rALzxBNEygnGtzxECVnjlnQEhjyh7n0AsK95JjAo8xLfPVdJjpM NUPQmQzKyLOa5a3LWkFknVzqaO77UjPSTsTeFWNjNlTUMux3Lzabtw7xo+gQq5ur6MadVv7+ys3V gI/TiQPL4OBKlTiwMGbnHk5/rQdU+d1pli9hP9J7j5Re8KWbnuV3p1m+jAO9J8rpw/x90WfluKD5 4EbbVU5QlIkqLDYnF/biTKgF4d5iJtRdvDGqWj2oSrsqD66R3JOwRq5yheIaCfQ2LNcIN8+zm6vB D9gO4p2UT0fU+Wi+yPMn+ZUPbP++tvMaMDjQZc5SYQCnF1Wcjw+RnChUcdSJ8hf5Zy7at386JDvF +Vh+tVZMqohkv6Hkv30OZ7BQFfnQOAuBU+s/LF12uuyIhyWaND2hxOze+/lTOszFA9zvVg/EOZuu Q2X22cPp82+npsEj40fZtl696REGOOyTTJ5ppIhekiLxm798+W4SagY82f/mndoWtxb6osXzh9Od 7cGvgfDTXfrh5O8KBQ1cmpXohzFkY1NWxgzajWQGyRGOE2cYPMEE8HfQIEYQ6o9SrqdcfDrLFHpe XE9h4P5kaQMfbx2dQHtYEBB+ApxUJeKEIoDEVwCQBtSjlyFm0lt64IZdWWeYL+pyesFgNxFOKABI d8sYgEh3DFSAp1xyirIjzHLUnZ8o48v2utJVNbjUSS+OJJyMxjDgZE1X2RIO6sZjwp5vWsLlE3zA NcG08gyBLy7C2p5DXiVIl0KxAgwazoE9t0HLYoCp9BuKzv5tBpedgR4pTTgtvgOdUCZsQg4dZQ1u aQQ8Sk0wrTs55lPC+FeHuaE1y9GaEoZ6ILt/wgDg0w53XjgeUsIW02Jf6mAjJ9AKWP6MC+QEocbY jwVyNlzdaEQHw9VNxTJc3bhapsg/Qqrj6sbFNsfskTrpuL5hqc7BdqRKO6rvtPLhMDnUFv3I1Y2b BP3I1Y1N2Y9c3bjHQBFwuCNwrJqEUyX0kesb+xHHmbF0dkyVjZ2QAsQkmM95E4Z9Ew7tkmCqhJ4V L2P19xD155FPqhl6LRvXKblguCDMBR+PQfMasVqItu3KWrEd1grXmiWHN65VvM2UK90a7FrQItaq trLoJCRNaS32DG7qtHWneoJ12DOoo1iHg4H7kfXYMbifWY+Difuh9dgzuJPaHgcj9eG0G5eDdSUI F815APDXPEDSVmAePiybh5Z12GlFoTkeqVjj1mKf55HLzGlgW4tDhsc91Fqf67u3SmlQfYtSsR3q J9VWooxsx8rJR9XUWZnhxkHWdXTdnlUhbg5mTQn9LCtS3BvMihZ7aZC3nGjji/Q7qZMT935OVysb GhuhuOje5oM2H7T5oM0HbT74McwHAYtBTrcKT8uGMyCkLd8SK5SWjAV6lEHDUXdLnOcgADJloJgO z7ylNxQ4IWelEAXCbwnjH/swB+AHxlL7UE98VD5SATP0qGY5DiY4UxEdnr1mCoJN0LWhZsUxKCzj QUaLqpB8FvISc3vrET+WHnG5jQZe83akl7JwOkzYsOh0vcBGnv8CgMD22YCYocW0hqdl8GsXGrQt IlqKNh9EiTncfGAd58hddGSTIb1FYkM2P8DBM2jzg7xJxTpJXqhiupB7p5g25Coqlg+5g4pllHDH lpFlD320qtLvng20HrdQHDcu1ALPODDu0oZL9LmtZQOGv1bm3iBbR0oydxU0HRMOXpec5k4wPBMy BW+xAOFHwkHXmRiAFr1kjTSAkVd6nthoTniwur26wuBO2Hrd3h2BdCFHDEDsK0YswB7fRRQLMADo 2GSDRwfZ/MM+asRMwndwjFhR0KES7mKJ5e9j8T102Jw9+gpn6ehJnIuGBzC56Mloy8xwZifWaLLl KrH8kpFXFluuUbQoco2jxSYNgtZIbi8023JzojGTmxvMttwb0BaSvoJmW+5KYEjlnoZWW+6JaIfl nopWm3TkvCcavf6z2lk0ephw9mJ4oXS2u6hsYnc5HsA2KmZieVkev0PQFRN0rYnpRZUaciP0WrFw o7DioTYjrcQtykqLm1uUGvSGrPOws2SdSG7prDLJL100KnbFrG6xq2Z1jF0Z1fV8YY+twXO/JMs6 KC9xZHi8x7K+TRltymhTRpsy2pTxg54yAhaDHnAvsUIVeNQpo78/g6ARH7X4UJYm8kJPAI5JSCnr vEIp0qFqlJXdHIW8zKOy5+9cjR6zIhiKqTEh0QEzoNZ4pCFOc43BSluKL0rcVRUhsyaxl7ET7ouh oypjtur/HhN/6wk//J5wnelGLt1iuqHTvFhu5OGNMyq5d4vlRg74Mh2Tv7eYbujvLTM5ufOL5Ub+ 32IJkP83m250NUAMCXQHF8stv9eAZw2jGCl4FDGKkYJHFaNYKXiUMbKVggcdo1gpeBAyipWCByWj WCkd++OK+ZUu8ojlRtcneLzR7QpparrXk7+NbCfQYU9kMwLlRrEy8JwoihWC5Y5ipcAxU5TTBWQd uQfjGVWUowmosygnF3jEFUNugFTjMeQWSH0pkhcRtVcM3AJ4uhb7wlKna0JsvNGNmNxbYn9Uthvd GqKeFj1XPx4LRs/Vj700ejYScTss6p3D6NhKJMx/HIsv8XQm54zb6Fkyns/kYuEuvJQajmeEE+3h C2U6n5Eqwf1/qTE6nuEKpdMDqW86nZH2oKMHaS86o5HmpJMLbm08opG+QOce0lXojEa6Ep6aSE+j IxruiHTmIv2UTmikH9NWs/Tz/PchqO9xjFDeMoBQtAwuKtmozppCVIMTiY3Znh2DGtm2fO6Ea000 A9WqKA6qddYr1CaidrDJRClRi4rSohbPSg06hKg87C1ZI2JvyhoTe1vWqNgbs7rF3iraGHvyKBGG qkP8SPFZC6WudZDlbGweH++52m9TRpsy2pTRpow2ZfxApww8f40UbLvECtlYoUedFp5MP4OGoM51 xz5PPoRTaplKAOCQxKT5XFfrRcL0ULqzC0i+zVh92fkK5ZPd6Or5MX2aVcMM6ZPd6NWxrt6kVcUX 3Gmlo+bNMWSIR7h68KiqmJ/xf5+pv/WGH0NvuNh8I/2T9o+hlKB+OIIz6x8z8pSM+seMPCWj/pmw 17MhBWdm9TP911HPpBMebK5NjrXMs7KJeVZOmtjw9n2KNCx7/UPI8Y3ZFjADNxNajhyZmE0JE47q mCjBno8h0rAxgdUoWI4ccZjtGMMXdch0TA+OZSuIYwezkWQkbhP+ma/JkJFkvBhBBlMbdSLijOMa p6K5bASl9jKOa5yYuSPbTDHH/5V6sVzhaCQZKzWew/iykSS7TNAWhmscu6AxXOPUlCYPjDTHGpOP OCDzTk5APCA5H4Ea7LJjI9RClx0fA8QUowpH7zeKb8tzaMe7mOQ81415TiUsf4/qa3TDk8xp/hbZ 1qqC0eQvBSf/P6ZFtoOwJvdBqRWyPKTWyP1QahUNl8JxUZqDLB5pKxzm0pSk6qWpLUZ2446At7Fy P7EDjgjuR3bAnsH9zA44orgfwh+pj+KdodyFbcRK6Lm+I1YSjwCrBgfeT8pjh+Xy2ILblXnkcbF5 ZNKUwQOXSQ+lFSnjnutsyPUdvNIbVN/aShRtw20VsxVpla7ipmZdRmYiqzruKKwJyUoUTcm9bMxW JDw9wpoW+yio4cIwiyiVo45R16d0M12TR4aOeNqmgzYdtOmgTQdtOvjBTwfj0VJDnBQCh+pFgO7U GjKAqinAowyVJJ3nk4zV5EOIpgry2ca9QukGtENKghhhGQr0eKcweEzXKHDve5QZqovVlBe5UDDW F9Cjmt86dk6rdQNt+2YShLnrS31IM1Ed8DDBoZBHih4ZeqH+EvN66xA/ig5xzVHLmEIZddRpcNJN WF1CSJDn7wGh4Sk73fzvxXgLAPTVyoT15nrCbCik3ZFeLDePbz2I5QYWVMKeTaSI6dXdyglmE8f2 YrzhzYxejDe4cNGL7QYVnrBcrUxRh3q23aBr2F5sN9jkTVjfrUxY7lZarx7dwPOS/KqF6QCIq6TH Jy7EVRIyE+MtbSHjuxiqKGK7wSC2vSuOlBIWV0l4ZUNsN6oItt3QD6UX4w3r0OYq7yJgH3UTiPmW TD/bF81nsr2cNsZ6k+1lqASx3jDKci/WG3WdTm9HJSi7zBagOEMGTC3Okqke/Jg3sT3AUCD5I1SK Mv1MkfmItSKy0SWIi4bjL5ccx2dmBvNqJo7GX64YnJYtuwCq6sQJPVc3Wn65OdAeyK2Fpp80JloT ua3R8st9weLbKmJ+ydsqcoXHqJ5m8VEYMcDoxRiZLTBOl3Tj/PCMU1ZUHgOUndhg9NiMGGFUGDHC UA3zCGQqQzZ6R6sGMNeEGGEQvEyGP1ck1yp0NDHCtFJBGyorHW48McEwDA/rLG56McE6rBVRedRz RB+mDqnUJXY80aY4gWRdC902dHypSp2k5Lo+8cJHEs71Df6dRsN7Hb+3OaHNCW1OaHNCmxNud04Q jXG6o70XaoqzCL2OC6wQulpH+v0osk05rSCuEU0ZhmSgCxHm9MQOSCQkA1ejR500lX2GesusH/WI ryc+WA3WyHPSRzXLoUY4zRREVthBQ1HR3C4yJdKUWT9cJ0Olz7npRftLzO2tP/wY+oPytYgQUJf0 svg79ewNJU8ksotBRpafVaQLO54+NPq6DwXwm2He7uD0gumeU2TDIUS+DaQQ7Jz05NHF/iBMQflc RT/3LPgpM6dtO9YAPW2Ty5uYeuubZine8Opl2xwHAOKsPTCvPGQp4HYFaerhxBn2PDHRLEv9WSES SzvuvhCrd6jGDH/ixJeivKbgAvfemVkYxsXE4HA10nu+z6Slt7lgLfN8agwtwq/zrqYlK2eAtUeR unwJOuJHiV4qQ+/AyRXe8/30MGm/6R94U/nhP9NDx9+9O0zLj+7hy/v+D784vJpWJtM//uH+NUTi S0n/37++/SRFxO6mf8zD/SEtbtJ//81Hh2ge3h7S++zTPw8f/1PxErEUw6awEKoY5RvEKhk4tOri TmUImPdbydpA+vRGdvF1D4/U97jwgo///SE9lgxk/vL5u0MHv118+Pb+8CptQScKf/j3w2GcKKnw uZI9v09jaX7vrXrLpacXo2hdRw9r1QiVFELPy5qUj+dFDIyKGeQVEiQVgGdPXpZB9FdnNerxYWHD D8R5zie/D4e0jLwnj++R/1R5Px/kcpITQcmkGJe4QIq0xGEc0A+cUhO6PN5q/upUZ8nQkyMyJWZ4 TQxU+ew0y5WxpTUxJWd4uRTcRREqOHMQlQujimIWuaSYB5f04tCkqdUo4Cuzoa2BC8OsUktL0Fiq oWsyYTK5+yAZ7j5XZYKNkTPhxkmZdIVSrKNiRNy9GmBbCXTjm/S6Pb6+//rjtffj/QhL8vztM+FV Id6HSv2bjz6+Ir4xEsUlBla5CYyfGJtI9/EpveDLx5v+7jTLl3GgLRpOz/jK0UDfnWb5Mvbkuc3p fe3JfYGcqScUfILPfC7uZSkTXdjgc2Gv6qqTNXLSdMA6v3jYpTaHHFQFXZ4DESl6UfC5F11VG9gU uTa4ad4sW5U+wha1GftjeI+BliTyp8+Ms2RR5bTFKKMLNLjQTRF7adsc1734ZAgiei+EFv4KgdOA YLK064z6nFFGaHZL0gxps93zkyeyahQE5r1g2uBUOYH6F3JVeIKfJunLYlNCNChaTp0Aurz0crHj 3U8Y5wkHtXeasD5OcsOIe8C095qwz1uzCdq8ceuGSFvAFFYOI4zIxu+E85awGwbaBSZgY95MTrhT e81uoO0c2otO2Nm8V+0G2jnHrewEQ97odgOtaWkj3A2yEd5FwuooKUGTe4EbaMufls2CqdO4gfbJ BWNu3JwD7bJjR5GykKZN2OEBArYAM3HcArTH77gFqCbckSsGjfEx6Hq03AIDnYPoFrDcApGOQnTb GW6BiL3ScAtQyxtugRFrgYx66TkdxffExT0tB7jf8elP6pZ0GoQtgL2W9wIpkpjsMyrMsK+SR50Z 3u3JwhxWghTGq3L64oSM7oBmmngHNFcD3vrM1YS3PqkO8Y5nruCI4Vm48vFOZ24cvNOZGw/ucErL 4h3O3PB4ZzN3DLy0mTtO3q+joU07udTvouynspZRXTbrU1BJdEkzd/lY7M3yHS0ZMCyaxxPtI/Jw 45LzcMTbqDJYiTYPZbzZmoc61xqrghh4p4hagCo9UnOMVikZbi7WQHCFNysobm1WYHgjWNQbHStR /Ts+WQ9FLxPVCaFSlWrFTiqaF+ITyoa1ilup6/4kfZ0TJvXi1XRRj43roxe3GaLNEG2GaDNEmyF+ ODPEIOrjVGF6IaFGtMIpsXyJVy4K9JhnHlPONIgptOwiegQVZ+8LDZjlCEgfapC/w8KfBRIrlw6X nyqshv8MPdKcF9lXKc+xrC2e0995SvZKNMNRr+/mQ0NHNn6Rqb71iB9Fj1gLKsr6MwX/ePaokN6N TRvvI4Vb7Q7Dw/HwaqBIpuqnUadfrGYdRdqmt2wJP93RY7aEk5gOQFC/oZ+kV27NQC/YUC5moBdr eGdwhulBHEmv8MSKMD7Hm4BXvyEoA0IqxFMufeA2InY5HAYOnp8m68vWBmTDeYqCyTaet2y5RnVe kw1Eb8l0jfDbsKWZSuYN261oeXqT7VaEhdnqjZitMCA7tlvR6uVI02wV+47tVjo56th0pTOvLhvc bmTLFe1xN7LliqPbjWy5gqJxIy8d0CXURVo6oG+ji7x2QI9Sx2HQB3RvdJHXDqboXwmDMwDFPc9/ RjU26NbkvAPXNzpZunAsSha4ynECcT1XORHrucpx3eJ6rnOsl/6oFz3O5ypPVep8rvIAUGo8tYjz XOO44nK6NZ0rl2vOcZVjZ3COqxzXes5xnUfy2niSRaLjuPPUCZ3lCoc1prNc37gidRz0njH/ndYh 8jmtcCV7WomwdFofS8lwISIFp5lAiJEVJ8Rx5eHYQOx0jdGyQ2qUDEipcFp6SIOQ8cntRSsPaU00 XaWxaeEhnYEsX+ksuPbgrkRGs/Q0WnpkvYJGt3RTWnwsYLVSkT7PufGYIJNdxgyVhYcUWew84pgJ D0iy2WW8ckXweCajXcY71SPqAtIiRQuIFiGTXbQMtp4oIV5Wko5io4FVGNsUrOGo64gGpDWtaEjq eaw9cUWcdSv226x7cT3tHd9D5PVBntDAz6tU4oXCIWMG/84D5PodpDZLtFmizRJtlmizxA9ylqDN B9xzQ6yQCxV61GmLP4Z7lSskzNJlqslYzRuELIP0aXeMuWcMeOkHhZwB8l3GCsHWAudJWwuoAsxs HqTiQPdZQI806Yl+OAmzrE/wEpPS1zaqjs8VoZpJt9r6OFFbSC8z17fu8MPvDme2jdLUgJcUn983 SjdLzQjWwcXbRqXP+QCzIOpxcuIeyef8yy+++/pgO3S9/uLz6Td6myeXbM7sfwHcEfeDCmVuZHN0 cmVhbQ1lbmRvYmoNMzMgMCBvYmoNPDwvQ29udGVudHMgMzUgMCBSL01lZGlhQm94IFswIDAgNzky IDYxMl0vUGFyZW50IDQ4IDAgUi9SZXNvdXJjZXMgPDwvRm9udCAzNCAwIFIvUHJvY1NldCBbL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTM0 IDAgb2JqDTw8L0YxMSA1IDAgUi9GMTIgMTQgMCBSL0YxMyA4IDAgUj4+DWVuZG9iag0zNSAwIG9i ag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMjE4Mz4+DXN0cmVhbQp4nO1925Icx5Hl F/Q/9NNa1digNuOSkZl6oyRS0ppESSR2Z82EMRlZbBIc6wIpAORwbH9+0/34Lasa1Vkgdk0gCnhA HlRc3T3c4+Lh8Y+b7pb+fva7m3RLf19+c1PabT+028PN0OPrnr8KfRT59/nN1/9y81fP3O3qNHZl uj39mEv8758kKvvp1ze/fnqTMmea/xm6ssu3Ne36fPv0cLMZtrdP/+Pm46c3//A2aIXWAm/U85s0 pd382bc6pxSQUt3lSk3t864bTzAlprz/9i83L+aKul2eujQ1bm9NaZw/hkJ/bl/tX3CheQw1AFCJ hOaGB4SmENqH2o5rJ0yo5FMkGWewaDbwrfcofu5Dz+f00iwC0t7lJ5pHtLNKFrQb8pJ2gtNuQVqC oKR1rFC1984Tw9lo/vUsMn9loo8tD7Wfac3ET/RRpy4bzY2rC64ds/SY5SKVV67+f+cqFAHRlkb4 iBE+3uaOq0p9RwP8b5uPtmXu9/xn83qb+s3rl99uB8Z18+UPr7e539y92k67bnO7/ffbp/+DdMGy vBE9QnmbpApjmWia5Wu0RE/ekKjt6mMFSevzOCfl9r+cW71rrQ2bu69+eLHNHcBXX8zfRTumLScx nLp+HPPt6QeRqg2k/sq0ayNxa6bt/CH43nDXiBP3klpREPVhat3AEn704XUg1+GkTMG55h0zk1Mb CnU83g/JdTgpU3AaM3FF6jC0to50+x+UpHVd19/+501rxJnQr7pLzfv1+VsXGbrBRVo33qpIJn7t qKCDd/xti1PuaYGBsm/dQtDRZRB0VBl8+yKFwVakMZyKPMoxTw+yTw/SrqsYgfw1DrNSqrlhAL7Y PpnH7TDmeQT+9Pr59sk81HPrprz5bvukl1++XyiPo/JStuKWquEk3bQroeb7bZut1tQPm2/t69Ws veaP1sKof6Co2Q7VNHcfBR1mBdf6nMbN3WGbCn3nzZehXy+trOW86ajUoc5cz7NuGjIK/sP2ySgN e/HV3U93X50lw9ygeSbl+Tdf/tftGXKgtln7yVztxUz+M8mnSgMxpD9H6mnY1UXhz7/7/hxnYL9W Fj4b/2VT/rbZzxyYudaXzfMvvt0+meWzdLVuXtyeIxgI0LHZ5lLmnJPk/OruxWzP5gSljvH/v/6W WHLC1kdHVM6sx/rKQ2meBKVZ4hTeK5wTFYKaWvFa07DMdzguFrC2iZhjtRheq7iX+Q7HxQqsE9HY a1G8vpae5i7elYHndNqXVXoMZYSGchnW0pVlCOdI1x+8OyMNtpVlKLdRhBLokhKEGi4+oIbKzyXU ACOcGsoYKuOs3s5l2I31ti+m+H6+7s5Do6mqlXl24OdhIiJ4/ftt1WHvLfli/gwa/cU63ZtLoX9q 70rl2ebFd7fbmVlzsS0qAdLF5ztVicFW1ObZ9tYXwo/JyjypmC11P0/XK1nbOhRmNfC94jrNGo8H NdIbXqsrlvkOJ+UKntkJKy/pDa8dx8t8h5NyBaeJJxVWj+FL6snL7szrCuvOunGKeW9s6lyGNXV1 GcK/Cdsd0p9ywQQsMJ0LMSJdUgh6sxAkWvCpIF1QhjDDyjDmPKozaoeleGFl9zZK4+yoLTTSZqEd pexPt0+GXRrKXNjH85Rg/kh187+fzsqg2/yefpvt+TBt/jz/xnVu/kJVItnfP+URzpk/orTQLH/6 mFTAlMrmV/PcEArg7LRC2zSYmvp8nkqkXaEy5uWxlfzim+2TWenMf9L5EmvXk+INJf4t0TyVp5z/ frt9MiebyVbWtasnJfrzqTXPTRPt+kxt89s5x0yX0s8NGHetG4eZVitaUpuuwuNE9zVNoalVm7tv iCOZC7x7ebud5+9zl4fN37ooHeXNwjdPFEv2eja3/03V8FmpohVCaFzaNqLyig4V2v3kPE7P3332 8UwU0O/zz4lsPUlT10fyP52TILln/OyTjzgty8pvmNrM5I/Pisq8gJznNqElD0ltWuztvKEzuTuZ FZ815WWEAckPbNKcJG20BH+oisD+r8+Piez5H+pjd66PtePlsLZ1FiiXi/Py1DfLtV6aaIpjjV0v Tl3T8f7ZH4hChfn/aygqjP4HFVUYhUqXn6uCpEmFDNAlJCOhmA2G51tJtLmlJMeWT8i2polssaB3 f5i7l1hn1M031GvRJa9ezxoLn1/dbkvCd1xEzoTJsxa8+9W2f6vRU/p6omN/f3708DRc8p0fPRPt DmnKT757efjVmdQ1zxbYUt+9+OFwrmhpfe1U8v7PdtY7vKFxXj7G7ijj4fm3rLOY+Gc3LmSPL+R9 tulmukPCn23/dRZn8HA2daXC5kTb8PLu1atV0psHlaZnszzVB2uQoRMsUrB6P9LeAlLW7eCpn222 T/I8kObPvH1DiVGP/khyica3+bNy8bG4EvpvRf8rGWJu0qre0vbFsTUKo4Codp4tbEqsmLMyCV0V qvyJ6LskwLOZZm/gKqn8mTJnuHpey0iPabIJLfOsy2WdopkFt3rOueF51g3H7Xq26R9r+uv5P2HX f3jx4u5+y6MmzdOn0P8WubrKUEnP8jwbmdobNgVnDdazbeANv8cFg5a6w+kUkLb/VNmF2d9335O9 sd58cbhbU0XubL6/qoq5U1ns22/DrlopHS1WehzbzIupWUd0hu8Z04kcMCE6S55RHSPCSR9woaWU ZCWtM8O4jj7F2avqIi4TTcoFE2oMZjYpoIr2N0DSjHvvAjPh3rsoGKdvH3bXV7kKlNmw0XbUPJVD 4hlTzm7CgSbhlBln3sCgsz2k5/0uwgTnwcS7lrxRQJB35QjTMr4bde902uHnDslH6m7f8ZYYMHeF LAwgbWvNEE4WaeC194xTFkxn0qQ1R8FdZdx8D5WgooLU2CJJ2JKcl4XgV+LNwRm2UWABlg1ZHpOE s0CmQ6UeAKcWBCsV9Fy5lgooo2XVwEEtSw6RqWqmeRGaa1OK0Dz14FkWoktHshK9QW5z3LAm2CmV aDOhS0p0oWJSovN3WXAgKcX5WKTvdDtLGdgpxXlTmLBCJkInJM/84btuLDwEm8rWiM0zkByyR1hF kTKPQvHMHSJcxyUGBzLTY5F+DIXZRp3UxcQPbamxnRVksH5UJUMVuKBC7pUKoFLuQQalYm6QFaVy brvqDMgNgqb8yQOkQfnH8y/nbh5UGMD9PELMRTjyCGFQ2ckTxojKVp4gDSp7ecIYc+2iQuuqNCvO VZVlyKkjgDcawgjRmmUA5XE3huGlzdbhl8fl6JRe6+DNA4aEjG2lmY783DCiVDMoxVVz5B6jUTWL ckwUT+53OaglZbeqrVxBCdVquQaVl7FBqBoRchb0ZQEVTJ9m8Mf0LbxjoI+DQ9aS/AcVd0tICqbW wJ6j4SE7wFfLcLUMV8twtQxXy/CLsgxDVsYcHM+Li9JB/uKnrGYW2PPwymeB9lZ16ha2RbAaiofQ ntVbDrIQoQPKGEHId3v6xR3dq4WicZxVKwDf+pC/lcZLqr1bNtEHh5uQ4lhDW5tbXHE5J8wSiqUE VvkPK7Q4Htzh9x0Z9asMvKcy8NAe4Jhl+rD0wH30kLnPmBv0GT1qHXtOCL43XMQ8aHrFa10elvkO J+UqVg2q6RWvdUVY5juclCu4jg1WRNIbXl8P5ljen+adWXW8ryV4S5s3c2UJwrsCH6vQl/VeBsZw KSQQaH0h2heXouYidEkJwgeUYEx51NWhL7C/ha2ibNU2Ozk1p4cf67kN1L7nGbsVcnbXve8xVQ1V svfTV15b+Hy5HXUf9hWdBorD6ypHCxGrfp4bt9Mz+3MnJGEzd9XirSXsa+YKJxzC7NNYxaG94z1F mq4IKoAJQ2vkSVOWrUzCJBRZHGcI06QpF0zRZt3ATMvYGSVIVitnMJ1wZiiKiP3tCNdRMBnBGWeU RkWrKqEZU05QooTZfTFByRImsuaEKVObtWuP9F0VzFTodvi5sI7GtjpwYyiKq/AgzJ1cLOjYNbtP EyZ7hCvDJohokCZVR4JHceeX1AFyYaMyAJXRutabkkZlAFqaBmUAOpIGZQA6mgZlAAhBC7hAp9SU AaBjasYBBgvyp2bkZ/akwLrUKwPAWTgNO+NTrwyAYKReGQDBoRVykKtUlQGQu1SVAyyVqQoDRGhT EQaQqwzDtkDyI4aYZ8aFJSs74aaO1Z1Y3KxpKYMK2vLEwus9w7TDOi7TASOMLOJBNCzijaCyiDeC yyLeuCGLeOOWLOKVmbKIN17LIt5kAYt4ExVZxJsoySJeBS1FIZRFvAmpLOJPsMq47MLoEEhxdMgW jI0edTXW0SVbMDb4pBs6NmUPxoauEMGGNvZgbOQLDU0zyB4M1Abob/pENmBM3wjvTB/JJNvUlbBe tVnKUFeq7ERwTBmmHDSlSJ1p0gTPPVW0kFnTwgknTNDSYUnXZPdkJm7Kor5dndNASRC3CatW/X3u SZxjrd/su9qLq7242ourvbjai/fUXvDpCfhwWEIFbCoWYH/jcObXm8Hea+7d4Dg262GIbUcvldD2 9Rg1X8SEan0AWV7HlhMdW6B9HP7HRlFaxcPgAbQXC+jK43ATUpg2P6u/nTfKqi4y8vxI8S3Bd2T6 rzLxC5GJh9zD5FQpZdlGiLuE6+Z7dUy4t6RXY0amKWHWcXXknWHCuC818m4wYdaRhPkcTBLPX6JZ 6zDhuEw0L2E+ThPFXIdxB8h6myCfxUGtE+Q9W9H6dRiwTStWgXBB8m4UzBtlYlXqAJ/4ERaHIFAB 5M0lwikLJiqMo96iotMdgg2FMZ0JK6xInZpgosE4+F0vuiw1iqElzPtvYogNi92e8y8AChMjT3gI m3fWFpkkUFMrp4/96JUHfKhFWHgAMvTKgob7Pr3yQIhYd0rTxmjBgrEqC3AfZKzKAnBwLMqCCfvY ZafyQPwfi/JgApVkRLLw6CV4EismsQQXULGTm/wkpUBggAjtmIQB+EFke4Ht9xqzZ5BBCy+ggtVd mAzWtAIyWLsryKD9Ar2s2yCuUwXEd6qBV07VMZIcXDeGQCicXyNf0jN2QsCc2xBIlwYIrIgKhNvl CLLvcoax4nLII8nFFAMPLQAsUcQxDn0ISG4dIRh4PoK0chlg/K8PP223jk6U6qNX+62jG420sa9U U9WALrvqGFvQKyCe6x1hl6ol5oQrLeG16TRw1XWeyIrpRAiJakvImatSFrigallKXROz9IqmDnO+ QPssGjym05uoyin5WcfGxTsEV4txtRhXi3G1GFeL8V5bjN5YczjCaLlISvje3ziq9dYyHaNG6y2r uyyszlR02LEJOUZcyYDQEVEXCqbEb0JHWbP/hk4t0N6sGKuF+yUMJvII7IP9w/+7vTVV4bp7qct1 HDhXhli1YR0np+NGDbbY63di+K/S8AuQhiALEtJGPBNNGYtnomDxS5RSDYFuAm2DVoqy7Qj1UTnG ukGr6SMuTbE4WMr2riLUtb8RrDJrvVDqucRfe//mfaEGp+oQMifsCyGMLUcjKZjkdLzBTtN+mDng e8UUXgDevJxcoeiPh7alCptZum1e5NZitx02O7qiCA+X8PkiuLQ8GnGJ7R6FiivRVS+ZnzN/lEFc ACW94fVxv2K+w0m5iqvYcE2veH1MrpjvcFKu4ixO45pe8fp6eDKx6M/o3VkZ7QplxLaO3tSVZRj/ Ro79Zd2x6DePR9BxnkeSXVSG9GUhR6OL0UX0AC+MHsqaFdG/aC1bJouc+i6Cf5HasCLPx/4acYXV 618X/Mt+OXszOvc0Myg0EdaIJFpEcKC7e0G3lPH9+tstrVAoPODXHOcAV/w119qQj5muKtyWVi0I 4f+bEEbn+o4m9HyR4x3HBVqtKfvMZ0dyq+Sgp4uC7bQxT7gBIskVrncADtkOx4UqHMRPXFMrXu+W G/MdTspVXNVgS3rFl9QzF+i98a6sdHdFfm9naOTqEphrDeHBQk/WexAbq6WQQJ5L3JBHqGaTnyA8 F1EDXBBqKEtWOP/yxlCB6wWPoqfzoNj84NrjxYOfd/dnvYHBDi/2vDvwQPsxsQ1RY7m+ZCX5fRic 2MgpVTyn+d5Btfn8iJACGZuiI8IN8AI+IL6cIDiPg+wFTBTge1wOpxM8yMYCJzbARQgm1KNc3rgw xBcpBEsr7qX5YTuiObT59wfX45XedLjKlbD9No8CniUk2ZxrmLwk3btruKeSdGOv8W3GpPt+Dfdu k+4LNtyFTLJt2DD3SLqr2DAnSqOdePNVRQ8zjouYSTctcaivsbLlDDrpjqd48CRd15ILT9KtBHHh SdhUNReeJMtp8eBJOBgwD56EHVpz4UnYwTUXnjSahu+ZDt2t+e+kYVr476RhUv8ew+YOJOm7UNYw 7mJNw+i+RdSSYVTfI7R0GN03iXoyDO67RB0dhl0LdBj0ZkrCb0J/UHBoi1P+NLQF/Ye2q4E7Q1P6 g3uDXHZU7g5q0YX7g1yWVOEYcJVSZWeQm5YiWoNcxFTJG+RSkkrmINfNRG4HfCN45iDXQQMGR3BN VhPXWArejPBa8HyAt4JbFxrZgwbaB+5r6GI7IgG/WOAUaqCAUhCXZI3AfFvUqY87ss4dXDZ17uGS rLMWV1WN87gj64KBm64uOKULUoXLfi51uGFnQlnSLkpsSaCCSrj9PMTMGB1Sso0cqtaGlbTJhp20 2YaldElHrfTYBrVQxAa9UMw0AghqCkPIrfpEuGHaBswyZSS8NGUlvHZlBlEwXQdJcVUISXJVCUlz TVqjmoWAmhaG/OoRifvSlQR5m7DkPU4o7pny++nAuNz3+motrtbiai2u1uJqLd5PazEZIw5HuGHv XGzFEu1vAp6rCjlP0N7b0y+tDnAwISdoL/7tC+1n8A3gKB8VaoBPGgLYmwUbijfOcRj7gnjkF1Ti 9m+oYm1dMTymt51JxrQuMtFHxYOjJHhdvxujf5WHX4A8nI9DDRcTvAl3dMTWENdG9NHc9lp17gX9 VDHNACZUTJsZyuK4LrgXzShF9aoKW3cMVMNqyoBJcoEJVc6ZWgDMNCBTttp4Vc3St6yngBD3D6/L K90lB4koOiAgi7gCEhYHu8ogq3cAn7IN6l7Hg6HUtgvODwTFv44jAxEW/zo5QGzqX8exSErt1b8u 8V5WL+51fEZRQG3CEnS6VxdHjuVbq3o48hyyVLmDRO/+UFjTiksM8gwQQThoNWxmV7ngRJjpILef CPPhp9yOqlyW+Ic025CD00MbQAbdUmwcHrmq21NrIIPu37UBZMoxr+7ntUEPMvts9ao3VpO9SvXW 0kaLL1fjs52qnl7aZfUEazzrlrisTrFiHqY860YYV6d3MRdTnnXL6blxq5iHKc+6CYuLKZhd1MWU DyCLeZhCVMqw8EMh3KKkFfMwldA/4iwkUlqCjynHozUfU5plE6zjAtqvRBjPzbNsL7yBLlZ3A12s bQ2EsbYPIIz1bRDCqBvwki6j0mV0r+FA1Ul9FMyptM+BKRPoYq5/ODIwnmJ+7DzHfNhlgufDJjCY /ro8Yfrr8sYqxWUR893F3jOPUHX+Ky1IPbSVDwrNrIMGc2sbU1q1jjfM1H08SsN1uGLe78NZ+y2j fV5AuCYQmrmmmDDk+iXJXdHgdMf0EBjmWmqA1mruqL1QcgOIYkoQ0mI6su1q1KCQNdewPThi6hei WoejYGp+pMGneToANN2JzvEB8nZRNq924monrnbiaieuduL9sxMjlMghggc/5ZR7gQOq4xHa64ip o9/dMWg26QG0Z21X7KT9/ggT6kZrwwIhL/CtZ4uf+zjSjw0gN0YH+jHYi61zLXE4UQunantU4Zb+ u1FUq9wvZf+BgRAc59+Jbb/y/n3j/QqvpYZHn6cdQi6wNgD08xsNAC2pDa/3m4v5DiflKm6i2DS9 4vUebTHf4aRcxUU0pKZXfEk93bjszxDostJhDIXExg6h06sLEf5xS0KP1hcSuL5gz0WFSHeiJA3N JOkiioAdThFlz+NedLVbPOv9R3uRLbgUf/PtNuuDbQuPtkc86VhVxdJf/0ARLPFw5aPOeY9Ex8Sz qFi1iPefvuj4P9khll80DI61D/rY/nHbpEOPe/L+Q29O0qvI7LEo2DYFA252tSTJvdDBDsP3JnSy XWjQbnsicYBtUQ0e+B3cfVVszT9189bfHSfn/V4vS+GqeOp1bok7vKnXuSeuiqd+p/ND9tuvulzA ffFUdTmB68Op6mqD74unqlYKF31SWA3UVPTeM99cTkWNCy6Lp7K895yKTxebXmWw2SPBPixk7EqB XrlOWaeqfFs8JZ3J4sZ2SjtdRDEZks6DK4OkCzQmwvLBZ8KtLrEt8CR9ssI6e5UaNXWTrqjQkG7S FRe3s5t2sRfduFiuER7Ceo1wHQOROpvAgIg2Wy+4fBQZ0Jl1B386m4+DeZ3N15m3nU7mwfnO5vqQ jM7WApCcrvnqjG869b56YzrISkPkstOFCMS203WK3NnrdB2j2H7nUee5MSStcFzi9bpxw9fbhhvA 1na5IWx9kxvE2nXcLza6yO1jo5vcTja6jpHmcq9ZLzWD98otuSpp3JRLlsZtuVNt0iB3rlVYcCPb JEnua5ukyX1uk0Rc9zYplWuOJtX286i5eXjqoJDSbcTIVXUdUNI0G29yzd2Go3TNhiuujNpoFsro YJcr9qYLxqgo5HK+KRLhh+kZudwPJSSsNA0lgQFMgYkomIJDXAHTfyJJqh4lKIFrTxZDV6647Zd6 fdk+3AYXWle5wUp8TW2xQ4Sf7+3nri4uoV1twNUGXG3A1QZcbcB7awO41g63xjSAQ5LXuAzVJdjH lG3xY7PYS4I8DERqC1OSEGLoCDAzGupwE2RHGiYYbwDI58i/k8d/AELDWK7rsY3zhhmQYV8t/kOt Ou49/oPpgcdUs5Kk9+31uuAYwuJ4esNqfkM0kJ9txq+S8J5Lwvrj5inciDvoWYzfn2PbStBMLW2s jWpr2TITjIG+CMdYa4RjrLU82tENzwoI69EMUIy1RjjGWsujnRuRsiMYY60RVliROsZay6OeWGEy RDhGZCFssdY6pM8mYXm0oDpsHwgP+nOH36sepTeGWU/SmRA5Aotvl0A1w1KWxbvLILoFvENTNN5d Accs3p30w+Ld4Zp/NwYiDNNitkk4HNsSNA5UJF9wYLCzUtYqhFt1Bg560spzPIJ2DsuXocM5bWPY VDhGhC+oYY6OcAYuekPzGT9HO2g+4yc6DBaGrGOgwQYXv2ALzQKUdSBCiMUT6sX482ZhfHqzYUu9 V5jiea9hio0omOI5ydiOO0Uxw3OKYxrgHOEpnvELMwhnJ2Z4zm7MQFwWMMlzWZHNRBUlTPNc0Hju 43Ioe34mp5g6iVDrjxaTDHnt9FmKttNnqdlOn5uOzhwbbqfPvQ7ONoaO22AGWWysC9VUFQhRTVOA 5qZHhCVjmLMTx8blpN20lDDclJgIhCk5ERhTghAn05EibapCRRhNw5Kkuvad9PZyv5ynYRZLrBAv oWVC8dWR370gvbt8qU/S1UhcjcTVSFyNxNVIvGdGwjTGYQllV0QMxBLtbwznW80Vv/bWgIVxAQ7G 4gTRAqwD2TAaDTz0mY6yoKmO+nyE9mapht6b5tisoATO7fRzH4wcFMDhSBucVc1CjK6GGp1VIv8P jYfoivTzDfqV4+8Lx8/cI+tYS1/20m/r+Vos3qA/3AzYjUz6Jr3iJrpGkitc6660yHY4KVVxt6yl O61lTV+6o1q6ZS2DeGJxYgHra+AZ46IjffaOrHMOkkK6o0K6ywrhmVCHnTrpzHjB47xCDS1BiXNJ EdqRKDx9duG5pJABTk5SxOA+Tmfdk1oruPZ3aYQvDYh3Ngahls7TYTgo/df32ye8n9/nzd2qzHw9 8Ojt4b+syVgmDX34p79saQePohi6/9Xna8rIQpffbQduc958djbyoOZL1uP/9dMft/T62zCWzUef Bl8niTxA4R95kzd3KeD7GeMOATChopElA+CdXMEUM+tey6GAWhIZtSG6+TEWSbX0ATeFBErTt9od caW4AjHJPNnaLxNj659g3Rv9UPu9brmf+NoKdrQPMxpxFijT5oQ7L7WTWXVqADzlTrgtQ5in5Am3 aQhngXw2KxP6BA9rwkMWzCe7siBIrcf5p6wXCHNy+eZTQ5kRpVZxqihml3BlmEeBfCQpy5bUCjbx saohyLv2suhJLePEUxZFhJkKsmginEHhEcVlBsiL0IuTLMcI0/0G407rJObrOMrPXXVmWnasBQkO zWXTah6U/kwswm30lhOu2tHMMHu3y9SUA8xGwoNTjWBVqjVgYwCHdG4CWAp75UAPqeuVA/Agn3pl Afzpp15ZwE7dU92p6GRA4QAudU1VOYAfhfy4DTYVJT8uXk1lpzLKNCjKAdw9m4pywLD9PoXsuMlm hcs9LKtcLsJZy+QilrVcrtFpx+QilnVbbuEZWXATy6gmd/iMqnITCyQfIjPkDpYxS64OGi/FM954 LXdXVBTkaosJilx9MUHCzRiTM7k3Y3Io92pUTHHrxoTYNSyEXO5kRQ2V4hiRO106hKRuHV3qXaKj T16rsdEpvik6eOWlGx3b6tmiQ18eyjHVIG4xpjkkNr9pFjkbhNrBqaFpJGzxucYCs12j8RafKzyI iulDLGZcXULSXJ3iRmDQtZMeNiaV23BKaSv/QP0GHe4aPeof0Td8S1HHxsW7w1dzcTUXV3NxNRdX c/H+motRlzuswiMMoB2jfUw6jrdvQPJMb6jd7I5gSm1WZAFQS5NXCoJGlFcLOHGnK7IlsryOQ84j sDc7mJdmMSMfru4/hPZmA0VBHG4sQXGV3sX1mevwI0oYnyLbbKzEkbNY2v313Rj9qyi8/6KwftqG 2BWDXG9UGzlMPhejiYRs46l9HUadCSBoxjD6XAyPyVQ13vGtHDXug87TqOTBJwIF2KZiZDqGwedi pOyHQScCTI0yNJuLkTUems4EWD0SLjqHwc82FSOzN/Q2FQMdepkL4DdjFtOgd2aRsR3qci42mBxD jAYfc0wEY6b8bPpZstt0WIq36bBUr9NhKsvmwtJsmwtLt2wujF7bVFiIkiPFwlyYCRrmwkzwMBlm hthkWBimk2Gw0+bCwmqbC4so2FyYJaXZVBiC1HQ2DDlrNhuGGDYbLxDTZtNhiHEzxYa5XNPxZDBq mpAdUzsrXmKwWPWY22njJASLtV2mdtY1hGCxnsvMzigjIViUbjKzM7JKDJYhTDTyGNgiMViMbYMx VMKvGLdlamfCgCvzJisyszNZkngrKmcyszMxlMmWialM7UyMZbJmYq6/yyjQ7DpItHgdRFq7DjJt nQ5CabyMT+2aDl/tug7vIQ59pZiqBqWoaA4l+LCcapviUX6pYlJ+quISdsdZvik8ERVTiBAkU5ci Z65OIYembSGmrowhxoOFGAgrfae9Lb8t4akKwu8yPN5isX+1GlercbUaV6txtRrvt9VoyppDgFO+ fRBU3IpZQAd18b2P9eqeL+MRrw+ICXIkBmXKskjrghhEmPoJlET9CzTnVIyWa8Zj1EZpoYz/pVkc kFqG/xKNqOf5kfY4PKAuThR6b+ResMXYJCSouqxLOY4cwbptE1f8P9/4X8XhFyAOC2FAKybRDapA 4dEjmFyGkrYpAO6S4qY7xVJUk51hfbH1FC8SC6j4hT7zrbwl7IAjnAk0OdWmF6dACablg+3y2XBJ 2ASvaZAXR92B8MHE2JGDAbzM3bDPOAtrGtMKjplNo6MB1lHeFEVigetjo4Vsh+NCFeZRYhchcT7S ayv7kbHXeVSowi724sK4azQz8i54+1fG/eLs1jpv2urswiWJgSZdkGnJJa+IWiFGlEsKkY6YuLis XJK9MyJa9LVH3w6lo5beQ5O589737kj4Yzsb4KxfvJ9+9p3QhsOaUCEHUAtPHYfPl9tRApHdvdpS bALyDHy1NjAazoFKb48L/4GCruGR5PBs8I/bJ3VuzDy73bT1rwbDEbWvtHo53AyFpr1A94o0EiJS 5hMH3BWOxL2ExFuWKKjTx5+QVOFlTsSS7XBcKGC1R4V6XDDPRzfg1/m8ejd4+t9fEtlPi/B2ogxt 6AVOxH3fSbxE6w3blXVuxKCPFuH0WV+EdsWEBj0RqbmkCGGElWGMedyRGEvcvvBp75kRX8+6z058 M8dLOTvoG5/axyq/f3CMf03/27G7sj9n/lMYk/Sw2zyz6BMI2BDcGvCeIZGXYUNgawJlgfhszbDm 42JkWiPCcgzFl8BSB1zt98bhuAkMzUDjGvEtmyFWikx/rWfjMkDBh9bjsyqdsmRSim136XSs9Rz+ iLfTaNTwgWHrRV0zqvIWHlIKWq+uPdfhqERBWV+OQ9J84dPui2yH40IB7eQaiQ1eUkfJi240p8VK BYUiYjtb6O7qQiz08iH05hJ1DRY3VddKn0vUNboShKaNJjWXFGHuBlKGMWaFuoaLHV5letsJWoPb lZfyiLrmaE6hyrdV13hqsFZ2HaJ3rhBEu+orlBJiG7jJo+eVdyEDqnjnCrjIPqyWVWTjVUTmGMp+ rqUOuFPY8DTAnDd8IgS34qrvamoP7EVO6WHRSPf6wteH2vN1J2Ty2mvtO16vwGO12sOz8Fit9mAd PFarPiPID80S7KrAsGyU5+0I9u1WH+ojKO/OYkBVe3dW1tD27iycVqu+Owuf1Wrvzgpz7OlZIYs9 PZsZtLg6rs0WyzRXq/bwbCc2Aw+wJQSBqvroakKMqqqPsuLWo9mpDiHdTKQ6BIir+uRrh5BuxkD/ PddF/li2clfr1pdotW36NqE0vSgLpGd5sfNQs7IAoCwolpUBQtGkDBCKJ2GA8CMpA4RfSRkg/OyU AWB3pywQaeh2C1nplAUsSmVSFkDSigWXhyQW2WVUSS0e4576WUZ9bdkwWIIg5J4c7w94afD69to4 X2gNZhHWVrHG2hX4LVpPcycdBx3warHTKSf0XOmIZ4uNzBmXrIwLeLbYuZQzBEC5yM8WO4fxOqUJ AJ6UdPkQzSHvWlbVJJAtvDAbNAs8TeVpXITQNKl1xQqp9t/jQ8c+KrRwfehY6raHjmsYcNpqe+a4 LMer9FlfORaK2DPHQjF75lgoOjgDStQkyhB95lj4Zc8cd6K2ZJQIt02NTbr116twRB0ISXIVCUlz DQpJdA0LQXUNDEHuu9v4au+C9hbrH6lO1I38qGPj8gferybiaiKuJuJqIq4m4v0yEdwGvEKN8NZg zBsRFjkLHBAtiKxQQvtQtTDc7BDnNbtxhLCscZVnKtCgA8oZwT4kpNYfAxQpbaP6yuhmUDAldaMo SHRBlUe8PfWkr9gstEWHsM2x9cCBI5FDXQ3YxsEDgyI86v4OrPxVEN5zQaDQxrCx/YQrGn0nJ4Xi vUe4t98JjQxSNsBN2t8IVBHRgsTi6YnrMRRfL0sdcGe/990AY8yEC4jFQ3EvDonWBYkfpz20A/EP u+Mrw1xKyPUm7iQabb9pgDiOuN4sfBxi9TeLLoeQ682izyHUf7PodIi53hbva9Zmse0Q5rlZ7Dt+ Z6BZaDwOCFebRc7DKwUNabv5axkZrDYLFMlmrzYLFIn3EZoFigTTm0aKlJ1hixQJgjeLFMlvMzSL FckGvvYWKxLvOvQaK5JPI3sLFQmd11uoSLwK0VtoSClNY0PiXYg+xIZk5ltsSAhOb8EhRX5DcEj8 HAnRh9iQrGI9wiMDozfNEXqPDcn0t+h8E076h8i7vteIXwgQ3vf+bGtC+k5FgZLXnf7KJKsa+w+h /PuqoQFZ7vq6fBOiLxpZkB996O2hLoVAeGLAE+MJCC8MgdG8LrwC4W3B+wbW1KYdD7EfQz8H7XeM fBboxCal1++2IDAWaM4ALNCcO1ijGfckzL0yV8LMG+unbhclY8ISzSRnwhrNJGta6pAchXLCEk1V TtCiEOIJG94m5JpfhsCE3WYbIVK1jaAJ8d9sgKHlNv4kYr4OT+m2jV48hmGDW6hmg18ewzDlIFRv +iNrpBCNc1ronOFIJQ27hcbCUxim0CAqru9aVIaQM1eWeArDlSnk1FQtHsNo9iqBvU9h+n0cRUXH hPoMjfFKftfR8RavFF1twtUmXG3C1SZcbcI/rU1g/9Be/BAWkEC15cIS7W8MQ8wk4xEoCI/LI6jV pVmRmEJqI5aoSiUSfKQP4dKbravegMajvGi+I+raAu3NUvXZ2+jYDKGhUcE+mDlWEYdjheEaeqmx LTq5EqeGehX6SFmOnMkssj1c9E5s+1UgfgkCcdZZjnhBPX3gqsMKb3KJ9STSIac17l4mWG/kaXrF 6y8wxHyHk3IV97LdqOkVr79kEPMdTspVXMS6a3rFl9STa+xP6MxKP36U4C0NzVxdwmQBTw7el3KB 25ryW8ow+lxQhvbEZSgv/d5WlwAuSAnKkhUPurPlLCMf8yC88BfbJx3CA+fN/uyNhoaLspb5kUsN 7J8YanIvufB6fAjX/Ppu7SUGXOBtrIeOLzH46+0Pff39Tx9tn8xqY8wtbX4TH2/3x+/YhvSdPa4m 24U45AImRDMQPJ0WEL+PDmg3wqQouwGmwneKF4kFdLgR1nccvA03whxU7Kn623RWgj+KKT1T7Hu6 H1aPHwydX8UB+jhy/nIUjchDlzTYZ59VDwveJ9vZdM5/BvL23HxDt3Z+eLmlaOrHAcKtjIQYbV7K pv8qjiOvjBe/fWLTSuk++8OvH0w48olpSPjk4WS8/vVk87D59JNtnufKmz8/3FTurqx2OMOLu22a bfL8Z/PTtknPXz//7vs3dBVvkHoJb2hZyl1MdLg7fHn3MrDizbogd7iv07Tr6+157vh9IH2aqtQe 72TIBTXFvSw6JLnCtdZ8ke1wUqriTk6/JbnCtTZ2ke1wUqrgNDaNFk7JDV5Sizce1QSSrLJfWkZs aujw6jKIcyMHYEdXZFNgVX5jdaDVZSVoL6LwhDdXLilDuKBlGFMeteW54o0jut2N0fkpOZzn1k2b u59en7PkueFhNc161pDnQV6osnqeu80Olvz7szWO06KQ8zVO/AKZV3hvnvTuU/9qO9DVx9Y257ta 8JJaI1OBCc/dYZumuf/D5svwKsTLs6UMvAdnpTxCMLwe5VXybc7Xr19u9U6ldyM0YTEVWnmhMyd+ marwLi3XFS5xfvbned5T+PGGp/Pc63gu9JvtEzKgy5/DTIpyQ5w+3T4ZZOr297/Qt5RPZc0JZkp+ 8vGW/NOob+F/Q75Q2dk3KKRDudnc7o8zrfDohTfoIyoY//nb+efS1dJv/v7rj1BJqWPIFdK+qT02 O1zRssSbBtyyf/t4Jttc2zBFsv3u91QLvp8unszgrfKScas7YccA8J4hXYJhSIBmuJl3oAMqHNkC OBfRmVJSLuIhJerxGML9yhIr5MkIYMKCmkBboBFxBxDxKYsrlXVg0Mg40j/BHmvhw+z3yrBoEpin 8J46on5OvqrUwDwlBJDGrxaditpW8jI6VbH4owD4RmSrkjVUCeJgl6TBVRAYqySNLoIo2iVpdBHE 1SpJQgYhCHfpNKIQR+UqncYHQwDv0nmAb4pPVDoNEMbxv0t36/HA8qTxwUQmJo0PJhSfND4YIo/n SeODGYf051xVihbYIrLVcYm5OGUoQpnlYbdozKAcEKkclAXckaxCKbHMclMOgA5Z5E5CmeWmTAAV c69MQDCz3C+ZkHtnAn7OgYW5epA82pLIVZmAH6vKBpOhKgcgOwaYBkVZALnLRVmAO3q5aKgqiG0u GsoKoctz1shXhpEc0ao8OSKZe3GIdGXVSShza45EyrJQ2GPohwTZsn5KHHMjwlADhSSUuRJQonsZ eSWSuZFfYoMZeySUubFPYospdxFN3HgvgclMNiT+jokOgh2ZZEkYZhU8nJ0GPTOCBiq2rlcl+Jj9 PgrsxjBItHQdRBInxgaZNk4HoYRRwwhFx2zwSgg1G9xCFhv8CKFmqkGoqppDQqiZYhGemOKRKGqm mIShprgkjJrqNYiDqTwJomYqUUTJVCaCqJlCFUlUfSth1EpRZW6BzyK1DybgxR4GiCbiaDRcHizz ahWuVuFqFa5W4WoV/umtQjalcTjCCT5BpwjLmQUOOWnps0B7b0BdGhhgifX5AKAAhYjp62ov4oAo 6wIt8lL7z6C9xhvN2RtoMAx7QSz/GbU8t8TMwIN11tTCY5rbudO8akN8DOVpFaphtoiYP9++X+Xh lyEPD54zMKvzZGefj8VIZG1j4d/Opc4dRA/RlB9LXSeaUfV5sEOZbjtsdr7n9PBnOnuyK6+J2kHY uylU4i57rLl309ICPtR31v06IQ4sfOveptD/C59fsmUKZW5kc3RyZWFtDWVuZG9iag0zNiAwIG9i ag08PC9Db250ZW50cyAzOCAwIFIvTWVkaWFCb3ggWzAgMCA3OTIgNjEyXS9QYXJlbnQgNDggMCBS L1Jlc291cmNlcyA8PC9Gb250IDM3IDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0lt YWdlQyAvSW1hZ2VJXT4+L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNMzcgMCBvYmoNPDwvRjE0IDUgMCBS L0YxNSAxNCAwIFI+Pg1lbmRvYmoNMzggMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5n dGggMTUyMTE+Pg1zdHJlYW0KeJztfVuTJLd15i/o/9CP3QpPKXFJALlvkk1qtWvLEjkr2eHYYHCb I1GO7qHEi+yfv4lzR2ZVddWwc3I0BPWg/qYyAXzAwQESOJe/3gy39X+f/erG3db/ffunm5Bux5xu n27yiH89wl+h/hHo/7+++ePPbn6nLw+HOJUhTLfrP+YSf/6pi3PZr/9488vXN87DS/P/5SEc/G10 h9Hfvn66uSv3t6//8+aT1zd/1TZwhdICbdTXN76U2zGlQ4rzkxWkfEhl/imGcsh+CenR+uYffnbz dq5mOKQhlxjm1s7llhTmVn738HZ+YTrU5/NhbuYTwzgdSn3dl1ybvML4uHTO794vjzB5Dzz8FF3L AxuqPOJhKJbHEhOvD4HHcJimOkYNHWiv0PERS+HmLzHT24XOeSbYVGUyHOw4LGHk4nfiEafBH6dR GyosXGyavYBEan8S3o3ZkoB2Kon5kWRZLHHcjcaI/X+WC7RWyFQ9a8dgiZnczmzGYSpH6WB7mU6c xkMwY7HEQm8fOtB4S6cUH0ZDh9ordAqVynSWmOntTMe5nI7SwfYqHbegs8RU6y50sPHn6biGTs7N Ir/CTO9DoRPDvNcydLC9SqfhcozYvkRC9uN4nIhl4ZsdyxrvRwSafZ6It9uXmOLBWW22xMxtZzr1 P6BTN2iWDrZX6fiDt2K1wkRvHzrQ+PN0oL1CZ/QH2/oFZHK7kMkp5rqtzHV7CfsA/BdDBporXGJq NsYrTOT2IePnz47zZGKym+UYvd1XrmDab7NsyOD/H+HizWYzxnlP3DR+if1+m801F/jDcoHWCpmQ moFYQKa2C5f5C9/ns1ygtUrFN5v+NU77jYtycWM6Qcbbr4BZkx8GO91X2O/4FTBPkCE9QwfaK3T8 hKct3PwlZnofCB0cL0MH26t08qFhs4DTfkdLSsZVPXacTG2ucgntB9oKI7l9yNQDv2fIhOb7zLt2 KBYw7Ph1doQMjJUl4+zIuKn58l9hIrczmbp3PkoGm6tscitXKzzteBCA58nn6eRG0Nz8KWlbv4B5 R0HjI8w8zDvmCGRgtCyZ2lzhMoxN4xeQqO1ChQ7NzjCBxiqT0J5frPD4AXCpH9CVCwqd5RLsaUaY 2iuLJRZy+7ChE7PTdKi9SicfJm/pLPGONxmGjpuSO04H2qt0km17OkJsHyJ0uGSIgDqwRJJhMTRf /Gu823ThM5nEV5RHiAz28z+U0hwsrTBz+0DogD4wbLC5yiY1R0trXHY8alI2s7yVo2ySPWkKJbZy tcJpx5MmPmA6wya2kjYcmsYvYNxRzvhIxnAB1WbJDOagKeRyiHaWLDGR25lM1WZHyWBzlU2a96aW zRITu33o4EnGOTbQXGXT3o6vMbH7QNjA0mPZNDfms85YSNoS73hnLmzq9+V4nI1vJW1YSNYS+z0l jU4yztEZGlFLpRWtJWZ6O9PxYQxH6WB7lU6qhRk6S1x2lDU+AFA6uJ5aOtBepeObQ+Y1Jnr70KFv 5lSts9xxOt4eO4fUGmissd/x4PkIHdgfWDqNyUYYp+ZwdoWZ3i50+NP5DB1sr9JJrXCt8LTjYa3S ieMJNqmRtTEsBmeJ046yxh/PwgZ3PJZNaMfGNQfnaxz2HBthU/86TsfZg/QQJ3s+u4RMbh8y9P18 hgw0V7nk5nh2jaf9jmuFTP0Pzp4XFzbUWiXTmmmtcd7vtFaMls+waay2QnSLoVjiHa22In+opXmr FmGvhtsdS8c1gxPyIVoVtsRMbx869DmQqjKIR+lge5VOsOfNK0jkdiHD22clg3s3SyaYA+gQWgO6 NQ67HUAbMmyLuibT2NMFPx2yHYslDjva00XePJ+hg+1VOq054BoTvZ3pkCkq7kMtm8Y6MPixPT9f 4R1tBCNvNs+wGZvjdB8WorbE436H6pF2Z2fIhFbQ3EKwljjsKGhMJs4bGziIxi21ZeMaQXNWgTWA ee3Dg/ZlaZa0kI8ScUaXudTeBqzwboqMdzGGCGykLZHU3A241k5zjdN+dwORtzEpzCt/Ok6nsdsM bjgEq7lWeEfLzWN0YDNt6UB7hc5Q2puaJWZ6u9DhjUwK9XT9KB1sr9KJ7WiscNnv6iby2p/q1KnL Z8GPA0sntqPTWAWvYNxzbHB5OcfF2gj7qTRHzkvM3HbhwqsLTB8HZOA7R8lQc5VNbI5o17jsdwId WTUnX+fNcTrRHtn6yS8GZ4njfke2x+jAZ5ul49vRGZr7gDX2O44Oq+ZzdAZ7PzDX0wrXEjO9fenM HIZylA62V+k0htsrWHYUNV5nlAx+h1oy1pDbl9gcN6/xfobckTVzctU86DiZaI+ffWkNt9c47nf8 HFk3p3qbNgId+Aq1dBpDbp8bU+clLDuacUee+2fIZGv5PI9bOxQrvJ/ls5LhkAdHyIztyITmJmCN xx3Hhue+0sEDAksn2JsBn10raAsY9rsZMGQo/MERMtaQ26fWcHuF836G3JEV2RkyqTHk9qk13F7j HQ25I899Q6eqOMumseP2aWzOztd4R0tuZXOUyGhP0X0Ktb2m4Us87niOztP+OBFoqRJpTOlXkGjt SkPiIBQ8hLJkrGW9H6dWmpY47WdbH3mGnCGDzVU2uRWpFZ52FLFbEwDhCJPcyNjYuDisYN5Rxhoe eDRoeYyNeLXuDWu8n7tDYKk6R6bxd/Cja47813hHfwelw9EPjtBx9hLALyJOrTDT24cODcoZOm0g Kh9bd4013tF9IzALiYFQ8NjW0mncN3wMi9FZ4h2dOAKzOEcntKPjFqOxxGHP0RE6FNKh4Cm0pePa 0Rls24cjxPYhQu0/R2RQFqF12VhhILYLEQ5HMfIfZVy4PFBjlYtvTv3XeEcHjsAxAiQAwhE63t4C +NC4bKyg3+8WIHCwgHNkrAeH96W5/VvhsJ8HxzEyrcsDtVbJpFauVrjsdxcY2LleAjqs2aRGzHzr 4rDGaU9BIx9uiRmwZtO4PHjfujis8Y4uD4FduJUNXkFZOo3Lg2+DHS6h39HhIbALt/jZr8k0IRC9 ax0C1ni/EIiBrmgNF7h9slwa9wDvhvYyZoV3dA8QNixvR9gMzd3MUBq5WkDmtg8XunE+Qwaaq1xi 46ixxmVHMSPPZyWD92iWTLR+G35oXQHWOO7nt2HokC44QqfxDfBD6wuwxjv6BgT2GD5Hp/ENcFNr P7/EQm8fOuQyzPYnBa85lQ01V9mMzWCs8Y4G9YH9bM+wGduxcYuxWeJxx7FRNqTejtBpDOpdmZor jBWedjSoD/xtc5oNNlfZtO4Aazztd6VxhA1cqVs2jXeAK2NzyLzGO/oHBHZMlbAbR+iM9uTZLSLs rvG439lzYMfUc3QaDwGXsz05X8I94+0G9uOUYBXFL26esLnKpTU5X+O832k6uz2eI9PYoLvc2pyv 8Y426IYOraNH6DRG6C5NzYHmCucdTdEDOz6eoYPtVTp2zrdg2vGA8wgRMESxRMzsT2ExKEu82+Rn h0cJIXKESGhHZGj8AdY47Dcunj0ez9EZrIvAvC41h4ArzPT2oUMujxx1o6BJjWGDzVU2Q3NutsZp v1NBzx6PZ9gM9hzNxWRPm5eQue3ChX0EJeTGmgw0V7m0Zs1rnHY7fD5GBqydLJnGytnF1qp5jXe0 cvbsIXiOTmPl7Np4zksYd7RxVjK851yTaeI7u9CaAa/xfmbBnr0dz5FpzIKdL23rlzjsaBbMVsGG DdihGTbYXGWTmmPANS4fAhv6HjjCJtljQedby9k1TvsdC3r2ejxHp7GkdW60prNL6He0pPXs+XiG DDRXubTJkNZ43M2SVsnwx80RMk1uJDe01oAr7HbMjXSEDlo/GjpDYx7ohtYccI13NA/07MZ5jk5j I+gWsYPXeEcrQc9unOfoNNZ1U25av4Buz1jChgx9fq7IYHOFS2urtYR5Typ8PXiaSmO4tYjquoDT jlZbx6iAxbBSaWO8ljav0xLuaB/k+ZrzNJMmzVMZ2kFZwB1zPCkTOt9YMxnsmOTWemYBmdguTNhB +DSV3NjSpMbVrEV5PzMayI9b29wUtXx+UZytaW7z++77nke359Hdks55Jj2P7n4keh7dFbmd2fQ8 ukBniXse3Zej0/PoNlyOEduXSM+j2/Pobkin59E1re95dDcn0/Po9jy6W3PpeXSh+T2P7uZkeh7d nkf3fZDpeXTHnkd3Kyo9j642vufRfS90eh7duCS2C5GeR7fn0X1fbHoeXW19z6O7HZ2eR7eRtJ5H dzM2PY9uLczQ6Xl0t6PT8+j2PLrvn07Po3sM9zy6L0Wm59G1je95dDdj0/Po9jy675dMz6OLdHoe 3a3Y9Dy6jWD1PLob8Oh5dKXtPY/u+6TT8+j2PLqbkOl5dC2bnkf3fdLpeXR7Ht1NyPQ8unae9Dy6 m5HpeXR7Ht33S6bn0T2GdzTk7nl0teE9j+5mNHoeXWSzxD2P7gvz6Hl0j7Dbl07Po0t0eh7d7ej0 PLq27T2P7ksT6Xl0ex7dvcj0PLprdvuw6Xl07Vj0PLobkel5dO1I9Dy6W5HpeXR7Ht33Rqfn0W3G pufR3Y5Oz6Pb8+i+Hzo9j25DpufR3Z5Oz6Pb8+huQaTn0e15dN8Xm55H15DpeXQ3o9Pz6FoyPY/u ZnR6Ht2eR/d9kOl5dHse3fdFp+fRta3veXQ3otLz6DKVnkd3SyY9j+6HkUdXP/8lkFPWkHTUPlOF 4LmyiuaGUC5abAv8+aAVUpraiid5FHuESlEwV/GgvUUNJzSvvFSGgsy/PDB32X5kfk77uwFz4Q/Y f/WwIpF6hlIoHABXYGBs+zcW7VDTwdiEYv9uHv1aEg9vmhEYi98sUe+x4l8+fy7Ucr6CH5PWVorf INvsuuyXTAILUfG2zs26qGSjlKlYy9aZTBe1bJRgFGrZPO/nqVpeKh1nW/7LZ8nE8rdOXrmoZaOc kljLtqkeoY6NMzBiHdsmRlzUsUW+whNVvGQaQahi2+x+iyo2SrqHtWydC+9ELS+aoq6tY5vMcVjH tgndTtXxknnWFnVslP4Matk4KxnWsWWyMKhh2xxebRUbpdbCSrbOeLWo5cUTUWH52+WHgvI3T9t0 opaXzaa0qGSbJEdYyaa5h6CKjVMCLerYKFMP1rJxAp0TlbxsXpumkq3SzWAlW2eBWdSyUXIWqGXz nClYy9apTE7V8rIZRqCWzRN/LGrZJh8HVrJxmoxFJZtkr8A6tk0q0daxUa4HiFKydQoGrGTrzAhY y7YJC6COjfMILOrYKLw/1rJ11P1FLdsEw4dKto5Rj5VsGzq+qePlI7pj8dsFWofyN49/jrVsHZb8 VC0vGy0catk8iDfWsm1sbaxj05DXUMXmkaixlq0DRJ+q5WXjNkMtm4dTbmvZJsox1rFt8GGsY+uY wFDLxqF6sY5tI+i2dWwV2BZq2Tje7KKOTcLAYh1bR2fFWjYOmtpWcrT8HxXLFMrfLMRoU/pGkT+x jq0DckItt5vFyVwX/6LhK8Gvb/Ookm0tWwV7xFq2jsEItWweGhFr2Tpi4aKWFw8kiOVvF98Pyt88 7B7Wsm00PKhj4yB1p+p40dhxWMnGId2wko0jrUElGwdAwzq2jUsGdWwdLqypZJsoXljFtsG1sI6t Y14tatkoFBXUsnmEKKxl48BNUMnW8ZQWlWwU5ghr2Tj60IlKXjYoEFaydaweqGXjEDpYx7aRbaCO zQPOLGrZKA4M1rJdeJZT5b9U1BQsf+tgJujHsnWMEaxl49AfWMmmETmgio0DZZyq42XjV2At24aV aOvYJtoD1LF5EAasZePYCG0lG4UswEq2jSQAdWzs4N/WsZXf/YlaXtgdHmvZ2ksdatnYeXxRxwY+ 3VjDlq7Wp2p4OQ9orGFDx+S2gg38haGCDd145/Jv6/9qUY2j7tIbd+Gsa/14vwZn0drS7iraXUUZ dVfRppbuKrqu9ZlauqtodxXVKrqraHcV7a6i3VW0u4p2V9Gb7ipKRXZXUVtJdxVd1dFdRburaHcV XdX6TC3dVXRZaVNJdxXlOrqraHcV9d1VtLuKHqmju4ouqmxq6a6itpbuKmpMULuraFNLdxXVQrur aHcV7a6i3VW0u4oegXndUU3x3VV0WWtTS3cVtaV2V1EtU6vorqLdVbS7inZXUd9dRbur6IlKuqto dxXtrqJtrU0t3VW0u4p2V9HuKtpdRW0l3VWUCu2uot1VtLuKVvShuYr2RKz7JGKtXT+Jnfvij9r1 dbtSe2cie1tf7RwZPjKMZI3MT8e1dXIW/8jFH7aWSCbQi2IR+oHMbuhpwaaWS7jQe0/LYhG6QOqa nhZ8cS23/3kDzg/DMN7+1w3u9wwzWHOE2ufvXKShAUUKj3ctEoY54/GOkC+4n3iXMllUqEju3h9R IvWlyiL2JQvjuxdJgyxFyqDXItWPffHuzz914627ff3Hm1++vnFwz16fxL/qZ/BYXVLhUPL1081/ 3L2+fzXe/XD/KlWTNJ/v3h79883j/f+9ff2/bj55fazYOsq21LtX97ev//Pkw2DAYtvwZq7JU00P 97F6nYzh7su5+ru/SL0zsXiSWDW9qaICbpG1BY5b8Gzfk/Hn6DMdKPgRNDfiR8EDXSvz88P6mvms Omnfe1qVS7j2S9RqGF460ZvXnpaFMkze1JCuUVchgj+BYQFfwMLiInGnQrSRUAY38sIiaNToEkbI ONxxXlSIDDXf5HD3XFMI94jKD/YIy89VPZK86Y/EbTg7p0MabucvnLqBhMn06/t5qxeGGOe5I/P3 b/Hc/A15qku3lnJ2AocC5+e2zheYwCPc88V5JxyFyKv56zRNY7777ayk5r3X5OLd3+5fxXpakONd vM93t1L8X2+qPMAQzH+AMObR/DHS+V/04OAhCrvieRtTMez/qufo5AHDhrbiuqmaRtyjo2dphThr wZFDAhZUHAtg3Nz5WjR9yrN8TeSTUzGsFVFm5xAB4r7KR9CUE52XVUx9hBstDyNAfYYYH/eE6n5y Ir/h6FFFzjh7whFgLAShG8iutDqeJnicAPSBY50ILh8Vj54wsCa7roqhVzCoBjqxVjQmW9rAPe6w xwfucWxKmbjHPaqL6WCJ8Fk++eFW7Lx2Qync6RCVpGLqdOzFuvUkiL+6ZMagZO7zEVdM3tyyQs3c 56S7MnU6Dn9J3OnwR8WZhcsDjCxbCR/3LFsT/A6gtjCWkfsc5ZbP/cmNumJfWiy/Q7fI+9CdVHYY sFO44jDgoswNC8OhmGYHuJxRWsFxr+DP3vRI8Nwj9DkAAqc9io7s2uMBxFfGIwTsEh6uEFEYeDhD PEQz2HhMpsIQRuwFkpUwHqwkhRFnDEtaSDijWBJDwhnHkhoyzkiS45BxvrKY8890dSWv87Tg4nna cPVemybzjRou85GIyXRF3jKbqVt4slOviSqgThVVQZ0uqoQGRVQNDRprouCNlqLBFi1GwiAqDmVF NCCJEitIkjRVnyiGql5RTFX9ohhP4hz5h5/dvJ21e9v5qLeL2WhXneOj1UH4O88P2uH8ri8UfaHo C0VfKPpC8REvFKNokSfAOdHYHAcwTA83LTbI47OjZ/Sg1ed2uUEsa8cR9GCXKpqRM3WpSAC8acCD PAiNX/ztI1N+sCpAGgcYVBgvjAhEGUANXy/Ux9MRdSEqXBoPWJS2jAuNkyyjNHVkqrRTR+1/aJl+ oRW/S8RHIRGXbtt8xtoDWvtXWDsisF95Ao9f0qKI6yjKHX+acKg5WEcqIBeo7yoK+DRefiUI3VK1 KB3XV2MmUrIIA2K8fuFrHVTGHu89NJ5Ygls60rkVw+l5xWh1gq4npIMRw8/wN3jsVZ2L1lUzhm6g JcZDRWzZlwJ2Avt+0aF1oICbKWAfDHqhUjV1YB/UhIc1gQ17CHtcS/lxgViaZ4M/qkxCj1FjxAAi yfxQGr4comHp2U8Ve8CzKwJ1kOc7YupAn7X/awdzQDLqf7GKoOHxHBKEhs8n7n8YXc+WRjT4niUB +mDk/ge58WwbSGLlRx4BFDvPTmsklp7MoElqcWOPeMKfcQQU0++wcZa3cUsuhWfcN0vlGXb00raM 22ZpOjqcEa8cuA+QdMZvCemTHKkTqM8yfotIn2ZUKtTjGT9kZEAy7pplwHIyo5lxyyyDnRMPfiQ4 JSMqGb+/RI4y7plFzjJ+v4kcZtg2s5Rm1IELKCKeUWfJFKDCZIpk3JDzDKK2yAQDZ0Sdf8REJmdO PFlpBBJP64yfETLlqQNFJaADoqoM6n5RKRk/Yljj0OiJQsqh0Vc08qLOMn5BibpDwWFlmPHzS1Ql iZ2o0oyfb6JqSWhFFWf8+AvsaUUbOJ9xvfDkf9RodFQvQ+GfH+Vn33p49xWjrxh9xegrRl8xfhor RmD98dRCA2YeLXqQR3HUzqEHW7ssPIrNKrJC87vJYTeKArQYHbJbIC20kF9DZhY86DoYFuti4AbB VDiCHswiiPrhSciJvnhGg2tfyMgRf5lKZyaLfvS/zOLfReIjEYlGIMDihCIfiVKuOBbGFWVugwFA iTEfUHJRdJjJNiRLOGpFPrZ4YBicw6MhICcIKqoVI2ap5aJ0bUCOjDv3IyYi1d41FX7wWiMvsPAL g3jeQKMIPzL2hYSPnhd8uZGXfe9pVS7jkfw2+flx7cd5CR9672lVLuNA8Sz5+bCOb/lsPbFYPjB4 wudC4yYsRBuLhXBjLy6ERhB8Twyji43GzKiT/4r00hWGZ0DGSBKQEUm6qkeCRCfFHuHhucDoC3bB NSLUrIrBXOpX93n+e/T+7rNPzhp7VV0v7z1j6QVfM7aWl7D0gi8q+rCqTfjV3GCZyHUjG9Ckz8Ny EmAXW8GIv9Q/C8ciVDBW23qE+CX1yCVI2CGWmRUuqHrkeYOHwpjCE1YELREEWg4hNeRRG88e7tBW dTwn9f7T4XqhzQX6CjgnIULANLNi0p9lBo4vacljyh342sDjz3S/WN30KnTmyta5gW8n4WKx4mSu fCtmGPBxZ+6Lq+PUxNes83sVJ71uFr8q+iCq2Fy7uqHwrWwAR6fCd7bw8VVx5FvYiI97c1Xu7BpS nauyuWMXZyv6hKzY6xV9hQPf4If6eDrYX+UuBj44K5bKoHC+lQ0Ikm2VXOjCFqNi17CS+2D4hqw4 RdspfJcM34wVumR6NGiHV+v/QW6qaUDkJru2qkJvRnOQa/CErOWWHKVhkFv0jJ0mt+woTANfUEGP y/V8AUDdXZCl3PULpu6fkLU8PyFrLiwOSNsTsK3A7DXayuiQM7OI7pAMyeiQNPVB9MiZewgdcLUH Y0DO3MMR/QxkAGJA2jQ+zdjFiBLKYxtjO/ZxPHgjGnHETiDJiSPODpaqmLAPWOow95BKZczIm2SW HEFEpNFfQgSeS+MJMdeWipkw3BhuOE09Hy0RnoroFKNTFd/kDg/sTdl04KQdXoyK4P5nFRI9ayBn h481UHSsgRLj2gmiwNDXWRUcyo6qP6hGtSOKnSpPdE5VxQrd4CTcEltTRNgD1K6nu3OroRt1Qpe3 +DtPh+vN7voS0JeAvgT0JaAvAR/eEoAaOeaDQAX1EsGCB/NguV3+HRIP3oOtuVlDHPhqLkGVOXzy 4YZOC1UM8JSJqjkByCDKYoP0RJMQtg8kfViscWjAuEIgTGR49bW+LfGwltphQJkw2nmU/m3GRcaJ +oDEV2ZGO1Oy/QL73cut5V0iPgqJOOabO0GmihDgMGtxxEqXq95TylU/gYYm/Ai4erIjrkXVyAce VhaDILwAYZE0KktaWM+fbYsFczqHSVYHwQIrcNJdBkH3E6amPCoNvu8kloFjvfBRzU+ZPNwv4MX8 vH0f4O4Z4SPAWdoRVjDho3VzrwimDWFX6LaOSnKFSiKiS0i3V/K0wXVdRjwjeHMo8ifXyQ141KbL hRgx0wAsP1HGF5tKaRIyskipOLFFyqy/KlY7qIrE8AmK5FDLaAtTsVg+VVLJseUNLAkVs2WNsynO 0BKn4syWOQjF8GnCx8XwKRVwlmYboJpRTAyf6tXCOInhExzxjxNb3sD+T/OeoflRGIvYPtVuGDkb CFovVSy2TwWgvSUNI2ciwhvtivHtulmrKCT7K2dDQ0upilM0hVM8FTSUoiN20zSJJhIBpIYWx89H S6mKve0VDgSLllIVi6lZ7dExco9DpRX7qAMyGiu2mvmMehwHc+TQ+mAmVaG3oiDZ2ehQeqQE1SRJ IwexQ0spciFXORw5BBKaRtWcaKmF9s6+eXxKpjg0StHq0GhFWoM2LdpYsHhRLmgQo1TRYEa7Auxp qJtwUmoX4iTWLiYdI0OApjw6RGjqIyOIlkA6wATYbgqFfFTTqeyN6ID9kQgWWiep2KHxkoolWEap 1KKtk8g02lWpyHNpPCXQLktnDLeFZxQuSzLhcjKTEe3BdLJyH/BkRiUtc526EPUAWqKpkqD+FyWC lmyqY2jsRAehGZyoKBx5UWBoQ6cKjuRGFCBY4Kl+JLFj7YnWEqpcSWo1paPYPoGdWe1cCJdnVLTV JmyCIdPgXcxku+7vur/r/q77u+7/wHQ/2ZGQDR1hQfj52aCHG4Phe2CJaE1hM0KoP8gychgAwrMW oFE6PYmWisEIQ3I4AbCWU0heVSwImXGxCW3MuFrJtIttQrgCpACglq/tu2Jw2qgINKm0FIp0eTM2 shDmZMcOZ8dqstAaLGavP2oV76LwcYjCNS5L9QSC7fJIY9SPe17XACRtBn34yxJJdpeyhNKwyxJL Ay8rMDZXFmhS87x+06IgyzupfVn+Se3z1kASAuLGgRYB2VjQIiAbD1qwZGNCi4LsW7zs5erpVRaH GgS0zYBFmJYI2S5p1kCMu0knPLTVohVD9nW0aJjS+FQFt4W4oJuWBO7yyIcwzlsaMsHrqk1LiukF 3kzDOk2bDe1C2UzjGV42m2kYgXYzLVkFefxkM13Qsl020zT8spsuh8KTxUjPQGD0PNVJ7JKsvvCK ZhqEBrC9GiNZyqH1zcOTt4XVvjAVeeQ86NKsTcyijWQpVwN3Wfq1B3CUpYNABrT7UGK0e1GitPtz MkNDB6g8cpkOCkUDpHbccVaoXOCsUbnBSSZiBVPQHOUVnFoslHpoSVunCfuFfbzKgWbEEE1p4uKV UcrEx4vaIj5e+SAzjXmIixcdMoqLF3VD0s1qttOc+1B9vIZodASNgLh4RVRA4uVF4ydeXuGQVD/x 6IuTlzcroBEdcfLy2Mfi5IWSx9oT5cBoVpBbNQxvXZCorU+8pZMHjUax/ng8Hd7JabWvAH0F6CtA XwH6CvChrACJxwI9DosoDIOCX6AH++yYbteIbyIfTOXNKlIGnrEtyvLsAx8+WgU3FKnlFJJXFRsE HgNSrHWJFMcCs9AFf7tErBCCF5fDLErhaaUjVCkvdPRgNIpZAnHuCZbZsZwttAQbH9Qfv5Z3ifg4 JOKYnQw9V8Dk4lpXRIzAFydOYIf+kXFSW95sgg7w84wvd0W07z2tymXMhoz8POPLXQTte0+rctnp rtCBLj0v+Jp6vKXTusJe6HcHZWhTsQxu6sVlVL7jwJHnhc/lLpHcSVyI6aRr/CqBjQoSsmFBuqIM Ggz1ZuTBucARkSI68Ew4FYA+nfdJJNd3mU/n3RIxiI1W+RJeiWBSGx3suy+LP59M7PlnunnEzLZj pgThqcZPZfjIcCT7cH6a8aVTvn3vaVkswYFukPhpxpdOxPa9p2WxCCMbPNHTgq+ppaYGslxKUTIX STcXYptairb14kJg7DBbhRDCHflFRfBwYwncQ1cUwESs/JSiAnRNITQUUogMTS3ESV6Zs9N+xE/I cTw7588mnRgpX9b4/IQfpwHHnmr72iSmmSe5v/vK/MO3UulguZye+qMDFTaGeooB5X/+zQ/fPtzX 4NIzpbs3t/evZrUAf//5/tXERGdNMG8u0lAyZaKYPzcq+PKrr7598913/3BfdUnVHrdnu4Fq9/FA eS/+ae7LuYYw3r357vv5byjUVPz2y+/vXThMLth//ebt7X2Yqr5K2pQrmntJG13dTEEbjUL89pvv K9Mwd//dNw/1T1CO3zzevwqkPqWuf7if5J9ezRygT1/Pv2JR+tc/z7xRiR99xfypvfX5P1aFPcxt U7UsIWQ58mt2GIqU7bazwzgXaKmdIa5KCzjQKsAR7bOxlJripdHXK8wOJPy8YJRnxBVBAhlwP1EE lQ4YKZUdi7j54kgkEXJ5oWgj5/6UaB8NGYL55QaHU/uKbfo4YIy5TPepCTcdmS7vCI503MFPM758 xbbvPS2LRRimthbBl6+l9r2nZbEEM5mT89OMr6mljorlkoqSuXCNQiumqS1E2npxITB2lKRKGI3X LNk43lQE99EVJXB/WAlKRUXoqv7AwdD+4MFp1+wTK3Wd6vWwe7WvtYvC2Q36iCFApJTzy3UBtzN9 +Os3X341r8v0xnC2uQ4jvoHbHDT3O1iM3YQrzJsv5uZXx5+6zplV6Peprh3FJ3f3hS7A4aIFmAIj Trz8v+sCDE2DZoZTTftFfR4XtkuWXWyZS7w1+M39q3xwc7H+7s1/f38/UtVfUAefKwuP1U1ZdmE9 9yKFA9QXdZX+9ss//vHPlejcFcM4f3kxty8e7jP9+ag99OV5usm/axOpnwYR8U8f64YwzZ9p857k v+aNUcBNiW4rvvx/bx6hM6FlRzcZ/7P+HufhnO6++cvtvcOHLSEz+k/z3y4eYOy/txsQdHONroAj Scz48eDwpDBmUDKA6t819qHDsJ+KaEmkOKWcd4MKgoibrO8WgM5f5EnFsTCuyEcOxmlQxFoRO7qT kebzWRWzIyz7j58k60vjG1AGAHQt4lQgHFSPU4FwQENOBeIj+/pBNhCO6MfZQHwgF19MBuIDH/JB MhDOjs7JQLxXd3w4I/Tqjg/97Tm7B3ai1+QfEFPOaXIQ6DgnyUNuKWePhA3AlD4SVYASAj1S0AHK /yMujpQ64JHdOCmNgbhxzphAsANC+QtkwPR38QE14kdFu8I9PqCGK+oFiz9L+IM6Xi5zjyMvlw/2 GNVxGk/qEyfZnTFEn0vc5Z6VunQ5q1cdEJc05w2I2qgRECKfUj1yBIqKo5UGSlRPASyii9znKEsu agQE6InInY6y6CJHQAA/WRfNntsFPqbG7Bcu6J6csPwO/YIv4yZfC8ZPAK24YKdIwyboFGk3Rv4T WhN3CvnYD02noFO89hk6zWufolO9dDm63OuAoEu+Dhi67OuAwtZExxsd/kUcMByASguoMxalSIqF JQ0DDagkxlZPRqsbHzmIQcUS1MCoIX4bp0gkfcfzh6qW+RVJX/L8o3bL9IwUgtsdDGmZ25EiffLE pz4TxRAxQKlve5zVCoa0UK1DAyZaCcNhGK2F461KbUItxToPhEU1YuEopdY52ihUCWmqUur5wkdC HoiKJw9tlH56bqVwdHLYA9u+KPRFoS8KfVHoi8JHsihgLgj+qmGIny6nEH7INNig2r0NepBJw7kX WiwrkaBBkkRomi+RhgZTokhqhAUPNwoHSaaxRBj+k+t0YbX4maxox9CDWelQJTytVQQlC1MGhFlP U2eYsRpM2guZDjpb7OywsXBeYoXvQvHRCMVf2ZoyclieGrncC34EXKtBzHHNMaibQTmZqOcsP1wW NYGNSJaQtLY8bfAQGQeHexH0wBbgMdo6QI4sJxQkGQhRJNypX+H8HgcKYM6pdzhAD9ksR4pNx5l7 JL4P2lNHDsfEiX8kfg9epkcOhUdJgwbOeAF7jDhIOiq8tR8kHRVYE3AUPk5YNEg2KhT2gdNR4fZh kHRUkc9O2UscFkoOEEh27HGQfFSRDlrFBD4OkowqcI+THTnsDzhyISd5kgGhVB6Dt0CST+FmwmIj j5whiiOTSVM0HRUMkKSjIhaSjgo3QoMYdKK/+8R2gRgkYGL3CbqDEvcJjC8wTXYEwlR0BBLiFHUA KzbG+BWK90T1IpzEfQJjI0ziPoEe75O4T0BohYndJya+L6MxwKkxid31oJdn7FdMFtgMeH6gD7I+ 7A5NQY4v4iZjJC3tQP9naSR5RwsJ8p4WkuRdPRkD7hK1j8g5W7qQPLeli9GxWwaA/L5lgMgvnMcv 26GlFFEy9JRYSUSDckQNJk1TjCpZlCJKBI+yOolgYoooEVvVqzmZn0UnYQ4omSJcuuRmgiRQMsG4 bRqtC6RYUjMlnqvip5Dt3KbUWTL3KRMUqwbMuyWKgy5+RLFQ2i7RO5gIStQSZf1irUV5oESnUcYw 0XmUCUp0IiUcE51JmaBYpWK2MlG4lFqGw302DvHa35o9iB/k/Dg6HmZGvFNElL4o9EWhLwp9UeiL wge8KODX4kCmxC3mlG4rlJNJBodY3vT2zwdbtV1WCJNb4lEkydxI4fHf/BdWa4G+gQ0+CTRYxzRq sxTLXBdU4+4gYs8beJpMseSJpKr7tKrWHpHBIdYyRdJiTgBuT2leYj3vAvB3KgDH3DQGDLiVQKm9 Ww64XNAZgH1usmRgcBzaDSOn0vOMr8wBR+89rcplHCI7ROHzjK/MAUfvPa3KZexIs/PzjK/MAWf4 eI7IJW4DFxeijcVCuLFX5YDL9Wz/SQnR0nZVDjgqQzrpmjKYjEoSkmFJuqoQRxGluRAenktdr0KK bCr5L78Vn4N/Flu8z887XlGgRSrjvN/VhPNfK3yxbHAhivtDJUFmd2qu97kxqWsiUtWjysAB5vDY L2B0OogqiJ1JYaUMgoBPjCNtN7ikmOhkEsVrCUfOY0lPG1wD2yGuyMO7dcsqAOMzI+RwXkJA4utJ JK+0PKP96fE+GqUeP/vKKkh9O18KvlPdpMBZKcCXKBqI3s/zZP6v2vWmuz9Vgf3h22rUO9y9uR2/ +h/VdyXM/8W7289+/ctmBkmpLtXdv5bazh3zGNC3tf/6N5/e10zrd/96vGRqr3Pii/j6fhzvfnj7 9s3jibbMva3Pn2oJXl7Zct+8fZCe+PIvV/szhkRZmtGljSD7ALIE8cMEr/RmxNeeFmUS8nhdz48S vNKTEV97WpRJaPBNDQSv9GK0HIrOtGu89mwjS5FWXuPBGPKAK7iQucZ7kPqDy+DueQcHxEZqSlGx uaqQwTf9QQOz8mE84/dHZy4YBRWmw9NfHu9f1Xujaix+3ja/0CaPX37GgZHi/srTV7lE4Dof4LQE 18i5nY58FM43M2CcX3n3fDPBBdJWZK33G4v523sImZvvvvnLm2+rP0RG/4zGIeK7tSF8CJiPnSy7 ET4CrGsBwAro0dAgWL0E83tQjHhIoWSvMIW0kecN9gzJzruinBQlMgkHQIdLUk5haxVqVGnX7J8m 66tsHuvWL0Uyeiy0ExSTxwodm0DWLUWUXHD1TIluj8WqrWIyeouoaTkXHFQSouSCoy2Q5ILD3VOU XHC0qZFccLiTYeO9ug2OkgrOo44X70T80bOhYP2+iJIaDm/Q43AwdoQVitlh7as4NBmZKh7YiLGg ABU1YhR5QrMIEiExYtHxozzxgU5M+W0eTrSBrDiaukPhEahtDiHzAGDTQ+YRQGuAkNXUEz5H88GY hVYZnWyvhdTkPxQZph4PSQcApooxgCSRZQNIFW8a7CC2MpiYPow8BigrgUx90ADSfDejpAWxDYPj x4oHNogsoCUlBaVHbEwgKwwLbGzLzNuFv4OtYZqpvD0cQLs2bfqEvSLMJu4Yz0ZztmPQpk77DY0g qVPRHk97HE0gdUDQnE8HDE0gdUDBGlCGGy0gVRrQlFClJUYjSpFWKZY0NIEUQYykhozaITVUjD2P in1E9UaTIooSY+NLnK48pahymXJoBKlTklrOMxZtIHVCI22Z72gEqcqAek2UBRhBkiKhHo9tqkdV QjRcoqTQBNIoMRxt0XET6ixRgSAqqiELqi1RoChpqmCt8kUpjZEVe2sXTxpFrObkwZXG0clhgxf1 RaIvEn2R6ItEXyQ+zkUCz3Sx658W+ATi75wGG1S/iRokNtGUNO9xgWVpOoLEJrrRgorR7pkbYQHb RHPz+bUj6MHO+uVqSE2iSb9CbBTtRYc8WSUhar1V5IRZ4rk7dLi8GT2eDyfmx8pS/seu+V0uPiK5 OBZrh5YCzLZzfbCdEbOVpijRVghygBqJNcxPM74m2I6+97QslmAkByR+mvE1YXD0vadlsQS9b7l4 v+LybC1DbLlQ2HR/xVEqFmKbWgvhtl5cyChJbp+UkbsiDCUPOJXBnXRNEUzGylAqKkRXFYLDoYXw 8FwZIq/G3i6wMMNp6q/u55mXRu/vPvvk/OFy/WzRN5+JtlMwxK/W89Lx8SgCL2xakMjc/lk/+DRM dxD1ZlgF5Pnin+4jnVB/cj/RP37++p5P14+GXGnK/W09bcb3PvvX+4kC62j0mfpv+Og/QgvgZ/1H vTz+4vX8J77z7/K2aer5sSD2cZJD8aaV//uT+3qT9+9N0Dky2mHXspTRNod9yTTM/fwnR8ivKpQR +VQRHCfaq1E544SbM55pK8yRd/l5g+c6CVc0YOnegghh3whTRGth0JqwCNa4cz9V5s8ae2BiZ9xO zx3j4ROH8KNgdgrm5xlfbntk33talUt4ok8/epzh5RZB5rWnZaEEM5mI0sMML68DtpeGCXz3CZML bWygEG0olMENvbAIGTmIGa10Ll5UzGBj2GnpoIuL4N5Q+cHeYPm5phAcCSmDB+Z5eyNMRenQq5Li kSXSg7//VdXsECnt/NoWCiavl1KeMzlqKrzI4OjSMfUuNbORsM7GKbWzcVpHRLxoNk6pnY1cDuPs 2eIQn2d85Xyk955W5TIe6bKen2d87ZxUPiiFU7p+TprGYiHc2GtmZR0xOysro3jtvJRCTDddXgjR MbKECVtYlq7qk5HCO3OfjMa64uiMhG3yILESf/9vdRbWLaYxAPzFb56bj7W9XMgzkdcx24/W+BIW gHD45YpnC8Df/1vduw3zf+7uF3UTiIX+5hrzJNwPOFL89D3hSPEjdBxelp4WfOX3JL33tCyW4EiH m/w04yu/J+m9p2WxBENuuTC+8nuy4QKqishc8/XUNBUmVL5iQpmxy0m/J11IV1gK64Bnjd56XRH8 KWhlCLTFNbsH7hEcDu0RHp6rvicxo9gA58EwUf723491osCnF0y5t8+ZLNUvGSngWZOlmsvFVLfJ Z6XDCLuryLTxfv4dthZ/O0vKwyeAlvKMgRNcONg60RDr5/cDWS1dkfXhRB/HcnFzJjgyWzcHYseT ndXz36Yuwen8ed0pgWPt97pGutVvdPOofmubXvn013XU538Nzrz1WWPqJbTQ6KmuFojmvUjGGQGw Ah0PQZTK12C8fKCCUnNAt8Yc8okeN3BMjCNuNxyaVQmCmh5uDC6lqdlcejFUW6+fJO1L7/Hr/VNd 5OkaH66ncNGXe94KJabcrOtccXqNnBNge41csVwjD/g8X4jX0gaNKldpFRNWbsDfo95wVyhR5QJg vdxw2USVg92riaUDu9dJP35BH0mUOVj7XKbjBF9vPivCa0MMQFsxbdQTqg/5XE8gJXSuD6uZSBSG 9yEhQkwSRvf4YyMnWBYNpYdjYhUxbgdHR8MwuSpEzIKDq/EHBsVe407g0GxwFVJh9rYPo/Y3fK5E 7XB4m/4GIZOIcTh2WSLKDSjOEmcIRx6n1yObTjiQXBUcnAQgWOaziKQue75W99gLjq/dA7J0fEsv 2JiHmMfjIdrSIrKW2uQjjZoyHpJp6Mi8B2PZYngm5j3yldHQ9FNG3uZmVjs42N4PtERJWL2CrE1c Pa9Di/fFOvKB1lsTV88lIzl4Ha2ShdfVVoeEZIRSdabj2+5kZBptD0TkuTCJozccopkt3BY5q5tw vIqaRdi5iOcxOlW5IyTkV8FJwlM9WD2Al2ikJKjzRYOA8YfqFxo71T+J9Y+NwKjaa0T9I8oNBUeV H34sqnIEuVPdCXf3qlpRaItcY8ktvahzPA5CayZ5UPSJxKjE33k2vIMpV18C+hLQl4C+BPQl4ENZ AvDoLdOVOdmlETYIDHIsetBnMRDRCg2ilx5sA5qlpJCFyxJ5frRa1cRDo+EizgGs5zhK+qpigxIH 2ibwwEsTppkySx2GpF0h0gBij8MvJ1pGrYZQldyqaBPpOZVmqMzA6RK9nCorG60XWcy7SHwcInE8 Fdqtm/K72WbVlSRIIk48S5WkogAd9RM/zfjKRGj03tOyWIRJcorCw+nqlKLmtadFmZTvK6hBQfWG C9ddkFG2roZFKkrjmpRftpmpSDuvSYDmAhtkIZfLD+F5kLWfrnqd+8HKTCoqNFflTwuc8hRPsIJe iV18co4nZBh+HY5J35ospX/69v7VgNZF7u7N+dNd3D1IQc+eoJem1pc/QJ83Dxhd7Vxmt/NpWAPs mKSUZ8/P5540VeJ59e29iwc4R/55PTPHI2XJ+nnBkfpzGb4m2Fuaek1yrjffPpv8DHuqRAoa9B93 v/9zfR8tyr79vl411Ib+8OVjbR8lVfv8/1Rf5rnZKd39Ek7FMaGYHnrr+Xh7qH6WSd3HmpZYO7iA Ynj3ab28RXJqz/YHynxXj+ZNHXXJBt3vBrpjIi9dx5GWyHWYcMRtuYMYagaMeAAMuPDmGksqpVG7 S8jLGD1soCdEfsQFz7757xLVxdhxiDdpPJtIMDk1vaB9yk+O9FGba7ykK+t1/ejT2CeYYmGxC7gw 4ilEIfV+wgteCltZce0cikLqfeG4k7BLqTjz79XWgBPCUsxMjylgJQ6p9/xj/Y0jqmEMUs/JZila Z8X0eAQwYEEwSt5z7FVYSSqkyJ9k5SuxV+GDvGKK/AlbV+8l9ipssipOtxykraLA0OHTFPlzwF6Q 4Kv1E7VCivw5YCdQgMVxQgtjjr+Ihojec3xGxbF5XmKvUnEcfhUrk+ir1BaJvkptlfCrSEWirxJR b3uBY+txL0n0VepFE34VetktBoHDr0b4W2KvwuiZ2KswuhJ7Fe/vTejV2glOY69O+LNEvwWbGxN7 FWxyTPDV2gvOBF+tYus0+Gpl7STYKmEJxgqnC/o4HCaY0uphgqkMDg9MY9BmRhqbByWCQfGUJwbN 027A8KvaTRgAU7sR469KF2P8TB0BiL+qA4ThN3UAMf6qDjAE76TBx9irKhkY+FMFB4OvqmBh2FAV PIy+KmKJUUdVaglMzY8mBKkvOkO4aBODdExmfnHTTAxSmq3B0uIYpIFnq8QgLcXMfeozCUFKXZoW Pa4hSKNVPDxgrJV4QFlr0YB7jRMp6g7FRHUhipHqSpAyVaUohKpqUUZFE6MI+4mNjSQWasIGwDfm U6vQUbt4/vWRf+WJcX2A7L5c9OWiLxd9uejLxd/vchFFfTwt8EmUCgQfttigyS/Qg22ALDyKdRlZ gvlN9OkxCtDiirIsaC3CdwnX9uubK/RglsLFykhNIo2wQg+6DIJCeLL6gjX0WQ3OXSFDh/wZnpwn Nor2j1/0uyz8/cvCsViqpAjwYO+dzwTqA37iRCgUoXLihR1TX/hy4NW1euv7wms7hhfwhdd2DNzh i13bg8+8tmPYD58PZmdQIa3tEYDjLUfG+J7FbDkqTrzlGDTiJ+1YKnS8g6lhOvzICz16uPuRxx3C dPiRBwcDpfjxYPZ1wUfdW0WAmX+GbqA7edqoVeyNKAQCGODF01W//EimAeQIWfEQbeH+wFtK6BfP XU5N89zlGGPEe+5yJOa4yzE8iXeHplscdzkEN/FOOx06ddBOr+EG/KCdDoMyHHg8PT7u7IC6SXPP QJBv0QYgDo51F6VhcbyQoTA580kRAWaz06s48sx1+Lg382vGDeAfMQeLM0tsFRdn1thiq8YkLNIy ylnHDa85WIQURdoX0hRpXzqF0rBwn+E2QruU0rBIl+MuRIcE87DIgOEeRsaT0rDIcMMGSIWBsrCI sOD+SYWJ0rCwrOH2S0WR0rCIqOLu7RjOvJsDcYm2sKjbymLmDDeF5xRliJEpR0xoQlJ6GZmv3A08 nSk9jUx37kVWB5TchrUFD0LSQfBG1/AQsi6iZAuiqOr4ixLD5Iaq41B0VAVO2A2iIlHyVIUW7AfW sCi4qoAhrKufVnlRsN8xJ0ajxRuVM/IWsf7uaCv6TmcBfZnoy0RfJvoy0ZeJv69lAqdeIMXdYIM0 thKhB/sspBg6jR5M/bLgCDSLByEQRUqOTd9uRu9h1Dqq5xSSdxUb5OUbkdCD6oG8WhOpVccBf/ep DuFvcNUa8A3eaG6pWPtCB86ZcXxmqjTnAD96we/y8HHIwzFPfFx0xiE+a0pAawiZ8T//NCqmEVTo JU+DIIlJ0tmncZ2tjuoXmECQNDvMYb96WlKlUJ6xMRSJefXZ/USJUt589cPb+7qoVvDVl/PfmCzm 7ns1Yvr/+3hSFAplbmRzdHJlYW0NZW5kb2JqDTM5IDAgb2JqDTw8L0NvbnRlbnRzIDQxIDAgUi9N ZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgNDAg MCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAv UGFnZT4+DWVuZG9iag00MCAwIG9iag08PC9GMTYgNSAwIFI+Pg1lbmRvYmoNNDEgMCBvYmoNPDwv RmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggMjQ2Pj4Nc3RyZWFtCnicjZDBTsMwDIafIO+QY4I0 E9uJk1wnAYIbU26IA6LtGFpbMWASb0/bTVAkmJAP+eN8/x8nL8rpsVZXCvVYu7Vi0SGKblUMB7Wd FI+Cj+uTas7U7bf5IAbz+SXKEFMatSzKM2SaTg6KhMClIQHHXWmVWV0vrS7P6qL8xjM5SD/4xSma PTDN6Duz6WwEFkE2jR3DfDS9vdfl5o8M7wiy/PdGjwJ+Drd9VW9PGJD89AEuAx5H3Fl0QI7I1FYA s0Q2+81rXWm7CJAkJTFvFglCDmL6oSsQhFKYO9t+b5EhOp9NPSAEMYYsc6R676qH7vHj6/Wf679q /wplbmRzdHJlYW0NZW5kb2JqDTQyIDAgb2JqDTw8L0NvbnRlbnRzIDQ0IDAgUi9NZWRpYUJveCBb MCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2VzIDw8L0ZvbnQgNDMgMCBSL1Byb2NT ZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldPj4vVHlwZSAvUGFnZT4+DWVu ZG9iag00MyAwIG9iag08PC9GMTcgNSAwIFIvRjE4IDE0IDAgUj4+DWVuZG9iag00NCAwIG9iag08 PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NDA5Pj4Nc3RyZWFtCnic7V1tkxzHbf4F9x/2 466ruOm36elxlT9YiZQoiWyLZOxKyS4WfTpKcm5J+XR2nErlv2eAB0Bj9pbLOYmp2NTKH3wPdwbd DaCBbjTQ88ersKH/Pf3Hq7ih/919dZXrZhjr5nA1Dvjrlv/K9EeW///66tVPrj7vL4d9mVrI0+bh HzPFv/skjjPt56+uPnp+FRO/NP/fGPI+bUrcD2nz/HD1xTbu6jbsfrd5/s9XHz+/+uNMNYeZSJmJ DWFobX5zP5YY5z59d/36KrW2T2Xu0LgvZe5vjnXPHWU8dzaO+9QUE5obyrXup+pRaZvrK8U57zFQ oZXLPifCZdjHdAKnffGPdxiawByHPX5qzQA3Q80yRC86mTpQx2/7CAXPbJ+5fmHMGcZMyo/jP4gx w7Cf5r6NaT+mmS8xo6/At4bzRP93q48rFKWnVsaphrFtHv7hWsFrhwdUBacpgWN43KBrZcVY5LXD A6qKx7h3jQha20bc/IEeqSGEYfOfRORoXLUP69n3JbgYQu0j+J4EWcBkWA426ADxfh+CpiKgaFz9 ASTBRa+Dtavg9+cii9aYKIJ+Zkb6xHuzWW7dLMc92ROyzPxXxawcJgJsnZ++2T0Z93Uaat3+afdk npljS+P2/pvdMD+TS9u+7v/6lZnxt9OeLUUT2j//6mZ+edrPZMZpe7/ZpTZbnThun++eDNu7XdvH MU9pe3OzMcJLr3LcBBuGnAaycNzEt2/u7nex7Wto4/YbaizmUMr2zesN/TOB7ZtXmxX9jolsDxO9 n3s2za/Ofby5WXiu8wKcAul4ma0Y2ec0TrPMgG4V5UAW79aeVbzWCi3fOxyTBcyz9x1dK4ZXW4jF e4djsoCppd4EwGr6bSIl6aNogRyIDWPdfAGR3kkQsV6uI9JlNivBoQ+H1y8riXRJMw1lz2NIKEdU d4QhojyPIUGSMAIQC71+1iykyKuEMhayV+/ZLqTZ6c+MKLUvCT/dVZmnjsh3O23v/iW13VINk3/g elf28+9D3q61F3HiZU6Zh1eLNv1kFtPczrj9BbUCC/Ts+W5+YzZNZftz+lc04x74+92TGKgfefvx btrP/xbL9sW5YWvb83JYjZWj51r57OMdsT/m7U/PsjFHWkR5es/uqdeZXr37phN8/dXuSd7P7iDE 7WY3z6nZ/LbtF5H4O5vftv3din7nIRjPnv5yHnLmwf8b84HGMBvxJnzoHHn6YuYv9Yla/IdZyrOQ 83B+YNrg7Bxmjf1/EVKOhabueSGdk03CwtWRcb7ou83MKTDC/evrL2/+ctYvad9C3Fcmuv2Pm//a 7DbP/wBvZDs63b7Zfq5v8b6eDUGm5VKJA3YNhGdyhBMvubFbKzT/CSY2BLFg4UK4NMalCZ4HSjix V2tsbGcsgGdbFjfReByEBxAL+8ZQVvswvTMORTDZvNkRt+4wZ2SeLQPzOjKNbG0Jhya4UmORjCBw rIzx+gg2RGx4CBc8HpNg+jkQUYKVGEC4FsHMhyDOvPLfEaQG5kGYqIUFLvou8cxjojXjJJBYHpqI AD2Z4agdI3nNGBKQgYQmEhjJRZQFD8LY/XRMjCEA4WEYRQIjnM6MFxIIda8CGipDiADymyEkMIs3 AaN1EX8YRAINQPWKeTAI+xuvjAlH1TNmQhH+N7ZyhMF/0doZA5Y9foUEDOqPrfl3B3DBaFOfXNMD mGBd4/H1nlcwwUbFzHKjHpULwpUR0jemeYY2SN743cAFlUeb9l5cbQITVJxtEtETmFj9uh5MAbJX PZkCuKB6NIn7UDWb4r52JZwSJK86OiWMWnVafjedn3ia2XwQ4jZdJp5WfTpJ52y2TfRen4wyMJ2r M2QTpVMZbLGZ3hpslFoC4apZCkQRzI6IQLqZGdVKpeYE2q1UFSs1enUQC1fBBjN/rErdOg5gg1lP aGK3rgVsUNtbYKIGMP3rq9/85Or1bNkd9ysvKI8eJAvDM41/74R0Psgy/POLk7g4iYuTuDiJi5P4 QJ2ECeOwhGnK0D/m0RJdXzksseZ2BCDBa50zFLVvy77Qs91pLBEaGTlWtzCAqbfzNrR4V7rfEQ1t ga7NdYWsffTYPKOhouDa+T02CodjEyEm+oQJL86+OB8p49e5kNNyruTUieFo4/P35+wvCvEhKMSJ MEAOgS1X4gUBhQFijwG8IyRIxzi08JvYhR+uypDItgi+NTyMwPq84rVR6eV7hwd0BcdxgnmV5w2v jRsv3zs8oKs4jfBI+rzi9e00nJPYeDKfF+l4VsVjhYjrLBOxzq4kIquxgNM0N6KymoiwxYg4Nq0n ojzpugSeqC49iicQSOeJCuidkercOEqYZx87TxtEJz/dZTmu+WhdWDiXiuON4ok80RjnRy9+QQCx 0rcEakeJ4lFoj8+e3h6LPRPiK4nX4r4jPkzbw4PRTvvODCfyGubEcD7xg6AArcTZ/3VX5V///Wwv oTed/jx+sUAnn+ajz/7wzyxmGdaMYja2g4ziv3e0VhxS8gHhX+2eDBLa/XWhEHRLNW5fPHWB5x88 YumLrFiPQ9KuB3/ePSl8pFm2dTf+H/UCm1TuxWe/2kU5Tu1EnnGz2rv31mzlBenx4Htg/dRfLz6b 204iExeOP2LMZjdP+Jle3Z6NgGtPhmiKTWMb5DzobWPTY4n/WUN73gAoc/swTp8BfESNoGk34k95 lDwYpxgvnv6KeMaa8cnZIwjpSJyasdsx7p+oeQi8t+l+/5ezRyu50WbJk/7ozZvbXWBzWdr25uXr 2d7oJJvtzfwnn7r9bI1cYhtOysVp5sfu9HxlKArhh8xpFBKbyKMdPMNejlFjFRTXIJhc2IMwdnEI i+Qx7PXnxEiCRUiNGoMGi3iFRThoeIezkSYNFvFwCevqj1OqJg0WDcybOmmwaN7XzbBpsIhTqQhL sKiwI6uaHpA5M6rp0pIzpiiXS8JFSFKooyxqRyywNPeLcMTzeDwyI5D8BUw5YbVqvIgSSSwPiyDx qVYNF+nrQho5WWP1LQ8qAiwDLIdLez6oDDKf0teyb37YRYVQkAJWVAjgWlEZIOOj5i4DZnoWGVT+ O1cvr6wC4NFm5Hd0edekEkCiXE17ryw1qQgaWBpVBKxrNaoEsByqUSUAVa1xr1E0ejmoAJCrUIMK wPCkUbPs3kZQrRNHkLQ3jqha7xsirL3vLfVxITrbh42oWmcLB3c71xBU61zFNsY4jv1TFwiiFV1g iGZ0eSLa0eXdkAEo2oBQSVcWxFFcQmDdN6driMJ0XWya1dhDOF2JNZlQlbz/PqbFyyoCIS5TSJrW CaY90wmoPdcJKuPS+avDbj7a2Ce/ck2Ng3J16kKYvG1RoYjpEZFNFkNliZrhEombYWve6omqqE0U TTKTKZpmJlU00SyuKOroUoFIkUdsrzQ2teC95Q+dtj06UUa3Q3vE0cXFX1z8xcVfXPzFxV/8bfsL 1jnkcSogebwVcR3DEjs0piN07Zrunqdjc1EKsiF6NcAUmD30WPLGtRMLhHcF0wD6mwsk/cuwAUee kZ80A7BERQLX/eVJM3YXBuOERQf2nHBCytXh1mzStE7DnWH8UH9/UYG/ZRU4FSKIsAMUGlkeWpx8 GMZRH/5iu+cEYA44uT9/sj4Xvxayr8PAdvNwNcaJ7JPgW8NJzJg8rnDtucfitcMDqoJLE3HicYNr TyMWrx0eUFU8iGuRx4dHnnlUlHgtBjM6nqyK7wuRRV9HN+TVREh2AyqS+njWH1aYvIWG49F6IsoR r0Rj7Ur0KI4McuKhHBnWnnhUrGaGEiyI9+ub17vZv3LQ7sueH/+mh+Duzha8oPxnSP284Of393cz SaTcf7OrMuF+34n7GoCb79ZPxCFwGDm3DLUaZBXdJNNC8YBEDH1c4OriPP/a4QFRwJQl+UOeNry6 OG/x3uEhXeA4SdmXPG/4Me2Q27LRYGcho1mldkLCdZVpWFdXExHZDVx518eTVk8AJ3AQ6Ux6BBHh SNcisES16DFERBxGxMTz7LQro3nCmydebJ8tjrlZd/444NBBiiwfWWJx9jBBKSdOwWDK7lDiKVFJ fFz5ycc7Knij4wn3r2+rpTjXYp20Jk9b9KejK/oakxUduXOm1/e7mMGFm6/oMBM9vLnb7NKEKsKT FS1r40YxY/sWm1ZsohY5SmocYT70lNQ5qsBs/LwAO+PsFcZRcvJixvYtSsoeYVRkhyKQB46Ev5g5 /USKoYELFkVS85tQwi3JhIRpNRkl2ZBw0rprhvx3Boiobxm0ShnbtyhpjrOY9oC1CGQmIOGFYMDP vEuNCYvEmOG7CBOTo6TaEGY+ZHjZKMfblEUnUCotp+pf10LtxKvdmFQC0npSCcgxdHId10LHLAvJ qBKQcUeVAHaxMaoIhGdhrywtTRetjuVBRcAb6BhUApBYmFQC2H6HSSTA4g6TygCb97CsFM+hqQyw 9w9NhQBNC02EgMVxkFCBKmqQBQThxhAyyLBWQVY6Dtvv4+L1BW3sl6xpnhyuZ5Rj6TrOuUxuYJOy AQMvnNtkbClB+QCulQB1UK6WCHVQppe4r04mJfVNAmBOTqIliUJA4CUvFaJkVQgoTMlQCPxYoA2q aQXexjSxwA+aohYu9jY9LgMmsKi5/KqTQF/WSaLEdRJp4zrJtGcyB7XjOkV1YDqDZdw6wZUtagCU a2IchKdqOpTlalpUJGp6RGRmmkSiZrkg8G7YJr16IunvC7MIdepmE9omJrV5Ywsl7cYYShzbfhk4 MtYn7HmXVt1ZIBWV/K6z49HHDRe3cXEbF7dxcRsXt/G37jampJI5HGGHaLe7QNf9WRLb2wBnorvm zfkwpuGZI1mAJm0kPjv0BlHtIf0d6zFI/b2O9TUMyoNr7wiT94t8uGWTf4no0WvnA2EbDg9thRps 130x4GNaisXEJKOXeTNAH9y8KY4d/dzhPbn/i0J8CAqxUAeOPsfqrXFtaq0pCFSb2mriRUdgm+CG 2g2m06ReS+/GeYClJgYPG4BFAiY04FGKgHXEAhBouiq+oSoHPP6xjvjUNRkl4iI2Sjh410lTHFjp W79AKuzGFadNZUQjSE4/XNHFPLxGkTQFXNQjkEAFkquFBAU6qBMs1Y63SkqqISlojOvTjqCUCdnT hkeUaaHQs42o7+LKyQ5q4YaRsBIk9cLGgEwNGyKgatiPdeSnKhta2KR5nuT0GNVZt68sFTsLXvQe CPYFsdycZAtmwqn1BXWpvKnR5TbBodpqnKDfCJQBuzFdyRPOtRtrwswN8ZFlECnCMRTMoCBZMHKO RXhMgis8RWmC8XMCMeRUhSqAtw2SnkOYeSDpO2VAAl2Q7B7CzIdBq72QQReQHFQGTgUzxRyK1pPk 5HHWmjQ8blCIiU5oW5LWZH2RtCfrq2RF2Vgka8oGiqQqZUNSGQiXospAuBhVBmByPBJB3CcvoaAy EAkGlYFIWA5dTQOCCEEVJJjypGkSGUC3CA+qa0NiDBlUAAgASpumtpff+HhshpBAx/g5oxTV3kYN ZiddMMGtadrKuJ4hOiK9HpQFMiSOrPQRD8oBcKRKbZFyrMpmWBhaZf2i/K6yflFxiE8zcdXmZCme UyVdZfOrilAnkbzMVdn8qh5V2fyqno1haZpk86ta2q0xlFp/V6Ufw97NCCWuE6ZOUDudUNI3nW+1 QWd1PurIFKTiZrLyRCe6OHMzBNUvIMFyXTM6gaiRqRKtUCMk8lQbVS3WERe6oCZOQiVmAREp6wbS Ai3C9KwRCDGwHKeRgIPtEh2zQ4NRhminbkGy/X6rv5v+Pzq4eHECFydwcQIXJ3BxAn9dTiBXZf6B sUEF7AAW4PqqQ9oKHYNs6FqniEW01c8AP0TFot/XbMBC8wYO5RPS0tuQvOuxIYxM6TJCHymfaGoP fF3vo0My5QNSU93b6ki9TXiXkRb+iGiUBQr77u3k7OjRwvfkzy868YHoxLtzN1PA9SIjyeZwNeI6 MMG3hotcA6XPK16dRrx47/CAruAml0/J4wpXJ/j61w7HRAVqRZA8rPAxbVBKnR9J7QNZlzELGr6f 1bq5moLIjeenDkY8+boM4i5rpqH8eQwN5YbXn9rV5zE0IAgloWJ5d/IwPuARq7+Eukqe781f7r/e PQlAyacPf3s2fXhkR9ppbp+cibjWkZdRvge3ll/cM43d5d8rPwWQRuIlUguOEx3v3tzv6CiTbpu4 ud7pBQ79Xv/FlwJevOPzANyQu0L827ubVzd3N6+vd3TYShmSNysIuHu7+wUJb15++eL3L293STrz EkTpx+3N2UxPUJ2CfbTgNzfzoCjUT3ezf0WxSGRMfn3vgpHDhKg6vs5iM0Mwpn2z32uy0DqbBkP8 MRfBAy3+usWgqC3PEMniP4a1N8RPO2xQdJ4Q2yBDhZvF4lg/XWNDEFtvQ8x2hxXPsx/x0NdFHwZU MOqHYIYm3/iR9fMgFYxZ1tcDrsQkrDDjcTZNQ5Pv48jqfZASxiyL+4EvSyNY8DpW5xlbgwFXeeYs G4cBFYxZ9hUDbgIlXJrggsdTEUz7lIx3kcSTZUcz4ApSwkMSTJuULBuigW8wJYgCBalgzNhODfKV iVw055+zj/RDSYPUTWVZQw5S9msikor0jK2d+zlX/7rsDJV6UhkE/dBSXfQt7YvreVIRyMCiikAG HlUEwpioMhCuyceFlKlBZSBMDyoEyCSoDERkQWUgEg1d2mlSEUAZ0qQigLKkSUUAZUqTygC6ltre q2KShbmqamoiBGhyknXpgNtXc5Lb2wy738fF6wva2P9a09jZ957x7rl3HDv7PjBsvm3gk8zgIIB1 QTk2iQVSjuL6qc5wvo21ywPXrZq4cKFglybf3NiFjTseuzJMSBAyZZmQP6SqNCG9yDRtQvqRaeKE 9CRT1AlH8qrXEz4qZYaJj477rFBqOmum4maU9kQm3MR3sPb5qAPR6Yr7M/t0Vj7odMcttGILhIVq Jyax62pHVAJqZ/g4sVshlZ4aKURSug2D8LuJQyilm0DoTjeRiKaYBV1YV/lAm1lf6Gz/apnEJ5zN 5zXmIGXp9rWzbnDEGuL3tLzi8eImLm7i4iYubuLiJj54NwGzPcnnLBk7RE5gga79s4sfAfqG49o3 v3A2mczTEVAvgiZwWY43f7LRIcdzGtiLHTtEozKiMXHnMN3HB44w9851lOzZ6+71YAsOD23DCfvd jN1OLs5LetinxfE0cRu5z9+fu78oxIegEI9bssn9VViy8b2yap/YTcp1V/CidSO3YZmTldvO4JQb HhcHzk46mcem49vRFlFZ73MfdDHQ72zXxYFchYa1A9+moosouYpFTX7Db1mXKWPdyAVhwHRoPSrH sazBRWlY9Ax1I9eN2ZpIriPDEqrR4+q58BHHUR0bruvC5WY2zeTiM/ezulEs0OSKFUdd10z4OuNo aybpnK2Z+Dx+tDWTDM3WTDiPH4MypdqKCYfx1RYWYGi1hQdOWaqtSyCPqssWnMZXW9VAnNWWPHwa X21FBFWotmLCd3Tp0quuSNXmF6/OCEfVO75nuPYpQEyotfs2EmCte7ccIxjrEjtP6N5unnQDW6zp BrZY1xrYoh3HlwX6uCZlS1D/v2AL+//ONSwPjKlYPXSe8+KiiwQLjy4yLEy6SLFwEWFjVdM1Aaue rilYFHVFmorTMiynTAmx2uo6OukXh6szQV3FsZSzGaDE3Mov+fmjPTELlqGzOv90JLoSTHs/eYUJ NrmxiO2THzw0w4AlsNkNEYCZFaygu9UR+XWrZF+dGL38DSRv7qA63Rw28MHM5cKUjmCCWlqo7Gjl J8vVmfDavLo9+MDc9Knhj+cuHuHiES4e4eIRLh7hQ/IIsNDYZYks3oqm1Ldngg1xBMfoMrr2HVh4 FuBjpE4DzfBuSijd2g1T0o4i9GGBrq8cpv4/QEUHrpu0VIcjzzf4/nWU7Nm+SYNBODywD9iSLQbQ jOUL2fRooaE+F2yqFMeNBzv2H+rbLyrxYajEqVSOyMZmSLTyWV1ZdupGLSy8Ij5D+YgaNacCnC8V TG6c3hBUqnNfg2grD8qQCFFwjOKphFBM4pw0MesYR/F8+nzHrFiCKxKDCc1G2qGRczKAbR7ZIJw4 qpPlUV7Ij3DsJzUIRyR8cfTjvjVXi9yHrVd/Jrn0Vq8pFVwko1WfV7z+zlX/3uEBXcFWQSDPG15/ H6p/7/CArmL17Pq84vXtgOV9PHxfsg5n5SWjWCj3vsa96+pKGiY/vkvBjWf91a1O6EzEMekx97+K Epom4Qbpx90hC45AGsYRFc6KW1chhao3En/2klIl+c7VtL2/3mXJ2Pv6bJLeJLopZM5nSk5Ir7aH nz7vk08D66hGmaUTp0WxkKaGASOlTEpVFIh7F6hXZCghvUOlliI/LyC+AGwPd8g1+gQJlKJXVjjE 10so1oIZ679tFmR8go+z9n5s414bxtEKmYpDiEGr+IoGYlqvt9Hj9GB7EamQsY1K1jI+O6ovrtpH TvKDhhXG1MuENAsg2AYq9RIjzSAIFtSR2kUN6kQt4Rtc7MOy9TV9IViyxOSqEjQwo9VSEnixYio9 eQm5n5C5mj09ITKByGc9goZ1lkV6w2hFepOnZlEeK9KzKE9MVmOmeRtagmYjcVEeKdIrzXPCwjwo 8gydiVYapyGgqQd6elmdRoEmi/JYcYYPAk0W5ZEqPYvySJWeC/NwlZ6FQ1Clp8ESBIEmF+ahcMdk sRaOAk0uykM7+UnDNgarYv4WY/UnZY6YuGl3ijck1xfst3tPm1YrBr9Z7yNtR5zgvb7xadJqRUvr mDybEfYxEUiUwUQkeQSQn6RtmGwlAcFkL3kbphuSwBBcXkfrmiXpD6Z4krdhijkVp7SStREscOMN krzoojbJTx9p1oI20qsetOklQm5QFrXxZU6OI6UHymqvXZTEim43rJQxOXE4o6OljKOL4anB0jrG HrWRUsbis3u6MbRSRgvcuPuR5Ly2W1orZZTbaiyOU7QwNFaJtEuNo9kT7x+OJsP3COxfPMLFI1w8 wsUjXDzCX69HGM1eHI6wJkweIQ3NLrC9SUJbgOvefFv4FcGaKHsKXbNFU0q3C9T/5niuA/0tie6+ DVxf6anfZMd2HrvJLkimetS8K3u6NXd0bcbgHda6Le8csLEr1olwemL4sP77cOwXdfgA1OH8tz5U Rmyx3nU/oVzGgYt1Fw8vo1UN71DEg8Y5ZB4uvsS9m33p/B9X11IhaN3+6Y6+pRG2N5vh5U/pcyV5 /q9sN08//WgRvTKqETerdLLLwFV/DjeP+OY//cUnuzSPdftLIx35cYrKnep6ZNNNbfx2e7IR/iZi f+yL7dNdxBC2N3/eFTfY726+/O1u/aeJ8shrmiGxDhyuSuEVhOBbxfTxKjb48rzhtRHr5XuHB3QV Z7nKWZ9XvDaSvHzv8ICu4pgwPn1e8fp2eG24GE/tw1kVn1Uavq+1d3UlDZMfTX0bTtyvJuFE3hzH HkNCRrLQotqV6FHcgCSMGyoYohEWk+j4A3qNF7P0RR0tUv90VyVC/dp/oGi2BAF18a/4Az9UIf6S bMT1rkhN+tli9oK7+ntLZ0PaufGyuEyT1b73kn/35bKbuY9J+/jNjkwlVbH3Lva3bu7W3Q+QG5sm ucXp3NeF7l69vCau8DeFzhfdK1FchHJM9MsbIltQge9uGHj1DT0jI7376ZoGcKE6N/BspjkvkaeY Pc3Xs2GfTfr8X9xudllkevKLSKeaIfo8Y3F7wDacE2KpuM213zXw7hPlhF1ACeTP5rmJRHbA2yvJ zgdEHj/9bZVBBCpdEyOw9teISpUYvs74B3jCmtueN5ygE5PeBABQigOJm2UUjuhEuXpWB6dYg/Y/ wkGf0Bf9eDFqGRaLmL4SeMetJUH3k4vXg3/93JJL0lto4bAg8L9bStlNCmVuZHN0cmVhbQ1lbmRv YmoNNDUgMCBvYmoNPDwvQ29udGVudHMgNDcgMCBSL01lZGlhQm94IFswIDAgNzkyIDYxMl0vUGFy ZW50IDQ4IDAgUi9SZXNvdXJjZXMgPDwvRm9udCA0NiAwIFIvUHJvY1NldCBbL1BERiAvVGV4dCAv SW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0+Pi9UeXBlIC9QYWdlPj4NZW5kb2JqDTQ2IDAgb2JqDTw8 L0YxOSA1IDAgUi9GMjAgMTQgMCBSPj4NZW5kb2JqDTQ3IDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVE ZWNvZGUvTGVuZ3RoIDEwNTgwPj4Nc3RyZWFtCnic7V3rrhzHcX6C8w77c9cwN9M9PT09BvKDtqXE gW3JFGMnEAxCPqIsB2elhKKdBEHePVNVX11md7lnlqKNUFwLxtmP09eq6qq+VFf/x123of+e/cNd 2tB/r/5419fNMNbN4W4c5NcD/+rpR4+/X9999aO733jmbl+m1vXT5vTHXOLffZymueznX9399Pld ypxp/jN2/T5vStoPefP8cPf5Nu3q/P/fb57/091Hz+/+Yy516obW5gwnP767/+Yu12Ff2yaNeT9Q e/ux35ei+MFw3/YTYU2vGJ2gesapdmPbnP6I9Ui+w0m5wFPbF68FKNSxpi+c63BUItA4p/DygdaW nzb/Rklq13XD5j+5kLzs0ZS9R5+9dZGhA1PWDrxtcczcft9Rid7tWXLerkiTDxTpdH3rIkHHKIFT dgl8+yKZvVYgmP2ZDbkz+f7u49z5IEvURR5n/Kvv8r7OXR8a/eHB9tuX3+zmoVeHnLdf7p7UfRlb Hrff7p4M+PnKhuKZEvNU96luUhmIhlzi09evX81Ftly7afunXd23Og3j9g9e+J/95+uX360f6VO3 KWPHkpVaxe8H+Z0Has4Dp9Hfa0e25zksCyOQhmHP2m9OZb/XjjfPc1gWRqCVfUaT9efacttE2jI2 el+at3uVwEkZsXlUhrVwVRngSGtzAdSN/oq8ykLOzPS4Jjco4OLABIBEXFGCUN5KUEZQCWfEPeV+ 38qmDJyYxf3ZPFTG/SzitS4F2+R6afeOSpzHz6xrywwSzN+zT3bTvp9L6bf/vHuSuv2sqabt813b z39T2X40f5ZfLy6NTCm4n0bSHFzwpzSmJeczKmQeoG3cfvzRLuV9TuPiX39NnaKK8/Zn3Ahuj1f9 k938ue9K2W5WNGKm6ohG/GL3pEEjfPN6l3rp3cs/7p5o1S9fbXaZeJPG7edprmfWTaltfx/0hM1N dCJiMxOfrHx9l6bC2q6lWZMeGBLqxLilSZT0jMcMTJZmxjNrBctnFog0Zco3YwAaK+OE0TzjXBgP UlaiD4RzA6axNmPRK5NI0ziTguE8ChgNFbDPjPsM3Mn3jpPPkkuFjySKAnvBolkaDSmCvWKiwozZ vhEmjT1WSkZ4FGNVKZlgNo91r1C+JugtIleaTdGUgZkSbJYXWD8T1QxKYQUsmCEb9wIWaFMKWNBo 4kBQWKA90V6nzFYcChVU6MGCGTex8rlFIvbKgo6oTTY6siArCxJlI9znyMAMFnAzExig3E97FYZR PveKmQYJDJgw/+jAAAjejIUBs5wyg2DdRGxnJAyYeJ6S6gQGAMfvMfMgVLCyq4iW1V2FCta2UQTT 2j4KHbRro8i19bxFmjRhvdGsCR2MphMmSQ3IZ2GCp+z8yl0nVAA/Cdfi/CbMYs6T7S4J8yEphKvL Ue6y8B5yRrgPckjYZTZ3vfQZIu1fJ808VB8RVriMF6q6FR9O1jQMN8LMLwxH6xeGK+Hig1mpomN9 xjWqAtC0OclZ1EyTgCWqZ5qqKdB8PFJTo6qpYSENpubqvpkKFEly/ViZDK4+WQ5duw5MBte+hdnH upmU9e9+dPfNrNkD8UuB0g7pSJ9wD/izF6OjAfOn39xsxM1G3GzEzUbcbMQP1EYMGbw4MBxVfwQw S84S3cekM4VOEUqd0b0Nmrn2hakRHOzGCbqXpX5QdwrO/Fykp6KadsV/3ZuZqpM3xnGwgoxs9HPh buRk/B9O9cEjClopYXxCbzsdKr2IgI8NQC5ttskwye/GuN8E4L0UgCtnZP1QsTMkpo4wzBPPyQgr LJI86ZSNvurcQwwt4dp8VkYYdJSPYUbWDzr1EANPeNTvtIk66NRDpgeEs04XeipO5x6NEoe5R2Vo U4+UGWedxrTGuNN5DOWGIZT5GMEhTIoI9zopKpK8U/7RvsugNlhmZISV3bkw7Ovyc8oxe+fTPy6+ 8+kfV6/7r2idSRO3vejsA10rkwqXdL2oKAtlyrQPc7K+NGWCELU0ZYIQvTRlgjClNGWCMM0+EkfL aHNwBoOKBolCGdWyiaiUUS0fS1Kpe52BEQ1KVbMpYliqmlUR01LV6g7Sy2Ffl7DppKs/St5KLI4/ hOqqdFtbQ39DU0fp9Lgw0qGrLRKBSaUUatJpIx/TPZB3km4b+ZmLxh5MwZR7MjMx1mICZqzHxMZE Q+ZgJjiYF6lcYQpmYodZlYkl9IyJLcyLiXX4XmN2DAorHoPGaseg0sZhzGnbMSS1azpg0fNhOTX1 8Q66mToAXYdIdFckwhRXNMIxV0QtainhtSkxEQVXcCwprv9Ejlw/ipy5+hQ5NO0qYurKV8R4wEz1 eN0O2ptpt4QnKgffy+L88mYlblbiZiVuVuJmJX64VmLIyhtbuYE3b0Rz2fd3SxxQ3VixBO69et3N VFvE2ydmOY5RyliIBQWI3/qrX/z01ClvTn5yF23hRkPaDB8wJXUzyMiGPxf/dUzdii/cXEHIQi2q 7NKCSnZG2LYhrCbGCmT/dKzAKi9X7t/TvN8E4L0UgHNuP2X+1XMb+FS/243bPbkMyMl++PmjcGxv UsSqeuZ+30lrVHX30JaMcw9Vyv9oSKUBuA7Y+0VZFS4weWjHoMZkCuQ3/SJFXNn5JaAhc11Q02oy tN1mI2x0tLLxDY8Pq79nxKQkGaQ02yJB2abd5vm/rfTq5DYMFRqnH3liAvxguOgeFNIrXu/VGfMd TsoFLrMh7UM9htd7dsZ8h5NyFfcJ/EV6xavrGXgKEfrDswLrzyrXKBQSGsuFWGPXFeIcbOK6aT1a 76QW2N5KINtVhShNXJaEJipLV9FEGOI0UQZRIRedL8lVkhgxmqfkr77YPenE9zJvX9/verhUfX3J parPPCnzcrZPdFCdTc3nNiH1s+eaPJkP6UUPtVzZUA6ZlxHLIs4lH/kENiS/1L48U9eTziR5SiQZ W66pBJ+34IP2j2RbyrxOmbYvPv5kN/8z0+zZr35iVHPn2AvdSb1Zr5/vKhXSD9vPnu/mVOwM9+OL bq9NJCoU8tmzn5Frm3j//Xg3wf5t5j6wW9vZSl5Qrkv1oLFyALia9p78Udpb0nW0vySYiRcJKyvv Ey9tYv1e5b/ar08v1tiz+YplRA/Fx+lamg2LV68v0nWepcXUF8k68kZHSP3Fl1++evnddxepwef/ K2sgSs962FN/vv3qi8OfZj7Ns7dZ1B7ImVJUyX9vdqWxitn+/UVPTaWIHI9zmf9Dg4sdwzdcNJUY /TeDP+lfdk8Ke2yWbdmdFf9H89Xz+X716S5huP9yHkHT3JV++9mPyWeVfGQvu59qp2oyBRPa4bJy 7tcLGg5ZhkMcA5f7Fvxmz3nsPvv4KXVeerFwrL0k5pVdXrwX2//1aVTueIVfcpIz1dzzTgTwA+Om MPc8vSdEB56OJpn2CZ6wm6RFTVhrqAE/wdhfsvQBk5gKJjSrh8I7DQEMMrsVLE3xonLGHg86mffL +fWH2/e12+SiKfKoJ+7cfsJ6sEtFV90k4tUi4TGsmwljh4ncjAjm4IQ0443sdFa5gjAqLoWx7aNO crUi7qP6VQtxkCq57NV5in6bp9Ug2DytcmPcuWNWEd982/wlrHvDnXzudY+dadDrPjZ7hRGBW9h5 JlyDS5kyAPvYxi7Zx4ZY2T62yaCVlmzjmjKri4u2pfN9a+ZXtzg8IGz71iy2XSBDMtcb3scmrCRn YPQuktjoTfRPzTauBQ2Re8mchngfm3CnkkBESOZzxPsKhMP2D8FeBauX5CnIXdLdI9leJGweaIN8 T3WJdR+bF5eWfBQ6WHGyRvDaFk1pQgdtaRMyBOepRT+nIzpMSochbGwrFeGoZUTG9q8xAY5exiHZ PDYGwk1MuIuNZ2O9uJiZZGCnxiQHW2AmWdgfU7kjLZJLUI1dkRtDSffcTZVOOX43JeQDworOvmmU mw8oa1qvO+w5jkfrWK+7CUnGQPEd9uqDHTvqpgyUplAUsqNuakQZ4mpmUrVkO+xQS3bMMbkOE2Fw BSdLPNd/LSrHUQhefYedqaCqte6bKt7FFngk9MFkWxPCv9XVy9FYeIuT0psJuJmAmwm4mYCbCfj/ YgLoENZXLd0g7ZGFyZuQLFMW2FCmDmuxDO5D7Qs7IvgUwURMcgYGG5TVVWMUCjI2lORuTET3dwGz k+sxmqzn92aa0nBk68RB9gQ1TXof7BprhIN2V/WDamjrgWnscN4dGYX+q+CPebMYKGMgRzwWfSfG /CYSPwyROLcDBXPQ07TpuhOwAUoRV9yrnMbpFXeFBR4cmlrx2vOvZb7DSbmKVbtq+jMxFlb1RkMW HJcL3JOy9moUXlOLt15qiVRZddKjhcSmxi6vLgTcY0+H0KH1YUYCz7mQQKT1hWh3ghyZWF1XhHDD ilDmvCFWwtDRjIjOx2YzexKAwIMcnNsnDVuj/jlss1JuCTASNlxffEq/v2eAA/dWKHKNbMiIjlPo uCLDo62U+JHQkBmRVnBUyAMEuG/ie0Xl0G+edJXEk7JTDKcuSewgfCREvh4SXMGQ3BcBRBsetPH0 y7q18d3ED6mv65bNpROftgnn6ITJ/2LC5Lt04kkzYW5OmCH/Fq/Phkk9YXLra5jzF454RVBa2WWJ koElA2HunqwoCDIlsOAonbirNixICDPJsWAhTKcGDeuZQrNlhhWI/BkbFkOEO/nMKkUGdd+wkCLY C+aJfz+Jm24To0qQqNAwoSFMniMN5hvhR4zlhCESpQC7tNhXOC1abng0WumQEasdHpHWuBJbDl9K 7VivPEC/e2UC6NIrE4Rqeb+gaXYeMM2z84B5kpUH4FlSHoClCUwAx5MyQQQCLqomL/DKMnmC3xBk rYkGV0ls8I9VSR3hPquSPMK9ljBp7xHutwHjO099Qn5xBvXyR6GFVi+upN64UUhhjW+xZ03pgI6L D6vRZQIdQDVxf3WqTkIHpXoSPyXjShI/JWVaEvcqY2lKKhHC8pQWEpGySoSM2iSev9KUlPfNJY0c m7qorRLUHiRVHZ9UkoPqW3zGMLDsphlRPIaR1o5RZi2TQWgNxxjVfmEIW7cxwo0sqgGUalAQStTR mTAt1AuYYupHeGbaCRxV5QWGm25rUfFBVEwvQpRMb4qkQamKGLrCFTF1hSxiPJkDGJbbC9qLIq+e bKmB8FGHxtWbrTercbMaN6txsxo3q/FDsBq+4jhEzPH6ziKsRyIMgE8RIrqP1U81Noe27NVSxd+c 7n5WSwisZxoxYkKjKsgFkJxj1pZbvmM0ZrROVEC0jbIK1OG/RNNeduI8Z20wg1FZnFPoUOFjXnLF uFQDTDFtCgX51uz3t/o3GXifZeDcbYSeSiBP+Kk+dm3lm4tuhd0o13w0tqbv6i49wJtkapvK52RD z8qVq/54Nzdm/t9IIXK3f9w9qds/v6J4mN325Wb4w092T/p9P/+vbDfPdonTjttv//x6lxMlWTTv uJrEJ19czavdk8I1/OF8DrFqnmPpd+rJSC/HcqnIb76a27v99nzBSY5THy05yRFhSHf49suXD+fT Soiqx8uUuEuxvX/ZjSBntva6//sZIhZxZgARJ2R++ZddCWz77uWXZ5zOL3vTyz2e0Ier78Tkhstg MKrAZmQpdHQJToqGr7wTg3yHk3IVd0f1dKf1rOpPd1RPt6zH4kUhveEr78Qs+kNnZfWaUwEtpDsq pLuqEOVglYs13qO1JRjPUYLT6NqORCmijqgUXVMIWGGFGGtW3YahS28jn6CtjKR89oIL23kv55Hr MDRdjZV+QZqXIparH/o1EcvX3JvJgx+AXBHa+V2cZay6CtFXdm2IzfyT3x+4EKP5cb/73PP0nst0 530/uwmNfUpdkO+e8sUns9Y+Oebx735NJIajtqsKP/3224fdLLUE2vblFxdtej+ym5U3efv5JTmS gPyxg/Rqxe/P2JbLowCEyrzYhoz883M6J5O7QkEinv5s1yNQPyXY/mKmg/T5txevD2gdKYy0N9Xx i3kYSJm/pmHApP+MZF/YzvU+/eVMbMG/nHMKK7yMn8d4/kYFuPDkaZDZIK6UAttVWGAYSUKlRJT9 Jix57GfNWsW/X1yooGNPsIZo0PQBG8TVV7k5YIBrsnux0hAvaLKQkWhnsSuookpvVFg/O8Kqrao2 D7Ojtf6usmnWYQuWo7l05kwpO25dcKbMnHhjnpV5MmdKUQmTOVPyZh/hrF6iTdJ36udJyeFOKV6f BAf1N2Heqh8hO40S7NRplKlqEXvZTYaw+tuQEEwWsZeXaYQtGM+Y2arGgAywsoxxAZV+syccnu4Q nEXq4M5KfnUmlASHqmIouGvGf/tsAXslt8XrReEWrxeVW8BezhubbLGQ0CULhoQuWzAkkMSCIYFi i2hIBI3+haGRv0nqbsEuC4YkzNS4CmC1xbeAKFhMXIiKxV2AKFlM3SRU0JC7LIYE4d2a+UqpBaMi g9w0EpK46RIuZYmr++2G7L2QxcoWU2VVFyFLiCRcS2x5EbpYz9g0hZ4PkS7itutUE7cpp6rceDKi 4zqU8UQcKI1l4rXrHBXnS+e4OO66RIjnpksMe+5CmsTr0+VM3HZNDsVpNGgt02LwnQ3a1jxObQxo bgv/aypxyrFy816WSbsOQG23eS+35eDVfgfvZR/5SjP1Xh5FskbnQAtqRTzmXOsow8zLexDBVh9w cNtcxAchg7mQQ1pMJZb9QmPKkQPUqZxHuK7l4wpXxXKa0R3vvC5If1Bxt3TH6udodLzF/YibvbjZ i5u9uNmLm714b+1FX5U1h4iJaHyV5AhgCRWQZULY8Iju3QalaHMEmv04AeT53gu1TBVGHFBegpCz yIsib0BjRuugABb6QOL86+hfIj2kWSoPs7auLFqRARqUeR9Wd8E6G5dgTW3YtKDejwdGvEvxDsz+ TRp+ANJwbl8g9bxvyxb+ykOTwe5+HXDua1fBcAw84T4Xh01TsPqwxDMdjgsE7GP5/Wn5j7YfmQ7H BQJ2GhOOkipYX75EBo1dqIEOK48DpJD+qJD+ukL4bh0NWnRk/XULZWx1Il2VHx1YCEq8NHgVFbpl IcaSRw9FyBCKHw5v037jpw4v/+v11xSdibdkc3ye9d8vR0jim8la5OWzkYK7w1b/gx2F+KHIdzs9 onl9edOZ/Q7Yp0rCY/ku8qcUV4i3luOFj4avvq0dNppf/HpXsB3tef5lN+LMhvelX/zjJ+sOZhBh 0Ro3N+gCVSRUZujJyqcvQYE6KTU9AFi4yPIZBw3r4vnHs5/vBvT1cgwyqYBj8F6o4KmLSij5xe/m NHQisDyAisHVPtrZAdSzT3Za3rM1bSr9Xh8z9VOqs0dToaW//YjCovGzn5twhmDPT9meOR5Hsj1z PJ5ke+b++kuvTzxNGkJzhnbJGAXZrWI8NX2CcWdZkyuUt6UYYg8cr8Ma4orudYfcn5LSHljgZvSw 2LE2a5sPt+ePnYHLtR5Zoh7uhiaLClmwAhXcTNe0itea9WW+w3GxAuVlMSQVsNbshkyHRWn43cPh CskArymdVnmx9a1589e5Gox4rql4CdLG1dlH2+M4eFfaFXMC523gwnVFKC2CtDTfWrmKEswFpwWY 8qhZL7J09enr59unX/IZOx9oh2fXX816Vv7x5XekDWFyL2jcIcvWgU+NL9n4QcKcxZZ8xWqZFDS7 Qhxm1SwPLrvN93nAf19sSk3LSfqllhR2wOGNGfhYac/D3Ga1F8iQaMrn5V0mQpbNt1D7X88LpMhr dqnyBqDw3m39vR2gv577T54KQ/S++Pabn+woxInEYAxXU+EEJIe7dF2TKa9nvQSbfS6FN9cI0QzX UZYLm4KTxNJASQmxM3QMn2BE5tDkAfaGCdGKPrFZCUjqXZ5faxfsqgR6CGwXVT/Qnp+TrIE3ynI+ WhGfS8ohYMjF59TncOXFJnHnJAPCL8ghmE4uSe8a8N4jYdxFEPeukvSuQt0LlNS88ZmLujxLQIes QaoJy2f19WX9WdSJXzyoKQi9XZLIvbr/yy0JwoPemqD9z16vD8gtCcKd39EgT562sUsScOyxWxKE cXlEmKXXGuSWRO712kNC8Ha/FcFOFuHSRJLkSW9BsBuRXrpQ3uudDP9eYna70YHi7cIHarcLIWid XRiRxut1EnTNbpug6+ZULYQJl1XcQyPQtUSi2y0YMMVuyQjHTObB0d4u2TDDe72Cgxmt3dARcent Bk/dW1BNl7VeLwBBFntcD4Ko9np7SCI5YRobsN42kshOIf2kjrsKc4u1TdJ1bc08EfCWSqwm74nE arKOyrg0Knik0qyfpxyoiKguRmUJxwQWSCwm5484Vjv/MF9X7soc3bkvwZZMODi2kkuOxL5wyZJ9 EZe8jIcEVDIlfpIJroRPcrn2z63F7DoutHgdN1o9hhUap4NOm66DUrumYxY91yGthMGIV7qpPlCi qr5Qoqs+UaaovgHTRBkJQ01Rgd2myCAOpudIVlwJiiCZjhQ5cw0qYugaVsTUNbCIcbGQNHqTaUH8 wx0im1nCE6WD7zo+rr8Ee7MVN1txsxU3W3GzFe+jrRiz8uZwhBHoUDgVQOVrjAscMrZ2hO5j/dHi lKwRRGE+lkguS7LLRlSCXosByhdBzBc/UZ8iuDfb1eu9dMdlEyyjBQRFyvtg90Q5HE6VRSdbNbHx wCkqm2gnWwnYR8LxwFFDrZdf343Jv8nDD0Ae3nx/Fe99PbZ5AN1Id1ROXPIfi1/Xs77se/hWjohY 0EOnAZvjEtIbXrtZv8x3OClXcRU1rskB126qL7IdjgtVSG+ihjoAr6mjxI6UhWfXuqiBUoY1U4pA M1eXwHxLvN9tfUHg0FVlGK+lDCPPNWVIT4L4yO0QFZ9rqMF8cGqALY9u3Vd+yJUe3PGLz9gYvnjw XiubYst4cUO61rKs5PtthtepW1sxv6HbU+CYv/Y+eC0cOScPxa7Af/998GHC9HuQ+Ls1iXeiTjWr PEkFXOXZJOjLgFhfK1aPMi2rIQqiDoITPGldSB9wVUigr+pIFVCRqgWrObZuYNRbN10tsuR/4N1/ dOCPbvFp5GNphloUd1hQIbnC9aYnZDuclAqcGgKnS3KD681CyHY4KVVxzbKWQHKF62uRaWPszBBo slLfciGLtg6hyysLEd7BDGp/wlOLK+zPpOtAmFLQ6JpClCJRiIbsQnQVRYQdThFlzwojJHs1Odup rR/T/rsr44fgpXXJPozi1WnFXbYRoyiRUPn3M09jJ3cbVlY/iEPu9Dc4q62F7zqk2vyc/p3ZqAzu 1ySXFrKO1dRwjEd/CBUmjv9kt7z7O2DcDXjQgnBRwQb9MYSrhKUOeLDvhMjBQS4aGDIFLXcGpCUP 3oUkesG6mEx3LuzTB9j1dTvlg5jHnLmSA2Nal2e8IjewZ3bOdS8+R3LtI+ONOsJMpSp7V0MT0Eli NBRRPQhzR+RFdoKkHTNeJR+a3PvIA2yuxBfJuai/k9jkXETxEa4MFSVJnaQ08bHJvTAEXjy5l+0o grRNlnvErm/8gXAGLCIWk5Qm7jOiMARDf5UG7GLEmKWIfrGyN+7JFxgAy5Zk886KVdZqtR2oj1Z1 Sn00ulPqo1OdMoD7nCalv5AkIb49KJYmpT/TM01KfiF3akp+YUdqSn5hV2r7EriZmtJfmJ1Gpb8I QxqVAfIR1BcxSiOoL1KWqlKfZTBVJb6IaMKDKAP7UWWpVn+DD3JnLCSFH4QWNcFnQmuSW2HWkAn+ GdpOuQXmneBbYN5HufXlNJBbX0aiqQTyyS0vJ69cSHDy44KIcQcXQZR5iM9gvJV7W856vrflkiH3 tFxyZDVvgsU3s4JGkV0eE8sJ2y8qtq5xRKb1e46ZdSigbB0pWrOOJG2ZjjQ0HONQu6XDFN22YQyq 2CgH1UwLgKqqJEB0UyFTCfoF3DL9A26afhJmq/aCKJhyg6iY8oMkmWaEpJnmhCSqYoWgmtoVORat HHbHl6Q/cDom0Kga5Ejd4PvbPdx2Mw4343AzDjfjcDMO741xaMoZsg2y/SCceSPi5c0SG6KEUmbm RFovOG22h/MskFuOgbOqplO1J8vvjf2Uehfo/i7gYZEWCLqTfWm1xjQcWb5B+nuMiia9D4ZOVMPh RFO0hFVjBDYAlCpmE9FzW571eXM6Xnwf8TfvyLDfJOB9lYBrJ2Tq16bWTs9jYQzV6UJtpTplqCmF zwabWfXnUBuszh5qo9UZRG24OouoiWdHErX/6mWi8wP1QsH0QZ1UdHahTiw6+YCPC6Ym6gGjMxd1 kNGZjTrQ6MxHHWx0YgT3G503qXeOzqtsb7+F03uVKd1d1Y8lZqw6i0HBgxIf9Q5KfbRrWE4j4bNk 3SrKAOl1UfoXdZAqC5oVpb+QtERy90p+sKNX8guv1FNLeameXMpr+HmpKKgbGMuJ+oipDKkDmcqY OphBBOF+pgKq3mkYKurloTCpVe3UNa6PdlALg5m0qmBGrSkws9ZUmGHrhxhp7SVMuBEBJt6INJVA wck8BMc4d+h15jDVwBoNl6is02CKxac1C87LtEblApMeExtMikysZM5kUocplUkltIsKrZ5cqUD7 59ZidjvpktJ1sGjlGEvattFnliWMRO2YjlTtuI5kJQzGudJN1YASdTIOqK+sMiGoGLBL9A94acpJ OG26C4Jgug2CYroPgqR6EXJmahNiaGoVYmpaV6T4xJVtSXu36ZrwRNng+1u7Pd/Mw8083MzDzTzc zMP7Yh7M19IXa4IDKhGwp8wSB0RPb1ip7NfqlUcLI46sR8iNRwnrtaj6shUcEGeN6D6mXXxMdROK TTUs2tS7NdhAb6CBsgnOrZYVzq3H2gKrtNiB6PSvlAm2ccqRazYSjgfOkavzOzLzN4H4IQjEWj+q oZenL9QnSLD7UXVj9AkzeJ1PGLIdTkoF1ofXJLWi6zzC2tK5rS1922qN7mCKrvQGW3RjCNS4xvep Lf2n2nXuU8KzIg+eoDPYZrrGFcyKUPJcU4ZSI4rOkF10rimk1oUjmDJmhR+YRPzrJ7w79XmIpETx wRriP718tdPYTjGG2MWIXZWjpnnZj3gs9xxQyMOIfE+XZX5gystb4RKW0t8ifAdcwkZ3fns3HmE9 R4d0n6gEp9nGv+AYhbC/AfFmruLOXG2liNTtg9Jaou7Icyriwb6r91MHP11DU3ZfKLQj+FUFXyju 1xk3sA+pv+u3CyjI1rQ83kfIY1m7cYzOxfk+ImYJZiKF830E65VFInu4Lc/3JRazLDkFxeN9xO4V 3NH35fE+YvkKprhj0+J8H4GiZXFMQb+mxfk+ovvKSpteipqW5/sS7VegRE6Nx/sILCqYPQGXx/uE 41FBmsIJP8RqgfVQfwFU6uyEnwmuJ/xoSDjhZ3Z1i40PwnbCT76kLRzxl41ECbcNBIJ2ws8vCoYj fsrclhxo4YSfJK/pCb8wsIUTfnYPDyf8xP5mJ/wiyM0P+RmELQQET3e5a+GIXyDoj+fHwrE+d7su wOLM3zNLWC8vW9Z2XjdHDbeWycLQWy1Rwr1XvK70TktUcCeKrEmNZhIE3Ekq61knuQT+do5otN1w 6p+dn7KYdm5LZG+XBl6Lu7BIJG8XJlnJm6xJ7O6gaEYZgOEMq2tBrvV7jpnDKX/KYcRo3eGYv4QB py3XY/5BR6cd8+cwmEGVKZzylxZ0AaiqqgJEN00CnkzhoJ94ZppIWDqFc/4+uxqDQJiWE3GZwjl/ X4OGhLSZBoU0Tn7OT8I6LQ8SoZ+Pdg6g9ocMxR0TYoVlZkO/N0w332pj+WYpbpbiZiluluJmKd4z SzFU5cbhCMvWIMzEAtzfOWTXHst2gu5jaxbmRnCwHSdIdgY7W3c9HOE3ouO8cAfqTPCW6N4sWBu8 jY6DgXRXIaD7YP9a8A5aKIvHlLdSSO0jiKDctCFydsgst5rfgeG/ycUPSC7WRkEe6FVxlhkhS9XT XIEaSQmJAa+MVS3ZDseFKtQ4p0gMeGW8asl2OC4UsEB7I7HCK6NWez/YMGk/ronU7M2UItDMa+JW D7WX0Wmd6a+IXGF87nXODgJdU4h2xmRHOgPZuaYI4YQVoYyhIla+VDx0cmBUmsVvWPk8hSX67uzL wEPH57ulZ9M9k3vgaRnwA2N6iUMwoSKpZ7tvqCCOkOBed/ZRVq877Ag1d4o1yK+mN8xTQmBCRaPm OGBtKxANefBOYDajfbTxcPQw8IdMhEcEWN4269skrtk1sxoGfjBcMdvW9IpX69BFvsNJuYr7o3r6 03pW9ac/qqc/qichzoamV7y+Hl65LfozVO/POu2BQvqjQvrrCpEeTJ2Y6dCjslqPKVm0kECm9YVo d6IsDdVl6apChCFeiDLos/WvXQ+dvODCjjesUv1t+092E55qCQdO/sLLi58+ledU+tJCrpD21/RT TuTOvrzy4ncfzdnkrZfwCss/8BMw8vt5UNgrQ792tODqR8yQCfaCRZV0rBoI88qJMD2uM8pqliBp mrHTUOjyPOCIxTDhIskleGPX44kdie3YyetjVVbaBEvUDJ18Q+w1edi1No29Jg+71qbRVOX1nyp7 AKXrZPQ0DaDHTeorthD6idtAmFe7hCtDXgsTTJJcUnOtpIFZZAiLQh71MytcbH7oM1KqsAmzgq8R hCfNOLHhqL29LjyOZU2RCZI1FC/BaD8Q5d66WZQBIEOvHACZenAAROyVAyByf8QEfauFOZSVA2Af YgIqcy2EofBeY+FBNKpGvIToVI2ICdGqCJgJwasaTxOCWTXYJgS3ajDObpCOdwsAA9pVMRWWuAoV rDBaUYS6RqGCNkUeDfOWttgNWCXrZjuiAmsdJ9IkVDAaTiIMSmAJCuwM4ENT54/EBDb2pSTCoNzl kMDO/JRUGBBpN4swFA+HPFQTLcQENskjnFuYZkhYYBPceVoCEbcvNmFBzrqINmzjxyqui2DFOvqs 3WOMdGxD13o9LgIl+9AHzaAYlKLtiOKmV8AR0ztgmCmlttRZNgtpJgyu7kRSXB2KILm6ZDkzZSpS 6LpWpNR1sUjxiN0KjwHr80FW+Audbm8O2uxSvvLAuD5S+M1c3MzFzVzczMXNXLzX5qKYBjkc4YBo D22B7j1t+LT4eR/rNXvj2A3IMbi/oxdsmXaimQzgZdvFz8GzOLY83JMlulfbNUwLOyhQG3kO3bvd Ew1wiBrCNPgbNXYgABilvcY4iWltUITY4N/XvN9Y/j6x/A2vgbHSGdXV9+LbYSMfjtJrafqAXbcb t3vfJgg/064uH6rDXs+A19jLUAN+YNwpLIPwYGBZCChzxHbgIsczWlIZ1R6U8xhnupY+YJI4wYRI CgorwYBkQ1XgoK9laCf0aQ3tZL88GfqgO79+AUAJhiye+YTJmg76QAomXoM+oNLR5jHBOOEf9PWV jp0NCCed5WV97lnmhDSch245ZRw6mzJmeR066fSTaT7pZIpVJOGqawCaR5RJZ2JkSQnmMNctuo/b sVkmPOrcuDIsOpPuBec40S46Ca/C3lEXADSLKKPrbKKDsl/1Rxl11s46HcKjU/5SddKO3FVn7Tzl L3COsMrhO6Fz/iKuFdZwnFTonL8MygP0Ww8FMOcvRZkgVMPBIab8pTgPBnlQGjwQUFtgWOmVATLn Lz04IOwuWTkgc/6SdZ4t0lKyzsNlzl+yztNZ1oouAJgdwSQxEZJr6MpwMVkqQWEDZ51s9YvsMvny 4kcRrThv83bJBrS3u8VONRnZ1um2pMm0z5FiMt10ik4iCr1PZlMN7JBHpIxbmOsaL+UNKee1TJVN FOQRKRMVnWhDkuQNKZMznaarHOINKddhmOarGAed19QO6gCwvKMvHpikoxpNqRrjS1cEWC5kHbhZ O8m8bLqcSDpyR10vpDjwlWbQC7IecKUBik/Ogdqi0pmgwhYLOFNZTTVYVQwV1nQJwGbEFKIsCVxh ipyZPuUVgStbkVJXxrIkGHCF+2THiElvM0pNttQ+PlLilbqbxbhZjJvFuFmMm8X4cCyGL0AOEQ++ G3CCWthAYGiAW7VEvpEw5H0cYwzdSC1/+yaC68KIdb+Aq18A30uQdlu+Y9SHvYTSLawiazob+8eo xZ2EAufRY01xTpWXuPZzKnShaoMppo1D4nQL6e3t/U0C3l8JOLujhG6zrnl8Rwkb7BWpL+8o6W7S /wHIBnCDCmVuZHN0cmVhbQ1lbmRvYmoNNDggMCBvYmoNPDwvQ291bnQgOS9LaWRzIFszMCAwIFIg MzMgMCBSIDM2IDAgUiAzOSAwIFIgNDIgMCBSIDQ1IDAgUiA1MCAwIFIgNTMgMCBSIDU5IDAgUl0v UGFyZW50IDQ5IDAgUi9UeXBlIC9QYWdlcz4+DWVuZG9iag00OSAwIG9iag08PC9Db3VudCAxNC9L aWRzIFszIDAgUiA0OCAwIFJdL1R5cGUgL1BhZ2VzPj4NZW5kb2JqDTUwIDAgb2JqDTw8L0NvbnRl bnRzIDUyIDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2Vz IDw8L0ZvbnQgNTEgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFn ZUldPj4vVHlwZSAvUGFnZT4+DWVuZG9iag01MSAwIG9iag08PC9GMjEgNSAwIFIvRjIyIDE0IDAg Uj4+DWVuZG9iag01MiAwIG9iag08PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlL0xlbmd0aCA1ODg2Pj4N c3RyZWFtCnic7V1rjxvXef4F+x/4kQyy7JzrnDFQFKpjtQ7qxpa2KArDMJT1Kla6tJyV7DYI8t97 3vs75C53KAkoLFP+YD7Lc32vz7nM8C8Xwwr+e/YvF2EF/9396SLVVRnrancxFvp0i58SfEj8/+8v Xv7m4iurPGzz1IY0rQ4/9Bb/4WmEtq9eXvzz1UWIWKn/bxzSNq5y2Ja4utpdfL0Om7qOm29WV7+/ +Ozq4i82EulWx2FD+/4ij2Wb86qksIWyDFOO25ihaBq2UG0PU3Go/5+/ufihdzZs4zSEqeLIcwit fxgT/Fu9uf4Bm42zTgi1vDoAPJqOrn13TbpvAsf+vyHfgyrWROgGLnhFjcgnml2vYVPvxWlU8Pme T9DiNctu0r/MhDfGufAUpzgXZooqTDfZIGNgYSieopP9y25EX6HwW41jLl3mqIQAH/I0RJW90/Ce BvcVvG8AbKtnDf+/aRhEPw2ltbg6/ACiT3nEibdhW3GQvXcYFOFbxbltc4MwxOUFOxWPUx1G1Oze B98P1dsdtCs4cr9SXrDrZ9F84t584t58hoGELOUFL+0nrP4MReowDGX1P72Z6qYD3aaZmJ6/R5s2 lTQTybu1yeoO24ThnXCcpi3G9HdpU02G22T8Xm3K3Nve3Nt7zb061VubovrnmlbvqdwTabREisEC cymFjTptMVHWXoES6m4zbWuJoa1/3FzWbR5bHNe3m9qj7VTG9RvNtfc1NwWIJNra+nKzuvrzg4Uz zsr1fbdp2zCmKa5fby4L9/2TDePtjcv0j8lwRGX2qL0FmcVRPt/S524/oGMpxnBpVJhV281ahM89 aZC6uZzixV46q7ebNwogNDd6Aqe0PTQ/dnB1Gf4yA6Um/PCgDR3h4kZYQw1Cj06mALtb2IjoFVsg wZxSXWRhVoKyYEM5pQnQgTZACoHq9xh+HIgT9JAwMov94sXmEpJkiTGu315v0jakIef198e8LSaM W9bOUXeLKUMxV/rZlRQPGjzuqRhGDIc5JcjS84r3FZ+QnLvix0YVSHVWusviydXmsjOJOrRx/WmP CPTpX4+KIk5AKRZ2GlPczvvsPZb1f315tIs8odZcrc96qOzRKuT1JxCjcJirzWUg7fWP0pwF5/my 5gFJR1XR3dtjsmsjrIXiIvWHCUmYK/3iu+/ubt68OSanWNDAlvUQY0MDi2bWL1/sXqE8QDK3m8uJ zfqvq03nF2DuTkhHBDKMut77OmxGzk/fgKwDpIa0/sfVhhXwt00YoED0qvh8c9k4gX0JmYW09vPm sqegGMa8zptx/duuTiqz6laHjT1ar+7Ve3wykPaSmPqXmz7+TmWm9b/18U9dImn9/LebELf9j+3e cZjR3ffp2y+egPP0bFlDd57LLguUz4ljbEjNcYyu63/fXI6cn6/6yPb7fvb0CciIZuH6thJ/176D 94iH+YmMp+TDoPVw7HHFF8QeK/1esWdhpxR7XOGnf3j2hZRfGCe6bkE9fuCfdK8g31qkX91AWRJh XOkFESa5zZm3XYJTH1ZZ//TjLQgWpXlzVJrdZVte2mf3wdkAe8h5fbdbQQhAB3o4WiwQUo9n4qhf /663w+55tenF0Pm9U2moef7sU/AYIqz3hJTfdUfv5VKBlo7mG6LHOorjgujsDZbsbsyzgXyzWs6c eV1fyMpguZGBoTO+VZwHWv5LecHLV9a+3u6gXcFDlZU1lRe8fGXt6+0O2mWcW5WVdSSmVE9bWfP+ h5sP7XPIfBaxSWnEBkuNyGAXN8IapLUyT6icsK51Wq8mtNPakMmYJdFkxJJOaYTVoY2oeqCRRxa5 DWRXMsQKzmmVo+WXECp6kJ/WP+ejK9vWgORrG4+sbAMpXjt89hpSZw8EtT6wnj0a8FPnnrBDFvsq nLLgsaidygTh0EofHWuNkAS18Nfr3Yu3m8wh6rrHLwp7R1ciaRrQVpb1SATI9fjKmOGPnVsFzrrA yRbmNRFQD8L1kTaPtdINBWQhrRyfxki2bV3+eHfz8hUot4sut/X/nhJxaTOrgUjAwkfwD4K3Cmvd uo0/gSfuY1K13X6jAqPbKiVw4v4lVNrNmxMw0AaDFBwOdlweaR83wfz4qw5/YSChFnSElQe4sDbr qDt1cxuQw3hCLFPNciNONKcERJqHs5aqxnJSC8PIsR1bGGwD6Hg8HTGdxDHpImG2f3F9PFTErjGr +0iowGzjezphi/B4SO3kubtvLNGRf5gELp2yX798+wRiCYVBY2/26RkscCi8PH9+itMnyBKhNDLo mrehMrxVGEcodKulBS93e19vd9Au44nTOhcXuNw5XbXdfqMMR9xN0D4EnkKvpjqfSXUSWUwmpjob aLXpLmxC9dYoENB0cDG5NA6YsrENkdApbYg8nP3UrPZzShOkCW1CFLOUWIVs61BjVj94n7zTFdlL 9CvwlR4yao8VmT3r6KowD5jfraejYSP3nNzDqx/XhwsbuMMdeg9j/fAbJN9+jn/trVUXYOz7eztw A3j6OUyp/zUF3+/Jaz86EqYTscboVlBJ4sdUVvCJ6z6ut9tvluGAKcp6EXziqo/r7fabJZh61gyu F8UnrvncXND0dDInrXBsqNSIjPWUNR8fpu9sRmVbl8cl1fdk6j+tCZmMWhDNhU3olCZYGdqGKmdB YMKckKvtC9275KvHl3wVjybqop0oWALFeZcfZtGXE24vLl31ueILln1W+n3WfUv7pIWf79Ov0qrq 5fSFX464GXBs5Xdc17Tys2aWLP18p+++9iuFTsAqX7apuXubwFuBmS8KSWnBS2PuvN5uv1mCQLcH 14vipdFwXm+33yzDiluV1ovgU3rJfiqVjrN5LotCDLXhBopt6EgXt8Gaw/0+N5/lhNTUjW2YiJY3 wfIwAyJ5iAWdIg9ShclDVPNoxC2V7xTY/rPFWUe57CLJK/1kHPCvx3y0jxWDTV60IV76OhOCjRuQ nee4ATma+p19tMG9fbUp7NSzWscGyrKIo54U//wCeR1Kw6io9YJc+I/33bdZmCykz2CU151SvrgF iki08KejRFvaGSyNvUNeKD0vhOpaeURVCTOX6/P1jzd3vdsw0qLh9Z2Lp7B5AhsvpZD/p1BwD4Xw LeIqEECjwtWDBHcpGYdQadnFLQXo1i1UDzFvxElxgej+BAFUKlpnqJe4vmDMA7m1KWS+4CNTzHrS gU78q546RbWY6Cih2yPdZ0i0cwZYv04DxnFAcLvNEE6dYKGtTmqmxJEuDcnJyQGWW6RS3uGk3wOC U4KOgL8qwl6zjL9aOzniX29teox/5dNedos/jnj627lbkLtXk+MXfBcLMC5fAMdsyTWOuO0DODIs enuRMFLDSsd3EXZnEObGMFHxmBljyqS6CdM47ysBTIQLNRWJKZRtbIzBVyrTD8AByuctfR3wcLdm Wg8ChhsHFUdAmL4moY544JhqoqgAGOWQ+H7igJ9RnLHSWXdlewIMSy1aHhDm5QK5Z51ISHGbffVI KzPoCkUcRAXcdRAVDKSiICqgkYetzKNC6UE0wPMeRAMRScogGmCpDaIB8oI6OJGXyVTQdJVk6iqT qICO28skKkBtwwYd20IkWMQ28KJJEw1UBIO3szKK/NGCAPP9UJRB4dAKVpypOKlgRHtNhUOzYvf9 FH192PGz1nFPznU+0V0RHRzd+LWRTyQXmVkbSC488TbMxdLwGQOVWgskF5Fq4ws4IvWm+mi0pldl NdqeUGW2SJYhum6JbFxsoePazFRaJg8RQ2rEX8XOGlNxscNWyDTEThvRbLbiRglTjb4VcldxCqkt TtMyGR47FPct7taSeCvHOB65eGtLW+/MMnH29Q5zc6FA5FZM4qMPJSxxDTWNF7TVtKUhqg0SsnJz urYIN231QraZisbHNlveiKVZeG2kEg2/ZKcUnt1TUxz0Oabs1AGk4EHMEQdhh+B14jlPnPPEOU+c 88Q5T3zEeSKpMnYe012Z+0CFRxjn2KE+rjm6Vrehs8zbPexy0wHqdWHb2AdBBwGUqmOYIapZxLKs nv8cKo+Oc99+LuTxcAg4QNec+Cxk7A5DxD1RPGrvThZOVTk7bA6h7uIdxB7W/UA5/2wUH4tRnMLd 4CgvTnTAylkRcBDyhk+dNMmClc5mVHMVgRC5QmWDZOeoG7WSywFWl+pz1ECWZV83GlOAU6DJkTfA o3wf6GjK0xA+NRKW0qExmByVCGKCAlyMuQGMjh4BHhxzg20U+RplIKmj8nNFklmInNkuDDkfbNK0 bBqXTRutLmmtE0PdgNKuxVqIVAKu2Y2cMygxUoBhNm/lgfgF4DqTmfJAOraMQVXADyipCvR5Jaew YUbFAcfs9D2wLeDVEeWBZCtBeSCqBnD0dhaUB9KTg0GIIJlpUCKIz2oFZVNoY4CHNsdJcmiYVQcL tsbptNL6RmdwY4P87IZOT67p1Ci987ybPhfGuZ+u0KjMiLmZTIlXmMhbNHUQJzFtEXczbSKjMWUT dTNjIEKktkLUzSyJ2JRZGnE3s8TGT6sp+8KTNTFi20ht2X2r5IsrK/nixpV9cefCvnhsyr6S+G9s fmrKvtLWu7cIpnqpKfvyQUPEXU38sbmgI+rimCTalJAlqtaQRqZgEQ8txQIiGZLGSz4V11iKVmih lozUQjEZMYXqwwU/qUJzv5Zz4cetc9Q33mm5f04Z55RxThnnlHFOGb/clIGj4HuVc+zQHrj2JVte PYBQhde++zofTdN13SGqushz4bBt1VJ4GXeIqq3xeOhaLe0BXeTlMM6zIj6qIb5/ANwCjyPD7jBS SKx2sTxqzzMxqJJ46uo1La9mXtPyau8Q96sPlfjPxvDLN4YTqZvey5M98ClrioTN4EkPOGgHfdID Dio7yF487HhOerxBe/OTWBtu3E86T9rXn5Sk0L7/pCSFzgUmJSl0bjAJS6EzhUlZCp05TI6lEKz+ pGZy5xuwpzLZAUeU27XK3QCP/rRkUpJCpymTJGQ+bZkGY26pSSrnnbYmqZ63d5owAa7clCkM+PRr cx035Rh0gtSUg+C4m1IUOn9qesZAs25ixXR61fSAgmTW9ACDTr9aNRWAyFs1FRD052pySVzO3Vrx TF3vssupXSt2yFeouONuqWVRAVlay6ICOjOELX1H3gBH2ZKD1vzmYUvCExlLggyzinhKY+3SZrr1 S8c0Ni7citdR0yGNToo38nXSfEqjMml60z0INeCL9kLsRi/wFp02+ABCtcUHNapNOr4QXfMxjZoC H36oqfA5jVoSH52opfFBjRgin7yokdI5jdow7zarjevXY3W1yT+4ZXUe7lmdi0c2uQOnyTsnz0xc l6Y9zfmsOT5LTeNC80GD5S0xhbWhIafpE5TNa1NDFmvbQhpZgwY8NBULh2RJFi7J0iyWoiFaqCU7 1UhMNmw3xPcO90kVttEvBV34idIQGkaaPXF4ThnnlHFOGeeUcU4Zv46UkaJoZreHHYptD137siWu HkRjdYe6U7HUwxhKWx6ZI+qHTmAtIgqEsnxse4C0pmGrOOQ5sGPdlg5SI9S0kHCA/LFuy+5M1+/N zsJ5bM4TRA6mp5wN8vGt9xvGkrD3zvjfM/WfDeJjMIjF9I0jEGweo6rpqlEcbHsRnl6ZbPMxEa4+ AoVpftcItrVdBApNUh9dNQpNUiPNLDRJnZiCQ5PEStwxSLqGMBxGSckVgd/qBxyFKkQqPAhVANMP deuOiQAWTzxClUBKzDFUCbTJnuEx5ohP+xjpCcVIUV7xgzXGmUIWThTdgzmuelZamqh4qK7vZJwI FBSSnXjh0JOdeNHX0c872l1ZoEwhigJYbtE4UaTyqgEUuhAoIEwhGCmKCIu/DxmCectE3w+OJsHr FbylDKICym1hsPuOKIbB7kOCSoZJ2AgZ6sC7hZxYB9napBt1w2R5tvlvKS1rZbqbZ21TUte++W6f jo0ZgY6drwbK1IhP6Lz5XqHKhdmIyo2uJapUmczMbjSqPpgGqb7Y91WfnAJU343eXC7mgC8pMluh 1yCZLbWRrENsjc2SmQ49XSRm2hr5pj431kgGYvWNHk1Sp5Dq7DNtJBGLS0nX4nH0GJp5JI9cHJYz ifizTHuccUuNBiK10STefCgRkXvyqEFI1CUxismjxjDWdtPDNZLLtJ2ZyqTk0kVPsbPJuH30wZfN FGPzjLBN2ygBZae2z8UO4o25Bmrm9BX+OUWcU8Q5RZxTxDlF/KJSRBZV7DzEu9cPILp7PcOK6DHx GboWp+m9a6pR6NISI04ifMObNhYtBHosm6s8hhmiuozxhjXX3EeZBwjdDm0vGTYZVLsXXLu8N8g9 tr0IcRjDve2LJILEGp69espUZ57iPcOv6T9Aqj+bw8dgDssPZJBRxTrIj7JgkgXsn1YAbNvegILs msPLRYvSOfplmaJ0riLwT2YCFqoAWyGlGZXAd0kol0NOBdhf7gOsDwbiSzKMUMWiXC7ReyqUztED HUXpHD6oUZTNoWfEImwOTQSgfzITcJLjmYmK+0cz9cUefFxD7/JAaG/QcN/p9cqR3qih1yuxbSVz 3LeQOR5atmMoHLmyOZqYkjmet5I5louwOZKakjmWaDQNoMSjaaBQ+Zi9xmbqVDLH2lY2R0AvV2Yq rJcrUQrC5dDKilI5ssGiVI5stAy2sw1CyEK3iAoCrnOoX6NQHBOESzzFMcXqeidiqGMjb7Sho7Pa zCjF2rSJCppYKEWzzIgHmkApuZvAiQeaQpAamL6ICKo2iViYspEHmi00fpeLkjF9l4s++ZOqWVrj d9AoH6skBs0e9FZiNWQkVGbnRKjMJ6Q55WP08hulYzwY5WMUvMUjeSpKxzJZ/WgMuDbn7kSpLByI HEWoo48jogTlY9EFIVGfsrFAVi5sjJSvZGwgmSgfY9Nxq92Wffgky9PgOtFbvjX2kuHWQZ7FUr6m bxbiO/Nt68rtBRz8jn3hHQ7sz/nhnB/O+eGcH8754ZeXH3QhONKoivs9g0NEl5dn2CECg8Sta+s+ zDINwQOASSRwH3QFSQMg3WDiTgykfXTti6Ik9tFYZdbX3u33MiEuEvcAR4AkF7F9yNjdEyP2QzhB jdKqGdUUZ1F1lj1fadqYX8+/Z54/m8LHYAruskbDHxGhpb/cleLNC4K8z8Hn/Q5FeZ8jPPCTBq2Z EWGQlZeSH2DOXVLcQXg8iDBv8mb+hXNB0BH0y7fBJt+Su6+ld1HG87R1G4+9nneOdeebd44Z874x b/8oYsNnrCGD21JH1d8Z2scDvyqUiwvEhEmQd7/ZkB3ijnn/Pc86tk0r2anM54nf9wuBE/5oOJgV v5M3HPs9wWmym8+PFx7lvUdLCuNNU9pCXlIY14Y49lnp+euoG1UCjwQiVFLWV7M/3fTI1//hW53X f4I3Lf90t4EfpV3frMofP9lcpm3q//J69WwTsOy4/sN/XH0G75Ef+r+wXsEvsuLfv3iyaWF9tYHf Wez/1p/OfxpUhwG/zVzdMOYvQHbFUHJ+uH0Mldq+uufXUudzRRMqAQ9r+WdOJp7Lzc+b7Kb95ua7 2S9AaoP69pZI2ZzP8fRtLXxux/hBlNFOCWZexkhTmdct7BCHmFdFWt7hQSAfPgJK0aNCrzMO8n65 7Fqy18vxJIO+aZ5ein4Ww1dLf3Q2DbiALsleqD5sxvUWfuOCXlXuPsajP7ZAJ438wv73ailirE0Z 10rv11KkX5fDy+XvOzv4qaKovwv4cEPh/uBRBribnydMStjEVz/dvNmkRDGIXkmPgek1/twPOvwP 3cs/WR1tcLQfLXpytwHZQZi5WUGgo0Z2L+DHbfHPb3ssXF9/v4kSUN702DLgL932cvjTJvTFnQZN 39LtRqLqK/303xo2b/7JRvp/VNhhowplbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2JqDTw8L0NvbnRl bnRzIDU4IDAgUi9NZWRpYUJveCBbMCAwIDc5MiA2MTJdL1BhcmVudCA0OCAwIFIvUmVzb3VyY2Vz IDw8L0ZvbnQgNTQgMCBSL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFn ZUldPj4vVHlwZSAvUGFnZT4+DWVuZG9iag01NCAwIG9iag08PC9GMjMgNSAwIFIvRjI0IDE0IDAg Ui9GMjUgNTUgMCBSL0YyNiA4IDAgUj4+DWVuZG9iag01NSAwIG9iag08PC9CYXNlRm9udCAvQ2Fs aWJyaS1Cb2xkSXRhbGljL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcvRmlyc3RDaGFyIDAvRm9u dERlc2NyaXB0b3IgNTYgMCBSL0xhc3RDaGFyIDI1NS9TdWJ0eXBlIC9UcnVlVHlwZS9UeXBlIC9G b250L1dpZHRocyBbMCA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3 IDUwNyAwIDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDIyNiAzMjYgNDM4IDQ5OCA1MDcgNzI5IDcwNSAyMzMgMzEy IDMxMiA0OTggNDk4IDI1OCAzMDYgMjY3IDQzNCA1MDcgNTA3IDUwNwo1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgMjc2IDI3NiA0OTggNDk4IDQ5OCA0NjMgODk4IDYwNiA1NjEgNTE5IDYzMCA0 ODggNDU5IDYzNyA2MzEgMjY3IDMzMSA1NDcgNDIzIDg3NCA2NTYgNjY4IDUzMiA2NzcgNTYzIDQ2 NSA0OTUgNjUzIDU5MSA5MDcgNTUxIDUyMCA0NzggMzI1IDQyNSAzMjUgNDk4IDQ5OCAzMDAgNTI4 IDUyOCA0MTIgNTI4CjQ5MSAzMTYgNTI4IDUyNyAyNDYgMjU1IDQ4MCAyNDYgODA0IDUyNyA1Mjcg NTI4IDUyOCAzNTIgMzk0IDM0NyA1MjcgNDY5IDc0NSA0NTkgNDcwIDM5NyAzNDQgNDc1IDM0NCA0 OTggNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcKNTA3IDUwNyA1MDcgNTA3 IDUwNyA1MDcgNTA3IDUwNyA1MDcgMjI2IDMyNiA0OTggNTA3IDQ5OCA1MDcgNDk4IDQ5OCA0MTUg ODM0IDQ0MSA1MzkgNDk4IDMwNiA1MDcgMzkwIDM0MiA0OTggMzM4IDMzNiAzMDEgNTU0IDU5OCAy NjggMzAzIDI1MiA0MzUgNTM5IDY1OCA2OTEgNzAyIDQ2MyA2MDYgNjA2IDYwNiA2MDYgNjA2IDYw NiA3NzUgNTE5IDQ4OAo0ODggNDg4IDQ4OCAyNjcgMjY3IDI2NyAyNjcgNjM5IDY1NiA2NjggNjY4 IDY2OCA2NjggNjY4IDQ5OCA2NzcgNjUzIDY1MyA2NTMgNjUzIDUyMCA1MzIgNTU1IDUyOCA1Mjgg NTI4IDUyOCA1MjggNTI4IDc2NCA0MTIgNDkxIDQ5MSA0OTEgNDkxIDI0NiAyNDYgMjQ2IDI0NiA1 MzcgNTI3IDUyNyA1MjcgNTI3IDUyNyA1MjcgNDk4IDU0NCA1MjcgNTI3CjUyNyA1MjcgNDcwIDUy OCA0NzBdPj4NZW5kb2JqDTU2IDAgb2JqDTw8L0FzY2VudCA3NTAvQXZnV2lkdGggNDkzLjEyMS9D YXBIZWlnaHQgMC9EZXNjZW50IC0yNTAvRmxhZ3MgMzIvRm9udEJCb3ggWy02OTEgLTMwNiAxMjY0 IDk2Nl0vRm9udEZpbGUyIDU3IDAgUi9Gb250TmFtZSAvQ2FsaWJyaS1Cb2xkSXRhbGljL0l0YWxp Y0FuZ2xlIC0xMS9NYXhXaWR0aCA5MDcvU3RlbVYgMjUzL1R5cGUgL0ZvbnREZXNjcmlwdG9yPj4N ZW5kb2JqDTU3IDAgb2JqDTw8L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3RoIDIwMzE5L0xlbmd0 aDEgNTY4MjA+Pg1zdHJlYW0KeJzsvQd8FcXbP/rszOyek7NnT0IvAXJSaYHQuxB678UEEBKSANE0 k1BFAbGi0kVBQWwoKBqQLioogqJgF3tBVARBpCole7+zs4GA6M/3ff/l3vtJ8Jvv9PrMzPPMLEga EflpBnFKTMtOzTvwnL8tQt4lijmQNrEwOPSD/klEsUVExvNj88ZlP3640/NE8SOJQiqMy5oy1lc+ awFR8zwiz/rxGanpR+a37kp0XQzKaDEeAdbZap/Cj/QUMz67cHLfr061h38G8HxWbloq5RyB+5Z4 +Ndnp07Oq+mv1oto83dIH8xJzc5Y/tXLvxJtgdfakpdbUGiH0V1Eu7bJ+Lz8jLzXp01F+3Z9RVSl CsK4ixok+0XlpsIHV4U7SJQb5fRrBhnURxZHt7Hx7EWeyyfw2/hsfj9/nO8Td+kVAh1qvlZzT61H ai2v9WdEpYiaEV0j+kZcH5EcMSLihohbI9ZH7Iz4KOLLiN8iTkUUB8OCUcG4YKNgs2CbYPtgl+Do 4M3BOcFFwQ3BrcGvI/XICpFVIoORUZFxkQ0jm0T2ixwdeUfkkshno1iUERUaVT6qUlT1qIioulH1 o3pEpUZlRLPosOjImIKYU7EUy2L9sWGxFWOrxj4e+1zsu7Hvxf5Ue3p8VvykhlWeqf5M5HlRHF1s 27bsJ3oTpBUskxXxQj6V34HezOFP8vfFPegN1dxesxi9WRFBEVUjghE9Iga4vRkdMSNiY8SuiE8j vo44EXEmSMHy6E1CsEmwdbAdejMqmBcsDM4LrghudntTuVRv+kYOjpwVOe9Sb8qhN9Wiarm9SYlK d3oTjEmJORxjX9Gb1bF7nN5MjE+JL0RvqjwTPE/FQac3mn1adsioSWQ3lK7izeT+2OuO7JV8fA+V +jnyDv68Rdf4+aEp0dH+P9SH6+DRh2TIL5DFY2t//fFA0Q+tiA7cfmD6D/V/qPHj6JIcv3Y/0PtA rwNdUOoPTtkTDkR/f57o+x8OLz88//Dth3+RoYeePLT00EOHFh2afyj50ED4Gx6qqvJ/m5vWMw25 Qw+FWkoC6S3tDiK9PHo0x1iM3yuMXZ4a3ntkVMjSkBeIfD+ZD5uvm+/6K/uDqhR/HX+6/13/IYtZ fquR1czqYqVjim93JnqG+i191vqSdlufXu61tc963zpkHb7kPyVhnXF9J0qlPGwVXzliKtY6ERCB GiqkhInzXvwhvok/K1rzh/lirJnpfI64jg/l+TyJZ/Ff+VF+jP/Gj/Pf+Ql+kp/ip/n1fJjoIjqK rrwvf4QElaPyVBVrM45qUzwlUBtqR+2pC3Wl3nQ9JdNwGkXpNJ4KqJCm0FSazmfwPD6TL+JTtaMa 00K1MK26Vkurow3Qhms3aJlalparTdAmardq92r3afdr87Sl2gZtu7ZD26Xt1t7lt/McPos/iNb3 5qv58/wpLlf8fObhy7X3+XjRE61fwSz+pOjG/+B/aifEIL6AT2P1+FntA54p4kU90YT3Ix27hoe8 FIK9MpSqUE2qRREUSY2oMTWhZhROPbCr9KV+1J8GiA40hDLpRrqJsmkaJWkPa1wTmq4ZmkfzaZZW SYvQglqkFq2N0kZrKdoYraY2RbtNm67N0GZqt4tE7S5to7ZJ26xt1d7WZmvvkE/zkqmFUEDzUwWt HFXUylNlrSJV0ipQNS2cqms1KEqLoWgtlmK0OIrValNQi6I62kCqqw2ietpgqq8NoQbaCGqojaSm Wio119KohZZOrbQMaqmNpdbaOGqr3UTXadlaDnXQ8qijlk+J2s3UWSukTloBddMmUU9tKnXXJmu3 UC9tGg3UZtEgSPhg7U4apt1DI7QH6AZtLo3U5tBobT6laAtojLaIUrWFekW9EmVoj9A4bRllaVso R3uZcrVtlKe9Qjdrr1K+9hpN0nbSrdoeuo1maHvpdu09mqnt05YYC/Wv9W+MRfq3xoP6d/r3xmL9 gP6DftB4yHhY/1H/Sf9ZP2Qs0X/RDxtL9SP6r/pR41FjmbFcP6b/ZjymHxfzxWv678YK/YTxuH5S P2U8oZ82DhtP6meMp/SzYonYrf+h/6mfM57Wzxsr9Qv6ReMZ41njiF5srDJ+NR4xjhrHjN+M47pt kLHa0AxmPGdwQxjPG7qxxjCMFwyP8aLhNYqMEGOt4TPWGabxkuE31hsbDMvYaASMTUaosdkIM7YY 5YytRnnjZaOCsc2oaLxiVDJeNV4zKhtVjO1GVWOHUc2oboQbr5OlmRSmBWiodrdRw3jDqGnsNGoZ bxoRxi4jaOw2Io23jCjjbSPa2GPEGO8Ysca7Rpyx16ht7KM07UEaqz1q1DHeM+oa7xv1jA+M+saH RrzxkdHA+NhoaHxiJBifGo2M/UZj4zOjifG50dT4wvjS+Mr4WrvR+Mb41mhmNDe+M1oYLY3vjQNG K+MHo7XRxmhrtDMOGtcZPxrtjZ+NDsYhI9H4xZvlzfbmeHO9ed6bvfneAm+hd4J3oneSd7J3ineq 9xbvNO+t3tu8070zvDO9t3tnee8IeSBkTsjckHkh80MWhCwMWRTyoDXTuj3k4ZAl2BUfCXk0ZFnI 8pDHQlaEPB7yhHZWuxDyJLNCngp5OmRlyDMhz4asClkd8lzI8yFrQl4IeTGkKGQtK89iWBUWzxiL CFkX8lLI+pANIRtDNoVsDtkSsjXk5ZBtIa/4evl6+/r4+vr6+fr7BvgG+gb5BvuG+Ib6hvmu9yX5 kn3DfSN8I303+Eb5RmvHtdPaOaazsMAUVonVYWZgLKvOojQ7cEvg1sD0wMzArMCdgbsD9zJNH6AP DNwXuD/wgHU8MDcwLzA/sCCwMLAo8GBgcmBx4KFAOqvPGgQeDiwJLA08Eng0sCywPPBYYEXg8cAT gSf1LD1Hz9PzA08HVgaeCTwbWBV4Tp+m36bPCA2ExrBloU0CawIvBooCawPrAusDGwObA1v0uYGt gW2BVwPbAzsCrwfeCOwM7Aq8FXg7sCfwbmBv4L3AB4EPAx8HPg3sD3we+DLwdeDbwPeBHwI/Bn4O /BI4Ejga+M2/zLfWt873EnucLWWPssZsOWvBWrN2rBcbwG5njVgT1pQ1Y81ZS9aKtWFtWXvWgSWy jqwT68y6sm6sO+vBerI+rC/rx/qz61hvVsCmsGlsBlvI8lkhm8gmsclsKruF3cqms1nsDnYnu4vd ze5l97H72Rz2AJvL5rFFbDF7iD3MZrIFbDabz5b4nvU951vue8y3wrfet8b3iu8J30bfSt9W3+O+ Db4nfZt8T/u2WKuttdZz1jrreesla4213nrB2mC9aG20iqxNvud9L/iKfC/7lvhW+Vb7nvFt8y31 PeXb7HvR94jvUd8y9jxbwz5hz7IP2evsJbaebWBb2Db2KdvE1rE32R72FHuarWTPsNXsOfYCe5EV sbVsI9vMtrKX2SvsNbad7WBvsJ1sN3uLvc3eYe+yvWwfe4+9zz5gH7GPuZ9bPJSH8Yq8Mq/Gq/Nw XoNH8mgey+N4HV6Px/MGPIE35s14c96Ct+KteRvelrfj1/H2PJF35FV4Vd6Jl+MdeENei0fwII/h tXlnHsVr8ia8pfWm9RHbz7tYu6yPrd3WJ9Zb1qfW29Z+a4/1mfWO9bn1rvUFe5XXZbt4U2uv9SW0 ga+s96yvoRN8Y31gfWt9aH1n7QhtFto8tGVoa+sNa6f/cf+P/if8P/mf9P/MVvHy/qf8h/xP+3/x r/Qf9j/jP+J/1v+rf5X/qH+1/5j/Of9v/uf9x/1r/L/7X/Cf8L/oP+kv8p/yr/Wf9q/zn/G/5D/r X+//w7/B/6d/o/+cf5P/vH+z/4J/i/+if6u/2P+yf5vf9r9ikf9VS/O/ZjH/dov7d1jC/7qlW4b/ Dcvj32l5/W9aIf5dls+/2zL9b1l+/9uW5d9jBfzvWKH+d60w/16rnH+fVd7/nlXB/75V0f+BVcn/ oVXZ/5FVxf+xVdX/iVXN/6lV3b/fCvd/ZtXwf27V9H9h1fJ/aUX4v7KC/q+tSP83VpT/Wyva/50V 4//eivUfsOL8P1i1/QetOoHfAyf1dwKnA2cCfwTOBS4EikMplIXyUN3oaPxudDJOGJ2Nk0YX45TR 1ThtdDPOGN2Ns0YP4w+jp/Gn0cs4Z/Q2zht9jAtGX+Oi0c8oNvobtjHAQ8ZADzMGebgx2COMIR7d GOoxjGEej3G9x2skeXxGssc0hnv8xgiPZYz0BIwbPKHGKE+YMdpTzkjxlDdSPRWMMZ6KRpqnkpHu qWxkeKoYYz1VjXGeasZ4T3Uj0xNu3OipYdzkqWlkeWoZ2Z4II8cTNHI9kUaeJ8q42RNt5HtijAJP rFHoiTMmeGobEz11jEmeusZkTz1jiqe+MdUTb9ziaWBM8zQ0bvUkGLd5GhnTPY2NGZ4mNEF7nSZq b9Bk7U1jpqepcbunmTHL09y4w9PCuNPT0rjL08q429PauMfTxtPW085znae9p4MnURSKJ8QE8aSY KJ4Sk8TTYrJYKaaIZ8RU8ay4RawS08Rqcat4TtwmnhfTxRoxQ7wgZooXxe2iSMwSa8UdYp24U7wk 7hLrxd1ig7hHbBT3ik1ittgs7hNbxP1iq3hAvCzmiG1irnhFzBOvigViu1godohF4nXxoHhDLBY7 xUPiTfGw2CWWirfEI+Jt8ajYI5aJd8Ry8S7dor0lHhN7xePiPbFC7DN7mH3MXmY/s6fZ1+xt9vft 9X3ge8/3kW+f70Pf+76PzVQz3Uwzx5pjzAzfEd8x31Hfcd+vvt/MTDPbvMnMNW80c8wsM8930nfW d9r3p++U7w/fGd85c4Z5h3m7eZc507zTnGXebYaaFcxyZiUzzKxoljcrm/PMheYC80FzvrnIDDdr mTXNoFnDjDCXmsvNR80V5iPmY+Yy83GztrnafMF83iwynzNfNNeYa814s5HZ0GxiNjAbmwlmU3Og OcAcb44z882bzfvN+8yHzMXmSvNp8yVznTnMHG4mmSPN680RZrJ5g+8L3ze+r3zf+b70fev72ve9 OcGcYk4ybzEnmlPNyeY0X7HJTDKFzza5qZm6udHcam42t5mbzJfNLeYrZkuzrdnavM5sZbYz25jt zSHmYHO0OdQcZQ4yU3yf+fb7PvV94vvcv9S/zH+/f55/iXmbWWjeahaY030nfL/7LvjO+y76F/jn +xeac8055r3mPeYD5myzulnNrGpW8T/oX+RfbK4ynzWfNJ+AzbTEfMZ8yqxv1jPrmnXMaP/D/of8 c83XzA3mq+Z6c7sZZUaazc1mZgv/HP8DVraVY+VaedbNVr5VYBVaE6yJ1iRrsjXFmmqdsE7yfOsW 2M4T+WTrVus2PpyP4GOs6XwUH83TrBl8Lp/Hb7FOiTbWHXyAdSc/Y53l5/h5foFf5MXcFiQ0wQQX QvtO6MIQHuEVIcInTOEXlgiIUBEmyonyooJ1t3WPda8127rPut96wJpjzbXmWfPF+3yltcBaaC2y HrQWWw9ZD1tLrKV8I3/MetTTU9QXjUQD0Vg0Fc1FQ9FCJIhmoqVoJeoa8zw9xDCRJK4XyWKUGC1G iOFipLhBDBHt+TTRX/SxlolO1mOhPUJHhY4OTQlNDR0TmhaaHpoROjZ0nPWn9ZQYKj7QQyw7ANMi wAIclp8eMAKe0BuMez0djdnGfcb9nk6ezsYDni7GHE9XY66nm6e7scDTy9Nbq6811LprrbTeZDCf NBI1cq3eyz8aMfyRP+xaNvoVKf+/b2eSYyFWgXXYgwZQNqw+DrvPA8vPB6svCLtPWn2jYfdJq28K LL7bYPPdDqtvEyw+2HuQtCcdS3U+v4Uv0B7mK/hy/rh2gnlEJ1ieQ0Qf0U10Fz34i2KQ6It5Hszu E/2097UPxEBYlnfxfry36Cn6G0tEZzGAj+eZPJk47FcvLFNYaI6MS6mGhItEMRS25W2iDl/J03mG nE3I+TQ+hqeJNrB3I2D1RsLWVTZuI8e+Jdi50rLN1MZqZ6FtW67mXY9FsHjtQtk9W9k9W9k9W9k9 W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k9W9k92//ong0/nuWw1ReWMibzaCY9 Ss/RBtpKO2gPfUQnNR+l0J30Gv1Ah+kEndcIFlElrYZW91r2+3/vp3iWnk0W3w6LrQqRfc7+pXiV DbtdD5QKWQhfFRF3OcQubx+9Oqx4YfHm4n0GtHAnbxh7B6HHtaP2OdZB+u0W0s/ulm4nx3HP8uIX ix+7ojmj0eMcysVo3ExjaBx8+TQZtu0tdCusnOk0g2ZhRO6iu+le/L6fHqA5NJfm0wJaSIvoQVpM D9HDtISW0iMYzWW0HOGL4V/uxJITs4KeoJX0LK2m52kNvUCPw/8kPUVP0zMIXYXw5+B/xknxnJtm OUJWImyVm+tFKqK1bpxyr6OXaD1m78Wr/JtoM22hjS5vpZdpG71Cr2JWt2OeX3d/q5jS4X+f4116 g3bSm7SLdtNb9DZk5R2E7aV99N5fwq8VVpL270t5nz6gDyGBH9Mn9Cl9Rp/TF/QlfUPf0gHI4kH6 1UmhYr+irxHzHUIP0KGrcu6/lFel+hbpvnfL+Il+Rvpf6CgdK5VHpf8KqQ7RGToLmfdq1WHvB2C5 n6Y/4Le0yog5p4XAFanV1hpgVSVozbTmWluto9ZJGwRfI+c2YR7kYhFmX8nDUsjDJMjRvQiT0qJm fCVW3apLs/wi5k3O2iMYc/nnNWfkX7/GSO1FT59FrrXOHP91rl53c7yFeHn/VjqVnMk3rihNjvhq pwVSbrYixXY399uXZuMTlPLxFaN5gH5EjBw3Gf+ZE/OOM8rfOqN8EPE/ObMgU6nx3Y/5/fRSCTvR 3u+R90PMy4dOKjlrnwMyzdtI9Tziv3Fn7hAdwWzJOTsM389wb3N2ph/RYjmXP7hx7yLmOParU5jZ 3+h3uE7CLf/sQMgJ4BhCf0MNJwGZ5gjadRwt+hVzfAKzfhYxf8J9hi7gzym06Bydh0vGfIGYM47/ PNlUTDZ2RU1jGke4dJOT5wL6fxGtKUbKYk2ji86dkrxR8kJyfJqp+SE/MqcTokqBVDGkknFeJ8RJ T39cSi9v1Mpp5bUKWkXsw5VRagBh5bWqbkxISYxWBWGBUukrETlh1bTqcNWS91m0Dzt5LToD+a4B CQ9qUYhlWk3M8ydaNCS7jlZXa6Q11ZojR4wWi9qkpLfXOmjRCInV4rTa4ProHyRea4eYjloXrSti bS1ea4H10F7rdq09ny3BCnB+sH9/pgc0Hfv/66wfTYZ/P2RwBQ2gJBpFN+qH2LuJ3UaPumHkiOHJ SUOHDB40cED/fn379O7Vs0f3bl27dO7UMbFD++vatW3TulXLFs0TGjaIrxMXGxMdFVG1YrmwUMv0 hXg9hi440yi+a3S3lGBRXEqRiIvu0aOB9EenIiC1VEBKURBB3a5MUxRMcZIFr0yZiJRjr0qZqFIm XkqphQXbUbsG8cGu0cGivV2ig5u14QOT4H6gS3RysOio4+7ruEWc47HgiYxEjmDXquO7BIu0lGDX om4Tx8/umtIF5a01fZ2jO2f4GsTTWp8JpwlXUZ3ovLVanfaa42B1urZZy8hryWqLeGzX1PSiAQOT unYJj4xMdsKos1NWkdG5yOOUFcyUbab7gmvjt8++f3MYjUmp70+PTk8dmVTEU5FpNu86e/bdReXq F9WN7lJUd+rBquhyRlF8dJeuRfWjUVjvQZcq0Ir02LDo4OzThMZHH/31ypBUN8SIDTtN0im7eGmY EF/iJrQNLUT/IiNlW+7bnEhj4CmaMTBJ+YM0JnwdJSbUTy5iKTJme0lMpaEyZkZJzKXsKdGRcqq6 prj/TRxftWjGmGCDeIy+818s/kN8sIjHpYxJGy85NWN2dJcuatyGJBUldoEjMdXta9e1jRKQPjUF nciUwzAwqSghOq+oYnQnlQABQTkHmYOTnCxutqKKnYsoJc3NVZTQtYtsV7Dr7JQuqoGyrOiBSVuo qf3d2mbB8JeaUjNKlu0oqtwZkxLXdXZS+tiiiJTwdMjn2GBSeGRRYjKGLzk6KSNZzlJ0WFHd71Bd pFOjkwt9uyp1SWLZc0+sN5jEwnmynC0EBLvhV3SndogIw3Q5XjmjndoFk7RwKkmGWtwU0nVFOfDw 2M49ZBSXWTv3CI9MjlQ//9CkcLdNemyRt1RZYQi41CZVz982TaWWDaob7JrRpVQDryhUdxvolnbt djI5Fm7FyOGV09mjJIrHYuUijKEYJ0jOYtVgEQ0IJkVnRCdHQ4YSByTJvsmxdua39+Do3gOHJzmz 7UrJkCt8Kr6V8hVRJKJLPKwzZLBb/fCSaXX83R3/JW+Pq6J7lkQHZ3ujew+eLQuPdgukIFYQOm3E 9Uy9r1X5Zlia3bC7RXdLjQ6GBbvNTt1szxgze21i4uy8rinj28gyonumz44enNQu3GnroKRbw6fK qspTb633kE4N4rH3dFobrd0zcG2ids/g4UlboG8H7xmStI5prHNKp+S1MYhL2hIkSnRCmQyVgdIT lB5Z0iB4vE768C2JRDOcWOEEOP60zRo5Yd6SMI3SNjMVFlYSxhAmVFiiEyZ/MElVx2OIsd12DabL 6ZmWPH52SrJcXFQZU4n/tCItuj0Vsej2azVm+It80RmdiszoTjK8gwzvoMINGe6BYODUxeDIPWl2 SjT2KQhUEoVrShS5LDK42baHJEXuDT+aHAlRGwkMTyoKqY+9X4/thXTdJVIQ3L1oRlqqbAcNTZJ5 PbE905IhtiUFIknPohCUEOKWgBTdnDxSHJEpDXODCXTyz4CnaEZyUXJ9WWlSZrIjzmFF1CO6DaZd lanHyYoSkmeXj27irE0sBV/s3ZJC0DYanKRCwuFFZclqkDx+tDwtGlFpKUGMtqC0wRB1tZf6wlVI BrZEEZfhwBfuRpLsFo81LV9RSEMUiP+k22wol6Qe60lOVo13fHe7CVB3WJGJFsWVGko3A0YHUT1l W/Df3WiqTLpDFjNwMw2KnoydRTbaKcmD6CIrtmcqNn+V30RIdKuSzF65R5huGTtVqEf23I9x57FD NtvPRE+JLPXTID5aHg5SMCl8CwSbkmdfHVA0on6DeO/VoZYTPHu217p2BjVeXusSIxDmMSznAv4d LF1OHmpLQ2kY9d/QoHKDyt52HX2sDfUkj1YE6Q8yIi90y7WJ5QWLbWnwgeFWubyB2sAuHjaEOnz9 zdc3fPP1XvBeLeHro58eDbv46dHyrVsnJDRupJWLLOegYoB5PIYRHdWQtWzZokXTpk3as+bNGrLo qAAQ17xZe9ayPW/apBZzkqqUTigSy1D+3YX+vNvFGDYx2GV8j1q8QWzliPIerZoeXd1M6FSnvFUz ITquTd3qhtcjDJ/HW7tlp6iu47pEFb8jvIGQQP1gjegKhggJNa26kdWjKniK4/TAuRN64Pz1osv5 bbxci4x+TY0plsn0EO8zkeG1GrWtVTG2Zjkr1AoEPDUiang85UN90dcNvLg8pEawps8KhIRV8ps1 I2r5An5vaOWLkdg61tvn9C56RYqi1K28G+9OSfWxwDsPTUqsQVWiqlSu7Kvkq2rWHES+ylWizEpV vXrYIH1onfpVO3QoX6V1By1hZ+um5fCnSbmmjRuFJ5b725SNGyXHBrgcoto8rj2TA1SlQlNNDmDl yoaHvRpSMa5D07bdYiy2nLPqLRs3blnTy3KYdtZTPrJlg0YtygcqNCxXyeTcrFxBzA+PLKcLs2LY hRr8UKCCTxiV68fIr6Ta27+Ianw/xUE6HtzKe/Cel3r0UkhNb63NrP76uNpxbb1wrKO4xpvZqkR/ hZC2tWtCCeeRPett1oauq96rxWZtyIbEQF/ex+lA9b5HOxztAAGp0lpLOPrx10fR47Cj5Vq3ln02 /wu55SiUiJQaDQiMwBBUcYXGo8XFQcBEpYq1mBS4ljxdtLwuonZVD6sR2ml4dpsBNyaGV23SL/uB 5MEzGoUhrladKl5W/EH00Fb1urWoG26FVK0TET9ywHWByErlpfDMDXZvE9dq9NTOHR5cdO+NHbp2 6l+pvB4S6is+1bJlnc5Jo1Pr1mpRr1rzEVO6yvFra//C38b4NaR2tOHK8dtYr0lLQ1DIZrYwMSS6 nL8Wr1gxOmEzm5tYm6LLlfM3OVyv5a46ZIQZicYAI8UoMrYbnnBuGLXq9fLbibX6ysGQY1G+dQLB uKl/VA5hglyACKnSGr4qzoDG/vcLw/jKxRgdbRiVKlaWA4ixrSSXZ+nRxjA3k6PMPDIFf7vjvR8t GCnEkBs6ZfZv5vf7DLOc6U8cntcmZW5Ko2qtkm59KnPErCF1z3Zo16R/u/rWkAFZnWqxL3oUDI6v 0qDCwEEVqlQIhJaLrx/n81etaNUZNP36zksevGdc+/rdR3Su0zzmusEJlWIaY63F2edYfT2PKlH3 K0c2MawSmYk+8lUyhR7WTe9Tsmq0hOp7mzZxhOyvkZdXVEtN7UMeLZqF1moSE5dQPYRpHhYINo6N TajuZVG+UJ+uy1/RvjDTMMwwn/y2EHPtwVx3o1lXtmcbhbIpWEDN2IOJFSq3xR+KDm2WGN71Z933 S2IvGHO0sV7Cn4nh7ixc/PhoB6AcRFxuCNhGwzAdstn+f5mtZN6i1PYK6ReVXH/tuLiSWXN3YCE3 WWcDqcw9nkAFvxXdpHOD6JYxFZr2SerTpE3uY+mNru/ayO/1cE+IP+ANRLXo37budXUqNO51fa/G LcYvGlWvf4cEn8kn+RMaRVeoUr58RL2qEfVi67Qb1rHPzFHNAxWrm97ygZAaUVE1ylWtWa1CVHy1 6Pi4Om2Gdew+dURTs3xl0ye/uLwee01Vvgsr5Zar5jPcrEqN2zVpHB1TrSqZVWMaN2kXXS1Eb9mz Vs/4zdr1GxLD+uqX9wY105jonTuxjZZz1kDYv8tWSgYu7SctWlZwxYHLVeDuI5fC0pgVXi8ionZl Dw+v2G3Eja26pbYND/HksNCIJjGxUnJu1PWQihGV6yYP6BDWRwtzgsO9LNIXGqLLnWN+dPe2MbU7 j2oZ1T2W1S0JvXiocqPKVWvXCDS/YXov7faSYOcLM33zoPnT9u0ZHdruNFXzOncgLx+Z9q7kd77Y 8u25yRcf8NXybMOpHoI9SH2Tht8GFZO207fi3OQ/3/XVwnm+tPR9SuiNInDZp71HJD63t/9bGM3s qRJiGrXE5p1yDYzRTWrroCYlSPCfqR0Q63JroIHrvhLPU3O9Gt3wF/ipmYPONJBFYXlF2fXBNcBd gM5AH2AYMA3hNcEPibeRbqW9AXhepFBzCT4GdUjc7PJEqiRuo3ZGMcpOvAaqAck0+j/iJqovgXJG i07UDGgK/2gxE+5S4Fts+5o4Qw8ClVyeo7emif8SE8TLtN7TkXZdDTHe3i3qUBHQyuWhQAb/yP6x NER3+6V/iXX6XPt+CdEKc/oSXX8tiPnU1MFKSpDgc9HvuRTuchCoDtQE6rhhCknUQDxKSX/BQwiX 2EEdWBg1YGF2D3Ad8BCgIzAYyABuQXhV8ByRi3SZ9lpgqdCRF2AXIA8At1z2UzVRiZoZPShevHQN PAS8TYP+Iw5SBwmjIQ3m5yHX55HvPYRHot5S4GPt4lI4fsl9C00CCMgEJmLM0v814ul+YxI9fDWE sPfwPTQDiHG5ARDP59q/lYZoTe3/LYwaVEMC7hjem9q6aFLK3dYzgtoa5wFScPJuAO4BetN1/BjS /Quwe+xexlq7l/cPu5fYZ7cyXoT7NNy5V2HmVXDDjY1X4a2r4IZfSr8J6Is6HixV9uHLZemWi3Z2 L89QhLemFleDv2M/dTWwTuIc9KJ22lmK087aXcAGeDjQCMgDMoBs4HaZRnCgJUUz0+5aAugasS7i VDkUxwqc8p5hNagxT6U4I8et62octb9z3e3+I4ZTLQnjXrhb298qUHv2AepzYP8AfMZrE1OwfweO A7b0629K2LbIs5uzcnY9totGsUPALurMPqVwPYxGiRf/HbD/jvLMBur8O6D91wN9XJboV8p9BfgO ytHP0LSrwdfYu/kbVBHgLis0tE9egbuxj95CufxpGsB+pWXsMD3AWtJSx72NHtHeJw73cvY7zdGm 0jztDvsI204PaBPpAZFKc9kJmsOOIP4IZQDLtAsIa0PTtHP0AuKK2NO0VYTTdvYUDWUrUXY7ymHj YGbcAayQp/aFYuAHNv4vYQd4C+wlmcAjTtjDQPpVYYuBDNRJfA6wAFjshN8EjOcD4Q8FsgHnS/YL 9wLZPAL+7kCOE/Y4MJVXhL8GEOOEPQs8xh5De54EnnXCDgDfMOgY7HVgA9L+AH2jEtDViU8EQrVv oIecBQ4oEF3sLMGy7X2If4vdZX8Pfp8x+x0Wf0lfmS51ELSpmXjM/lrpEMWPyzNN6QvFD+ipNFrp C8VLpY7g6AHb7Z0l5z0/bherM7z4lMwjz27+un1RnsM4K9eIOsXD5blpYOzkeWpMpKf0fPtPPb/4 Z/dMnOicheWxxwfs99VZVrzZ2Vudc6t4i/gdMuKcW8VFOJsGOedRLXtLybnDF5JXnSV2d5x38c4Z MtU9F/bSrXxv8Z3gaP1ltAH7uv4ZzRTfExff2+liDfZVievpBpFsf8NfoSyBkeOrcL4CkMvaojvW vsRcqitG0kjWi/qwXpDHXvatgCb3FH7QfkHk2N/yNyHTlSia10Lakj3hCfu8aG+/IUZQK96R2mOu e4g01HcZ4frDdB3Qmj9i5+o/U4b+KnWWYPc6cyn4KWeuW7AY+ozFaOHgo6y5vRzj8jTG5GNnPvPp Omc+J2AMJaZgjsbYN5fWHY1V9kH+Jca/JeJcuPpgH6nrlehZutfe6Klnb3TmGfPqiS+lx/nUPEtd tUT3wprsAXQWP9IGfY+aa+iaLXUPdNw5tNDTgFp6boS/Ji0y0jAm2UB/8gGjPANQ1sP2T3plWqiH 0iK9OvJL2agBHUjKhjz7Jdpg3jfaU0rpQzX1z+zPsfaEKIIsuHB1nMFSfxFehEmk2msceZEyJWVl H/CQo2s0cPSuEj3iU+oEEPbw+9F+R17EVmok5gFNaJqRS42MxXA/SgX6fuhn1dC+n6gKztzBxl0o v4l9XMymSUg/CeNIRmfUm4U65TneCeVJ2TpNbfhoCpVgx50zKEP0kOcFzsBSZ7jxGM6GG+1T7p7b BOjpnoE3O2faacgdIJrbrxrN7Vf0DfZJMRjn2HD3rGoPeejmuK+X55CjY+CMkeeccQMlq70ZZ8+f lKt/C7nE3i3yaBjSD+OHqI9MYyykZDGJ+urrqB//nfrz6fY5PgO6jEDdF+z9IhP14GwWHVHeE+ib C8jqgxLsEXoEiAE68A30MRAOtBQ+2scyaSYQz0fRZj6UqmPOZjky3ZyGsWjYMUXUFHO5E0gF9gOF mKNtwDjgPWCqzMNvse9hOygNSAduBW6DXKUDowHpnsKnYB10sBdjH3iPX6Af+Fj6inegT6ADtAWS EaYBlT3taR7wdAmjj6MRvgnrbS6wjN1Gyew2+3W2hLxsCXg7dWXb7c9YMsKTwZMowCbZB5EuC+k+ QbpwpPsE6ZKQ7gjK+hbYAfQFWou36ElxA90NdzwwF/v4IX47HdKx/+sTibwdiTyNgC4OVzLW0FYJ 2J8f62/QG/rndB97BWN+wX5LbIS+GKBIlGOCK4ok8sG9DXEnsbdegLuD6As5CkDf+ZZq8MeoPP+D TDADGhp1qKN3GNbWBQr1tIDMtsS+9Sz1Zt9g7k+gjuP2hyLF3sd/sT+DLI/jr0KXTaT6opN9EWU2 AroBPtR1EHgHOAz/YEC2Kxz+s6KQBrE1kK8VGO87ycM/QrmzIYf7qBfWQwP+MZXjX1Ft2R6gPX8M +8tjZAE6UAVoDgwE/EB1tC8Z7bsF7dP4cayvLijzF/K47eul2gcEsP4utY8quFzNbd+Nqn2Q6QTo Dzr0hvWQrSKazI7SdLaOZrGDtJktw/wfpflwL2H7ke59ep7tpqe03bQNGMUT7DPI62XrIRdF9nZ2 1N7N1uG8PYhze5n9I/yfs4P292w/0r1vn2K77aPIJ7Td9kqc617kjWR59lesEPIywf6I3Wh/y3CO sVT7JLsP7hz7GNLNRronWR50wkLI1AToNzdifUylGSyVJrD74M6hPPZZ8W4ejz31bmARzvPOLg+3 f9AXAOeoj4Nl1F4/grPnEOwvDyXra6kN3G30PPt1/RPq5L2NOul3UzvPHzhXLlAXoLsrq42ANi6u AwYDsYAAdBeJ+i/YE7GvGetpsuiDdBr2b5Qj9Q2pB8gz0+iEuHH2K9BnRmDNLQDuBjZKGJtoorFJ 85aw7xZaYMTRrWIs1dG+gK4DwP0/hBbxX7m/kSh159Ka/2y/DSDM3gm8gbC2OFPjcaba/3TnYQSu jZK7CaMKzbgW3LuIng5fsi9xTrW2X3P5TTcMbL8NvFUSVup8iefH7BXAY8CTwDIZ7uiQZ+1fLts0 9lagCNgMrHHCzv8NSuyD85fQ1+VBkl1bwJAs7rE/wNi3+i/cnTgodd9B0BFnXAnoMWFUA2fCmVL3 C5VLIUyG6ZnXRsmdgD772nDvASIk/yu520Fj+Umqyu4hCxgq7Vm9ArVwcbN4AfuSwgjoUFNg40Xj TGsr7djSNnppO1zkkiXaKRgbL4NXoD7cR+t5ZXqX30Tr2SbYQAtoDZ9GO/k4WqMV0RrsG+PZKfA4 yM1SxMn4x+ltGSaZW4i7B/tdEX3CJ+OcrED7xeP0G3sbZ8DztIfdQD2hi24HTjDYOEANrJ3KQBO+ QxOwCZ/jFbXyQAL30x7ut9+StgbQTrM1C2gPlAdasXHF3wOfsdX2pwpaXaC7tg/28WrkKY3p9kbg Jx5TvIfNv/gG6o1GnnnAk7xF8VcOKhZ/yv3FP/A5xR/ziOKD6ty2u/A59k3AH0TF+9HuibLtLta7 qCyh7ZN1ocz5pIHvQ1uaAl34Um0/X8pCkH+ti8YumkigfauBXbIuMdb+Au4w2IRH+BytGQD7UJaB vXAp1qNmzxAaveN8kbdaywEe0/ZpFYFGGK+NwHuouwfKaAkMgL7VUrbLwTfKrkN4Rb4WZ8dqrSsw 2jMSevpI+tozUiPwVuAEwpYbH9JHxvtaNfhfAn5H2FbtpH1OO0m1tAP2nygrkv4gBjTVztu/a+ep hmYT5ogaaIvtk9piKoewSKCPZtsHER7OwMxGuhHkATpqg6CLDqJG2hbwFhqsvWZvBo5Ax9zKa2sm eB0Ayxo20itaDVFdGwosAMKAvsBkYAPQCpgA9ALuLmFtdPF+9P0b4JQcCz0Je182dNo50OuaQjd5 k1Kc+/GfET4NesFBCoE9kwZuz5+3r9MLYFttpXZsAI2Bnd9IpFNzTzmapSfa7Z3990YaodeCLTgZ Ni3DPg67FfbddGnP6Pk0Um+OcoejD5/ZP2LNh/DvqZ7UGbzfUFtvK+jnjaidPh5n47ewjzrAhsG5 gD2/jbO/X+OuufT9v15H3ctLe7rkPEAdnpKyZZynFtr1k31M2tmXzx17rzx3YI8/Ie/rka+tzCtm Yu+XdltrjAfqku11bHjo0dj3Gzj31O65dfU5hHOkL+Imi272WOj2LYRpt4QOukLcb5/SR2HcYO9D 56sp7UPYZyliGWyK9dCZZJvkG4YDe/EV7xamvdPlTZfPSvt6oMIV7xQl7xIO7InAZ+hbDPp2W8mb A3TO5XyMfdRFR6CttEtLcPm9wT4DfP2X/nVy7dUr3hLste7bwael3hHeVu8H9q9AP6CF3tr+BFgN 7L80jy/TAmDgFe8E7ltBqXeBHnwe1YcsxsG+H4I6I/Ux6MsbsPGO2Iek/EJGz0FXbS6mYyxbU4wY gHP5WffOtyUNdO5whyK8u/2dvLtkM6F/fW+/IO8i9aXqfpG3wHl3zLkfHCUqUiXnbu0obMtCew3G 6YJnHNbCb7D3OqAdKBdny/Xu2f7XO73zsA1K3VWj/AWOTYq6S/QBvspeIW1PWa5zb9tKlVtat0Ad bzr3sG6ekrvPS/WgDCffW8gXQU1lm0vyX32fKnUF9oi9S3wHG/J9+3fjVrQNgL2ei71Fc/o7lfKh v2xlKXauhGhD7dl52AfFVI3Pp3VS1+ex0Llr2n/yz6FzvkTTpF3qtjsGKIe+Tpb2sas3nQHGue4R l3UmeyBQs+R+XZ7rl8agFWwKh+2bgJu1s8UVFOxMde9snwaGIOxXFwOAVo4tnnPF3XNF5J8CpPzl btm9T1bjWXzMxdfuPfKdpe6UZzr3xrvsArareAewDuUNB+oBSaXucEP4DvvjK+5uS+5vL93VFp+U 7UFZu5w0UneT99nybnqelBf7RcTVERMxjtHo53XIc4pq8t6wc47Zn/F+FKsvwZ59hjo79zm1YQO8 RELURRtWYq/q74TXhe5WTXSnGL4Yc55kJzrvVvWpHptMI6HPHRQ6xRvzqL94yW4ndTgjCvray7Dn 5L1QLvLJ+77PqaO8wxHfK12O/4m9XL7TzIbOORv2y51kefZRUy90LP1O7Bd/UDuck/GehdgPoFui nj6OznitdyJX/3Te7kre1XT3Lgngs+3zJWXLOGMd7J4V9jHnHeyS7mqvkv1kYcXbUNcA5Cvn5I+0 n3HeuFYSd9qN9jr3VK/hvDHQP3kX6uq+V7+dYZ9PQNxS/hJszQv2F/wWexZvSrdgzt4QK21bxGNP m2tnO3dha7APRUI+9sC2lvZ3U/soawQ91QBWUWt5H+O0tRXKdGDnX/EeOd+e6fLky3q4Hc7nFp+4 4v2x5L3RAfI8ZD+CPkfJe7mSt0Sh29PUeyLk+YJdmV0o/lPez5Xg8juivRFY+pd+q3fCBle+Edpz rnojLP0+CGDt3lJ8DuOyFMgDFpZ6B2xc+i3QufcreQO8/N4Xgb6sQjm2TIO4SY7cXIDOM9AOQ3vq oB1V9QS0pTvaNw95IOuQ53PCh/G8+u2tBBOv9P/l7e0a+DfvP//mzccoIst7FvvYPtgRL8B9Gu7c f4/SNsg/4Yr0/VDPg/DnuDiiWMbplgvYN56h/1D3xP9aG2CHJbr7fZx6f7W/57e5+30/nCdfwPY6 hr3Kiz0sBTq8vHcdBjSHjPa3c0Rf952yL/avjymLf0oD4Zd7aYwEy8A5JdEL+jLOPuzDrXgrSoTN 5RHPOfv79S7kGdHE2evH41xtT9fpO4BnqJW8/8cZt8fBBw6+Av5kiynIFtJwfhhtOyzLtj/Xjtnx rJudpB0jkz1mx2C/L8+2UXfxGFXFOu8sOtIw7O2H9TP27/wN+zBfT9m8lX2cfwLg/OUv2EVSxwMW 89vtMzyZPHoDGsJPQ99riX1pCPSSG6BzPGXH8g/tA7wd1Rb90ffbKVLmMZ7GOXyM2nsGUnu9PI3A HjJKX0AjjH6QzZ9wVm3HWmhKbfhvdjHKG+agtr1Wn2TPdHSLWOzJcv8egz1tDMY7hRLkexnOy/dZ tv0uP4C9/5xt6xvs06IQ4/Qs9vaXoZ/Pxnzdi/GqQ9cZd2I8tlAE5qQ70Jh/iTV3GDrRGfBQ6NZ3 QffLJa/+A4Vi3f4kQqjQaIszIcf+hY/E2mwMHeGwvQN2VwPoZOvFTVQPZdTTn6IC0ct+U9rUogp1 cOzq2vToJbt6E8r4T3b1A9AFpW39Jz3j2NfStnbtasemfo1mwaa+X75dYt+Z5bx/um+fbDNwM3SU bCqUb6DaVBoh3z6vePdsibif6AlgrnwDvfTu+SVNw3g675/sGRrGTtjn2W20kX1FC/gHtIm9Ts20 qfbnjKBn/26fRToNaTqz2+yL7Kj9NP/Attnr9jQjE/v+GzRL7MLaaGA/5ymwz+mD7LOwBfL5aMzd dcCv0JkbkIfnYV5aQ0eNpiX8gL3beAS6RxZVYsuokkizp4kDVFl8DEhdazl0h2dhmzyFtXQT5Ku7 /YXxBtbC/XJdSt0GZ9iTOKOy7Hj5xiwaQh8ZBP1wM5XXIWuwx5SeeaOzRt+FrhHLJmJNjLD3YE0M Ehuh19xnf4hxmMna0FKWQ4+y72iJHEv5pqztQH/Vu/KLWKe3aOvoWYzvfO0PmsoaUHVtG92jvURZ rActxDjOlWPJo6gc8ACwlJ2m5XwTymtDGcxHNVkFeoH3pTt5I1rpzMtBYAf1QXwOWw7soUz2BPXi lTEnv2PujtN98i1bvldrZzCvfmA96pFv1SvpAW0T3cE70x2X3z00Dfbvn/KegC2hH4HdJXetojf2 tN500LmLke/Y45w7mWgeUfwLG1f8Ixtf/DVrTQ9LoIw7gOlsNd1+FZoCC4GN8m1dvqE7b+aynjDs DVdBXH8lENYZ/HdIuBpILzn2aiC8OvgvQHgn8LVwdTv+Ll2nf2jHtcLjwH/B/7Qd/1BuNPgv+If2 9QZfC/+2HX83zjHgv+Af2tEPfC1c0Q7I1RgJ3qL4E7FU88m3O/ivczEDuIfNt99h4+zRWO+j+A92 Bp9T/BlrTlsQ9wdwHJgHJIlEu58EZzhbaxM5iFF3hJ7y9A4wgv1q/8K22b+zI/YpnF1Pw/2N9jnO lVKQb+qlQXTxUQleF+WVRoyLvws/dRVKwuV3HhVRl7rztBx/aVS8CleVw5qQDoQ5dxfye9BhmKMS TqB7xElbB3dx7lAysd/fRLX0V3Fevwu9vynOrE7Q0a+nG/gi2O6L7CPOdwv77YvGm4hrgz25PWxS +RacBntY8UPy+wN+j/2F1HP4bvs7cQy25vs0mXfHfg17X/S3q4qD2Of3QfdW3ykKxfaD0G2zhO/i BanjOjbA25QB/aGhPhg6QCHa53HuFuLF5/Zj4vPiUUAj4Dj8y8HJQBPX3wWoc9Vby2LEjQQaAydd /wi3jDPGU/Z24DHjqeJRQCPgOPzLwclAE+nnPxdv4z9fvBWYAPf2Uu4xwCDdX/yq7r84GZgAdwVg O9yTXH8VYAww2P0m5gWE3wikwW26/ptcv9/A+Wq8XrzV82ZxIZDlubV479V+FlW8k0VdnAlMgTvy Gv7xQDKLsgcDU/Xk4l/15IsbgZlwHwFvAm6HezGQLjoVy+9s0kWdiwEgHngNOIcwXdShkcB0+b2N nn/xGSAf7ibAIbhXu/6mwIPAaPfbnF+M9sUpQAu46wP74U4Dmkm/p4v9p6dL8c/esOJpwADPu8Uv w/873NNL/Je+q/nfiJJvdP4Ol77b+Vew//yvAHq+yXrZdwGzgCz4fa5f4kYgjPUq/hWcAvwG3ALU BTKB8f/xO0L5vZDEld8JXQsmEHJVWMcSd8l3RP878F99u/u3MPxA5X/GFd89XwNX3kH8z2H0ApL/ Ge53Rw8C+cC98MeA73P9twGRQIzznUsYdMcwW3671QkYC0z7T99Jl9x5yDsJueeCJ7s8BHwjON31 l8TnuNwN3AMsv7sZVCp+jMsR4ETnLslH/cGJ4IHqG7n/dTAWAyv+Ge6evwh7e5K7xx91/cklfncf 3mqEFhcCWfru4r1/8V+5jw2AOxH4vfQ+5p4di3BGJLlnx1HXn3zJ/y/2c3c//AV7X4qz/3UtTnT3 wzSgGdz1r9Y9+NKr9InS7lL6hMxTojNIvUD7jUaVQL+HSNxHw51vLhfCbs+lFp7q6vs+cQpr4CXg Kbper0/z5duD/iE19ySBe9Io59u9M7TA/ZZgCPSD3YYO/zuwe+Y4aGbUpcES8vtA+d2geJ5a6En2 Rox/c/0G6Bvyu77+l9+m5LuW/HspektKlij51tB5iyr53rD0u4z8/k99N6gwh9Jg1zWT3wfyXNLE bvddJZt8xr1UwyDolC1okSfM3uipiDaUx/5WgebJ9z69i71RTMU4XUTf5LuIAbv0EYoznne/oeuN Pb4tUIW6iwegB82B+1eK1U+BZ8HGhx4k72b4e1hH71FDwZxv4fqJIPWBvTlIGLBTDkKHOUhN5Hd5 Qurzk+xXxWCEPwj75RD10Y/aJ+VYwc6lkjcUfsy+gPyREiXf87nvHyXvLuo7PYBPt3++4pvpQ1RX fiPofHtnwN4uVvfzTtn10OcCSufbaazRyH7V6Ad9vT91EHdSb3l/JXLQtjPYu+T3ieed7ycJctLA qOp+L9mK6otxgBdYhX3kfYrXWyN+DtVz9hqp28k7U/XNw1gx3N6t96d8kQF9rgkwEvMMXVFC7nvy O0znW6vV9hrn7338JL+FpGnGwsv33/Lu3Nmbu8s3LYpxv93kzn13yfebJd9mSj1Tflf5KWT7U6on v8tEeV3kd6Dyu0seaZ8WIzAW8p62GoXrF4AZ9ADm9wHI4RojD2XthM1wFxXINwWxAO0i+TezMQ4u sxfV/9xAG4qwAeBtwJLS/ysE+ysgVgTkt8kYw8/tc7z4YmPo9Br03MOOrV6Xpoi1wDp6BDb5y2we efVImiOGY2+Va2yj/Qvy+qVs6bMozjOSmhvh1MSzhOoaNXFOy3frM5TvPUa1xK32E+Jl6oq9Mkmc sw+I2piLdpQiv8szImmEPpl+0pfRT873eZr8ro8ai0HafjGIXhVknxGkvaJQ4rbPeMrR7eIGukPW g3bUFivtnXoXrD0P1uftNAKy1FPUt5/kI8ni++wiMZCG8zaYl9q0DLgb2MCGaL2BoWwIxmsI1Wer 7WPAOfEdpXlOURXPAfus52H7B88Caoe+Ndeb2y95GkE2PrR3eZ5F/07Yj8rvvsWP9gXvGzRY30Ip SEsyPdZRir6DpulcriN7o9Efa5LZu4ytWFNj7Uflt9Dy+1TP45CbIsj9SCKZnrfAen2D+up7nTeG 57FnxOuD7O+M0xTPF9urnW+8h9P93kE0SK9NA2RaCUeudzt26VGMh67muHig/Dt8LJnKabsx/1Ox p/iLD/pW0E/iE1rAPqFZEnCvA+fJ8P8E2JNjIUDnUXY78DEpTc6ev7SUnRhzpZ8NK3UOvKLsWn0A E2y6/TaP0cL4Uq0N0uzC+REk+S/nEY1ndzjfk9O/wdU/pduDcfhCVNIacD9Vhv+AapvGeA/N5N2B BXADbAKt5JlaPNIfAb4HHnXXyVfK7ywtr74IZ+6i4gLgD5Fw8SfgLGzWYcD4v+h6Lv6ib7nge+wT CtT3Cn2ilN6A8U4BZgA4FS9uld/KA5DYC62AcUB1oBnQGEgFOgK3Ahj1C3eXYhmfjjJuAyIVit8F rwK3V3DqAi7YChcvuJitIP+dRwePKlxMUCgep+CkS7gKPqATREbW5QduR9nvADsQ9ibwMfAa/B+A nwJ+BCBX579DWBuFi3NV+otNwXtR10QXnyhcPKrg5JHtbut+zyWxUeHC+y7qwd8c+Z53sUPh4msu ML4XuwBZSLsLcU8rXCwB4i68gLC5Cucmo95NwEVgDXASYRjT818gHeT5PHbfC9iOzz2D9COAx4Ex wLMA2mNXBg8CHgYw9sUrgSkA2lKcCWA3L+4DYGe5KPtewS3jZ5XGlv+CxyzgbQAndPH0Un0pwZeu /Lzp/v0ZKU/PAYeAmwC05eKtSr4uMeSkeI7CBfk92ZNXIdVFljtW7vherHEVfC4sF+EKFy64WOVi tYsTChc9gPw+balbn+l+0xbuylF9IA6oCmDdXsDcXFjo/p0kjPXF9i5WAMuAz92xPVCqz1gTF1uK hOL2sAs0gAEp8jtR/o7d84q/r+f+XUDsgev/bwI6WWv5bTf1tf90/5b2gDL8/wUsWIYy/PfAU/7P Qmwrw/8Uep//+zDu/38fPOvLUIYylKEMZShDGcpQhjKUoQxlKEMZylCGMpShDGUoQxnKUIYylKEM ZShDGcpQhjKUoQxlKEMZylCGMpShDGUoQxnKUIYylKEMZfg/Co0oNEsLUhh9Tx5i4ARKIbIqVqlC wvknWhqwKPzmJH/Snd/SrVHA8Uk3o8qU77o5taN7XLegOFruunWqSjtdt0Ex9JXr9tBEraRML9Wj gOsOoaA20XX72Aptses2aZho4br9VE/c77ot9rDY6LoDlOXpd+mfl2ni2Xrp/zfu8fzquhmZnpOu m1MtT7HrFlTBG+K6dfJ7a7hug8p767huD7X1tnHdXqrk2eG6QyjMO8F1+7QB3jtdt0n1Qz5x3X6q 5Cv5p28srY+vkusOUAszFS3RRIg7zsqtxlm51Tgrtxpn5VbjrNxqnJVbjbNyq3FWbjXOyq3GWbnV OCu3GmflVuOs3GqclVuN8yoKUhNqRI3xO0h9KZPS0MpcKgDGUiHCOsOVT3nO71SEZMKVQw0R05Gy 8CdIgxA2jsYjrsDxZYAzkHoifqcjZWfky0KaMQjLpE7In4XwIPVEDhWTdo2a2zh1l84Z/Ju8w5za CtyWBak56myJ/lyZu8Gl3KXzXl1DptOHVKDQ6W86ys4G59NNCJMtkzHjEXrt0Rrn+CdgvEpSp4Gz 4U9F2zKdsWlIfZAijeogrIDqIk26U153J28uyvn7VmUjPt3pr+xpgVNqgePKcNLKGsciNBvuLJoC 3yS4ZItlmgkosRDhsjbVzhyUlonf45xSct1SC51eqzpznPFOc+Y/xx3phu4MyLoyHKmYgPAMJ0e+ E5LltPryOBdQvFNythOS5ZSYilFR4SW1ZKOcLEfG8txW5iAk26lVlSn7WViqBbLGPKcvSkJL5FO1 XdaUixEIov9KRmWr1GykOe3PdHpceEmC1ZipWoJO23PcfqnZHOOkvNzi0j2SozbZyad6fRP8Df8i xbWd0rKdEqY44zDBXSulx7tExmTtk5xRTXXnJd+RBsmqRjnXQVfiVG9UG8e5aeS6mOqWXoheqBma eGmWUh0ZkRKefUW/SiQ6DS1JdepPc+tv6IxUIWpsg/MmAbnln4aOzF25Hhq60p8A9xRnhsY5JeWh hCkIlSWOdeZLzuSVpZaES2lWI3fTpfKSHdlVozjF6X2BM1qFzjwXOHKpcgedcZMykuH0MNOpI8Pp 4xgnb8lId6WhWJcd3bz5pWKUfKU7a/ayzExy6kpzZOpa9Sq/TJuGcZ7grNr0S3OQ7sRLKVc9KBn3 PKenOe7Iq7IynN9Skq7ut4xXElsHueROItftmEs1XatVOX8p+d+P0eXSS3aNoLvuC512p12x/v7a 95LVdnW72pYaAdkT1Re1C5WcPPmXdrR0Z03nOGs79W97qsY59YoxVSsi1/2teqXcExzJm+DkTHfW h+xNxqVyZMosZ4390wz9r1oXl9dEgtMauQbUztjQmas8mrwq2KRR4ybBvplp+bkFuWMLg51z8/Ny 81MLM3NzGgY7ZmUFB2WOG19YEByUUZCRPzEjvWHn1KzMMfmZnXKz0oM9C+FJu5S5TdCNDJaKHZaR X4DCgs0btmziRjeQ0Sq2JENmQTA1WJifmp6RnZp/UzB3bLBwfEapZo3Lz52QJ4PTcrPzUnMyMwoa 9pmQVie1oG4wPSPYPT83t/CKorJz0zPyc4IFqTkFQTQ8c2xwbGp2ZtaU4KTMwvHBggljCrMygigz Jz0zZ1xBEO0rKMzIRs6cdFSRn4NGN0QHgmMzUgsn5GcUBPMzUrOCmU6bC+KDBdmpGJq01Dy4ZZbs CVmFmXkoMmdCdkY+UhZkFDoFFATz8nMxoHI8UXpWVu6k4HiMaDAT3UgrDGbmBAvlAKNlyBLMysxB XejmmMxxTsGqosKMyYXInHlTRsOSIa5dEMxOzZkSTJuAWVHtliOWkzEpmJ+KvuRnotvImJodxMCh GpQ4DiEFmVORvDAXHZoou5QanJSan63qkgOdNj41Hw3LyG84vrAwr01CwqRJkxpml8xDQwx/QuGU vNxx+al546ckpBWOzc0pLHCTSvfYVDTuJpkuOXcCmjglOKEgA03DrMjoYCpGJCM/O7OwMCM9OGaK 0+iuQ/t0RGy+48F4pU9QIzNpfGba+FJ5wZk5aVkT0pEVPUjPLMjLQgWy7Xn5mUiQhlQZOYUNgyV1 5+ZgYOtk1g1mZI+RmS4XlVOS+JotcpJL0cAwFRTmZ6ap+btUu5y2krLaOg2ok4laIEJy8eRLQUvP nZSTlZtaulK0OVW1FBOB7uaiKvyeUJg3oRBiPDEzLUOmGZ+RlXdVh/7NXDgzkZCeMTYVwtgwtSBv smtT2aeBqnQXXeNnbQjfzJ5cF94sYjN7ZF315qA5ivLXVWsJullRnqKR66q2Bo1QNFxR9LoqbUFR iiIVBRVFKKqlqKaiGoqqKQpXVFVRlXWVu0Vs1r5X9J2ibxV9o+hrRV8p+lLRF4o+V/SZov2KPlX0 kaJPFH2s6ENFHyh6X9E+RXsVvavoHUV7FL2t6C1FuxXtUrRT0RuKXle0Q9HWdZUkvbeu0lDQFkWb FW1StHFdpXTQBkXrFb2kaJ2iNx3izdZFNAA1VdREUWNFjRQlOHPLGyqfta5WAsh0iJ1fV7MR6Jyi PxSdVXRG0WlFpxSdVHRC0RfrajQFfa7oM0X7FX2i6GNFHynaotriV+K2SdGHij5QtFHRekWblSg+ oehxRSsUbVC0XNGnih5V9JiS1vsVPaDoXiVgdynfnYpylQjfp+huRdmKshTdpOhGlX2oomRFSYqu VzRM0WxFgxUNVLRMUT9F9ygaoKi/or6K+jjEQ5Wvl6Leiio7QsQqKcpRNEhRRUUVFJVXVE5RmKJQ RQFFliK/IlORT9EQRSFKaLcrqXtNSV0tJUs1FdVQFK6omqKqioQSN67E7WclNj8p+lHRQUW7lYTs UvSmop1KCt5QtEbR84qeU7JUXU14CzU8zRWlOa3mlVUjKimqqKiCovKKyikKU6Sp5pJqrq3ooqIL ig6o5n6v6DtF3yr6RtHXir5S9KWi11WPdijarug1Ra8qekXRNkUvK9qqaJXq9LOKnlG0UtHTip5S 9IMakAcVLVI0X9FcRQuV6C9QNFXRFEWTFU1SNE/RREUTFBUqKlA0Rq2O0YpGKbpBUaqiZmpWmipq oqixokaKUhQlKGqoqIGi+orqKaqrKE5RrKIYRXUU1VYLiCkRjlcifEbRKUUnFZ1Q9Lui44p+U3RM 0VFFvyo6ouiwol8UHVL0s6KfFP2o6LSig4p+UHRAyWcDJXXxiuorqqeorqI6imorilUUrShKUaSi CEU+JcIhiryKPIoMJcK/K4k8rug3RccUHVX0q6LDin5RdEjRe0oi9yk6ouh9RXsVvatEcY+itxW9 pRZsnPKtU6JYpOhFRS8oWqpoiaKHFb2jaLVDXFfCt1jRLEUzFM1UNF3RbYoylCi+pChT0XglL2MV pStaq6iroh6K/p/y6zy8iTKB4/i885ajbZJp2lpsSzpVOcTooHiBRRkKhEC0B80LtEiLCIIuR0w6 VguRyrGiHAVE8aSAeI7aNLi7YVeF3XXXPRWvvXRXvM9duqvuesdf+vNP/9fn2Tz5zmeOJO287zyT tpZMJjaZRNaTtWQXmUguIDXkPDKBzCDTSYiMJ+eSobyEh5DzyWAyiOQRSb655gWZSqYQjaziNZgl X3HnEm59Sb4gn5PPyKfkE/IEvxEeJ4+Rn5G+dOkmkBpAT3ICVg8gquynimrN//nC5n/Rx96Z5mvo VXTUU2f+Cj2Jfol+gX6ODqNDhbPNJ9Cj6ABKoz6UQr3oEfQwegi56EH0ALof3YfuRfeg/ehutLdg qbkH9aDd6C50J7oD3Y5uQ7eiXegWdHN+h7kdbUPdaCs6KJtkg10w29yCjc35i83J+XKWbMC/3qZs pGJfumQcTnov2ZMuzg1BD9lOtqX9NugmW8kWsplsIjeSG8hGcj2pIxelMbgZcSGJkJlkBgmT6SRE ppGpaWMamEJqSYAMJ5WkgpST49OYy4wYRsrIcaSUlJDiNGY6I/z2HPgR+hD9B/0b9aNj6F+Y8VfQ P9Df0cvoJfQ39FfM3l/Q4+gx9FN0EO3DLO3ERGTEbRzsW8nlHJilZAm5jCwmi8ilZCG5hCwgZ5Oz OExnknHkDHI6GUsschrH51QyhAwmg3IclPWyLl1jnnVI1mlTURTJ7GHsHHNq6ODASnFZKCMeTpeU 4k0PpUsqgUseTJecBB4g95P7eOL3knvIfnI32UVuITeTnbwebyI7SBtp5fnPJxeTeaSFNJO5ZA6Z TRSJkiYyizSSBlJPguQUjuIYcjIZTUaRkWQEOYmcSE7gQFcTk+QRSXQiiGavw1WaRV+hL9EX6HP0 GS7LT9En6AP0PnoPvYveQW+jt3B5voneQK+jZ9DT6I/oD+j36Hfot+g36Cn0a5RBP8El/GP0I5QR vZyRR8huche5kzNyB7md/JBsSPstsJ6jt46sJdeRLrKGXEuSZDVZRTrJNeRq0kGuIg5pJwkSJ1eS GFlJVpDlZBmZTGxO2iRyATmfTCQ15DwygYwn53IKzyFFxCA+4iUeUsg7UgHJJ0PtsfCfmJE/oz+h F9EL6Hn0HHoWHcEs3YSbzY6BG84POPhX2CtwHhvkSHO9tMx1wjLXhrvUdW6XWhNOqmvdpCpM1iQj SVmYrASrkm7ypeTg1eFOtcrtVHmdpZ16wTXhDnW126EKO4TnqrCjos4bzkeOLHWiziKn3dnpvIAd Q/Y7jzpPOjKTPWwXO+NrQl3ONkcvxXFdc4SR213tFPpC7eG4SrhxlRcfEY/G5YT+uNDtuFgQj8V1 vOhAfMTJodyLK+NlFaHquB1viMsrwytVzF2pVoSXq2PLRdHkAqm0anQESc2QUa1bRu2sri2LLdPz r8DZXm4tUUvdJeoya5Fa7C5Sl1oL1SXWAtVmzVet7nx1sdWi5rktqtmaq+bg9bOtqFJuVDVZjWqW 26jqrTpVh/0XWRF1oRtRM62wmuGGVUNYTLdCapo8x8Q3qVaFZ6yqq6q/Kq9wQSAW0GOBo4H+gIwN 7x+ur6kURsWaiu4KaWChc1FulneX95T3lg8yBlakJ1bcVazH/F1+/XS/7T/iP+rP0/x7/LrRbfQY vYasN9qMY0bWyOs1RK/vkO8Zn6z3tflW+qThy23LIttnnREyvHbE9I71yoljvZO89V7Z7RW21xoX sr0jRocmeeo9bR7Z4xG2Z9SY0LGCbIFuF+CAnT/qNCyGVYY0KaqF0EQRkENzcyGOM3GT1w6UiUEC fxP0RZuCwUhmSHZWJDW0YV5KbEyNbMot7caW1OCNKU21zJvbJ8TW5j6hT4mmSiONLdzesGWLVhuI pAJNc1N7As2RVBdW7NxKFitaoK9Mq20OtiacRDAYTAQT7Vi2tyawp93BcwCBJXTac0faE1ruhd/+ yB3mBwUTThvePbAvkftcJ5jbypX7Gd/zx/ftNxTf9S/wf/04vq1V+xrnDJXUCmVuZHN0cmVhbQ1l bmRvYmoNNTggMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGggODU4OT4+DXN0cmVh bQp4nO1dWZMbx5H+BfMf8Ag4RGzX1YffZJs6NkxZJrlaO0iFgguNRDkGY4mkbDn2z2/lnQVggMaQ G2GKkB6mP6K7jsyszKqsrKyfrroF/P/406uwgP9ffX+V+kUZ+sX2aij0dINPCR4S/3159d1vrv5s H3frPI1dmhb7D7XE//gkplr20++ufvf0KkT8qP4ZurSOixzWJS6ebq+eLcOqX6bV14un/3n18OnV T7XUqSvjWD/Ye3i9ub0K/VS/L32CArZXKeR1nwXfKM4R/tzI6wK5C1DLMPXdMC72H1wt9Nl2r1TG oc++FoWulhl94c+2e6UK7oY1MoRfFzi7lsXf4JW+67qy+GctZVwPTd/KOjgSPbl/ma4nWKb25H5l EqOhPOt5HO9ZnAqKp/TbFCh0NEkkOookvg0dicVGR2H5Ex1+Bz6uAy7bgAvrLtOYw6cY4zqPlcvT uqdxd7t60K/zMMZhef3Lm5erB916jH03xeXfVw8K//KjDsyg1R4oPQy1qEWJY20Nlf7Fqqfilp9p EYc+nLo1KBz9cvlgtXj6tzvfTuspNvV8Uhub1t3y1WpchyHV1m+1vu5Yk2MY1v3oa/6t1Nxqrj1C gv7yTXi4mta15pBrpx8M3Ir/Wj0IHT4vHy1WlY2VnP1yUVvZd+OwfBZWtfoSw7j8eqENrhWXOytm GkNRXPFXL1a1jtTlvLwBcvdTGZY/XwNBqD2vm6Lv7lMYxnUlRReBF0CK58tjXBjjOvTu9We+45/B Y055mJbf1H+e+J9fbK+PyUFMOGp8mc+X3aowjZ6vPqqUq49DXi6OytMY1jkv8jit0/G2fY4MqjTr l3+oxKtUTKWWnSpBq+jX2sMqu9pn1Fn5E47X+THQYyp9Sa5Oe3oMkhRRPp48qU0pxNvny1hfkabM aUkfRaafHeVjrlx3L9++PDr2ajOjf/34SJ1gdNnbz5ZvKgenkLqy/NeP1x+B+ENHF5UNaV3/OS9f fPvtq+vXr7/+aFWHJjJBh8txnqP05qrZhuPkf1grpYHxaSX1yPrpyZMAwwjY4lvzvE5KyjyqU/2p l9FznOg4eNzbJ6iekI72+nGqD/DH3p5B9evvQShJ6oD8R0dpCW35R1sTS163jfkB9QEK9e2bFbQA 9ON3R6vska2+lI/qKCFdN0csqroWTcAC9hGo49PfV8avx7aAx59DB0A00/J339ye0ml19lONuS8A ZDugHnOq5kQvQOtnsCX3E+64CvGAcGcn3DPImOrol4H8DESGBemkxMDI6t3nxyWmTsuqjvGV3SW/ rBi2LzbHBXacXXcfgE3ubRCXYx+MbUsb3p7kaBrTKXX1x2qAyFj8CSQe+fkpSSCai9+jBUNh/Bg+ o3f/WG0FPX3ztD6SSLjZiKvMPdocxr73xrDM1oXYuaHT0frsC5hNkun2vbPG/bUyk56+hFfp0RrU 0FUl+Kl+9PPt7fXN8XHYNW06IQbIF98DGOdfg9IhUs1hbhlOTT/ekjduuLs3D0uEo+piVeIaxs3z ZX8eR3NWBfTsDdjLWnScQfsOtYd+fWL4o230dV3fbkB/ofS8+PH4DHKCP66qOrE+YiqpW6nT8btr CBeriKpnbypoE9EHKdMMso7KkW2So/Y/Vg8yv5tXQzOe/IzuYInOVP5YywncsH7llF87RZk7Q6aO h0HVj8kX6vWZU4Euo2LXco5ztooBKHZX6y9AVG6u9iff0Z87ZyvNAqe/e9FGswjX2sXzLqZ5C76h gJOgaTuwb7ft5d68qKTcn67R0OqwyKowXEUHR+6M5XmslvzAJMLY/xdQSp1XU2Z4nFj7ZZ1TM48e zlx4F5zS+tb8tiozknXt5pM3oPUTjL9XP1glt9/jcr/+F07M3uoKcIquFlhyHxHQCfSUb9PXIHWB lOmBdcgcevdZlUs7c0QCEgtbAoYeNc5iJiXjAItmX49R8q0JWNAV5Qv3TovTYg2LhQMznJ9vQJJI Vx41HbDgHJtSXr8RPtzdI1Gx2+sXt6DCB5rp3/4ddCt9fGreTs0PpYP+Y8VOvd9+e/3L9be0OId6 /udfZ8lESIM6vo+NwW8+AxE5MghVJF0p9xiMqRIo1DVKp4pRR8lJ32UaK3HrunsE7bW9ymMAxz7B G4ERR9SNvCxwrh+++Wy7WyjDrupDq4LRXO+4/2q7UyKhNFYDoOULOqf8ENsuwIpe+jDLTSyFuFZC GdzM2UX06CXp0APOncEl6swihMNchFDnnCKkI15ooCciNecUQpzQMoQxUMRRV3iu9hYW9gn3AHiA 9zLZMq/4P/IxLZEjWm0r5egEKNdxVs2Rr/NFrWn5rVXnHs2Zff0atDhqntd+qnP3dCVN1K66lI55 T30dm53aFpxuBsrOn24F2u7gy6sUC/QJ1sB5hJcr7mm9HXH7KgJDKsRnmi5OhTYyAOcRMW3bRWwu YNyQSZGWYRV3mXGJ2Dn52foKOKKTAt0HBBO93Y2MO/g9rUcqLYDwg2+NUSJI252xA/kAHCLjHiqL 8M+EYZky6WbgRHSIa4GZXifNFyYkQ4CXAKJdBdyPjJES6LpFjCDqc0fjC15EEjmMBXXwPWEkccfk l3Z0DHCMTEJ/6kPFRfqYEcbRkWCchPyBRtzI5Ef6jaNQPwBdATfkr1jJDwJUh+2YHfdQBRGECfY4 CP2J9zTKUTYq6IX4JDgVE/Ejqh/ATubGnmlfIdBgLEx8FtmxMPEj+WJYwSsiTsSeiKAvq9rhwkiF al0DUUFaQksea+hIRNCOTEIE7uW0Q4VJqIAwdY6AqSMiCIFTR0QQBiTSzMKfFIgKzL0UiAjC3BRF Foj5CQXbZCNFEQaSnZRovHQMvNClTCNNhDKxR0+EFta3CEktyM8i/AlHqA0OLl3GTsIhaUOLWyYj L8FfG5fcLx23ieyEjmsmi477xL7KJBSn8ZWM6DE7pQIcMY0ziX4qveOm6ityoqo2I1kwbTcS1VQb kiiZthzYN+nE0NRsT+qpJ5K/vPrv31zdghb3tN6KdNfXWH0MpGGFFc1Q4NnNny/G4GIMLsbgYgwu xuC9NwaFlCT2Y7uDAcXxAKqVbK5arF+iWHmw8dV7o0IQQOgPow3aoxKdtnNQQSc+Z0PuS2r8EUQN DLTu1QYaljGvoFe0QRvHL6MO2GpvVSfcqa2NLMol7rsOlNK3A6P0WlY1xmKL396kX0Th/RcFLwg0 2+qRNqpoe1ZmZBl6VnVEBkNEMsI5iCnCogBic8hrtIPEKvGrCrFIxoAG+hUUlCCsZXPF2ESVO6Cq n7rH8MPu9SzHXsgchkpeOYbiwgyBrT29y+g8Jyx9td0pkdBk/tfpfOfrZJ7Xydyug/fqDuc7dUNs mly5LW0+x8k4OS/ldKazNWTztA6F5hlnOFrpcyXG/M+l914koPv5nMhkLmRoPM6DOZxPuFhxjy/U ic/ITsinqwdl+bP5OG8PPh6PJsiw69K7Yo/7XBMFU7tGuJrQ/bpdyT7ctXd/0gwslAH9yxDNMWaG VSCL+xVAnfOFQobMEJkYxt3EVoFLomguG44t7Cauh152UH7k+BIAOXvUo5ZhXGRaIO1Xk8MdYKza 9UPs9nFfesIw4twnqHBnd2ymXyTQEY8IlW5lXV7xQlf7oQ88s6dFPeDi5nOAaWVAMxjAtHIIGO4Z qlWhn2HDFBCtOgIG7AKmVUnFHf1OSxaIgqzkmHhFE2hslYnUbsBNEoBJMJyYqDjIOZsAr49sQAOG 5gNmPwjSDLBA+pXdIBGHZhnED4KnEwDz9Il+ZCcI0kcFMSA5WPYazK4PJJ/D0QlBQEaE0rRCVlYB o5UBM/25D7IyC6TViqzchAa8rgsZ941l1ScUlFUhn+UouaV/MvqjuPKCk7lXZD0aMAAWcBDZAN4X Wc+GgaigfiiSnSJ+KPotiJwhtVsvFGCmPspsUSfURN2WWYtgnt6S98heR++RFUbeI6uMvEfWGHQf aTvJe2TdIO+RdZO8R0YG8h4Zmch9pFQk75EROWbHAPIeGYPIe2QMRPeRcpe8R8Z88h6ZcNBE3oSH JvomXORAYsmLqqtYN6GWU5E1VTU4F4CJvHzOI4KcADZgpOrBO7ZssEnLR/OLIT9H5zWzgUzOWhvo QrVJHXI0oqbGYad6hHy1pmaYYaqF0FlrSor5rUqMnLWq4khYVAGSs9YUJMuaKlBy1pqCZVFl7Yue WlbN3lXSUH+r8i4vJg7oUO7sjI/zfecXG3GxERcbcbERFxvxPtmIpApku4PZpb+P2PHosfsSPY0e bbztaWwNYd7VO4jgWyCI04EOGsAPHfDfQePvBBvZVORIyZsd7FTCHtqw1ctZdMLWqwxV6cd1uJDC Vd3vDIU8Hhgazp/+bkz9RR5+BfIwwyOGvOCo6+1VHiYXhX0jmOKWb+R1gfOdre6z7W6hAofIupDf FjzfQeq/2+6VK1jtOb+/J/gzvIhjbnpTjCazHZFjbptaXJdnFsK8w8Fpncmzm6Hc9lw5qwTuSCM/ JZr8nEWNwluAQg1hzAzXLBq+GJJ6Rf+4klPpLvPD9z+sIkWYb/QcIvpM53hofelvfobwUzqyeNLp eyK0FedRcIS6WnD2Ko9vdYzu5FGWn0Q9x27iPB/k3WR8g3gUaAB2SRXUxm/4xTDKJIi9pKPMesY7 sEyqyj4G20VYvJ0jTrkcSj37RkH0OonykD5o0A73kbF3CX+wfT8r7o1mkVtZAtACRybKPKfU5QNP K3WizKaL1h5sunSWTCstXbawd0Bnybww02UPL9x0mswOA102wSpPJsm8ANQFFzsPdJLMC0ZZr/F6 UufI5ExQy8vLTzW+vDy9EYcGOxd0Lcmr2RvxadBiV5elvBamdSkvlHVdyq4GV1bWeDtCoWlJklUs RefRIt11JNm6tKf3GzJEITkFBwaZfTEVo1G8o9dj9hwQ9sBvusxg7ukyhGIagy5TmPm6jKGYyCCL nCwTsCKCxdO4JOs3msh1sjAFDnW6wiKp7WQBRucQdXkmUFCf/be0t21l0863VU3xStY0imfSllO4 k3VsZLpEiYSLo6fLJHQZNPSNI7YoBEupzSFayg2O4FJmcYSXMpMjwITXHCCmokDxYyopHF2mksTR ZyppFJwmYsihayqlHNqmUsxRHSriHCknI4ALk/HBMXY6fqQtMr44Rk/Hn3Slb0L8dPQKIWRwJxdY 4+g4KMVJ1DTOzTQKn6pVjTOJhhqEd6yhJqdpTaHxoWDVdyw4qgwxpNJ0Jcmd6VKKyFRNi0JLA3gn CtpIvRUfjL64p234dxkM946EvliEi0W4WISLRbhYhH9Di6D6w8JfCd+BkCubqxY7BMzgYgsvO7j2 0JoVVqs7iC1G4Fo4UpWKupF9G6nHECtoQxt7Nzt17VBRmdv4Mb9r+lwbDWUBG2fmUCdsdzWEKezU YJF2ZY3XPQJlKOwPDbHILhz6Hdj2i0j8OkTinP12yEASMh1CZ33D2cd0dgLYz07YqaWzE8C8VYrP 2i12r+kebBwxtdFoG/AAWUJRQwMW2I2SCOlGNnxj0F1Ydq/pLizyGHCW3eae3pcNeM3BdiP774AH 2btGOuihMTB8AHUfHMnQMcjk0NF98JidJ4jMMXt/HObA4xD9MxUlDhiyx5wjSJvRyXkmsr+xk/NO 3Itu0CCE0CP0QQiANQhhhNok0ptJ2MlRLLSwAD0DOjnHRRY1dnLMi9jXaZg/WlDAWRROodddcAbn SjLB6bKd2kNK5ObUHuBoc9fYuR322KVmnxJwHFvs9zWb95EOblPUKsJpq7WDpq3WTpq2Wj9w5qq9 pImrEYEmrkYkmrgaDWniajSmmauygCauxiCcuBr/aOJq/CVNYfxHPaLSQVNVEx6aMphw0VTVZC+y s3BspqoquuYP1akq+0Pj6D/Xk5TDuneDhmunEUWzFRtu1HAdjKRrbbByv3Uw07JShzpTTTUBrStN UzDRVZPE7NQMc0y0EK0rTUkRu0MbX2EqjqVFVSAtK1U9sqwFd94WiaAhFiSoqn1R57Ny3tlyN9pv VeCDxtLQxobxph0g9wrLupiJi5m4mImLmbiYiffJTAgntg1i58MOkA3KBstn5L3wYKMVl9bMBF74 UdrBQ2hzxT6tRvsZdoj9gIbct845dgBsxKMJI1o1gmE3/jtZbjGQIBx+mTZ89YVZ6lt5kpxv1bFM d17HA6OiDct6B6b+IgzvuzAczFiIDIhygdDZCQvTECnYj/PXDewNZlg0sgpfLvuBVTPOyvJn291C GSbRrvSywPNOzfJn291CGaq7nF4WeOYJ2qYj4Bsv50VdUSG+pVCINPWMs7RpSHQqUbuD8nzGcVop wegzvwTpiBcd6IjIzlmFECusEGHN3MSFqaAWOJK4sJ+RuNBKmZO40Nf5/5u4MKXRpWU8kbiw93Fa vMdRCh9fpa2IwrPPvuNnOIQPu0SF9scMUbAr4yy7S1xMlj0lkr9dKHtV8rbD4F4lDAj+0OVnDg0U p8SBUzKblg7I5Fv6l3eO7X6o/Z65G0975NS9raxCgCw6ReUadQHDrdcpKrdQ1j88FnSKSrFtunQC WGQpleVwtM4NOHRNV2ocnnajO9NFFqy0RV50wUrb2kUXrLRFXnTBOiLo3QITsMBIP+tydUSx0NVq IZHpxfnQ0e9Z1r5IBlmu0qZD0eUqbTsoA3GpDDCP/mtdrfZE5OyrluUnrZQB6/E2bLksX3nXoOh8 hmySDwQoUWaJTLFoMxCCSn+kdzD6o6YL696zK1giuJ5e10RwyO1OljsUCVBk74llRfYzKBCg6FYl SVrWrUyMBciTrYWBDHlq1sqAZSmNw80FfiCedJEXm68pNMBKJxVglaN+sLZRaEBpt2KsY3TFRWf7 Ni1deOKgdKNgACUrbekq1TkWQLnCO8LKNAoGUJ7yhrKwnGMBVBxgM1plhcMBVJZ4G1tljcMBit8C N63D8x2RYtNCGjswRTcI5HseI7SDriNIqpYRxjvoOgKx3eroYAUojo5JBm8vuPMDXyimng7aRFfF IRQflAG90zrCLvV09KLEUnTcVp3WixLzUSSmESnWyRQmSZopVIp2MoVLksraOIuebnbrPeG3OhR6 dT/uaB8ZKuN9T+NeLMbFYlwsxsViXCzG+2sxlC9bB4F+hwEtgTw0gHkOHdjo4Ok7MzmGnYHaQxvZ Z3Kq0GPelZI2NGhz5XC2CJ49FDO3kc3grlnEI6iqDlokZzG99tjuaYsD6jz5FZvSw1VMwMaAjhk/ Jnxo1zsx+xdpeO+l4WBerlFi5ca9vFzz3IkdplwAJxzJWccpGBjHUSLN8HWF57mB+bPtXqmCe7EV 9LrA8xzB/Nl2r1TBOblMioLOdAQ3XYF9OOnKOa7PpqV9tpae4wju5Ii9duecxIrM7b6l2FmFiB/X ixCGw7MInUUR5IYRhJlz2hUccRcpTjgJQmfpoxdwhTtcyxjjcnOWzzUOOK/Z9bnaidlDT988+nj1 IOK95mH5+8YRq8GZuNjKHKPKkeyZJvc05TeQGkSBq4TjwNlVqCC+j0/leRfKfrG87TAQnDBcEwm7 6gNF4RvCTbPMsbESNiw9cLH7xWGfnvYD7PjBTToyWf3IJ7VNQbdiPdJHcBtTNSYl42YDyuEncMth /W9Y/rDq4WbKfvnzK7gzultetxfXaRmUu90KWZZv/c6G1YUrxBJxVQnvPf78dwdfHNDb7V58cPg1 XGHaa3UQffHJCkbo8k93NJW6S4EzlJn0egU7o/W/5S9wNyj2/M3Lv/84cyBn3ImCvnOB3WpYruFI O43lw4/h2EaRzFkG2Wp9J4UWMox2ve67aCiupEKI77RQ7H2YRuXRmYWetgEDTlZL35NpLQPOfxjf KM6St4TfFzx7MtJ8t90rl3Ee23oUz54qNN9t98oV3MupJX5f8Dn11AJdf9B4an/mGWAqxDUWC9HG zi4EOYgr56316IyL+ZTrXIZS6ZzL/ZgiJklEEZGksyhC7DCKCHtOT0oor1kpUWcTX1RdRndXfnZ0 T7pHR5N9eXxPekDnja8Hs0v/9cvVwBvDD2eqTbqvpSTTHCfv6z5xXbm/y1avLbafXfEuY8mj36L2 p6+OKSVub5j0fvH/hcu4YdI395o/vUe4u+uy5eO3Wn/VAwFw1udvtD7njuzDE8tj8jGiTbd+H5eP CbedPZVgrtpRq7O/Jt2Rw1/JDazL9IZT7bNYQ+Gqe9fGvoGpC/L6+tV3LzZ4gzpcaV/nMv2p27yV hJ8+flj/mcaTk64Z92ZrP7/6C2S/odtyXcYbJ5YzrrTWBs2hSJ68OtBqvoLOgOjSvcquM/2pzjz6 chV4XFoqnycLCDihdg9OFhfz7XEZ6JLOiQKFhg6nfwRvFA7kSJaXGc61xc1n291CBSY+mCtvC55r IdvvtnvlCg7sbZb3BZ9TT85NbwajyUzzR0X4pg6uy7MLYc71ZLq4P+fcTev43XvenFWIdMfJ0BBV hs4qgphhZQhzTtrhHndnIDNYHPfM8Defw+CoY6Zf/mGekSwjLgdzkcXcW14f/zmqX9Qff6hfUGaw A1fA36E+v4eUXRHfuH51TP9IuzPuOOwYy7vn8qEuN79ubsOl/aoSE0Ux0lYSwzqLpa0kxryXtI8y pcEiHGSmTUUFSWnI08l97N/l50I/8L4XfINbV4ooJSPjKDkMuO2avoK7FttMiB9il2eeCRvJJcCu 8AAly54qbaEDHtxONOBsZ7oA6q42lBzdBnqJkmKBtsCL5AZkRxHg6E50Ae7ciS7wQYwMCRV3oos9 FDdyoguwnp2CnzX7CtIGsBy8gsVF1JPb7BbRbCyB/B+akCUQHTQhCw3HKAlZOiSDJmTphF0cWtAR JSTNhmH5Galm0DOXot8BD9E3RTKABAI+z3fFDMCBEjXPOtNA86yjOAH2eb4BKwNg+he7hgGaZx1p A9jn+Qbs8nzDhNXn+QbsTpfxfNYkJ2iedZSCEjTPOgleGC22AxgUJM86/aZ5vqHfQbOsM3a/T/5b jBBwRdPCTaumGAhrGka0WMspBEI7RuEw1m+MgDCq0P6OUS3yyHaJn4ujeWStpHlkWBO1CXSMpTE7 flPEAwsDuS9NUtCgmhTRnrVJGcU7NComOBk1ZeqvEjUJxw1zGwDydW6CK3T4SOUyumjD3EaftF1z XmQZrcyCbCObduNs4AvFRC9EUp290b/0Tq1QiIoqHWGX5oQKrc5ibkeXUqrPTueRrEQJtZmiV5Yk Z6ZLp3WjaklKTRWTPyROfGueHg5T0me5asG9xxmNjFP8swyOexwhvpiLi7m4mIuLubiYi/fSXAzU BD575iFHKTKbWrS5chii3ezDFk0UyKO1N1Yncg5FNSEtonowu5IJg0LO7XcA7HyXs/stNs8btV9h sKYZduZxD22c9SPlYNbWlIXq6l1dHj0dHJew7+POSm5v3Iix1uPE78LqX8ThVyAOd+8e54Sq/V3t HrMaTUViEfzNkTRDyphVBtxT4KpEFZlhCxOf9QldkArQw9HAm7aEMgDDdp6JQPae4X4UDChTqUP0 iKv0eL8s69KOV+UD6uo5SYUyXTekSYWy3efGO8g6cUSble0+N5T6rPe5jfhc3Ioi221uaEqz3eYG ljfbbW5omHOxaWNHPye3psh2mxtOCbLd5qZu4d6tKbLe5pbXhIJbU2S7zS0RR/Q2Nxi22e5zw8lR 1vvcWprzXDzbvTxITuWZYXrZnqgYd5kbENdf5kZQJ+2ZtrWZ9twHu8sN9rf8ZW5IAM14gHOs7C9z QwK629wINuR3l7mliDhExzx3lxtuubu73ID3epfbQARw17khwdx1bkgJzRBFYufvc4sI5RwMMkuT ynTUc01Co3hwU7Xm/XG04mimZ5XhPN7aQvNEayvN460vOM3UntI03ghBk1QjFE3jjY6kmY3ONJNX NtD82JhEeyl2HxwrEs1iUUQk9LRDNgkhG2QCRKbeBIymBSZ/dPDC5JOOumR/T0Xeuc/YxgAe07Ah ImUPag7H0Q0waZq7/y30bnxKx9wFcNmNbiaLuwBu0C0iR1S7AM4pFuGI3f4WvVpihvrb36DfO9e/ mdajdURurn/L/vq3EJ0+ZVH0179lUcf72eaY2pqCJts9nIHETLnRDon7Zpu7GIaLYbgYhothuBiG f2PDIAsae+Yjlu2jnL3yWD+ho1YObLTK2JoUwuziOog0IVij5ww7FPMO8t8uDj9qGjEYt+pfM+xG eZQ0YgxcGjFWApJGzHTCURWtXCjR1WtMGkkD9A1QE9zmk3tbY35h/vvG/ENRQQnDonK2k1PvOq4f wq7hMBfFcW2v+gnNHeMbxUWi/Pj9sh/ldzyWsPluu1euYNnRkPcFz47ya77b7pXLOEycLYDfV3xO PaH3/UHDr/2ZFz3HhVhjqRBp7OxCmIMY/+R6NDuMz3Edy3BUmh8KyJ0xSaLOiCSdUwizQwtR9pyM JywT5fXtk3pILerv+1erOvkNqSuHc74djE+kHMNa3tFo7p5T0rraf4BwRgoMtNxzb65fQXQfhqN/ hyGGECKIyersBtPrmSGPA87y4Dhm2g/mdtGPdv+oUeTxJx9DtCNV6GLN3dHJgyGQBw8JWAWuAZ88 XME6B8KiH+8EKgJd00gHOMB5ahg8mXTmlDAgOCeYSHEaQqXf4pu9smSE7GHO66DvO6w/C0ADqM9c r4P7xWgXJ1WVfovng+z63EiUKs6ZqCMJx7MuOCn7vBwU53Tl2a04izslLdnOc7QFP44WXXJirvQs K046f5p1xUlnTrOuODH7fNYFJyVqz7rgpOzzWVaclOY9d7bgBy2bdUJBWeKzJqunBPTZstUDsEkf 0FMngZHoWyxWJCbNbovLCmMH7U4RJxuY5OsUW+xkiINcYtJUTtwYSeVEqXSTpnKiXiRN5US58ZOm ciIqJM3mhLnxkyRzIhKmvnG5xFQaDqRiHOgJZ8/A1CRzisnlewDuJ03mRLnxk2ZzIulJLpsT/uwE L7lkTkgGTeZEP6rHCzvdJG+Cn9UBhjTQ1zErvhVFifGtKspHnGS2nV0TOde4doFzkWsXOVe5koBT mQuFONO5EpAzoSuBKVG6kp/WucYeclQo95Dxva2nGfvwDRMMzu+ugsPp30WuODu8ih1nj08ul092 QmtaVZ0YvWgv97XL5TNFN2Skcs3lgyn6k0vlM+ho5Oz+Ok550GbnqrFBzhRTJUCeAdURTG9VIXwv gaoYZpdqILrWQBUUc1v0F89WVLuRrKjy4xzaphxJzkx50q0hqltJSrO7JASJkOUMbBuqyLTX3XJ9 kaMWjDft6LhPqOLFQFwMxMVAXAzExUC8HwbCL2m2HieNR9tH5NJrsPtybIFGo0H1jZnJWa6WRj4c QBJVpsLgkD3DZx74r1Jc3AG60aLRYnLZOxnzLdesDFqElby0txM5m/a1xV3qu/PKJe9c9qU4tovE nZGxF5z4lnb+Ig6/AnE4mOkuk2YaOauAxREe9G3TNVT3zgL0f0gGo5oKZW5kc3RyZWFtDWVuZG9i ag01OSAwIG9iag08PC9Db250ZW50cyA2MSAwIFIvTWVkaWFCb3ggWzAgMCA3OTIgNjEyXS9QYXJl bnQgNDggMCBSL1Jlc291cmNlcyA8PC9Gb250IDYwIDAgUi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9J bWFnZUIgL0ltYWdlQyAvSW1hZ2VJXT4+L1R5cGUgL1BhZ2U+Pg1lbmRvYmoNNjAgMCBvYmoNPDwv RjI3IDUgMCBSL0YyOCAxNCAwIFI+Pg1lbmRvYmoNNjEgMCBvYmoNPDwvRmlsdGVyIC9GbGF0ZURl Y29kZS9MZW5ndGggNjQxNz4+DXN0cmVhbQp4nO1de5Mct3H/BPcd9s9dl281eAyAyX+WLTlKHD9E xo4rlWIxq5No1y1JkRTtjx/0u2f3bm/nqFSJ4kpV0v5uMHh0N7obQDfm+6thBf9+/dursIJ/33x3 lcpqrGW1v6oj/brFXwl+JP7/i6tvf3H1J3t52OapDWlaHf/oNX72Zay97qffXn3+9CpEfKn/rw5p G1c5bMe4erq/+u912JR13vzP6um/XX3x9Or7Xus0jK31F45+vN29vAq5bFtb5alsR+hvLHGr8FZg ztuYO5TSgnkI0EqdylDb6viHb4Xe2x9WSzAO43aK1opi18o5Y+H39ofVEgxp2mY3FsVnt7L6OxQp wzCMq39gNdmPrPPDDe3Jo6t0w8AqdRyPrRLZXLcDdFMH33qZR9YposJVCnk/oEampcki0VKE8fFV MpO1SmX6E52Ad7zbp1yzKRdgmDjr8FeoCeZcbhEIiVPv6eZ6XP+wue4t1hbr+uWdP29udXbeUS1w 2de6vt6snv793sINKOP7cNNbitzSbpO301jGtH7em1+/1nbnuuSg0jRgbXns1WAPgvTge1NrosNU qZmee3EVa1dcvYY0bpGNHfa5ADCRTpm2vSTgEBkDJVOGdgkPGXEh7dBAzjoUlKh0KIwHeJxkltdt QVgaw0Q40+s0ERKoTYIF2ooktYBDQVzpOU46wLkxzlSeNReyK1HZDC/lFLa1MEYyoHJGjCBSRYmI gDS/VVlPw1YeIw0G08PA6Y6T6DKkwgCDNxynrS+ukGrrMBXXWMfMAepMbMKBjIDJT8PoOLtRdsj0 RwrEKuQnAnVcmiNgx0p/IHDHnv6xGP2BPR3X6NjXcW7G3Q6jCMOAxZ1kxFHoj3LT4ShihkQYhQMk dh0zB0gsYyYOsNR2SByooBkQEwcM8/OAdJC3A4zfKu94iq7xCrPL+tZhya7rXbmEKOPqIPlBd9yy o0nNTASmWc3EfKFpzUgHpngdiffCkDoSGYRhtThu1kJEEGbXIszPDKfiRKVWYr7IUa1EBZGz2oj5 Ioe1bbNJaW3E+zlUEa+NpqpMAa5Mp0itNFV5BnFfdILVuo1u/vFIdHLWIpOVOVBkWteRZqpMeSag qoQ60lSNc/KrSqmZpiprHOaeKqSOvb5izqs6q6SNVd2R4Igy7AhpIKqSxU5Vacc5O1XLQququGOk wrgl1f2XX1y97Ho+1onkb4K+7ucandTL0OTxrT6WucGu1J8uFuNiMS4W42IxLhbjk7AYSfTHfg4d 6OOYo50WJa6dQjvfuhoew86KHKH+bglERlWAHgMqB0B76KG8RiPzYGd2MB3YxSQdwqlwB9o5I0j6 Ya+DU33xgAY3WijnePw6lU5Mlm6z2WT/OMb/IhI/E5GYCURCVy4kMk2slFPITkkDkvHbbxwQwTHy 5gvUk4+xSpa0Y/qb+iH44+jfHVssuWQyTPg/3LcZNnW93VzXbSvTOPsZ3GYu2JiE+4wpIqcTGhgA Iz2Bn63/F90zA91i7a4IkpNzKzWAE4P2LWXcuTvGjUaj5R0emuAUA02FRj1R1LBhhNyRW+t8Ektb DBhXP5Wx3rWzN1WsJeGEPdiFYx8rRhTrrhUmdIkZ3yKGfXDCUFWXyhhRWB0qqD4Jh0E2/KmuMFTq YcojPT/EhTWOlHdYIYDeA0BATUMjqkbC3JVbG4a4PTxKgk4sPt3Bn72a7n9EL3AvixbARRYtXeYB 21IZkK6NscogizNcLgHWxTHIZQmyOMPVFmBZfAVobLDFWcmIqyzeCOraeKLiujYu0NqwkmViGidb G/c6AcvaGCoBzIszPHEBrMtjmGpj0+UxkGFsYjlxCgLW5XFD6A1pGiubbXJ6ABd2FAqiVPzTIqth 0lFjEZpT5WXrFu4AQ/Fd03OqjKDMhjUKwXExDTh6qmQhOJYDrLsRQNExC8WxUcAxG0NGt9GRxiQU J2aOSShecdBJCE6iMIpiY+U4RiY4SdIYheATETwKwUkOxyiLtYEGGtR1YejdulnxqbjqaN1izdG6 RntDyx7rLC6KbCy0ZrKh0prKSIFLLiYTLceMhLRaMxLTas5YQKs9YxGtBpWDtFg0BjOQpTUJ+Wir a6SCiA4uUVWwaAFrYkfrWxNLXDyb1NJyWGWalt4m8lKbTAlautuMkb7IjCKVpROuFjcZacvAJqvQ QCYzbjjYXGcSkh6gzQpTEkx/VSK02WE6hnmnOoh2SlRFEedVgdE2iyk4lhtVgLhJY/qRxU60JznU plxZakn5zpbHuBUBxA2RHHkrZdpEvHSdBo/ZSb3o/ovuv+j+i+6/6P6fmO4vrJVpm4WxIlqazNDu yuFUVseIbYrsNGH7yTZ7BoRY1gM6t+CStJmVnDB0GKK2ch/SVw0ropFJtYh2clwC09p3kOARYAWA rbzw7+qe5ExF0K6bH0JTks94o4awFs87mh1Hk4VtsO6MfpAVv4jCz0MUlpxqVxgCGgntKSs1EhHW aLfiq5G1URPJCk58NdZvamHZdqmvxvpODTQpPHXV2BKqeWcFqL4aK0BxDdiuqq9G+lAdC9aH4q3x aNUvYf2o3hqPXt0aGL26aswFdYiYGuqr6U4du1eyscchnsV5drHZvp3Wpq4dVKV+HfWjiKCg0WZS 2TCKTGhyr9hTMioUdfRoR6eIp4ckLOro8UQYLegAp8loznVZcRvGvyKuXqP9SHX1iP1FXb2JqKSu HklPUVdvIipnEbui3g1yiQmlvhYTUmwgc8FDfYo00bdRoFztkWgiflfJrlMkvNbpyiopmzEvbsw0 bZQkNKuMYuhGGD3J8zJ6kxdi/CDXS7nF+23KTHK+jNnkAJkwoPNlskL+k4oSOV8maahETApJW5uU 0rmBSTEdcamMk6q3KcC1qf/UiMbqQFWenebI2dzjcejcJEfO5i7TQac20EimPZNQtQI5cqY0iAOq U8iRM53D/BOVVJNoqCI4eY1Gqs40HkuPKkSsR9UlC55qU+qUU7Uot1XPKOfH1kTqvbh4Wu5Q2/Dj Ytv3y+OcLhbhYhEuFuFiES4W4SdrEfQkmKJW7Kz3XtQ4akWhApqGXCmCnWvbWxUm1gGoUnAnG5Nc za1sPepU1zPqNge7KwdRSRwiO+vWgBrSo87mkZY9QDT3IzZi5o2Uwf5IN4imdv0fi5d6IYtu89UZ 1kmgkyS56uYRTB9s1S+i8LGLwl1xFVyw4RH9QVzFA5ll44B2ZyTFsr8qDSzFKNqN4cjhoVJa8Lmp kvP39ofVMhzYIkppwecmMc7f2x9WSzA3njBcWvGSVrpRmY2lNRvMWQl9UonvamvW17MrQd6Bidjb gMhWnFWFsJtqEAotqEAG4uWnNROgJZUwK7QSZQ1UEjSh8WQG40jOyDhy6uBXm+4JpSHn9WvLVnyf T2Urjq0CJ7mKk7mK4zQQ77m1Fy4j8vnmOq6/cX94o40Ofiz3Jy2OAX2KMYG7hfU/efXDm90mRhzS +ma1uQ4j/f7b5nqSgb7vf97GMrS6zpu6Xm26Hwbg+TffvLl5+/aXm/4SRuGtTpKBW495y+F8v+m0 7C2kcX3z9l3/jZW6hl8+f7eB6MGQ/F9fvVxt0gRxf8W6sqC75/QxgGLFPv5xc9093jSFvH7z6h2M NHXyr1/t4GcMtffndnOdOAxR2/rlZtI/XfcxIE2f9qdUlf36XR83pZ/e+Yr7adR68uvNdfeJe9/O zmAfB0pFqbynXhqml1T20xmOnPogpQWfr5b9e/vDagmmad6K4vMVpn9vf1gtw8rhZlJa8JJWIB/B j6U0G8yZiohOsqd5JdrXsytB3lWK3NURjUv0MvGbqxAaLahB6OElqDQToUX0IGYYPYQ5c8V8jzqG wHZwkUQh97lA88bP/HJaI2OAodZyWie3CQOYtfCLm+ffdOXLbwwnuxsoMSSDx4fdfYsaN0ykRm6e 9e53nYPKzKmaPxdQEC2WsH5mWjadpWU5f2oSHf9YLYtdw26m+7r2KyhP2usc3Uo9C0X0/+8hfjv0 auP65p/vNiM3/YwJfKouWtS7urz2PPUiZw3Zi6aK3zz/9tu/wUA7KYZxvdvI2J7tNpV/3hqFnp8e bomP7SLTaVAR//IWrH4ZY+iG5x/d+iWyPGY7nv/vzS0SE3t2pyX5V3ieOzun9avXq02gwn5Ajvv7 /hvC/IH372ah9ZT8MARasHS6YbD/wOlfgIs+BwQzZ0BP1qEK56+CJd9O6sLkPNF5B4B2V6yk4Sgw TTwBKPjCUMbAc8YD56PpADQLjQcY9e4WPZP+JAd+fkBdHiqvYjnjUwLCeQcuD2Urm6yQ3qHx5LSs zhQCrpu2WePFyQPPg+QuUa7qIIlWuLUIMLkNY8DBAuryoEnQlCc7aBI0WbFBsqApzXbQLOgsc1Ei zzBXaEiz4DPAEnzGE1c30YGik9tkB1wtoA5gdot9YwhnkA3RA815phQmj5tJoyQmDy4LGrtiWdDI IM2C5lFoFjQtnwZNmKIYukmS2SjwcJIsaPZpNAuaYhanyXMgTc04UAjrkQvEQEzNH7kA1CMXiEyY NBGa4i0nTYSmKLpJE6ExXHOSPOhJ/K9JjodG8hWrxp+IMyaxSlOZAZkfFNdkhcN2VlEQx25yG6va D4qp0k5yxJUOgiOydJAcsaVE4IguoREHfCkJORpMSUzBYsoAjiVTBnGsmfCvetZyZrKynvN5VTQ4 NXlw2cE5m2RxZrIKHicTq2BSZrKKrWnVWtxj1UmUeqxTRGrXlGDMPdYJJn2z7BCUYs0ILjJX9aij +rnNGds69zkBWVQDpXur4mBHQhULZ4ur3qH8Y1VLnGwuWovTj1WncaK66jxOQFadyHnuqjM5AVlU KiXJq8LljEZSyAdBdkZvS1qVgpKWafxwM+JRUdYXo3AxChejcDEKF6PwEzYKlJA98PnDHMtNAkeo FncHAWF9M/qfO9+0NyuM+ZD9TqR3CLDCk9/yi5r1wN6gDt8LLAB4Gq1bhnWuK8JV1UiNvLDSvLWn JYqp7vtVtVFEmcOj1ilSDuYEYj5YcqHWH2rPLwLwkQrAPbdSQsJKQaV2lBDvwt/3smMhQdu8KUEw TVESX9IMYXS54CTvQTVJN/XJLTjCfCWTlncYkmjSKFslEQHaHwKyZxItb0A7r3FHmjJQDrdtPq0x 33lNAvmB7eiWhPnJZ6N34LAVjzwTuqa0A7npJqr/AxvHZf0dXJT6wxvYNR7WN6vxm3+BE7DU/8nr 1ddffT7b3dRaQwF3wGqdb7q7YmjefOtf/f7LDdz4tf7D3TVzfwPShzd1x3H9w8uXB9fIWiN9Llr5 +3oS0EH29d683Cklnr9ecvxGElH4tiA6GGcokQQpk+GWwgwXxkTQa/uDOhlFCtuTogwXxkPQa/uD OhkNcdYCw4WxEH4Mrekglpz9+062pr1cEgeR6kDhAzqYJTEITA+pQ8jziDCGmdS0ZmKzqJIhzujB jDmKhDgRPcCLMEq1xOmwf327uYazcjiNOH340xrlRsrLD4RBcHKxll505saqGpdP2M//6P0MfAh2 upuJkon13dPdxEAK35A/Hpodyaw2mJdb169e37yBA7dKB4CzE7e3y87zR7owpWQ90GUoZ+C8uLnV 0oKXnOfbe/vDahlmDkWV0oKXnLTbe/vDahnGOB9LjEdjebAVjG1zY8FQ17LgDnqpxHcVKpG+nl3J qPfs7G1E7KUvONDXOoRIS6qQwXgZKs2EaFElxA6rRNizMNQKQpcbruRxPv12U/vadoxx/fUXp9UL LKHtzQcO9OkeK9fOjx1npRGhSQbS+9/XarEM0xoP1oejM/9nv9lk1lFfbCb+45OnG9Gvd57qzur9 I+gbeu/rP2wmPru3A274GxX9NfYAH9sf7Tj52dP+k975q77tunqaFzz6PKlanPXy37/YgC/3V6fs 5jeN7a/4TlYN3edTTNkzphNOvXiWEUXuChz5OjqpapzI8MpkO8L8RQYtb1gAXyMLr0YPcsZ2OTGC wqV1BHI32sHdaXq8+smO/EwlGUYiDCu4wBf9EgwTbylyacULDRy/tz+sluHIO7RSWvBCA8fv7Q+r ZZjqfCyCFxq42Vi6JtbBLFHns65CJdLXRQYujLQtpSNa8okSY3i1iLVlVYht8jIEtkmEaBFFUp2T VdizyMBR5tyAef6oGd//83YD27tgC/D7Iy8f8qJhimsFD3rRkLbgmvt/sXOBogqPovHypj9Hnf/+ 5KAiKiSr5QGfm75N49qktcFnm4EdadcHZ7Peb65zl0KwpA/EBuI+ybndmXCH9bg7GBTNrv/DxjIU PF/A9//8X2CIh/5PWP8KLDrZZBcs5x0Ii+4zp8EVNePvqPLlV8D1/tcU3FtfL44mDklTFmhyavoF wsD3VkhpwQujifm9/WG1BItmX2Dhsjj5wr22P6iTg2aT2Us4GkrLvrfFIa+zUZRmw1gSN+u7WZr2 c0kUcUiy5KCxnK/VhclGp0WvCx28zJRmQrMoCDlJcggd1CfbVDlbFZNJCrh1iPPOfX3q/XdvNtcD +c9hfXNaXaAbZBU9qJLbrNUfXyN3Z4uOlE+FR59OWEkDaCOt5UGF3CnpmiQFuNqEvEXF9BkoYdJR mh9xho5+KEx2ws0h166LcL1582AEMVGqZT4p6Xr3b/A+rZnevAPbBR394fkt9I8jk5/8J+zX9G6X sv4c1SxF5ZoWNYU719InRwLbSK4nfqWXSAzXX/6u/5EGZyu2v3D4OOh618b3B3fywrICgwH0jl76 ngZD/ppGwHNjB/AKXsaNU7K5otZmWvcQcnq3FHaw+yONPz0iwP9utKBAqBcOa+f5HPzwgmFbS32K gz4vFIuuSYj6gT+61wJC1FcaHhVjm11KCVgvpcRrmNvsVkrAeitlxvIriQOKUY56+XqIWGe3UgKW WykRaEgSLCVj0ZAkyJSPGhTGe00aFEb5sFGDwigzN2pQGF06HiUqLCARNCiM7s6KGhQ2yJ3YHJM0 bOnKbA5JGogIHPnRl79Fb9AmnLPcoT3DeVZeg8IGudo6usY0LIz7omFh3FeNC6OhaFgYDzR6Kuj3 kphKGhbGVHRxYUjlcMAEiQvL+FuDwpB7LigMuatBYbRoczFhQIRgQWETPdawPKBBcEFh0FpwUWFA heCiwkBsg0WFwaiDRoEx1igxutxFi1P6ttWGid/WGN39YZ2hi2W0s3D9R7BPRsTsxsmZ10oGzvpW MvF9H0pGvmZBSMzXfSgH6I4GZRBf+KEM5CselMF04UeUZy07yeDrPlRw+HYJFSy+70MFjy+n0BvW aW8nWriUE3F56GKjYrMZIlXnWUCazS/pmguO4tma/LAkOCrJbNXgqNbc3GeaaWwUk7QcUNxio7JX PMIw0UrCUNFazPBoASyq7khMTBeSGJmuRCkzVUpCaKqWZFQ1MYlw1M/tapCWXnVfGmvwYuVoZ87u yaenMjGWR+5ezMXFXFzMxcVcXMzFx2susqqP/QG+F9H3XmbYoSkeoJ3vgL/9nrGZkUPQ36STJacA PQZU1aDNEb3LOOuB1Z1o50zhgWXkLrFGOEI7M4OoEPZeX4iGPqnBhRTKOhq/wHvniQ/v/XCjf5GF j18W7orpZEVAm2+P+wA9x3PFSTK0OFJOb5uinJwoV0bShxGi3hlJGT1R74ykDyvE5m17iu7WyErY eQYA5dZIBEFcjkpxhs25HICLuByDRR7KxySi3hnJHxPTOyP5Y2N6ZyTeQR71zki6hDuOW+fXpZjN t8oIqzxGMsjti+SoAY5OFBIDinqLcq+jPJQLvugs3j57JpXLFyIG4oB+IYK7pl+IoAvDo3zygQem d3zTRzcifzBCyBLsmxz0NERP1MGIDtHJcTCiI1MG/V5xpOLBMzRMlhQHQw+qDVAcguguzg8LYshI mIJbUmSE1Xl6gLPM3EDFo5tfHc/A7GPG7mVKDgvOxjbfNGWHac8oOUw7DslhOihOAdBBcwqAEoXz w4Rm/AkOJSnnhynJ+RscyhJKEFOG8Tc4hJ+cH6bspk9wqDBwepgKC3+FQ4WJ88NE1vgjHPYFPsoP U1Hlr3DcgavPH4vZV+a+ANLcnJGu6I2llLqmU45HIjeWUt6bzlchg15ZSnlzOt2FinplKUX5i7YQ JhRjQnS6RlhoXyiYKyrgvyoxuhXfdByJjqlA+qKLqUj+FqKqUP5SomhYElxTwBheGqejhK0iX07U tbmWcipHv0kDzwO7oo/aC7iYiYuZuJiJi5m4mImPy0zQ1NPLZT12yCL89cPADmPu4/1o59r3H0Ej 6IwHIxTFiVuhtZvTe42ISO3ch/Rdww5FXSMy2pkeqEc2kXt1N5B1n+kQWYOb1sA1+Exza8NGC2Nc cHx8YKrM9gE+2OBf5OHnIQ/3fyh9zPIZ7HM/lM6fZh9pH0Lz3EbZl1AsX3aW8oeRyT9SRXeNrepl 28OisUnMcc3UpRRwM53xLeKkzxNG+3RE3oeCTB+8H+xu8Fup6fha7eNrtuOsvMMa0Z9kO4dMgG3u 4J1tBLkjtzaGcRbBr1hiQj7dsd8pQeQs56bZPvdL0J3CdOeUQ+0aGh4O/WiVor8YKOf/MZX+H0xf 8aoKZW5kc3RyZWFtDWVuZG9iag14cmVmDTAgNjINMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDE2IDAwMDAwIG4NCjAwMDAwMDAyMTAgMDAwMDAgbg0KMDAwMDAwMDI3MCAwMDAwMCBuDQowMDAw MDAwMzY1IDAwMDAwIG4NCjAwMDAwMDA1MjAgMDAwMDAgbg0KMDAwMDAwMTY4OCAwMDAwMCBuDQow MDAwMDAxODkzIDAwMDAwIG4NCjAwMDAwMzMxODIgMDAwMDAgbg0KMDAwMDAzMzMxMyAwMDAwMCBu DQowMDAwMDQ2OTUyIDAwMDAwIG4NCjAwMDAwNDcwMjMgMDAwMDAgbg0KMDAwMDA0NzIxMiAwMDAw MCBuDQowMDAwMDUxNjEyIDAwMDAwIG4NCjAwMDAwNTE2NTIgMDAwMDAgbg0KMDAwMDA1MjgyNyAw MDAwMCBuDQowMDAwMDUzMDQwIDAwMDAwIG4NCjAwMDAwODAwMTEgMDAwMDAgbg0KMDAwMDA4MDU1 NCAwMDAwMCBuDQowMDAwMDgwNzEwIDAwMDAwIG4NCjAwMDAwODA3NDAgMDAwMDAgbg0KMDAwMDA4 MDk3NiAwMDAwMCBuDQowMDAwMDgxMTMyIDAwMDAwIG4NCjAwMDAwODExNzIgMDAwMDAgbg0KMDAw MDA5NTgwOSAwMDAwMCBuDQowMDAwMDk1OTY1IDAwMDAwIG4NCjAwMDAwOTYwMDUgMDAwMDAgbg0K MDAwMDExMDI2MSAwMDAwMCBuDQowMDAwMTEwNDE3IDAwMDAwIG4NCjAwMDAxMTA0NTcgMDAwMDAg bg0KMDAwMDEyNjg2MiAwMDAwMCBuDQowMDAwMTI3MDE5IDAwMDAwIG4NCjAwMDAxMjcwNjAgMDAw MDAgbg0KMDAwMDEzOTYwNSAwMDAwMCBuDQowMDAwMTM5NzYyIDAwMDAwIG4NCjAwMDAxMzk4MTQg MDAwMDAgbg0KMDAwMDE1MjA2OSAwMDAwMCBuDQowMDAwMTUyMjI2IDAwMDAwIG4NCjAwMDAxNTIy NjggMDAwMDAgbg0KMDAwMDE2NzU1MSAwMDAwMCBuDQowMDAwMTY3NzA4IDAwMDAwIG4NCjAwMDAx Njc3MzkgMDAwMDAgbg0KMDAwMDE2ODA1NSAwMDAwMCBuDQowMDAwMTY4MjEyIDAwMDAwIG4NCjAw MDAxNjgyNTQgMDAwMDAgbg0KMDAwMDE3NTczNCAwMDAwMCBuDQowMDAwMTc1ODkxIDAwMDAwIG4N CjAwMDAxNzU5MzMgMDAwMDAgbg0KMDAwMDE4NjU4NSAwMDAwMCBuDQowMDAwMTg2NzEwIDAwMDAw IG4NCjAwMDAxODY3NzIgMDAwMDAgbg0KMDAwMDE4NjkyOSAwMDAwMCBuDQowMDAwMTg2OTcxIDAw MDAwIG4NCjAwMDAxOTI5MjggMDAwMDAgbg0KMDAwMDE5MzA4NSAwMDAwMCBuDQowMDAwMTkzMTQ4 IDAwMDAwIG4NCjAwMDAxOTQzMjkgMDAwMDAgbg0KMDAwMDE5NDU0OCAwMDAwMCBuDQowMDAwMjE0 OTUzIDAwMDAwIG4NCjAwMDAyMjM2MTMgMDAwMDAgbg0KMDAwMDIyMzc3MCAwMDAwMCBuDQowMDAw MjIzODEyIDAwMDAwIG4NCnRyYWlsZXINPDwvSW5mbyAxIDAgUi9Sb290IDIgMCBSL1NpemUgNjI+ Pg1zdGFydHhyZWYNMjMwMzAwDSUlRU9GCg== ------=_NextPart_000_0068_01CF5EE0.9A12EAD0 Content-Type: application/pdf; name="draft-hares-i2rs-rib-model-03.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-hares-i2rs-rib-model-03.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1WTXPbNhC961fs5FJ7xqI+3NZJeopcJeM2cV2JMz3UPUAgKKEmAQYALau/ vm9BMJIcZ5xOeyg1GlEk9u3bt29BfqRxNqExf9KvrAejxQWt/WBM7/BdDz4OJnEBpR9Z0yzHopc0 mVJeDrq4CU3P6eL8FeX14ORquljS1ro7bda0drZt6B8c1xnNxEYUrTvN/xxMzil/D0gTlDMqDH90 ogxfjTVzQt6pQJe2btoAOqffdFimUAX5IELrX9MyCFMIV3jKef0zmIuM3trqTnnGmj802ilg/CKD XSlH0+/OaDqefPvF8J9aoxssvFaBJfJndGVkxlhfXdWXjmVGP2uj/wusudPSe2v+b7xwXGov7b/D etM4XcGxXauAxcZ9/xTiwkbboEeldbUI2hq406t4gT7YQlUITyZ9IlPBdh1qFcqhnjo/dHo11Agd 1hw6HJ8jevp9jH6z8gH2C6m0PjOsSS6dl62RTMGTNqR4JFAIyPAaKZzT8JVJviLh1BG1sGu0FFW1 I9iPq8EErHb9eirUvZbK0+0JZ1POR1S/1UFulL89pdZHOoleT0kfCLNiYW5PFlez29OM6MbZYKWt OiRpTanXreuWNq3fJKRCBAGYYClsFCE4Lu/Pa2HEGmVpg2mtgMVDqz6tTxgbTO8WBf9AYENNN/Q4 xbUCLEEm32jfdYN8o6QutWJeh/wTVuxMxOk5IJUyYlUpiFTCyCwD84ibhv4LOsYaYiBSLVvZ1yYO 7qBDkEhBRwQAMmKpjgP0LoVUdCBC6WyNmwkIzdZhh5siQJIdqXsVwdQD74ui6iOPu5nqThj7NI+Y +LZprAsI3vK1oUQfPRZwoR3L6JS93Ffz/C3FXf63d9newcu4n5ItO7U/qLqf0/j/0R6OK75d1ToE wMPPZVtV0SXcDwOWsN4mJd27uHH2Xvs4A8gzu7yhi5fRMPH01QEb5nmUMY7Ep+dSYWVbQ9aIw9L1 i2lu1ihZue5xsU+dC3+Hrd9JNjlLEF1+bWHH2BcLFNc973xskqg82qwx1nqFkUpafE5APNbGx8Yp qhDL9GTrHFbuVyWoVBaURPpNCM3r0YgNF+Jjz2W872TWrUfR+H6UcEbPq9RNyp7ivah0EYcCbhYP um5rJub1A8xtwsYfKcX9YAHYYw0IqeKMnGoqeA9nALErbysVOl91uh3IEQCwSyUGXbONr6JftBEN DIBNj/cAOLf16nP6HrlKhUJlLznmG+3ElPBQW5I6tkzVKTW6ZzjsRRwdWBE51niq++zFkVBPuXir 4VoV3wII+9rj1wBWejK5iAjpreaM4DHBG0U60jvEs68Qv99gJ6TJH4Cc54Nf8fkbJWa6q2VuZHN0 cmVhbQplbmRvYmoKNiAwIG9iagoxMDEwCmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGggMTMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydl21v4jgQx9/zKebdtlJLSSile++OPqyQ aLdXclqdrvfCJBPwKrGztkOXb38zTgKB7ukCRIWS2D//ZzwP5gcM+gEM+Ko/47x39TqGpe0N4Av9 LXs/eoEfAPVHnMMkokG3EIQQpb1qXgDhEMbjW4jy3tlUOTQK3eW9EamDw9c0fJ3D63QC06cPz+j1 e2FkBuEguD6PvveGnyGa9c7udLExcrly8KydjPH8Uy+88U9oxu7h21n8du7nwvQheoTIlNaBUAm4 FUKBxmplQSaonEwlJiAsPyFaMGxoiY7LnAaAKN1KG9snSVkGfgELBi2aNSb9PQXRStrdRPrflovv GDtwGiZ3L0COaUTsdH2yMMOlyPZWfzF6La1kma+YCSfVkiF+1n29gKUZPPbtbOVc8dvVlWMcYl+i S/vaLK8ycpGyeClVqskhUgGmKevRyotIhEPQac0pygVNoLXoqU5pQMsYsv4lQ2GRLF9LfOfp9CU5 kBILg2mZZZuL2qUbSNDGRi4QNro0jfvYC+RCZ2TsvJHv0q34TkHqahaZeyjhTidIb3mhFS8K+NMZ ETvawNTofH845OSMGiVVnJU0dS7zIqt2fDK/h1nlHnDEYb2N1IQ9NUcvDa77LRex06pg8lvW3iY2 iayHgm8lxGCTdOngXRgjlNvQCjVlbx1G/lpXK7YischYBhlPSbXzd0BOoTQzOikrtdA/8gIY7gUe MwPvarXm9GDTSttIbfv3v4mjWl1IXzjBKczE8cr2WUwLGh6mUslj7QW4abG8NtoeTiyprBMqxu60 fdawZuGJNo5brGu68UzxuNLFSazPW1ZFC1o8tynQdmcFwQErbLEyyRXVUQYvyPD/o1KTOGANW6y4 CurOuoYHLPbZnCqHpIxUFdN220ug7lKx/B6iSDge6mKCPtiO8FfDYj3fjGyK9tGkNmvEftLcpqrK 3H3/dqwmh27q/PliRJ4LczSpzWKaz8fJ8yM8apNzdWrAJ7A4tv58mn1AddQVDlos3su/BDn/ngvP EzWNjKo2oodf8nGjG2vMmqzfRd5CuTjacxDu4n7s/VXxqmpRULNEgx0rzz4r3LISmXqKa2K/Q563 WRWNtUWlUthKoeNtrFi+tmKxPUzMuFacyOK9/IZ8aqAexEWnY2Yza3jA4rykju3qzn4E7SNr1K5f K0Et5HRdnJeVGAr8E228rXNb0+m2LhTCgY1F1rUrQXi91XW77bWGauIJNWeP1ZwDuCZiZ9t+zRrW LFz7EyCfutReeezAGoX+tDMRK5GU5gKQOlnW3/7yePhZSDqKwtfY6QUaCEcX1W+Jg9ffL2KJEP5D xIeo9wdd/wLOwhOqZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagoxMDA4CmVuZG9iagoxNyAwIG9i ago8PC9MZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVl1vmzAU fedX3LemassC6efe0q2dIq3dlqK+rJvkgAGvxE6NaVaJH79rMIlpoUl2UQRyzj333A8bnmDoejDU l7mHc+fD9AyS3BnCF/wlzpPjVQAwt3AOlwGCzsHzIYid2s8DfwRnZ+cQzJ3BhCsqOVVHnyWJFby2 iT+9g+nkEiY3b/5DGy8ky8Afesf7wR9ndAHBV2eA6xcuwB0NC8nUC3wSPGcRlUQxfAJ3qwv84/09 xxs1jN7Qhcn4dgxb+ncxniBjxeW5MA4fuVhmNEronHKV78Zrcfmoi8dCzjG9ZwpTGlNJeUi3Zlxz jQuVCpnvwTiKJM3z7TnWXKfI5Z9WVcMsUZqSIipCXXoTZSoKxXgChEcgzXNc8LDuDuNA9UhgY3Na YUIiJaMScEiWQj7mQCRttUZJEjHtTbLsBRZU6mrQSFMZH4joM8OSoKCgBdbxqcyNMlnwlaKFFEqE IssrDSqlHf88DEgmcGXJVAq5wgaEhikUPGbJwz4sxKLIiKIVQ5M5a/olOMwIpvkwwBFHtIhXkah0 DVegPXEHsBzmhJMEM5u91Hy4Wi/JlUp7DZU+4+BjCoaKC6nSo5kouK4OxohJiNIEMBzAMGPVIDKX uj0JK2GIGM+pVLVQ3TOkMMHdteBGBhYjLzJkbvShVsMT0bASmIqlloGREknmFRBLtCQy6qnXtVUv w5UiGj2ork6THGu6oxmv15qMSkmz+lBI2cKwzHBiKOXaAQNhQXBYdIo55CiS66G6ZkmBYTx3Per2 mXRwZNtBz3JrgldW6vLUjcBjsgS3stbyLZRG6u4RW17Gfnedq7jcAy+74W80dWrYKGYLRsvudwra F7O0Z3Vj+O78N6EPWp3ZhC6rXVJuid6Oe7eaWNY3CLaSN5Cetr8buWey3o1zv9HHmpGebdIr25JY WmcHeF1KW4gbS2kJdosqV3dlXYi2a1kdWyV01+cV4t2oHa6dUf+nTOsvL9uag/KjtcMOYX2W1e9W q3D6RXziV1SXJCVRgXCqgGTuivPq74Lhtwl8C5WYYan9k8Pq+++1xp/fkRBGv5DxKnB+4PUP4X1l 0mVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKODA4CmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGgg MjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFV9ty2zYQfddX7FvtGVO2lWsf 40km1UzTpI46fYjzABMgiYQEGACUrH59z+JCSXYv1tiiBWD37Nmzu9APulpe0xW/8ns9LC5vX1Hr F1f0Hr/t4sfiOm6g/FYPdLPBptd0vaJNs0jnrmn1jF69ek2bYXG2NkE5o0L11okm0OOf9er2M92u b2j94ckaft6MTve0urp+fr75tnj2M21+XZzh81s7BW1aGp0Ntra9J+EUadMpp0zo9yS1D07fT0FJ fExGhAkbhJGkRN2d/7S4flZsOdhSjgbxXcGMwXapRoU/JpBUtfbaGroXHpbwEDoVT7B3KYKAqWhE 1UpvsaVxdiAdPI1KOb8k+lOHLp4ScssmbUNG7eAQXnq7H/BZtjEKJ6RuBx9x8hGj2KJ15EcAEb3+ C/+Lcex1LQJg+QvexpHzmWxGDcq1DC+eDpbaSUs1A1fuJz9H0EymZkP56Jd19XapVWgqvXK+Arv3 vRoqH0RQDPQr4tkwSD4jengIO+u+V1Jtda1KGDknVeKMkzvaceojYvJT02Cvj2EN1geavKIaWz3t OJZs5TiB2Q3V1gRne44WhyTA/GJ3agsuEwusgdlatrPrdN1lMpMVOyongnWe6slluQgpnfKe7vfs pNHt5JgeDlzXJcVMHhgfLejXKmWJo9PDaF24VA/8Rm7qsXaklCSDzVFsnK3eWxLUOrtjRz2iZWUc uIipAPigUi6wUvHK14vjXHUI2Z9uqLam2tZfWfUpdvEkchp02xXV7QRECZUgba0TQ4TNUc2KZ5XT ZJxCBpOgvk1AmyWUrdyd7aBzzVGLUBxCaNIOQpu7czDwKTkYON7ipLZTL+leJW/ZFnxaTihCgEiG ohsOxZ/UHmmTK+ubqGO5Rm9kXbbEi70VMQyPwEWbekBthxGJKedbVK7JhwH0IzyHBC3b8UgxVAKc ovDEsGqQt+e01U6JiMoa1MLALuTeiAE7LOTZi72feVLLdknvb99RmIxRvb87h92wU0BQYHUoC58p RbhoLj8m7QpvcbUEaKE3BHFUk+5xa4zkr5tcIztwKFjYRgonuaGUsp3uoWtunbaeuNiR65NYNXfy BkSzV8Hpu2CedjGFygi0imyqmVzMX5YBozluWkkjpeQEbYVDz9ln/VfH1fu/DQn7Vi9LJ3/zH4CL 4rTZ2n6LAltR2I9cqU2uiwitOh0NCrxym+SmXixwdndOR5LvzhAGHi4HK3Wz5yepesVryGtym0PB 0SX9e1nHFuAjF3byByJyEScJqHnaQNPAcYlaZigK08voucfapoBdnvCz5tKQ3C4tChoPUQbwgHSg J6EaxGFExPwOCgqUHuC+K0w0d0pPkRh9/u3DJ/qwvkk90Xd2RzADLZNHaUDZeBNj1EFq0TJ1RF8C Kn542Vg+JnoW1AVKz9RxeO3jYt1rLnSE2uNQ3SFsnwZmtsSngUtgrG0BefIdkjTnL0WH1BzOAsnn RyB1kZ9yDgzDnFGwMkMpwaXuhIaN0oW1VsEwEwAu0VDk3Ibm+wR83Uy6j5qKFZSUxcTOXEYaYeHI 99yFin/sSQ3QqRFFFBkp5+PnjIKZ4M3qAWSUyXPUUWMV7vgsCmUukJiYCWMuNvlWhahzFlxlDboD tvyDrRhGEU+cb4TRhGEh/PdTDb6J9RJHuUqDp9RVsmGAl2+M6GRY12gLTC86r+QkBCvF/kSDkz8M 6nl2J1BH+gA7W1yCJA/4DDJlyC9zNEc3CYzHB66hWBfZe6xvnS6TBXDsWz7hPsk3gkr/zxe5pO84 Ko6uFzrMV4G8/6CUbGrTYUe6mmJ35LSJdp/QdDTCBQ1TH3R1AqpcAmKVA4VHv+EMMMS0sTq++WKy nSau42pyo8UNJfYX4JLxSo8H+I431GafLtAHYYA31UfIqRMeEpe09ocvY+3JqQvijEf+uWaAWqog dI8k5Iv3yxfR2I3ohJzcBSlE0y/nLw/vHka0TE8f62DvkdrVi4v4VeLxl4wvn/he8JxnybvN4ne8 /gZ0DU5PZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iagoxNTA5CmVuZG9iagoyNyAwIG9iago8PC9M ZW5ndGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVcFu2zgQvesrBrls AiReS26adG9O4nYN2HHrKIdF0wMtjWU2EqmSlB0X+/E7Q0mOFTdouzIMUeLwzXtvhtQ36PdC6POv uSdF8Of8AjIb9OED/bPgWxD6AGhuSQFXMQVdQhhBvAzqdSFEA7i4uIS4CI7HyqFR6M5ujFg6eHmN o/kdzMdXMJ4ezNE1LI3MIeqHb07ir8HgHcST4JjeFzrFHJbagFshr+8BxCvhIBVONLOJrvKU5xUs ECqLKSy2IBTgE1MS+ckfQThoEVE56bbgNJRGZ0YUIIBob7R5hBTXMsEexUdv2/iY8hq0DvSSckgL qU6qglCAxtpkQsnvlFFYYpnnemOJ4R0mTmoFEWQabSe9VJSZtaTohMwtw25YUKKVJWaVQ0vcU0iE l9OQLCiFVESVLSBAhvpQSZIvFVpvkEGRSpX5xRsjHY8b00AYj7SmBR7HNgQHLRYvalm/Yb0lP6wx 3+7JOW8xiCGsZLY6y5FCYC1xQzoaKM5Jr5WrdSjt5FImghEs+cG0lkYf2s4lEaoBaUvXlOuUJ6uS io41fncaiJywW5WsjFa6si2IZ9Gra8g2eCeF4cqxQOJV29EKfEuxoydRlDnaZ0GV3beyxWBL7Upv 1D7AxZ5bl1TSNZqWDNeXrDONEVyxEg3dCkZnZF3uZqkfbCLy/VYMeyGBX2vFonyQ73RK3unKJhsr fsQtkL+phaPp/V18dFrf4Xbmx/PRp/vxfHTD47u/h5PJblBHdNqWJmb3kyaWR88o17PpdHR7UwNN h//Qjet+NPsYj2e3w8lRy7Ghtts/7CCVlZpc8tlRGnT1RqIGS4xc1Oo+z99fR2H47sueFxE5wY7x IbATzEVtrG8B7MudJpojZOygEI/1xtkIk3a0GlyiQZXwcg168ZVQbS2i2wIPx7vGeTgh1OHepmjF eialD/IHSI1AzeD8DiHSJLjuowXS8dE9fF6/jK54h59JOjUEcW3yvX79233qKP6dVa/F93u924N4 COnt/6D2/AH44eX7ZSkSfDi2Dyf+FbnqH36a7EXqX/ThcNVvxXt3fq7r4OIqY6vrV9oC4L3MKtpY 0V++0fwX8gdsm6hBHTVtovhTThmuxEqklTkFpE2a93aLRk+lpE8DzBKnF2ggOj/1n+yXFD5/FBnC +RdCHMXBJ/r9B81DNtNlbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjg4NAplbmRvYmoKMzIgMCBv YmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VZNc9s2 EL3rV+wt8oyiWvRXMj3ZrtxqqjiqrPoSeTwQCIqoQYAGQCv699kFQZGSnJmeeqo1Hn1w8fbt291H vsLpcASn9IrvvOj9Mr+Cteudwu/4v+699kYhAOIbL+BmgUGfYJTAIuvV50aQnMHV1SdYFL3+RHth tfAff7Ms83D4N0nmDzCf3MDky9E1/LsurVSQnI7OTxb/9M4+w2La6yfD0RDCoVRkUksvjT750Esu w1U6FS5KB0yD0F76LficeeBGeya1A2sqL9ywEylTCsykSGG1BekdAo7OGkDNCoFgKbAmPkJh+Eb6 XGq8QqBSrwETeKa5gGX/QXAiB8kwWZ4MEZLAFrmoAb/8/bCAlYBKy9dK/ByIeCoVSQOFRKS1fBM6 MGqgTIaVCnAE77clcRDD9RAms7dzZAAwZjzvnlBGryOaN+/l/l/Y/0bYoyI5apyzNwFFpbwslSD0 Wtr3YvdkFUQ/HPYbA8ZCYWx9PohxUArWFiVoi7psZb2mKMmZwjQO1cwFYqGiLlAkmR12C79mlIjI fvSmNMqstw3TiLTsf5vf3Z5/Hl08DYA+XoyS06d9JXY6RnBTUqOZUltgzhkumY+zgaKO769vpuPn yex5Prt7vv1jfPvnng7MeytXWFo9pkKzlcIy56iPxVJKhijIesNsSnou+wizPAGeC/7iAOcL86Ia kX47JwENSZIN/RssUieo5E3EKi31yIMrjckonpZAyUJ6KJiSXJrKgUfLzCTHLHco7WSGSfiL8G4Q Grjj5UxlcQhYmlrhHOVSxrxgtqoMsBRsywyJoxVnjItl3yGzAzmbYaVgKjS0MxSKiY9TZKbSKTKb 1IshNTcF1bFjVXP94Nq0WJlHOUjY3UId8wrF6f0Ka6w4Y6QwuQkjQbFH6ClEMRUOR40FW4g8fwWD MHYjnRh0ytsJSYCpdDwAdsYQXYU6e7Blu3U4XL9BPRIieJf47pvagqNpZFzUrAqTCjUI9rk3pdwo Ff0MT9KWDlpN8DP1sMlZMot7i9f2nCBSa/3ACkajynAS1mF1Hc5UKzr119a+q5TZkApZhmutfUTa O4Y6Mm6NIzwn/M4vLF5Ab8PGF+i0HDPWeylwhSNO0B+ZTtkWE57Bo7S+QtyZlW8Ufy/QoOwLOc/j 7J6aX0cmgF/p12kSfo9wxPgQYoo+8SDsmww3hsfZ9IG2rjaPoDhOCXM/UYpUvDeNP4TwsIxdGri5 9W+HfW9q1OhN4agL6oajH8/IASY3Yc9K7G7gnhpsijYxE/60BRWikx2vdlyWfSVfBFzPZwhS85Pr 3FNdh04Y0pJS+15KN8TYsHae8GMamoX3glyi2XYuMXuEvTepwfXfuYsu8nh3oVJltoXcbFpLiDZG g7/zv5VoV5kmubGpozEPS2WNii7TyiN1Z6XjrXERYuhY3Kfj6vFbclSCi1DN3Z4gdYXej+fJ43Q9 yICzmoaF7JhaOHP/lc613u7I29EV3kkVaFbuvecatDCO96sdna4i3dJplDoKHS5nWy2Nw0USunfD cpZWdgAYw9Rw94Q9/l5K5AtfuTcrGvmLQXjePnwS/zZjawGXT4g4XvT+wtcPJL/ZdGVuZHN0cmVh bQplbmRvYmoKMzMgMCBvYmoKMTE5NwplbmRvYmoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicfVXbctpIEH3XV/Tb2lWYGPCGxG/2hqSoii+L lYdUspUaRi2Y9WhGnhlB2K9Pz0VIgLMIiqq5nD59+nTrBS6HI7j0T/rnVfZmMYWVzS7hE/1W2Us2 Cgcg/fEKbnM69A5GY8jLLN4bwXgC0+k7yKvsbK4cGoXu4oNhpYPjz3y8eILF/Bbmdyd79LmpjZAw vhxdnef/ZpP3kH/Ozvw6GN04oVYglHVMcYS7L085cK0cEwrcGqHUUuqtP1MxVTCnzQ5KgbKww/M/ svHbFksTi/un/Ob+r9mP+5u72fVr6MKCKFA5QQgFLHcgnAXFKhwQ1mjSYsER1hAgX9PdQG6J0Cjx 0iAwbrS1wKQ8iWQJLyFRHgxWYoMKSMCtNs9Q4EZwPOFvxPJCCuuuYzT6egH8CujSy0uxrNVcMEfs t8Kt6QCdSsGPU2i5EPsZ4+tTNThTsGYbhKqRTtQSYwynO/IGa4OWFAu30XoihShLNH7N7Wq0BP9R G8CfrCKIAWiFsNWNLKBuXIc0f9xctSAkiT/lDUM1hbvHz0+9LaY05W389qFEr9nl5utv3KJrJ7Ri smeWJLPwXi4Zx77Y+0QPRd+f7Ut/LPRJJfrS54S2R4m4a5S19bStM0S808hHXuqGbG5E1Lpm/Bkd pWW2zBQETYiPYc0DVCHRkLnFvuM60gapXga5k7tXzIPJmJ2DTr3zSgJJcYLvhGrbythBQO+w0Juv 20/dQ3zS2s5nQVbcBzlpjMXDl3y2+DH/cB3YBKuYC1HE2nbYsXaHXQZB4IN6efpGS6glUyk3xr1b bNQl2u8QxrYzIITsCeX7JcwES7KKMtqfBR9p2AjjGibFfzQsoF7vrOBMJv4+cK/T9j2Y7qRTtu3e w+U4ikLzsiRor2lbfYY96f5neB1lCn1LtqOr0BVVvFeZ8XDi4X2odDq2ZxiyaH0rCQIn19HgdpQA qV4Ir3Loeap31LzXsiT7QanCveTAYwxbI+9K/iwIklwYCXw/88NmEObKIJFDx4ffz0Nof8FicG2c Db5SEV8rP83EqqG2mRzNhHaAbMgtJJo3UdgiGBYDB3WupoH+LVuzojEDCkwaD/evwtnPmtrRwgN3 ekl1HP85CC/G41fmt0e2Qpj+Q5CzPPubnl9EXHIvZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago4 NTcKZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCA0MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nJVV31PiMBB+71+xbwcnIC2KHm/qVaczh3KlPh03N7FNae7apiapP2b8428TSqlF ERNgt83ut5tvN+EehgMbhnpWMsysQ/8EltIawhV+l9a9ZRsDqESYwXmARqdgOxDE1srPBmcEJyen EGRWx8sVFTlV/e+CxAraw3P8OfjeOXjTrTUcZ4VgKThD+6gb/LVG3yD4YXXeMmwPwUtFu1/2M37R E43t0Qf4B/31OECXzVP/YHeol3d0E/Vtv+FgcL3DD2xcR2dnvJWy2XqfKCXYHWr1+4yoMKmfcvqk El70UyYV4nyCWtiPq7bDO6ZrEt+Tu6h9+UDuiruX7xvs1sObPRxVcqzldPZjbuTZhXmt+z4mId1F 7qJzm7OQSHU4LVNltEUXHY6dPci9ZMtSUBhNwNcVh4xHNH0VLUiYhIiHZUZzBbKgIYsZlaASCjFP U/7I8mXVF+q5oHLyas98tckJTI0FzyGiUrGcKIa6NwMSRYJKCSw3kIaRhJKIior3FcL4MwjjLQRN bAOBrJhOyR1NgSjjp3gBPDZqY1EqEv5r4JxdNGB0mZrJVJnQOheKP/ri2t7RurINNJaHPNNksvXi Op8Cc6CqyQdk61o3ABadeQ+uFl3gAvWvRu/BI6ZAYQ4kj+AKiNAMtc9eIWjMnqh8VTqXIKy5CGB6 Ow8gIQ8UiJQ8ZETRCB6ZSoCprU7II6K4eK6vz02k+j6Rg3aT+De3gftn5ruXru9eX7iTVePhh0CO vSdwsyk8kLTESiVYMqIDSgws2ptBFgsidC4mA7QRPIOIxTESgT1cCK54yFM5AJgrrFyILnmsT4Ip 4+a86+ip5HpZMqwfbprU7jr0qjqlKLisioUueDzSCLE9tTmF5yQhUSl62BEIOajPn/tUMGwZuAkV v6MCnOOe+adqn9NfM7KkcPobEd3A+onzPzDFzf1lbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjcw NQplbmRvYmoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicjVZNc9s2EL3rV+wt9oykWHJSJ73FrZPRTBK7saY91D2AJCgiBgEFAKXo3/ctCH5I dppKow+Si4fdt2938Y0u5gu64Hf6zevJyy9XtPGTC/qAz2bybbKIBpR+8pqu1zB6Q4slrctJu25B y0u6unpD63pytjJBOiPD7HcnykCnr9Xyyz19WV3T6tOTZ3i92zqlaXmxeHW+/jq5fEvrj5Oz9pHy JLS39Gjs3pDAVVEro3xwIqidnBX4K0wu50TrSpK2e+ko4N9O6EZOz19MFpcjOH5SqU2VjLZOltLJ dv1760h+F/VWS37oJOXCUCYJ37f3d+/J2SZIICasEvaLt8v5xXw5X7y8XNJehYrECJRsSa+BvCpx O7cmOKs1tt46u3Gi9gOWaMH/J+Zyyg4a/hogBvwXPqHtldYcQLvayYKyQ4ybU1ELIzbSzQeEu2ET X9lGF7y28VgWLBUqDwKYmazETlmXCKsteEqsjeKBk4PLU/JS0r3Mg7KGruYL3nP5S5eWG5FXyWEm HPCg3HubK+xXtAyoQNYg9rSh3TKU0H1KhiSLEJzKcNcf72KpNZ7tpCmsmw12v9Kf8ZaP2/utzFV5 oGTWXqr8VEjDcjCkzAa0Kp9EWMgglPZMAt8dbFnN8MGrYpQ3zofP7Vb29oXNm1qaMApgOX8F8M/y e6jsNq19R6a9JidBtscKz1q12VdQjZu+0YFdK52te4Vpax+bbZu9o6BSEqekyhPjBOVJgR7Q0oYL WYn8UQaOCAs2qEaTPFPcDUrBme90+pyvoRJhsD1OVwrVdzVYNlof2BGrdxCF6R5DEY05vY3o3h3F dmoAkXEnkd8alrQyKLtaRHVC6RxidBmBbSwH2waagoNFiEn2ILddhKoCwl64SE3UKieiD43XCFSQ Q170IeGgXg2uo1PoSFlfUn0iRO9uXL+FL2EW7Cz+OaWamTheYGh1hyALBO+TRzfc19CmR8vARBfY UZZawphJ8wzDrGRvawm9RjGIzh8HThGnP20zsYVIbIruHdsrlSoW8GnqEs4PiMi7tnQUXaq78XZ7 Nux9intQZffshpPccKL4BogpyflmHucNOzc86DGwSGQYDRnLcNNo4dhqlHd4jGeCPt19vKfQILs6 3ctsqLrAVuUTaiBxY0Pv5igPT+und6cWysSKFEf58bFJCygYkXy+XfPgwZUqRDtdetnAUOtWvqrd 4f3qmhXYhMa1/sldLFOuwFxgDhxvlZBGitvIMOTz4UyrR3lKM1LHVIliJ11Qvp1Iousbqw93fTE8 nMOZ36yBoZfPlj77Fc8GmcwhxYQx4uLhLOZUsfs+tlfR5aWt6wJniofzyFYVx15UDRmbsLQ1nJ9M Dhx6DjSTHYHYZcTeUQf7izOH4LUUPk2vvrFiQvdhIE+dx6N0Px1sqRF28zgJL/UmLoH7Jq/6zg1U NBieNDz2pVYbBfEOLewHIXTKiXRgC4ze/uzAPQVdk81mCajDbTc9StiU9pEAnEBG8vUjEki4Z5IW BTOcBowdZeG/Y09YzzOArtP5+tPoE9DPOBhBduGnLtQX2TBXaltAdtjQ7uOQBh3oxGiAKDEVDgyc ToUtmAd91svjIvNoGYdIxMAXDsNBAfcwbyWHonUnPWFoHa+XUU3XohJF49DzMLn1vD+H33zfxt59 mwebAWb5ehpP5afn9b/v0Lfo7T9AvFlP/sD7X28++PplbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2Jq CjEyNzkKZW5kb2JqCjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1VTY/aMBC951fMraAllISlbHsr6rZCarctm1u3B+NMgivHZm0HtlJ/fMch FMIGxKJOFIWM5735sPN4hEE/goG/6icvgtezMeQ2GMAnuvPgMYiqAKgfvIBJQkE3EMWQZMEGF0E8 hPH4BpIi6EyVQ6PQhR8Myxwc2jSe3cNsOoHpl2drZO+XRkiIB9F1N/kVDN9C8jnokD9HZ8Gg1XKF aQ/cAiuSgimWo4G1kBIsqhQYKO1EJjhzQivQWRVrWYHdV0E03PI9dCwi3COvokbw0O3Tevxmu54Q SK/QMM/rTMldaRAYJSgtZfS8lAmf3EIvQVhgFuxCrxUI5RM2cmUi9+A5Sr1uZjnLjC6dJ9wN4wz7 06jgHACdgv7dC9LUzYdSWPfSpk5XdxU+szYXcTTRETXgGzm3grbc56NbGt4fSVhgMaeT2WJ2iVww GdbhJ2d+elJH6thVwhdMqIsS1MM8jt1Vf1nde/6rg22+6AAc7lzLTra5/hdJcxu28xcpvWBOwmVD 4YUxYxx9gNQ5SZQMXakUygqz+Rmi4uzYVHf2caMp1+/grhahQqcoa1zts8CZIt0BkaLyoogpzH+T iu0cBpwGbpA5UjeQuKJidNbYPKFSYTZC2d8I4x6apM+i86yHkuy10iDJpsKU+EZxxTdhC5aWpgcE YrL/r5/bpyUlsfCVO+0/m3jUq/4FDtr+8c2LbzT4SYy3SfCdrr+FLHL3ZW5kc3RyZWFtCmVuZG9i ago1MyAwIG9iago1NDQKZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nHVWTXMaORC98yv6FrvKEIOTdfa4rni9VNkbL+Daw2YPzUwz o1gjjSWNMf8+3ZJmwDiGoihGre7X7/UHT3A+mcK5vPN30Yw+Li6h8qNzuOFPNXoaTaMB5K+igasV G32B6QxWm1G6N4XZBVxefoFVMzqZm0DOUBh/dbgJcPyazxZLWMyvYH735oxff7ROaZidTz+drn6M Ln6H1e3ohJ8HC6EmoBdxjhrIBBV2YA04eurIhwnAig3Ec4kBx40tScPyr28Pt1/Bd21rXTj9MJpe 9B4RtrgTv7YNyrJPvWNfBaln4jPDkWrbgiol0kaRg411fFDxuemPJ+xRfP3JR/SCTavpjDERFGig cITh0FeoMUBrlQle4iJc3dxDS+QS9uzLUeiYv/JXEMQt02BgTdB5thFMrbOVw6ZRpgJnu0A+e+IY MVpPnseGBuQANzGTCCpk5ho0WHGcGn2GX2ZfHFiZUjFBQlaMG2/2KTAciS+O3uI+A7WRox6XQ+NF D2gx1D26wVNRo6nIn6UA6RcHT8ZbpTVnnz15wkaT9++VB5oSWNhMy4EA6ULCn33F2NE9dsE2GFQR a8IHZKSVlfTsM7mc4/Yojb4U/u6zP2ArcbPng8m1nS5FRWxbrVhIxmNsgB+dD9lRZxiADz2dzMe6 C0BRMzs8zSRZE5ApYrKU8TFtwz0xqDdYfz9ZZkyzyafJ9PupwJ79FnsiPpnsMwi7diilVa08lLbo Gs4BfEuFJMKRgBnZQUWGnCrOogDGq7WmCIIJ6JznOnvVebFaMTVUj2wf18cqjxJnYHzFAjwc8QHj JGUsO5sKlNXfYNFXB19adcbwGHjvDoR4vrdfEMtRYGRIKx/khnyD3RxQbmFbqyJWrssXON9XOUpB YfFI4TiNf0lVNSszuBcWtMVyvEaNpmBoezj3zoas16E5z0jmb/dxzRG6Npaf31/q9cvFkK7EH5J2 TVhyBbJUk2oCd/e3S9C4Zo5ibSPcLK6PE0lXjhO5jYCYlx7ZIHYq6syijZ0PuLbPB7rMc3e8r8zb KbK/vZT6w1eyRlpYfeviHMwVWsCWtB6XtFEyUTediWT2ZM0DcFnTCxuLIrGVZFzw9tpa9wglPauC qzxOhRrjYtCqUUH2Tm23Mi93r9jS3J86sWKtaJNquYfGQWJv2hSnRldu0VE/1ZglTfvhnbdWNH3k eeIPq5AbRiZ2gS2ulZZhZ6iyQSXW11TYZuje2KOqEWfI7ZuGN2fOE96zcZySx5vz7mG5yjTuYm2L I9mYcQ2aN6OW8WpCZ0TpLuQheUjjhx7NAJkHCGdxnfZmTG4ru03gCLnskXccPKNTtvMDA8cjTfjz bC/9D/10u5zMJq8K9ngQMKcc4td55IUqk5+XwH5G7GXOTZT2tqNeZZ5PUi3xkRDgqOH+zQ44QDlO y6e0UZrPs+jvCmssO16SJFJPhr9C1y8t94iHb0Wwa+7N2eez+Mfo6B/Tf/e8smE6/Z89Xq9G//D7 J1fQKaZlbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjExMjUKZW5kb2JqCjYyIDAgb2JqCjw8L0xl bmd0aCA2MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nH1WXW/bOBB8969Y9OUS wHFj97tvSeO0BtIk57goDpdDQElriReJVCXKrv/9zVKUZCfBJS3siNRydmdml7/odDKlU/kNn3Ex er38QGk9OqWv+J+Ofo2mfgOFj7ig8xU2faTpjFbrUfvelGZv6MOHj7QqRkcL47gy7E4uKrV29PRn MVve0XJxTovvz9bwc1ZWOqfZ6fTt8erf0ZtPtLoaHeG5sY7qpixt5SjZGVXomGqdGpVrk9L9EU/S CTbR1cVtv88aUpTZ2t0fkzIJaXP8x2j6pgvpsMQUq5prfGfi3wJc5cTGabejQqeZo60yjpylsrJp pQq/0zXGcI5gEiZjlXAlh0XWZXg5qcmu9/ZNiFb9H2RwTGZL0jU9culCkJQNV0hpqxGiLjnWax0r p62p5eSNTjihta2otgUw26KwJt9RU+NxG7iehFALJ7H5N4I4Wc2U82AS5dRJYRNg2Oo8p/YrVuoe m9uVqIVgCLFwUJmzY1Jx3FQq3skhs/ddBa9DLnGmNIDGCjXgAMqGNFDHJncaYUKlUJ0N6qWoVPEj u/EBJxEjSe4XJRM82KoK+aOON4bBumBCgsp/6rpNESX/fnt1F4D7I74u52PaZlyxNr4EIWimaugB ckDN/Usdh2ub53YL9NGOVIiEIC8uG1rchoVAsG2gnwJyG1aALoRJUIukfVWQwB9bWz3i8UbH3IJU rQz3AYlqBwAhlEKBgkSGgLE1rgI+j+YaZmFUYPfsHCE+4i5QhPoJUcEvCouPOujXHHIrSJCzqiLt KiWRmyLqIWF/QOy3e/5TBq6uNmL4PQHefbv5cXXRKRt0b9UuhAIeaFeceYBAXB6rUkU6F28GyIEL SvWGTZdsX3FJeU+ws8nbyWwyqDbXoEo5V+kIzHVEXcJk4eSgLKl3MDS0WMh35V++P6rvj8d7IYID DhSt6trGWglUb25WcUYFS/G6qB4I8kbpxfTsH4JMf6wyAZisoloNGtTz16XMWzuwt4cJ8EOEXjSf D1xsiW6XN6v5l9Xi5vrhdjm/nC/n11/mn8Gc7ttPLaasdAHuX0fwUSMFfDzMFT9lxWto2aDyLfPD A7Gqt53jFOg3Km+4rXCd2SZPpHfU3HXEVgpTtPZwKpo4qJnhQXv8/bFvCOiCcI/x4vUeb3f3HA7h 1gqTRbcmg4bX6LBU8UklvpU+iS9p5ldDfl0In4nei9RXF70N1EX7fpQm3WFpeaoHxUgGxhoeQrUc FpOnjFzdnF08nJ9dnYGIh5/zxddvq8AH/vkOKwflViUnkcqViWEQ4JyLuuSkp7wEyXz/cbcSvFAl hieiwHrs51wE8zDqOPVW//Qp0NeuDngTliYHi9eh2lZ8iDnlMwlVBXGeS0zO0OtDKYc4fQqhvYu/ pS1TJVOvk3bA5v9C3s+ieEcMTbDd3tY7UNBbuYvh6e6N/b+ApAQY/Fx52/Mvsd5hxccY++jYZ38N cbqpp/bAvzp99YIuDvXFrSGGQPKS4MV8rjYB20sY2qsNMi7LHAIcdxzvybVdEVoEwdPTD6R31rdd r1ek5kcLOjBxzgUoDV0xUxv2N54Dpb3YSDzCFwQtbkfuP8W+/u6016pwMSDtgFVh+DRGRosBC8je ghB/M3ppkIZOIhUKkdo68YHrW1GiFJeL8xPOdaplEh5KBSO1qdC3Ou1D6Q43Kjl3r8dh8f07n/y5 ylTSVGNiGaST/kI7/11qcEg3sbNS9tm7sb/ePrn3/n2rUsal+h9EnK9Gf+L3P3LCr4llbmRzdHJl YW0KZW5kb2JqCjYzIDAgb2JqCjEzMjAKZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCA2OCAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1WTXPjNgy961fg1qSTdWN722xzc7bujmeS bGr71nR2GImy2UikIlLx+t/3gZRkfXja0nHsUCDw8PAA5o2uJ1O65lf9GefRT+sb2tnomr7gvYve oqk3oPojzuluC6NPNJ3RNo3CuSnN5nRz84m2eXSx0k6WWroPv5UidTRcq9l6Q+vVHa0eRs+wFkWp MppdTz9ebv+O5r/S9j66mE0+TuYTokf53e1NQbFBDO0uf4hmv3gDPujI7SVl5iCto0y+y+yKBOnm iND0IslovNNbnOQzhkglcKRSJctb2u6VJfzA9LRNpXQV8kno5egjILWDKV8pke8qlvA0nTcYsEpZ lNLyYb2DI4MTZQvClKOteC+U7iUCUMsv6+Vm8231uF2uf198XtbQWt+ASMX+aFUskGRmdvyFvb+r 0lUiG4JSXJJUxJz/mRzA7CJJ4JpDWJNVTsEur8Aj0IK2mi6f3lulSpDhHTFdjWs42fY2KBdHnM0M iHAGiR87bkzlCVLaOqFxeMjA6olEgHRLC2/OpTWvVdFGPplwzRKuLMIkEuFzpUeF4bTlLph3MJ9L 3ONuUz2hTmQhdcK4axpPjnr4sX6EZ02mYIcoDetdi1x6GYrMGg5gCxmzxBLGreA4FsiS/cJ8CN9X kQ57Fe+9ST975x0yQfBWFcjrqw7BKutdnpLAatEgeOajJ0g0Dg1UiPhVOkpLk/tuSUwOhXKqpuek EXJ4joh3RxCUiipzTQ50UFnGwPhvywGF9d+N7gNye+HqIgfBcEYjTQy7AhCSnlC8/upGR94JMxYL Ky3JyW4yZPQA9PIMl4IypV8/ZIZ7qt7/f1geFp+7YMZ6Cz0FdEIP0UgmE235X+IEQO7Jtg9TdD23 w4nPerKMILtKa5mR1LEo+lzht98dDi8mpj5lyiHgh6f7zekpeTFYLjBEoHQg3/dpYuIqh89JryVO eEck1ajOt0fogJNxV5VAnnQ1DEFBan4wnakFoEEkaZWxEnS/Sfrz0d83ELml5ahK1leeG0VLmdge ngImpsxbcXXKGMrmpRfAjsrVTPVA8aBggf37zZO/UghibErxfNEWY1ixf6nN8+VVaMLuLROuPEGV Vm9Vh5zO3fh8sURn+WHyfDlKASPg2+PiYckjvLnvCqOCvPhK8EOiKa0NCJgVPwqG8Ovx39Dsi6J0 JUMyXb3Aa3sbcT8fMNDP1cXfvbAPnn2TT6c3PuSd2IukKq/Ql5jXk3ZSLb8XaDtLX2NnXkDA7Ocr /88K9defT2InaTr/Cy6X2+gPvP4BYDLeE2VuZHN0cmVhbQplbmRvYmoKNjggMCBvYmoKOTY1CmVu ZG9iago3MiAwIG9iago8PC9MZW5ndGggNzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJy9Vu9v2zYQ/e6/4r41ARwvdtKm6zcn8VYDDdI57oJhHQqaom02FKmQVJ3893tHUf6VBGs3 YBJiR9bdu3d37066p+Nen475zN+y7Pw0OaNF6BzTr/hbdO47/WRA+UuWdD6F0VvqD2g67zR+fRqc 0NnZW5qWnYOxjcpbFY8uvZhH2j/Gg8kNTcbnNL56cg/HsPLa0OC4f3o4/do5+ZmmHzoHg94pTqKb SkktDFn1EJeuCoevOoM3yQKe06UOVDhZl8pGCmw61yqQVD4KbZtftpx77KKoqn3lgiI3B1r/pEVT Qi7xG8WlKgnA6qEyQFEFzZRxq3c7oR3R5fjmYji5fNfQ0LbQUkREj0sRGQRh48r5OyrUNy0VhaWr TUGFdxXf3omNoxLyTkUStgCW9CrlJBpz6Wouce8FCl9ux9P3X0aTyfXkB9nsk2jJZTbdF6kknkHh YwZLXAEpY4iqgqHXCE/Ke+epVCGIhaLPB0bfKRpfXH1s7nw+fJLSZHQxGv8+eimPnEyE0OZacpsK FWLq0hyRnqnrbt6QwC+wUw+irIzqEqhGJ53JCQfCzevhVXvZ26Q1NIaMk8KYx03MlsfN++tPHy4h FDAAYjR8z5H45nTBlVMWOtxgQWVB+dQHESMX0NmUl3c1ivsKEnY2eqZlhGXSQ0uuitrZbRiPyhwZ XWpuiBSW47dTkOK35aOlW/F1S67lvYHar+ITAjw4MJJeJxp5UBoKG5iWDPqCTIIuVLIK0lWqcdma 2K3enyDCRIlC2wXNvSuTF1ZGRh6m9VGIKI5KVyhDV59upoRWIC2kjfHG/sGgA1THR87UA4wvPfZB l5PakQXQUGLYRJ7ux0ZXjXNOdW9aRFFqqwPKFlGfq+EfmVhDwWfmSNCBuG/wgfscN7SgXixJSImp yDAG0KHVwBPBNqXHRjOBQzSe2Ud41VY6Y31XvSmj7lU01FXlPM/6vIbcUxFzo7kBaebrWVD3NeB2 KrreE6JxS0zlUtgFz65rIRolr2uCpYDNsh6etqgzVij3EHHCLhvBGxJV1KVCzARr9FzJR2lywi0K BGyVZK0i6O1S2bSuuE2cdZrOJ93prlMthQU5n7Eyw+iTttLaQ+fRlAr/Kiv5ocOdwVjMviIo1orm OXJtzHVvwL8x2WoGP+duvY7MbVOqfy39FaDU/6b9FC21+Ael3wg4Y/1H6W+1/Xukn9SwyhXfNI0l wfwbFeyz39HATkWbgj8nCMZ5QRH7WvinkczDwJ5IGJSw431I67p9veH5XIvfGBZ/iqN2PNLzOo+O V6FyNigm8OZ1yudcLEVR+y7xu4jprd/SRg+Vhjldy+hm6PPgdTe9s+29zP35kR/0/dO/gDiadn7D +Tfue01mZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iagoxMDI5CmVuZG9iago3NyAwIG9iago8PC9M ZW5ndGggNzggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9VWFvGjkQ/c6vmH5q IgUSSGl6URoJGoiQLvRus/1QlSoyuwbc7trE9oZwv/7eeHcJS6IuiiD2+M17b8azj3TW6dIZf6rv JG+dRhe0dK0zusXfsvXY6oYAqr6SnIYxgj5Rt0fxolWe61LvnC4uPlGct44m2kurpW/fWLHwdPhM etE9RZMhTe5e7eEZrK3KqHfW/XAc/2qd/0Xx360jrEem8JLW1iytyHOll6Q0+ZUMUHff7mOy0hWZ 52WB376wmhKTSgQJf/y+1T2voRKjvVDaheMLk2Vmw3jCe6vmyOIuEd77WIcbcNbOiyyTKbXpu3Sn U0Mz6ExVIhBOm5UElA14NvBcGiZSH1K6kR8PR44nw9nxYaZB4tWT/HMaUSVRjhZFlm1ZucmekEjo 9DATggQl2FApQCDXkpOZRBqjX6ePpHBGI/2os+zQFCpE4VfGqv8kI3NUDOqAEu0c5mal9W4tE7XY gqFKVmTmv4CPvFYSgrDRFvNM1usdqGywfB3DrI2WwDNOhnpJDUDIoDn+Xwm9hNqNArXCV7xW4omr 6E21v6PB9adUrqVOAUrKs031YRKLBZvB9dfbCorlsVMbYVPsgHC8QxWkjW4HymqP8UnJV2UZaQlu 3lRYiZXsO47JTa2O88M76WVoBJMxMYk0Y1RHPot8ncmTssiubl/GKlwJ9Azq61IXjFIpzAEbZJ1v X/bbu3VUHFKRZC5rIF3KZhNXsrxHO5fNooSu85TCXeelV/qgit4ANhoTfeQq2IHb6mRljTaFg017 AaEXHOCZImfDfNgY+xs2PKlEvnd8jZtNIbRY8p0ysAum8EwRGbEkvy1ZO5NLkk+MapKksNwz++B1 NUMK7rowK171brFeG+uZXRraYE9EhdCQEoDmVskFZcp5tssVSxjEbjZF891zcB0D5tVIKedZ1VT7 x05CazYmGEDKG6beHCb35W2mD53DJNOqhGFAFCEIM8mjOrOjemicFrr+OTtuMGH1HyGXXbvlqSts udTlxeF0zP2aswF7u2FCQLirSNXE3W5YK42rlYcMVNYBI5vtYPeHIvlduHZD4lQUtkz1Ixp/6fe7 3Z/Yf3k1MOrDbTS4uxtEDQeubInaDqNYJ/L68vIzXU2m9/Fg+mX0MB3cja7pHak8dEAVjRfTocPN 5wddKX7HLUQi29wD1z8JKLMjJx8LiTRsyS7ChSn7JhAzVPMSYre0DxQuI0L+hAE20ddv8Sh6mNww kRLjLUk7Y96hzGXz7s0IfjOgRBgxvOOaFhwKZh9nR2wlEo8H8HJyM5rGk/FkFF1Tp9MJhPu9ADAU K5EW9oQkRl/W2TEfPa8VWo++Jt7MwaDXPwkv/kOB/2AQULfPRR/FrX/x+R/+lqDEZW5kc3RyZWFt CmVuZG9iago3OCAwIG9iagoxMDMyCmVuZG9iago4MiAwIG9iago8PC9MZW5ndGggODMgMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVW1vmlAU/s6vOPs0mxSntrVd40gQrvVmiAzI tsYaQvVqWeSlQLsu2Y/ffQEUi5pBDHjveZ7znHPPOTxDp92FDruL5yKUPtnXsM6kDtzR31p6lrrc AIrHIoShS41uoNsDdyUJXBd6F3B9fQNuKLVwlJM0Irmsp/4qh/0L92wHbDwEPHm3Ry81SYMN9Drd yzP3l3TxGVxDarGNQRo8ypsgy5Xb2y/w0OILCrTb7Yezs49Sr19YfmDcOlkFUZAHcZTRve5FjUUB xgADauiZ6gQpdP0DBGESpzlZQhq/5EG0pvootFVXxzEjdYKNe2ULOgaZUZd0l3ClMG/aR6Y6NJCH Lc+2Rp42RtpXZc418VwN43hD/Gg3RqhIRSShny+eqKBBRN7ypzgReYKKo56DBnWyn+c0M/Qt466h hj2IeiXRMk7r4Aq1q7YQKNROVFcbe6OpPVEYlfjr3ltIuD4umQKC5PVSTnNZkL7X95eb9E+YhMkm O2XiL075YbW+8hdka8fPeCf2erwiA7rjKhQOA8fWlB3GE6clnHK4vIfcwzf45wnm/gfY+n6pMCL6 0v9P/zzsiWU4IgCMEJInaqGlwl/1SnzVI6s0DgEjdwRBtIpTmizanRDGS7LJaor3zrfsdr6apLSx 3xTe9Mc07xWA4OBrxxgKbL0ySv8sZs9Qh8gohk4zdrdk+GFzrKp5qq7byHHEHODofexOMfHmFrWC TRfZI1WjA0JHpotHGNnKobPenwD0sB0LaVg1PBP9dL3x1HKUarI8tBKSgknnZMRn6LFThxkLpGAv g2iYDaW1ZU9dpLl4anqWjUbIRqaGtlPtCNKYqro3VA2VArwfCN+N3WokNVXYNmiaMWApM8tuKzEz k/yei5gLUxAleDToGWfaDiZOxJI1B3MM+Z+ENEfBcDTZNNfF54U1SrmCdeX9R6CENZ71YXPWEp6/ XKYky4QXVuLVyoEccztCiMxqtbSdb1M69J/85Ut6DiQHf9OucOgtCagtTBd5/Ejrpnd1zr/T+7os f02g22eMyJW+0fsfB+n5XGVuZHN0cmVhbQplbmRvYmoKODMgMCBvYmoKNzg3CmVuZG9iago4NyAw IG9iago8PC9MZW5ndGggODggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyNVm1v okoU/s6vOH7amohbabfdu+mSUB3bSQBdpOZuVmOmOlhueFugZpvsj98zA6si4C2mdYTzPHNenjmH n3DZH8Cl+JTf61D56NzCNlMu4QH/tspPZSANoPxah3DvotFnGGjgekqBG4B2Bbe3n8ENlQsa5TyN eK6OUublcHpRzZmBQ++BWrVneBlJ6gegXQ6uu+5/ytU/4JrKRd3sB9whx4qO9GX3gzK4ajdzn2yb mCvbsIgujZvN8tco4oHKozVLpJl2s+fsQP6W8AxiD7w4DVmeweJCxkHsJ2vRFRZj+WBPf2c/rsYT x9K/fIGv4pdqs5DrBZtYCjL7EdYvzI8aIvgtKVSMr+JoB+joBFnDGKORQ2Yz/YDBm+73KQG22aQ8 E87vrj/ubnoQsnUP+FbcVH1v0W2iIw+CbVChWwm6I2TvL3XJvOj2mhNdvzpCC6sIM9K+uXa0ObVd 4oyNIcHaE9ulY0ocGYiKLvA0a2BZmZMHOjTMVSEF/TiEsuxif0xLlqd+tG3MQwlWiT00pnohCokF KZnsNWC5H0dV4ZRI3Al1gDKg0/m1LglxdYOO0FJD5zRc2BNCVMsY6i15lTZ/U1NsgakrFvN/TcM+ B7Tne1tras70kyCqZ0ME8sNPdtfqC2eY8aXAFbXxwyROc/DSOAQ/ORuTuATLzSlLE00rQZgEWTuB eArF03MkKOI9R4sXaPIOot2vgEXnsyJN3kEV7SpeNVFJkwNVpWBp/JpzleUo52dcZTqIqmHLnDy5 ZDV1yJg4KGQijoLsYxvu+RHftJYMG6Q5EUdoYpvf9SXUrhpPjaHY2xi6dE6W5S9qz1zDNMlo+R4G uPMTtR7a74MPRX4a0Ri9VEsr/v/QPH8pxlqdYXmCbqjFjkebOD1G4WCAO/1k66K0c2l8mCWV84el bHBQDFTn3h7Dg2NYluHA1HBc0ECFkUioL3rTcW/sHN+HPIZnDrTixETEC5S4Y6BRMfbQlgUQxhse ZDWp4AgUMBEu9lAx3RcXb6zsppWeKDoV1h31V0xl1OZXSPN+CVX9KMtZtOZ92ZWhM5NdubZhoWZH vAPIIdvEIJOfqv5GOvhkU/dKO8rCoWXuPWmk8cUrjcfWPDss++XMOglNTLOxYVE8Jm1sqIBM/OuX Q1P1WOgHb8j1SZNc9+yFbV5THLA5sKC/LzL5lfgIgMk6j5+xONqnnnxTOj0oU7blMLgVbzHEVb7h 5w8aaX5BZW5kc3RyZWFtCmVuZG9iago4OCAwIG9iago5MjQKZW5kb2JqCjkyIDAgb2JqCjw8L0xl bmd0aCA5MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1V73OaMBj+zl/x+mnb 3XTVOtvu3O4QQpe7CA7Sbb3djksltWwQGGLX3u2PXxKsRnGucIqS50fy8L7hF5z0+nCizvV1nltv wjNYLK0TuJSfhfXL6msArC/zHCZUgs6hPwB6azW8PgxO4ezsHGhuvcSi5pXgddet2G0N+wcehBGE eAJ42hqTh11WaQaDk/7wFf1hnV4AJdbLQ0B9dADPPg9jKRd79hSTa/ij7ox27rx6YfVP/6cznZFo TwchZNyRKoORqTJWY749RR/evXsPVd2rilWdikU3FcuaiTnvVenNUn31BMs5dCIaYv+yNZuxtib2 BJEnpbzMlr2M3fBMord+wRVF8SxEHgqR72jftS3vsSRPRTdJG+vWZDs69oon/DYVaZ0WwlTGPkWh Zzsoxi7yKZYGeirGgF5oe+4qA+w24E0epnTKOe/mbN5lSVLx5VJBx1PbiW3XDVEU7YCj4CpUk5jd DzfjWjot74cbBZPhoohi36Y48J9B28vEq4ocQs8ZXVz0wSnyvBBQP5Z8aTqYc1Wij0wsenJB8Vq3 nYl2LSuZ9MOWYdzciae8Hx3Cjg5jh2aMhvB2LrvKh9AjA20G0pSIuykQ6ELOHuE3EzXUBUiSuoRN kcvuNc189JV+DGbbdmhqfdtePn+o4a4oQbVCO7KGT55KSZXdJQq7p4MdLnZBrPIbXpnW9Mr3ETno 3IF6JQTPnkw3HBI4NokDn1xryiQICLL9NSfhoqj5EtJbKET2CBrc7kPbofiztjTpWkF3JDSA5k+b jv2I2oQgteCNwBNV7yBZxhP5Czw82X1SHYjuilWWwI1CwjXTjwO6aQklm//kdato7jhLeNX0xKEe +/8O+e9GM8zarFkY0MAJyFHUtzGl5MP34xA3cmYas7cJbxzU4q5k4Zy3q0vJ62Ef6+HdHtmGY2Qz es769kN5HknVevwR2a7cZI/gZCqh7XnYiR1iS8lj+XwbeyT4sn6HHAeqLiV4iqnGvR3ooCbsjiWr 6jXwGljW28DRQ5nKnQKCeV3ItoPB29f61byvOmMLDv1zpYio9UmefwFryAeJZW5kc3RyZWFtCmVu ZG9iago5MyAwIG9iago4MDIKZW5kb2JqCjk3IDAgb2JqCjw8L0xlbmd0aCA5OCAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1W72+bPBD+zl9x/bRUKluTdu02MSRDnMQav15w2k1t hWjipGwEGJCqH/LHzxiSF5KWxigCh7vHd889PvMXzj/24by86vtsJX1yr2GZS+cw5r+l9FfqCwOo b7MVaJQbfYH+AOhCqvz6MLiA6+svQFdSj8QFy2JWyMMsWBSwP8jA9cAlGhDz4B0fKM3CCAbn/ctT +lu6+ArUkHrlixPwnpJ1NIdHBmEMqzTK5TSY/WEFRzr9IPUvdqZ8KOL9EwvmLFO/ffsO9z3FdAzP d6beRK0eDaRhQ71TPF8j9EF94CC910Iqx51Cbc+/QcYUq+WEGvXkAe5Puxw3UK9rO1tHpFNiW+rD /457ubF4FqT5OgqKMIlzbjS4auW2zFgzNWXsYp84/hB7lFhIgB8Q8soQfo5rU1u3DZ/+crDalUnt 8AP/apgpzy9REDei4TyH6fPl9p8yfz6/2s67yaqYvvlpIMsnQ2xRMiLYFZVpUaDEz20Ojln1XT7E 2sSlU2T43lSzMOVBdMuichoZ9u3WtBnnCQzZIoxDUUZIFoCtqQlJBpptGxhZh6rFFtIMUUzXGfn6 BOs/RIlrhwpU7CDqTvGnETI83IhPMRHVJ1UphTKIc3OpAjT8yhA6MtoIn6suIdSKfseEYIxlE+nq oXyrIEe2a1ZBDj0qKua5uvpKqN112wh/ufRtElHKGot9xhWOR9jFlo7bVNarGPaY6Mh4g1DDRkNf Q1yQOvZvMRlP6H5BGhF3Y3kO1gnXloV/Un9iO16dPvF05A7f4nOzs/BvCZ342HVtV60Wve85LAOL 8G3/IQdsImIIqe8RbjXZtiayFayYetZapUE5RGFedPK+EShc8Hv/n0DMXoqnJJXDOSySbBUUbyfF EdBw6GLPU5sIeRgvIwbBfJ6xPD8GBY9LkH4LBS+Fd1geRYtgxvgJdTTSoBtpcASSXwvBp1PL4meM QDKSZTgLIijWccyiY1Aqb5lLFznbnVF7t46I1you100AvkOrDVQwVbHj9eqYvnhET4CDPf+OpUWx O0L6eyfOTmnHmFnIxIft5oSs0iQrGFdklqxgHc/LnsynJK5KwAkEM5mzKD/sx2EqZ8m6YHJQFFn4 yJ9yFQSpSlXUsAWeFcKcS7i578WnyNsw+yA78wrm80BEpAVPwXydnQH/3gmij7vU8UsacoWCPSuS R94MBp/PxNfTHkN3TrDku+BreURhKv3Hr38iT0okZW5kc3RyZWFtCmVuZG9iago5OCAwIG9iago5 MTkKZW5kb2JqCjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicdVRdc9owEHz3r7j4pdABF0zzUSZNJ0zSDDNhmibuQyfkQdhnUCNLRCdC+fc9 yaZpILVhzFm7e3unQ0/QS/rQ83fzzKvow+0xzCnqwRV/59FT1A8AaB55BaOMQSfQTyEro5rXh3QA x8cnkFVRa6wdWo2ue2FF6WD3Gqe3d3A7HsF4srfG1/nSSgVpr/+xnf2KBp8gu45azdopukUtbc3K YVc4Z+WMf9EZDIef4fQMDkBWS2MdFlBaU8GW0X4X9QevtGqJZ9SFsf8qDYdeZ0+oBhLrHKZB5yhJ E4Afk2v4amwFpoQrK6pKWIakR9tU2QIDpvSYtVQKZghSEwZl9sZRCXMrlguZE+RCe4AgMrkUDGEx zjTgTD+FnsOFcAImpkAFmUUMqbvjiUdxMh8J561w1YHQLBiAkRX5IzqC+D4GoQuIH2JAnStDCEqS g0fcUPJCOJ/NLD6zCWk0sSmuAKHw+TXnBy0qpCHEdh1DhYIhudGlnK9sYOz2e9qyKIru2kqH03Zt wJoYyHGVtWwDMVptpu3kVRfZzt2mmhlFwCOF9g0fX7Y2uINm6S0IFRAdiA/iXTsNFJYWiZuA3rwT UqPt1N7ex1CgNjwQjArt8a8VirLroz17N8Ki5q4TE7ZdzRdGsrQn5oJj74Y6OzEwEYQis2dR2Ece kbV0C7aQG2U0tygexm8051IpuSRJHpAkCUN8Y3VBfu5CbWyO/GDQauZ4cIgnhCfF5+Yid1PTwqz1 XpLxECSFyaKwF0Hbh/UfhftVSi2bzW84F//jhFPgLca0NWH3TNr4eX9BNExe4E8liWSY7vSoFyyO xEIUK9495KpU8vc4ufy9lLzH8C13ZsaDkx52wuGyc+rc34g58sIDS15m0Xe+/wAAVXp0ZW5kc3Ry ZWFtCmVuZG9iagoxMDMgMCBvYmoKNjY4CmVuZG9iagoxMDcgMCBvYmoKPDwvTGVuZ3RoIDEwOCAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK2W71ObMBjH3/NX5N10E1ZQq+sbj0qq uWtpR+PcTne9SNOWjQJCdHrnH78QfpQCCp0r15ZLnufDNzw/knvQUVTQia/0315Ln60TsIykDrjg 36V0L6nCAKR/9hr0MTc6BaoG8EJK/FSgHYKTk1OA19Ie8hgNPcpkIyQLBsofpFlTYKE+QKPKHP/o Qei4QOuoR/v4l3T4BeChtAfAJ1l2Qi3a/yCph+kQEKPhHxD6D8zxlrLjRYx4NuVGexkusUDmFOvm OZyZ+giCG/Unl9ELmVL2VDyyrnF34hUtiE1l14mY8D8rWr3kz8kMZ2hOPeYsHBp+BDcdRfFKLtXX Uqsnf3K0ua2IzB8fOne5wpJB0YZPx4JKcl627eKHiJXWC+OYKP6pE1PEkPk8pFEkL8jacZ/rhb0U A0lr1OVmL7KcWjJ5TZi9qrcqGsZImT0HyWKMnkg/aF6NXnXdUiMv/HD9j65BSBfOk1iP9sp6Cj5O ID8eZT4iZzSeM0lqPBNvqThBPt8K1q2FFWjdtrR14EY5TNDUXFo8pwgDl9xRt1kZpZTHzq6KS4WN 9POZbhgWnE6bYXlhOnm9ZQLfrLb31lspyzz6xOSVH4jqa1QdW3NjkRjmW4mReJiXs8HYGiVtq2Ua 5p74xyRpeGe7ecLv+HI8SftlFvCUMMUWMi9aM5BRTJmUcYVMfKg1MrgVtAY679zIgCZGAwStDQ31 qlLax1oUqcJ/ln4ynsa7UZQoxLSxFcQomypNJ9uQum+Ruq1JtZWl7lxWOYxv0HHgtqs9jR3zxU5T Losd3nzj5lFSg69MEw7l92Qjp7AHz6OuTD2bBDnmbcdCwFeUzHl32bwP1ONdNiD2b8oicLs3ut1v yer+L5ZouzWspF/vSluGtArjtHg8g7WnPT65xKvwUC8Z31mc91gnD/WS8ba4JA8m1hjDc4zG5mxi wQG0ID8aVvKq7/suJV4jbTjWjVlfH4rz5TVEF5e4WDY70qKA2g5x5c0ekYUBWVrSvHtNRSeswDd9 eAWnPWCg6bluGQfZzewa4csZtKyxtaWG72XZySXk22nxJW9qWNnunrEhh3SPxZG8T1Zk/hAeAMoA cZWNnKfA4U0MjG3m3/HwaccH4oBfUn0zIUsKNLFzQyx95ddf7BA2yGVuZHN0cmVhbQplbmRvYmoK MTA4IDAgb2JqCjg2MwplbmRvYmoKMTEyIDAgb2JqCjw8L0xlbmd0aCAxMTMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx1Vl1v20YQfNev2LfagKxIclsnQRsgRuPAQAq7soo+NH04 kUvpYvKOuTtK1r/v7PFIkUpiwZZ8H7OzO7tDfaX5bEFzeaX3rJq8Wt3Q1k/m9BG/28nXySIeoPSW VXS7xqHXtFjSupi09xa0vKabm9e0riYX9yawMxyu/nCqCHT+c79cPdHq/pbu//xmDz/va6dLWs4X P1+uv0yu39D60+QC6w+GKey02eIvE7+oShsVtDVki7h0VNjLVVBU2ZxLT9rkOlOB8cnjhAqXP00W 1x3e0TaUWzI20E7tOUI4VvmVNeWRausi9p6db/xp8+B04G4XeIKU4mtTWFdFSqpsOSCA4RmOLX+N YW9mRH/7LoeV3tBHp6pKuYS0llVUZtuuCm8QONKWDTudkTI5ZVY4kaK9cprDUcIXrELj2M9GGa53 uO85i4nUzu51jlpI5eoSH7DYRC528wWHpF4trROBREvC9teCFSw5QBm7oLTAMGXKt/H7VBd9sivb SNEcF+zYZJxg2013tonMslKzCYAU2nyljQ+qLEmV0ldKTquwE76jdIU7uu5g3TMi31nXcZ6SLujh 6fEOQkvhvomICi7mUwEwfcYW/7khk55Fun/QYfddqOVcaoTrCcurigmVD6lfZ63OkVAHBdwtBwHK OG+rgJp36wkoMeC8U+ru/hZg/4B2/HeACOGFX+7UwUwHXMYlPAX+LvRJTNw81zDWRJXe0oalAfK2 MXgv9UIKGjOAYnh2ex0VPwmlQlDZs6fNsYvb90FLOzLYoGKDeFM67HS2I9YiTEond7Zuh9MWBWPc ZbJgOgVmBfonSB2Em7eQobJGB+tw7pXClB699p1KoRPnSUt6ceLb+8rxoEA/JJiAsHVsC+ubGpMK PSHmsROmx0H2stz2GSYq2MyWowFa9gOU6yJGCWjwl7CzNYVjzf4HrgF8e5D5Zsk7g28FHvtFQvGz 1iRG6nSGgY7NnEaSoq4neFs/7zH4CGdMWyZ/3RgDA+xOJKrvKYzW4aTahGgqqtuSrhGtnuHfApT0 FAOnreUxWzHDqEa6jGaGxZlM1b4pkfdAr3QibvYEE6+OZtQa+RZNGTNWG49+QkHEJhtpbBSg9J3l J7uZQswEhEdJZ+9dI3pWFYzTl10PbHCLMbPpNnG+5fMSivYrrkt5gIkan7TvbEAehDJ8vbBucK7E uch8uNgxQZWrpgwanjgq4sCcfHKn4dI0mkLj4CSZbcpcJj6z4qwv5/q27lF5LvfokCuMOviVMIU4 DfLYbDt/UDyEEodA3EfpBZBMWC3VuCZmuHFW5XjKhKjR6XEkbaHN3iLiMOmxe/2WeF5Jfd7R27e/ 0+eLbvHd50uazeTCm0W8cKt2Km/clOCMqpz1X00+vNQaT1l6yILdoO+Wv0zjF5WzbzD/Pqot03L5 HxA/rCd/4fU/0ZoGtGVuZHN0cmVhbQplbmRvYmoKMTEzIDAgb2JqCjEwNzUKZW5kb2JqCjExNyAw IG9iago8PC9MZW5ndGggMTE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZd c+I2FH33r7hvTWaADbC72U3TzJBdNssMCZS43YduJyNsgdXYkleSgfz7HsnG2JCZtlOY4CBdHd17 zv3gB130+nTh3tUzyoI3i0tam+CC7vC3Dn4EfW9A1SPK6DaE0QfqDyhcBeW5Pg2GdHn5gcIsOJtI y7XktvtZs5Wl49dksHikxeSWJvcne3iNci1SGlz0356HfwXDjxROg7PL3qA37BF942KdWB5TKow1 5z8Fg/d+352jbXOThKHC4ItVlCoWd5csZTLiZOHUSkTEMiXXxMhwS2oFqP5wDyX5ziYqN7jwi1YZ jDIV81TAPufa5DyyYsM7WD+5csP1C7AcihGZSJl2DjDSPE9FxKxQ0tt2aCtsQjbhFIvVimvufUuY Jc6ihDKeLbmukCp/6P63x5AStuEAnM5Gn59uR9PRw6fx07fx5O5rSMwYFQnm/PHowvZaFF1XQF3n wQ1dXf1C38/2izd0/QrmzffzXs+heAnegpG5VtYRUAViKh+Pl4lp3qSgxZRjdkR5+0hLAkeyWAlu aoVgLjKmX2p1iMn4sLtk0XORH6Sr3ApB8PV8MQvHn8LJ7OFpvhh/GS/GCPCGmLVaLAvLScjYiYPb tokA+3vCxT66/d3uytIEWpdX/jeKX3elJple4YUiJomlRtGSH6cceJxIUkgjTVulY9NpsbjPdYeA w806iKsCcBl4wiz4ZHXkLWfKC00BBhhgDarAIXg/tyJNcYd6xtdnfvW/U68Vyj8wV93kkvQdfHyo BIwSJqSpmZXNZSchq5d86eUFEldJTkqj5JHACWcxKh5rkL7ljyrsWvmOgCzgjpcZzvEdy/KUl9Bz w4tYbQVwuoesuZ9PH0lt6uI2KvNNSZpcaQtWSgNNd4sxrfBEANYphlARgyzFblz0+w6sVWAOlybz 3mmwLE3V1tUMjrr2zFLi0gr74opzqTl7psKxwA+6rzXLMhci0sGJXFeFxBGUDM85PiRoEzxC7XQ9 dXkdGVoay02R+q73b8rERY5cQGCmWzIPfd0GqPgZG2vND+uNtvQe8ZZNB542m9K0tViqEilH3A5P 8KqL6Fg6WBeGrf0/Ls9bqrPDMYcGHvaN/TBYsJgVqRUOLObGCukJMGXLrzxLUMTENgztcSlSyHBa yV58PwwaKPSiimoEvNKa2k0QzB2PHdAJ97g0hXbTBmPHhSFVhbUPIdZeZl/gvhnQCp7iDLx8VD4Z kP/wdD/2WKNPVFh+yznlrIWUlXU5GI79Mo0G/6aMoj37fEP/2Pc63LKExYXuEDo/S3v1L4fxLket GZpFVmF40uBdx/+OOPqB8cfcqTsY/gnEcRj8ivffy7DNRmVuZHN0cmVhbQplbmRvYmoKMTE4IDAg b2JqCjEwMDgKZW5kb2JqCjEyMiAwIG9iago8PC9MZW5ndGggMTIzIDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnicjVZNb+M2EL37V8ytCeA4tpM22WPSLooAXWybuOih2wNNjSVuJFIh qTjZX9/HD9mW7C1qI5EhDd/Me3wz1AvNZwuah2++ymZy+XhDpZvM6Vf8lZOXySIGUL7Ihu5XCLql xZJWm0lat6DlFd3c3NKqmZw9aM9Ws7/4xYqNp/HnYfn4RI8P9/Tw6egZPnetVTUt54vr89XXydUH Wv02ObudUVxiWrbCK6MdCU9OiprPf5gsf4pBWLyqlCPHMoRQoZzsnGNHvuIUTJZfOmW5Ye0dbYwl EXEL4cVFYwquZ8BbXO3xePScXGW6uqA1k1gD0BuqhC7wqxa27NOYDWACwL7gaQhlHRcV3NbmPRSB yJhAtG2tZKamdALLGJBya+yzm+2p3s4WWRHLonA58L6rn5Uu6ctZaU3Xhp+Ab7raqzYUtf4KZSK8 IIenuNewc6LkL+f06c+nFVgN6LuubY31XNC24rAqlwICr0qCLOvC7QQKBIUmfgvbL2qQ9cq/z3Jx T6pRYFW/x92I8UnQmDgLk3ZD1ipIA7iwXex8Clc6Q63BkzbWNEcVDSRaZon+ssrz/9RoG2IPbXZS rIFIWbgjsY6UoK0IrgOtlAU/fPJXr1Gwm2XXIjEngiFgJHrMp7SsuyIIZtl3Vl9IaBkMnZFYyGpM JnAJeFG+zGUg2FUWjF9je8DWpI1Xm96Y+yotkwTBdbiEBtvGWzuh+oojUGAEeaOUvc4DAffpLtGQ g4zfFWFotZ50MhzR50TU4J+N7TmlokuCw4WjLfcV7vTcKjQi6xCC+RLHhmg4rOLpsf0bVVYeS14j dGiGjLLD/i9qp7slyjts/D6dsapUWgSHRdzLQ7x+Q5M9shcP+mXM+nt7fMrwByb5gAKfWHY2+Pln xKuib5Wc7K6ugQFSQibANVhwnB7BW43QQLQx8YkWOTWFRIeNwGMZqceFuAM1vnEx28/oHjlCtNZ4 DDtS3nHdD2NRCqUxTQQU1QpJIYhjG8UV3gv5TOv30FKmhFtGpU3xLOP4Cui+DpL2Awr5JMTCLVR0 d1wPa/Qm0tTwH2Q3/SirzBZ7gl6NEy73FMBKK5oGbEM9xyoFDVLf9863Fv6Kc8cFNJESEU5DG0YB hBqdkyc047fWuNDFB6edr0QQkVQD08RTM/DTw/7tqwMU2j0ZkGOJURx3MOl2GSOwNIDFXFS+2kl7 OEgPjuVU80FlKU3LUm3SkbJmdKLaTUDs7TgnuiSe1bkXOj3MtKs3vgPMryO/e1GJorNTYvgmlJE/ H99avEc4+iy9WQN7+eM0vrSM3mb+/j305PL6H0B+XE3+wPdf6KMHfmVuZHN0cmVhbQplbmRvYmoK MTIzIDAgb2JqCjk5MwplbmRvYmoKMTI3IDAgb2JqCjw8L0xlbmd0aCAxMjggMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVV1X4kgQfedX1OFl9JwkS1DX8RFBZ3XEYSA7Pozz0CZF 6KHTjf2Bw7/f6k5QMbIPhkM+q6tu3VtV/Qi9JIWe/zXXvOr8NT2F0nR68IX+ZeexkwYDaC55BecZ GX2GtA/ZvFOvS6F/BKennyGrOgdX0qKWaOORZnMLb4+r/nQG06tzuBq3vtExWGkuoN9Ljw+z352j M8huOgdpL6GFg9vB4adO/+/wikyzBTdQqNxVKC3doAGpLJQoUTOLwOQGciUNL/wzpzuYKx38JOTo IE3J6yBfSvUksCjRuzH+Q/BN651dKG3gSTlRgOBLBKvALphc0hnpvV5yWUKplVtRpDhfME72TBbk JT3a4tS45viE9EVJv5BrMq5CNG8LxpUlmhpgsPBpee6SgKNBNFdCqCcfb4VqJdCnZjV/cBaLGhdC gYaXEtQ8PHmSK1WgAGZgxbRtPDWfgxBBLF5BhWi9by5fFDiCGO6I1C+odIkRDBeab/m54eI3SmOV WNGXa5zPIWOUkNMsgpnmJZNoFvCVS07PzjAJ/zCNJoJL9sCZbNzM8oVEr08g4pYTBjhnC1Y4nbxo nfa9/JLEq0jHNWWGc9Qoc9zC+XkVj5KFDxDzvjaxMxjnjE5rGa/zXztyvDoaSLMkhB8nlCLKCLr/ GoQhLa8L5gfX1jEBQyUl5kGnJuyrg4QbYeXd3B/8GKrR/WHwuV17i9aXy67ZrTdru3LGKxGUmbM8 FN1UuSDPbGMsVt2oro/4TcZtVy8cxL0+hQwYiOOVViUtNfeHJAg+aMf0JjRdstNhgVaOdl7HYDpf cEsUOI17OR1YwYjTQRIRvVQdmgi9Dg8N1xHcMV1EMKI7T0SWtHHfsgKZIyUGVI+vogY9QvG+ZicU e81Q29Ubyt7PZoedto+P0UWrHgRWsbE0jXy77+dMcFZTtk08a8gZJQ1b3bcZt1HuFglM6vAw24Z/ h4N3U90FHfd6ewpn4EpnbJgU/8sDDamYU/fGYRjtJaHpe+KAcr9UYunLZUr3zRBpGLlOYIzFGj0n e0V/HhbKzxOD4QWMffx3WHgG2HYUIH+8d558he2OpL3533nbOuNXveJTHiQ08SyTVCNdUtWqXAnK qMAV0knaNuzdAUbDd1+/vG2Ptqt3UvgYH9PLYT9Nz36R0poVtEfXCXa/4sZvpUWNlWJ4p2RsPFTK kudUiftIm+Kj4zoUKtzgGoWhVM6HE0iPI+8EfMgIxr7ZIT07O22DOj5LTwjUxKBkywgmhGlMU1tp 2qhqiFO1abqzdBu/Qdw0wkySfbgmXAi2iS+MZE5YynJMFx5naqWEKjdE3zijLWKrAmX8bTa57AbM bQ08RJqiTiIR2ws5nPRD1OemQQtMJM8rLv6siBYD33KrHmh77dN6r8muX/g5YSX5PPFFeZF1vtPv P7iS1b5lbmRzdHJlYW0KZW5kb2JqCjEyOCAwIG9iagoxMDY3CmVuZG9iagoxMzIgMCBvYmoKPDwv TGVuZ3RoIDEzMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVT23KbMBB95yvO 5CXxlFDAdnx58qVOh7ROU6DThyTTUUABxSA5kohLv77Cxk2dizTMCuns2bOr1SNcx4PbzNYmpfUx HCBTlovP5susR8vbAtCapMQsNqAhPB/xvbXz8+B3MRgMEZfWScA1lZzq00+S3Gu8HIEfRgiDGYLl qzMzpmvJCviu1+vED1Z3hPirdWL2r8Pzed/z3VvgSv6pM0Z5SmzEjo0op9zGpVkRnhrbbOjcxtHy NIiCaIxlVWjWOba87p7tvxGLtShEVuPmZBnfdBCKSjOegXFsMylpyoimiGqlaQktDNELijdwytAF kYmvbjpHNox4NOptnNM7WRFZmxTdoWO4/LOtqGmlcyHVMaZpKqlSVLVxLpmRgxnJSVrJgyRmkiQr qjEX5XqrufXo+i4i8VjRAj9J3W5GFef1EymojfkUGPXcYb89+hFNn3WY/0VJWDEGbwL/utsFntQk F8JJRGmgz7cSCo5zUazUgbCLirM1lbikeiPkStmmQonTRvO8Ua+5pCXROStSgukT5RV9X+boHZlX ueB0jA8eDAiDXr8pqXsgpM1ECn4/ediJckxn7gnDYGzMZrNxDg+f84skywinKscXxg9baCFZopTg b5VO7d2clXGb0Bb6qnwXhGNJ0yeaHlDPmUrEW7wP5RY8SRpAy+ab5BtU2yE2TEeQwvnXnIvfa2Ya Ct8SLe7Mpfh9e/u8Xry76yuSUfhnt4ZyEVvfzfwLkDoSX2VuZHN0cmVhbQplbmRvYmoKMTMzIDAg b2JqCjU2MAplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgOSAwIFIKL0ZvbnQgMTAgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRv YmoKMTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDE0IDAgUgovRm9udCAxNSAwIFIKPj4KL0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKMTYgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgov Rm9udCAyMCAwIFIKPj4KL0NvbnRlbnRzIDE3IDAgUgo+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDI0IDAgUgovRm9udCAyNSAw IFIKPj4KL0NvbnRlbnRzIDIyIDAgUgo+PgplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDI5IDAgUgovRm9udCAzMCAwIFIKPj4KL0Nv bnRlbnRzIDI3IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9UZXh0XQovRXh0R1N0YXRlIDM0IDAgUgovRm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMy IDAgUgo+PgplbmRvYmoKMzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDM5IDAgUgovRm9udCA0MCAwIFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+Pgpl bmRvYmoKNDEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0 YXRlIDQ0IDAgUgovRm9udCA0NSAwIFIKPj4KL0NvbnRlbnRzIDQyIDAgUgo+PgplbmRvYmoKNDYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAg UgovRm9udCA1MCAwIFIKPj4KL0NvbnRlbnRzIDQ3IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgov UmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDU0IDAgUgovRm9udCA1 NSAwIFIKPj4KL0NvbnRlbnRzIDUyIDAgUgo+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4K L0NvbnRlbnRzIDU3IDAgUgo+PgplbmRvYmoKNjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY0IDAgUgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRz IDYyIDAgUgo+PgplbmRvYmoKNjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDY5IDAgUgovRm9udCA3MCAwIFIKPj4KL0NvbnRlbnRzIDY3IDAgUgo+ PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDc0IDAgUgovRm9udCA3NSAwIFIKPj4KL0NvbnRlbnRzIDcyIDAgUgo+PgplbmRvYmoK NzYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5 IDAgUgovRm9udCA4MCAwIFIKPj4KL0NvbnRlbnRzIDc3IDAgUgo+PgplbmRvYmoKODEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg0IDAgUgovRm9u dCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgyIDAgUgo+PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIK Pj4KL0NvbnRlbnRzIDg3IDAgUgo+PgplbmRvYmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk0IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRl bnRzIDkyIDAgUgo+PgplbmRvYmoKOTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDk5IDAgUgovRm9udCAxMDAgMCBSCj4+Ci9Db250ZW50cyA5NyAw IFIKPj4KZW5kb2JqCjEwMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMTA0IDAgUgovRm9udCAxMDUgMCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSCj4+ CmVuZG9iagoxMDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDEwOSAwIFIKL0ZvbnQgMTEwIDAgUgo+PgovQ29udGVudHMgMTA3IDAgUgo+PgplbmRv YmoKMTExIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMTQgMCBSCi9Gb250IDExNSAwIFIKPj4KL0NvbnRlbnRzIDExMiAwIFIKPj4KZW5kb2JqCjEx NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTE5 IDAgUgovRm9udCAxMjAgMCBSCj4+Ci9Db250ZW50cyAxMTcgMCBSCj4+CmVuZG9iagoxMjEgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyNCAwIFIK L0ZvbnQgMTI1IDAgUgo+PgovQ29udGVudHMgMTIyIDAgUgo+PgplbmRvYmoKMTI2IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMjkgMCBSCi9Gb250 IDEzMCAwIFIKPj4KL0NvbnRlbnRzIDEyNyAwIFIKPj4KZW5kb2JqCjEzMSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTM0IDAgUgovRm9udCAxMzUg MCBSCj4+Ci9Db250ZW50cyAxMzIgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvS2lkcyBbCjQgMCBSCjExIDAgUgoxNiAwIFIKMjEgMCBSCjI2IDAgUgozMSAwIFIKMzYgMCBS CjQxIDAgUgo0NiAwIFIKNTEgMCBSCjU2IDAgUgo2MSAwIFIKNjYgMCBSCjcxIDAgUgo3NiAwIFIK ODEgMCBSCjg2IDAgUgo5MSAwIFIKOTYgMCBSCjEwMSAwIFIKMTA2IDAgUgoxMTEgMCBSCjExNiAw IFIKMTIxIDAgUgoxMjYgMCBSCjEzMSAwIFIKXSAvQ291bnQgMjYKPj4KZW5kb2JqCjEgMCBvYmoK PDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDEzNiAwIFIKPj4KZW5kb2Jq CjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKOSAwIG9iago8PC9SNwo3 IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxNCAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxOSAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iagoyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyNCAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoyOSAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoz NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agozOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0MCAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iago0NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NSAwIG9iago8PC9SOAo4IDAgUj4+ CmVuZG9iago0OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MCAwIG9iago8PC9SOAo4IDAg Uj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1NSAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2MCAwIG9iago8PC9S OAo4IDAgUj4+CmVuZG9iago2NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago2NSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3MCAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iago3NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago3NSAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago4 MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i ago4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4OSAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iago5MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5NCAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iago5NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5OSAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iagoxMDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKMTA0IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjEwNSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iagoxMDkgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTEwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjExNCAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMTUgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK MTE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEyMCAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iagoxMjQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTI1IDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjEyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMzAgMCBvYmoKPDwvUjgK OCAwIFI+PgplbmRvYmoKMTM0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEzNSAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0NvdXJpZXIvVHlwZS9Gb250 Ci9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjEzNiAwIG9iago8PC9UeXBlL01ldGFkYXRhCi9TdWJ0 eXBlL1hNTC9MZW5ndGggMTMyOT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVN ME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+ Cjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0 IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3 LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFk b2JlLmNvbS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzMxYTNjMDI1LTAz MGYtMTFlZi0wMDAwLTRhMWQ3ZWQxNTc4OScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29t L3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjAyJy8+CjxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSczMWEzYzAyNS0wMzBmLTExZWYtMDAwMC00YTFkN2VkMTU3ODkn IHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+PHhtcDpNb2RpZnlEYXRl PjIwMTQtMDQtMjNUMTY6MjI6MDUrMDI6MDA8L3htcDpNb2RpZnlEYXRlPgo8eG1wOkNyZWF0ZURh dGU+MjAxNC0wNC0yM1QxNjoyMjowNSswMjowMDwveG1wOkNyZWF0ZURhdGU+Cjx4bXA6Q3JlYXRv clRvb2w+R05VIEVuc2NyaXB0IDEuNi41LjkwPC94bXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3Jp cHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSczMWEzYzAyNS0wMzBmLTExZWYtMDAw MC00YTFkN2VkMTU3ODknIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv bW0vJyB4YXBNTTpEb2N1bWVudElEPSczMWEzYzAyNS0wMzBmLTExZWYtMDAwMC00YTFkN2VkMTU3 ODknLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzMxYTNjMDI1LTAzMGYtMTFlZi0wMDAw LTRhMWQ3ZWQxNTc4OScgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv JyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkg eG1sOmxhbmc9J3gtZGVmYXVsdCc+RW5zY3JpcHQgT3V0cHV0PC9yZGY6bGk+PC9yZGY6QWx0Pjwv ZGM6dGl0bGU+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0K ZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMDIpCi9DcmVhdGlv bkRhdGUoRDoyMDE0MDQyMzE2MjIwNSswMicwMCcpCi9Nb2REYXRlKEQ6MjAxNDA0MjMxNjIyMDUr MDInMDAnKQovVGl0bGUoRW5zY3JpcHQgT3V0cHV0KQovQ3JlYXRvcihHTlUgRW5zY3JpcHQgMS42 LjUuOTApPj5lbmRvYmoKeHJlZgowIDEzNwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMzE4NTUg MDAwMDAgbiAKMDAwMDAzNTAwNSAwMDAwMCBuIAowMDAwMDMxNjEzIDAwMDAwIG4gCjAwMDAwMjcz NzUgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxMDk1IDAwMDAwIG4gCjAwMDAw MzE5MjEgMDAwMDAgbiAKMDAwMDAzMzUzNiAwMDAwMCBuIAowMDAwMDMxOTYyIDAwMDAwIG4gCjAw MDAwMzE5OTEgMDAwMDAgbiAKMDAwMDAyNzUzNCAwMDAwMCBuIAowMDAwMDAxMTE1IDAwMDAwIG4g CjAwMDAwMDIxOTUgMDAwMDAgbiAKMDAwMDAzMjAyMSAwMDAwMCBuIAowMDAwMDMyMDUxIDAwMDAw IG4gCjAwMDAwMjc2OTYgMDAwMDAgbiAKMDAwMDAwMjIxNiAwMDAwMCBuIAowMDAwMDAzMDk2IDAw MDAwIG4gCjAwMDAwMzIwODEgMDAwMDAgbiAKMDAwMDAzMjExMSAwMDAwMCBuIAowMDAwMDI3ODU4 IDAwMDAwIG4gCjAwMDAwMDMxMTYgMDAwMDAgbiAKMDAwMDAwNDY5NyAwMDAwMCBuIAowMDAwMDMy MTQxIDAwMDAwIG4gCjAwMDAwMzIxNzEgMDAwMDAgbiAKMDAwMDAyODAyMCAwMDAwMCBuIAowMDAw MDA0NzE4IDAwMDAwIG4gCjAwMDAwMDU2NzQgMDAwMDAgbiAKMDAwMDAzMjIwMSAwMDAwMCBuIAow MDAwMDMyMjMxIDAwMDAwIG4gCjAwMDAwMjgxODIgMDAwMDAgbiAKMDAwMDAwNTY5NCAwMDAwMCBu IAowMDAwMDA2OTYzIDAwMDAwIG4gCjAwMDAwMzIyNjEgMDAwMDAgbiAKMDAwMDAzMjI5MSAwMDAw MCBuIAowMDAwMDI4MzQ0IDAwMDAwIG4gCjAwMDAwMDY5ODQgMDAwMDAgbiAKMDAwMDAwNzkxMyAw MDAwMCBuIAowMDAwMDMyMzIxIDAwMDAwIG4gCjAwMDAwMzIzNTEgMDAwMDAgbiAKMDAwMDAyODUw NiAwMDAwMCBuIAowMDAwMDA3OTMzIDAwMDAwIG4gCjAwMDAwMDg3MTAgMDAwMDAgbiAKMDAwMDAz MjM4MSAwMDAwMCBuIAowMDAwMDMyNDExIDAwMDAwIG4gCjAwMDAwMjg2NjggMDAwMDAgbiAKMDAw MDAwODczMCAwMDAwMCBuIAowMDAwMDEwMDgxIDAwMDAwIG4gCjAwMDAwMzI0NDEgMDAwMDAgbiAK MDAwMDAzMjQ3MSAwMDAwMCBuIAowMDAwMDI4ODMwIDAwMDAwIG4gCjAwMDAwMTAxMDIgMDAwMDAg biAKMDAwMDAxMDcxOCAwMDAwMCBuIAowMDAwMDMyNTAxIDAwMDAwIG4gCjAwMDAwMzI1MzEgMDAw MDAgbiAKMDAwMDAyODk5MiAwMDAwMCBuIAowMDAwMDEwNzM4IDAwMDAwIG4gCjAwMDAwMTE5MzUg MDAwMDAgbiAKMDAwMDAzMjU2MSAwMDAwMCBuIAowMDAwMDMyNTkxIDAwMDAwIG4gCjAwMDAwMjkx NTQgMDAwMDAgbiAKMDAwMDAxMTk1NiAwMDAwMCBuIAowMDAwMDEzMzQ4IDAwMDAwIG4gCjAwMDAw MzI2MjEgMDAwMDAgbiAKMDAwMDAzMjY1MSAwMDAwMCBuIAowMDAwMDI5MzE2IDAwMDAwIG4gCjAw MDAwMTMzNjkgMDAwMDAgbiAKMDAwMDAxNDQwNiAwMDAwMCBuIAowMDAwMDMyNjgxIDAwMDAwIG4g CjAwMDAwMzI3MTEgMDAwMDAgbiAKMDAwMDAyOTQ3OCAwMDAwMCBuIAowMDAwMDE0NDI2IDAwMDAw IG4gCjAwMDAwMTU1MjcgMDAwMDAgbiAKMDAwMDAzMjc0MSAwMDAwMCBuIAowMDAwMDMyNzcxIDAw MDAwIG4gCjAwMDAwMjk2NDAgMDAwMDAgbiAKMDAwMDAxNTU0OCAwMDAwMCBuIAowMDAwMDE2NjUy IDAwMDAwIG4gCjAwMDAwMzI4MDEgMDAwMDAgbiAKMDAwMDAzMjgzMSAwMDAwMCBuIAowMDAwMDI5 ODAyIDAwMDAwIG4gCjAwMDAwMTY2NzMgMDAwMDAgbiAKMDAwMDAxNzUzMiAwMDAwMCBuIAowMDAw MDMyODYxIDAwMDAwIG4gCjAwMDAwMzI4OTEgMDAwMDAgbiAKMDAwMDAyOTk2NCAwMDAwMCBuIAow MDAwMDE3NTUyIDAwMDAwIG4gCjAwMDAwMTg1NDggMDAwMDAgbiAKMDAwMDAzMjkyMSAwMDAwMCBu IAowMDAwMDMyOTUxIDAwMDAwIG4gCjAwMDAwMzAxMjYgMDAwMDAgbiAKMDAwMDAxODU2OCAwMDAw MCBuIAowMDAwMDE5NDQyIDAwMDAwIG4gCjAwMDAwMzI5ODEgMDAwMDAgbiAKMDAwMDAzMzAxMSAw MDAwMCBuIAowMDAwMDMwMjg4IDAwMDAwIG4gCjAwMDAwMTk0NjIgMDAwMDAgbiAKMDAwMDAyMDQ1 MyAwMDAwMCBuIAowMDAwMDMzMDQxIDAwMDAwIG4gCjAwMDAwMzMwNzEgMDAwMDAgbiAKMDAwMDAz MDQ1MSAwMDAwMCBuIAowMDAwMDIwNDczIDAwMDAwIG4gCjAwMDAwMjEyMTUgMDAwMDAgbiAKMDAw MDAzMzEwMiAwMDAwMCBuIAowMDAwMDMzMTMzIDAwMDAwIG4gCjAwMDAwMzA2MTcgMDAwMDAgbiAK MDAwMDAyMTIzNiAwMDAwMCBuIAowMDAwMDIyMTczIDAwMDAwIG4gCjAwMDAwMzMxNjQgMDAwMDAg biAKMDAwMDAzMzE5NSAwMDAwMCBuIAowMDAwMDMwNzgzIDAwMDAwIG4gCjAwMDAwMjIxOTQgMDAw MDAgbiAKMDAwMDAyMzM0MyAwMDAwMCBuIAowMDAwMDMzMjI2IDAwMDAwIG4gCjAwMDAwMzMyNTcg MDAwMDAgbiAKMDAwMDAzMDk0OSAwMDAwMCBuIAowMDAwMDIzMzY1IDAwMDAwIG4gCjAwMDAwMjQ0 NDcgMDAwMDAgbiAKMDAwMDAzMzI4OCAwMDAwMCBuIAowMDAwMDMzMzE5IDAwMDAwIG4gCjAwMDAw MzExMTUgMDAwMDAgbiAKMDAwMDAyNDQ2OSAwMDAwMCBuIAowMDAwMDI1NTM2IDAwMDAwIG4gCjAw MDAwMzMzNTAgMDAwMDAgbiAKMDAwMDAzMzM4MSAwMDAwMCBuIAowMDAwMDMxMjgxIDAwMDAwIG4g CjAwMDAwMjU1NTcgMDAwMDAgbiAKMDAwMDAyNjY5OCAwMDAwMCBuIAowMDAwMDMzNDEyIDAwMDAw IG4gCjAwMDAwMzM0NDMgMDAwMDAgbiAKMDAwMDAzMTQ0NyAwMDAwMCBuIAowMDAwMDI2NzIwIDAw MDAwIG4gCjAwMDAwMjczNTQgMDAwMDAgbiAKMDAwMDAzMzQ3NCAwMDAwMCBuIAowMDAwMDMzNTA1 IDAwMDAwIG4gCjAwMDAwMzM1OTggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxMzcgL1Jvb3Qg MSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8MTJENzNDNjUzREZDNEYwREY1MThDRUVGQTFDRDExRkE+ PDEyRDczQzY1M0RGQzRGMERGNTE4Q0VFRkExQ0QxMUZBPl0KPj4Kc3RhcnR4cmVmCjM1MTg0CiUl RU9GCg== ------=_NextPart_000_0068_01CF5EE0.9A12EAD0 Content-Type: text/plain; name="draft-hares-i2rs-rib-model-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-hares-i2rs-rib-model-03.txt" =0A= =0A= =0A= =0A= I2RS working group N. Bahadur=0A= Internet-Draft Bracket Computing=0A= Intended status: Standards Track R. Folkes=0A= Expires: October 25, 2014 Juniper Networks, Inc.=0A= S. Kini=0A= Ericsson=0A= S. Kini=0A= Cisco=0A= April 23, 2014=0A= =0A= =0A= Routing Information Base Info Model=0A= draft-ietf-i2rs-rib-info-model-03=0A= =0A= Abstract=0A= =0A= Routing and routing functions in enterprise and carrier networks are=0A= typically performed by network devices (routers and switches) using a=0A= routing information base (RIB). Protocols and configuration push=0A= data into the RIB and the RIB manager installs state into the=0A= hardware; for packet forwarding. This draft specifies an information=0A= model for the RIB to enable defining a standardized data model. Such=0A= a data model can be used to define an interface to the RIB from an=0A= entity that may even be external to the network device. This=0A= interface can be used to support new use-cases being defined by the=0A= IETF I2RS WG.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on October 25, 2014.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 1]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2014 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Conventions used in this document . . . . . . . . . . . . 5=0A= 2. RIB data . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2.1. RIB definition . . . . . . . . . . . . . . . . . . . . . 6=0A= 2.2. Routing instance . . . . . . . . . . . . . . . . . . . . 6=0A= 2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 2.4.1. Nexthop types . . . . . . . . . . . . . . . . . . . . 11=0A= 2.4.2. Nexthop list attributes . . . . . . . . . . . . . . . 12=0A= 2.4.3. Nexthop content . . . . . . . . . . . . . . . . . . . 13=0A= 2.4.4. Special nexthops . . . . . . . . . . . . . . . . . . 14=0A= 3. Reading from the RIB . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Writing to the RIB . . . . . . . . . . . . . . . . . . . . . 14=0A= 5. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 6. RIB Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 6.1. RBNF Form of Grammar . . . . . . . . . . . . . . . . . . 15=0A= 6.2. UML Form of Grammar . . . . . . . . . . . . . . . . . . . 20=0A= 6.3. Yang Data Model Tree Form-IM . . . . . . . . . . . . . . 20=0A= 7. Using the Rib Grammar . . . . . . . . . . . . . . . . . . . . 22=0A= 7.1. Using Route preference . . . . . . . . . . . . . . . . . 22=0A= 7.2. Using different nexthop types . . . . . . . . . . . . . . 22=0A= 7.2.1. Tunnel nexthops . . . . . . . . . . . . . . . . . . . 22=0A= 7.2.2. Replication List . . . . . . . . . . . . . . . . . . 22=0A= 7.2.3. Weighted lists . . . . . . . . . . . . . . . . . . . 23=0A= 7.2.4. Protection lists . . . . . . . . . . . . . . . . . . 23=0A= 7.2.5. Nexthop chains . . . . . . . . . . . . . . . . . . . 23=0A= 7.2.6. lists of lists . . . . . . . . . . . . . . . . . . . 23=0A= 8. RIB operations at scale . . . . . . . . . . . . . . . . . . . 24=0A= 8.1. RIB reads . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 8.2. RIB Writes . . . . . . . . . . . . . . . . . . . . . . . 24=0A= 8.3. RIB events and notifications . . . . . . . . . . . . . . 24=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 2]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24=0A= 10. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25=0A= 12. Informative References . . . . . . . . . . . . . . . . . . . 25=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26=0A= =0A= 1. Introduction=0A= =0A= Routing and routing functions in enterprise and carrier networks are=0A= traditionally performed in network devices. Traditionally routers=0A= run routing protocols and the routing protocols (along with static=0A= config) populate the Routing information base (RIB) of the router.=0A= The RIB is managed by the RIB manager and the RIB manager provides a=0A= north-bound interface to its clients i.e. the routing protocols to=0A= insert routes into the RIB. The RIB manager consults the RIB and=0A= decides how to program the forwarding information base (FIB) of the=0A= hardware by interfacing with the FIB manager. The relationship=0A= between these entities is shown in Figure 1.=0A= =0A= +-------------+ +-------------+=0A= |RIB client 1 | ...... |RIB client N |=0A= +-------------+ +-------------+=0A= ^ ^=0A= | |=0A= +----------------------+=0A= |=0A= V=0A= +---------------------+=0A= |RIB manager |=0A= | |=0A= | +-----+ |=0A= | | RIB | |=0A= | +-----+ |=0A= +---------------------+=0A= ^=0A= |=0A= +---------------------------------+=0A= | |=0A= V V=0A= +-------------+ +-------------+=0A= |FIB manager 1| |FIB manager M|=0A= | +-----+ | .......... | +-----+ |=0A= | | FIB | | | | FIB | |=0A= | +-----+ | | +-----+ |=0A= +-------------+ +-------------+=0A= =0A= =0A= Figure 1:RIB manager, RIB clients and FIB managers=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 3]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Routing protocols are inherently distributed in nature and each=0A= router makes an independent decision based on the routing data=0A= received from its peers. With the advent of newer deployment=0A= paradigms and the need for specialized applications, there is an=0A= emerging need to guide the router's routing function=0A= [I-D.ietf-i2rs-problem-statement]. Traditional network-device=0A= protocol-based RIB population suffices for most use cases where=0A= distributed network control is used. However there are use cases=0A= which the network operators currently address by configuring static=0A= routes, policies and RIB import/export rules on the routers. There=0A= is also a growing list of use cases [I-D.white-i2rs-use-case],=0A= [I-D.hares-i2rs-use-case-vn-vc] in which a network operator might=0A= want to program the RIB based on data unrelated to just routing=0A= (within that network's domain). Programming the RIB could be based=0A= on other information such as routing data in the adjacent domain or=0A= the load on storage and compute in the given domain. Or it could=0A= simply be a programmatic way of creating on-demand dynamic overlays=0A= (e.g. GRE tunnels) between compute hosts (without requiring the hosts=0A= to run traditional routing protocols). If there was a standardized=0A= publicly documented programmatic interface to a RIB, it would enable=0A= further networking applications that address a variety of use-cases=0A= [I-D.ietf-i2rs-problem-statement]=0A= =0A= A programmatic interface to the RIB involves 2 types of operations -=0A= reading from the RIB and writing (adding/modifying/deleting) to the=0A= RIB. [I-D.white-i2rs-use-case] lists various use-cases which require=0A= read and/or write manipulation of the RIB.=0A= =0A= In order to understand what is in a router's RIB, methods like per-=0A= protocol SNMP MIBs and show output screen scraping are used. These=0A= methods are not scalable, since they are client pull mechanisms and=0A= not proactive push (from the router) mechanisms. Screen scraping is=0A= error prone (since the output format can change) and is vendor=0A= dependent. Building a RIB from per-protocol MIBs is error prone=0A= since the MIB data represent protocol data and not the exact=0A= information that went into the RIB. Thus, just getting read-only RIB=0A= information from a router is a hard task.=0A= =0A= Adding content to the RIB from an external entity can be done today=0A= using static configuration mechanisms provided by router vendors.=0A= However the mix of what can be modified in the RIB varies from vendor=0A= to vendor and the method of configuring it is also vendor dependent.=0A= This makes it hard for an external entity to program a multi-vendor=0A= network in a consistent and vendor-independent way.=0A= =0A= he purpose of this draft is to specify an information model for the=0A= RIB. Using the information model, one can build a detailed data=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 4]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= model for the RIB. That data model could then be used by an external=0A= entity to program a network device.=0A= =0A= The rest of this document is organized as follows. Section 2 goes=0A= into the details of what constitutes and can be programmed in a RIB.=0A= Guidelines for reading and writing the RIB are provided in section 3.=0A= and Section 4 respectively. Section 5 provides a high-level view of=0A= the events and notifications going from a network device to an=0A= external entity, to update the external entity on asynchronous=0A= events. The RIB grammar is specified in Section 6. Examples of=0A= using the RIB grammar are shown in Section 7. Section 8 covers=0A= considerations for performing RIB operations at scale.=0A= =0A= 1.1. Conventions used in this document=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 2. RIB data=0A= =0A= This section describes the details of a RIB. It makes forward=0A= references to objects in the RIB grammar (Section 6). A high-level=0A= description of the RIB contents is as shown below.=0A= =0A= routing-instance=0A= =0A= | |=0A= | |=0A= 0..N | | 1..N=0A= | |=0A= =0A= =0A= interface(s) RIB(s)=0A= =0A= =0A= |=0A= |=0A= | 0..N=0A= =0A= =0A= route(s)=0A= =0A= Figure 2: RIB model=0A= =0A= Figure 3: RIB Model=0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 5]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.1. RIB definition=0A= =0A= A RIB is an entity that contains routes. A RIB is identified by its=0A= name and a RIB is contained within a routing instance (Section 2.2).=0A= The name MUST be unique within a routing instance. All routes in a=0A= given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST belong=0A= to a routing instance.=0A= =0A= A RIB is an entity that contains routes. A RIB is identified by its=0A= name and a RIB is contained within a routing instance (Section 2.2).=0A= The name MUST be unique within a routing instance. All routes in a=0A= given RIB MUST be of the same type (e.g. IPv4). Each RIB MUST belong=0A= to a routing instance.=0A= =0A= A routing instance can have multiple RIBs. A routing instance can=0A= even have two or more RIBs with the same type of routes (e.g. IPv6).=0A= A typical case where this can be used is for multi-topology routing=0A= ([RFC4915], [RFC5120].=0A= =0A= Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK=0A= attribute that enables Reverse path forwarding (RPF) checks on all IP=0A= routes in that RIB. Reverse path forwarding (RPF) check is used to=0A= prevent spoofing and limit malicious traffic. For IP packets, the IP=0A= source address is looked up and the rpf interface(s) associated with=0A= the route for that IP source address is found. If the incoming IP=0A= packet's interface matches one of the rpf interface(s), then the IP=0A= packet is forwarded based on its IP destination address; otherwise,=0A= the IP packet is discarded.=0A= =0A= 2.2. Routing instance=0A= =0A= A routing instance, in the context of the RIB information model, is a=0A= collection of RIBs, interfaces, and routing parameters. A routing=0A= instance creates a logical slice of the router and allows different=0A= logical slices; across a set of routers; to communicate with each=0A= other. Layer 3 Virtual Private Networks (VPN), Layer 2 VPNs (L2VPN)=0A= and Virtual Private Lan Service (VPLS) can be modeled as routing=0A= instances. Note that modeling a Layer 2 VPN using a routing instance=0A= only models the Layer-3 (RIB) aspect and does not model any layer-2=0A= information (like ARP) that might be associated with the L2VPN.=0A= =0A= The set of interfaces indicates which interfaces are associated with=0A= this routing instance. The RIBs specify how incoming traffic is to=0A= be forwarded. And the routing parameters control the information in=0A= the RIBs. The intersection set of interfaces of 2 routing instances=0A= MUST be the null set. In other words, an interface MUST NOT be=0A= present in 2 routing instances. Thus a routing instance describes=0A= the routing information and parameters across a set of interfaces.=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 6]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= A routing instance MUST contain the following mandatory fields.=0A= =0A= o INSTANCE_NAME: A routing instance is identified by its name,=0A= INSTANCE_NAME. This MUST be unique across all routing instances=0A= in a given network device.=0A= =0A= o rib-list: This is the list of RIBs associated with this routing=0A= instance. Each routing instance can have multiple RIBs to=0A= represent routes of different types. For example, one would put=0A= IPv4 routes in one RIB and MPLS routes in another RIB.=0A= =0A= A routing instance MAY contain the following optional fields.=0A= =0A= o interface-list: This represents the list of interfaces associated=0A= with this routing instance. The interface list helps constrain=0A= the boundaries of packet forwarding. Packets coming on these=0A= interfaces are directly associated with the given routing=0A= instance. The interface list contains a list of identifiers, with=0A= each identifier uniquely identifying an interface.=0A= =0A= o ROUTER_ID: The router-id field identifies the network device in=0A= control plane interactions with other network devices. This field=0A= is to be used if one wants to virtualize a physical router into=0A= multiple virtual routers. Each virtual router MUST have a unique=0A= router-id. ROUTER_ID MUST be unique across all network devices in=0A= a given domain.=0A= =0A= 2.3. Route=0A= =0A= A route is essentially a match condition and an action following the=0A= match. The match condition specifies the kind of route (IPv4, MPLS,=0A= etc.) and the set of fields to match on. Figure 3 represents the=0A= overall contents of a route.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 7]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= route=0A= =0A= =0A= | | |=0A= +---------+ | +----------+=0A= | | |=0A= 0..N | | | 1..N=0A= =0A= route-attribute match nexthop-list=0A= =0A= =0A= |=0A= |=0A= +-------+-------+-------+--------+=0A= | | | | |=0A= | | | | |=0A= =0A= IPv4 IPv6 MPLS MAC Interface=0A= =0A= =0A= (Unicast/Multicast)=0A= =0A= =0A= =0A= Figure 3: Route model=0A= =0A= =0A= This document specifies the following match types:=0A= =0A= o IPv4: Match on destination IP address in the IPv4 header=0A= =0A= o IPv6: Match on destination IP address in the IPv6 header=0A= =0A= o MPLS: Match on a MPLS label at the top of the MPLS label stack=0A= =0A= o MAC: Match on MAC destination addresses in the ethernet header=0A= =0A= o Interface: Match on incoming interface of the packet=0A= =0A= o IP multicast: Match on (S, G) or (*, G), where S and G are IP=0A= prefixes=0A= =0A= Each route MUST have associated with it the following mandatory route=0A= attributes.=0A= =0A= o ROUTE_PREFERENCE: This is a numerical value that allows for=0A= comparing routes from different protocols. Static configuration=0A= is also considered a protocol for the purpose of this field. It=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 8]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= is also known as administrative-distance. The lower the value,=0A= the higher the preference. For example there can be an OSPF route=0A= for 192.0.2.1/32 with a preference of 5. If a controller programs=0A= a route for 192.0.2.1/32 with a preference of 2, then the=0A= controller's route will be preferred by the RIB manager.=0A= Preference should be used to dictate behavior. For more examples=0A= of preference, see Section 7.1.=0A= =0A= Each route can have associated with it one or more optional route=0A= attributes.=0A= =0A= o route-vendor-attributes: Vendors can specify vendor-specific=0A= attributes using this. The details of this attribute is outside=0A= the scope of this document.=0A= =0A= 2.4. Nexthop=0A= =0A= A nexthop represents an object resulting from a route lookup. For=0A= example, if a route lookup results in sending the packet out a given=0A= interface, then the nexthop represents that interface.=0A= =0A= Nexthops can be fully resolved nexthops or unresolved nexthop. A=0A= resolved nexthop has adequate information to send the outgoing packet=0A= to the destination by forwarding it on an interface to a directly=0A= connected neighbor. For example, a nexthop to a point-to-point=0A= interface or a nexthop to an IP address on an Ethernet interface has=0A= the nexthop resolved. An unresolved nexthop is something that=0A= requires the RIB manager to determine the final resolved nexthop.=0A= For example, a nexthop could be an IP address. The RIB manager would=0A= resolve how to reach that IP address, e.g. is the IP address=0A= reachable by regular IP forwarding or by a MPLS tunnel or by both.=0A= If the RIB manager cannot resolve the nexthop, then the nexthop=0A= remains in an unresolved state and is NOT a candidate for=0A= installation in the FIB. Future RIB events can cause an unresolved=0A= nexthop to get resolved (like that IP address being advertised by an=0A= IGP neighbor). Conversely resolved nexthops can also become=0A= unresolved (e.g. in case of a tunnel going down) and hence would no=0A= longer be candidates to be installed in the FIB.=0A= =0A= When at least one of a route's nexthops is resolved, then the route=0A= can be used to forward packets. Such a route is considered eligible=0A= to be installed in the FIB and is henceforth referred to as a FIB-=0A= eligible route. Conversely, when all the nexthops of a route are=0A= unresolved that route can no longer be used to forward packets. Such=0A= a route is considered ineligible to be installed in the FIB and is=0A= henceforth referred to as a FIB-ineligible route. The RIB=0A= information model allows an external entity to program routes whose=0A= nexthops may be unresolved initially. Whenever an unresolved nexthop=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 9]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= gets resolved, the RIB manager will send a notification of the same=0A= (see Section 5 ).=0A= =0A= The overall structure and usage of a nexthop is as shown in the=0A= figure below.=0A= =0A= route=0A= =0A= =0A= |=0A= | 0..N=0A= =0A= =0A= nexthop-list=0A= =0A= |=0A= +------------------+------------------+=0A= 1..N | |=0A= | |=0A= =0A= nexthop-list-member special-nexthop=0A= =0A= =0A= |=0A= |=0A= =0A= nexthop-chain=0A= =0A= =0A= |=0A= 1..N |=0A= =0A= =0A= nexthop=0A= =0A= =0A= |=0A= |=0A= +--------+------+------------------+------------------+=0A= | | | |=0A= | | | |=0A= =0A= nexthop-id egress-interface logical-tunnel tunnel-encap=0A= =0A= Figure 4: Nexthop model=0A= =0A= Nexthops can be identified by an identifier to create a level of=0A= indirection. The identifier is set by the RIB manager and returned=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 10]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= to the external entity on request. The RIB data-model SHOULD support=0A= a way to optionally receive a nexthop identifier for a given nexthop.=0A= For example, one can create a nexthop that points to a BGP peer. The=0A= returned nexthop identifier can then be used for programming routes=0A= to point to the same nexthop. Given that the RIB manager has created=0A= an indirection for that BGP peer using the nexthop identifier, if the=0A= transport path to the BGP peer changes, that change in path will be=0A= seamless to the external entity and all routes that point to that BGP=0A= peer will automatically start going over the new transport path.=0A= Nexthop indirection using identifiers could be applied to not just=0A= unicast nexthops, but even to nexthops that contain chains and nested=0A= nexthops (Section 2.4.1).=0A= =0A= 2.4.1. Nexthop types=0A= =0A= This document specifies a very generic, extensible and recursive=0A= grammar for nexthops. Nexthops can be=0A= =0A= o Unicast nexthops - pointing to an interface=0A= =0A= o Tunnel nexthops - pointing to a tunnel=0A= =0A= o Replication lists - list of nexthops to which to replicate a=0A= packet=0A= =0A= o Weighted lists - for load-balancing=0A= =0A= o Protection lists - for primary/backup paths=0A= =0A= o Nexthop chains - for chaining headers, e.g. MPLS label over a GRE=0A= header=0A= =0A= o Lists of lists - recursive application of the above=0A= =0A= o Indirect nexthops - pointing to a nexthop identifier=0A= =0A= o Special nexthops - for performing specific well-defined functions=0A= =0A= It is expected that all network devices will have a limit on how many=0A= levels of lookup can be performed and not all hardware will be able=0A= to support all kinds of nexthops. RIB capability negotiation becomes=0A= very important for this reason and a RIB data-model MUST specify a=0A= way for an external entity to learn about the network device's=0A= capabilities. Examples of when and how to use various kinds of=0A= nexthops are shown in Section 7.2.=0A= =0A= Tunnel nexthops allow an external entity to program static tunnel=0A= headers. There can be cases where the remote tunnel end-point does=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 11]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= not support dynamic signaling (e.g. no LDP support on a host) and in=0A= those cases the external entity might want to program the tunnel=0A= header on both ends of the tunnel. The tunnel nexthop is kept=0A= generic with specifications provided for some commonly used tunnels.=0A= It is expected that the data-model will model these tunnel types with=0A= complete accuracy.=0A= =0A= Nexthop chains can be used to specify multiple headers over a packet,=0A= before a packet is forwarded. One simple example is that of MPLS=0A= over GRE, wherein the packet has an inner MPLS header followed by a=0A= GRE header followed by an IP header. The outermost IP header is=0A= decided by the network device whereas the MPLS header and GRE header=0A= are specified by the controller. Not every network device will be=0A= able to support all kinds of nexthop chains and an arbitrary number=0A= of header chained together. The RIB data-model SHOULD provide a way=0A= to expose nexthop chaining capability supported by a given network=0A= device.=0A= =0A= 2.4.2. Nexthop list attributes=0A= =0A= For nexthops that are of the form of a list(s), attributes can be=0A= associated with each member of the list to indicate the role of an=0A= individual member of the list. Two kinds of attributes are=0A= specified:=0A= =0A= o PROTECTION_PREFERENCE: This provides a primary/backup like=0A= preference. The preference is an integer value that should be set=0A= to 1 (primary) or 2 (backup). Only when all the primary nexthops=0A= fail is the traffic re-routed through the backup nexthops. This=0A= attribute must be specified for all the members of a list or none=0A= of them.=0A= =0A= o LOAD_BALANCE_WEIGHT: This is used for load-balancing. Each list=0A= member MUST be assigned a weight between 1 and 99. The weight=0A= determines the proportion of traffic to be sent over a nexthop=0A= used for forwarding as a ratio of the weight of this nexthop=0A= divided by the weights of all the nexthops of this route that are=0A= used for forwarding. To perform equal load-balancing, one MAY=0A= specify a weight of "0" for all the member nexthops. The value=0A= "0" is reserved for equal load-balancing and if applied, MUST be=0A= applied to all member nexthops.=0A= =0A= A nexthop list MAY contain elements that have both=0A= PROTECTION_PREFERENCE and LOAD_BALANCE_WEIGHT set. When both are=0A= set, it means under normal operation the network device should load=0A= balance the traffic over all FIB-eligible nexthops of the current=0A= protection preference.=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 12]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.4.3. Nexthop content=0A= =0A= At the lowest level, a nexthop can be one of:=0A= =0A= o identifier: This is an identifier returned by the network device=0A= representing another nexthop or another nexthop chain=0A= =0A= o EGRESS_INTERFACE: This represents a physical, logical or virtual=0A= interface on the network device. Address resolution must not be=0A= required on this interface. This interface may belong to any=0A= routing instance.=0A= =0A= o IP address: A route lookup on this IP address is done to determine=0A= the egress interface. Address resolution may be required=0A= depending on the interface.=0A= =0A= * An optional RIB name can also be specified to indicate the RIB=0A= in which the IP address is to be looked up. One can use the=0A= RIB name field to direct the packet from one domain into=0A= another domain. By default the RIB will be the same as the one=0A= that route belongs to.=0A= =0A= o EGRESS_INTERFACE and IP address: This can be used in cases e.g.=0A= where the IP address is a link-local address.=0A= =0A= o EGRESS_INTERFACE and MAC address: The egress interface must be an=0A= ethernet interface. Address resolution is not required for this=0A= nexthop.=0A= =0A= o tunnel encap: This can be an encap representing an IP tunnel or=0A= MPLS tunnel or others as defined in this document. An optional=0A= egress interface can be specified to indicate which interface to=0A= send the packet out on. The egress interface is useful when the=0A= network device contains Ethernet interfaces and one needs to=0A= perform address resolution for the IP packet.=0A= =0A= o logical tunnel: This can be a MPLS LSP or a GRE tunnel (or others=0A= as defined in this document), that is represented by a unique=0A= identifier (E.g. name).=0A= =0A= o RIB_NAME: A nexthop pointing to a RIB indicates that the route=0A= lookup needs to continue in the specified RIB. This is a way to=0A= perform chained lookups.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 13]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 2.4.4. Special nexthops=0A= =0A= This document specifies certain special nexthops. The purpose of=0A= each of them is explained below:=0A= =0A= o DISCARD: This indicates that the network device should drop the=0A= packet and increment a drop counter.=0A= =0A= o DISCARD_WITH_ERROR: This indicates that the network device should=0A= drop the packet, increment a drop counter and send back an=0A= appropriate error message (like ICMP error).=0A= =0A= o RECEIVE: This indicates that that the traffic is destined for the=0A= network device. For example, protocol packets or OAM packets.=0A= All locally destined traffic SHOULD be throttled to avoid a denial=0A= of service attack on the router's control plane. An optional=0A= rate-limiter can be specified to indicate how to throttle traffic=0A= destined for the control plane. The description of the rate-=0A= limiter is outside the scope of this document.=0A= =0A= 3. Reading from the RIB=0A= =0A= A RIB data-model MUST allow an external entity to read entries, for=0A= RIBs created by that entity. The network device administrator MAY=0A= allow reading of other RIBs by an external entity through access=0A= lists on the network device. The details of access lists are outside=0A= the scope of this document.=0A= =0A= The data-model MUST support a full read of the RIB and subsequent=0A= incremental reads of changes to the RIB. An external agent SHOULD be=0A= able to request a full read at any time in the lifecycle of the=0A= connection. When sending data to an external entity, the RIB manager=0A= SHOULD try to send all dependencies of an object prior to sending=0A= that object.=0A= =0A= 4. Writing to the RIB=0A= =0A= A RIB data-model MUST allow an external entity to write entries, for=0A= RIBs created by that entity. The network device administrator MAY=0A= allow writes to other RIBs by an external entity through access lists=0A= on the network device. The details of access lists are outside the=0A= scope of this document.=0A= =0A= When writing an object to a RIB, the external entity SHOULD try to=0A= write all dependencies of the object prior to sending that object.=0A= The data-model MUST support requesting identifiers for nexthops and=0A= collecting the identifiers back in the response.=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 14]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= Route programming in the RIB MUST result in a return code that=0A= contains the following attributes:=0A= =0A= o Installed - Yes/No (Indicates whether the route got installed in=0A= the FIB)=0A= =0A= o Active - Yes/No (Indicates whether a route is fully resolved and=0A= is a candidate for selection)=0A= =0A= o Reason - E.g. Not authorized=0A= =0A= The data-model MUST specify which objects are modify-able objects. A=0A= modify-able object is one whose contents can be changed without=0A= having to change objects that depend on it and without affecting any=0A= data forwarding. To change a non-modifiable object, one will need to=0A= create a new object and delete the old one. For example, routes that=0A= use a nexthop that is identified by a nexthop-identifier should be=0A= unaffected when the contents of that nexthop changes.=0A= =0A= 5. Notifications=0A= =0A= Asynchronous notifications are sent by the network device's RIB=0A= manager to an external entity when some event occurs on the network=0A= device. A RIB data-model MUST support sending asynchronous=0A= notifications. A brief list of suggested notifications is as below:=0A= =0A= o Route change notification, with return code as specified in=0A= Section 4.=0A= =0A= o Nexthop resolution status (resolved/unresolved) notification=0A= =0A= 6. RIB Grammar=0A= =0A= 6.1. RBNF Form of Grammar=0A= =0A= This section specifies the RIB information model in Routing Backus-=0A= Naur Form [RFC5511]=0A= =0A= =0A= RIB_GRAMMAR=0A= =0A= ::=3D ! import routing IM=0A= [ ] ! (sequence of interfaces)=0A= ! (sequences of ribs)=0A= [ ] ! import routing IM=0A= =0A= ! no list identifier for these lists=0A= ::=3D ( ...)=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 15]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ::=3D ( ...)=0A= =0A= !RIB Definitions=0A= ::=3D ! imported routing IM=0A= ! import routing IM=0A= [ ... ]=0A= [ ] ! I2RS Boolean=0A= =0A= ::=3D ! I2RS=0A= [ ] ! I2RS=0A= [ ] ! I2RS=0A= =0A= ::=3D [ ] ! I2RS=0A= [ =0A= | =0A= | =0A= | =0A= | ]=0A= =0A= ::=3D | ! I2RS=0A= | ! I2RS=0A= =0A= ::=3D | ! I2RS=0A= | | ! I2RS=0A= =0A= =0A= =0A= ! import from IETF information models=0A= =0A= ::=3D ( ...) ! I2RS=0A= ::=3D (ipv6-prefix>...) ! I2RS=0A= ::=3D ( ...) ! I2RS=0A= ::=3D ( ... ) ! I2RS=0A= ::=3D ! I2RS=0A= =0A= =3D ! I2RS (per Nitin)=0A= [( ... )=0A= [PROTECTION_PREFERENCE] ! I2RS=0A= [LOAD_BALANCE_WEIGHT] ! I2RS=0A= =0A= =0A= =0A= :: =3D ! [New] I2RS nexthop format=0A= [ ] ! [Nitin] NH type=0A= [ | ]=0A= [ ]=0A= [ | =0A= | ]=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 16]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= [ ]=0A= [ >]=0A= [ ]=0A= =0A= ! types of formats (I2RS ENUM) ! Format=0A= =0A= :: =3D ! Name of NH chain=0A= | ! ID of NH chain=0A= | ! NH-TYPE address (v4/v6, mac, egress-if)=0A= | ! NH_TYPE, egress-if, address(v4/v6),=0A= ! RIB_name=0A= | ! INTERFACE_IDENTIFIER, mac-adders=0A= | ! NH_TYPE, tunnel-name (string)=0A= | ! tunnel encapsulation=0A= =0A= ::=3D | !IRS ENUM=0A= | =0A= | | | =0A= | | =0A= =0A= ::=3D [ipv4-header] | ! import from ip=0A= [ipv6-header] | ! import from ip=0A= [mpls-header] | ! import mpls header=0A= [gre-header] | ! import from gre header=0A= [vxlan-header] | ! import from vxlan header=0A= [nvgre-header] ! import from nvgre header=0A= =0A= ::=3D ! I2RS defined=0A= [ ] ! I2RS defined=0A= [ROUTE_ACTIVE][ROUTE_INSTALLED] ! I2RS defined=0A= [ | ! imported=0A= | ! imported=0A= ] ! imported=0A= =0A= :: <> ! imported from Vendor=0A= =0A= ::=0A= =0A= RIB RBNF GRAMMAR PART 2 - Definitions=0A= =0A= ! Definitions to be Imported from Other IETF Informational models=0A= ! From routing IM (yang)=0A= =0A= ::=3D=3D rt.routing-instance.name !String=0A= :: =3D rt.routing-instance.router-id ! UNIT32=0A= ::=3D = rt.routing-instance.interfaces.interface.name=0A= =0A= ::=3D rt.routing-instance.ribs.rib.address-family=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 17]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ! IPV4_RIB_FAMILY | IPV6_RIB_FAMILY |=0A= ! MPLS_RIB_FAMILY | IEEE_RIB_FAMILY=0A= =0A= ::=3D rt.routing-instance.ribs.rib.name !STRING=0A= ::=3D rt.mpls.label=0A= ::=3Drt.route.admin-distance=0A= =0A= !I2RS redefinition=0A= =0A= ::=3D =0A= ::=3D =0A= ::=3D=0A= ::=3D =0A= ::=3D =0A= =0A= !From RFC6991 Common types=0A= =0A= ::=3D yang.mac_address=0A= ::=3D yang.ipv4-prefix=0A= ::=3D yang.ipv6-prefix=0A= ::=3D yang.ipv4-address=0A= ::=3D yang.ipv6-address=0A= =0A= !I2RS Definition - may want to add to Routing IM=0A= =0A= ::=3D STRING ! Next hop name=0A= ::=3D INTEGER-32 ! Next hop ID number=0A= ::=3D STRING ! tunnel name=0A= ::=3D BOOLEAN ! denotes if only LOCAL=0A= ::=3DBOOLEAN ! route ACTIVE route=0A= ::BOOLEAN ! route installed in FIB=0A= =0A= ! Should be in Yang IM -ip packet=0A= =0A= ::=3D =0A= =0A= =0A= []=0A= []=0A= =0A= ::=3D UINT8=0A= ::=3D UNIT8=0A= ::=3D=0A= =0A= =0A= []=0A= []=0A= []=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 18]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ! Should be in mpls-packet IM=0A= ::=3D ([]=0A= [ [] )=0A= | [])=0A= ! Should be in encapsulations=0A= =0A= ::=3D =0A= =0A= =0A= ::=3D( | )=0A= []=0A= =0A= ::=3D( | )=0A= []=0A= []=0A= =0A= ! Definitions of ENUM or BOOLEAN=0A= ::=3D BOOLEAN ! I2RS TRUE/FALSE=0A= ::=3D ! I2RS ENUM=0A= | =0A= | =0A= | =0A= =0A= ::=3D | ! I2RS ENUM=0A= | =0A= ::=3D BOOLEAN ! I2RS LOGICAL TRUE/FALSE=0A= ::=3D BOOLEAN ! I2RS LOGICAL = TRUE/FALSE=0A= ::=3D =0A= | ! (Per NITIN's EMAIL)=0A= =0A= ::=3D , ! I2RS ENUM list=0A= | ! nexthop-id format=0A= | ! single address format=0A= | ! Egress interface 1 format=0A= | ! Egress interface 2 format=0A= | ! Logical tunnel format=0A= | ! tunnel encapsulation=0A= =0A= :: =3D !I2RS Enum=0A= | =0A= | =0A= | =0A= | =0A= | =0A= =0A= !Imported from undefined Information Models=0A= :: =3D <> ! imported from rt-routing=0A= :: =3D <> ! imported from mpls-routing=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 19]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= ::=3D <> ! imported from ethernet=0A= :: <> ! imported from vendors=0A= =0A= =0A= =0A= 6.2. UML Form of Grammar=0A= =0A= The UML form will be inserted here if graphics can be associated=0A= =0A= 6.3. Yang Data Model Tree Form-IM=0A= =0A= Format of the Yang=0A= =0A= o Brackets "[" and "]" enclose list keys.=0A= =0A= o Abbreviations before data node names: "rw" means configuration=0A= (read-write) and "ro" state data (read-only).=0A= =0A= o Symbols after data node names: "?" means an optional node, "!"=0A= means a presence container, and "*" denotes a list and leaf-list.=0A= =0A= o Parentheses enclose choice and case nodes, and case nodes are also=0A= marked with a colon (":").=0A= =0A= o Ellipsis ("...") stands for contents of subtrees that are not=0A= shown.=0A= =0A= o I: is the symbol for the import definition=0A= =0A= o D: is the symbol for the I2RS definition=0A= =0A= o (M) is yang definition for this is missing=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 20]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= +--ir2s=0A= +--rw routing-instance=0A= +--rw INSTANCE_NAME [1] I:rt.routing-instance.name=0A= +--rw interface-list [1] ?=0A= | +--rw Interface_Identifier* [0..n] ?=0A= I:rt.routing-instance.interfaces.interface.name=0A= | +--rw rib-list [1]=0A= | | +--rw rib [1..n]=0A= | | | +--rw name [1] I:rt.routing-instance.ribs.rib.name=0A= | | | +--rw address-family [1]=0A= | | | +--rw route [1..n]=0A= | | | |--+--rw rt-match=0A= | | | | |--+--rw route-type [1] D:I2RS ENUM=0A= | | | | | +--rw route-form [1] D:I2RS ENUM=0A= | | | | | +--rw route-prefix [1..2]=0A= | | | | | +--rw ip-v4-prefix [0..2] ? I:yang.ipv4-prefix=0A= | | | | | +--rw ip-v6-prefix [0..2] ? = I:yang.ipv6-prefix=0A= | | | | | +--rw mpls-prefix [0..1] ? I:mpls.mpls-label=0A= | | | | | +--rw ieee-mac-prefix [0..2] ? I:yang.MAC_ADDRESS=0A= | | | | | +--rw interface-identifier [0..1]=0A= = I:rt.routing-instance.interfaces.interface.name=0A= | | | |--+--rw next-hop-list=0A= | | | | | +--rw nexthop [1..N]=0A= | | | | | | +--NH_FORM [1] D:I2RS ENUM=0A= | | | | | | +--NH_TYPE [1] ? D:I2RS ENUM=0A= | | | | | | +--NEXTHOP_NAME [0..1] ? D:I2RS STRING=0A= | | | | | | +--NEXTHOP_ID [0..1] ? D:I2RS UINT32=0A= | | | | | | +--INTERFACE_IDENTIFIER [0..1] ? I:STRING=0A= = I:rt.routing-instance.route.outgoing-interface=0A= | | | | | | +--ipv4-address [0..1] ? I.yang.ipv4-address=0A= | | | | | | +--ipv6-address [0..1] ? I.yang.ipv6-address=0A= | | | | | | +--rw ieee-mac-prefix [1] ? I:yang.MAC_ADDRESS=0A= | | | | | | +--rw RIB_ID [0..1] ? D:I2RS to rib-name=0A= I:rt.routing-instance.ribs.rib.name=0A= | | | | | | +--rw TUNNEL-NAME [0..1] ? D:I2RS STRING=0A= | | | | | | +--rw tunnel-encap [0..1] ?=0A= | | | | | | | +--ipv4-header [0..1] ? I:ip-packets (M)=0A= | | | | | | | +--ipv6-header [0..1] ? I:ip-packets (M)=0A= | | | | | | | +--mpls-header [0..1] ? I:mpls-packets (M)=0A= | | | | | | | +--gre-header [0..1] ? I:gre-packets (M)=0A= | | | | | | | +--vxlan-header [0..1] ? I:vxlan-packets (M)=0A= | | | | | | | +--nvgre-header [0..1] ? I:nvgre-packets (M)=0A= | | | | | +--rw PROTECTION_PREFERENCE [0..1] ? D:I2RS = Boolean=0A= | | | | | +--rw LOAD_BALANCE_WEIGHT [0..1] ? D:I2RS = Boolean=0A= | | | | | +--rw special-nexthop [1] ? I:IR2S ENUM:=0A= ENUM VALUES: DISCARD, DISCARD_WITH_ERROR=0A= |--+rw router-id [0..1] ? I:rt.routing.instance.router-id=0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 21]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= One thing the examination of the yang data models indicates is that=0A= you do not have the read-only portion versus the read-write portion=0A= of the informational model done.=0A= =0A= 7. Using the Rib Grammar=0A= =0A= The RIB grammar is very generic and covers a variety of features.=0A= This section provides examples on using objects in the RIB grammar=0A= and examples to program certain use cases.=0A= =0A= 7.1. Using Route preference=0A= =0A= Using route preference a client can pre-install alternate paths in=0A= the network. For example, if OSPF has a route preference of 10, then=0A= another client can install a route with route preference of 20 to the=0A= same destination. The OSPF route will get precedence and will get=0A= installed in the FIB. When the OSPF route is withdrawn, the=0A= alternate path will get installed in the FIB.=0A= =0A= Route preference can also be used to prevent denial of service=0A= attacks by installing routes with the best preference, which either=0A= drops the offending traffic or routes it to some monitoring/analysis=0A= station. Since the routes are installed with the best preference,=0A= they will supersede any route installed by any other protocol.=0A= =0A= 7.2. Using different nexthop types=0A= =0A= The RIB grammar allows one to create a variety of nexthops. This=0A= section describes uses for certain types of nexthops.=0A= =0A= 7.2.1. Tunnel nexthops=0A= =0A= A tunnel nexthop points to a tunnel of some kind. Traffic that goes=0A= over the tunnel gets encapsulated with the tunnel encap. Tunnel=0A= nexthops are useful for abstracting out details of the network, by=0A= having the traffic seamlessly route between network edges.=0A= =0A= 7.2.2. Replication List=0A= =0A= One can create a replication list for replication traffic to multiple=0A= destinations. The destinations, in turn, could be complex nexthops=0A= in themselves - at a level supported by the network device. Point to=0A= multipoint and broadcast are examples that involve replication.=0A= =0A= ::=3D () ...=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 22]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 7.2.3. Weighted lists=0A= =0A= A weighted list is used to load-balance traffic among a set of=0A= nexthops. From a modeling perspective, a weighted list is very=0A= similar to a replication list, with the difference that each member=0A= nexthop MUST have a LOAD_BALANCE_WEIGHT associated with it.=0A= =0A= ::=3D ( )...=0A= =0A= 7.2.4. Protection lists=0A= =0A= Protection lists are similar to weighted lists. A protection list=0A= specifies a set of primary nexthops and a set of backup nexthops.=0A= The attribute indicates which nexthop is=0A= primary and which is backup.=0A= =0A= ::=3D ( )...=0A= =0A= A protection list can also be a weighted list. In other words,=0A= traffic can be load-balanced among the primary nexthops of a=0A= protection list. In such a case, the list will look like:=0A= =0A= ::=3D ( =0A= )...=0A= =0A= 7.2.5. Nexthop chains=0A= =0A= A nexthop chain is a nexthop that puts one or more headers on an=0A= outgoing packet. One example is a Pseudowire - which is MPLS over=0A= some transport (MPLS or GRE for instance). Another example is VxLAN=0A= over IP. A nexthop chain allows an external entity to break up the=0A= programming of the nexthop into independent pieces - one per=0A= encapsulation.=0A= =0A= ::=3D ( ) ( )...=0A= =0A= 7.2.6. lists of lists=0A= =0A= Lists of lists is a complex construct. One example of usage of such=0A= a construct is to replicate traffic to multiple destinations, with=0A= high availability. In other words, for each destination you have a=0A= primary and backup nexthop (replication list) to ensure there is no=0A= traffic drop in case of a failure. So the outer list is a protection=0A= list and the inner lists are replication lists of primary/backup=0A= nexthops.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 23]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 8. RIB operations at scale=0A= =0A= This section discusses the scale requirements for a RIB data-model.=0A= The RIB data-model should be able to handle large scale of=0A= operations, to enable deployment of RIB applications in large=0A= networks.=0A= =0A= 8.1. RIB reads=0A= =0A= Bulking (grouping of multiple objects in a single message) MUST be=0A= supported when a network device sends RIB data to an external entity.=0A= Similarly the data model MUST enable a RIB client to request data in=0A= bulk from a network device.=0A= =0A= 8.2. RIB Writes=0A= =0A= Bulking (grouping of multiple write operations in a single message)=0A= MUST be supported when an external entity wants to write to the RIB.=0A= The response from the network device MUST include a return-code for=0A= each write operation in the bulk message.=0A= =0A= 8.3. RIB events and notifications=0A= =0A= There can be cases where a single network event results in multiple=0A= events and/or notifications from the network device to an external=0A= entity. On the other hand, due to timing of multiple things=0A= happening at the same time, a network device might have to send=0A= multiple events and/or notifications to an external entity. The=0A= network device originated event/notification message MUST support=0A= bulking of multiple events and notifications in a single message.=0A= =0A= 9. Security Considerations=0A= =0A= All interactions between a RIB manager and an external entity MUST be=0A= authenticated and authorized. The RIB manager MUST protect itself=0A= against a denial of service attack by a rogue external entity, by=0A= throttling request processing. A RIB manager MUST enforce limits on=0A= how much data can be programmed by an external entity and return=0A= error when such a limit is reached.=0A= =0A= The RIB manager MUST expose a data-model that it implements. An=0A= external agent MUST send requests to the RIB manager that comply with=0A= the supported data-model. The data-model MUST specify the behavior=0A= of the RIB manager on handling of unsupported data requests.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 24]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= 10. IANA=0A= =0A= This document does not generate any considerations for IANA.=0A= =0A= 11. Acknowledgements=0A= =0A= The authors would like to thank the working group co-chairs and=0A= reviewers on their comments and suggestions on this draft. The=0A= following people contributed to the design of the RIB model as part=0A= of the I2RS Interim meeting in April 2013 - Wes George, Chris=0A= Liljenstolpe, Jeff Tantsura, Sriganesh Kini, Susan Hares, Fabian=0A= Schneider and Nitin Bahadur.=0A= =0A= 12. Informative References=0A= =0A= [I-D.hares-i2rs-use-case-vn-vc]=0A= Hares, S. and M. Chen, "Use Cases for Virtual Connections=0A= on Demand (VCoD) and Virtual Network on Demand (VNoD)=0A= using Interface to Routing System", draft-hares-i2rs-use-=0A= case-vn-vc-02 (work in progress), February 2014.=0A= =0A= [I-D.ietf-i2rs-architecture]=0A= Atlas, A., Halpern, J., Hares, S., Ward, D., and T.=0A= Nadeau, "An Architecture for the Interface to the Routing=0A= System", draft-ietf-i2rs-architecture-02 (work in=0A= progress), February 2014.=0A= =0A= [I-D.ietf-i2rs-problem-statement]=0A= Alia, A., Nadeau, T., and D. Ward, "Interface to the=0A= Routing System Problem Statement", draft-ietf-i2rs-=0A= problem-statement-00 (work in progress), August 2013.=0A= =0A= [I-D.ietf-i2rs-rib-info-model]=0A= Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing=0A= Information Base Info Model", draft-ietf-i2rs-rib-info-=0A= model-02 (work in progress), February 2014.=0A= =0A= [I-D.white-i2rs-use-case]=0A= White, R., Hares, S., and A. Retana, "Protocol Independent=0A= Use Cases for an Interface to the Routing System", draft-=0A= white-i2rs-use-case-02 (work in progress), February 2014.=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.=0A= Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC=0A= 4915, June 2007.=0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 25]=0A= =0C=0A= Internet-Draft I2RS RIB IM April 2014=0A= =0A= =0A= [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi=0A= Topology (MT) Routing in Intermediate System to=0A= Intermediate Systems (IS-ISs)", RFC 5120, February 2008.=0A= =0A= Authors' Addresses=0A= =0A= Nitin Bahadur=0A= Bracket Computing=0A= 320 Soquel Way=0A= Sunnyvale, CA 94085=0A= USA=0A= =0A= Email: nitin_bahadur@yahoo.com=0A= =0A= =0A= Ron Folks=0A= Juniper Networks, Inc.=0A= 1194 N. Mathilda Avenue=0A= Sunnyvale, CA 94089=0A= USA=0A= =0A= Phone: +1 408 745 2000=0A= Email: ronf@juniper.net=0A= URI: www.juniper.net=0A= =0A= =0A= Sriganesh Kini=0A= Ericsson=0A= =0A= Email: sriganesh.kini@ericsson.com=0A= =0A= =0A= Jan Medved=0A= Cisco=0A= =0A= Email: jmedved@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bahadur, et al. Expires October 25, 2014 [Page 26]=0A= ------=_NextPart_000_0068_01CF5EE0.9A12EAD0-- From nobody Wed Apr 30 12:48:58 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455701A0275 for ; Wed, 23 Apr 2014 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.246 X-Spam-Level: **** X-Spam-Status: No, score=4.246 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB7_CR10JvfM for ; Wed, 23 Apr 2014 08:14:24 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C23DB1A0137 for ; Wed, 23 Apr 2014 08:14:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> In-Reply-To: Date: Wed, 23 Apr 2014 11:13:55 -0400 Message-ID: <00a801cf5f06$a52e4830$ef8ad890$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01CF5EE5.1E2533B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHQB8lGI9QG/kFEwAd6lU/sCRNDdTJclCzGQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/byXBLHzi4cI4POZvSeFhSYGE50w X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:49 -0700 Cc: 'Nitin Bahadur' , i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' , 'Dean Bogdanovic' , 'Russ White' , "'Jan Medved \(jmedved\)'" , 'Alia Atlas' , 'Jeffrey Haas' , 'Adrian Farrel' , "'Joel M. Halpern'" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 15:14:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01CF5EE5.1E2533B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: You are right about the graphics. I've started a thread to the RFC Editor and the ISE Editor who are working on the graphics. There is a UML to SVC project that I am looking into to see if we can do this. I just did the tree structures because they actually are a short step away from the UML diagrams. This may allow us to expand the yang trees to be a poor-man's uml while we wait for the graphics. Would you look at the tree to see if I got the yang tree right for config? The RBNF did not take care of the ro status, so I need to create this for the yang modules. This is one reason the RBNF is so poor rather than the UML. If these tree structures are ok, I think I can quickly turn this into a full yang definition. I'll do that once you respond and we can get the full yang module definition up and running. I'd love to work with you on a draft regarding the yang module definition as you are the expert. Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Wednesday, April 23, 2014 11:03 AM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern; Adrian Farrel; Alia Atlas; Nitin Bahadur; Jeffrey Haas Subject: Re: [i2rs] consensus on I2RS protocol and model On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares wrote: Andy: I started using UML to do the information models because Adrian Farrel and Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf models are still mining the existing SNMP/Configuration structures. For new development, I suspect UML may help us root out redundancy. Why? Because I think I've found lots of redundancy in the RIB_INFO model. I've attached slides that may convince you, and an alternate drafts. I do not have any objections to using UML. They are painful to read and write in ASCII art. Maybe that's why we tend to describe the model in introductory text. We also try to avoid duplicating normative text, and try to keep as much normative text in the YANG modules themselves (since they tend to get extracted and the RFC tossed ;-). This is an awesome step forwards. Thanks! I was going to translate the next info-model draft to YANG so we can compare YANG and ForCES using the same data definitions. Looks like you already did that, but I just see the YANG tree diagram in the draft, not the YANG module. It is still enough to see how YANG features would be defined, based on protocols. Clearly, not every I2RS router is going to implement the exact same set of protocols. Not every conceivable piece of data is going to be mandatory to implement. Data organization and modularity are really important aspects to get right the first time. Andy I've assumed in the information model that yang models as defined below +--------+---------------------------+-----------+ | Prefix | YANG module | Reference | +--------+---------------------------+-----------+ | if | ietf-interfaces | [YANG-IF ] | | | | | | ip | ietf-ip | [YANG-IP ] | | | | | | rt | ietf-routing | [routing] | | | | | | v4ur | ietf-ipv4-unicast-routing | [routing] | | | | | | v6ur | ietf-ipv6-unicast-routing | [routing | | | | | | yang | ietf-yang-types | [RFC6991 ] | | | | | | inet | ietf-inet-types | [RFC6991 ] | +--------+---------------------------+-----------+ I've attached a revision of the RIB-info-model draft that provides: 1) Revised RIB Grammar in RBNF (section 6.1) 2) (section 6.2) Spot for the pdf graphic attached as draf-thares-i2rs-info-rib-only-v7.pdf 3) (section 6.3) Yang tree structure (per yang documents) 4) Revised Usage - using simplified grammar Basically the complex RBNF grammar boils down to very few simply statement. The Yang Tree does not provide an easy way to design/debug redundancy. I think that the use of the UML tools that create the Yang modules/Yang Tree structures could speed time to market on the designs. For example, all the I2RS RIB is simply 5 power-point slides, that then can be generated into Yang module. This seems the normal progression of the process you started with the Yang-modules. CAVEATS: 1) For all mistakes on the UML and diagrams blame me - this first pass at UMLs, and it will need revising 2) Some of the redundancies could have been fixed in other ways 3) I did Yang modules to demonstrate proof of concept 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES Data model can do the same Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, April 22, 2014 8:46 PM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern Subject: Re: [i2rs] consensus on I2RS protocol and model <..snip> 1) Why do you think that only the RIB matters in the long run (Short run = RIB + BGP) - [Andy] Why do you think I said that I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. [Sue]: Agree! 2) Your modeling questions are important .. so let me ask a meta-question and then go a level deeper. Why does netmod never really publish an informational model? NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. [Sue]: Other designers on lists stated they suggested they considered IM in their design of YANG. I think the graphical finds redundancies wrote: > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) Russ Andy ------=_NextPart_000_00A9_01CF5EE5.1E2533B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

You are right about the graphics.  I’ve started a thread = to the RFC Editor and the ISE Editor who are working on the graphics. = There is a UML to SVC project that I am looking into to see if we can do = this.

 

I just did the tree structures because they actually are a short step = away from the UML diagrams.  This may allow us to expand the yang = trees to be a poor-man’s uml while we wait for the graphics. =   Would you look at the tree to see if I got the yang tree = right for config?   The RBNF did not take care of the ro = status, so I need to create this for the yang modules.  This is one = reason the RBNF is so poor rather than the UML. =  

 

If these tree structures are ok, I think I can quickly turn this into = a full yang definition.  I’ll do that once you respond and we = can get the full yang module definition up and running. I’d love = to work with you on a draft regarding the yang module definition as you = are the expert.

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Wednesday, = April 23, 2014 11:03 AM
To: Susan Hares
Cc: = i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ = White; Jan Medved (jmedved); Joel M. Halpern; Adrian Farrel; Alia Atlas; = Nitin Bahadur; Jeffrey Haas
Subject: Re: [i2rs] consensus on = I2RS protocol and model

 

 

 

On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

I started using UML to do the information models because Adrian = Farrel and Alia Atlas encouraged it to replace RBNF.   I think = that the yang/netconf models are still mining the existing = SNMP/Configuration structures. For new development, I suspect UML may = help us root out redundancy. Why?  Because I think I’ve found = lots of redundancy in the RIB_INFO model.  I’ve attached = slides that may convince you, and an alternate = drafts.

 

 

 

I = do not have any objections to using UML.

They are painful to read and write in ASCII = art.

Maybe that's why we = tend to describe the model in introductory = text.

We also try to avoid = duplicating normative text, and try to keep as = much

normative text in the = YANG modules themselves (since they tend to = get

extracted and the RFC = tossed ;-).

 

This is an awesome step forwards. =  Thanks!

I was going = to translate the next info-model draft to YANG so = we

can compare YANG and = ForCES using the same data definitions.

Looks like you already did that, but I just see the = YANG tree diagram in the draft,

not the YANG module.

 

It is still enough to see how YANG features would be = defined, based on protocols.

Clearly, not every I2RS router is going to implement = the exact same set of protocols.

Not every conceivable piece of data is going to be = mandatory to implement.

Data organization and modularity are really important = aspects to get right the first time.

 

 

Andy

 

 

I’ve assumed in the information model that yang models as = defined below

  +--------+---------------------------+-----------+

  | Prefix | = YANG = module           &= nbsp;   | Reference |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>  | = if     | = ietf-interfaces         &nbs= p; | [YANG-IF] |

  = |        = |            =             &= nbsp;  = |           = |

  | = ip     | = ietf-ip           =         | [YANG-IP] |

  = |        = |            =             &= nbsp;  = |           = |

  | = rt     | = ietf-routing          &= nbsp;   | [routing] = |

 |        = |            =             &= nbsp;  = |           = |

 | = v4ur   | ietf-ipv4-unicast-routing | [routing] |

  = |        = |            =             &= nbsp;  = |           = |

  | = v6ur   | ietf-ipv6-unicast-routing | [routing =  |

  = |        = |            =             &= nbsp;  = |           = |

  | = yang   | = ietf-yang-types         &nbs= p; | [RFC6991] = |

  = |        = |            =             &= nbsp;  = |           = |

  | = inet   | = ietf-inet-types         &nbs= p; | [RFC6991] = |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> 

I’ve attached a revision of the RIB-info-model draft that = provides:

1)      = Revised RIB Grammar in RBNF (section 6.1) =

2)      = (section 6.2) Spot for the pdf graphic attached as = draf-thares-i2rs-info-rib-only-v7.pdf

3)      = (section 6.3) Yang tree structure (per yang = documents)

4)      = Revised Usage – using simplified = grammar

 

Basically the complex RBNF grammar boils down to very few simply = statement.  The Yang Tree does not provide an easy way to = design/debug redundancy. I think that the use of the UML tools that = create the Yang modules/Yang Tree structures could speed time to market = on the designs.  For example, all the I2RS RIB is simply 5 = power-point slides, that then can be generated into Yang module.  = This seems the normal progression of the process you started with the = Yang-modules.

 

CAVEATS:

1)      = For all mistakes on the UML and diagrams blame me – this first = pass at UMLs, and it will need revising

2)      = Some of the redundancies could have been fixed in other ways =

3)      = I did Yang modules to demonstrate proof of = concept

4)      = I suspect with Jamal and Joel Halpern’s help (FoRCES gurus).. = FoRCES Data model can do the same

 

Sue Hares  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, April 22, 2014 8:46 PM
To: = Susan Hares
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

<..snip>  

1)      = Why do you think that only the RIB matters in the long run (Short run = =3D RIB + BGP) -

[Andy] Why do you think I said that I don't see anything special about I2RS = at all. Editing operational state = would probably work the same for other data.

[Sue]: Agree!

 

2)      = Your modeling questions are important .. so let me ask a = meta-question and then go a level deeper…

 Why does netmod never really publish an informational model? =

 NETMOD publishes YANG modules. I suppose it is perceived an = unnecessary.

[Sue]: Other designers on lists stated they suggested they considered = IM in their design of YANG.  I think the graphical finds = redundancies

<snip)  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: = Russ White
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi,

 <= /p>

On Sat, Apr = 19, 2014 at 8:22 AM, Russ White <russw@riw.us> wrote:


> = And the basic premise of I2RS is that there are requirements for the = work
> that were not addressed properly by the existing = configuration protocols.
> Otherwise the WG would not even need to = discuss protocol modifications.
> So the fact that NetConf / YANG = works for device configuration does not
> seem to be evidence that = it works for what I2RS wants to do.

Precisely. Otherwise, we = could have just looked at the problem, and said,
"let's use = YANG." But I think we're starting to confuse the problem = set
because we started by trying to boil the ocean. Once you actually = get to
town, it's hard to keep in focus that you're just there for a = new pitchfork
handle -- that game of checkers over there on the porch = of the hotel looks
so interesting, and the hardware store has so much = other stuff than just
pitchfork handles, after all.

So, given = we are _supposed_ to be focused on the RIB interface, and = not
protocol, configuration, device, etc., etc., what specific points = have the
use cases brought out that either NETCONF/YANG or FORCES not = fulfill? One of
the primary points was timing -- are these other = systems fast enough?

>From my perspective, these two systems = don't fulfill the I2RS mandate on the
RIB side for various = reasons:

- I'm not convinced on the speed side. YANG feels a bit = heavy weigh for what
we want here. The flexibility is there, but so = is the cost of that
flexibility.

 <= /o:p>

 <= /o:p>

Can you = explain how an off-line representation of the data model can be fast or = slow?

You mean = the YANG compiler takes too long to process a YANG = file?

You mean = the unspecified I2RS protocol will be too slow on the wire = if

it uses XML = or JSON encoding of YANG data structures?

 <= /o:p>

 <= /o:p>


- I'm not = convinced YANG has handled the atomicity issues in a way that
makes = sense for the application environment we have in mind. RESTCONF = seems
to go that direction, but I'm not certain it's a complete = solution (?).

 <= /o:p>

YANG is a = data modeling language.

RESTCONF is = a protocol.

Atomicity = is a property of the protocol.

Which YANG = statements prevent this from being accomplished in the TBD I2RS = protocol?

 <= /o:p>

 <= /o:p>

So, IMHO, I think = we need to either consider FORCES, or "something new." = But
we're going to have a hard time determining if this is true if we = can't make
a solid requirements list. For me, these are:

- = Atomic operations at the RIB level
- Speed that's comparable to a = local routing process installing routes in
the RIB
- An immediate = feedback system within the RESTful mold that tells the
installing = process what happened, and why, with the route it just tried = to
install in the RIB

So, it seems to me that we need to = return to the use cases -- there are two
in the charter. If we want = to discuss adding others, that's fine, but we
need to gain some = focus, and stop trying to boil the ocean, if we want to
make any = progress.

 <= /o:p>

It seems to = me this WG needs to start asking the right questions about = the

data = modeling language requirements.  E.g.:

 <= /o:p>

  - = What are the data types needed?  Is this a static set of will it = ever change?

  - = What are the high level data modeling constructs = needed?

  - = Are user defined types needed?

  - = Are re-usable data definitions needed?

  - = Does the data model need to be modular?  How does it grow over = time?

  - = Can vendors add data definitions that extend the standard = definitions?

  - = How are new definitions added in a way that does not break existing = clients?

  - = How is mandatory to implement vs. optional to implement functionality = handled?

  - = How is mandatory to use vs. optional to use functionality = handled?

 <= /o:p>

You are = asking about protocol requirements, not data = modeling.

IMO it = would be near-sighted and extremely impractical to = choose

a language = that only supported description on RIB info.  I fail to see = what

is so = special about RIB info that would warrant its own = DML.

 <= /o:p>

 <= /o:p>

:-)

R= uss

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_00A9_01CF5EE5.1E2533B0-- From nobody Wed Apr 30 12:48:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8E1A03D4 for ; Wed, 23 Apr 2014 10:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11vqGMIrV-tc for ; Wed, 23 Apr 2014 10:08:13 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5A1A03D1 for ; Wed, 23 Apr 2014 10:08:12 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so5266933wib.8 for ; Wed, 23 Apr 2014 10:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LtwAH5xutVH8816ghJetmTslhEgbzADv2hS0kA0tyKs=; b=IaAku53ugc5Txvzrqku7XzZ4g3TRrH0XqibxIX2Sb+w3cEIxON8wo+jZWiSEptB/P/ Ya54eWFY/mbcubOEJAZGmYr+Tzq3vwQ5syCn5rNQ6ot8XMYr+JBef8fE+iEER3sD6XnD ntLvj1WD39oCDwA9xIT4Okj/QgMemvjGw/d9IDDY9zEYZGofy6dd733OZTpS32gG2I9G aJaNVzcCDUATOu1FGaK47SqYPZyw3jL6XRcqg14s9mhuQxDieEd6qeCrR42BAaP0hrcV c+bKIsareIahhHFA2q76ipBxZN8W10qs0QQrFY6uJfGvgcjROjh3KqbIV90qCZByi0ru gCZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LtwAH5xutVH8816ghJetmTslhEgbzADv2hS0kA0tyKs=; b=FDPwff0BF10s8RO1dhP8WA8U4uU3XEYvs5dCzLBAL7d5CTchblLVqPfDhoHEkvHlAT JLL3HoDotf4YlHIBbwywmBFmQWf9teE7fsmMf8gIZsE34XumEDYkNmmp8SZ+NM6jf50T KGp7WeJcbCsxmUDrLjNl13sk+HPUg1Ujhqo8UX/hvH3Rd+eMc0YY040REyJTiEo2LOIk f+jTRZGNLv+1XRlc7yHlaUp3e+B2iRXCyguRYJgIsjBE/Eme51jhOjFJ0nXCGLMd15CP lIsCuRVtBGxhQVfkftYdH1wJzpe7jlbByDY4zZLG3xUXkhkpfvTzF5JrJ5fxwgjBYQCy /b+g== X-Gm-Message-State: ALoCoQktzORKVtr16vgG1Fi06OborH63YeJWc9HW/uzKPfKC10D9QNNloCyHyTN5y8N2xotJE40vygHsLpIRrl/RQtZmnJIxux1YIPxtbXSfDtRw4XWfXEX9VjkEJlAw+f1eZXk6xjrkHPnypV055yBAeBwbUIZ9i/3vTka76ygUx4+hp6LzmzDpKXn2MfMhHxnrC3d0CzGG MIME-Version: 1.0 X-Received: by 10.180.7.198 with SMTP id l6mr2724437wia.52.1398272886256; Wed, 23 Apr 2014 10:08:06 -0700 (PDT) Received: by 10.194.26.66 with HTTP; Wed, 23 Apr 2014 10:08:06 -0700 (PDT) Received: by 10.194.26.66 with HTTP; Wed, 23 Apr 2014 10:08:06 -0700 (PDT) In-Reply-To: <006701cf5f02$211325b0$63397110$@ndzh.com> References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> Date: Wed, 23 Apr 2014 10:08:06 -0700 Message-ID: From: Edward Crabbe To: Susan Hares Content-Type: multipart/alternative; boundary=f46d044287c0af64fb04f7b8c6ef Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/L-3BxI25g0HxLuOH9cNHTRTiczI X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:48 -0700 Cc: Nitin Bahadur , i2rs@ietf.org, Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Russ White , "Jan Medved \(jmedved\)" , Alia Atlas , Jeffrey Haas , adrian@olddog.co.uk, "Joel M. Halpern" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 23 Apr 2014 17:08:17 -0000 --f46d044287c0af64fb04f7b8c6ef Content-Type: text/plain; charset=ISO-8859-1 Hi Sue; Could we please move the UML discussion to a separate thread ? Definitely a useful topic , and I'm very glad the conversation is happening, but I'd like to keep this (very long) thread fairly focused. Cheers, -ed On Apr 23, 2014 7:42 AM, "Susan Hares" wrote: > Andy: > > > > I started using UML to do the information models because Adrian Farrel and > Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf > models are still mining the existing SNMP/Configuration structures. For new > development, I suspect UML may help us root out redundancy. Why? Because I > think I've found lots of redundancy in the RIB_INFO model. I've attached > slides that may convince you, and an alternate drafts. > > > > I've assumed in the information model that yang models as defined below > > +--------+---------------------------+-----------+ > > | Prefix | YANG module | Reference | > > +--------+---------------------------+-----------+ > > | if | ietf-interfaces | [YANG-IF] > | > > | | | | > > | ip | ietf-ip | [YANG-IP] > | > > | | | | > > | rt | ietf-routing *| [routing] |* > > | | | | > > | v4ur | ietf-ipv4-unicast-routing *| [routing] |* > > | | | | > > | v6ur | ietf-ipv6-unicast-routing |* [routing * | > > | | | | > > | yang | ietf-yang-types | [RFC6991] > | > > | | | | > > | inet | ietf-inet-types | [RFC6991] > | > > +--------+---------------------------+-----------+ > > > > I've attached a revision of the RIB-info-model draft that provides: > > 1) Revised RIB Grammar in RBNF (section 6.1) > > 2) (section 6.2) Spot for the pdf graphic attached as > draf-thares-i2rs-info-rib-only-v7.pdf > > 3) (section 6.3) Yang tree structure (per yang documents) > > 4) Revised Usage - using simplified grammar > > > > Basically the complex RBNF grammar boils down to very few simply > statement. The Yang Tree does not provide an easy way to design/debug > redundancy. I think that the use of the UML tools that create the Yang > modules/Yang Tree structures could speed time to market on the designs. > For example, all the I2RS RIB is simply 5 power-point slides, that then > can be generated into Yang module. This seems the normal progression of > the process you started with the Yang-modules. > > > > CAVEATS: > > 1) For all mistakes on the UML and diagrams blame me - this first > pass at UMLs, and it will need revising > > 2) Some of the redundancies could have been fixed in other ways > > 3) I did Yang modules to demonstrate proof of concept > > 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. > FoRCES Data model can do the same > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, April 22, 2014 8:46 PM > *To:* Susan Hares > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Russ White; Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > <..snip> > > 1) Why do you think that only the RIB matters in the long run (Short > run = RIB + BGP) - > > [Andy] Why do you think I said that I don't see anything special about > I2RS at all. Editing operational state would probably work the same for > other data. > > [Sue]: Agree! > > > > 2) Your modeling questions are important .. so let me ask a > meta-question and then go a level deeper... > > Why does netmod never really publish an informational model? > > NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. > > [Sue]: Other designers on lists stated they suggested they considered IM > in their design of YANG. I think the graphical finds redundancies > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Saturday, April 19, 2014 1:46 PM > *To:* Russ White > *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Jan Medved (jmedved); Joel M. Halpern > *Subject:* Re: [i2rs] consensus on I2RS protocol and model > > > > Hi, > > > > On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > > > > And the basic premise of I2RS is that there are requirements for the work > > that were not addressed properly by the existing configuration protocols. > > Otherwise the WG would not even need to discuss protocol modifications. > > So the fact that NetConf / YANG works for device configuration does not > > seem to be evidence that it works for what I2RS wants to do. > > Precisely. Otherwise, we could have just looked at the problem, and said, > "let's use YANG." But I think we're starting to confuse the problem set > because we started by trying to boil the ocean. Once you actually get to > town, it's hard to keep in focus that you're just there for a new pitchfork > handle -- that game of checkers over there on the porch of the hotel looks > so interesting, and the hardware store has so much other stuff than just > pitchfork handles, after all. > > So, given we are _supposed_ to be focused on the RIB interface, and not > protocol, configuration, device, etc., etc., what specific points have the > use cases brought out that either NETCONF/YANG or FORCES not fulfill? One > of > the primary points was timing -- are these other systems fast enough? > > >From my perspective, these two systems don't fulfill the I2RS mandate on > the > RIB side for various reasons: > > - I'm not convinced on the speed side. YANG feels a bit heavy weigh for > what > we want here. The flexibility is there, but so is the cost of that > flexibility. > > > > > > Can you explain how an off-line representation of the data model can be > fast or slow? > > You mean the YANG compiler takes too long to process a YANG file? > > You mean the unspecified I2RS protocol will be too slow on the wire if > > it uses XML or JSON encoding of YANG data structures? > > > > > > > - I'm not convinced YANG has handled the atomicity issues in a way that > makes sense for the application environment we have in mind. RESTCONF seems > to go that direction, but I'm not certain it's a complete solution (?). > > > > YANG is a data modeling language. > > RESTCONF is a protocol. > > Atomicity is a property of the protocol. > > Which YANG statements prevent this from being accomplished in the TBD I2RS > protocol? > > > > > > So, IMHO, I think we need to either consider FORCES, or "something new." > But > we're going to have a hard time determining if this is true if we can't > make > a solid requirements list. For me, these are: > > - Atomic operations at the RIB level > - Speed that's comparable to a local routing process installing routes in > the RIB > - An immediate feedback system within the RESTful mold that tells the > installing process what happened, and why, with the route it just tried to > install in the RIB > > So, it seems to me that we need to return to the use cases -- there are two > in the charter. If we want to discuss adding others, that's fine, but we > need to gain some focus, and stop trying to boil the ocean, if we want to > make any progress. > > > > It seems to me this WG needs to start asking the right questions about the > > data modeling language requirements. E.g.: > > > > - What are the data types needed? Is this a static set of will it ever > change? > > - What are the high level data modeling constructs needed? > > - Are user defined types needed? > > - Are re-usable data definitions needed? > > - Does the data model need to be modular? How does it grow over time? > > - Can vendors add data definitions that extend the standard definitions? > > - How are new definitions added in a way that does not break existing > clients? > > - How is mandatory to implement vs. optional to implement functionality > handled? > > - How is mandatory to use vs. optional to use functionality handled? > > > > You are asking about protocol requirements, not data modeling. > > IMO it would be near-sighted and extremely impractical to choose > > a language that only supported description on RIB info. I fail to see what > > is so special about RIB info that would warrant its own DML. > > > > > > :-) > > Russ > > > > Andy > > > > > --f46d044287c0af64fb04f7b8c6ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Sue;

Could we please move the UML discussion to a separate thread= ?  Definitely a useful topic , and I'm very glad the conversation= is happening, but I'd like to keep this (very long) thread fairly focu= sed.

Cheers,
  -ed

On Apr 23, 2014 7:42 AM, "Susan Hares"= <shares@ndzh.com> wrote:

Andy:

 

I started using UML to do the information = models because Adrian Farrel and Alia Atlas encouraged it to replace RBNF. =   I think that the yang/netconf models are still mining the exist= ing SNMP/Configuration structures. For new development, I suspect UML may h= elp us root out redundancy. Why?  Because I think I’ve found lot= s of redundancy in the RIB_INFO model.  I’ve attached slides tha= t may convince you, and an alternate drafts.

 

I’ve assumed = in the information model that yang models as defined below

  +--------+---------------------------+--------= ---+

  | Prefix | YANG module=             &nb= sp;  | Reference |

  +--------+---------------------------+-----------+<= u>

  | if    = ; | ietf-interfaces         &n= bsp; | [YANG-IF] |

  |        | =             &nb= sp;            = |           |<= /u>

  | ip     | ietf-i= p            &n= bsp;      | [YANG-IP] |

  |        | =             &nb= sp;            = |           |<= /u>

  | rt     | ietf-r= outing           &nb= sp;  | [routing] |

 |        | =             &nb= sp;            = |           |<= /u>

 | v4ur   | ietf-ipv4-unicas= t-routing | [routing] |

  |        | =             &nb= sp;            = |           |<= /u>

  | v6ur   | ietf-ipv6-unicas= t-routing | [routing  |

  |        | =             &nb= sp;            = |           |<= /u>

  | yang   | ietf-yang-types&= nbsp;          | [RFC6991] |

  |        | =             &nb= sp;            = |           |<= /u>

  | inet   | ietf-inet-types&= nbsp;          | [RFC6991] |

  +--------+---------------------------+-----------+<= u>

<= u> 

I’ve attached a rev= ision of the RIB-info-model draft that provides:

1)      = Revised RIB Grammar in RBNF (section 6.1)=

2)      (section 6.2) Spot for the pdf graphic = attached as draf-thares-i2rs-info-rib-only-v7.pdf

3)      (section 6.3) Yang tree structure (per = yang documents)

4)      Revised Usage – using simplified = grammar

 

Basically the compl= ex RBNF grammar boils down to very few simply statement.  The Yang Tre= e does not provide an easy way to design/debug redundancy. I think that the= use of the UML tools that create the Yang modules/Yang Tree structures cou= ld speed time to market on the designs.  For example, all the I2RS RIB= is simply 5 power-point slides, that then can be generated into Yang modul= e.  This seems the normal progression of the process you started with = the Yang-modules.

 

CAVEATS: =

1)      For all mistakes on the UML and diagram= s blame me – this first pass at UMLs, and it will need revising

2)      Some of the redundancies could have bee= n fixed in other ways

3)      I did Yang modules to demonstrate proof= of concept

4)      I suspect with Jamal and Joel Halpern&r= squo;s help (FoRCES gurus).. FoRCES Data model can do the same

 

Sue Hares  =

 

From: i2= rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, April 22, 2014 8:46 PM
To: Susan Hares
<= b>Cc: i2rs@ietf.org<= /a>; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medv= ed (jmedved); Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

 = ;

2)      Your modeling questions are important .. so let me ask a meta-question and= then go a level deeper…

 Why does netmod nev= er really publish an informational model?

 NETMOD = publishes YANG modules. I suppose it i= s perceived an unnecessary.

[Sue]: Other designers on= lists stated they suggested they considered IM in their design of YANG. &n= bsp;I think the graphical finds redundancies

<snip)  

 

From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Andy Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: Russ White
<= b>Cc: i2rs@ietf.org<= /a>; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan Medved (jmedved)= ; Joel M. Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

Hi,

 

On Sat, Apr 19, 2014 at= 8:22 AM, Russ White <= russw@riw.us> wrote:


>= ; And the basic premise of I2RS is that there are requirements for the work=
> that were not addressed properly by the existing configuration protoco= ls.
> Otherwise the WG would not even need to discuss protocol modifi= cations.
> So the fact that NetConf / YANG works for device configura= tion does not
> seem to be evidence that it works for what I2RS wants to do.

Pr= ecisely. Otherwise, we could have just looked at the problem, and said,
= "let's use YANG." But I think we're starting to confuse t= he problem set
because we started by trying to boil the ocean. Once you actually get totown, it's hard to keep in focus that you're just there for a new = pitchfork
handle -- that game of checkers over there on the porch of the= hotel looks
so interesting, and the hardware store has so much other stuff than justpitchfork handles, after all.

So, given we are _supposed_ to be foc= used on the RIB interface, and not
protocol, configuration, device, etc.= , etc., what specific points have the
use cases brought out that either NETCONF/YANG or FORCES not fulfill? One o= f
the primary points was timing -- are these other systems fast enough?<= br>
>From my perspective, these two systems don't fulfill the I2R= S mandate on the
RIB side for various reasons:

- I'm not convinced on the speed s= ide. YANG feels a bit heavy weigh for what
we want here. The flexibility= is there, but so is the cost of that
flexibility.

 

 

Can yo= u explain how an off-line representation of the data model can be fast or s= low?

You mean the YANG compiler takes too long= to process a YANG file?

You mean the unspecified I2RS protocol will be too slow on the wire if<= /u>

it uses XML or JSON encoding of YANG data= structures?

 

 


- I'm not con= vinced YANG has handled the atomicity issues in a way that
makes sense f= or the application environment we have in mind. RESTCONF seems
to go tha= t direction, but I'm not certain it's a complete solution (?).

 

YANG is a data modeling language.

=

RESTCONF is a protocol.

=

Atomicity is a property of the protocol.

Which YANG statements prevent this = from being accomplished in the TBD I2RS protocol?

 

 

So, IMHO, I think we = need to either consider FORCES, or "something new." But
we'= ;re going to have a hard time determining if this is true if we can't m= ake
a solid requirements list. For me, these are:

- Atomic operations at= the RIB level
- Speed that's comparable to a local routing process = installing routes in
the RIB
- An immediate feedback system within th= e RESTful mold that tells the
installing process what happened, and why, with the route it just tried to<= br>install in the RIB

So, it seems to me that we need to return to t= he use cases -- there are two
in the charter. If we want to discuss addi= ng others, that's fine, but we
need to gain some focus, and stop trying to boil the ocean, if we want tomake any progress.

 

It seems to m= e this WG needs to start asking the right questions about the=

data modeling language requirements. &nbs= p;E.g.:

 =

  - What are the data types = needed?  Is this a static set of will it ever change?

  - What are the high level data mod= eling constructs needed?

  - Are user defined types needed?

  - Are re-usable data definitions needed?

  - Does the data model need to be modular? &n= bsp;How does it grow over time?

  - Can vendors add data definitions that extend the standard = definitions?

  - How are new definitions added in= a way that does not break existing clients?

  - How is mandatory to implement vs. optional to= implement functionality handled?

  - How is mandatory to use vs. opti= onal to use functionality handled?

 

You ar= e asking about protocol requirements, not data modeling.

IMO it would be near-sighted and extremel= y impractical to choose

= a language that only supported description on RIB info.  I fail to see= what

is so special about RIB info that would w= arrant its own DML.

&nbs= p;

 <= /p>

:-)

Russ

<= p class=3D"MsoNormal"> 

Andy

 <= u>

=  

--f46d044287c0af64fb04f7b8c6ef-- From nobody Wed Apr 30 12:49:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C51D1A0158 for ; Thu, 24 Apr 2014 03:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMgX7zdm_DE0 for ; Thu, 24 Apr 2014 03:17:38 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA191A014B for ; Thu, 24 Apr 2014 03:17:38 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so2596991veb.41 for ; Thu, 24 Apr 2014 03:17:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+vzkEbgilZJC5dXvswe/uJbBKxFJbyyvZCk63w90OrE=; b=LZbFvyOokq8f4+2VtDygQTfWXYdR0clLd3BPYdtHk346ZPh0/N5Fdmwn+jsVpUjo+g WDTfh7L/Pczpk+zb+0TL/+u3E1tUwEhLa0U4i5R+bqLFKEc1/F9jRSmj4AfjhGhFbG0C CL9TJgRbbzNngghDCs+1LR6Tx8ZVarGu5UEnR8ItSD8PcQauUiLFXklCzKkH68v3Lxlm w8/n4RQhzEpLrQuP3saPDjIf0mHeBQWmamPyQdPwX2xRtTa7ffA7YytN1MFGqkgXEv0r +UR/T4Fbk18XJ7CxAGAK+7P9oxVBesn8QtAGwvX/yNBg953VDWZX7fgA2Q9CL20HLcuB OfIg== X-Gm-Message-State: ALoCoQkev1d5QxWpwUF3A2vQHBV1+CYzNo8dmRZGejg6fR2XMkN8th6CMOSPlzQJDxuRBn+5Lygb X-Received: by 10.58.74.201 with SMTP id w9mr27255vev.56.1398334652332; Thu, 24 Apr 2014 03:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Thu, 24 Apr 2014 03:17:11 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> From: Jamal Hadi Salim Date: Thu, 24 Apr 2014 06:17:11 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MKMX1XbibXavTfkYSDjgYbbtwac X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:50 -0700 Cc: Nitin Bahadur , "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , Alia Atlas , Jeffrey Haas , Adrian Farrel , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 10:17:40 -0000 Sorry, was there something i missed here that Andy is awesom-ing? What graphics? Sounds to me like an information model in plain english (the openstack people do this) would have been a reasonable start as well, no? cheers, jamal On Wed, Apr 23, 2014 at 11:03 AM, Andy Bierman wrote: > > > > On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares wrote: >> >> Andy: >> >> >> >> I started using UML to do the information models because Adrian Farrel and >> Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf >> models are still mining the existing SNMP/Configuration structures. For new >> development, I suspect UML may help us root out redundancy. Why? Because I >> think I've found lots of redundancy in the RIB_INFO model. I've attached >> slides that may convince you, and an alternate drafts. >> >> > > > > I do not have any objections to using UML. > They are painful to read and write in ASCII art. > Maybe that's why we tend to describe the model in introductory text. > We also try to avoid duplicating normative text, and try to keep as much > normative text in the YANG modules themselves (since they tend to get > extracted and the RFC tossed ;-). > > This is an awesome step forwards. Thanks! > I was going to translate the next info-model draft to YANG so we > can compare YANG and ForCES using the same data definitions. > Looks like you already did that, but I just see the YANG tree diagram in the > draft, > not the YANG module. > > It is still enough to see how YANG features would be defined, based on > protocols. > Clearly, not every I2RS router is going to implement the exact same set of > protocols. > Not every conceivable piece of data is going to be mandatory to implement. > Data organization and modularity are really important aspects to get right > the first time. > > > Andy > > >> >> I've assumed in the information model that yang models as defined below >> >> +--------+---------------------------+-----------+ >> >> | Prefix | YANG module | Reference | >> >> +--------+---------------------------+-----------+ >> >> | if | ietf-interfaces | [YANG-IF] | >> >> | | | | >> >> | ip | ietf-ip | [YANG-IP] | >> >> | | | | >> >> | rt | ietf-routing | [routing] | >> >> | | | | >> >> | v4ur | ietf-ipv4-unicast-routing | [routing] | >> >> | | | | >> >> | v6ur | ietf-ipv6-unicast-routing | [routing | >> >> | | | | >> >> | yang | ietf-yang-types | [RFC6991] | >> >> | | | | >> >> | inet | ietf-inet-types | [RFC6991] | >> >> +--------+---------------------------+-----------+ >> >> >> >> I've attached a revision of the RIB-info-model draft that provides: >> >> 1) Revised RIB Grammar in RBNF (section 6.1) >> >> 2) (section 6.2) Spot for the pdf graphic attached as >> draf-thares-i2rs-info-rib-only-v7.pdf >> >> 3) (section 6.3) Yang tree structure (per yang documents) >> >> 4) Revised Usage - using simplified grammar >> >> >> >> Basically the complex RBNF grammar boils down to very few simply >> statement. The Yang Tree does not provide an easy way to design/debug >> redundancy. I think that the use of the UML tools that create the Yang >> modules/Yang Tree structures could speed time to market on the designs. For >> example, all the I2RS RIB is simply 5 power-point slides, that then can be >> generated into Yang module. This seems the normal progression of the >> process you started with the Yang-modules. >> >> >> >> CAVEATS: >> >> 1) For all mistakes on the UML and diagrams blame me - this first >> pass at UMLs, and it will need revising >> >> 2) Some of the redundancies could have been fixed in other ways >> >> 3) I did Yang modules to demonstrate proof of concept >> >> 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. >> FoRCES Data model can do the same >> >> >> >> Sue Hares >> >> >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Tuesday, April 22, 2014 8:46 PM >> To: Susan Hares >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ >> White; Jan Medved (jmedved); Joel M. Halpern >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> <..snip> >> >> 1) Why do you think that only the RIB matters in the long run (Short >> run = RIB + BGP) - >> >> [Andy] Why do you think I said that I don't see anything special about >> I2RS at all. Editing operational state would probably work the same for >> other data. >> >> [Sue]: Agree! >> >> >> >> 2) Your modeling questions are important .. so let me ask a >> meta-question and then go a level deeper... >> >> Why does netmod never really publish an informational model? >> >> NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. >> >> [Sue]: Other designers on lists stated they suggested they considered IM >> in their design of YANG. I think the graphical finds redundancies >> >> > >> >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Saturday, April 19, 2014 1:46 PM >> To: Russ White >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Jan >> Medved (jmedved); Joel M. Halpern >> Subject: Re: [i2rs] consensus on I2RS protocol and model >> >> >> >> Hi, >> >> >> >> On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: >> >> >> > And the basic premise of I2RS is that there are requirements for the >> > work >> > that were not addressed properly by the existing configuration >> > protocols. >> > Otherwise the WG would not even need to discuss protocol modifications. >> > So the fact that NetConf / YANG works for device configuration does not >> > seem to be evidence that it works for what I2RS wants to do. >> >> Precisely. Otherwise, we could have just looked at the problem, and said, >> "let's use YANG." But I think we're starting to confuse the problem set >> because we started by trying to boil the ocean. Once you actually get to >> town, it's hard to keep in focus that you're just there for a new >> pitchfork >> handle -- that game of checkers over there on the porch of the hotel looks >> so interesting, and the hardware store has so much other stuff than just >> pitchfork handles, after all. >> >> So, given we are _supposed_ to be focused on the RIB interface, and not >> protocol, configuration, device, etc., etc., what specific points have the >> use cases brought out that either NETCONF/YANG or FORCES not fulfill? One >> of >> the primary points was timing -- are these other systems fast enough? >> >> >From my perspective, these two systems don't fulfill the I2RS mandate on >> the >> RIB side for various reasons: >> >> - I'm not convinced on the speed side. YANG feels a bit heavy weigh for >> what >> we want here. The flexibility is there, but so is the cost of that >> flexibility. >> >> >> >> >> >> Can you explain how an off-line representation of the data model can be >> fast or slow? >> >> You mean the YANG compiler takes too long to process a YANG file? >> >> You mean the unspecified I2RS protocol will be too slow on the wire if >> >> it uses XML or JSON encoding of YANG data structures? >> >> >> >> >> >> >> - I'm not convinced YANG has handled the atomicity issues in a way that >> makes sense for the application environment we have in mind. RESTCONF >> seems >> to go that direction, but I'm not certain it's a complete solution (?). >> >> >> >> YANG is a data modeling language. >> >> RESTCONF is a protocol. >> >> Atomicity is a property of the protocol. >> >> Which YANG statements prevent this from being accomplished in the TBD I2RS >> protocol? >> >> >> >> >> >> So, IMHO, I think we need to either consider FORCES, or "something new." >> But >> we're going to have a hard time determining if this is true if we can't >> make >> a solid requirements list. For me, these are: >> >> - Atomic operations at the RIB level >> - Speed that's comparable to a local routing process installing routes in >> the RIB >> - An immediate feedback system within the RESTful mold that tells the >> installing process what happened, and why, with the route it just tried to >> install in the RIB >> >> So, it seems to me that we need to return to the use cases -- there are >> two >> in the charter. If we want to discuss adding others, that's fine, but we >> need to gain some focus, and stop trying to boil the ocean, if we want to >> make any progress. >> >> >> >> It seems to me this WG needs to start asking the right questions about the >> >> data modeling language requirements. E.g.: >> >> >> >> - What are the data types needed? Is this a static set of will it ever >> change? >> >> - What are the high level data modeling constructs needed? >> >> - Are user defined types needed? >> >> - Are re-usable data definitions needed? >> >> - Does the data model need to be modular? How does it grow over time? >> >> - Can vendors add data definitions that extend the standard definitions? >> >> - How are new definitions added in a way that does not break existing >> clients? >> >> - How is mandatory to implement vs. optional to implement functionality >> handled? >> >> - How is mandatory to use vs. optional to use functionality handled? >> >> >> >> You are asking about protocol requirements, not data modeling. >> >> IMO it would be near-sighted and extremely impractical to choose >> >> a language that only supported description on RIB info. I fail to see >> what >> >> is so special about RIB info that would warrant its own DML. >> >> >> >> >> >> :-) >> >> Russ >> >> >> >> Andy >> >> >> >> > > From nobody Wed Apr 30 12:49:01 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C101A01DA for ; Thu, 24 Apr 2014 06:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5NxtgP2uB74 for ; Thu, 24 Apr 2014 06:36:30 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id D95F91A01B3 for ; Thu, 24 Apr 2014 06:36:29 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id dc16so2204942qab.21 for ; Thu, 24 Apr 2014 06:36:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dk/GRHQSZl/Hm1FvIHsNGDDexvvKkcCUslW3BvDkEF8=; b=iUBxkgcBAW55L0INvZUlVrhD6YbwircRLgZHPCf8Tz/izhLNRugrfmTXS3CcytLoIp vkNFnCMqoXDCuoVEYsAdbWpCMbf+eGlGBNFm5jeUu11bl+8xRuKY08ihVhyKqcOPVvCy eT6qD/zVx5ciWheDfRquLz6bnvlO1WsehLb1CqI9u9gRowjD/sj951Z9LVCGqqYxEM5S l/RiA25CKUwu2GUgDy6DGNjcp8lAMkoLipJnvxTbwYPwr+BRFvoJwbkcn9ibFCbtSYxw irIlXWulKg4YPjSmhDbjVU6Yw4DWdSUOfiCJq07+wdtONc3gjBfawqAmj9me4mGbENH5 Ss2Q== X-Gm-Message-State: ALoCoQmVhTr+VMEgHC3sgPG1R2xoCRikIMTpPTIvHOWDhjMyXkRK5D1qfSUkkxfxiMVSg+N9Av2M MIME-Version: 1.0 X-Received: by 10.229.230.68 with SMTP id jl4mr2778171qcb.2.1398346583509; Thu, 24 Apr 2014 06:36:23 -0700 (PDT) Received: by 10.140.41.134 with HTTP; Thu, 24 Apr 2014 06:36:23 -0700 (PDT) In-Reply-To: References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> Date: Thu, 24 Apr 2014 06:36:23 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a11347e9c62b9cc04f7c9ef04 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/46nN3d32kDc6PX7fCtJ8Gche1Yk X-Mailman-Approved-At: Wed, 30 Apr 2014 12:48:49 -0700 Cc: Nitin Bahadur , "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Russ White , "Jan Medved \(jmedved\)" , Alia Atlas , Jeffrey Haas , Adrian Farrel , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 24 Apr 2014 13:36:33 -0000 --001a11347e9c62b9cc04f7c9ef04 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 24, 2014 at 3:17 AM, Jamal Hadi Salim wrote: > Sorry, was there something i missed here that Andy is awesom-ing? > What graphics? > > No -- just progress on the info model. Once we have an info model, it can be mapped into both YANG and ForCES so they can be compared side-by-side, using the actual model that this WG wants to standardize. Andy > Sounds to me like an information model in plain english (the openstack > people do > this) would have been a reasonable start as well, no? > > cheers, > jamal > > On Wed, Apr 23, 2014 at 11:03 AM, Andy Bierman wrote: > > > > > > > > On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares wrote: > >> > >> Andy: > >> > >> > >> > >> I started using UML to do the information models because Adrian Farrel > and > >> Alia Atlas encouraged it to replace RBNF. I think that the > yang/netconf > >> models are still mining the existing SNMP/Configuration structures. For > new > >> development, I suspect UML may help us root out redundancy. Why? > Because I > >> think I've found lots of redundancy in the RIB_INFO model. I've > attached > >> slides that may convince you, and an alternate drafts. > >> > >> > > > > > > > > I do not have any objections to using UML. > > They are painful to read and write in ASCII art. > > Maybe that's why we tend to describe the model in introductory text. > > We also try to avoid duplicating normative text, and try to keep as much > > normative text in the YANG modules themselves (since they tend to get > > extracted and the RFC tossed ;-). > > > > This is an awesome step forwards. Thanks! > > I was going to translate the next info-model draft to YANG so we > > can compare YANG and ForCES using the same data definitions. > > Looks like you already did that, but I just see the YANG tree diagram in > the > > draft, > > not the YANG module. > > > > It is still enough to see how YANG features would be defined, based on > > protocols. > > Clearly, not every I2RS router is going to implement the exact same set > of > > protocols. > > Not every conceivable piece of data is going to be mandatory to > implement. > > Data organization and modularity are really important aspects to get > right > > the first time. > > > > > > Andy > > > > > >> > >> I've assumed in the information model that yang models as defined below > >> > >> +--------+---------------------------+-----------+ > >> > >> | Prefix | YANG module | Reference | > >> > >> +--------+---------------------------+-----------+ > >> > >> | if | ietf-interfaces | [YANG-IF] | > >> > >> | | | | > >> > >> | ip | ietf-ip | [YANG-IP] | > >> > >> | | | | > >> > >> | rt | ietf-routing | [routing] | > >> > >> | | | | > >> > >> | v4ur | ietf-ipv4-unicast-routing | [routing] | > >> > >> | | | | > >> > >> | v6ur | ietf-ipv6-unicast-routing | [routing | > >> > >> | | | | > >> > >> | yang | ietf-yang-types | [RFC6991] | > >> > >> | | | | > >> > >> | inet | ietf-inet-types | [RFC6991] | > >> > >> +--------+---------------------------+-----------+ > >> > >> > >> > >> I've attached a revision of the RIB-info-model draft that provides: > >> > >> 1) Revised RIB Grammar in RBNF (section 6.1) > >> > >> 2) (section 6.2) Spot for the pdf graphic attached as > >> draf-thares-i2rs-info-rib-only-v7.pdf > >> > >> 3) (section 6.3) Yang tree structure (per yang documents) > >> > >> 4) Revised Usage - using simplified grammar > >> > >> > >> > >> Basically the complex RBNF grammar boils down to very few simply > >> statement. The Yang Tree does not provide an easy way to design/debug > >> redundancy. I think that the use of the UML tools that create the Yang > >> modules/Yang Tree structures could speed time to market on the designs. > For > >> example, all the I2RS RIB is simply 5 power-point slides, that then can > be > >> generated into Yang module. This seems the normal progression of the > >> process you started with the Yang-modules. > >> > >> > >> > >> CAVEATS: > >> > >> 1) For all mistakes on the UML and diagrams blame me - this first > >> pass at UMLs, and it will need revising > >> > >> 2) Some of the redundancies could have been fixed in other ways > >> > >> 3) I did Yang modules to demonstrate proof of concept > >> > >> 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. > >> FoRCES Data model can do the same > >> > >> > >> > >> Sue Hares > >> > >> > >> > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman > >> Sent: Tuesday, April 22, 2014 8:46 PM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Russ > >> White; Jan Medved (jmedved); Joel M. Halpern > >> Subject: Re: [i2rs] consensus on I2RS protocol and model > >> > >> <..snip> > >> > >> 1) Why do you think that only the RIB matters in the long run > (Short > >> run = RIB + BGP) - > >> > >> [Andy] Why do you think I said that I don't see anything special about > >> I2RS at all. Editing operational state would probably work the same for > >> other data. > >> > >> [Sue]: Agree! > >> > >> > >> > >> 2) Your modeling questions are important .. so let me ask a > >> meta-question and then go a level deeper... > >> > >> Why does netmod never really publish an informational model? > >> > >> NETMOD publishes YANG modules. I suppose it is perceived an > unnecessary. > >> > >> [Sue]: Other designers on lists stated they suggested they considered IM > >> in their design of YANG. I think the graphical finds redundancies > >> > >> >> > >> > >> > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman > >> Sent: Saturday, April 19, 2014 1:46 PM > >> To: Russ White > >> Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; > Jan > >> Medved (jmedved); Joel M. Halpern > >> Subject: Re: [i2rs] consensus on I2RS protocol and model > >> > >> > >> > >> Hi, > >> > >> > >> > >> On Sat, Apr 19, 2014 at 8:22 AM, Russ White wrote: > >> > >> > >> > And the basic premise of I2RS is that there are requirements for the > >> > work > >> > that were not addressed properly by the existing configuration > >> > protocols. > >> > Otherwise the WG would not even need to discuss protocol > modifications. > >> > So the fact that NetConf / YANG works for device configuration does > not > >> > seem to be evidence that it works for what I2RS wants to do. > >> > >> Precisely. Otherwise, we could have just looked at the problem, and > said, > >> "let's use YANG." But I think we're starting to confuse the problem set > >> because we started by trying to boil the ocean. Once you actually get to > >> town, it's hard to keep in focus that you're just there for a new > >> pitchfork > >> handle -- that game of checkers over there on the porch of the hotel > looks > >> so interesting, and the hardware store has so much other stuff than just > >> pitchfork handles, after all. > >> > >> So, given we are _supposed_ to be focused on the RIB interface, and not > >> protocol, configuration, device, etc., etc., what specific points have > the > >> use cases brought out that either NETCONF/YANG or FORCES not fulfill? > One > >> of > >> the primary points was timing -- are these other systems fast enough? > >> > >> >From my perspective, these two systems don't fulfill the I2RS mandate > on > >> the > >> RIB side for various reasons: > >> > >> - I'm not convinced on the speed side. YANG feels a bit heavy weigh for > >> what > >> we want here. The flexibility is there, but so is the cost of that > >> flexibility. > >> > >> > >> > >> > >> > >> Can you explain how an off-line representation of the data model can be > >> fast or slow? > >> > >> You mean the YANG compiler takes too long to process a YANG file? > >> > >> You mean the unspecified I2RS protocol will be too slow on the wire if > >> > >> it uses XML or JSON encoding of YANG data structures? > >> > >> > >> > >> > >> > >> > >> - I'm not convinced YANG has handled the atomicity issues in a way that > >> makes sense for the application environment we have in mind. RESTCONF > >> seems > >> to go that direction, but I'm not certain it's a complete solution (?). > >> > >> > >> > >> YANG is a data modeling language. > >> > >> RESTCONF is a protocol. > >> > >> Atomicity is a property of the protocol. > >> > >> Which YANG statements prevent this from being accomplished in the TBD > I2RS > >> protocol? > >> > >> > >> > >> > >> > >> So, IMHO, I think we need to either consider FORCES, or "something new." > >> But > >> we're going to have a hard time determining if this is true if we can't > >> make > >> a solid requirements list. For me, these are: > >> > >> - Atomic operations at the RIB level > >> - Speed that's comparable to a local routing process installing routes > in > >> the RIB > >> - An immediate feedback system within the RESTful mold that tells the > >> installing process what happened, and why, with the route it just tried > to > >> install in the RIB > >> > >> So, it seems to me that we need to return to the use cases -- there are > >> two > >> in the charter. If we want to discuss adding others, that's fine, but we > >> need to gain some focus, and stop trying to boil the ocean, if we want > to > >> make any progress. > >> > >> > >> > >> It seems to me this WG needs to start asking the right questions about > the > >> > >> data modeling language requirements. E.g.: > >> > >> > >> > >> - What are the data types needed? Is this a static set of will it > ever > >> change? > >> > >> - What are the high level data modeling constructs needed? > >> > >> - Are user defined types needed? > >> > >> - Are re-usable data definitions needed? > >> > >> - Does the data model need to be modular? How does it grow over time? > >> > >> - Can vendors add data definitions that extend the standard > definitions? > >> > >> - How are new definitions added in a way that does not break existing > >> clients? > >> > >> - How is mandatory to implement vs. optional to implement > functionality > >> handled? > >> > >> - How is mandatory to use vs. optional to use functionality handled? > >> > >> > >> > >> You are asking about protocol requirements, not data modeling. > >> > >> IMO it would be near-sighted and extremely impractical to choose > >> > >> a language that only supported description on RIB info. I fail to see > >> what > >> > >> is so special about RIB info that would warrant its own DML. > >> > >> > >> > >> > >> > >> :-) > >> > >> Russ > >> > >> > >> > >> Andy > >> > >> > >> > >> > > > > > --001a11347e9c62b9cc04f7c9ef04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 24, 2014 at 3:17 AM, Jamal Hadi Salim <hadi@mojatatu.c= om> wrote:
Sorry, was there something i missed here tha= t Andy is awesom-ing?
What graphics?


No -- just progress on the info model.=

Once we have an info model, it can be mapped into= both
YANG and ForCES so they can be compared side-by-side,
using the actual model that this WG wants to standardize.

Andy


= =A0
Sounds to me like an information model in plain english (the openstack peop= le do
this) would have been a reasonable start as well, no?

cheers,
jamal

On Wed, Apr 23, 2014 at 11:03 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares <shares@ndzh.com> wrote:
>>
>> Andy:
>>
>>
>>
>> I started using UML to do the information models because Adrian Fa= rrel and
>> Alia Atlas encouraged it to replace RBNF. =A0 I think that the yan= g/netconf
>> models are still mining the existing SNMP/Configuration structures= . For new
>> development, I suspect UML may help us root out redundancy. Why? = =A0Because I
>> think I've found lots of redundancy in the RIB_INFO model. =A0= I've attached
>> slides that may convince you, and an alternate drafts.
>>
>>
>
>
>
> I do not have any objections to using UML.
> They are painful to read and write in ASCII art.
> Maybe that's why we tend to describe the model in introductory tex= t.
> We also try to avoid duplicating normative text, and try to keep as mu= ch
> normative text in the YANG modules themselves (since they tend to get<= br> > extracted and the RFC tossed ;-).
>
> This is an awesome step forwards. =A0Thanks!
> I was going to translate the next info-model draft to YANG so we
> can compare YANG and ForCES using the same data definitions.
> Looks like you already did that, but I just see the YANG tree diagram = in the
> draft,
> not the YANG module.
>
> It is still enough to see how YANG features would be defined, based on=
> protocols.
> Clearly, not every I2RS router is going to implement the exact same se= t of
> protocols.
> Not every conceivable piece of data is going to be mandatory to implem= ent.
> Data organization and modularity are really important aspects to get r= ight
> the first time.
>
>
> Andy
>
>
>>
>> I've assumed in the information model that yang models as defi= ned below
>>
>> =A0 +--------+---------------------------+-----------+
>>
>> =A0 | Prefix | YANG module =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Reference= |
>>
>> =A0 +--------+---------------------------+-----------+
>>
>> =A0 | if =A0 =A0 | ietf-interfaces =A0 =A0 =A0 =A0 =A0 | [YANG-IF]= |
>>
>> =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0 | ip =A0 =A0 | ietf-ip =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | [= YANG-IP] |
>>
>> =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0 | rt =A0 =A0 | ietf-routing =A0 =A0 =A0 =A0 =A0 =A0 =A0| [rout= ing] |
>>
>> =A0| =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0| v4ur =A0 | ietf-ipv4-unicast-routing | [routing] |
>>
>> =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0 | v6ur =A0 | ietf-ipv6-unicast-routing | [routing =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 | yang =A0 | ietf-yang-types =A0 =A0 =A0 =A0 =A0 | [RFC6991] |=
>>
>> =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 |
>>
>> =A0 | inet =A0 | ietf-inet-types =A0 =A0 =A0 =A0 =A0 | [RFC6991] |=
>>
>> =A0 +--------+---------------------------+-----------+
>>
>>
>>
>> I've attached a revision of the RIB-info-model draft that prov= ides:
>>
>> 1) =A0 =A0 =A0Revised RIB Grammar in RBNF (section 6.1)
>>
>> 2) =A0 =A0 =A0(section 6.2) Spot for the pdf graphic attached as >> draf-thares-i2rs-info-rib-only-v7.pdf
>>
>> 3) =A0 =A0 =A0(section 6.3) Yang tree structure (per yang document= s)
>>
>> 4) =A0 =A0 =A0Revised Usage - using simplified grammar
>>
>>
>>
>> Basically the complex RBNF grammar boils down to very few simply >> statement. =A0The Yang Tree does not provide an easy way to design= /debug
>> redundancy. I think that the use of the UML tools that create the = Yang
>> modules/Yang Tree structures could speed time to market on the des= igns. =A0For
>> example, all the I2RS RIB is simply 5 power-point slides, that the= n can be
>> generated into Yang module. =A0This seems the normal progression o= f the
>> process you started with the Yang-modules.
>>
>>
>>
>> CAVEATS:
>>
>> 1) =A0 =A0 =A0For all mistakes on the UML and diagrams blame me - = this first
>> pass at UMLs, and it will need revising
>>
>> 2) =A0 =A0 =A0Some of the redundancies could have been fixed in ot= her ways
>>
>> 3) =A0 =A0 =A0I did Yang modules to demonstrate proof of concept >>
>> 4) =A0 =A0 =A0I suspect with Jamal and Joel Halpern's help (Fo= RCES gurus)..
>> FoRCES Data model can do the same
>>
>>
>>
>> Sue Hares
>>
>>
>>
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of Andy Bierman
>> Sent: Tuesday, April 22, 2014 8:46 PM
>> To: Susan Hares
>> Cc: i2rs@ietf.org; Edward Cra= bbe; Jamal Hadi Salim; Dean Bogdanovic; Russ
>> White; Jan Medved (jmedved); Joel M. Halpern
>> Subject: Re: [i2rs] consensus on I2RS protocol and model
>>
>> <..snip>
>>
>> 1) =A0 =A0 =A0Why do you think that only the RIB matters in the lo= ng run (Short
>> run =3D RIB + BGP) -
>>
>> [Andy] Why do you think I said that I don't see anything speci= al about
>> I2RS at all. Editing operational state would probably work the sam= e for
>> other data.
>>
>> [Sue]: Agree!
>>
>>
>>
>> 2) =A0 =A0 =A0Your modeling questions are important .. so let me a= sk a
>> meta-question and then go a level deeper...
>>
>> =A0Why does netmod never really publish an informational model? >>
>> =A0NETMOD publishes YANG modules. I suppose it is perceived an unn= ecessary.
>>
>> [Sue]: Other designers on lists stated they suggested they conside= red IM
>> in their design of YANG. =A0I think the graphical finds redundanci= es
>>
>> <snip)
>>
>>
>>
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of Andy Bierman
>> Sent: Saturday, April 19, 2014 1:46 PM
>> To: Russ White
>> Cc: i2rs@ietf.org; Edward Cra= bbe; Jamal Hadi Salim; Dean Bogdanovic; Jan
>> Medved (jmedved); Joel M. Halpern
>> Subject: Re: [i2rs] consensus on I2RS protocol and model
>>
>>
>>
>> Hi,
>>
>>
>>
>> On Sat, Apr 19, 2014 at 8:22 AM, Russ White <russw@riw.us> wrote:
>>
>>
>> > And the basic premise of I2RS is that there are requirements = for the
>> > work
>> > that were not addressed properly by the existing configuratio= n
>> > protocols.
>> > Otherwise the WG would not even need to discuss protocol modi= fications.
>> > So the fact that NetConf / YANG works for device configuratio= n does not
>> > seem to be evidence that it works for what I2RS wants to do.<= br> >>
>> Precisely. Otherwise, we could have just looked at the problem, an= d said,
>> "let's use YANG." But I think we're starting to = confuse the problem set
>> because we started by trying to boil the ocean. Once you actually = get to
>> town, it's hard to keep in focus that you're just there fo= r a new
>> pitchfork
>> handle -- that game of checkers over there on the porch of the hot= el looks
>> so interesting, and the hardware store has so much other stuff tha= n just
>> pitchfork handles, after all.
>>
>> So, given we are _supposed_ to be focused on the RIB interface, an= d not
>> protocol, configuration, device, etc., etc., what specific points = have the
>> use cases brought out that either NETCONF/YANG or FORCES not fulfi= ll? One
>> of
>> the primary points was timing -- are these other systems fast enou= gh?
>>
>> >From my perspective, these two systems don't fulfill the I= 2RS mandate on
>> the
>> RIB side for various reasons:
>>
>> - I'm not convinced on the speed side. YANG feels a bit heavy = weigh for
>> what
>> we want here. The flexibility is there, but so is the cost of that=
>> flexibility.
>>
>>
>>
>>
>>
>> Can you explain how an off-line representation of the data model c= an be
>> fast or slow?
>>
>> You mean the YANG compiler takes too long to process a YANG file?<= br> >>
>> You mean the unspecified I2RS protocol will be too slow on the wir= e if
>>
>> it uses XML or JSON encoding of YANG data structures?
>>
>>
>>
>>
>>
>>
>> - I'm not convinced YANG has handled the atomicity issues in a= way that
>> makes sense for the application environment we have in mind. RESTC= ONF
>> seems
>> to go that direction, but I'm not certain it's a complete = solution (?).
>>
>>
>>
>> YANG is a data modeling language.
>>
>> RESTCONF is a protocol.
>>
>> Atomicity is a property of the protocol.
>>
>> Which YANG statements prevent this from being accomplished in the = TBD I2RS
>> protocol?
>>
>>
>>
>>
>>
>> So, IMHO, I think we need to either consider FORCES, or "some= thing new."
>> But
>> we're going to have a hard time determining if this is true if= we can't
>> make
>> a solid requirements list. For me, these are:
>>
>> - Atomic operations at the RIB level
>> - Speed that's comparable to a local routing process installin= g routes in
>> the RIB
>> - An immediate feedback system within the RESTful mold that tells = the
>> installing process what happened, and why, with the route it just = tried to
>> install in the RIB
>>
>> So, it seems to me that we need to return to the use cases -- ther= e are
>> two
>> in the charter. If we want to discuss adding others, that's fi= ne, but we
>> need to gain some focus, and stop trying to boil the ocean, if we = want to
>> make any progress.
>>
>>
>>
>> It seems to me this WG needs to start asking the right questions a= bout the
>>
>> data modeling language requirements. =A0E.g.:
>>
>>
>>
>> =A0 - What are the data types needed? =A0Is this a static set of w= ill it ever
>> change?
>>
>> =A0 - What are the high level data modeling constructs needed?
>>
>> =A0 - Are user defined types needed?
>>
>> =A0 - Are re-usable data definitions needed?
>>
>> =A0 - Does the data model need to be modular? =A0How does it grow = over time?
>>
>> =A0 - Can vendors add data definitions that extend the standard de= finitions?
>>
>> =A0 - How are new definitions added in a way that does not break e= xisting
>> clients?
>>
>> =A0 - How is mandatory to implement vs. optional to implement func= tionality
>> handled?
>>
>> =A0 - How is mandatory to use vs. optional to use functionality ha= ndled?
>>
>>
>>
>> You are asking about protocol requirements, not data modeling.
>>
>> IMO it would be near-sighted and extremely impractical to choose >>
>> a language that only supported description on RIB info. =A0I fail = to see
>> what
>>
>> is so special about RIB info that would warrant its own DML.
>>
>>
>>
>>
>>
>> :-)
>>
>> Russ
>>
>>
>>
>> Andy
>>
>>
>>
>>
>
>

--001a11347e9c62b9cc04f7c9ef04-- From nobody Wed Apr 30 12:51:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212731A099D for ; Wed, 30 Apr 2014 12:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.245 X-Spam-Level: *** X-Spam-Status: No, score=3.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, MANGLED_OFF=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGoQQat96Aos for ; Wed, 30 Apr 2014 12:50:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DAC151A0972 for ; Wed, 30 Apr 2014 12:50:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Mach Chen'" , References: <001101cf646a$f02b8a50$d0829ef0$@ndzh.com> In-Reply-To: Date: Wed, 30 Apr 2014 15:50:47 -0400 Message-ID: <002f01cf64ad$7b902dc0$72b08940$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHSYtUgjZ1e5k3vTLILET27QBfWPJskjabQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rcOE9TnMKJUv-4T8r5tgiw-uC8U Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 19:51:02 -0000 Nitin:=20 I'm glad we are getting to the detail. I think our first disconnect is = not at the grammar level, but at the functional level.=20 IMHO your RIB functionality is insufficient as it stands because it = doesn't contain the SRC-DST lookup using the packet + Meta data. RIBs should be able to match on the SRC-DST for all types of routes.=20 I see we have a different view on the functions of look-ups. This is a terrific discussion on the RIB-Info functionality. Let's try to decide = on this point, and then go back to grammar second. Will that work for you? = Thanks for your patience in clearly up where our assumptions were = different. Sue=20 -----Original Message----- From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]=20 Sent: Wednesday, April 30, 2014 2:10 PM To: Susan Hares; 'Mach Chen'; i2rs@ietf.org Cc: draft-ietf-i2rs-rib-info-model@tools.ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 Hi Sue, Thanks for putting this down in detail. Now it=B9s easier to explain = what I was trying to convey. -----Original Message----- From: Susan Hares >Problem: Your grammar does not handle source-destination form choice as = >a generic form used by all of the interfaces. Yes=D0it is by design. See more below. >=20 >Solution: Specify form as specific variable for all forms. >Confusion: I am suggesting two tags and you=20 >want see one tag for compilation. > >See the two tags: [form-type] as two parts to one tag: > >[high order tag form] [low order form - address form] > >At this point, all I have done is reduce your complex forms to 1 tag=20 > =3D > >Then your grammar is as follows: > > ::=3D ( | | = | > | ) = >::=3D | | | | > > =3D > =3D Routing protocols = would=20 >have: [rrr ff ttt] r =3D reserved/0 ff =3D 0/1 (for src/dst), ttt = =3D=20 >type] > > ::=3D | | | | What the above grammar does is that it allows one to construct a match = that looks like: ::=3D [Nitin} This is obviously incorrect. That=B9s the part I have been = trying to convey. In the world of routing protocols, we have IANA registries that specify = what combination is legal. In the world of data-models, we can=B9t depend on = that. So with the grammar above, how do you prevent a badly-written controller from sending a match condition that looks like above (not that the data-model will successfully compile this match condition=D0since the = rules allow it)? [Sue]: What is obviously incorrect?=20 I'm stating you can have source-destination possibilities on all of the functions. I think you are disagreeing on this point.=20 > >Each of these forms for matches could use the SRC and destination in=20 >the filter. > >I'm sure that IPv4, IPv6, and IEEE_MAC are obvious from your emails. >Interfaces can be viewed as the same for flows: =20 >. [nitin] Match is always on an incoming packet. A packet does not have embedded in it the dst-interface. So you cannot have a dst-interface as = part of the match condition. =20 [Sue]: Here is out disconnect. Match is not just on packet, but a route look-up with Meta Data with the meta data. Even Commodity chips allow = meta data to be associated with the packet flows. I see a RIB look-up as including Meta data (incoming interface) and route contain outgoing interface (even if it is *(any) interface).=20 >This can be that the traffic flow comes in on interface1 and goes out=20 >on interface 2 for all interfaces. MPLS could but it can be=20 >ingress/egress label as source/destination. > >Do you agree/disagree have a potential of having source-destination for = >most of these types? [Nitin] I disagree that there is a potential of having a src-dst for = most types. Src-dst is only possible =B3in a match condition=B2 for a route-type = that has src and dest information embedded in the packet. IPv4/IPv6 & IEEE-MAC are the only possibilities. For IEEE-MAC, there has been no use-case (requirement yet) to have = SRC-DST based routing=D0.so it wasn=B9t included so far. [Sue]: For the MPLS and L2VPN MAC related work, the set of MPLS use = cases I co-authored had this in mind. It is not an accepted use case, but it is = a published use case. I suspect what I am really stating, is that SRC-DST = is useful for all nodes. Thank you for being patient while we wind through = the disconnect.=20 > If you need context on the interfaces, pleases consider multicast and=20 >flows. [Nitin]: Multicast and flows have a next-hop that points to multiple interfaces. [Sue]: It is possible to create routes where the interfaces are the key information and the IP next hop is (*). =20 [Nitin] The incoming packet does not contain the list of outgoing interfaces. [Sue]: This is correct, but as I have noted above I am allowing for META data that would allow certain interfaces to be specified. For example, = as a security measure for a VPN, it would allow only routes coming in = interfaces 1-3 and going out 2-5. The meta data would contain this information as = part of the routing match. Did you have this restriction in mind? Please = see the white-use-case draft for this.=20 [Nitin]: Mcast has RPF which is done based on incoming interface (which = the network device knows for a given packet). So you match on mcast-address (S,G) + incoming-interface and then decide (as part of nexthop) where = all and how (load-balance, multiple copies, etc) you want to send the = packet. [Sue]: yes, interface(meta data) + packet in multicast as I indicated = up. To nexthop (meta data + interfaces) on outgoing.=20 Great response! I see we are arguing about functionality. Let's debate this.=20 My UML class drawings are very short, and they helped me understand what = I was missing in the functionality.=20 From nobody Wed Apr 30 13:25:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B911A884D for ; Wed, 30 Apr 2014 13:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b2ZRiH8UpDy for ; Wed, 30 Apr 2014 13:25:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7391A0973 for ; Wed, 30 Apr 2014 13:25:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , References: <002d01cf5cdf$d90c7b50$8b2571f0$@ndzh.com> In-Reply-To: Date: Wed, 30 Apr 2014 16:25:33 -0400 Message-ID: <005501cf64b2$575f3f90$061dbeb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01CF6490.D059D490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHI1tINcQgoIVIe2GvEOsw8Ch2XQps3rYxg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2CJvWST-ko31tCsShpkzYWgC93A Cc: 'Jeffrey Haas' , adrian@olddog.co.uk, 'Alia Atlas' Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 20:25:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01CF6490.D059D490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin: Thanks for the detailed response. From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com] Sent: Wednesday, April 30, 2014 3:01 PM To: Susan Hares; i2rs@ietf.org Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia Atlas Subject: Re: [i2rs] draft-ietf-i2rs-rib-info-model-02 Hi Sue, From: Susan Hares Date: Sunday, April 20, 2014 at 2:31 PM To: Cc: 'Jeffrey Haas' , , Alia Atlas Subject: [i2rs] draft-ietf-i2rs-rib-info-model-02 Nitin, Ron, Kini, Jan: 1) Is Section 7 of your document normative or informative? Section 7 is informative. Ok, then the RIB grammar stands alone. 2) Your grammar seems wordy/inconsistent in the repetition of the next hop below Your RIB grammar on page 17 states: ::= | ((nexthop-list-member>) | ( . | )) ::= ( | ) [] ::= ( .) Questions: Why do you have nexthop-list-member listed twice? Why list twice? Is this readability or technical matter? Why not: ::= (( | (nexthop-list-member) . ) . [Nitin on] Good question. It's a technical matter. The above (and below) format is needed to satisfy certain types of nexthops. I will list each of them. ([ ... ] )) ===> recursion. What you get from this is a way to perform the following actions on a given packet: * RECEIVE (send to local host) AND * Replicate to interface-1 and interface-2 AND * Load-balance among interface-3 and interface-4 [Nitin off] [Sue on] This functionality was evident from your earlier helpful email. However, your previous email stated you tagged this per next-hop. Did I understand each nexthop can have the following flags: 1) Special nexthops: discard, discard_with_error, receive 2) Protection_preference (primary/back-up), load_balance_weight (ecmp) If so, then I do not understand why the recursion in lists. These are just list of nexthops with flags. nexthop-list-member::= (flags) (nexthop) Or ::= [( | | ) ] () Are you trying to apply the flag Meta data is applying to the next hop chain? [Sue] Why not: ::= ((( | ( . ))[ tag acts like an enclosing tag for a list of next hops. It also indicates that the nexthops are related and should be treated as a chain to be applied one after the other to the same packet. Nothing magic. What it also allows (down the road) is to maintain an association of nexthop-chain contents to a chain-ID. And when a network-device supports nexthop-chain-IDs, the controller can replace the chain with just it's ID. Maintaining just a list of nexthops makes it harder for a controller to correlate whether 2 nexthops-list-members are effectively the same (without a bunch of crazy comparisons and sorting). Nexthop-chain tag also allows ease of understanding for Section 7.2.5. [nitin off] [Sue on] Ok - the assumption that a nexthop-chain-list identifier would be always associated with start of chain was not clear. Could you tell me where I missed that piece of information (other than the grammar - which has it optional). Why does the grammar not say: ::= (.) ::= [] :: == ( .) ::= ((( | ( . ))[ Multicast-source-ipv6-address ::= Did I miss someplace where they attached to the normative section 6. You indicated the PIM paths can be chains (section 7.3), but you do not give the normative section. These are going to be removed. [Nitin]: Now that you have understood a lot of the IM model, looking forward to an implementation of the same :-) Thanks Nitin [Sue]: I found a lot of these issues when starting at the UML drawings and then trying to retro-fit your UML. It's all about assumptions - let's clear up the last and come to agreement the RBNF. Once we get an agreed-upon RBNF text, I will like to suggest a UML equivalent. Thanks for your responses. Sue PS - I am working with developers. See my co-authors on the UML work. ------=_NextPart_000_0056_01CF6490.D059D490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin:

 

Thanks for the detailed = response.

 

From:= = Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]
Sent: = Wednesday, April 30, 2014 3:01 PM
To: Susan Hares; = i2rs@ietf.org
Cc: 'Jeffrey Haas'; adrian@olddog.co.uk; Alia = Atlas
Subject: Re: [i2rs] = draft-ietf-i2rs-rib-info-model-02

 

Hi Sue,

<= p class=3DMsoNormal> 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Sunday, April 20, 2014 at 2:31 PM
To: <i2rs@ietf.org>
Cc: = 'Jeffrey Haas' <jhaas@pfrc.org>, <adrian@olddog.co.uk>, Alia = Atlas <akatlas@juniper.net>
Sub= ject: [i2rs] = draft-ietf-i2rs-rib-info-model-02

 

=

Nitin, Ron, Kini, Jan: =

 

1)      = Is Section 7 = of your document normative or informative?

 

 

=

Section 7 is = informative.

 

Ok, then the RIB grammar = stands alone.

 

=

 

=

2)      = Your grammar = seems wordy/inconsistent in the repetition of the next hop below =

 

Your RIB grammar on = page 17 states:

 

<nexthop-list> ::=3D = <special-nexthop> |

        &nb= sp;           &nbs= p;           ((nex= thop-list-member>) |

        &nb= sp;           &nbs= p;            = ;(<nexthop-list-member> … | = <nexthop-list>))

 

<nexthop-list-member> ::=3D = (<nexthop-chain> |

        &nb= sp;           &nbs= p;            = ;            =       <nexthop-chain-identifier>)

        &nb= sp;           &nbs= p;            = ;            =      = [<nexthop-list-member-attributes>]

 

<nexthop-chain>::=3D = (<nexthop> …)

 

Questions: Why do you have = nexthop-list-member listed twice?  Why list <nexthop-list> = twice? Is this readability or technical matter?

 

Why not: =

<nexthop-list>::=3D = ((<special-nexthop> | (nexthop-list-member) … ) … =

 

[Nitin = on]

Good question. It’s a technical matter. = The above (and below) format is needed to satisfy certain types = of nexthops. I will list each of them.

 

([<nexthop-list-member> ... = ] <nexthop-list> )) =3D=3D=3D> = recursion.

What you get from this is a way to = perform the following actions on a given packet:

  • RECEIVE (send to local host)   =  AND
  • Replicate to interface-1 and interface-2   = AND
  • Load-balance = among interface-3 and interface-4

[Nitin off]

[Sue on]

This functionality was evident from your = earlier helpful email.  However, your previous email stated you = tagged this per next-hop.  Did I understand each nexthop can have = the following flags:

 

1)      = Special nexthops: discard, = discard_with_error, receive

2)      =  Protection_preference = (primary/back-up), load_balance_weight (ecmp)

 

If so, then I do not understand why the = recursion in lists.  These are just list of nexthops with flags. =

 

nexthop-list-member::=3D  (flags) = (nexthop)

 

Or

<nexthop-list-member> ::=3D = [(<SPECIAL_NEXT_HOP> | <PROTECTION_PREFERENCE> | = <LOADBALANCE>) ]

       &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   (<nexthop>)

 

Are you trying to apply the flag Meta data = is applying to the next hop chain?  

[Sue]

 

 

 

 

Why not: =

<nexthop-list-member> ::=3D = (((<nexthop-chain-identifier> | (<nexthops> … = ))[<nexthop-list-member-attributes]) )… =

 

Were you trying to name = the chains?

 

 

 

[Nitin on ] =

The <nexthop-chain> tag acts like an = enclosing tag for a list of next hops. It also indicates that the = nexthops are related and should be treated as a chain to be applied one = after the other to the same packet. Nothing magic. What it also = allows (down the road) is to maintain an association of nexthop-chain = contents to a chain-ID. And when a network-device supports = nexthop-chain-IDs, the controller can replace the chain with just = it’s ID. Maintaining just a list of nexthops makes it = harder for a controller to correlate whether 2 nexthops-list-members are = effectively the same (without a bunch of crazy comparisons and = sorting).

 

Nexthop-chain tag = also allows ease of understanding for Section 7.2.5.

[nitin = off]

[Sue on] =

Ok – the assumption that = a nexthop-chain-list identifier would be always associated with start of = chain was not clear.  Could you tell me where I missed that piece = of information (other than the grammar – which has it optional). =

 

Why = does the grammar not say:

 

<nexthop-chain-list>::=3D = <nexthop-chain-identifier>  (<nexthop>…) =
<nexthop-list-member>::=3D<nexthop-chain-list> = [<nexthop-list-member-attributes>]

= <nexthop-list>:: =3D=3D (<nexthop-chain-list> …) =

 

<nexthop-list-member> ::=3D = (((<nexthop-chain-identifier> | (<nexthops> … = ))[<nexthop-list-member-attributes]) )…

3)      = Two variables = seem orphaned:

 

Multicast-source-ipv4-address ::=3D = <IPv4_ADDRESS> <IPV4_PREFIX_LENGTH>

Multicast-source-ipv6-address ::=3D = <IPv6_ADDRESS> <IPv6_PREFIX_LENGTH>

 

        &nb= sp;Did I miss someplace where they attached to the normative section 6. =

        &nb= sp;  You indicated the PIM paths can be chains (section 7.3), = but you do not give the normative section. =

 

=

These are going to be = removed.

<= p class=3DMsoNormal> 

[Nitin]: = Now that you have = understood a lot of the IM model, looking forward to an implementation = of the same :-)

Thanks Nitin

 

[Sue]: =   I found a lot of these issues when starting at the UML = drawings and then trying to retro-fit your UML.

     &n= bsp;        It’s all about = assumptions – let’s clear up the last and come to agreement = the RBNF. 

 

   =              = Once we get an agreed-upon RBNF text, I will like to suggest a UML = equivalent.

 

Thanks = for your responses.

 

Sue =

 

PS – I am working = with developers. See my co-authors on the UML work. =

------=_NextPart_000_0056_01CF6490.D059D490-- From nobody Wed Apr 30 13:28:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33FB1A0916 for ; Wed, 30 Apr 2014 13:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndnyjBtjm1U6 for ; Wed, 30 Apr 2014 13:28:05 -0700 (PDT) Received: from nm25-vm2.bullet.mail.gq1.yahoo.com (nm25-vm2.bullet.mail.gq1.yahoo.com [98.136.217.113]) by ietfa.amsl.com (Postfix) with ESMTP id B0A861A0973 for ; Wed, 30 Apr 2014 13:28:04 -0700 (PDT) Received: from [216.39.60.182] by nm25.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 20:28:03 -0000 Received: from [208.71.42.193] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 20:28:03 -0000 Received: from [127.0.0.1] by smtp204.mail.gq1.yahoo.com with NNFMP; 30 Apr 2014 20:28:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398889683; bh=mRPNl2IbQyK1UoRB6y+v9FPDPdDiakwY8yXWeP+Mu38=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=5syUqJxZFJZnNBkphcPMnpcEvIuzOIg56JDe2zu6VAGBE4v8XZTnPeon67zQHubI8YovbwrihfFkgMtdDmpeGJIkI1L87sgMZorHhqaSGVToZtSEQGrGeDJ5BDLkXXouCUR4GALiAmVYtxkgJUt3cb+h+Ivr5kfXedMqkXADB+8= X-Yahoo-Newman-Id: 273676.89153.bm@smtp204.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: W0KjSm0VM1nGJHBdZZM1PxPSeDmcX7HUNpXkk2NrQGdUReD 27xy6hBs0XxkOZ33d2EgfG.n98Zd7pa6spVhRisA27wdq5m.W75jIE2hB8yv 8U6FozwJh0rLFCVyMZ_PFI2G54Vp3f9OW21DNwZlVNX.8HiJrZnIxN9BjrKt zegMLsND.jtTMOcbhric_1OXNgLQ9geQO_LckkNe6wGW3KyFegl0hXCHbmh8 6bJ5k70lX_.FPxvZIM2uesmFhrJSwHzyC6joOwXjhjkn2QuEjOH67de4kPRE cEb.ZrZQOg8kPre2iIE9T0wwuq_o5jL5EgkWcC.IIz04jeGy54uPCYeR5QmS zHZPMiOY_YiwXInZOgwaaxmslw9Zm0Fk6dzqG41jM082hOPqAFelqSH.vigg ko8iIoGtaML4qjYm4iEJeEqXOBCSPOBNDeC_xzWKBHF4CXH28mm9mq1AyeWZ fu1KvrK2PHCO3T6pe4HNtpzFVTOlx6Rsgk8SN.qeYshAAGzTmzV0bV0IBBGu pkdVOgP77WCCynGL_mHjs9VVi04F4JsM- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [98.139.211.125]) by smtp204.mail.gq1.yahoo.com with SMTP; 30 Apr 2014 13:28:03 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 30 Apr 2014 13:28:00 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 In-Reply-To: <002f01cf64ad$7b902dc0$72b08940$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fiwOkvpBnBuzMYPmtcBs1xvC1TM Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 20:28:09 -0000 > >IMHO your RIB functionality is insufficient as it stands because it >doesn't >contain the SRC-DST lookup using the packet + Meta data. RIBs should be >able to match on the SRC-DST for all types of routes. > >I see we have a different view on the functions of look-ups. This is a >terrific discussion on the RIB-Info functionality. Let's try to decide on >this point, and then go back to grammar second. Will that work for you? Yup=8Awe have a different view. Looking forward to see what views the rest of WG has. Thanks Nitin From nobody Wed Apr 30 13:33:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6D1A8891 for ; Wed, 30 Apr 2014 13:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veZFCLVCN8lK for ; Wed, 30 Apr 2014 13:33:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF91A09A6 for ; Wed, 30 Apr 2014 13:33:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> <20140430174854.GB31746@elstar.local> <002701cf64a9$76159410$6240bc30$@ndzh.com> <20140430194008.GB31986@elstar.local> In-Reply-To: <20140430194008.GB31986@elstar.local> Date: Wed, 30 Apr 2014 16:32:54 -0400 Message-ID: <006201cf64b3$5e145c70$1a3d1550$@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: AQD7MnlZh5dWEJhlAdE4T282rDtaOwFK6EKkAZg9FWwCcyTOhAKicq5hAnZX0SoCoDeitgJb3B4TAkpGmMQBVRmVhZw6q6JQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/svNiZkalJ2RszPcscjhzGf2D8nQ Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 20:33:16 -0000 Juergen: I suggest the UML as an Informational model is quick and easy to read. Most generated prototypes can enforce interoperability you wish for. If not, the UML to code tool is just broken. The steps are: UML--> Data Model (yang/forces) --> code I think the UML is readable. Please comment on my UML drawings that I sent at the beginning of this post. If you wish a power point of the UML so you can edit it, I'll send one. At the Yang step, Andy assures me it is readable so debugging the tool should be useful. I was answering the performance issue question with the iterative code. I think this does provide what you require. Can you tell me where your experience states this is a misstep? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, April 30, 2014 3:40 PM To: Susan Hares Cc: 'Nitin Bahadur'; 'Joel Halpern Direct'; 'Mach Chen'; draft-ietf-i2rs-rib-info-model@tools.ietf.org; i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 On Wed, Apr 30, 2014 at 03:22:00PM -0400, Susan Hares wrote: > Juergen: > > Thanks for the high quality and pragmatic response. Yes, I did mean > UML Class diagrams. As the teens say "my bad". > > As to the tools and code generation: > During my days of writing protocol software or managing protocol > software writers, I found it often took 3+ rewrites to get efficient code after > working good. If tools create inefficient code but working code - at least > a prototype to test against comes up quickly. If tools improve the > prototype may get closer and the re-writes less. But we are talking about standardizing data models we want to interoperate. You can't apply iterative code development to this. > As to descending into detail with UML: that's actually a plus for me. > The purpose behind UML is to quicken the pace of the process from high > level agreement to DM. We can standardize the high level and then use > the UML to provide quicken layers of agreement. As usual, the hard is finding agreement, not so much the format. A format that people do not read carefully may help in the sense that you get less reviews and thus you believe you were faster (but you might have just moved the difficult parts of the agreement finding process to a later stage). As such, a format that increases the chances of getting a fair number of substantial reviews of key parties should be the target. /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 nobody Wed Apr 30 13:49:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824651A08BE for ; Wed, 30 Apr 2014 13:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swNfqezDe4iZ for ; Wed, 30 Apr 2014 13:49:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D51A0957 for ; Wed, 30 Apr 2014 13:49:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Nitin Bahadur'" , References: <002f01cf64ad$7b902dc0$72b08940$@ndzh.com> In-Reply-To: Date: Wed, 30 Apr 2014 16:49:01 -0400 Message-ID: <00bd01cf64b5$9e7416a0$db5c43e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGmHcG9ZriICU9zKznF75N0fPqXn5t9L13w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ibw5wrccAA6GCf95SuYlcEzuuws Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 20:49:07 -0000 Nitin:=20 To make the discussion it easier, can you release a new version of the clean-up RBNF grammar? Even a post of your clean-up would help me not = miss something in our discussions.=20 Sue=20 -----Original Message----- From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]=20 Sent: Wednesday, April 30, 2014 4:28 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > >IMHO your RIB functionality is insufficient as it stands because it=20 >doesn't contain the SRC-DST lookup using the packet + Meta data. RIBs=20 >should be able to match on the SRC-DST for all types of routes. > >I see we have a different view on the functions of look-ups. This is a = >terrific discussion on the RIB-Info functionality. Let's try to decide = >on this point, and then go back to grammar second. Will that work for = you? Yup=A9we have a different view. Looking forward to see what views the = rest of WG has. Thanks Nitin From nobody Wed Apr 30 14:13:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D961A0953 for ; Wed, 30 Apr 2014 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWtCsuN8Uae6 for ; Wed, 30 Apr 2014 13:40:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAEC1A08BE for ; Wed, 30 Apr 2014 13:40:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Andy Bierman'" References: <71FA88B3-601E-47FC-8EA9-9451B9BCC5F9@juniper.net> <5351C11F.1070109@joelhalpern.com> <001a01cf5be3$345abf60$9d103e20$@riw.us> <006f01cf5e8c$015231b0$03f69510$@ndzh.com> <006701cf5f02$211325b0$63397110$@ndzh.com> In-Reply-To: <006701cf5f02$211325b0$63397110$@ndzh.com> Date: Wed, 30 Apr 2014 16:39:59 -0400 Message-ID: <008101cf64b4$5bc8c950$135a5bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CF6492.D4BE0720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNnmQphth37jSxo2JyFHVfe58SH+gE19ItPAkkZQqkBpfvoDQIkI0aUAsDj21sCB4SBTwLLvtGJAocAEHQB8lGI9QG/kFEwAd6lU/uXQo9LwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bzvk2fQ084PbYjBsoK16ru0J8tk X-Mailman-Approved-At: Wed, 30 Apr 2014 14:13:46 -0700 Cc: 'Nitin Bahadur' , i2rs@ietf.org, 'Edward Crabbe' , 'Jamal Hadi Salim' , 'Dean Bogdanovic' , 'Russ White' , "'Jan Medved \(jmedved\)'" , adrian@olddog.co.uk, 'Jeffrey Haas' , 'Alia Atlas' , "'Joel M. Halpern'" Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 20:40:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01CF6492.D4BE0720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ed and all: The chairs are just letting through old mail (see the date) - I moved this topic to another list. Anyone post on this topic should go to: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01. Use the thread index on the list to find it if you have questions drop me a note. Thanks, Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, April 23, 2014 10:42 AM To: 'Andy Bierman' Cc: Nitin Bahadur; i2rs@ietf.org; 'Edward Crabbe'; 'Jamal Hadi Salim'; 'Dean Bogdanovic'; 'Russ White'; 'Jan Medved (jmedved)'; Alia Atlas; 'Jeffrey Haas'; adrian@olddog.co.uk; 'Joel M. Halpern' Subject: Re: [i2rs] consensus on I2RS protocol and model Andy: I started using UML to do the information models because Adrian Farrel and Alia Atlas encouraged it to replace RBNF. I think that the yang/netconf models are still mining the existing SNMP/Configuration structures. For new development, I suspect UML may help us root out redundancy. Why? Because I think I've found lots of redundancy in the RIB_INFO model. I've attached slides that may convince you, and an alternate drafts. I've assumed in the information model that yang models as defined below +--------+---------------------------+-----------+ | Prefix | YANG module | Reference | +--------+---------------------------+-----------+ | if | ietf-interfaces | [YANG-IF ] | | | | | | ip | ietf-ip | [YANG-IP ] | | | | | | rt | ietf-routing | [routing] | | | | | | v4ur | ietf-ipv4-unicast-routing | [routing] | | | | | | v6ur | ietf-ipv6-unicast-routing | [routing | | | | | | yang | ietf-yang-types | [RFC6991 ] | | | | | | inet | ietf-inet-types | [RFC6991 ] | +--------+---------------------------+-----------+ I've attached a revision of the RIB-info-model draft that provides: 1) Revised RIB Grammar in RBNF (section 6.1) 2) (section 6.2) Spot for the pdf graphic attached as draf-thares-i2rs-info-rib-only-v7.pdf 3) (section 6.3) Yang tree structure (per yang documents) 4) Revised Usage - using simplified grammar Basically the complex RBNF grammar boils down to very few simply statement. The Yang Tree does not provide an easy way to design/debug redundancy. I think that the use of the UML tools that create the Yang modules/Yang Tree structures could speed time to market on the designs. For example, all the I2RS RIB is simply 5 power-point slides, that then can be generated into Yang module. This seems the normal progression of the process you started with the Yang-modules. CAVEATS: 1) For all mistakes on the UML and diagrams blame me - this first pass at UMLs, and it will need revising 2) Some of the redundancies could have been fixed in other ways 3) I did Yang modules to demonstrate proof of concept 4) I suspect with Jamal and Joel Halpern's help (FoRCES gurus).. FoRCES Data model can do the same Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, April 22, 2014 8:46 PM To: Susan Hares Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. Halpern Subject: Re: [i2rs] consensus on I2RS protocol and model <..snip> 1) Why do you think that only the RIB matters in the long run (Short run = RIB + BGP) - [Andy] Why do you think I said that I don't see anything special about I2RS at all. Editing operational state would probably work the same for other data. [Sue]: Agree! 2) Your modeling questions are important .. so let me ask a meta-question and then go a level deeper. Why does netmod never really publish an informational model? NETMOD publishes YANG modules. I suppose it is perceived an unnecessary. [Sue]: Other designers on lists stated they suggested they considered IM in their design of YANG. I think the graphical finds redundancies wrote: > And the basic premise of I2RS is that there are requirements for the work > that were not addressed properly by the existing configuration protocols. > Otherwise the WG would not even need to discuss protocol modifications. > So the fact that NetConf / YANG works for device configuration does not > seem to be evidence that it works for what I2RS wants to do. Precisely. Otherwise, we could have just looked at the problem, and said, "let's use YANG." But I think we're starting to confuse the problem set because we started by trying to boil the ocean. Once you actually get to town, it's hard to keep in focus that you're just there for a new pitchfork handle -- that game of checkers over there on the porch of the hotel looks so interesting, and the hardware store has so much other stuff than just pitchfork handles, after all. So, given we are _supposed_ to be focused on the RIB interface, and not protocol, configuration, device, etc., etc., what specific points have the use cases brought out that either NETCONF/YANG or FORCES not fulfill? One of the primary points was timing -- are these other systems fast enough? >From my perspective, these two systems don't fulfill the I2RS mandate on the RIB side for various reasons: - I'm not convinced on the speed side. YANG feels a bit heavy weigh for what we want here. The flexibility is there, but so is the cost of that flexibility. Can you explain how an off-line representation of the data model can be fast or slow? You mean the YANG compiler takes too long to process a YANG file? You mean the unspecified I2RS protocol will be too slow on the wire if it uses XML or JSON encoding of YANG data structures? - I'm not convinced YANG has handled the atomicity issues in a way that makes sense for the application environment we have in mind. RESTCONF seems to go that direction, but I'm not certain it's a complete solution (?). YANG is a data modeling language. RESTCONF is a protocol. Atomicity is a property of the protocol. Which YANG statements prevent this from being accomplished in the TBD I2RS protocol? So, IMHO, I think we need to either consider FORCES, or "something new." But we're going to have a hard time determining if this is true if we can't make a solid requirements list. For me, these are: - Atomic operations at the RIB level - Speed that's comparable to a local routing process installing routes in the RIB - An immediate feedback system within the RESTful mold that tells the installing process what happened, and why, with the route it just tried to install in the RIB So, it seems to me that we need to return to the use cases -- there are two in the charter. If we want to discuss adding others, that's fine, but we need to gain some focus, and stop trying to boil the ocean, if we want to make any progress. It seems to me this WG needs to start asking the right questions about the data modeling language requirements. E.g.: - What are the data types needed? Is this a static set of will it ever change? - What are the high level data modeling constructs needed? - Are user defined types needed? - Are re-usable data definitions needed? - Does the data model need to be modular? How does it grow over time? - Can vendors add data definitions that extend the standard definitions? - How are new definitions added in a way that does not break existing clients? - How is mandatory to implement vs. optional to implement functionality handled? - How is mandatory to use vs. optional to use functionality handled? You are asking about protocol requirements, not data modeling. IMO it would be near-sighted and extremely impractical to choose a language that only supported description on RIB info. I fail to see what is so special about RIB info that would warrant its own DML. :-) Russ Andy ------=_NextPart_000_0082_01CF6492.D4BE0720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed and all:

 

The chairs are just letting through old mail (see the date) – I = moved this topic to another list.  Anyone post on this topic should = go to:  Re: [i2rs] Some comments on = draft-ietf-i2rs-rib-info-model-01.

 

Use the thread index on the list to find it if you have questions = drop me a note.

 

Thanks,

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Wednesday, April 23, 2014 10:42 AM
To: = 'Andy Bierman'
Cc: Nitin Bahadur; i2rs@ietf.org; 'Edward = Crabbe'; 'Jamal Hadi Salim'; 'Dean Bogdanovic'; 'Russ White'; 'Jan = Medved (jmedved)'; Alia Atlas; 'Jeffrey Haas'; adrian@olddog.co.uk; = 'Joel M. Halpern'
Subject: Re: [i2rs] consensus on I2RS = protocol and model

 

Andy:

 

I started using UML to do the information models because Adrian = Farrel and Alia Atlas encouraged it to replace RBNF.   I think = that the yang/netconf models are still mining the existing = SNMP/Configuration structures. For new development, I suspect UML may = help us root out redundancy. Why?  Because I think I’ve found = lots of redundancy in the RIB_INFO model.  I’ve attached = slides that may convince you, and an alternate = drafts.

 

I’ve assumed in the information model that yang models as = defined below

 

  +--------+---------------------------+-----= ------+

  = | Prefix | YANG = module           &= nbsp;   | Reference |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal style=3D'page-break-before:always'>  = | if     | = ietf-interfaces         &nbs= p; | [YANG-IF] |

  = |        = |            =             &= nbsp;  = |           = |

  = | ip     | = ietf-ip           =         | [YANG-IP] |

  = |        = |            =             &= nbsp;  = |           = |

  = | rt     | = ietf-routing          &= nbsp;   | = [routing] |

 |        = |            =             &= nbsp;  = |           = |

 | = v4ur   | ietf-ipv4-unicast-routing | = [routing] |

  = |        = |            =             &= nbsp;  = |           = |

  = | v6ur   | ietf-ipv6-unicast-routing | = [routing  |

  = |        = |            =             &= nbsp;  = |           = |

  = | yang   | = ietf-yang-types         &nbs= p; | [RFC6991] = |

  = |        = |            =             &= nbsp;  = |           = |

  = | inet   | = ietf-inet-types         &nbs= p; | [RFC6991] = |

  = +--------+---------------------------+-----------+

<= p class=3DMsoNormal> 

I’ve attached a revision of the RIB-info-model draft that = provides:

1)      = Revised RIB Grammar in RBNF (section 6.1)

2)      = (section 6.2) Spot for the pdf graphic attached as = draf-thares-i2rs-info-rib-only-v7.pdf

3)      = (section 6.3) Yang tree structure (per yang = documents)

4)      = Revised Usage – using simplified = grammar

 

Basically the complex RBNF grammar boils down to very few simply = statement.  The Yang Tree does not provide an easy way to = design/debug redundancy. I think that the use of the UML tools that = create the Yang modules/Yang Tree structures could speed time to market = on the designs.  For example, all the I2RS RIB is simply 5 = power-point slides, that then can be generated into Yang module.  = This seems the normal progression of the process you started with the = Yang-modules.

 

CAVEATS:

1)      = For all mistakes on the UML and diagrams blame me – this first = pass at UMLs, and it will need revising

2)      = Some of the redundancies could have been fixed in other ways =

3)      = I did Yang modules to demonstrate proof of = concept

4)      = I suspect with Jamal and Joel Halpern’s help (FoRCES gurus).. = FoRCES Data model can do the same

 

Sue Hares  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Andy Bierman
Sent: Tuesday, April 22, 2014 = 8:46 PM
To: Susan Hares
Cc: i2rs@ietf.org; Edward Crabbe; Jamal = Hadi Salim; Dean Bogdanovic; Russ White; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

<..snip>  

1)      = Why do you think that only the RIB matters in the long run (Short run = =3D RIB + BGP) -

[Andy] Why do you = think I said that I don't see = anything special about I2RS at all. = Editing operational state would probably work the same for other = data.

[Sue]: Agree!

 

2)      = Your modeling questions are important .. so let me ask a = meta-question and then go a level deeper…

 Why does netmod never really publish an informational model? =

 NETMOD publishes YANG modules. I suppose it is perceived an = unnecessary.

[Sue]: Other designers on lists stated they suggested they considered = IM in their design of YANG.  I think the graphical finds = redundancies

<snip)  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Saturday, April 19, 2014 1:46 PM
To: = Russ White
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; = Dean Bogdanovic; Jan Medved (jmedved); Joel M. = Halpern
Subject: Re: [i2rs] consensus on I2RS protocol and = model

 <= /o:p>

Hi,

 <= /p>

On Sat, Apr = 19, 2014 at 8:22 AM, Russ White <russw@riw.us> wrote:


> = And the basic premise of I2RS is that there are requirements for the = work
> that were not addressed properly by the existing = configuration protocols.
> Otherwise the WG would not even need to = discuss protocol modifications.
> So the fact that NetConf / YANG = works for device configuration does not
> seem to be evidence that = it works for what I2RS wants to do.

Precisely. Otherwise, we = could have just looked at the problem, and said,
"let's use = YANG." But I think we're starting to confuse the problem = set
because we started by trying to boil the ocean. Once you actually = get to
town, it's hard to keep in focus that you're just there for a = new pitchfork
handle -- that game of checkers over there on the porch = of the hotel looks
so interesting, and the hardware store has so much = other stuff than just
pitchfork handles, after all.

So, given = we are _supposed_ to be focused on the RIB interface, and = not
protocol, configuration, device, etc., etc., what specific points = have the
use cases brought out that either NETCONF/YANG or FORCES not = fulfill? One of
the primary points was timing -- are these other = systems fast enough?

>From my perspective, these two systems = don't fulfill the I2RS mandate on the
RIB side for various = reasons:

- I'm not convinced on the speed side. YANG feels a bit = heavy weigh for what
we want here. The flexibility is there, but so = is the cost of that
flexibility.

 <= /o:p>

 <= /o:p>

Can you = explain how an off-line representation of the data model can be fast or = slow?

You mean = the YANG compiler takes too long to process a YANG = file?

You mean = the unspecified I2RS protocol will be too slow on the wire = if

it uses XML = or JSON encoding of YANG data structures?

 <= /o:p>

 <= /o:p>


- I'm not = convinced YANG has handled the atomicity issues in a way that
makes = sense for the application environment we have in mind. RESTCONF = seems
to go that direction, but I'm not certain it's a complete = solution (?).

 <= /o:p>

YANG is a = data modeling language.

RESTCONF is = a protocol.

Atomicity = is a property of the protocol.

Which YANG = statements prevent this from being accomplished in the TBD I2RS = protocol?

 <= /o:p>

 <= /o:p>

So, IMHO, I think = we need to either consider FORCES, or "something new." = But
we're going to have a hard time determining if this is true if we = can't make
a solid requirements list. For me, these are:

- = Atomic operations at the RIB level
- Speed that's comparable to a = local routing process installing routes in
the RIB
- An immediate = feedback system within the RESTful mold that tells the
installing = process what happened, and why, with the route it just tried = to
install in the RIB

So, it seems to me that we need to = return to the use cases -- there are two
in the charter. If we want = to discuss adding others, that's fine, but we
need to gain some = focus, and stop trying to boil the ocean, if we want to
make any = progress.

 <= /o:p>

It seems to = me this WG needs to start asking the right questions about = the

data = modeling language requirements.  E.g.:

 <= /o:p>

  - = What are the data types needed?  Is this a static set of will it = ever change?

  - = What are the high level data modeling constructs = needed?

  - = Are user defined types needed?

  - = Are re-usable data definitions needed?

  - = Does the data model need to be modular?  How does it grow over = time?

  - = Can vendors add data definitions that extend the standard = definitions?

  - = How are new definitions added in a way that does not break existing = clients?

  - = How is mandatory to implement vs. optional to implement functionality = handled?

  - = How is mandatory to use vs. optional to use functionality = handled?

 <= /o:p>

You are = asking about protocol requirements, not data = modeling.

IMO it = would be near-sighted and extremely impractical to = choose

a language = that only supported description on RIB info.  I fail to see = what

is so = special about RIB info that would warrant its own = DML.

 <= /o:p>

 <= /o:p>

:-)

R= uss

 <= /o:p>

Andy

 <= /o:p>

 

------=_NextPart_000_0082_01CF6492.D4BE0720-- From nobody Wed Apr 30 14:32:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75141A0982 for ; Wed, 30 Apr 2014 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxNGDAc3rE3S for ; Wed, 30 Apr 2014 14:32:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id C82EB1A09A5 for ; Wed, 30 Apr 2014 14:32:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F0DC4718; Wed, 30 Apr 2014 23:32:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 36vr4ZpP_Don; Wed, 30 Apr 2014 23:32:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 23:32:35 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 364932002C; Wed, 30 Apr 2014 23:32:35 +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 wkCkKz__Lu-O; Wed, 30 Apr 2014 23:32:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9162620013; Wed, 30 Apr 2014 23:32:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE9902CC7280; Wed, 30 Apr 2014 23:32:32 +0200 (CEST) Date: Wed, 30 Apr 2014 23:32:32 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140430213232.GA32419@elstar.local> Mail-Followup-To: Susan Hares , 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> <20140430174854.GB31746@elstar.local> <002701cf64a9$76159410$6240bc30$@ndzh.com> <20140430194008.GB31986@elstar.local> <006201cf64b3$5e145c70$1a3d1550$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006201cf64b3$5e145c70$1a3d1550$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CPqS8AoB9InmT68CY0YMZ5VkVrk Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 30 Apr 2014 21:32:40 -0000 On Wed, Apr 30, 2014 at 04:32:54PM -0400, Susan Hares wrote: > Juergen: > > I suggest the UML as an Informational model is quick and easy to read. Most > generated prototypes can enforce interoperability you wish for. If not, the > UML to code tool is just broken. The steps are: > > UML--> Data Model (yang/forces) --> code I believe that a tool that generates a meaningful YANG data model out of a UML information model requires so many details in the UML model that the UML model stops being an information model. A data model has to be very clear about naming. If you use YANG, you need to transfer an arbitrary graph of classes and their relationships into a tree. The answer to the question what becomes a reference between branches in a tree and what can be captured through nesting does not naturally fall out of a UML class diagram. Perhaps I am overly pessimistic. A key point of an information model is that it focusses on fundamental concepts and that it on purpose leaves out details that are needed in data models. So either your tool transforming UML class diagrams into YANG has a second information source or you have to overload your UML diagrams with details that turn your UML diagrams into a data model. > I think the UML is readable. Please comment on my UML drawings that I sent > at the beginning of this post. If you wish a power point of the UML so you > can edit it, I'll send one. > At the Yang step, Andy assures me it is > readable so debugging the tool should be useful. I was answering the > performance issue question with the iterative code. I think this does > provide what you require. I like to see the UML input and the YANG output or even better the tool. I am happy to see the text I wrote above proven wrong. > Can you tell me where your experience states this is a misstep? See above. I have seen people who added lots of details to their UML class diagrams in order to drive automation until the UML diagrams filled walls and essentially lost their value of summarizing key concepts. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 30 16:18:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48E11A04E8 for ; Wed, 30 Apr 2014 16:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Z3jUE3tygU for ; Wed, 30 Apr 2014 16:18:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 302E81A0955 for ; Wed, 30 Apr 2014 16:18:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGG81496; Wed, 30 Apr 2014 23:18:08 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 1 May 2014 00:16:50 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 1 May 2014 00:18:07 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Wed, 30 Apr 2014 16:18:01 -0700 From: Linda Dunbar To: "Bitar, Nabil N" , "i2rs@ietf.org" Thread-Topic: questiosn and suggestions to draft-bitar-i2rs-service-chaining-01 Thread-Index: Ac9kym3tZBf1+acZQzuW0tuCtYwfDw== Date: Wed, 30 Apr 2014 23:18:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CFFE9B@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.117] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/KdvQcxWjUTOgZLZ_0Vb1rx4vYes Subject: [i2rs] questiosn and suggestions to draft-bitar-i2rs-service-chaining-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 23:18:14 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_" --_000_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nabil, et al, Do you assume network nodes as service nodes in the context of Service Chai= ning? In the same level as today's middle boxes (a.k.a. L4-L7 service nodes)? For example, if a data flow needs to traverse through nodes: CE1, FW1, PE1,= P1, PE2, FW2, CE2, then service chain is: CE1 -> FW -> PE1 -> P1 -> PE2->= FW2-> CE2. Correct? There are protocols (e.g. IGP/BGP) to discover network layer nodes, but man= y of today's L4-L7 service functions (so called middle boxes) don't partici= pate in the routing protocols for topology discovery. Therefore, Section 3.1 (Service topology) should differentiate the two case= s. The attributes you listed in Section 3.1 for "Service Node" are more app= licable to L4-L7 service nodes. Page 7, you also listed additional attributes (many of them are for TE base= d routing), mixed with MAC/FIB database size, etc. They are more for L2/L3 = device. Section 3.2. (Monitoring Information) Many of today's L4-L7 service functions are monitored by their own monitori= ng systems. Monitoring FW is very different than monitoring DPI, or Video o= ptimization function. The parameters you listed in Section 3.2 are more for monitoring routers, l= ess for monitoring L4-L7 service functions. Should make it clear that those parameters are more for L2/L3 devices. Since your section 3 is to "describes requirements and applicability for s= uch information, and for directing traffic through a service chain", it is be b= eneficial to show a figure to differentiate network layer nodes from other = service functions (e.g. FW, DPI, or so called L4-L7 service functions). To = make it easier for the targeted description. For example, you can use the figure I have in https://datatracker.ietf.org/= doc/draft-dunbar-sfc-legacy-l4-l7-chain-architecture/ [cid:image001.png@01CF64A0.85162640] Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nabil, et al,

 

Do you assume network nodes as service nodes in the = context of Service Chaining?

In the same level as today’s middle boxes (a.k= .a. L4-L7 service nodes)?

 

For example, if a data flow needs to traverse throug= h nodes: CE1, FW1, PE1, P1, PE2, FW2, CE2, then service chain is: CE1 ->= FW ->  PE1 -> P1 -> PE2-> FW2-> CE2. Correct?

 

There are protocols (e.g. IGP/BGP) to discover netwo= rk layer nodes, but many of today’s L4-L7 service functions (so calle= d middle boxes) don’t participate in the routing protocols for topolo= gy discovery.

Therefore, Section 3.1= (Service topology) should differentiate the two cases. The attributes you = listed in Section 3.1 for “Service Node” are more applicable to= L4-L7 service nodes.

 

Page 7, you also liste= d additional attributes (many of them are for TE based routing), mixed with= MAC/FIB database size, etc. They are more for L2/L3 device.

 

 

Section 3.2.  (Mo= nitoring Information)

Many of today’s = L4-L7 service functions are monitored by their own monitoring systems. Moni= toring FW is very different than monitoring DPI, or Video optimization func= tion.

 

The parameters you lis= ted in Section 3.2 are more for monitoring routers, less for monitoring L4-= L7 service functions.

 

Should make it clear t= hat those parameters are more for L2/L3 devices.

 

 

Since your section 3 i= s to  “desc= ribes requirements and applicability for such

information, and for directing traffic throu= gh a service chain”, it is be beneficial to show a figure to differentiate network layer = nodes from other service functions (e.g. FW, DPI, or so called L4-L7 servic= e functions). To make it easier for the targeted description.

For example, you can u= se the figure I have in https://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-l4-l7-chain-archit= ecture/

 

 

 

 

Linda

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_-- --_004_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=19709; creation-date="Wed, 30 Apr 2014 23:18:01 GMT"; modification-date="Wed, 30 Apr 2014 23:18:01 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZAAAAEUCAYAAAAFnmACAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAEx9SURBVHja 7Z1nuFRFtr/v9/v1PvfD/eKMdxyzIhgB04iCigKKggRBBUWQoEQDAoqIggIGEMRElhwlKCACioBK FFQUR8xgxHzHqf//LWf1VO/Th9PsDqd39+99nn7g1Nln9961q9ZvVe1aq/7DOXfe//8M1kcfffTR R5/D+fzHv/4jhBBCHBYSECGEELGQgAghhIiFBEQIIUQsJCBCCCFiIQERQggRCwmIEEKIWEhAhBBC xEICIoQQIhYSEOF5+eWX3TPPPKOKCBg9erTbuXNnWd/jc88951avXl1xz/b77793w4YNcz/88IMa eg5IQIQHQ9KzZ8/Uz7///rvbs2ePmzVrlnvnnXcqsk7atGnjhbWcue2229yzzz6b+vnHH3/0zxzj euDAgVT5Z5995hYtWuTWr19fFvfNvTVt2tR9/fXXqbIPP/zQjRgxws2YMUMGIUskIMIzdepU17dv 39TPX331lRs/fry7+OKL3WOPPVaRdXLddde5tWvX+v+///77btWqVe6bb77xHvu7775bFvc4YMAA N2XKlNTPPPNBgwa5BQsWuLvvvtt9++237h//+IebNm2a69Chg7vxxhvL4r5p31deeaV/noBwduvW zYvnI4884iZPnux+/vln9+abb7rt27e7v//9727v3r2+HYh/IwERnqiAGHhkDz30UEXWSSggGzdu dP/7v//revTo4Q0M/27ZsiXx9xgVELxwpnegefPm3ngaK1ascJ07dy6LZxsVkP/7v/9LOQWvvvqq 69ixozt48KA/hmeNuAwePNj16dNHIhIgARGe6gTkwQcfdKNGjYp9XqYImPqYP3++9+DxZmHNmjW+ DE/3iy++8GVMm4XlX375pS/ftWuXL+MTGrSwfMeOHXmvk1BAoFOnTt5DBYzJhAkTEv/cowJizJ07 102cONEbVmP58uXupptuyvs1IMT2HM2IM2VmZevWrUsd++mnn6bKw+m0Tz75JGN5dUQFxPjuu++8 07Rhwwb/c+/evd2yZcvcHXfc4RYvXuxHZXyH+AMJiPBUJyB42+PGjYt93o8//tjdf//97t577/XT I2aQeGFP2X333Zfy6BCXp59+OlX+wQcf+HLeQ1DGBy/YCMtffPHFvNdJVEC6dOnitm3b5v/POwKm OZJOJgGhLikLxQOoi+7du+f9Gl544YXUc8T7B967WRn1/M9//tOX7969O1UeXjfORKby6sgkIEzX IZqbNm1KlfXq1cs7NTgM/Dtw4EAvJOIPJCDCExWQX375xa1cudJdddVV7pprrvH///XXXyuqTkIB QcxOP/10L6Z4x5dffrmfzkn6Kp6ogOAwNGrUyL9IxsDaAgqm8Di2fv36buHChVU896QRFRBGHvzM ogKe8S233OLLcRpwdpi6YrEBv6/Ud4KZkIAIT1RAMIxPPvmke+CBB/yH///0008VVSehgLzxxht+ aoOXye+9954bOXKkfzeUdEMaFRBGeDxvRo0PP/xwSiDnzZvny5jSpB6YSkoyUQHhfccTTzzh74/R r40yeP4smmBajBEv/4aj4EpHAiI8eFe8LBT/hpFXuS/jvfXWWysy/odlvJdccknaMl5x+EhAhIf5 3TAeQDj36KOPln0g4aRJk8peJDPBSjNGWgokzA0JiPCwAoqP+De81LeXt3ru5QXP1VYEivhIQIQQ QsRCAiKEECIWEhAhhBCxkIAkCGIzCKqKBnjlg61bt/qArkLAks9CJagjut2ihvMNUefkQMo3LB1l OXAhIBDvcF6KE2VdiJQstFGWB5NPKt98/vnn7vnnn8/pHMQ0FaovHQ7UD/WU1PdQEpCEwDp1VgQR 5EW6B8tXRAcg5QfpQFiaaC99WZ5IGR+ExwjL6UQcz5p4VhwRGBcezwoVO9a+r7ry3377LVUWvY6l S5e6yy67zP8uXwbFvo/ALqKP+U46YXgd3JddR3Xl/D+sD+vU/HzFFVf4+AeOMcLjOac9Gyvj/+Ez s3Jb7UPAGrEEJKlEWPO1CogXwtQBEdP9+vVLuz6eUfQ6uFd+JlCO4EGrEyvnEy5xpU1Eyzme76SM NmjGmO8jVuaiiy7yKWbCtpMrRIsTh0EgJ99LEsTo9VlsB+0h0/XxDIhcpy8RKGnPjHI7h523unJr I+H3VVfOdezfvz91HfbynvNSP9QTgapJXBEmAUkIM2fOdG3btnVHHHGEa9++vV9+CR999JFP9HbD DTe4O++8MxXsR0AUZXzMw6TDs3TRyhEkOtWQIUPcueee60444QRfbuk6CKayY0OPmUjkaDmZSm++ +WZfRr4gM8YEn9HZSUTI7yxVRa5goDB+devWdWeddZa7/fbbfQckGSD5mvgu7svEENENy7lvOjbi QxlZZkmTAURdU3bUUUe5Sy+91B/DsXR8/taOt7xNjFSsPubMmZO6xrDc8ieRqqVly5buz3/+s7v+ +uu9QOUDDBNBgWeeeaY79dRTfd1YKpjp06enroNnB+QUI7fXSSed5J89GXgRHAyrHTt8+PCUZ0yb sHLakBnLu+66y5d17drV1z3g2dNG//SnP/k2m6/RJ9cyduxY16xZs1R7YgQFBHra9RHkCbQH2gVl pGAhrQ4Q99KuXTvfl/jXnhnldo4wNQ7PLFpubYRPmCsuLGc/GRMKRJ0yYq0YQQHBuWwZQD1de+21 Pv+bBEQUDDw/PPnQy80XDKMJKisEmzdvdldffXVBzo3HzeipEGBcwlxY+YJ9VhjdFAKM2dChQ7M+ nhQdhcjphfHG0Iejt3zx1ltvuVatWuV0DkYy9KV8jo7iwAiJeirEVF8xkIAkCEsvUojGRgK5fHnD UXiPUKggRabHXnnllYKcm1FeIVJ3M52BV1uIGBPSbhxOqg28XrzmfMPIj8SEhXB29u3b5zdAywWm ogrVlw4H6od6SmqeOQmIEEKIWEhAhBBCxEICIoQQIhYSkATByiFWHyUthw/vbgq1DSg70dmOhkmB eXdepBfiHQgrfEoh1TptlLZqS4nzCe8vymVbWeoniX3akIAkCFZssOyPZYHZwAoTVm5Z4+SFHWvT Wc7Ii8hwPT8vPTkujBkxQ5CrobMlloWApabsdBiFF9UYGrt2Vt1Qf9w3omPLnRFlOjGfYgWVIR4d OnQoiNFgmastYw1BtKgTM+iIOm2BuqBOwtVStAGWzPJv+Oz520x7wmS6D9oeq9j4znzDsnSWIGf6 Tp5xGGdBG+f++Fi/4d54aW33GEJ5IUSvOlh+TT0lNSuwBCRB0BmbN2/ujWFNsLKGuBDiFlhjjoEg 0py4CTZKIk6A+Aki0DEurE/H0NtSXho0cQzEOyxZsiSn6+Za2FujEHB/4TJe7oVlqexhzb2wzBe4 37PPPtvfD/VBfALMnj3b723Oihw21SoGBK+x02MhBITYAzZECiE+gzJrC6+99ppfuXbKKaf4n6mb 888/P7WXOHFFGFz+xSAbrHhjS9fwvGw6RYwFx4dgrFmqbPva5xPaKY5UCNkI2BCNZckExCIciCkx Mfxs90jfIX6H9kHcD4GoISyBthirYmABqxIQUXAQEHZRq0lA8CrxcJnOoCOz3h2jRSMN4zEI/CMQ i4Czpk2b+vQQCBSeHB/2CKHzYSRygSXCeFmFgCC/xx9/PPUznR/RwItkWbIJBQJBUKMZPuIIGKGw q2D//v19wBkBchh1jhszZoyvD8Qp37EMGLDWrVsXRECIKrf7BLxsnjMBnHwfI0EL7KMt2aiLOkB4 aTNNmjTxBpkI6bffftv/HmeicePGKUG2emTJMMdH06HQ7hDJQgjIm2++6QMVDbYYJlCPoFpG2QSu 8n+CJcORL04Mdf/SSy/5+qftW3tnpMVolsBK26GRERp1yRa2tAWCeQmczedIFQGhniQgouBkKyDM DyMIYYoFjAd/d8EFF/gtSfHg6GB0NIzHscce6zvV0Ucf7TuYgUebJAHhWhl5Gba+nrgB7q9Xr17e KBCbgifboEEDXyeMTjCE1BmxEex/zsiJukFk8kkxBQRjR5sJYz2YtuGDY4FoYkQJzqMtUJ/HH3+8 r5czzjgjNT2IkWakRsR5FJ4tRj2kmAKCc8RIyt6FUa98SBPyt7/9zY8qEFHeNdA3cIrIusD9IxiW O4zfMWpla1vACeF7qCOyGNC2evfu7datW5e3e5GAiKKRrYCY98088S233OK9cgwJntZ5553nU43Q ecyAMZ2BoGBk8N7CdyykRAlTNcShWAKCF8kLZASSkQdTMBhGoA6YKiB9CL+3ekIgMIx4nxgaBOf1 119PzbE/9dRTadM2+aCYAsJ3YPBoB0zjME1n73xwMmgLCCieO6MV3o9hNDGYw4YNS7tGElcyBRiF tmP1bBRTQLgXRB+RYDqNFDzcC6l6cAx4xkzbhveB4OBUcJ9h3ivaezglyhQXAsPIi7+jLcydOzdv 9yIBEUUjWwGh4/PegvlrchshFnQ6XoDa3DENlk6GsOCxH3fccd7rxmNjqG7gdeWaKqRYAmLJFRER DCHR7/buhTxH9nLZoqMx5PXr1/fz5HiiGBVyejEdY1MfRAnzHfmkmAJCHiyeH+8EbM7f8pExnUkb 4L0R18LU54UXXujrhBEIH8uLBkS5I0JRaFOWR8wopoCQboZcXrR3nh1OENOOCAgCAZayhL7TsWNH d/LJJ3sBPfHEE70wGAhIuCgD4V25cqXP+cW/vDtZtGhR3u5FAiKKRrYCwstS5vTvueceP/3C/DVG E8+MoTudIVxpQqfDs6Sz2fQVHY4XryTa4+Uj/4/byIslINQP38P7C+6fqQheDGMkGVFgGKMJ6xh1 MG1hHiqCipHlBTMGCK+2YcOGfvojXxRTQHjfwbNFPLlXFg1g3EkKaG0hXFnFSAzRDN8ZMbIj9QpT XfXq1fP1w5QWU0dMaSG+3A/nNoopIAgiIoazwwiBhJE8c4QToYg6QIwgeNnOyNsEkT7FKOOcc85J TfNyDoSJl/HU3bhx43x7y7TKLS4SEFE0MJAtWrSoUUCYhqFB8nI8XB2DV4ZnTnlovPC6MRgYCZuK 4PeU86KUD/+Pa/CYGouumskXiCUvOc3Q4U3jbWOkrZ4ox+Dx3iNq0DAmvDzG67Qly7bMmTrkpTJ/ F05z5AqGF++/EAKCeIarsBBEBIL7Cfc2sbbAsw1fCmN8cSL4WAZhYHTCOwLOQ93SxqgTRh6cB4EN 43EQEJydQq3CssUR1la5Ft7h8DH4bq43LLP2yItyHASmKK2euD/qyNo9bYHz8l7Mlj3zb5jmPleo M+pJAiIKTrYjkFKjmC/Rk0AxRyC1RTFHIElGIxBRNFg5wxr+YgY65QM8tkJkfAWWmRKYlySYTmSZ bCEi0RkJ8N6rtqGN0lajgXr5gJFAodpTbfXp2t4ZMS4SECGEELGQgCQIPC+WJBZij4VCwiiB5aKF gDlsFgkkCebkWflWiH2wCXjLda+MfGC7AebzfYHBexdebpcD1A/1lClFTBKQgCQI5pNZkhsGCCYB 4ioKtSMhwsSL4yTBS3RiUgrxDoSVSPledhwH3tOx014hEl2yw2WuOxKWCizSoJ70DkQUHL1Er4pe oqejl+jJQi/RRdGQgFRFApKOBCRZSEBE0ZCAVEUCko4EJFlIQETRkIBURQKSjgQkWUhARNGQgFRF ApKOBCRZSEBE0ZCAVEUCko4EJFlIQETRoDNeeumliVvGS9R1y5YtC3JukuexZ0mSII6BxISFEBCS Z5IfrLbByWHJeaGW8WJ0ywGW8VJPSYvtMiQgCYJGxt4VSQs6IjEd6dQLAdv0snNiksCoEgBZiEBC Uq6z015tQxslQaelUc8nBGKSqr8coH6oJ9v4LGlIQIQQQsRCAiKEECIWEhAhhBCxkIAIIYSIhQQk QbBqh531CvHylZd5LBMuBOwSyGqTQsDOeoVa1szL7kIsWGCvDJ5jIfYDYYVerhlweaGb6/OijXKP hVhpxh4auV5fPvpSPtp1Ift0MZCAJIyePXsW5LxsYTpq1KiCnJtVWKShLwTs3z1nzpyCnJv9wsmc m28w8r179y7INc+cOTPnFUoIZ79+/XK+ll69ehVEJNlCd8CAAbXel9gamrT8uYBwUE9JRQKSEF55 5RV3zz33uGOOOcbveY3BB2JD2BOcNN4YDlsOiCGhjA97PQOdOSxn/2c8IPaHvuaaa1zDhg19OR0D iN+wY1etWpW6lkzleFEEsVHGfhS2w9qMGTN8Rz3xxBP979gbJB+wRzff16hRI58Om/3czSMkvTvf xX3Z7o0YnbDc9j+fOnWqLyOWxPaPRzQoq1Onjuvatas/ho7Oh7/ld5yLc9qzsfpYt25d2jOz8ldf fdWXLV++3Bu/448/3o0cOdKtX78+L/WBKLE0mJiCxo0b+7rhmQBLe+06eHYGz87KSbkPLIvu06dP 6nnZ8bQJO5Y9R4C2Rpuj7NFHH03FfKxcudINGzbMHXvssb7Nvvzyy3m5R57XokWL3K233upOOukk /73EhAA7Mdr1zZ4925fRHmgXlBFsaiPsFStW+ABU+tLQoUNTz4xyOwfBigbPzMq3bNniy9gvvnv3 7r6NUP7WW2/5cmJ87Nh58+b5MvZVx9GhbOzYsakR4tKlS33MDvVE8Ke1EQmIyDtvvPGGb3x169Z1 48ePT3VsGiNGevLkyW7BggUpg0lnoIyPGUY6YFj+6aefeqO4ZMkS16VLF9ekSRNfboZx+/btqWPD LUS3bdtWpfzAgQNu+vTpvoxObgJCTAKd5IwzzvC/MzHLFYRz2rRprkWLFj4qmQ7N1AZTWpTzXdyX XQfGLSznvqkPDCZliIRNRzBioqxBgwbew+QYExD+1o43g4mxsfowQxItN8ODkRgxYoQ77bTTvNBa ea4wBYnBatu2rQ/a5F7NYJIJwK6DZ2fw7KycZw1r1671xsyel5XTJuxYDCrQ1hYuXOjLePbUPSBG xCvVq1fPG24z8vkQEGJ+MP5nnnmm/96dO3f63+EM2fWZc0V7oF1QhuhZAC5byI4bN873pSeeeCL1 zCi3c4TbAvPMrNxGpIgym1rVr1/flyMcYdvhY84VQjZ37lxfhgNHlD4gXDh/1BMCs3XrVgmIKBwY w+uuu64g5168eLH3xgoB3iGefCFgJMCooBAwcjIDmk8QvxtvvLEg18yIAEcjFxCLm2++Oedruf76 61MOTT5hNNStW7eczoEzkGtfQmR69OiR0zkYxVFPSUUCkiAQEDz4QryYxHu0kUe+YQi/d+/egpyb aZpC5FsCvMlCpJjAM8YIFuL9AKOiXF/s4jHn+rxoo7RVGwGWWnvKR18ifxVtJB/XoZfoQgghKgoJ iBBCiFhIQIQQQsRCAiKEECIWEhAhhBCxkIAIIYSIhQRECCFELCQgwkM0O8FtSd0ZLd+wPp/gx0mT JlXcvRNB36pVK7/zX7lCdD73aFka4kAkeZs2bQqybW9SkICIVIeyHFHij7QZpAOxHFGVBMLBNquW +kP3mJk9e/b4FCRJ3c88H0hAhIdcPSSp0wjkDxiB9O3b14/MKg1yMt1www0Fy0xQCjDKyvUeyUfX uXPngmVCSAISEJHqDM8884xGIP+CEQjJDpOYITVXSExIEsRc9xUpZUhBkus9vvvuuz4po0YgQggh xGEiARFCCBELCYgQQohYSECEEELEQgIihBAiFhIQIYQQsZCACCGEiIUERHjWr1/vJkyYUJA9rJMI 8TBPPfWUW7NmTcXdO9vtjh492u3fv79s75Eocu7xwIEDsc/BnuiPPPKI+/bbbyu2n0hAhGfhwoVu wIABEpB/wR7Vd955p4/QrzR27NjhunXr5vebL1e2b9/uc53lco+k/+nevbv76quvKrafSECEh4hr 8vqQwkP8MQIhMv+VV16puHvfu3ev96xz8c5Lnffffz/ne9y9e7d77LHHNAKRuRCzZs3yXqdGIH/A CKRHjx4+oWKlsWXLFteuXbuyz4XFPX7yySexz4HT1aFDh7Ke6qsJCYgQQohYSECEEELEQgIihBAi FhIQIYQQsZCAiIywTScrVSoF9v94++233S+//KKHH4FlqmwylWTYu6Oct+itLSQgIiNsKjR48OCy 3lQoZPPmze6BBx5wP//8sx5+hE8//dTHxCQ13oGl6UOHDnVvvPGGHmaekYCIahk2bJhbuXJl2d8n o4+RI0dWZNBgtrDz3vz58xN57Rs3bnRDhgxRjFMBkICIannnnXf8KAQDW84w2rrrrrs0fXUISG8y cOBA9+OPPybu2u+//363du1aPcQCIAER1WJDfzy4cmbSpElu6tSpeuA1MGjQIJ8zLUngHPTt2zeR wpcEJCDikLz00ks+5UO5cvDgQT/6KOeo63xB5PXtt9+eqGsmYeKUKVP08AqEBEQcEqZ18OCYwihH 5s2b5x566CE96CzbwoMPPuinNpPAN9984+65556c0pWIQyMBETUyY8aMshyFkASvf//+btu2bXrI WbJkyRLfFkg2WerMnDnTPfnkk3poBUQCImrkyy+/dM8++2zZ3RexLuV4X4Xk+++/d8uWLXO//vpr yV8rKwg1NVlYJCBCCCFiIQERQggRCwmIEEKIWEhAhBBCxKIkBITd33766Sc9jTxDXqdCpW9gSWcS XqRmA21PaS5yq78krMoq1b6UZEpCQFjZwXptkV8effTRgmVRnT17tlu4cGFZ1BN5sPbs2aMGExNy ppFwsZwZO3askjFmoNYFZMOGDT5RW926dX0yO+vIRAi/8MILPoHb8uXLU1lSX3vtNV/GZ9++fanz ZConHbmVhQ8/Uzkixhp3ylasWJHKixQtN6+bqFw7RxioRKqHbMvfe++9VNlbb72VOjZTOTELixcv 9mVEh9t1RMsZzbHsFuP+t7/9zd1xxx1px+cK2XkXLVrkrrnmGnfttdem6uq7777z5VwHyydtb3U7 nvJVq1alPNU1a9b4sgULFvjrBa49U/muXbtS9bF9+/bUtYTlO3bs8GVkjOXeKVu9enXq+w4cOJBW Dhg9fm7YsKFP2RIeL2rmww8/9PV3+umnexG2fFN46rQ5fsezJ6AP2Gvdnhfp1Y1M5Z999lmqbN26 dalj7ZnxCdOq0Kei5bT5F1980ZfRh2mjQHsNy+njwD7pdg6zQ3beCy+80PXr18+3T2vbogQE5Pnn n3e33XabO/bYY/0oBEExQ0CE8L333usDlxAUIKiNMj5mNKor37RpU6oMg2SQ2ylavn//fjdixAhf 9thjj7kffvjBl2PEwnLLqTNt2rTUOdhHwiCnkpVj4AzSKUTLET0rQwRCMbRyGjh8/vnnPgqYMrwh m/Kjo5GGnHKEGAO4d+9e7xWedtpprn379r48X1OEdKjhw4f7DnXxxRf7UQ51RT1RznU88cQTKQFm HT7J7CgfP358ahrgmWee8WX33Xdfat8Rrv3pp59OlVv0+8svv5yqDwTLCMsxCMCeD9w7ZQSRWWcn J1JYDrt37/bCUadOHXfDDTekHS9qBueG+jzhhBNc165dfU4xM9C0OX5H26SNAg6hPa/Q+IflOGZA tLuVTZ48OZXQk2dm5WGKEvpUtJw2//jjj/sy+jBxP0B7pS9bOX0fcDDsHK+//rovo2/z8xlnnOHa tGnj261S/peQgAAeCg9H5Jdbb721YFlIEfUJEyaURT116dIl8Rsm1SYdOnTwTks5QzqfStja4HAp CQHBI8DzKPe04cWGIbl5f/kGTzCchkgyjFTNCxWHD7MGTKWWM4y2lFOrKlrGK4QQIhYSECGEELGQ gAghhIhFSQgI86cs99M7kPzCUspCvdxkJVu5rItnmbiytsaHlYK25LpcYQm6YoWqUhICwjLOZs2a +TiAbGAtNi/uiPfgobIE1tZyZwtr2G35aLnSuXPntOXB+YRltqz9zwb222D5LUszWcbLC/ilS5f6 /RpYxo0BZ+knL7NZ0kkZvyvWwgqWOtOmRDxatmzpF2xkA8tiWX7NsluWw7K0lmc+Z84c/9xxJHEo iYWijcyaNSvVRmozW8XNN9/s49REOiUhIKz3pxHWJCDECRBLcOedd/olpI0bN/Zrz8855xzvBdHw LP4AMD4ED1kAkcFxbM05atQo/zPfa8FO/H25rCih0VscSb4h5sPq71CwdwTPi2MJ2CNojOWQf/3r X70IsRz4xBNP9CMa4keOO+44vzZ/zJgxPo6F+I1Cc91117lXXnlF1iAmBJWGgbDVgRMxZMgQ/5xp C7QNHDliwHr06OHbAsGv9O3Nmze7o446yg0ePNiXE4dRKGcoG7p37+4DCkU6RRMQDDQeZaZALQTk qquuqlFAmJIhmM4gyhrvFkN00003+caGsSLqmHPhxfJzt27dUg8fUWGf5AYNGvigIGAZcbt27Xws CkF6BEXRuJMO94F3VwgIEKMeDwVR6FyDiTOig4Ag6BhtYOoDo4IBYmTCswICJ3m+xRglXn/99QWL l6kE6Dc1CQiO2RVXXJFaCosoMC0EBHHitNFOEA+CcYFMB0B/pt8Xqi1nAwIXBiMXG+wmmRKsL5UK WQsID5jhJh+LxGRIaWU1ee0cQ+MYOHCg34caI2LTE9kKCAYlfIgWFd6rVy/Xs2dPfz1ERptnjLhg lJgaueiii9KmuRjJhPm3aJyMZJgLJ11G27ZtE9+xa1tAeB4EM5I3y6KAzSAwukC069ev738GMghQ 3qpVKx/pXqwkfYUSELInWP+wTAqk17Aysi1YH4iWA7/j/1Zuzhfl1Fm0nPZtZZZJoRhkIyBcMwGb ZHCI5s1i+hqxOProo/3Ig2lOnj1twMr5m9pM3pmtgNi0HB8z9tg14owow2GyNn045dz7c8895wMa iaLHwSqFtDtZCwgpAfAU+FgaAuaNrYxhaTYgFnifpMEwIcpWQBgxkLIkSu/evf3cKUycONGnp6DD kpoAA9anTx/XpEmTNJFDzBi5GPw9+2Pb9Vx99dWlqQqHQSkICG2FFCIYD6YNGZVgFC+//HI/pcGo 0Ywo8+hMZTL3TfqTYlEoAWH+3vqHzZ8z98+7Kcpop5bahXcDVm7tEmEYNGiQL6P+bDRGvd59991V yqdPn576vmJ6y9kICMYQh462cOONN/p75Z0YMAWGU3nXXXelFjPQfxmx8O4Dx7G204dkKyBMxdoz sP6Bs0weLco4jwX30hesHAc4LEcorByxMPg/TjiOVym8wy3aFBYdBWNGI2EqIzRs2QoIakwD5CUc c6fkvKHSTcBQaQwPDY55dgwDxoqXcKeeeqr/G/PqGH3wcFB6rg1xoiPQUBmxNGrUKOU1JpXaFhDS gzRv3twvduBdBt4kBpTngHcZjf5GUC677LKi56PSFFZuZCMgzArQ32yExf/pl0xt4UyGCROBqa4L LrjA5zYrBWp7Cgu7hV1i4Qr2k5FcKeTkKpqAYOhJioYXEiVbAQE8FDxZPC8S6KH4/C2jkJ07d/py pkD4HioZhWeulQb71FNP+QbLA+AY/g4155xMg1155ZX+fAwRMXxJf2lW2wLCtAOCTqNnFMiyXzoC 9Ur94kyEneDhhx92LVq08M+pmEhAciMbAaEPIiI4gLyXZNECjgJOBs+8U6dOaWLBjABthBFqMafj qqO2BYRRJyNaEq2WUjLHRC7jFdnBNIFN7eWbw1nGW+rwLkbLeOPDtGO575WhZbyZKQkBwfPgAUlA 8gsevq10yTek6y72SKFQMN/MyFPEA++c0X85w7uocCsB8QclISC8gyi15WnlAC/vwriYfMK0gq2C SzosriiX7XlrA/puue+jUsi+lGRKQkBofIxClMokv/AOolALAXgBbstvkw7vwMpFDGsDFkmU+yZL 9KVoQLIoEQFhVQ7z0DVNYTFSYXUGhqsQYsP30xEynZuVIzSisKPgkdgyzFKEhQEsgywEvPBmaTfw PCzNBM4ACyZYiliTUWEdO8Y7F5HjHLm2BaZPbSc8cfiwLL+mDbkYpZgBRqxpM9lkfCC2JZeYB9oG 7TDX6XEWgdRmJHypUjIv0VnzXdNDxjAR10EUeSFST9CoO3bsWGU6jSXBzJOz9j6c62Ur3lKeFyU6 v1CNntVVtgqL1TVHHnmkj+NAZFnXz7LpmubFERtWzzVt2vSwk/EhOiwDZaFArs+AHfWUyiQ+rGis KRcWQXCkLGG1FnnsiGPAwakJluzzkp7treOAgCBwucZMkCGBWBWRTsnkwoou48WzJ6UBaS7wdMPd 7zA6LNG1BkLkOBHoeJIsETVvBSHgZS/Gjr22mefmePY7RhDsRbCdg6R6Z511VlrSNpbu/elPf/KB bwR+4c1wHpYS/+Uvf/ENPISORBwK+2tzHo7lHlguzH1idBkVFGO6rljLeDHmCIjF0RAUZ5H8iAjL NhFb1rEbiDKBmwSGXnLJJanny/USo0PKk0OBN0vdI/gsu84FLePNjWyW8dKf69at69sk8OxxAMD2 OWdln+U+o03RN+lzlNvfMXp59tln/YjA9i2vDs6Fg3H88cfnnG25tpfxliolKSA0NjwOgvtoXIxO SIdh0His8QErjfhghFgtYccyYsBA0bhZZ46wIBR4E2T7ZOUN3ifDZD40SJYTWyoJYPhMGefh/JyD 6+S6EJxwmSzTIIgVwXIs+SNdCtNcxKTgfTHtg+HE2y3GS9tiCQgjQ+qCJIhE+CMgRBsjpog6QWKI B52Q/+PJUU/UC8kwjznmGD8CYbREQCjPiHOx5j2b65CA1C7ZCAiCwEgF54p0JThV9B3S19AucAbo w/ye/kNGCUYtOBKMQGhHwLMmnoxjePaHmjrDgeP8OH8W9R4XCUhmSlJAeKGOV2rwczjFEQoInjx/ z2hiwIAB3pDhzVDOCAaBYMSCx2P5ZfBwKWM6jPQPZsz5lxQm0QhpIt0zdRDOEa4NR6Ro7FwfDe7S Sy/1AsR9MU0TzQFUaIolIDZtxTOykR0BnIi5pb0BRiPUGYaEjm3wM/uW4Cjwf44hOpmMvICwIPp8 SPsdwrO2dzFxkYDkRjYCwoiRUSlOAyNSRo44Uzh5jCgMAg3pR/Rlg1kF2gQr/84991zfb/mZ8+GU Ad9vbYREjSEcl+syYwlIZkpSQCxbqzVKvFdetBuIgUWJM5LAYOPt4tmT84rpLEYLTDPhDTP/yRQK goLnQlQ65WT3RTAs0pXv5zqi+w5wLZki6GnIoYHmvHjWfDdeNCMhPC/m+jlvsZOfFUtAEA6EE7hv 3n+0bt3a33+Y04qObQk1LacZz5YpBoSd+mSqkWfNew3OBfwOweFj+YIMzs85c0ECkhvZCAh9yrZs oB/+53/+px91kDGbfspInWPoywgKbYRRPuCU0LfoS6TDoU3TRshEYYsfsBnWRkJbYdcXLTtcJCCZ Kdl3IBhhRgo0HrwMGgCGBPFgbwC8ezxdRgsMazmO6RDmPMm8S9g/jY3f0UBplKwMYtoKLxfjR6Cd pW0nEpm/PeGEE/yIw95t0Gjq1KnjhQZviTl+87RPP/10n7uJqSquHU+ceVs8LK4Zb5npMLwqjCSe Ffm7ikWhBcRGCNwn9UbaCfsdKWUwCExJId68MEXYeQasvuFvqUP+hvpluoL6YzRhe7Ug9tXBORh9 nH322T5nEulp4m44JAHJjWwEhFEkbYR+h7EnTQkOHzMFvC9kvw1GrTYlzNQVYsKU1i233OJHHrQP BIJ3IrQR2tOh3pXxO/oA+80wCsklNZEEJDMlIyDkoYquwqKhISS2VJYpJuYyERN2IrTcOXj2jERs WSDTIRb4g8fKOWyainPxIo6162HuHQwbBoty/uVnQCw4jnPwHVyjXQcv6bgO/sZeitu1hC/tuF47 bzGnsTDihdpQCs/f0uYjktwfIz2rh3AJL8+XOglhVEadMvrjYyMLvEw8z5qW9vIc+T6eNefnE3ep JtMpWoUVH0abNa3CsjYS9tkw+ND6SAirInmutnzfAvnom7SRmnYh5ffMNHBe+mu4pcDhgohpQ6mq lOwIRORObSdTTAoageRGNiOQpKMRSGZKQkDwNunAikTPL0zX2Q5w+YaXkjZHnXSIS8jFO610WChh I/ZyhZVjuS4FLkdKQkCEEEIkDwmIEEKIWEhAhBBCxKJk0rmXS2bXUoJ56bhLW2uCVW41rYLJJ6zU yib5XhxYIaRU3fGh7xYzHT7flau9YMEOIQDZLtwpZF9KMiUhIBgiYgJEfiE2oqbllXEhGIxYm2JB /jDibQoBaTXCXGvi8CAmo1CLNTLBy2xiuHKFaPZsYfdNbTpWlVoXkKVLl/qAQQLtCCKzwCC8TXJh ESxI7hvbr4FlqZTxCWMLMpUTyWxlpE0wiCq3ctuxDw+DKGjKMI7mbeCdhuUW30BglJ0jzPRJIFS2 5dyrlYVJGTOV43GRH4gy0q/YdeBFheV4VHQwjC2JIckhRHm+PGxWKxH4RWoW9rImMJK6op4o5zpI M2MeKalciBS3covpIQUMZQQa2vp/rj0sJ2aGWAGi1lkq2qhRI19uq2Ho0FZPFpFMPIl9HwJnsQac KywHS4FD5DxR8JSXcnr+UoO4Jurv5JNP9qlHLE6CZ0+b43e0TUsNRLCuPa/QsQnLbTkw8T1WtnDh wtSxOBJ81ymnnOJ/Z/aCPmXHWzAibZ4+a0lTLcfd6tWrfa614447zufcs6SMlNs5LPMEcV78TAZw Ao1pnxqtlpCA0CCILCUaGaNnDw4BIbKcTk/mXRMQIscp48PDNTKVE7VqZTQOI1M5mXuJVqeMxm8C grCE5Wa4ESw7B4bIIHAv23ISwVlZGMiWqRwBQVApwxDbdYTlpIXACOMN0nGJ0iYAivJ8NXoCKxFU IomJ3eHZmIBQznVgiE1AEBw6L+WkNjEDjbGhDNExQeDaw3LEgOO5frIKkKYmPJ40KFZPLMU1wbLv I0Levo9zWbnlL8NI8fOZZ57po54pl4BkD8u4qb969er5EYEZbp49z4zf0TZNQFiqb88rjBsJy00Q CCy0snBLAtKXkOnhtNNO87+zZIr0KTvegmdp8zgflNGHTUAQLIJgET5imWxkQbmdw9LoIEz8fN55 56WyfWv3yhISEDPeRAOL/EJqiDCZYT4ZO3ZsUfdERwwIXiwEBImZwRCHD545YlwsEAuyLOQCMWc4 JdlCSpXQCRV/UBICgqfAcFiBhPkF76lQAV6MAoo5783IwvaKyDdMeWq70viQJsQSkhYDvivXd1aM NLE52Y446UvhNg/iD7SMVwghRCwkIEIIIWIhARFCCBELCUiCsdTylQBLLQuVWViUNrwb1cqn0kQC kmBY6swuf5UQIcvyXVaVicqDZb4s3xWlhwQkwbApDzsfEktT7hBPwPp/UXlt3LagFqWHBCThEJD1 4IMPln0AHAKSj/QVIlkQSEvQn5b4lyYSkIRDx2Kf+DfeeKOs71MCUpltm62T161bp8ooUSQgZcBL L73k08GUMxKQyoNpK565XqCXLhKQMoAoajKikjCwXJGAVB6PPvpoWiJFUXpIQMqEefPm+YRx5YoE pLIgaScZkst9r/WkIwEpE8gVxYqsQm26VNtoGW9lgTP03HPPqSJKHAlIGYG3ZvtflBsLFizw+8WI yoBtCoq546WIhwREJAL2PylmxlchRM1IQIQQQsRCAlKGEL1bbulN2LJWK3LKH9t5VCQDCUgZwg6P vFAvp854OC/RP/roIzd58mSffNG2PGU7YrYvJWqf/bBt+1WmxtiCl/NzrG2pGoVYBLbvHTNmjD8H 0dGllF6D++DFM9eV7WZLbPObCVZArVixouj3QDBsMXe5FLkjASlDGIFgSMope222ubDYZe7uu+/2 e2Hfdttt7rLLLvPlLAlt3LixX+7MHtfsF8/KNZJREm/Afu3sed2iRYuM5yVVDKJ86qmn+mM7derk Y2/YlRHBIhaHXeuisG84270ePHgwdR6OR6x4TnYMe8ez4x0CFgbOkXGZY/kbzsH3sQMgsJPnjh07 /Lsh/oacaK1atXLDhg1L/T3R3Pzdzp07/VawBnuOs6c9QrF582bvdACiQp00bdq0yr1wHXxfeG/8 HbtTUpe5QtS5to1NFhKQMmXbtm1u+PDhZRPFm20cyNChQ/0IAzDKthR00qRJ7qGHHvJGmvxK7OnO OREag7xi9reZ2LRpk+vevbv//6BBg7wYLVu2zJ111llu5MiRfoSEGAH1ziiIvbT79OmT2sN7w4YN PmsA4jNkyBA/SuQ5nXDCCd7wU8417N+/31/rvffe6+/psccec23btnVz5851devW9WLFMRdccIH/ ncFIKsxKwDHjx4/35+jVq5cfbQHCccQRR3gh7N27d0oYVq1a5dq3b+9at26dOgcBqhh3jkOUGYUx SuH/l19+uRdk7o/6iQujpsGDB5ftKsJyRQJSxgwYMMB7l+VAtgKycuVKP5JYvHix2759e6p86tSp rn79+q5evXqub9++vqxHjx7eoIfg8VfHm2++6U455RR3ySWXuPPPPz9VzqiF3zHSsBEPwsVICBg9 IDiAx86xXBvGn2kwRi8NGjTwe7PD008/7UUBo4qB5tj169d7ww2dO3d2r732mv8/Uz6IjMHoAWNv MAJh9MF3UgfNmjVL3ec111yTcZqT60WsDMTxiSeeSP3MFB7CyzlbtmzpR1V8Z/i9hwv39vzzz6vT JgwJSBnDdEBoXJJMNgKCMcQLxrginh06dPDePTACwePHEDNqAAz1nDlzsr4GNrXCY8f7ZyTAHhUI wrXXXusDOJnGadOmjT8WwWAa0WBEwnsK3r1g5Pn9eeed50WDKSCmk4w1a9b46TpiIRg1MYpB9Lh/ pq3atWuXelfDucJRE4Yeg28wsmCEwPluueWW1PVxLYhJpkjvPXv2+LozSKceTl0h0oyWNm7c6Ec1 dh0mcIcL988ojRGXSBYSkDKGQCwMBx006WQjILwf4N0GBg4jSPAhhhcvnNEA0zJM6RhMcSEqM2fO 9KLDlBNTONXB7xl5MNXF58wzz/Tf1bBhQ/9+APE6/fTT3b59+/zIAsPPVNH8+fP9SAGB4Xr4m6VL l7o6der4lWW8d2AKa+LEiX7zJMQFg42B5r0N7xr4G6bImOJBFBEWpuL4fbdu3byQMdLo2rWr69ix o5/CZGTAVB1TT4geQsM1c32MQBC+KVOmeFFjkQHvUng3wn0yWkMwOS/JOhmt8X38HyHi/AhTkyZN vHgiJDfeeGOsWB3qJxRbkRwkIGUO8/TlsLIl2xEIUyvM82O8MYx47BhLDC5GzlZfGRhIVi9xbhYd 2MvuTPAugXMw92/vAjB+lGHgGZHwf8QBMMZM6zAq4D0CQoYh530E38X38s4EsePlN2LC72x0geAw ckIEOI+96MYxYEUZ5XwngoN4MArg+/kgFhhzRISpK0YliNI999yTGoExVcV5uQaulevjflhwwDkQ O84LlhmX9yv8HSMqhIyRA1NtfB//R5wOB+qbdx9///vf1VkTiASkzMHLxtAlPUcW3m655sJCTHgR X90S4nKGUQ5TiSKZSEAqAF7SJn3HQl6KMwIoRxih4PXz3oYX8ZUEo6RyC3qtJCQgQgghYiEBEYmA OfJSivwWQkhAKgqWsGab5qLUYJ48m0h0kQxY0aUX58lHAlJBrFu3zg0cODCR146AsLJKJB9SqrCK TbsNJh8JSAVB8BjLOJM4CtGWtuUDsSfabbA8kIBUGKxmsnxNSUICUh6w6qp///5+eblIPhKQCoNp A6aCCGxLEhKQ8oBgSW1NXD5IQCoQpg8sK2tSkIAkH7ICEGlPGhhRHkhAKhBSUZCqIknBhRKQ5MOG UaSrF+WDBKRCYXOkJI1CyOcl45NsWIbNSkBRPkhAKhRSZliivCTAyh2mP0RyYV97pS0pLyQgIhGw akeBZ0KUFhIQIYQQsZCACCGEiIUERAghRCwkIEIIIWIhARFCCBELCYgQQohYSEDyzK+//uqz3f72 229p5WTCffPNN7NOYb1r1y6f9jrkxx9/9NG80f3NP/vsM7d161b3j3/8I62cDZg+/PDDtDLW4XMd 0XN88sknbtu2be7333+v8RzVlZMoj+v7/vvvM547vL5//vOfPg4lujSXe+T62IY35OOPP3bbt2+v cn2ZznHw4EF/Hfxb0zm4jh07drh9+/alHcsxHBstt3NH75Hofs7D+cJzZzoH98Y5qK+azmHXQR2G 8P2ZzkFdZIrv4VlFyzk3zyV6btoGzyAas5HpHDxT2l40txr3yDl4niHEH9G2o9eR6RzffPONPwd9 J5vyTOcm2wJ7zX/++ecZz6G4lNyQgOSZmTNnussuu6xKw8R4NWzY0K1atSqr81x33XVVUne89957 7qyzznIbNmxIK580aZJr3LhxFWPStm1bN2zYsCqdrEGDBlUigtlvvGnTpj5fUUj79u19Cvgo7dq1 c/fee29aGaLC9WHYQp588kl36aWXpp0bo3H11Ve7kSNHph2L+NavX99t3LgxrZwMws2bN09Lv4Kh bdWqlXvggQfSjsVgnHnmmd7whowdO9Y1a9YsTdwxgC1atKiSoZjv4fui5Rh47jGaz2nEiBH+fkLj z7mvvPJKN3r06LRjN23a5M+xe/futPJRo0a5li1bpgkcDgntacKECVXukXNwPSE87zZt2lR5XgRh 0h5CqIfLL7/cjRs3Lq2cgD+eQdSBGT58uGvdunXaPSIQTZo0cc8++2zasa+//ro/R3TrgEGDBrmO HTumlSEEl1xyic82ELJ69Wp/DoQ1Wk5figrzkCFDXIcOHdLKENoLL7zQTZ8+Pa187dq1Ge9RHB4S kDxCxyfTbbSzmzHB04t6TdWxf//+KqMVjBrnwKiEIByMQsKODQTfRUcadh1RoaCjRb00+PLLL723 lk05BinT9eG1c31RuL7oSKO6e+S4TNeX6R75W84RHQVWd4+URUcU1ZVXd49cQ6YU5Znu0a4vmous unuk7qKjKbuO6D3yTHg2Uaorz3SPtI1M15fpHmlzma6vunukTUevg3Nkug76CueIjqyrK890j5yb kU3UuaruHsXhIQHJIzRoPPuoQRNClC6IDCMpRCb8ZOvsVTISECFERcPIr1+/fn7aOPw89NBDqpwa kIAIISoeprKYDgw/0SkyURUJiBBCiFhIQPIMK0YmTpyo5YFClDAs92XlWHThiTg8JCB5hqWiV111 lVZ3CFHCvPPOO36pN0vjRXwkIHmEOVPW27NOXQhR2rAr5/z581UROSABiQnBVjQ+PhbJy3D4wIED GhYLkQBYphvGMhGZbn16z549qqAskIBkSXRFxrRp03wkNh8isIUQyWbhwoWpPk0kfQhT0tE0OkIC khWkqWC4K4SoPAgqJK3NjBkzVBkRJCBZNB5yJS1dulSVIUQFwuzDCy+8oBfuGZCA1ADZTVnuF819 JIQQlY4ERAghRCwkIEIIIWIhAakGLcUVQohDIwHJADuvLV68WBUhhKgW0qFEd3OsNCQgGbj//vvd vHnzVBFCiGphp84uXbpUdB1IQCKw6uruu+92X331lSpDCFEtBBCzPW+mXSQrBQlIhKlTp7pnnnlG FSGEqJG33nrLpy+qVCQgAQQNsqf5xx9/rMoQQogakIAELF++3I0ZM0YVIYSIDYHHo0eProh7lYD8 C5KlMfrYtGmTKkMIEZvnnnvOjRo1qiLuVQLyL9auXesGDx6sfZCFECJLJCD/4osvvvDxH0IIIbJD AiKEECIWFSsgX375pfv000/VAoQQeeXrr792H330UUXca8UKyMSJE90DDzyg1l6h2PbDlqafrU2/ /fZbd/DgwaJfyy+//JK2tapINnPnznX9+/eviHutWAF5/PHH/UtzUZlgtHv16uXOO+889/3337vJ kye7evXquUmTJlX7N/v27XOzZs3K+7Xs2LHDXXjhhW7VqlV6MGUAOxf26NGjIu61YgVk3Lhxfu9j UblguP/7v//bTZkyxf989dVXu7179/r/b9y40XuRTz/9tBcbYJn3kUce6W655RY3dOhQP2JhJEvq G4MsBrQrRjLLli3zxz766KN+yhSIEbj55pvdO++8478X4QKcmfHjx7thw4b533/wwQd6QAll5syZ 7tZbb62Ie5WAiIrl9ddfd1dccYWfynz//fddhw4dfBaCbdu2uTvvvNNvYWpG/vfff/cJNtneePv2 7e7dd991v/32mxs+fLg3/iwDX716tReIAQMGeNEgKSfHzp492/Xs2dPnV2Nu/Oyzz/bC8tJLL7mV K1d6gUI4KONv1qxZ43788Uc9oIQiAakAJCBi/fr1rlu3bm7z5s1+tNGuXTv/XgQBaNu2revTp4/r 3r27u+qqq/y7EkYlN910U9o5du7c6UXjtttu88cxNconOgc+YsQI9/zzz/v/I1Qvvvhi2u8RkDp1 6vi/FclGAlIBSEAEI5BOnTr5/zNC+K//+i8/9TRy5Eg/RcU005YtW/xLUUYbGzZs8CMWIGszo5Cf fvrJT33Zp3Xr1v53CIi902C1H0JE4j24/vrr/cgkhNTgpL/A+CxdulQPJ8FIQCoACYhg6gmvH4O9 detWd9FFF/nVUHx4t8FIxPaGIdUNL9vvu+8+/4IUg29pb/r27esefvhht2TJktT+EAgPItS1a1d3 1113uYULF/pypsP4TsTmwQcf9GW7d+92559/vnvttdf8O5hTTz3Vf4+tEBPJQgJSAYwdO9YNGTJE rb2CYWTAO4n9+/f7nxll8K4DSGnDO5BoZmaW/1IeLru19Df8rb1wt/OxZ0SY7tu+k9GLvbAnCzRl nJu/JyMCH7sWkSyYqmREWwloBCKEEHlEI5AKAA8wOg8thBC5wjuwN954oyLuVbmwhBBCxEICIoQQ OcDKvUrdF10CEkAgGAFgQgiRLaS/icb1VAoSkACWZZIb6bPPPlNlCCFqhOwCZBCwlXyVhgQkAnui k5ZCCCFqYtq0aalcapWIBCQCa/rDtfxCCJEJ4ncGDhzoV3RWKhKQLCCxHUNUBXYJIQySXlo2gUpF ApIFBAaxXwPpu4UQAkhRUynxHtUhAcmCL774wmdstZQVQojKhgU3CAjpaioZCYgQQhwmU6dO9fu5 VDoSECGEELGQgAghhIiFBEQIIUQsJCB5hn0ili9f7n7++WdVhhAJgz1aWJ4rskMCkmdIbXD22Wf7 vFpCiGTRr18/v+OkyA4JSAFgt0P2txZCJIfvvvvOdevWzb355puqjCyRgBQA0jvv2bNHFSFECcL+ 9u+8847fUI4thy11ERkn2K6YrYVFdkhAhBAVxffff+8GDx7ss+j27dvX71Mv4iEBKRJsOHPttde6 119/PfY5PvzwQ9euXTu3ZcuWtPIFCxa4Ll26eA8qZMCAAW7ChAlpZR9//LFr3759lWH6rFmz/PD9 119/TSu//fbb3RNPPFHlWigfP358Wtn777/vr2/nzp1p5bNnz/bnDpNUklesT58+7plnnqlyj1zf tm3b0srJetqzZ0/vPRp4ipzjqaeeSjt29+7drm3btt7LDJkxY4Y/Rxg9THaBXr16+cCwEL6HY6Pl eKjc465du9LKn332Wde7d+8079XOPXny5LRjd+zY4c/xwQcfpJWzr8Rtt92WlnON59G9e3f/fEL4 fs7B9YQ8+eSTfh4/Cs+qf//+aWXUA+d+/vnn08rfeust/wz27duXVj5x4kR/7vAef/rpJ9/25s+f n3Ysz49z8DxDmN4lgjuEdtG1a1c3d+7ctPKNGzf6c+Rq4EeMGOFWrFghI1QAJCBFgjxaI0eOzClz JwkdSd4W7ZSI0iOPPFLF+D/99NNu2bJlaWW85KdDYexDSGFP546ma8EwLlmypMq1UP7CCy+klSGS XF/U8Kxfv949/vjjVc6NsVu5cmVa2ZdffumvL3qPLErACEYTWiIeUeOASHIdUcPzyiuvuHHjxqWd A2OIQL788stpx1LOsdFy9orJdI9sKISBjZ4DAV+1alVaOXtmcw5S5IRwXFTwqTOey7p169LKP/nk k4z3uHTpUv/co/CsomJNPXCP1EsIwsYzoK2EUM/Re0SE2IRtw4YNaeU8P87B8wxZvHixF8oQxJr2 8eqrr6aV01c4Bysb48JzYo+fSs9ZVSgkIEKIsgVRQoBFYZCA1BJMSTz00ENpH7xpvLNoOR4lUwVC iKoQdxXtM4899pgfsYdTniL/SEBqCaZumF8PPwsXLvTTRZnKtcmVEJlh+izaZ9iCIZepL5EdEhAh hBCxkIAIIYSIhQRECCFELCQgQgghYiEBEUIIEQsJiBBCiFhIQIQQQsRCAiKEECIWEhAhhBCxkIAI IYSIhQRECCFELCQgQgghYlHRAhLdWyLJhJv8aEvO0noe6huiXKk4AWEDnlatWrmWLVu666+/3l11 1VWp/QJImc4uft99912tXd8PP/zgd87r1KmT3+iopiy8XCub8dx6661+Yx/+hs2lrrvuusP63kWL FvnzZMtzzz3n5syZU+vPkw2O2JGxJrZu3VplEy1jyJAhfn/sfF9XkyZN/A5+X3/9da3XE7v7setf TdsCsKHV5Zdf7m644QbXvHlzv4FWbcHOloMGDSoJu8E2uPRJtsIV/6biBATPis5Bymd2U8MQ3njj jX4XNozwGWeckbY1LDuaYZjZspMU7Bgrtlc1o8WGNfwej5NOet9993lDxbal06dP94JgBgzjHt2C NMqmTZvc0KFD/feyxec999xT7bHsVseudGPGjPFGCgG46KKL/E53GK81a9b4vRFsF0Q6Afdw//33 p+20x5azF1xwgbvzzjtTZbZ7H7sdUkd79+715eyvwM5255xzTmqb1Y8++siNHj3a75pHWbh7HvXK 70hTz2557N1Q0/1TT+zaB2y9i4Hneqhjrp3fU6/sitigQYMq26myu+LDDz/sd78j1TfHUi+XXHKJ r0/S4wO7RPK8/vrXv6a2CUawMf4cww58PAMTceqP7+T+ee60g+gukAapxHkGtIPQm8cgU9/stGdb 7vI9w4YNS4kYz+jee+/1x7IrIO3LrhmoR45nB0juj2sMt+mNQntm/+8jjjiiRjFjl0h2L6QNdezY 0e/ueChoWzhg3FO42yb3TdvjWQD38cADD3hHhX066H/UOX/LcVwXuzrS9nnm3FebNm3clVdeWaXN 05Zo81zn5s2bU8+Nc1IXhxr9UbfsDEp/pF7pIwb1ya6XPN/QieS+EFbaXuvWrVPl/C3tLNw6mfoa NWqUTyfPc4puMy0BKQPYu5qHjDeBEaDBsvUmDx0jY/sI7Nmzx918883eKDIqOP74430HQzw4zo5p 2LCh95Ywlp07d/aGA+NFQ0QwaOQ0VrYsZaOb6H7fIT///HPKYGGIGRFVB+dmn3UDQ0mjptGeeuqp 3nBzT9zvgQMH/LXSwehE7Gluhp7rY2/xUEDoFJxj+PDh3mgyWsNIYQz5O4yLbb+KcWDEQ2fHGDLC e/vtt33HY7/sefPm+X3Bjz76aC+q1YFIYFC4PuqJvc0REp7T3Xff7Y1K06ZNfd1SR1wHe5+HW7Vy rXwn98S5brrpJn8s9UQ5z449vwFvnHM1btzYi78JJAJVt25db6DYM5wNvSjv27evv2eM4Pnnn+89 +uo2LKKuMDaIa8hrr73mjS31xLVjcDCkl156qXvppZf8MTw3nBralG2rSztF2Pg+2g+jA87P9XPP 0e8JYc9zzsMzqmlEYcaXusWYHsoYc33UCcaYNmbPgb+lf/Evz4B7pW1Sr8cee6zfOI37oT/wN7Sb gwcP+rZBvfLMccIQCfZ9N2h7lN1xxx3+nOw3T/+kTrhWRJa2hpBU91xol0ceeaRv/wgRf299l3vh utjUDSFDRGiDOBk8c9oP10OdUO84VjwbRIQtc+kH7GnPtXHvLVq0OORzkYAkFB7yNddc40466STf MMLOg/GzfZzxOMzLBkYueEn8Hu/IoLPjqQOdA6MTnhPjxffhdTZr1swNHDiwxmvEE7/rrrsO6QHS 8JmKi8L18T3mRfHddHLg+uncdFr+NRAWRCSE66YDIWoYLBtNAR2ZjmNg9OxnRJQORP3hhRnt27ev sv92yBVXXOGNHKMqRJh/DQSEva2je2xzDOJsMMLp1q2b92rxNG2kZUKYCUQmvC6MAQJpz5PvsFGC wbnDn6MgWrQl29sdT5znhbAg6hjTc889N7VXN8aTMkY5GC88ckYhPAO+CxE98cQTUyMzfsdxoXHN BCNHnit/RzsI2xPPhvPyCT1xuz+cpkPBOaknjsWY2970V199tTfMPAP6Gj8Do2qEkpFfSP/+/X09 ISbhc8CJCQWEnxlJ2b0yHY2jgAOIMDHCoU5OO+20KnvFh3BOngVw3fQJRrnhXvLUGcLLFJrt4U5b om1z7osvvtg7XNw70+C0OfoHx9NeuBbam0YgZQgNFo+TzopnHoIwWAPFC6ZTAx0fo4yBohPSEQDP idGIDd/xEvm7EISHhr1+/Xr/3sC83UzgOTE9wnsMhtR8qoPvRozMCNFYadx41hgLg9EDnRcjTyfB e+KaGU0ZeOZRYcOYYyQQkLBeAKNtIxDgeq2uevTo4QWLKTXrfFwT3xk1VNG6x+hQTwi3jRS4BgSA OsSDjxq6UBjwQhFqDDZ/g7cKiLEJJnUUGjE8SxNYwCBhAAEvE++dZ2bnAgxjaMCrM1S0McCwcDzn og1hnM8++2wv0FY/TKHyrDjGvoO2ilFlVMbf2OgYAcHbrgmMIMKM4WWqLtwfnCkzHCg+4fQTjgde d02jFdo5bQlngWtDTBA++gkOBuWIFF49IBK8R4jCSIR7xUmw+gJGIdSHQRvGUJuI0jcYVdNeGEVS r5yLew7PE6VDhw7+XMAIH+ePOg8dFpxAzkf7MmFB5GkrtB/aMvdFX2UKlWfE9SIqCBL1gnAeqv9K QBIIHizz5nSqsNNgIOisRx11lPc+aFR0VjoCnZXGdfLJJ/vGwbw3w12GwRhSvB+8URryhRde6D1L jBjzyMB8MMaVc3G8zdtmgg6Ap0mHwqCEI51M7Nq1yxt+Oh/GFy+JIfxf/vIXP0TH4HJ9/A6DjxHE 4DIC4b0AYsjxdPrTTz/dG1kMCNNFxxxzjDcMq1ev9vXC+TB0dDZGA40aNfIixFQa9423TIeuU6eO r0M6D6KF4WQ0Qv3R4aoDwcDAIUaID9MNCA7fxRQFHZS6YaSD8HMdGGGMB79nfhyjhuHGm8UI2hw8 9cJIg2vBKDBlgSHincgJJ5zgjQqGlGeLEaCM+8Jg8B2ffPKJrwuEgO+nDC+zOpimwmD37NnT/w1T M1OmTPEf/o56Y+oTz9feo2CoqCOmQoC65HnQbrgfxBjhW7ZsmTvrrLP8dB71dChjSZ0wGuL7/vzn P2e1UIJnFI6iq4MpOEYv1rbt/QN9iedAW+e6EXWeFwsKaIvUhz0XwEGhzzDaM2hrePscT/+jLoBn RJ3yHGn3PBMcG+qbdsMHw45zlQnaMlOp1AP9sl69ev57qHNzOLgnHAfOSx+mDdsoiz5Cn0PQbfRL v8Je0F7pB/Qv2ghtuaZFCxKQhEHDovEy3MYoGAz18RowWDRee2mMR8V0Eh4L3pO9PKdT0ojwqjBs GGoaOfPYlHP+sGPjteCNVbcSyKDBIiLMv/Op6Xigc2JU7AU9c+rcBw0dQ4nxtFEP94K3zX1xnYgk v+N6+V6unw7N33EOzkld2PkYiZlHzLF4mVwzHZNzI9Aci5jSAemYnB+hYgqL4w4Fc8bUk80d8/2I NtdDZ+TveX72vseugzK+D/GjzrgXm6YwKOdcZqD5l2dN/VB/vFvA4CKelHEvjO6snrh3Ric8Z4zH oUYg9gw4P0aP8yEUjDC5B9oTAoax5juBc0ZXttFeuWauyaZDuC/uj3LOy/OqCe6N52aLBQ4FbSMb z5kRCu2fthM9L7/Dg+d7ERWunfvmeqmP6GIS2lA4RcroiHbA8dRhOHVJe6RvhNNUPHv6IHV+qJWL TINxDM4Kf2/XxDXybPidTUcbtCnaOffE76xuOBfXaOJG++CZ0mY4TyUsp1cg4SHAwDBsxZPAg8bL KvchaT7BKOBx4+1Rf/xrxjtpYORxHhjpYOj54MHmAwwPI9b/+Z//yWpaSohSQQJyCPAY8VLw3PCy DrVUUlQFT5BRHl4eHnOSg9O4dpafMv2IR5xPIcTzxcNlFJXNiFOIUkECIoQQIhYSECGEELGQgAgh hIiFBEQIIUQsJCBCCCFiIQERQggRi/8HRmnJAEy44FwAAAAASUVORK5CYII= --_004_4A95BA014132FF49AE685FAB4B9F17F645CFFE9Bdfweml701chmchi_-- From nobody Wed Apr 30 16:31:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097881A6F28 for ; Wed, 30 Apr 2014 16:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfsdAMGapFF0 for ; Wed, 30 Apr 2014 16:31:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE01A09CD for ; Wed, 30 Apr 2014 16:31:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 73D31C20B; Wed, 30 Apr 2014 19:31:50 -0400 (EDT) Date: Wed, 30 Apr 2014 19:31:50 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140430233150.GV1256@pfrc> References: <535916F0.3050206@joelhalpern.com> <55AA400B-3D5A-4980-8330-3541A1663586@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/J3wwUkdvksTZcafUsxxn1c3SQqM Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Dean Bogdanovic , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 23:31:53 -0000 Jamal, On Tue, Apr 29, 2014 at 09:47:59AM -0400, Jamal Hadi Salim wrote: > In your slides, IIRC, at the meeting you illustrated several daemons > all interacting with the > agent doing different things. In our case it will very likely be > multiple daemons doing > different things for the agent (and sometimes remote machines). In any > case, this may end up being > an implementation issue. I suspect it may be. I tend to view the Agent as anything from the entire intelligent i2rs portion of the system to something as simple as a light-touch dispatcher for underlying instances implementing portions of i2rs. As an example, a RIB query may be dispatched one way, a BGP query may be dispatched another. The fact that this is happening within the implementation should remain an opaque detail, I think. If we decide to ever get clever about our transport system, as an example using SCTP channels, there's little reason that even the transport endpoint might eventually get tied to the underlying component rather than being fronted by a dispatcher. But lets solve the easier case first. :-) > I have another issue I will post probably under a separate topic: > Prioritization. A topic near and dear to me. :-) -- Jeff From nobody Wed Apr 30 16:48:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9101A6F22 for ; Wed, 30 Apr 2014 16:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m91jPHn6mhmp for ; Wed, 30 Apr 2014 16:48:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 025D91A09D3 for ; Wed, 30 Apr 2014 16:48:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 66EE3C20B; Wed, 30 Apr 2014 19:48:41 -0400 (EDT) Date: Wed, 30 Apr 2014 19:48:41 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140430234841.GW1256@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uv_8TwpBPAzljW5iR37L3d8Z520 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Dean Bogdanovic , Andy Bierman Subject: Re: [i2rs] Clients-Agents protocol prioritization X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 23:48:45 -0000 On Tue, Apr 29, 2014 at 10:19:14AM -0400, Jamal Hadi Salim wrote: > This is back again with node overload. > Our experience with ForCES made us prioritize events and request-response > differently. This is important only when there is an overload case. > As an example if i had sufficient cycles/bandwith/ram space to respond to either > an ADD or an event - I choose to use those resources to process and respond > to the ADD; which means events are not reliably delivered to the clients. > > I think something like this would be needed for I2RS. In our architecture, we are permitting multiple clients to communicate with one agent, so this somewhat compounds the issue. It does permit some amount of discussion of what we can do about a few issues in this problem space: - Pipelining: If you can submit multiple requests but they must be satisfied in the order submitted (e.g. as per netconf), the amount of work that a given request implies has impact on overall throughput. - Even if you're able to bypass this to some extent using multiple client sessions, if the resources you're working with rendezvous at a common blocking point (e.g. some RIB service that has internal mutual exclusion semantics), then this can be problematic. We're not doing locking and thus we're not exploring the semantic of saying "would block". - The work in a reply may be huge. Consider a single client having in its work queue a "add route" and a "give me the entire BGP RIB". Ordering will clearly have impacts on how quickly the add route operation completes. I suspect that (mutex example aside), operational semantics across more than one client session may address many of these issues. What isn't clear is what needs to be addressed in our documents about such issues. -- Jeff From nobody Wed Apr 30 16:50:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8D1A6F65 for ; Wed, 30 Apr 2014 16:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHOixtawe-3D for ; Wed, 30 Apr 2014 16:50:52 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 81D601A6F55 for ; Wed, 30 Apr 2014 16:50:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <001f01cf647b$a1e3a740$e5aaf5c0$@ndzh.com> <53610252.4000800@joelhalpern.com> <004301cf6483$5fbc67f0$1f3537d0$@ndzh.com> <20140430174854.GB31746@elstar.local> <002701cf64a9$76159410$6240bc30$@ndzh.com> <20140430194008.GB31986@elstar.local> <006201cf64b3$5e145c70$1a3d1550$@ndzh.com> <20140430213232.GA32419@elstar.local> In-Reply-To: <20140430213232.GA32419@elstar.local> Date: Wed, 30 Apr 2014 19:50:30 -0400 Message-ID: <001701cf64ce$f8780710$e9681530$@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: AQFK6EKkY2O/kDe4bfslVloTN/UuZgGYPRVsAnMkzoQConKuYQJ2V9EqAqA3orYCW9weEwJKRpjEAVUZlYUCPruT3wK9fPDzm33V1bA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E77M65vJrLlQPKuC2YVbkGAY4t0 Cc: 'Nitin Bahadur' , 'Joel Halpern Direct' , 'Mach Chen' , draft-ietf-i2rs-rib-info-model@tools.ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 23:50:54 -0000 Juergen: I believe that a tool that generates a meaningful YANG data model out of a UML information model requires so many details in the UML model that the UML model stops being an information model. A data model has to be very clear about naming. If you use YANG, you need to transfer an arbitrary graph of classes and their relationships into a tree. The answer to the question what becomes a reference between branches in a tree and what can be captured through nesting does not naturally fall out of a UML class diagram. Perhaps I am overly pessimistic. A key point of an information model is that it focusses on fundamental concepts and that it on purpose leaves out details that are needed in data models. So either your tool transforming UML class diagrams into YANG has a second information source or you have to overload your UML diagrams with details that turn your UML diagrams into a data model. [Sue-on]: Yes, I am focused on the depth of description. Thank you for mentioning it. I am using the concept library of information models. I'm hoping you can just state this links to this UML diagram in the library, and that details for a particular modular can be specified in that diagram. If there is I thought that this was reasonable - to use one level of detail in one diagram (so all could read), and a more detailed reference to the diagram. I'm read and re-reading my tutorial book to see if there is any problem with this in UML. I'm not sure the official way to call this. If there isn't, I'll have to invent it. [Sue-off] > I think the UML is readable. Please comment on my UML drawings that I > sent at the beginning of this post. If you wish a power point of the > UML so you can edit it, I'll send one. > At the Yang step, Andy assures me it is readable so debugging the tool > should be useful. I was answering the performance issue question with > the iterative code. I think this does provide what you require. [Sue] I like to see the UML input and the YANG output or even better the tool. I am happy to see the text I wrote above proven wrong. > Can you tell me where your experience states this is a misstep? See above. I have seen people who added lots of details to their UML class diagrams in order to drive automation until the UML diagrams filled walls and essentially lost their value of summarizing key concepts. [Sue]: Without levels of hierarchy or scoping, the tool is unworkable. The CAD/CAM guys learned to use scoping with diagrams - so would thing UML should do the same thing. Thank you for your kind and very knowledge hints to help me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Apr 30 16:57:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971001A6F22 for ; Wed, 30 Apr 2014 16:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ2icvFqhpOP for ; Wed, 30 Apr 2014 16:57:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93F1A0A02 for ; Wed, 30 Apr 2014 16:57:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BE8B2C20B; Wed, 30 Apr 2014 19:57:43 -0400 (EDT) Date: Wed, 30 Apr 2014 19:57:43 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140430235743.GX1256@pfrc> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <5BFE8EA4-B2D0-4E1F-92E3-D4CA330964AD@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DkkFs8F5ZkFXuXfdh_t6lJ6cEdc Cc: Andy Bierman , "" , Martin Bjorklund , "" , "" , Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 23:57:49 -0000 On Thu, Apr 24, 2014 at 06:24:31AM -0400, Jamal Hadi Salim wrote: > Either I am misunderstanding both of you or both of you misunderstood the > requirement. > The idea is to allow a single writer per object as a starting point. > OTOH, if you really mean what you say then I violently disagree. Single writer per object at a given time. No locking, but also nothing restricting more than one client from modifying the same thing. (The things driving the clients must do the coordinating.) -- Jeff From nobody Wed Apr 30 17:24:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF801A802D for ; Wed, 30 Apr 2014 17:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANW5C1NYG2eO for ; Wed, 30 Apr 2014 17:24:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD61A6F22 for ; Wed, 30 Apr 2014 17:24:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F8A3C20B; Wed, 30 Apr 2014 20:24:51 -0400 (EDT) Date: Wed, 30 Apr 2014 20:24:51 -0400 From: Jeffrey Haas To: Martin Bjorklund Message-ID: <20140501002451.GY1256@pfrc> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140424.131244.180603940339430480.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YIyN82UAn04Pir90fflx5yt0c0Q Cc: i2rs@ietf.org, edc@google.com, ietfc@btconnect.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 00:24:57 -0000 On Thu, Apr 24, 2014 at 01:12:44PM +0200, Martin Bjorklund wrote: > > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt > > > > Figure 1 and Figure 2 show. What YANG does not have is a way of > > correlating the two trees > > See also Lada's reply. > > What kind of correlation are you looking for? The point is that these > are *different* structures, with different semantics. If an entry > exists in the operational state, it doesn't imply there is a > corresponding entry in the config, and vice versa. And just b/c a > config entry also exists in operational state doesn't mean that it is > *exactly* as configured; some other dynamic mechanism might have > changed it. It all depends on what you model. As I try to work through my reading of netconf and yang, the use case we're discussing here is the one that troubles me the most. Let me pick two specific examples of injecting i2rs state on top of something that may have coverage within existing yang configuration models: static routes and BGP. It would be very convenient for purposes of configuring static routes in i2rs where the semantic is ephemeral configuration to not have to duplicate the existing yang model. If the model in question was design to use groupings, it appears that it would be easy to have one instance for normal configuration and a second one specifically for i2rs. It would be even more convenient if we had a semantic that was not only "config true", but potentially "config true|ephemeral". The issues then comes back to the ones noted in draft-bjorklund-netmod-operational-00: How do we distinguish operational, config or ephemeral config states? When there are different precedences (ephemeral overrides static, e.g.), how could you do a get that presents the implemented order? The BGP example to my mind may only go slightly further than this. For some types of i2rs configuration state, I can foresee wanting some portion of it to be based upon non-ephemeral configuration - for example base BGP state that should not be modified by i2rs. Presuming that base state exists, it may be desirable to permit something like BGP peer configuration to re-use the existing BGP yang model for configuration, just in an ephemeral context. Thus, some portions of the configuration are instantiated ephemerally and some require underlying non-i2rs config. > I don't think a separate structure for i2rs routes are needed, b/c it > is supposed to directly modify the operational state. This is where I think we're getting stuck. There is some vagueness between operational state that can be modified and ephemeral configuration. But the real issue is when multiple forms exist, how do we operate upon it/see it in a useful fashion? -- Jeff From nobody Wed Apr 30 17:30:31 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F31A6F1D for ; Wed, 30 Apr 2014 17:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3aPioBgKAT5 for ; Wed, 30 Apr 2014 17:30:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15C1A0981 for ; Wed, 30 Apr 2014 17:30:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B2B47C20B; Wed, 30 Apr 2014 20:30:21 -0400 (EDT) Date: Wed, 30 Apr 2014 20:30:21 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140501003021.GZ1256@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-wF7vERsLYCuEu9xZmOfRZdat5E Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model Requirements WAS(Re: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 00:30:25 -0000 On Sat, Apr 19, 2014 at 06:43:33AM -0400, Jamal Hadi Salim wrote: > So 54 emails later.... [...] And now I'm many beyond that... :-) > Andy, Dean and myself included presented based on our view of what the > requirements are. > There are no requirements spelt out anywhere. Why is this such a hard > question to ask > around an engineering forum? I have to agree that we're not converging on requirements in an explicit form. What I do see is that we're covering implicit forms of the requirements by discussing the proposed solutions and the issues with them. I'll remind all sides that I created wiki stubs for these to be documented. In the absence of someone filling them in, I'll write down some of my own observations early next week. http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/NetconfYangAnalysis -- Jeff From nobody Wed Apr 30 17:34:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F67A1A0981 for ; Wed, 30 Apr 2014 17:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaZskpFg8AmA for ; Wed, 30 Apr 2014 17:34:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EAE461A096A for ; Wed, 30 Apr 2014 17:34:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6B0BFC20B; Wed, 30 Apr 2014 20:34:49 -0400 (EDT) Date: Wed, 30 Apr 2014 20:34:49 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140501003449.GA1256@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FnXKVzdUsRYJ9057PFkRQKjFV6c Cc: i2rs@ietf.org Subject: Re: [i2rs] Operational State X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 00:34:51 -0000 On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote: > This tri-partite split has been the norm for Ops Area for many years > now. > It may or may not be appropriate for I2RS but I do think that I2RS > should > at least take cognizance of this in deciding what terms to use I think this is one of the clearest description of one of our problems - and thus requirements - that I've seen thus far. :-) -- Jeff From nobody Wed Apr 30 17:49:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B764E1A6FFE for ; Wed, 30 Apr 2014 17:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANmBejlVcaAL for ; Wed, 30 Apr 2014 17:49:17 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A2E191A6FC2 for ; Wed, 30 Apr 2014 17:49:17 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 14D52C20B; Wed, 30 Apr 2014 20:49:16 -0400 (EDT) Date: Wed, 30 Apr 2014 20:49:16 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501004916.GB1256@pfrc> References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/u4Q2jWH92wa8y72llD_QFklQx4Y Cc: Nitin Bahadur , "i2rs@ietf.org" , Mach Chen , draft-ietf-i2rs-rib-info-model@tools.ietf.org, "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 00:49:21 -0000 On Wed, Apr 30, 2014 at 07:02:19AM -0700, Andy Bierman wrote: > On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern wrote: > NETCONF and RESTCONF already have a standard Role-Based Access Control > Model, > called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, leave > it > to vendors, or something else? Regardless of the data model and protocol, I believe we'll need something like this for I2RS. Section 3.2.1 of RFC 6536 covers properties that I would suspect would be requirements for any such system. While Joel is correct that we're not to the point of worrying about the details yet until we choose, I suspect that it's not too hard to read the remaining content of section 3 in the context of somewhat more abstract protocol operations and derive impacts on requirements. -- Jeff From nobody Wed Apr 30 22:39:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F591A09FF for ; Wed, 30 Apr 2014 22:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjTX0-gEMoxD for ; Wed, 30 Apr 2014 22:38:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17B1A09F7 for ; Wed, 30 Apr 2014 22:38:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E667B1038; Thu, 1 May 2014 07:38:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7mcu4T7XHHq5; Thu, 1 May 2014 07:38:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 May 2014 07:38:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70DBE20017; Thu, 1 May 2014 07:38:41 +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 lL61OMTRRewY; Thu, 1 May 2014 07:38:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E787420013; Thu, 1 May 2014 07:38:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCE9B2CC7568; Thu, 1 May 2014 07:38:39 +0200 (CEST) Date: Thu, 1 May 2014 07:38:39 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140501053839.GA33275@elstar.local> Mail-Followup-To: Jeffrey Haas , Martin Bjorklund , i2rs@ietf.org, edc@google.com, ietfc@btconnect.com References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140501002451.GY1256@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/89mrZOO-RGX_g66tMyHUF2ohgCg Cc: i2rs@ietf.org, Martin Bjorklund , edc@google.com, ietfc@btconnect.com Subject: Re: [i2rs] consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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 May 2014 05:38:51 -0000 On Wed, Apr 30, 2014 at 08:24:51PM -0400, Jeffrey Haas wrote: > > This is where I think we're getting stuck. There is some vagueness between > operational state that can be modified and ephemeral configuration. Are you saying there is a difference between 'writable operational state' and 'ephemeral configuration' but the difference is still unclear and hence vague? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103